Re: Multi-commit feature sequences...

[Janek Warchoł]

2011/9/8 David Kastrup <address@hidden>:
>
> 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.

I certainly am a bit intimidated... (not that i am a very
representative member of developer team)  That's a bit deeper level
than what i used to do with git until now.

cheers,
Janek