Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > On Sun, 30 Apr 2006, sean wrote: > >> Well I agree with you that doing something like this is important. We >> should take this moment of moving things to the config file to correct >> the terminology and help make things clear. We're not storing "Pull:" >> information, we're storing config/remote.$NICK.fetch data. It's really >> used just by fetch, pull just happens to call fetch. > > I have no strong feelings either way. I have a strong feeling that naming them "Pull: " was a mistake to begin with and they should have been called "Fetch: " ;-). >> Along that same line of reasoning, it seems more appropriate to use >> git fetch --store ... rather than git pull --store ... to set this >> information. > > Both works. I'd rather not see --store added to either fetch nor pull. While I would agree --store would appear to be a convenient short-hand for first timers, I strongly suspect this will cause more confusion and complexity down the line. If a topic that interests you appears today at the remote, and you start following it by adding --store when you fetch from it, and later when the topic disappears at the remote in two weeks because it is fully cooked and merged into somewhere else, you would need to have a way to --unstore it somehow, and at that time the first timer needs to learn repo-config to deal with that failure anyway. Or you need to teach git-fetch that fetch failure of a branch is actually OK as long as all of the following holds true: - the branch was added with --store in the past; the user is not actively asking for it in the current request, saying "I want to fetch from there THIS TIME". - the fetch failed only because the remote repository droped the branch (IOW you need to tell connection and protocol failure from "branch disappeared"case), - the fetch is not being done to merge it into the current branch, or something complicated like that, and unstore it automatically for the user. Other than that, I do not have strong feelings against using the standard .git/config to store what we store in .git/remotes/* currently, and I also suspect doing so would be a prerequiste first step to do "per local branch configuration" (e.g. "when on this branch, merge from this branch by default") some people seem to want. - : 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