rethinking patch management with GIT / topgit

[Petr Baudis]

On Sun, Mar 28, 2010 at 08:21:48AM +0200, Enrico Weigelt wrote:
> > You would want to still use something like the topgit model in your 
> > "forked upstream", since again, you will probably want to have the
> > two desirable properties we seek to preserve - to reiterate them,
> 
> Actually, I dont want to - I want (and *do*) simply rebase.
> Gives me a clean history and branching graph.
> 
> >   (i) Have full and incremental history available for all changes.
> 
> I dont want all changes I ever made (if I want to, I still have the
> old tags around) - I just want those changes which are needed from
> upstream to my branches in a clean line.
> 
> >   (ii) Have the ability to produce a diff from current version to
> > current upstream version for each logical change, for purposes of review
> > or e.g. upstream submission.
> 
> git log ?
> tig ?

But if you need to fix up an already committed commit, you either make
a new commit, which will break (ii), or you rebase, which will break
anyone else working on a clone of your repository and break (i).

That's what my argument boils down to. Sure, if you want to keep things
simple, don't care about distributed workflow or keeping full history,
there's no need for TopGit complexity. But sometimes you *do* care.

-- 
				Petr "Pasky" Baudis
http://pasky.or.cz/ | "Ars longa, vita brevis." -- Hippocrates