git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Haggerty <mhagger@alum.mit.edu>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: Bug: "git checkout -b" should be allowed in empty repo
Date: Tue, 31 Jan 2012 09:57:17 +0100	[thread overview]
Message-ID: <4F27ACED.2050709@alum.mit.edu> (raw)
In-Reply-To: <7v39axc9gp.fsf@alter.siamese.dyndns.org>

On 01/30/2012 07:48 PM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
>> [3] If commit 0000000 were treated specially, then there would be no
>> unborn branches but only branches pointing at the empty commit.  In that
>> case, my expectation would change--the old branch should be left
>> pointing at 0000000.  But currently git has no concept of an unborn
>> branch that is not HEAD.
> 
> And it probably is not a good thing to add such. Under that constraints,
> HEAD that says refs/heads/foo where foo does not exist yet needs to be
> special cased at places where it matters.
> 
> For that matter, even if we artificially created refs/heads/foo before any
> commit is made and made it point at 0{40}, you would need to add special
> cases to other parts of the system

No, the idea is to avoid special casing by making 0{40} into a real (but
empty) revision.

> (e.g. "commit" needs to notice that the
> result should be a root, not a child of 0{40};

No, commits that were previously generated as orphans *would* now be
generated as children of the special 0{40} commit.

> "checkout other_branch"
> needs to notice that it should refrain from running the equivalent of
> "read-tree -m HEAD other_branch" because HEAD does not point at a real
> tree;

No, it would merge the 0{40} commit with other_branch like usual,
resulting in the same contents as other_branch.  Indeed, if other_branch
is also ultimately a descendant of 0{40}, this would be like a
fast-forward merge.

> etc.

This "etc" might include problems.

> so it does not change the fact that the unborn branch is case
> is special.

On the contrary, I believe that much special casing could be eliminated
and the UI made more uniform by treating everything as a descendant of a
special "NULL" commit.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

  parent reply	other threads:[~2012-01-31  8:57 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-29  6:09 Bug: "git checkout -b" should be allowed in empty repo Michael Haggerty
2012-01-29  6:56 ` Junio C Hamano
2012-01-29  7:50   ` Junio C Hamano
2012-01-30  6:38   ` Michael Haggerty
2012-01-30 18:48     ` Junio C Hamano
2012-01-30 20:10       ` Junio C Hamano
2012-01-30 21:50         ` Jeff King
2012-02-06  2:06           ` Junio C Hamano
2012-02-06  2:08             ` Junio C Hamano
2012-02-06  4:30             ` Jeff King
2012-02-06  4:42               ` Andrew Ardill
2012-02-06  5:06                 ` Jeff King
2012-02-06  8:51                   ` Michael Haggerty
2012-02-06  8:57                     ` Jeff King
2012-02-06 18:17                       ` Junio C Hamano
2012-02-06 20:14                         ` Jeff King
2012-02-07  8:04                         ` Michael Haggerty
2012-02-06 18:39                 ` demerphq
2012-02-06  5:15               ` Junio C Hamano
2012-02-06  5:18                 ` Jeff King
2012-02-06  5:30                   ` Junio C Hamano
2012-02-06  5:34                     ` Junio C Hamano
2012-02-06  5:45                     ` Jeff King
2012-02-06  8:59                     ` Michael Haggerty
2012-02-06 18:31                       ` Junio C Hamano
2012-01-30 21:48       ` Jeff King
2012-02-06  1:26         ` [PATCH] branch --edit-description: protect against mistyped branch name Junio C Hamano
2012-02-06  1:27           ` Junio C Hamano
2012-02-06  4:20           ` Jeff King
2012-01-31  8:57       ` Michael Haggerty [this message]
2012-01-31 10:01         ` Bug: "git checkout -b" should be allowed in empty repo Johannes Sixt
2012-01-31 10:11           ` demerphq
2012-01-31 10:09         ` Jakub Narebski
2012-01-31 16:32           ` Michael Haggerty

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=4F27ACED.2050709@alum.mit.edu \
    --to=mhagger@alum.mit.edu \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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).