* 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
* Re: linux-2.6 clone with CygWin git
From: Pascal Obry @ 2007-11-09 17:16 UTC (permalink / raw)
To: Medve Emilian, git
In-Reply-To: <20071109150306.GA20531@old.davidb.org>
David Brown a écrit :
> It's because of the case-insensitive nature of the filesystem. The kernel
> contains both an xt_connmark.h and an xt_CONNMARK.h file, that are
> different. But only one exists on Windows, so git sees the first one it
> wrote as having been modified.
Probably not something for the list... but if you ask me this is just
bad practice anyway. Casing has no semantic, it is nonsense to have two
files with the same name with different casing!
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: [PATCH] builtin-commit: Refresh cache after adding files.
From: Kristian Høgsberg @ 2007-11-09 17:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, git
In-Reply-To: <Pine.LNX.4.64.0711091702190.4362@racer.site>
On Fri, 2007-11-09 at 17:05 +0000, Johannes Schindelin wrote:
> Hi,
>
> 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. I'll send an updated patch. 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.
Kristian
^ permalink raw reply
* Re: [PATCH] builtin-commit: Refresh cache after adding files.
From: Johannes Schindelin @ 2007-11-09 17:05 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: gitster, git
In-Reply-To: <1194626427-2419-1-git-send-email-krh@redhat.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 368 bytes --]
Hi,
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.
Thanks,
Dscho
^ permalink raw reply
* Re: corrupt object on git-gc
From: Nicolas Pitre @ 2007-11-09 16:52 UTC (permalink / raw)
To: Yossi Leybovich; +Cc: Johannes Sixt, Andreas Ericsson, git, Yossi Leybovich
In-Reply-To: <4fe79b4b0711090831o30d2880dh3d9ec0bb0503f77a@mail.gmail.com>
On Fri, 9 Nov 2007, Yossi Leybovich wrote:
> On Nov 9, 2007 11:03 AM, Nicolas Pitre <nico@cam.org> wrote:
> > On Fri, 9 Nov 2007, Yossi Leybovich wrote:
> >
> > > On Nov 9, 2007 10:34 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> > > > Yossi Leybovich schrieb:
> > > > > [about corrupt loose object '4b9458b3786228369c63936db65827de3cc06200']
> > > >
> > > > You can try to create a clone (after you have fixed up the artificial
> > > > breakages that you made). If that goes well, then the bad object is
> > > > referenced only from reflogs.
> > > >
> > >
> > >
> > > git clone ib ib-clone
> > > Initialized empty Git repository in /home/mellanox/work/symm/ib-clone/.git/
> > > 0 blocks
> >
> > Please try "file://ib" instead. Otherwise the clone will only hardlink
> > files to the original repository.
> >
> >
>
> And agian the corruption pop up again , so clone does not help
OK that means that the object is really part of your active history.
Linus just posted a nice summary of your only option left. If you
manage to recreate the damaged object then it would be nice of you if
you could provide us with both the bad and the good one for analysis.
Nicolas
^ permalink raw reply
* Re: tracking remotes with Git
From: Michael Poole @ 2007-11-09 16:37 UTC (permalink / raw)
To: Ivan Shmakov; +Cc: git
In-Reply-To: <b1e3a35f0711090444g3c31e862g4ef4ef8139927840@mail.gmail.com>
Ivan Shmakov writes:
> 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?
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.
Michael Poole
^ permalink raw reply
* Re: [PATCH 1/2] Add strchrnul()
From: Jakub Narebski @ 2007-11-09 16:44 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: René Scharfe, Junio C Hamano, Git Mailing List
In-Reply-To: <473467C4.8020208@op5.se>
Andreas Ericsson wrote:
> Jakub Narebski wrote:
>> René Scharfe wrote:
>>> +#if !defined(__GLIBC__) && !__GLIBC_PREREQ(2, 1)
>>> +# define strchrnul(s, c) gitstrchrnul(s, c)
>>> +static inline char *gitstrchrnul(const char *s, int c)
>>> +{
>>> + while (*s && *s != c)
>>> + s++;
>>> +
>>> + return (char *)s;
>>> +}
>>> +#endif
>>> +
>>
>> This is good solution, although I'm not sure about the check itself.
>> What if somebody has libc which is not glibc, but it does have
>> strchrnul?
>
> They most likely fall into the minority that get to suffer from
> using code that's as fast as what's in there today, although
> a bit more readable. The glibc optimization is really only
> worthwhile for architectures where strchrnul()-like operations
> have microcode support, or when it's used on large strings.
If we end up using this solution, then adding test for strchrnul in the
configure (configure.ac and config.mak.in) is not needed...
> YMMV. I suppose rewriting it as
>
> #if defined(__GLIBC_PREREQ) && __GLIBC_PREREQ(2, 1)
#if !defined(HAVE_STRCHRNUL) && \
defined(__GLIBC_PREREQ) && __GLIBC_PREREQ(2, 1)
> # define HAVE_STRCHRNUL
> #endif
>
> #ifdef HAVE_STRCHRNUL
> ...
>
> would work too, and will provide an easier way out for other fellas
> wanting to say "Hey, my favourite solaris libc has this too!". OTOH,
> that rewrite can be done when the first such case appears.
...but if we end up using this version (be it HAVE_STRCHRNUL, or
NO_STRCHRNUL), then test for strchrnul in ./configure is I think
necessary.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] builtin-commit: Refresh cache after adding files.
From: Kristian Høgsberg @ 2007-11-09 16:40 UTC (permalink / raw)
To: gitster; +Cc: git, Johannes Schindelin, Kristian Høgsberg
This fixes the race in the last test int t3700.
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
---
I'm basically just copying what git-commit.sh does, but I'll admit to not
quite understanding why it's necessary. It does fix the race in t3700 though.
Applies on top of pu.
cheers,
Kristian
builtin-commit.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 7dc8977..19862df 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;
@@ -110,6 +111,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: cogito remote branch
From: Jon Loeliger @ 2007-11-09 16:28 UTC (permalink / raw)
To: MichaelTiloDressel@t-online.de; +Cc: Johannes Schindelin, Git List
In-Reply-To: <1IqWRW-0QQ4LA0@fwd26.aul.t-online.de>
On Fri, 2007-11-09 at 10:10, MichaelTiloDressel@t-online.de wrote:
> There are just some features
> which simplify things for me in cogito. E.g. in cogito in the simplest
> way you don't need to be aware of the index. While with git
> you have to remember to add the changes to the index explicitly
> to get them committed.
>
> Cheers,
> Michael
"git commit -a ..." might be useful for you.
Other lingering cogito-isms you think are lacking in git?
jdl
^ permalink raw reply
* Re: corrupt object on git-gc
From: Yossi Leybovich @ 2007-11-09 16:31 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Johannes Sixt, Andreas Ericsson, git, Yossi Leybovich
In-Reply-To: <alpine.LFD.0.9999.0711091102370.21255@xanadu.home>
On Nov 9, 2007 11:03 AM, Nicolas Pitre <nico@cam.org> wrote:
> On Fri, 9 Nov 2007, Yossi Leybovich wrote:
>
> > On Nov 9, 2007 10:34 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> > > Yossi Leybovich schrieb:
> > > > [about corrupt loose object '4b9458b3786228369c63936db65827de3cc06200']
> > >
> > > You can try to create a clone (after you have fixed up the artificial
> > > breakages that you made). If that goes well, then the bad object is
> > > referenced only from reflogs.
> > >
> >
> >
> > git clone ib ib-clone
> > Initialized empty Git repository in /home/mellanox/work/symm/ib-clone/.git/
> > 0 blocks
>
> Please try "file://ib" instead. Otherwise the clone will only hardlink
> files to the original repository.
>
>
And agian the corruption pop up again , so clone does not help
[mellanox@mellanox-compile ib]$ git clone file://ib ib-clone
Initialized empty Git repository in /home/mellanox/work/symm/ib-clone/.git/
remote: Generating pack...
remote: Counting objects: 276
Done counting 3288 objects.
remote: Deltifying 3288 objects...
remote: error: remote: corrupt loose object
'4b9458b3786228369c63936db65827de3cc06200'remote:
remote: fatal: remote: object 4b9458b3786228369c63936db65827de3cc06200
cannot be readremote:
error: git-upload-pack: git-pack-objects died with error.
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: index-pack died with error code 128
fetch-pack from 'file://ib' failed.
fatal: git-upload-pack: aborting due to possible repository corruption
on the remote side.
> Nicolas
>
^ permalink raw reply
* Re: corrupt object on git-gc
From: Linus Torvalds @ 2007-11-09 16:28 UTC (permalink / raw)
To: Yossi Leybovich; +Cc: git, ae, Yossi Leybovich
In-Reply-To: <4fe79b4b0711090538wf483ce7j89c518962e89780e@mail.gmail.com>
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 *becuse* 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
* Re: git rebase --skip
From: J. Bruce Fields @ 2007-11-09 16:26 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jeff King, Junio C Hamano, Björn Steinbrink,
Andreas Ericsson, Mike Hommey, git
In-Reply-To: <20071109161945.GA26826@fieldses.org>
On Fri, Nov 09, 2007 at 11:19:46AM -0500, J. Bruce Fields wrote:
> On Fri, Nov 09, 2007 at 10:59:57AM +0000, Johannes Schindelin wrote:
> > Hi,
> >
> > On Thu, 8 Nov 2007, Jeff King wrote:
> >
> > > So I am fine with the original patch (unconditional reset --hard), but
> > > it would be nice to see the people who care submit concrete proposals
> > > for such a safety valve.
> >
> > 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.
> >
> > In that case, I might beg to differ for two reasons: --skip is definitely
> > not the default operation, so the fingers do not get any chance to do
> > that, and even if, they would get wired to --force --skip just as easily.
> >
> > Besides, after my patch to rebase on a detached HEAD, it is very easy to
> > go back to the original state and try again.
>
> We can't make --skip do an automatic reset --hard. I expect --skip to
> tell me if I haven't finished resolving conflicts. If it doesn't do
> that, I'll lose work. I can't be the only user with that expectation.
>
> (To be more specific: the work I lose is the work spent resolving how
> however many conflicts I've dealt with so far. It isn't always the case
> that I get to a certain point in a rebase and say "ah, yes, I know this
> is already applied, I can reset and skip it." More often I want to go
> through each conflict and decide individually. So I do that for a few,
> I run --continue or --skip when I think I'm done (but don't actually
> check first, 'cause I count on rebase to do that), then fix up anything
> remaining.)
(Eh, now that I think of it: what I actually usually do is run
--continue, git says there's one more conflict, I fix that up and run
--continue again, it tells me there's nothing to commit, I say huh?
Then eventually I remember I need to run --skip instead, cursing it for
not just figuring that out on its own.... So actually it may be that
the only time I run --skip is after --continue has told me I need to. I
can't *swear* that that's the case, so I'm still nervous about the idea
of --skip automatically resetting. Oh well. Take that one user's
experience for what it's worth.)
--b.
^ permalink raw reply
* Re: git rebase --skip
From: J. Bruce Fields @ 2007-11-09 16:19 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jeff King, 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:
> Hi,
>
> On Thu, 8 Nov 2007, Jeff King wrote:
>
> > So I am fine with the original patch (unconditional reset --hard), but
> > it would be nice to see the people who care submit concrete proposals
> > for such a safety valve.
>
> 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.
>
> In that case, I might beg to differ for two reasons: --skip is definitely
> not the default operation, so the fingers do not get any chance to do
> that, and even if, they would get wired to --force --skip just as easily.
>
> Besides, after my patch to rebase on a detached HEAD, it is very easy to
> go back to the original state and try again.
We can't make --skip do an automatic reset --hard. I expect --skip to
tell me if I haven't finished resolving conflicts. If it doesn't do
that, I'll lose work. I can't be the only user with that expectation.
(To be more specific: the work I lose is the work spent resolving how
however many conflicts I've dealt with so far. It isn't always the case
that I get to a certain point in a rebase and say "ah, yes, I know this
is already applied, I can reset and skip it." More often I want to go
through each conflict and decide individually. So I do that for a few,
I run --continue or --skip when I think I'm done (but don't actually
check first, 'cause I count on rebase to do that), then fix up anything
remaining.)
--b.
^ permalink raw reply
* Re: corrupt object on git-gc
From: Nicolas Pitre @ 2007-11-09 16:17 UTC (permalink / raw)
To: Alex Riesen; +Cc: Yossi Leybovich, git
In-Reply-To: <20071109081035.GA2794@steel.home>
On Fri, 9 Nov 2007, Alex Riesen wrote:
> Yossi Leybovich, Fri, Nov 09, 2007 00:59:47 +0100:
> > I wonder if someone can help in this error
> > I tried to do git-gc and got error on corrupted object.
> >
> > I do the following:
> >
> > $ git-gc
> > Generating pack...
> > Done counting 3037 objects.
> > Deltifying 3037 objects...
> > error: corrupt loose object '4b9458b3786228369c63936db65827de3cc06200'
>
> It is loose. Nothing uses it in this repository.
Very wrong. Loose object != unreachable object.
Nicolas
^ permalink raw reply
* Re: cogito remote branch
From: MichaelTiloDressel @ 2007-11-09 16:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711091417060.4362@racer.site>
>> Such a pity. We just got used to it.
>t's open source. You are free to use/maintain it.
True. But I'm not sure if it would be worth the effort.
I don't mind using git directly. There are just some features
which simplify things for me in cogito. E.g. in cogito in the simplest
way you don't need to be aware of the index. While with git
you have to remember to add the changes to the index explicitly
to get them committed.
Cheers,
Michael
^ permalink raw reply
* Re: fatal: serious inflate inconsistency
From: Nicolas Pitre @ 2007-11-09 16:11 UTC (permalink / raw)
To: bob; +Cc: git
In-Reply-To: <6C571F0D-442F-49B9-8CF8-D7DACB41FC1A@mac.com>
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
^ permalink raw reply
* Re: corrupt object on git-gc
From: Nicolas Pitre @ 2007-11-09 16:03 UTC (permalink / raw)
To: Yossi Leybovich; +Cc: Johannes Sixt, Andreas Ericsson, git, Yossi Leybovich
In-Reply-To: <4fe79b4b0711090753r52abd3e1ree64271c0fa229f6@mail.gmail.com>
On Fri, 9 Nov 2007, Yossi Leybovich wrote:
> On Nov 9, 2007 10:34 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> > Yossi Leybovich schrieb:
> > > [about corrupt loose object '4b9458b3786228369c63936db65827de3cc06200']
> >
> > You can try to create a clone (after you have fixed up the artificial
> > breakages that you made). If that goes well, then the bad object is
> > referenced only from reflogs.
> >
>
>
> git clone ib ib-clone
> Initialized empty Git repository in /home/mellanox/work/symm/ib-clone/.git/
> 0 blocks
Please try "file://ib" instead. Otherwise the clone will only hardlink
files to the original repository.
Nicolas
^ permalink raw reply
* Re: corrupt object on git-gc
From: Johannes Sixt @ 2007-11-09 16:03 UTC (permalink / raw)
To: Yossi Leybovich; +Cc: Andreas Ericsson, git, Yossi Leybovich
In-Reply-To: <4fe79b4b0711090753r52abd3e1ree64271c0fa229f6@mail.gmail.com>
Yossi Leybovich schrieb:
> On Nov 9, 2007 10:34 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>> Yossi Leybovich schrieb:
>>> [about corrupt loose object '4b9458b3786228369c63936db65827de3cc06200']
>> You can try to create a clone (after you have fixed up the artificial
>> breakages that you made). If that goes well, then the bad object is
>> referenced only from reflogs.
>>
>
>
> git clone ib ib-clone
> Initialized empty Git repository in /home/mellanox/work/symm/ib-clone/.git/
> 0 blocks
Make this:
git clone file:///home/mellanox/work/symm/ib ib-clone
otherwise you get a hard-linked identical copy, but you want to use the git
protocol to create the clone.
-- Hannes
^ permalink raw reply
* Re: Inconsistencies with git log
From: Linus Torvalds @ 2007-11-09 15:54 UTC (permalink / raw)
To: Jon Smirl; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <9e4733910711071609t3e5412f1mf02e501b2d820bb3@mail.gmail.com>
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?
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
^ permalink raw reply
* Re: corrupt object on git-gc
From: Yossi Leybovich @ 2007-11-09 15:53 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Andreas Ericsson, git, Yossi Leybovich
In-Reply-To: <47347E0E.1040205@viscovery.net>
On Nov 9, 2007 10:34 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Yossi Leybovich schrieb:
> > [about corrupt loose object '4b9458b3786228369c63936db65827de3cc06200']
>
> You can try to create a clone (after you have fixed up the artificial
> breakages that you made). If that goes well, then the bad object is
> referenced only from reflogs.
>
git clone ib ib-clone
Initialized empty Git repository in /home/mellanox/work/symm/ib-clone/.git/
0 blocks
[mellanox@mellanox-compile ib-clone]$ cd ib-clone/
[mellanox@mellanox-compile ib-clone]$ git branch -a
* mlx4
origin/HEAD
origin/master
origin/mlx4
origin/mlx4-work
origin/mthca
origin/second_port
[mellanox@mellanox-compile ib-clone]$ git-gc
Generating pack...
Done counting 3288 objects.
Deltifying 3288 objects...
error: corrupt loose object '4b9458b3786228369c63936db65827de3cc06200'
fatal: object 4b9458b3786228369c63936db65827de3cc06200 cannot be read
error: failed to run repack
So still I cant pack my repository
> -- Hannes
>
>
^ permalink raw reply
* git-gui messes up the diff view on non ASCII characters
From: Peter Baumann @ 2007-11-09 15:49 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
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?
-Peter
^ permalink raw reply
* Re: corrupt object on git-gc
From: Johannes Sixt @ 2007-11-09 15:34 UTC (permalink / raw)
To: Yossi Leybovich; +Cc: Andreas Ericsson, git, Yossi Leybovich
In-Reply-To: <4fe79b4b0711090701g7a43cdfdi5e20e5ffb437d7bb@mail.gmail.com>
Yossi Leybovich schrieb:
> [about corrupt loose object '4b9458b3786228369c63936db65827de3cc06200']
You can try to create a clone (after you have fixed up the artificial
breakages that you made). If that goes well, then the bad object is
referenced only from reflogs.
-- Hannes
^ permalink raw reply
* git 1.5.3.5 error over NFS
From: Bill Lear @ 2007-11-09 15:31 UTC (permalink / raw)
To: git
I've brought this up before, but I don't recall a resolution to it.
We have an NFS-mounted filesystem, and git pull is choking on it.
% uname -a
Linux uhlr.zopyra.com 2.6.9-42.0.2.ELsmp #1 SMP Wed Aug 23 13:38:27 BST 2006 x86_64 x86_64 x86_64 GNU/Linux
% git --version
git version 1.5.3.5
% git pull
remote: Generating pack...
remote: Done counting 998 objects.
remote: Result has 836 objects.
remote: Deltifying 836 objects.
remote: 100% (836/836) done
Indexing 836 objects...
remote: Total 836 (delta 526), reused 688 (delta 380)
100% (836/836) done
Resolving 526 deltas...
fatal: cannot pread pack file: No such file or directory
fatal: index-pack died with error code 128
fatal: Fetch failure: git://source/repo
I looked through the archives of this list and did not see a final
resolution, other than a suspected bug in the OS NFS code.
Do we just need to update our OS?
Bill
^ permalink raw reply
* [PATCH REPLACEMENT for 2/2] git status: show relative paths when run in a subdirectory
From: Johannes Schindelin @ 2007-11-09 15:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: David Symonds, Brian Gernhardt, Jon Smirl, Git Mailing List,
gitster
In-Reply-To: <7v8x593zyv.fsf@gitster.siamese.dyndns.org>
To show the relative paths, the function formerly called quote_crlf()
(now called quote_path()) takes the prefix as an additional argument.
While at it, the static buffers were replaced by strbufs.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Thu, 8 Nov 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > -static const char *quote_crlf(const char *in, char *buf, size_t sz)
> > +static const char *quote_crlf(const char *in, int len, char *buf, size_t sz,
> > + const char *prefix)
> > {
>
> This is not quote_*crlf* anymore.
>
> > @@ -118,8 +150,8 @@ static void wt_status_print_filepair(struct wt_status *s,
> > const char *one, *two;
> > char onebuf[PATH_MAX], twobuf[PATH_MAX];
> >
> > - one = quote_crlf(p->one->path, onebuf, sizeof(onebuf));
> > - two = quote_crlf(p->two->path, twobuf, sizeof(twobuf));
> > + one = quote_crlf(p->one->path, -1, onebuf, sizeof(onebuf), s->prefix);
> > + two = quote_crlf(p->two->path, -1, twobuf, sizeof(twobuf), s->prefix);
>
> I wonder if it makes more sense to use strbuf here...
Here you are.
builtin-runstatus.c | 1 +
t/t7502-status.sh | 91 +++++++++++++++++++++++++++++++++++++++++++++++++++
wt-status.c | 69 ++++++++++++++++++++++++++-------------
wt-status.h | 1 +
4 files changed, 139 insertions(+), 23 deletions(-)
create mode 100755 t/t7502-status.sh
diff --git a/builtin-runstatus.c b/builtin-runstatus.c
index 2db25c8..8d167a9 100644
--- a/builtin-runstatus.c
+++ b/builtin-runstatus.c
@@ -14,6 +14,7 @@ int cmd_runstatus(int argc, const char **argv, const char *prefix)
git_config(git_status_config);
wt_status_prepare(&s);
+ s.prefix = prefix;
for (i = 1; i < argc; i++) {
if (!strcmp(argv[i], "--color"))
diff --git a/t/t7502-status.sh b/t/t7502-status.sh
new file mode 100755
index 0000000..269b334
--- /dev/null
+++ b/t/t7502-status.sh
@@ -0,0 +1,91 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Johannes E. Schindelin
+#
+
+test_description='git-status'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ : > tracked &&
+ : > modified &&
+ mkdir dir1 &&
+ : > dir1/tracked &&
+ : > dir1/modified &&
+ mkdir dir2 &&
+ : > dir1/tracked &&
+ : > dir1/modified &&
+ git add . &&
+ test_tick &&
+ git commit -m initial &&
+ : > untracked &&
+ : > dir1/untracked &&
+ : > dir2/untracked &&
+ echo 1 > dir1/modified &&
+ echo 2 > dir2/modified &&
+ echo 3 > dir2/added &&
+ git add dir2/added
+'
+
+cat > expect << \EOF
+# On branch master
+# Changes to be committed:
+# (use "git reset HEAD <file>..." to unstage)
+#
+# new file: dir2/added
+#
+# Changed but not updated:
+# (use "git add <file>..." to update what will be committed)
+#
+# modified: dir1/modified
+#
+# Untracked files:
+# (use "git add <file>..." to include in what will be committed)
+#
+# dir1/untracked
+# dir2/modified
+# dir2/untracked
+# expect
+# output
+# untracked
+EOF
+
+test_expect_success 'status' '
+
+ git status > output &&
+ git diff expect output
+
+'
+
+cat > expect << \EOF
+# On branch master
+# Changes to be committed:
+# (use "git reset HEAD <file>..." to unstage)
+#
+# new file: ../dir2/added
+#
+# Changed but not updated:
+# (use "git add <file>..." to update what will be committed)
+#
+# modified: ../dir1/modified
+#
+# Untracked files:
+# (use "git add <file>..." to include in what will be committed)
+#
+# untracked
+# ../dir2/modified
+# ../dir2/untracked
+# ../expect
+# ../output
+# ../untracked
+EOF
+
+test_expect_success 'status with relative paths' '
+
+ (cd dir1 && git status) > output &&
+ git diff expect output
+
+'
+
+test_done
diff --git a/wt-status.c b/wt-status.c
index 03b5ec4..0d25362 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -82,33 +82,46 @@ static void wt_status_print_trailer(struct wt_status *s)
color_fprintf_ln(s->fp, color(WT_STATUS_HEADER), "#");
}
-static const char *quote_crlf(const char *in, char *buf, size_t sz)
+static char *quote_path(const char *in, int len,
+ struct strbuf *out, const char *prefix)
{
- const char *scan;
- char *out;
- const char *ret = in;
+ if (len > 0)
+ strbuf_grow(out, len);
+ strbuf_setlen(out, 0);
+
+ if (prefix) {
+ int off = 0;
+ while (prefix[off] && off < len && prefix[off] == in[off])
+ if (prefix[off] == '/') {
+ prefix += off + 1;
+ in += off + 1;
+ len -= off + 1;
+ off = 0;
+ } else
+ off++;
+
+ for (; *prefix; prefix++)
+ if (*prefix == '/')
+ strbuf_addstr(out, "../");
+ }
- for (scan = in, out = buf; *scan; scan++) {
- int ch = *scan;
- int quoted;
+ for (; (len < 0 && *in) || len > 0; in++, len--) {
+ int ch = *in;
switch (ch) {
case '\n':
- quoted = 'n';
+ strbuf_addstr(out, "\\n");
break;
case '\r':
- quoted = 'r';
+ strbuf_addstr(out, "\\r");
break;
default:
- *out++ = ch;
+ strbuf_addch(out, ch);
continue;
}
- *out++ = '\\';
- *out++ = quoted;
- ret = buf;
}
- *out = '\0';
- return ret;
+
+ return out->buf;
}
static void wt_status_print_filepair(struct wt_status *s,
@@ -116,10 +129,12 @@ static void wt_status_print_filepair(struct wt_status *s,
{
const char *c = color(t);
const char *one, *two;
- char onebuf[PATH_MAX], twobuf[PATH_MAX];
+ struct strbuf onebuf, twobuf;
- one = quote_crlf(p->one->path, onebuf, sizeof(onebuf));
- two = quote_crlf(p->two->path, twobuf, sizeof(twobuf));
+ strbuf_init(&onebuf, 0);
+ strbuf_init(&twobuf, 0);
+ one = quote_path(p->one->path, -1, &onebuf, s->prefix);
+ two = quote_path(p->two->path, -1, &twobuf, s->prefix);
color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
switch (p->status) {
@@ -151,6 +166,8 @@ static void wt_status_print_filepair(struct wt_status *s,
die("bug: unhandled diff status %c", p->status);
}
fprintf(s->fp, "\n");
+ strbuf_release(&onebuf);
+ strbuf_release(&twobuf);
}
static void wt_status_print_updated_cb(struct diff_queue_struct *q,
@@ -205,8 +222,9 @@ static void wt_read_cache(struct wt_status *s)
static void wt_status_print_initial(struct wt_status *s)
{
int i;
- char buf[PATH_MAX];
+ struct strbuf buf;
+ strbuf_init(&buf, 0);
wt_read_cache(s);
if (active_nr) {
s->commitable = 1;
@@ -215,11 +233,12 @@ static void wt_status_print_initial(struct wt_status *s)
for (i = 0; i < active_nr; i++) {
color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
color_fprintf_ln(s->fp, color(WT_STATUS_UPDATED), "new file: %s",
- quote_crlf(active_cache[i]->name,
- buf, sizeof(buf)));
+ quote_path(active_cache[i]->name, -1,
+ &buf, s->prefix));
}
if (active_nr)
wt_status_print_trailer(s);
+ strbuf_release(&buf);
}
static void wt_status_print_updated(struct wt_status *s)
@@ -254,7 +273,9 @@ static void wt_status_print_untracked(struct wt_status *s)
const char *x;
int i;
int shown_header = 0;
+ struct strbuf buf;
+ strbuf_init(&buf, 0);
memset(&dir, 0, sizeof(dir));
dir.exclude_per_dir = ".gitignore";
@@ -291,9 +312,11 @@ static void wt_status_print_untracked(struct wt_status *s)
shown_header = 1;
}
color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
- color_fprintf_ln(s->fp, color(WT_STATUS_UNTRACKED), "%.*s",
- ent->len, ent->name);
+ color_fprintf_ln(s->fp, color(WT_STATUS_UNTRACKED), "%s",
+ quote_path(ent->name, ent->len,
+ &buf, s->prefix));
}
+ strbuf_release(&buf);
}
static void wt_status_print_verbose(struct wt_status *s)
diff --git a/wt-status.h b/wt-status.h
index 7744932..f58ebcb 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -23,6 +23,7 @@ struct wt_status {
int workdir_untracked;
const char *index_file;
FILE *fp;
+ const char *prefix;
};
int git_status_config(const char *var, const char *value);
--
1.5.3.5.1645.g1f4df
^ permalink raw reply related
* Re: linux-2.6 clone with CygWin git
From: David Brown @ 2007-11-09 15:03 UTC (permalink / raw)
To: Medve Emilian; +Cc: git
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E270174D8A2@az33exm24.fsl.freescale.net>
On Fri, Nov 09, 2007 at 07:29:07AM -0700, Medve Emilian wrote:
># modified: include/linux/netfilter/xt_CONNMARK.h
>
>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?
It's because of the case-insensitive nature of the filesystem. The kernel
contains both an xt_connmark.h and an xt_CONNMARK.h file, that are
different. But only one exists on Windows, so git sees the first one it
wrote as having been modified.
David
^ 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