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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Santi Béjar <sbejar@xxxxxxxxx> 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?  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.



-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]