Back merging master into topic branches

[Tim Janik <timj gnu org>]

On 18.10.2016 15:35, Stefan Westerfeld wrote:
> > > I tried it, while merging master into wip/soundfont-merge there are the
following
> > > problems:
> > >
> > >  * git diff [ foo.cc ] will show all changes in master, that is a lot
> > >  * it can be workarounded using explicit git diff master [ foo.cc ]
> > >  * also, git status produces a looong list of stuff, due to the number
> > >    of changes in master
> > >
> > > also after the merge gitk will show every change in master if you select
> > > the merge commit and look at the history.

After working on your branch and merge commits for a couple hours, I'm not sure
that actually is a problem. But see below.

> > > So the next thing I tried was reversing it, and create wip/soundfont-merge
> > > as proposed:
> > >
> > >  * git diff shows the expected thing (diffs created by soundfont code)
> > >  * git status shows the expected thing (status changes by soundfont code)
> > >
> > > after merge gitk will show the soundfont branch history.
> >
> > Hm, gitk shows a combined diff for the merge... Just learning how to read
that from git-diff(1) ;-)
> > With git diff, I suspect you view this:
> >   git diff 1698dc960d2607323551a72c59d581efdbe6e1fc^!
> > I.e.:
> >   *   1698d # Merge branch 'wip/soundfont' into wip/soundfont-merge (8 days
ago) <Stefan Westerfeld>
> > Right?
>
> Right.

I find this makes it really hard to follow the commits of the feature branch.
I'm trying to cleanup and merge the history on the entire branch from your
current wip/soundfont-merge and in the end would like to:

a) get a patch series that reflects all soundfont patches since f126a239 (where
the original soundfont-support branch was started),

b) squash the patch series into a single commit for review and discussion purposes.

The only way I see that is to always do:
  git checkout feature-branch
  git merge master
And in the end use:
  git log --first-parent

As for the diff, if I navigate to a merge commit, I can get either diff:
  git checkout c71b02f619f74e2ae2fdd8890c9af1d34fa3496b
  git diff HEAD^1 # shows soundfont applied on top of master
  git diff HEAD^2 # shows recent master changes applied on top of soundfont
  git log --first-parent # gives only master changes and no SF2 stuff
  git log # gives occasional SF2 commit with lots of master stuff mangled in

Reconsidering the above, I think I'll stick with my initial suggestion and fix
up the history [1] so that master indeed gets merged into the SF2 branch every
once in a while.

Do you have any compelling reason otherwise, apart from the behavior of "git
diff HEAD^" which you'd like to equal "git diff HEAD^2"?

Note about the git diff HEAD^1 case, in the context of the entire branch, this
actually _wrongly_ shows every SF2 change twice, once in the non-merge commits,
and then replicating it in the "against-master" merge diffs.

I quite often use git log -p to view diffs. Ideally so that I can review the
feature branch diffs w/o any master changes. I don't see a way to get that to
work with your merge order, but if the parent order is always
<intergration-branch> <other-changes>, I can at least use git log -p
--first-parent to review a single integration/topic branch's history.

See also the manual page on git log for this:

       git log -p -m --first-parent
           Shows the history including change diffs, but only from the
           “main branch” perspective, skipping commits that come from
           merged branches, and showing full diffs of changes
           introduced by the merges. This makes sense only when
           following a strict policy of merging all topic branches
           when staying on a single integration branch.


[1]
http://stackoverflow.com/questions/25265528/how-do-i-swap-the-order-of-two-parents-of-a-git-commit/36528357#36528357
 - note GIT_AUTHOR_NAME + GIT_AUTHOR_DATE also must be adjusted

-- 
Yours sincerely,
Tim Janik

https://testbit.eu/timj/
Free software author.