Re: git-show --stat on first commit

Hello,

I'm sure this one will be known about already. git-show --stat on the the first commit doesn't show anything. I assume it's because git-diff-tree has nothing to diff against (although shouldn't that be an everything-new diff?).

Given the above; does anyone have a suggestion for what I could use as a replacement? Even just a list of the new files would be useful.

Andy

Andy Parkins wrote:

Yes, and git-diff-tree requires --root option if you want to generate
creation diff for initial (parentless, root) commit.
 

git show --stat --root

On 11/21/06, Andy Parkins <andyparkins@gmail.com> wrote:

$ git show --stat --root

In general the initial commit diff (or stat) is hidden, but perhaps it make sense to show it in "git show", you asked fo this specifically.

On 2006-11-21, Santi Béjar <sbejar@gmail.com> wrote:

Why not make --root the default? I also stumbled over this behaviour and even asked on this list.

In my opinion this will help new users which are supprised that they can't get the diff of the inital commit (which is totaly non-intuitiv behavior).

And one less "wart" to clean, which another thread is all about. :-)

Peter

Peter Baumann wrote:

You can always use git-ls-tree

Because for projects imported into git first commit diff is huge, and not very interesting. By the way, git show by default doesn't show diff for merges (you need --cc for that), nor rename detection (you need -M for that).

But you can always set default diff-tree options, including --root, --cc and -M in the show.difftree configuration variable (either in repo config, or in user config). It is IMHO better solution than changing defaults.

On 2006-11-21, Jakub Narebski <jnareb@gmail.com> wrote:

Ah. I wasn't aware of this. Thank for this nice tip.

Peter

On Tue, 21 Nov 2006, Peter Baumann wrote:

I suspect we should make the thing a config option, and default it to "on".

I personally do _not_ want to see the root commit, because for the kernel, it's a honking huge import that does not make sense as a "diff". It's not really a diff against anything, after all - it's an import.

That's really the reason why git defaults to not showing the root diff at all: exactly because for the kernel, the initial commit was state that "just came to be", and I found it both illogical and annoying to see it as a diff, since that commit really was a "black hole" where previous history just disappeared.

But if you have the _full_ history with a new project, "--root" by default probably makes tons of sense.

I really don't think it's a wart - see above - but it depends on the project.

There's also another reason for the root being special, which is purely git-internal: the root really has no parents at all, and the normal "git diff" is "diff against parents". So from a purely implementation standpoint, the "root" case is actually a special case, and for a while I was kind of wondering whether I should do what a lot of other SCM's seem to do, namely start out with an "empty root" when doing "git init-db".

git didn't end up doing that (and I'm personally pretty happy about it), but it was one of the things I was kind of thinking about: a "git import" kind of thing would have created an initial commit which was pre-populated with the thing to import, and a "git init-db" would have created an initial root commit that was empty.

