* Re: Inconsistencies with git log
From: Peter Baumann @ 2007-11-09 18:39 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, Jon Smirl, Johannes Schindelin, Git Mailing List
In-Reply-To: <7vd4ujtgh7.fsf@gitster.siamese.dyndns.org>
On Fri, Nov 09, 2007 at 10:35:00AM -0800, Junio C Hamano wrote:
> Peter Baumann <waste.manager@gmx.de> writes:
>
> > Hm. I tried to run your 'git log' and 'git log .' example and a diff
> > revealed that the output of those two isn't the same, contrary to what I
> > thought.
> >
> > In the 'git-log .' case, there should be done a history simplification,
> > but then only commits which don't change anything are pruned and AFAIR
> > 'git commit' doesn't allow this. Using core git, one could create commits
> > with the same tree as their parent, but I don't think that all the commits
> > which get removed in the '.' case where produced that way. There has to be
> > another case I can't figure out.
>
> The answer is "merges".
>
> If a merge does not change the tree from one of the ancestors,
> the side branches are pruned out, to give you _one_ explanation
> of how you got there. And by pruning such side branches, you
> get the simpler explanation.
>
> Linus gave the example of "log origin/pu ."; there is at least
> one merge I am aware of that did not change any path (it is the
> one that merges "jc/maint-format-patch-encoding" topic). With
> the path limiter, the merge commit and the two commits that
> leads to it on the side branch are hidden away.
Doh. Could have figured this out myself. But thank your for the explanation.
-Peter
^ permalink raw reply
* Re: Inconsistencies with git log
From: Jakub Narebski @ 2007-11-09 18:37 UTC (permalink / raw)
To: git
In-Reply-To: <7vd4ujtgh7.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Peter Baumann <waste.manager@gmx.de> writes:
>
>> Hm. I tried to run your 'git log' and 'git log .' example and a diff
>> revealed that the output of those two isn't the same, contrary to what I
>> thought.
>>
>> In the 'git-log .' case, there should be done a history simplification,
>> but then only commits which don't change anything are pruned and AFAIR
>> 'git commit' doesn't allow this. Using core git, one could create commits
>> with the same tree as their parent, but I don't think that all the commits
>> which get removed in the '.' case where produced that way. There has to be
>> another case I can't figure out.
>
> The answer is "merges".
>
> If a merge does not change the tree from one of the ancestors,
> the side branches are pruned out, to give you _one_ explanation
> of how you got there. And by pruning such side branches, you
> get the simpler explanation.
>
> Linus gave the example of "log origin/pu ."; there is at least
> one merge I am aware of that did not change any path (it is the
> one that merges "jc/maint-format-patch-encoding" topic). With
> the path limiter, the merge commit and the two commits that
> leads to it on the side branch are hidden away.
Does it mean that "git log" and "git log --full-history ." produce
the same output?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: corrupt object on git-gc
From: Yossi Leybovich @ 2007-11-09 18:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, ae, Yossi Leybovich
In-Reply-To: <alpine.LFD.0.999.0711091000310.15101@woody.linux-foundation.org>
On Nov 9, 2007 1:02 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Fri, 9 Nov 2007, Yossi Leybovich wrote:
> >
> > Ok, tried that and unfortuantly the SHA1 number is apear only one
> >
> > [mellanox@mellanox-compile ib]$ git log --raw --all --full-history --
> > SymmK/St.c | grep 4b9
> > :100755 100755 308806c... 4b9458b3786228369c63936db65827de3cc06200 M SymmK/St.c
>
> Actually, that's not at all "unfortunately", because that implies that
> it's the very *latest* version of that "SymmK/St.c" file. I really think
> you already had it checked out, but didn't try my first suggestion of just
> doing "git hash-object -w SymmK/St.c" which likely would have fixed it
> already (unless you had changed it in your working tree, of course!)
>
Its very old version of the file.
What interesting is the second part of the experiment
I tried to apply the same commit on this file and it leaded to different SHA1
> Linus
>
^ permalink raw reply
* Re: Inconsistencies with git log
From: Linus Torvalds @ 2007-11-09 18:36 UTC (permalink / raw)
To: Peter Baumann; +Cc: Jon Smirl, Johannes Schindelin, Git Mailing List
In-Reply-To: <20071109182248.GD28800@xp.machine.xx>
On Fri, 9 Nov 2007, Peter Baumann wrote:
>
> Hm. I tried to run your 'git log' and 'git log .' example and a diff
> revealed that the output of those two isn't the same, contrary to what I
> thought.
Btw, you can *make* them the same by using
git log --full-history --sparse .
which basically tells git that you do not want any of the history
simplification that git log does by default.
There's two different kinds of simplifications (which is why there are two
kinds of switches above):
- the "simplify merges to just the parent that is identical"
This basically means that if a merge result comes 100% from one of the
parents, by default we will only look at that parent. Using
--full-history avoids this.
- the "dense" history, which removes simple commits that don't make any
changes
This is the "--sparse" thing: it says that we're interested even in
regular commits that simply don't make any changes.
> In the 'git-log .' case, there should be done a history simplification,
> but then only commits which don't change anything are pruned and AFAIR
> 'git commit' doesn't allow this.
Actually, git itself creates these commits under several circumstances:
- you can *force* it. No, "git commit" on its own doesn't allow it, but
you can do it quite easily with "git commit-tree" and setting things
up by hand.
- you can import history from other SCM's. I think all importers will
honor other SCM's, and if they allow empty commits then the end result
will have empty commits in it too!
- merges. This is the common case. You have a "git merge --ours" or
similar, which basically merges just one side (or, even without
"--ours", this is really common for the non-"." case: a merge just
doesn't touch some files at all). Then, the merge simplifier will first
turn it into a "single parent", and then densification will remove that
(now uninteresting) empty merge.
> Using core git, one could create commits with the same tree as their
> parent, but I don't think that all the commits which get removed in the
> '.' case where produced that way. There has to be another case I can't
> figure out.
See above. Three cases, in fact.
Linus
^ permalink raw reply
* Re: Inconsistencies with git log
From: Junio C Hamano @ 2007-11-09 18:35 UTC (permalink / raw)
To: Peter Baumann
Cc: Linus Torvalds, Jon Smirl, Johannes Schindelin, Git Mailing List
In-Reply-To: <20071109182248.GD28800@xp.machine.xx>
Peter Baumann <waste.manager@gmx.de> writes:
> Hm. I tried to run your 'git log' and 'git log .' example and a diff
> revealed that the output of those two isn't the same, contrary to what I
> thought.
>
> In the 'git-log .' case, there should be done a history simplification,
> but then only commits which don't change anything are pruned and AFAIR
> 'git commit' doesn't allow this. Using core git, one could create commits
> with the same tree as their parent, but I don't think that all the commits
> which get removed in the '.' case where produced that way. There has to be
> another case I can't figure out.
The answer is "merges".
If a merge does not change the tree from one of the ancestors,
the side branches are pruned out, to give you _one_ explanation
of how you got there. And by pruning such side branches, you
get the simpler explanation.
Linus gave the example of "log origin/pu ."; there is at least
one merge I am aware of that did not change any path (it is the
one that merges "jc/maint-format-patch-encoding" topic). With
the path limiter, the merge commit and the two commits that
leads to it on the side branch are hidden away.
^ permalink raw reply
* Re: [PATCH] builtin-commit: Refresh cache after adding files.
From: Junio C Hamano @ 2007-11-09 18:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Kristian Høgsberg, git
In-Reply-To: <Pine.LNX.4.64.0711091702190.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 9 Nov 2007, Kristian Høgsberg wrote:
>
>> This fixes the race in the last test int t3700.
>
> Well, it is not a race. My fault. I thought it was.
>
> What you basically did was to make sure that the index is up-to-date after
> adding the files. You might even want to say that in the commit message,
> and only then say that it fixes t3700, too.
Ah, it all makes sense. I should have been more relaxed and
careful when I first read your t3700 patch.
If this were a breakage in racy-git-avoidance code, then
refresh_cache() Kristian added (or "add --refresh" immediately
after "git commit" in the test script) would have been fooled by
the same raciness and wouldn't have changed a thing.
This discussion exposes a problem with add_files_to_cache()
function.
Try this in a clean repository that tracks Makefile:
$ git diff-files --name-only ;# no output
$ touch Makefile
$ git diff-files --name-only
Makefile
$ git add -u
$ git diff-files --name-only
Makefile
$ git add Makefile
$ git diff-files --name-only ;# no output
I think this is a broken behaviour. As long as we are adding
the contents from a path on the filesystem to the corresponding
location in the index, it should sync the stat bits for the
entry in the index with the filesystem to make the entry
stat-clean. IOW, we should not see stat-dirtiness reported
after "add -u".
The funny thing is that add_files_to_cache() run by "git add -u"
calls add_file_to_cache() to add the updated contents for
touched paths, but the latter function is used in the more
explicit "git add Makefile" codepath, without any magic
postprocessing after the function returns to sync the stat
info. IOW, both "add -u" and "add Makefile" ends up calling
add_file_to_cache("Makefile") and I do not see why we are
getting different results.
And add_file_to_cache(), which calls add_file_to_index() on
the_index, does call the fill_stat_cache_info() to sync the stat
information by itself, as it should be. I am still puzzled with
this.
So I think Kristian's two refresh_cache() do fix the issue, but
at the same time I _think_ it is a workaround for broken
add_files_to_cache() behaviour, which is what we should fix.
^ permalink raw reply
* Re: Inconsistencies with git log
From: Peter Baumann @ 2007-11-09 18:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jon Smirl, Johannes Schindelin, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0711090943120.15101@woody.linux-foundation.org>
On Fri, Nov 09, 2007 at 09:53:00AM -0800, Linus Torvalds wrote:
>
>
> On Fri, 9 Nov 2007, Linus Torvalds wrote:
> >
> > In fact, even at the top-of-tree, "git log" and "git log ." are two
> > totally different things [...]
>
> Btw, the reason (and really the *only* reason) this is interesting at all
> is just to show that the notion of "full history" and "relative pathnames"
> really have nothing to do with each other. They really are in totally
> different and orthogonal dimensions.
>
> "Full history" is something that exist *independently* of the pathnames.
>
> So the fact is, "git log" on its own is really about the *project*. It is
> totally pathname-independent, and I'd argue that many people are often
> just interested in the explanations (even though you obviously can also
> see the patches and the files changed too!) so I seriously doubt that this
> is just an implementation issue or my personal hang-up.
>
> In other words "git log" simply is something *global*. It doesn't matter
> where in the tree you are, the end result is the same - it's about the
> project as a whole.
>
> In contrast, "git log <filename>" is fundamentally different. Now you're
> explicitly stating that it's not something global any more, and that it's
> about the *files*. That's also why "git log" and "git log ." are acually
> different even at the top level.
>
> Because when you're interested in the files, by implication you're not
> interested in commits that don't change the files - and there can be such
> commits even when you give the *total* file list.
>
Hm. I tried to run your 'git log' and 'git log .' example and a diff
revealed that the output of those two isn't the same, contrary to what I
thought.
In the 'git-log .' case, there should be done a history simplification,
but then only commits which don't change anything are pruned and AFAIR
'git commit' doesn't allow this. Using core git, one could create commits
with the same tree as their parent, but I don't think that all the commits
which get removed in the '.' case where produced that way. There has to be
another case I can't figure out.
A little confused,
Peter
^ permalink raw reply
* Re: tracking remotes with Git
From: Ivan Shmakov @ 2007-11-09 18:11 UTC (permalink / raw)
To: git; +Cc: Ivan Shmakov
In-Reply-To: <87ode31iki.fsf@graviton.dyn.troilus.org>
>>>>> Michael Poole <mdpoole@troilus.org> writes:
[...]
>> * it looks like `git-cvsimport' uses its own CVS protocol
>> implementation which doesn't support compression; I've tried to
>> clone a repository of a project hosted in CVS since circa 1998 and
>> it 20 MiB or so to obtain revisions until 2000 or so; any ways to
>> minimize traffic?
> What I do is arguably a horrible kludge, but it works well: rsync
> to mirror the CVS repository to my local drive, and cvsimport from
> that. When I was tweaking the import process (command-line options
> and the author conversion file), having the local copy helped a
> lot.
Well, rsync certainly gives CVS the ``disconnected operation''
ability... Any chances to get rsync (or scp/sftp, etc.) access
to the CVS repositories on Savannah? (I'm not one of the
developers of the aforementioned project, if that matters.)
^ permalink raw reply
* Re: Inconsistencies with git log
From: Linus Torvalds @ 2007-11-09 18:14 UTC (permalink / raw)
To: Jon Smirl; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <9e4733910711091004p6b5dd0c3x2c92148a51dd9927@mail.gmail.com>
On Fri, 9 Nov 2007, Jon Smirl wrote:
>
> Should "git log" and "git log path" have two different command names?
Do you think that would really help?
We actually have people complaining about the numebr of git commands
already. And the thing is, "git log" is actually what things like "gitk"
use to visualize the history, and all *those* commands want the two
different modes too! You want a "global history" view in gitk, but you
also want a "file limited view". So having two different commands is
actually what people absolutely DO NOT want.
On the same note: several git commands have totally different fundamental
behaviour based on arguments - in ways even more different than "git log".
At least "git log" always shows a log, the arguments just change what
*part* of the log they show.
For example, think about "git checkout": you can use it to check out
individual files and directories, but you can obviously use it to switch
branches (and create them!) too. That's actually a much bigger difference
than the different modes of "git log", but considering how many people
have complained about "many different commands", I think people seem to be
happier with commands that do somewhat related things just depending on
the kinds of arguments they get.
Linus
^ permalink raw reply
* Re: git push failing, unpacker error
From: Jon Smirl @ 2007-11-09 18:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vtznvtii4.fsf@gitster.siamese.dyndns.org>
On 11/9/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Jon Smirl" <jonsmirl@gmail.com> writes:
>
> > On 11/9/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> >> I updated both sides to current git and it still fails. How do I debug this?
> >> What's causing this, "error: pack-objects died with strange error"?
> >
> > My remote host is running 2.4.32, is git ok on that kernel?
>
> No problem that I am aware of. We are not *that* intimate with
> the kernel.
>
> Do "git-fsck --full" on both repositories pass?
I've just discovered that the hosting company has a mechanism for
killing processes that it believes are consuming too much memory. When
git does it's mmap's it looks like it is using over 512MB of memory
which causes it to get zapped. At least I think this is what is
happening.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: fatal: serious inflate inconsistency
From: bob @ 2007-11-09 18:06 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.0.9999.0711091103540.21255@xanadu.home>
Thank you, Nicolas. I will look into installing a new
zlib.
I moved the two large files into their own repository
and then both repositories worked correctly. So,
it must be something related to the size, hopefully,
in zlib.
Again, thanks for the reponse.
On Nov 9, 2007, at 11:11 AM, Nicolas Pitre wrote:
> On Fri, 9 Nov 2007, bob wrote:
>
>> Sorry, but I am not that familiar with git's internal workings,
>> but here is a failure that I can consistently create. I am
>> running MacOSX 10.4.10 with git compiled from source.
>> Here is the problem output that I am receiving:
>>
>> remote: Generating pack...
>> remote: Done counting 11402 objects.
>> remote: Deltifying 11402 objects...
>> remote: 100% (11402/11402) done
>> Indexing 11402 objects...
>> 100% (11402/11402) done
>> Resolving 3356 deltas...
>> fatal: serious inflate inconsistency
>
> A similar problem (if not the same problem) has been reported on
> MacOSX
> in the past. The conclusion was that either the gcc version or zlib
> version on MacOSX was bad and updating them fixed it. I don't
> remember
> the details now but you should be able to find them in the mail
> archive
> (or maybe someone else remembers).
>
>
> Nicolas
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Inconsistencies with git log
From: Jon Smirl @ 2007-11-09 18:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0711090943120.15101@woody.linux-foundation.org>
On 11/9/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Fri, 9 Nov 2007, Linus Torvalds wrote:
> >
> > In fact, even at the top-of-tree, "git log" and "git log ." are two
> > totally different things [...]
>
> Btw, the reason (and really the *only* reason) this is interesting at all
> is just to show that the notion of "full history" and "relative pathnames"
> really have nothing to do with each other. They really are in totally
> different and orthogonal dimensions.
Should "git log" and "git log path" have two different command names?
> "Full history" is something that exist *independently* of the pathnames.
>
> So the fact is, "git log" on its own is really about the *project*. It is
> totally pathname-independent, and I'd argue that many people are often
> just interested in the explanations (even though you obviously can also
> see the patches and the files changed too!) so I seriously doubt that this
> is just an implementation issue or my personal hang-up.
>
> In other words "git log" simply is something *global*. It doesn't matter
> where in the tree you are, the end result is the same - it's about the
> project as a whole.
>
> In contrast, "git log <filename>" is fundamentally different. Now you're
> explicitly stating that it's not something global any more, and that it's
> about the *files*. That's also why "git log" and "git log ." are acually
> different even at the top level.
>
> Because when you're interested in the files, by implication you're not
> interested in commits that don't change the files - and there can be such
> commits even when you give the *total* file list.
>
> Linus
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: corrupt object on git-gc
From: Linus Torvalds @ 2007-11-09 18:02 UTC (permalink / raw)
To: Yossi Leybovich; +Cc: git, ae, Yossi Leybovich
In-Reply-To: <4fe79b4b0711090953h5b06f7d4l2d17972630a4d355@mail.gmail.com>
On Fri, 9 Nov 2007, Yossi Leybovich wrote:
>
> Ok, tried that and unfortuantly the SHA1 number is apear only one
>
> [mellanox@mellanox-compile ib]$ git log --raw --all --full-history --
> SymmK/St.c | grep 4b9
> :100755 100755 308806c... 4b9458b3786228369c63936db65827de3cc06200 M SymmK/St.c
Actually, that's not at all "unfortunately", because that implies that
it's the very *latest* version of that "SymmK/St.c" file. I really think
you already had it checked out, but didn't try my first suggestion of just
doing "git hash-object -w SymmK/St.c" which likely would have fixed it
already (unless you had changed it in your working tree, of course!)
Linus
^ permalink raw reply
* Re: corrupt object on git-gc
From: Yossi Leybovich @ 2007-11-09 17:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, ae, Yossi Leybovich
In-Reply-To: <alpine.LFD.0.999.0711090758560.15101@woody.linux-foundation.org>
On Nov 9, 2007 11:28 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> and you should now have a line that looks like
>
> 10064 blob 4b9458b3786228369c63936db65827de3cc06200 my-magic-file
That works and now I know the file
>
> The easiest way to do it is to do
>
> git log --raw --all --full-history -- subdirectory/my-magic-file
>
> and that will show you the whole log for that file (please realize that
> the tree you had may not be the top-level tree, so you need to figure out
> which subdirectory it was in on your own), and because you're asking for
> raw output, you'll now get something like
>
> commit abc
> Author:
> Date:
> ..
> :100644 100644 4b9458b... newsha... M somedirectory/my-magic-file
>
>
> commit xyz
> Author:
> Date:
>
> ..
> :100644 100644 oldsha... 4b9458b... M somedirectory/my-magic-file
>
> and this actually tells you what the *previous* and *subsequent* versions
> of that file were! So now you can look at those ("oldsha" and "newsha"
> respectively), and hopefully you have done commits often, and can
> re-create the missing my-magic-file version by looking at those older and
> newer versions!
>
> If you can do that, you can now recreate the missing object with
Ok, tried that and unfortuantly the SHA1 number is apear only one
[mellanox@mellanox-compile ib]$ git log --raw --all --full-history --
SymmK/St.c | grep 4b9
:100755 100755 308806c... 4b9458b3786228369c63936db65827de3cc06200 M
SymmK/St.c
git log --raw --all --full-history -- SymmK/St.c
...
...
commit 597e70e7dc8e06a7cdbe4d9e9727411c964bd023
Author: sleybo <sleybo@mellanox.co.il>
Date: Fri Oct 5 10:41:43 2007 -0400
1. increase QPs parameters - QP is bigger than 4k
2. lock buffers use the dma key
3. add prints
:100755 100755 308806c... 4b9458b3786228369c63936db65827de3cc06200 M
SymmK/St.c
What intersting is that the SHA1 that I looked for apear only once
(only as new SHA1)
So I checkout version of the file which produce the old SHA1 308806c....
[mellanox@mellanox-compile ib-tmp]$ git checkout mlx4-start -- SymmK/St.c
[mellanox@mellanox-compile ib-tmp]$ git hash-object -w SymmK/St.c
308806cf3a864656a49d00edc35b9505abd627a2
than I did
[mellanox@mellanox-compile ib-tmp]$ git diff-tree --stdin -p --pretty
597e70e7dc8e06a7cdbe4d9e9727411c964bd023 > commit-597e70e
( which is the commit SHA1)
[mellanox@mellanox-compile ib-tmp]$ git apply commit-597e70e
Adds trailing whitespace.
../ib/commit-597e70e:1622:
Adds trailing whitespace.
../ib/commit-597e70e:1646: (int)devif->lock_dma +
lockid*sizeof(u64),
warning: 2 lines add whitespace errors.
[mellanox@mellanox-compile ib-tmp]$ git hash-object -w SymmK/St.c
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
So the same commit actual lead to the wrong SHA1
(I tried this flow on different file and it works)
I think I am close but still not there , any suggestions ?
Thanks
Yossi
^ permalink raw reply
* Re: Inconsistencies with git log
From: Linus Torvalds @ 2007-11-09 17:53 UTC (permalink / raw)
To: Jon Smirl; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0711090929130.15101@woody.linux-foundation.org>
On Fri, 9 Nov 2007, Linus Torvalds wrote:
>
> In fact, even at the top-of-tree, "git log" and "git log ." are two
> totally different things [...]
Btw, the reason (and really the *only* reason) this is interesting at all
is just to show that the notion of "full history" and "relative pathnames"
really have nothing to do with each other. They really are in totally
different and orthogonal dimensions.
"Full history" is something that exist *independently* of the pathnames.
So the fact is, "git log" on its own is really about the *project*. It is
totally pathname-independent, and I'd argue that many people are often
just interested in the explanations (even though you obviously can also
see the patches and the files changed too!) so I seriously doubt that this
is just an implementation issue or my personal hang-up.
In other words "git log" simply is something *global*. It doesn't matter
where in the tree you are, the end result is the same - it's about the
project as a whole.
In contrast, "git log <filename>" is fundamentally different. Now you're
explicitly stating that it's not something global any more, and that it's
about the *files*. That's also why "git log" and "git log ." are acually
different even at the top level.
Because when you're interested in the files, by implication you're not
interested in commits that don't change the files - and there can be such
commits even when you give the *total* file list.
Linus
^ permalink raw reply
* Re: git push failing, unpacker error
From: Junio C Hamano @ 2007-11-09 17:51 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910711090643t493b0e6fl2a18390a2f9ab842@mail.gmail.com>
"Jon Smirl" <jonsmirl@gmail.com> writes:
> On 11/9/07, Jon Smirl <jonsmirl@gmail.com> wrote:
>> I updated both sides to current git and it still fails. How do I debug this?
>> What's causing this, "error: pack-objects died with strange error"?
>
> My remote host is running 2.4.32, is git ok on that kernel?
No problem that I am aware of. We are not *that* intimate with
the kernel.
Do "git-fsck --full" on both repositories pass?
^ permalink raw reply
* Re: corrupt object on git-gc
From: Junio C Hamano @ 2007-11-09 17:45 UTC (permalink / raw)
To: Yossi Leybovich; +Cc: Christian Couder, git
In-Reply-To: <6C2C79E72C305246B504CBA17B5500C9029A36F1@mtlexch01.mtl.com>
"Yossi Leybovich" <sleybo@mellanox.co.il> writes:
> Just tried it :
>
> sleybo@SLEYBO-LT /w/work/EMC/ib.071030.001/ib
> $ git-cat-file.exe -p 4b9458b3786228369c63936db65827de3cc06200
> error: corrupt loose object '4b9458b3786228369c63936db65827de3cc06200'
> fatal: Cannot read object 4b9458b3786228369c63936db65827de3cc06200
>
> Is this say something ?
Linus gave a good description of how to diagnose and assess the
extent of damage and potentially recover, so I won't repeat it,
but I am more interested in understanding how the object got
corrupted in the first place.
One thing the above says, with the .exe extension, is that you
are using it on some DOS derived platform. Is this Cygwin? Is
this WinGit? Is this (infamous) "text mount"?
^ permalink raw reply
* Re: [PATCH] builtin-commit: Refresh cache after adding files.
From: Kristian Høgsberg @ 2007-11-09 17:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, git
In-Reply-To: <Pine.LNX.4.64.0711091722520.4362@racer.site>
On Fri, 2007-11-09 at 17:24 +0000, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 9 Nov 2007, Kristian H?gsberg wrote:
>
> > On Fri, 2007-11-09 at 17:05 +0000, Johannes Schindelin wrote:
> >
> > > On Fri, 9 Nov 2007, Kristian Høgsberg wrote:
> > >
> > > > This fixes the race in the last test int t3700.
> > >
> > > Well, it is not a race. My fault. I thought it was.
> > >
> > > What you basically did was to make sure that the index is up-to-date
> > > after adding the files. You might even want to say that in the commit
> > > message, and only then say that it fixes t3700, too.
> >
> > OK, I guess what I was wondering was why write_cache() doesn't write out
> > an up-to-date index.
>
> write_cache() only writes the index, it does not update it.
>
> > Do we need a call to refresh_cache() when we update the user cache but
> > commit an index created from read_tree+add_files? I.e. after the
> > add_files_to_index() call on line 97? The shell script doesn't do this,
> > it only runs update-index --refresh for the index that gets committed.
>
> I think it would be sane to do so.
>
> IIUC this basically means that "git add <file> && git commit" should do
> the same to the cache as "git commit <file>".
No, that's equivalent to "git commit -i <file>". If you just say "git
commit <file>", that will create a temporary index initialized to HEAD,
add file to that index and the regular (user) index, and then commit the
temporary index file. The shell script doesn't refresh the regular
index in this case. I think it makes sense to add that, but it will be
a subtle difference in behaviour.
cheers,
Kristian
^ permalink raw reply
* Re: Inconsistencies with git log
From: Jakub Narebski @ 2007-11-09 17:41 UTC (permalink / raw)
To: git
In-Reply-To: <9e4733910711090920m6b0b7704x7c5a3849215f385c@mail.gmail.com>
Jon Smirl wrote:
> The summary of this is that new users do not expect "git log" to give
> them the whole log when the command is executed in a subdirectory.
> This causes a training burden because of the unexpected behavior. They
> try 'git log' and then I have to tell them to use "git log ."
That's too bad, that they have to unlearn bad expectations. Having
"git log" _always_ meaning whole history is very useful. You can always
do "git log ." (two characters more); how do you propose to request
full history from within subdirectory if by default "git log" output
would limit history to current directory only?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Inconsistencies with git log
From: Linus Torvalds @ 2007-11-09 17:38 UTC (permalink / raw)
To: Jon Smirl; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <9e4733910711090920m6b0b7704x7c5a3849215f385c@mail.gmail.com>
On Fri, 9 Nov 2007, Jon Smirl wrote:
>
> The summary of this is that new users do not expect "git log" to give
> them the whole log when the command is executed in a subdirectory.
> This causes a training burden because of the unexpected behavior. They
> try 'git log' and then I have to tell them to use "git log ."
No. The summary is that *you* are confused.
The fact is, "git log" always has given the whole log, and there is no
confusion at all. The only people who may be confused are people who
misread the documentation on purpose, or who came from some broken other
SCM, and are confused just because of *that*.
Git makes it very clear indeed at all points that it tracks whole history.
It's a big deal. We *make* a big deal about it, and "git log" follows that
very consistently.
In fact, even at the top-of-tree, "git log" and "git log ." are two
totally different things, even if in practice the differences are often
hard to see. But one gives the "full history", and the other gives the
"simplified history for the pathnames given", and the two are REALLY
REALLY different.
Try it. Do
git log origin/pu > full
git log origin/pu . > limited
in the git tree, and look at the differences (it might be useful to use
gitk instead, and look at where the differences start! That visual
difference is going to give you a lot more of an "Ahaa!" moment when you
understand it). When you can explain and understand those differences,
then you *really* understand git (and quite frankly, it's actually rather
simple, but you have to really *think* about what those things things
are).
Now, for normal use you never need to really to care. Git does a lot of
things, and some random user will seldom need the full power of git, nor
do they need to really care about why "git log ." and "git log" are
actually not the same thing at all, even at the top level.
But you're blaming git for your *own* confusion, which probably comes from
crap systems that don't even know what "history" is because they can't
really track it right anyway.
Linus
^ permalink raw reply
* Re: [PATCH] add a howto document about corrupted blob recovery
From: Johannes Schindelin @ 2007-11-09 17:30 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <alpine.LFD.0.9999.0711091221210.21255@xanadu.home>
Hi,
On Fri, 9 Nov 2007, Nicolas Pitre wrote:
> Extracted from a post by Linus on the mailing list.
Heh. I was hoping that somebody would be quicker than me...
Ciao,
Dscho
^ permalink raw reply
* [PATCH] add a howto document about corrupted blob recovery
From: Nicolas Pitre @ 2007-11-09 17:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <alpine.LFD.0.999.0711090758560.15101@woody.linux-foundation.org>
Extracted from a post by Linus on the mailing list.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
On Fri, 9 Nov 2007, Linus Torvalds wrote:
> But since you don't seem to have backups right now, the good news is that
> especially with a single blob being corrupt, these things *are* somewhat
> debuggable.
I was in the process of writing a similar message, but Linus was quicker
and his version is actually much nicer. Certainly good howto material.
diff --git a/Documentation/howto/recover-corrupted-blob-object.txt b/Documentation/howto/recover-corrupted-blob-object.txt
new file mode 100644
index 0000000..9b6853c
--- /dev/null
+++ b/Documentation/howto/recover-corrupted-blob-object.txt
@@ -0,0 +1,134 @@
+Date: Fri, 9 Nov 2007 08:28:38 -0800 (PST)
+From: Linus Torvalds <torvalds@linux-foundation.org>
+Subject: corrupt object on git-gc
+Abstract: Some tricks to reconstruct blob objects in order to fix
+ a corrupted repository.
+
+On Fri, 9 Nov 2007, Yossi Leybovich wrote:
+>
+> Did not help still the repository look for this object?
+> Any one know how can I track this object and understand which file is it
+
+So exactly *because* the SHA1 hash is cryptographically secure, the hash
+itself doesn't actually tell you anything, in order to fix a corrupt
+object you basically have to find the "original source" for it.
+
+The easiest way to do that is almost always to have backups, and find the
+same object somewhere else. Backups really are a good idea, and git makes
+it pretty easy (if nothing else, just clone the repository somewhere else,
+and make sure that you do *not* use a hard-linked clone, and preferably
+not the same disk/machine).
+
+But since you don't seem to have backups right now, the good news is that
+especially with a single blob being corrupt, these things *are* somewhat
+debuggable.
+
+First off, move the corrupt object away, and *save* it. The most common
+cause of corruption so far has been memory corruption, but even so, there
+are people who would be interested in seeing the corruption - but it's
+basically impossible to judge the corruption until we can also see the
+original object, so right now the corrupt object is useless, but it's very
+interesting for the future, in the hope that you can re-create a
+non-corrupt version.
+
+So:
+
+> ib]$ mv .git/objects/4b/9458b3786228369c63936db65827de3cc06200 ../
+
+This is the right thing to do, although it's usually best to save it under
+it's full SHA1 name (you just dropped the "4b" from the result ;).
+
+Let's see what that tells us:
+
+> ib]$ git-fsck --full
+> broken link from tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
+> to blob 4b9458b3786228369c63936db65827de3cc06200
+> missing blob 4b9458b3786228369c63936db65827de3cc06200
+
+Ok, I removed the "dangling commit" messages, because they are just
+messages about the fact that you probably have rebased etc, so they're not
+at all interesting. But what remains is still very useful. In particular,
+we now know which tree points to it!
+
+Now you can do
+
+ git ls-tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
+
+which will show something like
+
+ 100644 blob 8d14531846b95bfa3564b58ccfb7913a034323b8 .gitignore
+ 100644 blob ebf9bf84da0aab5ed944264a5db2a65fe3a3e883 .mailmap
+ 100644 blob ca442d313d86dc67e0a2e5d584b465bd382cbf5c COPYING
+ 100644 blob ee909f2cc49e54f0799a4739d24c4cb9151ae453 CREDITS
+ 040000 tree 0f5f709c17ad89e72bdbbef6ea221c69807009f6 Documentation
+ 100644 blob 1570d248ad9237e4fa6e4d079336b9da62d9ba32 Kbuild
+ 100644 blob 1c7c229a092665b11cd46a25dbd40feeb31661d9 MAINTAINERS
+ ...
+
+and you should now have a line that looks like
+
+ 10064 blob 4b9458b3786228369c63936db65827de3cc06200 my-magic-file
+
+in the output. This already tells you a *lot* it tells you what file the
+corrupt blob came from!
+
+Now, it doesn't tell you quite enough, though: it doesn't tell what
+*version* of the file didn't get correctly written! You might be really
+lucky, and it may be the version that you already have checked out in your
+working tree, in which case fixing this problem is really simple, just do
+
+ git hash-object -w my-magic-file
+
+again, and if it outputs the missing SHA1 (4b945..) you're now all done!
+
+But that's the really lucky case, so let's assume that it was some older
+version that was broken. How do you tell which version it was?
+
+The easiest way to do it is to do
+
+ git log --raw --all --full-history -- subdirectory/my-magic-file
+
+and that will show you the whole log for that file (please realize that
+the tree you had may not be the top-level tree, so you need to figure out
+which subdirectory it was in on your own), and because you're asking for
+raw output, you'll now get something like
+
+ commit abc
+ Author:
+ Date:
+ ..
+ :100644 100644 4b9458b... newsha... M somedirectory/my-magic-file
+
+
+ commit xyz
+ Author:
+ Date:
+
+ ..
+ :100644 100644 oldsha... 4b9458b... M somedirectory/my-magic-file
+
+and this actually tells you what the *previous* and *subsequent* versions
+of that file were! So now you can look at those ("oldsha" and "newsha"
+respectively), and hopefully you have done commits often, and can
+re-create the missing my-magic-file version by looking at those older and
+newer versions!
+
+If you can do that, you can now recreate the missing object with
+
+ git hash-object -w <recreated-file>
+
+and your repository is good again!
+
+(Btw, you could have ignored the fsck, and started with doing a
+
+ git log --raw --all
+
+and just looked for the sha of the missing object (4b9458b..) in that
+whole thing. It's up to you - git does *have* a lot of information, it is
+just missing one particular blob version.
+
+Trying to recreate trees and especially commits is *much* harder. So you
+were lucky that it's a blob. It's quite possible that you can recreate the
+thing.
+
+ Linus
^ permalink raw reply related
* Re: [PATCH] builtin-commit: Refresh cache after adding files.
From: Johannes Schindelin @ 2007-11-09 17:24 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: gitster, git
In-Reply-To: <1194628412.30909.7.camel@hinata.boston.redhat.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1128 bytes --]
Hi,
On Fri, 9 Nov 2007, Kristian H?gsberg wrote:
> On Fri, 2007-11-09 at 17:05 +0000, Johannes Schindelin wrote:
>
> > On Fri, 9 Nov 2007, Kristian Høgsberg wrote:
> >
> > > This fixes the race in the last test int t3700.
> >
> > Well, it is not a race. My fault. I thought it was.
> >
> > What you basically did was to make sure that the index is up-to-date
> > after adding the files. You might even want to say that in the commit
> > message, and only then say that it fixes t3700, too.
>
> OK, I guess what I was wondering was why write_cache() doesn't write out
> an up-to-date index.
write_cache() only writes the index, it does not update it.
> Do we need a call to refresh_cache() when we update the user cache but
> commit an index created from read_tree+add_files? I.e. after the
> add_files_to_index() call on line 97? The shell script doesn't do this,
> it only runs update-index --refresh for the index that gets committed.
I think it would be sane to do so.
IIUC this basically means that "git add <file> && git commit" should do
the same to the cache as "git commit <file>".
Thanks,
Dscho
^ permalink raw reply
* Re: Inconsistencies with git log
From: Jon Smirl @ 2007-11-09 17:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0711090747210.15101@woody.linux-foundation.org>
On 11/9/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Wed, 7 Nov 2007, Jon Smirl wrote:
> >
> > Then why doesn't this work?
>
> Jon, lookie here:
>
> > jonsmirl@terra:~/mpc5200b$ git log Documentation
> > all the log for Documentation....
> > jonsmirl@terra:~/mpc5200b$ cd Documentation
> > jonsmirl@terra:~/mpc5200b/Documentation$ git log Documentation
>
> Instead of the above sequence, do:
>
> jonsmirl@terra:~/mpc5200b$ ls Documentation
> .. all the files in Documentation ..
> jonsmirl@terra:~/mpc5200b$ cd Documentation
> jonsmirl@terra:~/mpc5200b/Documentation$ ls Documentation
>
> and now tell me, why doesn't that work? And can't you see how *stupid*
> your complaint is?
I never expected that to work it was just a response to the earlier
misstatement that the paths were relative to the project root. It
demonstrated that they were not.
The summary of this is that new users do not expect "git log" to give
them the whole log when the command is executed in a subdirectory.
This causes a training burden because of the unexpected behavior. They
try 'git log' and then I have to tell them to use "git log ."
>
> The rule is:
> - git log without arguments gives the whole, unabridged, and full
> history.
> - git log with arguments gives the *simplified* history for those
> arguments.
>
> But the arguments - if they exist - are always relative. You want things
> like filename completion to work. Making the pathname arguments absolute
> would be horrible. Think about it: it's just much more logical to always
> be able to say "I want the log for file xyz", and you don't want that to
> be absolute, since you shouldn't care where in the tree you are.
>
> And the fact that git log gives the whole history when you don't give any
> arguments at all IN NO WAY makes it any more sensible to give "absolute"
> pathnames. The history being "whole" has nothing to do with the pathnames
> being "absolute". The two are totally independent issues.
>
> Linus
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: git rebase --skip
From: Jeff King @ 2007-11-09 17:20 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Björn Steinbrink, Andreas Ericsson,
Mike Hommey, git
In-Reply-To: <Pine.LNX.4.64.0711091056530.4362@racer.site>
On Fri, Nov 09, 2007 at 10:59:57AM +0000, Johannes Schindelin wrote:
> Isn't having to say "--skip" instead of "--continue" enough? Some people
> might complain that it's too easy to get your fingers wired to type
> --skip.
They already have.
> Besides, after my patch to rebase on a detached HEAD, it is very easy to
> go back to the original state and try again.
But you are losing any work you did in resolving merges.
But I don't personally have this problem, so I will stop defending those
who claim to, and let them speak for themselves (hopefully with
patches!).
-Peff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox