[PATCH] Branch and pull-- now with remote

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Erik Bågfors wrote:
> On 5/29/05, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:

>>you might want to have more than one merge source, whereas I think it
>>makes sense to have just one pull source.
> 
> 
> Might be true.. but there should be some way to refer to the default
> branch.  Branch must somehow store which branch it was branched from,
> so that pull knows what to pull (terrible sentence :) ).

Yes.  It's a file structure issue.  Should there be an x-pull-location
file and an x-merge-location file?  Should they be unified?

> bzr merge default? (Maybe not)...

"bzr merge" is fine.  It's more of an implementation issue than anything
else.  The latest merge code is in one branch, and the branch/pull code
is in another...

> Well, if I create a neat feature, and I put that on a branch
> somewhere, and you cherry-pick it, and it doesn't conflict. Why
> shouldn't I be the committer, keep my commit-message, etc?

That's a simple case, where it's easy to say yes.  But say you create a
feature branch that I merge.  Your branch has multiple commits.  So
which commit message do I use?

Say someone else commits some of the changes to that branch.

So which author should get credit?

And there's an argument to be made that while the original author
deserves credit (e.g. in another metadata field), the 'committer' field
should always reflect who actually committed the code to that branch.

After all, by committing your code, I am, in effect, signing off on it,
and someone who trusts me would accept my sign-off even if they didn't
know you.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCmfJy0F+nu1YWqI0RAkM3AJwOgKihPxlt3OZDP1zSorqXhMpB3wCcDagU
wKdN7BwnONzDuUzbYpXaYUQ=
=kYVf
-----END PGP SIGNATURE-----