Re: [Gnu-arch-users] Re: Future of GNU Arch, bazaar and bazaar-ng ... ?

[Martin Langhoff]

On 8/23/05, John A Meinel <address@hidden> wrote:
> I still feel like StGIT is barking up the wrong tree. You have a tool
> which handles repeated modifications and merging, and then you put
> another one on top of it that does exactly the same thing, only throwing
> out history. So why not just give a "throw out history" option, and then
> not have to worry about multiple pieces repeating themselves.

hmmm. There's a bit more than just rollup or not. 

I think that the "formality" requirements for the commits you'll want
to keep for a long time and (most importantly) publish as stable,
reference-able, immutable objects so that you can run a distributed
SCM make it really hard and painful to be flexible.

There are lots of things you can't do, that you _should not_ do with
real "hard" commits in a distributed SCM because people need to be
able to refer to them as an immutable object. The GIT/StGIT combo
gives you hard, immutable, publishable commits as well as soft,
malleable patches.

The hard commits provide guarantees you can hang your distributed scm
infrastructure from. The other ones don't, but provide a means of
discussing and polishing code.

I understand your 'one tool' idea, though. Now, even if you have it in
one tool, you will want the commands to be different, to avoid
confusion. You don't want to accidentally commit when you are pushing
a patch into the stack.

And StGIT's syntax follows the same conventions and patterns that git
does, with different commands. Not a bad thing for me, at least.

> This would give the newbie hacker a consistent usage (so their method of
>developing doesn't just suddenly change once they have become
> respected),

AFAIK most kernel hackers still use StGIT. People use it as an
'extension' of git to have additional commands, not as a separate tool
as in a 'separate SCM'.

Have you seen this http://wiki.procode.org/cgi-bin/wiki.cgi/StGIT_Tutorial ?

cheers,


martin