* pull --preserve-merges
From: Stephen Haberman @ 2008-11-07 22:01 UTC (permalink / raw)
To: git
Hi,
Awhile ago I brought up wanting to have a "rebase with preserve merges"
option for `git pull`:
http://thread.gmane.org/gmane.comp.version-control.git/96513
Andreas had a patch to help by supporting manually typing out `git pull
--rebase --preserve-merges`:
http://thread.gmane.org/gmane.comp.version-control.git/96593
And then I did another small copy/paste patch on top to add a config
setting of `branch.<name>.preservemerges` much like the existing
`branch.<name>.rebase`.
The patches haven't gotten an explicit "no" that I noticed, nor have
they been applied...is there anything I can do to move them along?
Resubmit them or what not?
Thanks,
Stephen
^ permalink raw reply
* Re: Issue updating files during a checkout from a remote push
From: Jeff King @ 2008-11-07 21:59 UTC (permalink / raw)
To: Steve Walker; +Cc: git
In-Reply-To: <09C2A669-2B99-4490-9C95-FCCD76C03D61@idibu.com>
On Thu, Nov 06, 2008 at 06:17:54PM +0100, Steve Walker wrote:
> Sorry to keep answering my own questions directly after posting...
>
> I just tried with a 'git commit -f' and the files updated.
There is no "-f" option to commit. Did you mean "checkout -f"?
If that is the case, then yes, that will "fix" your problem in that it
brings the HEAD, index, and working tree into sync. But it is dangerous
in that it throws away any local changes you might have had.
If you did really mean "commit" then that is also a bad solution. It
creates a new commit on top of the recently pushed work that reverts all
of the changes made by the recently pushed work.
-Peff
^ permalink raw reply
* Re: Issue updating files during a checkout from a remote push
From: Jeff King @ 2008-11-07 21:56 UTC (permalink / raw)
To: Steve Walker; +Cc: git
In-Reply-To: <334B3AB1-125A-4163-BEBC-9A73C4F569B5@idibu.com>
On Thu, Nov 06, 2008 at 06:04:20PM +0100, Steve Walker wrote:
> The overall issue is that with files that have been pushed into our repo
> on our server, when we then check out into local working copy the new
> files appear, but the updated files dont update even though the output
> suggests it has. The flow I'm doing:
The short answer is: don't push into the current branch of a non-bare
repo.
> 2. On my local box I change file, add it, commit, then push it from my
> local box to our server repo:
OK, so this updates the HEAD of the receiving repository. But the index
and working tree are untouched.
> 3. It all looks good, on my server if i do a 'git log' I can see in the
> latest update:
Right, because the HEAD has been updated.
> 4. So I check out:
>
> oneworld:/home/beta_idibu/public_html# git checkout master
> M .gitignore
> M steve-git-test.txt
> M steve-git-test2.txt
> M steve-git-test3.txt
> Already on branch "master"
> oneworld:/home/beta_idibu/public_html#
But you were already _on_ master, so git shouldn't need to touch the
index and working tree. But the contents of master have changed out from
under you, so it looks like you have modifications.
So generally you don't want to push to the current branch, but there is
no safety valve disallowing it (and I will post a patch series in a
minute which introduces one). In the past, people have suggested doing a
merge with the working tree, but that is not desirable for two reasons:
1. you are changing the working tree out from under whoever's repo you
push into
2. the merge might not be clean, in which case the user needs to
resolve conflicts. But the user isn't even doing stuff in the
now-conflicted repository. So the suggested workflow is instead to
go to that repo and do a 'pull'
So depending on what you want to accomplish, there are a number of
alternative workflows:
- if you just want to publish refs, you can use a bare repo without a
working tree at all (git --bare init, or git clone --bare).
- if you just want to throw away working tree changes on a push (e.g.,
you are pushing to a production server whose working tree is kept up
to date), you can do that automatically with a post-receive hook. But
it will never be the default, because we don't want to throw anything
away unless the user has explicitly told us to do so.
- if you are working in repos A and B, and you want to get changes from
B to A, then you would generally go to A and "git pull B". But
sometimes that is not possible (e.g., you can only make network
connections one way). In that case, you can push to a "remote" branch
on A, and then merge from there when you're at A. E.g.,:
/repo/B$ git push /repo/A master:refs/remotes/B/master
/repo/B$ cd /repo/A
/repo/A$ git merge B/master
-Peff
^ permalink raw reply
* Re: absurdly slow git-diff
From: Linus Torvalds @ 2008-11-07 21:37 UTC (permalink / raw)
To: Abhijit Menon-Sen, Pierre Habouzit, Davide Libenzi; +Cc: Git Mailing List
In-Reply-To: <20081107200126.GA20284@toroid.org>
On Sat, 8 Nov 2008, Abhijit Menon-Sen wrote:
>
> If anyone's interested, the files are http://toroid.org/misc/1 and
> http://toroid.org/misc/2
Btw, you can see this by just doing
git diff 1 2
without even doing "git init" or doing any actual git repository.
> Does anyone understand why this slowdown might happen or have
> suggestions about where I should look for it?
Sure. It's actually fairly simple. You're hitting a O(n^2) thing (possibly
higher), and it's triggered by the fact that almost all your lines are
identical, ie you have a file that basically has 40,000 lines of each of
xxxx: xxx, xx xxx xxxx xx:xx:xx +xxxx
xx: xxxx xxxxxxxxxxx <xxxx@xxxx.xxx>
xxxx: xxxx xxxxxxxxxxx <xxxx@xxxx.xxx>
and 30,000 of
* xxxxx xxxxx (xxxxxx.xxxx xxx xxxxx (\Xxxxxx) xxxxxx.xxxxxx {xxx}
with a smattering of others. And this is a case where the internal git
implementation does really badly. And nobody has really cared before,
because nobody has ever had a case that mattered.
There's a number of different 'diff' algorithms, and it looks like GNU
diff has one that avoids the O(n^2) case for this case.
I'm adding Davide as the original author of the diff library to the cc.
I'm also adding Pierre, since he was talking about trying to implement
another diff algorithm (although I'm not at all sure that the patience
diff really would help this case at all).
Linus
^ permalink raw reply
* Re: absurdly slow git-diff
From: Mike Hommey @ 2008-11-07 21:28 UTC (permalink / raw)
To: Abhijit Menon-Sen; +Cc: git
In-Reply-To: <20081107200126.GA20284@toroid.org>
On Sat, Nov 08, 2008 at 01:31:27AM +0530, Abhijit Menon-Sen wrote:
> I have a 240k-line file, and I change one character on every sixth line.
> The resulting diff gives git serious indigestion:
>
> $ git --version
> git version 1.6.0.3.640.g6331a
> $ mkdir a; cd a; git init
> Initialized empty Git repository in /home/ams/a/.git/
> $ cp ../1 .; git add 1; git commit -q -m 1
> $ cp ../2 1; git add 1; git commit -q -m 2
You don't need to go that far. You can stop at cp ../2 1 and run git
diff from there.
All the time is spent in the two loops in
xdiff/xprepare.c:xdl_cleanup_records, on line 400 and 412.
I'll leave the rest of the investigation to people actually knowing this
code ;)
Mike
^ permalink raw reply
* Re: [PATCH 2/3] Introduce rename factorization in diffcore.
From: Junio C Hamano @ 2008-11-07 21:11 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20081107203952.GJ5158@nan92-1-81-57-214-146.fbx.proxad.net>
Yann Dirson <ydirson@altern.org> writes:
> On Fri, Nov 07, 2008 at 12:19:14PM -0800, Junio C Hamano wrote:
>> I am afraid that this is totally unacceptable, as you yourself mentioned,
>> the end result is unapplicable with any existing tool and would confuse
>> viewers like gitk and gitweb.
>
> Well, other tools will still have to be taught about a new syntax, if
> they're going to use the new flag - just like it was for --rename.
You are mistaken. For a patch, you are dealing with two different
parties: producer and consumer. If you are adding new feature to the
producer, the output format should be desigend to allow the consumer tell
that it is something it does not know how to handle.
Marking a non patch with "diff --git" to trigger the logic to signal the
beginning of a patch to git-apply (and perhaps other tools) is a non
starter.
And for this "we are giving a patch that your git-apply can apply and gitk
can show, but by the way we also think the whole directory foo moved to
new location bar" is merely an additional information. You should still
be able to apply the patch with tools that are unaware of this new
directory move detection feature.
^ permalink raw reply
* Re: [minor usability suggestion] git rebase <upstream> --onto <newbase> ?
From: Junio C Hamano @ 2008-11-07 21:06 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Ingo Molnar, git
In-Reply-To: <alpine.LNX.1.00.0811071504110.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> "git log origin/master -p" works, though.
That's an accident. Do not rely on it.
^ permalink raw reply
* Re: git-push and $GIT_DIR/branches
From: Martin Koegler @ 2008-11-07 20:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vljvvh61y.fsf@gitster.siamese.dyndns.org>
On Fri, Nov 07, 2008 at 08:08:57AM -0800, Junio C Hamano wrote:
> mkoegler@auto.tuwien.ac.at (Martin Koegler) writes:
>
> > I think, that the git-push behaviour is a bit unlogical in conjunction
> > with $GIT_DIR/branches.
>
> That is because it is illogical to use $GIT_DIR/branches in conjunction
> with git; the former is a backward compatibility wart with Cogito which is
> now dead.
I'm aware, that $GIT_DIR/branches origins from Cogito and are not
recommended. But eg. Documentation/urls-remotes.txt does not reflect
this.
I asume, that you [and probably many other] are not very interrested
in this feature. But would you accept a patch changing the push
refspec to HEAD:refs/heads/<head>?
mfg Martin Kögler
^ permalink raw reply
* Re: [PATCH 2/3] Introduce rename factorization in diffcore.
From: Yann Dirson @ 2008-11-07 20:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3ai3gugt.fsf@gitster.siamese.dyndns.org>
On Fri, Nov 07, 2008 at 12:19:14PM -0800, Junio C Hamano wrote:
> I am afraid that this is totally unacceptable, as you yourself mentioned,
> the end result is unapplicable with any existing tool and would confuse
> viewers like gitk and gitweb.
Well, other tools will still have to be taught about a new syntax, if
they're going to use the new flag - just like it was for --rename.
That makes me think that it could be interesting to have a header
telling which diff extensions it is using. It could even be
interesting to come with a cross-vc convention, which would ease the
interchange of modern patch files (I suppose some other tools already
have their own extensions for file renames).
What about some hint like the following ?
|extended diff features: git:rename git:binary git:filetypes
|extended diff features: git:unixperms git:dir-rename
Maybe we could leave "filetype" and "unixperms" out, since these do
not replace an information that would otherwise be present in a
standard diff anyway, and would just be ignored by a tool not
supporting them.
> I think it would be a much better approach to emit a hint that talks about
> directory rename in a format that does not fool usual "patch" application
> tools. E.g.
>
> |directory moved with similarity index 82%
> |rename from ppc
> |rename from foo
> |diff --git a/ppc/sha1.h b/foo/sha1.h
> |similarity index 85%
> |rename from ppc/sha1.h
> |rename to foo/sha1.h
> |index 9b34f76..8fce4b7 100644
> |--- ppc/sha1.h
> |+++ foo/sha1.h
> |@@ ...
So you're favoring the "patch is not textually splittable approach".
Don't you think it would be good to add some sort of hint about this
as a patch header ?
> IOW, do not add anything that begins with "diff --git" if it is not a
> patch.
OK.
^ permalink raw reply
* absurdly slow git-diff
From: Abhijit Menon-Sen @ 2008-11-07 20:01 UTC (permalink / raw)
To: git
I have a 240k-line file, and I change one character on every sixth line.
The resulting diff gives git serious indigestion:
$ git --version
git version 1.6.0.3.640.g6331a
$ mkdir a; cd a; git init
Initialized empty Git repository in /home/ams/a/.git/
$ cp ../1 .; git add 1; git commit -q -m 1
$ cp ../2 1; git add 1; git commit -q -m 2
$ time git show HEAD > x
git show HEAD > x 309.88s user 0.46s system 97% cpu 5:17.06 total
(I use commit -q above not only for brevity; for the second commit,
calculating the diffstat takes the same five minutes that git show,
git log -p, git log --stat etc. all take.)
Note that diff(1) can handle the patch fine:
$ time diff -u ../1 ../2 >/dev/null
diff -u ../1 ../2 > /dev/null 0.30s user 0.06s system 69% cpu 0.519 total
If anyone's interested, the files are http://toroid.org/misc/1 and
http://toroid.org/misc/2
Does anyone understand why this slowdown might happen or have
suggestions about where I should look for it?
Thanks.
-- ams
^ permalink raw reply
* Re: [PATCH 2/3] Introduce rename factorization in diffcore.
From: Junio C Hamano @ 2008-11-07 20:19 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20081107193957.GI5158@nan92-1-81-57-214-146.fbx.proxad.net>
Yann Dirson <ydirson@altern.org> writes:
> The direct transposition of the raw output of a dir rename with a
> change would yield something like:
>
> |diff --git a/ppc/ b/foo
> |similarity index 100%
> |rename from ppc/
> |rename to foo/
> |diff --git a/ppc/sha1.h b/foo/sha1.h
> |--- ppc/sha1.h
> |+++ foo/sha1.h
> |...
>
> This would have the usefulness I'm looking for, in that the content
> modifications would not be "hidden" among a whole lot af individual
> file rename hunks.
I am afraid that this is totally unacceptable, as you yourself mentioned,
the end result is unapplicable with any existing tool and would confuse
viewers like gitk and gitweb.
I think it would be a much better approach to emit a hint that talks about
directory rename in a format that does not fool usual "patch" application
tools. E.g.
|directory moved with similarity index 82%
|rename from ppc
|rename from foo
|diff --git a/ppc/sha1.h b/foo/sha1.h
|similarity index 85%
|rename from ppc/sha1.h
|rename to foo/sha1.h
|index 9b34f76..8fce4b7 100644
|--- ppc/sha1.h
|+++ foo/sha1.h
|@@ ...
IOW, do not add anything that begins with "diff --git" if it is not a
patch.
^ permalink raw reply
* Re: [minor usability suggestion] git rebase <upstream> --onto <newbase> ?
From: Daniel Barkalow @ 2008-11-07 20:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ingo Molnar, git
In-Reply-To: <7vej1ngztd.fsf@gitster.siamese.dyndns.org>
On Fri, 7 Nov 2008, Junio C Hamano wrote:
> Ingo Molnar <mingo@elte.hu> writes:
>
> > earth4:~/tip> git rebase 685aebb --onto linus
> > Current branch core/urgent is up to date.
> > ...
> > For example "git log" is exemplary in this area as it accepts just
> > about any permutation of parameters thrown at it, ...
>
> Not really.
>
> There may be oddball commands whose parameter order have been established
> differently long before "git log" came, but almost all of them now use the
> same convention used by the "git log" family, which is flags/options then
> revs (and then paths if the operation makes sense with paths). And rebase
> is not one of the oddball ones.
>
> Your "rebase" example is a rev then a flag/option, which is not how any
> other git command take its command line parameters.
"git log origin/master -p" works, though. It's paths, not revisions, that
can't appear before options (or revisions).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 2/3] Introduce rename factorization in diffcore.
From: Yann Dirson @ 2008-11-07 19:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy6zwgx3i.fsf@gitster.siamese.dyndns.org>
On Thu, Nov 06, 2008 at 05:10:09PM -0800, Junio C Hamano wrote:
> Yann Dirson <ydirson@altern.org> writes:
>
> > Rename factorization tries to group together files moving from and to
> > identical directories - the most common case being directory renames.
> > We do that by first identifying groups of bulk-moved files, and then
> > hiding those of the individual renames which carry no other
> > information (further name change, or content changes).
> > This feature is activated by the new --factorize-renames diffcore
> > flag.
>
> I have a mixed feeling about this one, primarily because I cannot
> visualize how a useful output should look like. Unless you rename one
> directory to another without any content changes, you would have to say
> "this directory changed to that, and among the paths underneath them, this
> file have this content change in addition".
Right. This is something I have already thought about, without taking
the time to finalize. So let's have a try.
The direct transposition of the raw output of a dir rename with a
change would yield something like:
|diff --git a/ppc/ b/foo
|similarity index 100%
|rename from ppc/
|rename to foo/
|diff --git a/ppc/sha1.h b/foo/sha1.h
|--- ppc/sha1.h
|+++ foo/sha1.h
|...
This would have the usefulness I'm looking for, in that the content
modifications would not be "hidden" among a whole lot af individual
file rename hunks.
But if we want to make this more generally useful (eg. allow other
tools to apply such patches), we need to be careful. A typical patch
file can usually be seen as a sequence of changes which can be applied
independently (at least in order). It is obvious that this is not
true for the above output. So we could also consider making this
patch output sequential with something like:
|diff --git a/ppc/ b/foo
|similarity index 100%
|rename from ppc/
|rename to foo/
|diff --git a/foo/sha1.h b/foo/sha1.h
|--- foo/sha1.h
|+++ foo/sha1.h
|...
However, such output would possibly be confusing, eg. when looking at
it from gitk and looking for commits which modify ppc/sha1.h.
A solution to this could be to add an annotation such as:
|diff --git a/ppc/ b/foo
|similarity index 100%
|rename from ppc/
|rename to foo/
|diff --git a/foo/sha1.h b/foo/sha1.h
|--- foo/sha1.h (previously ppc/sha1.h)
|+++ foo/sha1.h
|...
That would make the "git diff" format diverge a bit more from the
standard, but since a full-fledged git patch already cannot be used by
standard patch tools, it should not be a big issue - we should just be
careful about choosing a suitable format if we go that way.
But as we already change the patch format, we could also simply say
that we don't care about the patch being "litterally splittable", add
a "this is a non-splittable whole" note at the beginning of the patch
output, and go with the litteral solution shown as first example.
How do you feel wrt this ?
> A related feature that would benefit from something like your change
> without any downside/complication of output format issues is to boost
> rename similarity score of a path when its neighbouring paths are moved to
> the same location.
Yes, that could be triggered by distinct switches.
Doing this would be related to detecting "directory splits" (ie. when
some files are really not moved, or moved into several dirs instead of
being all moved to the same target dir). We can start by detecting
dir-splits, then shift the scoring threshold and do another pass on
split dirs.
^ permalink raw reply
* Re: [PATCH v2 3/3] pack-objects: honor '.keep' files
From: Shawn O. Pearce @ 2008-11-07 19:25 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Brandon Casey, Junio C Hamano, Git Mailing List, Nicolas Pitre
In-Reply-To: <4913F859.8070500@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
>
> Only -d should honor .keep, imo. .keep-files is nothing about "don't copy
> objects from this file" and all about "never delete this file".
>
> The only muddying comes from you, who decided that .keep-files should
> have impact on anything else than deleting the protected pack. Before that,
> .keep files had a clear semantic, and repack's documentation was correct.
>
> How do you explain .keep-files now? "protects pack-files that will forever
> be used"? Then why the hell is it called ".keep" instead of "eternal"?
The _intent_ behind .keep files has always been to avoid copying
the objects into a new pack during git-repack, because the objects
are held in a pack that cannot be deleted.
Sadly the implementation has never quite worked right, which is
what led to this patch series I think.
--
Shawn.
^ permalink raw reply
* Re: [PATCH/RFC v3] git add -i: Answer questions with a single keypress
From: Jeff King @ 2008-11-07 19:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk5bgiy18.fsf@gitster.siamese.dyndns.org>
On Thu, Nov 06, 2008 at 09:06:59AM -0800, Junio C Hamano wrote:
> Thanks. And thanks, Jeff, for being a good reviewer.
You're welcome. I'm trying to lead by example. :)
-Peff
^ permalink raw reply
* Re: [PATCH/RFC v3] git add -i: Answer questions with a single keypress
From: Jeff King @ 2008-11-07 19:19 UTC (permalink / raw)
To: Suraj N. Kurapati; +Cc: git
In-Reply-To: <200811060815.16797.sunaku@gmail.com>
On Thu, Nov 06, 2008 at 08:15:16AM -0800, Suraj N. Kurapati wrote:
> v1 and v2 make the mistake of setting raw mode, which prevent the user from
> pressing Control-C to exit the program. v3 fixes this by using cbreak mode.
OK, makes sense.
> The git-svn.perl script also uses Term::ReadKey. Since it is already in the
> git source repository, I thought it was okay to use Term::ReadKey.
We are not always consistent with such things, and git-add--interactive
is a little "more core" than git-svn, I think. Still, maybe I am being
overly cautious. We can always try it and see who complains. ;)
I think considering this improvement:
> > - This only enhances one particular input, the patch loop. It is
> > probably worth being consistent and allowing these behavior for other
> > menus (though the numeric inputs are a bit trickier).
>
> Understood.
it makes sense to factor the ReadKey procedure into a separate function
anyway. At which point it should be easy enough to substitute in the
original behavior if there is no ReadKey.
Side note: I don't know if such people exist, but I suppose it is
possible that somebody would _prefer_ the old behavior. In which case
factoring it out will also make it easier to predicate the behavior on a
config variable, if people want that.
-Peff
^ permalink raw reply
* [BUG] git-log --follow incompatibile with --max-count
From: Jakub Narebski @ 2008-11-07 18:38 UTC (permalink / raw)
To: git; +Cc: Blucher, Guy
First, it is a bit strange that while "git log" understand '--follow'
option, "git rev-parse" (the plumbing equivalent to be used in scripts)
does not.
Second, somehow "git log --follow <filename>" is incompatible with
'-n' / '--max-count':
$ git log --max-count=10 --follow --pretty=oneline --abbrev-commit gitweb/gitweb.perl
f24dce1... gitweb: Separate features with no project specific override
61b4606... gitweb: Better processing format string in custom links in navbar
$ git log --max-count=10 --pretty=oneline --abbrev-commit gitweb/gitweb.perl
f24dce1... gitweb: Separate features with no project specific override
61b4606... gitweb: Better processing format string in custom links in navbar
8db49a7... gitweb: generate parent..current URLs
b0be383... gitweb: parse parent..current syntax from PATH_INFO
3550ea7... gitweb: use_pathinfo filenames start with /
b02bd7a... gitweb: generate project/action/hash URLs
d8c2882... gitweb: parse project/action/hash_base:filename PATH_INFO
1b2d297... gitweb: refactor input parameters parse/validation
3e3d4ee... Merge branch 'pb/gitweb-tagcloud' into pb/gitweb
0d1d154... gitweb: Support for simple project search form
$ git log --max-count=10 --pretty=oneline --abbrev-commit gitweb/gitweb.perl | wc -l
10
Without '--nax-count' it works correctly:
$ git log --pretty=oneline --abbrev-commit gitweb/gitweb.perl | wc -l
446
$ git log --follow --pretty=oneline --abbrev-commit gitweb/gitweb.perl | wc -l
485
Both bugs were noticed by Guy Blucher when writing 'historyfollow'
patch for gitweb:
"[RFC] gitweb: add 'historyfollow' view that follows renames"
Msg-ID: <054F21930D24A0428E5B4588462C7AED0149B4B8@ednex512.dsto.defence.gov.au>
http://permalink.gmane.org/gmane.comp.version-control.git/99199
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [minor usability suggestion] git rebase <upstream> --onto <newbase> ?
From: Junio C Hamano @ 2008-11-07 18:23 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20081107092035.GA1339@elte.hu>
Ingo Molnar <mingo@elte.hu> writes:
> earth4:~/tip> git rebase 685aebb --onto linus
> Current branch core/urgent is up to date.
> ...
> For example "git log" is exemplary in this area as it accepts just
> about any permutation of parameters thrown at it, ...
Not really.
There may be oddball commands whose parameter order have been established
differently long before "git log" came, but almost all of them now use the
same convention used by the "git log" family, which is flags/options then
revs (and then paths if the operation makes sense with paths). And rebase
is not one of the oddball ones.
Your "rebase" example is a rev then a flag/option, which is not how any
other git command take its command line parameters.
> Or at least we should print some sort of warning/error?
With that I agree with. Patches? ;-)
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Linus Torvalds @ 2008-11-07 18:08 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, Miles Bader, git
In-Reply-To: <20081107071231.GA4063@blimp.localdomain>
On Fri, 7 Nov 2008, Alex Riesen wrote:
>
> Does not work if there are ranges given :-/
> It'd be very nice to have: git show #c1..$c2 $c3 $c4 $c5..$c6
Yeah, we've very fundamentally never supported that. Not for show, but
also not for anything else (ie "gitk a..b c..d" does _not_ give you two
ranges).
It's easy to see why once you understand what 'a..b' really means (ie it
just expands to '^a' and 'b'), and how it's not really a "range" operation
as much as a set operation that interacts with all the other arguments
too. But unless you're very aware of that, it can be surprising.
Linus
^ permalink raw reply
* Re: [PATCH] checkout: Don't crash when switching away from an invalid branch.
From: Johannes Schindelin @ 2008-11-07 18:05 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git
In-Reply-To: <871vxnbhbh.fsf@wine.dyndns.org>
Hi,
On Fri, 7 Nov 2008, Alexandre Julliard wrote:
> I have a tree where for some reason HEAD was pointing to an invalid
> commit. I'm not sure how this happened, but git checkout should be able
> to recover from that situation without crashing.
Agree.
> diff --git a/builtin-checkout.c b/builtin-checkout.c
> index 57b94d2..7c1b8cd 100644
> --- a/builtin-checkout.c
> +++ b/builtin-checkout.c
> @@ -47,7 +47,8 @@ static int post_checkout_hook(struct commit *old, struct commit *new,
>
> memset(&proc, 0, sizeof(proc));
> argv[0] = name;
> - argv[1] = xstrdup(sha1_to_hex(old->object.sha1));
> + argv[1] = old ? xstrdup(sha1_to_hex(old->object.sha1))
> + : "0000000000000000000000000000000000000000";
I guess you want to use the variable null_sha1 here.
> @@ -492,10 +493,13 @@ static void update_refs_for_switch(struct checkout_opts *opts,
> }
>
> old_desc = old->name;
> - if (!old_desc)
> + if (!old_desc && old->commit)
> old_desc = sha1_to_hex(old->commit->object.sha1);
> - strbuf_addf(&msg, "checkout: moving from %s to %s",
> - old_desc, new->name);
> + if (old_desc)
> + strbuf_addf(&msg, "checkout: moving from %s to %s",
> + old_desc, new->name);
> + else
> + strbuf_addf(&msg, "checkout: moving to %s", new->name);
Why not
old_desc ? old_desc : "(invalid)"
?
> diff --git a/t/t2011-checkout-invalid-head.sh b/t/t2011-checkout-invalid-head.sh
> new file mode 100755
Nice!
Thank you,
Dscho
^ permalink raw reply
* [PATCH] checkout: Don't crash when switching away from an invalid branch.
From: Alexandre Julliard @ 2008-11-07 17:02 UTC (permalink / raw)
To: git
I have a tree where for some reason HEAD was pointing to an invalid
commit. I'm not sure how this happened, but git checkout should be
able to recover from that situation without crashing.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
builtin-checkout.c | 14 +++++++++-----
t/t2011-checkout-invalid-head.sh | 18 ++++++++++++++++++
2 files changed, 27 insertions(+), 5 deletions(-)
create mode 100755 t/t2011-checkout-invalid-head.sh
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 57b94d2..7c1b8cd 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -47,7 +47,8 @@ static int post_checkout_hook(struct commit *old, struct commit *new,
memset(&proc, 0, sizeof(proc));
argv[0] = name;
- argv[1] = xstrdup(sha1_to_hex(old->object.sha1));
+ argv[1] = old ? xstrdup(sha1_to_hex(old->object.sha1))
+ : "0000000000000000000000000000000000000000";
argv[2] = xstrdup(sha1_to_hex(new->object.sha1));
argv[3] = changed ? "1" : "0";
argv[4] = NULL;
@@ -492,10 +493,13 @@ static void update_refs_for_switch(struct checkout_opts *opts,
}
old_desc = old->name;
- if (!old_desc)
+ if (!old_desc && old->commit)
old_desc = sha1_to_hex(old->commit->object.sha1);
- strbuf_addf(&msg, "checkout: moving from %s to %s",
- old_desc, new->name);
+ if (old_desc)
+ strbuf_addf(&msg, "checkout: moving from %s to %s",
+ old_desc, new->name);
+ else
+ strbuf_addf(&msg, "checkout: moving to %s", new->name);
if (new->path) {
create_symref("HEAD", new->path, msg.buf);
@@ -551,7 +555,7 @@ static int switch_branches(struct checkout_opts *opts, struct branch_info *new)
* a new commit, we want to mention the old commit once more
* to remind the user that it might be lost.
*/
- if (!opts->quiet && !old.path && new->commit != old.commit)
+ if (!opts->quiet && !old.path && old.commit && new->commit != old.commit)
describe_detached_head("Previous HEAD position was", old.commit);
if (!old.commit) {
diff --git a/t/t2011-checkout-invalid-head.sh b/t/t2011-checkout-invalid-head.sh
new file mode 100755
index 0000000..764bb0a
--- /dev/null
+++ b/t/t2011-checkout-invalid-head.sh
@@ -0,0 +1,18 @@
+#!/bin/sh
+
+test_description='checkout switching away from an invalid branch'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ echo hello >world &&
+ git add world &&
+ git commit -m initial
+'
+
+test_expect_success 'checkout master from invalid HEAD' '
+ echo 0000000000000000000000000000000000000000 >.git/HEAD &&
+ git checkout master --
+'
+
+test_done
--
1.6.0.3.669.g76740
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* Re: [PATCH (GITK) v3 6/6] gitk: Explicitly position popup windows.
From: Johannes Sixt @ 2008-11-07 16:37 UTC (permalink / raw)
To: Alex Riesen; +Cc: Paul Mackerras, Alexander Gavrilov, git
In-Reply-To: <81b0412b0811070639q47244bc4t10791781fb0ec43b@mail.gmail.com>
Alex Riesen schrieb:
> 2008/11/7 Paul Mackerras <paulus@samba.org>:
>> Is there any reason to call tk::PlaceWindow under Linux or MacOS?
>> If not I'd rather add an if statement so we only call it on Windows.
>>
>
> Yes, please. I rather like the smart placement in compiz.
Just out of curiosity because I don't use compiz: Did you mean
"Yes, please call tk::PlaceWindow on Linux"
or
"Yes, please add the if statement"
? ;)
-- Hannes
^ permalink raw reply
* Re: [PATCH (GITK) v3 6/6] gitk: Explicitly position popup windows.
From: Alex Riesen @ 2008-11-07 14:39 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Alexander Gavrilov, git
In-Reply-To: <18708.11537.229423.296701@cargo.ozlabs.ibm.com>
2008/11/7 Paul Mackerras <paulus@samba.org>:
> Alexander Gavrilov writes:
>
>> For some reason, on Windows all transient windows are placed
>> in the upper left corner of the screen. Thus, it is necessary
>> to explicitly position the windows relative to their parent.
>> For simplicity this patch uses the function that is used
>> internally by Tk dialogs.
>
> Is there any reason to call tk::PlaceWindow under Linux or MacOS?
> If not I'd rather add an if statement so we only call it on Windows.
>
Yes, please. I rather like the smart placement in compiz.
^ permalink raw reply
* [PATCH 2/2] diffcore-rename: add config option to allow to cache renames
From: Nguyễn Thái Ngọc Duy @ 2008-11-07 14:35 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1226068533-10152-1-git-send-email-pclouds@gmail.com>
If diff.cacherenames is true, then renames will be cached to
$GIT_DIR/rename-cache. By default, it will not overwrite existing
cache. Add --refresh-cache to overwrite.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
if git-svn is going to use this, then perharps we should add a rule to prevent
overwriting certain cache files with .keep files, so that git-svn generated cache
does not get lost
Documentation/config.txt | 5 ++++
Documentation/diff-options.txt | 5 ++++
diff.c | 12 +++++++++++
diff.h | 2 +
diffcore-rename.c | 41 ++++++++++++++++++++++++++++++++++++++++
t/t4030-rename-cache.sh | 27 ++++++++++++++++++++++++++
6 files changed, 92 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 29369d0..81160d3 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -630,6 +630,11 @@ diff.renames::
will enable basic rename detection. If set to "copies" or
"copy", it will detect copies, as well.
+diff.cacherenames::
+ Tells git to automatically cache renames when detected. The
+ cache resides in $GIT_DIR/rename-cache, which is used by git
+ if exists.
+
fetch.unpackLimit::
If the number of objects fetched over the git native
transfer is below this
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index c62b45c..d477a40 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -102,6 +102,11 @@ endif::git-format-patch[]
Turn off rename detection, even when the configuration
file gives the default to do so.
+--refresh-rename-cache::
+ By default, when git finds a cached version of a commit, it
+ will not overwrite the cache. This option makes git overwrite
+ old cache or create a new one.
+
--check::
Warn if changes introduce trailing whitespace
or an indent that uses a space before a tab. Exits with
diff --git a/diff.c b/diff.c
index e368fef..1d65bd9 100644
--- a/diff.c
+++ b/diff.c
@@ -26,6 +26,7 @@ int diff_use_color_default = -1;
static const char *external_diff_cmd_cfg;
int diff_auto_refresh_index = 1;
static int diff_mnemonic_prefix;
+static int diff_cache_renames;
static char diff_colors[][COLOR_MAXLEN] = {
"\033[m", /* reset */
@@ -109,6 +110,11 @@ int git_diff_basic_config(const char *var, const char *value, void *cb)
return 0;
}
+ if (!strcmp(var, "diff.cacherenames")) {
+ diff_cache_renames = git_config_bool(var, value);
+ return 0;
+ }
+
if (!prefixcmp(var, "diff.color.") || !prefixcmp(var, "color.diff.")) {
int slot = parse_diff_color_slot(var, 11);
if (!value)
@@ -2248,6 +2254,8 @@ int diff_setup_done(struct diff_options *options)
if (options->detect_rename && options->rename_limit < 0)
options->rename_limit = diff_rename_limit_default;
+ if (options->detect_rename)
+ options->cache_renames = diff_cache_renames;
if (options->setup & DIFF_SETUP_USE_CACHE) {
if (!active_cache)
/* read-cache does not die even when it fails
@@ -2415,6 +2423,10 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
DIFF_OPT_SET(options, RELATIVE_NAME);
options->prefix = arg + 11;
}
+ else if (!strcmp(arg, "--refresh-rename-cache")) {
+ options->cache_renames = 1;
+ options->refresh_rename_cache = 1;
+ }
/* xdiff options */
else if (!strcmp(arg, "-w") || !strcmp(arg, "--ignore-all-space"))
diff --git a/diff.h b/diff.h
index 8b68f6f..eb97955 100644
--- a/diff.h
+++ b/diff.h
@@ -85,6 +85,8 @@ struct diff_options {
int pickaxe_opts;
int rename_score;
int rename_limit;
+ int cache_renames;
+ int refresh_rename_cache;
int warn_on_too_large_rename;
int dirstat_percent;
int setup;
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 598cc8d..2b87e4e 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -527,6 +527,44 @@ static void load_rename_cache(struct diff_queue_struct *q,
free_hash(&filepair_table);
}
+static void save_rename_cache(struct diff_queue_struct *outq,
+ struct diff_options *options)
+{
+ int i;
+ FILE *fp = NULL;
+ struct stat st;
+
+ for (i = 0;i < outq->nr; i++) {
+ struct diff_filepair *dp = outq->queue[i];
+
+ if (!(dp->renamed_pair || /* rename pair */
+ (!DIFF_FILE_VALID(dp->one) && DIFF_FILE_VALID(dp->two)))) /* create pair */
+ continue;
+
+ if (!fp) {
+ char *sha1 = sha1_to_hex(options->commit->object.sha1);
+ char *path = git_path("rename-cache/%c%c/%s", sha1[0], sha1[1], sha1+2);
+
+ /* Already cached. If not force refresh, move on */
+ if (!stat(path, &st) && !options->refresh_rename_cache)
+ return;
+
+ safe_create_leading_directories(path);
+ fp = fopen(path, "w");
+
+ if (!fp)
+ return;
+ }
+
+ fprintf(fp, "%s ", sha1_to_hex(dp->two->sha1));
+ fprintf(fp, "%s %d\n",
+ sha1_to_hex(DIFF_FILE_VALID(dp->one) ? dp->one->sha1 : null_sha1),
+ dp->score);
+ }
+ if (fp)
+ fclose(fp);
+}
+
void diffcore_rename(struct diff_options *options)
{
int detect_rename = options->detect_rename;
@@ -770,6 +808,9 @@ void diffcore_rename(struct diff_options *options)
}
diff_debug_queue("done copying original", &outq);
+ if (options->commit && options->cache_renames)
+ save_rename_cache(&outq, options);
+
free(q->queue);
if (cacheq.queue)
free(cacheq.queue);
diff --git a/t/t4030-rename-cache.sh b/t/t4030-rename-cache.sh
index 0d8390c..24d3667 100755
--- a/t/t4030-rename-cache.sh
+++ b/t/t4030-rename-cache.sh
@@ -52,4 +52,31 @@ test_expect_success 'load create pair cache' '
test_cmp expected result
'
+cat >expected <<EOF
+f2ad6c76f0115a6ba5b00456a849810e7ec0af20 0000000000000000000000000000000000000000 0
+78981922613b2afb6025042ff6bd878ac1994e85 78981922613b2afb6025042ff6bd878ac1994e85 60000
+EOF
+test_expect_success 'save rename cache' '
+ P=.git/rename-cache/$(git rev-parse HEAD|sed "s,\(..\)\(.*\),\1/\2,") &&
+ rm -r .git/rename-cache
+ git config diff.cacherenames true
+ git show --summary -C -M --find-copies-harder > /dev/null
+ test_cmp expected $P
+'
+
+test_expect_success 'subsequent command does not change cache' '
+ P=.git/rename-cache/$(git rev-parse HEAD|sed "s,\(..\)\(.*\),\1/\2,") &&
+ echo corrupted >> $P
+ ! test_cmp expected $P &&
+ git show --summary -C -M --find-copies-harder HEAD > /dev/null &&
+ ! test_cmp expected $P
+'
+
+test_expect_success 'overwrite cache with --refresh-rename-cache' '
+ P=.git/rename-cache/$(git rev-parse HEAD|sed "s,\(..\)\(.*\),\1/\2,") &&
+ ! test_cmp expected $P &&
+ git show --summary -C -M --find-copies-harder --refresh-rename-cache HEAD > /dev/null &&
+ test_cmp expected $P
+'
+
test_done
--
1.6.0.3.802.g47c38
^ permalink raw reply related
* [PATCH 1/2] diffcore-rename: support rename cache
From: Nguyễn Thái Ngọc Duy @ 2008-11-07 14:35 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
This patch teaches diffcore_rename() to look into
$GIT_DIR/rename-cache and make use of it to recreate diff_filepair.
With proper cache, there should be no available entry for estimation
after exact matching.
Rename caching is per commit. I don't think abitrary tree-tree caching
is worth it.
$GIT_DIR/rename-cache spans out like $GIT_DIR/objects. Each file
corresponds to one commit. Its content consists of lines like this
<Destination SHA-1> <SPC> <Source SHA-1> <SPC> <Score in decimal> <NL>
This can be used to:
- Make --find-copies-harder pratically usable for moderate-size
repositories. The first "git show" on a linux kernel commit was 5.3
sec, it then went down to 0.13 sec.
- Give git-svn a chance to (locally) import explicit renames from
Subversion
- People may correct rename results for better diff, if automatic
rename detection is not good enough.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
diff.h | 2 +
diffcore-rename.c | 142 ++++++++++++++++++++++++++++++++++++++++++++++-
log-tree.c | 2 +
t/t4030-rename-cache.sh | 55 ++++++++++++++++++
4 files changed, 199 insertions(+), 2 deletions(-)
create mode 100755 t/t4030-rename-cache.sh
diff --git a/diff.h b/diff.h
index a49d865..8b68f6f 100644
--- a/diff.h
+++ b/diff.h
@@ -110,6 +110,8 @@ struct diff_options {
add_remove_fn_t add_remove;
diff_format_fn_t format_callback;
void *format_callback_data;
+
+ struct commit *commit;
};
enum color_diff {
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 168a95b..598cc8d 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -5,6 +5,7 @@
#include "diff.h"
#include "diffcore.h"
#include "hash.h"
+#include "commit.h"
/* Table of rename/copy destinations */
@@ -409,13 +410,130 @@ static void record_if_better(struct diff_score m[], struct diff_score *o)
m[worst] = *o;
}
+struct cached_filepair {
+ unsigned char dst[20];
+ unsigned char src[20];
+ int score;
+};
+
+static int free_cached_filepair(void *p)
+{
+ free(p);
+ return 0;
+}
+
+static void load_rename_cache(struct diff_queue_struct *q,
+ struct diff_queue_struct *cacheq,
+ struct diff_options *options)
+{
+ char *sha1_hex;
+ FILE *fp;
+ struct hash_table filepair_table;
+ struct hash_table src_table;
+ struct cached_filepair *pp;
+ int i, hash;
+ static int no_cache_available = -1;
+ struct stat st;
+ char *path;
+
+ if (no_cache_available == -1)
+ no_cache_available = stat(git_path("rename-cache"), &st) || !S_ISDIR(st.st_mode);
+
+ /* return soon so we don't need to waste CPU */
+ if (no_cache_available > 0)
+ return;
+
+
+ /* src_table initialization */
+ init_hash(&src_table);
+ for (i = 0; i < q->nr; i++) {
+ struct diff_filepair *p = q->queue[i];
+ if (DIFF_FILE_VALID(p->one)) {
+ unsigned int hash = hash_filespec(p->one);
+ insert_hash(hash, p, &src_table);
+ }
+ }
+
+ /* filepair_table initialization */
+ init_hash(&filepair_table);
+ sha1_hex = sha1_to_hex(options->commit->object.sha1);
+ path = git_path("rename-cache/%c%c/%s",sha1_hex[0], sha1_hex[1], sha1_hex+2);
+ if (stat(path, &st))
+ fp = NULL;
+ else
+ fp = fopen(path, "r");
+ if (fp) {
+ char src_sha1_hex[41], dst_sha1_hex[41];
+ struct cached_filepair p;
+
+ src_sha1_hex[40] = dst_sha1_hex[40] = '\0';
+ while (fscanf(fp, "%40c %40c %d\n", dst_sha1_hex, src_sha1_hex, &p.score) == 3) {
+ if (get_sha1_hex(src_sha1_hex, p.src) ||
+ get_sha1_hex(dst_sha1_hex, p.dst))
+ break;
+
+ pp = xmalloc(sizeof(*pp));
+ memcpy(pp, &p, sizeof(*pp));
+ memcpy(&hash, p.dst, sizeof(hash));
+ insert_hash(hash, pp, &filepair_table);
+ }
+ fclose(fp);
+ }
+
+ for (i = 0; i < q->nr; i++) {
+ struct diff_filepair *p = q->queue[i];
+ struct diff_filepair *dp, *src;
+
+ /* find remote_dst */
+ if (DIFF_FILE_VALID(p->one) ||
+ !DIFF_FILE_VALID(p->two) ||
+ (options->single_follow && strcmp(options->single_follow, p->two->path)))
+ continue;
+
+ memcpy(&hash, p->two->sha1, sizeof(hash));
+ pp = lookup_hash(hash, &filepair_table);
+ if (!pp || memcmp(p->two->sha1, pp->dst, 20))
+ continue;
+
+ /* create pair */
+ if (is_null_sha1(pp->src)) {
+ if (DIFF_FILE_VALID(p->one))
+ continue;
+ diff_q(cacheq, p);
+ q->queue[i] = NULL;
+ continue;
+ }
+
+ memcpy(&hash, pp->src, sizeof(hash));
+ src = lookup_hash(hash, &src_table);
+ if (!src || memcmp(pp->src, src->one->sha1, 20))
+ continue;
+
+ src->one->rename_used++;
+ src->one->count++;
+ p->two->count++;
+
+ dp = diff_queue(NULL, src->one, p->two);
+ dp->renamed_pair = 1;
+ dp->score = pp->score;
+
+ diff_q(cacheq, dp);
+ q->queue[i] = NULL;
+ diff_free_filepair(p);
+ }
+
+ for_each_hash(&filepair_table, free_cached_filepair);
+ free_hash(&src_table);
+ free_hash(&filepair_table);
+}
+
void diffcore_rename(struct diff_options *options)
{
int detect_rename = options->detect_rename;
int minimum_score = options->rename_score;
int rename_limit = options->rename_limit;
struct diff_queue_struct *q = &diff_queued_diff;
- struct diff_queue_struct outq;
+ struct diff_queue_struct outq, cacheq;
struct diff_score *mx;
int i, j, rename_count;
int num_create, num_src, dst_cnt;
@@ -423,8 +541,19 @@ void diffcore_rename(struct diff_options *options)
if (!minimum_score)
minimum_score = DEFAULT_RENAME_SCORE;
+ cacheq.queue = NULL;
+ cacheq.nr = cacheq.alloc = 0;
+
+ if (detect_rename && options->commit)
+ load_rename_cache(q, &cacheq, options);
+
for (i = 0; i < q->nr; i++) {
struct diff_filepair *p = q->queue[i];
+
+ /* was consumed by rename cache */
+ if (!p)
+ continue;
+
if (!DIFF_FILE_VALID(p->one)) {
if (!DIFF_FILE_VALID(p->two))
continue; /* unmerged */
@@ -563,10 +692,17 @@ void diffcore_rename(struct diff_options *options)
*/
outq.queue = NULL;
outq.nr = outq.alloc = 0;
- for (i = 0; i < q->nr; i++) {
+ for (i = j = 0; i < q->nr; i++) {
struct diff_filepair *p = q->queue[i];
struct diff_filepair *pair_to_free = NULL;
+ if (!p) {
+ if (j >= cacheq.nr)
+ die("Internal error: running out of cacheq.");
+ diff_q(&outq, cacheq.queue[j++]);
+ continue;
+ }
+
if (!DIFF_FILE_VALID(p->one) && DIFF_FILE_VALID(p->two)) {
/*
* Creation
@@ -635,6 +771,8 @@ void diffcore_rename(struct diff_options *options)
diff_debug_queue("done copying original", &outq);
free(q->queue);
+ if (cacheq.queue)
+ free(cacheq.queue);
*q = outq;
diff_debug_queue("done collapsing", q);
diff --git a/log-tree.c b/log-tree.c
index cec3c06..a67ef6d 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -518,6 +518,7 @@ int log_tree_commit(struct rev_info *opt, struct commit *commit)
log.commit = commit;
log.parent = NULL;
opt->loginfo = &log;
+ opt->diffopt.commit = commit;
shown = log_tree_diff(opt, commit, &log);
if (!shown && opt->loginfo && opt->always_show_header) {
@@ -527,5 +528,6 @@ int log_tree_commit(struct rev_info *opt, struct commit *commit)
}
opt->loginfo = NULL;
maybe_flush_or_die(stdout, "stdout");
+ opt->diffopt.commit = NULL;
return shown;
}
diff --git a/t/t4030-rename-cache.sh b/t/t4030-rename-cache.sh
new file mode 100755
index 0000000..0d8390c
--- /dev/null
+++ b/t/t4030-rename-cache.sh
@@ -0,0 +1,55 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 Nguyen Thai Ngoc Duy
+#
+
+test_description='Test diff rename cache'
+. ./test-lib.sh
+
+cat >expected <<EOF
+ create mode 100644 c
+ copy a => d (100%)
+EOF
+test_expect_success 'setup' '
+ for i in a b c
+ do
+ echo $i > $i
+ done
+ cp a d
+ A_SHA1=$(git hash-object a)
+ B_SHA1=$(git hash-object b)
+ C_SHA1=$(git hash-object c)
+ D_SHA1=$(git hash-object d)
+ git add a b
+ git commit -m first
+ git add c d
+ git commit -m second
+ git show --pretty=oneline --summary -C -M --find-copies-harder HEAD|sed 1d > result
+ test_cmp expected result
+'
+
+cat >expected <<EOF
+ copy a => c (100%)
+ copy a => d (100%)
+EOF
+test_expect_success 'load rename pair cache' '
+ P=.git/rename-cache/$(git rev-parse HEAD|sed "s,\(..\)\(.*\),\1/\2,") &&
+ mkdir -p $(dirname $P)
+ echo $C_SHA1 $A_SHA1 60000 >> $P
+ git show --pretty=oneline --summary -C -M --find-copies-harder HEAD|sed 1d > result
+ test_cmp expected result
+'
+
+cat >expected <<EOF
+ copy a => c (100%)
+ create mode 100644 d
+EOF
+test_expect_success 'load create pair cache' '
+ P=.git/rename-cache/$(git rev-parse HEAD|sed "s,\(..\)\(.*\),\1/\2,") &&
+ mkdir -p $(dirname $P)
+ echo $D_SHA1 0000000000000000000000000000000000000000 0 >> $P
+ git show --pretty=oneline --summary -C -M --find-copies-harder HEAD|sed 1d > result
+ test_cmp expected result
+'
+
+test_done
--
1.6.0.3.802.g47c38
^ permalink raw reply related
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