Re: [DRAFT] Branching and merging with git

From: J. Bruce Fields <bfields@fieldses.org>
Date: Jan 8, 2007, 02:35 UTC
Message-ID: <20070108023511.GI18009@fieldses.org>
In-Reply-To: <7vzm8uz7pz.fsf@assigned-by-dhcp.cox.net>

On Sun, Jan 07, 2007 at 04:24:08PM -0800, Junio C Hamano wrote:

Show 7 quoted lines

> "J. Bruce Fields" <bfields@fieldses.org> writes:
> In other words, I think we have enough information in the
> tutorial documents, but the problem is not the lack of
> information -- the problem is the lack of organization.
> 
> I think this effort of yours is wonderful because it directly
> tackles that problem.

OK, thanks for the vote of confidence.... My tentative organization (which I'm totally open to argument about) is:

chapters 1 and 2: "Read-only" operations:

	clone, fetch, the commit DAG, etc.; material that could be
	useful to a linux kernel tester, for example.  This also
	includes lots of stuff about branch manipulation and fetching,
	just because that's necessary to keep a repo up to date and
	check out random commits.  Once we have "git remote" and
	disconnected checkouts most of this could be postponed till
	later.

Chapter 3: "Read-write" operations:

	Read-write stuff: creating commits (basic mention of index),
	handling merges, git-gc, ending with distributed stuff:
	importing and exporting patches, pull and push, etc.

Chapter 4 (unwritten): interactions with other VCS's

	cvs, subversion.  Also some of us use track projects with git
	even when all we've got is a sequence of release tarballs to
	track, and that might be worth documenting.

Chapter 5 (unwritten): rewriting history

	rebasing, cherry-picking, managing patch series, etc.

Chapter 6 (unwritten): git internals

	I intend to just do a wholesale import of either tutorial-2.txt,
	core-tutorial.txt, or the README, or some combination thereof,
	but can't decide which.

--b.