* Re: [RFC PATCH 3/3] Support fetching from foreign VCSes
From: Johannes Schindelin @ 2009-01-12 19:09 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <alpine.LNX.1.00.0901121246320.19665@iabervon.org>
Hi,
On Mon, 12 Jan 2009, Daniel Barkalow wrote:
> Maybe fast-import should be able to run with a bi-directional connection
> to its input, so it can acknowledge checkpoints?
Whoa.
fast-import was first and foremost a very simple way to get stuff done.
Is it absolutely necessary to complicate that?
I mean, I don't know about git-svn, but shouldn't it be
relatively easy to use fast-import to import from Subversion once the
information is extracted from Subversion?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] grep: don't call regexec() for fixed strings
From: René Scharfe @ 2009-01-12 19:18 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <81b0412b0901120732t1bd1978awdc4be47767e02863@mail.gmail.com>
Alex Riesen schrieb:
> 2009/1/10 René Scharfe <rene.scharfe@lsrfire.ath.cx>:
>> +static int isregexspecial(int c)
>> +{
>> + return isspecial(c) || c == '$' || c == '(' || c == ')' || c == '+' ||
>> + c == '.' || c == '^' || c == '{' || c == '|';
>> +}
>> +
>> +static int is_fixed(const char *s)
>> +{
>> + while (!isregexspecial(*s))
>> + s++;
>> + return !*s;
>> +}
>
> strchr?
Oh, yes, that would look nicer.
Another option is to extend ctype.c and implement isregexspecial() --
and while we're at it islowerxdigit() (builtin-name-rev.c::ishex()) and
iswordchar() (config.c::iskeychar(), grep.c::word_char()), too -- as
table lookups. I.e., something like the following (untested).
Which of the mentioned functions are really worth of this promotion?
The isregexspecial() char class has more members than isspecial(), but
it's not performance critical (unless you have a lot of patterns and
only a small amount of data to grep :).
Are there more candidates for ctype-ification?
René
ctype.c | 14 ++++++++++----
git-compat-util.h | 6 ++++++
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/ctype.c b/ctype.c
index 9208d67..1a76586 100644
--- a/ctype.c
+++ b/ctype.c
@@ -10,20 +10,26 @@
#undef AA
#undef DD
#undef GS
+#undef RR
+#undef US
+#undef Ah
#define SS GIT_SPACE
#define AA GIT_ALPHA
#define DD GIT_DIGIT
#define GS GIT_SPECIAL /* \0, *, ?, [, \\ */
+#define RR GIT_REGEX_SPECIAL /* $, (, ), +, ., ^, {, | */
+#define US GIT_UNDERSCORE
+#define Ah (GIT_ALPHA | GIT_LOWER_XDIGIT)
unsigned char sane_ctype[256] = {
GS, 0, 0, 0, 0, 0, 0, 0, 0, SS, SS, 0, 0, SS, 0, 0, /* 0-15 */
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* 16-15 */
- SS, 0, 0, 0, 0, 0, 0, 0, 0, 0, GS, 0, 0, 0, 0, 0, /* 32-15 */
+ SS, 0, 0, 0, RR, 0, 0, 0, RR, RR, GS, RR, 0, 0, RR, 0, /* 32-15 */
DD, DD, DD, DD, DD, DD, DD, DD, DD, DD, 0, 0, 0, 0, 0, GS, /* 48-15 */
0, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, /* 64-15 */
- AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, GS, GS, 0, 0, 0, /* 80-15 */
- 0, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, /* 96-15 */
- AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, 0, 0, 0, 0, 0, /* 112-15 */
+ AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, GS, GS, 0, RR, US, /* 80-15 */
+ 0, Ah, Ah, Ah, Ah, Ah, Ah, AA, AA, AA, AA, AA, AA, AA, AA, AA, /* 96-15 */
+ AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, RR, RR, 0, 0, 0, /* 112-15 */
/* Nothing in the 128.. range */
};
diff --git a/git-compat-util.h b/git-compat-util.h
index e20b1e8..5eaa662 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -328,12 +328,18 @@ extern unsigned char sane_ctype[256];
#define GIT_DIGIT 0x02
#define GIT_ALPHA 0x04
#define GIT_SPECIAL 0x08
+#define GIT_REGEX_SPECIAL 0x10
+#define GIT_UNDERSCORE 0x20
+#define GIT_LOWER_XDIGIT 0x40
#define sane_istest(x,mask) ((sane_ctype[(unsigned char)(x)] & (mask)) != 0)
#define isspace(x) sane_istest(x,GIT_SPACE)
#define isdigit(x) sane_istest(x,GIT_DIGIT)
#define isalpha(x) sane_istest(x,GIT_ALPHA)
#define isalnum(x) sane_istest(x,GIT_ALPHA | GIT_DIGIT)
#define isspecial(x) sane_istest(x,GIT_SPECIAL)
+#define isregexspecial(x) sane_istest(x,GIT_SPECIAL | GIT_REGEX_SPECIAL)
+#define iswordchar(x) sane_istest(x,GIT_ALPHA | GIT_DIGIT | GIT_UNDERSCORE)
+#define islowerxdigit(x) sane_istest(x,GIT_DIGIT | GIT_LOWER_XDIGIT)
#define tolower(x) sane_case((unsigned char)(x), 0x20)
#define toupper(x) sane_case((unsigned char)(x), 0)
^ permalink raw reply related
* checking out by date
From: David Bryson @ 2009-01-12 19:30 UTC (permalink / raw)
To: git
Hi All,
I have a very large repository that imported into git from CVS with
about 5 years worth of history.
Today I decided to checkout some code from the past:
$ git checkout master@{"Mon Dec 31 2007"}
warning: Log for 'master' only goes back to Tue, 2 Dec 2008 16:57:15
-0800.
Then proceeds to checkout a code snapshot from 2 Dec. To work around
this I checked out a specific commit id, by looking at the log:
commit 3771ec1d6ccf329da378b7633fdef60474eac4b7
Author: XXXXXXXXXXXXXXX
Date: Mon Dec 31 23:25:17 2007 +0000
BugId: none
correct wrong commit
$ git checkout 3771ec1d6ccf329da378b7633fdef60474eac4b7
...
HEAD is now at 3771ec1... BugId: none correct wrong commit
So what has caused git to be unable to process the date information,
even though the information is clearly in the history ? Did I miss
something ?
Dave
^ permalink raw reply
* Re: [RFC PATCH 3/3] Support fetching from foreign VCSes
From: Daniel Barkalow @ 2009-01-12 19:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901122007070.3586@pacific.mpi-cbg.de>
On Mon, 12 Jan 2009, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 12 Jan 2009, Daniel Barkalow wrote:
>
> > Maybe fast-import should be able to run with a bi-directional connection
> > to its input, so it can acknowledge checkpoints?
>
> Whoa.
>
> fast-import was first and foremost a very simple way to get stuff done.
> Is it absolutely necessary to complicate that?
>
> I mean, I don't know about git-svn, but shouldn't it be
> relatively easy to use fast-import to import from Subversion once the
> information is extracted from Subversion?
I assume that git-svn's problem is that it would need to store too much of
the information (rather than being able to discard it) if it couldn't get
the information back from the git object database.
Actually, I think it might be actually simplify programs using fast-import
if they could ask it for data from before, and I think that would have to
be necessary in order to have a reasonable non-git-specific incremental
importer without duplicating the storage of a lot of information that
previously went into fast-import.
I know I found it helpful in my p4 one to be able to pick up the
incremental state by looking at what refs exist and the information in
commits they point to, rather than trying to get the information from the
perforce client state or custom storage.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Lightweight tag ?
From: Junio C Hamano @ 2009-01-12 19:52 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Francis Moreau, git
In-Reply-To: <496B59A3.2080507@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
>> That's not what Junio said:
>>
>> Don't use explicit --tags blindly. It says "no matter what kind of tag,
>> transfer everything under refs/tags". Otherwise you won't see a
>> difference.
>>
>> So I interpret this like don't use --tags otherwise lightweight and annoted tags
>> are the same.
>
> I don't see a difference between lightweight tags and tag objects
> regarding the question of automatic tag following, see my parenthetical
> request for correction (below) in case I'm wrong.
It was me who was confused on two points.
(1) push does not do autofollow and you always have to be explicit
(including saying "--tags" which is to push all refs/tags/*); I
somehow thought the question was about fetch;
(2) if you explicitly ask to fetch tags, there won't be any difference
(which was my "don't say --tags explicitly because you won't see a
difference if you did so").
On the other hand, the autofollowing during the fetch originally
followed only annotated tags (it was partly by design, so that people
can use lightweight tags for local stuff without worrying about
contaminating others' tag namespace with many of them) and I somehow
thought this was still the case.
But it is not the case anymore since 6c96c0f (git-fetch: follow
lightweight tags as well, 2006-11-18).
So, sorry for the noise.
^ permalink raw reply
* Re: checking out by date
From: Boyd Stephen Smith Jr. @ 2009-01-12 19:58 UTC (permalink / raw)
To: David Bryson; +Cc: git
In-Reply-To: <20090112193039.GO25823@eratosthenes.cryptobackpack.org>
[-- Attachment #1: Type: text/plain, Size: 2276 bytes --]
On Monday 2009 January 12 13:30:39 David Bryson wrote:
>I have a very large repository that imported into git from CVS with
>about 5 years worth of history.
>
>Today I decided to checkout some code from the past:
>
>$ git checkout master@{"Mon Dec 31 2007"}
>warning: Log for 'master' only goes back to Tue, 2 Dec 2008 16:57:15
>-0800.
>
>Then proceeds to checkout a code snapshot from 2 Dec. To work around
>this I checked out a specific commit id, by looking at the log:
>
>commit 3771ec1d6ccf329da378b7633fdef60474eac4b7
>Author: XXXXXXXXXXXXXXX
>Date: Mon Dec 31 23:25:17 2007 +0000
>
>$ git checkout 3771ec1d6ccf329da378b7633fdef60474eac4b7
>...
>HEAD is now at 3771ec1... BugId: none correct wrong commit
>
>So what has caused git to be unable to process the date information,
>even though the information is clearly in the history ? Did I miss
>something ?
The ref@{date} format uses the reflogs which are expired regularly, IIRC.
Also, I don't think reflogs are built by cvsimport, so they would only go
back to the import date.
While there is date information in the output of 'git log', some of those
commits may never have been pointed to by the named ref, so they wouldn't
satisfy the semantics of "$ref as it was on $date". With a linear history,
this "only" puts you in the middle of a fast-forward, which isn't *that* bad.
However, with a non-linear history, taking the ancestor with the latest commit
date before the given date might end up checking out a topic branch that
hadn't yet been merged on that date, which could be incredibly confusing.
It should be possible to introduce a commit "spelling" to enable
checkout-by-date, but I don't know of one currently. Something
like "commitish~{date}" meaning "commitish~n where n is the largest value
s.t. commit_date(commitish~n) <= date", intentionally taking the first parent
on any merge to discard the merge event.
If this is a feature we feel is valuable, I don't think it would be that hard
to code.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] Update bash completions to prevent unbound variable errors.
From: Ted Pavlic @ 2009-01-12 19:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, gitster
In bash, "set -u" gives an error when a variable is unbound. In this
case, the bash completion script included in the git/contrib directory
produces several errors.
The attached patch replaces things like
if [ -z "$1" ]
with
if [ -z "${1-}" ]
so that the unbound variable returns an empty value. Hence, the
completion script will now work even "set -u" set.
Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
---
contrib/completion/git-completion.bash | 68
++++++++++++++++----------------
1 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 7b074d7..50e345f 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -52,25 +52,25 @@ esac
__gitdir ()
{
- if [ -z "$1" ]; then
- if [ -n "$__git_dir" ]; then
+ if [ -z "${1-}" ]; then
+ if [ -n "${__git_dir-}" ]; then
echo "$__git_dir"
elif [ -d .git ]; then
echo .git
else
git rev-parse --git-dir 2>/dev/null
fi
- elif [ -d "$1/.git" ]; then
- echo "$1/.git"
+ elif [ -d "${1-}/.git" ]; then
+ echo "${1-}/.git"
else
- echo "$1"
+ echo "${1-}"
fi
}
__git_ps1 ()
{
local g="$(git rev-parse --git-dir 2>/dev/null)"
- if [ -n "$g" ]; then
+ if [ -n "${g-}" ]; then
local r
local b
if [ -d "$g/rebase-apply" ]
@@ -111,8 +111,8 @@ __git_ps1 ()
fi
fi
- if [ -n "$1" ]; then
- printf "$1" "${b##refs/heads/}$r"
+ if [ -n "${1-}" ]; then
+ printf "${1-}" "${b##refs/heads/}$r"
else
printf " (%s)" "${b##refs/heads/}$r"
fi
@@ -122,11 +122,11 @@ __git_ps1 ()
__gitcomp_1 ()
{
local c IFS=' '$'\t'$'\n'
- for c in $1; do
- case "$c$2" in
- --*=*) printf %s$'\n' "$c$2" ;;
- *.) printf %s$'\n' "$c$2" ;;
- *) printf %s$'\n' "$c$2 " ;;
+ for c in ${1-}; do
+ case "$c${2-}" in
+ --*=*) printf %s$'\n' "$c${2-}" ;;
+ *.) printf %s$'\n' "$c${2-}" ;;
+ *) printf %s$'\n' "$c${2-} " ;;
esac
done
}
@@ -135,7 +135,7 @@ __gitcomp ()
{
local cur="${COMP_WORDS[COMP_CWORD]}"
if [ $# -gt 2 ]; then
- cur="$3"
+ cur="${3-}"
fi
case "$cur" in
--*=)
@@ -143,8 +143,8 @@ __gitcomp ()
;;
*)
local IFS=$'\n'
- COMPREPLY=($(compgen -P "$2" \
- -W "$(__gitcomp_1 "$1" "$4")" \
+ COMPREPLY=($(compgen -P "${2-}" \
+ -W "$(__gitcomp_1 "${1-}" "${4-}")" \
-- "$cur"))
;;
esac
@@ -152,13 +152,13 @@ __gitcomp ()
__git_heads ()
{
- local cmd i is_hash=y dir="$(__gitdir "$1")"
+ local cmd i is_hash=y dir="$(__gitdir "${1-}")"
if [ -d "$dir" ]; then
git --git-dir="$dir" for-each-ref --format='%(refname:short)' \
refs/heads
return
fi
- for i in $(git ls-remote "$1" 2>/dev/null); do
+ for i in $(git ls-remote "${1-}" 2>/dev/null); do
case "$is_hash,$i" in
y,*) is_hash=n ;;
n,*^{}) is_hash=y ;;
@@ -170,13 +170,13 @@ __git_heads ()
__git_tags ()
{
- local cmd i is_hash=y dir="$(__gitdir "$1")"
+ local cmd i is_hash=y dir="$(__gitdir "${1-}")"
if [ -d "$dir" ]; then
git --git-dir="$dir" for-each-ref --format='%(refname:short)' \
refs/tags
return
fi
- for i in $(git ls-remote "$1" 2>/dev/null); do
+ for i in $(git ls-remote "${1-}" 2>/dev/null); do
case "$is_hash,$i" in
y,*) is_hash=n ;;
n,*^{}) is_hash=y ;;
@@ -188,7 +188,7 @@ __git_tags ()
__git_refs ()
{
- local i is_hash=y dir="$(__gitdir "$1")"
+ local i is_hash=y dir="$(__gitdir "${1-}")"
local cur="${COMP_WORDS[COMP_CWORD]}" format refs
if [ -d "$dir" ]; then
case "$cur" in
@@ -221,7 +221,7 @@ __git_refs ()
__git_refs2 ()
{
local i
- for i in $(__git_refs "$1"); do
+ for i in $(__git_refs "${1-}"); do
echo "$i:$i"
done
}
@@ -229,11 +229,11 @@ __git_refs2 ()
__git_refs_remotes ()
{
local cmd i is_hash=y
- for i in $(git ls-remote "$1" 2>/dev/null); do
+ for i in $(git ls-remote "${1-}" 2>/dev/null); do
case "$is_hash,$i" in
n,refs/heads/*)
is_hash=y
- echo "$i:refs/remotes/$1/${i#refs/heads/}"
+ echo "$i:refs/remotes/${1-}/${i#refs/heads/}"
;;
y,*) is_hash=n ;;
n,*^{}) is_hash=y ;;
@@ -264,7 +264,7 @@ __git_remotes ()
__git_merge_strategies ()
{
- if [ -n "$__git_merge_strategylist" ]; then
+ if [ -n "${__git_merge_strategylist-}" ]; then
echo "$__git_merge_strategylist"
return
fi
@@ -350,7 +350,7 @@ __git_complete_revlist ()
__git_all_commands ()
{
- if [ -n "$__git_all_commandlist" ]; then
+ if [ -n "${__git_all_commandlist-}" ]; then
echo "$__git_all_commandlist"
return
fi
@@ -368,7 +368,7 @@ __git_all_commandlist="$(__git_all_commands
2>/dev/null)"
__git_porcelain_commands ()
{
- if [ -n "$__git_porcelain_commandlist" ]; then
+ if [ -n "${__git_porcelain_commandlist-}" ]; then
echo "$__git_porcelain_commandlist"
return
fi
@@ -473,7 +473,7 @@ __git_aliases ()
__git_aliased_command ()
{
local word cmdline=$(git --git-dir="$(__gitdir)" \
- config --get "alias.$1")
+ config --get "alias.${1-}")
for word in $cmdline; do
if [ "${word##-*}" ]; then
echo $word
@@ -488,7 +488,7 @@ __git_find_subcommand ()
while [ $c -lt $COMP_CWORD ]; do
word="${COMP_WORDS[c]}"
- for subcommand in $1; do
+ for subcommand in ${1-}; do
if [ "$subcommand" = "$word" ]; then
echo "$subcommand"
return
@@ -599,7 +599,7 @@ _git_bisect ()
local subcommands="start bad good skip reset visualize replay log run"
local subcommand="$(__git_find_subcommand "$subcommands")"
- if [ -z "$subcommand" ]; then
+ if [ -z "${subcommand-}" ]; then
__gitcomp "$subcommands"
return
fi
@@ -1371,7 +1371,7 @@ _git_remote ()
{
local subcommands="add rm show prune update"
local subcommand="$(__git_find_subcommand "$subcommands")"
- if [ -z "$subcommand" ]; then
+ if [ -z "${subcommand-}" ]; then
__gitcomp "$subcommands"
return
fi
@@ -1500,7 +1500,7 @@ _git_stash ()
{
local subcommands='save list show apply clear drop pop create branch'
local subcommand="$(__git_find_subcommand "$subcommands")"
- if [ -z "$subcommand" ]; then
+ if [ -z "${subcommand-}" ]; then
__gitcomp "$subcommands"
else
local cur="${COMP_WORDS[COMP_CWORD]}"
@@ -1552,7 +1552,7 @@ _git_svn ()
proplist show-ignore show-externals
"
local subcommand="$(__git_find_subcommand "$subcommands")"
- if [ -z "$subcommand" ]; then
+ if [ -z "${subcommand-}" ]; then
__gitcomp "$subcommands"
else
local remote_opts="--username= --config-dir= --no-auth-cache"
@@ -1672,7 +1672,7 @@ _git ()
c=$((++c))
done
- if [ -z "$command" ]; then
+ if [ -z "${command-}" ]; then
case "${COMP_WORDS[COMP_CWORD]}" in
--*=*) COMPREPLY=() ;;
--*) __gitcomp "
--
1.6.1.87.g15624
^ permalink raw reply related
* [PATCH] Fix Dcoumentation typos surrounding the word 'handful'.
From: Jon Loeliger @ 2009-01-12 20:02 UTC (permalink / raw)
To: git; +Cc: Jon Loeliger
Some instances replaced by "handful of", others use
the word "few", a couple get a slight rewording.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
Junio,
I wasn't sure that fixing the release notes was important.
I can hit those too if you would like.
jdl
Documentation/diff-options.txt | 2 +-
Documentation/git-describe.txt | 2 +-
Documentation/git-ls-files.txt | 2 +-
Documentation/git-ls-tree.txt | 2 +-
Documentation/gitcore-tutorial.txt | 8 ++++----
Documentation/githooks.txt | 2 +-
.../howto/rebase-from-internal-branch.txt | 2 +-
Documentation/pretty-options.txt | 2 +-
8 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 671f533..43793d7 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -116,7 +116,7 @@ endif::git-format-patch[]
--abbrev[=<n>]::
Instead of showing the full 40-byte hexadecimal object
name in diff-raw format output and diff-tree header
- lines, show only handful hexdigits prefix. This is
+ lines, show only a partial prefix. This is
independent of --full-index option above, which controls
the diff-patch output format. Non default number of
digits can be specified with --abbrev=<n>.
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index 3d79f05..a99b4ef 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -87,7 +87,7 @@ With something like git.git current tree, I get:
v1.0.4-14-g2414721
i.e. the current head of my "parent" branch is based on v1.0.4,
-but since it has a handful commits on top of that,
+but since it has a few commits on top of that,
describe has added the number of additional commits ("14") and
an abbreviated object name for the commit itself ("2414721")
at the end.
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index 9f85d60..057a021 100644
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -126,7 +126,7 @@ OPTIONS
--abbrev[=<n>]::
Instead of showing the full 40-byte hexadecimal object
- lines, show only handful hexdigits prefix.
+ lines, show only a partial prefix.
Non default number of digits can be specified with --abbrev=<n>.
\--::
diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt
index 4c7262f..b345f4d 100644
--- a/Documentation/git-ls-tree.txt
+++ b/Documentation/git-ls-tree.txt
@@ -59,7 +59,7 @@ OPTIONS
--abbrev[=<n>]::
Instead of showing the full 40-byte hexadecimal object
- lines, show only handful hexdigits prefix.
+ lines, show only a partal prefix.
Non default number of digits can be specified with --abbrev=<n>.
--full-name::
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index e4dd551..7ba5e58 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -1243,10 +1243,10 @@ $ git ls-files --stage
------------
In our example of only two files, we did not have unchanged
-files so only 'example' resulted in collapsing, but in real-life
-large projects, only small number of files change in one commit,
-and this 'collapsing' tends to trivially merge most of the paths
-fairly quickly, leaving only a handful the real changes in non-zero
+files so only 'example' resulted in collapsing. But in real-life
+large projects, when only a small number of files change in one commit,
+this 'collapsing' tends to trivially merge most of the paths
+fairly quickly, leaving only a handful of real changes in non-zero
stages.
To look at only non-zero stages, use `\--unmerged` flag:
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index cfdae1e..e4d61d5 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -15,7 +15,7 @@ DESCRIPTION
Hooks are little scripts you can place in `$GIT_DIR/hooks`
directory to trigger action at certain points. When
-'git-init' is run, a handful example hooks are copied in the
+'git-init' is run, a handful of example hooks are copied into the
`hooks` directory of the new repository, but by default they are
all disabled. To enable a hook, rename it by removing its `.sample`
suffix.
diff --git a/Documentation/howto/rebase-from-internal-branch.txt b/Documentation/howto/rebase-from-internal-branch.txt
index d214d4b..74a1c0c 100644
--- a/Documentation/howto/rebase-from-internal-branch.txt
+++ b/Documentation/howto/rebase-from-internal-branch.txt
@@ -27,7 +27,7 @@ the kind of task StGIT is designed to do.
I just have done a simpler one, this time using only the core
GIT tools.
-I had a handful commits that were ahead of master in pu, and I
+I had a handful of commits that were ahead of master in pu, and I
wanted to add some documentation bypassing my usual habit of
placing new things in pu first. At the beginning, the commit
ancestry graph looked like this:
diff --git a/Documentation/pretty-options.txt b/Documentation/pretty-options.txt
index 6d66c74..5f21efe 100644
--- a/Documentation/pretty-options.txt
+++ b/Documentation/pretty-options.txt
@@ -10,7 +10,7 @@ configuration (see linkgit:git-config[1]).
--abbrev-commit::
Instead of showing the full 40-byte hexadecimal commit object
- name, show only handful hexdigits prefix. Non default number of
+ name, show only a partial prefix. Non default number of
digits can be specified with "--abbrev=<n>" (which also modifies
diff output, if it is displayed).
+
--
1.6.0.4.761.g47577
^ permalink raw reply related
* Re: [PATCH] stgit namelength is an integer
From: Karl Hasselström @ 2009-01-12 20:13 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git
In-Reply-To: <20090105190354.GA8295@osc.edu>
Thanks, but the test suite fails unless I apply this first:
Return None instead of crashing on undefined integer config items
Signed-off-by: Karl Hasselström <kha@treskal.com>
diff --git a/stgit/config.py b/stgit/config.py
index 8934445..5b47580 100644
--- a/stgit/config.py
+++ b/stgit/config.py
@@ -65,7 +65,9 @@ class GitConfig:
def getint(self, name):
value = self.get(name)
- if value.isdigit():
+ if value == None:
+ return None
+ elif value.isdigit():
return int(value)
else:
raise GitConfigException, 'Value for "%s" is not an integer: "%s"' % (name, value)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply related
* Re: [PATCH] Update bash completions to prevent unbound variable errors.
From: Boyd Stephen Smith Jr. @ 2009-01-12 20:35 UTC (permalink / raw)
To: Ted Pavlic; +Cc: git
In-Reply-To: <496BA0E4.2040607@tedpavlic.com>
[-- Attachment #1: Type: text/plain, Size: 660 bytes --]
On Monday 2009 January 12 13:58:28 you wrote:
>In bash, "set -u" gives an error when a variable is unbound. In this
>case, the bash completion script included in the git/contrib directory
>produces several errors.
>
>The attached patch replaces things like
>
> if [ -z "$1" ]
>
>with
>
> if [ -z "${1-}" ]
That looks ugly to me. Any reason we shouldn't just "set +u" at the top of
the script?
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Update bash completions to prevent unbound variable errors.
From: Adeodato Simó @ 2009-01-12 20:40 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: Ted Pavlic, git
In-Reply-To: <200901121435.35547.bss@iguanasuicide.net>
* Boyd Stephen Smith Jr. [Mon, 12 Jan 2009 14:35:35 -0600]:
> >The attached patch replaces things like
> > if [ -z "$1" ]
> >with
> > if [ -z "${1-}" ]
> That looks ugly to me. Any reason we shouldn't just "set +u" at the top of
> the script?
`set +u` affects the shell globally, not just to the sourced file. If
you do that, you must be aware that you'll be preventing people from
running their shell in `set -u` mode. (Merely stating a fact here, not
giving any opinion.)
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
The problem I have with making an intelligent statement is that some
people then think that it's not an isolated occurrance.
-- Simon Travaglia
^ permalink raw reply
* Re: Lightweight tag ?
From: Francis Moreau @ 2009-01-12 20:50 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, git
In-Reply-To: <496B59A3.2080507@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
>> Perhaps it needs documents which are more user friendly: I don't know where
>> the 'lightweight' word is coming from (perhaps from the implementation) but
>> I would expect that the _local_ term appears in the git-tag manual.
>
> It's the other way round. "lightweight" is in the first few lines of the
> man, "local" nowhere. In fact I don't see it anywhere in the docs.
Sorry my previous reply wasn't clear, I meant that the word
'lightweight' appears in the man page of git-tag but I don't see why
such term is used, well now I can see but it's implementation detail
so useless (or worth: confusing) for a dumb user (me).
In contrary I would have expected to find the 'local' word if git
support local tags.
>> I just need to create a local tag where I'm sure it won't be seen by others
>> whatever the git operations I'm doing, normally a simple "git tag" switch
>> should be enough...
>
> Taking "whatever" literally this is impossible, of course.
>
>
> Taking it /cum grano salis/ it's still impossible within the same repo:
> If others have read access they can "ls-remote" and "fetch" happily what
> they want. The sane and easy way is to use a private repo for your local
> work and all your "local tags", then to push to a public (i.e.
> publically readable) repo those branches and tags which you want to be seen.
>
This is how things are currently implemented but if lightweight is
really useless and local tags are somehow missing in Git then I'm
pretty sure it's possible to create such tags that are not seen by
git-{pull,push,fetch] operations.
>
> Are you a Mercurial user by any chance?
Nope.
> "hg tag -l" creates local tags which are stored in an unversioned,
> private file, whereas "hg tag" creates (and commits) a tag entry in
> a versioned file, which is the source of some confusion and problems
> with hg tags ("hg co sometag" does not contain sometag etc.). Maybe
> you want the behaviour of "hg tag -l"?
Yes, It sounds that 'hg tag -l' is what I'm looking for in git...
Thanks
--
Francis
^ permalink raw reply
* [PATCH v2] git-web--browse: don't add start as candidate on Ubuntu
From: Ramsay Jones @ 2009-01-12 21:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Couder, Petr Baudis, GIT Mailing-list
In-Reply-To: <7vljtr33sb.fsf@gitster.siamese.dyndns.org>
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
Junio C Hamano wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
>> Le jeudi 1 janvier 2009, Ramsay Jones a écrit :
>> ...
>>> Does anybody else see this issue and can someone test the patch?
>> Petr, as you added support for using /bin/start on MinGW, could you test?
>>
>> diff --git a/git-web--browse.sh b/git-web--browse.sh
>> index 78d236b..7ed0fad 100755
>> --- a/git-web--browse.sh
>> +++ b/git-web--browse.sh
>> @@ -115,7 +115,7 @@ if test -z "$browser" ; then
>> browser_candidates="open $browser_candidates"
>> fi
>> # /bin/start indicates MinGW
>> - if test -n /bin/start; then
>> + if test -x /bin/start; then
>> browser_candidates="start $browser_candidates"
>> fi
>
> In any case, the original test is simply bogus. 'test -n "$foo"' is to
> see if $foo is an empty string, and giving a constant /bin/start always
> yields true.
>
> As an old timer, I tend to prefer "test -f" in this context, as anybody
> sane can expect that the directory /bin will contain executables and
> nothing else. Another reason is purely stylistic. Historically "-f" has
> been much more portable than "-x" (which came from SVID), even though it
> wouldn't make much difference in practice in the real world these days.
Sorry for the late reply; if this has already been resolved, then sorry for
the noise.
I was expecting to be castigated for having /sbin in my $PATH. Indeed, I was
a bit surprised... So, I checked my initialization files and then the system
initialization files and could not find where it was being set...
$ strings /bin/bash | grep sbin
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$ strings /bin/sh | grep sbin
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
So I don't think it's anything I'm doing...
Anyway, I've changed the patch as you suggested. It would still be good
if someone on MinGW could test it.
ATB,
Ramsay Jones
git-web--browse.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-web--browse.sh b/git-web--browse.sh
index 78d236b..c5e62a6 100755
--- a/git-web--browse.sh
+++ b/git-web--browse.sh
@@ -115,7 +115,7 @@ if test -z "$browser" ; then
browser_candidates="open $browser_candidates"
fi
# /bin/start indicates MinGW
- if test -n /bin/start; then
+ if test -f /bin/start; then
browser_candidates="start $browser_candidates"
fi
--
1.6.1
^ permalink raw reply related
* Re: [PATCH] Update bash completions to prevent unbound variable errors.
From: Ted Pavlic @ 2009-01-12 21:11 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git
In-Reply-To: <200901121435.35547.bss@iguanasuicide.net>
>> if [ -z "${1-}" ]
>
> That looks ugly to me. Any reason we shouldn't just "set +u" at the top of
> the script?
As already discussed, because the script must be sourced, then the "set
+u" has global scope.
I suppose that the option could be tested and then reset as appropriate
at the end of the script.
(note: for some reason Mercurial's bash completion script does not have
this problem; they use $1 directly without bash complaining)
--
Ted Pavlic <ted@tedpavlic.com>
Please visit my ALS association page:
http://web.alsa.org/goto/tedpavlic
My family appreciates your support in the fight to defeat ALS.
^ permalink raw reply
* Re: [JGIT] Blame functionality for jgit
From: Manuel Woelker @ 2009-01-12 21:17 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Robin Rosenberg, git
In-Reply-To: <20090112174232.GJ10179@spearce.org>
On Mon, Jan 12, 2009 at 6:42 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
>
>> I largely ported the cgit blame algorithm described here
>> https://kerneltrap.org/mailarchive/git/2006/10/12/224187 , the
>> relevant file is builtin-blame.c cf.
>> http://repo.or.cz/w/git.git?a=blob;f=builtin-blame.c;hb=HEAD
>
> OK. Fortunately Junio has largely given his blessing to this code
> being converted to Java under the BSD license.
Glad to hear that, Dscho already mentioned that a port like this might
raise license concerns. So I hope Junio would be okay with that.
> Unfortunately I can't reach incava.org to download java-diff, but
> its entry on sourceforge says it uses an LGPL license. Within JGit
> we do want to stick to BSD and BSD dependencies, so bringing in
> java-diff as a new dependency isn't something we really want to do.
>
> Fortunately Dscho has been working on a Java diff implementation for
> JGit, and is considering releasing it under a BSD license so we can
> include it.
>
> The interface is still to be decided, but in general we have
> found that running against a byte[] is much faster than running
> against String. We're probably going to want the diff library to
> take a byte[] and an IntList (as created by RawParseUtils.lineMap)
> and let it work against the byte array ranges directly, without any
> additional allocations, except where it needs to build up its hash
> of records.
That sounds like a good plan. For now I am not all that concerned
about performance myself (premature optimization and all that), but in
the long run - and especially with rename/copy detection that will
definitely a factor for usability. We could adopt the interface to
allow for a "fast" implementation, and have existing diff
implementations adapted to that. I'd be very interested to see Dscho's
diff work, and maybe we can get something going on that front. A
patience diff implementation would be rather neat too, and all my
googling hasn't turned up anything.
> I think eventually we'll have a BSD licensed LCS that will come with
> JGit, which would eliminate the need for such a shim. I'd like
> to see that happen before blame gets added, but if blame is ready
> and the shim is reasonably well done, I'm inclined to bring blame
> in early.
While trying to look up the Myers diff algorithm I found a diff
implementation in Apache wicket (cf.
http://wicket.sourceforge.net/apidocs/wicket/util/diff/myers/package-summary.html
). This one is under an Apache license, is that any better? It's truly
kind of sad that you need a degree in law these days to get any work
done in this license jungle. I just happen to strongly oppose the
reinvention of circular transportation-enabling devices...
> - Don't use @author tags, we don't use them anywhere else.
>
> - Please include copyright headers on all new files.
>
> - I think the IDiff, IDifference should be in a ".diff" package so
> we can reuse them for other diff applications. Especially if we
> wind up using a shim to link to different LCS implementations.
>
> - I think the API for BlameEngine should be more like:
>
> public class BlameEngine {
> private final RevWalk rw;
>
> public BlameEngine(final Repository repo) {
> this(new RevWalk(repo));
> }
>
> public BlameEngine(final RevWalk walk) {
> rw = walk;
> }
>
> public RevWalk getRevWalk() {
> return rw;
> }
>
> public List<BlameEntry> blame(RevCommit c, String path);
> }
>
> One reason for this style of API is we can have the engine cache
> blame records. This can make a GUI navigator much more efficient
> as it jumps around between commits and asks for blames over the
> same data.
>
> - Internally you should *always* use RevCommit, not Commit.
> The RevCommit class can be orders of magnitude faster than Commit.
>
> - Internally you should always use RevTree and TreeWalk to locate
> blob IDs. Its orders of magnitude faster than Tree and TreeEntry.
>
> - Don't use new String(loader.getBytes()) (e.g. in Origin.getData)
> to get the data for a file. We want to do raw diffs, so that the
> character encoding is considered as part of the blame. E.g. if
> a file switches character encodings, the blame has to go to the
> commit that introduced the new encoding. This is a huge reason
> to use byte[] and IntList over an array of String.
>
> - RawParseUtils.lineMap will be faster than a Pattern of "^(.*)$".
>
Thanks for the comments. This first version was basically just a
proof-of-concept to see if and how it could work. I didn't want to
pour too much effort into, before knowing if this project was viable
at all. This input is very valuable and I will try to incorporate the
suggestions into future revisions.
I'll keep you posted on new developments
- Manuel
^ permalink raw reply
* Re: [PATCH] Update bash completions to prevent unbound variable errors.
From: Ted Pavlic @ 2009-01-12 21:21 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git
In-Reply-To: <496BB204.2040109@tedpavlic.com>
> (note: for some reason Mercurial's bash completion script does not have
> this problem; they use $1 directly without bash complaining)
It appears like they use
complete -o bashdefault
whereas Git's uses
complete -o default
I think that's the difference.
--
Ted Pavlic <ted@tedpavlic.com>
Please visit my ALS association page:
http://web.alsa.org/goto/tedpavlic
My family appreciates your support in the fight to defeat ALS.
^ permalink raw reply
* Re: [PATCH] Update bash completions to prevent unbound variable errors.
From: Adeodato Simó @ 2009-01-12 21:25 UTC (permalink / raw)
To: Ted Pavlic; +Cc: git, Boyd Stephen Smith Jr.
In-Reply-To: <496BB204.2040109@tedpavlic.com>
* Ted Pavlic [Mon, 12 Jan 2009 16:11:32 -0500]:
>> That looks ugly to me. Any reason we shouldn't just "set +u" at the top of
>> the script?
> As already discussed, because the script must be sourced, then the "set
> +u" has global scope.
> I suppose that the option could be tested and then reset as appropriate
> at the end of the script.
That does not help, because appart from being global, it of course takes
effect at run time. In other words, it doesn't matter if set -u is
active or not at function definition time, but at function invoation
time.
> (note: for some reason Mercurial's bash completion script does not have
> this problem; they use $1 directly without bash complaining)
Because (from a quick look) their completion script never expands a
variable which is not known to be set.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
A hacker does for love what other would not do for money.
^ permalink raw reply
* Re: [PATCH] Update bash completions to prevent unbound variable errors.
From: Boyd Stephen Smith Jr. @ 2009-01-12 21:27 UTC (permalink / raw)
To: Adeodato Simó; +Cc: Ted Pavlic, git
In-Reply-To: <20090112204030.GA23327@chistera.yi.org>
[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]
On Monday 2009 January 12 14:40:30 Adeodato Simó wrote:
>* Boyd Stephen Smith Jr. [Mon, 12 Jan 2009 14:35:35 -0600]:
>> >The attached patch replaces things like
>> >
>> > if [ -z "$1" ]
>> >
>> >with
>> >
>> > if [ -z "${1-}" ]
>>
>> That looks ugly to me. Any reason we shouldn't just "set +u" at the top
>> of the script?
>
>`set +u` affects the shell globally, not just to the sourced file. If
>you do that, you must be aware that you'll be preventing people from
>running their shell in `set -u` mode. (Merely stating a fact here, not
>giving any opinion.)
I'm not familiar with bash completion exception as a user, I didn't realize
all these functions had to be sourced into the current shell.
Well, if the user want to run in "set -u" mode preventing it is bogus, IMO.
We could use subshells and unset at the top of _git and _gitk functions, that
would be only a +6/-4 patch. It would also not be something future
contributors have to think (much) about.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH/RFC] Documentation/git-mailsplit.txt: Emphasize -o more
From: jidanni @ 2009-01-12 21:28 UTC (permalink / raw)
To: git
The need for -o cannot be overstated. Else the arguments get
interpreted differently. We also mention the output.
(By the way, "fatal: unknown option: -o" is seen if a space comes
after it.)
Signed-off-by: jidanni <jidanni@jidanni.org>
---
Documentation/git-mailsplit.txt | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-mailsplit.txt b/Documentation/git-mailsplit.txt
index 5cc94ec..5dc24c9 100644
--- a/Documentation/git-mailsplit.txt
+++ b/Documentation/git-mailsplit.txt
@@ -13,10 +13,18 @@ DESCRIPTION
-----------
Splits a mbox file or a Maildir into a list of files: "0001" "0002" .. in the
specified directory so you can process them further from there.
+The number of files produced is printed to the standard output.
IMPORTANT: Maildir splitting relies upon filenames being sorted to output
patches in the correct order.
+REQUIRED OPTIONS
+-------
+-o<directory>::
+ Directory in which to place the individual messages.
+ -o is required or else arguments may be misinterpreted in a
+ backwards compatibility mode.
+
OPTIONS
-------
<mbox>::
@@ -27,9 +35,6 @@ OPTIONS
Root of the Maildir to split. This directory should contain the cur, tmp
and new subdirectories.
--o<directory>::
- Directory in which to place the individual messages.
-
-b::
If any file doesn't begin with a From line, assume it is a
single mail message instead of signaling error.
--
1.6.0.6
^ permalink raw reply related
* Re: [PATCH] Update bash completions to prevent unbound variable errors.
From: Shawn O. Pearce @ 2009-01-12 21:31 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: Adeodato Simó, Ted Pavlic, git
In-Reply-To: <200901121527.21818.bss@iguanasuicide.net>
"Boyd Stephen Smith Jr." <bss@iguanasuicide.net> wrote:
>
> Well, if the user want to run in "set -u" mode preventing it is bogus, IMO.
> We could use subshells and unset at the top of _git and _gitk functions, that
> would be only a +6/-4 patch. It would also not be something future
> contributors have to think (much) about.
Running in subshells is a bad idea. We'd likely lose access
to the completion word array, and it would take a lot longer per
completion because you need to spin-up and tear-down that subshell.
We have spent some time to make the current completion code use as
few forks as possible to get the results we want, because it runs
faster that way.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Update bash completions to prevent unbound variable errors.
From: Shawn O. Pearce @ 2009-01-12 21:32 UTC (permalink / raw)
To: Ted Pavlic; +Cc: Boyd Stephen Smith Jr., git
In-Reply-To: <496BB442.90107@tedpavlic.com>
Ted Pavlic <ted@tedpavlic.com> wrote:
>> (note: for some reason Mercurial's bash completion script does not have
>> this problem; they use $1 directly without bash complaining)
>
> It appears like they use
>
> complete -o bashdefault
>
> whereas Git's uses
>
> complete -o default
>
> I think that's the difference.
If that's all we need to do, that's a simple 1 line change... which
I like.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Update bash completions to prevent unbound variable errors.
From: Ted Pavlic @ 2009-01-12 21:37 UTC (permalink / raw)
To: Adeodato Simó; +Cc: git, Boyd Stephen Smith Jr.
In-Reply-To: <20090112212544.GA24941@chistera.yi.org>
> Because (from a quick look) their completion script never expands a
> variable which is not known to be set.
They use $1, $2, etc. In fact, they use $1, $2, and $3 in their _hg,
which is their main completion function. Why would those be defined there?
In fact, it's $1, $2, $3, and $4 that are causing the problemw ith the
git completions.
--Ted
--
Ted Pavlic <ted@tedpavlic.com>
Please visit my ALS association page:
http://web.alsa.org/goto/tedpavlic
My family appreciates your support in the fight to defeat ALS.
^ permalink raw reply
* Re: [PATCH] Update bash completions to prevent unbound variable errors.
From: Boyd Stephen Smith Jr. @ 2009-01-12 21:38 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Adeodato Simó, Ted Pavlic, git
In-Reply-To: <20090112213149.GL10179@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 1114 bytes --]
On Monday 2009 January 12 15:31:49 Shawn O. Pearce wrote:
>"Boyd Stephen Smith Jr." <bss@iguanasuicide.net> wrote:
>> Well, if the user want to run in "set -u" mode preventing it is bogus,
>> IMO. We could use subshells and unset at the top of _git and _gitk
>> functions, that would be only a +6/-4 patch. It would also not be
>> something future contributors have to think (much) about.
>
>Running in subshells is a bad idea.
Yeah, not only for all the reasons you mention, but because it would require
refactoring to use -C instead of -F (so we a longer and uglier patch); our
changes to COMPREPLY in the subshell wouldn't be seen by bash.
Having tripped over my lack of experience twice in two messages in this
thread, I'm going to bow out of the rest of it. My ascetic opinion still
stands, but I'll take working code, warts and all, over broken code.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Update bash completions to prevent unbound variable errors.
From: Adeodato Simó @ 2009-01-12 21:40 UTC (permalink / raw)
To: Ted Pavlic; +Cc: Shawn O. Pearce, git, gitster
In-Reply-To: <496BA0E4.2040607@tedpavlic.com>
* Ted Pavlic [Mon, 12 Jan 2009 14:58:28 -0500]:
I don't know if this patch will go forward or not, but there are several
instances of spurious ${x-}, eg.:
> __gitdir ()
> {
> - if [ -z "$1" ]; then
> + if [ -z "${1-}" ]; then
Given the above...
> - elif [ -d "$1/.git" ]; then
> - echo "$1/.git"
> + elif [ -d "${1-}/.git" ]; then
> + echo "${1-}/.git"
> else
> - echo "$1"
> + echo "${1-}"
... this other hunk is redundant, because if [ -z "${1-}" ] fails, then
$1 is surely set.
> __git_ps1 ()
> {
> local g="$(git rev-parse --git-dir 2>/dev/null)"
> - if [ -n "$g" ]; then
> + if [ -n "${g-}" ]; then
Spurious, $g is always set here.
> @@ -111,8 +111,8 @@ __git_ps1 ()
> - if [ -n "$1" ]; then
> + if [ -n "${1-}" ]; then
This one is okay...
> - printf "$1" "${b##refs/heads/}$r"
> + printf "${1-}" "${b##refs/heads/}$r"
But this one is unnecessary, if [ -n "${1-}" ] succeeds, then $1 is set.
And so on.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
The true teacher defends his pupils against his own personal influence.
-- Amos Bronson Alcott
^ permalink raw reply
* rebase-merge/done: No such file or directory
From: jidanni @ 2009-01-12 19:13 UTC (permalink / raw)
To: johannes.schindelin; +Cc: git
Bug at git-rebase--interactive.sh:107: count=$(grep -c '^[^#]' < "$DONE")
$DONE might not exist. Do test -f $DONE before you grep it.
This will happen if the user gave a wrong squash choice.
$ git rebase --interactive ...
Waiting for Emacs...
grep: .git/rebase-merge/done: No such file or directory
Cannot 'squash' without a previous commit
^ 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