Re: 'HEAD' is not a commit (according to git-checkout)

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

 



On Wed, May 27, 2020 at 11:52:28AM -0400, Randall S. Becker wrote:

> On May 27, 2020 11:44 AM, Junio C Hamano wrote:
> > Jeff King <peff@xxxxxxxx> writes:
> > 
> > > On Sun, May 24, 2020 at 09:15:33AM -0700, Junio C Hamano wrote:
> > >
> > >> So, should we allow a random upstream & start-point combination?  It
> > >> appears to me that as long as they share _some_ common ancestory, it
> > >> may make sense.
> > >
> > > But wouldn't just about any two tips in a repository share some common
> > > ancestry?
> > 
> > Yes, we are on the same page; the above was my round-about way to say
> > that it does not look useful to restrict the allowed combination in order to
> > give us some safety.
> 
> I have seen some strange ones, as part of migrating from other SCM
> solutions to git, where there were two completely unrelated histories
> - at least temporarily until stitched together towards the end of the
> migration. I don't think the assumption about common ancestry holds
> generally. I might have misunderstood, though.

No, I don't think you've misunderstood. It does happen, and there's even
an example in git.git. Doing:

  git checkout -b new-branch --track=origin/todo origin/master

would be nonsense. But it's a rare enough case that I don't think it's
worth worrying too much about. Plus it's pretty easy to undo, or at
least no harder than lots of other mistakes (e.g., trying to rebase on
the wrong branch).

-Peff



[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]

  Powered by Linux