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

[John A Meinel]

Martin Langhoff wrote:
> 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?

All this says to me, is that you want the ability to do either a
rollup-commit, or a pull everything commit. Bzr is currently moving into
the pull-everything land (it currently keeps a back-pointer, but the
merge code isn't greedy enough to pull all the revisions into the
current tree).

Since you want to apply something as "just-a-patch" it would be
something like a hypothetical:

"bzr merge --no-history"

That can work by either not referencing the other history at all, or it
can do it by referencing the history, but not pulling it locally. The
nice part of the latter is that future merges will work too.

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.

This would give the newbie hacker a consistent usage (so their method of
developing doesn't just suddenly change once they have become
respected), and they haven't been taught the bad practise of "play with
it, don't actually commit until you are 100% sure that everything is
worked out". My personal philosophy is "commit everything that you do,
mainlines are where you sort out what works and what doesn't".

But then again, I use my source control to move back and forth between
about 5 different machines. So I'm used to committing things in a broken
state, just because I'm going somewhere else and I want to keep working
on it there.

I definitely agree that rollup changesets and history preserving
changesets are both useful. I'm just arguing to use the already builtin
functionality to do it, rather than tacking it on in a single front-end
that might use a format no other front-ends can read.

John
=:->

>
> cheers,
>
>
> martin
>

signature.asc
Description: OpenPGP digital signature