That would have made the current "don't show the root diff" behaviour very natural (and you'd still have gotten the initial diff for a new project), but on the other hand, it would have had that annoying unnecessary "init" commit, and you'd _still_ have wanted to have something like "--root" in order to show the import commit as a patch (which you _sometimes_ want to do).

So having a config option would solve the problem, but what annoys me right now about the config options is that we really should have a graphical front-end to setting those things or something, because while _I_ don't have any issues with editing a ".git/config" file, I think we're getting to the point where a lot of our problems are really about "you can do it, but you have to know a lot about git to even know you can do it".

Linus Torvalds <torvalds@osdl.org> wrote:

Funny; I recently thought about rewriting Documentation/config.txt into a format that was not only easily read by asciidoc but which also had enough annotation data to render a Tk based UI from.

That way we could always have the configuration option editor match the current set of configuration options, and also offer good help for them. E.g. use a checkbox for booleans, a tk_optionMenu for choice lists, and offer up the asciidoc text as "help" on the option.

Its sort of in the back of my mind as something I'd like to do in git-gui, but right now branch management (creating, deleting, merging) is more important.

Right now git-gui does have a GUI editor for its own configuration data that it keeps in "gui" sections of .git/config and ~/.gitconfig, and lets the user view and edit both.

On 2006-11-21, Linus Torvalds <torvalds@osdl.org> wrote:

That would be great.

I am aware of the import problem, especially from the kernel history.

And I think handling this behaviour as a config option is the right thing, because most of the time if someone imports a project into git he will import the whole history, especially if he is using one of the cvs/svn importers. A "halfway import" as seen in the kernel repo is a special case and it is unlikely seen again.

Peter

On Tue, 21 Nov 2006, Peter Baumann wrote:

Actually, I see "halfway imports" all the time.

I've found that some of the git things like "git grep" etc are _so_ convenient, that whenever I get a source tar-ball for _anything_, I tend to do

	zcat < xyz-123.tar.gz | tar xvf -
	cd xyz-123
	git init-db
	git add
	git commit -m "Import xyz-123"

the first thing I do. Even if I never end up changing anything in that archive, it's just that convenient (and fast - sure, doing the hashing and compression means that the "git add" might not be truly instantaneous, but it's definitely fast enough that for almost all projects, doing this is so cheap that you don't need to care).

And _especially_ for things like this, being able to do "git log -p" to check the small trivial one-liners that I might do is nice (it happens - my pine4.64 import these days has three small commits to add buildnotes and handle UTF-8 input etc).

And again, that's when you do _not_ want to see "--root". Because it's never what you actually care about.

So I think imports are important. They may be throw-away trees like mine, but they're still useful.

On Tue, Nov 21, 2006 at 06:11:19PM +0100, Peter Baumann wrote:

Not all projects run on a public VCS. Hell, not all projects run on a VCS at all. And in the CVS case, you don't always have enough access to actually download the repository, which afaik is needed for importing.

  OG.

Olivier Galibert <galibert@pobox.com> wrote:

There is a tool floating around the 'net that will download a CVS repository and recreate the ,v files locally for you. cvssuck appears to be its name:

  http://freshmeat.net/projects/cvssuck/

On Tue, Nov 21, 2006 at 07:38:53PM CET, Olivier Galibert wrote:

It isn't needed. It's probably much slower over the net but that's how I created the glibc-cvs.git repository (at repo.or.cz); cvsps can operate over the network.

On Tue, Nov 21, 2006 at 05:31:30PM CET, Linus Torvalds wrote:

It's being asked by users time by time (first in April last year ;) and I'm not sure about any good answer I should tell them, so is the reason for not doing the implicit empty commit that it would be "annoying" I suppose in the log output?

Is that a reason good enough?

It would solve some of these annoying corner cases nicely, and you can still hide this empty commit from log output etc.

Petr Baudis wrote:

git repo-config show.difftree --root git repo-config whatchanged.difftree --root

On Tue, Nov 21, 2006 at 07:16:44PM CET, Jakub Narebski wrote:

That means extra pointless setup and is besides the point anyway, I was asking about empty commits, not default command settings.

BTW, the other frequent reason why empty commits come up so frequently is a FAQ "how do I create an unrelated branch in my repository" - their idea is that they will create a new branch starting with an empty commit (of course noone would think of anything like that in inferior VCSes because replacing the checked out trees would took forever; how cool Git is!).

(The answer is usually "create the branch in a separate repo and then fetch it to the original one". But it feels a bit kludgy given the otherwise seamless support for unrelated branches. (Not that I ever was a big fan of unrelated long-lived branches in general.))

Petr Baudis <pasky@suse.cz> wrote:

Or just abuse git-symbolic-ref:

	rm .git/index
	git symbolic-ref HEAD refs/heads/unrelated-branch
	git add ...
	git commit ...

see, so simple. And no need to create an unrelated repository and pull across to this one...

On Tuesday 2006, November 21 18:21, Petr Baudis wrote:

Just as kludgy, but I did this today by writing the name of the new branch in .git/HEAD then doing

for file in $(git-ls-files); do git-update-index --force-remove $file; done

Before creating the new files and "git-commit"ing.

Andy

On Tue, Nov 21, 2006 at 07:39:56PM CET, Andy Parkins wrote:

Ok, this approach looks actually reasonable (contrary to the frequently suggested rm approach, which is rather dangerous).

Perhaps git checkout --empty could do this?

Petr Baudis <pasky@suse.cz> wrote:

Or perhaps just delete .git/index?

Any git-update-index --add or git-add command will immediately create an empty index. Indeed this is the initial state after git-init-db, since there is no HEAD to load into the index there is no index...

On Tue, Nov 21, 2006 at 07:52:59PM CET, Shawn Pearce wrote:

But your working tree has still the contents of the old branch.

Sure, you could possibly just remove the files and then the index at once but that are just details.

Petr Baudis <pasky@suse.cz> writes:

I agree with you.  Personally, I think:

 - show is where the user is asking for _that_ particular
   commit, so it can safely default to --root, always.  No
   option is needed.

 - what we want for log and underlying rev-list is majorly
   dependent of the nature of the root commit.  Per repository
   (or even per root) option which defaults to "on" (I was
   going to say "off" to be backward compatible and convenient
   for "me", but even Linus says "on" so I am playing along)
   would make sense.

So just "core.showroot = yes | no" would be the only thing we would need, I think. Unless we do fancier "core.hideroot = SHA1-1 SHA1-2 ..." to say "these root should not be shown", that is.

I wrote something about this after reading #git log several days ago where somebody named Insount (sp?) was talking about "elegant idea" of the empty initial commit, but did not send it and kept silent about it. As Linus said in an earlier message, I've thought about this and am personally happy about the current way of not having it, and here is why.

Interestingly, I already talked about "show --root" in the message that I did not send -- I think you made this the right thread to post it in ;-)

