git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Carlos Rica <jasampler@gmail.com>
Cc: git@vger.kernel.org, Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: On writing builtin-reset.c, a question about git-reset.sh
Date: Sun, 19 Aug 2007 17:24:52 -0700	[thread overview]
Message-ID: <7vir7b9hnv.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <46C8D604.4090203@gmail.com> (Carlos Rica's message of "Mon, 20 Aug 2007 01:45:08 +0200")

Carlos Rica <jasampler@gmail.com> writes:

> Hi, I'm writing builtin-reset.c and
> I'm really stuck with a little code in
> git-reset.sh:
>
> if orig=$(git rev-parse --verify HEAD 2>/dev/null)
> then
> 	echo "$orig" >"$GIT_DIR/ORIG_HEAD"
> else
> 	rm -f "$GIT_DIR/ORIG_HEAD"
> fi
>
> My question is about when this condition
> could fail (and then the rm executed),...

When orig does not exist.  That is, when HEAD is a symref that
point at an unborn branch (e.g. between "git init" and your
first "git commit").  After "git reset" of any kind, we would
want to make sure that GIT_DIR/ORIG_HEAD points at the commit
you were previously at, and if orig is not there we do not want
anything in that file.

Another possibility would be if somebody wants to add an
unrelated branch to the repository [*1*].  This is against
recommended practice, but you could make your HEAD point at an
unborn branch using plumbing commands, or even by hand:

	$ echo 'ref: refs/heads/unrelated' >.git/HEAD

Your next commit will make a root commit that is pointed by
'refs/heads/unrelated' ref, but before that happens, we would
not want to have GIT_DIR/ORIG_HEAD if you did git-reset.

Now, you might wonder if "git reset" makes any sense from such a
state, and actually it does ;-)

	$ git init
        $ git remote add -f friend ../neighbour.git/
        $ git reset --hard friend/master

[Footnote]

*1* People often seem to want to do something like the html, man, and
todo branches in my public repository that do not share any history
with the primary development branches.  Perhaps they think it is cool
to do so, but it is not.  These independent branches originate from
different repositories, and are published in the same repository only
for easier distribution.  There is no reason for you (nor me) to
create such unrelated branches in a single originating repository.

A recommended procedure to publish independent branches in a single
repository is to push into one from separate, independent
repositories.  Starting an independent history in an existing
repository, like the main body of this message shows you how, is not
recommended.

      reply	other threads:[~2007-08-20  0:25 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-19 23:45 On writing builtin-reset.c, a question about git-reset.sh Carlos Rica
2007-08-20  0:24 ` Junio C Hamano [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vir7b9hnv.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=jasampler@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).