* 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
* [PATCH] user-manual: add advanced topic "bisecting merges"
From: Steffen Prohaska @ 2007-11-04 9:16 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska
This commits adds a discussion of the challenge of bisecting
merge commits to the user manual. The text is slightly
adapted from a mail by Junio C Hamano <gitster@pobox.com>
to the mailing list
<http://marc.info/?l=git&m=119403257315527&w=2>.
The discussion is added to "Exploring git history" in a
sub-section titled "Advanced topics". The discussion requires
detailed knowledge about git. It is assumed that the reader will
skip advanced topics on first reading. At least the text suggest
to do so.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
Documentation/user-manual.txt | 89 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 89 insertions(+), 0 deletions(-)
Junio's discussion was enlightening for me. I think it's a good idea to add
such discussions to the user manual. It was not obvious to me where to place
the discussion in the current structure of the manual. So I added "Advanced
topics".
Is a sub-section "Advanced topics" a good idea? Any better suggestions?
Steffen
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index d99adc6..480e7c1 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -934,6 +934,95 @@ Figuring out why this works is left as an exercise to the (advanced)
student. The gitlink:git-log[1], gitlink:git-diff-tree[1], and
gitlink:git-hash-object[1] man pages may prove helpful.
+[[history-advanced-topics]]
+Advanced topics
+---------------
+This section covers advanced topics that typically require more
+knowledge about git than the manual presented to this point.
+
+You may want to skip the section at first reading, and come back
+later when you have a better understanding of git.
+
+[[bisect-merges]]
+Why bisecting merge commits can be harder than bisecting linear history
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The following text is based upon an email by Junio C. Hamano to
+the git mailing list
+(link:http://marc.info/?l=git&m=119403257315527&w=2[link:http://marc.info/?l=git&m=119403257315527&w=2]).
+It was slightly adapted for this manual.
+
+Bisecting merges can be challenging due to the complexity of
+changes introduced at a merge. Bisecting through merges is not a
+technical problem. The real problem is what to do when the
+culprit turns out to be a merge commit. How to spot what really
+is wrong, and figure out how to fix. The problem is not for the
+tool but for the human, and it is real.
+
+Imagine this history.
+
+................................................
+ ---Z---o---X---...---o---A---C---D
+ \ /
+ o---o---Y---...---o---B
+................................................
+
+Suppose that on the upper development line, the meaning of one
+of the functions existed at Z was changed at commit X. The
+commits from Z leading to A change both the function's
+implementation and all calling sites that existed at Z, as well
+as new calling sites they add, to be consistent. There is no
+bug at A.
+
+Suppose in the meantime the lower development line somebody
+added a new calling site for that function at commit Y. The
+commits from Z leading to B all assume the old semantics of that
+function and the callers and the callee are consistent with each
+other. There is no bug at B, either.
+
+You merge to create C. There is no textual conflict with this
+three way merge, and the result merges cleanly. You bisect
+this, because you found D is bad and you know Z was good. Your
+bisect will find that C (merge) is broken. Understandably so,
+as at C, the new calling site of the function added by the lower
+branch is not converted to the new semantics, while all the
+other calling sites that already existed at Z would have been
+converted by the merge. The new calling site has semantic
+adjustment needed, but you do not know that yet. You need to
+find out that is the cause of the breakage by looking at the
+merge commit C and the history leading to it.
+
+How would you do that?
+
+Both "git diff A C" and "git diff B C" would be an enormous patch.
+Each of them essentially shows the whole change on each branch
+since they diverged. The developers may have well behaved to
+create good commits that follow the "commit small, commit often,
+commit well contained units" mantra, and each individual commit
+leading from Z to A and from Z to B may be easy to review and
+understand, but looking at these small and easily reviewable
+steps alone would not let you spot the breakage. You need to
+have a global picture of what the upper branch did (and
+among many, one of them is to change the semantics of that
+particular function) and look first at the huge "diff A C"
+(which shows the change the lower branch introduces), and see if
+that huge change is consistent with what have been done between
+Z and A.
+
+If you linearlize the history by rebasing the lower branch on
+top of upper, instead of merging, the bug becomes much easier to
+find and understand. Your history would instead be:
+
+................................................................
+ ---Z---o---X--...---o---A---o---o---Y*--...---o---B*--D*
+................................................................
+
+and there is a single commit Y* between A and B* that introduced
+the new calling site that still uses the old semantics of the
+function, even though that was already modified at X. "git show
+Y*" will be a much smaller patch than "git diff A C" and it is
+much easier to deal with.
+
+
[[Developing-with-git]]
Developing with git
===================
--
1.5.3.4.464.ge1bc2
^ permalink raw reply related
* Re: [PATCH] status&commit: Teach them to show commits of modified submodules.
From: Yin Ping @ 2007-11-04 9:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxzoyz7f.fsf@gitster.siamese.dyndns.org>
On 11/3/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Yin Ping" <pkufranky@gmail.com> writes:
>
> > On 11/3/07, Junio C Hamano <gitster@pobox.com> wrote:
> >> How does this work when you are a toplevel developer and do not
> >> have the submodule cloned and checked out?
> >>
> >> Our code should treat having the submodule directory and not
> >> having it when there is a mode 160000 entry in the index equally
> >> likely. Cloning and checking-out is _not_ the norm (nor the
> >> exception).
> >>
> > When submodule is not cheched out, it is never modified.
>
> How so? Can't you update the index alone?
>
Sorry i have been away and come back just now.
I think it's a rare case that the submodule entry in the index is
different from HEAD when the submodule is not checked out.
This may only happen when git-reset --soft is called. However, it may
be a wrong operation to commit the changed submodule index entry
while the submodule is never checked out.
There is another similar case, 'git pull' update the submodule entry
in both HEAD and index, but the submodule checked out is not updated.
In this case, 'git-log since..until' in the submodule directory will
fail since 'until' commit is not checked out yet. I think it may be
also a user mistake.
In both case, i think the user should be notified about the
inconsistence. My patch handle this by two warning messages as follows
(where $name is module name)
+ cd $name >&/dev/null || { echo " Warning:
fail to chdir to $name" && exit; }
+ if echo "$left$right" | grep 'unknown
revision' >&/dev/null
+ then
+ echo " Warning: $name is not a
repository or dosn't contains commit $headone/$indexone"
+ else
--
franky
^ permalink raw reply
* Re: [PATCH] status&commit: Teach them to show commits of modified submodules.
From: Yin Ping @ 2007-11-04 9:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxzoyz7f.fsf@gitster.siamese.dyndns.org>
sorry, this is the reformated message of last one
On 11/3/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Yin Ping" <pkufranky@gmail.com> writes:
>
> > On 11/3/07, Junio C Hamano <gitster@pobox.com> wrote:
> >> How does this work when you are a toplevel developer and do not
> >> have the submodule cloned and checked out?
> >>
> >> Our code should treat having the submodule directory and not
> >> having it when there is a mode 160000 entry in the index equally
> >> likely. Cloning and checking-out is _not_ the norm (nor the
> >> exception).
> >>
> > When submodule is not cheched out, it is never modified.
>
> How so? Can't you update the index alone?
>
Sorry i have been away and come back just now.
I think it's a rare case that the submodule entry in the index is
different from HEAD when the submodule is not checked out.
This may only happen when git-reset --soft is called. However, it may
be a wrong operation to commit the changed submodule index entry
while the submodule is never checked out.
There is another similar case, 'git pull' update the submodule entry
in both HEAD and index, but the submodule checked out is not updated.
In this case, 'git-log since..until' in the submodule directory will
fail since 'until' commit is not checked out yet. I think it may be
also a user mistake.
In both case, i think the user should be notified about the
inconsistence. My patch handle this by two warning messages as follows
(where $name is module name)
+ cd $name >&/dev/null || { echo " Warning:
fail to chdir to $name" && exit; }
+ if echo "$left$right" | grep 'unknown
revision' >&/dev/null
+ then
+ echo " Warning: $name is not a
repository or doesn't contains commit $headone/$indexone"
+ else
--
franky
^ permalink raw reply
* [PATCH] git-reset: add -q option to operate quietly
From: Gerrit Pape @ 2007-11-04 9:37 UTC (permalink / raw)
To: git, Junio C Hamano
Many git commands have a -q option to suppress output to stdout, let's
have it for git-reset too.
This was asked for by Joey Hess through
http://bugs.debian.org/444933
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
Documentation/git-reset.txt | 7 +++++--
builtin-reset.c | 14 ++++++++++----
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 87afa6f..050e4ea 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -8,8 +8,8 @@ git-reset - Reset current HEAD to the specified state
SYNOPSIS
--------
[verse]
-'git-reset' [--mixed | --soft | --hard] [<commit>]
-'git-reset' [--mixed] <commit> [--] <paths>...
+'git-reset' [--mixed | --soft | --hard] [-q] [<commit>]
+'git-reset' [--mixed] [-q] <commit> [--] <paths>...
DESCRIPTION
-----------
@@ -45,6 +45,9 @@ OPTIONS
switched to. Any changes to tracked files in the working tree
since <commit> are lost.
+-q::
+ Be quiet, only report errors.
+
<commit>::
Commit to make the current HEAD.
diff --git a/builtin-reset.c b/builtin-reset.c
index e1dc31e..dd301df 100644
--- a/builtin-reset.c
+++ b/builtin-reset.c
@@ -18,7 +18,7 @@
#include "tree.h"
static const char builtin_reset_usage[] =
-"git-reset [--mixed | --soft | --hard] [<commit-ish>] [ [--] <paths>...]";
+"git-reset [--mixed | --soft | --hard] [-q] [<commit-ish>] [ [--] <paths>...]";
static char *args_to_str(const char **argv)
{
@@ -173,7 +173,7 @@ static const char *reset_type_names[] = { "mixed", "soft", "hard", NULL };
int cmd_reset(int argc, const char **argv, const char *prefix)
{
- int i = 1, reset_type = NONE, update_ref_status = 0;
+ int i = 1, reset_type = NONE, update_ref_status = 0, quiet = 0;
const char *rev = "HEAD";
unsigned char sha1[20], *orig = NULL, sha1_orig[20],
*old_orig = NULL, sha1_old_orig[20];
@@ -185,7 +185,7 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
reflog_action = args_to_str(argv);
setenv("GIT_REFLOG_ACTION", reflog_action, 0);
- if (i < argc) {
+ while (i < argc) {
if (!strcmp(argv[i], "--mixed")) {
reset_type = MIXED;
i++;
@@ -198,6 +198,12 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
reset_type = HARD;
i++;
}
+ else if (!strcmp(argv[i], "-q")) {
+ quiet = 1;
+ i++;
+ }
+ else
+ break;
}
if (i < argc && argv[i][0] != '-')
@@ -258,7 +264,7 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
switch (reset_type) {
case HARD:
- if (!update_ref_status)
+ if (!update_ref_status && !quiet)
print_new_head_line(commit);
break;
case SOFT: /* Nothing else to do. */
--
1.5.3.5
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Jakub Narebski @ 2007-11-04 9:43 UTC (permalink / raw)
To: git
In-Reply-To: <7vr6j6ve90.fsf@gitster.siamese.dyndns.org>
[Cc: Junio C Hamano <gitster@pobox.com>, git @vger.kernel.org]
Junio C Hamano wrote:
> * jn/gitweb (Sat Nov 3 00:41:20 2007 +0100) 9 commits
Now that I have sned those patches ;-) I have a few doubts about them
> + gitweb: Use config file for repository description and URLs
> + gitweb: Read repo config using 'git config -z -l'
I'd like some comments on that series, preferably by someone better
with Perl than me, but I think this is a good change performance wise.
> + gitweb: Add tests for overriding gitweb config with repo config
More tests is always good.
> + gitweb: Use href(-replay=>1, action=>...) to generate alternate
> views
> + gitweb: Use href(-replay=>1, page=>...) to generate pagination
> links
> + gitweb: Easier adding/changing parameters to current URL
Now I'm not so sure about this, because it changes semantics of "next page"
and alternate view links: after this series they count from current
version, not from the displayed version.
But perhaps those doubts are unnecessary...
> + gitweb: Remove CGI::Carp::set_programname() call from t9500 gitweb
> test
This removes unnecessary code, which can cause mysterious errors.
> + gitweb: Add 'status_str' to parse_difftree_raw_line output
> + gitweb: Always set 'from_file' and 'to_file' in
> parse_difftree_raw_line
This simplifies gitweb code, and I think there aren't any issues with those
patches.
> Will push these out to 'master' over the weekend.
Thanks.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] git-format-patch: Number patches when there are more than one
From: Andreas Ericsson @ 2007-11-04 9:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Mike Hommey, git, spearce
In-Reply-To: <Pine.LNX.4.64.0711040023000.4362@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Sat, 3 Nov 2007, Andreas Ericsson wrote:
>
>> Every piece of DWIM can be translated as "do what I didn't say". If you
>> had to say it, it wouldn't be DWIM after all.
>
> At some point, though, it becomes a "Do what _I_ (and nobody else does, or
> at least what a substantial part of the rest of the world did not) mean",
> and that point is reached here and now.
>
Every piece of dwimmery is suggested by someone and usually backed by a few,
so it's likely wanted by many. Your ultra-conserative "works for *me*, so
shut up and stop trying to change things" means git really has to be flawless.
For you, that is. For others, there are still things to improve. I'd
appreciate if you could losen the "MY playpen" a little though, as it takes
an awful lot of energy from the constructive discussions.
> Wow. I did not think I had to explain _that_.
>
Dito.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] status&commit: Teach them to show commits of modified submodules.
From: Yin Ping @ 2007-11-04 9:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <46dff0320711040125v111c75davb49e9822537f4b19@mail.gmail.com>
On 11/4/07, Yin Ping <pkufranky@gmail.com> wrote:
> sorry, this is the reformated message of last one
Oh, I'm beaten my the mail client (gmail client will automatically
wrap line to width 80, which is not suitable for patch). Just ignore
my last messge and bear the wrapped patch line. Sorry for the
inconvience again
--
franky
^ permalink raw reply
* Re: [PATCH] git-fetch: more terse fetch output
From: Steffen Prohaska @ 2007-11-04 9:56 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Mike Hommey, Linus Torvalds, Junio C Hamano, git, Shawn O. Pearce,
Jeff King
In-Reply-To: <alpine.LFD.0.9999.0711031645350.21255@xanadu.home>
On Nov 3, 2007, at 9:50 PM, Nicolas Pitre wrote:
> On Sat, 3 Nov 2007, Mike Hommey wrote:
>
>> On Sat, Nov 03, 2007 at 04:30:27PM -0400, Nicolas Pitre wrote:
>>> On Sat, 3 Nov 2007, Linus Torvalds wrote:
>>>
>>>>
>>>>
>>>> On Sat, 3 Nov 2007, Nicolas Pitre wrote:
>>>>>
>>>>> Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done.
>>>>
>>>> I mostly like this, but can we please just use "MB/kB" instead of
>>>> "MiB/KiB"?
>>>>
>>>> I hope it was some kind of joke on crazy EU bureaucrats that
>>>> just wasn't
>>>> caught in time.
>>>
>>> I don't care either ways. In fact my own preference is for MB/
>>> kB, but
>>> if I had used that first I'm sure someone else would have asked
>>> for the
>>> purist notations.
>>
>> As far as you don't claim 1MB is 1024KB, it's okay.
>
> [ heh, I knew someone would say something ]
>
> Yes, to me, 1MB is 1024 KB. Always been, until those idiotic hard
> disk
> manufacturers decided to redefine the common interpretation of what
> everyone else used to consider what a MB is just to boost their
> marketing claims.
I believe it doesn't matter what prefix we use for a
_progress indicator_, as long as we use the same prefix for
the the amount already transferred and the bandwidth. A precise
language doesn't matter here.
Here is a short excerpt from a discussion of the standard.
I haven't downloaded the full document "IEEE Trial-Use Standard
for Prefixes for Binary Multiples" but copied from Wikipedia <http://
en.wikipedia.org/wiki/Binary_prefix>:
“This standard is prepared with two goals in mind: (1) to
preserve the SI prefixes as unambiguous decimal multipliers and
(2) to provide alternative prefixes for those cases where binary
multipliers are needed. The first goal affects the general
public, the wide audience of technical and nontechnical persons
who use computers without much concern for their construction
or inner working. These persons will normally interpret kilo,
mega, etc., in their proper decimal sense. The second goal
speaks to specialists—the prefixes for binary multiples make
it possible for persons who work in the information sciences
to communicate with precision.”
Binary multiplier make it possible to communicate with
precision. If you use the binary prefixes it is absolutely
clear what you are talking about. The meaning of the old
prefixes depend on the context.
But all this does not matter here. We are talking about a
progress indicator. Precision doesn't matter. The user wants
to be sure that something is happening and get an idea of how
much longer it will take to finish the fetch. An approximation
is sufficient.
What matters though is saving two characters, because the line
width is limited. So lets take "MB, kB".
Steffen
^ 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