* Re: git-prompt.sh vs leading white space in __git_ps1()::printf_format
From: Simon Oosthoek @ 2012-12-26 12:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Piotr Krukowiecki, git
In-Reply-To: <7vvcbpp846.fsf@alter.siamese.dyndns.org>
* Junio C Hamano <gitster@pobox.com> [2012-12-25 23:47:53 -0800]:
> Can we make it take an optional third parameter so that we could say
>
> PROMPT_COMMAND='__git_ps1 ": \h \W" "; " "/%s"'
>
> to do the same as what the command substitution mode would have
> given for
>
> PS1=': \h \W$(__git_ps1 "/%s"); '
>
> perhaps?
>
> Totally untested, but perhaps along this line.
>
I tried your patch and (to my surprise, after the first reading) it worked.
I've further modified git-prompt.sh to include more usage text and I changed
the name of ps1 to gitstring, as it might be confused with PS1 upon casual
reading.
I'll be sending a format-patch patchmail ASAP...
> contrib/completion/git-prompt.sh | 24 ++++++++++++++----------
> 1 file changed, 14 insertions(+), 10 deletions(-)
>
> diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
> index 9b074e1..b2579f4 100644
> --- a/contrib/completion/git-prompt.sh
> +++ b/contrib/completion/git-prompt.sh
> @@ -236,9 +236,10 @@ __git_ps1 ()
> local printf_format=' (%s)'
>
> case "$#" in
> - 2) pcmode=yes
> + 2|3) pcmode=yes
> ps1pc_start="$1"
> ps1pc_end="$2"
> + printf_format="${3:-$printf_format}"
> ;;
> 0|1) printf_format="${1:-$printf_format}"
> ;;
> @@ -339,6 +340,7 @@ __git_ps1 ()
>
> local f="$w$i$s$u"
> if [ $pcmode = yes ]; then
> + local ps1=
> if [ -n "${GIT_PS1_SHOWCOLORHINTS-}" ]; then
> local c_red='\e[31m'
> local c_green='\e[32m'
> @@ -356,29 +358,31 @@ __git_ps1 ()
> branch_color="$bad_color"
> fi
>
> - # Setting PS1 directly with \[ and \] around colors
> + # Setting ps1 directly with \[ and \] around colors
> # is necessary to prevent wrapping issues!
> - PS1="$ps1pc_start (\[$branch_color\]$branchstring\[$c_clear\]"
> + ps1="\[$branch_color\]$branchstring\[$c_clear\]"
>
> if [ -n "$w$i$s$u$r$p" ]; then
> - PS1="$PS1 "
> + ps1="$ps1 "
> fi
> if [ "$w" = "*" ]; then
> - PS1="$PS1\[$bad_color\]$w"
> + ps1="$ps1\[$bad_color\]$w"
> fi
> if [ -n "$i" ]; then
> - PS1="$PS1\[$ok_color\]$i"
> + ps1="$ps1\[$ok_color\]$i"
> fi
> if [ -n "$s" ]; then
> - PS1="$PS1\[$flags_color\]$s"
> + ps1="$ps1\[$flags_color\]$s"
> fi
> if [ -n "$u" ]; then
> - PS1="$PS1\[$bad_color\]$u"
> + ps1="$ps1\[$bad_color\]$u"
> fi
> - PS1="$PS1\[$c_clear\]$r$p)$ps1pc_end"
> + ps1="$ps1\[$c_clear\]$r$p"
> else
> - PS1="$ps1pc_start ($c${b##refs/heads/}${f:+ $f}$r$p)$ps1pc_end"
> + ps1="$c${b##refs/heads/}${f:+ $f}$r$p"
> fi
> + ps1=$(printf -- "$printf_format" "$ps1")
> + PS1="$ps1pc_start$ps1$ps1pc_end"
> else
> # NO color option unless in PROMPT_COMMAND mode
> printf -- "$printf_format" "$c${b##refs/heads/}${f:+ $f}$r$p"
/Simon
^ permalink raw reply
* [PATCH] wt-status: Show ignored files in untracked dirs
From: Antoine Pelisse @ 2012-12-26 10:16 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse
In-Reply-To: <50DA91AF.1060200@alum.mit.edu>
When looking for ignored files, we do not recurse into untracked
directory, and simply consider the directory ignored status.
As a consequence, we don't see ignored files in those directories.
Change that behavior by recursing into untracked directories searching
for ignored files.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
---
I jumped in.
This seems to be broken since the creation of the --ignored option to
wt-status.
This fixes the issue and breaks none of the existing tests.
The behavior seems sane to me, giving something like that:
?? .gitignore
?? x
?? y/foo
!! x.ignore-me
!! y/foo.ignore-me
Cheers,
Antoine
wt-status.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/wt-status.c b/wt-status.c
index 2a9658b..7c41488 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -516,7 +516,7 @@ static void wt_status_collect_untracked(struct wt_status *s)
if (s->show_ignored_files) {
dir.nr = 0;
- dir.flags = DIR_SHOW_IGNORED | DIR_SHOW_OTHER_DIRECTORIES;
+ dir.flags = DIR_SHOW_IGNORED;
fill_directory(&dir, s->pathspec);
for (i = 0; i < dir.nr; i++) {
struct dir_entry *ent = dir.entries[i];
--
1.8.1.rc3.11.g86c3e6e.dirty
^ permalink raw reply related
* Re: [PATCH] gitweb: fix error when highlight is enabled
From: Junio C Hamano @ 2012-12-26 9:55 UTC (permalink / raw)
To: Orgad Shaneh; +Cc: git
In-Reply-To: <1356508456-17454-1-git-send-email-orgads@gmail.com>
Orgad Shaneh <orgads@gmail.com> writes:
> Use of uninitialized value in substitution iterator at gitweb.cgi line 1560
This is not just about squelching an error message, but more
importantly, attempting to fix an information lossage, no?
The statement captures each control character in the string to $1,
then matches a class of known/safe control chars against that
control character we just have seen. If matches, it just wants to
use that control character, otherwise it wants to apply quot_cec()
on that control character. It forgets that "$1" is reset
immediately when =~ matches with the class of known/safe control
chars, and your version attempts to fix it by recapturing it.
What if you are looking at a non-safe control, say "\001"? It is
matched and is captured by ([[;cntrl:]]), making $1 -eq "\001", and
then the replacement side of s///e operator, tries to match and
capture it with ([\t\n\r]), but it does *not* match.
What does that "$1" you are feeding quot_cec() contain at that
point? I _think_ "$1" is left intact when the inner match fails and
you are correctly feeding "\001" to quot_cec(), but it is not
immediately obvious. Perl regexp, especially s///e, is a yucky
language X-<.
I wonder if there is a better way to express what goes inside the
replacement side of this s///e construct in a more obvious way. The
updated one may be correct but it looks too subtle to my taste..
> Signed-off-by: Orgad Shaneh <orgads@gmail.com>
> ---
> gitweb/gitweb.perl | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 0f207f2..862b9cd 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -1556,7 +1556,7 @@ sub sanitize {
> return undef unless defined $str;
>
> $str = to_utf8($str);
> - $str =~ s|([[:cntrl:]])|($1 =~ /[\t\n\r]/ ? $1 : quot_cec($1))|eg;
> + $str =~ s|([[:cntrl:]])|($1 =~ /([\t\n\r])/ ? $1 : quot_cec($1))|eg;
> return $str;
> }
^ permalink raw reply
* Re: [PATCH] refs: do not use cached refs in repack_without_ref
From: Michael Haggerty @ 2012-12-26 8:24 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20121221080449.GA21741@sigill.intra.peff.net>
On 12/21/2012 09:04 AM, Jeff King wrote:
> When we delete a ref that is packed, we rewrite the whole
> packed-refs file and simply omit the ref that no longer
> exists. However, we base the rewrite on whatever happens to
> be in our refs cache, not what is necessarily on disk. That
> opens us up to a race condition if another process is
> simultaneously packing the refs, as we will overwrite their
> newly-made pack-refs file with our potentially stale data,
> losing commits.
> [...]
>
> There are a few other interesting races in this code that this does not
> fix:
>
> 1. We check to see whether the ref is packed based on the cached data.
> That means that in the following sequence:
>
> a. receive-pack starts, caches packed refs; master is not packed
>
> b. meanwhile, pack-refs runs and packs master
>
> c. receive-pack deletes the loose ref for master (which might be
> a no-op if the pack-refs from (b) got there first). It checks
> its cached packed-refs and sees that there is nothing to
> delete.
>
> We end up leaving the entry in packed-refs. In other words, the
> deletion does not actually delete anything, but it still returns
> success.
>
> We could fix this by scanning the list of packed refs only after
> we've acquired the lock. The downside is that this would increase
> lock contention on packed-refs.lock. Right now, two deletions may
> conflict if they are deletions of packed refs. With this change,
> any two deletions might conflict, packed or not.
>
> If we work under the assumption that deletions are relatively rare,
> this is probably OK. And if you tend to keep your refs packed, it
> would not make any difference. It would have an impact on repos
> which do not pack refs, and which have frequent simultaneous
> deletions.
>
> 2. The delete_ref function first deletes the loose ref, then rewrites
> the packed-refs file. This means that for a moment, the ref may
> appear to have rewound to whatever was in the packed-refs file, and
> the reader has no way of knowing.
>
> This is not a huge deal, but I think it could be fixed by swapping
> the ordering. However, I think that would open us up to the reverse
> race from above: we delete from packed-refs, then before we delete
> the loose ref, a pack-refs process repacks it. Our deletion looks
> successful, but the ref remains afterwards.
I'm sorry to take so long to respond to this patch. Thank you for
tracking down this bug and for your careful analysis.
I think your patch is correct and should fix the first race condition
that you described. But I think the continued existence of the other
race conditions is an indication of a fundamental problem with the
reference locking policy--independent of the in-RAM reference cache.
The tacit assumption of the current locking policy is that changes to
the packed-refs file are not critical for correctness, because loose
references take precedence over it anyway. This is true for adding and
modifying references. But it is not true for deleting references,
because there is no way for a deletion to be represented as a loose
reference in a way that takes precedence over the packed-refs file
(i.e., there is no way for a loose reference to say "I am deleted,
regardless of what packed-refs says"). Thus the race conditions for
deleting references, whether via delete_ref() or via pack_refs() with
--prune.
The current algorithms for deleting references are:
* Delete reference foo:
1. Acquire the lock $GIT_DIR/refs/heads/foo.lock
2. Unlink $GIT_DIR/refs/heads/foo
3. repack_without_ref():
a. Acquire the lock $GIT_DIR/packed-refs.lock
b. Write the packed-refs without the "foo" reference to
$GIT_DIR/packed-refs.lock
c. Rename $GIT_DIR/packed-refs.lock to $GIT_DIR/packed-refs
4. Release lock $GIT_DIR/refs/heads/foo.lock
* Pack references:
1. Acquire lock $GIT_DIR/packed-refs.lock
2. for_each_ref() call handle_one_ref():
a. Write ref and its SHA1 to $GIT_DIR/packed-refs.lock
b. Possibly record ref and its SHA1 in the refs_to_prune list.
3. Commit $GIT_DIR/packed-refs
4. prune_refs(): for each ref in the ref_to_prune list, call
prune_ref():
a. Lock the reference using lock_ref_sha1(), verifying that the
recorded SHA1 is still valid. If it is, unlink the loose
reference file then free the lock; otherwise leave the loose
reference file untouched.
There is a problem if two processes try to delete a reference at the
same time, or if one process tries to delete a reference at the same
time as another process is trying to pack the references. The reason is
that there is no "transaction" that spans both the rewriting of the
packed-refs file and also the deletion of the loose-ref files, and
therefore it is possible for conflicting changes to be made in the two
locations.
I think that all of the problems would be fixed if a lock would be held
on the packed-refs file during the whole process of deleting any
reference; i.e., change the algorithms to:
* Delete reference foo:
1. Acquire the lock $GIT_DIR/packed-refs.lock (regardless of whether
"foo" is a packed ref)
2. Write to $GIT_DIR/packed-refs.new a version of the packed-refs
file that omits "foo"
3. Atomically replace $GIT_DIR/packed-refs with
$GIT_DIR/packed-refs.new (but without relinquishing the lock
$GIT_DIR/packed-refs.lock)
4. Delete loose ref for "foo":
a. Acquire the lock $GIT_DIR/refs/heads/foo.lock
b. Unlink $GIT_DIR/refs/heads/foo if it is unchanged. If it is
changed, leave it untouched. If it is deleted, that is OK too.
c. Release lock $GIT_DIR/refs/heads/foo.lock
5. Release lock $GIT_DIR/packed-refs.lock (without changing
$GIT_DIR/packed-refs again)
* Pack references:
1. Acquire lock $GIT_DIR/packed-refs.lock
2. for_each_ref() call handle_one_ref():
a. Write ref and its SHA1 to $GIT_DIR/packed-refs.new
b. Possibly record ref and its SHA1 in the refs_to_prune list.
3. Atomically replace $GIT_DIR/packed-refs with
$GIT_DIR/packed-refs.new (but without relinquishing the lock
$GIT_DIR/packed-refs.lock)
4. prune_refs(): for each ref in the ref_to_prune list, call
prune_ref():
a. Lock the loose reference using lock_ref_sha1(), verifying that
the recorded SHA1 is still valid
b. If it is, unlink the loose reference file (otherwise, leave
it untouched)
c. Release the lock on the loose reference
5. Release lock $GIT_DIR/packed-refs.lock (without changing
$GIT_DIR/packed-refs again)
It is important that after step (3) in either of the above algorithms,
the new packed-refs file has been switched "live" even though there is
no way to guarantee that it holds the correct values for all references.
This is OK, because (a) references that have been added or changed will
be represented by loose references that take precedence over the stale
references in the packed-refs file; (b) no references can have been
deleted while the packed-refs file was being rewritten, because
reference deletion is serialized via the lock on the packed-refs file.
If one of the later steps fails, it is OK to leave this version of the
packed-refs file active.
The proposed algorithms will have to hold the lock on packed-refs for
much longer; in the case of packed-refs, the lock has to be held for the
whole time that all of the loose references are being deleted.
Effectively it is being used to prevent other processes from deleting
references while it is working because that would make the just-written
packed-refs file invalid.
I would appreciate a critique of my analysis. Even if you agree, I
think it would be OK to apply Peff's patch to fix up the most pressing
problem, then implement the more complete solution later.
By the way, this is something that I would be happy to add to my to-do
list, but it could take a while for me to get to it because of a lack of
time and because I'm still busy with two other biggish git-related
projects (git-multimail [1] and a git merging helper [2]).
Michael
[1] https://github.com/mhagger/git-multimail
[2] A fun project that I haven't yet mentioned on the list
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* [PATCH] gitweb: fix error when highlight is enabled
From: Orgad Shaneh @ 2012-12-26 7:54 UTC (permalink / raw)
To: git; +Cc: Orgad Shaneh
Use of uninitialized value in substitution iterator at gitweb.cgi line 1560
Signed-off-by: Orgad Shaneh <orgads@gmail.com>
---
gitweb/gitweb.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0f207f2..862b9cd 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1556,7 +1556,7 @@ sub sanitize {
return undef unless defined $str;
$str = to_utf8($str);
- $str =~ s|([[:cntrl:]])|($1 =~ /[\t\n\r]/ ? $1 : quot_cec($1))|eg;
+ $str =~ s|([[:cntrl:]])|($1 =~ /([\t\n\r])/ ? $1 : quot_cec($1))|eg;
return $str;
}
--
1.7.10.4
^ permalink raw reply related
* Re: git-prompt.sh vs leading white space in __git_ps1()::printf_format
From: Junio C Hamano @ 2012-12-26 7:47 UTC (permalink / raw)
To: Simon Oosthoek; +Cc: Piotr Krukowiecki, git
In-Reply-To: <50C8E857.5080000@xs4all.nl>
Simon Oosthoek <s.oosthoek@xs4all.nl> writes:
> On 12/12/12 18:50, Junio C Hamano wrote:
>> Simon Oosthoek <s.oosthoek@xs4all.nl> writes:
>>
>>> This removes most of the ambiguities :-)
>>> Ack from me!
>>
>> OK, as this is a low-impact finishing touch for a new feature, I'll
>> fast-track this to 'master' before the final release.
>>
>
> Ok, wonderful!
> BTW, I tried the thing I mentioned and it was safe to do:
> PS1='blabla$(__git_ps1 x y)blabla'
> will not eat your prompt, although I'd recommend putting something
> useful instead of blabla ;-)
Actually, I deeply regret merging this to 'master'. The original
"as a command substitution in PS1" mode, you could add anything
around the status string, so I could do:
PS1=': \h \W$(__git_ps1 "/%s"); '
to get something like:
: hostname dirname/<STATUS>; <CURSOR HERE>
In the new PROMPT_COMMAND mode, there is always parentheses around
the status string (and an SP before the parenthesees) that the user
cannot get rid of.
This is not a usability regression per-se (if you do not like the
extra parentheses, you do not have to use the colored mode), but is
something that will make me never use the mode.
Can we make it take an optional third parameter so that we could say
PROMPT_COMMAND='__git_ps1 ": \h \W" "; " "/%s"'
to do the same as what the command substitution mode would have
given for
PS1=': \h \W$(__git_ps1 "/%s"); '
perhaps?
Totally untested, but perhaps along this line.
contrib/completion/git-prompt.sh | 24 ++++++++++++++----------
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 9b074e1..b2579f4 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -236,9 +236,10 @@ __git_ps1 ()
local printf_format=' (%s)'
case "$#" in
- 2) pcmode=yes
+ 2|3) pcmode=yes
ps1pc_start="$1"
ps1pc_end="$2"
+ printf_format="${3:-$printf_format}"
;;
0|1) printf_format="${1:-$printf_format}"
;;
@@ -339,6 +340,7 @@ __git_ps1 ()
local f="$w$i$s$u"
if [ $pcmode = yes ]; then
+ local ps1=
if [ -n "${GIT_PS1_SHOWCOLORHINTS-}" ]; then
local c_red='\e[31m'
local c_green='\e[32m'
@@ -356,29 +358,31 @@ __git_ps1 ()
branch_color="$bad_color"
fi
- # Setting PS1 directly with \[ and \] around colors
+ # Setting ps1 directly with \[ and \] around colors
# is necessary to prevent wrapping issues!
- PS1="$ps1pc_start (\[$branch_color\]$branchstring\[$c_clear\]"
+ ps1="\[$branch_color\]$branchstring\[$c_clear\]"
if [ -n "$w$i$s$u$r$p" ]; then
- PS1="$PS1 "
+ ps1="$ps1 "
fi
if [ "$w" = "*" ]; then
- PS1="$PS1\[$bad_color\]$w"
+ ps1="$ps1\[$bad_color\]$w"
fi
if [ -n "$i" ]; then
- PS1="$PS1\[$ok_color\]$i"
+ ps1="$ps1\[$ok_color\]$i"
fi
if [ -n "$s" ]; then
- PS1="$PS1\[$flags_color\]$s"
+ ps1="$ps1\[$flags_color\]$s"
fi
if [ -n "$u" ]; then
- PS1="$PS1\[$bad_color\]$u"
+ ps1="$ps1\[$bad_color\]$u"
fi
- PS1="$PS1\[$c_clear\]$r$p)$ps1pc_end"
+ ps1="$ps1\[$c_clear\]$r$p"
else
- PS1="$ps1pc_start ($c${b##refs/heads/}${f:+ $f}$r$p)$ps1pc_end"
+ ps1="$c${b##refs/heads/}${f:+ $f}$r$p"
fi
+ ps1=$(printf -- "$printf_format" "$ps1")
+ PS1="$ps1pc_start$ps1$ps1pc_end"
else
# NO color option unless in PROMPT_COMMAND mode
printf -- "$printf_format" "$c${b##refs/heads/}${f:+ $f}$r$p"
^ permalink raw reply related
* Bug in git status
From: Michael Haggerty @ 2012-12-26 5:57 UTC (permalink / raw)
To: git discussion list
I think I have found a bug in "git status --untracked-files=all
--ignored", in both 1.8.0 and in master:
$ git init status-test
Initialized empty Git repository in
/home/mhagger/self/proj/git/status-test/.git/
$ cd status-test
$ touch x
$ touch x.ignore-me
$ mkdir y
$ touch y/foo
$ touch y/foo.ignore-me
$ git status --porcelain --untracked-files=all --ignored
?? x
?? x.ignore-me
?? y/foo
?? y/foo.ignore-me
The above output is what I expect. But if I add a .gitignore file, the
output of y/foo.ignore-me is incorrectly suppressed:
$ echo '*.ignore-me' >.gitignore
$ git status --porcelain --untracked-files=all --ignored
?? .gitignore
?? x
?? y/foo
!! x.ignore-me
I came across this problem when trying to use the results of the above
command to build a more flexible "git clean" type of script.
I don't have time to look into this at the moment, if somebody wants to
jump in.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH] stash: treat numerical arguments as shorthand for stash@{n}
From: Junio C Hamano @ 2012-12-26 2:08 UTC (permalink / raw)
To: Peter Collingbourne; +Cc: git
In-Reply-To: <1356482314-29044-1-git-send-email-peter@pcc.me.uk>
Peter Collingbourne <peter@pcc.me.uk> writes:
> This patch causes git-stash to treat any argument consisting of
> between one and three numerical digits as if it were of the form
> `stash@{<n>}`, where `<n>` is the argument supplied.
Inperative mood.
>
> This is a significant usability improvement for people dealing with
> multiple stashes, as it avoids redundantly typing 'stash@{' ... '}'
> (which involves shifted characters on most keyboards) in the very
> common case that the stash was created using git-stash.
Be less subjective by dropping "significant"; do not shove the
judgement down the throat of reviewers.
> diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
> index 711ffe1..8ffcc97 100644
> --- a/Documentation/git-stash.txt
> +++ b/Documentation/git-stash.txt
> @@ -40,6 +40,10 @@ the usual reflog syntax (e.g. `stash@{0}` is the most recently
> created stash, `stash@{1}` is the one before it, `stash@{2.hours.ago}`
> is also possible).
>
> +Any argument supplied to this command consisting of between one
> +and three numerical digits is treated as if it were of the
> +form `stash@{<n>}`, where `<n>` is the argument supplied.
Why up to 999, not 99 or 9999?
How about doing it this way instead:
if commit=$(git rev-parse --verify --quiet $arg^0)
then
: that is a commit-ish, even though it is 0123
elif test "$arg" = 0 || expr "$arg" : '[1-9][0-9]*$' >/dev/null &&
commit=$(git rev-parse --verify --quiet "stash@{$arg}^0")
then
: $arg is decimal integer and stash@{$arg} is a commit-ish
else
BAD
fi
> diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
> index 5dfbda7..5467acf 100755
> --- a/t/t3903-stash.sh
> +++ b/t/t3903-stash.sh
> @@ -38,7 +38,7 @@ test_expect_success 'parents of stash' '
> '
>
> test_expect_success 'applying bogus stash does nothing' '
> - test_must_fail git stash apply stash@{1} &&
> + test_must_fail git stash apply 1 &&
If you are _adding_ a feature, do not remove tests for existing one;
otherwise you will risk masking a breakage you may be introducing to
an existing feature. Add tests to check that (1) your new feature
works when it should, and (2) your new feature does *not* kick in
when it should not. For example, if you only accept up to 3-digit
decimal integer, make sure feeding 0000 (or something that is *not*
3-digit decimal integer) does not trigger your new feature.
> echo 1 >expect &&
> test_cmp expect file
> '
> @@ -113,7 +113,7 @@ test_expect_success 'drop middle stash' '
> git stash &&
> echo 9 > file &&
> git stash &&
> - git stash drop stash@{1} &&
> + git stash drop 1 &&
Likewise throughout the patch.
^ permalink raw reply
* [PATCH] stash: treat numerical arguments as shorthand for stash@{n}
From: Peter Collingbourne @ 2012-12-26 0:38 UTC (permalink / raw)
To: git; +Cc: Peter Collingbourne
This patch causes git-stash to treat any argument consisting of
between one and three numerical digits as if it were of the form
`stash@{<n>}`, where `<n>` is the argument supplied.
This is a significant usability improvement for people dealing with
multiple stashes, as it avoids redundantly typing 'stash@{' ... '}'
(which involves shifted characters on most keyboards) in the very
common case that the stash was created using git-stash.
Signed-off-by: Peter Collingbourne <peter@pcc.me.uk>
---
Documentation/git-stash.txt | 4 ++++
git-stash.sh | 15 ++++++++++++++-
t/t3903-stash.sh | 18 +++++++++---------
3 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 711ffe1..8ffcc97 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -40,6 +40,10 @@ the usual reflog syntax (e.g. `stash@{0}` is the most recently
created stash, `stash@{1}` is the one before it, `stash@{2.hours.ago}`
is also possible).
+Any argument supplied to this command consisting of between one
+and three numerical digits is treated as if it were of the
+form `stash@{<n>}`, where `<n>` is the argument supplied.
+
OPTIONS
-------
diff --git a/git-stash.sh b/git-stash.sh
index bbefdf6..2232719 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -327,7 +327,20 @@ parse_flags_and_rev()
i_tree=
u_tree=
- REV=$(git rev-parse --no-flags --symbolic "$@") || exit 1
+ ARGS=
+ for arg
+ do
+ case "$arg" in
+ [0-9]|[0-9][0-9]|[0-9][0-9][0-9])
+ ARGS="${ARGS}${ARGS:+ }${ref_stash}@{$arg}"
+ ;;
+ *)
+ ARGS="${ARGS}${ARGS:+ }$arg"
+ ;;
+ esac
+ done
+
+ REV=$(git rev-parse --no-flags --symbolic $ARGS) || exit 1
FLAGS=
for opt
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 5dfbda7..5467acf 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -38,7 +38,7 @@ test_expect_success 'parents of stash' '
'
test_expect_success 'applying bogus stash does nothing' '
- test_must_fail git stash apply stash@{1} &&
+ test_must_fail git stash apply 1 &&
echo 1 >expect &&
test_cmp expect file
'
@@ -113,7 +113,7 @@ test_expect_success 'drop middle stash' '
git stash &&
echo 9 > file &&
git stash &&
- git stash drop stash@{1} &&
+ git stash drop 1 &&
test 2 = $(git stash list | wc -l) &&
git stash apply &&
test 9 = $(cat file) &&
@@ -570,16 +570,16 @@ test_expect_success 'ref with non-existent reflog' '
test_expect_success 'invalid ref of the form stash@{n}, n >= N' '
git stash clear &&
- test_must_fail git stash drop stash@{0} &&
+ test_must_fail git stash drop 0 &&
echo bar5 > file &&
echo bar6 > file2 &&
git add file2 &&
git stash &&
- test_must_fail git stash drop stash@{1} &&
- test_must_fail git stash pop stash@{1} &&
- test_must_fail git stash apply stash@{1} &&
- test_must_fail git stash show stash@{1} &&
- test_must_fail git stash branch tmp stash@{1} &&
+ test_must_fail git stash drop 1 &&
+ test_must_fail git stash pop 1 &&
+ test_must_fail git stash apply 1 &&
+ test_must_fail git stash show 1 &&
+ test_must_fail git stash branch tmp 1 &&
git stash drop
'
@@ -590,7 +590,7 @@ test_expect_success 'stash branch should not drop the stash if the branch exists
git commit -m initial &&
echo bar >file &&
git stash &&
- test_must_fail git stash branch master stash@{0} &&
+ test_must_fail git stash branch master 0 &&
git rev-parse stash@{0} --
'
--
1.7.5.3
^ permalink raw reply related
* Re: Using Eclipse git plugin
From: Robin Rosenberg @ 2012-12-25 21:01 UTC (permalink / raw)
To: Dennis Putnam; +Cc: git
In-Reply-To: <50D72E73.8070501@bellsouth.net>
----- Ursprungligt meddelande -----
> This may be more of an Eclipse question than a git question but
> hopefully someone on this list knows both. I now have a working git
> central repository (on Linux) and a local repository clone (on
> Windows).
> I can see and edit my files in Eclipse, commit them and push them to
> the
> remote repository. The problem I am having now is developing my code
> in
> Eclipse. It seems I can no longer run the code as the 'Run as
> Application' menu item is missing. How do I test my code now? TIA.
You're better off visiting the some Eclipse forums for this. I see
no reason to suspect this has anything to do Git or even EGit. You should
check the Error log view for hints errors hidden from view. It can also
be the case that your selection is not a Java class with a test case or
main method.
If it is EGit-related, http://www.eclipse.org/egit/support contains more
tips on getting help.
-- robin
^ permalink raw reply
* Re: [PATCH] t9200: let "cvs init" create the test repository
From: Junio C Hamano @ 2012-12-25 1:49 UTC (permalink / raw)
To: git
In-Reply-To: <7vr4mflyxu.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Some platforms (e.g. NetBSD 6.3) seem to configure their CVS to
s/6.3/6.0/; sorry for the noise.
^ permalink raw reply
* Re: GIT get corrupted on lustre
From: Greg Troxel @ 2012-12-25 1:11 UTC (permalink / raw)
To: Eric Chamberland; +Cc: git
In-Reply-To: <50D861EE.6020105@giref.ulaval.ca>
[-- Attachment #1: Type: text/plain, Size: 617 bytes --]
we are using git since may and all is working fine for all of us
(almost 20 people) on our workstations. However, when we clone our
repositories to the cluster, only and only there
we are having many problems similiar to this post:
What filesystem tests have you run on lustre? I would run every test
you can find, and lustre should have a robust test suite. It's really
hard to be certain, but given how many filesystems git is used with,
your experience points to a lustre bug.
I would also suggest using ktrace/ktruss/strace and perhaps poring over
the logs to see if you can spot any bad behavior.
[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]
^ permalink raw reply
* [PATCH] t9200: let "cvs init" create the test repository
From: Junio C Hamano @ 2012-12-25 1:09 UTC (permalink / raw)
To: git
Some platforms (e.g. NetBSD 6.3) seem to configure their CVS to
allow "cvs init" in an existing directory only to members of
"cvsadmin".
Instead of preparing an empty directory and then running "cvs init"
on it, let's run "cvs init" and let it create the necessary
directory.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t9200-git-cvsexportcommit.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/t/t9200-git-cvsexportcommit.sh b/t/t9200-git-cvsexportcommit.sh
index b59be9a..c5368a3 100755
--- a/t/t9200-git-cvsexportcommit.sh
+++ b/t/t9200-git-cvsexportcommit.sh
@@ -25,8 +25,9 @@ GIT_DIR=$PWD/.git
export CVSROOT CVSWORK GIT_DIR
rm -rf "$CVSROOT" "$CVSWORK"
-mkdir "$CVSROOT" &&
+
cvs init &&
+test -d "$CVSROOT" &&
cvs -Q co -d "$CVSWORK" . &&
echo >empty &&
git add empty &&
^ permalink raw reply related
* Re: Find the starting point of a local branch
From: Nguyen Thai Ngoc Duy @ 2012-12-25 1:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tomas Carnecky, Seth Robertson, Woody Wu, git
In-Reply-To: <7vbodjnu5c.fsf@alter.siamese.dyndns.org>
On Tue, Dec 25, 2012 at 2:10 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> I looked briefly at reflog before writing my previous mail and noticed
>> that when I create a new branch (usually using "git checkout -b branch
>> ref") it does not record the base commit.
>
> Hmph. Perhaps you are referring to something different than what I
> think "the base commit" with that word.
>
> $ git reflog mz/pick-unborn | tail -n 1
> b3cf6f3 mz/pick-unborn@{3}: branch: Created from ko/master
No you're right. My reflogs must be pruned. Creating a new branch does
produce that entry.
>> We could at least invalidate the recorded base in reflog and let user
>> define a new one (I hope).
>
> Please do not even think about going back and rewrite to lose
> information. If the records have full information, you should be
> able to reconstruct what you want from it without rewriting.
>
> Even more importantly, wish to "invalidate" indicates that you know
> at a newer point that you have more authoritative information than
> the older reflog entries, so you should be able to do the moral
> equivalent by writing the event as establishing a new base at that
> point (e.g. "checkout -B"), and stopping at that point in the reflog
> when reading, without losing the older reflog entries.
Exactly. And when we prune the reflog, we could add the base back so
the base is always in reflog.
--
Duy
^ permalink raw reply
* [LHF] making t5000 "tar xf" tests more lenient
From: Junio C Hamano @ 2012-12-24 20:49 UTC (permalink / raw)
To: git
I've been running testsuite on a few platforms that are unfamiliar
to me, and was bitten by BSD implementation of tar that do not grok
the extended pax headers. I've already fixed one in t9502 [*1*]
where we produce a tarball with "git archive" and then try to
validate it with the platform implementation of "tar" so that the
test won't barf when it sees the extended pax header.
t5000 is littered with similar tests that break unnecessarily with
BSD implementations. I think what it wants to test are:
- "archive" produces tarball, and "tar" can extract from it. If
your "tar" does not understand pax header, you may get it as an
extra file that shouldn't be there, but that should not cause the
test to fail---in real life, people without a pax-aware "tar"
will just ignore and remove the header and can go on.
- "get-tar-commmit-id" can inspect a tarball produced by "archive"
to recover the object name of the commit even on a platform
without a pax-aware "tar".
Perhaps t5000 can be restructured like so:
- create a tarball with the commit-id and test with
"get-tar-commit-id" to validate it; also create a tarball out of
a tree to make sure it does not have commit-id and check with
"get-tar-commit-id". Do this on any and all platform, even on
the ones without a pax-aware "tar".
- check platform implementation of "tar" early to see if extracting
a simple output from "git archive" results in an extra pax header
file. If so, remember this fact and produce any and all tarballs
used in the remainder of the test by forcing ^{tree}.
so that people on platforms without pax-aware "tar" do not have to
install GNU tar only to pass this test.
It would be a good exercise during the holiday week for somebody on
BSD (it seems NetBSD is more troublesome than OpenBSD) to come up
with a patch to help users on these platforms.
Thanks.
[Footnote]
*1* http://thread.gmane.org/gmane.comp.version-control.git/211803
^ permalink raw reply
* Re: [PATCH] Python scripts audited for minimum compatible version and checks added.
From: Eric S. Raymond @ 2012-12-24 19:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pete Wyckoff, git
In-Reply-To: <7v7go7nu1f.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com>:
> > Should I resubmit, or do you intend to fix these while merging?
>
> I'd appreciate a re-roll, perhaps in a few days after the dust
> settles.
You'll get it.
It will take a little longer than it otherwise might have because I'm
in the middle of straightening out the mess around cvsps and git-cvsimport,
which is deeper and nastier than I realized.
It turns out that one of the options git-cvsimport depends on, -A, has
been broken (leading to incorrect conversions of branchy repos) since
2006 if not earlier; I'm removing it outright.
Thus, the version of git-cvsimport in the git-tree will die with an
error calling cvsps 3.x - but since what it was doing before was actually
mangling users' repositories this is no great loss.
I'm going to have to shoot the existing implementation of
git-cvsimport through the head and rewrite it. This won't be
difficult; I already have a proof-of-concept in 126 lines of Python,
which is a big improvement over the 1179 lines of Perl in the existing
version. Most of the vanished bulk is CVS client code for fetching
logs and files, which is now done better and faster inside cvsps.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: [PATCH] Python scripts audited for minimum compatible version and checks added.
From: Junio C Hamano @ 2012-12-24 19:12 UTC (permalink / raw)
To: esr; +Cc: Pete Wyckoff, git
In-Reply-To: <20121224153257.GA28213@thyrsus.com>
"Eric S. Raymond" <esr@thyrsus.com> writes:
> Pete Wyckoff <pw@padd.com>:
>> esr@thyrsus.com wrote on Thu, 20 Dec 2012 09:13 -0500:
>> ...
>> Many of your changes have these three problems; I just picked on
>> my favorite one.
>
> Should I resubmit, or do you intend to fix these while merging?
I'd appreciate a re-roll, perhaps in a few days after the dust
settles.
Thanks, both, for the patch and the review.
^ permalink raw reply
* Re: Find the starting point of a local branch
From: Junio C Hamano @ 2012-12-24 19:10 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Tomas Carnecky, Seth Robertson, Woody Wu, git
In-Reply-To: <CACsJy8DMGrHqgY7himfJA-6f5beZ83Pje+-ex62LQOAARWh=Nw@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> On Mon, Dec 24, 2012 at 1:27 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>>
>>> On Mon, Dec 24, 2012 at 12:34 PM, Tomas Carnecky
>>> <tomas.carnecky@gmail.com> wrote:
>>>>> Maybe we should store this information. reflog is a perfect place for
>>>>> this, I think. If this information is reliably available, git rebase
>>>>> can be told to "rebase my whole branch" instead of my choosing the
>>>>> base commit for it.
>>>>
>>>> What's the starting point of the branch if I type: git branch foo <commit-ish>?
>>>
>>> You start working off <commit-ish> so I think the starting point would
>>> be <commit-ish>.
>>
>> Yeah, that sounds sensible. Don't we already have it in the reflog,
>> though?
>
> I looked briefly at reflog before writing my previous mail and noticed
> that when I create a new branch (usually using "git checkout -b branch
> ref") it does not record the base commit.
Hmph. Perhaps you are referring to something different than what I
think "the base commit" with that word.
$ git reflog mz/pick-unborn | tail -n 1
b3cf6f3 mz/pick-unborn@{3}: branch: Created from ko/master
>> What is trickier is when you later transplant it to some other base
>> (perhaps prepare a topic on 'master', realize it should better apply
>> to 'maint' and move it there). If the user did the transplanting by
>> hand, reflog would probably not have enough information, e.g. after
>>
>> $ git checkout maint^0
>> $ git log --oneline master..topic
>> $ git cherry-pick $one_of_the_commit_names_you_see_in_the_above
>> $ git cherry-pick $another_commit_name_you_see_in_the_above
>> ...
>> $ git branch -f topic
>>
>> no reflog other than HEAD@{} will tell you that you were at maint^0,
>> so the reflog of topic wouldn't know it "forked" from there, either.
>
> We could at least invalidate the recorded base in reflog and let user
> define a new one (I hope).
Please do not even think about going back and rewrite to lose
information. If the records have full information, you should be
able to reconstruct what you want from it without rewriting.
Even more importantly, wish to "invalidate" indicates that you know
at a newer point that you have more authoritative information than
the older reflog entries, so you should be able to do the moral
equivalent by writing the event as establishing a new base at that
point (e.g. "checkout -B"), and stopping at that point in the reflog
when reading, without losing the older reflog entries.
^ permalink raw reply
* Re: Find the starting point of a local branch
From: Martin von Zweigbergk @ 2012-12-24 17:24 UTC (permalink / raw)
To: Woody Wu; +Cc: Seth Robertson, git
In-Reply-To: <20121224073103.GA10793@zuhnb712>
On Sun, Dec 23, 2012 at 11:31 PM, Woody Wu <narkewoody@gmail.com> wrote:
> On Sun, Dec 23, 2012 at 11:09:58PM -0500, Seth Robertson wrote:
>>
>> In message <20121224035825.GA17203@zuhnb712>, Woody Wu writes:
>>
>> How can I find out what's the staring reference point (a commit number
>> or tag name) of a locally created branch? I can use gitk to find out it
>> but this method is slow, I think there might be a command line to do it
>> quickly.
>>
>> The answer is more complex than you probably suspected.
>>
>> Technically, `git log --oneline mybranch | tail -n 1` will tell you
>> the starting point of any branch. But...I'm sure that isn't what you
>> want to know.
>>
>> You want to know "what commit was I at when I typed `git branch
>> mybranch`"?
>
> Yes, this is exactly I want to know.
>
>>The problem is git doesn't record this information and
>> doesn't have the slightest clue.
>>
>> But, you say, I can use `gitk` and see it. See? Right there. That
>> isn't (necessarily) the "starting point" of the branch, it is the
>> place where your branch diverged from some other branch. Git is
>> actually quite able to tell you when the last time your branch
>> diverged from some other branch. `git merge-base mybranch master`
>> will tell you this, and is probably the answer you were looking for.
>
> This is not working to me since I have more than one local branch that
> diverged from the master, and in fact, the branch I have in question was
> diverged from another local branch.
As Jeff mentions in a later message, "git pull --rebase" would
probably do what you want. It works with local branches too.
I once tried to add the same cleverness that "git pull --rebase"
directly in "git rebase" [1], but there were several issues with those
patches, one of was regarding the performance ("git pull --rebase" can
be equally slow, but since it often involves network, users probably
rarely notice). I think it would be nice to at least add it as an
option to "git rebase" some day. Until then, "git pull --rebase" works
fine.
[1] http://thread.gmane.org/gmane.comp.version-control.git/166710
^ permalink raw reply
* Re: Find the starting point of a local branch
From: Jeff King @ 2012-12-24 15:34 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Seth Robertson, Woody Wu, git
In-Reply-To: <CACsJy8Dt94XLSa8Sg3T0URJYG9cHD_sUySuhm3Vu4ESy-VrXag@mail.gmail.com>
On Mon, Dec 24, 2012 at 06:16:05PM +0700, Nguyen Thai Ngoc Duy wrote:
> > The reason that git does not bother storing "where did I start this
> > branch" is that it is usually not useful. The right question is usually
> > "what is the merge base". There are exceptions, of course (e.g., if you
> > are asking something like "what work did I do while checked out on the
> > 'foo' branch"). But for merging and rebasing, I think the computed
> > merge-base is much more likely to do what people want.
>
> Rebasing is exactly why I want this. Merge base works most of the time
> until you rewrite upstream (which I do sometimes).
True, although wouldn't you generally want to rebase it on top of the
rewritten upstream in that case (which is what "pull --rebase" will do,
by scanning the reflog for the last version of the upstream that you
actually built on).
> There are also cases when I create a branch without upstream, or when
> upstream is renamed. Still, making "rebase -i --topic" == "rebase -i
> $(git merge-base HEAD @{upstream})" would be cool.
Yeah. I usually just do "rebase -i @{upstream}" which picks the same
commits, but moves to the updated version of upstream (IOW, I both
rewrite and move forward at the same time). But there is value in
rewriting without moving forward in many workflows. That seems like a
sensible feature to me.
-Peff
^ permalink raw reply
* Re: [PATCH] Python scripts audited for minimum compatible version and checks added.
From: Eric S. Raymond @ 2012-12-24 15:32 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git
In-Reply-To: <20121224133649.GA1400@padd.com>
Pete Wyckoff <pw@padd.com>:
> esr@thyrsus.com wrote on Thu, 20 Dec 2012 09:13 -0500:
> > diff --git a/git-p4.py b/git-p4.py
> > index 551aec9..ec060b4 100755
> > --- a/git-p4.py
> > +++ b/git-p4.py
> > @@ -12,6 +12,11 @@ import optparse, sys, os, marshal, subprocess, shelve
> > import tempfile, getopt, os.path, time, platform
> > import re, shutil
> >
> > +if sys.hexversion < 0x02040000:
> > + # The limiter is the subprocess module
> > + sys.stderr.write("git-p4.py: requires Python 2.4 or later.")
> > + sys.exit(1)
> > +
> > verbose = False
>
> If 2.3 does not have the subprocess module, this script will fail
> at the import, and not run your version test.
Yes, the import of subprocess should move to after the check.
> All the uses of sys.stderr.write() should probably include a
> newline. Presumably you used write instead of print to avoid
> 2to3 differences.
That is correct.
> The name of this particular script, as users would type it, is
> "git p4"; no dash and no ".py".
>
> Many of your changes have these three problems; I just picked on
> my favorite one.
Should I resubmit, or do you intend to fix these while merging?
> > diff --git a/git-remote-testgit.py b/git-remote-testgit.py
> > index 5f3ebd2..22d2eb6 100644
> > --- a/git-remote-testgit.py
> > +++ b/git-remote-testgit.py
> > @@ -31,6 +31,11 @@ from git_remote_helpers.git.exporter import GitExporter
> > from git_remote_helpers.git.importer import GitImporter
> > from git_remote_helpers.git.non_local import NonLocalGit
> >
> > +if sys.hexversion < 0x01050200:
> > + # os.makedirs() is the limiter
> > + sys.stderr.write("git-remote-testgit.py: requires Python 1.5.2 or later.")
> > + sys.exit(1)
> > +
>
> This one, though, is a bit of a lie because git_remote_helpers
> needs 2.4, and you add that version enforcement in the library.
Agreed. The goal here was simply to have the depedencies of the individual
scripts be clearly documented, and establish a practice for future
submitters to emulate.
> I assume what you're trying to do here is to make the
> version-related failures more explicit, rather than have users
> parse an ImportError traceback, e.g.
See above. At least half the point is making our dependencies
explicit rather than implicit, so we can make better policy
decisions.
> But what about the high-end of the version range? I'm pretty
> sure most of these scripts will throw syntax errors on >= 3.0,
> how should we catch that before users see it?
That's a problem for another day, when 3.x is more widely deployed.
I'd be willing to run 2to3 on these scripts and check forward
compatibility.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: GIT get corrupted on lustre
From: Brian J. Murrell @ 2012-12-24 15:11 UTC (permalink / raw)
To: git
In-Reply-To: <50D861EE.6020105@giref.ulaval.ca>
[-- Attachment #1: Type: text/plain, Size: 741 bytes --]
On 12-12-24 09:08 AM, Eric Chamberland wrote:
> Hi,
Hi,
> Doing a "git clone" always work fine, but when we "git pull" or "git gc"
> or "git fsck", often (1/5) the local repository get corrupted.
Have you tried adding a "-q" to the git command line to quiet down git's
"feedback" messages?
I discovered other oddities with using git on Lustre which I described
in this thread:
http://thread.gmane.org/gmane.comp.version-control.git/208886
I found that by simply disabling the feedback (which disables the
copious SIGALRM processing) I could alleviate the issue.
I wonder if your issues are more of the same.
I filed Lustre bug LU-2276 about it at:
http://jira.whamcloud.com/browse/LU-2276
Cheers,
b.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]
^ permalink raw reply
* Re: GIT get corrupted on lustre
From: Andreas Schwab @ 2012-12-24 14:48 UTC (permalink / raw)
To: Eric Chamberland; +Cc: git
In-Reply-To: <50D861EE.6020105@giref.ulaval.ca>
Eric Chamberland <Eric.Chamberland@giref.ulaval.ca> writes:
> #1) However, how can we *test* the filesystem (lustre) compatibility with
> git? (Is there a unit test we can run?)
Have you considered running git's testsuite?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* GIT get corrupted on lustre
From: Eric Chamberland @ 2012-12-24 14:08 UTC (permalink / raw)
To: git
Hi,
we are using git since may and all is working fine for all of us (almost
20 people) on our workstations. However, when we clone our repositories
to the cluster, only and only there
we are having many problems similiar to this post:
http://thread.gmane.org/gmane.comp.file-systems.lustre.user/12093
Doing a "git clone" always work fine, but when we "git pull" or "git gc"
or "git fsck", often (1/5) the local repository get corrupted.
for example, I got this error two days ago while doing "git gc":
error: index file .git/objects/pack/pack-7b43b1c613a851392aaf4f66916dff2577931576.idx is too small
error: refs/heads/mail_seekable does not point to a valid object!
also, I got this error 5 days ago:
error: index file .git/objects/pack/pack-ef9b5bbff1ebc1af63ef4262ade3e18b439c58af.idx is too small
error: refs/heads/mail_seekable does not point to a valid object!
Removing stale temporary file .git/objects/pack/tmp_pack_lO7aw2
and this one some time ago:
Removing stale temporary file .git/objects/pack/tmp_pack_5CHb2F
Removing stale temporary file .git/objects/pack/tmp_pack_GY159g
Removing stale temporary file .git/objects/pack/tmp_pack_aKkXTS
We are using git 1.8.0.1 on CentOS release 5.8 (Final).
We think it could be related to the fact that we are on a *Lustre*
filesystem, which I think doesn't fully support file locking.
Questions:
#1) However, how can we *test* the filesystem (lustre) compatibility
with git? (Is there a unit test we can run?)
#2) Is there a way to compile GIT to be compatible with lustre? (ex: no
threads?)
#3) If you *know* your filesystem doesn't allow file locking, how would
you configure/compile GIT to work on it?
#4) Anyone has another idea on how to solve this?
Thanks,
Eric
^ permalink raw reply
* Re: [PATCH] Python scripts audited for minimum compatible version and checks added.
From: Pete Wyckoff @ 2012-12-24 13:36 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: git
In-Reply-To: <20121220141855.05DAA44105@snark.thyrsus.com>
esr@thyrsus.com wrote on Thu, 20 Dec 2012 09:13 -0500:
> diff --git a/git-p4.py b/git-p4.py
> index 551aec9..ec060b4 100755
> --- a/git-p4.py
> +++ b/git-p4.py
> @@ -12,6 +12,11 @@ import optparse, sys, os, marshal, subprocess, shelve
> import tempfile, getopt, os.path, time, platform
> import re, shutil
>
> +if sys.hexversion < 0x02040000:
> + # The limiter is the subprocess module
> + sys.stderr.write("git-p4.py: requires Python 2.4 or later.")
> + sys.exit(1)
> +
> verbose = False
If 2.3 does not have the subprocess module, this script will fail
at the import, and not run your version test.
All the uses of sys.stderr.write() should probably include a
newline. Presumably you used write instead of print to avoid
2to3 differences.
The name of this particular script, as users would type it, is
"git p4"; no dash and no ".py".
Many of your changes have these three problems; I just picked on
my favorite one.
> diff --git a/git-remote-testgit.py b/git-remote-testgit.py
> index 5f3ebd2..22d2eb6 100644
> --- a/git-remote-testgit.py
> +++ b/git-remote-testgit.py
> @@ -31,6 +31,11 @@ from git_remote_helpers.git.exporter import GitExporter
> from git_remote_helpers.git.importer import GitImporter
> from git_remote_helpers.git.non_local import NonLocalGit
>
> +if sys.hexversion < 0x01050200:
> + # os.makedirs() is the limiter
> + sys.stderr.write("git-remote-testgit.py: requires Python 1.5.2 or later.")
> + sys.exit(1)
> +
This one, though, is a bit of a lie because git_remote_helpers
needs 2.4, and you add that version enforcement in the library.
I assume what you're trying to do here is to make the
version-related failures more explicit, rather than have users
parse an ImportError traceback, e.g. That seems somewhat useful
for people with ancient installs.
But what about the high-end of the version range? I'm pretty
sure most of these scripts will throw syntax errors on >= 3.0,
how should we catch that before users see it?
-- Pete
^ 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