Re: [PATCH/RFC 2/3] git-fetch: Split fetch and merge logic
- From
- Santi Béjar <sbejar@gmail.com>
- Date
- Feb 19, 2007, 22:13 UTC
- 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:
Show 13 quoted lines
> 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.
Show 12 quoted lines
> > > 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".
Show 9 quoted lines
> > 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