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

[Nicolas Pitre <nico@cam.org>]

On Wed, 25 Apr 2007, Carl Worth wrote:

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

With all the safeties (reflogs, etc) this warning could be toned down 
even more now.

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

I don't feel comfortable with that.

To me it looks like Git would perform some hardcoded magic without 
helping the user understanding what is going on.  Worse: it can perform 
all those operations even if that is not what you wanted.

I much prefer multiple simple commands that perform basic and 
understandable operations than a single complex one with more magic in 
it.  If it was just me I'd eliminate the pull command and a pull would 
always be a fetch followed by a merge...

I understand your desire for people to get at your code as quickly and 
easy as possible, but that conflicts with our desire for people to 
really understand the basics of Git.  Creating magic commands with 
hardcoded defaults for a one-click-does-all behavior isn't helping 
that understanding at all.

If you really want people to get at your code with no Git consideration 
what so ever, then just direct them at the corresponding gitweb and/or 
git-archive invocations with --remote=<repo> to store a local copy.

> 	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.)

And why again isn't detached head just fine for your usage scenario 
instead? Only the "obnoxious" warning?


Nicolas