Unhelpful "branch.master.remote = <nickname>" advice?

Unhelpful "branch.master.remote = <nickname>" advice?

[Jan Nieuwenhuizen]

[-- Attachment #1: Type: text/plain, Size: 998 bytes --]

Hi,

git pull -r*) URL says:

    If you often merge with the same branch, you may want to
    configure the following variables in your configuration
    file:

        branch.master.remote = <nickname>
        branch.master.merge = <remote-ref>
        remote.<nickname>.url = <url>
        remote.<nickname>.fetch = <refspec>

and after cut-and-pasting that into .git/config, replacing
<foo> with values, I get

    $ git pull -r http://github.com/../../master
    fatal: bad config file line 17 in .git/config

where line 17 is [without any indentation]

    branch.master.remote = eddy

This is with git version version 1.6.3.3

Greetings,
Jan.  -- who just finds out the uninstall target is missing?!?
	 See attached.

*) I've been wondering why GIT lacks a "update", ie
   pull-without-merge command.  You almost never want
   to git pull /without/ -r?

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl    | http://lilypond.org

[-- Attachment #2: 0001-Makefile-add-uninstall-target.-Fixes-elementary-good.patch --]
[-- Type: text/x-patch, Size: 3234 bytes --]

>From 5b5107e2887b11cab3a391bd550d30c7df68242f Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen <janneke@gnu.org>
Date: Wed, 11 Nov 2009 14:19:00 +0100
Subject: [PATCH] Makefile: add uninstall target.  Fixes elementary good cleaning manners.

   * Modified     Makefile
   * Modified     gitk-git/Makefile
   * Modified     perl/Makefile
   * Modified     templates/Makefile
---
 Makefile           |   18 +++++++++++++++++-
 gitk-git/Makefile  |    2 ++
 perl/Makefile      |    2 +-
 templates/Makefile |    5 +++++
 4 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 5d5976f..135c3ac 100644
--- a/Makefile
+++ b/Makefile
@@ -1781,7 +1781,23 @@ quick-install-man:
 quick-install-html:
 	$(MAKE) -C Documentation quick-install-html
 
+bindir_PROGRAMS = git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X git-shell$X git-cvsserver
 
+uninstall:
+ifndef NO_TCLTK
+	$(MAKE) -C gitk-git uninstall
+	$(MAKE) -C git-gui gitexecdir='$(gitexec_instdir_SQ)' uninstall
+endif
+ifndef NO_PERL
+	$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' uninstall
+endif
+	$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' uninstall
+	$(RM) $(ALL_PROGRAMS:%='$(DESTDIR_SQ)$(gitexec_instdir_SQ)'/%)
+	$(RM) $(BUILT_INS:%='$(DESTDIR_SQ)$(gitexec_instdir_SQ)'/%)
+	$(RM) $(OTHER_PROGRAMS:%='$(DESTDIR_SQ)$(gitexec_instdir_SQ)'/%)
+	-rmdir -p '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
+	$(RM) $(bindir_PROGRAMS:%='$(DESTDIR_SQ)$(bindir_SQ)'/%)
+	-rmdir -p '$(DESTDIR_SQ)$(bindir_SQ)'
 
 ### Maintainer's dist rules
 
@@ -1857,7 +1873,7 @@ ifndef NO_TCLTK
 endif
 	$(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-GUI-VARS GIT-BUILD-OPTIONS
 
-.PHONY: all install clean strip
+.PHONY: all install uninstall clean strip
 .PHONY: shell_compatibility_test please_set_SHELL_PATH_to_a_more_modern_shell
 .PHONY: .FORCE-GIT-VERSION-FILE TAGS tags cscope .FORCE-GIT-CFLAGS
 .PHONY: .FORCE-GIT-BUILD-OPTIONS
diff --git a/gitk-git/Makefile b/gitk-git/Makefile
index e1b6045..d68f19a 100644
--- a/gitk-git/Makefile
+++ b/gitk-git/Makefile
@@ -47,6 +47,8 @@ install:: all
 uninstall::
 	$(foreach p,$(ALL_MSGFILES), $(RM) '$(DESTDIR_SQ)$(msgsdir_SQ)'/$(notdir $p) &&) true
 	$(RM) '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
+	-rmdir -p '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
+	-rmdir -p '$(DESTDIR_SQ)$(msgsdir_SQ)'
 
 clean::
 	$(RM) gitk-wish po/*.msg
diff --git a/perl/Makefile b/perl/Makefile
index 4ab21d6..25fc304 100644
--- a/perl/Makefile
+++ b/perl/Makefile
@@ -10,7 +10,7 @@ ifndef V
 	QUIET = @
 endif
 
-all install instlibdir: $(makfile)
+all install instlibdir uninstall: $(makfile)
 	$(QUIET)$(MAKE) -f $(makfile) $@
 
 clean:
diff --git a/templates/Makefile b/templates/Makefile
index 408f013..f4048d9 100644
--- a/templates/Makefile
+++ b/templates/Makefile
@@ -51,3 +51,8 @@ install: all
 	$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(template_instdir_SQ)'
 	(cd blt && $(TAR) cf - .) | \
 	(cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) xof -)
+
+uninstall:
+	-(cd blt && find . -type f) | (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && xargs $(RM))
+	-(cd blt && find . -mindepth 1 -type d) | (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && xargs rmdir)
+	-rmdir -p '$(DESTDIR_SQ)$(template_instdir_SQ)'
-- 
1.6.3.3

Re: Unhelpful "branch.master.remote = <nickname>" advice?

[Tomas Carnecky]

On Nov 11, 2009, at 2:22 PM, Jan Nieuwenhuizen wrote:

> Hi,
>
> git pull -r*) URL says:
>
>    If you often merge with the same branch, you may want to
>    configure the following variables in your configuration
>    file:
>
>        branch.master.remote = <nickname>
>        branch.master.merge = <remote-ref>
>        remote.<nickname>.url = <url>
>        remote.<nickname>.fetch = <refspec>

These are meant to be used with git-config(1):
git config branch.master.remote <nickname>

Or if you want to manually edit the config file, add this:

[branch "master"]
     remote = <nickname>

etc.

>
> and after cut-and-pasting that into .git/config, replacing
> <foo> with values, I get
>
>    $ git pull -r http://github.com/../../master
>    fatal: bad config file line 17 in .git/config
>
> where line 17 is [without any indentation]
>
>    branch.master.remote = eddy
>
> This is with git version version 1.6.3.3
>
> Greetings,
> Jan.  -- who just finds out the uninstall target is missing?!?
> 	 See attached.

Next time please send patches inline, it's easier to review them that  
way.

>
> *) I've been wondering why GIT lacks a "update", ie
>   pull-without-merge command.  You almost never want
>   to git pull /without/ -r?

As 'pull == fetch + merge' (pull -r == fetch + rebase), pull without  
merge would be fetch.

tom

Re: Unhelpful "branch.master.remote = <nickname>" advice?

[Tomas Carnecky]

On Nov 11, 2009, at 7:56 PM, Jan Nieuwenhuizen wrote:

>> These are meant to be used with git-config(1):
>> git config branch.master.remote <nickname>
>
> Okay...that's the other thing I tried.  Look
>
>   $ cp .git/config .git/config.orig
>   19:32:05 janneke@peder:~/vc/gub
>   $ git config branch.master.remote = eddy
>   19:32:08 janneke@peder:~/vc/gub
>   $ diff -u .git/config.orig .git/config
>   --- .git/config.orig	2009-11-11 19:32:05.724046086 +0100
>   +++ .git/config	2009-11-11 19:32:08.304045852 +0100
>   @@ -6,6 +6,7 @@
>    [branch "master"]
> 	    remote = origin
> 	    merge = refs/heads/master
>   +	remote = =
>    [remote "origin"]
> 	    url = git@github.com:janneke/gub.git
> 	    fetch = +refs/heads/*:refs/remotes/origin/*
>   [1]19:32:10 janneke@peder:~/vc/gub

You used this:
$ git config branch.master.remote = <something>
Do you see the difference between that and what I posted?

> Also, if this is meant to be used with git config, then
> /why/ does the text say "in your configuration file"?
>
> I think it might be more helpful if this text said
> configuration file and gave a usable configuration file
> snippet, or alternatively said git config, and gave usable
> git config commands.

Feel free to send a patch ;)

>
>> Or if you want to manually edit the config file, add this:
>>
>> [branch "master"]
>>    remote = <nickname>
>>
>> etc.
>
> Thanks!  Tried this.  However, there already was a
>
>  [branch "master"]
>       remote = origin
>
> which is my default branch that I publish to and pull
> from.  After adding a nickname for this new branch that
> I'll probably be pulling from a lot, my config file reads
>
>   [branch "master"]
> 	    remote = origin
> 	    merge = refs/heads/master
>   [remote "origin"]
> 	    url = git@github.com:janneke/gub.git
> 	    fetch = +refs/heads/*:refs/remotes/origin/*
>   # advise from git pull, using <nickname> = eddy
>   #        branch.master.remote = <nickname>
>   #        branch.master.merge = <remote-ref>
>   #        remote.<nickname>.url = <url>
>   #        remote.<nickname>.fetch = <refspec>
>   [branch "master"]
> 	    remote = eddy
> 	    merge = refs/heads/master
>   [remote "eddy"]
> 	    url = http://github.com/epronk/gub.git
> 	    fetch = +refs/heads/*:refs/remotes/origin/*
>
> With this new "eddy" addition
>
> git pull -r eddy
>
> seems to work fine, but the good old default pull now says
>
>   $ git pull -r
>   error: More than one value for the key branch.master.remote: eddy
>   Current branch master is up to date.

branch.master.remote has two different values, git doesn't know which  
remote to use. Do you want to pull from origin or eddy? I would  
recommend only keeping one [branch "master"] section and edit it  
appropriately.

> and I'm not really sure where it pulls from?  Then I think,
> possibly now I need to specify the <nickname> for the default
> url too [never knew that was a nick], which has automagically
> be named "origin".  Yes, that makes sense.
>
> Well, /then/ I get thoroughly confused
>
>   $ git pull -r origin
>   You asked me to pull without telling me which branch you
>   want to merge with, and 'branch.master.merge' in
>   your configuration file does not tell me either.	Please
>   specify which branch you want to merge on the command line and
>   try again (e.g. 'git pull <repository> <refspec>').
>   See git-pull(1) for details.
>
>   If you often merge with the same branch, you may want to
>   configure the following variables in your configuration
>   file:
>
> 	branch.master.remote = <nickname>
> 	branch.master.merge = <remote-ref>
> 	remote.<nickname>.url = <url>
> 	remote.<nickname>.fetch = <refspec>
>
>   See git-config(1) for details.
>   [1]19:43:02 janneke@peder:~/vc/gub

Hm, I can't explain that one. I would use either the short form (git  
pull -r) or the long form (git pull -r origin master). Try removing  
the duplicate branch.master section and try again.

>
>> As 'pull == fetch + merge' (pull -r == fetch + rebase), pull without
>> merge would be fetch.
>
> Okay, that's fighting over naming conventions, let me retry this.
> I still wonder why does Git have a shorthand for fetch + merge [pull],
> which you almost never want, and no shorthand for fetch + rebase
> [known to most *CS/*SCM users as "update"]?

Is 'git pull -r' not short enough for you? If not, feel free to create  
a alias:
$ git config alias.up 'pull -r'

tom

Re: Unhelpful "branch.master.remote = <nickname>" advice?

[Jan Nieuwenhuizen]

Op woensdag 11-11-2009 om 20:10 uur [tijdzone +0100], schreef Tomas
Carnecky:
> On Nov 11, 2009, at 7:56 PM, Jan Nieuwenhuizen wrote:

Hi Tomas,

> You used this:
> $ git config branch.master.remote = <something>
> Do you see the difference between that and what I posted?

Sure, I now know what syntax you and the advise mean.  However,
I'm just pointing out that the git pull advise makes no sense,
however way you try to interpret it?

> > I think it might be more helpful if this text said
> > configuration file and gave a usable configuration file
> > snippet, or alternatively said git config, and gave usable
> > git config commands.
> 
> Feel free to send a patch ;)

[just maybe, if my uninstall patch goes in easily, but]

First I need to know what the new advise should be.  As you
can see below, I'm still confused.

I was hoping someone would say: Ah blast!  That was me,
stupid: Fixed in master :-)  And everything would make
sense and work.

> branch.master.remote has two different values, git doesn't know which  
> remote to use.

Well, it can see that there already is a value for branch.master.remote
defined, and it /still/ advises to add one.  It also uses <nickname>,
which suggests there could be multiple values?

For all I know, pull can only handle one nickname and it shouldn't
give this advise at all?

> Do you want to pull from origin or eddy?

I'm publishing on origin -- that's what the original clone was
from.  Also, I use it to update from most often, when I work
from different locations.  All fine.

Now this Eddy guy says: pull from here.  I try it and get
this advise.  So, I'd like to have

   git pull  # use origin by default
   git pull eddy # pull from eddy's url

> I would  
> recommend only keeping one [branch "master"] section and edit it  
> appropriately.

Yes, I tried that and came up with

    [branch "master"]
	    remote = origin
	    merge = refs/heads/master
    [remote "origin"]
	    url = git@github.com:janneke/gub.git
	    fetch = +refs/heads/*:refs/remotes/origin/*
    # advise from git pull, using <nickname> = eddy
    #        branch.master.remote = <nickname>
    #        branch.master.merge = <remote-ref>
    #        remote.<nickname>.url = <url>
    #        remote.<nickname>.fetch = <refspec>
    #[branch "master"]
    #	remote = eddy # ignore branch.master.remote advise
    #	merge = refs/heads/master
    [remote "eddy"]
	    url = http://github.com/epronk/gub.git
	    fetch = +refs/heads/*:refs/remotes/origin/*

This /seems/ to work.  However, I still get this

    $ git pull -r
    From git@github.com:janneke/gub
     + 7bb5905...8ff38da master     -> origin/master  (forced update)
    First, rewinding head to replay your work on top of it...
    Fast-forwarded master to 8ff38da0a7013a891de18a0b7bec12b9d1fa6637.
    20:25:55 janneke@peder:~/vc/gub

[looks okay]

    $ git pull -r eddy
    From http://github.com/epronk/gub
     + 8ff38da...7bb5905 master     -> origin/master  (forced update)
[looks fine too, but still continues with]
    You asked me to pull without telling me which branch you
    want to merge with, and 'branch.master.merge' in
    your configuration file does not tell me either.	Please
    specify which branch you want to merge on the command line and
    try again (e.g. 'git pull <repository> <refspec>').
    See git-pull(1) for details.

    If you often merge with the same branch, you may want to
    configure the following variables in your configuration
    file:

	branch.master.remote = <nickname>
	branch.master.merge = <remote-ref>
	remote.<nickname>.url = <url>
	remote.<nickname>.fetch = <refspec>

    See git-config(1) for details.
    [1]20:26:01 janneke@peder:~/vc/gub
    $ 

so I'm still missing something?

> Is 'git pull -r' not short enough for you?

It's more of a usability thing.  It annoys me that the most
used functionality needs a command line option.  Worse however,
is that people [myself included] tend to forget that "-r",
and our logs have lots of these ugly, unnecessary

    c377994 Merge branch 'master' of ssh+git://git.sv.gnu.org/srv/git/lilypond

Also, we need to explain this to all newcomers.

Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl    | http://lilypond.org

Re: Unhelpful "branch.master.remote = <nickname>" advice?

[Tomas Carnecky]

On Nov 11, 2009, at 8:34 PM, Jan Nieuwenhuizen wrote:

> Op woensdag 11-11-2009 om 20:10 uur [tijdzone +0100], schreef Tomas
> Carnecky:
>> On Nov 11, 2009, at 7:56 PM, Jan Nieuwenhuizen wrote:
>
> Hi Tomas,
>
>> You used this:
>> $ git config branch.master.remote = <something>
>> Do you see the difference between that and what I posted?
>
> Sure, I now know what syntax you and the advise mean.  However,
> I'm just pointing out that the git pull advise makes no sense,
> however way you try to interpret it?

It didn't tell you to copy'n'paste the whole lines to a git-config(1)  
commandline. But I do see that the output can be confusing for someone  
not familiar with the git configuration files/git-config.

>>> I think it might be more helpful if this text said
>>> configuration file and gave a usable configuration file
>>> snippet, or alternatively said git config, and gave usable
>>> git config commands.
>>
>> Feel free to send a patch ;)
>
> [just maybe, if my uninstall patch goes in easily, but]
>
> First I need to know what the new advise should be.  As you
> can see below, I'm still confused.
>
> I was hoping someone would say: Ah blast!  That was me,
> stupid: Fixed in master :-)  And everything would make
> sense and work.

You can use git-blame(1) to find out who wrote those lines ;)

>
>> branch.master.remote has two different values, git doesn't know which
>> remote to use.
>
> Well, it can see that there already is a value for  
> branch.master.remote
> defined, and it /still/ advises to add one.  It also uses <nickname>,
> which suggests there could be multiple values?
>
> For all I know, pull can only handle one nickname and it shouldn't
> give this advise at all?
>
>> Do you want to pull from origin or eddy?
>
> I'm publishing on origin -- that's what the original clone was
> from.  Also, I use it to update from most often, when I work
> from different locations.  All fine.
>
> Now this Eddy guy says: pull from here.  I try it and get
> this advise.  So, I'd like to have
>
>   git pull  # use origin by default
>   git pull eddy # pull from eddy's url

I don't know the relationship between you and eddy, but usually you  
shouldn't rebase (=rewrite) eddies commits. That also means you'd have  
to live with the merge commits.

>
>> I would
>> recommend only keeping one [branch "master"] section and edit it
>> appropriately.
>
> Yes, I tried that and came up with
>
>    [branch "master"]
> 	    remote = origin
> 	    merge = refs/heads/master
>    [remote "origin"]
> 	    url = git@github.com:janneke/gub.git
> 	    fetch = +refs/heads/*:refs/remotes/origin/*
>    # advise from git pull, using <nickname> = eddy
>    #        branch.master.remote = <nickname>
>    #        branch.master.merge = <remote-ref>
>    #        remote.<nickname>.url = <url>
>    #        remote.<nickname>.fetch = <refspec>
>    #[branch "master"]
>    #	remote = eddy # ignore branch.master.remote advise
>    #	merge = refs/heads/master
>    [remote "eddy"]
> 	    url = http://github.com/epronk/gub.git
> 	    fetch = +refs/heads/*:refs/remotes/origin/*

I see your mistake. Both the origin and eddy remote write to the same  
namespace (refs/remotes/origin/*), and that's also why you get (force  
update) below

. Change the fetch line of remote.eddy.fetch to +refs/heads/*:refs/ 
remotes/eddy/*. After that both command (pull -r / pull -r eddy)  
should work (I hope).

>
> This /seems/ to work.  However, I still get this
>
>    $ git pull -r
>    From git@github.com:janneke/gub
>     + 7bb5905...8ff38da master     -> origin/master  (forced update)
>    First, rewinding head to replay your work on top of it...
>    Fast-forwarded master to 8ff38da0a7013a891de18a0b7bec12b9d1fa6637.
>    20:25:55 janneke@peder:~/vc/gub
>
> [looks okay]
>
>    $ git pull -r eddy
>    From http://github.com/epronk/gub
>     + 8ff38da...7bb5905 master     -> origin/master  (forced update)
> [looks fine too, but still continues with]
>    You asked me to pull without telling me which branch you
>    want to merge with, and 'branch.master.merge' in
>    your configuration file does not tell me either.	Please
>    specify which branch you want to merge on the command line and
>    try again (e.g. 'git pull <repository> <refspec>').
>    See git-pull(1) for details.
>
>    If you often merge with the same branch, you may want to
>    configure the following variables in your configuration
>    file:
>
> 	branch.master.remote = <nickname>
> 	branch.master.merge = <remote-ref>
> 	remote.<nickname>.url = <url>
> 	remote.<nickname>.fetch = <refspec>
>
>    See git-config(1) for details.
>    [1]20:26:01 janneke@peder:~/vc/gub
>    $
>
> so I'm still missing something?
>
>> Is 'git pull -r' not short enough for you?
>
> It's more of a usability thing.  It annoys me that the most
> used functionality needs a command line option.  Worse however,
> is that people [myself included] tend to forget that "-r",
> and our logs have lots of these ugly, unnecessary
>
>    c377994 Merge branch 'master' of ssh+git://git.sv.gnu.org/srv/git/lilypond
>
> Also, we need to explain this to all newcomers.

I've found that all the available guides and books about git explain  
merging pretty well (it's a central part of git after all).

tom

Re: Unhelpful "branch.master.remote = <nickname>" advice?

[Jan Nieuwenhuizen]

Op woensdag 11-11-2009 om 21:32 uur [tijdzone +0100], schreef Tomas
Carnecky:

Hi Tomas,

> It didn't tell you to copy'n'paste the whole lines to a git-config(1)  
> commandline. But I do see that the output can be confusing for someone  
> not familiar with the git configuration files/git-config.

Once I get this to work, I'll send a patch for it.

> I don't know the relationship between you and eddy, but usually you  
> shouldn't rebase (=rewrite) eddies commits. That also means you'd have  
> to live with the merge commits.

Hmm, okay.

> I see your mistake. Both the origin and eddy remote write to the same  
> namespace (refs/remotes/origin/*), and that's also why you get (force  
> update) below

Ah, that makes sense.

> . Change the fetch line of remote.eddy.fetch to +refs/heads/*:refs/ 
> remotes/eddy/*. After that both command (pull -r / pull -r eddy)  
> should work (I hope).

Okay, so now I have

    [branch "master"]
	    remote = origin
	    merge = refs/heads/master
    [remote "origin"]
	    url = git@github.com:janneke/gub.git
	    fetch = +refs/heads/*:refs/remotes/origin/*
    # advise from git pull, using <nickname> = eddy
    #        branch.master.remote = <nickname>
    #        branch.master.merge = <remote-ref>
    #        remote.<nickname>.url = <url>
    #        remote.<nickname>.fetch = <refspec>
    #[branch "master"]
    #	remote = eddy
    #	merge = refs/heads/master
    [remote "eddy"]
	    url = http://github.com/epronk/gub.git
    #use remote.eddy.fetch to +refs/heads/*:refs/remotes/eddy/*.
	    fetch = +refs/heads/*:refs/remotes/eddy/*

It looked promising, but still get

    15:00:20 janneke@peder:~/vc/gub
    $ git pull -r --verbose
    From git@github.com:janneke/gub
     = [up to date]      lilypond-release-branch -> origin/lilypond-release-branch
     = [up to date]      master     -> origin/master
    Current branch master is up to date.
    15:00:26 janneke@peder:~/vc/gub
    $ git pull -r --verbose eddy
    From http://github.com/epronk/gub
     = [up to date]      lilypond-release-branch -> eddy/lilypond-release-branch
     = [up to date]      master     -> eddy/master
    You asked me to pull without telling me which branch you
    want to merge with, and 'branch.master.merge' in
    your configuration file does not tell me either.	Please
    specify which branch you want to merge on the command line and
    try again (e.g. 'git pull <repository> <refspec>').
    See git-pull(1) for details.

    If you often merge with the same branch, you may want to
    configure the following variables in your configuration
    file:

	branch.master.remote = <nickname>
	branch.master.merge = <remote-ref>
	remote.<nickname>.url = <url>
	remote.<nickname>.fetch = <refspec>

    See git-config(1) for details.
    [1]15:00:33 janneke@peder:~/vc/gub
    $ 

After this I started to re-read git-config's man page
again.  There is something strange that I do not understand

    branch.<name>.merge
        Defines, together with branch.<name>.remote, the upstream
        branch for the given branch.  It tells git-fetch/git-pull
        which branch to merge and can also affect git-push (see
        push.default).

this seems to imply that the merge variable here

   [branch "master"]
       remote = FOOBAR
       merge = refs/heads/master

is somehow tied to the remote nick FOOBAR.  That would
mean it is actually taken as

     branch.<name>.<nickname>.merge

and also that it's impossible to specify more than one
<nickname>.  That would be make nicknames unusable and
thus silly, so I cannot be right?

Thanks a lot for your continued support!

Greetings,
Jan.


-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl    | http://lilypond.org

[PATCH] git-pull.sh: overhaul error handling when no candidates are found

[Jan Krüger]

* The longish error message displayed when the user uses "git pull" but
  has no remote/merge/rebase lines configured for the current branch
  contains example configuration to remedy the situation... but the
  example uses a rather invalid syntax, using the dotted syntax "git
  config" accepts, but also "=" separators which are used in the config
  file format. It also implies that this syntax is valid in git config
  files. This changes the example to use valid config file syntax.

* When git pull --rebase is used, error_on_no_merge_candidates still
  thinks we're trying to merge, so the resulting message talks about
  merge all the time, and the function looks at the "branch.foo.merge"
  setting rather than the "branch.foo.rebase" setting, and so even tends
  to output the wrong message for the rebase case. This makes both the
  setting verification and the message depend on the mode of operation.

Signed-off-by: Jan Krüger <jk@jk.gs>
---
I tried to pick this apart into several patches but couldn't really
find any decent way of separating the changes. It should address all of
the confusion already identified plus some additional confusion, though.

I'll admit that the dynamification of the messages is a bit crude.

 git-pull.sh |   43 ++++++++++++++++++++++++++-----------------
 1 files changed, 26 insertions(+), 17 deletions(-)

diff --git a/git-pull.sh b/git-pull.sh
index 37f3d93..906c827 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -91,45 +91,54 @@ error_on_no_merge_candidates () {
 		esac
 	done
 
+	if [ true = "$rebase" ]; then
+		op_type=rebase
+		op_prep=against
+	else
+		op_type=merge
+		op_prep=with
+	fi
+
 	curr_branch=${curr_branch#refs/heads/}
-	upstream=$(git config "branch.$curr_branch.merge")
+	upstream=$(git config "branch.$curr_branch.$op_type")
 	remote=$(git config "branch.$curr_branch.remote")
 
 	if [ $# -gt 1 ]; then
-		echo "There are no candidates for merging in the refs that you just fetched."
+		echo "There are no candidates for using the refs that you just fetched."
 		echo "Generally this means that you provided a wildcard refspec which had no"
 		echo "matches on the remote end."
 	elif [ $# -gt 0 ] && [ "$1" != "$remote" ]; then
 		echo "You asked to pull from the remote '$1', but did not specify"
-		echo "a branch to merge. Because this is not the default configured remote"
+		echo "a branch to use. Because this is not the default configured remote"
 		echo "for your current branch, you must specify a branch on the command line."
 	elif [ -z "$curr_branch" ]; then
 		echo "You are not currently on a branch, so I cannot use any"
-		echo "'branch.<branchname>.merge' in your configuration file."
-		echo "Please specify which branch you want to merge on the command"
+		echo "'branch.<branchname>.$op_type' in your configuration file."
+		echo "Please specify which branch you want to use on the command"
 		echo "line and try again (e.g. 'git pull <repository> <refspec>')."
 		echo "See git-pull(1) for details."
 	elif [ -z "$upstream" ]; then
 		echo "You asked me to pull without telling me which branch you"
-		echo "want to merge with, and 'branch.${curr_branch}.merge' in"
-		echo "your configuration file does not tell me either.	Please"
-		echo "specify which branch you want to merge on the command line and"
+		echo "want to $op_type $op_prep, and 'branch.${curr_branch}.$op_type' in"
+		echo "your configuration file does not tell me either. Please"
+		echo "specify which branch you want to use on the command line and"
 		echo "try again (e.g. 'git pull <repository> <refspec>')."
 		echo "See git-pull(1) for details."
 		echo
-		echo "If you often merge with the same branch, you may want to"
-		echo "configure the following variables in your configuration"
-		echo "file:"
+		echo "If you often $op_type $op_prep the same branch, you may want to"
+		echo "use something like the following in your configuration file:"
 		echo
-		echo "    branch.${curr_branch}.remote = <nickname>"
-		echo "    branch.${curr_branch}.merge = <remote-ref>"
-		echo "    remote.<nickname>.url = <url>"
-		echo "    remote.<nickname>.fetch = <refspec>"
+		echo "    [branch \"${curr_branch}\"]"
+		echo "    remote = <nickname>"
+		echo "    $op_type = <remote-ref>"
+		echo "    [remote \"<nickname>\"]"
+		echo "    url = <url>"
+		echo "    fetch = <refspec>"
 		echo
 		echo "See git-config(1) for details."
 	else
-		echo "Your configuration specifies to merge the ref '${upstream#refs/heads/}' from the"
-		echo "remote, but no such ref was fetched."
+		echo "Your configuration specifies to $op_type $op_prep the ref '${upstream#refs/heads/}'"
+		echo "from the remote, but no such ref was fetched."
 	fi
 	exit 1
 }
-- 
1.6.5.2.156.g89436

Re: [PATCH] git-pull.sh: overhaul error handling when no candidates are found

[Jeff King]

On Thu, Nov 12, 2009 at 03:53:10PM +0100, Jan Krüger wrote:

> * The longish error message displayed when the user uses "git pull" but
>   has no remote/merge/rebase lines configured for the current branch
>   contains example configuration to remedy the situation... but the
>   example uses a rather invalid syntax, using the dotted syntax "git
>   config" accepts, but also "=" separators which are used in the config
>   file format. It also implies that this syntax is valid in git config
>   files. This changes the example to use valid config file syntax.

Personally, I would go the other way: give them something they can cut
and paste on the command line, like:

  git config branch.${curr_branch}.merge ${upstream#refs/heads/}

> +	if [ true = "$rebase" ]; then
> +		op_type=rebase
> +		op_prep=against
> +	else
> +		op_type=merge
> +		op_prep=with
> +	fi
> +
>  	curr_branch=${curr_branch#refs/heads/}
> -	upstream=$(git config "branch.$curr_branch.merge")
> +	upstream=$(git config "branch.$curr_branch.$op_type")

Isn't branch.*.rebase a boolean value?

-Peff

Re: [PATCH] git-pull.sh: overhaul error handling when no candidates are found

[Jan Krüger]

> Personally, I would go the other way: give them something they can cut
> and paste on the command line, like:

A matter of taste, I suppose. The user has to edit the lines anyway
since they contain placeholders.

> Isn't branch.*.rebase a boolean value?

Argh! Of course it is. Note to self: don't write patches in a hurry.
Disregard everything I said. I thought I was seeing incorrect behavior
in what Jan (N.) reported...

Jan

Re: [PATCH] git-pull.sh: overhaul error handling when no candidates are found

[Jeff King]

On Thu, Nov 12, 2009 at 04:25:58PM +0100, Jan Krüger wrote:

> > Personally, I would go the other way: give them something they can cut
> > and paste on the command line, like:
> 
> A matter of taste, I suppose. The user has to edit the lines anyway
> since they contain placeholders.

Oh, true. I was thinking we filled them in with the right values, but of
course we don't know what those values are (if we did, we wouldn't be
bugging the user...). So ignore what I said.

> > Isn't branch.*.rebase a boolean value?
> 
> Argh! Of course it is. Note to self: don't write patches in a hurry.
> Disregard everything I said. I thought I was seeing incorrect behavior
> in what Jan (N.) reported...

If it makes you feel better, the reason I noticed your error so quickly
is that I made the _exact_ same one while doing a patch in that area a
month or two ago.

-Peff

[PATCH v2] git-pull.sh --rebase: overhaul error handling when no candidates are found

[Jan Krüger]

* The longish error message displayed when the user uses "git pull" but
  has no remote/merge/rebase lines configured for the current branch
  contains example configuration to remedy the situation... but the
  example uses a rather invalid syntax, using the dotted syntax "git
  config" accepts, but also "=" separators which are used in the config
  file format. It also implies that this syntax is valid in git config
  files. This changes the example to use valid config file syntax.

* When git pull --rebase is used, error_on_no_merge_candidates still
  thinks we're trying to merge, so the resulting message talks about
  merge all the time. This makes the message depend on the mode of
  operation.

Signed-off-by: Jan Krüger <jk@jk.gs>
---
So this still uses config file syntax, but the erroneous check for
using the "rebase" setting is gone. Instead, if --rebase is in effect,
include "rebase = true" in the sample config snippet.

By the way, Jeff, it's precisely your patch that confused me into
thinking there was a bug. I sort of assumed the messages you added had
already been there in the version Jan N. is using. Stupid assumption, I
guess.

 git-pull.sh |   41 ++++++++++++++++++++++++++---------------
 1 files changed, 26 insertions(+), 15 deletions(-)

diff --git a/git-pull.sh b/git-pull.sh
index 37f3d93..315ec51 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -91,45 +91,56 @@ error_on_no_merge_candidates () {
 		esac
 	done
 
+	if [ true = "$rebase" ]; then
+		op_type=rebase
+		op_prep=against
+	else
+		op_type=merge
+		op_prep=with
+	fi
+
 	curr_branch=${curr_branch#refs/heads/}
 	upstream=$(git config "branch.$curr_branch.merge")
 	remote=$(git config "branch.$curr_branch.remote")
 
 	if [ $# -gt 1 ]; then
-		echo "There are no candidates for merging in the refs that you just fetched."
+		echo "There are no candidates for using the refs that you just fetched."
 		echo "Generally this means that you provided a wildcard refspec which had no"
 		echo "matches on the remote end."
 	elif [ $# -gt 0 ] && [ "$1" != "$remote" ]; then
 		echo "You asked to pull from the remote '$1', but did not specify"
-		echo "a branch to merge. Because this is not the default configured remote"
+		echo "a branch to use. Because this is not the default configured remote"
 		echo "for your current branch, you must specify a branch on the command line."
 	elif [ -z "$curr_branch" ]; then
 		echo "You are not currently on a branch, so I cannot use any"
 		echo "'branch.<branchname>.merge' in your configuration file."
-		echo "Please specify which branch you want to merge on the command"
+		echo "Please specify which branch you want to use on the command"
 		echo "line and try again (e.g. 'git pull <repository> <refspec>')."
 		echo "See git-pull(1) for details."
 	elif [ -z "$upstream" ]; then
 		echo "You asked me to pull without telling me which branch you"
-		echo "want to merge with, and 'branch.${curr_branch}.merge' in"
-		echo "your configuration file does not tell me either.	Please"
-		echo "specify which branch you want to merge on the command line and"
+		echo "want to $op_type $op_prep, and 'branch.${curr_branch}.merge' in"
+		echo "your configuration file does not tell me either. Please"
+		echo "specify which branch you want to use on the command line and"
 		echo "try again (e.g. 'git pull <repository> <refspec>')."
 		echo "See git-pull(1) for details."
 		echo
-		echo "If you often merge with the same branch, you may want to"
-		echo "configure the following variables in your configuration"
-		echo "file:"
+		echo "If you often $op_type $op_prep the same branch, you may want to"
+		echo "use something like the following in your configuration file:"
 		echo
-		echo "    branch.${curr_branch}.remote = <nickname>"
-		echo "    branch.${curr_branch}.merge = <remote-ref>"
-		echo "    remote.<nickname>.url = <url>"
-		echo "    remote.<nickname>.fetch = <refspec>"
+		echo "    [branch \"${curr_branch}\"]"
+		echo "    remote = <nickname>"
+		echo "    merge = <remote-ref>"
+		test rebase = "$op_type" &&
+			echo "    rebase = true"
+		echo "    [remote \"<nickname>\"]"
+		echo "    url = <url>"
+		echo "    fetch = <refspec>"
 		echo
 		echo "See git-config(1) for details."
 	else
-		echo "Your configuration specifies to merge the ref '${upstream#refs/heads/}' from the"
-		echo "remote, but no such ref was fetched."
+		echo "Your configuration specifies to $op_type $op_prep the ref '${upstream#refs/heads/}'"
+		echo "from the remote, but no such ref was fetched."
 	fi
 	exit 1
 }
-- 
1.6.5.2.156.g89436

Re: [PATCH v2] git-pull.sh --rebase: overhaul error handling when no candidates are found

[Jonathan Nieder]

Jan Krüger wrote:

> Subject: [PATCH v2] git-pull.sh --rebase: overhaul error handling when no candidates are found

s/error handling/error message/. :)

> --- a/git-pull.sh
> +++ b/git-pull.sh
> @@ -91,45 +91,56 @@ error_on_no_merge_candidates () {
[...]
>  	if [ $# -gt 1 ]; then
> -		echo "There are no candidates for merging in the refs that you just fetched."
> +		echo "There are no candidates for using the refs that you just fetched."
>  		echo "Generally this means that you provided a wildcard refspec which had no"
>  		echo "matches on the remote end."

This sounds a little awkward to me, maybe because all the remote refs
are being used to populate the remotes/<remote>/* hierarchy.

I’m trying to come up with an alternative wording, but it is hard:

 * Merging and rebasing are about incorporating the remote history
   into our own, so how about something like "... no candidates for
   incorporating from the refs ..."?  

 * Maybe one is using 'git pull' to update.  "There are no
   candidates to use for an update among the refs that you just
   fetched."

 * Or: "There are no upstreams to local branches among the refs that
   you just fetched."

I like the third of these best, but I hope you can do better.

>  	elif [ $# -gt 0 ] && [ "$1" != "$remote" ]; then
>  		echo "You asked to pull from the remote '$1', but did not specify"
> -		echo "a branch to merge. Because this is not the default configured remote"
> +		echo "a branch to use. Because this is not the default configured remote"

Maybe just "... did not specify a branch."?

>  		echo "for your current branch, you must specify a branch on the command line."
>  	elif [ -z "$curr_branch" ]; then
>  		echo "You are not currently on a branch, so I cannot use any"
>  		echo "'branch.<branchname>.merge' in your configuration file."
> -		echo "Please specify which branch you want to merge on the command"
> +		echo "Please specify which branch you want to use on the command"

s/branch/remote branch/?  The reader might worry that the command is
going to try to re-attach his HEAD.

The rest of your patch looks good to me.  Thanks for working on this.

Jonathan

[PATCH] pull: clarify advice for the unconfigured error case

[Jonathan Nieder]

From: Jan Krüger <jk@jk.gs>

When pull --rebase fails because it cannot find what branch to
merge against, the error message implies we are trying to merge.
Say "rebase against" instead of "merge with" to avoid confusion.

The configuration suggested to remedy the situation uses a
confusing syntax, with variables specified in the dotted form
accepted by 'git config' but separated from their values by the
'=' delimiter used by config files.  Since the user will have to
edit this output anyway, it is more helpful to provide a config
file snippet to paste into an editor and modify.

Signed-off-by: Jan Krüger <jk@jk.gs>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Jonathan Nieder wrote:
> Jan Krüger wrote:
 
>> --- a/git-pull.sh
>> +++ b/git-pull.sh
>> @@ -91,45 +91,56 @@ error_on_no_merge_candidates () {
>[...]
>>  	if [ $# -gt 1 ]; then
>> -		echo "There are no candidates for merging in the refs that you just fetched."
>> +		echo "There are no candidates for using the refs that you just fetched."
>>  		echo "Generally this means that you provided a wildcard refspec which had no"
>>  		echo "matches on the remote end."
>
> This sounds a little awkward to me, maybe because all the remote refs
> are being used to populate the remotes/<remote>/* hierarchy.

Scratch that --- I was confused.

I still find pull pretty confusing.  In its three forms, it does
different things:

 - 'git pull' fetches from the current branch’s remote (both its
   standard fetch refspec and the current branch’s), then merges any
   branches that match the current branch’s refspec.

 - 'git pull foo' fetches from the specified remote.  If it is
   the current branch’s remote, this is just a synonym for
   'git pull'; otherwise, it first fetches and then complains.

 - 'git pull foo refspec' does a fetch according to the specified
   refspec, and if any branches match, merges them into the
   current branch.

I was worried about the first form before (but who uses wildcards
in their branches’ refspecs?), but as Peff explains in commit
a8c9bef (pull: improve advice for unconfigured error case,
2009-10-05) the third one should be much more common.

In the --rebase case, exactly one branch would have to match for
this to make any sense (there is no such thing as an octopus
rebase), so I reworded the message accordingly.

 git-pull.sh |   48 +++++++++++++++++++++++++++++++++---------------
 1 files changed, 33 insertions(+), 15 deletions(-)

diff --git a/git-pull.sh b/git-pull.sh
index 37f3d93..2c384c4 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -91,45 +91,63 @@ error_on_no_merge_candidates () {
 		esac
 	done
 
+	if test true = "$rebase"
+	then
+		op_type=rebase
+		op_prep=against
+	else
+		op_type=merge
+		op_prep=with
+	fi
+
 	curr_branch=${curr_branch#refs/heads/}
 	upstream=$(git config "branch.$curr_branch.merge")
 	remote=$(git config "branch.$curr_branch.remote")
 
 	if [ $# -gt 1 ]; then
-		echo "There are no candidates for merging in the refs that you just fetched."
+		if [ "$rebase" = true ]; then
+			printf "There is no candidate for rebasing against "
+		else
+			printf "There are no candidates for merging "
+		fi
+		echo "among the refs that you just fetched."
 		echo "Generally this means that you provided a wildcard refspec which had no"
 		echo "matches on the remote end."
 	elif [ $# -gt 0 ] && [ "$1" != "$remote" ]; then
 		echo "You asked to pull from the remote '$1', but did not specify"
-		echo "a branch to merge. Because this is not the default configured remote"
+		echo "a branch. Because this is not the default configured remote"
 		echo "for your current branch, you must specify a branch on the command line."
 	elif [ -z "$curr_branch" ]; then
 		echo "You are not currently on a branch, so I cannot use any"
 		echo "'branch.<branchname>.merge' in your configuration file."
-		echo "Please specify which branch you want to merge on the command"
+		echo "Please specify which remote branch you want to use on the command"
 		echo "line and try again (e.g. 'git pull <repository> <refspec>')."
 		echo "See git-pull(1) for details."
 	elif [ -z "$upstream" ]; then
 		echo "You asked me to pull without telling me which branch you"
-		echo "want to merge with, and 'branch.${curr_branch}.merge' in"
-		echo "your configuration file does not tell me either.	Please"
-		echo "specify which branch you want to merge on the command line and"
+		echo "want to $op_type $op_prep, and 'branch.${curr_branch}.merge' in"
+		echo "your configuration file does not tell me, either. Please"
+		echo "specify which branch you want to use on the command line and"
 		echo "try again (e.g. 'git pull <repository> <refspec>')."
 		echo "See git-pull(1) for details."
 		echo
-		echo "If you often merge with the same branch, you may want to"
-		echo "configure the following variables in your configuration"
-		echo "file:"
+		echo "If you often $op_type $op_prep the same branch, you may want to"
+		echo "use something like the following in your configuration file:"
+		echo
+		echo "    [branch \"${curr_branch}\"]"
+		echo "    remote = <nickname>"
+		echo "    merge = <remote-ref>"
+		test rebase = "$op_type" &&
+			echo "    rebase = true"
 		echo
-		echo "    branch.${curr_branch}.remote = <nickname>"
-		echo "    branch.${curr_branch}.merge = <remote-ref>"
-		echo "    remote.<nickname>.url = <url>"
-		echo "    remote.<nickname>.fetch = <refspec>"
+		echo "    [remote \"<nickname>\"]"
+		echo "    url = <url>"
+		echo "    fetch = <refspec>"
 		echo
 		echo "See git-config(1) for details."
 	else
-		echo "Your configuration specifies to merge the ref '${upstream#refs/heads/}' from the"
-		echo "remote, but no such ref was fetched."
+		echo "Your configuration specifies to $op_type $op_prep the ref '${upstream#refs/heads/}'"
+		echo "from the remote, but no such ref was fetched."
 	fi
 	exit 1
 }
-- 
1.6.5.3

Re: [PATCH] pull: clarify advice for the unconfigured error case

[Junio C Hamano]

Jonathan Nieder <jrnieder@gmail.com> writes:

> From: Jan Krüger <jk@jk.gs>
>
> When pull --rebase fails because it cannot find what branch to
> merge against, the error message implies we are trying to merge.
> Say "rebase against" instead of "merge with" to avoid confusion.

I was going over the mail archive to see if I missed any important fixes
that should be in before 1.6.6 final and noticed that this is not applied,
and there was no follow-up to this message either.

Is this a good replacement for 31971b3 (git-pull.sh --rebase: overhaul
error handling when no candidates are found, 2009-11-12) that is on 'pu'
and does the lack of follow-up mean everybody involved in the discussion
is happy with this version?

> diff --git a/git-pull.sh b/git-pull.sh
> index 37f3d93..2c384c4 100755
> --- a/git-pull.sh
> +++ b/git-pull.sh
> @@ -91,45 +91,63 @@ error_on_no_merge_candidates () {
>  		esac
>  	done
>  
> +	if test true = "$rebase"
> +	then
> +		op_type=rebase
> +		op_prep=against
> +	else
> +		op_type=merge
> +		op_prep=with
> +	fi
> +
>  	curr_branch=${curr_branch#refs/heads/}
>  	upstream=$(git config "branch.$curr_branch.merge")
>  	remote=$(git config "branch.$curr_branch.remote")
>  
>  	if [ $# -gt 1 ]; then
> -		echo "There are no candidates for merging in the refs that you just fetched."
> +		if [ "$rebase" = true ]; then
> +			printf "There is no candidate for rebasing against "
> +		else
> +			printf "There are no candidates for merging "
> +		fi
> +		echo "among the refs that you just fetched."
>  		echo "Generally this means that you provided a wildcard refspec which had no"
>  		echo "matches on the remote end."
>  	elif [ $# -gt 0 ] && [ "$1" != "$remote" ]; then
>  		echo "You asked to pull from the remote '$1', but did not specify"
> -		echo "a branch to merge. Because this is not the default configured remote"
> +		echo "a branch. Because this is not the default configured remote"
>  		echo "for your current branch, you must specify a branch on the command line."
>  	elif [ -z "$curr_branch" ]; then
>  		echo "You are not currently on a branch, so I cannot use any"
>  		echo "'branch.<branchname>.merge' in your configuration file."
> -		echo "Please specify which branch you want to merge on the command"
> +		echo "Please specify which remote branch you want to use on the command"
>  		echo "line and try again (e.g. 'git pull <repository> <refspec>')."
>  		echo "See git-pull(1) for details."
>  	elif [ -z "$upstream" ]; then
>  		echo "You asked me to pull without telling me which branch you"
> -		echo "want to merge with, and 'branch.${curr_branch}.merge' in"
> -		echo "your configuration file does not tell me either.	Please"
> -		echo "specify which branch you want to merge on the command line and"
> +		echo "want to $op_type $op_prep, and 'branch.${curr_branch}.merge' in"
> +		echo "your configuration file does not tell me, either. Please"
> +		echo "specify which branch you want to use on the command line and"
>  		echo "try again (e.g. 'git pull <repository> <refspec>')."
>  		echo "See git-pull(1) for details."
>  		echo
> -		echo "If you often merge with the same branch, you may want to"
> -		echo "configure the following variables in your configuration"
> -		echo "file:"
> +		echo "If you often $op_type $op_prep the same branch, you may want to"
> +		echo "use something like the following in your configuration file:"
> +		echo
> +		echo "    [branch \"${curr_branch}\"]"
> +		echo "    remote = <nickname>"
> +		echo "    merge = <remote-ref>"
> +		test rebase = "$op_type" &&
> +			echo "    rebase = true"
>  		echo
> -		echo "    branch.${curr_branch}.remote = <nickname>"
> -		echo "    branch.${curr_branch}.merge = <remote-ref>"
> -		echo "    remote.<nickname>.url = <url>"
> -		echo "    remote.<nickname>.fetch = <refspec>"
> +		echo "    [remote \"<nickname>\"]"
> +		echo "    url = <url>"
> +		echo "    fetch = <refspec>"
>  		echo
>  		echo "See git-config(1) for details."
>  	else
> -		echo "Your configuration specifies to merge the ref '${upstream#refs/heads/}' from the"
> -		echo "remote, but no such ref was fetched."
> +		echo "Your configuration specifies to $op_type $op_prep the ref '${upstream#refs/heads/}'"
> +		echo "from the remote, but no such ref was fetched."
>  	fi
>  	exit 1
>  }
> -- 
> 1.6.5.3

Re: [PATCH] pull: clarify advice for the unconfigured error case

[Jonathan Nieder]

Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> From: Jan Krüger <jk@jk.gs>
>>
>> When pull --rebase fails because it cannot find what branch to
>> merge against, the error message implies we are trying to merge.
>> Say "rebase against" instead of "merge with" to avoid confusion.
[...]
> Is this a good replacement for 31971b3 (git-pull.sh --rebase: overhaul
> error handling when no candidates are found, 2009-11-12) that is on 'pu'

Yes, that is the intent.

> and does the lack of follow-up mean everybody involved in the discussion
> is happy with this version?

I’m not sure.  I know I like it. :-)

I was the only one with nitpicks about the wording (sorry).  Re
whether to use configuration file syntax or a 'git config' command
line snippet, it seemed like there was some consensus once it was
clear that the user would have to modify the lines anyway to fill in
the right values.  But others can speak up if this seems wrong.

Hope that helps,
Jonathan

Re: [PATCH] pull: clarify advice for the unconfigured error case

[Jeff King]

On Wed, Dec 02, 2009 at 07:26:14PM -0600, Jonathan Nieder wrote:

> > and does the lack of follow-up mean everybody involved in the discussion
> > is happy with this version?
> 
> I’m not sure.  I know I like it. :-)
> 
> I was the only one with nitpicks about the wording (sorry).  Re
> whether to use configuration file syntax or a 'git config' command
> line snippet, it seemed like there was some consensus once it was
> clear that the user would have to modify the lines anyway to fill in
> the right values.  But others can speak up if this seems wrong.

Yeah, that was my main complaint, and I withdrew it after getting a
clue. :) I gave the patch another quick look, and I think it is fine.

-Peff

Re: [PATCH] pull: clarify advice for the unconfigured error case

[Jan Nieuwenhuizen]

Op woensdag 02-12-2009 om 20:43 uur [tijdzone -0500], schreef Jeff King:
> On Wed, Dec 02, 2009 at 07:26:14PM -0600, Jonathan Nieder wrote:
> 
> > > and does the lack of follow-up mean everybody involved in the discussion
> > > is happy with this version?

> Yeah, that was my main complaint, and I withdrew it after getting a
> clue. :) I gave the patch another quick look, and I think it is fine.

Great, thanks!

Jan.


-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl    | http://lilypond.org

Re: [PATCH] pull: clarify advice for the unconfigured error case

[Jan Krüger]

Junio C Hamano <gitster@pobox.com> wrote:

> Is this a good replacement for 31971b3 (git-pull.sh --rebase: overhaul
> error handling when no candidates are found, 2009-11-12) that is on
> 'pu' and does the lack of follow-up mean everybody involved in the
> discussion is happy with this version?

I'm not deliriously happy but I can't think of a better version, and I
suppose it's better than what I suggested. In other words, I'm fine
with the patch.

Jan

Re: [PATCH] pull: clarify advice for the unconfigured error case

[Junio C Hamano]

Jan Krüger <jk@jk.gs> writes:

> Junio C Hamano <gitster@pobox.com> wrote:
>
>> Is this a good replacement for 31971b3 (git-pull.sh --rebase: overhaul
>> error handling when no candidates are found, 2009-11-12) that is on
>> 'pu' and does the lack of follow-up mean everybody involved in the
>> discussion is happy with this version?
>
> I'm not deliriously happy but I can't think of a better version, and I
> suppose it's better than what I suggested. In other words, I'm fine
> with the patch.

Thanks.

Re: [PATCH v2] git-pull.sh --rebase: overhaul error handling when no candidates are found

[Junio C Hamano]

Jan Krüger <jk@jk.gs> writes:

> So this still uses config file syntax, but the erroneous check for
> using the "rebase" setting is gone. Instead, if --rebase is in effect,
> include "rebase = true" in the sample config snippet.

Will queue.

I've been ill and didn't follow the discussion very closely, so perhaps
there may still some minor disagreements in the details I didn't catch?

Just in case, I'll queue it on 'pu' for now.

Thanks.

Re: Unhelpful "branch.master.remote = <nickname>" advice?

[Björn Steinbrink]

On 2009.11.12 15:17:29 +0100, Jan Nieuwenhuizen wrote:
> Op woensdag 11-11-2009 om 21:32 uur [tijdzone +0100], schreef Tomas
> Carnecky:
> 
> Hi Tomas,
> 
> > It didn't tell you to copy'n'paste the whole lines to a git-config(1)  
> > commandline. But I do see that the output can be confusing for someone  
> > not familiar with the git configuration files/git-config.
> 
> Once I get this to work, I'll send a patch for it.
> 
> > I don't know the relationship between you and eddy, but usually you  
> > shouldn't rebase (=rewrite) eddies commits. That also means you'd have  
> > to live with the merge commits.
> 
> Hmm, okay.
> 
> > I see your mistake. Both the origin and eddy remote write to the same  
> > namespace (refs/remotes/origin/*), and that's also why you get (force  
> > update) below
> 
> Ah, that makes sense.
> 
> > . Change the fetch line of remote.eddy.fetch to +refs/heads/*:refs/ 
> > remotes/eddy/*. After that both command (pull -r / pull -r eddy)  
> > should work (I hope).
> 
> Okay, so now I have
> 
>     [branch "master"]
> 	    remote = origin
> 	    merge = refs/heads/master
>     [remote "origin"]
> 	    url = git@github.com:janneke/gub.git
> 	    fetch = +refs/heads/*:refs/remotes/origin/*
>     # advise from git pull, using <nickname> = eddy
>     #        branch.master.remote = <nickname>
>     #        branch.master.merge = <remote-ref>
>     #        remote.<nickname>.url = <url>
>     #        remote.<nickname>.fetch = <refspec>
>     #[branch "master"]
>     #	remote = eddy
>     #	merge = refs/heads/master
>     [remote "eddy"]
> 	    url = http://github.com/epronk/gub.git
>     #use remote.eddy.fetch to +refs/heads/*:refs/remotes/eddy/*.
> 	    fetch = +refs/heads/*:refs/remotes/eddy/*
> 
> It looked promising, but still get
> 
>     15:00:20 janneke@peder:~/vc/gub
>     $ git pull -r --verbose
>     From git@github.com:janneke/gub
>      = [up to date]      lilypond-release-branch -> origin/lilypond-release-branch
>      = [up to date]      master     -> origin/master
>     Current branch master is up to date.

That used the configured defaults.

>     15:00:26 janneke@peder:~/vc/gub
>     $ git pull -r --verbose eddy
>     From http://github.com/epronk/gub
>      = [up to date]      lilypond-release-branch -> eddy/lilypond-release-branch
>      = [up to date]      master     -> eddy/master

This one got arguments, so it didn't use defaults.

If you want "git pull" to use the "eddy" remote, then set
branch.<name>.remote to eddy, not to origin.


And as a sidenote:
Using "git pull --rebase" with more than one upstream is most of the
time a very bad idea.

Let's say we have:

A---B---C---D (master)
     \   \
      \   E---F---G (origin's master)
       \
        H---I---J (eddy's master)

Now you do "git pull --rebase origin master", which results in:

                      D' (master)
                     /
A---B---C---E---F---G (origin's master)
     \
      H---I---J (eddy's master)

And then you do "git pull eddy master", which will now rebase history
that is not yours:

A---B---C---E---F---G (origin's master)
     \
      H---I---J (eddy's master)
               \
                C'--E'--F'--G'--D' (master)

IOW, you get one hell of a mess.

Björn

Re: Unhelpful "branch.master.remote = <nickname>" advice?

[Tomas Carnecky]

On Nov 12, 2009, at 3:17 PM, Jan Nieuwenhuizen wrote:
>
> Okay, so now I have
>
>    [branch "master"]
> 	    remote = origin
> 	    merge = refs/heads/master
>    [remote "origin"]
> 	    url = git@github.com:janneke/gub.git
> 	    fetch = +refs/heads/*:refs/remotes/origin/*
>    # advise from git pull, using <nickname> = eddy
>    #        branch.master.remote = <nickname>
>    #        branch.master.merge = <remote-ref>
>    #        remote.<nickname>.url = <url>
>    #        remote.<nickname>.fetch = <refspec>
>    #[branch "master"]
>    #	remote = eddy
>    #	merge = refs/heads/master
>    [remote "eddy"]
> 	    url = http://github.com/epronk/gub.git
>    #use remote.eddy.fetch to +refs/heads/*:refs/remotes/eddy/*.
> 	    fetch = +refs/heads/*:refs/remotes/eddy/*
>
> It looked promising, but still get
>
>    15:00:20 janneke@peder:~/vc/gub
>    $ git pull -r --verbose
>    From git@github.com:janneke/gub
>     = [up to date]      lilypond-release-branch -> origin/lilypond- 
> release-branch
>     = [up to date]      master     -> origin/master
>    Current branch master is up to date.
>    15:00:26 janneke@peder:~/vc/gub
>    $ git pull -r --verbose eddy
>    From http://github.com/epronk/gub
>     = [up to date]      lilypond-release-branch -> eddy/lilypond- 
> release-branch
>     = [up to date]      master     -> eddy/master
>    You asked me to pull without telling me which branch you
>    want to merge with, and 'branch.master.merge' in
>    your configuration file does not tell me either.	Please
>    specify which branch you want to merge on the command line and
>    try again (e.g. 'git pull <repository> <refspec>').
>    See git-pull(1) for details.
>
>    If you often merge with the same branch, you may want to
>    configure the following variables in your configuration
>    file:
>
> 	branch.master.remote = <nickname>
> 	branch.master.merge = <remote-ref>
> 	remote.<nickname>.url = <url>
> 	remote.<nickname>.fetch = <refspec>
>
>    See git-config(1) for details.
>    [1]15:00:33 janneke@peder:~/vc/gub
>    $

Do you want to rebase on top of origin or eddy? It doesn't make sense  
to rebase on top of both.

With git you usually develop new features in branches and then merge  
the result into the master branch once it's ready. So you would use a  
branch 'feature-X' and there you work on your feature. Since it's your  
private/local branch, you can rebase it however you want. In the  
meantime eddy has also worked on some new cool features, and now that  
he's ready he told you to pull from his branch. So you 'git checkout  
master; git pull eddy master' to merge his new features. Then you can  
push the result into your github repo, checkout feature-X and rebase  
that on top of the new origin/master. Once your feature is done, you  
can checkout master, merge feature-X and push that to github.

Another reason not to rebase on top of eddy's master branch is this:  
if is master is behind your master (eg. your master has commits that  
his master doesn't), and you rebase on top of his master, you loose  
the commits.

>
> After this I started to re-read git-config's man page
> again.  There is something strange that I do not understand
>
>    branch.<name>.merge
>        Defines, together with branch.<name>.remote, the upstream
>        branch for the given branch.  It tells git-fetch/git-pull
>        which branch to merge and can also affect git-push (see
>        push.default).
>
> this seems to imply that the merge variable here
>
>   [branch "master"]
>       remote = FOOBAR
>       merge = refs/heads/master
>
> is somehow tied to the remote nick FOOBAR.  That would
> mean it is actually taken as
>
>     branch.<name>.<nickname>.merge
>
> and also that it's impossible to specify more than one
> <nickname>.  That would be make nicknames unusable and
> thus silly, so I cannot be right?

It seems like 'git pull <remote>' doesn't work. Either use 'git pull',  
in which case git takes the needed info from  
branch.<name>.remote/.merge, or use 'git pull <remote> <branch>' in  
which case git will use the info from the commandline. It doesn't make  
much sense to say 'pull from X but rebase on top of the same remote  
branch name as if you'd pull from Y'.

tom

[PATCH] Makefile: add uninstall target. Fixes elementary good cleaning manners.

[Jan Nieuwenhuizen]

Op woensdag 11-11-2009 om 15:08 uur [tijdzone +0100], schreef Tomas
Carnecky:

> > Greetings,
> > Jan.  -- who just finds out the uninstall target is missing?!?
> > 	 See attached.
> 
> Next time please send patches inline, it's easier to review them that  
> way.

Sorry.  Let me retry that.  See below.

Greetings,
Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl    | http://lilypond.org
>From f260a4dcf0b42088eb1da74aee49f49ac4b0c55b Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen <janneke@gnu.org>
Date: Wed, 11 Nov 2009 14:19:00 +0100
Subject: [PATCH] Makefile: add uninstall target.  Fixes elementary good cleaning manners.

   * Modified     Makefile
   * Modified     gitk-git/Makefile
   * Modified     perl/Makefile
   * Modified     templates/Makefile

Signed-off-by: Jan Nieuwenhuizen <janneke@gnu.org>
---
 Makefile           |   18 +++++++++++++++++-
 gitk-git/Makefile  |    2 ++
 perl/Makefile      |    2 +-
 templates/Makefile |    5 +++++
 4 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 5d5976f..135c3ac 100644
--- a/Makefile
+++ b/Makefile
@@ -1781,7 +1781,23 @@ quick-install-man:
 quick-install-html:
 	$(MAKE) -C Documentation quick-install-html
 
+bindir_PROGRAMS = git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X git-shell$X git-cvsserver
 
+uninstall:
+ifndef NO_TCLTK
+	$(MAKE) -C gitk-git uninstall
+	$(MAKE) -C git-gui gitexecdir='$(gitexec_instdir_SQ)' uninstall
+endif
+ifndef NO_PERL
+	$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' uninstall
+endif
+	$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' uninstall
+	$(RM) $(ALL_PROGRAMS:%='$(DESTDIR_SQ)$(gitexec_instdir_SQ)'/%)
+	$(RM) $(BUILT_INS:%='$(DESTDIR_SQ)$(gitexec_instdir_SQ)'/%)
+	$(RM) $(OTHER_PROGRAMS:%='$(DESTDIR_SQ)$(gitexec_instdir_SQ)'/%)
+	-rmdir -p '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
+	$(RM) $(bindir_PROGRAMS:%='$(DESTDIR_SQ)$(bindir_SQ)'/%)
+	-rmdir -p '$(DESTDIR_SQ)$(bindir_SQ)'
 
 ### Maintainer's dist rules
 
@@ -1857,7 +1873,7 @@ ifndef NO_TCLTK
 endif
 	$(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-GUI-VARS GIT-BUILD-OPTIONS
 
-.PHONY: all install clean strip
+.PHONY: all install uninstall clean strip
 .PHONY: shell_compatibility_test please_set_SHELL_PATH_to_a_more_modern_shell
 .PHONY: .FORCE-GIT-VERSION-FILE TAGS tags cscope .FORCE-GIT-CFLAGS
 .PHONY: .FORCE-GIT-BUILD-OPTIONS
diff --git a/gitk-git/Makefile b/gitk-git/Makefile
index e1b6045..d68f19a 100644
--- a/gitk-git/Makefile
+++ b/gitk-git/Makefile
@@ -47,6 +47,8 @@ install:: all
 uninstall::
 	$(foreach p,$(ALL_MSGFILES), $(RM) '$(DESTDIR_SQ)$(msgsdir_SQ)'/$(notdir $p) &&) true
 	$(RM) '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
+	-rmdir -p '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
+	-rmdir -p '$(DESTDIR_SQ)$(msgsdir_SQ)'
 
 clean::
 	$(RM) gitk-wish po/*.msg
diff --git a/perl/Makefile b/perl/Makefile
index 4ab21d6..25fc304 100644
--- a/perl/Makefile
+++ b/perl/Makefile
@@ -10,7 +10,7 @@ ifndef V
 	QUIET = @
 endif
 
-all install instlibdir: $(makfile)
+all install instlibdir uninstall: $(makfile)
 	$(QUIET)$(MAKE) -f $(makfile) $@
 
 clean:
diff --git a/templates/Makefile b/templates/Makefile
index 408f013..f4048d9 100644
--- a/templates/Makefile
+++ b/templates/Makefile
@@ -51,3 +51,8 @@ install: all
 	$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(template_instdir_SQ)'
 	(cd blt && $(TAR) cf - .) | \
 	(cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) xof -)
+
+uninstall:
+	-(cd blt && find . -type f) | (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && xargs $(RM))
+	-(cd blt && find . -mindepth 1 -type d) | (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && xargs rmdir)
+	-rmdir -p '$(DESTDIR_SQ)$(template_instdir_SQ)'
-- 
1.6.3.3

Re: [PATCH] Makefile: add uninstall target. Fixes elementary good cleaning manners.

[Matthieu Moy]

Jan Nieuwenhuizen <janneke-list@xs4all.nl> writes:

> Sorry.  Let me retry that.  See below.

Please, read Documentation/SubmittingPatches 

>>From f260a4dcf0b42088eb1da74aee49f49ac4b0c55b Mon Sep 17 00:00:00 2001
> From: Jan Nieuwenhuizen <janneke@gnu.org>
> Date: Wed, 11 Nov 2009 14:19:00 +0100
> Subject: [PATCH] Makefile: add uninstall target.  Fixes elementary good cleaning manners.
>
>    * Modified     Makefile
>    * Modified     gitk-git/Makefile
>    * Modified     perl/Makefile
>    * Modified     templates/Makefile

Git knows better than you which files are modified by a commit, so
it's counter-productive to rewrite by hand this list in the commit
message. This place is the place to explain _why_ your change is good
(to convince the maintainer to apply it in git.git in particular).

>  Makefile           |   18 +++++++++++++++++-
>  gitk-git/Makefile  |    2 ++
>  perl/Makefile      |    2 +-
>  templates/Makefile |    5 +++++

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Unhelpful "branch.master.remote = <nickname>" advice?

[Jan Krüger]

Hi,

> git pull -r*) URL says: [...]
>         branch.master.remote = <nickname>
> and after cut-and-pasting that into .git/config, replacing
> <foo> with values, I get [...]
>     fatal: bad config file line 17 in .git/config
> where line 17 is [without any indentation]
>     branch.master.remote = eddy

The confusion is that while you can set values with this syntax if
you're using git config (git config branch.master.remote <some value>),
they're written differently in actual config files:

  [branch "master"]
  remote = <nickname>
  merge = <remote-ref>
  
  [remote "<nickname>"]
  url = <url>
  fetch = <refspec>

I can't think of a message of comparable length that would make this
clearer, though.

> Jan.  -- who just finds out the uninstall target is missing?!?
> 	 See attached.

I have no comments about the patch contents themselves, but please read
Documentation/SubmittingPatches. Most importantly, patches are
usually sent inline here, and without a signoff line they can't be
accepted for inclusion in the official repository.

> *) I've been wondering why GIT lacks a "update", ie
>    pull-without-merge command.  You almost never want
>    to git pull /without/ -r?

-r stands for "rebase", i.e. it makes git pull use rebase instead of
merge. Rebase has certain problematic implications for decentralized
development, which is why it should only really be used in specific
circumstances (for rebasing commits that haven't been published in any
way yet).

"You" may almost never want to use git pull without rebase, but "many
others" do, and very often. Personally, I donn't recall a single
occasion where I have used git pull --rebase (not counting git-svn
stuff).

Anyway, look at config options branch.autosetuprebase and
branch.<nickname>.rebase to see how you can make pull use rebase by
default.

-Jan

Re: Unhelpful "branch.master.remote = <nickname>" advice?

[Junio C Hamano]

Jan Nieuwenhuizen <janneke-list@xs4all.nl> writes:

> *) I've been wondering why GIT lacks a "update", ie
>    pull-without-merge command.  You almost never want
>    to git pull /without/ -r?

"You almost never want to git pull w/o --rebase" is incorrect, and you
cannot draw any conclusion from that statement.

I never want to run "git pull --rebase" myself, not in this project, nor
at work.  On the other hand, I always run "git pull --rebase" while
working on another OSS project that I am only following (I'm holding onto
a few private patches until they get applied).

So even the same person never uses --rebase or always uses --rebase,
depending on how he interacts with the repository on the other side,