Re: Default remote branch for local branch

From: Junio C Hamano <junkio@cox.net>
Date: Apr 3, 2006, 08:23 UTC
Message-ID: <7vr74ff4oy.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <200604030128.42680.Josef.Weidendorfer@gmx.de>

Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:

Show 17 quoted lines

> On Sunday 02 April 2006 23:40, you wrote:
>> > Let me try to understand this: the general idea is that
>> >
>> >   pull.origin = [<refspec> of] <remote> for <branch>
>> >
>> > specifies the default action of git-pull if we are on <branch>, ie.
>> > a "git pull" then runs "git pull <remote> [<refspec>]".
>> 
>> Not quite.
>> 
>> It will be (if this were a serious proposal -- I am not
>> absolutely convinced this is a good idea) more like "git fetch
>> <remote>" followed by "git-merge HEAD the-refspec-named-there".
>
> So it is not really a <refspec>, but a <localbranch> which has to
> appear in the .git/remotes file on the right side of a refspec on
> a Pull line.

No, I meant <refspec> not <localbranch> here, because I do not want to force people to have tracking local branch. The call to merge in pull that happens immediately after fetch does not use localbranch, but uses what's recorded in FETCH_HEAD, and if we were to do this change the above change would most likely to affect how each remote branch heads fetched are marked for (or not for) merges.

Show 13 quoted lines

> All I wanted to remark is, that, with
>
>  URL: <remote-URL>
>  Pull: refs/head/master:refs/head/remote1
>  Pull: refs/head/other:refs/head/remote2
>
> the config
>
>  pull.origin = <remote> for refs/head/my-devel-for-remote2
>
> which does not use the [<refspec> of] part, always is bogus:
> We get remote1 merged into my-devel-for-remote2 on a git-pull,
> which is not what we want.

I think we are on the same page, if you just think of not having [<refspec> of] a short-hand for naming the first Pull: line.

> Optionally, branching <new> off from <old> could add <new> as
> topic branch of <old>: Thus, if you are on <old> and do git-pull,
> you get <new> merged in.

I agree with Andreas on this part.

Show 6 quoted lines

>> A bigger thing is that I am trying to avoid _requiring_ tracking
>> branches.
>
> I don't think you force anything when you add functionality to git-pull
> for the config discussed here. Nobody *has* to use this config - it's
> a porcelain thingie.

Not if you made the [<refspec> of] part <localbranch>. Then this configuration for default merge source per local branch feature is available only to people who are willing to use tracking branches.

>> If you are not micromanaging your subsystem 
>> maintainers, you should not have to care where they were the
>> last time you pulled from them....
>> [...why not needing to use tracking branches is good...]

>> If we are going require tracking branches,
>
> I do not understand. Why should we require this?

I forgot to say "on the other hand" before that "If".

Show 5 quoted lines

>> we could do a bit 
>> more with them, like remembering where the tip was when we
>> fetched the last time (or the time before that...) and diff with
>> that, but the tracking branch heads are not set up to do things
>> like that right now -- they are single pointers.

Actually I think this part is independent and I did not have to mention. There is no point complicating only the tracking branches at all.

I just wanted to mention that it would be handy to be able to take snapshots of tracking branch heads, but it does not really matter whether they are "your" local development branches or tracking branches. Just a nightly or on-demand

         d="$GIT_DIR/refs/snapshot/`date '+%Y-%m-%d'`" &&
         mkdir "$GIT_DIR/refs/snapshot/$d" &&
         tar Ccf "$GIT_DIR/refs/" - heads |
         tar Cxf "$d" -

would do, and then you should be able to ask "where was my 'master' head yesterday?".