* Re: [PATCH] Ignore end-of-line style when computing similarity score for rename detection
From: Junio C Hamano @ 2007-06-28 8:16 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4683619A.F753C97E@eudaptics.com>
Johannes Sixt <J.Sixt@eudaptics.com> writes:
> Steven Grimm wrote:
>>
>> Signed-off-by: Steven Grimm <koreth@midwinter.com>
>> ---
>> Okay, let's try this again with an MUA that won't change my tabs to
>> spaces -- sorry about that.
>>
>> A couple of source files got checked into my code base with DOS-style
>> end-of-line characters. I converted them to UNIX-style (the convention
>> for this project) in my branch. Then later, I renamed a couple of them.
>>
>> Meanwhile, back in the original branch, someone else fixed a bug in one
>> of the files and checked it in, still with DOS-style line endings.
>>
>> When I merged that change into my branch, git didn't detect the rename
>> because the fact that every line has a change (the end-of-line
>> character) dropped the similarity score way too low.
>>
>> This patch teaches git to ignore end-of-line style when looking for
>> potential rename candidates. A separate question, which I expect may be
>> more controversial, is what to do with conflict markers; with this
>> patch, the entire file is still marked as in conflict if the end-of-line
>> style changes (but it's still an improvement in that we at least detect
>> the rename now.)
>
> I think that nobody would object to have a use-case description like
> this in the commit message...
Oh, yeah. 100% agreed.
^ permalink raw reply
* Re: [PATCH] Ignore end-of-line style when computing similarity score for rename detection
From: Johannes Sixt @ 2007-06-28 7:22 UTC (permalink / raw)
To: git
In-Reply-To: <20070628024603.GA1534@midwinter.com>
Steven Grimm wrote:
>
> Signed-off-by: Steven Grimm <koreth@midwinter.com>
> ---
> Okay, let's try this again with an MUA that won't change my tabs to
> spaces -- sorry about that.
>
> A couple of source files got checked into my code base with DOS-style
> end-of-line characters. I converted them to UNIX-style (the convention
> for this project) in my branch. Then later, I renamed a couple of them.
>
> Meanwhile, back in the original branch, someone else fixed a bug in one
> of the files and checked it in, still with DOS-style line endings.
>
> When I merged that change into my branch, git didn't detect the rename
> because the fact that every line has a change (the end-of-line
> character) dropped the similarity score way too low.
>
> This patch teaches git to ignore end-of-line style when looking for
> potential rename candidates. A separate question, which I expect may be
> more controversial, is what to do with conflict markers; with this
> patch, the entire file is still marked as in conflict if the end-of-line
> style changes (but it's still an improvement in that we at least detect
> the rename now.)
I think that nobody would object to have a use-case description like
this in the commit message...
-- Hannes
^ permalink raw reply
* Re: [PATCH] Avoid perl in t1300-repo-config
From: Alex Riesen @ 2007-06-28 7:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Frank Lichtenheld
In-Reply-To: <7vmyykog4e.fsf@assigned-by-dhcp.pobox.com>
On 6/28/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Alex Riesen" <raa.lkml@gmail.com> writes:
>
> > It fixes the test on system where ActiveState Perl is used.
> > It is also shorter.
> > ...
> > -git config --null --list | perl -0ne 'chop;($key,$value)=...
> > +git config --null --list | xargs -n1 -0 echo 'Key:' > result
>
> This now makes us rely on "xargs -0", which is probably much
> less portable than Perl isn't it?
Dunno. Have yet too meet a system where it doesn't work.
That said, SUSv6 does not mention it.
> Maybe postprocess "git config -z" output with "tr '[\000]' 'Q'"
> or something so that the comparison of the result does not have
> to worry about NULs? I dunno.
Will try that.
> By the way, is it possible for gmail users to avoid attachments
> when sending patches in?
No. The message text is unpredictably garbled
^ permalink raw reply
* [PATCH] Add emacs 'ediff' mode to git-mergetool's tools
From: Jason Sewall @ 2007-06-28 6:25 UTC (permalink / raw)
To: gitster, git; +Cc: Jason Sewall
It is now possible to specifiy 'ediff' as a value to the '--tool=' option to git-mergetool; this invokes an ediff session in emacs with the appropriate files.
Signed-off-by: Jason Sewall <jasonsewall@gmail.com>
---
Ediff is is an emacs mode similar to emerge for performing merges; it is fuller-featured than emerge and I find it easier to use.
git-mergetool.sh | 17 +++++++++++++----
1 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 7b66309..c27d212 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -258,6 +258,15 @@ merge_file () {
status=$?
save_backup
;;
+ ediff)
+ if base_present ; then
+ emacs --eval "(ediff-merge-files-with-ancestor \"$LOCAL\" \"$REMOTE\" \"$BASE\" \"$path\")"
+ else
+ emacs --eval "(ediff-merge-files \"$LOCAL\" \"$REMOTE\" \"$path\")"
+ fi
+ status=$?
+ save_backup
+ ;;
esac
if test "$status" -ne 0; then
echo "merge of $path failed" 1>&2
@@ -299,7 +308,7 @@ done
if test -z "$merge_tool"; then
merge_tool=`git-config merge.tool`
case "$merge_tool" in
- kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | "")
+ kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | ediff | vimdiff | gvimdiff | "")
;; # happy
*)
echo >&2 "git config option merge.tool set to unknown tool: $merge_tool"
@@ -320,7 +329,7 @@ if test -z "$merge_tool" ; then
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 ediff"
fi
if echo "${VISUAL:-$EDITOR}" | grep 'vim' > /dev/null 2>&1; then
merge_tool_candidates="$merge_tool_candidates vimdiff"
@@ -328,7 +337,7 @@ if test -z "$merge_tool" ; then
merge_tool_candidates="$merge_tool_candidates opendiff emerge vimdiff"
echo "merge tool candidates: $merge_tool_candidates"
for i in $merge_tool_candidates; do
- if test $i = emerge ; then
+ if test $i = emerge -o $i = ediff ; then
cmd=emacs
else
cmd=$i
@@ -351,7 +360,7 @@ case "$merge_tool" in
exit 1
fi
;;
- emerge)
+ emerge|ediff)
if ! type "emacs" > /dev/null 2>&1; then
echo "Emacs is not available"
exit 1
--
1.5.2.2.589.g4b646
^ permalink raw reply related
* Re: [PATCH] Ignore end-of-line style when computing similarity score for rename detection
From: Shawn O. Pearce @ 2007-06-28 6:18 UTC (permalink / raw)
To: Steven Grimm; +Cc: Junio C Hamano, git
In-Reply-To: <20070628060416.GA13162@midwinter.com>
Steven Grimm <koreth@midwinter.com> wrote:
> Junio rightly points out that it would be a mistake to discard \r
> characters from binary files when computing similarity scores. So now we
> only do it if the file contents test as non-binary.
>
> The file attributes aren't available at this level of the code, but they
> could be propagated down from the higher levels if we don't trust
> buffer_is_binary() to make an adequately accurate decision.
Ick. If we can get the attributes into diff_filespec this is
pretty easy, as you can do a crlf->lf conversion on both files if
both are considered to be text, but it doesn't look like it would
be very easy to get the attributes into the diff_filespec.
Actually even better if you can also run the in/out filter things.
I'm thinking of say an XML file that has had whitespace formatting
changes, but whose XSD and processors ignore unnecessary whitespace.
Be nice if the rename detection actually was able to canonicalize
both files before detecting the rename, assuming both files had a
canonicalizer input filter defined that does that...
Of course diff.c defines a nice diff_is_binary() at file scope that
does at least a "can we diff this" decision. Might be good if that
could be reused for the rename detection.
OK, that's far more than I actually know about diffcore. This is
one for Junio, Linus, you, and those who are less tired than I feel
right now... ;-)
Personally I'd rather see us doing the right thing (use attributes
and fallback on guessing if no preference is stated either way)
over doing something half-a**ed (only guessing).
--
Shawn.
^ permalink raw reply
* [PATCH] Ignore end-of-line style when computing similarity score for rename detection
From: Steven Grimm @ 2007-06-28 6:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtzssog5i.fsf@assigned-by-dhcp.pobox.com>
Signed-off-by: Steven Grimm <koreth@midwinter.com>
---
Junio rightly points out that it would be a mistake to discard \r
characters from binary files when computing similarity scores. So now we
only do it if the file contents test as non-binary.
The file attributes aren't available at this level of the code, but they
could be propagated down from the higher levels if we don't trust
buffer_is_binary() to make an adequately accurate decision.
diffcore-delta.c | 19 +++++++++++++------
1 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/diffcore-delta.c b/diffcore-delta.c
index 7338a40..52e648f 100644
--- a/diffcore-delta.c
+++ b/diffcore-delta.c
@@ -1,6 +1,7 @@
#include "cache.h"
#include "diff.h"
#include "diffcore.h"
+#include "xdiff-interface.h"
/*
* Idea here is very simple.
@@ -125,7 +126,8 @@ static struct spanhash_top *add_spanhash(struct spanhash_top *top,
}
}
-static struct spanhash_top *hash_chars(unsigned char *buf, unsigned int sz)
+static struct spanhash_top *hash_chars(unsigned char *buf, unsigned int sz,
+ int is_binary)
{
int i, n;
unsigned int accum1, accum2, hashval;
@@ -143,9 +145,12 @@ static struct spanhash_top *hash_chars(unsigned char *buf, unsigned int sz)
unsigned int c = *buf++;
unsigned int old_1 = accum1;
sz--;
- accum1 = (accum1 << 7) ^ (accum2 >> 25);
- accum2 = (accum2 << 7) ^ (old_1 >> 25);
- accum1 += c;
+ /* Ignore \r\n vs. \n when computing text file similarity. */
+ if (c != '\r' && ! is_binary) {
+ accum1 = (accum1 << 7) ^ (accum2 >> 25);
+ accum2 = (accum2 << 7) ^ (old_1 >> 25);
+ accum1 += c;
+ }
if (++n < 64 && c != '\n')
continue;
hashval = (accum1 + accum2 * 0x61) % HASHBASE;
@@ -172,14 +177,16 @@ int diffcore_count_changes(void *src, unsigned long src_size,
if (src_count_p)
src_count = *src_count_p;
if (!src_count) {
- src_count = hash_chars(src, src_size);
+ int src_is_binary = buffer_is_binary(src, src_size);
+ src_count = hash_chars(src, src_size, src_is_binary);
if (src_count_p)
*src_count_p = src_count;
}
if (dst_count_p)
dst_count = *dst_count_p;
if (!dst_count) {
- dst_count = hash_chars(dst, dst_size);
+ int dst_is_binary = buffer_is_binary(dst, dst_size);
+ dst_count = hash_chars(dst, dst_size, dst_is_binary);
if (dst_count_p)
*dst_count_p = dst_count;
}
--
1.5.2.2.571.ge134
^ permalink raw reply related
* Re: [PATCH] git-submodule: Instead of using only annotated tags, use any tag found in .git/refs/tags
From: Shawn O. Pearce @ 2007-06-28 5:27 UTC (permalink / raw)
To: Medve Emilian-EMMEDVE1; +Cc: git
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E27011CFD8F@az33exm24.fsl.freescale.net>
Medve Emilian-EMMEDVE1 <Emilian.Medve@freescale.com> wrote:
> While playing with git-describe I noticed that the --all option is maybe
> not trying first to find a tag as the man page suggests but it goes
> directly for .git/refs. Here is some output from my git repo clone with
> yesterday's head on the master branch:
>
> $ git-describe aeb59328453cd4f438345ea79ff04c96bccbbbb8
> v1.5.2.2-549-gaeb5932
>
> $ git-describe --all aeb59328453cd4f438345ea79ff04c96bccbbbb8
> heads/master
Yea. Look at what's happening. In the --all case we attach
heads/master into the ->util field of aeb5's struct commit*.
Since no annotated tag (a ref with prio 2) and no lightweight tag
(a ref with prio 1) was found pointing at aeb5 we kept that ->util
field pointing at the heads/master ref (which has prio 0).
The --all and --tags options are about selecting what refs can
appear in that ->util field. That's _all_ they do.
Later in describe() at l.151 we immediately display a ref if there
is one in the ->util field:
150 n = cmit->util;
151 if (n) {
152 printf("%s\n", n->path);
153 return;
154 }
So we're favoring a ref that points directly at a commit over any
other ref. We only search if we don't have a ref pointing directly
at the input commit. Searching is when ranking really gets involved.
> Do you think we want to fix that? If yes, I could look into it and
> submit a patch.
I'm not sure. If we "fixed" this then --all would only ever turn
up a head if no annotated tag exists on the entire history of that
input commit. Because the "fix" would be to actually not return
right away here at l.151, but instead to drop down further into the
slower loop where we traverse through commits, pick our candidates,
rank them, and then pick the highest priorty ref that is also
the closest. The annotated tag would always win over the head.
At which point --all is only ever useful if the repository *never*
had an annotated tag along the input branch. I'm not sure that's
useful as a description for a commit. If no annotated tag exists
the raw commit SHA-1 is probably a better description. Its at
least stable with time. ;-)
In my opinion, git-describe is doing *exactly* what the manual page
says it does. But both the current implementation and the manual
page were last majorly overhauld by me. So take my comments about
the documentation with a grain of salt. ;-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-log: detect dup and fdopen failure
From: Shawn O. Pearce @ 2007-06-28 5:02 UTC (permalink / raw)
To: Josh Triplett; +Cc: Linus Torvalds, Jim Meyering, Geert Bosch, Alex Riesen, git
In-Reply-To: <4683211E.2010704@freedesktop.org>
Josh Triplett <josh@freedesktop.org> wrote:
> Linus Torvalds wrote:
> > That said, the whole "prepend 'x' to the function name" thing is obviously
> > how git does things, but maybe it would be more readable in the long term
> > to make the prefix be 'safe_' instead of 'x', or something like that?
>
> If you want a more verbose name than xfoo, I personally like the foo_or_die
> convention, which reminds you explicitly that the function might kill the
> program. safe_ might convey exactly the opposite impression.
I think the _gently suffix is already preferred for the
non-die()'ing variant of a function within Git. For example see
setup_git_directory_gently() or lookup_commit_reference_gently().
Of course pkt-line.c goes and defines safe_read/safe_write.
And lets not forget about safe_create_dir() and
safe_create_leading_directories().
I guess we're about half-way in both directions. Next function
declared with safe_ prefix or _gently suffix will tip the scale in
one direction or the other. ;-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Avoid perl in t1300-repo-config
From: Junio C Hamano @ 2007-06-28 4:30 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List, Frank Lichtenheld, Junio C Hamano
In-Reply-To: <81b0412b0706270545w65ca2556yaafaac6ff31b5961@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
> It fixes the test on system where ActiveState Perl is used.
> It is also shorter.
> ...
> -git config --null --list | perl -0ne 'chop;($key,$value)=split(/\n/,$_,2);print "Key: $key\n";print "Value: $value\n" if defined($value)' > result
> +git config --null --list | xargs -n1 -0 echo 'Key:' > result
This now makes us rely on "xargs -0", which is probably much
less portable than Perl isn't it? Because the point of the test
is that it can show things in NUL terminated format, I'd rather
keep it use a bit more portable stuff. Also I am not sure if
the two tests are really testing the same thing.
Maybe postprocess "git config -z" output with "tr '[\000]' 'Q'"
or something so that the comparison of the result does not have
to worry about NULs? I dunno.
By the way, is it possible for gmail users to avoid attachments
when sending patches in?
^ permalink raw reply
* Re: [PATCH] Ignore end-of-line style when computing similarity score for rename detection
From: Junio C Hamano @ 2007-06-28 4:29 UTC (permalink / raw)
To: Steven Grimm; +Cc: 'git'
In-Reply-To: <46831F70.2060403@midwinter.com>
I wonder if we have a path or the attribute cue at this point of
the operation. Your patch may solve that special case of CRLF
mangled files, but diffcore-delta works both on text and binary
and I am not sure what damange/side-effect you are causing.
And you are not ignoring "\r\n vs \n difference" as the comment
claims, but are discarding '\r' unconditionally. When we start
doing something like that, I would feel much better if we _know_
we are operating on a text file at least.
^ permalink raw reply
* Re: [PATCH] git-submodule: Try harder to describe the status of a submodule
From: Junio C Hamano @ 2007-06-28 4:24 UTC (permalink / raw)
To: Emil Medve; +Cc: git
In-Reply-To: <118297160163-git-send-email-Emilian.Medve@Freescale.com>
Emil Medve <Emilian.Medve@Freescale.com> writes:
> Some repositories might not use/have annotated tags (for example repositories created with
> git-cvsimport) or might not have tags at all and could cause git-submodule status to fail because
> git-describe might fail.
>
> This change makes git-submodule status try harder in displaying the status of a module by
> considering lightweight tags, subsequent tags and branches.
Why are we suddenly seeing these loooooooong lines...
> +get_revname()
> +{
> + _revname=$(git-describe --tags "$1" 2>/dev/null || git-describe --contains "$1" 2>/dev/null)
> + if test -z "$_revname" -o "$_revname" = "undefined"
> + then
> + _revname=$(git-describe --all "$1" 2>/dev/null | cut -d / -f2-)
> + test -z "$_revname" && _revname=undefined
> + fi
I really do not think using --all is useful. If you do not have
a tag and the rev cannot be described, what damage does it incur?
We still say "$sha1 $path" in the output anyway, and ($revname)
is only "it makes it nicer" appendix.
> @@ -155,7 +174,7 @@ modules_list()
> say "-$sha1 $path"
> continue;
> fi
> - revname=$(unset GIT_DIR && cd "$path" && git-describe $sha1)
> + revname=$(unset GIT_DIR && cd "$path" && get_revname $sha1)
> if git diff-files --quiet -- "$path"
> then
> say " $sha1 $path ($revname)"
In that sense, I would prefer mine much better. If a rev is
indescribable, your version would say:
" dddddddddddddddddddddddddddddddddddddddd subdir (undefined)"
while mine would have said:
" dddddddddddddddddddddddddddddddddddddddd subdir"
^ permalink raw reply
* Re: Problem with Linus's git repository?
From: Junio C Hamano @ 2007-06-28 4:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: walt, git
In-Reply-To: <alpine.LFD.0.98.0706270932040.8675@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> What is your git version? The _real_ fix probably is to just upgrade. Are
> you using that broken(*) Debian git package by any chance?
>
> Linus
>
> (*) By broken I mean "stable cannot be bothered to upgrade packages to
> modern versions, and is still on some ancient 1.4-based git version"
Well, although git 1.4 is ancient in git timescale, you can keep
your repository friendly with older versions of git and 1.4
certainly is not too old for that. In other words, newer git
lets you choose to make your repository unreadable by 1.4, and
you chose to do so, perhaps for a good reason.
Should we call git 1.5 "backward incompatible" with 1.4, because
it allows you (or anybody) to make that choice? I dunno.
^ permalink raw reply
* Re: [PATCH] git-log: detect dup and fdopen failure
From: Josh Triplett @ 2007-06-28 2:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jim Meyering, Geert Bosch, Alex Riesen, git
In-Reply-To: <alpine.LFD.0.98.0706270935340.8675@woody.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 776 bytes --]
Linus Torvalds wrote:
> On Wed, 27 Jun 2007, Jim Meyering wrote:
>> Subject: [PATCH] git-log: detect dup and fdopen failure
>> git-compat-util.h (xdup, xfdopen): Define functions.
>>
>> Signed-off-by: Jim Meyering <jim@meyering.net>
>
> Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
>
> That said, the whole "prepend 'x' to the function name" thing is obviously
> how git does things, but maybe it would be more readable in the long term
> to make the prefix be 'safe_' instead of 'x', or something like that?
If you want a more verbose name than xfoo, I personally like the foo_or_die
convention, which reminds you explicitly that the function might kill the
program. safe_ might convey exactly the opposite impression.
- Josh Triplett
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* [PATCH] Ignore end-of-line style when computing similarity score for rename detection
From: Steven Grimm @ 2007-06-28 2:46 UTC (permalink / raw)
To: git
In-Reply-To: <46831F70.2060403@midwinter.com>
Signed-off-by: Steven Grimm <koreth@midwinter.com>
---
Okay, let's try this again with an MUA that won't change my tabs to
spaces -- sorry about that.
A couple of source files got checked into my code base with DOS-style
end-of-line characters. I converted them to UNIX-style (the convention
for this project) in my branch. Then later, I renamed a couple of them.
Meanwhile, back in the original branch, someone else fixed a bug in one
of the files and checked it in, still with DOS-style line endings.
When I merged that change into my branch, git didn't detect the rename
because the fact that every line has a change (the end-of-line
character) dropped the similarity score way too low.
This patch teaches git to ignore end-of-line style when looking for
potential rename candidates. A separate question, which I expect may be
more controversial, is what to do with conflict markers; with this
patch, the entire file is still marked as in conflict if the end-of-line
style changes (but it's still an improvement in that we at least detect
the rename now.)
diffcore-delta.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/diffcore-delta.c b/diffcore-delta.c
index 7338a40..10bbf95 100644
--- a/diffcore-delta.c
+++ b/diffcore-delta.c
@@ -143,9 +143,12 @@ static struct spanhash_top *hash_chars(unsigned char *buf, unsigned int sz)
unsigned int c = *buf++;
unsigned int old_1 = accum1;
sz--;
- accum1 = (accum1 << 7) ^ (accum2 >> 25);
- accum2 = (accum2 << 7) ^ (old_1 >> 25);
- accum1 += c;
+ /* Ignore \r\n vs. \n when computing similarity. */
+ if (c != '\r') {
+ accum1 = (accum1 << 7) ^ (accum2 >> 25);
+ accum2 = (accum2 << 7) ^ (old_1 >> 25);
+ accum1 += c;
+ }
if (++n < 64 && c != '\n')
continue;
hashval = (accum1 + accum2 * 0x61) % HASHBASE;
--
1.5.2.2.571.ge134
^ permalink raw reply related
* [PATCH] Ignore end-of-line style when computing similarity score for rename detection
From: Steven Grimm @ 2007-06-28 2:39 UTC (permalink / raw)
To: 'git'
Signed-off-by: Steven Grimm <koreth@midwinter.com>
---
A couple of source files got checked into my code base with DOS-style
end-of-line characters. I converted them to UNIX-style (the convention
for this project) in my branch. Then later, I renamed a couple of them.
Meanwhile, back in the original branch, someone else fixed a bug in one
of the files and checked it in, still with DOS-style line endings.
When I merged that change into my branch, git didn't detect the rename
because the fact that every line has a change (the end-of-line
character) dropped the similarity score way too low.
This patch teaches git to ignore end-of-line style when looking for
potential rename candidates. A separate question, which I expect may be
more controversial, is what to do with conflict markers; with this
patch, the entire file is still marked as in conflict if the end-of-line
style changes (but it's still an improvement in that we at least detect
the rename now.)
diffcore-delta.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/diffcore-delta.c b/diffcore-delta.c
index 7338a40..10bbf95 100644
--- a/diffcore-delta.c
+++ b/diffcore-delta.c
@@ -143,9 +143,12 @@ static struct spanhash_top *hash_chars(unsigned
char *buf, unsigned int sz)
unsigned int c = *buf++;
unsigned int old_1 = accum1;
sz--;
- accum1 = (accum1 << 7) ^ (accum2 >> 25);
- accum2 = (accum2 << 7) ^ (old_1 >> 25);
- accum1 += c;
+ /* Ignore \r\n vs. \n when computing similarity. */
+ if (c != '\r') {
+ accum1 = (accum1 << 7) ^ (accum2 >> 25);
+ accum2 = (accum2 << 7) ^ (old_1 >> 25);
+ accum1 += c;
+ }
if (++n < 64 && c != '\n')
continue;
hashval = (accum1 + accum2 * 0x61) % HASHBASE;
--
1.5.2.2.571.ge134
^ permalink raw reply related
* Re: most commonly used git commands?
From: Josh Triplett @ 2007-06-28 2:30 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, Michael S. Tsirkin, git
In-Reply-To: <46a038f90706271917j7abb4bddu21debafe3461c695@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1228 bytes --]
Martin Langhoff wrote:
> On 6/25/07, Junio C Hamano <gitster@pobox.com> wrote:
>> "Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
>>>> Quoting Junio C Hamano <gitster@pobox.com>:
>>>> Perhaps they are most commonly used by the person who came up
>>>> with that list first ;-)?
>>>>
>>>> I think "add" deserves to be there, I am not sure "apply" is.
>>> git add is supposed to be rare, no?
>>> That's why git commit lists file additions/removals ...
>> No. You are talking in terms of pre-1.5 git. The semantics of
>> "git add" has been clarified since then --- it adds contents,
>> and is not about telling git that there are new files it did not
>> know so far.
>
> In other words - git-add is also a (semantically good) alias for
> git-update-index.
>
> So you "add" files to the next commit. Whether they are "new" to git
> or just changed it doesn't matter that much in that situation. And
> git-commit will look at those files that have been "added".
>
> Makes things a whole lot easier to explain. I didn't understand it
> initially, now I'm completely sold on the concept.
Agreed; this change converted me from a "git commit -a" user to a big fan of
the index.
- Josh Triplett
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: most commonly used git commands?
From: Martin Langhoff @ 2007-06-28 2:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael S. Tsirkin, git
In-Reply-To: <7vodj41nm6.fsf@assigned-by-dhcp.pobox.com>
On 6/25/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
>
> >> Quoting Junio C Hamano <gitster@pobox.com>:
> >> Perhaps they are most commonly used by the person who came up
> >> with that list first ;-)?
> >>
> >> I think "add" deserves to be there, I am not sure "apply" is.
> >
> > git add is supposed to be rare, no?
> > That's why git commit lists file additions/removals ...
>
> No. You are talking in terms of pre-1.5 git. The semantics of
> "git add" has been clarified since then --- it adds contents,
> and is not about telling git that there are new files it did not
> know so far.
In other words - git-add is also a (semantically good) alias for
git-update-index.
So you "add" files to the next commit. Whether they are "new" to git
or just changed it doesn't matter that much in that situation. And
git-commit will look at those files that have been "added".
Makes things a whole lot easier to explain. I didn't understand it
initially, now I'm completely sold on the concept.
m
^ permalink raw reply
* Re: most commonly used git commands?
From: Josh Triplett @ 2007-06-28 1:37 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Junio C Hamano, git
In-Reply-To: <20070625064017.GA2839@mellanox.co.il>
Michael S. Tsirkin wrote:
> I did this by mistake:
>
> $git fet linux-2.6
> git: 'fet' is not a git-command
>
> The most commonly used git commands are:
> add Add file contents to the changeset to be committed next
> apply Apply a patch on a git index file and a working tree
> (use 'git help -a' to get a list of all installed git commands)
It should have listed more than just those two...
- Josh Triplett
^ permalink raw reply
* Re: cloning empty repo
From: Josh Triplett @ 2007-06-28 1:32 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Marijn Schouten (hkBst), git
In-Reply-To: <20070624230157.GM17393@spearce.org>
Shawn O. Pearce wrote:
> "Marijn Schouten (hkBst)" <hkBst@gentoo.org> wrote:
>> is there any reason why cloning an empty repository should result in an error
>> instead of a succesfully cloned empty repo?
>
> There's nothing to clone. The repository is empty.
>
> If you create a Git repository using `git init` and then create
> another one also using `git init` then both repositories are empty,
> and an empty repository is identical to every other empty repository.
>
> So if you want to setup an empty repository and then clone nothing,
> you actually can just setup another empty repository and configure
> the 'origin' remote:
>
> mkdir a; cd a; git init; cd ..
>
> mkdir b; cd b; git init
> # now a and b are identical
>
> git remote add origin ../a/.git
> # now b is a "clone" of a's nothingness...
You can also simulate a clone of any other repository by using a similar
series of commands; git clone exists so that you don't have to. Why not allow
cloning an empty repository, which would give you an empty repository with the
correct origin remote?
- Josh Triplett
^ permalink raw reply
* Re: Darcs
From: Josh Triplett @ 2007-06-28 1:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Bu Bacoo, git
In-Reply-To: <alpine.LFD.0.98.0706241030540.3593@woody.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 496 bytes --]
Linus Torvalds wrote:
> On Sun, 24 Jun 2007, Bu Bacoo wrote:
>> What do you think about darcs?
>>
>> There was a lot written/spoken about morons and stupidos around
>> thinking in cvs / svn, etc... (what would be the words for dudes
>> around vss ....).
>
> Ahh, a chance to flame! I will never back down from such a challenge!
>
> Darcs is .. umm .. ehh..
Wow. You completely skipped the opportunity to flame Visual Source Safe (vss)
users. :) Too easy?
- Josh Triplett
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: Mark Levedahl's gitk patches
From: Paul Mackerras @ 2007-06-28 0:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mark Levedahl, Johannes Sixt, git
In-Reply-To: <7v645axm7r.fsf@assigned-by-dhcp.pobox.com>
Junio C Hamano writes:
> I took a look at differences between your gitk.git and what I
> have. It appears that our "proc readrefs" differ a bit.
>
> Most notably, the global hash tagcontents is read when readrefs
> run in the version I have, while gitk.git version fills it
> lazily in showtag, where it is actually used. Because you read
> the refs using "show-ref -d", you do not need to do extra forks
> to figure out the objects referred to by the tags in your code.
Yes, that was one of the many improvements I made. Basically I pulled
a lot of stuff over from the 'new' branch.
> I think what you have is a lot better from interactive latency
> point of view. I'll take the version from gitk.git and push the
> results out.
Thanks. I have now pushed out Mark Levedahl's two bug fixes as well.
Paul.
^ permalink raw reply
* Re: post-update script to update wc - version 2
From: Sam Vilain @ 2007-06-27 23:53 UTC (permalink / raw)
To: Steven Grimm; +Cc: Sam Vilain, git
In-Reply-To: <468217B4.3030708@midwinter.com>
Steven Grimm wrote:
> Sam Vilain wrote:
>> # An example hook script to prepare a packed repository for use over
>> # dumb transports.
>>
> Maybe this comment isn't quite accurate any more?
Ok that should read something like
# This hook does two things:
#
# 1. update the "info" files that allow the list of references to be
# queries over dumb transports such as http
#
# 2. if this repository looks like it is a non-bare repository, and
# the checked-out branch is pushed to, then update the working copy.
# This makes "push" and "pull" symmetric operations as in darcs and
# bzr.
Sam.
^ permalink raw reply
* Re: [PATCH 1/2] git-send-email: Add negations and config equivalents for --suppress-from and --no-signed-off-cc
From: Adam Roben @ 2007-06-27 23:47 UTC (permalink / raw)
To: Adam Roben; +Cc: git, Junio C Hamano
In-Reply-To: <1182927238504-git-send-email-aroben@apple.com>
Junio, I see that you applied my previous patch to master before I
sent these two new ones that replace it. Would you like me to redo
these patches based on master, or will you revert the old patch and
apply these? I'm happy either way. Thanks!
-Adam
On Jun 26, 2007, at 11:53 PM, Adam Roben wrote:
> This change makes git-send-email's behavior easier to modify by
> adding config
> equivalents for two more of git-send-email's flags.
>
> The mapping of flag to config setting is:
> --[no-]supress-from => sendemail.suppressfrom
> --[no-]signed-off-cc => sendemail.signedoffcc
>
> Signed-off-by: Adam Roben <aroben@apple.com>
> ---
> Thanks to Junio for the suggestion for how to clean up the default
> values.
>
> Documentation/git-send-email.txt | 16 ++++++++++------
> git-send-email.perl | 34 ++++++++++++++++++++
> +-------------
> 2 files changed, 31 insertions(+), 19 deletions(-)
>
> diff --git a/Documentation/git-send-email.txt b/Documentation/git-
> send-email.txt
> index 946bd76..01bbd18 100644
> --- a/Documentation/git-send-email.txt
> +++ b/Documentation/git-send-email.txt
> @@ -59,9 +59,11 @@ The --cc option must be repeated for each user
> you want on the cc list.
> Only necessary if --compose is also set. If --compose
> is not set, this will be prompted for.
>
> ---no-signed-off-by-cc::
> - Do not add emails found in Signed-off-by: or Cc: lines to the
> - cc list.
> +--signed-off-by-cc, --no-signed-off-by-cc::
> + If this is set, add emails found in Signed-off-by: or Cc:
> lines to the
> + cc list.
> + Default is the value of 'sendemail.signedoffbycc'
> configuration value;
> + if that is unspecified, default to --signed-off-by-cc.
>
> --quiet::
> Make git-send-email less verbose. One line per email should be
> @@ -82,9 +84,11 @@ The --cc option must be repeated for each user
> you want on the cc list.
> Only necessary if --compose is also set. If --compose
> is not set, this will be prompted for.
>
> ---suppress-from::
> - Do not add the From: address to the cc: list, if it shows up in a
> From:
> - line.
> +--suppress-from, --no-suppress-from::
> + If this is set, do not add the From: address to the cc:
> list, if it
> + shows up in a From: line.
> + Default is the value of 'sendemail.suppressfrom'
> configuration value;
> + if that is unspecified, default to --no-supress-from.
>
> --dry-run::
> Do everything except actually send the emails.
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 9f75551..584eda9 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -64,15 +64,14 @@ Options:
> email sent, rather than to the first email sent.
> Defaults to on.
>
> - --no-signed-off-cc Suppress the automatic addition of email
> addresses
> - that appear in Signed-off-by: or Cc: lines to the
> cc:
> - list. Note: Using this option is not recommended.
> + --signed-off-cc Automatically add email addresses that appear in
> + Signed-off-by: or Cc: lines to the cc: list.
> Defaults to on.
>
> --smtp-server If set, specifies the outgoing SMTP server to use.
> Defaults to localhost.
>
> --suppress-from Suppress sending emails to yourself if your address
> - appears in a From: line.
> + appears in a From: line. Defaults to off.
>
> --quiet Make git-send-email less verbose. One line per email
> should be all that is output.
> @@ -137,9 +136,6 @@ my $compose_filename = ".msg.$$";
> my (@to,@cc,@initial_cc,@bcclist,@xh,
> $initial_reply_to,$initial_subject,@files,$from,$compose,$time);
>
> -# Behavior modification variables
> -my ($chain_reply_to, $quiet, $suppress_from, $no_signed_off_cc,
> - $dry_run) = (1, 0, 0, 0, 0);
> my $smtp_server;
> my $envelope_sender;
>
> @@ -154,9 +150,21 @@ if ($@) {
> $term = new FakeTerm "$@: going non-interactive";
> }
>
> -my $def_chain = $repo->config_bool('sendemail.chainreplyto');
> -if (defined $def_chain and not $def_chain) {
> - $chain_reply_to = 0;
> +# Behavior modification variables
> +my ($quiet, $dry_run) = (0, 0);
> +
> +# Variables with corresponding config settings
> +my ($chain_reply_to, $suppress_from, $signed_off_cc);
> +
> +my %config_settings = (
> + "chainreplyto" => [\$chain_reply_to, 1],
> + "suppressfrom" => [\$suppress_from, 0],
> + "signedoffcc" => [\$signed_off_cc, 1],
> +);
> +
> +foreach my $setting (keys %config_settings) {
> + my $config = $repo->config_bool("sendemail.$setting");
> + ${$config_settings{$setting}->[0]} = (defined $config) ?
> $config : $config_settings{$setting}->[1];
> }
>
> @bcclist = $repo->config('sendemail.bcc');
> @@ -177,8 +185,8 @@ my $rc = GetOptions("from=s" => \$from,
> "smtp-server=s" => \$smtp_server,
> "compose" => \$compose,
> "quiet" => \$quiet,
> - "suppress-from" => \$suppress_from,
> - "no-signed-off-cc|no-signed-off-by-cc" => \$no_signed_off_cc,
> + "suppress-from!" => \$suppress_from,
> + "signed-off-cc|signed-off-by-cc!" => \$signed_off_cc,
> "dry-run" => \$dry_run,
> "envelope-sender=s" => \$envelope_sender,
> );
> @@ -609,7 +617,7 @@ foreach my $t (@files) {
> }
> } else {
> $message .= $_;
> - if (/^(Signed-off-by|Cc): (.*)$/i && !$no_signed_off_cc) {
> + if (/^(Signed-off-by|Cc): (.*)$/i && $signed_off_cc) {
> my $c = $2;
> chomp $c;
> push @cc, $c;
> --
> 1.5.2.2.551.ga811
>
> -
> 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: post-update script to update wc - version 2
From: Sam Vilain @ 2007-06-27 22:45 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0706270221y40bac0a7gf6b73eda9f1e4bb0@mail.gmail.com>
Alex Riesen wrote:
> On 6/27/07, Sam Vilain <sam@vilain.net> wrote:
>> Sam Vilain wrote:
>>> this_tree=`git-cat-file commit $commit | awk '/^tree/ { print $2; exit }'`
>> Of course on newer git, `git-rev-parse $commit:` will do that.
> Are you sure? Maybe you mean git-rev-parse "$commit"^{tree}?
Ah, I missed that on the git-rev-parse man page. Much better!
Sam.
^ permalink raw reply
* Re: git-svn error "Unable to extract revision information from commit ...~1"
From: Steven Grimm @ 2007-06-27 20:25 UTC (permalink / raw)
To: Patrick Doyle; +Cc: 'git'
In-Reply-To: <e2a1d0aa0706271031n3191a27fi41ca5ba3f14c3a51@mail.gmail.com>
Patrick Doyle wrote:
> Wouldn't the svn head be called "git-svn"?
> Should the first checkout be written as:
>
> git checkout -b tempbranch git-svn
>
> (In other words, were the "trunk" and "tempbranch" arguments swapped
> in your example?)
Yes, sorry, I swapped the arguments. Should indeed be "git checkout -b
(your new branch name) (svn head branch name)" rather than the other way
around. My apologies for not proofreading my message.
However, the name of the svn head branch depends on the version of
git-svn you're using, and how you cloned the svn repository. If you used
the -T/--trunk option, then the svn head branch will indeed be called
"trunk" (and you might also have other branches corresponding to
whatever branches you're tracking in the svn repository.) If you're not
using that option, then your svn tracking branch will be called
"git-svn" or "origin" depending on your git-svn version.
> Finally, what is the purpose of creating a new branch as part of that
> command?
You never ever want to work directly on the git-svn tracking branch. It
is considered a remote branch and while it is technically possible to
check it out and commit to it, you will almost certainly confuse git-svn
if you do.
Also, creating a new branch means you still have your original nonlinear
history easily accessible if you need it (just check out your old
branch.) You can certainly still get at the old history without creating
a new branch, but it's more awkward.
-Steve
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox