Re: [PATCH/RFC 2/3] git-fetch: Split fetch and merge logic

From: Junio C Hamano <junkio@cox.net>
Date: Feb 19, 2007, 20:44 UTC
Message-ID: <7v649x7u90.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <87vei2o75x.fsf@gmail.com>

Santi Béjar <sbejar@gmail.com> writes:

Show 9 quoted lines

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

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

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.