Re: Using Eclipse git plugin

[Robin Rosenberg]

- 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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] stash: treat numerical arguments as shorthand for stash@{n}

[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 pe...@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

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] stash: treat numerical arguments as shorthand for stash@{n}

[Junio C Hamano]

Peter Collingbourne pe...@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 ?

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  (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.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bug in git status

[Michael Haggerty]

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
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git-prompt.sh vs leading white space in __git_ps1()::printf_format

[Junio C Hamano]

Simon Oosthoek s.oosth...@xs4all.nl writes:

 On 12/12/12 18:50, Junio C Hamano wrote:
 Simon Oosthoek s.oosth...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html