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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
