Julian Phillips <julian@xxxxxxxxxxxxxxxxx> writes:
> On Fri, 16 Oct 2009, Junio C Hamano wrote:
>
>> Julian Phillips <julian@xxxxxxxxxxxxxxxxx> writes:
>> ...
>>> I don't care what git has to do, I'm talking about the user experience
>>
>> But Bj?rn is showing two commands the _user_ has to type, iow, the comment
>> is about the user experience.
>
> Only Currently. My point was that _if_ we wanted to support this sort
> of thing, then we can make is simpler to do by providing a simple
> command for the user.
>
> The point I wanted to make was that the decision on what to do should
> be driven by the user's experience - not by the fact that it is easier
> to implement something else.
Sorry, but I do not see in what way what you said in the thread connects
to the above three lines. Are you talking about this one from you a few
messages back?
How about:
$ git checkout origin/master
$ git fetch
Refusing to fetch, as it would update a checkedout branch
"git fetch -f" will force the update, but you will need to run "git
reset --hard HEAD" to update your checkout to match.
I am not seeing "not the implementation ease but the user experience"
drive in this suggestion. If you are driving from the user experience
point of view, I would have instead suggested:
How about:
$ git checkout origin/master
$ git fetch
and fetch happily updates the tracked branch, without affecting the
HEAD state (nor index nor the work tree, of course).
User experience here is:
* Let's checkout what the upstream has on the master. I am at least
aware that git is distributed and does not go to the network unless
I tell it to, and am aware that origin/master is the state of the
upsream _when I told git to look at it the last time_. So I'll get
the state I talked with the upstream the last time, and that is what
I want to look at.
* Hmm, there may be even more updates since I talked with the upstream
the last time. Let's tell git to fetch. I already know that this
updates origin/master to a more recent state.
Isn't it much cleaner and less confusing? And with these kind of
awareness, the user can choose to do various things from here, e.g.:
* Oh, fetch did fetched something. I want the updated state. Let's
check it out with "git checkout origin/master"; or
* Ok, what changed since I last talked with the upstream? I have one
end of the state already checked out, and I updated origin/master
with their latest, so I can say "git diff HEAD origin/master".
Notice in the latter the user can be a neophyte who hasn't learned reflogs
yet.
> My interest in this thread is solely that it might provide a mechanism
> to find out which tag was checked out.
Hmm, what is lacking in "git describe HEAD" for that? I am not
complaining that you might be asking for something that exists, but I _do_
want to know if something that exists is not a satisfactory solution and
if so how it can be improved.
--
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