Re: [PATCH] GIT commit statistics.

From: Petr Baudis <pasky@suse.cz>
Date: Nov 12, 2005, 12:53 UTC
Message-ID: <20051112125331.GB30496@pasky.or.cz>
In-Reply-To: <46a038f90511120419v70166c60t93d58b7544e03e3b@mail.gmail.com>

Dear diary, on Sat, Nov 12, 2005 at 01:19:45PM CET, I got a letter where Martin Langhoff <martin.langhoff@gmail.com> said that...

Show 5 quoted lines

> The same process would be much easier if I could just cg-update from
> the repo and get it to try and actually rebase my local commits --
> rewriting history as if I had committed them after the update. Of
> course, it'd be cheating... but we cheat all the time anyway, we only
> sweat harder at it ;-)

I'm a bit reluctant about this functionality available in cg-update, but then people will start to want commit stack and stuff, while they should be just already long using StGIT for tracking their patches.

Actually, I wanted to also implement e-mail functionality to cg-mkpatch, but I'm not sure now - perhaps people wanting that should really just use StGIT. Cogito or GIT core is not very suitable for keeping your patches against someone else's tree if he is not going to GIT-merge with you, exactly because it's not really very convenient to update your patches.

On the same note, I would like StGIT to drop functionality not really belonging to patch stack manager (stg add, stg rm, stg status, ...) so that its commandset gets smaller and more focused - but before I would suggest dropping stg status, cg-status must be able to do conflicts tracking, so I will dedicate another mail to this sometime in the future, with a more detailed proposal.

So, is there any reason why you want this in GIT/Cogito and don't want to use StGIT?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.