Re: git bug? + question

On 2006-11-02 22:45:49 -0500, Sean wrote:

One thing that would make separate-remotes nicer to work with is to
have an automatic mapping between any local branch and one of the
same name in remotes.

So for instance, if you have a local branch named pu checked out and
you pull from origin, remotes/origin/pu would be merged after the
fetch unless a manual mapping was defined in the remotes or config
file.

I would rather see the default pull source of a branch being
determined by which branch it was branched off of. But this should
mean the same thing in this case. We'd just have to have the heuristic
that default pulls from a remotes/*/* branch causes a fetch, while a
default pull from a local branch does not.

Maybe even going as far as automatically creating a local branch for
each remote branch on clone is worth considering.

Yes, maybe. It should make for a good default for beginners, at least.

On a peripherally related topic, someone on the xorg list was
complaining that after the initial clone, there is no easy way to
track branches that get added/deleted from the remote repo. It would
be nice if pull had an option to automatically add and remove remote
branches from the remotes/<remote>/xxx namespace.

That would definitely be useful. But I want it in fetch, not pull. :-)
Well, I suppose it could be in both.

Hmm, I think my dislike of remote pulls can be summed up as: I find it
convoluted to have a command that will fetch multiple remote branches,
then merge just one of them into my current branch. (I have no problem
with pull when the branches to pull are specified explicitly, since in
that case they are all merged.) With explicitly specified default pull
sources it would get better, since then I would know that the correct
branch would be merged, but I still don't quite like it.

-- 
Karl Hasselström, kha@treskal.com

On Fri, 3 Nov 2006 09:12:32 +0100
Karl Hasselström [off-list ref] wrote:

I would rather see the default pull source of a branch being
determined by which branch it was branched off of. But this should
mean the same thing in this case. We'd just have to have the heuristic
that default pulls from a remotes/*/* branch causes a fetch, while a
default pull from a local branch does not.

Well, when you create a branch a branch.<branch>.merge entry could be
automatically made so that a merge from the proper place happens.
But in the absence of any config merge entries, it would be nice to
default to the same branch name from the remote namespace.  This
removes the need to create merge entries for the initial clone.
Of course, currently you have to create branch.<branch>.merge
entries by hand.

quoted

On a peripherally related topic, someone on the xorg list was
complaining that after the initial clone, there is no easy way to
track branches that get added/deleted from the remote repo. It would
be nice if pull had an option to automatically add and remove remote
branches from the remotes/<remote>/xxx namespace.

That would definitely be useful. But I want it in fetch, not pull. :-)
Well, I suppose it could be in both.

Yes.
 

Hmm, I think my dislike of remote pulls can be summed up as: I find it
convoluted to have a command that will fetch multiple remote branches,
then merge just one of them into my current branch. (I have no problem
with pull when the branches to pull are specified explicitly, since in
that case they are all merged.) With explicitly specified default pull
sources it would get better, since then I would know that the correct
branch would be merged, but I still don't quite like it.

Yeah.. Although fetching multiple remotes makes more sense as an
optimization, especially when using a separate remotes namespace.
Perhaps the real confusion is created because the only porcelain 
level merge command current in Git is "git pull .".  A separate
name might make things easier to grasp.

Sean