* Re: What's cooking in git.git (Jan 2009, #05; Wed, 21)
From: Junio C Hamano @ 2009-01-23 6:23 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git
In-Reply-To: <200901212321.50526.bss@iguanasuicide.net>
"Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:
>>* js/diff-color-words (Tue Jan 20 21:46:57 2009 -0600) 8 commits
>> + color-words: Support diff.wordregex config option
>> + color-words: make regex configurable via attributes
>> + color-words: expand docs with precise semantics
>> + color-words: enable REG_NEWLINE to help user
>> + color-words: take an optional regular expression describing words
>> + color-words: change algorithm to allow for 0-character word
>> boundaries
>> + color-words: refactor word splitting and use ALLOC_GROW()
>> + Add color_fwrite_lines(), a function coloring each line
>> individually
>
> I think my patch in
> http://thread.gmane.org/gmane.comp.version-control.git/106567 should be
> applied to the top of this.
Thanks.
^ permalink raw reply
* Re: RFC: git diff colorization idea
From: Junio C Hamano @ 2009-01-23 6:45 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git@vger.kernel.org List
In-Reply-To: <5034E8A9-2B17-4368-8EDF-5FEE61BB2BAD@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
>>> Any feedback or suggestions before I get in too deep?
>>
>> I personally find your "prposal" picture too loud to my eye.
>
> Yes, mine too. I wouldn't actually use those colors in practice.
> (Doubly so because the "removed" color looks like the "whitespace
> error" color.)
I did not mean that your choice of colors is loud. Not at all. What I
meant was the use of color _everywhere_ makes it too loud, and also the
use of _larger number of_ colors makes it too loud.. In other words, you
are painting the output more than what the current output does, and that
made me find it too loud, no matter what the choice of colors are.
You might have misunderstood my illustration, but what I meant to suggest
was to leave most of the characters on both - and + lines in monochrome
(or whatever the "normal" is), and paint _only_ the words that are
different. The outcome would become _less_ colorful than the current
"whole -/+ lines are painted" output, but "only different words are
coloured; the words that are unmodified are left uncoloured, without
distracting the eyes." Much less louder than even the current one, yet
giving more information.
As -/+ has a marker value, I think colouring them may be Ok, too. That
would make something like this:
| {
|<red>-</red> <gray>local subcommands="add rm show prune<gray> <red>update</red>"
|<green>+</green> local subcommands="add <green>rename</green> rm show prune"
| if ...
^ permalink raw reply
* Re: [PATCH 1/3] Add "partial commit" tests during a conflicted merge
From: Johannes Sixt @ 2009-01-23 7:09 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nanako Shiraishi, Nathan Yergler, Michael J Gruber,
Asheesh Laroia, git
In-Reply-To: <7vbpty4kby.fsf_-_@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> +test_expect_success 'setup merge commit with paths test' '
> + git reset --hard &&
> + git checkout HEAD^0 &&
> + echo frotz >file &&
> + test_tick &&
> + git add file &&
> + git commit -a -m "one side says frotz" &&
> + git tag one-side-says-frotz &&
> + git reset --hard HEAD^ &&
> + echo nitfol >file &&
> + test_tick &&
> + git add file &&
> + git commit -a -m "the other side says nitfol" &&
> + git tag the-other-side-says-nitfol
> +'
> +
> +test_expect_success 'reject --only during a merge' '
> + git checkout HEAD^0 &&
> + git reset --hard the-other-side-says-nitfol &&
> + test_must_fail git merge one-side-says-frotz &&
> + echo yomin-only >file &&
> + test_must_fail git commit -m merge --only file &&
I don't see why this must fail: 'file' is the only file that is different
from HEAD. Yes, currently we fail; but if something is about to be
changed, then this can change as well.
> + git reset --hard
> +'
> +
> +test_expect_success 'allow --include during a merge' '
> + git checkout HEAD^0 &&
> + git reset --hard the-other-side-says-nitfol &&
> + test_must_fail git merge one-side-says-frotz &&
> + echo yomin-include >file &&
> + git commit -m merge --include file &&
> + git reset --hard
> +'
> +
> +test_expect_failure 'assume --include during a merge' '
> + git checkout HEAD^0 &&
> + git reset --hard the-other-side-says-nitfol &&
> + test_must_fail git merge one-side-says-frotz &&
> + echo yomin-assumed >file &&
> + git add file &&
> + git commit -m merge file &&
> + git reset --hard
> +'
If I read the test case correctly, there is only 'file' that is different
from HEAD, and it had a conflict. But IMO, the test should stress the
point that after the conflicted merge there are at least two files that
are different from HEAD, one was trivially merged, and the other had a
conflict.
-- Hannes
^ permalink raw reply
* Re: [PATCH 1/3] Add "partial commit" tests during a conflicted merge
From: Junio C Hamano @ 2009-01-23 7:16 UTC (permalink / raw)
To: Johannes Sixt
Cc: Nanako Shiraishi, Nathan Yergler, Michael J Gruber,
Asheesh Laroia, git
In-Reply-To: <49796D0C.5070408@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
>> +test_expect_success 'reject --only during a merge' '
>> + git checkout HEAD^0 &&
>> + git reset --hard the-other-side-says-nitfol &&
>> + test_must_fail git merge one-side-says-frotz &&
>> + echo yomin-only >file &&
>> + test_must_fail git commit -m merge --only file &&
>
> I don't see why this must fail: 'file' is the only file that is different
> from HEAD. Yes, currently we fail; but if something is about to be
> changed, then this can change as well.
Not at all.
Avoiding --only is to prevent a much more dangerous glitch.
Suppose you and the other have two paths diverged, and one merges cleanly
and the other results in conflict. When "git merge" gives control back to
you, the cleanly merged result is ALREADY IN THE INDEX.
Now you futz with the other path, and say
git commit --only other
What --only tells git is "I do not care what I've staged in the index.
Start from the contents of HEAD commit, and update the index entry at these
paths (and these path _ONLY_), and commit the contents registered in the
index.
That is why --include is the only sane semantics during a conflicted
merge. I thought you should know better, as you were the one who gave the
explanation to Nathan, which triggered Nana's response, which resulted in
this series.
^ permalink raw reply
* Re: Merging adjacent deleted lines?
From: Jay Soffian @ 2009-01-23 7:18 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Jonathan del Strother, Junio C Hamano, Git Mailing List
In-Reply-To: <200901222113.31082.robin.rosenberg.lists@dewire.com>
On Thu, Jan 22, 2009 at 3:13 PM, Robin Rosenberg
<robin.rosenberg.lists@dewire.com> wrote:
> torsdag 22 januari 2009 11:57:41 skrev Jonathan del Strother:
>> Mmm. I use opendiff, which is generally ok, but in this case produced
>> a merge looking like this :
>>
>> http://pastie.org/paste/asset/367587/Picture_6.png
>>
>> Which, in my mind, isn't any clearer about the fact that both lines
>> ought to be deleted than the text conflict markers are. Do any of the
>> other graphical tools present conflicts like that differently?
>
> Try a three-way merge tool instead like, e.g. xxdiff.
opendiff (aka FileMerge) *is* a three-way merge tool. If the
screenshot above is not clear, I'm not sure what would be. The left
pane shows your copy of the file with only line1, line3, and line4.
The right pane shows the other copy, with only line1, line2, and
line4.
The lower pane shows the merge resolution, which currently has the
single conflict highlighted, and is being resolved toward the right.
You can use the Action drop down menu to resolve the conflict one of
five ways: left, right, both (left first), both (right first),
neither. You've currently got "right" selected. The appropriate
resolution is "neither", which keeps neither line3 from the left, nor
line2 from the right.
Shrug.
j.
^ permalink raw reply
* Re: [PATCH 1/3] Add "partial commit" tests during a conflicted merge
From: Johannes Sixt @ 2009-01-23 7:32 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nanako Shiraishi, Nathan Yergler, Michael J Gruber,
Asheesh Laroia, git
In-Reply-To: <7vab9i331g.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>
>>> +test_expect_success 'reject --only during a merge' '
>>> + git checkout HEAD^0 &&
>>> + git reset --hard the-other-side-says-nitfol &&
>>> + test_must_fail git merge one-side-says-frotz &&
>>> + echo yomin-only >file &&
>>> + test_must_fail git commit -m merge --only file &&
>> I don't see why this must fail: 'file' is the only file that is different
>> from HEAD. Yes, currently we fail; but if something is about to be
>> changed, then this can change as well.
>
> Not at all.
Read again what I said: 'file' is the *ONLY* file that is different from
HEAD. Why should an explicit --only not work in this case?
> Avoiding --only is to prevent a much more dangerous glitch.
[...]
We are in total agreement about what you said in the rest of the message.
I'm proposing that, during a merge, if --only was given (or remains the
implicit choice), then we compare the index with HEAD, and if nothing
outside the given pathspec differs from HEAD, then allow the commit.
-- Hannes
^ permalink raw reply
* Re: how to force a commit date matching info from a mbox ?
From: Junio C Hamano @ 2009-01-23 7:37 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git list, Christian MICHON
In-Reply-To: <20090123094529.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>:
>
>> Perhaps something like this totally untested patch.
>
> You have test scripts already, but you say it is untested?
Correct. I did not run that new test, let alone existing ones ;-)
^ permalink raw reply
* Re: [PATCH 1/3] Add "partial commit" tests during a conflicted merge
From: Junio C Hamano @ 2009-01-23 7:39 UTC (permalink / raw)
To: Johannes Sixt
Cc: Nanako Shiraishi, Nathan Yergler, Michael J Gruber,
Asheesh Laroia, git
In-Reply-To: <4979727F.80007@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Read again what I said: 'file' is the *ONLY* file that is different from
> HEAD. Why should an explicit --only not work in this case?
I know what you said.
If you study the codepath, the code does not know nor care if 'file' is
the only one or if there are other changed paths.
Too much additional code is needed and for too little gain.
^ permalink raw reply
* Re: [PATCH] git-cvsserver: run post-update hook *after* update.
From: Junio C Hamano @ 2009-01-23 8:00 UTC (permalink / raw)
To: Stefan Karpinski; +Cc: git
In-Reply-To: <d4bc1a2a0901222143i1a7dd051h1778dcb563120195@mail.gmail.com>
Stefan Karpinski <stefan.karpinski@gmail.com> writes:
> I know that this and the other patch I sent are completely trivial and
> uninteresting, but they would appear to be correct. Do I need to prod
> more to get them included or what? Did I submit them incorrectly?
If you spend the bandwidth to quote the whole patch, don't quote it, but
please use the same bandwidth to resend it --- that way, if the reason
your patch left unapplied was because your earlier submission was lost in
the noise or too heavy maintainer workload, it can be easily picked up.
Upon my cursory look the patch looks sane, even though it risks breaking
people's scripts that relied on the incorrect behaviour of running the
hook before the update is done, which is slightly worrysome. Find out who
are knowledgeable in the area of the code you are touching, and Cc them to
ask their input. "git shortlog -s -n git-cvsserver.perl" may help.
Please sign your patch.
Thanks.
Oh, and one more thing. Please do not top post.
> On Fri, Jan 16, 2009 at 2:22 PM, Stefan Karpinski
> <stefan.karpinski@gmail.com> wrote:
>>
>> CVS server was running the hook before the update
>> action was actually done. This performs the update
>> before the hook is called.
>> ---
>>
>> Unless I'm severely misunderstanding the meaning of
>> a *post-update* hook, I think this is a no-brainer.
>>
>> git-cvsserver.perl | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/git-cvsserver.perl b/git-cvsserver.perl
>> index c1e09ea..d2e6003 100755
>> --- a/git-cvsserver.perl
>> +++ b/git-cvsserver.perl
>> @@ -1413,14 +1413,14 @@ sub req_ci
>> close $pipe || die "bad pipe: $! $?";
>> }
>>
>> + $updater->update();
>> +
>> ### Then hooks/post-update
>> $hook = $ENV{GIT_DIR}.'hooks/post-update';
>> if (-x $hook) {
>> system($hook, "refs/heads/$state->{module}");
>> }
>>
>> - $updater->update();
>> -
>> # foreach file specified on the command line ...
>> foreach my $filename ( @committedfiles )
>> {
>> --
>> 1.6.0.3.3.g08dd8
>>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: how to force a commit date matching info from a mbox ?
From: Christian MICHON @ 2009-01-23 8:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git list
In-Reply-To: <alpine.DEB.1.00.0901230119490.3586@pacific.mpi-cbg.de>
On Fri, Jan 23, 2009 at 1:21 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 22 Jan 2009, Christian MICHON wrote:
>
>> I've a big set of patches in a mbox file: there's sufficient info inside
>> for git-am to work.
>>
>> Yet, each time I do import these, my sha1sums are changing because of
>> different commit dates.
>>
>> I'd like to force the commit date to match the info/date from the time I
>> received the email (and therefore always get back the right sha1sums).
>>
>> is this possible ?
>
> Have you tried setting GIT_COMMITTER_DATE to the given date?
yes, I did. This is what I want to change: I can fix the same
GIT_COMMITTER_DATE for all patches in the mbox, but I really want +
GIT_COMMITTER_DATE=GIT_AUTHOR_DATE
>
> Alternatively, you can always use a commit-message filter with
> filter-branch to fix it up.
>
> Ciao,
> Dscho
>
I'm curious if this could be done: the problem I quickly faced was
that this approach would double the amount of commits.
So I'm eager to test Junio's patch :)
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: how to force a commit date matching info from a mbox ?
From: Christian MICHON @ 2009-01-23 8:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7vljt26fp9.fsf@gitster.siamese.dyndns.org>
On Fri, Jan 23, 2009 at 1:14 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Christian MICHON <christian.michon@gmail.com> writes:
>
>> I'd like to force the commit date to match the info/date from the time
>> I received the email (and therefore always get back the right
>> sha1sums).
>>
>> is this possible ?
>
> "am" being a tool to accept patches written in some past to faithfully
> record both author timestamp and committer timestamp, what you seem to
> want is outside of the current scope of the tool.
>
> A patch to butcher "git-am" to copy GIT_COMMITTER_DATE from
> GIT_AUTHOR_DATE and export it should be trivial to implement, though.
>
> Perhaps something like this totally untested patch.
>
I love this idea. I'll try to test it asap. Thanks!
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: [PATCH] Change octal literals to be XEmacs friendly
From: Junio C Hamano @ 2009-01-23 8:09 UTC (permalink / raw)
To: malc, Vassili Karpov; +Cc: git, Alexandre Julliard
In-Reply-To: <871vuwbnio.fsf@linmac.oyster.ru>
malc@pulsesoft.com writes:
> case uses eql and (eql ?\001 1) evaluates to nil under XEmacs
> (probably because some internal type of ?\001 is char)
And I presume the new way to spell is compatible with non XEmacs emacs?
It may be obvious to you, but please spell it out. Parenthesized
"probably" does not help building the confidence in the patch either.
> Signed-off-by: Vassili Karpov <av1474@comtv.ru>
How are the (nameless) author of the patch malc@pulsesoft.com and Vassili
Karpov, the person who signed off, related?
Next time, please spend a few minutes to see if there are active
developers who are familiar in the area you are touching, and Cc your
patch to ask their input.
git blame -L562,+29 contrib/emacs/git.el
tells me that most of this came from 40f162b (git.el: Display file types
and type changes., 2008-01-06) by Alexandre, so I am Cc'ing him.
> ---
> contrib/emacs/git.el | 30 +++++++++++++++---------------
> 1 files changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
> index 09e8bae..715580a 100644
> --- a/contrib/emacs/git.el
> +++ b/contrib/emacs/git.el
> @@ -562,29 +562,29 @@ the process output as a string, or nil if the git command failed."
> (let* ((old-type (lsh (or old-perm 0) -9))
> (new-type (lsh (or new-perm 0) -9))
> (str (case new-type
> - (?\100 ;; file
> + (#o100 ;; file
> (case old-type
> - (?\100 nil)
> - (?\120 " (type change symlink -> file)")
> - (?\160 " (type change subproject -> file)")))
> - (?\120 ;; symlink
> + (#o100 nil)
> + (#o120 " (type change symlink -> file)")
> + (#o160 " (type change subproject -> file)")))
> + (#o120 ;; symlink
> (case old-type
> - (?\100 " (type change file -> symlink)")
> - (?\160 " (type change subproject -> symlink)")
> + (#o100 " (type change file -> symlink)")
> + (#o160 " (type change subproject -> symlink)")
> (t " (symlink)")))
> - (?\160 ;; subproject
> + (#o160 ;; subproject
> (case old-type
> - (?\100 " (type change file -> subproject)")
> - (?\120 " (type change symlink -> subproject)")
> + (#o100 " (type change file -> subproject)")
> + (#o120 " (type change symlink -> subproject)")
> (t " (subproject)")))
> - (?\110 nil) ;; directory (internal, not a real git state)
> - (?\000 ;; deleted or unknown
> + (#o110 nil) ;; directory (internal, not a real git state)
> + (#o000 ;; deleted or unknown
> (case old-type
> - (?\120 " (symlink)")
> - (?\160 " (subproject)")))
> + (#o120 " (symlink)")
> + (#o160 " (subproject)")))
> (t (format " (unknown type %o)" new-type)))))
> (cond (str (propertize str 'face 'git-status-face))
> - ((eq new-type ?\110) "/")
> + ((eq new-type #o110) "/")
> (t ""))))
>
> (defun git-rename-as-string (info)
>
> --
> mailto:av1474@comtv.ru
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] git mergetool: Don't repeat merge tool candidates
From: Junio C Hamano @ 2009-01-23 8:16 UTC (permalink / raw)
To: Johannes Gilger; +Cc: git, Theodore Ts'o
In-Reply-To: <1232569442-12480-1-git-send-email-heipei@hackvalue.de>
Johannes Gilger <heipei@hackvalue.de> writes:
> git mergetool listed some candidates for mergetools twice, depending on
> the environment.
>
> Signed-off-by: Johannes Gilger <heipei@hackvalue.de>
> ---
> git-mergetool.sh | 13 +++++--------
> 1 files changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/git-mergetool.sh b/git-mergetool.sh
> index 00e1337..8f09e4a 100755
> --- a/git-mergetool.sh
> +++ b/git-mergetool.sh
> @@ -390,21 +390,18 @@ fi
>
> if test -z "$merge_tool" ; then
> if test -n "$DISPLAY"; then
> - merge_tool_candidates="kdiff3 tkdiff xxdiff meld gvimdiff"
> if test -n "$GNOME_DESKTOP_SESSION_ID" ; then
> - merge_tool_candidates="meld $merge_tool_candidates"
> - fi
> - if test "$KDE_FULL_SESSION" = "true"; then
> - merge_tool_candidates="kdiff3 $merge_tool_candidates"
> + merge_tool_candidates="meld kdiff3 tkdiff xxdiff gvimdiff"
> + else
> + merge_tool_candidates="kdiff3 tkdiff xxdiff meld gvimdiff"
> fi
> fi
> if echo "${VISUAL:-$EDITOR}" | grep 'emacs' > /dev/null 2>&1; then
> - merge_tool_candidates="$merge_tool_candidates emerge"
> + merge_tool_candidates="$merge_tool_candidates emerge opendiff vimdiff"
> fi
> if echo "${VISUAL:-$EDITOR}" | grep 'vim' > /dev/null 2>&1; then
> - merge_tool_candidates="$merge_tool_candidates vimdiff"
> + merge_tool_candidates="$merge_tool_candidates vimdiff opendiff emerge"
> fi
> - merge_tool_candidates="$merge_tool_candidates opendiff emerge vimdiff"
> echo "merge tool candidates: $merge_tool_candidates"
> for i in $merge_tool_candidates; do
> init_merge_tool_path $i
Doesn't this change the order of the tools listed in the variable,
affecting which one ends up being used? I think that is a worse
regression than repeating the same name twice in an otherwise no-op
informational message.
Please spend a few minutes to see if there are active developers who are
familiar with the area of code you are touching and Cc them to ask their
input.
git blame -L390,+20 git-mergetool.sh
tells me that most of this came from 301ac38 (git-mergetool: Make default
selection of merge-tool more intelligent, 2007-06-10), so I am Cc'ing Ted.
^ permalink raw reply
* Re: how to force a commit date matching info from a mbox ?
From: Nanako Shiraishi @ 2009-01-23 8:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list, Christian MICHON
In-Reply-To: <7vwscm1nic.fsf@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>:
> Nanako Shiraishi <nanako3@lavabit.com> writes:
>
>> Quoting Junio C Hamano <gitster@pobox.com>:
>>
>>> Perhaps something like this totally untested patch.
>>
>> You have test scripts already, but you say it is untested?
>
> Correct. I did not run that new test, let alone existing ones ;-)
I applied your patch and run the test suite, including the new one, and they passed.
I tried to write a new option I said that I wanted in my previous message. Here is a patch.
--->8---
Subject: [PATCH] git-am: Add --ignore-date option
This new option makes the command ignore the date header field recorded in
the format-patch output. The commits will have the timestamp when they
are created instead.
You can work a lot in one day to accumulate many changes, but apply and
push to the public repository only some of them at the end of the first
day. Then next day you can spend all your working hours reading comics or
chatting with your coworkers, and apply your remaining patches from the
previous day using this option to pretend that you have been working at
the end of the day.
Signed-off-by: しらいしななこ <nanako3@lavabit.com>
---
git-am.sh | 12 +++++++++++-
t/t4150-am.sh | 9 +++++++++
2 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index e96071d..eb88d90 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -24,6 +24,7 @@ r,resolved to be used after a patch failure
skip skip the current patch
abort restore the original branch and abort the patching operation.
committer-date-is-author-date lie about committer date
+ignore-date use current timestamp for author date
rebasing (internal use for git-rebase)"
. git-sh-setup
@@ -135,6 +136,7 @@ sign= utf8=t keep= skip= interactive= resolved= rebasing= abort=
resolvemsg= resume=
git_apply_opt=
committer_date_is_author_date=
+ignore_date=
while test $# != 0
do
@@ -172,6 +174,8 @@ do
git_apply_opt="$git_apply_opt $(sq "$1$2")"; shift ;;
--committer-date-is-author-date)
committer_date_is_author_date=t ;;
+ --ignore-date)
+ ignore_date=t ;;
--)
shift; break ;;
*)
@@ -379,7 +383,13 @@ do
GIT_AUTHOR_NAME="$(sed -n '/^Author/ s/Author: //p' "$dotest/info")"
GIT_AUTHOR_EMAIL="$(sed -n '/^Email/ s/Email: //p' "$dotest/info")"
- GIT_AUTHOR_DATE="$(sed -n '/^Date/ s/Date: //p' "$dotest/info")"
+ case "$ignore_date" in
+ t)
+ GIT_AUTHOR_DATE="$(date -R)"
+ ;;
+ '')
+ GIT_AUTHOR_DATE="$(sed -n '/^Date/ s/Date: //p' "$dotest/info")"
+ esac
if test -z "$GIT_AUTHOR_EMAIL"
then
diff --git a/t/t4150-am.sh b/t/t4150-am.sh
index 8d3fb00..5ecf456 100755
--- a/t/t4150-am.sh
+++ b/t/t4150-am.sh
@@ -277,4 +277,13 @@ test_expect_success 'am without --committer-date-is-author-date' '
test "$at" != "$ct"
'
+test_expect_success 'am --ignore-date' '
+ git checkout first &&
+ test_tick &&
+ git am --ignore-date patch1 &&
+ git cat-file commit HEAD | sed -e "/^$/q" >head1 &&
+ at=$(sed -ne "/^author /s/.*> //p" head1) &&
+ echo "$at" | grep "+0000"
+'
+
test_done
--
1.6.1.224.gb56c7
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* Re: RFC: git diff colorization idea
From: Nanako Shiraishi @ 2009-01-23 8:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Wincent Colaiuta, git
In-Reply-To: <7vhc3q6evi.fsf@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>:
> If you were to go this route, I suspect that showing the unchanged part on
> the preimage line in light gray might make sense, like:
>
> | _git_remote ()
> | {
> |- <gray>local subcommands="add rm show prune<gray> <red>update</red>"
> |+ local subcommands="add <green>rename</green> rm show prune"
> | local subcommand=$(__git_find_subcommand "$subcommands")"
> | if ...
>
> because there will be the same chars/words on the postimage line anyway.
I think this makes a lot more sense than any of the screenshot
WIncent prepared on his web pages, and it is a much easier output
for users to spot which word is different by not coloring the
unchanged word at all.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: how to force a commit date matching info from a mbox ?
From: Christian MICHON @ 2009-01-23 8:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <46d6db660901230008q418f3d3bsc68ca4e9d675cb36@mail.gmail.com>
On Fri, Jan 23, 2009 at 9:08 AM, Christian MICHON
<christian.michon@gmail.com> wrote:
>> A patch to butcher "git-am" to copy GIT_COMMITTER_DATE from
>> GIT_AUTHOR_DATE and export it should be trivial to implement, though.
>>
>> Perhaps something like this totally untested patch.
>>
>
> I love this idea. I'll try to test it asap. Thanks!
>
working fine! I've predictable/reproducible commits with this patch!
many thanks and kudos!
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: git-svn fails to fetch repository
From: Petr Baudis @ 2009-01-23 8:52 UTC (permalink / raw)
To: B.Steinbrink; +Cc: Vladimir Pouzanov, git
In-Reply-To: <loom.20090113T204616-845@post.gmane.org>
On Tue, Jan 13, 2009 at 08:46:55PM +0000, Vladimir Pouzanov wrote:
> Björn Steinbrink <B.Steinbrink <at> gmx.de> writes:
> > Is that Linux box using Gentoo? If so, try emerging subversion with -dso
> > in your build flags.
>
> Yeah, that's gentoo. Will try rebuilding svn now.
I have hit the same issue (segfault on Gentoo) and this fixed it for me.
But do you have any details on why is the segfault caused and how to
prevent it? USE=dso is the default on Gentoo. :-(
--
Petr "Pasky" Baudis
The average, healthy, well-adjusted adult gets up at seven-thirty
in the morning feeling just terrible. -- Jean Kerr
^ permalink raw reply
* [PATCH 1/7] refs: add a "for_each_replace_ref" function
From: Christian Couder @ 2009-01-23 9:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This is some preparation work for the following patches that are using
the "refs/replace/" ref namespace.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
refs.c | 5 +++++
refs.h | 1 +
2 files changed, 6 insertions(+), 0 deletions(-)
Here is a new patch series. I only fixed what Junio reported
as bugs (thanks) and added a global switch to forbid the
replacement for connectivity walkers. I added a few test
cases for the latter, but I may be missing a lot of things.
diff --git a/refs.c b/refs.c
index 33ced65..042106d 100644
--- a/refs.c
+++ b/refs.c
@@ -632,6 +632,11 @@ int for_each_remote_ref(each_ref_fn fn, void *cb_data)
return do_for_each_ref("refs/remotes/", fn, 13, cb_data);
}
+int for_each_replace_ref(each_ref_fn fn, void *cb_data)
+{
+ return do_for_each_ref("refs/replace/", fn, 13, cb_data);
+}
+
/*
* Make sure "ref" is something reasonable to have under ".git/refs/";
* We do not like it if:
diff --git a/refs.h b/refs.h
index 06ad260..8d2ee5a 100644
--- a/refs.h
+++ b/refs.h
@@ -23,6 +23,7 @@ extern int for_each_ref(each_ref_fn, void *);
extern int for_each_tag_ref(each_ref_fn, void *);
extern int for_each_branch_ref(each_ref_fn, void *);
extern int for_each_remote_ref(each_ref_fn, void *);
+extern int for_each_replace_ref(each_ref_fn, void *);
/*
* Extra refs will be listed by for_each_ref() before any actual refs
--
1.6.1.231.g9c286
^ permalink raw reply related
* [PATCH 2/7] replace_object: add mechanism to replace objects found in "refs/replace/"
From: Christian Couder @ 2009-01-23 9:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The code implementing this mechanism has been copied from the commit
graft code.
This mechanism is used in "read_sha1_file". sha1 passed to this
function that match a ref name in "refs/replace/" are replaced by
the sha1 that has been read in the ref.
We "die" if the replacement recursion depth is too high or if we
can't read the replacement object.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Makefile | 1 +
commit.h | 2 +
replace_object.c | 117 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
sha1_file.c | 14 +++++-
4 files changed, 131 insertions(+), 3 deletions(-)
create mode 100644 replace_object.c
diff --git a/Makefile b/Makefile
index fa6c51c..953638f 100644
--- a/Makefile
+++ b/Makefile
@@ -471,6 +471,7 @@ LIB_OBJS += read-cache.o
LIB_OBJS += reflog-walk.o
LIB_OBJS += refs.o
LIB_OBJS += remote.o
+LIB_OBJS += replace_object.o
LIB_OBJS += rerere.o
LIB_OBJS += revision.o
LIB_OBJS += run-command.o
diff --git a/commit.h b/commit.h
index 3a7b06a..37aa763 100644
--- a/commit.h
+++ b/commit.h
@@ -122,6 +122,8 @@ struct commit_graft *read_graft_line(char *buf, int len);
int register_commit_graft(struct commit_graft *, int);
struct commit_graft *lookup_commit_graft(const unsigned char *sha1);
+const unsigned char *lookup_replace_object(const unsigned char *sha1);
+
extern struct commit_list *get_merge_bases(struct commit *rev1, struct commit *rev2, int cleanup);
extern struct commit_list *get_merge_bases_many(struct commit *one, int n, struct commit **twos, int cleanup);
extern struct commit_list *get_octopus_merge_bases(struct commit_list *in);
diff --git a/replace_object.c b/replace_object.c
new file mode 100644
index 0000000..5b973ba
--- /dev/null
+++ b/replace_object.c
@@ -0,0 +1,117 @@
+#include "cache.h"
+#include "refs.h"
+
+static struct replace_object {
+ unsigned char sha1[2][20];
+} **replace_object;
+
+static int replace_object_alloc, replace_object_nr;
+
+static int replace_object_pos(const unsigned char *sha1)
+{
+ int lo, hi;
+ lo = 0;
+ hi = replace_object_nr;
+ while (lo < hi) {
+ int mi = (lo + hi) / 2;
+ struct replace_object *rep = replace_object[mi];
+ int cmp = hashcmp(sha1, rep->sha1[0]);
+ if (!cmp)
+ return mi;
+ if (cmp < 0)
+ hi = mi;
+ else
+ lo = mi + 1;
+ }
+ return -lo - 1;
+}
+
+static int register_replace_object(struct replace_object *replace,
+ int ignore_dups)
+{
+ int pos = replace_object_pos(replace->sha1[0]);
+
+ if (0 <= pos) {
+ if (ignore_dups)
+ free(replace);
+ else {
+ free(replace_object[pos]);
+ replace_object[pos] = replace;
+ }
+ return 1;
+ }
+ pos = -pos - 1;
+ if (replace_object_alloc <= ++replace_object_nr) {
+ replace_object_alloc = alloc_nr(replace_object_alloc);
+ replace_object = xrealloc(replace_object,
+ sizeof(*replace_object) *
+ replace_object_alloc);
+ }
+ if (pos < replace_object_nr)
+ memmove(replace_object + pos + 1,
+ replace_object + pos,
+ (replace_object_nr - pos - 1) *
+ sizeof(*replace_object));
+ replace_object[pos] = replace;
+ return 0;
+}
+
+static int register_replace_ref(const char *refname,
+ const unsigned char *sha1,
+ int flag, void *cb_data)
+{
+ /* Get sha1 from refname */
+ const char *slash = strrchr(refname, '/');
+ const char *hash = slash ? slash + 1 : refname;
+ struct replace_object *repl_obj = xmalloc(sizeof(*repl_obj));
+
+ if (strlen(hash) != 40 || get_sha1_hex(hash, repl_obj->sha1[0])) {
+ free(repl_obj);
+ warning("bad replace ref name: %s", refname);
+ return 0;
+ }
+
+ /* Copy sha1 from the read ref */
+ hashcpy(repl_obj->sha1[1], sha1);
+
+ /* Register new object */
+ if (register_replace_object(repl_obj, 1))
+ die("duplicate replace ref: %s", refname);
+
+ return 0;
+}
+
+static void prepare_replace_object(void)
+{
+ static int replace_object_prepared;
+
+ if (replace_object_prepared)
+ return;
+
+ for_each_replace_ref(register_replace_ref, NULL);
+ replace_object_prepared = 1;
+}
+
+/* We allow "recursive" replacement. Only within reason, though */
+#define MAXREPLACEDEPTH 5
+
+const unsigned char *lookup_replace_object(const unsigned char *sha1)
+{
+ int pos, depth = MAXREPLACEDEPTH;
+ const unsigned char *cur = sha1;
+
+ prepare_replace_object();
+
+ /* Try to recursively replace the object */
+ do {
+ if (--depth < 0)
+ die("replace depth too high for object %s",
+ sha1_to_hex(sha1));
+
+ pos = replace_object_pos(cur);
+ if (0 <= pos)
+ cur = replace_object[pos]->sha1[1];
+ } while (0 <= pos);
+
+ return cur;
+}
diff --git a/sha1_file.c b/sha1_file.c
index f08493f..4f2fd10 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2163,10 +2163,18 @@ static void *read_object(const unsigned char *sha1, enum object_type *type,
void *read_sha1_file(const unsigned char *sha1, enum object_type *type,
unsigned long *size)
{
- void *data = read_object(sha1, type, size);
+ const unsigned char *repl = lookup_replace_object(sha1);
+ void *data = read_object(repl, type, size);
+
+ /* die if we replaced an object with one that does not exist */
+ if (!data && repl != sha1)
+ die("replacement %s not found for %s",
+ sha1_to_hex(repl), sha1_to_hex(sha1));
+
/* legacy behavior is to die on corrupted objects */
- if (!data && (has_loose_object(sha1) || has_packed_and_bad(sha1)))
- die("object %s is corrupted", sha1_to_hex(sha1));
+ if (!data && (has_loose_object(repl) || has_packed_and_bad(repl)))
+ die("object %s is corrupted", sha1_to_hex(repl));
+
return data;
}
--
1.6.1.231.g9c286
^ permalink raw reply related
* [PATCH 3/7] sha1_file: add a "read_sha1_file_repl" function
From: Christian Couder @ 2009-01-23 9:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This new function will replace "read_sha1_file". This latter function
becoming just a stub to call the former will a NULL "replacement"
argument.
This new function is needed because sometimes we need to use the
replacement sha1.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
cache.h | 6 +++++-
sha1_file.c | 9 +++++++--
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/cache.h b/cache.h
index 8e1af26..1b34381 100644
--- a/cache.h
+++ b/cache.h
@@ -625,7 +625,11 @@ int longest_ancestor_length(const char *path, const char *prefix_list);
/* Read and unpack a sha1 file into memory, write memory to a sha1 file */
extern int sha1_object_info(const unsigned char *, unsigned long *);
-extern void * read_sha1_file(const unsigned char *sha1, enum object_type *type, unsigned long *size);
+extern void *read_sha1_file_repl(const unsigned char *sha1, enum object_type *type, unsigned long *size, const unsigned char **replacement);
+static inline void *read_sha1_file(const unsigned char *sha1, enum object_type *type, unsigned long *size)
+{
+ return read_sha1_file_repl(sha1, type, size, NULL);
+}
extern int hash_sha1_file(const void *buf, unsigned long len, const char *type, unsigned char *sha1);
extern int write_sha1_file(void *buf, unsigned long len, const char *type, unsigned char *return_sha1);
extern int pretend_sha1_file(void *, unsigned long, enum object_type, unsigned char *);
diff --git a/sha1_file.c b/sha1_file.c
index 4f2fd10..ea89ce5 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2160,8 +2160,10 @@ static void *read_object(const unsigned char *sha1, enum object_type *type,
return read_packed_sha1(sha1, type, size);
}
-void *read_sha1_file(const unsigned char *sha1, enum object_type *type,
- unsigned long *size)
+void *read_sha1_file_repl(const unsigned char *sha1,
+ enum object_type *type,
+ unsigned long *size,
+ const unsigned char **replacement)
{
const unsigned char *repl = lookup_replace_object(sha1);
void *data = read_object(repl, type, size);
@@ -2175,6 +2177,9 @@ void *read_sha1_file(const unsigned char *sha1, enum object_type *type,
if (!data && (has_loose_object(repl) || has_packed_and_bad(repl)))
die("object %s is corrupted", sha1_to_hex(repl));
+ if (replacement)
+ *replacement = repl;
+
return data;
}
--
1.6.1.231.g9c286
^ permalink raw reply related
* [PATCH 4/7] object: call "check_sha1_signature" with the replacement sha1
From: Christian Couder @ 2009-01-23 9:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Otherwise we get a "sha1 mismatch" error for replaced objects.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
object.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/object.c b/object.c
index 50b6528..217bee9 100644
--- a/object.c
+++ b/object.c
@@ -187,17 +187,18 @@ struct object *parse_object(const unsigned char *sha1)
unsigned long size;
enum object_type type;
int eaten;
- void *buffer = read_sha1_file(sha1, &type, &size);
+ const unsigned char *repl;
+ void *buffer = read_sha1_file_repl(sha1, &type, &size, &repl);
if (buffer) {
struct object *obj;
- if (check_sha1_signature(sha1, buffer, size, typename(type)) < 0) {
+ if (check_sha1_signature(repl, buffer, size, typename(type)) < 0) {
free(buffer);
- error("sha1 mismatch %s\n", sha1_to_hex(sha1));
+ error("sha1 mismatch %s\n", sha1_to_hex(repl));
return NULL;
}
- obj = parse_object_buffer(sha1, type, size, buffer, &eaten);
+ obj = parse_object_buffer(repl, type, size, buffer, &eaten);
if (!eaten)
free(buffer);
return obj;
--
1.6.1.231.g9c286
^ permalink raw reply related
* [PATCH 6/7] mktag: call "check_sha1_signature" with the replacement sha1
From: Christian Couder @ 2009-01-23 9:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Otherwise we get a "sha1 mismatch" error for replaced objects.
Note that I am not sure at all that this is a good change.
It may be that we should just refuse to tag a replaced object. But
in this case we should probably give a meaningfull error message
instead of "sha1 mismatch".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
mktag.c | 7 ++++---
t/t6050-replace.sh | 12 ++++++++++++
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/mktag.c b/mktag.c
index ba3d495..ac812e5 100644
--- a/mktag.c
+++ b/mktag.c
@@ -18,16 +18,17 @@
/*
* We refuse to tag something we can't verify. Just because.
*/
-static int verify_object(unsigned char *sha1, const char *expected_type)
+static int verify_object(const unsigned char *sha1, const char *expected_type)
{
int ret = -1;
enum object_type type;
unsigned long size;
- void *buffer = read_sha1_file(sha1, &type, &size);
+ const unsigned char *repl;
+ void *buffer = read_sha1_file_repl(sha1, &type, &size, &repl);
if (buffer) {
if (type == type_from_string(expected_type))
- ret = check_sha1_signature(sha1, buffer, size, expected_type);
+ ret = check_sha1_signature(repl, buffer, size, expected_type);
free(buffer);
}
return ret;
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index 0a585ec..334aed6 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -70,6 +70,18 @@ test_expect_success 'replace the author' '
git show $HASH2 | grep "O Thor"
'
+cat >tag.sig <<EOF
+object $HASH2
+type commit
+tag mytag
+tagger T A Gger <> 0 +0000
+
+EOF
+
+test_expect_success 'tag replaced commit' '
+ git mktag <tag.sig >.git/refs/tags/mytag 2>message
+'
+
#
#
test_done
--
1.6.1.231.g9c286
^ permalink raw reply related
* [PATCH 5/7] replace_object: add a test case
From: Christian Couder @ 2009-01-23 9:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In this patch the setup code is very big, but this will be used in
test cases that will be added later.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
t/t6050-replace.sh | 75 ++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 75 insertions(+), 0 deletions(-)
create mode 100755 t/t6050-replace.sh
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
new file mode 100755
index 0000000..0a585ec
--- /dev/null
+++ b/t/t6050-replace.sh
@@ -0,0 +1,75 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 Christian Couder
+#
+test_description='Tests replace refs functionality'
+
+exec </dev/null
+
+. ./test-lib.sh
+
+add_and_commit_file()
+{
+ _file="$1"
+ _msg="$2"
+
+ git add $_file || return $?
+ test_tick || return $?
+ git commit --quiet -m "$_file: $_msg"
+}
+
+HASH1=
+HASH2=
+HASH3=
+HASH4=
+HASH5=
+HASH6=
+HASH7=
+
+test_expect_success 'set up buggy branch' '
+ echo "line 1" >> hello &&
+ echo "line 2" >> hello &&
+ echo "line 3" >> hello &&
+ echo "line 4" >> hello &&
+ add_and_commit_file hello "4 lines" &&
+ HASH1=$(git rev-parse --verify HEAD) &&
+ echo "line BUG" >> hello &&
+ echo "line 6" >> hello &&
+ echo "line 7" >> hello &&
+ echo "line 8" >> hello &&
+ add_and_commit_file hello "4 more lines with a BUG" &&
+ HASH2=$(git rev-parse --verify HEAD) &&
+ echo "line 9" >> hello &&
+ echo "line 10" >> hello &&
+ add_and_commit_file hello "2 more lines" &&
+ HASH3=$(git rev-parse --verify HEAD) &&
+ echo "line 11" >> hello &&
+ add_and_commit_file hello "1 more line" &&
+ HASH4=$(git rev-parse --verify HEAD) &&
+ sed -e "s/BUG/5/" hello > hello.new &&
+ mv hello.new hello &&
+ add_and_commit_file hello "BUG fixed" &&
+ HASH5=$(git rev-parse --verify HEAD) &&
+ echo "line 12" >> hello &&
+ echo "line 13" >> hello &&
+ add_and_commit_file hello "2 more lines" &&
+ HASH6=$(git rev-parse --verify HEAD)
+ echo "line 14" >> hello &&
+ echo "line 15" >> hello &&
+ echo "line 16" >> hello &&
+ add_and_commit_file hello "again 3 more lines" &&
+ HASH7=$(git rev-parse --verify HEAD)
+'
+
+test_expect_success 'replace the author' '
+ git cat-file commit $HASH2 | grep "author A U Thor" &&
+ R=$(git cat-file commit $HASH2 | sed -e "s/A U/O/" | git hash-object -t commit --stdin -w) &&
+ git cat-file commit $R | grep "author O Thor" &&
+ git update-ref refs/replace/$HASH2 $R &&
+ git show HEAD~5 | grep "O Thor" &&
+ git show $HASH2 | grep "O Thor"
+'
+
+#
+#
+test_done
--
1.6.1.231.g9c286
^ permalink raw reply related
* [PATCH 7/7] environment: add global variable to disable replacement
From: Christian Couder @ 2009-01-23 9:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This new "read_replace_refs" global variable is set to 1 by
default, so that replace refs are used by default. But
reachability traversal and packing commands ("cmd_fsck",
"cmd_prune", "cmd_pack_objects", "upload_pack",
"cmd_unpack_objects") set it to 0, as they must work with the
original DAG.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin-fsck.c | 1 +
builtin-pack-objects.c | 2 ++
builtin-prune.c | 1 +
builtin-unpack-objects.c | 2 ++
cache.h | 1 +
environment.c | 1 +
replace_object.c | 3 +++
t/t6050-replace.sh | 23 +++++++++++++++++++++++
upload-pack.c | 2 ++
9 files changed, 36 insertions(+), 0 deletions(-)
Note that I tried a little to test this, but I don't know much
about packing and reachability traversal commands, so I may be
very wrong on this patch. There may also be many other
commands where "read_replace_refs" should be set to 0.
Please check.
diff --git a/builtin-fsck.c b/builtin-fsck.c
index aecc828..67356fb 100644
--- a/builtin-fsck.c
+++ b/builtin-fsck.c
@@ -586,6 +586,7 @@ int cmd_fsck(int argc, const char **argv, const char *prefix)
int i, heads;
errors_found = 0;
+ read_replace_refs = 0;
argc = parse_options(argc, argv, fsck_opts, fsck_usage, 0);
if (write_lost_and_found) {
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index e851534..8e161a3 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -2080,6 +2080,8 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
int rp_ac_alloc = 64;
int rp_ac;
+ read_replace_refs = 0;
+
rp_av = xcalloc(rp_ac_alloc, sizeof(*rp_av));
rp_av[0] = "pack-objects";
diff --git a/builtin-prune.c b/builtin-prune.c
index 545e9c1..c0a26fe 100644
--- a/builtin-prune.c
+++ b/builtin-prune.c
@@ -140,6 +140,7 @@ int cmd_prune(int argc, const char **argv, const char *prefix)
char *s;
save_commit_buffer = 0;
+ read_replace_refs = 0;
init_revisions(&revs, prefix);
argc = parse_options(argc, argv, options, prune_usage, 0);
diff --git a/builtin-unpack-objects.c b/builtin-unpack-objects.c
index 47ed610..1a4d51b 100644
--- a/builtin-unpack-objects.c
+++ b/builtin-unpack-objects.c
@@ -495,6 +495,8 @@ int cmd_unpack_objects(int argc, const char **argv, const char *prefix)
int i;
unsigned char sha1[20];
+ read_replace_refs = 0;
+
git_config(git_default_config, NULL);
quiet = !isatty(2);
diff --git a/cache.h b/cache.h
index 1b34381..48fa12a 100644
--- a/cache.h
+++ b/cache.h
@@ -510,6 +510,7 @@ extern size_t packed_git_window_size;
extern size_t packed_git_limit;
extern size_t delta_base_cache_limit;
extern int auto_crlf;
+extern int read_replace_refs;
extern int fsync_object_files;
extern int core_preload_index;
diff --git a/environment.c b/environment.c
index e278bce..d11dde1 100644
--- a/environment.c
+++ b/environment.c
@@ -38,6 +38,7 @@ int pager_use_color = 1;
const char *editor_program;
const char *excludes_file;
int auto_crlf = 0; /* 1: both ways, -1: only when adding git objects */
+int read_replace_refs = 1;
enum safe_crlf safe_crlf = SAFE_CRLF_WARN;
unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;
enum branch_track git_branch_track = BRANCH_TRACK_REMOTE;
diff --git a/replace_object.c b/replace_object.c
index 5b973ba..1227214 100644
--- a/replace_object.c
+++ b/replace_object.c
@@ -100,6 +100,9 @@ const unsigned char *lookup_replace_object(const unsigned char *sha1)
int pos, depth = MAXREPLACEDEPTH;
const unsigned char *cur = sha1;
+ if (!read_replace_refs)
+ return sha1;
+
prepare_replace_object();
/* Try to recursively replace the object */
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index 334aed6..17f6063 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -82,6 +82,29 @@ test_expect_success 'tag replaced commit' '
git mktag <tag.sig >.git/refs/tags/mytag 2>message
'
+test_expect_success '"git fsck" works' '
+ git fsck master > fsck_master.out &&
+ grep "dangling commit $R" fsck_master.out &&
+ grep "dangling tag $(cat .git/refs/tags/mytag)" fsck_master.out &&
+ test -z "$(git fsck)"
+'
+
+test_expect_success 'repack, clone and fetch work' '
+ git repack -a -d &&
+ git clone --no-hardlinks . clone_dir &&
+ cd clone_dir &&
+ git show HEAD~5 | grep "A U Thor" &&
+ git show $HASH2 | grep "A U Thor" &&
+ git cat-file commit $R &&
+ git repack -a -d &&
+ test_must_fail git cat-file commit $R &&
+ git fetch ../ "refs/replace/*:refs/replace/*" &&
+ git show HEAD~5 | grep "O Thor" &&
+ git show $HASH2 | grep "O Thor" &&
+ git cat-file commit $R &&
+ cd ..
+'
+
#
#
test_done
diff --git a/upload-pack.c b/upload-pack.c
index e5adbc0..186e338 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -616,6 +616,8 @@ int main(int argc, char **argv)
int i;
int strict = 0;
+ read_replace_refs = 0;
+
for (i = 1; i < argc; i++) {
char *arg = argv[i];
--
1.6.1.231.g9c286
^ permalink raw reply related
* [PATCHv2] git mergetool: Don't repeat merge tool candidates
From: Johannes Gilger @ 2009-01-23 9:14 UTC (permalink / raw)
To: gitster; +Cc: git, tytso, Johannes Gilger
In-Reply-To: <7v7i4m1lq4.fsf@gitster.siamese.dyndns.org>
git mergetool listed some candidates for mergetools twice, depending on
the environment.
Signed-off-by: Johannes Gilger <heipei@hackvalue.de>
---
The first patch had the fatal flaw that it listed nothing when DISPLAY
and EDITOR/VISUAL were unset, we fixed that.
The order in which merge-candidates appear is still exactly the same,
only duplicates have been stripped. The check for KDE_FULL_SESSION was
removed since kdiff3 was added as long as DISPLAY was set and we weren't
running gnome.
git-mergetool.sh | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 00e1337..acdcffb 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -390,21 +390,21 @@ fi
if test -z "$merge_tool" ; then
if test -n "$DISPLAY"; then
- merge_tool_candidates="kdiff3 tkdiff xxdiff meld gvimdiff"
if test -n "$GNOME_DESKTOP_SESSION_ID" ; then
- merge_tool_candidates="meld $merge_tool_candidates"
- fi
- if test "$KDE_FULL_SESSION" = "true"; then
- merge_tool_candidates="kdiff3 $merge_tool_candidates"
+ merge_tool_candidates="meld kdiff3 tkdiff xxdiff gvimdiff"
+ else
+ merge_tool_candidates="kdiff3 tkdiff xxdiff meld gvimdiff"
fi
fi
if echo "${VISUAL:-$EDITOR}" | grep 'emacs' > /dev/null 2>&1; then
- merge_tool_candidates="$merge_tool_candidates emerge"
+ merge_tool_candidates="$merge_tool_candidates emerge opendiff vimdiff"
fi
if echo "${VISUAL:-$EDITOR}" | grep 'vim' > /dev/null 2>&1; then
- merge_tool_candidates="$merge_tool_candidates vimdiff"
+ merge_tool_candidates="$merge_tool_candidates vimdiff opendiff emerge"
+ fi
+ if test -z "$merge_tool_candidates" ; then
+ merge_tool_candidates="opendiff emerge vimdiff"
fi
- merge_tool_candidates="$merge_tool_candidates opendiff emerge vimdiff"
echo "merge tool candidates: $merge_tool_candidates"
for i in $merge_tool_candidates; do
init_merge_tool_path $i
--
1.6.1.40.g8ea6a
^ 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