* Re: [PATCH 5/6] Do linear-time/space rename logic for exact renames
From: Linus Torvalds @ 2007-10-25 20:25 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0710251522190.7345@iabervon.org>
On Thu, 25 Oct 2007, Daniel Barkalow wrote:
>
> Creating a list of the pointers doesn't work correctly with the grow
> implementation, because growing the hash may turn a collision into a
> non-collision, at which point items other than the first cannot be found
> (since they're listed inside a bucket that's now wrong for them). AFAIK,
> resizing a hash table requires being able to figure out what happened with
> collisions.
Nope.
The hash algorithm is much smarter than that.
I *always* uses a full 32-bit hash, and no amount of resizing is ever
going to change that. The index into the hash-table is in fact entirely
unused.
This has several good properties:
- it means that hash-table resizing is a non-event
- it means that you always have the full 32-bit hash, and a collision in
the hash size never causes unnecessary work apart from the fact that
the code walks the hash table a bit more.
- because the hash is embedded in the table itself, it has relatively
good cache behaviour when compared to something that needs to actually
follow the pointer to validate the full data. So assuming that the full
32-bit hash is good enough to effectively never have any collisions
(or, assuming you don't even *care* about the collisions, which is the
case when you're just generating content fingerprints for lines when
comparing the data in two files), you never end up with unnecessarily
following pointers to cachelines that you are not interested in.
The last point at least somewhat mitigates the (inevitably) bad cache
behaviour that hash tables tend to have. It's not like it's going to be
wonderful in the cache, but at least it's less horrid than the more common
implementation that needs to follow the pointer to validate each hash
entry that may or may not be a collision.
but the important part is #1, which is what allows the code to be a
generic hash algorithm that resizes the hash table without even
understanding or caring what is behind the pointer.
Linus
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinishedsummary continued
From: J. Bruce Fields @ 2007-10-25 20:27 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Federico Mena Quintero, git
In-Reply-To: <4720FA6E.9040805@op5.se>
On Thu, Oct 25, 2007 at 10:19:58PM +0200, Andreas Ericsson wrote:
> Federico Mena Quintero wrote:
>> On Thu, 2007-10-25 at 12:38 -0400, J. Bruce Fields wrote:
>>> Also, there's
>>> the restriction that we'd like to keep it looking good in plain ascii,
>>> so diagrams have to be done in ascii somehow.
>> Hmm, what's the rationale for this? I'd assume that most people read
>> the user's manual as a web page (or as bedside reading if they can print
>> a PDF thereof), where diagrams can be pretty.
>
> man pages.
I think he's talking about Documentation/user-manual.txt, which isn't
turned into man pages. (Might be nice if it could be though, I
suppose.)
--b.
^ permalink raw reply
* Re: recent change in git.git/master broke my repos
From: Nicolas Pitre @ 2007-10-25 20:38 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Karl Hasselström, Randal L. Schwartz, git
In-Reply-To: <4720FB4E.3030300@op5.se>
On Thu, 25 Oct 2007, Andreas Ericsson wrote:
> Nicolas Pitre wrote:
> > Isn't that called a remote branch that gets updated with "git fetch' ?
> > You can even trick Git into not using the refs/remotes/ namespace for them
> > if you wish.
> >
>
> You'd lose the ability to do "git diff origin/master" while disconnected
> though. It's quite valuable.
I don't see how you'd lose anything.
Nicolas
^ permalink raw reply
* Re: recent change in git.git/master broke my repos
From: Andreas Ericsson @ 2007-10-25 20:42 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Karl Hasselström, Randal L. Schwartz, git
In-Reply-To: <alpine.LFD.0.9999.0710251637240.22100@xanadu.home>
Nicolas Pitre wrote:
> On Thu, 25 Oct 2007, Andreas Ericsson wrote:
>
>> Nicolas Pitre wrote:
>>> Isn't that called a remote branch that gets updated with "git fetch' ?
>>> You can even trick Git into not using the refs/remotes/ namespace for them
>>> if you wish.
>>>
>> You'd lose the ability to do "git diff origin/master" while disconnected
>> though. It's quite valuable.
>
> I don't see how you'd lose anything.
>
Sorry, I thought you were talking about a config along the lines of:
fetch = refs/heads/*:refs/heads/*
What other trick are you talking about?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Fix generation of perl/perl.mak
From: Johannes Schindelin @ 2007-10-25 20:42 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <20071025201724.GA11308@steel.home>
Hi,
On Thu, 25 Oct 2007, Alex Riesen wrote:
> Besides, a changed Git.pm is *NOT* a reason to rebuild all the perl
> scripts, so remove the dependency too.
>
> [...]
>
> @@ -931,10 +931,6 @@ $(XDIFF_LIB): $(XDIFF_OBJS)
> $(QUIET_AR)$(RM) $@ && $(AR) rcs $@ $(XDIFF_OBJS)
>
>
> -perl/Makefile: perl/Git.pm perl/Makefile.PL GIT-CFLAGS
> - (cd perl && $(PERL_PATH) Makefile.PL \
> - PREFIX='$(prefix_SQ)')
> -
This is not really the dependency triggering a rebuild of all perl
scripts, right?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix generation of perl/perl.mak
From: Alex Riesen @ 2007-10-25 21:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0710252140500.4362@racer.site>
Johannes Schindelin, Thu, Oct 25, 2007 22:42:07 +0200:
> On Thu, 25 Oct 2007, Alex Riesen wrote:
>
> > Besides, a changed Git.pm is *NOT* a reason to rebuild all the perl
> > scripts, so remove the dependency too.
> >
> > [...]
> >
> > -perl/Makefile: perl/Git.pm perl/Makefile.PL GIT-CFLAGS
> > - (cd perl && $(PERL_PATH) Makefile.PL \
> > - PREFIX='$(prefix_SQ)')
> > -
>
> This is not really the dependency triggering a rebuild of all perl
> scripts, right?
In a way. This rebuilds perl/perl.mak which, in turn, can cause the
rebuild of all perl scripts. The rule you replaced with "[...]" does
the same, but uses perl/Makefile, which generates the perl.mak
depending on the NO_PERL_MAKEMAKER setting.
^ permalink raw reply
* Re: git apply fails to apply a renamed file in a new directory
From: Alex Riesen @ 2007-10-25 21:30 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: git
In-Reply-To: <20071025180737.GA13829@uranus.ravnborg.org>
Sam Ravnborg, Thu, Oct 25, 2007 20:07:37 +0200:
> I just stumbled on what looks like a simple bug in git apply.
> I had following diff:
>
> diff --git a/arch/i386/defconfig b/arch/x86/configs/i386_defconfig
> similarity index 100%
> rename from arch/i386/defconfig
> rename to arch/x86/configs/i386_defconfig
> diff --git a/arch/x86_64/defconfig b/arch/x86/configs/x86_64_defconfig
> similarity index 100%
> rename from arch/x86_64/defconfig
> rename to arch/x86/configs/x86_64_defconfig
> --
> 1.5.3.4.1157.g0e74-dirty
>
> When trying to apply this diff using:
> git apply -p1 < .../patch
works here. Don't use -p1, it is assumed
^ permalink raw reply
* Re: git apply fails to apply a renamed file in a new directory
From: Alex Riesen @ 2007-10-25 21:35 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: git
In-Reply-To: <20071025213038.GC11308@steel.home>
Alex Riesen, Thu, Oct 25, 2007 23:30:38 +0200:
> Sam Ravnborg, Thu, Oct 25, 2007 20:07:37 +0200:
> > I just stumbled on what looks like a simple bug in git apply.
> > I had following diff:
> >
> > diff --git a/arch/i386/defconfig b/arch/x86/configs/i386_defconfig
> > similarity index 100%
> > rename from arch/i386/defconfig
> > rename to arch/x86/configs/i386_defconfig
> > diff --git a/arch/x86_64/defconfig b/arch/x86/configs/x86_64_defconfig
> > similarity index 100%
> > rename from arch/x86_64/defconfig
> > rename to arch/x86/configs/x86_64_defconfig
> > --
> > 1.5.3.4.1157.g0e74-dirty
.1157...-dirty. Your git looks heavily modified. Could you try with a
something like master of kernel.org?
Mine is based off d90a7fda355c251b8ffdd79617fb083c18245ec2
(builtin-fetch got merged).
> > When trying to apply this diff using:
> > git apply -p1 < .../patch
>
> works here. Don't use -p1, it is assumed
>
^ permalink raw reply
* Re: [PATCH 5/6] Do linear-time/space rename logic for exact renames
From: Daniel Barkalow @ 2007-10-25 21:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0710251317020.30120@woody.linux-foundation.org>
On Thu, 25 Oct 2007, Linus Torvalds wrote:
> On Thu, 25 Oct 2007, Daniel Barkalow wrote:
> >
> > Creating a list of the pointers doesn't work correctly with the grow
> > implementation, because growing the hash may turn a collision into a
> > non-collision, at which point items other than the first cannot be found
> > (since they're listed inside a bucket that's now wrong for them). AFAIK,
> > resizing a hash table requires being able to figure out what happened with
> > collisions.
>
> Nope.
>
> The hash algorithm is much smarter than that.
Ah, yes. I was just confused by the comment suggesting the possibility of
a collision when the only way to have two calls get the same bucket is
when the key that the library gets is actually identical.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git apply fails to apply a renamed file in a new directory
From: Sam Ravnborg @ 2007-10-25 21:41 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20071025213523.GD11308@steel.home>
On Thu, Oct 25, 2007 at 11:35:23PM +0200, Alex Riesen wrote:
> Alex Riesen, Thu, Oct 25, 2007 23:30:38 +0200:
> > Sam Ravnborg, Thu, Oct 25, 2007 20:07:37 +0200:
> > > I just stumbled on what looks like a simple bug in git apply.
> > > I had following diff:
> > >
> > > diff --git a/arch/i386/defconfig b/arch/x86/configs/i386_defconfig
> > > similarity index 100%
> > > rename from arch/i386/defconfig
> > > rename to arch/x86/configs/i386_defconfig
> > > diff --git a/arch/x86_64/defconfig b/arch/x86/configs/x86_64_defconfig
> > > similarity index 100%
> > > rename from arch/x86_64/defconfig
> > > rename to arch/x86/configs/x86_64_defconfig
> > > --
> > > 1.5.3.4.1157.g0e74-dirty
>
> .1157...-dirty. Your git looks heavily modified. Could you try with a
> something like master of kernel.org?
I guess I still have Linus' rename stuff added - will update.
>
> Mine is based off d90a7fda355c251b8ffdd79617fb083c18245ec2
> (builtin-fetch got merged).
>
> > > When trying to apply this diff using:
> > > git apply -p1 < .../patch
> >
> > works here. Don't use -p1, it is assumed
> >
It seems to be a picnic[*] bug - at least I cannot reproduce it.
Sorry for the noise but thanks for testing.
[*] Problem In Chair Not In Computer
Sam
^ permalink raw reply
* Re: git-svnimport
From: Steven Walter @ 2007-10-25 22:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Felipe Balbi, git
In-Reply-To: <Pine.LNX.4.64.0710251403160.25221@racer.site>
On Thu, Oct 25, 2007 at 02:04:29PM +0100, Johannes Schindelin wrote:
> FYI you'll have to do something like this:
>
> git svn init svn://busybox.net/trunk/busybox
> git svn fetch
>
> to merge with current busybox (although I updated before I pushed).
More than that, you'll want to:
git svn init <foo>
cp .git/refs/remotes/origin/master .git/refs/remotes/git-svn
git svn fetch
If git-svn doesn't find a remote named "git-svn" it will assume that it
has no information about the repository and starting doing a full
checkout. By copying the ref, git-svn will see that there are already
commits with git-svn-id lines and rebuild its "rev-db". After that, it
will incrementally update for newer revisions.
That ought to save you a few precious minutes :)
--
-Steven Walter <stevenrwalter@gmail.com>
Freedom is the freedom to say that 2 + 2 = 4
B2F1 0ECC E605 7321 E818 7A65 FC81 9777 DC28 9E8F
^ permalink raw reply
* Re: git-svnimport
From: Johannes Schindelin @ 2007-10-25 22:22 UTC (permalink / raw)
To: Steven Walter; +Cc: Felipe Balbi, git
In-Reply-To: <20071025222029.GA11677@dervierte>
Hi,
On Thu, 25 Oct 2007, Steven Walter wrote:
> On Thu, Oct 25, 2007 at 02:04:29PM +0100, Johannes Schindelin wrote:
> > FYI you'll have to do something like this:
> >
> > git svn init svn://busybox.net/trunk/busybox
> > git svn fetch
> >
> > to merge with current busybox (although I updated before I pushed).
>
> More than that, you'll want to:
>
> git svn init <foo>
> cp .git/refs/remotes/origin/master .git/refs/remotes/git-svn
> git svn fetch
>
> If git-svn doesn't find a remote named "git-svn" it will assume that it
> has no information about the repository and starting doing a full
> checkout. By copying the ref, git-svn will see that there are already
> commits with git-svn-id lines and rebuild its "rev-db". After that, it
> will incrementally update for newer revisions.
>
> That ought to save you a few precious minutes :)
Good catch. Thanks.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Teach 'git pull' the '--rebase' option
From: Johannes Schindelin @ 2007-10-25 22:54 UTC (permalink / raw)
To: git, gitster
When calling 'git pull' with the '--rebase' option, it performs a
fetch + rebase instead of a fetch + pull.
This behavior is more desirable than fetch + pull when a topic branch
is ready to be submitted.
fetch + rebase might also be considered a better workflow with shared
repositories in any case, or for contributors to a centrally managed
project, such as Wine -- or Git.
For your convenience, you can set the default behavior for a branch by
defining the config variable branch.<name>.rebase, which is
interpreted as a bool. This setting can be overridden on the command
line by --rebase and --no-rebase.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Documentation/git-pull.txt | 6 ++++++
git-pull.sh | 11 ++++++++++-
t/t5520-pull.sh | 22 ++++++++++++++++++++++
3 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index e1eb2c1..c3ce8ee 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -33,6 +33,12 @@ include::urls-remotes.txt[]
include::merge-strategies.txt[]
+\--rebase::
+ Instead of a merge, perform a rebase after fetching.
+
+\--no-rebase::
+ Override earlier \--rebase.
+
DEFAULT BEHAVIOUR
-----------------
diff --git a/git-pull.sh b/git-pull.sh
index 74bfc16..b5ecb80 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -16,6 +16,9 @@ test -z "$(git ls-files -u)" ||
die "You are in the middle of a conflicted merge."
strategy_args= no_summary= no_commit= squash=
+curr_branch=$(git symbolic-ref -q HEAD)
+curr_branch_short=$(echo "$curr_branch" | sed "s|refs/heads/||")
+rebase=$(git config --bool branch.$curr_branch_short.rebase)
while :
do
case "$1" in
@@ -43,6 +46,12 @@ do
esac
strategy_args="${strategy_args}-s $strategy "
;;
+ -r|--r|--re|--reb|--reba|--rebas|--rebase)
+ rebase=true
+ ;;
+ --no-r|--no-re|--no-reb|--no-reba|--no-rebas|--no-rebase)
+ rebase=false
+ ;;
-h|--h|--he|--hel|--help)
usage
;;
@@ -86,7 +95,6 @@ merge_head=$(sed -e '/ not-for-merge /d' \
case "$merge_head" in
'')
- curr_branch=$(git symbolic-ref -q HEAD)
case $? in
0) ;;
1) echo >&2 "You are not currently on a branch; you must explicitly"
@@ -133,5 +141,6 @@ then
fi
merge_name=$(git fmt-merge-msg <"$GIT_DIR/FETCH_HEAD") || exit
+test true = "$rebase" && exec git-rebase $merge_head
exec git-merge $no_summary $no_commit $squash $strategy_args \
"$merge_name" HEAD $merge_head
diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
index 93eaf2c..52b3a0c 100755
--- a/t/t5520-pull.sh
+++ b/t/t5520-pull.sh
@@ -53,4 +53,26 @@ test_expect_success 'the default remote . should not break explicit pull' '
test `cat file` = modified
'
+test_expect_success '--rebase' '
+ git branch to-rebase &&
+ echo modified again > file &&
+ git commit -m file file &&
+ git checkout to-rebase &&
+ echo new > file2 &&
+ git add file2 &&
+ git commit -m "new file" &&
+ git tag before-rebase &&
+ git pull --rebase . copy &&
+ test $(git rev-parse HEAD^) = $(git rev-parse copy) &&
+ test new = $(git show HEAD:file2)
+'
+
+test_expect_success 'branch.to-rebase.rebase' '
+ git reset --hard before-rebase &&
+ git config branch.to-rebase.rebase 1 &&
+ git pull . copy &&
+ test $(git rev-parse HEAD^) = $(git rev-parse copy) &&
+ test new = $(git show HEAD:file2)
+'
+
test_done
--
1.5.3.4.1351.gee906
^ permalink raw reply related
* Re: [PATCH] Teach 'git pull' the '--rebase' option
From: Linus Torvalds @ 2007-10-25 23:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0710252351130.4362@racer.site>
On Thu, 25 Oct 2007, Johannes Schindelin wrote:
>
> This behavior is more desirable than fetch + pull when a topic branch
> is ready to be submitted.
I'd like there to be some *big*warning* about how this destroys history
and how you must not do this if you expose your history anywhere else.
I think it's a perfectly fine history, but if you have already pushed out
your history somewhere else, you're now really screwed. In ways that a
*real* merge will never screw you.
So the "--rebase" option really is only good for the lowest-level
developers. And that should be documented.
Linus
^ permalink raw reply
* Re: [PATCH] Teach 'git pull' the '--rebase' option
From: Johannes Schindelin @ 2007-10-25 23:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, gitster
In-Reply-To: <alpine.LFD.0.999.0710251602160.30120@woody.linux-foundation.org>
Hi,
On Thu, 25 Oct 2007, Linus Torvalds wrote:
> On Thu, 25 Oct 2007, Johannes Schindelin wrote:
> >
> > This behavior is more desirable than fetch + pull when a topic branch
> > is ready to be submitted.
>
> I'd like there to be some *big*warning* about how this destroys history
> and how you must not do this if you expose your history anywhere else.
>
> I think it's a perfectly fine history, but if you have already pushed out
> your history somewhere else, you're now really screwed. In ways that a
> *real* merge will never screw you.
>
> So the "--rebase" option really is only good for the lowest-level
> developers. And that should be documented.
Fair enough.
How about this in the man page:
\--rebase::
Instead of a merge, perform a rebase after fetching.
*NOTE:* Never do this on branches you plan to publish! This
command will _destroy_ history, and is thus only suitable for
topic branches to be submitted to another committer.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Teach 'git pull' the '--rebase' option
From: Linus Torvalds @ 2007-10-25 23:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0710260007450.4362@racer.site>
On Fri, 26 Oct 2007, Johannes Schindelin wrote:
>
> \--rebase::
> Instead of a merge, perform a rebase after fetching.
> *NOTE:* Never do this on branches you plan to publish! This
> command will _destroy_ history, and is thus only suitable for
> topic branches to be submitted to another committer.
Well, it really needs explanation of what "destroy" means.
Also, it's not strictly even necessary to publish things for this to cause
problems. It's perfectly sufficient to just do development on two private
developer machines, and do things like keeping the two machines in sync by
pulling things between them manually...
So even "normal" developers who never publish a git tree to others may
actually hit this issue.
Linus
^ permalink raw reply
* Re: [PATCH] Teach 'git pull' the '--rebase' option
From: Linus Torvalds @ 2007-10-25 23:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.LFD.0.999.0710251634200.30120@woody.linux-foundation.org>
On Thu, 25 Oct 2007, Linus Torvalds wrote:
> Also, it's not strictly even necessary to publish things for this to cause
> problems. It's perfectly sufficient to just do development on two private
> developer machines, and do things like keeping the two machines in sync by
> pulling things between them manually...
.. or any branch use, for that matter.
I do agree that "git merge --rebase" is potentially convenient, I'm just
not sure it's a great idea to document as such. People shouldn't do it
unless they really *really* understand the implications, and I think the
implications are much easier to understand if you instead teach them
"fetch+rebase", and perhaps even keep the "merge --rebase" option entirely
undocumented.
Linus
^ permalink raw reply
* Re: [PATCH] Teach 'git pull' the '--rebase' option
From: Junio C Hamano @ 2007-10-25 23:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, git, gitster
In-Reply-To: <Pine.LNX.4.64.0710260007450.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 25 Oct 2007, Linus Torvalds wrote:
>
>> On Thu, 25 Oct 2007, Johannes Schindelin wrote:
>> >
>> > This behavior is more desirable than fetch + pull when a topic branch
>> > is ready to be submitted.
>>
>> I'd like there to be some *big*warning* about how this destroys history
>> and how you must not do this if you expose your history anywhere else.
>>
>> I think it's a perfectly fine history, but if you have already pushed out
>> your history somewhere else, you're now really screwed. In ways that a
>> *real* merge will never screw you.
>>
>> So the "--rebase" option really is only good for the lowest-level
>> developers. And that should be documented.
>
> Fair enough.
>
> How about this in the man page:
>
> \--rebase::
> Instead of a merge, perform a rebase after fetching.
> *NOTE:* Never do this on branches you plan to publish! This
> command will _destroy_ history, and is thus only suitable for
> topic branches to be submitted to another committer.
Nits.
(1) This "operation" will "rewrite" history.
You are not describing a command, but just one mode of operation
of a command, whose other modes of operation do not share this
history altering behaviour.
The history is rewritten and made hard to work with for others
who have previous incarnation of that history. If it happens
that nobody shared that previously published history nobody
needs to suffer. In that sense, there is something _usable_
depending on who you are. Destroy feels a bit too strong a
word.
(2) This is not suitable for people who publish their trees and
let others fetch and work off of them.
Rebase is fine for e-mail submitting contributors as your
description above suggests, but as your proposed commit log
message said, it is also perfectly appropriate if your
interaction with the outside world is "fetch + rebase +
push". You are not limited to "submitted to another
committer".
^ permalink raw reply
* git-fast-import segfaults
From: cpettitt @ 2007-10-26 0:29 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <de47e4420710251726nb45a19fk15b3105b735a74f8@mail.gmail.com>
I'm seeing the following errors when I run git-fast-import (on Intel
OSX) with some data from a git-p4 import:
[cpettitt@gish scratch2]$ rm -rf .git; git init; git-fast-import < ~/writer.out
Initialized empty Git repository in .git/
git-fast-import(23021) malloc: *** error for object 0x500e50: double free
git-fast-import(23021) malloc: *** set a breakpoint in szone_error to debug
git-fast-import(23021) malloc: *** Deallocation of a pointer not
malloced: 0x501a80; This could be a double free(), or free() called
with the middle of an allocated block; Try setting environment
variable MallocHelp to see tools to help debug
git-fast-import(23021) malloc: *** error for object 0x5020a0: double free
git-fast-import(23021) malloc: *** set a breakpoint in szone_error to debug
git-fast-import(23021) malloc: *** Deallocation of a pointer not
malloced: 0x5007e0; This could be a double free(), or free() called
with the middle of an allocated block; Try setting environment
variable MallocHelp to see tools to help debug
git-fast-import(23021) malloc: *** Deallocation of a pointer not
malloced: 0x5006e0; This could be a double free(), or free() called
with the middle of an allocated block; Try setting environment
variable MallocHelp to see tools to help debug
git-fast-import(23021) malloc: *** Deallocation of a pointer not
malloced: 0x501e10; This could be a double free(), or free() called
with the middle of an allocated block; Try setting environment
variable MallocHelp to see tools to help debug
git-fast-import(23021) malloc: *** Deallocation of a pointer not
malloced: 0x502190; This could be a double free(), or free() called
with the middle of an allocated block; Try setting environment
variable MallocHelp to see tools to help debug
git-fast-import(23021) malloc: *** error for object 0x500280: double free
git-fast-import(23021) malloc: *** set a breakpoint in szone_error to debug
git-fast-import(23021) malloc: *** Deallocation of a pointer not
malloced: 0x5009c0; This could be a double free(), or free() called
with the middle of an allocated block; Try setting environment
variable MallocHelp to see tools to help debug
git-fast-import(23021) malloc: *** error for object 0x500b00:
incorrect checksum for freed object - object was probably modified
after being freed, break at szone_error to debug
git-fast-import(23021) malloc: *** set a breakpoint in szone_error to debug
Segmentation fault
I start getting free errors at fast-import.c:1577:
rc = rc_free;
if (rc)
rc_free = rc->next;
else {
rc = cmd_hist.next;
cmd_hist.next = rc->next;
cmd_hist.next->prev = &cmd_hist;
free(rc->buf); // <-- error is emitted
in free here
}
I believe these errors started showing up in commit
b449f4cfc972929b638b90d375b8960c37790618. I did a bisect on
fast-import.c and this was the first commit for that file that
exhibits this bug with the input.
I thought I would check with the list to see if this is a known issue
before I spend time trying to dig into it.
^ permalink raw reply
* Re: Git and Windows
From: Bo Yang @ 2007-10-26 2:40 UTC (permalink / raw)
Cc: git
In-Reply-To: <Pine.LNX.4.64.0710251517350.25221@racer.site>
Johannes Schindelin :
> Hi,
>
> On Thu, 25 Oct 2007, Bo Yang wrote:
>
>
>> I am a new comer to this list but I have used git for two week
>> development control. I think it is a very cool tool, the only flaw is
>> that I have not found Windows version of it. Does git just aim at Linux
>> kernel development? Is there any plan or in the future to migrate it to
>> windows?
>>
>
> Funny. The first three hits I get from Google are
>
> Wikipedia,
> GitWiki and
> msysgit
>
> The first two pointing to the third. And happily enough, there is a
> Download page at the third site. Oh, and it has a description what its
> affiliation with git is.
>
So, if I want to get invovled with the Windows version git development,
I should download the Gitme, right?
Regards!
Bo
^ permalink raw reply
* [PATCH] Bisect run: "skip" current commit if script exit code is 125.
From: Christian Couder @ 2007-10-26 3:39 UTC (permalink / raw)
To: Junio Hamano, Shawn O. Pearce, Johannes Schindelin; +Cc: git
This is incompatible with previous versions because an exit code
of 125 used to mark current commit as "bad". But hopefully this exit
code is not much used by test scripts or other programs. (126 and 127
are used by bash.)
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-bisect.txt | 8 ++++++--
git-bisect.sh | 11 ++++++++++-
t/t6030-bisect-porcelain.sh | 40 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 56 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index 785f381..14b7a95 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -183,13 +183,17 @@ $ git bisect run my_script
Note that the "run" script (`my_script` in the above example) should
exit with code 0 in case the current source code is good and with a
-code between 1 and 127 (included) in case the current source code is
-bad.
+code between 1 and 127 (included), except 125 that is special, in case
+the current source code is bad.
Any other exit code will abort the automatic bisect process. (A
program that does "exit(-1)" leaves $? = 255, see exit(3) manual page,
the value is chopped with "& 0377".)
+The special exit code 125 should be used when the current source code
+cannot be tested. If the "run" script exits with this code, the current
+revision will be "skip"ped, see `git bisect skip` above.
+
You may often find that during bisect you want to have near-constant
tweaks (e.g., s/#define DEBUG 0/#define DEBUG 1/ in a header file, or
"revision that does not have this commit needs this patch applied to
diff --git a/git-bisect.sh b/git-bisect.sh
index f8d0099..180c6c2 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -392,7 +392,10 @@ bisect_run () {
fi
# Find current state depending on run success or failure.
- if [ $res -gt 0 ]; then
+ # A special exit code of 125 means cannot test.
+ if [ $res -eq 125 ]; then
+ state='skip'
+ elif [ $res -gt 0 ]; then
state='bad'
else
state='good'
@@ -404,6 +407,12 @@ bisect_run () {
cat "$GIT_DIR/BISECT_RUN"
+ if grep "first bad commit could be any of" "$GIT_DIR/BISECT_RUN" \
+ > /dev/null; then
+ echo >&2 "bisect run cannot continue any more"
+ exit $res
+ fi
+
if [ $res -ne 0 ]; then
echo >&2 "bisect run failed:"
echo >&2 "'bisect_state $state' exited with error code $res"
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 16d0c4a..53956c0 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -177,6 +177,46 @@ test_expect_success 'bisect skip and bisect replay' '
git bisect reset
'
+HASH6=
+test_expect_success 'bisect run & skip: cannot tell between 2' '
+ add_line_into_file "6: Yet a line." hello &&
+ HASH6=$(git rev-parse --verify HEAD) &&
+ echo "#"\!"/bin/sh" > test_script.sh &&
+ echo "tail -1 hello | grep Ciao > /dev/null && exit 125" >> test_script.sh &&
+ echo "grep line hello > /dev/null" >> test_script.sh &&
+ echo "test \$? -ne 0" >> test_script.sh &&
+ chmod +x test_script.sh &&
+ git bisect start $HASH6 $HASH1 &&
+ if git bisect run ./test_script.sh > my_bisect_log.txt
+ then
+ echo Oops, should have failed.
+ false
+ else
+ test $? -eq 2 &&
+ grep "first bad commit could be any of" my_bisect_log.txt &&
+ ! grep $HASH3 my_bisect_log.txt &&
+ ! grep $HASH6 my_bisect_log.txt &&
+ grep $HASH4 my_bisect_log.txt &&
+ grep $HASH5 my_bisect_log.txt
+ fi
+'
+
+HASH7=
+test_expect_success 'bisect run & skip: find first bad' '
+ git bisect reset &&
+ add_line_into_file "7: Should be the last line." hello &&
+ HASH7=$(git rev-parse --verify HEAD) &&
+ echo "#"\!"/bin/sh" > test_script.sh &&
+ echo "tail -1 hello | grep Ciao > /dev/null && exit 125" >> test_script.sh &&
+ echo "tail -1 hello | grep day > /dev/null && exit 125" >> test_script.sh &&
+ echo "grep Yet hello > /dev/null" >> test_script.sh &&
+ echo "test \$? -ne 0" >> test_script.sh &&
+ chmod +x test_script.sh &&
+ git bisect start $HASH7 $HASH1 &&
+ git bisect run ./test_script.sh > my_bisect_log.txt &&
+ grep "$HASH6 is first bad commit" my_bisect_log.txt
+'
+
#
#
test_done
--
1.5.3.4.1494.g253d
^ permalink raw reply related
* [PATCH] Test suite: reset TERM to its previous value after testing.
From: Christian Couder @ 2007-10-26 4:13 UTC (permalink / raw)
To: Junio Hamano, Pierre Habouzit; +Cc: git
Using konsole, I get no colored output at the end of "t7005-editor.sh"
without this patch.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
t/t7005-editor.sh | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
This patch should be applied on top of Pierre Habouzit's
"Add some fancy colors in the test library when terminal supports it."
patch.
diff --git a/t/t7005-editor.sh b/t/t7005-editor.sh
index 28643b0..01cc0c0 100755
--- a/t/t7005-editor.sh
+++ b/t/t7005-editor.sh
@@ -4,6 +4,8 @@ test_description='GIT_EDITOR, core.editor, and stuff'
. ./test-lib.sh
+OLD_TERM="$TERM"
+
for i in GIT_EDITOR core_editor EDITOR VISUAL vi
do
cat >e-$i.sh <<-EOF
@@ -88,4 +90,6 @@ do
'
done
+TERM="$OLD_TERM"
+
test_done
--
1.5.3.4.1494.g253d
^ permalink raw reply related
* [PATCH] Make rebase smarter
From: Steven Walter @ 2007-10-26 4:41 UTC (permalink / raw)
To: git, federico; +Cc: Steven Walter
In-Reply-To: <1193328386.4522.352.camel@cacharro.xalalinux.org>
It is a common workflow to run "git fetch; git rebase origin/<foo>" Where
foo is the remote tracking branch. git-rebase should default to using
the remote tracking branch if no other ref is given.
Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
---
git-rebase.sh | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 058fcac..1a2b51b 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -261,8 +261,19 @@ case "$diff" in
;;
esac
-# The upstream head must be given. Make sure it is valid.
upstream_name="$1"
+# Default to the remote tracking branch if we have one
+if [ -z "$upstream_name" ]
+then
+ curr_branch=$(git symbolic-ref -q HEAD)
+ curr_branch=${curr_branch//refs\/heads\//}
+ merge=$(git config branch.$curr_branch.merge)
+ remote=$(git config branch.$curr_branch.remote)
+ fetch=$(git config remote.$remote.fetch)
+
+ expanded=$(git fetch--tool expand-refs-wildcard "0000000000000000000000000000000000000000 $merge" "$remote" "$fetch")
+ upstream_name=${expanded/#*:/}
+fi
upstream=`git rev-parse --verify "${upstream_name}^0"` ||
die "invalid upstream $upstream_name"
--
1.5.3.4.1.gb4ad62-dirty
^ permalink raw reply related
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Steffen Prohaska @ 2007-10-26 6:18 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Junio C Hamano, Theodore Tso, Johannes Schindelin, Peter Baumann,
J. Bruce Fields, Jakub Narebski, Federico Mena Quintero, git
In-Reply-To: <4720FA00.1050805@op5.se>
On Oct 25, 2007, at 10:18 PM, Andreas Ericsson wrote:
> Junio C Hamano wrote:
>> Andreas Ericsson <ae@op5.se> writes:
>
>> With that in mind, how about making "git checkout foo", after
>> foo is set up thusly, to show:
>> git log --pretty=oneline --left-right origin/pu...foo
>> if (and only if) they have diverged? Then you can deal with the
>> staleness of local tracking fork 'foo' in any way you want.
>> You could even go one step further and make this "checkout foo",
>> in addition to or instead of showing the above left-right log,
>> - automatically run "git merge origin/pu" if it is a
>> fast-forward, and say it did _not_ run that merge if it is
>> not a fast-forward;
>> - automatically run "git merge origin/pu" always, even if it is
>> not a fast-forward;
>> - automatically run "git rebase origin/pu" always;
>> Would that make your life easier?
>
> That it would, except the confusion would then be that it's
> automatically
> rebased for the branches one currently hasn't got checked out while
> pulling,
> and the branch that *is* checked out gets merged (crazy, yes), so
> those
> who prefer the rebase would get what they want by doing something
> completely
> bonkers, such as:
>
> git checkout -b just-gonna-pull HEAD^
> git pull
> git checkout whatever-other-branch-they-were-on
>
> (yes, "aggresively ignorant", I think Ted said in an earlier mail)
>
> It'd probably be better to go with Dscho's suggestion, although I'm
> not quite
> sure what that was any more. It involved automagical rebasing on
> fetch or pull
> though.
git pull's automagic and the automatic behaviour of git checkout
proposed by Junio should always do the same. git pull should
be changed to act a if your three commands were fused into it
(but obviously implemented differently).
I think teaching "git checkout" a dwim mode is quite
interesting. The required work to bring a local branch
up-to-date with a remote branch is deferred until really needed.
An then "git checkout" does the right thing. A lot of automagic
but definitely intriguing.
Steffen
^ permalink raw reply
* Re: [PATCH] Bisect run: "skip" current commit if script exit code is 125.
From: Benoit SIGOURE @ 2007-10-26 6:25 UTC (permalink / raw)
To: Christian Couder; +Cc: git list
In-Reply-To: <20071026053937.2831a89b.chriscool@tuxfamily.org>
[-- Attachment #1: Type: text/plain, Size: 1980 bytes --]
On Oct 26, 2007, at 5:39 AM, Christian Couder wrote:
> This is incompatible with previous versions because an exit code
> of 125 used to mark current commit as "bad". But hopefully this exit
> code is not much used by test scripts or other programs. (126 and 127
> are used by bash.)
>
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> ---
> Documentation/git-bisect.txt | 8 ++++++--
> git-bisect.sh | 11 ++++++++++-
> t/t6030-bisect-porcelain.sh | 40 +++++++++++++++++++++++++++++++
> +++++++++
> 3 files changed, 56 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-bisect.txt b/Documentation/git-
> bisect.txt
> index 785f381..14b7a95 100644
> --- a/Documentation/git-bisect.txt
> +++ b/Documentation/git-bisect.txt
> @@ -183,13 +183,17 @@ $ git bisect run my_script
>
> Note that the "run" script (`my_script` in the above example) should
> exit with code 0 in case the current source code is good and with a
> -code between 1 and 127 (included) in case the current source code is
> -bad.
> +code between 1 and 127 (included), except 125 that is special, in
> case
> +the current source code is bad.
>
> Any other exit code will abort the automatic bisect process. (A
> program that does "exit(-1)" leaves $? = 255, see exit(3) manual
> page,
> the value is chopped with "& 0377".)
>
> +The special exit code 125 should be used when the current source code
> +cannot be tested. If the "run" script exits with this code, the
> current
> +revision will be "skip"ped, see `git bisect skip` above.
> +
> You may often find that during bisect you want to have near-constant
> tweaks (e.g., s/#define DEBUG 0/#define DEBUG 1/ in a header file, or
> "revision that does not have this commit needs this patch applied to
Since exit 77 is already used by automake to mean "skip", wouldn't it
be better to do the same thing here?
Cheers,
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ 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