Raphael Hertzog writes ("Re: Triggers status?"): > When there are good reasons, I'm happy to let anyone ignore my > suggestions. But in this case, given that Ian is just learning git > usage I believe that most of the things listed are consequences of > errors / lack of knowledge rather than deliberate choices.
I made a deliberate choice to publish my triggers work as a branch that could be merged in both directions. That was necessary to facilitate merging changes from Debian into the Ubuntu version. It enabled me to make my further substantial changes for my flex experiment based on code that wasn't going to be radically revised. It meant I could merge fixes from the trunk into the triggers branch, and then into the flex branch, or just into the flex branch if I wanted just to work on that at a particular time, without undue difficulty. (By undue difficulty I mean without imposing undue work on a human, for example by generating spurious conflicts on merging or requiring a particular conflict to be resolved twice.) It meant that I could publish triggers, and my flex experiment, in a way that means that other people can edit their own versions and contribute aappropriate. I was able to do all of these things straightforwardly and with a minimum of fuss, once I'd got used to git's slightly odd terminology and the usual initial kind of minor stumbling block with a new tool. The only problem seems to me that you are objecting to this mode of interaction. Can you please explain what is lost by my approach ? > If this is a deliberate choice, then why not. But I believe this is just > the result of not having set up the user.name and user.email git > configuration items... No, it's due to a bug in the Debian git package, which should have acquired my email address in the standard way. In that case it would have used a correct address. > Well, plain "git rebase" compared to "git merge" only avoids (possibly > repeated) merge commits. It doesn't change contents of the patches and > doesn't changes author dates / emails. AIUI git rebase also prevents repeated merging backwards and forwards between different branches. > Many git tools rely on this convention to offer differing short/long view > of changesets. So I don't like when the first line of the commit log is: > "dpkg (1.14.5ubuntu16) gutsy; urgency=low" I agree that this is unhelpful. I can't remember why I didn't use debcommit at that point but I'm using it nowadays and I'm happy to continue doing so. Is there really merit in going back and fixing old commit log entries ? > Then you're right, it looses history, so it's not required to proceed that > way. But in many cases, it can ease the review because you'll present your > change as a coherent serie of patches: > - logical change 1 > - logical change 2 > - logical change 3 The actual triggers functionality isn't sensibly divisible in this way and the individual bugfixes which I've made at the same time are too trivial to care about in this way. > Sure, patches are perfectly fine. If I were to supply patches and you were to apply them, my flex branch would be completely messed up, wouldn't it ? Next time I wanted to do a merge it would try to apply another copy of the triggers changes. The whole point of using a drcs is to avoid that kind of thing. > I wish we could have a quicker review/integration cycle. But submitting a > git branch in the form that Ian used doesn't help much unless you follow > the conventions of the team. I don't understand how presenting it as a git branch can be inferior to presenting it as a patch. For the purposes of review, git can tell you exactly what the changes are. The difference is that if you merge from my branch, my other branches don't get trashed. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]