As has been discussed recently, update-index isn't intended as a

"porcelain" command so the mention of it in the output of git-commit

does lead to some user confusion.

---

 wt-status.c |    2 +-

 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/wt-status.c b/wt-status.c

index 7dd6857..4edabcd 100644

--- a/wt-status.c

+++ b/wt-status.c

@@ -126,7 +126,7 @@ static void wt_status_print_changed_cb(s

 	int i;

 	if (q->nr)

 		wt_status_print_header("Changed but not updated",

-				"use git-update-index to mark for commit");

+				"use \"git commit <files>\" to commit or \"git commit -a\" for all");

 	for (i = 0; i < q->nr; i++)

 		wt_status_print_filepair(WT_STATUS_CHANGED, q->queue[i]);

 	if (q->nr)

--

1.4.3.3.gf040

Are we sure this isn't porcelain-ish?  We need to use it in merge

conflict correction and the like?  You can't use git-commit there as a

replacement.  I'd expect it to be 'git update-index' rather than

'git-update-index' of course.
-apw

-

I think status should be taken as Porcelain-ish so it should

notice more about the environment to see why the user has

changed but not updated files and recommend the possible action

depending on the context.
For that, you would need to enumerate what kind of 'context'

there could be with the current set of tools.  Here is a

strawman.
 1. None of the below.

 2. A merge was attempted and resulted in a conflict.

 3. An am or rebase without --merge was attempted and

    resulted in a conflict or patch rejection.

 4. A "rebase --merge was attempted and resulted in a conflict.
In the normal case, the next user action would be:
 1-1. The user wants that change in the next commit, and should

      run "git update-index $that_path" to prepare the index for

      partial commit, or "git commit -a" to commit all the

      changes made to the working tree so far.  Carl's patch

      helps the user in this case.
 1-2. The user realizes that the some of the changes in the

      working tree were not desirable, and "git checkout --

      $that_path" to revert them before continuing.  Before

      deciding to revert, the user may want to check what the

      difference is by running "git diff -- $that_path" so

      suggesting these two might also be helpful.
 1-3. The user wants to keep that change a strictly local change

      in the working tree (this is often very useful and making

      "commit -a" the default will not be acceptable unless

      there is a very compelling reason to do so).  This means

      the suggestion we would make should clearly be

      _suggestion_.
The earlier wording was bad in that it suggested to use a

Plumbing command update-index, but was attempting to convey that

it was merely a conditional suggestion by saying "use it TO MARK

FOR COMMIT", implying that if the user does not want to mark

them for commit, it is Ok not to use update-index.
When a merge is in progress, we would have .git/MERGE_HEAD and

that would be the way to tell case 2.  In...
[ message continues ]

It was Junio that recently said update-index is plumbing, not

porcelain.
So, the fact that conflict resolution still requires the use of

update-index would just be the next thing to fix. A name for a

replacement to use there could be "git resolve <paths>", (since the

old git-resolve is now officially deprecated). That's a name that

matches what hg uses in this situation, (another option is "resolved"

which is what stg uses, but I think verbs for commands work better in

general).
It would be really nice if none of the "common" commands had a hyphen

in them, for example.
And then, the next phase of my evil plan would be to introduce a -i

option for git-commit making it commit the state in the index. Then

git-commit with no options could work like "git-commit -a" does now,

(with the additional protection of not committing any unmerged

files---that is the new "git resolve" would be required before "git

commit" would work after a conflict). Users who really, really like

the current behavior of git-commit could use the new alias support to

pass the new -i option in order to maintain compatible behavior.
Then, the last thing I'd really like to fix is to allow a usage of

"git merge <branch>" instead of the awkward "git pull . <branch>".
With that, most of the user-interface warts that I regularly run into

with git would be solved. Oh, except it would also be nice to

eliminate the "plumbing" commands in a couple of places:
 1) From the "man git" man page
 2) From git-<TAB>, (maybe the solution for this is to make

    "git <TAB>" work and only do tab-completion for the commands

    blessed enough to appear in "git --help"? Also push the tab

    completion stuff out as a standard part of packages.
Anyway, now I've just gone and blown all my secret plans for changing

git in ways to make it less intimidating for new users.
For reference, the latest potential batch of new users that I'm

dealing with is the set of Fedora package maintainers who ar...
[ message continues ]

I just cannot do otherwise than cheer this with applause.
Even if I have a clear preference for GIT's _technology_, I still think

that the HG user interface is more convivial.  I even been thinking

about writing something like an hg-like frontend to GIT from time to

time just so that GIT could then be better compared to (and actually

just used like) HG.
I still think that the GIT user interface sucks in many ways.  The

confusion between pull, fetch and push is still my favorite, along with

the locale vs remote branch issue.  Maybe we'll better handle the branch

issue eventually, but it would be so much intuitive to split branch

merging out of git-pull, and make git-pull be the same as git-fetch

(maybe deprecating git-fetch in the process) so push and pull are really

_only_ opposite of each other.
If the fetch+merge behavior (which I think should really be refered as

pull+merge) is still desirable, then it should be called git-update and

be no more than a single shell script line such as
	git_pull && git_merge"
This is really what most people expect from such a command name based

on obvious historical reasons.  The lack of any branch argument to

git-pull and git-merge could be defined as using the first defined

remote branch by default.  But having git-pull performing merges is IMHO

overloading the word and goes against most people's expectations.
Nicolas

-

I've actually been tempted to do the same myself. I really think that

the technology is a more important criterion than the UI so the

imagined hg-on-git interface would be an attempt to get people to look

past the interface differences and look at the technology when

deciding.
But, then, I'd be guilty of creating another cogito, and I just argued

against its existence in a separate thread. So I think we're better
The --use-separate-remotes thing is technology in the right direction

here. But I think it's another example of very useful stuff being

improperly hidden behind another command-line option. Getting rid of

the "remote-tracking branches" as user-visible branches possible for

committing should be a priority. And that should be the default for

everyone, not just people who happen to clone with this obscure

option.
Similarly, the reflog stuff was often trumpeted in the recent git

vs. bzr debate. Why is that very useful functionality buried in a
Once again, there's lots of useful work on "branch configuration" that

allows for commands to be able to get the "right" default repository

for push and pull. I hope that that stuff can be enabled by default

and not require --use-separate-remotes or manual configuration for

people to benefit from it.
I apologize if I sound like I'm ranting here. I love to see the many

good improvements being made to git. It's just that there seems to be

a sort of shyness about new features, (perhaps a fear of changing

existing behavior?). When it improves the user experience, let's make

the improvement the default and not add any more
	--make-this-command-do-what-it-really-should-have-always-done
options.
-Carl

I've actually been tempted to do that too, and my earlier "if I

were to redo git from scratch" message was the beginning of it

to summarize my preference about some of the issues raised in

this thread.
Commenting on the messages in this thread:
 - "resolve / resolved" are both confusing, when you are talking

   about "mark-resolved" operation.
 - "pull/push/fetch" have undesired confusion depending on where

   people learned the term.  I'd perhaps vote for replacing

   fetch with download and push with upload.
 - I think it would be sensible to make remote tracking branches

   less visible.  For example:
	git diff origin
   where origin is the shorthand for your upstream (e.g. you

   have .git/remotes/origin that records the URL and the branch

   you are tracking) should be easier to understand than
   	git diff remotes/origin/HEAD
   The latter is an implementation detail.  I could imagine we

   might even want to allow
	git diff origin#next
   to name the branch of the remote repository.  The notion of

   "where the tips of remote repository's branches are" is

   probably be updated by "git download" (in other words, the

   above "git diff" does not automatically initiate network

   transfer).
 - "git merge" to merge another branch into the current would

   make sense.  "git pull . remotes/origin/next" is showing too

   much implementation detail.  It should just be:
	git merge origin#next
And I agree with Pasky that fixing UI is hard unless you are

willing to get rid of historical warts.  Syntax of the command

line arguments the current set of Porcelain-ish takes are

sometimes just horrible.  It may not be a bad idea to start

building the fixed UI from scratch, using different prefix than

"git" (say "gu" that stands for "git UI" or "gh" that stands for

"git for humans").
Of course, it could even be "cg" ;-).
-

