Thomas Rast <trast@xxxxxxxxxxxxxxx> writes:
> Junio C Hamano <gitster@xxxxxxxxx> writes:
>
>> Thomas Rast <trast@xxxxxxxxxxxxxxx> writes:
>>
>>> In some sense this is a really bad case of wrong UI design, because we
>>> (this happens on #git a lot) have to teach users not to use the command
>>> so they won't trip over this problem. It would be better to fix the
>>> real issue instead. IIRC it was even on the 1.8.0 wishlist...
>>
>> Is it?
>>
>> There already is a way to ask it to update the single tracking
>> branch while fetching; "git fetch origin master" that
>> unconditionally updates refs/remotes/origin/master without a way to
>> tell it not to do so will be a grave usability regression.
>
> Grave? Do you have any data/use-cases to back that up with?
When I get a pull request from say Eric, I would:
git fetch git-svn master
git show-branch remotes/git-svn/master FETCH_HEAD
to see what happened since the last pull request on the other side.
He may have rebased (which is not necessarily a crime), or I may see
more commits in the output than what he lists in the request message
(which may indicate I may have missed an earlier pull request from
him).
Such a sanity check will stop working if the first "fetch" updated
my remotes/git-svn/master. I would have to enable reflog for
tracking branch and do something like this:
git show-branch remotes/git-svn/master@{1} remotes/git-svn/master
So I was correct in saying that without an easy escape hatch, such a
change would be a regression.
But I think I (and others) could just train fingers to do
git fetch git-svn master:
as a workaround.
Updating Documentation/pull-fetch-param.txt would be a bear, though.
The documentation is stale in that it was written in the days back
when .git/remotes/ was the primary way to configure remotes, and was
not adjusted to use the termilology used in the [remote "where"]
section of the .git/config file (notice a mention of "'Pull: '
lines" there), so it needs cosmetic adjustment anyway, but the
semantics it spells is still up to date. The current rule is very
simple and understandable. You either say from the command line
exactly what should happen (refspec without colon is the same as the
refspec with colon at the end, meaning "do not track"; if you want
to track, you write what to update with the fetch), or we use the
configured refspec (which again spells what should happen).
The updated rule would be more complex. If a remote nickname is
used, and a refspec given from the command line is without colon, a
new special rule overrides the current behaviour and tries to match
with a configured refspec. You would need to desribe what happens
in that case.
--
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