On Thu, 2007-10-25 at 16:30:24 +0100, Ian Jackson wrote: > Raphael Hertzog writes ("Re: Triggers status?"): > > And it would be wise & fine to proceed that way if your history > > was clean and all. I was just showing you that loosing the history > > doesn't involve as much work as you expected to, but of course it's > > more work.
> I don't know what you mean by `not as much as you expected'. > The results you demonstrated seemed entirely consistent with what I > expected and it is precisely that kind of merging makework that my > approach avoids. > > Doing extra merge work for the benefit of cosmetic redaction of commit > logs (which is IMO itself of doubtful value) seems an absurd tradeoff. > Merging substantial conflicting changes is one of the most demanding > and error-prone programming tasks. I'm astonished that you're > seriously advocating a workflow that prefers to have humans running > around fixing up mistakes made by computers. If this was about fixing only log entries, there's several ways to accomplish that that imply zero conflict resolution while merging, 'git commit --amend', 'git format-patch' and editing the resulting mails, 'git cherry-pick -n', the more advanced 'git-filter-branch', etc. > Guillem, do you have an opinion about the use of git I'd like to see the changes split in logical patches/commits, with proper log messages. It makes the review task easier, but more importantly it makes the history in the main repo clearer, for people to dig into if needed in the future, or in the present, via the debian-dpkg-cvs mailing list, which is how the other part of the peer review is done right now. The fact that those changes are in a branch is no excuse to treat them in a different way in which they would be treated if submitted as incremental patches. To git this distinction is not meaningful; push, pull, format-patch, etc, are just ways to transfer the changes. It might also be easier for you to not make new changes dependant on some of your existing branches, to avoid unneeded conflicts and also this way merging them into the main repo should be easier. I also get the impression that your current workflow and derived complaints stem from a lack of familiarity with git and its commands and possible workflows, which should allow you to do less manual work and not more! I think there's enough people here that can (and might be willing to) help with specific issues. > or (preferably!) about the actual code ? I've not yet properly reviewed it, just skimmed over the changes some weeks ago, and found some of the problems Raphael described. I'd like to finish the current release and then I'll focus on the triggers stuff. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]