On Tuesday 14 November 2006 22:36, Junio C Hamano wrote:
I have been away on business last week and have been following this thread

from the archives.  There is a comment I want to make about split of

Porcelain and Plumbing namespaces that is not particularly an answer to this

particular post, but it does seem an appropriate place to insert it.
I think there were three (historic) mistakes in the development of git

	- to split git and cogito so that some of the commands started git and some

cg (aided and abetted by putting them in separate repositories).

	- to try and make the distinction between plumbing and porcelein a line in

the sand (after all this is exactly why git and cg separated) when in

practice it isn't that straight forward

	- for cogito to (initially) not support the internal branches, but in fact

deal with them via cloned repositories
On the other hand, it was a good move to bring gitk and gitweb into the core

repository.
These were not technical mistakes, but social ones.
Much of the discussion on UI warts doesn't exist in the cogito world (not that

I use it at all anymore, despite its more user friendly interface - just

because I didn't want to learn two parallel sets of commands and I prefered

git's branch model so stuck with the slightly less friendly git command set)

but if you look at any of the SCM comparison discussions that happen now,

they are always comparing the core git with the other SCM, not git plus all

its porcelains.
So I think it would be a mistake (which hopefully does seem to be the

concensus reached in the list) to try and introduce new namespaces to the

command set.

--

Alan Chandler

http://www.chandlerfamily.org.uk

-

Well that's what "resolved" is saying. But speaking of which, it took me

_weeks_ of regular (though not extensive) usage to train my fingers to
It's too long. :-(
I think if some people have a real problem with something it's "pull",

not push or fetch. Without "pull" name, there's no confusion about

merging or not merging; and without it, there's also no confusion about

"push" and the fetch/push duality. I'm not saying that this is enough an
Hmm, wait. I didn't start using refs/remotes/ yet for obvious reasons,

but wasn't it generally agreed when implementing them that what you

