Re: [PATCH 3/3] fetch: optionally store the current remote information in the config

Johannes Schindelin [off-list ref] writes:

On Sun, 30 Apr 2006, sean wrote:

quoted

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: " ;-).

quoted

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.