Re: Default remote branch for local branch

[Josef Weidendorfer <Josef.Weidendorfer@gmx.de>]

On Monday 03 April 2006 10:23, Junio C Hamano wrote:
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> 
> > 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.

Oh, ok. I just had to look up the manual regarding refspecs when
pulling/fetching again: "<ref>" is the same as "<ref>:" and does
not create/use any local branch.

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

Yes, I understand this. But I do not think that such an optional
shortcut is useful for config files entries. It complicates parsing/editors,
and seems to make it more confusing. Despite, I agree that such optional
shortcuts are nice for porcelain command lines.

As I see the use of "<refspec> of <remote>", I still think that specifying
a local branch is useful, too. So what about

  pull.origin = (<refspec> of <remote> | <localbranch>) for <branch>	

instead? We can distinguish the two cases by looking for the "of".
When the <refspec> is of the form <src>:<dst> (where <dst> is the local
branch), we probably want to sanity check against .git/remotes/.

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

Yup. If we want to support topic branches with defaults, we should use
another config option. And now, I am not convinced about the usefulness
of this any more.

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

Yes, I understand this now.

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

Wow. For this, versioning of the /refs directory as subproject
would be good ;-)

Josef