On Fri, 16 Oct 2009, Junio C Hamano wrote:
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).
True. I was saying that having git stop and explain things is better than
making a mess for the user to clear up. Having it just work would of
course be even better. Hoist by my own petard indead ...
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.
What is lacking is the "checked out" part. "git describe HEAD" will tell
me _a_ tag that matches the currently checked out state. However, it
makes no guarantee that it was the one I checked out. If I tag the code
with "v1.0.0", and a colleague later tags it with "this_version_sucks",
then when I check out and build the code for the customer the version it
reports could well be "this_version_sucks" instead of "v1.0.0" ...
Nicolas Pitre suggested using the reflog, which does seem to include the
information that I want, but I feel a little uneasy about accessing it via
a script - how certain is it that the format of the message won't change?
Is accessing the reflog the sort of thing people expect as part of the
scripting interface?
--
Julian
---
Those who would repeat the past must control the teaching of history.
-- Bene Gesserit Coda
--
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