{"thread":{"id":"8623","subject":"t5515 in general","startedAt":"2007-06-17T06:06:51Z","lastAt":"2007-06-17T08:04:37Z","messageCount":2,"participants":["Daniel Barkalow","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"45206","messageId":"Pine.LNX.4.64.0706170034540.4740@iabervon.org","threadId":"8623","inReplyTo":null,"subject":"t5515 in general","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-06-17T06:06:51Z","receivedAt":"2007-06-17T06:06:51Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"It looks to me like t5515 enshrines a number of infelicities in the \ncurrent fetch code. For example, if you have a branch configuration which \nspecifies a remote that's configured through a branches/* file, and you \nhave a merge setting for the branch, it's ignored, and we test that it's \nignored with a whole bunch of tests. I think that the behavior here should \neither be unspecified, or we should make it more generally consistant \n(i.e., if you specify any \"merge\" items, this overrides the default of \nusing the first refspec, even if the first refspec is implicit in the fact \nthat you're using a branches/* file, which automatically only has the \nconfigured refspec refs/heads/master:). Or leave it unspecified and \nuntested, since neither option is actually useful.\n\nThis makes me think that a lot of t5515 was done by putting together a \nbunch of configurations and automatically making tests for them without \nchecking whether the current behaviour is actually something we want, or \nwhether the configuration even could do anything sensible in the first \nplace. So it might be worth going through that set and eliminating \nanything not actually predicted by the documentation.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"45210","messageId":"7v4pl70zxm.fsf@assigned-by-dhcp.pobox.com","threadId":"8623","inReplyTo":"Pine.LNX.4.64.0706170034540.4740@iabervon.org","subject":"Re: t5515 in general","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-17T08:04:37Z","receivedAt":"2007-06-17T08:04:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"In general I would agree that the whole \"backward compatible\"\nthing we do with .git/branches and then .git/remotes when we\nreally went to the new model of using .git/config primarily was\ndone too cautiously, in that the configuration would not affect\nexisting setup that used branches and remotes, as they did not\nhave any way to express those new concepts (i.e. per branch\ndefault remote, and per branch default merge sources).\n\nI am actually in favor of killing .git/branches support way\nbefore we do 1.6.0, and .git/remotes by the time we do 1.6.0.\nBut if you can arrange the url/fetch configurations to be still\ntaken from these old locations while applying per-branch default\nremote and merge from .git/config, that would probably be easier\nfor people to migrate to .git/config only style.\n"}]}