Re: Making git disappear when talking about my code (was: Re: GIT vs Other: Need argument)

On Wed, 25 Apr 2007 07:55:49 -0700 (PDT), Linus Torvalds wrote:

Alternatively, we *could* make just

	git checkout --track branch

be a shorthand for

	git checkout --track -b branch origin/branch

when "branch" doesn't exist, but origin/branch does. With the "--track",
it's already unambiguous (you cannot track a detached head, so we know we
want a branch.

I like that a lot, thanks! Things that make the command-line simpler
with no loss in functionality nor introducing any ambiguity are really
nice.

And I'd even follow that up to propose making "git checkout branch"
(where branch doesn't exist but remote/<something>/branch does), do
something new, (not detached head, nor creating a local tracking
branch), that would allow the following:

1. Using "git checkout branch" to examine the working-tree status of a
   branch.

	This functionality exists already, but with a fairly obnoxious
	detached head warning.

2. Subsequently using "git pull" to track that remote branch

	This functionality is currently missing without creating a
	local branch first. This is an inconvenience compared to the
	pre-separate-remotes git where "git checkout next" followed by
	a sequence of "git pull" was enough to track a branch.

	Now, old git also had the huge defect that it was too easy to
	screw everything up by committing to what should have been
	treated as a read-only tracking branch, which is where the
	next point comes in.

3. Allow a commit from this state, by *then* creating the explicit
   local branch setup to track the remote-tracking branch.

	That is, under this proposal the command sequence of:

		git checkout branch
		# hack
		git commit

	Would get one to the exact same state as today's sequence of:

		git branch --track branch origin/branch
		git checkout branch
		# hack
		git commit

	Which to me just looks like making git easier to use.

	Of course, git could complain politely if the branch name it
	wanted to create were taken already and instruct the user how
	to create a new name for the tracking branch before the
	commit.

Is that a totally insane idea? (The answer might very well depend on
some details of the implementation---presumably .git/HEAD would have
to store both the name of the remote-tracking branch as well as the
sha1 to which it corresponded at the time of the checkout.)

-Carl