* Re: [PATCH] format-patch: Add configuration and off switch for --numbered
From: Junio C Hamano @ 2007-11-04 4:40 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: git
In-Reply-To: <20071104033824.GA56097@Hermes.local>
The change looks good. Tests needed.
^ permalink raw reply
* Re: [PATCH] format-patch: Add configuration and off switch for --numbered
From: Brian Gernhardt @ 2007-11-04 4:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejf6vd17.fsf@gitster.siamese.dyndns.org>
On Nov 4, 2007, at 12:40 AM, Junio C Hamano wrote:
> The change looks good. Tests needed.
Thought so. Somebody's not happy. ;-)
I was going to modify the existing tests for --numbered, but
discovered that there were none. Having nothing to start with, I
didn't add.
That said, I'll try to hack something up.
~~ Brian
^ permalink raw reply
* Re: [PATCH 1/2] Added basic color support to git add --interactive
From: Jeff King @ 2007-11-04 4:57 UTC (permalink / raw)
To: Dan Zwell
Cc: Shawn O. Pearce, Wincent Colaiuta, Git Mailing List,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld
In-Reply-To: <20071102224100.71665182@paradox.zwell.net>
On Fri, Nov 02, 2007 at 10:41:00PM -0500, Dan Zwell wrote:
> +sub print_colored {
> + my $color = shift;
> + my $string = join("", @_);
> +
> + if ($use_color) {
> + # Put a color code at the beginning of each line, a reset at the end
> + # color after newlines that are not at the end of the string
> + $string =~ s/(\n+)(.)/$1$color$2/g;
> + # reset before newlines
> + $string =~ s/(\n+)/$normal_color$1/g;
> + # codes at beginning and end (if necessary):
> + $string =~ s/^/$color/;
> + $string =~ s/$/$normal_color/ unless $string =~ /\n$/;
> + }
> + print $string;
> +}
This would probably be a bit more readable by marking the regex as
multline using /m. Something like:
$string =~ s/^/$color/mg;
$string =~ s/.$/$&$normal_color/mg;
which covers both the "start/end of line" and "start/end" of string
cases.
Also, if there is to be pager support for showing diffs, perhaps
print_colored needs to take a filehandle argument (or, even simpler,
change "print_colored(...)" to "print color(...), so the caller can use
print as usual).
-Peff
^ permalink raw reply
* Re: [PATCH] git-fetch: more terse fetch output
From: Jeff King @ 2007-11-04 4:58 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <alpine.LFD.0.9999.0711030101340.21255@xanadu.home>
On Sat, Nov 03, 2007 at 01:32:48AM -0400, Nicolas Pitre wrote:
> This makes the fetch output much more terse and prettier on a 80 column
> display, based on a consensus reached on the mailing list. Here's an
> example output:
Thank you for this; it was at the end of a very long todo list for me.
> Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done.
> Resolving deltas: 100% (4604/4604), done.
> From git://git.kernel.org/pub/scm/git/git
> ! [rejected] html -> origin/html (non fast forward)
> 136e631..f45e867 maint -> origin/maint (fast forward)
> 9850e2e..44dd7e0 man -> origin/man (fast forward)
> 3e4bb08..e3d6d56 master -> origin/master (fast forward)
> fa3665c..536f64a next -> origin/next (fast forward)
> + 4f6d9d6...768326f pu -> origin/pu (forced update)
> * [new branch] todo -> origin/todo
One nice thing about this format is that it works equally well for
"push" (changing "From" to "To" and reversing the order of the
branches). Comments?
-Peff
^ permalink raw reply
* Re: [PATCH] Allow 'git blame rev path' to work on bare repository
From: Junio C Hamano @ 2007-11-04 5:21 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <1194092575-7133-2-git-send-email-mh@glandium.org>
Mike Hommey <mh@glandium.org> writes:
> While 'git blame rev -- path' works, 'git blame rev path' didn't.
>
> Signed-off-by: Mike Hommey <mh@glandium.org>
> ---
> builtin-blame.c | 4 ----
> 1 files changed, 0 insertions(+), 4 deletions(-)
>
> diff --git a/builtin-blame.c b/builtin-blame.c
> index aedc294..141287e 100644
> --- a/builtin-blame.c
> +++ b/builtin-blame.c
> @@ -2294,10 +2294,6 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
> }
> else if (i != argc - 1)
> usage(blame_usage); /* garbage at end */
> -
> - if (!has_path_in_work_tree(path))
> - die("cannot stat path %s: %s",
> - path, strerror(errno));
> }
> }
>
Sorry but a NAK; at least limit the removal of the test only to a bare
repository case.
^ permalink raw reply
* Re: [RFC PATCH] Make gitk use --early-output
From: Linus Torvalds @ 2007-11-04 5:30 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18221.2285.259487.655684@cargo.ozlabs.ibm.com>
On Sun, 4 Nov 2007, Paul Mackerras wrote:
>
> This makes gitk use the --early-output flag on the git log command.
>
> When gitk sees the "Final output:" line from git log, it goes into a
> mode where it basically just checks that it is getting the commits
> again in the same order as before. If they are, well and good; if
> not, it truncates its internal list at the point of difference and
> proceeds to read in the commits in the new order from there on, and
> re-does the graph layout if necessary.
>
> This gives a much more immediate feel to the startup; gitk shows its
> window with the first screenful of commits displayed very quickly this
> way.
Goodie. Seems to work for me. I'll tweak the behaviour of --early-output a
bit more, because right now if things are really cold in the cache, the
"--early-output" logic will often trigger with just a single commit in the
list (because the timeout is so short), but it already seems to work
pretty well.
Linus
^ permalink raw reply
* Re: [PATCH 1/2] Added basic color support to git add --interactive
From: Junio C Hamano @ 2007-11-04 5:36 UTC (permalink / raw)
To: Jeff King
Cc: Dan Zwell, Shawn O. Pearce, Wincent Colaiuta, Git Mailing List,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld
In-Reply-To: <20071104045735.GA12359@segfault.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Nov 02, 2007 at 10:41:00PM -0500, Dan Zwell wrote:
>
>> +sub print_colored {
>> + my $color = shift;
>> + my $string = join("", @_);
>> +
>> + if ($use_color) {
>> + # Put a color code at the beginning of each line, a reset at the end
>> + # color after newlines that are not at the end of the string
>> + $string =~ s/(\n+)(.)/$1$color$2/g;
>> + # reset before newlines
>> + $string =~ s/(\n+)/$normal_color$1/g;
>> + # codes at beginning and end (if necessary):
>> + $string =~ s/^/$color/;
>> + $string =~ s/$/$normal_color/ unless $string =~ /\n$/;
>> + }
>> + print $string;
>> +}
>
> This would probably be a bit more readable by marking the regex as
> multline using /m. Something like:
>
> $string =~ s/^/$color/mg;
> $string =~ s/.$/$&$normal_color/mg;
>
> which covers both the "start/end of line" and "start/end" of string
> cases.
I think you would end up spitting out:
COLOR something RESET LF COLOR RESET LF
instead of:
COLOR something RESET LF LF
when you get "something\n\n" if you did that. Not a big deal,
though, as at this point we would be human I/O bound.
> Also, if there is to be pager support for showing diffs, perhaps
> print_colored needs to take a filehandle argument (or, even simpler,
> change "print_colored(...)" to "print color(...), so the caller can use
> print as usual).
Making it take a FH would be useful. With that, my
proof-of-concept patch to add print_diff_hunk would become:
sub print_diff_hunk {
my ($text) = @_;
my $pager;
if ($use_pager) {
open($pager, "| less");
} else {
$pager = \*STDOUT;
}
for (@$text) {
print_colored $pager $color ...
}
close($pager);
}
^ permalink raw reply
* Re: [REPLACEMENT PATCH 2/2] Add "--early-output" log flag for interactive GUI use
From: Linus Torvalds @ 2007-11-04 5:38 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Marco Costalba, Junio C Hamano, Git Mailing List
In-Reply-To: <18221.14113.498416.396006@cargo.ozlabs.ibm.com>
On Sun, 4 Nov 2007, Paul Mackerras wrote:
>
> Linus Torvalds writes:
>
> > When the full list is generated, there will be a "Final output:" string
> > prepended to it, regardless of whether any early commits were shown or
> > not, so that the consumer can always know the difference between early
> > output and the final list.
>
> How hard would it be to put the total number of commits on that "Final
> output" line? That would be useful for me.
Not hard. I think we basically have it anyway. The reason I didn't do it
is that there's actually multiple numbers: there's the number of primary
("interesting") commits, and then there are the "others", ie the edge
things etc. So the number I'd pick would be the number of actual
interesting commits, no edges, no nothing. Or what?
One other thing I was thinking of was also to perhaps allow multiple
partial early-output things, in case we get just 5 commits in the first
0.1 seconds, then 50 in the first second, and 200 after 2 seconds.. I can
well imagine getting the full list taking a long time over a network
filesystem (somebody mentioned samba), and maybe having just a single
trigger is too inflexible.
Linus
^ permalink raw reply
* Re: [PATCH 1/2] Added basic color support to git add --interactive
From: Jeff King @ 2007-11-04 5:43 UTC (permalink / raw)
To: Junio C Hamano
Cc: Dan Zwell, Shawn O. Pearce, Wincent Colaiuta, Git Mailing List,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld
In-Reply-To: <7v640ivagv.fsf@gitster.siamese.dyndns.org>
On Sat, Nov 03, 2007 at 10:36:00PM -0700, Junio C Hamano wrote:
> I think you would end up spitting out:
>
> COLOR something RESET LF COLOR RESET LF
>
> instead of:
>
> COLOR something RESET LF LF
>
> when you get "something\n\n" if you did that. Not a big deal,
> though, as at this point we would be human I/O bound.
Yes, though I wonder if the former is "more correct" in the sense that
we don't know what the attributes are doing, and maybe it matters for
them to apply to each line, whether it has text or not.
But I don't think it's possible for a blank line to actually do anything
with the attributes we're currently allowing, and we don't have any
plans to allow arbitrary terminal control codes in the color specs, so
it probably doesn't matter.
-Peff
^ permalink raw reply
* [RFC] OSX Mail.app IMAP cache support for git-mailsplit?
From: Michael J. Cohen @ 2007-11-04 5:49 UTC (permalink / raw)
To: Git Mailing List
Trivially, adding support for checking for Messages/ inside the
specified Maildir after cur/ is found not to exist would be enough to
make this work.
Is there interest in a patch for this at all?
-mjc
^ permalink raw reply
* [PATCH 2/1] format-patch: Test --[no-]numbered and format.numbered
From: Brian Gernhardt @ 2007-11-04 5:50 UTC (permalink / raw)
To: git
In-Reply-To: <C9FC46B6-AF2E-4E61-A272-2C46BFA33641@silverinsanity.com>
Just because there wasn't a test for --numbered isn't a good reason
not to test format.numbered. So now we test both.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
---
And here's that something I hacked up. Hmm... that doesn't sound
sanitary.
As a side note, send-email is hard to troubleshoot. Is there a way to
get it to give more than "your setup doesn't work"? And is the pile of
warnings (mostly "Use of uninitialized value") in Term::Readline just a
problem in my setup? I tried to use it instead of mutt and did not
have a happy experience.
t/t4021-format-patch-numbered.sh | 106 ++++++++++++++++++++++++++++++++++++++
1 files changed, 106 insertions(+), 0 deletions(-)
create mode 100755 t/t4021-format-patch-numbered.sh
diff --git a/t/t4021-format-patch-numbered.sh b/t/t4021-format-patch-numbered.sh
new file mode 100755
index 0000000..43d64bb
--- /dev/null
+++ b/t/t4021-format-patch-numbered.sh
@@ -0,0 +1,106 @@
+#!/bin/sh
+#
+# Copyright (c) 2006 Brian C Gernhardt
+#
+
+test_description='Format-patch numbering options'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+
+ echo A > file &&
+ git add file &&
+ git commit -m First &&
+
+ echo B >> file &&
+ git commit -a -m Second &&
+
+ echo C >> file &&
+ git commit -a -m Third
+
+'
+
+# Each of these gets used multiple times.
+
+test_num_no_numbered() {
+ cnt=$(grep "^Subject: \[PATCH\]" $1 | wc -l) &&
+ test $cnt = $2
+}
+
+test_single_no_numbered() {
+ test_num_no_numbered $1 1
+}
+
+test_no_numbered() {
+ test_num_no_numbered $1 2
+}
+
+test_single_numbered() {
+ grep "^Subject: \[PATCH 1/1\]" $1
+}
+
+test_numbered() {
+ grep "^Subject: \[PATCH 1/2\]" $1 &&
+ grep "^Subject: \[PATCH 2/2\]" $1
+}
+
+test_expect_success 'Default: no numbered' '
+
+ git format-patch --stdout HEAD~2 >patch0 &&
+ test_no_numbered patch0
+
+'
+
+test_expect_success 'Use --numbered' '
+
+ git format-patch --numbered --stdout HEAD~2 >patch1 &&
+ test_numbered patch1
+
+'
+
+test_expect_success 'format.numbered = true' '
+
+ git config format.numbered true &&
+ git format-patch --stdout HEAD~2 >patch2 &&
+ test_numbered patch2
+
+'
+
+test_expect_success 'format.numbered && single patch' '
+
+ git format-patch --stdout HEAD^ > patch3 &&
+ test_single_numbered patch3
+
+'
+
+test_expect_success 'format.numbered && --no-numbered' '
+
+ git format-patch --no-numbered --stdout HEAD~2 >patch4 &&
+ test_no_numbered patch4
+
+'
+
+test_expect_success 'format.numbered = auto' '
+
+ git config format.numbered auto
+ git format-patch --stdout HEAD~2 > patch5 &&
+ test_numbered patch5
+
+'
+
+test_expect_success 'format.numbered = auto && single patch' '
+
+ git format-patch --stdout HEAD^ > patch6 &&
+ test_single_no_numbered patch6
+
+'
+
+test_expect_success 'format.numbered = auto && --no-numbered' '
+
+ git format-patch --no-numbered --stdout HEAD~2 > patch7 &&
+ test_no_numbered patch7
+
+'
+
+test_done
--
1.5.3.5.530.gcd7a
^ permalink raw reply related
* Re: [PATCH] Add missing inside_work_tree setting in setup_git_directory_gently
From: Nguyen Thai Ngoc Duy @ 2007-11-04 7:03 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin; +Cc: git
In-Reply-To: <7vir4ivdcr.fsf@gitster.siamese.dyndns.org>
On Sat, Nov 03, 2007 at 09:33:40PM -0700, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
> > When both GIT_DIR and GIT_WORK_TREE are set, and
> > setup_git_directory_gently() changes the current working
> > directory accordingly, it should also set inside_work_tree = 1.
> >
> > Without this, work_tree handling code in setup_git_directory()
> > will be activated. If you stay in root work tree (no prefix),
> > it does not harm. It does if you work from a subdirectory though.
>
> Please add automated test script for this, thanks.
>
Thank you for reminding. I tried to put a test in
t1501-worktree.sh and found out core.worktree can override
inside_work_tree previously set by setup_git_directory_gently(),
activating the worktree code in setup_git_directory() again.
This made me think setup_git_directory_gently() should use
get_git_work_tree() instead. But then git_work_tree_cfg may not be
initialized when get_git_work_tree() is called (starting from
setup_git_directory(), git_work_tree_cfg is initialized in
check_repository_format_version(), which is called _after_
setup_git_directory_gently()).
The interaction between these variables and functions is really beyond
my knowledge. Johannes, can you have a look at this? In theory the
following test should pass:
diff --git a/t/t1501-worktree.sh b/t/t1501-worktree.sh
index 7ee3820..bdb7720 100755
--- a/t/t1501-worktree.sh
+++ b/t/t1501-worktree.sh
@@ -103,6 +103,11 @@ test_expect_success 'repo finds its work tree from work tree, too' '
test sub/dir/tracked = "$(git ls-files)")
'
+test_expect_success 'Try a command from subdir in worktree' '
+ (cd repo.git/work/sub &&
+ GIT_DIR=../.. GIT_WORK_TREE=.. git blame dir/tracked)
+'
+
test_expect_success '_gently() groks relative GIT_DIR & GIT_WORK_TREE' '
cd repo.git/work/sub/dir &&
GIT_DIR=../../.. GIT_WORK_TREE=../.. GIT_PAGER= \
--
Duy
^ permalink raw reply related
* Re: [REPLACEMENT PATCH 2/2] Add "--early-output" log flag for interactive GUI use
From: Paul Mackerras @ 2007-11-04 7:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Marco Costalba, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0711032234030.15101@woody.linux-foundation.org>
Linus Torvalds writes:
> > How hard would it be to put the total number of commits on that "Final
> > output" line? That would be useful for me.
>
> Not hard. I think we basically have it anyway. The reason I didn't do it
> is that there's actually multiple numbers: there's the number of primary
> ("interesting") commits, and then there are the "others", ie the edge
> things etc. So the number I'd pick would be the number of actual
> interesting commits, no edges, no nothing. Or what?
Any of those numbers is probably good enough for a progress bar, but
ideally it would be the total number that you are going to output.
So, with --boundary it would include the edge commits, otherwise it
would just be the interesting commits, I think.
> One other thing I was thinking of was also to perhaps allow multiple
> partial early-output things, in case we get just 5 commits in the first
> 0.1 seconds, then 50 in the first second, and 200 after 2 seconds.. I can
> well imagine getting the full list taking a long time over a network
> filesystem (somebody mentioned samba), and maybe having just a single
> trigger is too inflexible.
In fact gitk won't mind if you give it multiple occurrences of "Final
output", as long as you start from the beginning again after each
occurrence. So having multiple triggers is certainly doable as far as
gitk is concerned. Later on we could optimize that by having git log
match up how many initial commits are the same in both the new list
and the old list, and have it output that rather than the N commits
that were the same as last time.
Paul.
^ permalink raw reply
* Re: [PATCH 2/5] Update git-sh-setup(1) to allow transparent use of git-rev-parse --parseopt
From: Junio C Hamano @ 2007-11-04 7:43 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: gitster, torvalds, git
In-Reply-To: <1194043193-29601-3-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> writes:
> If you set OPTIONS_SPEC, git-sh-setups uses git-rev-parse --parseopt
> automatically.
>
> It also diverts usage to re-exec $0 with the -h option as parse-options.c
> will catch that.
>
> PARSEOPT_OPTS can also be used to pass options git git-rev-parse --parseopt
> mode (like --keep-dashdash).
>
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> ...
> +if test -n "$OPTIONS_SPEC"; then
> + usage() {
> + exec "$0" -h
> + }
> +
> + eval `echo "$OPTIONS_SPEC" | git rev-parse --parseopt $PARSEOPT_OPTS -- "$@" || echo exit $?`
I do not quite get why you use $PARSEOPT_OPTS without setting
any yourself, which means that the users can screw themselves by
having something random and insane in their environments.
Trust me that this kind of backdoor, especially when the
intended uses of the backdoor is not documented well, will be
abused by (perhaps clueless, perhaps curious, perhaps fearless)
users and you will get blamed.
So I'd rather (1) first find out what _you_ wanted to use this
backdoor for, (2) see if that is a useful feature to share with
others instead of keeping that to yourself, and (3) if so to
have a much narrower interface to allow such an option that
cannot be abused.
The same comment applies to the git-clone one which has a
similar invocation of "rev-parse --parseopt" because it cannot
source git-sh-setup.
^ permalink raw reply
* Re: [PATCH 9/5] Migrate git-checkout.sh to use git-rev-parse --parseopt --keep-dashdash
From: Junio C Hamano @ 2007-11-04 7:44 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: gitster, git
In-Reply-To: <1194112219-19968-4-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> writes:
> Also fix some space versus tabs issues.
> ---
> git-checkout.sh | 99 +++++++++++++++++++++++++++----------------------------
> 1 files changed, 49 insertions(+), 50 deletions(-)
>
> diff --git a/git-checkout.sh b/git-checkout.sh
> index 8993920..5424745 100755
> --- a/git-checkout.sh
> +++ b/git-checkout.sh
> @@ -1,6 +1,16 @@
> #!/bin/sh
>
> -USAGE='[-q] [-f] [-b <new_branch>] [-m] [<branch>] [<paths>...]'
> +PARSEOPT_OPTS=--keep-dashdash
> +OPTIONS_SPEC="\
> +git-branch [options] [<branch>] [<paths>...]
> +--
> +b= create a new branch started at <branch>
> +l create the new branchs reflog
> +track tells if the new branch should track the remote branch
> +f proceed even if the index or working tree is not HEAD
> +m performa three-way merge on local modifications if needed
> +q,quiet be quiet
> +"
Ok, so this is how PARSEOPT_OPTS gets used. It is a way for the
command that sources git-sh-setup to tell the parseopt code what
to do. I can agree with this, but then all the other commands
that do not set PARSEOPT_OPTS before sourcing git-sh-setup
should set it to empty string. Otherwise the users can screw
you with their environment variables.
^ permalink raw reply
* Re: [REPLACEMENT PATCH 2/2] Add "--early-output" log flag for interactive GUI use
From: Marco Costalba @ 2007-11-04 7:52 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Linus Torvalds, Junio C Hamano, Git Mailing List
In-Reply-To: <18221.28744.805398.598809@cargo.ozlabs.ibm.com>
On 11/4/07, Paul Mackerras <paulus@samba.org> wrote:
>
> Later on we could optimize that by having git log
> match up how many initial commits are the same in both the new list
> and the old list, and have it output that rather than the N commits
> that were the same as last time.
>
Partial output of commits after "Final output" line would be more
difficult for me to handle instead or restarting form beginning.
One possible optimization along this line instead would be that git
log match up how many initial commits are the same in both the new
list and the old list, and if the old list is whole included
unmodifies in the new simply git log outputs the new commits (not
already present in the old) without the "Final output" line.
Marco
^ permalink raw reply
* [PATCH] fix comment in strbuf.h to use correct name strbuf_avail()
From: Steffen Prohaska @ 2007-11-04 8:02 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, Steffen Prohaska
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
strbuf.h | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
Note, the patch is against Junio's pu.
Steffen
diff --git a/strbuf.h b/strbuf.h
index 9720826..e5cdd1e 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -24,11 +24,11 @@
*
* strbuf_grow(sb, SOME_SIZE);
* // ... here the memory areay starting at sb->buf, and of length
- * // sb_avail(sb) is all yours, and you are sure that sb_avail(sb) is at
- * // least SOME_SIZE
+ * // strbuf_avail(sb) is all yours, and you are sure that strbuf_avail(sb)
+ * // is at least SOME_SIZE
* strbuf_setlen(sb, sb->len + SOME_OTHER_SIZE);
*
- * Of course, SOME_OTHER_SIZE must be smaller or equal to sb_avail(sb).
+ * Of course, SOME_OTHER_SIZE must be smaller or equal to strbuf_avail(sb).
*
* Doing so is safe, though if it has to be done in many places, adding the
* missing API to the strbuf module is the way to go.
--
1.5.3.4.464.ge1bc2
^ permalink raw reply related
* Re: [PATCH] Allow 'git blame rev path' to work on bare repository
From: Mike Hommey @ 2007-11-04 8:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vabpuvb4e.fsf@gitster.siamese.dyndns.org>
On Sat, Nov 03, 2007 at 10:21:53PM -0700, Junio C Hamano wrote:
> Mike Hommey <mh@glandium.org> writes:
>
> > While 'git blame rev -- path' works, 'git blame rev path' didn't.
> >
> > Signed-off-by: Mike Hommey <mh@glandium.org>
> > ---
> > builtin-blame.c | 4 ----
> > 1 files changed, 0 insertions(+), 4 deletions(-)
> >
> > diff --git a/builtin-blame.c b/builtin-blame.c
> > index aedc294..141287e 100644
> > --- a/builtin-blame.c
> > +++ b/builtin-blame.c
> > @@ -2294,10 +2294,6 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
> > }
> > else if (i != argc - 1)
> > usage(blame_usage); /* garbage at end */
> > -
> > - if (!has_path_in_work_tree(path))
> > - die("cannot stat path %s: %s",
> > - path, strerror(errno));
> > }
> > }
> >
>
> Sorry but a NAK; at least limit the removal of the test only to a bare
> repository case.
I fail to see why this test is necessary here. The lack of file in the
working tree is caught in fake_working_tree_commit() anyways.
Mike
^ permalink raw reply
* Re: [PATCH] fix comment in strbuf.h to use correct name strbuf_avail()
From: Pierre Habouzit @ 2007-11-04 8:56 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11941633412454-git-send-email-prohaska@zib.de>
[-- Attachment #1: Type: text/plain, Size: 1394 bytes --]
On Sun, Nov 04, 2007 at 08:02:21AM +0000, Steffen Prohaska wrote:
>
> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Acked-By: Pierre Habouzit <madcoder@debian.org>
> ---
> strbuf.h | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> Note, the patch is against Junio's pu.
>
> Steffen
>
> diff --git a/strbuf.h b/strbuf.h
> index 9720826..e5cdd1e 100644
> --- a/strbuf.h
> +++ b/strbuf.h
> @@ -24,11 +24,11 @@
> *
> * strbuf_grow(sb, SOME_SIZE);
> * // ... here the memory areay starting at sb->buf, and of length
> - * // sb_avail(sb) is all yours, and you are sure that sb_avail(sb) is at
> - * // least SOME_SIZE
> + * // strbuf_avail(sb) is all yours, and you are sure that strbuf_avail(sb)
> + * // is at least SOME_SIZE
> * strbuf_setlen(sb, sb->len + SOME_OTHER_SIZE);
> *
> - * Of course, SOME_OTHER_SIZE must be smaller or equal to sb_avail(sb).
> + * Of course, SOME_OTHER_SIZE must be smaller or equal to strbuf_avail(sb).
> *
> * Doing so is safe, though if it has to be done in many places, adding the
> * missing API to the strbuf module is the way to go.
> --
> 1.5.3.4.464.ge1bc2
>
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 9/5] Migrate git-checkout.sh to use git-rev-parse --parseopt --keep-dashdash
From: Pierre Habouzit @ 2007-11-04 9:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7ikytpz0.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2013 bytes --]
On Sun, Nov 04, 2007 at 07:44:03AM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > Also fix some space versus tabs issues.
> > ---
> > git-checkout.sh | 99 +++++++++++++++++++++++++++----------------------------
> > 1 files changed, 49 insertions(+), 50 deletions(-)
> >
> > diff --git a/git-checkout.sh b/git-checkout.sh
> > index 8993920..5424745 100755
> > --- a/git-checkout.sh
> > +++ b/git-checkout.sh
> > @@ -1,6 +1,16 @@
> > #!/bin/sh
> >
> > -USAGE='[-q] [-f] [-b <new_branch>] [-m] [<branch>] [<paths>...]'
> > +PARSEOPT_OPTS=--keep-dashdash
> > +OPTIONS_SPEC="\
> > +git-branch [options] [<branch>] [<paths>...]
> > +--
> > +b= create a new branch started at <branch>
> > +l create the new branchs reflog
> > +track tells if the new branch should track the remote branch
> > +f proceed even if the index or working tree is not HEAD
> > +m performa three-way merge on local modifications if needed
> > +q,quiet be quiet
> > +"
>
> Ok, so this is how PARSEOPT_OPTS gets used. It is a way for the
> command that sources git-sh-setup to tell the parseopt code what
> to do. I can agree with this, but then all the other commands
> that do not set PARSEOPT_OPTS before sourcing git-sh-setup
> should set it to empty string. Otherwise the users can screw
> you with their environment variables.
yes it's the why, and it's also the why this variable isn't quoted
because it is meant to get options to pass to git-rev-parse --parseopt
In fact it's only used in git-checkout right now. I believe the proper
way to do that is that git-sh-setup does a PARSEOPT_OPTS= and that
git-checkout.sh its sole user overrides it once git-sh-setup is sourced.
I'll send the two updated patches for that.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [UPDATED PATCH 3/5] Update git-sh-setup(1) to allow transparent use of git-rev-parse --parseopt
From: Pierre Habouzit @ 2007-11-04 9:11 UTC (permalink / raw)
To: gitster, Junio C Hamano; +Cc: git, Pierre Habouzit
In-Reply-To: <7vd4uqtpza.fsf@gitster.siamese.dyndns.org>
If you set OPTIONS_SPEC, git-sh-setups uses git-rev-parse --parseopt
automatically.
It also diverts usage to re-exec $0 with the -h option as parse-options.c
will catch that.
PARSEOPT_OPTS can also be used to pass options git git-rev-parse --parseopt
mode (like --keep-dashdash).
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
git-sh-setup.sh | 46 ++++++++++++++++++++++++++++------------------
1 files changed, 28 insertions(+), 18 deletions(-)
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index 86d7d4c..dfff0d1 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -16,9 +16,34 @@ die() {
exit 1
}
-usage() {
- die "Usage: $0 $USAGE"
-}
+if test -n "$OPTIONS_SPEC"; then
+ # override this after . git-sh-setup if you need to use --keep-dashdash
+ PARSEOPT_OPTS=
+ usage() {
+ exec "$0" -h
+ }
+
+ eval `echo "$OPTIONS_SPEC" | git rev-parse --parseopt $PARSEOPT_OPTS -- "$@" || echo exit $?`
+else
+ usage() {
+ die "Usage: $0 $USAGE"
+ }
+
+ if [ -z "$LONG_USAGE" ]
+ then
+ LONG_USAGE="Usage: $0 $USAGE"
+ else
+ LONG_USAGE="Usage: $0 $USAGE
+
+$LONG_USAGE"
+ fi
+
+ case "$1" in
+ -h|--h|--he|--hel|--help)
+ echo "$LONG_USAGE"
+ exit
+ esac
+fi
set_reflog_action() {
if [ -z "${GIT_REFLOG_ACTION:+set}" ]
@@ -91,21 +116,6 @@ get_author_ident_from_commit () {
LANG=C LC_ALL=C sed -ne "$pick_author_script"
}
-if [ -z "$LONG_USAGE" ]
-then
- LONG_USAGE="Usage: $0 $USAGE"
-else
- LONG_USAGE="Usage: $0 $USAGE
-
-$LONG_USAGE"
-fi
-
-case "$1" in
- -h|--h|--he|--hel|--help)
- echo "$LONG_USAGE"
- exit
-esac
-
# Make sure we are in a valid repository of a vintage we understand.
if [ -z "$SUBDIRECTORY_OK" ]
then
--
1.5.3.5.1498.g0a37d
^ permalink raw reply related
* [UPDATED PATCH 5/5] Migrate git-clone to use git-rev-parse --parseopt
From: Pierre Habouzit @ 2007-11-04 9:11 UTC (permalink / raw)
To: gitster, Junio C Hamano; +Cc: git, Pierre Habouzit
In-Reply-To: <1194167515-30378-1-git-send-email-madcoder@debian.org>
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
git-clone.sh | 102 +++++++++++++++++++++++++++++++++-------------------------
1 files changed, 58 insertions(+), 44 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index 0ea3c24..52c5601 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -8,15 +8,36 @@
# See git-sh-setup why.
unset CDPATH
+OPTIONS_SPEC="\
+git-clone [options] <repo> [<dir>]
+--
+n,no-checkout don't create a checkout
+bare create a bare repository
+naked create a bare repository
+l,local to clone from a local repository
+no-hardlinks don't use local hardlinks, always copy
+s,shared setup as a shared repository
+template= path to the template directory
+q,quiet be quiet
+reference= reference repository
+o,origin= use <name> instead of 'origin' to track upstream
+u,upload-pack= path to git-upload-pack on the remote
+depth= create a shallow clone of that depth
+
+use-separate-remote compatibility, do not use
+no-separate-remote compatibility, do not use"
+
die() {
echo >&2 "$@"
exit 1
}
usage() {
- die "Usage: $0 [--template=<template_directory>] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [--origin <name>] [--depth <n>] [-n] <repo> [<dir>]"
+ exec "$0" -h
}
+eval `echo "$OPTIONS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?`
+
get_repo_base() {
(
cd "`/bin/pwd`" &&
@@ -106,64 +127,57 @@ depth=
no_progress=
local_explicitly_asked_for=
test -t 1 || no_progress=--no-progress
-while
- case "$#,$1" in
- 0,*) break ;;
- *,-n|*,--no|*,--no-|*,--no-c|*,--no-ch|*,--no-che|*,--no-chec|\
- *,--no-check|*,--no-checko|*,--no-checkou|*,--no-checkout)
- no_checkout=yes ;;
- *,--na|*,--nak|*,--nake|*,--naked|\
- *,-b|*,--b|*,--ba|*,--bar|*,--bare) bare=yes ;;
- *,-l|*,--l|*,--lo|*,--loc|*,--loca|*,--local)
- local_explicitly_asked_for=yes
- use_local_hardlink=yes ;;
- *,--no-h|*,--no-ha|*,--no-har|*,--no-hard|*,--no-hardl|\
- *,--no-hardli|*,--no-hardlin|*,--no-hardlink|*,--no-hardlinks)
- use_local_hardlink=no ;;
- *,-s|*,--s|*,--sh|*,--sha|*,--shar|*,--share|*,--shared)
- local_shared=yes; ;;
- 1,--template) usage ;;
- *,--template)
+
+while test $# != 0
+do
+ case "$1" in
+ -n|--no-checkout)
+ no_checkout=yes ;;
+ --naked|--bare)
+ bare=yes ;;
+ -l|--local)
+ local_explicitly_asked_for=yes
+ use_local_hardlink=yes
+ ;;
+ --no-hardlinks)
+ use_local_hardlink=no ;;
+ -s|--shared)
+ local_shared=yes ;;
+ --template)
shift; template="--template=$1" ;;
- *,--template=*)
- template="$1" ;;
- *,-q|*,--quiet) quiet=-q ;;
- *,--use-separate-remote) ;;
- *,--no-separate-remote)
+ -q|--quiet)
+ quiet=-q ;;
+ --use-separate-remote|--no-separate-remote)
die "clones are always made with separate-remote layout" ;;
- 1,--reference) usage ;;
- *,--reference)
+ --reference)
shift; reference="$1" ;;
- *,--reference=*)
- reference=`expr "z$1" : 'z--reference=\(.*\)'` ;;
- *,-o|*,--or|*,--ori|*,--orig|*,--origi|*,--origin)
- case "$2" in
+ -o,--origin)
+ shift;
+ case "$1" in
'')
usage ;;
*/*)
- die "'$2' is not suitable for an origin name"
+ die "'$1' is not suitable for an origin name"
esac
- git check-ref-format "heads/$2" ||
- die "'$2' is not suitable for a branch name"
+ git check-ref-format "heads/$1" ||
+ die "'$1' is not suitable for a branch name"
test -z "$origin_override" ||
die "Do not give more than one --origin options."
origin_override=yes
- origin="$2"; shift
+ origin="$1"
;;
- 1,-u|1,--upload-pack) usage ;;
- *,-u|*,--upload-pack)
+ -u|--upload-pack)
shift
upload_pack="--upload-pack=$1" ;;
- *,--upload-pack=*)
- upload_pack=--upload-pack=$(expr "z$1" : 'z-[^=]*=\(.*\)') ;;
- 1,--depth) usage;;
- *,--depth)
+ --depth)
+ shift
+ depth="--depth=$1" ;;
+ --)
shift
- depth="--depth=$1";;
- *,-*) usage ;;
- *) break ;;
+ break ;;
+ *)
+ usage ;;
esac
-do
shift
done
--
1.5.3.5.1498.g0a37d
^ permalink raw reply related
* [UPDATED PATCH 9/5] Migrate git-checkout.sh to use git-rev-parse --parseopt --keep-dashdash
From: Pierre Habouzit @ 2007-11-04 9:11 UTC (permalink / raw)
To: gitster, Junio C Hamano; +Cc: git, Pierre Habouzit
In-Reply-To: <1194167515-30378-2-git-send-email-madcoder@debian.org>
Also fix some space versus tabs issues.
---
git-checkout.sh | 99 +++++++++++++++++++++++++++----------------------------
1 files changed, 49 insertions(+), 50 deletions(-)
diff --git a/git-checkout.sh b/git-checkout.sh
index 8993920..f99f0d5 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -1,8 +1,18 @@
#!/bin/sh
-USAGE='[-q] [-f] [-b <new_branch>] [-m] [<branch>] [<paths>...]'
+OPTIONS_SPEC="\
+git-branch [options] [<branch>] [<paths>...]
+--
+b= create a new branch started at <branch>
+l create the new branchs reflog
+track tells if the new branch should track the remote branch
+f proceed even if the index or working tree is not HEAD
+m performa three-way merge on local modifications if needed
+q,quiet be quiet
+"
SUBDIRECTORY_OK=Sometimes
. git-sh-setup
+PARSEOPT_OPTS=--keep-dashdash
require_work_tree
old_name=HEAD
@@ -20,13 +30,12 @@ quiet=
v=-v
LF='
'
-while [ "$#" != "0" ]; do
- arg="$1"
- shift
- case "$arg" in
- "-b")
- newbranch="$1"
+
+while test $# != 0; do
+ case "$1" in
+ -b)
shift
+ newbranch="$1"
[ -z "$newbranch" ] &&
die "git checkout: -b needs a branch name"
git show-ref --verify --quiet -- "refs/heads/$newbranch" &&
@@ -34,64 +43,54 @@ while [ "$#" != "0" ]; do
git check-ref-format "heads/$newbranch" ||
die "git checkout: we do not like '$newbranch' as a branch name."
;;
- "-l")
+ -l)
newbranch_log=-l
;;
- "--track"|"--no-track")
- track="$arg"
+ --track|--no-track)
+ track="$1"
;;
- "-f")
+ -f)
force=1
;;
-m)
merge=1
;;
- "-q")
+ -q|--quiet)
quiet=1
v=
;;
--)
+ shift
break
;;
- -*)
- usage
- ;;
*)
- if rev=$(git rev-parse --verify "$arg^0" 2>/dev/null)
- then
- if [ -z "$rev" ]; then
- echo "unknown flag $arg"
- exit 1
- fi
- new_name="$arg"
- if git show-ref --verify --quiet -- "refs/heads/$arg"
- then
- rev=$(git rev-parse --verify "refs/heads/$arg^0")
- branch="$arg"
- fi
- new="$rev"
- elif rev=$(git rev-parse --verify "$arg^{tree}" 2>/dev/null)
- then
- # checking out selected paths from a tree-ish.
- new="$rev"
- new_name="$arg^{tree}"
- branch=
- else
- new=
- new_name=
- branch=
- set x "$arg" "$@"
- shift
- fi
- case "$1" in
- --)
- shift ;;
- esac
- break
+ usage
;;
- esac
+ esac
+ shift
done
+arg="$1"
+if rev=$(git rev-parse --verify "$arg^0" 2>/dev/null)
+then
+ [ -z "$rev" ] && die "unknown flag $arg"
+ new_name="$arg"
+ if git show-ref --verify --quiet -- "refs/heads/$arg"
+ then
+ rev=$(git rev-parse --verify "refs/heads/$arg^0")
+ branch="$arg"
+ fi
+ new="$rev"
+ shift
+elif rev=$(git rev-parse --verify "$arg^{tree}" 2>/dev/null)
+then
+ # checking out selected paths from a tree-ish.
+ new="$rev"
+ new_name="$arg^{tree}"
+ shift
+fi
+[ "$1" = "--" ] && shift
+
case "$newbranch,$track" in
,--*)
die "git checkout: --track and --no-track require -b"
@@ -138,8 +137,8 @@ Did you intend to checkout '$@' which can not be resolved as commit?"
git ls-files -- "$@" |
git checkout-index -f -u --stdin
- # Run a post-checkout hook -- the HEAD does not change so the
- # current HEAD is passed in for both args
+ # Run a post-checkout hook -- the HEAD does not change so the
+ # current HEAD is passed in for both args
if test -x "$GIT_DIR"/hooks/post-checkout; then
"$GIT_DIR"/hooks/post-checkout $old $old 0
fi
@@ -294,5 +293,5 @@ fi
# Run a post-checkout hook
if test -x "$GIT_DIR"/hooks/post-checkout; then
- "$GIT_DIR"/hooks/post-checkout $old $new 1
+ "$GIT_DIR"/hooks/post-checkout $old $new 1
fi
--
1.5.3.5.1498.g0a37d
^ permalink raw reply related
* Re: [PATCH 2/5] Update git-sh-setup(1) to allow transparent use of git-rev-parse --parseopt
From: Pierre Habouzit @ 2007-11-04 9:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: torvalds, git
In-Reply-To: <7vd4uqtpza.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 637 bytes --]
On Sun, Nov 04, 2007 at 07:43:53AM +0000, Junio C Hamano wrote:
> Trust me that this kind of backdoor, especially when the
> intended uses of the backdoor is not documented well, will be
> abused by (perhaps clueless, perhaps curious, perhaps fearless)
> users and you will get blamed.
That has been fixed, and documented in git-sh-setup. I renumbered my 3
patches incorrectly though. Those are supposed to supersede patches 2, 4, and 9.
Cheers,
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/5] Update git-sh-setup(1) to allow transparent use of git-rev-parse --parseopt
From: Pierre Habouzit @ 2007-11-04 9:15 UTC (permalink / raw)
To: Junio C Hamano, torvalds, git
In-Reply-To: <20071104091449.GC26269@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 795 bytes --]
On dim, nov 04, 2007 at 09:14:49 +0000, Pierre Habouzit wrote:
> On Sun, Nov 04, 2007 at 07:43:53AM +0000, Junio C Hamano wrote:
> > Trust me that this kind of backdoor, especially when the
> > intended uses of the backdoor is not documented well, will be
> > abused by (perhaps clueless, perhaps curious, perhaps fearless)
> > users and you will get blamed.
>
> That has been fixed, and documented in git-sh-setup. I renumbered my 3
> patches incorrectly though. Those are supposed to supersede patches 2, 4, and 9.
And I'm stupid this obviously doesnt work doh..... sorry, I'll
rethought this.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ 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