Re: master^ is not a local branch -- huh?!?

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

 



In article <alpine.LFD.2.00.1002012253260.1681@xxxxxxxxxxx>,
 Nicolas Pitre <nico@xxxxxxxxxxx> wrote:

> On Mon, 1 Feb 2010, Ron Garret wrote:
> 
> > In article <20100202001530.GL9553@xxxxxxxxxxxxx>,
> >  Petr Baudis <pasky@xxxxxxx> wrote:
> > 
> > > On Mon, Feb 01, 2010 at 03:56:31PM -0800, Ron Garret wrote:
> > > > In article <7vwrywplxz.fsf@xxxxxxxxxxxxxxxxxxxxxxxx>,
> > > >  Junio C Hamano <gitster@xxxxxxxxx> wrote:
> > > > > Ron Garret <ron1@xxxxxxxxxxx> writes:
> > > > > > And as long as I'm weighing in, it would also help to prevent 
> > > > > > confusion 
> > > > > > if it were made clear that this unnamed branch doesn't actually 
> > > > > > come 
> > > > > > into existence unless and until you do a commit.
> > > > > 
> > > > > This shows that you are still thinking a branch is a line (or 
> > > > > multiple
> > > > > lines).  It is not.
> > > > 
> > > > The git user's guide says it is:
> > > > 
> > > > "When we need to be precise, we will use the word "branch" to mean a 
> > > > line of development..."
> > > > 
> > > > But I understand that a branch is not necessarily a line.  In general 
> > > > it's a DAG.  I get that.
> > > 
> > > Again, no. In the most narrow sense, "branch == branch head".
> > 
> > The manual specifically contradicts you, so either you are wrong or the 
> > manual is wrong.
> 
> In that case it's most probably the manual which is wrong.

OK.  That happens.

> > Don't forget that what is at issue here is not how git works (I'm pretty 
> > sure everyone is on the same page about that) but how to explain it to 
> > someone who is not already familiar with it.  So it's important to use 
> > terminology that is consistent with what the manual says.
> 
> Or rather that the manual has to be debugged and be brought in sync with 
> reality.

Sure.  I'm agnostic about how this synchronization happens.  But I think 
it's important that it happen, otherwise a lot of people will remain 
confused, and that would be a shame.

> All the people who had their hands dirty with the code usually 
> hang here, and what they say has precedence with whatever is in the 
> manual.

Yes, but what they say still ought to pass some basic tests of utility.  
For example, a definition of "branch" that makes it effectively 
synonymous with "commit" is probably not useful.

> It is good of course that you bring those issues to our attention.  but 
> it is more likely that the manual needs fixing than anything else.

That's fine.  My only aim here is to raise the issue.

By the way, if you (plural) think it would be helpful I'd be happy to 
take a stab at rewriting this part of the manual.  Writing docs is a 
drag, but it would probably be a useful exercise for me.

rg

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