[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)

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.


Reply to: