Raphael Hertzog writes ("Re: git bikeshedding (Re: triggers in dpkg, and dpkg
maintenance)"):
> As soon as you edit commits, they'll get a new id, and thus you'll disrupt
> merging.
As I thought.
What I am trying to achieve is to use git in the proper way: that is,
in a way which makes merging work properly.
Insisting that I use git in a manner which makes merges break but
gives prettier logfiles is absurd.
> The thing that you doesn't seem to understand is that if you don't do it,
> Guillem will do it for you and you'll have to fix up your other branches
> (flex-based parser, ...) anyway and you won't be able to use plain merge
> for that (or rather you can but it will be highly inefficient compared to
> a "git-rebase -i" where you skip the irrelevant commits that have been
> merged with other id).
Only if Guillem insists on not taking on board the points that I and
others are making here.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
