Re: If I were redoing git from scratch...

From: Jakub Narebski <jnareb@gmail.com>
Date: Nov 4, 2006, 12:21 UTC
Message-ID: <eii0kg$1co$1@sea.gmane.org>
In-Reply-To: <7vpsc3xx65.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano wrote:

> * Core data structure

[...]

Show 5 quoted lines

> The biggest one is that we use too many static (worse, function
> scope static) variables that live for the life of the process,
> which makes many things very nice and easy ("run-once and let
> exit clean up the mess" mentality), but because of this it
> becomes awkward to do certain things.  Examples are:

One of examples that have been only rarely fixed was for_each_ref forcing callers to using static variable to store gathered data instead of passing the data as one of arguments.

Show 10 quoted lines

> * Fetch/Push/Pull/Merge confusion
> 
> Everybody hates the fact that inverse of push is fetch not pull,
> and merge is not a usual Porcelain (while it _is_ usable as a
> regular UI command, it was originally done as a lower layer
> helper to "pull" Porcelain and has a strange parameter order
> with seemingly useless HEAD parameter in the middle).
> 
> If I were doing git from scratch, I would probably avoid any of
> the above words that have loaded meanings from other SCMs.

I'm a bit used to "push", "fetch" and "pull". I consider "pull" a bit of artifact from times of one branch per repository layout. The fact that "pull" fetches _all_ the branches but merges one [usually] with the _current_ branch (unless you configure it other way)...

I'll leave "push" as is, leave "fetch" as is, and make "pull" to be "fetch" by default unless you use "--merge[=<branch>]" option. I'd rename "merge" to "merge-driver" and make new "merge" thanks to new users wouldn't have to learn to use "git pull . branchA" to merge current branch with branchA.

Perhaps would make it possible to specify remote branch a la cogito, <URL>#<branch>, to pull remote branch without tracking branch, and for symmetry have "--pull[=<repo>]" or "--fetch[=<repo>]" option.

> * Unified "fetch" and "push" across backends.
>

Very nice idea, but one must remember the limitations of import/export tools and of course limitations of other SCM... well, and also limitations of Git, if there are any compared to other SCM ;-)

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git