confusion over the new branch and merge config

confusion over the new branch and merge config

[Nicolas Pitre]

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

Re: confusion over the new branch and merge config

[Junio C Hamano]

Nicolas Pitre <nico@cam.org> writes:

> [ 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. ]

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

> $ 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". ]

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

> $ git checkout -b local_next origin/next

"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.

> 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?

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

> $ 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... ]

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.

> $ 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.

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

> $ 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?  

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.

Re: confusion over the new branch and merge config

[Sean]

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

> 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.

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

Re: confusion over the new branch and merge config

[Junio C Hamano]

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

> This seems inconsistent and confusing.

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

Re: confusion over the new branch and merge config

[Junio C Hamano]

Sean <seanlkml@sympatico.ca> writes:

> 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"?

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.

Re: confusion over the new branch and merge config

[Sean]

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

> 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.

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

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

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.
 
> 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.

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

Re: confusion over the new branch and merge config

[Alan Chandler]

On Thursday 21 December 2006 23:01, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
> > [ 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. ]

Added snipped content back in
>>
>> $ git branch -r
>> * master
>>   origin/HEAD
>>   origin/html
>>   origin/maint
>>   origin/man
>>   origin/master
>>   origin/next
>>   origin/pu
>>   origin/todo

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

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

>
> > $ 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

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.

> > to
> >
> > [ Hmmmmmmmm.... /me stares at the message wondering.
> >   I just want to _see_ and maybe _install_ the code from "next". ]
>
> Rewording to suggest "checkout -b newbranchname origin/next",
> perhaps?
>
> > $ git checkout -b local_next origin/next
>
> "git checkout -b next origin/next" should work just fine, I
> think.
>

-- 
Alan Chandler
http://www.chandlerfamily.org.uk

Re: confusion over the new branch and merge config

[Junio C Hamano]

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

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

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.

>> > $ 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
>
> 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.

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.

Re: confusion over the new branch and merge config

[Andy Parkins]

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

> 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.

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
-- 
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com

Re: confusion over the new branch and merge config

[Andy Parkins]

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

> 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 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
-- 
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com

Re: confusion over the new branch and merge config

[Andy Parkins]

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

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

> $ git branch -r
> * master
>   origin/HEAD
>   origin/html
>   origin/maint
>   origin/man
>   origin/master
>   origin/next
>   origin/pu
>   origin/todo

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

-- 
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com

Re: confusion over the new branch and merge config

[Lars Hjemli]

On 12/22/06, Andy Parkins <andyparkins@gmail.com> wrote:
> On Thursday 2006 December 21 22:17, Nicolas Pitre wrote:
> > $ git branch -r
> > * master
> >   origin/HEAD
> >   origin/html
> >   origin/maint
> >   origin/man
> >   origin/master
> >   origin/next
> >   origin/pu
> >   origin/todo
>
> I'm trying to track down why "master" is being shown in this case";

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


-- 
larsh

Re: confusion over the new branch and merge config

[Nicolas Pitre]

On Fri, 22 Dec 2006, Lars Hjemli wrote:

> On 12/22/06, Andy Parkins <andyparkins@gmail.com> wrote:
> > On Thursday 2006 December 21 22:17, Nicolas Pitre wrote:
> > > $ git branch -r
> > > * master
> > >   origin/HEAD
> > >   origin/html
> > >   origin/maint
> > >   origin/man
> > >   origin/master
> > >   origin/next
> > >   origin/pu
> > >   origin/todo
> >
> > I'm trying to track down why "master" is being shown in this case";
> 
> This looks very much like "git branch -a".

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


Nicolas

Re: confusion over the new branch and merge config

[Alan Chandler]

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

> 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?

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.

-- 
Alan Chandler
http://www.chandlerfamily.org.uk

Re: confusion over the new branch and merge config

[Nicolas Pitre]

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

> Nicolas Pitre <nico@cam.org> writes:
> 
> > $ 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... ]
> 
> 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.

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

> > $ 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.
> 
> Yes, that is one of the reasons that you would prefer 'merge'
> when you are working locally.

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

> > $ 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?  
> 
> 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.

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

Re: confusion over the new branch and merge config

[Jakub Narebski]

<opublikowany i wysłany>

Nicolas Pitre wrote:
> On Thu, 21 Dec 2006, Junio C Hamano wrote:

>> 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.
> 
> 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.

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)...
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: confusion over the new branch and merge config

[Nicolas Pitre]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1490 bytes --]


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

On Fri, 22 Dec 2006, Jakub Narebski wrote:

> <opublikowany i wysłany>