wrote above would work? (That a ref not found in refs/{heads,tags}/ is

looked up in remotes and if it's a directory, /HEAD is appended.) So it
So, here is an arbitrary list of random reasons why cg commands are not

part of git yet:
(i) Naming issues. Example: "pull" vs. "update".
(ii) Namespace issues. Big selling point of Cogito is that it's

_simple_. A very important part of that is that your command set is

limited, so that even someone who wants to fully grok Cogito is not

overwhelmed and has just few commands in front of him. I think we're

doing pretty good here, and I very carefully weight adding another

command to the set (I'm actually pondering removing some now). The

similar applies to actual commands' usage, though certainly not so

heavily; and there are few warts here.
But overally, I think this point is pretty much unsolvable and this is

where I actually think the main "incompatibleness" of Cogito and Git

with its free mix of high- and mid- and low- level commands lies. I

don't think the thread provided any solution to this either.
(ii) Behaviour issues. Example: Cogito tries to deal with uncommitted

local changes in your repository when doing stuff. It didn't shine at it

before recent improvements (post-v0.18), but it tried to preserve your

local uncommitted changes during various operations (merging,

fast-forwarding, switching branches, seeking, ...). I think historically

Git'...
[ message continues ]

(on a tangent)
I concur, but probably in a different way.
some 10 years ago I vowed never to write perl code again, and some 5

years ago, I made the same pledge for shell scripts, because I spent

inordinate amounts of time debugging them.
When I see the GIT shell scripts, my hands start to itch to make a

nice object oriented Python wrapper for it.
--

 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

-

I've been thinking about revamping the style of shell scripts in

git-core Porcelain-ish for some time, and I have a feeling that

now may be a good time to do so, after one feature release is

out and the list is discussing UI improvements.
But before mentioning the specifics, let me mention one tangent.

I recently installed an OpenBSD bochs (it was actually a qemu

image) without knowing much about the way of the land, and after

adjusting myself to necessary glitches (like "make" being called

"gmake" there), I saw git properly built and pass its selftest.

I was pleasantly surprised when I noticed there was no 'bash' on

the system after all that.
I would like to keep it that way.
I'll list things I would want to and not want to change.

Comments from the list are very appreciated.  You can say things

in two ways:
 * I guarantee that the _default_ shell on all sane platforms we

   care about handle this construct correctly, although it was

   not in the original Bourne.  There is no reason to stay away

   from it these days.
or
 * You've stayed away from this construct but now you say you

   feel it is Ok to use it.  Don't.  It would break with the

   shell on my platform (or "it is a bad practice because of

   such and such reasons").
I do not think many people can say the former with authority

unless you have a portability lab (the company I work for used

to be like that and it was an interesting experience to learn

all about irritating implementation differences).  And "POSIX

says shell should behave that way" is _not_ what I want to hear

about.
But the latter should be a lot easier to say, and would be

appreciated because it would help us avoid regressions.
Things I would want to change:
 - One indent level is one tab and the tab-width is eight

   columns.  Some of our scripts tend to use less than eight

   spaces for indentation to avoid line wrapping.
 - More use of shell functions are fine.   Especially if the

   above change makes lines too long, the...
[ message continues ]

Actually, which sane platforms we care about have /bin/sh that is NOT
What about [ instead of test? And
	if foo; then
instead of
	if foo

	then
?
Am I the only one who hates
case "$log_given" in

tt*)

        die "Only one of -c/-C/-F can be used." ;;

*tm*|*mt*)

        die "Option -m cannot be combined with -c/-C/-F." ;;

esac
instead of having this stuff in explicit variables and writing out some

explicit boolean expressions? (There _are_ few cases where the case is

cool, but they are rare.)
It would be really great if Git would have something alike the Cogito's

optparse infrastructure. I'm not sure if you can implement it in Bourne

sh with reasonable performance, though...
I think addressing these three particular points would make the scripts

hugely more coder-friendly. (And well, I usually say that coding style

is not *that* important and is frequently overemphasised. But that holds
It's a pity. :-( Which shell doesn't support them?
This is quite a larger deal, I think; but the portability concerns are

very real, I guess. :|
--

				Petr "Pasky" Baudis

Stuff: http://pasky.or.cz/

#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj

$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

-

Petr Baudis <pasky@suse.cz> writes:
You already said this kind of details are subjective so I'd omit

the usual "I would think" and answer them without worrying about
This is much more readable without "case".  "abandon the old

rule that told us to avoid if when case would do" applies.

Although it is about multiple possibility switch (so a case can

be made that "case" is appropriate here), we should reduce the

use of "case" to cases like the outermost big "case" you find in
getopt(1) is fine, unless somebody screams that it is not

available on his platform.
-

It should be stressed that git-core plumbing written in C is not

just for git Porcelain-ish, and it will continue to be shared

service.  We would add core support for what Porcelains need and

we would try hard to keep them generic enough so that other

Porcelains can use them.  Keeping the core and Porcelain-ish in

the same project has made it easier to keep them in sync and to

find and add missing features that would benefit Porcelains (not

limited to git Porcelain-ish).  But that should not be mistaken

as plumbing somehow belongs more to git Porcelain-ish than to

Cogito or others.
I also think you should take credit for some core improvements

you did yourself (e.g "ls-files -t" format was originally added

for the sole purpose of helping Cogito, but now others use it,

too).
-

Of course, I didn't mean to say that. I should do more often things

like adding --stdin to the fetchers. From one part, I'm used to work

with a fixed set of system tools and extending Git with the

functionality I want means changing my thinking mode and "jumping out of

the system" a bit. The other part is that I cannot use the improvements

in Cogito right away (at least not in the main branch) but I have to

wait for the next Git release; but this is mostly just an excuse. :-)
--

				Petr "Pasky" Baudis

Stuff: http://pasky.or.cz/

#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj

$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

-

This and other examples in "making remote tracking branches less

visible" are hard to read because I used the word "origin" in

two different sense.  So here is a needed clarification.
If you have remotes/upstream that says:
	URL: git://git.xz/repo.git

        Pull: refs/heads/master:remotes/origin/master

        Pull: refs/heads/next:remotes/origin/next
Then, currently the users need to say:
	git diff remotes/origin/master

        git merge remotes/origin/next
By "making tracking branches less visible", what I mean is to

let the users say this instead:
	git diff upstream

        git merge upstream#next
-

What is the point of hiding tracking branches?  Why just not making them

easier to use instead?  There are currently so many ways to specify

remote branches that even I get confused.
OK..... let's pretend this is my follow-up to your "If I were redoing

git from scratch" query.  Actually I would not redo it from scratch

since the vast majority of it is rather sane already.  But here's some

changes that I would do:
1) make "git init" an alias for "git init-db".
What's the point of "-db"?  Sure we're initializing the GIT database.

But who cares?  The user doesn't care if GIT uses a "database" or

whatever.  And according to some people's definition of a "database" it

could be argued that GIT doesn't use a database at all in the purist

sense of it. What the user wants is to get started and "init" (without

the "-db" is so much more to the point. Doesn't matter if incidentally

it happens to be the same keyword HG uses for the same operation because

we are not afflicted by the NIH disease, right? And it has 3 chars less

to type which is for sure a premium improvement to the very first GIT

user experience!
2) "pull" and "push" should be symmetrical operations
They are symmetrical in the dictionary and in people's mind.  OK but what

if I merge content from another _local_ branch into the current one?

Isn't that kind of a pull as well?  Answer: NO IT IS NOT!  Reason:

because we already have "merge" for that very operation for damn sake!

And because "merging" isn't a synonym for "pulling" at all, we cannot

pretend it should sort of become more true if taken the other way

around.
Actually, if we _merge_ stuff together, we certainly have to /pull/ some

of it, meaning that "merge" might imply a "pull", even in real life

situations outside of the GIT context (think merging Vodka and Kahlua in

a glass where you might have to pull the Vodka bottle out of the freezer

before you can merge it). And thankfully we got it right with git-merge

which can take either ...
[ message continues ]

(This is somewhat related to the HEAD issue, e.g.

<7v1wo3d6g4.fsf@assigned-by-dhcp.cox.net>, by virtue of basically

eliminating it.)
Let's see. If you are adding the alias, you can as well add some

porcelain stuffing in it, too.
What are the 99% of use cases when doing "init"?
(a) You are going to do an initial commit right away; the repository is

at this point basically useless for anything but initial commit. So you

might have "init" well just perform it for you right away.
(b) You are setting up a bare repository on a server and you will push

to it in a minute. Cogito has a separate cg-admin-setuprepo command for

it, which will also prepare it for usage by dumb servers and optionally
If you _really_ want to do it in Git, the only sensible way to do it is

to stop using the "pull" verb for a command name altogether for at least

some rather long period of time, otherwise that's a blatant backwards

..snip..
By the way, due to the way you describe it, it's not all that clear to

me how is this (in)compatible with the current way we do it, on other

than the usage and git-pull's auto-creation magic level.
Is it that what you are describing _is_ in fact what we do support now,

with "branch groups" meaning "remotes" etc, and you are only proposing

some enhancements to automatically create remotes in git-pull, or are

there some other differences I've missed?
--

				Petr "Pasky" Baudis

Stuff: http://pasky.or.cz/

#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj

$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

-

Nicolas Pitre wrote:
I would change that so "local_name" is always a branch group name, but

branch group names can be used as refs. That is,
git pull startrek.com/kirk.git:master kirk
would always create the branch-head .git/refs/remote/kirk/master which

for short can be referenced as just "kirk" (barring clashes ofc), so

long as it only has one branch tracked.
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

Personally, I agree with almost everything in this email.  Except the 
I was completely confused by this origin/master/clone stuff when I started

with git.  In hindsight, now I understand git a bit more, this is what I

would have liked:
 * Don't use the name "origin" twice.  In fact, don't use it at all.  In a

distributed system there is no such thing as a true origin.
 * .git/remotes/origin should be ".git/remotes/default".   "origin" is only

special because it is the default to push and pull - it's very nice to have a

default, but it should therefore be /called/ "default".
 * Whatever git-clone calls the remote, it should be matched by a directory

in .git/refs/remotes.  So .git/remotes/$name contains "Pull"s to get all the

remote branches to .git/refs/remotes/$name/*.   This implies that

git /always/ does --use-separate-remote in clone.  If a branch is practically

read-only it should be technically read-only too.
 * If clone really wants to have a non-read-only master, then that should

be .git/refs/heads/master and will initialise

to .git/refs/remotes/$name/master after cloning.  Personally I think this is

dangerous because it assumes there is a "master" upstream - which git doesn't

mandate at all.  Maybe it would be better to take the upstream HEAD and

create a local branch for /that/ branch rather than require that it is

called "master".
 * Ensuring we have /all/ upstream branches at a later date is hard, and not

automatic.  Here is the .git/remotes/default file that should be possible:

    URL: git://host/project.git

    Pull: refs/heads/*:refs/remotes/default/*

   Now, every git-pull would check for new upstream branch refs and sync them

into the local remotes list.  These are read-only so it'd be perfectly safe

to delete any locally that no longer exist upstream.
 * git-clone should really just be a small wrapper around

    - git-init-db

    - create .git/remotes/default

    - maybe create specific .git/config

    - git-fetch default

   If ...
[ message continues ]

But "default" is way too generic a name, it's much more confusing I

think. As the one guilty of inventing master and origin, I agree that

they are somewhat silly, but if I would have to pick which one to

replace with something "better", I'd much rather pick master.
  Yes, Git can operate in a completely distributed manner. People do use

it as it. And there are also people that have no origin branch in their

repository. But the vast (overwhelming!) majority of people _does_ work

in some kind of hierarchical setup, and for them origin does have a
  Here I think that modulo the lack of remotes support (which is not a

fundamental thing here), the general setup of how Cogito does stuff is

much more saner than the current Git mess. It does basically exactly

what you've said above, and even the fetching itself is IMHO written

much more cleanly than in Git. In an ideal world, Git would just take
  It shouldn't be hard to do at all. Have the porcelain call "protocol

drivers" based on protocol in some generic way, like

/usr/lib/git/protocol/$proto.
--

				Petr "Pasky" Baudis

Stuff: http://pasky.or.cz/

#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj

$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

-

I think the naming is just a minor detail and can be overridden

with "clone --origin" already.  Renaming it to default is just

like making separate-remote the default to me -- it is fine as
I think the latter is what clone has done always; take remote's

HEAD and use that to initialize local master (there is no

confusion coming from multiple peer repositories because you

clone from only one place to initialize the repository -- that

one _is_ the origin), and we even keep the HEAD pointing at the

remote's master or whatever it points at at the remote.  Using
That is not entirely true.  clone has convenience because people

asked.  It does not have to mean you are not allowed to give
A list of common things wished by people certainly is a handy

thing to have.
A consensus would not write code and it generally does not take

technology into account to tell what is realistic and what is

not, so the result needs to be take with a grain of salt,

though.
-

It's this sort of thing that is confusing though - the remote HEAD branch

could be anything, and yet that is made to be origin locally as a tracking

branch and then master as the writable branch.  What if upstream /has/ a

master but "next" is its HEAD?  You'd then get
 next:remotes/origin

 master:remotes/master
Then a local master which is actually upstream next!  Oh dear.
I may well have misunderstood what you've said above above clone always

initialising master from remote's HEAD; if so please disregard what I'm 
Absolutely, that was why I said clone shouldn't have special abilities.  In

fact, if you're willing you don't need clone at all; you just need 
Of course, I only suggested it because the same suggestions were popping up

multiple times.  Anyway; I put it in the GitWiki at

http://git.or.cz/gitwiki/Wishlist
Andy
--

Dr Andrew Parkins, M Eng (Hons), AMIEE

andyparkins@gmail.com

-

I agree, sort of.  Not because"origin" is ambigous as a name.  But

rather because there is a magic translation from "master" to "origin",

and I think this is wrong to do that.
As mentioned elsewhere (and let's start using "get" instead of "pull" as

suggested by Johannes), a "get" should probably always create a branch

group even if it contains only one branch.  This way the remote branch

called "master" will still be called "master" locally, under the branch

group used to represent the remote repository.  And if a local name is

not provided then let's just call it "default".  This way, amongst the

remote references, there would be a "default/master" that would be used

when nothing else is provided by the user. So...
	git get repo.com/time_machine.git
would create a local branch named "remotes/default/master" if the remote

repo has only a master branch.
Then, a simple:
	git merge
could be the same as
	git merge default
which would be equivalent to
	git merge default/master
Afterwards, because the "default" remote already exists, then:
	git get
would be the same as
	git get default
to get changes for all branches in the "default" remote branches, of

which "master" might be the only one in the simple case.
But again I think it is important that the URL to use must be a per

branch attribute i.e. attached to "default/master" and not just

"default".  This way someone could add all branches of interest into the

"default" group even if they're from different repositories, and a

simple  get without any argument would get them all.
Nicolas

-

Why not call it remotes/repo.com/time_machine.git/master and have a

DEFAULT_ORIGIN that is a symref to it in the same way as HEAD is a symref to

a local branch
--

Alan Chandler

http://www.chandlerfamily.org.uk

-

I think the "one group per one remote repository" model is a lot

easier to explain.  At least when I read your first "branch

group" proposal that was I thought was going on and I found it

quite sensible (and it maps more or less straightforwardly to

the way existing .git/refs/remotes is set up by default).
-

I think one group per remote repo is how things should be by default

too.  But we should not limit it to that if possible.
Nicolas

-

Without the limitation, we risk name collisions when getting all

branches from the remote repository (that is, including any new

branches we previously didn't know about).
--

Karl Hasselstr

Ok, I think in essence we are saying the same thing except I

went overboard by suggsting to extend sha1_name to also look at

.git/remotes/$name which is not necessary, because we already

have the .git/refs/remotes/%s/HEAD magic there.  Consider the
I think that makes a lot of sense to have "gh pull" and "gh

push" as symmetric operations, and make "gh merge" do the

fast-forward and 3-way merge magic done in the current "git
I would probably prefer making the default namespace under

.git/refs/remotes/remote-name for the tracking branches this

proposal creates, but other than that I agree with the general

direction this proposal is taking us, including branch groups.

We have .git/refs/remotes/%s/HEAD magic so I do not think we

even need to treat one branch repository any specially as you

suggsted.
The reason I am suggsting "gh" instead of "git" is primarily to

deal with stale documentation people would find googling.  I can

easily see people get confused by reading "pull = fetch + merge"

from either mailing list archive or Git cheat sheet various

projects seem to have developed.
It does not mean we need to redo _all_ UI.  I think most of the

archaeology commands have sane UI so during the transition

period (git 1.99) we can have "git log" and "gh log" which are

one and the same program, and perhaps git 2.0 can be shipped

with clear distinction between plumbing (i.e. git-update-index

and friends) and porcelain (e.g. "gh pull" that only fetches but

with the user friendliness you outlined here), with backward

compatibility wart to help old timers (e.g. "git pull" that

still does "git fetch" followed by "git merge").
-

Hi,
Please no. It only makes things even more confusing. "git init" is perfect

as it is. We can always have internal aliases from "init-db" to "init" to 
I am really opposed to do "gh pull". Not only because of "gh" being

completely confusing (we already _have_ "git", and for porcelains

different TLAs), but "pull" _really_ is confusing by now. And Mercurial

did not help one wit by insisting on their own interpretation.
Why not do something like "get/put" instead? It is
- easier to remember

- not bogus (AFAICT the meaning is not used in diametrical senses)

- shorter to type than download/upload
As for "git merge": Just by the number of arguments you can discern

between the original usage and the new usage, so I am all in favour of

replacing "git pull <blabla>" by "git merge <blabla>". Where "<blabla>"

can be a branch or a remote or a URL (with cogito style #branchname).
Ciao,

Dscho
-

I completely agree that creating yet another command prefix for

basically the same tools would be a disaster.  We have "git" already so 
Well, of all compromizes this is probably the best one so far.  I would

have prefered to bite the bullet and fix "pull" instead of adding yet

more commands.  But if the consensus is that there is no way on earth

that "pull" can be salvaged then get/put is probably more enjoyable than

download/upload.  This way pull/fetch/push could still be available

(albeit burried somewhere out of sight).
Nicolas

-

I still think in the long run you would be better off giving

separate names to Porcelains because I am sure you are going to

find the next command to "fix", you cannot suddenly change the

semantics of the command, and you soon run out of alternative

ways to name the action and you in addition have to explain the

differences between fetch and get to new users.  At least, with

"ig pull", you can dismiss all the broken git-x Porcelain-ish by

saying "Oh, git-x user-level commands had inconsistent semantics

and broken UI so do not use them anymore -- they are still there

only to help old timers transition.  The user level commands are

now called ig-x and ig stands for improved git".
But that's a very minor detail and can be fixed when we hit the

wall, so let's wait and see what happens.  Please consider my

gh/gu/cg/whatever dropped.
I think get/put is much better than suddenly changing what pull

means and is shorter to type than x-load; I am Ok with them.

Although I think these words are tainted by SCCS, I do not think

anybody cares.
-

> "ig pull", you can dismiss all the broken git-x Porcelain-ish by

 > saying "Oh, git-x user-level commands had inconsistent semantics

 > and broken UI so do not use them anymore -- they are still there

 > only to help old timers transition.  The user level commands are

 > now called ig-x and ig stands for improved git".
I think it would be good if there were different commands for

porcelains. Not because fixing the current commands is too much work,

but rather because it would clarify the structure of git.  GIT is a

3-layer approach:
  - index+workdir+refs over

  - a DAG of commits over

  - a file based SHA1 database
at first sight it is difficult to tell for each command on which layer

it operates. It would help understanding GIT a lot if each layer got

it's own command, eg.
   git - sha1 content db

   gic - sequences of commits

   giu - UI
they're also tainted  by darcs, but that's a minor problem, I suppose.
--

  Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

-

The problem I think with that is that the line between plumbing and porcelain

is not clear.  If you have two names then for the ambiguous ones you are just

making it more confusing because there is yet another variable to try before

you get the function you want.
Andy
--

Dr Andrew Parkins, M Eng (Hons), AMIEE

andyparkins@gmail.com

-

This is moot because we (at least tentatively) agreed not to do

"gh" or "ig" or whatever, but I do not understand why you feel

so.
If we had a separate Porcelain namespace (say "ng" for "new

git") you would know "ng-commit" is not a Plumbing and when you

are writing a Porcelain script you would stay away from using it

in your script.
In the longer term, when the new Porcelain UI Nico and friends

are designing matures, and if it makes everybody (including

existing users who learned git-* Porcelain-ish during 18-months

process) happy, we could gradually deprecate and eventually

remove the git-* Porcelain-ish over time, at that point we would

have a very clear line between plumbing and porcelain.
But that would not be a flag-day change.  During the transition

period you cannot mechanically tell if git-foo is a plumbing or

a porcelain just like you cannot do so now.
-

I'm not the original poster, but I feel the same way about the line

being unclear.
Here's a real-world example from last week.
For cairo I wrote a little script that two revspecs, (or one in

which case its first parent is used), and it goes off and checks out

both versions, builds each, runs a performance test on each, and then

generates a report showing the performance impact.
So now I can do things like:
	# What's the performance impact of my latest change:

	cairo-perf-diff HEAD
	# Have my last few changes helped as much as I'd hoped:

	cairo-perf-diff HEAD~3 HEAD
	# How has performance changed since our last stable release:

	cairo-perf-diff 1.2.6 HEAD
Anyway, when I announced this I also mentioned how easily someone

might generate an entire series of reports for a series of

commits. The command I gave as an example is:
	for rev in $(git rev-list 1.2.6..HEAD); do

	    cairo-perf-diff $rev

	done
I think that's a perfectly legitimate one-liner for users to use, and

it really shows off the easy-scriptability of git. But certainly, no

"new porcelain" author is going to consider rev-list to be porcelain

rather than plumbing, right? So as soon as I start teaching people to

do useful stuff like this, they might have to reach down into the

"scary" git interface.
I think we're much better off just having one "git" namespace for the

standard command-line interface, and then making it as easy to use as

possible.
-Carl

That is a very fine example, but I do not see why it is a

problem.  I do not think the goal of Porcelain is to make it

totally unnecessary for users to know about the plumbing.
The one-liner is essentially a new Porcelain command that is

useful in the cairo developers' workflow, and implementing it

with a plumbing command makes perfect sense.  The whole point of

git plumbing is to be friendly for scripted use.  If the user

who learns that one-liner from you gets curious why and how that

one-liner works, that would be a good gentle introduction to the

plumbing, but otherwise the user is not forced to know about it.
Also I do not see a problem if some plumbing commands happen to

be also useful by themselves ("[alias] less = -p cat-file -p"

comes to mind for example).
Some plumbing commands may be too deep magic and users do not

have to directly deal with them every day.  Some other plumbing

commands are so low-level and needs combination with others to

be any useful, and it is cumbersome to type the combination

every day.  For the latter kind, we have Porcelain commands that

implement the frequently used combination and the end users do

not have to know about them.
So it is true that by having a rich and usable set of Porcelain,

there is less need for the users to know about all the plumbing

details, but I consider that is a happy consequence.  It does

not have to be the goal of having a good Porcelain to hide the

whole plumbing.
-

If not, then the promise of the porcelain fails. If cogito offers

"Here are 40 commands so you don't have to learn git's 140" and then

next says "Oh, and you'll still want to learn all those git commands

too", then its existence only makes the "too much stuff to learn"

problem worse, not better.
But I think you agree with me (for now) that fixing the git UI should

not involve creating a new primary command to replace "git".
-Carl

I didn't get this argument before either - why do you need to learn "all

those git commands" too? You'll never have to learn "git add" or even

"git commit". If you want to pick specific git commands later (like "git

bisect", which even seeks in a Cogito-compatible way), that's fine, go

ahead! But you by no means have to learn _other_ commands than those you

need. If you want to bisect, you have to learn no other Git commands

than "git bisect".
Another point is, if using _just_ _git_ requires you to learn "all those

git commands too" from git-commit-tree up (yes it does! if you want your

authorship information to be correct), something is wrong.
--

				Petr "Pasky" Baudis

Stuff: http://pasky.or.cz/

#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj

$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

-

When/why do I need git-commit-tree? Isn't git-commit enough?
-- robin

-

As I said, when you need to find out how to setup your authorship

information. It's documented as deep as on the git-commit-tree level.

BTW, the documentation is another important part of the

plumbing/porcelain separation, it's not only about the list of commands

but also that porcelain documentation should be reasonably

self-contained and not require users to peek at plumbing docs in order

to find out many stuff. It's also a consideration I take when

maintaining Cogito documentation.
--

				Petr "Pasky" Baudis

Stuff: http://pasky.or.cz/

#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj

$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

-

There is merit in trying to segregate porcelain vs plumbing... at least

in theory.  In practice though I don't think this is something we should

absolutely strive for.
Why? Because something is always going to fail the categorization.

Sure there are commands that are pure plumbing like git-commit-tree,

etc.  Some are pure porcelain like git-commit or git-log.  Yet we use

git-log's output for git-shortlog.  Does it mean that git-log is

plumbing? Also I have a script here that uses git-commit directly

because it is so much convenient rather than futzing with the really

bare plumbing.  I don't think git-commit should be prevented from being

used within another script even if it is classified as porcelain.
So we have that notion of plumbing vs porcelain but in practice there is

a whole spectrum between those two poles and I think it is a good thing.
Nicolas

-

On Wed, 15 Nov 2006 15:01:47 +0100 (CET)
This makes a lot of sense.  The "git" command isn't damaged so bad

that it can't be saved in a backward compatible way, at least for

a transition period.  Adding a new command name seems like a step
Both these ideas sound like a step in the right direction too.
Sean

-

Why gh?  Is Git just Mercurial backwards?  :)
I'm all in favor of this discussion, and in particular of just

breaking the entire UI in 2.0 by using a new frontend command.

I'm just not sure that "Mercurial backwards" describes Git well.
--

Shawn.

-

I do not have any obsession to any name as long as it is

different from "git" to avoid confusion coming from older

documents that would be found by googling.  gh was just

shorthand for "git for humans" (and easy to type with index

fingers).  I think I listed a few other possibilities in my

previous message.
-

Yes, "resolve" sounds better than "resolved". The latter is arguably

more correct, since you're telling git that you have already resolved

the file and not asking it to resolve it for you, but I still prefer
Seems very sane. Default to simple behavior, and provide a switch to
This should reduce newbie confusion a lot.
--

Karl Hasselstr

Hmm, did they (not) consider Cogito? They wouldn't have those issues.

;-)
--

				Petr "Pasky" Baudis

Stuff: http://pasky.or.cz/

#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj

$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

-

I didn't ask.
Frankly, I don't see a lot of value in the git/cogito split right now.
When I first learned git and cogito (January 2006) and switched cairo

from cvs to git (the repository storage), I recommended cogito to

cairo programmers as a "more cvs-like" way to work with the new

repository.
Since then, having worked with git (the command-line program)

exclusively for my own work, and having introduced it to dozens of new

users, I don't bother recommending cogito anymore. It's just not that

hard to learn git itself, so there's not that much value in learning

cogito instead.
And this is particularly true since there's quite a large cost to

having to learn cogito _in addition to_ git. And I think that's what

most people would have to do anyway. For example, cogito doesn't wrap

all git commands. So users have to dip down into git for things like

git-bisect or else miss out an important functionality.
And for something like the Fedora transition, where I'm working with

the people who will be training the community in the new tools, the

trainers would have to learn both if they want to support a community

using both git and cogito. These trainers are already complaining

about the ~140 git commands, so adding 40 more cogito commands as well

doesn't make the story better.
It's great that git is written in a script-friendly way so that new

interfaces can be built on top of it. And I think the benefits of new

user interfaces are clear when they work in fundamentally different

ways, (say, being operated through a GUI). But where git and cogito

are both command-line utilities and have the same basic functionality,

I don't see how its helpful to maintain both tools. (Certainly some of

my attitude here is due to the timing of my introduction to git

contrasted with the timing of the inception of cogito. I'm sure git

improved a lot between those two events.)
There are some things that cogito does that git does not that I would

like to have in git. One is having a "commit" comm...
[ message continues ]

Jumping into this a day late, but:
Agreed totally on the second point. It would be great if git natively

supported everything people use in Cogito.
I find myself using native git commands for the most part, except for

one Cogito command: "cg-update". It is vastly more convenient than

git-pull in large part because it automatically merges upstream changes

with uncommitted working-copy changes. I suppose you could classify this

as "hide the index" in some sense.
Maybe I should give an example of what I mean. Suppose I have two child

repositories (owned by different developers, say):
cg-clone repo child1

cg-clone repo child2
Now I go into both of them and make different (hopefull non-conflicting)

edits to the same file.
echo foo >> child1/testfile

perl -pi -e 's/tree/shrub/' child2/testfile
I push the change from child1 into the integration repo.
cd child1

git-commit -a

git-push
Now I want to incorporate the change into child2, where I'm still doing

work. With Cogito, I go to child2 and run:
cg-update
and afterwards, the upstream changes are merged into testfile and "git

diff" still shows my local edits. With Git native commands, updating

child2 if I'm not ready to commit yet is more like:
git-diff --binary > /tmp/patch

git-reset --hard

git-pull

git-apply /tmp/patch
I might have gotten that slightly wrong, but I think I have the general

idea right; in any event, it's not nearly as convenient! The alternative

is to commit then pull, but then when I want to look at my local edits,

I have to remember to diff my working copy against the correct revision,

which gets increasingly annoying if I update more than once.
Like others on this list, I'm also trying to sell an existing user base

(in this case, they're using Subversion) on Git. The lack of a built-in

equivalent to "svn update" is actually a pretty big UI annoyance for

people whose workflow doesn't require git's more sophisticated feature

set at a given point in time. Eve...
[ message continues ]

stg pull would help you in such a situation as well, but I see

what you mean.
Just like we have an explicit -m option to "checkout" to allow

file-level merging of local changes, I think it is reasonable to

hav an option that allows file-level merging of local changes

when doing a pull that you _know_ will not conflict.
When there will be a conflict between your HEAD and MERGE_HEAD

even without your local changes, you somehow need to sort out

the resulting mess that come from conflicts due to the branch

diversion (i.e. log HEAD...MERGE_HEAD) and conflicts between

your local change and what the other branch did.  The resulting

merge commit obviously needs to record resolutions only to the

former and should not even record anything you did locally,

conflicted or not.  Which is a pain for the end user and giving

them a way to revert to the state before this three-and-half

way merge started also needs to be there.
Unfortunately the only way to know if there will be a file-level

conflict is to try one, and stashing away the current state just

in case it conflicted is a performance penalty, so this probably

should stay as an option just like "-m" to the "checkout".
But the basic mechanism to do this three-and-half way merge is

simple and I have no objection if somebody wanted to add such an

option to "git pull".
-

I think it would be just great if it worked at least for fast-forwarding

case; I think this is where it is actually most useful. Cogito tries to

support even the three-way case as long as the changes touch different

files, but I'm not sure if it was a good idea to begin with.
--

				Petr "Pasky" Baudis

Stuff: http://pasky.or.cz/

#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj

$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

-

I am of two minds here.
I do not think the Porcelain-ish UI that is shipped with git

should be taken with the same degree of "authority" as git

Plumbing.  The plumbing needed to have something that worked for

one particular workflow (namely, workflow of the people in the

integrator role of kernel-style project) and that is where the

current set of Porcelain-ish originates.  Linus works primarily

as an integrator so the toolsets he did tend to be more pleasant

to use for integrators and less so for contributors.  I started

as a contributor and added some commands like format-patch and

rebase that Linus never would have felt the need for.  I think

single isolated developers, contributors and CVS style shared

repository usage could be a lot improved because neither of us

were concentrating in their workflows.  This needs somebody

motivated enough to improve things in that area.  For example,

StGIT with its 'float' command is a great improvement over what

rebase does for people in the contributor role.
By now, perhaps git may be good enough for the kernel folks,

even for those not in the integrator role, but I have no doubt

that they have many dislikes to the way some commands work.

They and X.org folks are using git primarily because Linus and

Keith forced them to ;-), and being interoperable is more

important than having to tolerate sucky UI here and there.

Everybody knows that git Porcelain-ish sucks, and making it more

usable is a worthy goal.
But making it more usable for whom is a big question.  
Quite frankly, I do not think there can be _the_ single UI that

would satisfy different types of workflows for some of the

commands.  The commands related to software archaeology, in

which my main interest and strength lie, would easily be usable

across workflows, but commands to build commits locally and

propagate them to and from other repositories would be affected

by the workflow.
For example, fetching and merging from many places without

necessarily having correspondin...
[ message continues ]

I think we should fix this. "This is great technology with a crap

interface on top" really isn't a good story. I don't actually agree

with that---I don't think the git interface is really all that bad,

it's just got a few little things that tend to trip up new users in my

experience.
And what git does really well, (history exploring, allowing for

pipeline on-liners to iterate over revisions in A..B), are things that

don't even exist in other tools, nor even in the "alternate"

porcelains for git. This stuff is where git's interface is really
Yes, there are some specific workflow-oriented operations that git

doesn't handle as well as it could. Things like commit --amend are

certainly improvements. One that is still totally broken is "follow

all the development in another repository" where clone followed by

repeated fetch doesn't do the job as soon as the remote adds or
I strongly disagree. Or at least, I don't think we've tried hard

enough yet that we should give up on this.
I do agree that people in different roles will have different lists of

"most used operations" and that some operations won't appear on some

users lists at all, (someone who's just "watching" development won't

commit or merge, for example---[or so they thing when they start]).
But I really don't think that for any given operation that different

roles impose a different desire on the behavior of the operation. We

have different people with different background and disagreement on

names and silly things like that, but I don't think that's related to

...
I don't think we've ever had this right in git. The new

--use-separate-remotes stuff or similar will start to help as it
Workflow-interruption is an important thing to support, but separating

update-index and commit really doesn't address it nearly as much as I

would like. The lack of really good workflow-interruption support has

been one of my longest-running annoyances with git, (perhaps because I

have a problem with trying to do too many things at o...
[ message continues ]

..snip passage about workflows..
Controversy's fun, so...
<Cogito maintainer hat _off_> (But yeah, it still looks silly that I'm

saying this.)
 From the current perspective, I think it has been a mistake that the

porcelain and plumbing was not kept separate in independent packages,

and perhaps even maintained separately (and perhaps not; at least having

a single tree with plumbing/ and porcelain/ directories and separate

packages in distributions might already help something), so that "git"

would be kept as a kind of library and then there would be a separate

package providing an interface to it. Or you could select one of several

packages. Not only would that make Cogito prevail in the world and bring

me a flood of marriage proposals, but look at how would it help the

general public:
  (i) Clearly divided porcelain/plumbing interface, so that you can

really isolate the two UI-wise; endless confusion reigns there now. Is

git-update-index porcelain or plumbing? _You_ call git-merge a proper

porcelain? From my perspective, git-update-ref is as plumbing as it

gets, but it's classified as porcelain. Etc, etc. This would be by far

the most important advantage.
  (ii) The plumbing and porcelain would not share the same namespace,

leading to clearer UI. (I'm just inflating (i).)
  (iii) The documentation would not be a strange mix of porcelain and

plumbing. (More (i) inflation.)
  (iv) (i) is troublesome because I have a feeling that Junio declared

several times that he doesn't care that much about stable API for

porcelain compared to the plumbing. But with the current mix it's

desirable to use some porcelain even in other porcelains and in scripts.
  (v) Git would be properly libified by now. If you wanted to convert

bits of porcelain to C, it would be at least much higher priority.
  (vi) You wouldn't need to make the gruesome choice on what is the

canonical workflow the _the_ Git porcelain supports (see the snipped

passage). Or you would, but it would have less ...
[ message continues ]

It appears that you are not grumpy as you were anymore ;-).  I
Yes.  The current "merge" started its life as Linus's porcelain

(we did not have fetch and pull infrastructure back then) but

quickly has become just a helper for pull to produce a merge

commit.  If anybody thinks its UI is good as a general end-user

level command, there is a need for "head examination".
As you say, update-ref is as plumbing as it gets and it should

not be listed as Porcelain; I am a bit surprised that it is

labelled as such myself.
This is true and it is a problem.
While we encourage Porcelain writers to use plumbing in order to

give git Porcelain-ish more freedom to evolve to give better UI

for humans, not having a clear distinction between the two makes
I am not sure about "libified" part and I do not know what bits

of porcelain wants to become C right now.  But I do not think
Yes.  This is really important.
Linus and me having done Porcelain-ish that supports integrator

role workflow better than other workflows such as contributor

role should not discourage people from working on alternative or

complementary Porcelains to help other workflows better (see the

snipped passage).
StGIT sets a great example, and efforts like it is encoraged

more.
I think both Linus and myself tried to make it clear that the

purpose of Porcelain-ish that comes with core git is 50% to make

plumbing (perhaps minimally) usable and the other 50% to serve

as an example for Porcelain writers to learn how to use the

plumbing, but we should probably have stressed the latter

better.
-

Merge strategies. Or wait, is that already plumbing?
Or git-status. git-add. Plenty more.
--

				Petr "Pasky" Baudis

Stuff: http://pasky.or.cz/

#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj

$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

-

If you mean "git merge" it sure needs to be brought forward.  It can't

be clearer than:
	git-merge the_other_branch
or
	git-merge git://repo.com/time_machine.git
to instantaneously understand what is going on.
Nicolas

-

Uh, see contrib/completion/git-completion.bash.
"git <TAB>" completes commands.  It offers too many completions

for your taste it sounds like, as it also offers plumbing... but

that's fixable.  :-)
--

Shawn.

-

Oops. I had seen this and thought I had installed it properly a while

ago, (copied it to /etc/bash_completion.d/git), but I hadn't realized

it wasn't active in the shell I used to test while composing that
Yes, I think we'd all be better off if we could designate some subset

of the current git commands as not being intended for users to type on

the command line and pulled them out of the completion scripts.
It is tough though. Looking through what's available in the short list

from "git --help" I notice that update-index isn't there, and that's

currently still required, (as we've been discussing here). But even

things as "core plumbing" as git rev-list I find extremely useful on

the command like with simple pipelines.
On the other hand, there are definitely some commands I've never

typed, and are not intended to be typed by the user. Here are a few I

see as fairly obvious just from skimming the list:
	merge-*

	http-*

	ssh-*

	upload-*

	mktag

	mktree

	check-ref-format

	...
There are a bunch of others as well. Maybe it would be easier to start

with the list in git --help and see what should be added to that.
The documentation for some of the above commands have phrases such as

"Invoked by <other command>" and "usually not invoked by the end user"

which does make the distinction quite clear. So it would be nice if

git could keep these away from the user more.
-Carl