From: Jakub Narebski <jnareb@gmail.com>
To: git@vger.kernel.org
Subject: Re: If I were redoing git from scratch...
Date: Sat, 04 Nov 2006 13:21:57 +0100 [thread overview]
Message-ID: <eii0kg$1co$1@sea.gmane.org> (raw)
In-Reply-To: 7vpsc3xx65.fsf@assigned-by-dhcp.cox.net
Junio C Hamano wrote:
> * Core data structure
[...]
> 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.
> * 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
next prev parent reply other threads:[~2006-11-04 12:22 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-04 11:34 If I were redoing git from scratch Junio C Hamano
2006-11-04 12:21 ` Jakub Narebski [this message]
2006-11-04 16:44 ` Linus Torvalds
2006-11-04 19:16 ` Shawn Pearce
2006-11-04 22:29 ` Robin Rosenberg
2006-11-04 22:44 ` Linus Torvalds
2006-11-04 23:15 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='eii0kg$1co$1@sea.gmane.org' \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).