-- >8 --
Subject: empty initial commit

Don't do it.  It is stupid.

	I'm imitating somebody who says "I am so right that it
        hurts".  Don't worry, I'll come back to my usual self
        and talk about what is wrong with our current tools and
        what needs to be fixed shortly ;-).

(1) Your claim that it is elegant because it removes a special
    case is bogus, because you are not removing special cases
    anyway.

The initial commit _is_ special. The first real example in "everyday" document begins by creating the initial commit out of an extracted tarball. You would _actively_ want to special case that commit. Its diff from nothingness is so uninteresting while inspecting the development history of the project that we do not even show it in "git log -p" output unless explicitly asked with "--root" option, for example [side note: we might want to default to --root for "git show", which clearly indicates that the user is interested in that particular one commit]. If you introduce the fake "epoch" commit, then you have to move that special case logic elsewhere and squelch the output when the parent is a commit with an empty tree, instead of the current logic which is to omit it when it is the root commit. You have to have special case either way.

(2) A branch yet to be born (i.e. a freshly initialized
    repository whose HEAD points at refs/heads/master that does
    not exist yet) and a branch whose tip points at a fake
    "epoch" commit are fundamentally different.

Let's remember our GIT 101. Two commits that happen to have the same tree are not equivalent, because a commit represents both the then-current state when it was made _and_ the development history that led to it. The development history is represented by chains of commits.

Earlier Linus and I updated git-pull to allow pulling into a branch yet to be born because a branch yet to be born _is_ an ancestor of any commit and can be fast-forwarded. There was no branch and there was no earlier history.

You cannot say the same thing for a branch that points at a root commit that has an empty tree. For one thing it would record authorship information and stuff so it won't be "THE universal void". You can have infinite (well, bounded by 2^160 because we use SHA-1 to name objects) such root commits, and they are not equivalent. Does that mean a true root commit (not your fake commit) can be a child of 2^160 empty parents that are all alike? Which one of them do you choose to record as its parent and why?

