confusion over the new branch and merge config

OK I know I'm a total idiot and honnestly I didn't look at the code implementation at all because I don't expect newbies to even look there.

But here's some pitfalls I'm sure people are likely to encounter...

$ git clone git://git.kernel.org/pub/scm/git/git.git git
Initialized empty Git repository in /home/nico/test/git/.git/
remote: Generating pack...
remote: Done counting 34527 objects.
remote: Deltifying 34527 objects.
remote:  100% (34527/34527) done
Indexing 34527 objects.
remote: Total 34527, written 34527 (delta 23920), reused 34111 (delta 23623)
 100% (34527/34527) done
Resolving 23920 deltas.
 100% (23920/23920) done
Checking files out...
 100% (748/748) done

[ wooh! I feel good ]

$ cd git
$ git branch
* master

[ Hmmm... there used to be many more (remote) branches before.  Where 
  are they? Looking into .git/refs I see a remote/ directory and all 
   remote branches are there.  But I'm cheating now because a newbie 
   might not even think of looking there.

   Ah? there is -a and -r options to git-branch.  Fair enough. ]

$ git branch -r
* master
  origin/HEAD
  origin/html
  origin/maint
  origin/man
  origin/master
  origin/next
  origin/pu
  origin/todo
$ git checkout next
error: pathspec 'next' did not match any file(s) known to git.
Did you forget to 'git add'?

