From: Andy Parkins <hidden> Date: 2016-08-11 20:38:54
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
--
Dr Andy Parkins, M Eng (hons), MIEE
From: Petr Baudis <hidden> Date: 2016-08-11 19:23:36
On Tue, Nov 21, 2006 at 07:16:44PM CET, Jakub Narebski wrote:
Petr Baudis wrote:
quoted
On Tue, Nov 21, 2006 at 05:31:30PM CET, Linus Torvalds wrote:
quoted
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).
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?
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 "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
From: Jakub Narebski <hidden> Date: 2016-08-11 19:25:55
Andy Parkins wrote:
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?).
Yes, and git-diff-tree requires --root option if you want to generate
creation diff for initial (parentless, root) commit.
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.
git show --stat --root
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
From: Petr Baudis <hidden> Date: 2016-08-11 19:27:06
On Tue, Nov 21, 2006 at 07:52:59PM CET, Shawn Pearce wrote:
Petr Baudis [off-list ref] wrote:
quoted
On Tue, Nov 21, 2006 at 07:39:56PM CET, Andy Parkins wrote:
quoted
for file in $(git-ls-files); do git-update-index --force-remove $file; done
Before creating the new files and "git-commit"ing.
Ok, this approach looks actually reasonable (contrary to the frequently
suggested rm approach, which is rather dangerous).
Perhaps git checkout --empty could do this?
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...
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 "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
From: Petr Baudis <hidden> Date: 2016-08-11 19:42:45
On Tue, Nov 21, 2006 at 07:38:53PM CET, Olivier Galibert wrote:
On Tue, Nov 21, 2006 at 06:11:19PM +0100, Peter Baumann wrote:
quoted
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.
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.
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.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
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.
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.
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.))
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 Tue, Nov 21, 2006 at 07:39:56PM CET, Andy Parkins wrote:
quoted
for file in $(git-ls-files); do git-update-index --force-remove $file; done
Before creating the new files and "git-commit"ing.
Ok, this approach looks actually reasonable (contrary to the frequently
suggested rm approach, which is rather dangerous).
Perhaps git checkout --empty could do this?
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 06:11:19PM +0100, Peter Baumann wrote:
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.
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.
On Tue, Nov 21, 2006 at 06:11:19PM +0100, Peter Baumann wrote:
quoted
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.
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.
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/
--
From: Andy Parkins <hidden> Date: 2016-08-11 20:13:51
On Tuesday 2006, November 21 18:21, Petr Baudis wrote:
(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.))
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
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
From: Jakub Narebski <hidden> Date: 2016-08-11 20:15:02
Peter Baumann wrote:
On 2006-11-21, Santi Béjar [off-list ref] wrote:
quoted
On 11/21/06, Andy Parkins [off-list ref] wrote:
quoted
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.
You can always use git-ls-tree
quoted
$ 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.
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. :-)
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.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
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.
$ 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.
Why not make --root the default? I also stumbled over this behaviour and
even asked on this list.
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.
And one less "wart" to clean, which another thread is all about. :-)
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".
From: Petr Baudis <hidden> Date: 2016-08-11 20:22:10
On Tue, Nov 21, 2006 at 05:31:30PM CET, Linus Torvalds wrote:
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).
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 "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
From: Jakub Narebski <hidden> Date: 2016-08-11 20:22:43
Petr Baudis wrote:
On Tue, Nov 21, 2006 at 05:31:30PM CET, Linus Torvalds wrote:
quoted
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).
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?
git repo-config show.difftree --root
git repo-config whatchanged.difftree --root
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
From: Petr Baudis <hidden> Date: 2016-08-11 20:28:15
On Tue, Nov 21, 2006 at 07:39:56PM CET, Andy Parkins wrote:
On Tuesday 2006, November 21 18:21, Petr Baudis wrote:
quoted
(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.))
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.
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 "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
From: Carl Worth <hidden> Date: 2016-08-11 20:31:03
On Tue, 21 Nov 2006 08:31:30 -0800 (PST), Linus Torvalds wrote:
I suspect we should make the thing a config option, and default it to
"on".
Agreed. That would be fabulous!
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.
Ah, that's a rationale I wouldn't have guessed.
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".
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.
git didn't end up doing that (and I'm personally pretty happy about it),
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."
So having a config option would solve the problem,
If the default is fixed, yes.
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".
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
From: Peter Baumann <hidden> Date: 2016-08-11 20:32:37
On 2006-11-21, Jakub Narebski [off-list ref] wrote:
Peter Baumann wrote:
quoted
On 2006-11-21, Santi Béjar [off-list ref] wrote:
quoted
On 11/21/06, Andy Parkins [off-list ref] wrote:
quoted
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.
You can always use git-ls-tree
quoted
quoted
$ 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.
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. :-)
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.
Ah. I wasn't aware of this. Thank for this nice tip.
Peter
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".
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.
--
From: Peter Baumann <hidden> Date: 2016-08-11 20:36:47
On 2006-11-21, Santi Béjar [off-list ref] wrote:
On 11/21/06, Andy Parkins [off-list ref] wrote:
quoted
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.
$ 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.
Santi
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
From: Peter Baumann <hidden> Date: 2016-08-11 20:45:50
On 2006-11-21, Linus Torvalds [off-list ref] wrote:
On Tue, 21 Nov 2006, Peter Baumann wrote:
quoted
Why not make --root the default? I also stumbled over this behaviour and
even asked on this list.
I suspect we should make the thing a config option, and default it to
"on".
That would be great.
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 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