If you start two branches with your scheme, they will have two different fake root commits -- when merging these two branches that were independently born, should these fake root commits be treated as equivalents for merge-base computation? If so that introduces a very special case that we currently do not need in a very deep place. But we can already do a merge without common ancestor just fine (I've done one myself and Linus did two), so these 2^160 empty fake commits are not adding value to the system.

Of course, you could use "THE truly universal void" commit that is by convention created in every git repository that has some agreed-upon author/committer/log information as that fake root and uniformly use it everywhere to solve the above, to emulate what we already do. But we have been doing fine without such a fake commit, thank you.

So it's stupid to introduce such a fake commit.  Don't do it.

Now, back to my usual self.

I suspect that an independent branch creation inside an existing repository is not an everyday event, and your complaint is primarily coming from the fact that you somehow wanted to do that recently and there was not a canned way to do so, not because you need to do that very often and the tool is lacking. But for the moment, let's say it is an everyday event and making it easy to do so adds to the general value of our toolset.

I think the real shortcoming of the current set of tools is that while it allows you to be initially on a yet-to-be-born branch, it does not offer you a way to be on another yet-to-be-born branch once you created the first branch.

The command "git branch $newbranch" wants a commit to begin the newly created branch at. Another, "git checkout -b $newbranch", has the same property. If you do not give the starting commit, they conveniently defaults to HEAD, which is inconvenient for what you want.

So it _is_ cumbersome to create (or, "not to create") and be on a yet-to-be-born branch, and as a consequence, it is not possible unless you go down to bare plumbing level to start two unrelated histories in one repository. We do not give you a direct way to do that. An obvious workaround is to create a new repository to start a separate history afresh and fetch that branch in, but if an independent branch creation had a valid purpose and were an everyday event, it certainly is merely a workaround and shows that the toolset is lacking.

Maybe a new option "git checkout --void $newbranchname", which does a rough equivalent of:

	new="refs/heads/$newbranchname"
	git show-ref -q --verify "$new" &&
                die "branch $newbranchname already exists"
	# git ls-files -z | xargs -0 rm -f
        rm -f .git/index
        git symbolic-ref HEAD "$new"

is what you would want to add. I am undecided about the commented out part to remove everything from the working tree, though. On one hand, if you are running "git init-db" in a directory full of files from an extracted tarball, we would not touch any existing files, but on the other hand, since we are interested in creating a totally unrelated history, losing tracked files feels more like the right thing to do.

In any case, I suspect you need to have a bit more convincing and persuasive argument why creating and maintaining more than one, totally unrelated histories in a single repository is necessary.

And "git.git has more than one roots and it looks kinda cool" is not a convincing argument at all. For one thing, these roots were not created in a single repository. The true git root was done in Linus's dircache project back when there was no multiple branches, gitk, git-tools and gitweb were all done in their own separate repositories and later merged in to be part of the current tip of the master.

Todo, html and man roots all come from their own separate repositories and because they are not part of the history of the git development they are still independent.

The real reason I have "todo" in git.git was because the parent directory /pub/scm/git/ was not writable to me at kernel.org and I was too lazy to ask for ownership/permission changed when I took over /pub/scm/git/git.git; I otherwise would have created a separate git-todo.git next to git.git there.

And the reason html and man roots are in git.git is because having "todo" in git.git turned out to be not-so-disastrous as I feared when I first did so, and it seemed like an interesting way to experiment on the "central place to distribute unrelated stuff" idea. But they come from their own separate repositories.

By the way, I would solve B1..B100 merge issue without special casing by:

	git checkout -b merged B$(pick-randomly 1 100)
        i=1
        while test $i -le 100
        do
        	git pull . B$i
                i=$(($i + 1))
	done

Starting from a randomly picked parent and starting from an void (created with "git checkout --void" we discussed above) would give you exactly the same result because pulling B$i on top of B$i (or something that already has merged B$i) is a fast forward.

Junio C Hamano wrote:

We don't show patch for merges by default in git-show, so I don't see why we would want to show root commit diff in git-show by default: those two are very similar.

On Tuesday 2006 November 21 20:03, Jakub Narebski wrote:

$ git init-db $ date > file1 $ git add file1; git commit -a -m "file1 added" $ date > file2 $ git add file2; git commit -a -m "file2 added" $ git show --stat HEAD $ git show --stat HEAD^

I can understand while people get confused. Two patches, both add a file. git-show on one of them shows a stat; on the other it doesn't.

Andy

Andy Parkins wrote:

Well, perhaps "git show --stat" should show diffstat also for root commit, because it shows diffstat for merges (although not patch), but not patch (which usually is huge).

This allows one to see the root commit as a diff in commands like git-log, git-show and git-whatchanged. It also modifies git-diff-tree to act as --root was specified on the commandline. The default is set to true.

Signed-off-by: Peter Baumann <Peter.B.Baumannn@stud.informatik.uni-erlangen.de>
---
I'm not sure if making core.showroot acting on git-diff-tree is the
right thing to do. Please check first bevore applying.

 Documentation/config.txt |    6 ++++++
 builtin-diff-tree.c      |    1 +
 builtin-log.c            |    3 +++
 cache.h                  |    1 +
 config.c                 |    5 +++++
 environment.c            |    1 +
 6 files changed, 17 insertions(+), 0 deletions(-)

Peter Baumann <Peter.B.Baumann@stud.informatik.uni-erlangen.de> writes:

I agree that this "use --root by default" belongs to Porcelain layer, not the plumbing. We would probably want to do this in the same way as we do the color in diff.c::git_diff_ui_config().

On 2006-11-23, Junio C Hamano <junkio@cox.net> wrote:

Sorry, but I don't understand. The color handling doesn't look any different to me than the handling of the other config entrys. Did I miss something?

Peter

Peter Baumann <Peter.B.Baumann@stud.informatik.uni-erlangen.de> writes:

"git-diff-tree --color HEAD" (with explicit command line instruction to color it) still colours its output, but "[diff] color = auto" in ~/.gitconfig would not affect the coloring. Hence, "git-diff-tree HEAD" with the configuration entry gives monochrome.

"git diff HEAD" on the other hand looks at '[diff] color = auto" and will color its output without being told on the command line.

Junio C Hamano <junkio@cox.net> writes:

Since this is about "log" family that deals with revision structure, how about....

-- >8 -- [PATCH] config option log.showroot to show the diff of root commits

From: Peter Baumann <Peter.B.Baumann@stud.informatik.uni-erlangen.de>

This allows one to see a root commit as a diff in commands like git-log, git-show and git-whatchanged.

Signed-off-by: Peter Baumann <Peter.B.Baumannn@stud.informatik.uni-erlangen.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 Documentation/config.txt |    6 ++++++
 builtin-log.c            |   20 ++++++++++++++++----
 2 files changed, 22 insertions(+), 4 deletions(-)

On 2006-11-24, Junio C Hamano <junkio@cox.net> wrote:

[...]

Patch looks good.

One question, what's the difference between git-log -p and git-whatchanged -p? I could only see it differ in the root commit handling.

Interesting parts marked with | as first character of the line.

  git-repo-config --get log.showroot
  false

  git-log -p 8bc9a0c769ac1df7820f2dbf8f7b7d64835e3c68
  commit 8bc9a0c769ac1df7820f2dbf8f7b7d64835e3c68
  Author: Linus Torvalds <torvalds@ppc970.osdl.org>
  Date:   Thu Apr 7 15:16:10 2005 -0700

      Add copyright notices.

      The tool interface sucks (especially "committing" information, which is just
      me doing everything by hand from the command line), but I think this is in
      theory actually a viable way of describing the world. So copyright it.

  diff --git a/cat-file.c b/cat-file.c
  index 74a0a23..d8f0121 100644
  --- a/cat-file.c
  +++ b/cat-file.c
  @@ -1,3 +1,8 @@
  +/*
  + * GIT - The information manager from hell
  + *
  + * Copyright (C) Linus Torvalds, 2005
  + */
   #include "cache.h"

   int main(int argc, char **argv)

  [... rest of the diff ...]

| commit e83c5163316f89bfbde7d9ab23ca2e25604af290
| Author: Linus Torvalds <torvalds@ppc970.osdl.org>
| Date:   Thu Apr 7 15:13:13 2005 -0700
|
|     Initial revision of "git", the information manager from hell
|
  [ ... as specified in log.showroot, no diff of the root commit ...]

  git-whatchanged -p 8bc9a0c769ac1df7820f2dbf8f7b7d64835e3c68
  commit 8bc9a0c769ac1df7820f2dbf8f7b7d64835e3c68
  Author: Linus Torvalds <torvalds@ppc970.osdl.org>
  Date:   Thu Apr 7 15:16:10 2005 -0700
  
      Add copyright notices.
      
      The tool interface sucks (especially "committing" information, which is just
      me doing everything by hand from the command line), but I think this is in
      theory actually a viable way of describing the world. So copyright it.
  
  diff --git a/cat-file.c b/cat-file.c
  index 74a0a23..d8f0121 100644
  --- a/cat-file.c
  +++ b/cat-file.c
  @@ -1,3 +1,8 @@
  +/*
  + * GIT - The information manager from hell
  + *
  + * Copyright (C) Linus Torvalds, 2005
  + */
   #include "cache.h"
   
   int main(int argc, char **argv)

  [... rest of the diff ...]
|
| [ ... no commit message etc from the root commit is shown ...]
|

As you can see, the root commit isn't shown. Is this intentional? Or is it just me not getting the different meaning of git-log and git-whatchanged?

Setting "log.showroot = true" the output of the 2 commands is identical.

Peter

Peter Baumann <Peter.B.Baumann@stud.informatik.uni-erlangen.de> writes:

Some historical background.

The traditional command do do log-minded things was whatchanged and it was implemented as

	git rev-list $revision_args -- $path_limits |
        git diff-tree --stdin --pretty -r $format_args

and whatchanged did not give --root to diff-tree by default. And 'diff-tree' does not show --pretty logs when there is no diff to be shown (which still is true today and is a useful behaviour), hence no mention of the root commit.

On the other hand, "git-log" traditionally looked like this:

	git rev-list --pretty $revision_args 

Back then, there was no path_limits nor even diff options to it.

Later, Linus (with help from others) made the revision walk machinery as callable inside programs other than "rev-list", eliminating the need to pipe rev-list into diff-tree to perform log-minded things. That enriched what "git log" can do, and mostly made "whatchanged" a redundant command. As you may have noticed, there isn't much difference between these two commands in builtin-log.c; their differences are solely what default options for diff and revision machinery are used and are meant to match the traditional behaviour of these commands.

So there shouldn't be any differences, really, when you override their defaults with the likes of -p.

Honestly speaking, I do not think there was _any_ consciously designed intention to handle root commits, either to make these commands behave identically or differently; regarding parentless commits, they just behave the way they happen to behave, because root commits were not something either Linus nor I were interested in.

Given the recent discussion, however, the intention now should be that Porcelain level commands should default to do --root (i.e. when asked to do "diff" to show how a commit without a parent differs from its nonexistent parent, show diff with emptiness).

On 2006-11-24, Junio C Hamano <junkio@cox.net> wrote:

Ah. I see. Thanks for the clarification.

Peter

On Tue, 21 Nov 2006 08:31:30 -0800 (PST), Linus Torvalds wrote:

Agreed. That would be fabulous!

Ah, that's a rationale I wouldn't have guessed.

This is the rationale I was guessing was the cause. It clearly takes a special case in the code to show the root diff, and --root seemed like that special-case implementation leaking into the interface, (where, usually, the user wouldn't expect the first commit to be any different than any other).

This looks like yet another case where a feature was added, and a new command-line option with it, when what was really wanted was a new default.

It seems a reasonable enough decision, but it does have some impacts. Several of the tools don't work in the strange state between git-init and the first git-commit. Some of these are getting worked out now, (such as pull), but Junio was still objecting to fixing diff to work.

There's a decision to have git's internals support this intermediate state, but all the tools should be made completely functional. This is an important things to get right, since this is the first state in which a new user will have her repository, (right after doing git-init-db as the first step in the tutorial). So it's important to make this state functional and not have to explain the "strange" implementation details "Normally, you would have a branch HEAD at this point, so these commands would usually work even though they don't yet, etc. etc."

If the default is fixed, yes.

I agree with that statement. But I also think that for the "new user problems" a new graphical tool for twiddling git options wouldn't make the system any less imposing. On the other hand, getting the defaults to be less surprising would definitely help, (and configuration options can be used to good effect to allow "old-timers" to maintain the behavior they're used to as defaults change).

-Carl

Linus Torvalds <torvalds@osdl.org> writes:

I agree fully with the above.  Let's make it happen.