From: Santi Béjar <sbejar@gmail.com>
Date: Mon, 19 Feb 2007 22:13:35 GMT
Subject: Re: [PATCH/RFC 2/3] git-fetch: Split fetch and merge logic
Message-ID: <8aa486160702191413p10c8ca0ek949580ffe953ea79@mail.gmail.com>
In-Reply-To: <7v649x7u90.fsf@assigned-by-dhcp.cox.net>

On 2/19/07, Junio C Hamano <junkio@cox.net> wrote:
> Santi Béjar <sbejar@gmail.com> writes:
>
> > git-fetch fetches the branches from the remote and saves this
> > information in .git/FETCH_FETCHED, and at the end it generates
> > the file .git/FETCH_HEAD.
> >
> > There are two cases where the behaviour is changed:
> >
> > 1) branch.*.merge no longer must exactly match the remote part
> >    of the branch fetched. Both are expanded in full (as refs/heads/...)
> >    and matched afterwards.
>
> How hard would it be to fix this?

At least it is not a 2 lines "fix".

>  I see this as a regression.
> If you are setting configuration, wouldn't you rather see the
> behaviour consistent even when remote adds new refs?

I don't see it a regression. All current setups continue to work
properly and, sorry but I don't see how adding a new ref changes this.

>
> > 2) When the remote is specified with $GIT_DIR/branches/... and there is
> >    a branch.*.merge, the remote branch name must match to get them merged.
> >    Before the branch in $GIT_DIR/branches/... was always merged.
>
> I do not think the current $GIT_DIR/branches/ support with
> respect to choosing which remote branch to choose was done with
> any deep thinking, other than to stay backward compatible, so I
> would not put too much trust in what is in the documentation.
> At the same time, I personally can be pursuaded to go either
> way, exactly because I do not think the current behaviour has
> strict reasoning behind it.

I prefer my way, but I don't mind much either and it can be "fixed".

>
> However, I wonder how this change would affect existing setups
> people may have.
>
> Merging this at this moment would be a pain even if there were
> no downsides, as there are a few topics that want to touch
> parse-remote and fetch (two already in 'pu', and git-bundle
> series also wants to hook into git-fetch); these topics would
> need to get adjusted if this clean-up goes in first.

A problematic decision :)

Santi