* Re: Fix UTF Encoding issue
From: Benjamin Close @ 2007-12-03 21:46 UTC (permalink / raw)
To: Jakub Narebski
Cc: Martin Koegler, Ismail Dönmez, Junio C Hamano,
Alexandre Julliard, git, Perl Unicode Mailing List, Dan Kogai
In-Reply-To: <200712031802.55514.jnareb@gmail.com>
Jakub Narebski wrote:
> On Mon, 3 Dec 2007, Martin Koegler wrote:
>
>> On Mon, Dec 03, 2007 at 04:06:48AM -0800, Jakub Narebski wrote:
>>
>>> Ismail Dönmez <ismail@pardus.org.tr> writes:
>>>
>>>> Monday 03 December 2007 Tarihinde 12:14:43 yazm??t?:
>>>>
>>>>> Benjamin Close <Benjamin.Close@clearchain.com> writes:
>>>>>
>>>>>> - eval { $res = decode_utf8($str, Encode::FB_CROAK); };
>>>>>> - if (defined $res) {
>>>>>> - return $res;
>>>>>> - } else {
>>>>>> - return decode($fallback_encoding, $str, Encode::FB_DEFAULT);
>>>>>> - }
>>>>>> + eval { return ($res = decode_utf8($str, Encode::FB_CROAK)); };
>>>>>> + return decode($fallback_encoding, $str, Encode::FB_DEFAULT);
>>>>>> }
>>>>>>
>> This version is broken on Debian sarge and etch. Feeding a UTF-8 and a latin1
>> encoding of the same character sequence yields to different results.
>>
>
>
For the record, this was on a debian sid machine.
#perl --version
This is perl, v5.8.8 built for x86_64-linux-gnu-thread-multi
and the result of not using the original patch was:
<h1>Software error:</h1>
<pre>Cannot decode string with wide characters at /usr/lib/perl/5.8/Encode.pm line 166.
</pre>
I haven't tried the other solutions tested here.
>> eval { $res = decode_utf8(...); }
>> if ($@)
>> return decode(...);
>> return $res
>>
>> or
>>
>> eval { $res = decode_utf8(...); }
>> if (defined $res)
>> return $res;
>> else
>> return decode(...);
>>
>> show the same (wrong) behaviour on Debian sarge. They do not always
>> decode non UTF-8 characters correctly, eg.
>> #öäü does not work
>> #äöüä does work
>>
>> On Debian etch, both versions are working.
>>
>
> I don't know enough Perl to decide if it is a bug in gitweb usage
> of decode_utf8, if it is a bug in your version of Encode, or if it
> is bug in Encode.
>
> Send copy of this mail to maintainers of Encode perl module.
>
Ismail do you know if sid was also broken?
^ permalink raw reply
* Re: [PATCH] Simplify crud() in ident.c
From: Alex Riesen @ 2007-12-03 21:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0712032046480.27959@racer.site>
Johannes Schindelin, Mon, Dec 03, 2007 21:47:09 +0100:
> On Mon, 3 Dec 2007, Alex Riesen wrote:
> > + return c <= 32 ||
> > + c == '.' ||
> > + c == ',' ||
> > + c == ':' ||
> > + c == ';' ||
> > + c == '<' ||
> > + c == '>' ||
> > + c == '"' ||
> > + c == '\'';
>
> Or enhance ctype.c.
>
That's be nice, but the "crud" conflicts with existing classification,
so I'd have to change the is*-macros as well. Don't feel like it.
I believe the code is never in hotpath anyway so the shorter the
better.
^ permalink raw reply
* Re: [PATCH] Allow ':/<oneline-prefix>' syntax to work with save_commit_buffer == 0
From: Junio C Hamano @ 2007-12-03 21:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, git, gitster
In-Reply-To: <Pine.LNX.4.64.0712031841520.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> On Mon, 3 Dec 2007, Jeff King wrote:
>
> > On Mon, Dec 03, 2007 at 10:55:15AM +0000, Johannes Schindelin wrote:
> >
> > > But then, my patch also works when save_commit_buffer == 0.
> > > But I can refactor this into its own patch, since it really is
> > > a separate issue.
> >
> > Agreed.
>
> Here we go.
The log message is a bit lacking. I would have expected "git-show
command can take ':/prefix' as an argument to name a commit whose
subject begins with the prefix, but git-foobar command didn't and
instead errored out. This fixes it so that ':/prefix' syntax can be
used for any command that wants to take a commit object name".
^ permalink raw reply
* Re: [PATCH] Simplify crud() in ident.c
From: Alex Riesen @ 2007-12-03 21:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano
In-Reply-To: <m3lk8bv8du.fsf@roke.D-201>
Jakub Narebski, Mon, Dec 03, 2007 21:19:29 +0100:
> Perhaps simplier, but isn't it slower?
doubt it
^ permalink raw reply
* Re: [PATCH] Open external merge tool with original file extensions in all three files
From: Junio C Hamano @ 2007-12-03 21:28 UTC (permalink / raw)
To: Pini Reznik; +Cc: git
In-Reply-To: <7v63zfiqx8.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Pini Reznik <pinir@expand.com> writes:
>
>> This required to be able to use syntax highlighting in meld during
>> conflicts resolution....
>
>> + extension=`echo $path | awk -F \. '{print $NF}'`
>> + BACKUP="$path.BACKUP.$$.${extension}"
>> + LOCAL="$path.LOCAL.$$.${extension}"
>> + REMOTE="$path.REMOTE.$$.${extension}"
>> + BASE="$path.BASE.$$.${extension}"
>
> I had to wonder what would happen in these cases:
>
> * path = "a/b/c/d"
> * path = "a/b.c/d"
>
> I also think spawning awk for this is way overkill.
IOW, I would probably write the above like this:
ext="$$$(expr "$path" : '.*\(\.[^/]*\)$')"
BACKUP="$path.BACKUP.$ext"
LOCAL="$path.LOCAL.$ext"
REMOTE="$path.REMOTE.$ext"
BASE="$path.BASE.$ext"
^ permalink raw reply
* Re: v1.5.4 plans
From: Junio C Hamano @ 2007-12-03 21:23 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.0.99999.0712031258460.9605@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> Two things I would like to see in the next version (1.5.5) as well, for
> which we could provide early warnings now:
>
> - repack.usedeltabaseoffset defaulting to true
>
> - pack.indexversion defaulting to 2
I think the former would be sensible, the latter I fear might be a bit
too new but I do not recall the exact version dependency.
Could you draft a patch to ReleaseNotes to explain the consequences of
these changes using ordinary user's vocabulary, like:
Starting v1.5.5, repack.usedeltabaseoffset will default to true,
which will give denser packfile (i.e. more efficient storage).
The downside is that git older than version X will not be able
to use a repository packed using this setting.
^ permalink raw reply
* [PATCH v3] Adding menus for Emacs git.el
From: Remi Vanicat @ 2007-12-03 21:06 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git
In-Reply-To: <87ir3f4s76.fsf@wine.dyndns.org>
Adding three menus to the git-status-mode of git.el : One for marking
and unmarking, one for what you do when you have a conflict, and the
other one for all the rest.
---
Alexandre Julliard <julliard@winehq.org> writes:
> Remi Vanicat <vanicat@debian.org> writes:
>> + ["Interctive Diff File" git-diff-file-idiff t]
>
> The typo is still here.
Pff, The typo was in two place, and I forgot to check this...
This time, I have run a spell checker on every menu entries, to be
sure.
contrib/emacs/git.el | 48 ++++++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 46 insertions(+), 2 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index e147da0..7fbea55 100644
(define-key toggle-map "i" 'git-toggle-show-ignored)
(define-key toggle-map "k" 'git-toggle-show-unknown)
(define-key toggle-map "m" 'git-toggle-all-marks)
- (setq git-status-mode-map map)))
+ (setq git-status-mode-map map))
+ (easy-menu-define git-menu-mark git-status-mode-map
+ "Git Merge Menu"
+ `("Merge"
+ ["Next Unmerged File" git-next-unmerged-file t]
+ ["Prev Unmerged File" git-prev-unmerged-file t]
+ ["Mark as Resolved" git-resolve-file t]
+ ["Interactive Merge File" git-find-file-imerge t]
+ ["Diff Against Common Base File" git-diff-file-base t]
+ ["Diff Combined" git-diff-file-combined t]
+ ["Diff Against Merge Head" git-diff-file-merge-head t]
+ ["Diff Against Mine" git-diff-file-mine t]
+ ["Diff Against Other" git-diff-file-other t]))
+ (easy-menu-define git-menu-mark git-status-mode-map
+ "Git Mark Menu"
+ `("Mark"
+ ["Mark File" git-mark-file t]
+ ["Mark All" git-mark-all t]
+ ["Unmark File" git-unmark-file t]
+ ["Unmark All" git-unmark-all t]
+ ["Toggle All Mark" git-toggle-all-marks t]))
+ (easy-menu-define git-menu git-status-mode-map
+ "Git Menu."
+ `("Git"
+ ["Refresh" git-refresh-status t]
+ ["Commit" git-commit-file t]
+ "--------"
+ ["Add File" git-add-file t]
+ ["Revert File" git-revert-file t]
+ ["Ignore File" git-ignore-file t]
+ ["Remove File" git-remove-file t]
+ "--------"
+ ["Find File" git-find-file t]
+ ["View File" git-view-file t]
+ ["Diff File" git-diff-file t]
+ ["Interactive Diff File" git-diff-file-idiff t]
+ ["Log" git-log-file t]
+ "--------"
+ ["Quit" git-status-quit t]
+ "--------"
+ ["Show Uptodate" git-toggle-show-uptodate :style toggle :selected git-show-uptodate]
+ ["Show Ignored" git-toggle-show-ignored :style toggle :selected git-show-ignored]
+ ["Show Unknown" git-toggle-show-unknown :style toggle :selected git-show-unknown]))
+
+)
;; git mode should only run in the *git status* buffer
(put 'git-status-mode 'mode-class 'special)
--
1.5.3.6
^ permalink raw reply
* Re: importing bk into git
From: Christoph @ 2007-12-03 20:59 UTC (permalink / raw)
To: David Kettler; +Cc: git
In-Reply-To: <t1o1wa432gc.fsf@ednux512.dsto.defence.gov.au>
On Monday 03 December 2007 04:02:43 you wrote:
> G'day,
>
> I modified that script to convert a number of our repositories in
> February. The version below worked for me at the time, but I'm not
> able to test it now as our BK license has expired. In particular I'm
> not sure if the bk_info.split line is correct; I had a reduced form of
> this line in the file which now looks obviously wrong.
>
> The script is slow; most of the time is in the bk export for every
> revision. There are probably dumb things in there; I don't know
> python and I was just starting with git.
>
> Changes from the version I downloaded from the web include:
> - sundry changes to make it work for me
> - separate committers file to translate user names to full names
> - specify a git dir template
> - copy tags from BK
> - minimal conversion of ignore files
> - increased recursion limit to handle large number of commits
>
> I hope this is useful to someone.
Thanks,
I have made some modifications to get the script working as well. I was able
to convert some simple (really small test repos).I wanted to try to convert
my real big repo (>10k files, >5000 revisions) before mailing it. However, as
running this conversion will probably take more than 24hours I will do so
next weekend.
I will check your script and integrate my changes (if there are any relative
to yours) after that.
best regards
Christoph
^ permalink raw reply
* Re: Many things pushed out to 'master'
From: Junio C Hamano @ 2007-12-03 20:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0712031838450.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Mon, 3 Dec 2007, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> > But I remembered that you requested a mode for signed tags where they
>> > would just be copied. I just realised while implementing "verbatim"
>> > that "ignore" does just that. Maybe we should rename this mode to
>> > "verbatim"?
>> >
>> > And maybe you want to make it the default (even if I think that this
>> > will result in more surprise moments than the current mode which
>> > aborts).
>>
>> I did not hear others agreeing with me, so let's respect the original
>> author's thinking.
>
> But the original author already admitted that the original naming was
> stupid...
Ok, send in updates, please.
^ permalink raw reply
* [PATCH] Make Git accept absolute path names for files within the work tree
From: Robin Rosenberg @ 2007-12-03 20:53 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Anatol Pomozov, git, Linus Torvalds,
Anatol Pomozov
In-Reply-To: <200712030755.37038.robin.rosenberg@dewire.com>
This patch makes it possible to drag files and directories from
a graphical browser and drop them onto a shell and feed them
to common git operations without editing away the path to the
root of the work tree.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
I will not surrender to the fierce competion on this subject. Here is an update
with hopefully correct test cases this time. (Linus. your code did not pass). Like Linus,
this code does not resolve symlinks, but I forgot to state that it is by design. It
solves my problem and happens to solve Anatols problem (actually the same since
passing absolute file names to blame is my most important use case).
-- robin
builtin-blame.c | 4 +-
setup.c | 53 +++++++++++++++++++++++
t/t3904-abspatharg.sh | 112 +++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 166 insertions(+), 3 deletions(-)
create mode 100755 t/t3904-abspatharg.sh
diff --git a/builtin-blame.c b/builtin-blame.c
index c158d31..b905dcf 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -1880,9 +1880,7 @@ static unsigned parse_score(const char *arg)
static const char *add_prefix(const char *prefix, const char *path)
{
- if (!prefix || !prefix[0])
- return path;
- return prefix_path(prefix, strlen(prefix), path);
+ return prefix_path(prefix, prefix ? strlen(prefix) : 0, path);
}
/*
diff --git a/setup.c b/setup.c
index 2c7b5cb..1f0ec79 100644
--- a/setup.c
+++ b/setup.c
@@ -4,9 +4,62 @@
static int inside_git_dir = -1;
static int inside_work_tree = -1;
+static
+const char *strip_work_tree_path(const char *prefix, int len, const char *path)
+{
+ const char *work_tree = get_git_work_tree();
+ int n = strlen(work_tree);
+
+ if (strncmp(path, work_tree, n))
+ return path;
+
+ if (!prefix && !path[n])
+ return path + n;
+
+ if (!prefix) {
+ if (path[n] == '/')
+ return path + n + 1;
+ else
+ if (path[n])
+ return path;
+ else
+ return path + n;
+ }
+
+ if (prefix && !path[n])
+ return path;
+
+ if (strncmp(path + n + 1, prefix, len - 1)) {
+ fprintf(stderr,"prefix mismatch\n");
+ char *np;
+ int i;
+ int d=0;
+ for (i = 0; i < len; ++i)
+ if (prefix[i] == '/')
+ d++;
+ np = xmalloc(strlen(path + n) + d * 3 + 1);
+ for (i=0; i < d * 3; i += 3)
+ strcpy(np + i, "../");
+ strcpy(np + i, path + n + 1);
+ path = np;
+ return np;
+ }
+
+ if (path[len + n] == '/')
+ return path + len + n + 1;
+ else
+ if (path[len + n])
+ return path;
+ else
+ return path + len + n;
+}
+
const char *prefix_path(const char *prefix, int len, const char *path)
{
const char *orig = path;
+ if (is_absolute_path(path))
+ path = strip_work_tree_path(prefix, len, path);
+
for (;;) {
char c;
if (*path != '.')
diff --git a/t/t3904-abspatharg.sh b/t/t3904-abspatharg.sh
new file mode 100755
index 0000000..47f1222
--- /dev/null
+++ b/t/t3904-abspatharg.sh
@@ -0,0 +1,112 @@
+#!/bin/sh
+#
+# Copyright (C) 2007 Robin Rosenberg
+#
+
+test_description='Test absolute filename arguments to various git
+commands. Absolute arguments pointing to a location within the git
+work tree should behave the same as relative arguments. '
+
+. ./test-lib.sh
+
+test_expect_success 'add files using absolute path names' '
+ echo a >afile &&
+ echo b >bfile &&
+ git-add afile &&
+ git-add "$(pwd)/bfile" &&
+ test "afile bfile" = "$(echo $(git ls-files))"
+ mkdir x &&
+ (
+ cd x &&
+ echo c >cfile &&
+ echo d >dfile &&
+ git-add cfile &&
+ git-add "$(pwd)"
+ ) &&
+ test "afile bfile x/cfile x/dfile" = "$(echo $(git ls-files))" &&
+ git ls-files x >f1 &&
+ git ls-files "$(pwd)/x" >f2 &&
+ diff -u f1 f2
+'
+
+test_expect_success 'commit using absolute path names' '
+ git commit -m "foo" &&
+ echo aa >>bfile &&
+ git commit -m "aa" "$(pwd)/bfile"
+'
+
+test_expect_success 'log using absolute path names' '
+ echo bb >>bfile &&
+ git commit -m "bb" $(pwd)/bfile &&
+
+ git log bfile >f1.txt &&
+ git log "$(pwd)/bfile" >f2.txt &&
+ diff -u f1.txt f2.txt
+'
+
+test_expect_success 'blame using absolute path names' '
+ git blame bfile >f1.txt &&
+ git blame "$(pwd)/bfile" >f2.txt &&
+ diff -u f1.txt f2.txt
+'
+
+test_expect_success 'diff using absolute path names' '
+ git diff HEAD HEAD^ -- "$(pwd)/bfile" >f1.txt &&
+ git diff HEAD HEAD^ -- bfile >f2.txt &&
+ diff -u f1.txt f2.txt
+'
+
+test_expect_success 'rm using absolute path names' '
+ git rm "$(pwd)/afile" "$(pwd)/x/cfile" &&
+ test "bfile x/dfile" = "$(echo $(git ls-files))"
+'
+
+test_expect_success 'mv using absolute path names' '
+ git reset --hard &&
+ git mv "$(pwd)/afile" "$(pwd)/dfile" &&
+ test "bfile dfile x/cfile x/dfile" = "$(echo $(git ls-files))" &&
+ git mv "$(pwd)/dfile" afile &&
+ test "afile bfile x/cfile x/dfile" = "$(echo $(git ls-files))"
+'
+
+test_expect_success 'show using absolute path names' '
+ git reset --hard &&
+ git show "$(pwd)/bfile" >f1.txt &&
+ git show bfile >f2.txt &&
+ diff -u f1.txt f2.txt
+'
+
+test_expect_success 'add path in parent directory' '
+ (
+ d1="$(pwd)/x"
+ d2="$(pwd)/x/y"
+ mkdir -p x/y &&
+ echo hello1 >x/fa &&
+ echo hello2 >x/y/fb &&
+ cd x/y &&
+ git add "$d1/fa" "$d2/fb"
+ ) &&
+ test "afile bfile x/cfile x/dfile x/fa x/y/fb" = "$(echo $(git ls-files))"
+'
+
+test_expect_success 'add a parent directory' '
+ (
+ d1="$(pwd)/a"
+ d2="$(pwd)/a/b"
+ d3="$(pwd)/a/b/c"
+ mkdir -p a/b/c
+ echo helloa >a/a1 &&
+ echo hellob >a/b/b1 &&
+ echo helloc >a/b/c/c1 &&
+ cd a/b/c &&
+ git add "$d2"
+ ) &&
+ test "a/b/b1 a/b/c/c1 afile bfile x/cfile x/dfile x/fa x/y/fb" = "$(echo $(git ls-files))"
+'
+
+test_expect_failure 'add a directory outside the work tree' '
+ d1="(cd .. ; pwd)" &&
+ git add "$d1"
+'
+
+test_done
--
1.5.3.5.1.gb2df9
^ permalink raw reply related
* Re: [PATCH] Simplify crud() in ident.c
From: Johannes Schindelin @ 2007-12-03 20:47 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <20071203191143.GB17671@steel.home>
Hi,
On Mon, 3 Dec 2007, Alex Riesen wrote:
> diff --git a/ident.c b/ident.c
> index 9b2a852..dbd0f52 100644
> --- a/ident.c
> +++ b/ident.c
> @@ -113,25 +113,15 @@ static int add_raw(char *buf, size_t size, int offset, const char *str)
>
> static int crud(unsigned char c)
> {
> - static char crud_array[256];
> - static int crud_array_initialized = 0;
> -
> - if (!crud_array_initialized) {
> - int k;
> -
> - for (k = 0; k <= 31; ++k) crud_array[k] = 1;
> - crud_array[' '] = 1;
> - crud_array['.'] = 1;
> - crud_array[','] = 1;
> - crud_array[':'] = 1;
> - crud_array[';'] = 1;
> - crud_array['<'] = 1;
> - crud_array['>'] = 1;
> - crud_array['"'] = 1;
> - crud_array['\''] = 1;
> - crud_array_initialized = 1;
> - }
> - return crud_array[c];
> + return c <= 32 ||
> + c == '.' ||
> + c == ',' ||
> + c == ':' ||
> + c == ';' ||
> + c == '<' ||
> + c == '>' ||
> + c == '"' ||
> + c == '\'';
Or enhance ctype.c.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Simplify crud() in ident.c
From: Jakub Narebski @ 2007-12-03 20:19 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <20071203191143.GB17671@steel.home>
Perhaps simplier, but isn't it slower?
--
Jakub Narebski
^ permalink raw reply
* [PATCH] Simplify crud() in ident.c
From: Alex Riesen @ 2007-12-03 19:11 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Noticed it accidentally.
ident.c | 28 +++++++++-------------------
1 files changed, 9 insertions(+), 19 deletions(-)
diff --git a/ident.c b/ident.c
index 9b2a852..dbd0f52 100644
--- a/ident.c
+++ b/ident.c
@@ -113,25 +113,15 @@ static int add_raw(char *buf, size_t size, int offset, const char *str)
static int crud(unsigned char c)
{
- static char crud_array[256];
- static int crud_array_initialized = 0;
-
- if (!crud_array_initialized) {
- int k;
-
- for (k = 0; k <= 31; ++k) crud_array[k] = 1;
- crud_array[' '] = 1;
- crud_array['.'] = 1;
- crud_array[','] = 1;
- crud_array[':'] = 1;
- crud_array[';'] = 1;
- crud_array['<'] = 1;
- crud_array['>'] = 1;
- crud_array['"'] = 1;
- crud_array['\''] = 1;
- crud_array_initialized = 1;
- }
- return crud_array[c];
+ return c <= 32 ||
+ c == '.' ||
+ c == ',' ||
+ c == ':' ||
+ c == ';' ||
+ c == '<' ||
+ c == '>' ||
+ c == '"' ||
+ c == '\'';
}
/*
--
1.5.3.6.1022.g35305
^ permalink raw reply related
* Adding Git to Better SCM Initiative : Comparison
From: Jakub Narebski @ 2007-12-03 19:57 UTC (permalink / raw)
To: git
In-Reply-To: <200711282339.59938.jnareb@gmail.com>
Below there is email I want to send to Shlomi Fish to have him include
GIT in "Better SCM Initiative : Comparison page".
Please check it and send comments and corrections. TIA.
-- >8 --
I have noticed that your SCM comparison at "Better SCM Initiative" website
http://better-scm.berlios.de/comparison/comparison.html
misses GIT, version control system which is used to manage Linux kernel.
GIT was created by Linus Torvalds in response to the change of BitKeeper
licensing, as a tool to manage Linux kernel sources. It is based on
three years of Linus experience with BitKeeper, and inspired by
Monotone architecture. It was designed for Linux kernel, and is used
by various projects, including X.Org, various Freedesktop projects, WINE,
OLPC (One Laptop Per Child), Samba.
<blurb src="http://git-scm.org">
Git is a popular version control system designed to handle very large projects
with speed and efficiency; it is used mainly for various open source projects,
most notably the Linux kernel.
Git falls in the category of distributed source code management tools, similar to
e.g. GNU Arch or Monotone (or BitKeeper in the proprietary world). Every Git
working directory is a full-fledged repository with full revision tracking
capabilities, not dependent on network access or a central server.
Git is an Open Source project covered by the GNU General Public License v2. It was
originally written by Linus Torvalds and is currently maintained by Junio C
Hamano.
</blurb>
Below there is patch to the sources for the site.
BTW. when asking about updating GIT info for comparison, please CC
git mailing list, git@vger.kernel.org
Index: src/comparison/scm-comparison.xml
===================================================================
--- src/comparison/scm-comparison.xml (revision 290)
+++ src/comparison/scm-comparison.xml (working copy)
@@ -38,6 +38,9 @@ <implementations>
<impl id="darcs">
<name>Darcs</name>
</impl>
+ <impl id="git">
+ <name>Git</name>
+ </impl>
<impl id="mercurial">
<name>Mercurial</name>
</impl>
@@ -106,6 +109,7 @@ <title>Atomic Commits</title>
<s id="svk">Commits are atomic.</s>
<s id="aegis">Commits are atomic.</s>
<s id="bitkeeper">Yes (but need to verify)</s>
+ <s id="git">Yes.</s>
<s id="mercurial">Yes.</s>
<s id="monotone">Yes.</s>
<s id="opencm">Yes. Commits are atomic.</s>
@@ -142,6 +146,13 @@ <title>Files and Directories Moves or Renames</title>
<s id="darcs">Yes. Renames are supported.</s>
<s id="bitkeeper">Yes. Renames are supported.</s>
<s id="aegis">Yes. Renames are supported.</s>
+ <s id="git">
+ Yes (or no depending on interpretation). Git detects
+ renames based on content regardless of whether the
+ committer indicated the fact.
+ You can follow history of file across renames using
+ 'git log -M --follow'.
+ </s>
<s id="mercurial">Yes. Renames are supported.</s>
<s id="monotone">Yes. Renames are supported.</s>
<s id="opencm">Yes. Renames are supported</s>
@@ -214,6 +225,13 @@ <title>File and Directories Copies</title>
Yes. Copies are supported.
</s>
<s id="aegis">No. Copies are not supported.</s>
+ <s id="git">
+ Yes (or no depending on interpretation). Git detects
+ copies (when requested) based on content regardless
+ of whether the committer indicated the fact.
+ You can follow history of file across copies using
+ 'git log -C -C --follow'.
+ </s>
<s id="mercurial">Yes. Copies are supported</s>
<s id="monotone">Yes. Copies are supported</s>
<s id="opencm">No. Copies are not supported.</s>
@@ -267,6 +285,7 @@ <title>Remote Repository Replication</title>
<s id="darcs">Yes.</s>
<s id="bitkeeper">Yes.</s>
<s id="aegis">Yes.</s>
+ <s id="git">Yes.</s>
<s id="mercurial">Yes.</s>
<s id="monotone">Yes.</s>
<s id="opencm">No.</s>
@@ -313,6 +332,7 @@ <title>Propagating Changes to Parent Repositories</title>
<s id="darcs">Yes.</s>
<s id="bitkeeper">Yes.</s>
<s id="aegis">Yes.</s>
+ <s id="git">Yes.</s>
<s id="mercurial">Yes.</s>
<s id="monotone">Yes.</s>
<s id="opencm">No.</s>
@@ -373,6 +393,10 @@ <title>Repository Permissions</title>
<s id="svk">
Same as subversion.
</s>
+ <s id="git">
+ Partial (?). It is possible to lock down repository
+ (access to branches and tags) using hooks.
+ </s>
<s id="mercurial">
Yes. It is possible to lock down repositories,
subdirectories, or files using hooks.
@@ -455,6 +479,13 @@ <title>Changesets' Support</title>
<s id="darcs">
Yes. Changesets are supported.
</s>
+ <s id="git">
+ Yes. Changesets are supported.<br />
+ Actually Git is snapshot based which means Git records
+ the full state in every commit. This means that any two
+ commits can be compared directly very quickly, although the
+ repository is typically browsed as a series of changesets.
+ </s>
<s id="mercurial">
Yes. Changesets are supported.
</s>
@@ -509,6 +540,11 @@ <title>Tracking Line-wise File History</title>
<s id="arch">Not in the command line client, but ViewARCH,
a web-interface for Arch, has it.</s>
<s id="darcs">Yes. (darcs annotate)</s>
+ <s id="git">
+ Yes. (git blame, git gui blame).
+ It can also detect the origin of copied and moved source
+ lines, and can ignore whitespace changes.
+ </s>
<s id="mercurial">Yes. (hg annotate)</s>
<s id="monotone">Yes, as of version 0.19.</s>
<s id="aegis">Yes. aeannotate</s>
@@ -570,6 +606,11 @@ <title>Ability to Work only on One Directory...</title>
whole.
</s>
<s id="aegis">No. All changes are made repository-wide.</s>
+ <s id="git">
+ No. All changes are made repository-wide. However
+ it is possible to commit only selected changes in the
+ working tree rather than everything. You can also
+ use submodules (subproject) support.</s>
<s id="mercurial">
It is possible to commit changes only in a subset of the
tree. There are plans for partial checkouts.
@@ -636,6 +677,10 @@ <title>Tracking Uncommited Changes</title>
Yes, using "darcs whatsnew".
</s>
<s id="aegis">Yes. Using aediff</s>
+ <s id="git">
+ Yes, of course. Using git diff.
+ Note that git uses staging area for commits (index).
+ </s>
<s id="mercurial">Yes. Using hg diff.</s>
<s id="monotone">Yes. In a similar fashion to CVS.</s>
<s id="opencm">Yes. Using cm diff</s>
@@ -681,6 +726,11 @@ <title>Per-File Commit Messages</title>
<s id="darcs">
No.
</s>
+ <s id="git">
+ No. The message applies to the commit as a whole.
+ But you can tag (with description) given contents
+ of a file (blob).
+ </s>
<s id="mercurial">
No.
</s>
@@ -782,6 +832,15 @@ <title>Documentation</title>
and the client contains a help tool that offers
an integrated help system.
</s>
+ <s id="git">
+ Good. There's Git User's Manual, manpages, some
+ technical documentation and some howtos. All
+ documentation is also available
+ <a href="http://www.kernel.org/pub/software/scm/git/docs">online</a>
+ in HTML format; there is additional information (including
+ beginnings of FAQ) on a
+ <a href="http://git-scm.org/gitwiki">git wiki</a>.
+ </s>
<s id="mercurial">
Very good. There's an overview and tutorial on the
web site, and integrated help for every command.
@@ -894,6 +953,16 @@ <title>Ease of Deployment</title>
to install the subversion perl bindings and a few modules
from CPAN.
</s>
+ <s id="git">
+ Very good. Install from RPM or deb on Linux; use
+ msysGit or Cygwin install on Windows. Git requires
+ zlib; also POSIX shell and utilities and Perl for some
+ commands.
+ Installing from sources is easy: Makefile has ready
+ configuration for many OS, you can also use autoconf
+ to generate Makefile configuration. Compiling docs
+ requires asciidoc toolchain, but you can use prebuild.
+ </s>
<s id="mercurial">
Excellent. Binary packages are available for all
popular platforms. Building from source requires
@@ -1006,6 +1075,13 @@ <title>Command Set</title>
but since the model is different most commands are
unique.
</s>
+ <s id="git">
+ Tries to follow CVS conventions, but deviates where there
+ is a different design (following BitKeeper for DVCS).
+ Large command set (~140) is divided into plumbing commands
+ (low lewel, to be used in scripts) and porcelain (high level).
+ It is easy to add new commands as scripts, or as git aliases.
+ </s>
<s id="mercurial">
Tries to follow CVS conventions, but deviates where there
is a different design.
@@ -1106,6 +1182,13 @@ <title>Networking Support</title>
There exists some HTTP-functionality, but it is quite
limited.
</s>
+ <s id="git">
+ Excellent. Uses HTTPS (with WebDAV) or ssh for push
+ (to publish changes to server) and HTTP, FTP, ssh or custom
+ "git" protocol for fetch (read from server). There is also
+ git-bundle for offline transport, and tools to exchange
+ (create and apply) patches via email.
+ </s>
<s id="mercurial">
Excellent. Uses HTTP or ssh. Remote access also
works safely without locks over read-only network
@@ -1203,6 +1286,11 @@ <title>Portability</title>
Very good. Supports many UNIXes, Mac OS X, and Windows,
and is written in a portable language.
</s>
+ <s id="git">
+ Good to very good. Portable across all POSIX systems.
+ There exists Win32 binary using MinGW (msysGit),
+ or you can use binary provided by Cygwin.
+ </s>
<s id="mercurial">
Excellent. Runs on all platforms supported by
Python. Repositories are portable across CPU
@@ -1300,6 +1388,10 @@ <title>Web Interface</title>
is included in the distribution.
</s>
<s id="aegis">Yes.</s>
+ <s id="git">
+ Yes, gitweb is included in git since version 1.4.0.
+ Other web interfaces exists: cgit, wit, git-php
+ </s>
<s id="mercurial">Yes. The web interface is a bundled component.</s>
<s id="monotone">No.</s>
<s id="opencm">No.</s>
@@ -1373,6 +1464,12 @@ <title>Availability of Graphical User-Interfaces.</title>
<s id="aegis">
There is tkaegis.
</s>
+ <s id="git">
+ There is history viewer 'gitk' and commit tool 'git-gui';
+ both in Tcl/Tk. There also exists a number of third-party
+ GUIs, including: qgit (Qt), GitView (GTK+), Giggle (GTK+),
+ tig (ncurses).
+ </s>
<s id="mercurial">
History viewing available with hgit extension;
check-in extension (hgct) makes committing easier.
@@ -1453,6 +1550,7 @@ <title>License</title>
GNU GPL (open-source)
</s>
<s id="svk">Perl License. (open source)</s>
+ <s id="git">GNU GPL v2 (open source)</s>
<s id="mercurial">GNU GPL (open source)</s>
<s id="monotone">GNU GPL (open source)</s>
<s id="opencm">
^ permalink raw reply
* Re: git-svn: .git/svn disk usage
From: David Voit @ 2007-12-03 18:51 UTC (permalink / raw)
To: git
In-Reply-To: <65dd6fd50712022217l5f807f31pf3f00d82c3dccf5c@mail.gmail.com>
Ollie Wild <aaw <at> google.com> writes:
>
> Hi,
>
> I've been using git-svn to mirror the gcc repository at
> svn://gcc.gnu.org/svn/gcc. Recently, I noticed that my .git directory
> is consuming 11GB of disk space. Digging further, I discovered that
> 9.8GB of this is attributable to the .git/svn directory (which
> includes 200 branches and 2,588 tags). Given that my .git/objects
> directory is 652MB, it seems that it ought to be possible to store
> this information in a more compact form.
>
> I'm curious if other developers have run into this issue. If so, are
> there any proposals / plans for improving the storage of git-svn
> metadata?
>
> Thanks,
> Ollie
>
Hi all,
I've seen the same effect, so i tried to reduce the size of the revdb and made a
new format:
First, in the bin files the sha1 are stored as hexvalues not as ascii, this
reduces the a single sha1 from 41 bytes to 20.
Second, only save the non-zero commits, thats what the idx are used for.
A idx file has three 32bit integers per entry.
The first integer represents the first zero svn revision, the second the last
zero revision and the last integer is the position of the next non-zero revision
in the bin.
Example:
Revision 0-373006 are zero revision and 373007 is the first actualy used revision
and 373008-373623 are again zero revisions
the idx has the following content:
0 373006 0
373007 373007 1
and the bin only saves
59037b8043268c9ca0d87ba86519ed0b5358c8a1
eef3f7e25993a46e3c4242aa502d93e909b08c57
The format currently used produce a 373624*41bytes large file.
Used on a git-svn clone here, i get:
The results are:
old:
1,1G hadoop (1004M svn/)
new:
47M hadoop (5,9M svn/)
in detail:
.git/svn/trunk:
old:
-rw-r--r-- 1 david david 24M 2007-11-29 10:26
.rev_db.13f79535-47bb-0310-9956-ffa450edef68
-rw-r--r-- 1 david david 75K 2007-11-29 10:26
.rev_db.7fecf15c-03ad-4724-994c-e980afa7160c
new:
-rw-r--r-- 1 david david 32K 2007-12-03 18:40
revdb-13f79535-47bb-0310-9956-ffa450edef68.bin
-rw-r--r-- 1 david david 18K 2007-12-03 18:40
revdb-13f79535-47bb-0310-9956-ffa450edef68.idx
-rw-r--r-- 1 david david 32K 2007-12-03 18:44
revdb-7fecf15c-03ad-4724-994c-e980afa7160c.bin
-rw-r--r-- 1 david david 2,0K 2007-12-03 18:44
revdb-7fecf15c-03ad-4724-994c-e980afa7160c.idx
Here a example sourcecode to test this idea:
I try to integrate this in git-svn this week.
NOTE: I'm not a perl hacker, so use at your own risk.
Bye David
ps.: I'm not a member of this list please reply directly to me.
migrate.pl:
$uuid = "7fecf15c-03ad-4724-994c-e980afa7160c";
open (NONZERO, '.rev_db.'.$uuid);
open (IDX, '>revdb-'.$uuid.'.idx');
open (BIN, '>revdb-'.$uuid.'.bin');
$first_zero = 0;
$pos = 0;
$rev = 0;
while ($sha1 = <NONZERO>) {
chomp($sha1);
if ($sha1 ne ("0" x 40))
{
print BIN pack("H40", $sha1);
if ($first_zero != $rev)
{
print IDX pack("N N N", $first_zero, ($rev-1), $pos);
}
$first_zero=$rev+1;
$pos++;
}
$rev++;
}
close(BIN);
close(IDX);
close(NONZERO);
parse.pl:
use strict;
use Fcntl;
my(@index, $buf, $i);
my($uuid) = "13f79535-47bb-0310-9956-ffa450edef68";
my($db_path) = "revdb-$uuid.bin";
sysopen(IDX, "revdb-$uuid.idx", O_RDONLY);
while (sysread(IDX, $buf, 12)) {
my($minrev, $maxrev, $pos) = unpack("N N N", $buf);
push @index, [$minrev, $maxrev, $pos];
}
close(IDX);
my($lastindex) = scalar(@index)-1;
my($lastindexpos) = $index[$lastindex][2];
my($lastindexrev) = $index[$lastindex][1];
my @stat = stat $db_path;
($stat[7] % 20) == 0 or die "$db_path inconsistent size: $stat[7]\n";
my ($maxrev) = ($stat[7]/20)-($lastindexpos)+($lastindexrev);
my ($minrev) = $index[0][1]+1;
my($cachestep) = int((scalar(@index))/9);
my(@cache);
for (my($i)=0; $i < scalar(@index); $i += $cachestep) {
push @cache, [$index[$i][0], $i];
}
my($lastsearch) = 0;
sub pos2sha1 {
my($pos) = @_;
sysopen(BINDB, $db_path, O_RDONLY);
sysseek(BINDB, $pos, 0);
my($buf);
sysread(BINDB, $buf, 20);
return unpack ("H40", $buf);
close(BINDB);
}
sub get_sha1 {
my($rev) = @_;
my($i) = 0;
if (($rev <= 0) || ($rev > $maxrev) || $rev <= $index[0][1]) {
return ("0" x 40);
}
if ($rev > $lastindexrev) {
my($pos) = (((($rev-1) - $lastindexrev)+$lastindexpos))*20;
return pos2sha1($pos);
}
if(($rev >= $index[$lastsearch][0] && $rev <= $index[$lastsearch][1]) ||
($rev >= $index[$lastsearch+1][0] && $rev <= $index[$lastsearch+1][1])) {
return ("0" x 40);
}
elsif ($rev > $index[$lastsearch][1] && $rev < $index[$lastsearch+1][0]) {
my($pos) = (($rev-1) - $index[$lastsearch][1] + $index[$lastsearch][2]) * 20;
return pos2sha1($pos);
}
elsif($rev > $index[$lastsearch+1][1] && $rev < $index[$lastsearch+2][0]) {
$lastsearch++;
my($pos) = (($rev-1) - $index[$lastsearch][1] + $index[$lastsearch][2]) * 20;
return pos2sha1($pos);
}
elsif($lastsearch != 0 && $rev > $index[$lastsearch-1][1] && $rev <
$index[$lastsearch][0]) {
$lastsearch--;
my($pos) = (($rev-1) - $index[$lastsearch][1] + $index[$lastsearch][2]) * 20;
return pos2sha1($pos);
}
my($l, $r);
$l = 0;
$r = scalar(@index)-1;
my($lastcache) = scalar(@cache)-1;
for (my($i)=0; $i <= $lastcache; $i++) {
if ($rev >= $cache[$i][0]) {
$l = $cache[$i][1];
}
if ($rev < $cache[$lastcache-$i][0]) {
$r = $cache[$lastcache-$i][1];
}
}
if ($rev <= $index[$l][1]) {
return ("0" x 40);
}
while ($l <= $r) {
$i = int(($l + $r)/2);
if ($rev >= $index[$i][0] && $rev <= $index[$i][1]) {
$lastsearch = $i;
return ("0" x 40);
}
elsif ($rev <= $index[$i][0]) {
$r = $i-1;
}
elsif ($rev >= $index[$i+1][0]) {
$l = $i+1;
}
else {
$lastsearch = $i;
my($pos) = (($rev-1) - $index[$i][1] + $index[$i][2]) * 20;
return pos2sha1($pos);
}
}
return ("0" x 40);
}
for (my($i)=$maxrev; $i >= $minrev; $i--) {
my($sha1) = get_sha1($i);
if ($sha1 ne ("0" x 40)) {
print "$i = $sha1\n";
}
}
^ permalink raw reply
* Re: [PATCH] Set OLD_ICONV on Cygwin.
From: Pascal Obry @ 2007-12-03 18:49 UTC (permalink / raw)
To: Pascal Obry; +Cc: git
In-Reply-To: <1196502562-1052-1-git-send-email-pascal@obry.net>
I pretty well understand that this patch is not very important but since
I got no reply I'm wondering if there is something wrong with it ?
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: [PATCH 1/3] git-help: add -i|--info option to display info page.
From: Pascal Obry @ 2007-12-03 18:45 UTC (permalink / raw)
To: Christian Couder
Cc: Junio C Hamano, git, Theodore Tso, Jakub Narebski, Alex Riesen,
Andreas Ericsson, Matthieu Moy, Eric Wong
In-Reply-To: <200712030653.15694.chriscool@tuxfamily.org>
Christian Couder a écrit :
> So if someone has information about how "woman" or other web or man or info
Ok about woman. Woman is an Emacs mode to display man pages. To send man
page to display in Emacs from the command line one can use emacsclient
for example. I'm already doing this for standard man pages with a bash
function. This function does something like this:
$ emacsclient -e '(woman "git")'
-e is for eval and the argument is the Emacs Lisp string to evaluate.
Let me know if you need more information about woman.
I think it would be nice to be able to define a Git alias. In the string
some %x could be replaced by the man page requested. We could define
multiple replacements:
%n - the man entry (git-commit)
%s - the simple name of the man page (git-commit.1)
%f - the full pathname of the man page (/usr/man/man1/git-commit.1)
%i - the full pathname of the info page
With this I think it should be possible to define and configure any
external tool to display the man page.
This would be more versatile and could be used to display info or man
using whatever tool.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* [PATCH] Allow ':/<oneline-prefix>' syntax to work with save_commit_buffer == 0
From: Johannes Schindelin @ 2007-12-03 18:42 UTC (permalink / raw)
To: Jeff King; +Cc: git, gitster
In-Reply-To: <20071203173022.GA19219@coredump.intra.peff.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Mon, 3 Dec 2007, Jeff King wrote:
> On Mon, Dec 03, 2007 at 10:55:15AM +0000, Johannes Schindelin wrote:
>
> > But then, my patch also works when save_commit_buffer == 0.
> > But I can refactor this into its own patch, since it really is
> > a separate issue.
>
> Agreed.
Here we go.
sha1_name.c | 19 ++++++++++++++++---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index e78b2b9..da1aad1 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -601,24 +601,35 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
{
struct commit_list *list = NULL, *backup = NULL, *l;
int retval = -1;
+ char *temp_commit_buffer = NULL;
if (prefix[0] == '!') {
if (prefix[1] != '!')
die ("Invalid search pattern: %s", prefix);
prefix++;
}
- if (!save_commit_buffer)
- return error("Could not expand oneline-name.");
for_each_ref(handle_one_ref, &list);
for (l = list; l; l = l->next)
commit_list_insert(l->item, &backup);
while (list) {
char *p;
struct commit *commit;
+ enum object_type type;
+ unsigned long size;
commit = pop_most_recent_commit(&list, ONELINE_SEEN);
parse_object(commit->object.sha1);
- if (!commit->buffer || !(p = strstr(commit->buffer, "\n\n")))
+ if (temp_commit_buffer)
+ free(temp_commit_buffer);
+ if (commit->buffer)
+ p = commit->buffer;
+ else {
+ p = read_sha1_file(commit->object.sha1, &type, &size);
+ if (!p)
+ continue;
+ temp_commit_buffer = p;
+ }
+ if (!(p = strstr(p, "\n\n")))
continue;
if (!prefixcmp(p + 2, prefix)) {
hashcpy(sha1, commit->object.sha1);
@@ -626,6 +637,8 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
break;
}
}
+ if (temp_commit_buffer)
+ free(temp_commit_buffer);
free_commit_list(list);
for (l = backup; l; l = l->next)
clear_commit_marks(l->item, ONELINE_SEEN);
--
1.5.3.7.2119.g774e1
^ permalink raw reply related
* Re: Many things pushed out to 'master'
From: Johannes Schindelin @ 2007-12-03 18:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wa3iquj.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 3 Dec 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > But I remembered that you requested a mode for signed tags where they
> > would just be copied. I just realised while implementing "verbatim"
> > that "ignore" does just that. Maybe we should rename this mode to
> > "verbatim"?
> >
> > And maybe you want to make it the default (even if I think that this
> > will result in more surprise moments than the current mode which
> > aborts).
>
> I did not hear others agreeing with me, so let's respect the original
> author's thinking.
But the original author already admitted that the original naming was
stupid...
Ciao,
Dscho
^ permalink raw reply
* Re: Incorrect git-blame result if I use full path to file
From: Linus Torvalds @ 2007-12-03 18:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Anatol Pomozov, git
In-Reply-To: <Pine.LNX.4.64.0712031807410.27959@racer.site>
On Mon, 3 Dec 2007, Johannes Schindelin wrote:
>
> I have the slight suspicion that this could break diff --no-index.
Quite possible.
> And it does not contain any symlink resolution, right?
That's correct, and by design. If you give a path where the absolute part
of the path contains some symlink that eventually gets you to the right
point, you get screwed. That's part of why I'd _prefer_ to do the "die()"
part, so that you get screwed with a nice error message, rather than being
screwed by getting unexpected results!
Linus
^ permalink raw reply
* Re: Incorrect git-blame result if I use full path to file
From: Linus Torvalds @ 2007-12-03 18:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Anatol Pomozov, git
In-Reply-To: <alpine.LFD.0.9999.0712031012280.8458@woody.linux-foundation.org>
On Mon, 3 Dec 2007, Linus Torvalds wrote:
>
> On Mon, 3 Dec 2007, Johannes Schindelin wrote:
> >
> > I have the slight suspicion that this could break diff --no-index.
>
> Quite possible.
Side note: another issue (for the particular case that Anatol hit) is that
this patch obviously only helps for commands that actually use
"get_pathspec()" (usually through doing all the common argument setup
stuff). So "git log" and friends work fine.
HOWEVER. "git blame" has its own argument parsing that doesn't use any of
the common routines, and thus the behaviour that Anatol complained about
isn't fixed at all by the patch.
I think that should be fixed by just making git blame use the standard
arguments (which in turn may involve having to teach the *other* commands
about the "-S <revs-file>" and "-L n,m" forms! I think those are why it
does its own specialized parsing), but obviously git-blame could also be
tought to just do "get_pathspec()" too.
Linus
^ permalink raw reply
* Re: [REGRESSION ?] git-remote "--mirror" option is not integrated in 1.5.3.7
From: Felipe Balbi @ 2007-12-03 18:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vprxnir9t.fsf@gitster.siamese.dyndns.org>
On Dec 3, 2007 2:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Mon, 3 Dec 2007, Felipe Balbi wrote:
> >
> >> I've using git-remote --mirror mode for while right now but I saw it's
> >> not integrated in v.1.5.3.7, is this on purpose? I can still get it if I
> >> compile recent git's head "36863af16e91aebc87696209f4f4780cf4c4059f".
> >
> > AFAICT there are problems with --prune. That might be a reason that it is
> > not in 1.5.3.7 (haven't checked if that's even the case, though).
>
> That is a _NEW_ feature. Maintenance series won't get any new features.
so it'll be only in 1.5.4 ?
ok, thanks Junio
> -
> 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
>
--
Best Regards,
Felipe Balbi
felipebalbi@users.sourceforge.net
^ permalink raw reply
* Re: Many things pushed out to 'master'
From: Junio C Hamano @ 2007-12-03 18:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0712031109380.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> But I remembered that you requested a mode for signed tags where they
> would just be copied. I just realised while implementing "verbatim" that
> "ignore" does just that. Maybe we should rename this mode to "verbatim"?
>
> And maybe you want to make it the default (even if I think that this will
> result in more surprise moments than the current mode which aborts).
I did not hear others agreeing with me, so let's respect the original
author's thinking.
^ permalink raw reply
* Re: [PATCH] Open external merge tool with original file extensions in all three files
From: Junio C Hamano @ 2007-12-03 18:17 UTC (permalink / raw)
To: Pini Reznik; +Cc: git
In-Reply-To: <1196695874-22567-1-git-send-email-pinir@expand.com>
Pini Reznik <pinir@expand.com> writes:
> This required to be able to use syntax highlighting in meld during
> conflicts resolution....
> + extension=`echo $path | awk -F \. '{print $NF}'`
> + BACKUP="$path.BACKUP.$$.${extension}"
> + LOCAL="$path.LOCAL.$$.${extension}"
> + REMOTE="$path.REMOTE.$$.${extension}"
> + BASE="$path.BASE.$$.${extension}"
I had to wonder what would happen in these cases:
* path = "a/b/c/d"
* path = "a/b.c/d"
I also think spawning awk for this is way overkill.
^ permalink raw reply
* Re: [PATCH/RFC] Use regex for :/ matching
From: Junio C Hamano @ 2007-12-03 18:17 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, git
In-Reply-To: <20071203173022.GA19219@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Dec 03, 2007 at 10:55:15AM +0000, Johannes Schindelin wrote:
>
>> Except that I did not support ".." (does yours?), _and_ that my patch is
>> not as nice as yours.
>
> No, I didn't. I'm not sure it is sane, since :/ can contain free-form
> text (and with a regex, .. is not that unlikely). And you can always do
> git-log --not :/foo :/bar
>
>> But then, my patch also works when save_commit_buffer == 0. But I can
>> refactor this into its own patch, since it really is a separate issue.
>
> Agreed.
What I found mildly irritating in the current syntax (and that is the
primary reason why I use it rarely) is that there is no way to tell it
to dig from a particular ref (e.g. "on master branch, find the latest
commit whose title matches this string").
For "git-log", you can do "git log master --grep=string -1" to emulate
this, and it extends to "git log maint..master --grep=string" to limit
the revision ranges and "find all not just latest" very naturally.
Also once we start to talk about supporting "ranges", I suspect the
semantics becomes fuzzier, because ":/" is defined as an extended SHA-1
expression that resolves to a single commit. ":/A..:/B" is probably
unneeded as you can always say "^:/B :/A", but making ":/A" (we need an
extended syntax to differentiate from the singleton case we currently
have) to mean "all the commits that match this pattern" is something
people might be interested to see. Unfortunately, that does not define
a revision range operator but a operator that gives back set of commits
that are not consecutive, primarily good for giving to nothing but "git
show", and again "git log --grep" would emulate it just as well.
So in short:
* I do not think extending it to mean a set of commits (with some
definition of how the set is computed) is a good idea. It can stay
"name one commit that matches this string" without losing usefulness,
and I think it should;
* The definition of the "match" can be tweaked and introducing regexp
might be a good way;
* The definition of the "match" may become more useful if we can limit
which refs to dig from.
^ 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