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:
> Then again, this is also handled well by having a mainline and a
> micro-branch, and doing a final rollup commit into the mainline.
> In fact, that is exactly what StGIT is doing, only they throw away the
> microbranch when they are done.

Almost, but not really. There *is* a difference that I think is relevant.

With git you're micro-branching and micro-merging all the bloody time,
unless you work with yourself. Unless there's conflict, all the
merging happens automatically/transparently. So far, nothing new. Now
each merge carries all the commits. It is _not_ one commit, it brings
the history.

After the fact, a linearized log of a given "personal" branch has all
the other commits rather than the "merged from upstream" commit that
included a dozen upstream commits, now in one fat blob. Looking at the
changelog is _much_ more useful, as I traverse the public and
"branch-local" commits as a single streamlined history.

Compared to that, Arch loses a lot of content, data and interesting
stuff every time it merges. For instance, if at a later time you find
that in the merge a bug was introduced and you want to track down
which commit/author it was... you depend on the remote Arch repo to be
alive and available. If it's gone, your context is gone with it too.
Now sure how well bzr does in this front, I sure hope it's more
git-ish.

Git's approach of 'merging history' is great for the core team of a
project (foss or otherwise): you can work with great hackers in
disconnected fashion and when you sync, it brings all the commits as
if you had all been working on a central repo. The history that is
important to the project is preserved. If you open a feature branch,
when you merge it in, it brings all that valuable history with it.
Yay.

On the other hand, there's a wannabe hacker that's dabbling away on a
little patch,  committing and recommitting better send you a plain ol'
diff, you don't want to merge the history of his silly
edit/commit/post/reject cycle into the project history. I'm sure his
commit messages say bad things about your mother too...

If the wannabe hacker starts doing this more often, he'll probably use
StGIT, as it helps the process a lot. Instead of committing on top of
bad patches, you push/pop/edit the stack.

Does that make sense? 

cheers,


martin