Re: [PATCH 4/5] status: show the ref that is checked out, even if it's detached

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> When a remote ref or a tag is checked out, HEAD is automatically
> detached. There is no user friendly way to find out what ref is
> checked out in this case. This patch digs in reflog for this
> information and shows "Detached from origin/master" or "Detached from
> v1.8.0" instead of "Currently not on any branch".

"Detached from" is a nice attempt to compromise in the phrasing.

We usually say you detach HEAD at v1.8.0, but what is shown is what
started from such a state but then the user may have built more
history on top of it and may no longer be at v1.8.0, so obviously we
do not want to say "Detached at".  We are in a "detached at v1.8.0
and then possibly built one or more commits on top" state (would it
be helpful to differentiate the "nothing built on top" and "some
commits have been built on top" cases, I wonder).

Also I wonder if you could do a bit more to help the users who do:

    $ git checkout $(git merge-base HEAD nd/branch-show-rebase-bisect-state)

aka

    $ git checkout ...nd/branch-show-rebase-bisect-state

and then do one or more commits on top.

Instead of punting to "Currently not on any branch", would it help
to show the place you first detached at, so that the user can then
grab that commit object name and run

    $ git log --oneline $that_commit..

or something?

> +static int grab_1st_switch(unsigned char *osha1, unsigned char *nsha1,
> +			   const char *email, unsigned long timestamp, int tz,
> +			   const char *message, void *cb_data)
> +{
> +	struct grab_1st_switch_cbdata *cb = cb_data;
> +	const char *target = NULL;
> +
> +	if (prefixcmp(message, "checkout: moving from "))
> +		return 0;
> +	message += strlen("checkout: moving from ");
> +	target = strstr(message, " to ");
> +	if (!target)
> +		return 0;
> +	target += strlen(" to ");
> +	strbuf_reset(&cb->buf);
> +	hashcpy(cb->sha1, nsha1);
> +	if (!prefixcmp(target, "refs/")) {
> +		const char *end = target;
> +		while (*end && *end != '\n')
> +			end++;
> +		strbuf_add(&cb->buf, target, end - target);
> +	}
> +	return 0;
> +}

Can't this be done by generalizing grab_nth_branch_switch() and then
exposing it as part of the general API?  

I also feel uneasy about two issues this and the previous change
introduces:

 1) It is somewhat unnerving that this step reads what comes after
    "to", while nth_branch_switch() reads what comes between "from"
    and "to", but it probably cannot be avoided because this series
    wants to know what we switched "to" earlier, while "checkout -"
    wants to know what we switched "from"

 2) The previous one records this sequence in a funny way:

        : start from branch A
        git checkout B
        git checkout C

    The resulting reflog entries result in

        checkout: moving from A to refs/heads/B
        checkout: moving from B to refs/heads/C

    even though existing code and tools are expecting to read

        checkout: moving from A to B
        checkout: moving from B to C

By the way, even though the title of this patch is "status: show the
ref that is checked out, even if it's detached", a quick check with

        $ cd ../linux-3.0
        $ git describe
        v3.8-rc7
        $ ../git.git/git-checkout v3.8-rc7
        $ tail -n 1 .git/logs/HEAD | sed -e 's/.*checkout/checkout/'
        checkout: moving from master to refs/tags/v3.8-rc7
        $ ../git.git/git-status | head -n 1
        # Not currently on any branch.
        $ ../git.git/git-branch -v
        * (no branch) 836dc9e Linux 3.8-rc7
          master      836dc9e Linux 3.8-rc7

does not seem to give me anything more helpful.
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]