* Re: What's cooking in git.git (Nov 2009, #03; Sun, 15)
From: Junio C Hamano @ 2009-11-16 0:26 UTC (permalink / raw)
To: Peter Weseloh; +Cc: git
In-Reply-To: <loom.20091116T003914-635@post.gmane.org>
Peter Weseloh <Peter.Weseloh@gmail.com> writes:
> Does that mean this feature will not make it into 'master' any time soon?
It does not mean anything about this _feature_, but it does mean this
particular _implementation_ is not likely to.
> Having the ability to do sparse checkouts only of the repo sounds like a
> way out.
There is a big difference between (a) a feature is desirable and (b) a
particular implementation of that feature does things right.
The change in the topic is very intrusive and I am hesitant to merge it
into even 'next'. Before considering inclusion to 'next', it does not
matter that much if a topic realizes the feature as it advertises, but it
does matter a lot if it breaks things for people who do not need the
feature. While 'pu' has carried this topic for quite a long time, we
haven't heard much success report from folks like you with the need for
the feature if this implementation worked well for them without breaking
things.
I am not convinced that it won't regress fundamental things for the common
codepaths when "sparse" is not used, and the latest update patch posted to
the list (I do not think I picked it up) seemed very likely to regress
things for the normal codepath.
> Another question: What's the timeline for 1.7.0? I couldn't find anything
> about it neither here nor in the wiki.
When it is ready. But it is likely that there won't be 1.6.7.
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2009, #03; Sun, 15)
From: Daniel Barkalow @ 2009-11-16 0:30 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, git
In-Reply-To: <fabb9a1e0911151532w1ad81a0bi8b13ca59d13cdd79@mail.gmail.com>
On Mon, 16 Nov 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Sun, Nov 15, 2009 at 23:26, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > My initial cleanup for "Allow helper to map private ref names into normal
> > names" was wrong (and the original was supposed to be RFC, and isn't
> > signed-off); I identified the bug he reported in it, but haven't gotten
> > positive test results from him yet, and the series obviously needs a
> > proper version rolled in before it goes into next.
>
> Sorry, I tested, got primary positive results, then wanted to test
> something else and instead of:
> ~/code$ rm -rf test
>
> I did:
> ~/code$ rm -rf git
>
> I hate it when my fingers don't listen. Anyway, I ^C-ed and managed to
> save my worktree, but most of my git/.git was gone already. I'll get
> back to you tomorrow with more results since the time I was going to
> spend on running it through valgrind was wasted trying to recover my
> git repo :P.
Ouch. I remember one day when I got some old code all cleaned up for my
initial commit, and was about to type "cvs import", but decided I should
get rid of the editor cruft first. So I typed "rm *~", but missed one key.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 1/2] git-svn: add (failing) test for SVN 1.5+ merge with intervening commit
From: Toby Allsopp @ 2009-11-16 1:15 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Sam Vilain
In-Reply-To: <20091114214031.GA3732@dcvr.yhbt.net>
[Dropped Junio from CC]
On Sun, Nov 15 2009, Eric Wong wrote:
> Hi Toby,
>
> Thanks for this series, acked and squashed into a single commit to avoid
> unnecessary bisection failures at git://git.bogomips.org/git-svn
Great, thanks. I have no objection to being squashed, but I'm not sure
what you mean by bisection failures. Does a test_expect_failure cause
problems for bisection? It appears to be fairly common to introduce a
failing test case and later fix it, e.g. ce06461 then 751c597. I'd just
like to understand any potential problems with what I did.
Cheers,
Toby.
^ permalink raw reply
* Re: [PATCH 1/2] git-svn: add (failing) test for SVN 1.5+ merge with intervening commit
From: Eric Wong @ 2009-11-16 1:30 UTC (permalink / raw)
To: Toby Allsopp; +Cc: git, Sam Vilain
In-Reply-To: <87k4xrb785.fsf@navakl084.mitacad.com>
Toby Allsopp <Toby.Allsopp@navman.co.nz> wrote:
> [Dropped Junio from CC]
>
> On Sun, Nov 15 2009, Eric Wong wrote:
>
> > Hi Toby,
> >
> > Thanks for this series, acked and squashed into a single commit to avoid
> > unnecessary bisection failures at git://git.bogomips.org/git-svn
>
> Great, thanks. I have no objection to being squashed, but I'm not sure
> what you mean by bisection failures. Does a test_expect_failure cause
> problems for bisection? It appears to be fairly common to introduce a
> failing test case and later fix it, e.g. ce06461 then 751c597. I'd just
> like to understand any potential problems with what I did.
Oops. I didn't even notice you had test_expect_failure there :x
I'll just leave it as is incase somebody has already pulled from me
(other, unrelated patches coming in a few)
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 1/2] http-backend: Fix access beyond end of string.
From: Shawn O. Pearce @ 2009-11-16 1:36 UTC (permalink / raw)
To: Tarmigan Casebolt, Junio C Hamano; +Cc: git
In-Reply-To: <1258233058-2348-1-git-send-email-tarmigan+git@gmail.com>
Tarmigan Casebolt <tarmigan+git@gmail.com> wrote:
> diff --git a/http-backend.c b/http-backend.c
> index f8ea9d7..ab9433d 100644
> --- a/http-backend.c
> +++ b/http-backend.c
> @@ -634,7 +634,7 @@ int main(int argc, char **argv)
> cmd = c;
> cmd_arg = xmalloc(n);
> strncpy(cmd_arg, dir + out[0].rm_so + 1, n);
> - cmd_arg[n] = '\0';
> + cmd_arg[n-1] = '\0';
> dir[out[0].rm_so] = 0;
> break;
Shouldn't this instead be:
diff --git a/http-backend.c b/http-backend.c
index 9021266..16ec635 100644
--- a/http-backend.c
+++ b/http-backend.c
@@ -626,7 +626,7 @@ int main(int argc, char **argv)
}
cmd = c;
- cmd_arg = xmalloc(n);
+ cmd_arg = xmalloc(n + 1);
strncpy(cmd_arg, dir + out[0].rm_so + 1, n);
cmd_arg[n] = '\0';
dir[out[0].rm_so] = 0;
The cmd_arg string was simply allocated too small. Your fix is
terminating the string one character too short which would cause
get_loose_object and get_pack_file to break.
--
Shawn.
^ permalink raw reply related
* Re: [PATCH 2/2] http-backend: Let gcc check the format of more printf-type functions.
From: Shawn O. Pearce @ 2009-11-16 1:39 UTC (permalink / raw)
To: Tarmigan Casebolt; +Cc: git
In-Reply-To: <1258233058-2348-2-git-send-email-tarmigan+git@gmail.com>
Tarmigan Casebolt <tarmigan+git@gmail.com> wrote:
> We already have these checks in many printf-type functions that have
> prototypes which are in header files. Add these same checks to
> static functions in http-backend.c
>
> Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
> ---
>
> Shawn, please consider this patch in addition to the one that you posted
> that actually fixes the bug. With this patch, gcc will warn about that bug.
Yup, it would have caught it, thanks.
Acked-by: Shawn O. Pearce <spearce@spearce.org>
--
Shawn.
^ permalink raw reply
* Re: [PATCH v2] Speed up bash completion loading
From: Shawn O. Pearce @ 2009-11-16 1:55 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Stephen Boyd, Kirill Smelkov, Sverre Rabbelier,
git
In-Reply-To: <20091115102912.GA4100@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> wrote:
> Since git is not used in each and every interactive xterm, it
> seems best to load completion support with cold caches and then
> load each needed thing lazily. This has most of the speed
> advantage of pre-generating everything at build time, without the
> complication of figuring out at build time what commands will be
> available at run time.
>
> Suggested-by: Kirill Smelkov <kirr@mns.spb.ru>
> Cc: Shawn O. Pearce <spearce@spearce.org>
Acked-By: Shawn O. Pearce <spearce@spearce.org>
--
Shawn.
^ permalink raw reply
* [PATCH] gitk: Use git-difftool for external diffs
From: David Aguilar @ 2009-11-16 3:12 UTC (permalink / raw)
To: paulus; +Cc: peff, sam, git, David Aguilar
This teaches gitk about git-difftool. A benefit of this change is
that gitk's external diff now works with read-only repositories.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
The diffstat alone makes me happy.
gitk | 83 ++++--------------------------------------------------------------
1 files changed, 5 insertions(+), 78 deletions(-)
diff --git a/gitk b/gitk
index db5ec54..881ef95 100755
--- a/gitk
+++ b/gitk
@@ -2520,7 +2520,7 @@ proc savestuff {w} {
global viewname viewfiles viewargs viewargscmd viewperm nextviewnum
global cmitmode wrapcomment datetimeformat limitdiffs
global colors uicolor bgcolor fgcolor diffcolors diffcontext selectbgcolor
- global autoselect extdifftool perfile_attrs markbgcolor
+ global autoselect perfile_attrs markbgcolor
global hideremotes
if {$stuffsaved} return
@@ -2554,7 +2554,6 @@ proc savestuff {w} {
puts $f [list set markbgcolor $markbgcolor]
puts $f [list set diffcontext $diffcontext]
puts $f [list set selectbgcolor $selectbgcolor]
- puts $f [list set extdifftool $extdifftool]
puts $f [list set perfile_attrs $perfile_attrs]
puts $f "set geometry(main) [wm geometry .]"
@@ -3204,31 +3203,10 @@ proc save_file_from_commit {filename output what} {
return $output
}
-proc external_diff_get_one_file {diffid filename diffdir} {
- global nullid nullid2 nullfile
- global gitdir
-
- if {$diffid == $nullid} {
- set difffile [file join [file dirname $gitdir] $filename]
- if {[file exists $difffile]} {
- return $difffile
- }
- return $nullfile
- }
- if {$diffid == $nullid2} {
- set difffile [file join $diffdir "\[index\] [file tail $filename]"]
- return [save_file_from_commit :$filename $difffile index]
- }
- set difffile [file join $diffdir "\[$diffid\] [file tail $filename]"]
- return [save_file_from_commit $diffid:$filename $difffile \
- "revision $diffid"]
-}
-
proc external_diff {} {
global nullid nullid2
global flist_menu_file
global diffids
- global extdifftool
if {[llength $diffids] == 1} {
# no reference commit given
@@ -3249,23 +3227,9 @@ proc external_diff {} {
set diffidto [lindex $diffids 1]
}
- # make sure that several diffs wont collide
- set diffdir [gitknewtmpdir]
- if {$diffdir eq {}} return
-
- # gather files to diff
- set difffromfile [external_diff_get_one_file $diffidfrom $flist_menu_file $diffdir]
- set difftofile [external_diff_get_one_file $diffidto $flist_menu_file $diffdir]
-
- if {$difffromfile ne {} && $difftofile ne {}} {
- set cmd [list [shellsplit $extdifftool] $difffromfile $difftofile]
- if {[catch {set fl [open |$cmd r]} err]} {
- file delete -force $diffdir
- error_popup "$extdifftool: [mc "command failed:"] $err"
- } else {
- fconfigure $fl -blocking 0
- filerun $fl [list delete_at_eof $fl $diffdir]
- }
+ set cmd {git difftool --no-prompt $diffidfrom $diffidto -- $flist_menu_file}
+ if {[catch {eval exec $cmd &} err]} {
+ error_popup "[mc "git difftool: command failed:"] $err"
}
}
@@ -3557,19 +3521,6 @@ proc read_line_source {fd inst} {
return 0
}
-# delete $dir when we see eof on $f (presumably because the child has exited)
-proc delete_at_eof {f dir} {
- while {[gets $f line] >= 0} {}
- if {[eof $f]} {
- if {[catch {close $f} err]} {
- error_popup "[mc "External diff viewer failed:"] $err"
- }
- file delete -force $dir
- return 0
- }
- return 1
-}
-
# Functions for adding and removing shell-type quoting
proc shellquote {str} {
@@ -10446,7 +10397,7 @@ proc doprefs {} {
global maxwidth maxgraphpct
global oldprefs prefstop showneartags showlocalchanges
global uicolor bgcolor fgcolor ctext diffcolors selectbgcolor markbgcolor
- global tabstop limitdiffs autoselect extdifftool perfile_attrs
+ global tabstop limitdiffs autoselect perfile_attrs
global hideremotes
set top .gitkprefs
@@ -10498,15 +10449,6 @@ proc doprefs {} {
-font optionfont -variable perfile_attrs
grid x $top.lattr -sticky w
- entry $top.extdifft -textvariable extdifftool
- frame $top.extdifff
- label $top.extdifff.l -text [mc "External diff tool" ] -font optionfont \
- -padx 10
- button $top.extdifff.b -text [mc "Choose..."] -font optionfont \
- -command choose_extdiff
- pack $top.extdifff.l $top.extdifff.b -side left
- grid x $top.extdifff $top.extdifft -sticky w
-
label $top.cdisp -text [mc "Colors: press to choose"]
grid $top.cdisp - -sticky w -pady 10
label $top.ui -padx 40 -relief sunk -background $uicolor
@@ -10566,15 +10508,6 @@ proc doprefs {} {
bind $top <Visibility> "focus $top.buts.ok"
}
-proc choose_extdiff {} {
- global extdifftool
-
- set prog [tk_getOpenFile -title [mc "External diff tool"] -multiple false]
- if {$prog ne {}} {
- set extdifftool $prog
- }
-}
-
proc choosecolor {v vi w x cmd} {
global $v
@@ -11100,12 +11033,6 @@ set datetimeformat "%Y-%m-%d %H:%M:%S"
set autoselect 1
set perfile_attrs 0
-if {[tk windowingsystem] eq "aqua"} {
- set extdifftool "opendiff"
-} else {
- set extdifftool "meld"
-}
-
set colors {green red blue magenta darkgrey brown orange}
set uicolor grey85
set bgcolor white
--
1.6.5.2.180.gc5b3e
^ permalink raw reply related
* Re: Preserving empty directories when doing a git-svn clone/rebase
From: Eric Wong @ 2009-11-16 3:32 UTC (permalink / raw)
To: Steven J. Murdoch; +Cc: git
In-Reply-To: <20091115020605.GE15966@cl.cam.ac.uk>
"Steven J. Murdoch" <git+Steven.Murdoch@cl.cam.ac.uk> wrote:
> When git-svn clones a Subversion repository, any empty directories
> appear to be silently dropped (tested using git version 1.6.5.2 on Mac
> OS X Snow Leopard). This causes problems for using git with software
> projects which depend on Subversion's ability to track empty
> directories. I was recently caught out by this, and it was difficult
> to debug what had gone wrong.
>
> Would it be possible to change git-svn to handle this case? Since git
> doesn't have the ability to track empty directories, probably the
> simplest thing to do would be to automatically add a file (e.g.
> .gitignore) to any empty directories. In theory this could cause
> problems, but I would think the chances of this are far lower than
> with the current behaviour.
Hi Steven,
The problem is that some git-svn using folks have started using
.gitignore to create empty directories on their own. Dealing with
conflicts like this is very problematic because we have to know
if the .gitignore file is supposed to be committed up to SVN or
not (it can be quite expensive to check).
Attempting to deal with mismatching the information stored in the git
index and SVN nearly made my head explode when I tried to implement
svn:externals support via git submodules. Fortunately I stopped in
time, but the mental scars still remain.
> I think this feature would help projects in which some contributors
> are transitioning to git. It would especially be useful to novice
> users of git, who are not aware of the potential problems with having
> empty directories.
>
> I see there was a discussion in 2006:
> http://kerneltrap.org/mailarchive/git/2006/11/29/231586
>
> However, since then I haven't seen any updates. The rationale behind
> the original request still seems applicable today:
>
> "I think there are many potential git users out there who are
> currently svn users. And git-svn is a really nice way to get started,
> but this sort of stumbling block could really turn people off. For
> example, it made me look pretty dumb when I carelessly complained to
> my colleague about his code not working and then it turns out to be
> because my super-advanced scm tool "messed things up"."
> (git-svn and empty directories in svn (was: [PATCH 1.2/2 (fixed)]
> git-svn: fix output reporting from the delta fetcher))
Shortly afterwards, git svn started logging unhandled information into
unhandled.log files. I hoped that somebody would write a parser for
those log files to be able to recreate useful information from them.
Since I'm lazy, forgetful and absent-minded, I never got around to it
until now.
Let me know how it works and if the "git svn mkdirs" command name makes
sense. Thanks for reminding me :)
>From 023675791988373beab921ad3ada115b2c224edf Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Sun, 15 Nov 2009 18:57:16 -0800
Subject: [PATCH] git svn: attempt to create empty dirs on clone+rebase
Attempt to parse unhandled.log files for empty_dir statements
and make a best effort attempt to recreate empty directories
on fresh clones and rebase.
This cannot affect "normal" git commands like "checkout" or
"reset", so users switching between branches in a single working
directory should use the new "git svn mkdirs" command after
switching branches.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Documentation/git-svn.txt | 7 +++
git-svn.perl | 45 ++++++++++++++++
t/t9115-git-svn-dcommit-funky-renames.sh | 4 +-
t/t9146-git-svn-empty-dirs.sh | 85 ++++++++++++++++++++++++++++++
4 files changed, 139 insertions(+), 2 deletions(-)
create mode 100755 t/t9146-git-svn-empty-dirs.sh
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 1812890..db00ed4 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -320,6 +320,13 @@ Any other arguments are passed directly to 'git log'
directories. The output is suitable for appending to
the $GIT_DIR/info/exclude file.
+'mkdirs'::
+ Attempts to recreate empty directories that core git cannot track
+ based on information in $GIT_DIR/svn/<refname>/unhandled.log files.
+ Empty directories are automatically recreated when using
+ "git svn clone" and "git svn rebase", so "mkdirs" is intended
+ for use after commands like "git checkout" or "git reset".
+
'commit-diff'::
Commits the diff of two tree-ish arguments from the
command-line. This command does not rely on being inside an `git svn
diff --git a/git-svn.perl b/git-svn.perl
index ea922ac..ab0a8dd 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -168,6 +168,9 @@ my %cmd = (
'Create a .gitignore per svn:ignore',
{ 'revision|r=i' => \$_revision
} ],
+ 'mkdirs' => [ \&cmd_mkdirs ,
+ "recreate empty directories after a checkout",
+ { 'revision|r=i' => \$_revision } ],
'propget' => [ \&cmd_propget,
'Print the value of a property on a file or directory',
{ 'revision|r=i' => \$_revision } ],
@@ -769,6 +772,7 @@ sub cmd_rebase {
$_fetch_all ? $gs->fetch_all : $gs->fetch;
}
command_noisy(rebase_cmd(), $gs->refname);
+ $gs->mkemptydirs;
}
sub cmd_show_ignore {
@@ -830,6 +834,12 @@ sub cmd_create_ignore {
});
}
+sub cmd_mkdirs {
+ my ($url, $rev, $uuid, $gs) = working_head_info('HEAD');
+ $gs ||= Git::SVN->new;
+ $gs->mkemptydirs($_revision);
+}
+
sub canonicalize_path {
my ($path) = @_;
my $dot_slash_added = 0;
@@ -1196,6 +1206,7 @@ sub post_fetch_checkout {
command_noisy(qw/read-tree -m -u -v HEAD HEAD/);
print STDERR "Checked out HEAD:\n ",
$gs->full_url, " r", $gs->last_rev, "\n";
+ $gs->mkemptydirs($gs->last_rev);
}
sub complete_svn_url {
@@ -2724,6 +2735,34 @@ sub do_fetch {
$self->make_log_entry($rev, \@parents, $ed);
}
+sub mkemptydirs {
+ my ($self, $r) = @_;
+ my %empty_dirs = ();
+
+ open my $fh, '<', "$self->{dir}/unhandled.log" or return;
+ binmode $fh or croak "binmode: $!";
+ while (<$fh>) {
+ if (defined $r && /^r(\d+)$/) {
+ last if $1 > $r;
+ } elsif (/^ \+empty_dir: (.+)$/) {
+ $empty_dirs{$1} = 1;
+ } elsif (/^ \-empty_dir: (.+)$/) {
+ delete $empty_dirs{$1};
+ }
+ }
+ close $fh;
+ foreach my $d (sort keys %empty_dirs) {
+ $d = uri_decode($d);
+ next if -d $d;
+ if (-e _) {
+ warn "$d exists but is not a directory\n";
+ } else {
+ print "creating empty directory: $d\n";
+ mkpath([$d]);
+ }
+ }
+}
+
sub get_untracked {
my ($self, $ed) = @_;
my @out;
@@ -3556,6 +3595,12 @@ sub uri_encode {
$f
}
+sub uri_decode {
+ my ($f) = @_;
+ $f =~ s#%([0-9a-fA-F]{2})#chr(hex($1))#eg;
+ $f
+}
+
sub remove_username {
$_[0] =~ s{^([^:]*://)[^@]+@}{$1};
}
diff --git a/t/t9115-git-svn-dcommit-funky-renames.sh b/t/t9115-git-svn-dcommit-funky-renames.sh
index 9be7aef..767799e 100755
--- a/t/t9115-git-svn-dcommit-funky-renames.sh
+++ b/t/t9115-git-svn-dcommit-funky-renames.sh
@@ -19,7 +19,7 @@ test_expect_success 'init and fetch repository' '
'
test_expect_success 'create file in existing ugly and empty dir' '
- mkdir "#{bad_directory_name}" &&
+ mkdir -p "#{bad_directory_name}" &&
echo hi > "#{bad_directory_name}/ foo" &&
git update-index --add "#{bad_directory_name}/ foo" &&
git commit -m "new file in ugly parent" &&
@@ -37,7 +37,7 @@ test_expect_success 'rename pretty file' '
git update-index --add pretty &&
git commit -m "pretty :x" &&
git svn dcommit &&
- mkdir regular_dir_name &&
+ mkdir -p regular_dir_name &&
git mv pretty regular_dir_name/pretty &&
git commit -m "moved pretty file" &&
git svn dcommit
diff --git a/t/t9146-git-svn-empty-dirs.sh b/t/t9146-git-svn-empty-dirs.sh
new file mode 100755
index 0000000..5948544
--- /dev/null
+++ b/t/t9146-git-svn-empty-dirs.sh
@@ -0,0 +1,85 @@
+#!/bin/sh
+#
+# Copyright (c) 2009 Eric Wong
+
+test_description='git svn creates empty directories'
+. ./lib-git-svn.sh
+
+test_expect_success 'initialize repo' '
+ for i in a b c d d/e d/e/f "weird file name"
+ do
+ svn_cmd mkdir -m "mkdir $i" "$svnrepo"/"$i"
+ done
+'
+
+test_expect_success 'clone' 'git svn clone "$svnrepo" cloned'
+
+test_expect_success 'empty directories exist' '
+ (
+ cd cloned &&
+ for i in a b c d d/e d/e/f "weird file name"
+ do
+ if ! test -d "$i"
+ then
+ echo >&2 "$i does not exist"
+ exit 1
+ fi
+ done
+ )
+'
+
+test_expect_success 'more emptiness' '
+ svn_cmd mkdir -m "bang bang" "$svnrepo"/"! !"
+'
+
+test_expect_success 'git svn rebase creates empty directory' '
+ ( cd cloned && git svn rebase )
+ test -d cloned/"! !"
+'
+
+test_expect_success 'git svn mkdirs recreates empty directories' '
+ (
+ cd cloned &&
+ rm -r * &&
+ git svn mkdirs &&
+ for i in a b c d d/e d/e/f "weird file name" "! !"
+ do
+ if ! test -d "$i"
+ then
+ echo >&2 "$i does not exist"
+ exit 1
+ fi
+ done
+ )
+'
+
+test_expect_success 'git svn mkdirs -r works' '
+ (
+ cd cloned &&
+ rm -r * &&
+ git svn mkdirs -r7 &&
+ for i in a b c d d/e d/e/f "weird file name"
+ do
+ if ! test -d "$i"
+ then
+ echo >&2 "$i does not exist"
+ exit 1
+ fi
+ done
+
+ if test -d "! !"
+ then
+ echo >&2 "$i should not exist"
+ exit 1
+ fi
+
+ git svn mkdirs -r8 &&
+ if ! test -d "! !"
+ then
+ echo >&2 "$i not exist"
+ exit 1
+ fi
+ )
+'
+
+test_done
--
Eric Wong
^ permalink raw reply related
* Re: [PATCH 1/2] http-backend: Fix access beyond end of string.
From: Jeff King @ 2009-11-16 4:55 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Tarmigan Casebolt, Junio C Hamano, git
In-Reply-To: <20091116013654.GX11919@spearce.org>
On Sun, Nov 15, 2009 at 05:36:54PM -0800, Shawn O. Pearce wrote:
> Tarmigan Casebolt <tarmigan+git@gmail.com> wrote:
> > diff --git a/http-backend.c b/http-backend.c
> > index f8ea9d7..ab9433d 100644
> > --- a/http-backend.c
> > +++ b/http-backend.c
> > @@ -634,7 +634,7 @@ int main(int argc, char **argv)
> > cmd = c;
> > cmd_arg = xmalloc(n);
> > strncpy(cmd_arg, dir + out[0].rm_so + 1, n);
> > - cmd_arg[n] = '\0';
> > + cmd_arg[n-1] = '\0';
> > dir[out[0].rm_so] = 0;
> > break;
>
> Shouldn't this instead be:
>
> diff --git a/http-backend.c b/http-backend.c
> index 9021266..16ec635 100644
> --- a/http-backend.c
> +++ b/http-backend.c
> @@ -626,7 +626,7 @@ int main(int argc, char **argv)
> }
>
> cmd = c;
> - cmd_arg = xmalloc(n);
> + cmd_arg = xmalloc(n + 1);
> strncpy(cmd_arg, dir + out[0].rm_so + 1, n);
> cmd_arg[n] = '\0';
> dir[out[0].rm_so] = 0;
>
> The cmd_arg string was simply allocated too small. Your fix is
> terminating the string one character too short which would cause
> get_loose_object and get_pack_file to break.
Actually, from my reading, I think his fix is right, because you trim
the first character during the strncpy (using "out[0].rm_so + 1"). But
it's not clear when you create 'n' that you are dropping that character.
IOW, you are doing:
/* string + '\0' - '/' */
size_t n = out[0].rm_eo - (out[0].rm_so + 1) + 1;
which ends up the same as your n, but means that the NUL goes at
cmd_arg[n-1]. But I didn't actually run it, so if his fix is breaking
things, then both Tarmigan and I are counting wrong. ;)
-Peff
^ permalink raw reply
* Re: [RFC] format-patch: Ensure that author and commit time are not lost
From: Jeff King @ 2009-11-16 5:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Björn Gustavsson, git
In-Reply-To: <7vzl6nfqkx.fsf@alter.siamese.dyndns.org>
On Sun, Nov 15, 2009 at 01:03:42PM -0800, Junio C Hamano wrote:
> I would expect the right solution would be to give send-email an ability
> to either (1) use "Sender:" to record the operator of the MUA while
> keeping "From: " taken from the payload, or (2) duplicate "From: " as an
> in-body header when it sends out.
I agree that send-email is the "right" place for this functionality in
the git toolchain. And indeed, it already does (2):
$ sed -ne '/$author ne $sender/,+1p' git-send-email.perl
if (defined $author and $author ne $sender) {
$message = "From: $author\n\n$message";
That being said, like you, I usually pull the patches directly from
format-patch into my MUA, and I fix up the headers manually. I suspect
there are many others who do the same thing. And each of us has to
either handle this case manually, or write our own munging code
ourselves for our particular setup.
So in that sense, even though format-patch is not the right place, it
may be useful for it to give tool support to people who do not use the
"format-patch to send-email" workflow. In other words, I would be
happy if my short glue shell-script became:
git format-patch --stdout --sender-is-me "$@" >mbox &&
mutt -f mbox
and this just handled the case properly, without me having to parse the
From header of each message and munge the messages in my script.
The arguments against it are:
1. It is polluting format-patch with MUA cruft.
2. --sender-is-me (besides being a terrible name) may not be
expressive enough. You might want --sender=... depending on the
setup of the calling script.
Honestly, though, I send few enough patches made by other people that I
have never found it to be a huge burden. This would be a minor
convenience to have.
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] http-backend: Fix access beyond end of string.
From: Junio C Hamano @ 2009-11-16 6:12 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, Tarmigan Casebolt, Junio C Hamano, git
In-Reply-To: <20091116045532.GC14664@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Nov 15, 2009 at 05:36:54PM -0800, Shawn O. Pearce wrote:
> ...
>> Shouldn't this instead be:
>>
>> diff --git a/http-backend.c b/http-backend.c
>> index 9021266..16ec635 100644
>> --- a/http-backend.c
>> +++ b/http-backend.c
>> @@ -626,7 +626,7 @@ int main(int argc, char **argv)
>> }
>>
>> cmd = c;
>> - cmd_arg = xmalloc(n);
>> + cmd_arg = xmalloc(n + 1);
>> strncpy(cmd_arg, dir + out[0].rm_so + 1, n);
>> cmd_arg[n] = '\0';
>> dir[out[0].rm_so] = 0;
>>
>> The cmd_arg string was simply allocated too small. Your fix is
>> terminating the string one character too short which would cause
>> get_loose_object and get_pack_file to break.
>
> Actually, from my reading, I think his fix is right, because you trim
> the first character during the strncpy (using "out[0].rm_so + 1").
Your regexps all start with leading "/", and rm_so+1 points at the
character after the slash; the intention being that you would copy
the rest of the matched sequence without the leading "/".
So allocating n = rm_eo - rm_so is Ok. It counts the space for
terminating NUL. But copying "up to n bytes" using strncpy(), only to NUL
terminate immediately later, is dubious. You would want to copy only n-1
bytes. I.e.
n = out[0].rm_eo - out[0].rm_so; /* allocation */
... validate and fail invalid method ...
cmd_arg = xmalloc(n);
memcpy(cmd_arg, dir + out[0].rm_so + 1, n-1);
cmd_arg[n-1] = '\0';
^ permalink raw reply
* Re: git am and CRLF files
From: Stefan Naewe @ 2009-11-16 7:33 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <4AFD2A8F.7000806@atlas-elektronik.com>
On 11/13/2009 10:44 AM, Stefan Naewe wrote:
> Hi there.
> I have:
>
> $ git version
> git version 1.6.5.1.1367.gcd48
>
> $ git config --get core.autocrlf
> false
>
> A repository with some UNIX (LF) and some Windows (CRLF) files.
> (and no: I will not change the files. My editors handle CRLF and LF correctly)
>
> My problem:
>
> 'git am' can't handle changes in CRLF files because the patch
> gets converted (by git mailsplit) to contain only LF.
>
> Which is wrong IMHO.
>
> git-am on my msysgit version looks like this (lines: 214++)
>
> <---------->
> split_patches () {
> case "$patch_format" in
> mbox)
> case "$rebasing" in
> '')
> keep_cr= ;;
> ?*)
> keep_cr=--keep-cr ;;
> esac
> git mailsplit -d"$prec" -o"$dotest" -b $keep_cr -- "$@" > "$dotest/last" ||
> clean_abort
> ;;
> <---------->
>
> The '--keep-cr' flags is passed to git mailsplit when git am is in 'rebasing' mode.
> By looking through git-am I found that I can pass "--rebasing" to git am to get my
> patch applied correctly.
> But why is git am behaving that way ?
>
> Puzzled,
>
> Stefan
Does anyone have any comment on this ?
Regards,
Stefan
--
----------------------------------------------------------------
/dev/random says: Microsoft Windows... a virus with mouse support.
^ permalink raw reply
* how to make gitk to use specified history information
From: Liu Yubao @ 2009-11-16 7:51 UTC (permalink / raw)
To: git
Hi,
I want to obtain an outline of history information, for example:
a - b - c - d - h -i -j
\ /
e- f - g
I simplify the graph like this:
a - c - d - j
\ /
g
That's to say, I skip all commits that
* have only one parent, and
* have only one child, and
* its child has only one parent
I checked `git help rev-list` but didn't find this feature, so I
write a little script[1] to parse output of `git rev-list --parents
--full-history --sparse --all` and get the simplified history:
j d
d c g
c a
g a
Now how can I make gitk to show this simpilified history? I have tried
GraphViz but the history information is still so large that GraphViz
crashes.
[1] http://jff.googlecode.com/svn/trunk/utils/git-branch-graph.pl
Best regards,
Liu Yubao
^ permalink raw reply
* Re: how to make gitk to use specified history information
From: Eric Raible @ 2009-11-16 8:08 UTC (permalink / raw)
To: git
In-Reply-To: <4B01049A.5090402@gmail.com>
Liu Yubao <yubao.liu <at> gmail.com> writes:
> I want to obtain an outline of history information, for example:
>
> a - b - c - d - h -i -j
> \ /
> e- f - g
>
> I simplify the graph like this:
>
> a - c - d - j
> \ /
> g
"gitk --simplify-by-decoration"?
- Eric
^ permalink raw reply
* Re: [PATCH] Re: Clarify documentation on the "ours" merge strategy.
From: Peter Krefting @ 2009-11-16 8:20 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nanako Shiraishi, Thomas Rast, Nicolas Sebrecht, Baz,
Git Mailing List, Johannes.Schindelin, B.Steinbrink
In-Reply-To: <7vk4xsqhkv.fsf@alter.siamese.dyndns.org>
Junio C Hamano:
> Even though I still think -Xours/-Xtheirs are nonsense options in the
> context of source code management, I suspect that they might be exactly
> what Peter needs in this situation.
Yes, it sounds like it would. That is not something I would use for source
code management, but it would fit this, and some other use-cases I have,
quite nicely.
I tend to use Git not only for source code management, but also for document
synchronisation across machines which may, or may not, be connected to a
network at any given time. Git is very nice for that sort of work.
> ; otherwise Peter's web site is seriously broken from the security point
> of view and no SCM can fix that),
Indeed. If it that was the case, I deserve whatever problems I get :-)
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH v2] Speed up bash completion loading
From: Stephen Boyd @ 2009-11-16 8:28 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Kirill Smelkov, Sverre Rabbelier, Shawn O. Pearce,
git
In-Reply-To: <20091115102912.GA4100@progeny.tock>
Jonathan Nieder wrote:
>
> Junio C Hamano wrote:
>> Jonathan Nieder <jrnieder@gmail.com> writes:
>>
>>> __git_compute_merge_strategies ()
>>> {
>>> - : ${__git_merge_strategies=$(__git_list_merge_strategies)}
>>> + __git_merge_strategies=$(__git_list_merge_strategies)
>> Wouldn't
>>
>> : ${__gms:=$(command)}
>>
>> run command only until it gives a non-empty string?
>
> Yes. :)
Why not do this for all of the lists and not just the merge strategies?
^ permalink raw reply
* Re: how to make gitk to use specified history information
From: Liu Yubao @ 2009-11-16 8:38 UTC (permalink / raw)
To: Eric Raible; +Cc: git
In-Reply-To: <loom.20091116T090441-576@post.gmane.org>
Eric Raible wrote:
> Liu Yubao <yubao.liu <at> gmail.com> writes:
>
>> I want to obtain an outline of history information, for example:
>>
>> a - b - c - d - h -i -j
>> \ /
>> e- f - g
>>
>> I simplify the graph like this:
>>
>> a - c - d - j
>> \ /
>> g
>
> "gitk --simplify-by-decoration"?
>
> - Eric
>
Thanks, but that gets "a - g - j" which isn't what I want.
(g and j are heads of two branches).
The command sequence to produce that full revision graph:
#!/bin/bash
d=/tmp/t$$
rm -rf $d && mkdir $d && cd $d || exit 1
doit () {
for s in $@; do
echo $s >> a.txt
git add a.txt
git commit -q -m $s
done
}
git init
doit a b c
git checkout -b t HEAD~2
doit e f g
git checkout master
git merge t
doit d h i j
gitk &
^ permalink raw reply
* [PATCH] Document git-svn's first-parent rule
From: Thomas Rast @ 2009-11-16 10:15 UTC (permalink / raw)
To: git; +Cc: Eric Wong
git-svn has the following rule to detect the SVN base for its
operations: find the first git-svn-id line reachable through
first-parent ancestry. IOW,
git log --grep=^git-svn-id: --first-parent -1
Document this, as it is very important when using merges with git-svn.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/git-svn.txt | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 1812890..6da4151 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -735,6 +735,16 @@ merges you've made. Furthermore, if you merge or pull from a git branch
that is a mirror of an SVN branch, 'dcommit' may commit to the wrong
branch.
+If you do merge, note the following rule: 'git svn dcommit' will
+attempt to commit on top of the SVN commit named in
+------------------------------------------------------------------------
+git log --grep=^git-svn-id: --first-parent -1
+------------------------------------------------------------------------
+You 'must' therefore ensure that the most recent commit of the branch
+you want to dcommit to is the 'first' parent of the merge. Chaos will
+ensue otherwise, especially if the first parent is an older commit on
+the same SVN branch.
+
'git clone' does not clone branches under the refs/remotes/ hierarchy or
any 'git svn' metadata, or config. So repositories created and managed with
using 'git svn' should use 'rsync' for cloning, if cloning is to be done
--
1.6.5.2.427.ge73cb
^ permalink raw reply related
* [PATCH] Expand ~ and ~user in core.excludesfile, commit.template
From: Matthieu Moy @ 2009-11-16 10:07 UTC (permalink / raw)
To: git; +Cc: Matthieu Moy, Karl Chen
These config variables are parsed to substitute ~ and ~user with getpw
entries.
user_path() refactored into new function expand_user_path(), to allow
dynamically allocating the return buffer.
Original patch by Karl Chen, modified by Matthieu Moy.
Signed-off-by: Karl Chen <quarl@quarl.org>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
The original thread was here:
http://thread.gmane.org/gmane.comp.version-control.git/93250/focus=94276
My version is made a bit simpler by using strbuf for string
manipulation in expand_user_path.
I'm not sure I fully adressed Junio's point here:
http://thread.gmane.org/gmane.comp.version-control.git/93250/focus=94276
> I do not see any strong reason why the single caller of user_path() has to
> keep using the static allocation. Would it help to reduce the complexity
> of your expand_user_path() implementation, if we fixed the caller along
> the lines of this patch (untested, but just to illustrate the point)?
>
> [...]
> --- i/path.c
> +++ w/path.c
> @@ -221,19 +221,22 @@ char *enter_repo(char *path, int strict)
> if (PATH_MAX <= len)
> return NULL;
> if (path[0] == '~') {
> - if (!user_path(used_path, path, PATH_MAX))
> + char *newpath = expand_user_path(path);
> [...]
I'm just copying back into the static buffer to let enter_repo() do
the same string manipulation as it used to do (concatenate with .git
suffixes). I think the whole enter_repo could use strbuf instead of
static buffers, but that's a different point (probably made easier by
my patch).
Documentation/config.txt | 4 ++-
builtin-commit.c | 2 +-
cache.h | 2 +
config.c | 11 +++++-
path.c | 84 +++++++++++++++++++++++++++------------------
5 files changed, 66 insertions(+), 37 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index d1e2120..c37b51d 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -380,7 +380,8 @@ Common unit suffixes of 'k', 'm', or 'g' are supported.
core.excludesfile::
In addition to '.gitignore' (per-directory) and
'.git/info/exclude', git looks into this file for patterns
- of files which are not meant to be tracked. See
+ of files which are not meant to be tracked. "~" and "~user"
+ are expanded to the user's home directory. See
linkgit:gitignore[5].
core.editor::
@@ -670,6 +671,7 @@ color.ui::
commit.template::
Specify a file to use as the template for new commit messages.
+ "~" and "~user" are expanded to the user's home directory.
diff.autorefreshindex::
When using 'git-diff' to compare with work tree
diff --git a/builtin-commit.c b/builtin-commit.c
index d525b89..09d2840 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -999,7 +999,7 @@ static int git_commit_config(const char *k, const char *v, void *cb)
struct wt_status *s = cb;
if (!strcmp(k, "commit.template"))
- return git_config_string(&template_file, k, v);
+ return git_config_pathname(&template_file, k, v);
return git_status_config(k, v, s);
}
diff --git a/cache.h b/cache.h
index 71a731d..42f7cd8 100644
--- a/cache.h
+++ b/cache.h
@@ -645,6 +645,7 @@ int set_shared_perm(const char *path, int mode);
#define adjust_shared_perm(path) set_shared_perm((path), 0)
int safe_create_leading_directories(char *path);
int safe_create_leading_directories_const(const char *path);
+extern char *expand_user_path(const char *path);
char *enter_repo(char *path, int strict);
static inline int is_absolute_path(const char *path)
{
@@ -903,6 +904,7 @@ extern unsigned long git_config_ulong(const char *, const char *);
extern int git_config_bool_or_int(const char *, const char *, int *);
extern int git_config_bool(const char *, const char *);
extern int git_config_string(const char **, const char *, const char *);
+extern int git_config_pathname(const char **, const char *, const char *);
extern int git_config_set(const char *, const char *);
extern int git_config_set_multivar(const char *, const char *, const char *, int);
extern int git_config_rename_section(const char *, const char *);
diff --git a/config.c b/config.c
index c644061..0fcc4ce 100644
--- a/config.c
+++ b/config.c
@@ -351,6 +351,15 @@ int git_config_string(const char **dest, const char *var, const char *value)
return 0;
}
+int git_config_pathname(const char **dest, const char *var, const char *value) {
+ if (!value)
+ return config_error_nonbool(var);
+ *dest = expand_user_path(value);
+ if (!*dest)
+ die("Failed to expand user dir in: '%s'", value);
+ return 0;
+}
+
static int git_default_core_config(const char *var, const char *value)
{
/* This needs a better name */
@@ -474,7 +483,7 @@ static int git_default_core_config(const char *var, const char *value)
return git_config_string(&editor_program, var, value);
if (!strcmp(var, "core.excludesfile"))
- return git_config_string(&excludes_file, var, value);
+ return git_config_pathname(&excludes_file, var, value);
if (!strcmp(var, "core.whitespace")) {
if (!value)
diff --git a/path.c b/path.c
index 047fdb0..009c8e0 100644
--- a/path.c
+++ b/path.c
@@ -11,6 +11,7 @@
* which is what it's designed for.
*/
#include "cache.h"
+#include "strbuf.h"
static char bad_path[] = "/bad-path/";
@@ -207,43 +208,49 @@ int validate_headref(const char *path)
return -1;
}
-static char *user_path(char *buf, char *path, int sz)
+static inline struct passwd *getpw_str(const char *username, size_t len)
{
+ if (len == 0)
+ return getpwuid(getuid());
+
struct passwd *pw;
- char *slash;
- int len, baselen;
+ char *username_z = xmalloc(len + 1);
+ memcpy(username_z, username, len);
+ username_z[len] = '\0';
+ pw = getpwnam(username_z);
+ free(username_z);
+ return pw;
+}
- if (!path || path[0] != '~')
- return NULL;
- path++;
- slash = strchr(path, '/');
- if (path[0] == '/' || !path[0]) {
- pw = getpwuid(getuid());
- }
- else {
- if (slash) {
- *slash = 0;
- pw = getpwnam(path);
- *slash = '/';
- }
- else
- pw = getpwnam(path);
- }
- if (!pw || !pw->pw_dir || sz <= strlen(pw->pw_dir))
- return NULL;
- baselen = strlen(pw->pw_dir);
- memcpy(buf, pw->pw_dir, baselen);
- while ((1 < baselen) && (buf[baselen-1] == '/')) {
- buf[baselen-1] = 0;
- baselen--;
- }
- if (slash && slash[1]) {
- len = strlen(slash);
- if (sz <= baselen + len)
- return NULL;
- memcpy(buf + baselen, slash, len + 1);
+/*
+ * Return a string with ~ and ~user expanded via getpw*. If buf != NULL, then
+ * it is a newly allocated string. Returns NULL on getpw failure or if
+ * path is NULL.
+ */
+char *expand_user_path(const char *path)
+{
+ struct strbuf user_path = STRBUF_INIT;
+ char * first_slash = strchrnul(path, '/');
+ char * to_copy;
+ if (path == NULL)
+ goto return_null;
+
+ if (path[0] == '~') {
+ const char *username = path + 1;
+ size_t username_len = first_slash - username;
+ struct passwd *pw = getpw_str(username, username_len);
+ if (!pw)
+ goto return_null;
+ strbuf_add(&user_path, pw->pw_dir, strlen(pw->pw_dir));
+ to_copy = first_slash;
+ } else if (path[0] != '/') {
+ to_copy = path;
}
- return buf;
+ strbuf_add(&user_path, to_copy, strlen(to_copy));
+ return strbuf_detach(&user_path, NULL);
+return_null:
+ strbuf_release(&user_path);
+ return NULL;
}
/*
@@ -291,8 +298,17 @@ char *enter_repo(char *path, int strict)
if (PATH_MAX <= len)
return NULL;
if (path[0] == '~') {
- if (!user_path(used_path, path, PATH_MAX))
+ char *newpath = expand_user_path(path);
+ if (!newpath || (PATH_MAX - 10 < strlen(newpath))) {
+ if (path != newpath)
+ free(newpath);
return NULL;
+ }
+ /* Copy back into the static buffer. A pity
+ since newpath was not bounded, but other
+ branches of the if are limited by PATH_MAX
+ anyway. */
+ strcpy(used_path, newpath); free(newpath);
strcpy(validated_path, path);
path = used_path;
}
--
1.6.5.2.152.gbbe9e
^ permalink raw reply related
* Re: git am and CRLF files
From: Nanako Shiraishi @ 2009-11-16 10:50 UTC (permalink / raw)
To: Stefan Naewe; +Cc: git@vger.kernel.org
In-Reply-To: <4B01004A.8060600@atlas-elektronik.com>
Quoting Stefan Naewe <stefan.naewe@atlas-elektronik.com>
>> A repository with some UNIX (LF) and some Windows (CRLF) files.
>> (and no: I will not change the files. My editors handle CRLF and LF correctly)
>>
>> My problem:
>>
>> 'git am' can't handle changes in CRLF files because the patch
>> gets converted (by git mailsplit) to contain only LF.
>
>> Stefan
>
> Does anyone have any comment on this ?
This was done very much on purpose.
The "am" command is meant to handle e-mailed patches, and traditionally
mails are known to clobber carriage returns.
See commit c2ca1d79dbd54b06a05e5d14a897699e59dc9f9f
Allow mailsplit (and hence git-am) to handle mails with CRLF line-endings
It is not that uncommon to have mails with DOS line-ending, notably
Thunderbird and web mailers like Gmail (when saving what they call
"original" message). So modify mailsplit to convert CRLF line-endings to
just LF.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] RFC Allow case insensitive search flag with git-grep for fixed-strings
From: Nanako Shiraishi @ 2009-11-16 10:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Brian Collins, Jeff King
In-Reply-To: <B7C4E16C-B15D-4A7B-873A-B6BD0FDAD8C8@gmail.com>
Quoting Brian Collins <bricollins@gmail.com>
> You will have to excuse me, this is my first patch and I don't know if
> this is the right place to post this. Apologies in advance if I'm in
> the wrong place.
>
> git-grep currently throws an error when you combine the -F and -i
> flags. This isn't in line with how GNU grep handles it. This patch
> allows the simultaneous use of those flags.
Junio, may I ask what happened to this patch?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] Doc: mention the crlf attribute in config autocrlf section
From: Nanako Shiraishi @ 2009-11-16 10:50 UTC (permalink / raw)
To: Matthew Ogilvie; +Cc: git, gitster
In-Reply-To: <1258223700-4009-1-git-send-email-mmogilvi_git@miniinfo.net>
Quoting Matthew Ogilvie <mmogilvi_git@miniinfo.net>
> The reverse reference has long existed, and the autocrlf description
> was actually obsolete and wrong (saying only file content is used),
> not just incomplete.
What do you mean by "reverse reference"?
> Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
> ---
> Documentation/config.txt | 7 ++++---
> 1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index d1e2120..0dc6b12 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -169,9 +169,10 @@ core.autocrlf::
> writing to the filesystem. The variable can be set to
> 'input', in which case the conversion happens only while
> reading from the filesystem but files are written out with
> - `LF` at the end of lines. Currently, which paths to consider
> - "text" (i.e. be subjected to the autocrlf mechanism) is
> - decided purely based on the contents.
> + `LF` at the end of lines. A file is considered
> + "text" (i.e. be subjected to the autocrlf mechanism) based on
> + the file's `crlf` attribute, or if `crlf` is unspecified,
> + based on the file's contents. See linkgit:gitattributes[5].
>
> core.safecrlf::
> If true, makes git check if converting `CRLF` as controlled by
The updated text looks correct to me.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* dirty code to get an outline of commit history with gitk [Was: how to make gitk to use specified history information]
From: Liu Yubao @ 2009-11-16 10:58 UTC (permalink / raw)
To: Eric Raible; +Cc: git, Junio C Hamano
In-Reply-To: <loom.20091116T090441-576@post.gmane.org>
Eric Raible wrote:
> Liu Yubao <yubao.liu <at> gmail.com> writes:
>
>> I want to obtain an outline of history information, for example:
>>
>> a - b - c - d - h -i -j
>> \ /
>> e- f - g
>>
>> I simplify the graph like this:
>>
>> a - c - d - j
>> \ /
>> g
>
> "gitk --simplify-by-decoration"?
>
> - Eric
>
Hi, I get a very dirty implementation, see
http://jff.googlecode.com/svn/trunk/utils/git-branch-graph/
http://jff.googlecode.com/files/gitk-branch-graph--all.png
http://jff.googlecode.com/files/gitk--all.png
These are just to show my expectation, the code is very very very dirty,
I hope git and gitk will add this feature in an elegant and efficent way.
^ permalink raw reply
* Re: Idea for git-touch
From: Luís Sousa @ 2009-11-16 10:57 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4AFD26ED.4020602@op5.se>
Andreas Ericsson wrote:
> On 11/12/2009 06:13 PM, Luís Sousa wrote:
>> Yeah, but still need some copy&paste of message :)
>>
>> Jan Krüger wrote:
>>> On Thu, 12 Nov 2009 17:05:21 +0000, Luís Sousa <llsousa@ualg.pt> wrote:
>>>> But still preserves the original date, isn't it?
>>>
>>> Yes, and I just remembered that, too. Sorry. Today is not my day.
>>>
>>> Even so, you can still save one command:
>>>
>>> git reset --soft HEAD^
>>> git commit
>>>
>
Thanks, but still preserves timestamp.
> Make that
>
> git reset --soft HEAD^ && git commit -C ORIG_HEAD
>
> and you won't have to bother with copy-pasting.
>
^ 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