[ WTF!?!?  This definitely used to work before.  OK it is listed as
  "origin/next" so let's try to be consistent. ]

$ git checkout origin/next
git checkout: to checkout the requested commit you need to specify
              a name for a new branch which is created and switched to

[ Hmmmmmmmm.... /me stares at the message wondering.
  I just want to _see_ and maybe _install_ the code from "next". ]

$ git checkout origin/next local_next error: pathspec 'local_next' did not match any file(s) known to git. Did you forget to 'git add'?

[ But it just said to me above that I needed to provide a name for the 
  branch to be switched to...  Why doesn't it just work? F***ing tool!

  OK I'll use my git knowledge and cheat again. ]

$ git checkout -b local_next origin/next

This is I think a good example where user experience might still be improved. First the message about "providing a name for a new branch" could certainly be less anbigous.

Then the "next" branch name could possibly be made to work without the "origin/" if there is no conflict?

And there was a discussion about allowing checkouts to be made from a remote branch but not allowing any commit on it. What happened of this idea?

Now that I have my local_next branch, I want it to be kept up to date when performing a pull. Before the "next" branch sort of was always updated, but now it is a separate thing I cannot see directly and I need to pull it in my local version.

$ git pull origin/next fatal: The remote end hung up unexpectedly Cannot get the repository state from git://git.kernel.org/pub/scm/git/git.git/next

[ WTF?  Where that ...pub/scm/git/git.git/next comes from?  Hmmm... ]

$ git pull next fatal: 'next': unable to chdir or not a git archive fatal: The remote end hung up unexpectedly Cannot get the repository state from next

[ ... an even more interesting set of error messages.

  Yeah, Linus says you must use git-pull . blah syntax. ]

$ git pull . next error: no such remote ref refs/heads/next Fetch failure: . $ git pull . origin/next error: no such remote ref refs/heads/origin/next Fetch failure: .

[ F**K YOU STUPID TOOL !!!  OK let's cheat a bit again. ]

$ git pull . remotes/origin/next Already up-to-date.

[ Woooh!  But since I always hated this syntax let's try merge instead. ]

$ git merge origin/next Already up-to-date.

OK here again various error messages could be improved. The fact that a remote connection was established in some cases is really dubious. And git-pull not accepting "origin/next" is IMHO a bug.

Well well... But I don't want to perform this two-step git-pull+git-merge all the time. So let's have a look at this promising warning:

$ git pull origin
Warning: No merge candidate found because value of config option
         "branch.local_next.merge" does not match any remote branch fetched.
No changes.

So this means that branch.local_next.merge should be set to origin/next? Let's have a look at the default in .git/config:

[remote "origin"]
        url = git://git.kernel.org/pub/scm/git/git.git
        fetch = refs/heads/*:refs/remotes/origin/*
[branch "master"]
        remote = origin
        merge = refs/heads/master

But according to the warning above, branch.master.merge should have been set to refs/remotes/origin/master, not refs/heads/master, right? Otherwise does this mean that master will merge itself into itself?

This is where my own git experience stops as I don't understand the above for real. So let's see the doc:

|branch.<name>.merge::
|        When in branch <name>, it tells `git fetch` the default refspec to
|        be marked for merging in FETCH_HEAD. The value has exactly to match
|        a remote part of one of the refspecs which are fetched from the remote
|        given by "branch.<name>.remote".
|        The merge information is used by `git pull` (which at first calls
|        `git fetch`) to lookup the default branch for merging. Without
|        this option, `git pull` defaults to merge the first refspec fetched.
|        Specify multiple values to get an octopus merge.

Hmmmmmmm... Even after reading this twice I'm still not sure what it really means. But as I said at the top I'm an idiot.

Nicolas

Nicolas Pitre <nico@cam.org> writes:

A newbie might not even expect to see "many more branches" because there is no "before" for him.

Rewording to suggest "checkout -b newbranchname origin/next", perhaps?

"git checkout -b next origin/next" should work just fine, I think.

There was a talk about allowing "checkout -b <new> <track>" to add branch.<new>.merge and branch.<new>.remote if <track> can be proven to corresond uniquely to one remote and one branch from that remote; I think that would match the expectation most of the time but that "most" would not be 100% nor even 80%, so I think that should be an optional feature. In any case, there was a talk but there is no code yet.

It remains to be an idle talk without any code. Contributions appreciated.

This comes from ancient request by Linus to allow:

	$ cat .git/remotes/jgarzik
	URL: master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/
	$ git pull jgarzik/misc-2.6

See http://article.gmane.org/gmane.comp.version-control.git/6181 for the full text.

Personally I thought this was confusing when I implemented it the first time, and I still find it confusing.

I suspect nobody uses it. I am all for removing this "URL prefix shorthand" feature in v1.5.0.

Yes, that is one of the reasons that you would prefer 'merge' when you are working locally.

No, the message says "any REMOTE branch" -- refs/heads/next is what it is called at the remote, and that is how the value is expected to be spelled; I think somebody added an example to config.txt recently to stress this. The above error messasge obviously was not clear enough. Rewording appreciated.

On Thu, 21 Dec 2006 15:01:21 -0800 Junio C Hamano <junkio@cox.net> wrote:

This seems inconsistent and confusing. When working with the local repository, git-branch doesn't list that as "refs/heads/next" it just lists "next". Why all of a sudden when trying to fetch it from a remote repo must a user know about "refs/heads"?

This seems like an internal detail slipping into the user interface. But maybe i'm wrong, when would it ever be anything other than "refs/heads/<branch>"? If it's _always_ "refs/heads", couldn't that prefix just be assumed if not provided by the user?

Sean

Sean <seanlkml@sympatico.ca> writes the value of branch.<me>.merge being the name at the remote site, saying:

Check the archive for messages on this issue that talks about the case without tracking branches.

Sean <seanlkml@sympatico.ca> writes:

You can always say "git log refs/heads/next" even though you are allowed to say "git log next". Maybe we should remove that shorthand to make it consistent? I think not.

The remote side can add things without your knowing, so insisting on the exact match makes sense in a weird sort of way.

And this is a config file you would set once and then can forget about it. I do not see a big deal about having to spell it fully.

On Thu, 21 Dec 2006 16:46:46 -0800 Junio C Hamano <junkio@cox.net> wrote:

Of course not. But why not add the shorthand to the other case to make it consistent?

I'm sure there are technical reasons why things are they way they
are, nothing weird about that.  But looking in from the outside
and not knowing what those reasons are, leads to an honest
question if it's absolutely necessary for a user to have to learn
about the internal "refs/heads" directory structure of Git.
It would be nicer if they could just think in terms of branches
and tags.
 

It's not a huge deal, it's just one more slightly unexpected thing for a user to have to deal with in learning Git. It seems reasonable for a user to be able to refer to a remote branch as "remote/branch", and not "remote/refs/heads/branch". But if that simply can't be accommodated, so be it.

Sean

On Friday 2006 December 22 00:46, Junio C Hamano wrote:

On a related subject - I'd like to remove all the "refs/" literals from git. All refs are always under "refs/", so prefixing everything with refs/ is just noise.

The place that makes it stand out that this is wrong is (I think) found in refs.c (excuse my abuse of syntax):

int for_each_ref(each_ref_fn fn, void *cb_data)
    return do_for_each_ref("refs/", fn, 0, cb_data);
int for_each_tag_ref(each_ref_fn fn, void *cb_data)
    return do_for_each_ref("refs/tags/", fn, 10, cb_data);
int for_each_branch_ref(each_ref_fn fn, void *cb_data)
    return do_for_each_ref("refs/heads/", fn, 11, cb_data);
int for_each_remote_ref(each_ref_fn fn, void *cb_data)
    return do_for_each_ref("refs/remotes/", fn, 13, cb_data);

What's significant is that it is only for_each_ref() that hands the prefix 
back.  The change I'd like to make is 
    return do_for_each_ref("refs/", fn, 5, cb_data);

Obviously, this will imply a lot of changes everywhere else; so I didn't want to dive into it without mentioning it here first.

Is this a sensible thing to want to do?  

As I'm talking about code cleanups, I'd also like to change all variables called "sha1" to "hash" (or similar). The point being that the variables hold hashes not sha1's.

I don't say that the above are serious problems, I just like cleaning code :-)

Andy

On Thursday 21 December 2006 23:01, Junio C Hamano wrote:

Added snipped content back in

And according to the man page git branch -r should print ONLY the remote branches

What about the error message saying that origin/next is read only. Something like

git-checkout: the requested commit is on a remote read only branch. You need to specify a new local branch with the -b option to proceed.

Alan Chandler <alan@chandlerfamily.org.uk> writes:

Heh, sounds like you spotted a bug -- patches welcome (or I'll fix it myself if I get around to it before everybody else). Thanks.

I agree that explicitly suggesting the use of -b is a good idea, but your wording is a bit too specific; after all you might do

	$ H=`git-rev-parse origin/next`
        $ git checkout $H

and there is not enough information to say "is on a remote read only branch". We could do that with more specific hacks in git-checkout; patches welcome.

On Friday 2006 December 22 08:21, Junio C Hamano wrote:

I can't reproduce this bug. I tried having an identically named branch in both remotes and heads. Output was fine. I don't like to say "impossible", but it certainly seems that

This from append_ref():
    } else if (!strncmp(refname, "refs/remotes/", 13)) {
        kind = REF_REMOTE_BRANCH;

and this from print_ref_list():
    if (ref_list.list[i].kind == REF_LOCAL_BRANCH &&
        !strcmp(ref_list.list[i].name, head)) {
            c = '*';

Make it almost inconceivable that a remote branch is being starred, or that a local branch is making it into the "-r" output.

Alan: could you show a tree of your .git/refs/heads and your .git/refs/remotes 
for the repository that is displaying this error?

Andy

On Friday 22 December 2006 08:39, Andy Parkins wrote:

It wasn't my repository I was responding to - it was Nicolas Pitre's post that listed both remote and local branches - and I then looked at the man page to see what -r did and saw that it said "only" remote branches.

On Thu, 21 Dec 2006, Junio C Hamano wrote:

Please do.  I'm sure Linus can find a better way now.

Sure.  But why doesn't pull accept "origin/next"?

But wouldn't it be much less confusing if it used the local name for that remote branch instead? After all it is what should be used with git-merge if performed manually, it is what diff, log, and al must use as well. Why would this need a remote name for something that is a local operation after all? I think "refs/heads/master" is really ambigous since you might be confused between the local and remote meaning of it, whereas "origin/master" carries no confusion at all.

Nicolas

<opublikowany i wysłany>

Nicolas Pitre wrote:

Perhaps less confusing, but also less powerfull. Current notation allows for pulling _without need for tracking branches_.

Although I wonder if it is possible to have multiple branch.<name>.remote, and branch.<name>.merge always refering to latest remote (octopus if there are more than one branch.<name>.merge for remote)...

Could you at least keep me in CC when replying to me please?

On Fri, 22 Dec 2006, Jakub Narebski wrote:

?

Is this really a killer feature worth the confusion?

If you put the repo to pull from on the command line then sure you might not want a tracking branch, but if you go to the trouble of adding a branch.blah.merge config entry then you certainly don't mind having a tracking branch?

Nicolas

Nicolas Pitre wrote:

I have Cc-ed you and Junio, but somehow message I send to mailing list loses the Cc:. Perhaps it is time to change news client (KMail), or upgrade it...

Sorry, it is added (in my locale) when both sending reply via mail, and to newsgroup (and to git mailing list via GMane NNTP news2mail interface).

I'm not sure. On one hand you have this feature, pulling without tracking branch (which is nice workflow for one-branch repos at least), on the other hand the tracking branch tells us the remote, and we can check if they match.

On another hand, you can have two remotes which are the same repository (mirrors for example)... although that would be better solved by allowing multiple url...

Nicolas Pitre <nico@cam.org> writes:

Well, "request" was very inprecise word -- I should have said "suggestion". But I think I agree.

Seconds?  Thirds?

-- >8 -- [PATCH] Do not support "partial URL shorthand" anymore.

We used to support specifying the top part of remote URL in remotes and use that as a short-hand for the URL.

	$ cat .git/remotes/jgarzik
	URL: git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/
	$ git pull jgarzik/misc-2.6

This is confusing when somebody attempts to do this:

	$ git pull origin/foo

which is not syntactically correct (unless you have origin/foo.git repository) and should fail, but it resulted in a mysterious access to the 'foo' subdirectory of the origin repository.

Which was what it was designed to do, but because this is an oddball "feature" I suspect nobody uses, let's remove it.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 git-parse-remote.sh |   34 +++++++---------------------------
 1 files changed, 7 insertions(+), 27 deletions(-)

On Fri, Dec 22, 2006 at 03:39:33PM -0800, Junio C Hamano wrote:

Except with the forthcoming submodule support, this feature might become more useful.

  Tom

On Fri, 22 Dec 2006, Junio C Hamano wrote:

Well since I suggested it I seconds this of course.

If it ever becomes useful for, say, submodules as someone pointed out, then this can be restored at that point and done properly for the task.

Nicolas

On Thu, Dec 21, 2006 at 03:01:21PM -0800, Junio C Hamano wrote:

BTW, is there some explanation why branch.*.merge specifies a _remote_ head? The following would make much more sense to me:

[branch "master"] remote = origin merge = refs/remotes/origin/master

Because I don't _care_ that the other guy calls it refs/heads/master. I care that I'm pulling from refs/remotes/origin/master on my end (and however I get stuff into that branch is defined by the remote).

It also means that even without a remote, the merge option makes sense (e.g., if I do repeated merges from one local branch to another). And it means that it's _always_ correct for "checkout -b <new> <track>" to set branch.<new>.merge to <track>, without having to worry about finding an appropriate remote.

-Peff

On Sat, 23 Dec 2006, Jeff King wrote:

Exactly the point I'm trying to make !

I'm glad I'm not alone to come to this conclusion.

Nicolas

Jeff King <peff@peff.net> writes:

Only *if* you store it in that tracking branch. The name the other party gives _do_ matter to you anyway, because you have to _know_ it to fetch. What it does NOT matter is if you use a tracking branch, or if you do, which local tracking branch you use to track it.

Junio C Hamano <junkio@cox.net> wrote:

My $0.02 USD (worth almost nothing these days!):

I agree with Junio.  branch.<n>.merge makes sense as the remote name.

On Fri, Dec 22, 2006 at 10:15:15PM -0800, Junio C Hamano wrote:

No, their names _don't_ matter to most users. With the new remote layout and wildcards, I'll never even see 'refs/heads/next' when I clone git.git; I'll only talk about 'origin/next'. The local tracking branch matters much more to me, because it's the thing I'll use to interact with git. I don't say 'git-checkout -b topic origin refs/heads/master'; I say 'git-checkout -b topic origin/next'.

Yes, my proposed syntax means you have to have a tracking branch. But does it really make sense for people to put entries in their config file, but not have a tracking branch? What do people use non-tracking branch pulls for, anyway? I would assume for one-off pulls of infrequently used repositories, in which case they're always saying "git-pull git://path/to/repo foo:bar". My point being that if we can improve the usefulness of the config file, it's probably not worth worrying about people combining branch.*.merge config entries with non-tracking-branch pulls, since they're extremely unlikely to be used together.

Does anyone out there use non-tracking-branch pulls? If so, can you describe your use case?

-Peff

Jeff King <peff@peff.net> writes:

Not at all. I pull from gitk repository and I do not have tracking branch, but I still have a remote defined for it.

On Fri, Dec 22, 2006 at 11:11:18PM -0800, Junio C Hamano wrote:

Do you also define branch.*.merge to use with this? Is there a reason you don't want a tracking branch?

-Peff

Junio C Hamano <junkio@cox.net> writes:

Having said that, I think we _could_ do this.

If you (or other people) use branch.*.merge, with its value set to remote name _and_ local name, and actually verify that either form works without confusion, please report back and I'll apply.

My scar is still fresh from the "not having branch.*.merge is an error" mistake, where the thing stayed on 'next' for the better part of last week without anybody complaining, and immediately broken peoples' workflows when it was pushed out to 'master'.

I really do not want to repeat that.

-- >8 --

Junio C Hamano wrote:

Hmmm... that DWIM is even better than proposed some time ago localmerge (or mergelocal, I don't remember) config variable.

Hi,

On Sat, 23 Dec 2006, Junio C Hamano wrote:

I do not claim to understand your patch (I have no idea if || or && is stronger in shell), but here is another proposition: if the config variablÃe starts with "refsremotes/", assume it is local.

Ciao, Dscho

Johannes Schindelin wrote:

Why? You can track another repository tracking branches, using it as a kind of proxy repository, even if it is not bare...

On Sat, Dec 23, 2006 at 01:51:03AM -0800, Junio C Hamano wrote:

I am happy to try this out and report back. However, I'm out of town for the holidays, so I won't have anything useful to say until next week.

-Peff

On Sat, 23 Dec 2006, Junio C Hamano wrote:

This is nice, thanks.

What would be nice as well is to be able to provide only the _name_ of the tracking branch without the refs/remotes/$origin/ prefix. Since there is already a 'branch."blah".remote = $origin' entry, then having 'branch."blah".merge = $foo' could mean "refs/remotes/$origin/$foo" when $foo contains no slash.

Nicolas

On Sun, Dec 24, 2006 at 03:49:50PM -0500, Nicolas Pitre wrote:

NAK. That makes branch names like "jc/foo" second-class citizens. You would do better to say "entries without refs/ are implicitly local refs in refs/remotes/".

-Peff

On Sat, Dec 23, 2006 at 01:51:03AM -0800, Junio C Hamano wrote:

This [using tracking branches in branch.*.merge] seems to be working for me, but it is possible to get some confusing results with it. Try this config:

[remote "origin"]
  url = /my/other/git/repo
  fetch = refs/heads/master:refs/heads/origin
  fetch = refs/heads/origin:refs/heads/junio
[branch "master"]
  remote = origin
  merge = refs/heads/origin

That is, we have a local tracking branch 'X' which has the same name as a remote branch 'X'. When we fetch, both will be marked for merge in FETCH_HEAD, and git-pull will attempt to do an octopus.

Is this too convoluted a config to worry about (no, I don't actually do this in my repository -- I just constructed the most plausible reason I could think of for having conflicting names). I actually think having a branch.*.mergelocal would make just as much sense and would be more robust (plus, it should be safe and sensible for "git-checkout -b foo bar" to point branch.foo.mergelocal to refs/heads/bar).

-Peff

Jeff King <peff@peff.net> writes:

If we are to worry about, and I think we might have to, I think not worrying about mergelocal and not accepting the name of local tracking branch is the only sensible thing to do.

Is there a problem if we did that?  I do not think of any.

On Tue, Jan 02, 2007 at 09:32:30AM -0800, Junio C Hamano wrote:

Sorry, I don't see the problem with mergelocal. Can you elaborate?

-Peff

Jeff King <peff@peff.net> writes:

I might have misread what you meant by mergeLocal, and you might be trying to introduce a default for "git merge" so that without anything on the command line "git merge" would merge something locally available depending on which branch you are on.

But I did not think of that, and thought you were saying "look at branch.*.mergelocal (if exists) in the same place we look at branch.*.merge in the current code, and just like the latter is used to match up with the remote refname we just fetched, use the former to match the local tracking branches, to decide what to merge". And if that is what you meant by mergelocal, I do not see much advantage in that approach -- that is what I meant in the response. The remote name is available whether you use tracking branches locally or not, so using that to specify the merge operation that happens after a 'pull' is more consistent, less confusing, and matches the long-hand "git pull $URL remote-branch" a lot better than having another configuration that can be used only half the time.

Some people repeatedly argued that remote branch names do not matter. I think they are wrong and are missing the point of distributedness of git. You are fetching from there, so you need to know the name the other end gives them in the first place. But much more importantly, the fact you are fetching from there means some other people could also be fetching from the same place. Now how would you discuss what that common repository recently placed on that branch? You would not use the local tracking branch name which _is_ meaningless to the other person. You use the remote name.

For example, I have a separate repository (that happens to be checked out in Meta/ subdirectory of my main working area, so its control files are in Meta/.git repository) to keep things that I push to my 'todo' branch. After I push the updates to 'todo' out to kernel.org from that repository, I usually fetch from kernel.org into that repository, so that I can later see up to which one I have already pushed out. I am old fashioned and still use remotes and non 'separate-remote' layout for this:

	URL: kernel.org:/pub/scm/git/git.git
        Push: refs/heads/master:refs/heads/todo
        Pull: refs/heads/todo:refs/heads/ko

As you can see from the above, my 'ko' is the local tracking branch, and 'master' in that repository is what is known as 'todo' to the public. But when I talk about what I have in that branch, I would never say 'master' nor 'ko' -- people would not care how I call that branch locally in my private repository. What's private is private and does not matter to others. Instead I would say something like "my 'todo' branch has drafts for v1.5.0 release notes these days".

What does this all mean? It means that remote branch names matter more when you are talking about external communication. And "git pull" (more so for "git fetch") is all about external communication.

Obviously, the local names should matter more when you are doing local operations. So if you are using mergeLocal to give a shorthand to "git merge" that does not explicitly say what to merge, the above discussion does not apply. But if that is the case, mergeLocal should also not affect the selection of branches to be merged when "git pull" happens from a remote either.

Junio C Hamano wrote:

You can always use remote = ".", and then remote and local branches are the same...

On 1/2/07, Jakub Narebski <jnareb@gmail.com> wrote:

Currently it does not work.

Santi

Santi Béjar wrote:

Fact.

I remember that there was proposal of having branch.<name>.remote=. and branch.<name>.merge=<ref> to make "git pull" on branch <name> do "git pull . <ref>". There was some discussion about this; perhaps it was not accepted (or forgotten to be accepted after resolving discussion).

[sorry this is old, but hopefully you remember what we were talking about. :)]

On Tue, Jan 02, 2007 at 12:04:33PM -0800, Junio C Hamano wrote:

No, I think you read me right: I wanted a way of saying "this is the local branch from which merges should happen if no other branch is specified".

Let me say right now that I'm not _that_ interested in this concept, so I'm going to stop pushing for it. However, I do want to respond to a few points in this mail; feel free to ignore. :)

There are two advantages I see to putting local branches in branch.*.merge:

  1. there seems to be some newbie confusion over using the remote name.
    Pull is conceptually (to me anyway), two steps:
      1. Fetch from a remote into my local tracking branches
      2. Merge from some tracking branch into my current branch.
    whereas I have seen you explain pull as:
      1. Fetch into FETCH_HEAD, selecting some branches for merge
      2. Merge any branches marked for merge
    I know that your model is more flexible, since it supports skipping
    the tracking branches. But for newbies looking at the config, I
    think the first makes much more sense.
      1. Newbies always have tracking branches, since that's now the
         default layout.
      2. Newbies don't know about FETCH_HEAD, since we don't talk about
         it in tutorials (and really, with tracking branches, what's the
         point?).
      3. Out of the two steps (fetching and merging), I would expect the
         .merge config option to be dealth with in the latter. But
         actually, it is an intimate part of fetching. This doesn't
         matter if you're pulling, but my workflow (and many others, it
         seems, especially those who rebase regularly) is:
           git fetch
           gitk master...origin
           git rebase ;# or git-pull

  2. There has been a requested feature (which I think makes sense) to
     create an automatic "upstream" for local branches. I.e.,
       git checkout -b new old
       hack hack hack
       git pull ;# should pull from 'old'
     This should be trivial to implement as
       git-repo-config branch.$new.mergeLocal $old
     but instead is requiring some magic to treat '.' as a noop remote.

[This ends the productive portion of this mail, but read on for more philosophical wanderings.]

I think the opposite. :)

To me, the distributed part of git (and one of its strengths over other systems) is that we are all working on a giant digraph of the history, and git is very efficient at adding to, examining, and communicating about parts of that graph.

Refs are just pointers into the graph, and so the names we give them are mostly just local matters (unless we're publishing those names). For example, before I started using separate remotes, I had what by many would be considered a funny setup. I was used to working with master and origin, but I wanted to start tracking next instead. So I made my origin track your next, and I called my master what you call next (plus local commits). As a result, I called your master 'stable' so I could still access it. So the history was distributed, but the names were completely local.

Another oft-mentioned example from the big bzr debate is a fork: what if I stop pulling from you, and start pulling from somebody else? The pointers have changed, but the underlying history is inherently the same. There's no penalty for me to switch names.

That isn't to say the names of the pointers are without value. Talking about 'master' and 'next' is very useful for humans. But what we _really_ mean is "Junio's master" and "Junio's next", because you are publishing those pointers. I don't know (or care) what's on Linus' master, so he can call it whatever he wants. Or if I do care, I don't necessarily care how it relates to your master. So to me, getting hung up on remote names (that is, treating them as anything besides publishing points) misses the point of git's distributedness.

Which isn't to say branch.*.merge looking at remote refs is _wrong_, but that using local names is at least as right (conceptually). :)

Sure, you would. Because you're talking about that other repo. But my mental model is that all git operations are local operations, except for fetching and pushing. I really think of pull as a shorthand "git-fetch; git-merge". So to me, git-merge is a local operation that should deal with local names.

Exactly. Only published names matter to other people. However, I contend that published names stop mattering once you have a mapping to local names.

I think this is where we really disagree. As I said, git-pull is really just "fetch+merge" to me. And merge isn't about external communication.

What I'm suggesting is that it can be used for either (local merges or pulls, since both are git-merge.

I think I am fundamentally denying the way "for-merge" branch selection works in git-pull. That is, it isn't the way I think of it conceptually, perhaps because I don't actually 'pull' very often. I _always_ fetch first.

-Peff

On Tue, Jan 09, 2007 at 10:05:24AM -0500, Jeff King wrote:

Let me add a third:

There are some operations which care about who our upstream is, but didn't necessarily just do a fetch (so FETCH_HEAD is not an option). For example, I have a short porcelain-ish script that formats all of my changes as patches and shows them as a mutt mailbox. If you don't specify an upstream, it uses 'origin'. However, this isn't right if I'm on 'next'. What I _really_ want is to say "a sensible upstream branch for the branch I'm currently on" which is basically what "mergeLocal" would be.

Come to think of it, mergeLocal is a terrible name, since it should really would be for merging, rebasing, and anything else which wanted to say "where did I probably come from?" So perhaps "upstream" would make more sense?

-Peff

Jeff King wrote:

Without remote (or rather with remote ".") remote branch names are the same as tracking branch names :-)

On Thursday 2006 December 21 22:17, Nicolas Pitre wrote:

Sorry Alan; I thought it was your bug - it wasn't...

I'm trying to track down why "master" is being shown in this case"; would it be possible to show me the output of

$ tree .git/refs/heads .git/refs/remotes

As I am having trouble reproducing this error.

Andy

On 12/22/06, Andy Parkins <andyparkins@gmail.com> wrote:

This looks very much like "git branch -a".

I've just tried this:

$ git clone git://git2.kernel.org/pub/scm/git/git.git
Initialized empty Git repository in /home/larsh/src/tmp/git/.git/
remote: Generating pack...
remote: Done counting 34527 objects.
remote: Deltifying 34527 objects.
remote:  100% (34527/34527) done
Indexing 34527 objects.
remote: Total 34527, written 34527 (delta 23920), reused 34111 (delta 23623)
 100% (34527/34527) done
Resolving 23920 deltas.
 100% (23920/23920) done
Checking files out...
 100% (748/748) done
$ cd git
$ git branch -r
  origin/HEAD
  origin/html
  origin/maint
  origin/man
  origin/master
  origin/next
  origin/pu
  origin/todo
$ git branch -a
* master
  origin/HEAD
  origin/html
  origin/maint
  origin/man
  origin/master
  origin/next
  origin/pu
  origin/todo
$ cp .git/refs/heads/master .git/refs/remotes/master
$ git branch -r
  master
  origin/HEAD
  origin/html
  origin/maint
  origin/man
  origin/master
  origin/next
  origin/pu
  origin/todo
$ git symbolic-ref HEAD refs/remotes/master
$ git branch -r
fatal: HEAD not found below refs/heads!
$ git --version
git version 1.4.4.2.gee60

On Fri, 22 Dec 2006, Lars Hjemli wrote:

Yes it was.  I just pasted the wrong line in my example.  Sorry.

Nicolas