Re: merging initial part of a branch?

"J. Bruce Fields" [off-list ref] writes:

That's the only reference I can find to the "tag <tag>" notation, and
it's a bit unhelpful as written.  (What backward compatibility?)

How about the following?--b.

Makes sense.  Thanks.

Backward compatibility is that it was only either "<branch>" or
"tag <tag>".  When heads/branch or tags/tag came later,
supporting the separate word form "tag <tag>" was a bit
cumbersome but was done for b/c.

On Thu, Jan 12, 2006 at 08:00:06PM -0800, Junio C Hamano wrote:

Backward compatibility is that it was only either "<branch>" or
"tag <tag>".  When heads/branch or tags/tag came later,
supporting the separate word form "tag <tag>" was a bit
cumbersome but was done for b/c.

Thanks for the explanation, makes sense.

I might try to put together some more extensive documentation patches
over the next couple weeks if you're willing to take them.  Plain git
actually seems to have pretty usable interfaces at this point, but it's
not always obvious where to find them....

I also have Yet Another Git Tutorial, at
http://www.fieldses.org/~bfields/kernel/git.html.  (Corrections and
suggestions welcomed.)

--b.

"J. Bruce Fields" [off-list ref] writes:

....  Plain git
actually seems to have pretty usable interfaces at this point, but it's
not always obvious where to find them....

I share that feeling too, especially in the documentation area.

Last time we had something very nice going on in this thread:

    http://thread.gmane.org/gmane.comp.version-control.git/12917

whose the key article is:

    http://article.gmane.org/gmane.comp.version-control.git/13360

but the general sentiment was that having another document is
making things more confusing and we should try to clarify the
main documentation instead. Pasky said aptly:

    http://article.gmane.org/gmane.comp.version-control.git/13410

I am not much of a documentation person myself, and I do not
have much interaction with people new to git, without which it
is hard to know which point is harder to grasp and what
documentation pages assume certain things are known to an
uninitiated when they should not.

So I would really appreciate documentaiotn patches to clarify
the current mess ;-).

I also have Yet Another Git Tutorial, at
http://www.fieldses.org/~bfields/kernel/git.html.  (Corrections and
suggestions welcomed.)

The $prefix defaults to $HOME/bin/.  Having $bindir on $PATH
ought to be enough and exporting GIT_EXEC_PATH is not needd.

Other than that I did not see anything obviously wrong, although
I suspect you did not intend to say clone with stgit.

On Fri, Jan 13, 2006 at 11:50:44AM -0800, Junio C Hamano wrote:

"J. Bruce Fields" [off-list ref] writes:
but the general sentiment was that having another document is
making things more confusing and we should try to clarify the
main documentation instead.

Understood.  We may need to add documentation here and there, but that
needs to be done alongside clarifying the existing text and
organization, and without creating unnecessary duplication.

So I would really appreciate documentaiotn patches to clarify
the current mess ;-).

OK.  I'll see if I can up with something useful!

quoted

I also have Yet Another Git Tutorial, at
http://www.fieldses.org/~bfields/kernel/git.html.  (Corrections and
suggestions welcomed.)

The $prefix defaults to $HOME/bin/.  Having $bindir on $PATH
ought to be enough and exporting GIT_EXEC_PATH is not needd.

Other than that I did not see anything obviously wrong, although
I suspect you did not intend to say clone with stgit.

Whoops, right.  Thanks for the corrections; I've applied all three.

--b.