Re: Question on empty commit

Luben Tuikov [off-list ref] writes:

Ok, so what I'm seeing is that git history records what the _user did_
as opposed to _what happened to the code_.

Is it possible to have an env var to control this "feature".  I.e. if
the result is 0 lines 0 files changed, then do not update the index and/or
the git database.

Good question.  We could go stronger than that, and say it would
make more sense not to make that commit by default, except when
the merge was done with "ours" strategy (it explicitly asks for
an empty commit to make it stand out that trees were in sync at
that point), or the merge was manually resolved and the result
happens to match what treeB already had.

Why?

          treeB ---------o--o--o--*--o--o---*--o..?
                                 /         /     .
                                /         /     .
          common upstream ---- / --o--o--o--o  .
                              /           \   . 
                             /             \ .
          treeA ------o--o--o---------------*
                                    ^
                                    |
                     No commit on this segment.

                o are commits, * are merge commits.

At point '?' we can choose not to make a merge.  You could,
after seeing such an empty merge, emulate this behaviour by
doing "git reset --hard HEAD^" yourself.  Then some time later,
when treeA truly has something new to offer treeB, the next
merge attempt will create a true merge commit at '!':

          treeB ---------o--o--o--*--o--o---*--o--?--o--o--!
                                 /         /     .        /
                                /         /     .        /
          common upstream ---- / --o--o--o--o  .        /
                              /           \   .        /
                             /             \ .        / 
          treeA ------o--o--o---------------*--o--o--o

When we have the last two 'o' commits on treeB development
track, creating '?' merge _might_ have some value, because we
can clearly see that those two new 'o' commits on treeB are
compatible with the '*' merge commit on treeA track.  Without
the merge at '?' we would not be able to tell that, so in that
sense it is a small plus to have '?' merge commit, and it may
even help bisection bug hunting.  But in practice it may not
matter and just clutter your history.

Especially if we did not have the last two 'o' commits on treeB
line, making an empty merge commit at '?' would mostly be
pointless.


          treeB ---------o--o--o--*--o--o---*--o--?--------!
                                 /         /     .        /
                                /         /     .        /
          common upstream ---- / --o--o--o--o  .        /
                              /           \   .        /
                             /             \ .        / 
          treeA ------o--o--o---------------*--o--o--o

But unfortunately we cannot tell if we are going to build on top
of '?' before we merge with treeA again next time at '!', when
we are at point '?', so we could have an option or environment
variable to control this "feature", but unless you can predict
the future at point '?', deciding whether to use that option
would be rather difficult.