Re: Triggers status?
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
Reply to: