* Re: Possible regression in git-rev-list --header
From: Junio C Hamano @ 2006-12-30 20:20 UTC (permalink / raw)
To: Marco Costalba; +Cc: git, Johannes Schindelin
In-Reply-To: <Pine.LNX.4.63.0612301955340.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sat, 30 Dec 2006, Marco Costalba wrote:
>
>> When 'commitencoding' variable is set in config file then git-rev-list
>> called with --header option sends also the encoding information.
>
> As Jakub pointed out, qgit should not expect to know all headers. I am
> very sorry, since I said I looked at all parsers of the commit header in
> git, but that was _only_ git, and no porcelains.
>
> Please fix qgit, since I really consider this a bug.
I have to agree with Johannes. In principle Porcelains should
be prepared to see and ignore unknown headers.
However, this commit created by `commit-tree` certalinly can be
improved.
$ git rev-list --header -n1 HEAD
6d751699cb04150abd79a730187d4e2ed6330c05
tree 70209eebdc59d108948feb15c3c5497f299ef290
parent 49a8186d7352d0454df79b289fecb18c8e535c32
author Marco Costalba <mcostalba@gmail.com> 1167500660 +0100
committer Marco Costalba <mcostalba@gmail.com> 1167500660 +0100
encoding UTF-8
Test commit
Let's see what git-rev-list --header spits out.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
-- >8 --
commit-tree: cope with different ways "utf-8" can be spelled.
People can spell config.commitencoding differently from what we
internally have ("utf-8") to mean UTF-8. Try to accept them and
treat them equally.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/builtin-commit-tree.c b/builtin-commit-tree.c
index 146aaff..0651e59 100644
--- a/builtin-commit-tree.c
+++ b/builtin-commit-tree.c
@@ -119,8 +119,7 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
}
/* Not having i18n.commitencoding is the same as having utf-8 */
- encoding_is_utf8 = (!git_commit_encoding ||
- !strcmp(git_commit_encoding, "utf-8"));
+ encoding_is_utf8 = is_encoding_utf8(git_commit_encoding);
init_buffer(&buffer, &size);
add_buffer(&buffer, &size, "tree %s\n", sha1_to_hex(tree_sha1));
diff --git a/utf8.c b/utf8.c
index 1eedd8b..7c80eec 100644
--- a/utf8.c
+++ b/utf8.c
@@ -277,6 +277,15 @@ void print_wrapped_text(const char *text, int indent, int indent2, int width)
}
}
+int is_encoding_utf8(const char *name)
+{
+ if (!name)
+ return 1;
+ if (!strcasecmp(name, "utf-8") || !strcasecmp(name, "utf8"))
+ return 1;
+ return 0;
+}
+
/*
* Given a buffer and its encoding, return it re-encoded
* with iconv. If the conversion fails, returns NULL.
diff --git a/utf8.h b/utf8.h
index cae2a8e..a07c5a8 100644
--- a/utf8.h
+++ b/utf8.h
@@ -3,6 +3,8 @@
int utf8_width(const char **start);
int is_utf8(const char *text);
+int is_encoding_utf8(const char *name);
+
void print_wrapped_text(const char *text, int indent, int indent2, int len);
#ifndef NO_ICONV
^ permalink raw reply related
* Re: [PATCH] git-fetch: Avoid reading packed refs over and over again
From: Han-Wen Nienhuys @ 2006-12-30 20:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612302020060.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin escreveu:
> $ git grep -e exclude-existing v1.5.0-rc0
> v1.5.0-rc0:builtin-show-ref.c: if (!strcmp(arg, "--exclude-existing"))
> v1.5.0-rc0:builtin-show-ref.c: if (!strncmp(arg, "--exclude-existing=", 19))
> v1.5.0-rc0:git-fetch.sh: git-show-ref --exclude-existing=refs/tags/ |
>
> The last line means that it _is_ in v1.5.0-rc0. (BTW it is the commit
> tags/v1.5.0-rc0~84, which I found by "git log v1.5.0-rc0 git-fetch.sh |
> git name-rev --tags --stdin | less".)
oh, oops. I was looking for the commit message of the patch you originally
sent me. Cool.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: [PATCH] xdl_merge(): fix a segmentation fault when refining conflicts
From: Jakub Narebski @ 2006-12-30 19:47 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0612301944350.19693@wbgn013.biozentrum.uni-wuerzburg.de>
<opublikowany i wysłany>
Johannes Schindelin wrote:
> On Thu, 28 Dec 2006, Shawn Pearce wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> > Thank you Alexandre! I looked for the bug for quite some time, but
>> > was never close to the real culprit.
>>
>> Thanks for fixing this!
>>
>> > +<<<<<<< orig.txt
>> > +=======
>> > +Nam et si ambulavero in medio umbrae mortis,
>> > +non timebo mala, quoniam TU mecum es:
>> > +virga tua et baculus tuus ipsa me consolata sunt.
>> > +>>>>>>> new5.txt
>>
>> As a side note I lately have noticed that xdl_merge is producing a
>> conflict like the above when one branch added the lower half and
>> the other branch didn't change anything in the area.
>>
>> I haven't spent any time to try to reproduce it, or to see if RCS'
>> merge utility would automatically merge the file without producing
>> a conflict. But right now it does seem like xdl_merge is producing
>> conflicts when I didn't think it should be.
>
> I thought very long about that problem. It looks like a bug, but it is
> not. At least in my humble opinion.
>
> If you touched the same spot in two different versions, say you added a
> fix in one branch, and that fix and a comment in the other one, you might
> be tempted to automatically resolve that conflict, taking the version with
> the comment.
>
> But it helps you catch mismerges: If you add a chunk of identical code in
> the two branches, but with an increment _before_ it in one branch, and
> _after_ it in the other branch, both should be marked as a conflict.
>
> Of course, you can hit mismerges like the illustrated one _without_ being
> marked as conflict (e.g. if the chunk of identical code is _not_ added,
> but only the increments), but we should at least avoid them where
> possible.
Perhaps you could make it even more conservating merge conflicts option
(to tighten merge conflicts even more) to xdl_merge, but not used by default
because as it removes accidental conflicts it increases mismerges (falsely
not conflicted).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Default "tar" umask..
From: Junio C Hamano @ 2006-12-30 19:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0612301037570.4473@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> We just had a posting on the kernel security list where a person was
> upset that the 2.6.19.1 and .2 tar-files were apparently group and
> world-writable.
I had an impression that this is only an issue when you untar as
root, and running 'tar xf' as root _is_ a more serious security
issue than whatever permission the tar archive itself records.
Having said that, I do not see much reason for anybody to want
to extract any material that is worth to be placed under version
control in a way that is world-writable, so I do not mind having
002 as the default, but I feel that group-writability should be
kept under control of the umask of end users who know what they
are doing.
Historically we used to have 022 as the default, and IIRC we
loosened it exactly because some people hated that we created
files and directories closed to group members.
^ permalink raw reply
* Re: [PATCH 0/11] Misc. pull/merge/am improvements
From: Junio C Hamano @ 2006-12-30 19:27 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061228084245.GA18150@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
>> I am very tempted to have sliding window mmap() if it helps
>> people on cygwin, for example.
>
> Especially now that NO_MMAP is the default on that platform.
> At this point it may be ready to graduate to next to try and get a
> wider audience. Since fixing that segfault in pack-objects I can't
> break it. Of course I couldn't break it before you found that error,
> so take my words with a grain of salt... ;-)
After I fixed a few problems in sp/mmap topic (one was a bug
that screwed up OBJ_OFS_DELTA codepath in pack-objects, another
was an unrelated bug in send-pack that merging this series
revealed), I've tried to redo _all_ merges leading to the tip of
'pu' in git.git history, with small and default mmap window
sizes on my primary machine.
With the default setting, the whole experiment to redo 1561
merges took this much:
193.54user 131.17system 5:23.48elapsed 100%CPU
(0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+35700235minor)pagefaults 0swaps
While with smaller window size i.e. with
[core]
packedgitwindowsize = 20
packedgitlimit = 4194304
the numbers are almost the same:
195.90user 134.40system 5:29.14elapsed 100%CPU
(0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+35862520minor)pagefaults 0swaps
A more important thing is that the merge results exactly match
what I get without sp/mmap (i.e. 'next'). Interestingly, with
either configurations, sp/mmap is slightly faster than 'next'
but I haven't done repeated tests so it may not be statistically
significant.
This is by no means a proof of correctness, but is a good way to
gain more confidence in the code.
^ permalink raw reply
* Re: [PATCH] git-fetch: Avoid reading packed refs over and over again
From: Johannes Schindelin @ 2006-12-30 19:24 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <4596B837.8030108@xs4all.nl>
Hi,
On Sat, 30 Dec 2006, Han-Wen Nienhuys wrote:
> Johannes Schindelin escreveu:
> >
> > Here you have to check first, if len > 3. Strictly speaking, there should
> > not be any line coming in which is shorter than 42 bytes. But I was
> > recentely bitten by such an assuption...
> >
> > Overall, I like it. I even have the impression that this could actually
> > open a way to build in fetch instead of relying on a POSIX conformant and
> > fast shell for such a central part of git.
>
> is there any chance of this going in GIT 1.5.0 ? It's not in the rc0
> release.
Um.
$ git grep -e exclude-existing v1.5.0-rc0
v1.5.0-rc0:builtin-show-ref.c: if (!strcmp(arg, "--exclude-existing"))
v1.5.0-rc0:builtin-show-ref.c: if (!strncmp(arg, "--exclude-existing=", 19))
v1.5.0-rc0:git-fetch.sh: git-show-ref --exclude-existing=refs/tags/ |
The last line means that it _is_ in v1.5.0-rc0. (BTW it is the commit
tags/v1.5.0-rc0~84, which I found by "git log v1.5.0-rc0 git-fetch.sh |
git name-rev --tags --stdin | less".)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-fetch: Avoid reading packed refs over and over again
From: Han-Wen Nienhuys @ 2006-12-30 19:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612181329480.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin escreveu:
>
> Here you have to check first, if len > 3. Strictly speaking, there should
> not be any line coming in which is shorter than 42 bytes. But I was
> recentely bitten by such an assuption...
>
> Overall, I like it. I even have the impression that this could actually
> open a way to build in fetch instead of relying on a POSIX conformant and
> fast shell for such a central part of git.
is there any chance of this going in GIT 1.5.0 ? It's not in the rc0 release.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: Possible regression in git-rev-list --header
From: Johannes Schindelin @ 2006-12-30 18:57 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <e5bfff550612300956mef4691fqf607fad173c571da@mail.gmail.com>
Hi,
On Sat, 30 Dec 2006, Marco Costalba wrote:
> When 'commitencoding' variable is set in config file then git-rev-list
> called with --header option sends also the encoding information.
As Jakub pointed out, qgit should not expect to know all headers. I am
very sorry, since I said I looked at all parsers of the commit header in
git, but that was _only_ git, and no porcelains.
Please fix qgit, since I really consider this a bug.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] xdl_merge(): fix a segmentation fault when refining conflicts
From: Johannes Schindelin @ 2006-12-30 18:53 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Alexandre Julliard, Junio C Hamano, git
In-Reply-To: <20061229041626.GA12072@spearce.org>
Hi,
On Thu, 28 Dec 2006, Shawn Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Thank you Alexandre! I looked for the bug for quite some time, but
> > was never close to the real culprit.
>
> Thanks for fixing this!
>
> > +<<<<<<< orig.txt
> > +=======
> > +Nam et si ambulavero in medio umbrae mortis,
> > +non timebo mala, quoniam TU mecum es:
> > +virga tua et baculus tuus ipsa me consolata sunt.
> > +>>>>>>> new5.txt
>
> As a side note I lately have noticed that xdl_merge is producing a
> conflict like the above when one branch added the lower half and
> the other branch didn't change anything in the area.
>
> I haven't spent any time to try to reproduce it, or to see if RCS'
> merge utility would automatically merge the file without producing
> a conflict. But right now it does seem like xdl_merge is producing
> conflicts when I didn't think it should be.
I thought very long about that problem. It looks like a bug, but it is
not. At least in my humble opinion.
If you touched the same spot in two different versions, say you added a
fix in one branch, and that fix and a comment in the other one, you might
be tempted to automatically resolve that conflict, taking the version with
the comment.
But it helps you catch mismerges: If you add a chunk of identical code in
the two branches, but with an increment _before_ it in one branch, and
_after_ it in the other branch, both should be marked as a conflict.
Of course, you can hit mismerges like the illustrated one _without_ being
marked as conflict (e.g. if the chunk of identical code is _not_ added,
but only the increments), but we should at least avoid them where
possible.
Ciao,
Dscho
^ permalink raw reply
* Default "tar" umask..
From: Linus Torvalds @ 2006-12-30 18:45 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
We just had a posting on the kernel security list where a person was
upset that the 2.6.19.1 and .2 tar-files were apparently group and
world-writable.
Now, the default kernel releases don't do that (at least any more),
because I've got
[tar]
umask=022
in my git config file these days, but the stable team apparently doesn't.
Looking at some of the tar-files I have lying around, they all seem to
have used that 022 umask, and maybe we should just change the git default
to that?
Anybody who wants to, can get the zero umask by just using the config
file, but maybe the default should be the common case, and the case that
isn't as likely to be a security issue if you untar it.
GNU tar has a "--no-same-permissions" flag to use the user umask at untar
time, but I think that's a GNU-tar specific feature (at least I can't see
any short flag to do the same), and I have to admit that I've _never_ used
it even though I've used "tar" a long time, so at least going by my
personal experience, I'd say it's very uncommon for people to use it.
The trivial untested patch below should do it.
Linus
---
diff --git a/archive-tar.c b/archive-tar.c
index af47fdc..d4a2fa4 100644
--- a/archive-tar.c
+++ b/archive-tar.c
@@ -15,7 +15,7 @@ static char block[BLOCKSIZE];
static unsigned long offset;
static time_t archive_time;
-static int tar_umask;
+static int tar_umask = 022;
static int verbose;
/* writes out the whole block, but only if it is full */
^ permalink raw reply related
* Re: Possible regression in git-rev-list --header
From: Jakub Narebski @ 2006-12-30 18:30 UTC (permalink / raw)
To: git
In-Reply-To: <e5bfff550612300956mef4691fqf607fad173c571da@mail.gmail.com>
Marco Costalba wrote:
> When 'commitencoding' variable is set in config file then git-rev-list
> called with --header option sends also the encoding information.
>
> $ git rev-list --header -n1 HEAD
> 6d751699cb04150abd79a730187d4e2ed6330c05
> tree 70209eebdc59d108948feb15c3c5497f299ef290
> parent 49a8186d7352d0454df79b289fecb18c8e535c32
> author Marco Costalba <mcostalba@gmail.com> 1167500660 +0100
> committer Marco Costalba <mcostalba@gmail.com> 1167500660 +0100
> encoding UTF-8
>
> Test commit
>
> Let's see what git-rev-list --header spits out.
>
> Signed-off-by: Marco Costalba <mcostalba@gmail.com>
>
> $ git --version
> git version 1.5.0.rc0.g1ed48
>
>
> This is very unfortunate because qgit parsing routine it's totally
> broken after this change. Please revert the patch, or at least make
> git-rev-list --header quiet as default, IOW add an option
> --show-encoding that defaults to disabled.
Well, that is incompatibile change, but it also shows design errors
in qgit, as it should ignore unknown headers, and rely on "\n\n" to
separate header from the body. Isn't it?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Possible regression in git-rev-list --header
From: Marco Costalba @ 2006-12-30 17:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
When 'commitencoding' variable is set in config file then git-rev-list
called with --header option sends also the encoding information.
$ git rev-list --header -n1 HEAD
6d751699cb04150abd79a730187d4e2ed6330c05
tree 70209eebdc59d108948feb15c3c5497f299ef290
parent 49a8186d7352d0454df79b289fecb18c8e535c32
author Marco Costalba <mcostalba@gmail.com> 1167500660 +0100
committer Marco Costalba <mcostalba@gmail.com> 1167500660 +0100
encoding UTF-8
Test commit
Let's see what git-rev-list --header spits out.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
$ git --version
git version 1.5.0.rc0.g1ed48
This is very unfortunate because qgit parsing routine it's totally
broken after this change. Please revert the patch, or at least make
git-rev-list --header quiet as default, IOW add an option
--show-encoding that defaults to disabled.
Sorry to ask you this but _all_ the qgit users out there will see a
broken main view revision's list for all the commits created after the
patch went in.
Thanks
Marco
^ permalink raw reply
* Re: [PATCH] Fix 'git add' with .gitignore (Re: git-add ignores .gitignore)
From: Brian Gernhardt @ 2006-12-30 14:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsa2msx2.fsf@assigned-by-dhcp.cox.net>
On Dec 29, 2006, at 1:57 PM, Junio C Hamano wrote:
> Thanks for noticing.
>
> The commit 4888c534 tried to mark the path it returns so that
> the caller can tell if it is ignored or not, but botched the
> case where a directory is ignored. It should have marked the
> contents as ignored if higher level directory was.
>
> But I think the approach that change makes is more expensive
> than the original code and is not necessary. How about this
> patch, after you revert that commit?
Tried it and it works for me! Thanks.
~~ Brian
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2006-12-30 12:54 UTC (permalink / raw)
To: Raimund Bauer; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <45965A82.8030903@gmx.net>
Hi,
On Sat, 30 Dec 2006, Raimund Bauer wrote:
> * Johannes Schindelin wrote, On 30.12.2006 12:22:
> > (Of course, the correct thing would not be "git reset --hard", but rather
> > "git diff --ours | git apply -R; git reset", but that's a tad long, no?)
> Then maybe introduce "git reset --ours" which does exactly that?
That is possible.
But does it make sense?
It is a volatile state, and errors are too easy. So I think it makes sense
to have to _ask_ for such a state.
(Having said that, I think that it actually might make sense for bisecting
an error where you _need_ a local patch to get it running to begin with.)
Ciao,
Dscho
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Raimund Bauer @ 2006-12-30 12:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0612301217010.19693@wbgn013.biozentrum.uni-wuerzburg.de>
* Johannes Schindelin wrote, On 30.12.2006 12:22:
> (Of course, the correct thing would not be "git reset --hard", but rather
> "git diff --ours | git apply -R; git reset", but that's a tad long, no?)
Then maybe introduce "git reset --ours" which does exactly that?
--
best regards
Ray
^ permalink raw reply
* Re: SIGSEGV in merge recursive
From: Florian Weimer @ 2006-12-30 11:46 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0612301204280.19693@wbgn013.biozentrum.uni-wuerzburg.de>
* Johannes Schindelin:
>> > > Failed to read a valid object file image from memory.
>> >
>> > Who says this?
>
> Again, who says this?
It's a GDB message.
^ permalink raw reply
* [PATCH] git-clean: Fix the -q option.
From: Alexandre Julliard @ 2006-12-30 11:47 UTC (permalink / raw)
To: git
The 'quiet' flag is set by -q, but it's not used anywhere.
Remove it and set the 'echo1' variable instead.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
git-clean.sh | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/git-clean.sh b/git-clean.sh
index 3834323..071b974 100755
--- a/git-clean.sh
+++ b/git-clean.sh
@@ -18,7 +18,6 @@ SUBDIRECTORY_OK=Yes
ignored=
ignoredonly=
cleandir=
-quiet=
rmf="rm -f --"
rmrf="rm -rf --"
rm_refuse="echo Not removing"
@@ -31,14 +30,13 @@ do
cleandir=1
;;
-n)
- quiet=1
rmf="echo Would remove"
rmrf="echo Would remove"
rm_refuse="echo Would not remove"
echo1=":"
;;
-q)
- quiet=1
+ echo1=":"
;;
-x)
ignored=1
--
1.5.0.rc0.g3710-dirty
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2006-12-30 11:22 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0612292219280.18171@xanadu.home>
Hi,
On Fri, 29 Dec 2006, Nicolas Pitre wrote:
> On Fri, 29 Dec 2006, Johannes Schindelin wrote:
>
> > On Thu, 28 Dec 2006, Junio C Hamano wrote:
> >
> > > * jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
> > > + git-merge: preserve and merge local changes when doing fast
> > > forward
> >
> > I'd like this, but behind a command line switch. And in addition to
> > saying "cannot merge, blabla needs update", git could spit out "if you
> > want to risk a 3way merge, go ahead and add the --preserve-local flag
> > to git-merge".
> >
> > Comments?
>
> Is there really a point for not always doing it?
>
> IOW, if you really want a command line switch, maybe it should be used
> to prevent the above not to allow it?
There is a drawback to enabling this all the time. If the merge screws up
with gazillions of conflicts, because I pulled the wrong branch, I am so
used to "git reset --hard". Bummer. All my changes lost.
That is why we encourage commit-before-pull, to have a saved state.
(Of course, the correct thing would not be "git reset --hard", but rather
"git diff --ours | git apply -R; git reset", but that's a tad long, no?)
Ciao,
Dscho
^ permalink raw reply
* Re: SIGSEGV in merge recursive
From: Johannes Schindelin @ 2006-12-30 11:07 UTC (permalink / raw)
To: Luben Tuikov; +Cc: Junio C Hamano, git
In-Reply-To: <898450.11823.qm@web31804.mail.mud.yahoo.com>
Hi,
On Fri, 29 Dec 2006, Luben Tuikov wrote:
> > > Failed to read a valid object file image from memory.
> >
> > Who says this?
Again, who says this? I cannot find _anything_ in my local repo (with its
own set of modifications, which do not hide such a message).
Given that there is a fix in master for a segfault, I have to admit that I
believe you did not use _that_ version, but a git without that fix.
Besides, Alexandre hit an interesting bug, which is not at all easy to
reproduce (except with three 70k files which I don't want to include in
the test set). Since Alexandre provided _examples_ where I can _reproduce_
the problem, I will be working on that bug, and not yours.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix 'git add' with .gitignore (Re: git-add ignores .gitignore)
From: Brian Gernhardt @ 2006-12-30 4:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsa2msx2.fsf@assigned-by-dhcp.cox.net>
On Dec 29, 2006, at 1:57 PM, Junio C Hamano wrote:
> Thanks for noticing.
Hard not to. Git suddenly tried to add a couple hundred files from a
library I don't want to track. ;-)
> How about this patch, after you revert that commit?
I'm on vacation at my in-laws, so I'll try it when I get a chance but
it may take a few days. (I'm only checking e-mail and that's just so
I'm not buried in git list mails on Tuesday.
~~ Brian
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Nicolas Pitre @ 2006-12-30 3:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0612291853210.19693@wbgn013.biozentrum.uni-wuerzburg.de>
On Fri, 29 Dec 2006, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 28 Dec 2006, Junio C Hamano wrote:
>
> > * jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
> > + git-merge: preserve and merge local changes when doing fast
> > forward
>
> I'd like this, but behind a command line switch. And in addition to saying
> "cannot merge, blabla needs update", git could spit out "if you want to
> risk a 3way merge, go ahead and add the --preserve-local flag to
> git-merge".
>
> Comments?
Is there really a point for not always doing it?
IOW, if you really want a command line switch, maybe it should be used
to prevent the above not to allow it?
Nicolas
^ permalink raw reply
* Re: [PATCH] gitweb: New feature last_modified_ref.
From: Robert Fitzsimons @ 2006-12-30 0:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robert Fitzsimons, Jakub Narebski, Martin Langhoff, git
In-Reply-To: <7vlkkqms8n.fsf@assigned-by-dhcp.cox.net>
> I somehow suspect this is solving the problem with a wrong
> tradeoff.
I think the main problem is that we are trying to fix possible
performance problems with the latest version, just because they might
cause a major problem on kernel.org.
At this point I think we should get the latest version loaded and see
what the real problems are.
Robert
^ permalink raw reply
* Re: [PATCH/RFH] send-pack: fix pipeline.
From: Junio C Hamano @ 2006-12-29 23:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Andy Whitcroft
In-Reply-To: <Pine.LNX.4.64.0612291307520.4473@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Fri, 29 Dec 2006, Junio C Hamano wrote:
>>
>> I really need a sanity checking on this one. I think I got the
>> botched pipeline fixed with the patch I am replying to, but I do
>> not understand the waitpid() business. Care to enlighten me?
>
> I think it was a beginning of a half-hearted attempt to check the exit
> status of the rev-list in case something went wrong.
>
> Which we simply don't do, so if git-rev-list ends up with some problem
> (due to a corrupt git repo or something), it will just send a partial
> pack.
>
> For some reason I thought we had fixed that by just generating the object
> list internally, but I guess we don't do that. That's just stupid. We
> should make "send-pack.c" use
>
> list-heads | git pack-objects --revs
>
> list-heads | git-rev-list --stdin | git-pack-objects
>
> because as it is now, I think send-pack is more fragile than it needs to
> be.
>
> Or maybe I'm just confused.
Dont' worry, you are no more confused than I am ;-).
"I thought we've done the 'pack-objects --revs' for the
upload-pack side but haven't done so on the send-pack side." was
what I initially wrote, but apparently we haven't. On the other
hand, I think upload-pack gets error termination from rev-list
right.
It seems that repack is the only thing that uses the internal
rev-list.
^ permalink raw reply
* Re: [PATCH/RFH] send-pack: fix pipeline.
From: Linus Torvalds @ 2006-12-29 21:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Andy Whitcroft
In-Reply-To: <7vzm96latb.fsf@assigned-by-dhcp.cox.net>
On Fri, 29 Dec 2006, Junio C Hamano wrote:
>
> I really need a sanity checking on this one. I think I got the
> botched pipeline fixed with the patch I am replying to, but I do
> not understand the waitpid() business. Care to enlighten me?
I think it was a beginning of a half-hearted attempt to check the exit
status of the rev-list in case something went wrong.
Which we simply don't do, so if git-rev-list ends up with some problem
(due to a corrupt git repo or something), it will just send a partial
pack.
For some reason I thought we had fixed that by just generating the object
list internally, but I guess we don't do that. That's just stupid. We
should make "send-pack.c" use
list-heads | git pack-objects --revs
list-heads | git-rev-list --stdin | git-pack-objects
because as it is now, I think send-pack is more fragile than it needs to
be.
Or maybe I'm just confused.
Linus
^ permalink raw reply
* Re: SIGSEGV in merge recursive
From: Luben Tuikov @ 2006-12-29 20:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7iwampi4.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
> > This time it happens when merging one of my git trees into another:
> > ...
> > And here is the backtrace:
> >
> > $gdb ~/bin/git-merge-recursive
> > GNU gdb 6.5
> > Copyright (C) 2006 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you are
> > welcome to change it and/or distribute copies of it under certain conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB. Type "show warranty" for details.
> > This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library
> > "/lib/libthread_db.so.1".
> >
> > (gdb) run 777f68432f1db967573e5722bf0fd08af05e748f -- HEAD
> > d985fdaf7a4b8b1dde313c8fad12983dc4ce20f7
> > Starting program: /home/luben/bin/git-merge-recursive 777f68432f1db967573e5722bf0fd08af05e748f
> --
> > HEAD d985fdaf7a4b8b1dde313c8fad12983dc4ce20f7
> > Failed to read a valid object file image from memory.
>
> Who says this?
>
> > Merging HEAD with d985fdaf7a4b8b1dde313c8fad12983dc4ce20f7
> > Merging:
> > 52d5052 Merge branch 'git-upstream' into git-lt-work
> > d985fda Merge branch 'next' into git-upstream
> > found 1 common ancestor(s):
> > 777f684 Merge branch 'next' into git-upstream
> > Auto-merging .gitignore
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x08070469 in xdl_merge (orig=0xbff3aae0, mf1=0xbff3aad8,
> > name1=0x80f5208 "HEAD:.gitignore", mf2=0xbff3aad0,
> > name2=0x80f59a8 "d985fdaf7a4b8b1dde313c8fad12983dc4ce20f7:.gitignore",
> > xpp=0xbff3aae8, level=2, result=0xbff3aac8) at xdiff/xmerge.c:200
> > warning: Source file is more recent than executable.
> > 200 */
>
> What local mods are you running with?
Not much -- the one-offs you've sent to git and me to fix various
problems I've complained about, some scripts of mine which have nothing
to do with merging. The log of the commits diff between next and
git-lt-work doesn't show anything in the merge area -- only things
I've been active in like gitweb, etc.
Luben
^ 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