Multi-commit feature sequences...

[David Kastrup]

Well, I tried pushing a multi-commit change as a single merge commit
right now.  The idea behind this was that the last commit in the
sequence was getting most of the testing attention, and usually nobody
will gain from bisecting possibly suboptimal commits in the sequence (I
did try to make reasonably sure the individual commits pass compilation
and testing, but they got less attention overall).  Sort of an
experiment in order to figure out whether it makes sense proposing that
kind of workflow.

Consider it as an experiment (yes, I know, I have bad timing for
experiments, but it looked quite clean and orderly before pushing, and I
had no idea how to complete a workflow test without pushing).

Some things catching my attention:

a) git does not particularly fancy that workflow: when the feature
   branch is strictly ahead of master, it does a "fast forward" that
   does not create new commits but just moves all the commits into
   master.  You need to call git merge -no-ff to get a true merge.
b) The commit message is autogenerated, so you better have given your
   branch a nice name.  Or use -m and/or --log.
c) If you do "git log", you get the individual commits listed.  However,
   HEAD~1 refers to the state before the merge.  So this should be
   pretty much what is most convenient, in particular counting as a
   single commit for bisecting (and reverting!).  If bisecting points to
   the merge commit, you can presumably just bisect starting from the
   second parent commit.
d) "Translation of GIT committish: xxx".  Uh.  What to put into
   "committish"?  Likely the merge commit.  It would likely make more
   sense to use the GIT hash of the source file object rather than the
   commit, since that is tied to the contents of the file rather than
   its history, and the translators are concerned with the contents.
   But object ids are actually rather well hidden in git...  Something
   like
git rev-parse HEAD~1:Documentation/extending/programming-interface.itely
   cranks out the object id for a file belonging to a certain revision
   (and as long as the file contents do not change, the id does not
   change).  But it is rather hard to discover this kind of
   information.

Overall, the results look reasonably consistent and usable.  Given that
people are likely not too enthused digging into git's depth all too
much, I am not sure this is worth proposing as a general workflow.

-- 
David Kastrup