2011/9/8 David Kastrup <d...@gnu.org>: > > 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
