t5515 in general

t5515 in general

[Daniel Barkalow]

It looks to me like t5515 enshrines a number of infelicities in the 
current fetch code. For example, if you have a branch configuration which 
specifies a remote that's configured through a branches/* file, and you 
have a merge setting for the branch, it's ignored, and we test that it's 
ignored with a whole bunch of tests. I think that the behavior here should 
either be unspecified, or we should make it more generally consistant 
(i.e., if you specify any "merge" items, this overrides the default of 
using the first refspec, even if the first refspec is implicit in the fact 
that you're using a branches/* file, which automatically only has the 
configured refspec refs/heads/master:). Or leave it unspecified and 
untested, since neither option is actually useful.

This makes me think that a lot of t5515 was done by putting together a 
bunch of configurations and automatically making tests for them without 
checking whether the current behaviour is actually something we want, or 
whether the configuration even could do anything sensible in the first 
place. So it might be worth going through that set and eliminating 
anything not actually predicted by the documentation.

	-Daniel
*This .sig left intentionally blank*

Re: t5515 in general

[Junio C Hamano]

In general I would agree that the whole "backward compatible"
thing we do with .git/branches and then .git/remotes when we
really went to the new model of using .git/config primarily was
done too cautiously, in that the configuration would not affect
existing setup that used branches and remotes, as they did not
have any way to express those new concepts (i.e. per branch
default remote, and per branch default merge sources).

I am actually in favor of killing .git/branches support way
before we do 1.6.0, and .git/remotes by the time we do 1.6.0.
But if you can arrange the url/fetch configurations to be still
taken from these old locations while applying per-branch default
remote and merge from .git/config, that would probably be easier
for people to migrate to .git/config only style.