* 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: 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: 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: [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: 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: 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: 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: 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: 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: [PATCH] builtin-commit: Refresh cache after adding files.
From: Kristian Høgsberg @ 2007-11-09 18:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vhcjvtgz5.fsf@gitster.siamese.dyndns.org>
On Fri, 2007-11-09 at 10:24 -0800, Junio C Hamano wrote:
> 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".
Yup, that's what I expected, and why I couldn't quite understand why the
refresh was necessary.
> 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.
There is some timing involved in this, which may explain the different
results you see. On my laptop I can trigger the add_files_to_cache()
problem roughly 4 out of 5 times, but on my faster desktop, it can't
trigger it.
> 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.
OK, I'll resend the patch with a better description, and add a refresh
call for the user index too, for the git commit <file> case.
cheers,
Kristian
^ permalink raw reply
* [PATCH v2] builtin-commit: Refresh cache after adding files.
From: Kristian Høgsberg @ 2007-11-09 18:50 UTC (permalink / raw)
To: gitster; +Cc: git, Johannes Schindelin, Kristian Høgsberg
This fixes the race in the last test in t3700-add.sh.
add_files_to_cache() should leave the new index stat-clean, but some
times it doesn't. Calling refresh_cache() in a few places works
around this for now.
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
---
Should we add the refresh_cache() call in add_files_to_cache() instead?
builtin-commit.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 7dc8977..81539c8 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -81,6 +81,7 @@ static char *prepare_index(const char **files, const char *prefix)
if (all || also) {
add_files_to_cache(verbose, also ? prefix : NULL, files);
+ refresh_cache(REFRESH_QUIET);
if (write_cache(fd, active_cache, active_nr) || close(fd))
die("unable to write new_index file");
return lock_file.filename;
@@ -94,6 +95,7 @@ static char *prepare_index(const char **files, const char *prefix)
/* update the user index file */
add_files_to_cache(verbose, prefix, files);
+ refresh_cache(REFRESH_QUIET);
if (write_cache(fd, active_cache, active_nr) || close(fd))
die("unable to write new_index file");
@@ -110,6 +112,7 @@ static char *prepare_index(const char **files, const char *prefix)
fd = hold_lock_file_for_update(next_index_lock,
git_path("next-index-%d", getpid()), 1);
add_files_to_cache(verbose, prefix, files);
+ refresh_cache(REFRESH_QUIET);
if (write_cache(fd, active_cache, active_nr) || close(fd))
die("unable to write new_index file");
--
1.5.3.4.206.g58ba4
^ permalink raw reply related
* Re: corrupt object on git-gc
From: Linus Torvalds @ 2007-11-09 18:55 UTC (permalink / raw)
To: Yossi Leybovich; +Cc: git, ae, Yossi Leybovich
In-Reply-To: <4fe79b4b0711091037g8c6c048h29b7d387e75d62bb@mail.gmail.com>
On Fri, 9 Nov 2007, Yossi Leybovich wrote:
>
> 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
Eh. That commit was basically corrupt, because the blob had gotten
removed. I don't even understand how git diff-tree gave a diff with that
file at all (side note: I'd also suggest you just use "git show <commit>"
instead of that complex and _really_ old git-diff-tree incantation).
So no, you didn't "apply the same commit".
But if you have the diff somewhere (perhaps email archive? you sent it to
somebody?) or you can re-create it exactly, then..
Linus
^ permalink raw reply
* Re: corrupt object on git-gc
From: Mike Hommey @ 2007-11-09 19:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Yossi Leybovich, git, ae, Yossi Leybovich
In-Reply-To: <alpine.LFD.0.999.0711091050230.15101@woody.linux-foundation.org>
On Fri, Nov 09, 2007 at 10:55:03AM -0800, Linus Torvalds wrote:
>
>
> On Fri, 9 Nov 2007, Yossi Leybovich wrote:
> >
> > 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
>
> Eh. That commit was basically corrupt, because the blob had gotten
> removed. I don't even understand how git diff-tree gave a diff with that
> file at all (side note: I'd also suggest you just use "git show <commit>"
> instead of that complex and _really_ old git-diff-tree incantation).
>
> So no, you didn't "apply the same commit".
>
> But if you have the diff somewhere (perhaps email archive? you sent it to
> somebody?) or you can re-create it exactly, then..
Or maybe just from memory, by looking at the diff between the previous version
and the next version of the file.
Mike
^ permalink raw reply
* Re: git push failing, unpacker error
From: Nicolas Pitre @ 2007-11-09 19:27 UTC (permalink / raw)
To: Jon Smirl; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <9e4733910711091009q2c6409fdj75cf8051d073c9c5@mail.gmail.com>
On Fri, 9 Nov 2007, Jon Smirl wrote:
> 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.
You might be interested by the following config variables:
core.packedGitWindowSize
core.packedGitLimit
core.deltaBaseCacheLimit
pack.windowMemory
pack.deltaCacheSize
Certainly one or more of them could be tweaked in the remote repo to
solve your problem. But since your problem happens on push then you
should look at the core variables first.
Nicolas
^ permalink raw reply
* [PATCH] print warning/error/fatal messages in one shot
From: Nicolas Pitre @ 2007-11-09 19:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Not doing so is likely to create a messed up display when sent over the
sideband protocol.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/usage.c b/usage.c
index f5e652c..a5fc4ec 100644
--- a/usage.c
+++ b/usage.c
@@ -7,9 +7,9 @@
static void report(const char *prefix, const char *err, va_list params)
{
- fputs(prefix, stderr);
- vfprintf(stderr, err, params);
- fputs("\n", stderr);
+ char msg[256];
+ vsnprintf(msg, sizeof(msg), err, params);
+ fprintf(stderr, "%s%s\n", prefix, msg);
}
static NORETURN void usage_builtin(const char *err)
^ permalink raw reply related
* Re: [PATCH v2] builtin-commit: Refresh cache after adding files.
From: Junio C Hamano @ 2007-11-09 19:37 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git, Johannes Schindelin
In-Reply-To: <1194634238-3308-1-git-send-email-krh@redhat.com>
Kristian Høgsberg <krh@redhat.com> writes:
> This fixes the race in the last test in t3700-add.sh.
> add_files_to_cache() should leave the new index stat-clean, but some
> times it doesn't. Calling refresh_cache() in a few places works
> around this for now.
Sorry, but this description based on my previous observation is
not quite right.
As we have been promising users that "git status" will clear
away the stat dirtiness, we should call refresh_cache() at the
end of prepare_index() regardless of the add_files_to_cache()
issue. We need to refresh_cache() the whole thing, even if we
fixed add_files_to_cache() to add entries that are stat clean,
so this is not a workaround but implementation of the advertised
behaviour. It does hide the problem add_files_to_cache() seems
to have, which we would need to fix independently.
I think the additional refresh_cache() for the user index you
did is also the right thing to do for the same reason.
> Signed-off-by: Kristian Høgsberg <krh@redhat.com>
> ---
>
> Should we add the refresh_cache() call in add_files_to_cache() instead?
I do not think so. These two functions, add_files_to_cache()
and add_file_to_cache(), should make the entries they add to the
index stat-clean, but they should not spend extra cycles
scanning the whole index and re-statting the whole tree to
refresh entries the user did not mention.
^ permalink raw reply
* Re: corrupt object on git-gc
From: Yossi Leybovich @ 2007-11-09 19:41 UTC (permalink / raw)
To: Mike Hommey; +Cc: Linus Torvalds, git, ae, Yossi Leybovich
In-Reply-To: <20071109190707.GA17864@glandium.org>
What I do notice is that this commit involve few files. most of the
file the commit generate the right next SHA1
only for one file its generate broken SHA1
>From the git show <commit> I can see that the file which end up
corrupted is actually being totaly remove from
diff --git a/SymmK/St.c b/SymmK/St.c
index 308806c..4b9458b 100755
--- a/SymmK/St.c
+++ b/SymmK/St.c
@@ -1,1535 +0,0 @@
-MODULE_ALIAS(m_st);
-
-#include <errno.h>
-#include <string.h>
-#include <stdarg.h>
-#include <sys/types.h>
-#include <sys/time.h>
-#include "ib_global_init.h"
....
.....
....
While I tried to delete the whole file and I did not get the right SHA1
Is this soud familiar to some one ?
maybe its releated to issue with some kind of white character I cant see.
Yossi
^ permalink raw reply related
* Re: corrupt object on git-gc
From: Mike Hommey @ 2007-11-09 19:52 UTC (permalink / raw)
To: Yossi Leybovich; +Cc: Linus Torvalds, git, ae, Yossi Leybovich
In-Reply-To: <4fe79b4b0711091141i38044a5o1ef940d9c7afd58f@mail.gmail.com>
On Fri, Nov 09, 2007 at 02:41:05PM -0500, Yossi Leybovich wrote:
> What I do notice is that this commit involve few files. most of the
> file the commit generate the right next SHA1
> only for one file its generate broken SHA1
>
> From the git show <commit> I can see that the file which end up
> corrupted is actually being totaly remove from
>
> diff --git a/SymmK/St.c b/SymmK/St.c
> index 308806c..4b9458b 100755
> --- a/SymmK/St.c
> +++ b/SymmK/St.c
> @@ -1,1535 +0,0 @@
> -MODULE_ALIAS(m_st);
> -
> -#include <errno.h>
> -#include <string.h>
> -#include <stdarg.h>
> -#include <sys/types.h>
> -#include <sys/time.h>
> -#include "ib_global_init.h"
> ....
> .....
> ....
>
>
> While I tried to delete the whole file and I did not get the right SHA1
> Is this soud familiar to some one ?
> maybe its releated to issue with some kind of white character I cant see.
Because the blob is corrupted, git show can't display the correct diff.
You have to guess it by yourself ! The best you can do is look at the
diff for this file between its previous version and the one just after
the corrupted version.
Mike
^ permalink raw reply
* Re: [PATCH] tests: git push mirror mode tests V2
From: Junio C Hamano @ 2007-11-09 20:05 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: git
In-Reply-To: <1194603673.0@pinky>
Andy Whitcroft <apw@shadowen.org> writes:
> +test_expect_success 'push mirror does not create new branches' '
> +
> + mk_repo_pair &&
> + (
> + cd master &&
> + echo one >foo && git add foo && git commit -m one &&
> + git push --mirror up
> + ) &&
> + master_master=$(cd master && git show-ref -s --verify refs/heads/master) &&
> + mirror_master=$(cd mirror && git show-ref -s --verify refs/heads/master) &&
> + test "$master_master" = "$mirror_master"
> +
> +'
I am quite puzzled by this and many other "does not" in the test
description. The --mirror option is advertised as
- newly created will be pushed;
- locally updated will be force pushed;
- locally deleted will be removed.
which makes sense as we do want these things to happen for
"mirrors". Indeed the above updates master branch at the master
repository and makes sure that change is propagated to the
mirror repository. The description should read "push mirror
creates new branches" shouldn't it?
^ permalink raw reply
* Re: [PATCH] git-checkout: Test for relative path use.
From: Robin Rosenberg @ 2007-11-09 19:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Symonds, git, Johannes Schindelin, Andreas Ericsson
In-Reply-To: <7vtznwxl59.fsf@gitster.siamese.dyndns.org>
fredag 09 november 2007 skrev Junio C Hamano:
> David Symonds <dsymonds@gmail.com> writes:
>
> > Signed-off-by: David Symonds <dsymonds@gmail.com>
> > ---
> > Test 5 in this series fails because of a bug in git-ls-files, where
> > git-ls-files t/../
> > (with or without --full-name) returns no files.
>
> Heh, you shouldn't do that ;-)
>
> Seriously, that's a long standing limitation in the code, not to
> deal with arbitrary combination of ups and downs, but I do not
> think there is any fundamental reason to disallow something
> like:
>
> cd Documentation && git ls-files --full-name ../t
>
> Patches welcome.
I'm for allowing it, but then it should really be all over, not just some arbitrary
command. Everywhere or not at all.
-- robin
^ permalink raw reply
* Re: tracking remotes with Git
From: Robin Rosenberg @ 2007-11-09 20:38 UTC (permalink / raw)
To: Ivan Shmakov; +Cc: git
In-Reply-To: <b1e3a35f0711090444g3c31e862g4ef4ef8139927840@mail.gmail.com>
fredag 09 november 2007 skrev Ivan Shmakov:
> I'm using Git (1.5.3.5 debian 1) for about a day or so, and I'm
> quite impressed that it allows tracking remote repositories
> (I've tried CVS and SVN) so easily with `git-cvsimport' and
> `git-svn'. However, I've ran into a couple of problems with
> them:
>
> * 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?
You can pass options to cvsps. My guess is -P "-Z" will do it.
-- robin
^ permalink raw reply
* Re: [PATCH 2/2] --pretty=format: on-demand format expansion
From: René Scharfe @ 2007-11-09 21:13 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Paul Mackerras, Git Mailing List, Pierre Habouzit
In-Reply-To: <Pine.LNX.4.64.0711090122470.4362@racer.site>
Johannes Schindelin schrieb:
> Hi,
>
> On Fri, 9 Nov 2007, Ren? Scharfe wrote:
>
>> strbuf.c | 24 ++++++
>> strbuf.h | 3 +
>> pretty.c | 276 ++++++++++++++++++++++++++++++++++----------------------------
>
> I would be so grateful if you could (trivially) split up this patch into
> the addition of strbuf_expend() (with a small example in the commit
> message), and a patch that uses it in pretty.c.
Makes sense. Will do next time.
Thanks,
René
^ permalink raw reply
* Re: linux-2.6 clone with CygWin git
From: Brian Dessent @ 2007-11-09 21:24 UTC (permalink / raw)
To: Medve Emilian; +Cc: git
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E270174D8A2@az33exm24.fsl.freescale.net>
[ Please note, it's spelled "Cygwin" not "CygWin". ]
Medve Emilian wrote:
> Can somebody please double-check this scenario for me just to validate
> that this happens only due to some particular factors combination on my
> box?
As others have pointed out, this is not a git issue -- you'd have run
into the same problem with a simple tarball of the kernel source because
of the filesystem case insensitivity. Cygwin provides managed mounts to
work around this Win32 limitation, at the cost of non-Cygwin apps seeing
uglified filenames and a decreased effective maximum path length due to
the mangling.
Brian
^ permalink raw reply
* Re: git-gui messes up the diff view on non ASCII characters
From: Michele Ballabio @ 2007-11-09 21:30 UTC (permalink / raw)
To: git; +Cc: Peter Baumann, Shawn O. Pearce
In-Reply-To: <20071109154935.GC28800@xp.machine.xx>
On Friday 09 November 2007, Peter Baumann wrote:
> I'm managing some UTF-8 encoded LaTeX files in git, which include some
> non ASCII characters like the german ä,ö and ü. If I view the diff with
> git-diff on an UTF8 enabled terminal, all looks nice. So does the diff
> view in gitk after I commited my changes. Only git-gui shows some
> "strange" characters, so I assume it is an encoding problem.
>
> I have to admit that I'm totally unaware how this should work, but at
> least I think my configuration is correct here, because otherwise git-diff
> or gitk would show the same behaviour. Is there anything which could be
> done to make git-gui happy, too?
It's a known issue, and already on Shawn's ToDo list. I have to add that
viewing untracked UTF8 files in git-gui works just fine. Weird.
^ permalink raw reply
* git submodules and diffing
From: Sven Herzberg @ 2007-11-09 21:19 UTC (permalink / raw)
To: git-list
Hi,
when I started working with git submodules, I realized that git-diff
only lists the revision ids of a submodule if it has changed. I have
created a repository which includes a diff command for git-submodule,
so you can use it like "gut submodule diff <modules...>"
I pushed my git tree at git://git.imendio.com/sven/git.git
Feel free to look into the changes and request improvements or merge
it into your tree.
Regards,
Sven
PS: Please CC me, I'm not on this list
^ 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