?

> Nicolas Pitre wrote:
> > On Thu, 21 Dec 2006, Junio C Hamano wrote:
> 
> >> 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.
> > 
> > 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.
> 
> Perhaps less confusing, but also less powerfull. Current notation
> allows for pulling _without need for tracking branches_.

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

Re: confusion over the new branch and merge config

[Jakub Narebski]

Nicolas Pitre wrote:
> 
> Could you at least keep me in CC when replying to me please?

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...

> On Fri, 22 Dec 2006, Jakub Narebski wrote:
> 
>> <opublikowany i wysłany>
> 
> ?

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).


>> Perhaps less confusing, but also less powerfull. Current notation
>> allows for pulling _without need for tracking branches_.
> 
> 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?

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...
-- 
Jakub Narebski
Poland

Re: confusion over the new branch and merge config

[Junio C Hamano]

Nicolas Pitre <nico@cam.org> writes:

> On Thu, 21 Dec 2006, Junio C Hamano wrote:
>
>> Nicolas Pitre <nico@cam.org> writes:
>> 
>> > $ 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... ]
>> 
>> 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.
>
> Please do.  I'm sure Linus can find a better way now.

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(-)

diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index b163d22..aaef861 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -7,18 +7,7 @@ GIT_DIR=$(git-rev-parse --git-dir 2>/dev/null) || :;
 get_data_source () {
 	case "$1" in
 	*/*)
-		# Not so fast.	This could be the partial URL shorthand...
-		token=$(expr "z$1" : 'z\([^/]*\)/')
-		remainder=$(expr "z$1" : 'z[^/]*/\(.*\)')
-		if test "$(git-repo-config --get "remote.$token.url")"
-		then
-			echo config-partial
-		elif test -f "$GIT_DIR/branches/$token"
-		then
-			echo branches-partial
-		else
-			echo ''
-		fi
+		echo ''
 		;;
 	*)
 		if test "$(git-repo-config --get "remote.$1.url")"
@@ -40,12 +29,7 @@ get_remote_url () {
 	data_source=$(get_data_source "$1")
 	case "$data_source" in
 	'')
-		echo "$1" ;;
-	config-partial)
-		token=$(expr "z$1" : 'z\([^/]*\)/')
-		remainder=$(expr "z$1" : 'z[^/]*/\(.*\)')
-		url=$(git-repo-config --get "remote.$token.url")
-		echo "$url/$remainder"
+		echo "$1"
 		;;
 	config)
 		git-repo-config --get "remote.$1.url"
@@ -54,14 +38,10 @@ get_remote_url () {
 		sed -ne '/^URL: */{
 			s///p
 			q
-		}' "$GIT_DIR/remotes/$1" ;;
+		}' "$GIT_DIR/remotes/$1"
+		;;
 	branches)
-		sed -e 's/#.*//' "$GIT_DIR/branches/$1" ;;
-	branches-partial)
-		token=$(expr "z$1" : 'z\([^/]*\)/')
-		remainder=$(expr "z$1" : 'z[^/]*/\(.*\)')
-		url=$(sed -e 's/#.*//' "$GIT_DIR/branches/$token")
-		echo "$url/$remainder"
+		sed -e 's/#.*//' "$GIT_DIR/branches/$1"
 		;;
 	*)
 		die "internal error: get-remote-url $1" ;;
@@ -77,7 +57,7 @@ get_default_remote () {
 get_remote_default_refs_for_push () {
 	data_source=$(get_data_source "$1")
 	case "$data_source" in
-	'' | config-partial | branches | branches-partial)
+	'' | branches)
 		;; # no default push mapping, just send matching refs.
 	config)
 		git-repo-config --get-all "remote.$1.push" ;;
@@ -196,7 +176,7 @@ canon_refs_list_for_fetch () {
 get_remote_default_refs_for_fetch () {
 	data_source=$(get_data_source "$1")
 	case "$data_source" in
-	'' | config-partial | branches-partial)
+	'')
 		echo "HEAD:" ;;
 	config)
 		canon_refs_list_for_fetch -d "$1" \
-- 
1.4.4.3.ge228b

Re: confusion over the new branch and merge config

[Tom Prince]

On Fri, Dec 22, 2006 at 03:39:33PM -0800, Junio C Hamano wrote:
> [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.

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

  Tom

Re: confusion over the new branch and merge config

[Nicolas Pitre]

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

> 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>

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

Re: confusion over the new branch and merge config

[Jeff King]

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

> > $ git checkout -b local_next origin/next
> 
> "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.

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

Re: confusion over the new branch and merge config

[Nicolas Pitre]

On Sat, 23 Dec 2006, Jeff King 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).

Exactly the point I'm trying to make !

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


Nicolas

Re: confusion over the new branch and merge config

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> 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

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.

Re: confusion over the new branch and merge config

[Shawn Pearce]

Junio C Hamano <junkio@cox.net> wrote:
> Jeff King <peff@peff.net> writes:
> 
> > 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
> 
> 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.

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

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

-- 
Shawn.

Re: confusion over the new branch and merge config

[Jeff King]

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

> 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.

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

Re: confusion over the new branch and merge config

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> 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".

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

Re: confusion over the new branch and merge config

[Jeff King]

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

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

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

-Peff

Re: confusion over the new branch and merge config

[Jakub Narebski]

Jeff King wrote:

> 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.

Without remote (or rather with remote ".") remote branch names are the same
as tracking branch names :-)
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: confusion over the new branch and merge config

[Junio C Hamano]

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

> Jeff King <peff@peff.net> writes:
>
>> 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
>
> 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.

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 --

diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index aaef861..b45af5c 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -146,8 +146,13 @@ canon_refs_list_for_fetch () {
 		else
 			for merge_branch in $merge_branches
 			do
-			    [ "$remote" = "$merge_branch" ] &&
-			    dot_prefix= && break
+			    if	test "$remote" = "$merge_branch" ||
+				test "z$local" != z &&
+			    	test "$local" = "$merge_branch"
+			    then
+				    dot_prefix=
+				    break
+			    fi
 			done
 		fi
 		case "$remote" in

Re: confusion over the new branch and merge config

[Jakub Narebski]

Junio C Hamano wrote:

>> 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.
> 
> 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.

Hmmm... that DWIM is even better than proposed some time ago localmerge
(or mergelocal, I don't remember) config variable.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: confusion over the new branch and merge config

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1118 bytes --]

Hi,

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

> Junio C Hamano <junkio@cox.net> writes:
> 
> > Jeff King <peff@peff.net> writes:
> >
> >> 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
> >
> > 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.
> 
> 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.

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

Re: confusion over the new branch and merge config

[Jakub Narebski]

Johannes Schindelin wrote:

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

>> 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.
> 
> 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 
> variable starts with "refs/remotes/", assume it is local.

Why? You can track another repository tracking branches, using it as a kind
of proxy repository, even if it is not bare...
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: confusion over the new branch and merge config

[Jeff King]

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

> 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.

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

Re: confusion over the new branch and merge config

[Nicolas Pitre]

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

> 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.

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

Re: confusion over the new branch and merge config

[Jeff King]

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

> 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.

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

Re: confusion over the new branch and merge config

[Jeff King]

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

> 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.

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

Re: confusion over the new branch and merge config

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Sat, Dec 23, 2006 at 01:51:03AM -0800, Junio C Hamano wrote:
>
>> 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.
>
> 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).

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.

Re: confusion over the new branch and merge config

[Jeff King]

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

> 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.

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

-Peff

Re: confusion over the new branch and merge config

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Tue, Jan 02, 2007 at 09:32:30AM -0800, Junio C Hamano wrote:
>
>> 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.
>
> Sorry, I don't see the problem with mergelocal. Can you elaborate?

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.

Re: confusion over the new branch and merge config

[Jakub Narebski]

Junio C Hamano wrote:

> 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.

You can always use remote = ".", and then remote and local branches
are the same...
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: confusion over the new branch and merge config

[Santi Béjar]

On 1/2/07, Jakub Narebski <jnareb@gmail.com> wrote:
> Junio C Hamano wrote:
>
> > 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.
>
> You can always use remote = ".", and then remote and local branches
> are the same...

Currently it does not work.

Santi

Re: confusion over the new branch and merge config

[Jakub Narebski]

Santi Béjar wrote:
> On 1/2/07, Jakub Narebski <jnareb@gmail.com> wrote:
>> Junio C Hamano wrote:
>>
>>> 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.
>>
>> You can always use remote = ".", and then remote and local branches
>> are the same...
> 
> Currently it does not work.

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).

-- 
Jakub Narebski
Poland

Re: confusion over the new branch and merge config

[Jeff King]

[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:

> 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.

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".

> 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.

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.]

> 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

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). :)

> 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.

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.

> 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".

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

> 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.

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.

> 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

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

> case, mergeLocal should also not affect the selection of
> branches to be merged when "git pull" happens from a remote
> either.

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

Re: confusion over the new branch and merge config

[Jeff King]

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

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

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