nike high heels online shop

[nmaore]

nike high heels online shop http://www.schuhenikewelt.de/nike-high-heels  
Flugreisen weitestgehend weiterhin wiedergeboren einmal mehr, die Ware
einige exquisite Leichtathletik nike air passt größten britischen Schuh
Layout werden. Wir haben gesehen, Nike geschieht zu tun brauchen in diesen
Tagen, dass Anbau und wollen zusätzlich ermutigen, herausspringen mit
modischen Nike SB Dous. Personen um die ganze Welt sind sehr fein bewusst,
den 3 Monaten Nike Komfort und Luxus. Sowohl alte und kleine Zuschauer
könnte die Marke sein. Nike hat bekam ständig auf der Innenseite der oberen
Positionierung gewesen, wegen der Anerkennung, die Errungenschaften der
viele Jahre. Nike Dip mit weltberühmten Jordan, rief die ausgezeichnete nach
dem Superstar. Diese Menschen wurden im Hinterkopf trägt weiter entlang der
Anerkennung der Basketball Teilnehmer, verzierte ihre Kleidung, um die
Bewegung nike air max Reise uk Schuhe oder Stiefel zu überprüfen, Nike Dunk
Design virtuelle Darstellungen von Personal und Alter. die machen zeitlos
und stilsicher privaten Eindrücke. Nike Dunks Fans entscheiden, welche
Marke, weil sie die Gedanken der Menschen zu denken. Große Vielfalt, ist es
in Multicolor-Leistungsmerkmale und zusätzlich Farben. Wird kommen die Art
und Weise einem Dip Nike Store oder spezielle Nike Dunks Websites. Nike
Franchisenehmer haben diese verschiedenen Auswahlen. Ist sicherlich nicht zu
jeder Art von Stil erscheinen und auch Komfort für Leute, die wollen, die
vollständig mit dem Nike Air Max Frisch 2013 ist konzentriert.
Ein Standard-Fehler, dass viele Kunden zu machen ist der Kauf aa Paar Nike
Air Max mit keinen Versuch folgenden so auf der Oberseite nach Hause findet,
die entweder kleine oder vielleicht auch zu groß. Es ist alles andere hilft,
all die harte Arbeit auf der Suche nach einem guten Paar erschweren. Nach
dem Abschluss des Tages, eine Person kann ihre verloren haben, ist, dass
alles kann schnell für mehr wurden vermieden nahmen ihre time.Other als
Typen gleichzeitig oben, unser Geschäft auch Materialien Nike Air Jordan und
Nike Air zusätzlich Push One. Was mehr ist, Nike Rift sowie die Firma Puma
Schuhe oder Stiefel ist auch eine der Alternativen in Betracht gezogen, um
Ihren Mangel zu erfüllen.
Der  nike high heels kaufen http://www.schuhenikewelt.de/nike-high-heels  
basteln geplanten Zyklus Hatfield und auch diese Jordan Schuhe kam heraus,
indem er eine neue Jumpman-Logo und. Diese ausgezeichnete Art der Jordan
Schuhe wurde durch 1992-1993 NBA-Zyklus eingeführt und diese Air Jordan
waren frei nur von einigen anderen wesentlichen Merkmale des Jordan III
starten eine Art offensichtlich Luft / Lüftung Abschnitt in sich die Ferse,
nutzen von stürzen Leder und zusätzlich Elefanten Beschriftung ordentlich.
Der Air Jordan VIII landete unter Berücksichtigung der Anteil an
flower-Kraft Air Jordan Schuhe sind wirklich vom Feinsten Veranstaltung
Jordan Schuhe der die ganze Zeit angenommen. Unter den wichtigsten Gründen
fahren die große Anerkennung von Air Jordans ist definitiv eine Neigung der
verschiedenen Arten von Jordan Schuhe eingeführt bisher. diese Air Jordan
wurden in 1991 min gebracht und teilten auch viele Ähnlichkeiten mit seinem
Vorgänger. Umwelt Jordan V-Sequenz sind vielleicht zu den wenigen
Unternehmen, Schuhe oder Stiefel, die diese Schuhe oder Stiefel
Angebotsabgabe jeden Kleinigkeit, die fast jedem High-Performance-Schuhe und
passiert muss von Tinker Hatfield gemeint sein.
Preiswert Authentic Air Jordan 4 Retro uk finden Sie im Internet gefunden
fühlen, unabhängig davon, ob Sie haben, um ein wenig schwerer zu entwerfen,
um sie zu finden. Einige dieser Geschäfte haben diese kleine Anzahl von AJ
Schuhe auf Lager, dass sie nicht genau das, was die überwiegende Mehrheit
der Air Jordan Schuh Kunden für suchen. Genau das, was die überwiegende
Mehrheit der Menschen die erste Wahl ist, muss Ihr ertragen Möglichkeit und
auch die von einer Shopping-Shop kaufen wird. Nike Air Jordan Basketball
Maximum Schuhe oder Stiefel aus der Arena langsam und allmählich
verändernden Identität geworden Nike Gesellschaft im alten Stil Flut Schuhe.
Aber Nike hat eine Menge von sehr starken Nike Jordan Schuhe oder Stiefel
Fans gebaut, so dass jedes Jahr die Einführung des neuen Designs. 2012 Nike
Air Jordan Basketball-Schuhe sind keine Ausnahme. Heute Xiaobian werfen Sie
einen Blick in der Besorgnis über die neuen 2012 Nike Air Jordan
Basketball-Schuhe oder Stiefel-olor, Auftraggeber Schatten Schuhe oder
Stiefel nähen Anleitung von AJ9 Generation Vamp Platzierung schönen Bogen,
so dass die Schuhe oder Stiefel kann nicht eintönig.
Erscheinungsbild Air Jordan Schuhe, was wir hier haben. Unser Unternehmen
Boy E von Top-Rack Sneakers konnte seine Hände eines lokalen Satz von der
Umwelt jordan 1 in der weißen / Rot / schwarzen Colorway ein wenig zu früh
zu bekommen. Von den Lesern Zeit allerersten erkannt unseren Rückseite im
Oktober, haben Einzelpersonen über die faux Verfärbung in der Sohle
beschäftigt. E liefert uns, 

Re: git log: Add a switch to limit the number of displayed lines from the commit messages

[Jonathan Nieder]

Junio C Hamano wrote:

 Or inside less that is spawned by git log -p, I often say this:

 /^commit .*|^diff --git .*ENTER

 and navigate with 'n' and 'p'.

Hm, that implies an interesting trick.  If I run

LESS='FRSX +/^commit |^diff --git ' git log -p

then 'n' and shift+'n' can be used for navigating without having to
spell out the /pattern to start by hand.
--
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 V3 1/4] git-mw: Introduction of GitMediawiki.pm

[Matthieu Moy]

Benoît Person benoit.per...@ensimag.fr writes:

 On 16 June 2013 22:18, Matthieu Moy matthieu@grenoble-inp.fr wrote:
 benoit.per...@ensimag.fr writes:

 changes from the V2:
   - Add a way to test, without installation, code that uses GitMediawiki.pm.

 This still needs to be documented, even very quickly, somewhere in the
 code (e.g a comment in the Makefile).
 Well, I think I will have to re-read some docs (and some earlier
 reviews) about what to write in commit messages, in the emails, in the
 code as comments and in the documentation ... I am just totally lost
 right now :/ .

Don't worry, reviews are meant to improve your code (present and
future), not to blame you ;-).

Just think about what you expect as a user or developer. Would you run
git log Makefile or git blame Makefile to know how to use the
Makefile? Commit messages are primarily meant for reviewers (here's
some code, and here's why it's good and why you should merge it), and
can be very useful when bisecting a regression or blaming a source file.

Right now, git-remote-mediawiki has only little doc, and the user manual
is hosted on a GitHub wiki, not in the source. So there's no ideal place 
to say how to use the tool as a developer, but a comment in the Makefile
should be OK.

 Also, it seems to be only part of the solution. With your change, from
 contrib/mw-to-git/ and after running only make,

 ./git-mw takes the installed version of GitMediawiki.pm in priority

 ../../bin-wrappers/git takes the installed version of git-mw only (i.e.
 does not know git mw if make install hasn't been ran).
 Same thing as the documentation point, I think I am a bit lost in that
 whole thing. I will re-look into it for the next version :/ .

In short, the include path should contain both the *.pm file and the
git-foo ones.

  perlcritic:
 - perlcritic -2 *.perl
 + perlcritic -2 *.perl
 \ No newline at end of file

 Please, avoid these whitespace-only changes. They create noise during
 review, and more potential conflicts.
 For that one, I don't know why git assumes there is a change in it :

I think you removed a newline from the end of the file. It's usually
considered good practice to have this trailing newline (e.g. so that
cat file in a terminal doesn't put your prompt after the last line).
IIRC, it's actually required to call the file a text file according to
POSIX.

 I will look into that for the next version ...

In any case, using git add -p and if needed its s command avoids
introducing unwanted things in the commit.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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] name-rev: Allow to omit refs/tags/ part in --refs option when --tags used

[Namhyung Kim]

In its current form, when an user wants to filter specific ref using
--refs option, she needs to give something like --refs=refs/tags/v1.*.

This is not intuitive as users might think it's enough to give just
actual tag name part like --refs=v1.*.  It applies to refs other than
just tags too.  Change it for users to be able to use --refs=sth or
--refs=remotes/sth.

Also remove the leading 'tags/' part in the output when --tags option
was given since the option restricts to work with tags only.  This is
what we have if --name-only option was given also.

Signed-off-by: Namhyung Kim namhyung@lge.com
---
 builtin/name-rev.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/builtin/name-rev.c b/builtin/name-rev.c
index 6238247..446743b 100644
--- a/builtin/name-rev.c
+++ b/builtin/name-rev.c
@@ -97,7 +97,8 @@ static int name_ref(const char *path, const unsigned char 
*sha1, int flags, void
if (data-tags_only  prefixcmp(path, refs/tags/))
return 0;
 
-   if (data-ref_filter  fnmatch(data-ref_filter, path, 0))
+   if (data-ref_filter  !prefixcmp(data-ref_filter, refs/)
+fnmatch(data-ref_filter, path, 0))
return 0;
 
while (o  o-type == OBJ_TAG) {
@@ -113,12 +114,15 @@ static int name_ref(const char *path, const unsigned char 
*sha1, int flags, void
if (!prefixcmp(path, refs/heads/))
path = path + 11;
else if (data-tags_only
-data-name_only
 !prefixcmp(path, refs/tags/))
path = path + 10;
else if (!prefixcmp(path, refs/))
path = path + 5;
 
+   if (data-ref_filter  prefixcmp(data-ref_filter, refs/)
+fnmatch(data-ref_filter, path, 0))
+   return 0;
+
name_rev(commit, xstrdup(path), 0, 0, deref);
}
return 0;
-- 
1.7.11.7

--
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] rebase -i: fixup fixup! fixup!

[Thomas Rast]

Junio C Hamano gits...@pobox.com writes:

 Thomas Rast tr...@inf.ethz.ch writes:

 Isn't it a bit of an academic question?
 ...
 And once you have that, it seems a nicer and cleaner idea to generate
 'fixup! A' each time, instead of a successive sequence of

   fixup! A
   fixup! fixup! A
   fixup! fixup! fixup! A
   ...

 As to reordering, you are absolutely correct.
[...]
 Does dropping these leading fixup! (or squash!) at commit time
 make the application in rebase -i --autosquash significantly
 easier to do?

Conveniently enough we have seen both already ;-)  Andrew's version for
commit.c could use a bit of refactorization, since it inserts the same
code in two places, but then it's about the same complexity as the
change for rebase.

I'm not sure it's worth arguing about whether the fixup! fixup!  is a
symptom of some underlying problem, and changing rebase is only tapering
over the symptom; or whether it's actually a useful distinction.  Either
one works fine as a fix for an annoyance that Andrew had, and that bit
me in the past too.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
--
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 v2 0/6] --valgrind improvements

[Thomas Rast]

Here's the promised reroll.  It integrates everyone's suggestions (I
hope I didn't miss any), most notably the two by Peff:

* --valgrind-parallel only does the valgrind wrapper setup in the
  children, avoiding lock contention and confusion because it tries to
  wrap the wrappers.

* more careful --verbose-only toggling (with some extra care about the
  blank lines in between)



Thomas Rast (6):
  test-lib: enable MALLOC_* for the actual tests
  test-lib: refactor $GIT_SKIP_TESTS matching
  test-lib: verbose mode for only tests matching a pattern
  test-lib: valgrind for only tests matching a pattern
  test-lib: allow prefixing a custom string before ok N etc.
  test-lib: support running tests under valgrind in parallel

 t/README|  10 ++
 t/test-lib-functions.sh |   2 +
 t/test-lib.sh   | 248 ++--
 t/valgrind/valgrind.sh  |   3 +
 4 files changed, 213 insertions(+), 50 deletions(-)

-- 
1.8.3.1.530.g6f90e57

--
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 v2 2/6] test-lib: refactor $GIT_SKIP_TESTS matching

[Thomas Rast]

It's already used twice, and we will have more of the same kind of
matching in a minute.

Signed-off-by: Thomas Rast tr...@inf.ethz.ch
---
 t/test-lib.sh | 41 -
 1 file changed, 24 insertions(+), 17 deletions(-)

diff --git a/t/test-lib.sh b/t/test-lib.sh
index 35da859..d9a74ff 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -328,6 +328,20 @@ test_debug () {
test $debug =  || eval $1
 }
 
+match_pattern_list () {
+   arg=$1
+   shift
+   test -z $*  return 1
+   for pat
+   do
+   case $arg in
+   $pat)
+   return 0
+   esac
+   done
+   return 1
+}
+
 test_eval_ () {
# This is a separate function because some tests use
# return to end a test_expect_success block early.
@@ -358,14 +372,10 @@ test_run_ () {
 test_skip () {
test_count=$(($test_count+1))
to_skip=
-   for skp in $GIT_SKIP_TESTS
-   do
-   case $this_test.$test_count in
-   $skp)
-   to_skip=t
-   break
-   esac
-   done
+   if match_pattern_list $this_test.$test_count $GIT_SKIP_TESTS
+   then
+   to_skip=t
+   fi
if test -z $to_skip  test -n $test_prereq 
   ! test_have_prereq $test_prereq
then
@@ -630,15 +640,12 @@ cd -P $TRASH_DIRECTORY || exit 1
 
 this_test=${0##*/}
 this_test=${this_test%%-*}
-for skp in $GIT_SKIP_TESTS
-do
-   case $this_test in
-   $skp)
-   say_color info 3 skipping test $this_test altogether
-   skip_all=skip all tests in $this_test
-   test_done
-   esac
-done
+if match_pattern_list $this_test $GIT_SKIP_TESTS
+then
+   say_color info 3 skipping test $this_test altogether
+   skip_all=skip all tests in $this_test
+   test_done
+fi
 
 # Provide an implementation of the 'yes' utility
 yes () {
-- 
1.8.3.1.530.g6f90e57

--
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 v2 5/6] test-lib: allow prefixing a custom string before ok N etc.

[Thomas Rast]

This is not really meant for external use, and thus not documented. It
allows the next commit to neatly distinguish between sub-tests and the
main run.

The format is intentionally not valid TAP.  The use in the next commit
would not result in anything valid either way, and it seems better to
make it obvious.

Signed-off-by: Thomas Rast tr...@inf.ethz.ch
---
 t/test-lib.sh | 27 +++
 1 file changed, 15 insertions(+), 12 deletions(-)

diff --git a/t/test-lib.sh b/t/test-lib.sh
index 40bd7da..aaf6084 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -209,6 +209,9 @@ do
--root=*)
root=$(expr z$1 : 'z[^=]*=\(.*\)')
shift ;;
+   --statusprefix=*)
+   statusprefix=$(expr z$1 : 'z[^=]*=\(.*\)')
+   shift ;;
*)
echo error: unknown test option '$1' 2; exit 1 ;;
esac
@@ -316,12 +319,12 @@ trap 'die' EXIT
 
 test_ok_ () {
test_success=$(($test_success + 1))
-   say_color  ok $test_count - $@
+   say_color  ${statusprefix}ok $test_count - $@
 }
 
 test_failure_ () {
test_failure=$(($test_failure + 1))
-   say_color error not ok $test_count - $1
+   say_color error ${statusprefix}not ok $test_count - $1
shift
echo $@ | sed -e 's/^/#   /'
test $immediate =  || { GIT_EXIT_OK=t; exit 1; }
@@ -329,12 +332,12 @@ test_failure_ () {
 
 test_known_broken_ok_ () {
test_fixed=$(($test_fixed+1))
-   say_color error ok $test_count - $@ # TODO known breakage vanished
+   say_color error ${statusprefix}ok $test_count - $@ # TODO known 
breakage vanished
 }
 
 test_known_broken_failure_ () {
test_broken=$(($test_broken+1))
-   say_color warn not ok $test_count - $@ # TODO known breakage
+   say_color warn ${statusprefix}not ok $test_count - $@ # TODO known 
breakage
 }
 
 test_debug () {
@@ -460,8 +463,8 @@ test_skip () {
of_prereq= of $test_prereq
fi
 
-   say_color skip 3 skipping test: $@
-   say_color skip ok $test_count # skip $1 (missing 
$missing_prereq${of_prereq})
+   say_color skip 3 ${statusprefix}skipping test: $@
+   say_color skip ${statusprefix}ok $test_count # skip $1 
(missing $missing_prereq${of_prereq})
: true
;;
*)
@@ -497,11 +500,11 @@ test_done () {
 
if test $test_fixed != 0
then
-   say_color error # $test_fixed known breakage(s) vanished; 
please update test(s)
+   say_color error ${statusprefix}# $test_fixed known breakage(s) 
vanished; please update test(s)
fi
if test $test_broken != 0
then
-   say_color warn # still have $test_broken known breakage(s)
+   say_color warn ${statusprefix}# still have $test_broken known 
breakage(s)
fi
if test $test_broken != 0 || test $test_fixed != 0
then
@@ -524,9 +527,9 @@ test_done () {
then
if test $test_remaining -gt 0
then
-   say_color pass # passed all $msg
+   say_color pass ${statusprefix}# passed all 
$msg
fi
-   say 1..$test_count$skip_all
+   say ${statusprefix}1..$test_count$skip_all
fi
 
test -d $remove_trash 
@@ -540,8 +543,8 @@ test_done () {
*)
if test $test_external_has_tap -eq 0
then
-   say_color error # failed $test_failure among $msg
-   say 1..$test_count
+   say_color error ${statusprefix}# failed $test_failure 
among $msg
+   say ${statusprefix}1..$test_count
fi
 
exit 1 ;;
-- 
1.8.3.1.530.g6f90e57

--
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 v2 4/6] test-lib: valgrind for only tests matching a pattern

[Thomas Rast]

With the new --valgrind-only=pattern option, one can enable
--valgrind at a per-test granularity, exactly analogous to
--verbose-only from the previous commit.

The options are wired such that --valgrind implies --verbose (as
before), but --valgrind-only=pattern implies
--verbose-only=pattern unless --verbose is also in effect.

Signed-off-by: Thomas Rast tr...@inf.ethz.ch
---
 t/README   |  5 +
 t/test-lib.sh  | 36 +++-
 t/valgrind/valgrind.sh |  3 +++
 3 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/t/README b/t/README
index f4e6299..abe991f 100644
--- a/t/README
+++ b/t/README
@@ -126,6 +126,11 @@ appropriately before running make.
the 't/valgrind/' directory and use the commands under
't/valgrind/bin/'.
 
+--valgrind-only=pattern::
+   Like --valgrind, but the effect is limited to tests with
+   numbers matching pattern.  The number matched against is
+   simply the running count of the test within the file.
+
 --tee::
In addition to printing the test output to the terminal,
write it to files named 't/test-results/$TEST_NAME.out'.
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 84e5f03..40bd7da 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -201,6 +201,9 @@ do
--valgrind=*)
valgrind=$(expr z$1 : 'z[^=]*=\(.*\)')
shift ;;
+   --valgrind-only=*)
+   valgrind_only=$(expr z$1 : 'z[^=]*=\(.*\)')
+   shift ;;
--tee)
shift ;; # was handled already
--root=*)
@@ -211,7 +214,14 @@ do
esac
 done
 
-test -n $valgrind  verbose=t
+if test -n $valgrind_only
+then
+   test -z $valgrind  valgrind=memcheck
+   test -z $verbose  verbose_only=$valgrind_only
+elif test -n $valgrind
+then
+   verbose=t
+fi
 
 if test -n $color
 then
@@ -371,15 +381,36 @@ maybe_setup_verbose () {
last_verbose=$verbose
 }
 
+maybe_teardown_valgrind () {
+   test -z $GIT_VALGRIND  return
+   GIT_VALGRIND_ENABLED=
+}
+
+maybe_setup_valgrind () {
+   test -z $GIT_VALGRIND  return
+   if test -z $valgrind_only
+   then
+   GIT_VALGRIND_ENABLED=t
+   return
+   fi
+   GIT_VALGRIND_ENABLED=
+   if match_pattern_list $test_count $valgrind_only
+   then
+   GIT_VALGRIND_ENABLED=t
+   fi
+}
+
 # Called from test_skip after it has incremented $test_count.  This
 # means it runs before any test-specific code and output.
 test_setup_hook_ () {
maybe_setup_verbose
+   maybe_setup_valgrind
 }
 
 # Called at the end of test_expect_*.  This means it runs after all
 # test-specific code and output.
 test_teardown_hook_ () {
+   maybe_teardown_valgrind
maybe_teardown_verbose
 }
 
@@ -590,6 +621,9 @@ then
export GIT_VALGRIND
GIT_VALGRIND_MODE=$valgrind
export GIT_VALGRIND_MODE
+   GIT_VALGRIND_ENABLED=t
+   test -n $valgrind_only  GIT_VALGRIND_ENABLED=
+   export GIT_VALGRIND_ENABLED
 elif test -n $GIT_TEST_INSTALLED
 then
GIT_EXEC_PATH=$($GIT_TEST_INSTALLED/git --exec-path)  ||
diff --git a/t/valgrind/valgrind.sh b/t/valgrind/valgrind.sh
index 6b87c91..4215303 100755
--- a/t/valgrind/valgrind.sh
+++ b/t/valgrind/valgrind.sh
@@ -4,6 +4,9 @@ base=$(basename $0)
 
 TOOL_OPTIONS='--leak-check=no'
 
+test -z $GIT_VALGRIND_ENABLED 
+exec $GIT_VALGRIND/../../$base $@
+
 case $GIT_VALGRIND_MODE in
 memcheck-fast)
;;
-- 
1.8.3.1.530.g6f90e57

--
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 v2 1/6] test-lib: enable MALLOC_* for the actual tests

[Thomas Rast]

1b3185f (MALLOC_CHECK: various clean-ups, 2012-09-14) moved around the
MALLOC_CHECK_ and MALLOC_PERTURB_ assignments, intending to limit
their effect to only the test runs.  However, they were actually
enabled only during test cleanup.  Call setup/teardown_malloc_check
also around the evaluation of the actual test snippet.

Signed-off-by: Thomas Rast tr...@inf.ethz.ch
---
 t/test-lib.sh | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/t/test-lib.sh b/t/test-lib.sh
index eff3a65..35da859 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -337,8 +337,10 @@ test_eval_ () {
 test_run_ () {
test_cleanup=:
expecting_failure=$2
+   setup_malloc_check
test_eval_ $1
eval_ret=$?
+   teardown_malloc_check
 
if test -z $immediate || test $eval_ret = 0 || test -n 
$expecting_failure
then
-- 
1.8.3.1.530.g6f90e57

--
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 v2 3/6] test-lib: verbose mode for only tests matching a pattern

[Thomas Rast]

With the new --verbose-only=pattern option, one can enable --verbose
at a per-test granularity.  The pattern is matched against the test
number, e.g.

  ./t-basic.sh --verbose-only='2[0-2]'

to see only the full output of test 20-22, while showing the rest in the
one-liner format.

As suggested by Jeff King, this takes care to wrap the entire test_expect_*
block, but nothing else, in the verbose toggling.  To that end we use
a new pair of hook functions.  The placement is a bit weird because we
need to wait until the beginning of test_skip for $test_count to be
incremented.

This is arguably not *too* useful on its own, but makes the next patch
easier to follow.

Helped-by: Jeff King p...@peff.net
Signed-off-by: Thomas Rast tr...@inf.ethz.ch
---
 t/README|  5 +
 t/test-lib-functions.sh |  2 ++
 t/test-lib.sh   | 44 ++--
 3 files changed, 49 insertions(+), 2 deletions(-)

diff --git a/t/README b/t/README
index 35b3c5c..f4e6299 100644
--- a/t/README
+++ b/t/README
@@ -76,6 +76,11 @@ appropriately before running make.
command being run and their output if any are also
output.
 
+--verbose-only=pattern::
+   Like --verbose, but the effect is limited to tests with
+   numbers matching pattern.  The number matched against is
+   simply the running count of the test within the file.
+
 --debug::
This may help the person who is developing a new test.
It causes the command defined with test_debug to run.
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index 5251009..0eac1dd 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -358,6 +358,7 @@ test_expect_failure () {
fi
fi
echo 3 
+   test_teardown_hook_
 }
 
 test_expect_success () {
@@ -376,6 +377,7 @@ test_expect_success () {
fi
fi
echo 3 
+   test_teardown_hook_
 }
 
 # test_external runs external test scripts that provide continuous
diff --git a/t/test-lib.sh b/t/test-lib.sh
index d9a74ff..84e5f03 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -184,6 +184,9 @@ do
help=t; shift ;;
-v|--v|--ve|--ver|--verb|--verbo|--verbos|--verbose)
verbose=t; shift ;;
+   --verbose-only=*)
+   verbose_only=$(expr z$1 : 'z[^=]*=\(.*\)')
+   shift ;;
-q|--q|--qu|--qui|--quie|--quiet)
# Ignore --quiet under a TAP::Harness. Saying how many tests
# passed without the ok/not ok details is always an error.
@@ -342,6 +345,44 @@ match_pattern_list () {
return 1
 }
 
+maybe_teardown_verbose () {
+   test -z $verbose_only  return
+   exec 4/dev/null 3/dev/null
+   verbose=
+}
+
+last_verbose=t
+maybe_setup_verbose () {
+   test -z $verbose_only  return
+   if match_pattern_list $test_count $verbose_only
+   then
+   exec 42 31
+   # Emit a delimiting blank line when going from
+   # non-verbose to verbose.  Within verbose mode the
+   # delimiter is printed by test_expect_*.  The choice
+   # of the initial $last_verbose is such that before
+   # test 1, we do not print it.
+   test -z $last_verbose  echo 3 
+   verbose=t
+   else
+   exec 4/dev/null 3/dev/null
+   verbose=
+   fi
+   last_verbose=$verbose
+}
+
+# Called from test_skip after it has incremented $test_count.  This
+# means it runs before any test-specific code and output.
+test_setup_hook_ () {
+   maybe_setup_verbose
+}
+
+# Called at the end of test_expect_*.  This means it runs after all
+# test-specific code and output.
+test_teardown_hook_ () {
+   maybe_teardown_verbose
+}
+
 test_eval_ () {
# This is a separate function because some tests use
# return to end a test_expect_success block early.
@@ -358,9 +399,7 @@ test_run_ () {
 
if test -z $immediate || test $eval_ret = 0 || test -n 
$expecting_failure
then
-   setup_malloc_check
test_eval_ $test_cleanup
-   teardown_malloc_check
fi
if test $verbose = t  test -n $HARNESS_ACTIVE
then
@@ -372,6 +411,7 @@ test_run_ () {
 test_skip () {
test_count=$(($test_count+1))
to_skip=
+   test_setup_hook_
if match_pattern_list $this_test.$test_count $GIT_SKIP_TESTS
then
to_skip=t
-- 
1.8.3.1.530.g6f90e57

--
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 v2 6/6] test-lib: support running tests under valgrind in parallel

[Thomas Rast]

With the new --valgrind-parallel=n option, we support running the
tests in a single test script under valgrind in parallel using 'n'
processes.

This really follows the dumbest approach possible, as follows:

* We spawn the test script 'n' times, using a throw-away
  TEST_OUTPUT_DIRECTORY.  Each of the instances is given options that
  ensures that it only runs every n-th test under valgrind, but
  together they cover the entire range.

* We add up the numbers from the individual tests, and provide the
  usual output.

This is really a gross hack at this point, and should be improved.  In
particular we should keep the actual outputs somewhere more easily
discoverable, and summarize them to the user.

Nevertheless, this is already workable and gives a speedup of more
than 2 on a dual-core (hyperthreaded) machine, using n=4.  This is
expected since the overhead of valgrind is so big (on the order of 20x
under good conditions, and a large startup overhead at every git
invocation) that redundantly running the non-valgrind tests in between
is not that expensive.

Helped-by: Jeff King p...@peff.net
Signed-off-by: Thomas Rast tr...@inf.ethz.ch
---
 t/test-lib.sh | 106 ++
 1 file changed, 84 insertions(+), 22 deletions(-)

diff --git a/t/test-lib.sh b/t/test-lib.sh
index aaf6084..ca293c6 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -204,6 +204,15 @@ do
--valgrind-only=*)
valgrind_only=$(expr z$1 : 'z[^=]*=\(.*\)')
shift ;;
+   --valgrind-parallel=*)
+   valgrind_parallel=$(expr z$1 : 'z[^=]*=\(.*\)')
+   shift ;;
+   --valgrind-only-stride=*)
+   valgrind_only_stride=$(expr z$1 : 'z[^=]*=\(.*\)')
+   shift ;;
+   --valgrind-only-offset=*)
+   valgrind_only_offset=$(expr z$1 : 'z[^=]*=\(.*\)')
+   shift ;;
--tee)
shift ;; # was handled already
--root=*)
@@ -217,7 +226,7 @@ do
esac
 done
 
-if test -n $valgrind_only
+if test -n $valgrind_only || test -n $valgrind_only_stride
 then
test -z $valgrind  valgrind=memcheck
test -z $verbose  verbose_only=$valgrind_only
@@ -367,7 +376,9 @@ maybe_teardown_verbose () {
 last_verbose=t
 maybe_setup_verbose () {
test -z $verbose_only  return
-   if match_pattern_list $test_count $verbose_only
+   if match_pattern_list $test_count $verbose_only ||
+   { test -n $valgrind_only_stride 
+   expr $test_count % $valgrind_only_stride - 
$valgrind_only_offset = 0 /dev/null; }
then
exec 42 31
# Emit a delimiting blank line when going from
@@ -391,7 +402,7 @@ maybe_teardown_valgrind () {
 
 maybe_setup_valgrind () {
test -z $GIT_VALGRIND  return
-   if test -z $valgrind_only
+   if test -z $valgrind_only  test -z $valgrind_only_stride
then
GIT_VALGRIND_ENABLED=t
return
@@ -400,6 +411,10 @@ maybe_setup_valgrind () {
if match_pattern_list $test_count $valgrind_only
then
GIT_VALGRIND_ENABLED=t
+   elif test -n $valgrind_only_stride 
+   expr $test_count % $valgrind_only_stride - 
$valgrind_only_offset = 0 /dev/null
+   then
+   GIT_VALGRIND_ENABLED=t
fi
 }
 
@@ -552,6 +567,9 @@ test_done () {
esac
 }
 
+
+# Set up a directory that we can put in PATH which redirects all git
+# calls to 'valgrind git ...'.
 if test -n $valgrind
 then
make_symlink () {
@@ -599,33 +617,42 @@ then
make_symlink $symlink_target $GIT_VALGRIND/bin/$base || exit
}
 
-   # override all git executables in TEST_DIRECTORY/..
-   GIT_VALGRIND=$TEST_DIRECTORY/valgrind
-   mkdir -p $GIT_VALGRIND/bin
-   for file in $GIT_BUILD_DIR/git* $GIT_BUILD_DIR/test-*
-   do
-   make_valgrind_symlink $file
-   done
-   # special-case the mergetools loadables
-   make_symlink $GIT_BUILD_DIR/mergetools $GIT_VALGRIND/bin/mergetools
-   OLDIFS=$IFS
-   IFS=:
-   for path in $PATH
-   do
-   ls $path/git-* 2 /dev/null |
-   while read file
+   # In the case of --valgrind-parallel, we only need to do the
+   # wrapping once, in the main script.  The worker children all
+   # have $valgrind_only_stride set, so we can skip based on that.
+   if test -z $valgrind_stride
+   then
+   # override all git executables in TEST_DIRECTORY/..
+   GIT_VALGRIND=$TEST_DIRECTORY/valgrind
+   mkdir -p $GIT_VALGRIND/bin
+   for file in $GIT_BUILD_DIR/git* $GIT_BUILD_DIR/test-*
do
-   make_valgrind_symlink $file
+   make_valgrind_symlink $file
done
-   done
-   IFS=$OLDIFS
+   # special-case the mergetools loadables
+   

[PATCH] [submodule] Remove duplicate call to set_rev_name

[Fredrik Gustafsson]

set_rev_name is a possible expensive operation. If a submodule has
changes in it, set_rev_name was called twice.

Solution is to move set_rev_name so it's only called once, no matter the
codepath taken.

Signed-off-by: Fredrik Gustafsson iv...@iveqy.com
---
 git-submodule.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/git-submodule.sh b/git-submodule.sh
index 79bfaac..75feaf1 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -1129,16 +1129,16 @@ cmd_status()
say -$sha1 $displaypath
continue;
fi
-   set_name_rev $sm_path $sha1
if git diff-files --ignore-submodules=dirty --quiet -- 
$sm_path
then
+   set_name_rev $sm_path $sha1
say  $sha1 $displaypath$revname
else
if test -z $cached
then
sha1=$(clear_local_git_env; cd $sm_path  
git rev-parse --verify HEAD)
-   set_name_rev $sm_path $sha1
fi
+   set_name_rev $sm_path $sha1
say +$sha1 $displaypath$revname
fi
 
-- 
1.8.0

--
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

Git pull silently removing files in the index

[Stefan Schüßler]

I think there's a bug in git pull. Doing a git pull in a fresh repository 
without any commits removes files in the index.

Example:

  $ mkdir foo 
  $ cd foo
  $ git init
  $ touch file1 file2
  $ git add file1
  $ ls
  file1 file2
  $ git pull https://github.com/sos4nt/empty.git master
  $ ls
  file2

file2 is still there, but file1 was silently removed and no error message 
was shown.

I'm running git 1.8.3.1

Cheers, Stefan--
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] config doc: rewrite push.default section

[Matthieu Moy]

Junio C Hamano gits...@pobox.com writes:

 +* `matching` - push the refspec :.  In other words, push all
 +  branches having the same name in both ends, even if it means
 +  non-fast-forward updates.  This is for those who prepare all the
 +  branches into a publishable shape and then push them out with a
 +  single command.  Dangerous, and inappropriate unless you are the
 +  only person updating your push destination.

 It was already pointed out that unnecessary negativity needs to be
 fixed, but more importantly the above Dangerous is not even
 correct.

What's really dangerous is the --force flag. A few weeks ago I had to
help a colleague who did a git push --force to update his branch, and
he lost data on his co-worker's branches (thanks to git reflog, it
wasn't an actual data loss, but still pretty bad).

But then the place to warn loudly is the doc for --force. What about
this?

--- 8 --- 8 --- 8 --- 8 --- 8 --- 8 

From a529588dd8df84e54e5ec267068248cc555373f5 Mon Sep 17 00:00:00 2001
From: Matthieu Moy matthieu@imag.fr
Date: Mon, 17 Jun 2013 13:02:39 +0200
Subject: [PATCH] Documentation/git-push.txt: explain better cases where
 --force is dangerous

The behavior of git push --force is rather clear when it updates only
one remote ref, but running it when pushing several branches can really
be dangerous. Warn the users a bit more and give them the alternative to
push only one branch.

Signed-off-by: Matthieu Moy matthieu@imag.fr
---
 Documentation/git-push.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 938d1ee..0899a35 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -136,6 +136,13 @@ already exists on the remote side.
not an ancestor of the local ref used to overwrite it.
This flag disables the check.  This can cause the
remote repository to lose commits; use it with care.
+   Note that `--force` applies to all the refs that are pushed,
+   hence using `git push --all --force`, or `git push --force`
+   with `push.default` set to `matching` may override refs other
+   than the current branch (including local refs that are
+   strictly behind their remote counterpart). To force a push to
+   only one branch, use `git push remote +branch` instead of
+   `--force`.
 
 --repo=repository::
This option is only relevant if no repository argument is
-- 
1.8.3.1.495.g13f33cf.dirty


-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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] status: display the SHA1 of the commit being currently processed

[Mathieu Lienard--Mayor]

When in the middle of a rebase, it can be annoying to go in .git
in order to find the SHA1 of the commit where the rebase stopped.

git-status now includes this information in its default output.
With this new information, the message is now shorter, to avoid
too long lines.

The new message looks like:
$ git status
 HEAD detached from 33e516f
 Editing c346c87 while rebasing branch 'rebase_i_edit' on 'f90e540'.

Signed-off-by: Mathieu Lienard--Mayor mathieu.lienard--ma...@ensimag.imag.fr
Signed-off-by: Jorge Juan Garcia Garcia 
jorge-juan.garcia-gar...@ensimag.imag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---

 -changes in the tests to match the new status output
 -read file rebase-merge/stopped_sha to include the SHA in status output

 t/t7512-status-help.sh |   36 
 wt-status.c|   25 +
 2 files changed, 45 insertions(+), 16 deletions(-)

diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh
index bf08d4e..dc93d77 100755
--- a/t/t7512-status-help.sh
+++ b/t/t7512-status-help.sh
@@ -189,10 +189,11 @@ test_expect_success 'status when rebasing -i in edit 
mode' '
test_when_finished git rebase --abort 
ONTO=$(git rev-parse --short HEAD~2) 
TGT=$(git rev-parse --short two_rebase_i) 
+   SHA=$(git rev-parse --short three_rebase_i) 
git rebase -i HEAD~2 
cat expected -EOF 
# HEAD detached from $TGT
-   # You are currently editing a commit while rebasing branch 
'\''rebase_i_edit'\'' on '\''$ONTO'\''.
+   # Editing $SHA while rebasing branch '\''rebase_i_edit'\'' on 
'\''$ONTO'\''.
#   (use git commit --amend to amend the current commit)
#   (use git rebase --continue once you are satisfied with your 
changes)
#
@@ -217,9 +218,10 @@ test_expect_success 'status when splitting a commit' '
git rebase -i HEAD~3 
git reset HEAD^ 
TGT=$(git rev-parse --short HEAD) 
+   SHA=$(git rev-parse --short three_split) 
cat expected -EOF 
# HEAD detached at $TGT
-   # You are currently splitting a commit while rebasing branch 
'\''split_commit'\'' on '\''$ONTO'\''.
+   # Splitting $SHA while rebasing branch '\''split_commit'\'' on 
'\''$ONTO'\''.
#   (Once your working directory is clean, run git rebase --continue)
#
# Changes not staged for commit:
@@ -247,11 +249,12 @@ test_expect_success 'status after editing the last commit 
with --amend during a
test_when_finished git rebase --abort 
ONTO=$(git rev-parse --short HEAD~3) 
TGT=$(git rev-parse --short three_amend) 
+   SHA=$(git rev-parse --short four_amend) 
git rebase -i HEAD~3 
git commit --amend -m foo 
cat expected -EOF 
# HEAD detached from $TGT
-   # You are currently editing a commit while rebasing branch 
'\''amend_last'\'' on '\''$ONTO'\''.
+   # Editing $SHA while rebasing branch '\''amend_last'\'' on 
'\''$ONTO'\''.
#   (use git commit --amend to amend the current commit)
#   (use git rebase --continue once you are satisfied with your 
changes)
#
@@ -277,11 +280,12 @@ test_expect_success 'status: (continue first edit) second 
edit' '
export FAKE_LINES 
test_when_finished git rebase --abort 
ONTO=$(git rev-parse --short HEAD~3) 
+   SHA=$(git rev-parse --short three_edits) 
git rebase -i HEAD~3 
git rebase --continue 
cat expected -EOF 
# HEAD detached from $ONTO
-   # You are currently editing a commit while rebasing branch 
'\''several_edits'\'' on '\''$ONTO'\''.
+   # Editing $SHA while rebasing branch '\''several_edits'\'' on 
'\''$ONTO'\''.
#   (use git commit --amend to amend the current commit)
#   (use git rebase --continue once you are satisfied with your 
changes)
#
@@ -298,12 +302,13 @@ test_expect_success 'status: (continue first edit) second 
edit and split' '
export FAKE_LINES 
test_when_finished git rebase --abort 
ONTO=$(git rev-parse --short HEAD~3) 
+   SHA=$(git rev-parse --short three_edits) 
git rebase -i HEAD~3 
git rebase --continue 
git reset HEAD^ 
cat expected -EOF 
# HEAD detached from $ONTO
-   # You are currently splitting a commit while rebasing branch 
'\''several_edits'\'' on '\''$ONTO'\''.
+   # Splitting $SHA while rebasing branch '\''several_edits'\'' on 
'\''$ONTO'\''.
#   (Once your working directory is clean, run git rebase --continue)
#
# Changes not staged for commit:
@@ -325,12 +330,13 @@ test_expect_success 'status: (continue first edit) second 
edit and amend' '
export FAKE_LINES 
test_when_finished git rebase --abort 
ONTO=$(git rev-parse --short HEAD~3) 
+   SHA=$(git rev-parse --short three_edits) 
git rebase -i HEAD~3 
git rebase --continue 
   

Re: [PATCH] status: display the SHA1 of the commit being currently processed

[Thomas Adam]

Hi,

[I rarely do reviews on this list, so feel free to ignore this.]

On 17 June 2013 13:10, Mathieu Lienard--Mayor
mathieu.lienard--ma...@ensimag.imag.fr wrote:
 diff --git a/wt-status.c b/wt-status.c
 index bf84a86..5f5cddf 100644
 --- a/wt-status.c
 +++ b/wt-status.c
 @@ -885,8 +885,19 @@ static void show_rebase_in_progress(struct wt_status *s,
 struct wt_status_state *state,
 const char *color)
  {
 +   char *stopped_sha = 
 read_line_from_git_path(rebase-merge/stopped-sha);
 +   int must_free_stopped_sha = 1;
 struct stat st;

 +   /*
 +* If the file stopped-sha does not exist
 +* we go back to the old output saying a commit
 +* instead of providing the commit's SHA1.
 +*/
 +   if (!stopped_sha) {
 +   stopped_sha = a commit;
 +   must_free_stopped_sha = 0;
 +   }

Rather than having to assign a toggle of deciding when to free
stopped_sha, how much overhead would be introduced by just doing:

if (!stopped_sha)
stopped_sha = strdup(a commit);

And then at the end just do:

free (stopped_sha);

Just a thought.

-- Thomas Adam
--
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] status: display the SHA1 of the commit being currently processed

[Peter Krefting]

Mathieu Lienard--Mayor:


+   /*
+* If the file stopped-sha does not exist
+* we go back to the old output saying a commit
+* instead of providing the commit's SHA1.
+*/
+   if (!stopped_sha) {
+   stopped_sha = a commit;
+   must_free_stopped_sha = 0;
+   }


This is missing gettext markers, and besides that, it very difficult 
to handle for translators. Please consider changing the code to use 
different strings based on what you want to insert, i.e.:



if (state-branch)
status_printf_ln(s, color,
-_(You are currently splitting a commit 
while rebasing branch '%s' on '%s'.),
+(Splitting %s while rebasing branch '%s' 
on '%s'.),


   stopped_sha ? _(Splitting %s while rebasing branch '%s' on '%s'.)
   : _(Splitting a commit while rebasing branch '%2$s' on '%3$s'.)

or something similar.

--
\\// Peter - http://www.softwolves.pp.se/
--
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 error

[justin.sathyanathan]

Hi,
For Below issue , O/S is Windows7.

Regards,
Justin,
---
Sun Certified Enterprise Architect for Java EE platform | Certified TA | Java 
Capability | Accenture- India Delivery Center
AIM: justinsprabhu| +91-80-40771095 (w)|+91-9611804388 (m)
https://collaboration.accenture.com/javaportal | https://aal.accenture.com

-Original Message-
From: Sathyanathan, Justin
Sent: Monday, June 17, 2013 6:51 PM
To: 'git@vger.kernel.org'
Subject: RE: GIt error



Hi,

1.Iam getting error attached when cloning of repository is done:



2.Also, when file is tried to be added,it gives error below:

$ git add *
fatal: unable to stat 'src/development_architecture/integration_application_proj
ect_template/provider_archetype/provider_archetype/src/main/resources/archetype-
resources/__rootArtifactId__-data/src/main/java/com/accenture/afpj/sample/skelet
on/visitor/data/VisitorRepositoryJpaImpl.java': Filename too long

Request you to help to resolve same asap as it is affecting the project.
Regards,
Justin,
---
Sun Certified Enterprise Architect for Java EE platform | Certified TA | Java 
Capability | Accenture- India Delivery Center
AIM: justinsprabhu| +91-9611804388 (m)


This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise confidential information. If you have received it in 
error, please notify the sender immediately and delete the original. Any other 
use of the e-mail by you is prohibited.

Where allowed by local law, electronic communications with Accenture and its 
affiliates, including e-mail and instant messaging (including content), may be 
scanned by our systems for the purposes of information security and assessment 
of internal compliance with Accenture policy.

__

www.accenture.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

[PATCH] config: Add description of --local option

[Namhyung Kim]

It was missed in the option list while mentioned from the general
description.  Add it for completeness.

Signed-off-by: Namhyung Kim namhy...@gmail.com
---
 Documentation/git-config.txt |9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index d88a6fc..19a7be0 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -114,6 +114,15 @@ rather than from all available files.
 +
 See also FILES.
 
+--local::
+   For writing options: write to the repository .git/config file.
+   This is the default behavior.
++
+For reading options: read only from the repository .git/config rather than
+from all available files.
++
+See also FILES.
+
 -f config-file::
 --file config-file::
Use the given config file instead of the one specified by GIT_CONFIG.
-- 
1.7.9.2

--
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] status: display the SHA1 of the commit being currently processed

[Mathieu Liénard--Mayor]

Le 2013-06-17 15:10, Peter Krefting a écrit :

Mathieu Lienard--Mayor:


+   /*
+* If the file stopped-sha does not exist
+* we go back to the old output saying a commit
+* instead of providing the commit's SHA1.
+*/
+   if (!stopped_sha) {
+   stopped_sha = a commit;
+   must_free_stopped_sha = 0;
+   }


This is missing gettext markers, and besides that, it very difficult
to handle for translators. Please consider changing the code to use
different strings based on what you want to insert, i.e.:


if (state-branch)
status_printf_ln(s, color,
-	 _(You are currently splitting a commit while rebasing branch 
'%s' on '%s'.),

+_(Splitting %s while rebasing branch '%s' 
on '%s'.),


   stopped_sha ? _(Splitting %s while rebasing branch '%s' on 
'%s'.)
   : _(Splitting a commit while rebasing branch '%2$s' 
on '%3$s'.)


or something similar.

Actually, at first I dealt with it this way:

status_printf_ln(s, color,
 _(Splitting %s while rebasing branch '%s' on '%s'.),
 stopped_sha ? stopped_sha : _(a commit),
 );

Would this be more suitable for translators ?

--
Mathieu Liénard--Mayor,
2nd year at Grenoble INP - ENSIMAG
(+33)6 80 56 30 02
--
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 error

[Fredrik Gustafsson]

On Mon, Jun 17, 2013 at 01:28:30PM +, justin.sathyanat...@accenture.com 
wrote:
 1.Iam getting error attached when cloning of repository is done:

What error?

 2.Also, when file is tried to be added,it gives error below:
 
 $ git add *
 fatal: unable to stat 
 'src/development_architecture/integration_application_proj
 ect_template/provider_archetype/provider_archetype/src/main/resources/archetype-
 resources/__rootArtifactId__-data/src/main/java/com/accenture/afpj/sample/skelet
 on/visitor/data/VisitorRepositoryJpaImpl.java': Filename too long

As it said, filename is too long.
See the FAQ:
https://github.com/msysgit/msysgit/wiki/Frequently-Asked-Questions
and the thread:
http://thread.gmane.org/gmane.comp.version-control.msysgit/14572

 Request you to help to resolve same asap as it is affecting the project.
If you want reliable and direct help I suggest you hire a git-consult or
buy support. This list will help you in the best way it can (and mostly
that's enough) but cannot do things asap.

-- 
Med vänliga hälsningar
Fredrik Gustafsson

tel: 0733-608274
e-post: iv...@iveqy.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 error

[Konstantin Khomoutov]

On Mon, 17 Jun 2013 13:28:30 +
justin.sathyanat...@accenture.com wrote:

 For Below issue , O/S is Windows7.
[...]
 1.Iam getting error attached when cloning of repository is done:

What error?

 2.Also, when file is tried to be added,it gives error below:
 
 $ git add *
 fatal: unable to stat
 'src/development_architecture/integration_application_proj
 ect_template/provider_archetype/provider_archetype/src/main/resources/archetype-
 resources/__rootArtifactId__-data/src/main/java/com/accenture/afpj/sample/skelet
 on/visitor/data/VisitorRepositoryJpaImpl.java': Filename too long
[...]

This is a limitation of Git for Windows: the standard Windows API which
works with unmangled filenames limits their length to 260 characters
while your particular entry is 262 characters long.

AFAIK, there's no clean/easy way to make use of extended Windows API
which requires mangling filenames by adding the \\?\ to them.

You could read [1] for more details.

So it seems you have two options for now:

* Restructure the project.
* Use Git under Cygwin [2] which might not have this limitation
  (personally, I do not know whether it does).

P.S.

Please next time you ask consider doing two things:
* If you post your message to several groups, take care to mention this
  fact in each of them.
* Do not require anyone to do anything ASAP unless this claim is
  backed by your or your employer's wallet.

1. http://msdn.microsoft.com/en-us/library/aa365247#maxpath
2. http://cygwin.com/packages/git/
--
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 error

[Konstantin Khomoutov]

On Mon, 17 Jun 2013 17:47:07 +0400
Konstantin Khomoutov kostix+...@007spb.ru wrote:

  For Below issue , O/S is Windows7.
  1.Iam getting error attached when cloning of repository is done:
 
 What error?

Okay, the Microsoft Word document with two screenshots has been
scrubbed by the list software but passed through the git-users list
where you posted this as well; answering here.

The errors shown there most probably has the same nature: Git failed to
create a filesystem entry while attempting to check out a revision
after cloning the project.  So the error is not about cloning, it's
about checking out actual files to the work tree.

The rest is explained in my first reply.

[...]
--
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] status: display the SHA1 of the commit being currently processed

[Peter Krefting]

Mathieu Liénard--Mayor:


Actually, at first I dealt with it this way:

status_printf_ln(s, color,
_(Splitting %s while rebasing branch '%s' on '%s'.),
 stopped_sha ? stopped_sha : _(a commit),
 );

Would this be more suitable for translators ?


Not really, the text surrounding a commit might need to be inflected 
differently depending on whether it is a SHA-1 or the a commit 
string. Word order might also be different.


--
\\// Peter - http://www.softwolves.pp.se/
--
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] status: display the SHA1 of the commit being currently processed

[Mathieu Liénard--Mayor]

Le 2013-06-17 15:54, Peter Krefting a écrit :

Mathieu Liénard--Mayor:


Actually, at first I dealt with it this way:

status_printf_ln(s, color,
_(Splitting %s while rebasing branch '%s' on 
'%s'.),

 stopped_sha ? stopped_sha : _(a commit),
 );

Would this be more suitable for translators ?


Not really, the text surrounding a commit might need to be
inflected differently depending on whether it is a SHA-1 or the a
commit string. Word order might also be different.

Okay, I'll use what you suggested then.
--
Mathieu Liénard--Mayor,
2nd year at Grenoble INP - ENSIMAG
(+33)6 80 56 30 02
--
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] rebase -i: fixup fixup! fixup!

[Junio C Hamano]

Thomas Rast tr...@inf.ethz.ch writes:

 Conveniently enough we have seen both already ;-)  Andrew's version for
 commit.c could use a bit of refactorization, since it inserts the same
 code in two places, but then it's about the same complexity as the
 change for rebase.

 I'm not sure it's worth arguing about whether the fixup! fixup!  is a
 symptom of some underlying problem, and changing rebase is only tapering
 over the symptom; or whether it's actually a useful distinction.

If they are about the same complexity, then my instict tells me that
it is a better design not to strip on the writing side.

Thanks.

--
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] config doc: rewrite push.default section

[Junio C Hamano]

Matthieu Moy matthieu@grenoble-inp.fr writes:

 But then the place to warn loudly is the doc for --force. What about
 this?

Sounds sensible.  I am not sure if --all is all that common to be
singled out, though.  I always push these out refspecs, like

[remote origin]
push = refs/heads/master
push = refs/heads/next

share the need for the same cautiousness against --force, and
applies to all the refs that are pushed already covers both.

Mentioning 'matching' here is a very good idea, as people may not
realize it is pushing out more than the current branch.

 --- 8 --- 8 --- 8 --- 8 --- 8 --- 8 

 From a529588dd8df84e54e5ec267068248cc555373f5 Mon Sep 17 00:00:00 2001
 From: Matthieu Moy matthieu@imag.fr
 Date: Mon, 17 Jun 2013 13:02:39 +0200
 Subject: [PATCH] Documentation/git-push.txt: explain better cases where
  --force is dangerous

 The behavior of git push --force is rather clear when it updates only
 one remote ref, but running it when pushing several branches can really
 be dangerous. Warn the users a bit more and give them the alternative to
 push only one branch.

 Signed-off-by: Matthieu Moy matthieu@imag.fr
 ---
  Documentation/git-push.txt | 7 +++
  1 file changed, 7 insertions(+)

 diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
 index 938d1ee..0899a35 100644
 --- a/Documentation/git-push.txt
 +++ b/Documentation/git-push.txt
 @@ -136,6 +136,13 @@ already exists on the remote side.
 not an ancestor of the local ref used to overwrite it.
 This flag disables the check.  This can cause the
 remote repository to lose commits; use it with care.
 +   Note that `--force` applies to all the refs that are pushed,
 +   hence using `git push --all --force`, or `git push --force`
 +   with `push.default` set to `matching` may override refs other
 +   than the current branch (including local refs that are
 +   strictly behind their remote counterpart). To force a push to
 +   only one branch, use `git push remote +branch` instead of
 +   `--force`.
  
  --repo=repository::
 This option is only relevant if no repository argument is
 -- 
 1.8.3.1.495.g13f33cf.dirty
--
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

git-rebranch

[Dan Keder]

Hello,

I made a small script for easier rebasing of development branches. It
is useful in case you are developing in multiple (private) branches
and you want to rebase your branches onto upstream often.

You can find it here:

https://github.com/dankeder/git-rebranch

How it works:

1. Define the branch layout in a config file .gitrebranch
2. Run git rebranch

For more information see the README file.

Let me know if you find it useful. Also, feel free to create a github
issue in case you encounter any bugs or problems.

Regards,
dan

--
\o/
--
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] status: display the SHA1 of the commit being currently processed

[Johannes Sixt]

Am 6/17/2013 15:57, schrieb Mathieu Liénard--Mayor:
 Le 2013-06-17 15:54, Peter Krefting a écrit :
 Mathieu Liénard--Mayor:

 Actually, at first I dealt with it this way:

 status_printf_ln(s, color,
 _(Splitting %s while rebasing branch '%s' on '%s'.),
  stopped_sha ? stopped_sha : _(a commit),
  );

 Would this be more suitable for translators ?

 Not really, the text surrounding a commit might need to be
 inflected differently depending on whether it is a SHA-1 or the a
 commit string. Word order might also be different.
 Okay, I'll use what you suggested then.

That's not a good idea. Do we already use %1$ style formats elsewhere?
I'm afraid that they are not supported everywhere.

-- Hannes
--
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] name-rev: Allow to omit refs/tags/ part in --refs option when --tags used

[Junio C Hamano]

Namhyung Kim namhyung@lge.com writes:

 In its current form, when an user wants to filter specific ref using
 --refs option, she needs to give something like --refs=refs/tags/v1.*.

 This is not intuitive as users might think it's enough to give just
 actual tag name part like --refs=v1.*.

I do not think Users might think is not particularly a good
justification, but I agree that it would be useful to allow
--refs=v1.\* to match refs/heads/v1.4-maint and refs/tags/v1.4.0; it
is easy for the users to disambiguate with longer prefix if they
wanted to.

 It applies to refs other than
 just tags too.  Change it for users to be able to use --refs=sth or
 --refs=remotes/sth.

 Also remove the leading 'tags/' part in the output when --tags option
 was given since the option restricts to work with tags only.

This part is questionable, as it changes the output people's scripts
have been reading from the command since eternity ago.

If the pattern asks to match with v1.* (not tags/v1.* or
refs/tags/v1.*) and you find refs/tags/v1.*, it might be acceptable
to strip refs/tags/ part.  Existing users are _expected_ to feed a
pattern with full refname starting with refs/, so they will not be
negatively affected by such a usability enhancement on the output
side.

 diff --git a/builtin/name-rev.c b/builtin/name-rev.c
 index 6238247..446743b 100644
 --- a/builtin/name-rev.c
 +++ b/builtin/name-rev.c
 @@ -97,7 +97,8 @@ static int name_ref(const char *path, const unsigned char 
 *sha1, int flags, void
   if (data-tags_only  prefixcmp(path, refs/tags/))
   return 0;
  
 - if (data-ref_filter  fnmatch(data-ref_filter, path, 0))
 + if (data-ref_filter  !prefixcmp(data-ref_filter, refs/)
 +  fnmatch(data-ref_filter, path, 0))
   return 0;

What does this mean?  When --refs is specified, if it begins with
refs/ then do not show unmatching path, but let any path be subject
to the following if --refs does not begin with refs/ sounds like a
broken logic, unless you add another fnmatch() later in the codepath
to compensate.  And you indeed do so, but then at that point, do we
still need this if(...) return 0 at all?

I think it can and should be improved here, and then the one in the
main logic you added can be removed.

Wouldn't it make more sense to see if the given pattern matches a
tail substring of the ref, instead of using the hardcoded strip
refs/heads/, refs/tags or refs/, and then match once logic?  That
way, --refs=origin/* can find refs/remotes/origin/master by running
fnmatch of origin/* against its substrings, i.e.

refs/remotes/origin/master
remotes/origin/master
origin/master

and find that the pattern matches it.

Perhaps it is just the matter of adding something like:

static int subpath_matches(const char *path, const char *filter)
{
const char *subpath = path;
while (subpath) {
if (!fnmatch(data-ref_filter, subpath, 0))
return subpath - path;
subpath = strchr(path, '/');
if (subpath)
subpath++;
}
return -1;
}

and then at the beginning of name_ref() do this:

int can_abbreviate_output = data-name_only;

if (data-tags_only  prefixcmp(path, refs/tags/))
return 0;
if (data-ref_filter) {
switch (subpath_matches(path, data-ref_filter)) {
case -1: /* did not match */
return 0;
default: /* matched subpath */
can_abbreviate_output = 1;
break;
case 0: /* matched fully */
break;
}
}

The logic before calling name_rev() will be kept as only decide how
the output looks like, without mixing the unrelated decide if we
want to use it logic in.

   while (o  o-type == OBJ_TAG) {
 @@ -113,12 +114,15 @@ static int name_ref(const char *path, const unsigned 
 char *sha1, int flags, void
   if (!prefixcmp(path, refs/heads/))
   path = path + 11;
   else if (data-tags_only
 -  data-name_only
!prefixcmp(path, refs/tags/))
   path = path + 10;
   else if (!prefixcmp(path, refs/))
   path = path + 5;
  
 + if (data-ref_filter  prefixcmp(data-ref_filter, refs/)
 +  fnmatch(data-ref_filter, path, 0))
 + return 0;
   name_rev(commit, xstrdup(path), 0, 0, deref);
   }
   return 0;
--
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] name-rev: Allow to omit refs/tags/ part in --refs option when --tags used

[Junio C Hamano]

Junio C Hamano gits...@pobox.com writes:

 Wouldn't it make more sense to see if the given pattern matches a
 tail substring of the ref, instead of using the hardcoded strip
 refs/heads/, refs/tags or refs/, and then match once logic?  That
 way, --refs=origin/* can find refs/remotes/origin/master by running
 fnmatch of origin/* against its substrings, i.e.

   refs/remotes/origin/master
 remotes/origin/master
 origin/master

 and find that the pattern matches it.

 Perhaps it is just the matter of adding something like:
 ...
 and then at the beginning of name_ref() do this:

   int can_abbreviate_output = data-name_only;

   if (data-tags_only  prefixcmp(path, refs/tags/))
   return 0;
   if (data-ref_filter) {
   switch (subpath_matches(path, data-ref_filter)) {
   case -1: /* did not match */
   return 0;
   default: /* matched subpath */
   can_abbreviate_output = 1;
   break;
   case 0: /* matched fully */
   break;
   }
   }

 The logic before calling name_rev() will be kept as only decide how
 the output looks like, without mixing the unrelated decide if we
 want to use it logic in.

... which may make the call name_rev with this abbreviated path
logic look something like this:

if (o  o-type == OBJ_COMMIT) {
if (can_abbreviate_output)
path = shorten_unambiguous_ref(path, 0);
else if (!prefixcmp(path, refs/heads/))
path = path + 11;
else if (data-tags_only
 data-name_only
 !prefixcmp(path, refs/tags/))
path = path + 10;
else if (!prefixcmp(path, refs/))
path = path + 5;

name_rev((struct commit *) o, xstrdup(path), 0, 0, deref);
}

--
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] diff: add --ignore-blank-lines option

[Junio C Hamano]

Antoine Pelisse apeli...@gmail.com writes:

 So here is a more thorough description of the option:

 - real changes are interesting

OK, I think I can understand it.

 - blank lines that are close enough (less than context size) to
   interesting changes are considered interesting (recursive definition)

OK.

 - context lines are used around each hunk of interesting changes

OK.

 - If two hunks are separated by less than inter-hunk-context, they
   will be merged into one.

Makes sense.

 The current implementation does the interesting changes selection in a
 single pass.

current meaning the code after this patch is applied?  Is there
a possible future enhancement hinted here?

 +xdchange_t *xdl_get_hunk(xdchange_t **xscr, xdemitconf_t const *xecfg)
 +{
 + xdchange_t *xch, *xchp, *lxch;
   long max_common = 2 * xecfg-ctxlen + xecfg-interhunkctxlen;
 + long max_ignorable = xecfg-ctxlen;
 + unsigned long changes = ULONG_MAX;
 +
 + /* remove ignorable changes that are too far before other changes */
 + for (xchp = *xscr; xchp  xchp-ignore; xchp = xchp-next) {
 + xch = xchp-next;
 +
 + if (xch == NULL ||
 + xch-i1 - (xchp-i1 + xchp-chg1) = max_ignorable)
 + *xscr = xch;
 + }

This strips leading ignorable ones away until we see an unignorable
one.  Looks sane.

 + if (*xscr == NULL)
 + return NULL;
 +
 + lxch = *xscr;

lxch remembers the last one that is interesting.

 + for (xchp = *xscr, xch = xchp-next; xch; xchp = xch, xch = xch-next) {
 + long distance = xch-i1 - (xchp-i1 + xchp-chg1);
 + if (distance  max_common)
   break;

If we see large-enough gap, the one we processed last (in xchp) is
the end of the current hunk.  Looks sane.

 + if (distance  max_ignorable 
 + (!xch-ignore || changes == ULONG_MAX)) {
 + lxch = xch;
 + changes = ULONG_MAX;

The current one is made into the last interesting one we have seen
and the hunk continues, if either (1) the current one is interesting
by itself, or (2) the last one we saw does not match some
unexplainable criteria to cause changes set to not ULONG_MAX.

Puzzling.

 + } else if (changes != ULONG_MAX 
 +xch-i1 + changes - (lxch-i1 + lxch-chg1)  
 max_common) {
 + break;

If the last one we saw does not match some unexplainable criteria to
cause changes set to not ULONG_MAX, and the distance between this
one and the last intersting one is further than the context, this
one will not be a part of the current hunk.

Puzzling.

Could you add comment to the changes variable and explain what the
variable means?

 + } else if (!xch-ignore) {
 + lxch = xch;
 + changes = ULONG_MAX;

When this change by itself is interesting, it becomes the last
interesting one and the hunk continues.

 + } else {
 + if (changes == ULONG_MAX)
 + changes = 0;
 + changes += xch-chg2;

Puzzled beyond guessing.  Also it is curious why here and only here
we look at chg2 side of the things, not i1/chg1 in this whole thing.
--
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: Suggestion: add option in git-p4 to preserve user in Git repository

[Deirdre Connolly]

Olivier, did you upload your hacked version anywhere? 
I also need something like this.




--
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] status: display the SHA1 of the commit being currently processed

[Junio C Hamano]

Johannes Sixt j.s...@viscovery.net writes:

 Am 6/17/2013 15:57, schrieb Mathieu Liénard--Mayor:
 Le 2013-06-17 15:54, Peter Krefting a écrit :
 Mathieu Liénard--Mayor:

 Actually, at first I dealt with it this way:

 status_printf_ln(s, color,
 _(Splitting %s while rebasing branch '%s' on '%s'.),
  stopped_sha ? stopped_sha : _(a commit),
  );

 Would this be more suitable for translators ?

 Not really, the text surrounding a commit might need to be
 inflected differently depending on whether it is a SHA-1 or the a
 commit string. Word order might also be different.
 Okay, I'll use what you suggested then.

 That's not a good idea. Do we already use %1$ style formats elsewhere?

In the template, we obviously don't.

But my understanding is that the reordering using printf() is the
mechanism we suggest l10n folks to use when the order of parameters
given to printf does not match the preferred word order in the
message in their language.
--
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

New User Question

[Joel McGahen]

I have a question about GIT remote repos. Here is my scenario.

1. Work client has a repo (origin, branch of master).
2. Due to contractual issues I need to host a remote copy of this repo that my 
developers can utilize while we get the contractual issues resolved as 
development must continue. 
3. I have a virtual machine from the client which already has a remote of 
origin setup. 
4. I have created a bare repo on a server my developer's have access to. 
5. I have added that remote to my copy of the client VM local repo and pushed 
its contents to my newly created bare repo.

What I need to understand is how to
a) Connect my developer's VM local repos to the new remote repo I created so 
they can continue to work.
b) Once the contractual issues are resolved reconnect the developer's local 
repos back to the original orgin/master repo and merge all their changes.

I'm fairly new to GIT but have worked with version control for a long time 
(CVS, PVCS, Subversion etc).

Any help would be greatly appreciated!





--
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: New User Question

[William Swanson]

On Mon, Jun 17, 2013 at 8:39 AM, Joel McGahen vin4bacc...@me.com wrote:
 What I need to understand is how to
 a) Connect my developer's VM local repos to the new remote repo I created so 
 they can continue to work.
 b) Once the contractual issues are resolved reconnect the developer's local 
 repos back to the original orgin/master repo and merge all their changes.

Git stores information about remotes in the .git/config file. You can
either edit this file directly to change which URL orgin points to,
or you can use the git remote commands to make the same changes. You
can read the documentation by typing git help remote.
--
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: New User Question

[Joel McGahen]

Thanks William. You response is much appreciated. 

Should I have just changed the origin URL in the first place to point to my new 
local repo? What I did was to just add another remote with a different name 
(temp_repo). So if I do git remote I see origin and temp_repo. I then pushed 
to temp_repo. 

Or should I have pushed as I did and then change the origin to the new repo 
location? So If I would git remote i would still only see one (origin) but it 
would point towards the temp_repo location?


On Jun 17, 2013, at 12:51 PM, William Swanson swanson...@gmail.com wrote:

 On Mon, Jun 17, 2013 at 8:39 AM, Joel McGahen vin4bacc...@me.com wrote:
 What I need to understand is how to
 a) Connect my developer's VM local repos to the new remote repo I created so 
 they can continue to work.
 b) Once the contractual issues are resolved reconnect the developer's local 
 repos back to the original orgin/master repo and merge all their changes.
 
 Git stores information about remotes in the .git/config file. You can
 either edit this file directly to change which URL orgin points to,
 or you can use the git remote commands to make the same changes. You
 can read the documentation by typing git help remote.

--
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: New User Question

[Fredrik Gustafsson]

On Mon, Jun 17, 2013 at 11:39:44AM -0400, Joel McGahen wrote:
 I have a question about GIT remote repos. Here is my scenario.
 
 1. Work client has a repo (origin, branch of master).
 2. Due to contractual issues I need to host a remote copy of this repo that 
 my developers can utilize while we get the contractual issues resolved as 
 development must continue. 
 3. I have a virtual machine from the client which already has a remote of 
 origin setup. 
 4. I have created a bare repo on a server my developer's have access to. 
 5. I have added that remote to my copy of the client VM local repo and pushed 
 its contents to my newly created bare repo.
 
 What I need to understand is how to
 a) Connect my developer's VM local repos to the new remote repo I created so 
 they can continue to work.
 b) Once the contractual issues are resolved reconnect the developer's local 
 repos back to the original orgin/master repo and merge all their changes.
 
 I'm fairly new to GIT but have worked with version control for a long time 
 (CVS, PVCS, Subversion etc).
 
 Any help would be greatly appreciated!

Hi!
The short answer is: git remote add (and git help remote for
details). It's also possible to manally edit .git/config if it's
basically just a adress change you're doing.

The long answer is harder. You've experience with centralized systems.
Remember that git is decentralized. Every developer you've is a fully
functional unit on his own. All you need is a way for the developers to
interact with eachothers. It can be done via e-mail, or with them
pulling from eachother directly or as you've done, with one central
repository that everyone sync to.

The questions you've is rather fundamental to git. I tells me that you
do not fully utilize the strengths of git. I suggest reading the
progit book.

Good luck!

-- 
Med vänliga hälsningar
Fredrik Gustafsson

tel: 0733-608274
e-post: iv...@iveqy.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: [PATCH] config doc: rewrite push.default section

[Philip Oakley]

From: Matthieu Moy matthieu@grenoble-inp.fr
Sent: Monday, June 17, 2013 12:09 PM

Junio C Hamano gits...@pobox.com writes:


+* `matching` - push the refspec :.  In other words, push all
+  branches having the same name in both ends, even if it means
+  non-fast-forward updates.  This is for those who prepare all the
+  branches into a publishable shape and then push them out with a
+  single command.  Dangerous, and inappropriate unless you are the
+  only person updating your push destination.


It was already pointed out that unnecessary negativity needs to be
fixed, but more importantly the above Dangerous is not even
correct.


What's really dangerous is the --force flag. A few weeks ago I had to
help a colleague who did a git push --force to update his branch, 
and

he lost data on his co-worker's branches (thanks to git reflog, it
wasn't an actual data loss, but still pretty bad).

But then the place to warn loudly is the doc for --force. What about
this?

--- 8 --- 8 --- 8 --- 8 --- 8 --- 8

From a529588dd8df84e54e5ec267068248cc555373f5 Mon Sep 17 00:00:00 2001
From: Matthieu Moy matthieu@imag.fr
Date: Mon, 17 Jun 2013 13:02:39 +0200
Subject: [PATCH] Documentation/git-push.txt: explain better cases 
where

--force is dangerous

The behavior of git push --force is rather clear when it updates 
only
one remote ref, but running it when pushing several branches can 
really
be dangerous. Warn the users a bit more and give them the alternative 
to

push only one branch.

Signed-off-by: Matthieu Moy matthieu@imag.fr
---
Documentation/git-push.txt | 7 +++
1 file changed, 7 insertions(+)

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 938d1ee..0899a35 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -136,6 +136,13 @@ already exists on the remote side.
   not an ancestor of the local ref used to overwrite it.
   This flag disables the check.  This can cause the
   remote repository to lose commits; use it with care.
+   Note that `--force` applies to all the refs that are pushed,
+   hence using `git push --all --force`, or `git push --force`
+   with `push.default` set to `matching` may override refs other
+   than the current branch (including local refs that are
+   strictly behind their remote counterpart). To force a push to
+   only one branch, use `git push remote +branch` instead of
+   `--force`.


It would be useful to include a real example e.g. `git push origin 
+master`, or a link to specifying a refspec see refspec... above, 
such that the + doesn't get lost in the general text, as push is one 
of the first few commands a new user is likely to be looking up (and 
misunderstanding ;-), so let's make the + obvious


I did notice that the refspec... section doesn't actually associate 
the + with the force action - Am I misunderstanding this?




--repo=repository::
   This option is only relevant if no repository argument is
--
1.8.3.1.495.g13f33cf.dirty


--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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


-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3345 / Virus Database: 3199/6417 - Release Date: 
06/16/13




--
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] config doc: rewrite push.default section

[Matthieu Moy]

Philip Oakley philipoak...@iee.org writes:

 +   Note that `--force` applies to all the refs that are pushed,
 +   hence using `git push --all --force`, or `git push --force`
 +   with `push.default` set to `matching` may override refs other
 +   than the current branch (including local refs that are
 +   strictly behind their remote counterpart). To force a push to
 +   only one branch, use `git push remote +branch` instead of
 +   `--force`.

 It would be useful to include a real example e.g. `git push origin
 +master`, or a link to specifying a refspec see refspec... above,
 such that the + doesn't get lost in the general text, as push is one
 of the first few commands a new user is likely to be looking up (and
 misunderstanding ;-), so let's make the + obvious

Yes, why not. I'll point to the refspec section for detail, and just
give an example here.

 I did notice that the refspec... section doesn't actually associate
 the + with the force action - Am I misunderstanding this?

It says:

  By having the optional leading `+`, you can tell Git to update the
  dst ref even if it is not allowed by default (e.g., it is not a
  fast-forward.)

I think it's OK.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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: New User Question

[William Swanson]

On Mon, Jun 17, 2013 at 9:56 AM, Joel McGahen vin4bacc...@me.com wrote:
 Should I have just changed the origin URL in the first place to point to my 
 new local repo? What I did was to just add another remote with a different 
 name (temp_repo). So if I do git remote I see origin and temp_repo. I then 
 pushed to temp_repo.

A remote is just a shorthand for a specific URL. All the commands that
take remote names, like push, work just as well with raw URL's.
Configuring a remote is basically a way to save time typing the URL.

As Fredrik pointed out, Git is completely decentralized, so there is
nothing special about the remote repositories. When you do a fetch,
the local repository basically says, Hello remote, please send me all
the commits you have that I don't have. When you do a push, the local
repository basically says, here are all the commits I have. Please
take any ones you don't have. The two repositories simply act as
peers.

 Or should I have pushed as I did and then change the origin to the new repo 
 location? So If I would git remote i would still only see one (origin) but 
 it would point towards the temp_repo location?

If you look in a repository's .git/config file, you may see some
per-branch config options that refer to specific remotes, like this:

[branch master]
remote = origin

In this case, you can just edit the config file to point to temp_repo,
either by hand or by using a command like git config. Or, if you
prefer, you could change origin to point to your new server. How you
configure things is up to you and what works best for your workflow;
git is happy either way.
--
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] Documentation/git-push.txt: explain better cases where --force is dangerous

[Matthieu Moy]

The behavior of git push --force is rather clear when it updates only
one remote ref, but running it when pushing several branches can really
be dangerous. Warn the users a bit more and give them the alternative to
push only one branch.

Signed-off-by: Matthieu Moy matthieu@imag.fr
---
 Documentation/git-push.txt | 8 
 1 file changed, 8 insertions(+)

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 938d1ee..9b9e7d1 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -136,6 +136,14 @@ already exists on the remote side.
not an ancestor of the local ref used to overwrite it.
This flag disables the check.  This can cause the
remote repository to lose commits; use it with care.
+   Note that `--force` applies to all the refs that are pushed,
+   hence using it with `push.default` set to `matching` or with
+   multiple push destination configured may override refs other
+   than the current branch (including local refs that are
+   strictly behind their remote counterpart). To force a push to
+   only one branch, use a `+` in front of the refspec to push
+   (e.g `git push origin +master` to force a push to the `master`
+   branch). See the `refspec...` section above for details.
 
 --repo=repository::
This option is only relevant if no repository argument is
-- 
1.8.3.1.495.g13f33cf.dirty

--
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 v2 5/6] status: do not depend on rebase reflog messages

[Junio C Hamano]

Ramkumar Ramachandra artag...@gmail.com writes:

 diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh
 index bf08d4e..739624e 100755
 --- a/t/t7512-status-help.sh
 +++ b/t/t7512-status-help.sh
 @@ -188,10 +188,9 @@ test_expect_success 'status when rebasing -i in edit 
 mode' '
   export FAKE_LINES 
   test_when_finished git rebase --abort 
   ONTO=$(git rev-parse --short HEAD~2) 
 - TGT=$(git rev-parse --short two_rebase_i) 
   git rebase -i HEAD~2 
   cat expected -EOF 
 - # HEAD detached from $TGT
 + # rebase in progress; onto $ONTO
   # You are currently editing a commit while rebasing branch 
 '\''rebase_i_edit'\'' on '\''$ONTO'\''.
   #   (use git commit --amend to amend the current commit)
   #   (use git rebase --continue once you are satisfied with your 
 changes)

This hunk (and others that used to use $TGT) shows that the original
test was depending too much on the implementation detail (i.e. that
rebase/rebase-i internally uses checkout to affect the reflog, making
the info shown as detached from/at not useful during rebase).
This step may have started as a workaround against the fallout from 6/6,
but I think this is a good change by itself independent of checkut -
fix, which is the main topic of this series.

 diff --git a/wt-status.c b/wt-status.c
 index 2511270..85a00f1 100644
 --- a/wt-status.c
 +++ b/wt-status.c
 @@ -1174,7 +1174,10 @@ void wt_status_print(struct wt_status *s)
   branch_name += 11;
   else if (!strcmp(branch_name, HEAD)) {
   branch_status_color = color(WT_STATUS_NOBRANCH, s);
 - if (state.detached_from) {
 + if (state.rebase_in_progress || 
 state.rebase_interactive_in_progress) {
 + on_what = _(rebase in progress; onto );
 + branch_name = state.onto;

The part after || is what I missed in the how about an approach
along this line patch.

Good job.

 + } else if (state.detached_from) {
   unsigned char sha1[20];
   branch_name = state.detached_from;
   if (!get_sha1(HEAD, sha1) 
--
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 v3 1/2] am: handle stray $dotest directory

[Junio C Hamano]

Junio C Hamano gits...@pobox.com writes:

 Will replace what has been queued on 'pu'.

... after fixing an indentation error, that is.

--
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] diff: add --ignore-blank-lines option

[Antoine Pelisse]

On Mon, Jun 17, 2013 at 6:18 PM, Junio C Hamano gits...@pobox.com wrote:
 Antoine Pelisse apeli...@gmail.com writes:

 So here is a more thorough description of the option:

 - real changes are interesting

 OK, I think I can understand it.

 - blank lines that are close enough (less than context size) to
   interesting changes are considered interesting (recursive definition)

 OK.

 - context lines are used around each hunk of interesting changes

 OK.

 - If two hunks are separated by less than inter-hunk-context, they
   will be merged into one.

 Makes sense.

 The current implementation does the interesting changes selection in a
 single pass.

 current meaning the code after this patch is applied?  Is there
 a possible future enhancement hinted here?

 +xdchange_t *xdl_get_hunk(xdchange_t **xscr, xdemitconf_t const *xecfg)
 +{
 + xdchange_t *xch, *xchp, *lxch;
   long max_common = 2 * xecfg-ctxlen + xecfg-interhunkctxlen;
 + long max_ignorable = xecfg-ctxlen;
 + unsigned long changes = ULONG_MAX;
 +
 + /* remove ignorable changes that are too far before other changes */
 + for (xchp = *xscr; xchp  xchp-ignore; xchp = xchp-next) {
 + xch = xchp-next;
 +
 + if (xch == NULL ||
 + xch-i1 - (xchp-i1 + xchp-chg1) = max_ignorable)
 + *xscr = xch;
 + }

 This strips leading ignorable ones away until we see an unignorable
 one.  Looks sane.

 + if (*xscr == NULL)
 + return NULL;
 +
 + lxch = *xscr;

 lxch remembers the last one that is interesting.

 + for (xchp = *xscr, xch = xchp-next; xch; xchp = xch, xch = xch-next) 
 {
 + long distance = xch-i1 - (xchp-i1 + xchp-chg1);
 + if (distance  max_common)
   break;

 If we see large-enough gap, the one we processed last (in xchp) is
 the end of the current hunk.  Looks sane.

 + if (distance  max_ignorable 
 + (!xch-ignore || changes == ULONG_MAX)) {
 + lxch = xch;
 + changes = ULONG_MAX;

 The current one is made into the last interesting one we have seen
 and the hunk continues, if either (1) the current one is interesting
 by itself, or (2) the last one we saw does not match some
 unexplainable criteria to cause changes set to not ULONG_MAX.

 Puzzling.

 + } else if (changes != ULONG_MAX 
 +xch-i1 + changes - (lxch-i1 + lxch-chg1)  
 max_common) {
 + break;

 If the last one we saw does not match some unexplainable criteria to
 cause changes set to not ULONG_MAX, and the distance between this
 one and the last intersting one is further than the context, this
 one will not be a part of the current hunk.

 Puzzling.

 Could you add comment to the changes variable and explain what the
 variable means?

 + } else if (!xch-ignore) {
 + lxch = xch;
 + changes = ULONG_MAX;

 When this change by itself is interesting, it becomes the last
 interesting one and the hunk continues.

 + } else {
 + if (changes == ULONG_MAX)
 + changes = 0;
 + changes += xch-chg2;

 Puzzled beyond guessing.  Also it is curious why here and only here
 we look at chg2 side of the things, not i1/chg1 in this whole thing.
--
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 v2 0/6] Fix checkout-dash to work with rebase

[Junio C Hamano]

Junio C Hamano gits...@pobox.com writes:

 In other words, the order I was anticipating to see after the
 discussion (this is different from saying A series that is not
 ordered like this is unacceptable) was:

   wt-status: remove unused field in grab_1st_switch_cbdata

 This is an unrelated clean-up, and can be done before anything else.

   t/checkout-last: checkout - doesn't work after rebase

 This spells out what we want to happen at the end and marks the
 current breakage.

   status: do not depend on rebase reflog messages

 This compensates for fallouts from the next change.

   checkout: respect GIT_REFLOG_ACTION

 And this is the fix, the most important step.

   rebase: prepare to write reflog message for checkout
   rebase -i: prepare to write reflog message for checkout

 And these are icing on the cake, but that cannot be done before
 status is fixed.

I actually tried to reorder the patches and they seem to work OK as
expected.  And I think it makes sense to order them the way I've
been suggesting, so I'll tentatively queue the result of reordering
on 'rr/rebase-checkout-reflog' and push it out as a part of 'pu'.

Please check to see if I introduced a new bug while doing so.

Regardless of the ordering, however, I suspect two patches that
change the message recorded in reflog in rebase need further
fixing.

For example, the one in git reabse does this:

GIT_REFLOG_ACTION=$GIT_REFLOG_ACTION: checkout $onto_name
git checkout -q $onto^0 || die could not detach HEAD
git update-ref ORIG_HEAD $orig_head
...
run_specific_rebase

But the specific rebase, e.g. git-rebase--interactive, does this:

case $head_name in
refs/*)
message=$GIT_REFLOG_ACTION: $head_name onto $onto 
git update-ref -m $message $head_name $newhead $orig_head 
git symbolic-ref \
  -m $GIT_REFLOG_ACTION: returning to $head_name \
  HEAD $head_name
;;
esac  {

I think the message you added to git reabse is only meant for that
specific checkout $onto, but it is set globally.  Wouldn't it
affect later use, which expected it to be rebase and nothing else?

Perhaps something like this on top of the entire series may be
sufficient (which will be queued as SQUASH??? at the tip).

Hint for anybody (not limited to Ram):

There also are other 'git checkout' invocations in git-rebase\*.sh
that are not yet covered by these nicer reflog message patches,
which may want to be fixed up before these two icing-on-cake patches
become ready to be merged; see output of

git grep -C2 'git checkout' -- git-rebase\*.sh

Thanks.

 git-rebase--interactive.sh| 15 ++-
 git-rebase.sh |  4 ++--
 t/t3404-rebase-interactive.sh | 15 +++
 3 files changed, 27 insertions(+), 7 deletions(-)

diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index a05a6e4..f21ff7c 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -837,9 +837,11 @@ comment_for_reflog start
 
 if test ! -z $switch_to
 then
-   GIT_REFLOG_ACTION=$GIT_REFLOG_ACTION: checkout $switch_to
-   output git checkout $switch_to -- ||
-   die Could not checkout $switch_to
+   (
+   GIT_REFLOG_ACTION=$GIT_REFLOG_ACTION: checkout $switch_to
+   export GIT_REFLOG_ACTION
+   output git checkout $switch_to --
+   ) || die Could not checkout $switch_to
 fi
 
 orig_head=$(git rev-parse --verify HEAD) || die No HEAD?
@@ -981,7 +983,10 @@ has_action $todo ||
 
 test -d $rewritten || test -n $force_rebase || skip_unnecessary_picks
 
-GIT_REFLOG_ACTION=$GIT_REFLOG_ACTION: checkout $onto_name
-output git checkout $onto || die_abort could not detach HEAD
+(
+   GIT_REFLOG_ACTION=$GIT_REFLOG_ACTION: checkout $onto_name
+   export GIT_REFLOG_ACTION
+   output git checkout $onto
+) || die_abort could not detach HEAD
 git update-ref ORIG_HEAD $orig_head
 do_rest
diff --git a/git-rebase.sh b/git-rebase.sh
index 7d55372..2344eef 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -523,8 +523,8 @@ test $type = interactive  run_specific_rebase
 # Detach HEAD and reset the tree
 say $(gettext First, rewinding head to replay your work on top of it...)
 
-GIT_REFLOG_ACTION=$GIT_REFLOG_ACTION: checkout $onto_name
-git checkout -q $onto^0 || die could not detach HEAD
+GIT_REFLOG_ACTION=$GIT_REFLOG_ACTION: checkout $onto_name \
+   git checkout -q $onto^0 || die could not detach HEAD
 git update-ref ORIG_HEAD $orig_head
 
 # If the $onto is a proper descendant of the tip of the branch, then
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index a58406d..c175ef1 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -934,6 +934,21 @@ test_expect_success 'rebase --edit-todo can be used to 
modify todo' '
test L = $(git cat-file commit HEAD | sed -ne \$p)
 '
 

Re: [PATCH] config doc: rewrite push.default section

[Philip Oakley]

From: Matthieu Moy matthieu@grenoble-inp.fr
Sent: Monday, June 17, 2013 6:20 PM

Philip Oakley philipoak...@iee.org writes:


+   Note that `--force` applies to all the refs that are pushed,
+   hence using `git push --all --force`, or `git push --force`
+   with `push.default` set to `matching` may override refs 
other

+   than the current branch (including local refs that are
+   strictly behind their remote counterpart). To force a push 
to
+   only one branch, use `git push remote +branch` instead 
of

+   `--force`.


It would be useful to include a real example e.g. `git push origin
+master`, or a link to specifying a refspec see refspec... 
above,
such that the + doesn't get lost in the general text, as push is 
one

of the first few commands a new user is likely to be looking up (and
misunderstanding ;-), so let's make the + obvious


Yes, why not. I'll point to the refspec section for detail, and just
give an example here.


I did notice that the refspec... section doesn't actually associate
the + with the force action - Am I misunderstanding this?


It says:

 By having the optional leading `+`, you can tell Git to update the
 dst ref even if it is not allowed by default (e.g., it is not a
 fast-forward.)

I think it's OK.


I was more noting that there is zero direct association in the text 
between the --force option, and the +, and with that, a funny feeling 
that either (a) they had subtle differences I hadn't understood, or (b) 
they were exactly the same and the documenation was being too subtle and 
a cluebat should be applied to the documenation (on the principle I am 
not a unique fool ;-)




--
Matthieu Moy
http://www-verimag.imag.fr/~moy/


Maybe...
--- 8 --- 

From 57d8aaac6b7543919aaf09909c13a180722c0a94 Mon Sep 17 00:00:00 2001

From: Philip Oakley philipoak...@iee.org
Date: Mon, 17 Jun 2013 18:47:04 +0100
Subject: [PATCH] git-push doc: +dst refspec is --force

Signed-off-by: Philip Oakley philipoak...@iee.org
---
Documentation/git-push.txt | 2 ++
1 file changed, 2 insertions(+)

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index eb2883c..df92b09 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -136,6 +136,8 @@ already exists on the remote side.
 not an ancestor of the local ref used to overwrite it.
 This flag disables the check.  This can cause the
 remote repository to lose commits; use it with care.
+ See also the optional leading `+` dst ref specifier in
+ 'refspec...' above.

--repo=repository::
 This option is only relevant if no repository argument is
--
1.8.1.msysgit.1


--
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] Remove pdf target from Makefiles

[Thomas Ackermann]

This target was only used to create user-manual.pdf with dblatex
using a separate style definition than was used for user-manual.html.
These two style definitions had to be maintained separately and
so made improvements to user-manual.html unnecessarily hard.

Signed-off-by: Thomas Ackermann th.ac...@arcor.de
---

Improving anything on the formatting of user-manual.pdf would necessitate
to create customized versions of public dblatex style files from
/etc/asciidoc/dblatex/. Instead of trying to expand on creating more and better
pdfs from the git documentation I suggest to drop the pdf target altogether
and thus also get rid of the dependency on dblatex.

 Documentation/Makefile | 15 ---
 Makefile   |  6 --
 2 files changed, 21 deletions(-)

diff --git a/Documentation/Makefile b/Documentation/Makefile
index 62dbd9a..c42aa07 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -81,7 +81,6 @@ DOC_MAN7=$(patsubst %.txt,%.7,$(MAN7_TXT))
 prefix?=$(HOME)
 bindir?=$(prefix)/bin
 htmldir?=$(prefix)/share/doc/git-doc
-pdfdir?=$(prefix)/share/doc/git-doc
 mandir?=$(prefix)/share/man
 man1dir=$(mandir)/man1
 man5dir=$(mandir)/man5
@@ -102,7 +101,6 @@ infodir?=$(prefix)/share/info
 MAKEINFO=makeinfo
 INSTALL_INFO=install-info
 DOCBOOK2X_TEXI=docbook2x-texi
-DBLATEX=dblatex
 ifndef PERL_PATH
PERL_PATH = /usr/bin/perl
 endif
@@ -185,7 +183,6 @@ ifndef V
QUIET_XMLTO = @echo '   ' XMLTO $@;
QUIET_DB2TEXI   = @echo '   ' DB2TEXI $@;
QUIET_MAKEINFO  = @echo '   ' MAKEINFO $@;
-   QUIET_DBLATEX   = @echo '   ' DBLATEX $@;
QUIET_XSLTPROC  = @echo '   ' XSLTPROC $@;
QUIET_GEN   = @echo '   ' GEN $@;
QUIET_STDERR= 2 /dev/null
@@ -207,8 +204,6 @@ man7: $(DOC_MAN7)
 
 info: git.info gitman.info
 
-pdf: user-manual.pdf
-
 install: install-man
 
 install-man: man
@@ -229,10 +224,6 @@ install-info: info
  echo No directory found in $(DESTDIR)$(infodir) 2 ; \
fi
 
-install-pdf: pdf
-   $(INSTALL) -d -m 755 $(DESTDIR)$(pdfdir)
-   $(INSTALL) -m 644 user-manual.pdf $(DESTDIR)$(pdfdir)
-
 install-html: html
'$(SHELL_PATH_SQ)' ./install-webdoc.sh $(DESTDIR)$(htmldir)
 
@@ -289,7 +280,6 @@ mergetools-list.made: ../git-mergetool--lib.sh $(wildcard 
../mergetools/*)
 clean:
$(RM) *.xml *.xml+ *.html *.html+ *.1 *.5 *.7
$(RM) *.texi *.texi+ *.texi++ git.info gitman.info
-   $(RM) *.pdf
$(RM) howto-index.txt howto/*.html doc.dep
$(RM) technical/*.html technical/api-index.txt
$(RM) $(cmds_txt) $(mergetools_txt) *.made
@@ -352,11 +342,6 @@ user-manual.texi: user-manual.xml
rm $@++  \
mv $@+ $@
 
-user-manual.pdf: user-manual.xml
-   $(QUIET_DBLATEX)$(RM) $@+ $@  \
-   $(DBLATEX) -o $@+ -p /etc/asciidoc/dblatex/asciidoc-dblatex.xsl -s 
/etc/asciidoc/dblatex/asciidoc-dblatex.sty $  \
-   mv $@+ $@
-
 gitman.texi: $(MAN_XML) cat-texi.perl
$(QUIET_DB2TEXI)$(RM) $@+ $@  \
($(foreach xml,$(MAN_XML),$(DOCBOOK2X_TEXI) --encoding=UTF-8 \
diff --git a/Makefile b/Makefile
index 03524d0..ab8fb15 100644
--- a/Makefile
+++ b/Makefile
@@ -2089,9 +2089,6 @@ html:
 info:
$(MAKE) -C Documentation info
 
-pdf:
-   $(MAKE) -C Documentation pdf
-
 XGETTEXT_FLAGS = \
--force-po \
--add-comments \
@@ -2404,9 +2401,6 @@ install-html:
 install-info:
$(MAKE) -C Documentation install-info
 
-install-pdf:
-   $(MAKE) -C Documentation install-pdf
-
 quick-install-doc:
$(MAKE) -C Documentation quick-install
 
-- 
1.8.3.msysgit.0



---
Thomas
--
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] fixup! push: switch default from matching to simple

[Matthieu Moy]

Signed-off-by: Matthieu Moy matthieu@imag.fr
---
This is to be squashed into jc/push-2.0-default-to-simple

(Noticed while writing the other patch about --force)

 Documentation/git-push.txt | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 9b9e7d1..81b875b 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -381,8 +381,10 @@ Examples
configured for the current branch).
 
 `git push origin`::
-   Without additional configuration, works like
-   `git push origin :`.
+   Without additional configuration, pushes the current branch to
+   the configured upstream (`remote.origin.merge` configuration
+   variable) if it has the same name as the current branch, and
+   errors out without pushing otherwise.
 +
 The default behavior of this command when no refspec is given can be
 configured by setting the `push` option of the remote, or the `push.default`
-- 
1.8.3.1.495.g13f33cf.dirty

--
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] status: display the SHA1 of the commit being currently processed

[Junio C Hamano]

Mathieu Lienard--Mayor mathieu.lienard--ma...@ensimag.imag.fr
writes:

 When in the middle of a rebase, it can be annoying to go in .git
 in order to find the SHA1 of the commit where the rebase stopped.

 git-status now includes this information in its default output.
 With this new information, the message is now shorter, to avoid
 too long lines.

 The new message looks like:
 $ git status
  HEAD detached from 33e516f
  Editing c346c87 while rebasing branch 'rebase_i_edit' on 'f90e540'.

Hmph.  It only looks into rebase-merge and not rebase-apply; is this
patch complete, or just to show a Work-In-Progress?

I do not think you need to introduce a new stopped-sha file (if you
need it, call that with sha-1).  git rebase [-i/-m] knows where
it stopped and what the next step is without having to have such an
extra file.  Why should you need one?

It seems that wt_status_get_state() tries to read in-progress state
for various operations, and I think the logic to _detect_ what to
show (i.e. what is the next commit to be replayed?  how many more
remains to be replayed?, etc.) would mix well with that function.
Extend wt_status_state structure to hold the necessary info, query
the state from the filesystem in that function, and display the info
(but not collect info) in show_rebase_in_progress(), to keep the
clean division of labor between these two places.

Also, please pay closer attention to topics that are under
discussion in other threads.  I think Ram's Fix 'checkout -' after
'rebase' finishes topic cf.

  http://thread.gmane.org/gmane.comp.version-control.git/227994/focus=228092

makes the output reasonably better and consistent (please check what
I'll be pushing out on 'pu' later today after fixing some of them
up).  I suspect that this patch will conflict with it, so either you
would need to wait, or work together with that branch (i.e. rebase
on top of it as necessary), or something.

In the longer term to address issues discussed in this thread cf.

  http://thread.gmane.org/gmane.comp.version-control.git/227432/focus=227471

I think the right direction is *NOT* to keep the first HEAD
detached at line and to add more cruft to the status output as
additional lines, when various sequencer-like operations that
tentatively take you to detached HEAD state to give control back to
you in the middle.  git status knows what operation is in
progress, and I think we should start our output _without_ that
HEAD detached at line.

Thanks.
--
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 v3 4/5] stash: introduce 'git stash store'

[Junio C Hamano]

Ramkumar Ramachandra artag...@gmail.com writes:

 + test $# == 1 ||

This is broken under POSIX shells.  No need to resend (will locally
patch up).
--
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] diff: add --ignore-blank-lines option

[Antoine Pelisse]

On Mon, Jun 17, 2013 at 6:18 PM, Junio C Hamano gits...@pobox.com wrote:
 Antoine Pelisse apeli...@gmail.com writes:

 So here is a more thorough description of the option:

 - real changes are interesting

 OK, I think I can understand it.

 - blank lines that are close enough (less than context size) to
   interesting changes are considered interesting (recursive definition)

 OK.

 - context lines are used around each hunk of interesting changes

 OK.

 - If two hunks are separated by less than inter-hunk-context, they
   will be merged into one.

 Makes sense.

 The current implementation does the interesting changes selection in a
 single pass.

 current meaning the code after this patch is applied?  Is there
 a possible future enhancement hinted here?

No. There might be, but I'm not sure it should be discussed right now
(In case you're curious, I'm thinking about interaction with combined
diff). I will take the hint and rephrase.

 +xdchange_t *xdl_get_hunk(xdchange_t **xscr, xdemitconf_t const *xecfg)
 +{
 + xdchange_t *xch, *xchp, *lxch;
   long max_common = 2 * xecfg-ctxlen + xecfg-interhunkctxlen;
 + long max_ignorable = xecfg-ctxlen;
 + unsigned long changes = ULONG_MAX;

Let me explain what changes means, as I know it will help the rest
of the message:
It counts the number of *added* blank lines we have ignored since
lxch (needed to calculate the distance between lxch and xch)
It also has the meaning of what was called interesting before.
If changes == ULONG_MAX, we are still in interesting zone, otherwise
it means we have ignored changes *added* blank lines (0 being a
valid value).
(Actually, After rereading this part, it looks like I could check that
lxch == xchp rather than setting changes to ULONG_MAX).

 +
 + /* remove ignorable changes that are too far before other changes */
 + for (xchp = *xscr; xchp  xchp-ignore; xchp = xchp-next) {
 + xch = xchp-next;
 +
 + if (xch == NULL ||
 + xch-i1 - (xchp-i1 + xchp-chg1) = max_ignorable)
 + *xscr = xch;
 + }

 This strips leading ignorable ones away until we see an unignorable
 one.  Looks sane.

 + if (*xscr == NULL)
 + return NULL;
 +
 + lxch = *xscr;

 lxch remembers the last one that is interesting.

 + for (xchp = *xscr, xch = xchp-next; xch; xchp = xch, xch = xch-next) 
 {
 + long distance = xch-i1 - (xchp-i1 + xchp-chg1);
 + if (distance  max_common)
   break;

 If we see large-enough gap, the one we processed last (in xchp) is
 the end of the current hunk.  Looks sane.

 + if (distance  max_ignorable 
 + (!xch-ignore || changes == ULONG_MAX)) {
 + lxch = xch;
 + changes = ULONG_MAX;

 The current one is made into the last interesting one we have seen
 and the hunk continues, if either (1) the current one is interesting
 by itself, or (2) the last one we saw does not match some
 unexplainable criteria to cause changes set to not ULONG_MAX.

 Puzzling.

- If we are still in interesting zone, we take it, even if it's
ignorable change. Because it's close enough.
- Otherwise, only take real changes. We are close to another change,
and we are still in the loop, so it must be interesting.

 + } else if (changes != ULONG_MAX 
 +xch-i1 + changes - (lxch-i1 + lxch-chg1)  
 max_common) {
 + break;

 If the last one we saw does not match some unexplainable criteria to
 cause changes set to not ULONG_MAX, and the distance between this
 one and the last intersting one is further than the context, this
 one will not be a part of the current hunk.

 Puzzling.

If we are no longer in interesting zone (changes != ULONG_MAX), it
means we will stop if the distance is too big.
changes is used in the calculation to consider the changes we have
already ignored (xch-i1 - (lxch-i1 + lxch-chg1) will only work if
xch and lxch are consecutive, we need to add the blank lines we
ignored).

 Could you add comment to the changes variable and explain what the
 variable means?

 + } else if (!xch-ignore) {
 + lxch = xch;
 + changes = ULONG_MAX;

 When this change by itself is interesting, it becomes the last
 interesting one and the hunk continues.

Exactly, and changes goes back to interesting.

 + } else {
 + if (changes == ULONG_MAX)
 + changes = 0;
 + changes += xch-chg2;

 Puzzled beyond guessing.  Also it is curious why here and only here
 we look at chg2 side of the things, not i1/chg1 in this whole thing.

chg2 being the number of blank line *additions*.
I don't want to coalesce two hunks because some blank lines have been
removed between the two, so we must not change the distance
calculation because of a blank line removal. That behavior can be seen
in 

Re: [PATCH] wt-status: give better advice when cherry-pick is in progress

[Junio C Hamano]

Ralf Thielow ralf.thie...@gmail.com writes:

 When cherry-pick is in progress, 'git status' gives the advice to
 run git commit to finish the cherry-pick. However, this won't continue
 the sequencer.
 git status should give the advice of running git cherry-pick --continue
 or git cherry-pick --abort.

Is the above _always_ the case, or does the updated advice message
only apply when you are cherry-picking a range of commits with git
cherry-pick A..B?  In other words, when git cherry-pick $it (a
single commit) stops, waiting for your help to resolve it, would
git cherry-pick --continue conclude it?

If that works then this definitely is a good change (the user only
needs to know cherry-pick --continue).

 Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
 ---
  t/t7512-status-help.sh | 6 --
  wt-status.c| 6 --
  2 files changed, 8 insertions(+), 4 deletions(-)

 diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh
 index bf08d4e..4f09bec 100755
 --- a/t/t7512-status-help.sh
 +++ b/t/t7512-status-help.sh
 @@ -632,7 +632,8 @@ test_expect_success 'status when cherry-picking before 
 resolving conflicts' '
   cat expected -\EOF 
   # On branch cherry_branch
   # You are currently cherry-picking.
 - #   (fix conflicts and run git commit)
 + #   (fix conflicts and run git cherry-pick --continue)
 + #   (use git cherry-pick --abort to cancel the cherry-pick operation)
   #
   # Unmerged paths:
   #   (use git add file... to mark resolution)
 @@ -655,7 +656,8 @@ test_expect_success 'status when cherry-picking after 
 resolving conflicts' '
   cat expected -\EOF 
   # On branch cherry_branch
   # You are currently cherry-picking.
 - #   (all conflicts fixed: run git commit)
 + #   (all conflicts fixed: run git cherry-pick --continue)
 + #   (use git cherry-pick --abort to cancel the cherry-pick operation)
   #
   # Changes to be committed:
   #
 diff --git a/wt-status.c b/wt-status.c
 index bf84a86..438a40d 100644
 --- a/wt-status.c
 +++ b/wt-status.c
 @@ -955,10 +955,12 @@ static void show_cherry_pick_in_progress(struct 
 wt_status *s,
   if (advice_status_hints) {
   if (has_unmerged(s))
   status_printf_ln(s, color,
 - _(  (fix conflicts and run \git commit\)));
 + _(  (fix conflicts and run \git cherry-pick 
 --continue\)));
   else
   status_printf_ln(s, color,
 - _(  (all conflicts fixed: run \git 
 commit\)));
 + _(  (all conflicts fixed: run \git 
 cherry-pick --continue\)));
 + status_printf_ln(s, color,
 + _(  (use \git cherry-pick --abort\ to cancel the 
 cherry-pick operation)));
   }
   wt_status_print_trailer(s);
  }
--
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] wt-status: give better advice when cherry-pick is in progress

[Ralf Thielow]

2013/6/17 Junio C Hamano gits...@pobox.com:
 Ralf Thielow ralf.thie...@gmail.com writes:

 When cherry-pick is in progress, 'git status' gives the advice to
 run git commit to finish the cherry-pick. However, this won't continue
 the sequencer.
 git status should give the advice of running git cherry-pick --continue
 or git cherry-pick --abort.

 Is the above _always_ the case, or does the updated advice message
 only apply when you are cherry-picking a range of commits with git
 cherry-pick A..B?  In other words, when git cherry-pick $it (a
 single commit) stops, waiting for your help to resolve it, would
 git cherry-pick --continue conclude it?


Yes, both --continue and --abort works with a single commit.

 If that works then this definitely is a good change (the user only
 needs to know cherry-pick --continue).

 Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
 ---
  t/t7512-status-help.sh | 6 --
  wt-status.c| 6 --
  2 files changed, 8 insertions(+), 4 deletions(-)

 diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh
 index bf08d4e..4f09bec 100755
 --- a/t/t7512-status-help.sh
 +++ b/t/t7512-status-help.sh
 @@ -632,7 +632,8 @@ test_expect_success 'status when cherry-picking before 
 resolving conflicts' '
   cat expected -\EOF 
   # On branch cherry_branch
   # You are currently cherry-picking.
 - #   (fix conflicts and run git commit)
 + #   (fix conflicts and run git cherry-pick --continue)
 + #   (use git cherry-pick --abort to cancel the cherry-pick operation)
   #
   # Unmerged paths:
   #   (use git add file... to mark resolution)
 @@ -655,7 +656,8 @@ test_expect_success 'status when cherry-picking after 
 resolving conflicts' '
   cat expected -\EOF 
   # On branch cherry_branch
   # You are currently cherry-picking.
 - #   (all conflicts fixed: run git commit)
 + #   (all conflicts fixed: run git cherry-pick --continue)
 + #   (use git cherry-pick --abort to cancel the cherry-pick operation)
   #
   # Changes to be committed:
   #
 diff --git a/wt-status.c b/wt-status.c
 index bf84a86..438a40d 100644
 --- a/wt-status.c
 +++ b/wt-status.c
 @@ -955,10 +955,12 @@ static void show_cherry_pick_in_progress(struct 
 wt_status *s,
   if (advice_status_hints) {
   if (has_unmerged(s))
   status_printf_ln(s, color,
 - _(  (fix conflicts and run \git commit\)));
 + _(  (fix conflicts and run \git cherry-pick 
 --continue\)));
   else
   status_printf_ln(s, color,
 - _(  (all conflicts fixed: run \git 
 commit\)));
 + _(  (all conflicts fixed: run \git 
 cherry-pick --continue\)));
 + status_printf_ln(s, color,
 + _(  (use \git cherry-pick --abort\ to cancel the 
 cherry-pick operation)));
   }
   wt_status_print_trailer(s);
  }
--
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

smudge filter

[shawn wilson]

Can someone take a look at this and let me know what I'm doing wrong?

Also, what's the best way to test filters? I can't really do -Debug or
really even print various output.

https://github.com/ag4ve/github-test
--
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] Documentation/git-push.txt: explain better cases where --force is dangerous

[Junio C Hamano]

Matthieu Moy matthieu@imag.fr writes:

 The behavior of git push --force is rather clear when it updates only
 one remote ref, but running it when pushing several branches can really
 be dangerous. Warn the users a bit more and give them the alternative to
 push only one branch.

 Signed-off-by: Matthieu Moy matthieu@imag.fr
 ---

Looks good.  Thanks.


  Documentation/git-push.txt | 8 
  1 file changed, 8 insertions(+)

 diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
 index 938d1ee..9b9e7d1 100644
 --- a/Documentation/git-push.txt
 +++ b/Documentation/git-push.txt
 @@ -136,6 +136,14 @@ already exists on the remote side.
   not an ancestor of the local ref used to overwrite it.
   This flag disables the check.  This can cause the
   remote repository to lose commits; use it with care.
 + Note that `--force` applies to all the refs that are pushed,
 + hence using it with `push.default` set to `matching` or with
 + multiple push destination configured may override refs other
 + than the current branch (including local refs that are
 + strictly behind their remote counterpart). To force a push to
 + only one branch, use a `+` in front of the refspec to push
 + (e.g `git push origin +master` to force a push to the `master`
 + branch). See the `refspec...` section above for details.
  
  --repo=repository::
   This option is only relevant if no repository argument is
--
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] fixup! push: switch default from matching to simple

[Junio C Hamano]

Matthieu Moy matthieu@imag.fr writes:

 Signed-off-by: Matthieu Moy matthieu@imag.fr
 ---
 This is to be squashed into jc/push-2.0-default-to-simple

 (Noticed while writing the other patch about --force)

Thanks.

Note that this has to further change if Ram's triangular push fix
comes before 2.0.

I am not sure if these original two lines are necessary.  Wouldn't
it more appropriate to just drop the Without additional configuration
and go straight to The default behaviour of this command...?

  Documentation/git-push.txt | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

 diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
 index 9b9e7d1..81b875b 100644
 --- a/Documentation/git-push.txt
 +++ b/Documentation/git-push.txt
 @@ -381,8 +381,10 @@ Examples
   configured for the current branch).
  
  `git push origin`::
 - Without additional configuration, works like
 - `git push origin :`.
 + Without additional configuration, pushes the current branch to
 + the configured upstream (`remote.origin.merge` configuration
 + variable) if it has the same name as the current branch, and
 + errors out without pushing otherwise.
  +
  The default behavior of this command when no refspec is given can be
  configured by setting the `push` option of the remote, or the `push.default`
--
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] diff: add --ignore-blank-lines option

[Junio C Hamano]

Antoine Pelisse apeli...@gmail.com writes:

 + unsigned long changes = ULONG_MAX;

 Let me explain what changes means, as I know it will help the rest
 of the message:
 It counts the number of *added* blank lines we have ignored since
 lxch (needed to calculate the distance between lxch and xch)
 It also has the meaning of what was called interesting before.
 If changes == ULONG_MAX, we are still in interesting zone, otherwise
 it means we have ignored changes *added* blank lines (0 being a
 valid value).

OK.  That deserves a comment next to this variable.

 (Actually, After rereading this part, it looks like I could check that
 lxch == xchp rather than setting changes to ULONG_MAX).

Yeah, I think so.

 + if (distance  max_ignorable 
 + (!xch-ignore || changes == ULONG_MAX)) {
 + lxch = xch;
 + changes = ULONG_MAX;

 - If we are still in interesting zone, we take it, even if it's
 ignorable change. Because it's close enough.
 - Otherwise, only take real changes. We are close to another change,
 and we are still in the loop, so it must be interesting.

OK.

 + } else if (changes != ULONG_MAX 
 +xch-i1 + changes - (lxch-i1 + lxch-chg1)  
 max_common) {
 + break;

 If we are no longer in interesting zone (changes != ULONG_MAX), it
 means we will stop if the distance is too big.
 changes is used in the calculation to consider the changes we have
 already ignored (xch-i1 - (lxch-i1 + lxch-chg1) will only work if
 xch and lxch are consecutive, we need to add the blank lines we
 ignored).

And this uses max_common that is much larger than max_ignorable
because...?

The last interesting change, with its post context and inter hunk
gap, together with precontext for this one, is close enough to the
beginning of this one.  So it is understandable if xch by itself is
intereseting to use max_common.  Even an interesting one, if that is
so far from the last interesting one, should not be part of this
hunk.

However, if the current one is by itself uninteresting, should we
still use the max_common, or should this be compared with
max_ignorable?

 Could you add comment to the changes variable and explain what the
 variable means?

 + } else if (!xch-ignore) {
 + lxch = xch;
 + changes = ULONG_MAX;

 When this change by itself is interesting, it becomes the last
 interesting one and the hunk continues.

 Exactly, and changes goes back to interesting.

 + } else {
 + if (changes == ULONG_MAX)
 + changes = 0;
 + changes += xch-chg2;

 Puzzled beyond guessing.  Also it is curious why here and only here
 we look at chg2 side of the things, not i1/chg1 in this whole thing.

 chg2 being the number of blank line *additions*.

This is on the else side of if (!xch-ignore), so we are looking at
ignored hunk, which means there is only blank line change.  Can chg2
be 0 while chg1 is not zero, i.e. xch being a blank line removal?

What should happen in that case?  Don't we want to show it, for the
same reason we want to keep removal, as long as it is close enough
to the interesting zone?

 Hope that makes things clearer,

Yes, it helped quite a bit.
--
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] tests: allow sha1's as part of the path

[Junio C Hamano]

Makes sense; thanks.
--
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] GIT-VERSION-GEN: support non-standard $GIT_DIR path

[Junio C Hamano]

Dennis Kaarsemaker den...@kaarsemaker.net writes:

  I'm doing daily builds of git, using many workers and a shared git.git,
  with per-worker checkouts

OK, so GIT_DIR is explicitly specified in these workers.

Makes sense.
--
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] GIT-VERSION-GEN: support non-standard $GIT_DIR path

[Junio C Hamano]

Junio C Hamano gits...@pobox.com writes:

 Dennis Kaarsemaker den...@kaarsemaker.net writes:

  I'm doing daily builds of git, using many workers and a shared git.git,
  with per-worker checkouts

 OK, so GIT_DIR is explicitly specified in these workers.

 Makes sense.

Actually it does not.  What if GIT_DIR is an empty string or not set
at all?  The patch breaks the build for everybody else, doesn't it?

Perhaps like this instead?

 GIT-VERSION-GEN | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index 2908204..91ec831 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -11,7 +11,7 @@ LF='
 if test -f version
 then
VN=$(cat version) || VN=$DEF_VER
-elif test -d .git -o -f .git 
+elif test -d ${GIT_DIR:-.git} -o -f .git 
VN=$(git describe --match v[0-9]* --abbrev=7 HEAD 2/dev/null) 
case $VN in
*$LF*) (exit 1) ;;




--
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] mergetool--lib: refactor {diff,merge}_cmd logic

[Junio C Hamano]

David Aguilar dav...@gmail.com writes:

 On Sun, Jun 16, 2013 at 10:51 AM, John Keeping j...@keeping.me.uk wrote:
 Instead of needing a wrapper to call the diff/merge command, simply
 provide the diff_cmd and merge_cmd functions for user-specified tools in
 the same way as we do for built-in tools.

 Signed-off-by: John Keeping j...@keeping.me.uk
 ---

 This is a nice cleanup.

 Acked-by: David Aguilar dav...@gmail.com

Thanks, both.
--
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 2/2] Documentation/Makefile: move infodir to be with other '*dir's

[Junio C Hamano]

John Keeping j...@keeping.me.uk writes:

 Signed-off-by: John Keeping j...@keeping.me.uk
 ---

Thanks; will directly apply 1/2 on maint.  I am not absolutely sure
about this one, where variables related to an optional info
support used to be in one place but with the patch only infodir is
separated away.  Maybe it is not a big deal, though.

  Documentation/Makefile | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/Documentation/Makefile b/Documentation/Makefile
 index af3d8a4..0cfdc36 100644
 --- a/Documentation/Makefile
 +++ b/Documentation/Makefile
 @@ -81,6 +81,7 @@ DOC_MAN7 = $(patsubst %.txt,%.7,$(MAN7_TXT))
  prefix ?= $(HOME)
  bindir ?= $(prefix)/bin
  htmldir ?= $(prefix)/share/doc/git-doc
 +infodir ?= $(prefix)/share/info
  pdfdir ?= $(prefix)/share/doc/git-doc
  mandir ?= $(prefix)/share/man
  man1dir = $(mandir)/man1
 @@ -98,7 +99,6 @@ RM ?= rm -f
  MAN_REPO = ../../git-manpages
  HTML_REPO = ../../git-htmldocs
  
 -infodir ?= $(prefix)/share/info
  MAKEINFO = makeinfo
  INSTALL_INFO = install-info
  DOCBOOK2X_TEXI = docbook2x-texi
--
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] wt-status: give better advice when cherry-pick is in progress

[Junio C Hamano]

Ralf Thielow ralf.thie...@gmail.com writes:

 2013/6/17 Junio C Hamano gits...@pobox.com:
 Ralf Thielow ralf.thie...@gmail.com writes:

 When cherry-pick is in progress, 'git status' gives the advice to
 run git commit to finish the cherry-pick. However, this won't continue
 the sequencer.
 git status should give the advice of running git cherry-pick --continue
 or git cherry-pick --abort.

 Is the above _always_ the case, or does the updated advice message
 only apply when you are cherry-picking a range of commits with git
 cherry-pick A..B?  In other words, when git cherry-pick $it (a
 single commit) stops, waiting for your help to resolve it, would
 git cherry-pick --continue conclude it?


 Yes, both --continue and --abort works with a single commit.

Perhaps that is a good thing to explain, in addition to won't
continue the sequencer, as single-pick case does not have much to
do with it ;-)

Thanks, will queue.

 If that works then this definitely is a good change (the user only
 needs to know cherry-pick --continue).

 Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
 ---
  t/t7512-status-help.sh | 6 --
  wt-status.c| 6 --
  2 files changed, 8 insertions(+), 4 deletions(-)

 diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh
 index bf08d4e..4f09bec 100755
 --- a/t/t7512-status-help.sh
 +++ b/t/t7512-status-help.sh
 @@ -632,7 +632,8 @@ test_expect_success 'status when cherry-picking before 
 resolving conflicts' '
   cat expected -\EOF 
   # On branch cherry_branch
   # You are currently cherry-picking.
 - #   (fix conflicts and run git commit)
 + #   (fix conflicts and run git cherry-pick --continue)
 + #   (use git cherry-pick --abort to cancel the cherry-pick 
 operation)
   #
   # Unmerged paths:
   #   (use git add file... to mark resolution)
 @@ -655,7 +656,8 @@ test_expect_success 'status when cherry-picking after 
 resolving conflicts' '
   cat expected -\EOF 
   # On branch cherry_branch
   # You are currently cherry-picking.
 - #   (all conflicts fixed: run git commit)
 + #   (all conflicts fixed: run git cherry-pick --continue)
 + #   (use git cherry-pick --abort to cancel the cherry-pick 
 operation)
   #
   # Changes to be committed:
   #
 diff --git a/wt-status.c b/wt-status.c
 index bf84a86..438a40d 100644
 --- a/wt-status.c
 +++ b/wt-status.c
 @@ -955,10 +955,12 @@ static void show_cherry_pick_in_progress(struct 
 wt_status *s,
   if (advice_status_hints) {
   if (has_unmerged(s))
   status_printf_ln(s, color,
 - _(  (fix conflicts and run \git 
 commit\)));
 + _(  (fix conflicts and run \git cherry-pick 
 --continue\)));
   else
   status_printf_ln(s, color,
 - _(  (all conflicts fixed: run \git 
 commit\)));
 + _(  (all conflicts fixed: run \git 
 cherry-pick --continue\)));
 + status_printf_ln(s, color,
 + _(  (use \git cherry-pick --abort\ to cancel the 
 cherry-pick operation)));
   }
   wt_status_print_trailer(s);
  }
--
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] unpack-trees: don't shift conflicts left and right

[René Scharfe]

Am 16.06.2013 02:56, schrieb Junio C Hamano:
 One thing renaming df_conficts to conflicts really proves is that
 this field is not used by the traverse_trees machinery at all.
 
 Before this patch, the bits in conflicts (now df_conflicts) mask had
 the semantics that is not consistent with the dirmask/mask the
 tree-walk machinery uses to communicate with its callers and
 callbacks.  Everything in tree-walk.[ch] is about walk N trees,
 and bit 0 of dirmask and mask always means the first tree, not
 first tree, or in index if the callback is doing a merge, which
 is used in the conflicts field before this patch.

Right.

 I think the true source of the confusion is that the conflicts
 field does not logically belong there.  It is not needed in the
 general walk N trees machinery.

NB: The only other caller of traverse_trees is git merge-tree.

 The information is only useful for the unpack_trees callback, and
 info-data is a more appropriate place to hang such a callback
 specific data.
 
 Perhaps we should use info-data field to point at
 
   struct {
   struct unpack_trees_options *o;
   unsigned long df_conflict;
   };
 
 and get rid of info-conflicts field?

Here's a patch that does so, but it complicates matters quite a bit.
Did I miss anything (or rather: add too much)?

---
 tree-walk.h|  1 -
 unpack-trees.c | 38 +-
 2 files changed, 29 insertions(+), 10 deletions(-)

diff --git a/tree-walk.h b/tree-walk.h
index ae04b64..4876695 100644
--- a/tree-walk.h
+++ b/tree-walk.h
@@ -46,7 +46,6 @@ struct traverse_info {
int pathlen;
struct pathspec *pathspec;
 
-   unsigned long df_conflicts;
traverse_callback_t fn;
void *data;
int show_all_errors;
diff --git a/unpack-trees.c b/unpack-trees.c
index b27f2a6..1c1b4de 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -416,11 +416,17 @@ static int unpack_index_entry(struct cache_entry *ce,
return ret;
 }
 
+struct unpack_callback_info {
+   struct unpack_trees_options *options;
+   unsigned long df_conflicts;
+};
+
 static int find_cache_pos(struct traverse_info *, const struct name_entry *);
 
 static void restore_cache_bottom(struct traverse_info *info, int bottom)
 {
-   struct unpack_trees_options *o = info-data;
+   struct unpack_callback_info *uci = info-data;
+   struct unpack_trees_options *o = uci-options;
 
if (o-diff_index_cached)
return;
@@ -429,7 +435,8 @@ static void restore_cache_bottom(struct traverse_info 
*info, int bottom)
 
 static int switch_cache_bottom(struct traverse_info *info)
 {
-   struct unpack_trees_options *o = info-data;
+   struct unpack_callback_info *uci = info-data;
+   struct unpack_trees_options *o = uci-options;
int ret, pos;
 
if (o-diff_index_cached)
@@ -452,9 +459,14 @@ static int traverse_trees_recursive(int n, unsigned long 
dirmask,
int i, ret, bottom;
struct tree_desc t[MAX_UNPACK_TREES];
void *buf[MAX_UNPACK_TREES];
+   struct unpack_callback_info *uci = info-data;
+   struct unpack_callback_info newuci;
struct traverse_info newinfo;
struct name_entry *p;
 
+   newuci = *uci;
+   newuci.df_conflicts |= df_conflicts;
+
p = names;
while (!p-mode)
p++;
@@ -464,7 +476,7 @@ static int traverse_trees_recursive(int n, unsigned long 
dirmask,
newinfo.pathspec = info-pathspec;
newinfo.name = *p;
newinfo.pathlen += tree_entry_len(p) + 1;
-   newinfo.df_conflicts |= df_conflicts;
+   newinfo.data = newuci;
 
for (i = 0; i  n; i++, dirmask = 1) {
const unsigned char *sha1 = NULL;
@@ -564,8 +576,9 @@ static int unpack_nondirectories(int n, unsigned long mask,
 const struct traverse_info *info)
 {
int i;
-   struct unpack_trees_options *o = info-data;
-   unsigned long conflicts = info-df_conflicts | dirmask;
+   struct unpack_callback_info *uci = info-data;
+   struct unpack_trees_options *o = uci-options;
+   unsigned long conflicts = uci-df_conflicts | dirmask;
 
/* Do we have *only* directories? Nothing to do */
if (mask == dirmask  !src[0])
@@ -644,7 +657,8 @@ static int find_cache_pos(struct traverse_info *info,
  const struct name_entry *p)
 {
int pos;
-   struct unpack_trees_options *o = info-data;
+   struct unpack_callback_info *uci = info-data;
+   struct unpack_trees_options *o = uci-options;
struct index_state *index = o-src_index;
int pfxlen = info-pathlen;
int p_len = tree_entry_len(p);
@@ -699,7 +713,8 @@ static struct cache_entry *find_cache_entry(struct 
traverse_info *info,
const struct name_entry *p)
 {
int pos = find_cache_pos(info, p);
-   struct unpack_trees_options *o = 

Re: [PATCH v4 0/6] submodule: drop the top-level requirement

[Jens Lehmann]

Am 16.06.2013 16:18, schrieb John Keeping:
 Changes since v3:
 
 * There are four new patches, three of which are style fixes for
   existing tests and one fixes an existing error message to return a
   more accurate path when recursing.
 
 * You now cannot run git submodule add relative URL from a
   subdirectory.  Because the interpretation of the URL changes depending
   on whether or not remote.origin.url is configured, I have decided to
   just ban this for now.  If someone comes up with a sensible way to
   handle this then we can lift this restriction later.
 
 * The path variable exported in submodule foreach now uses the
   relative path and matches the sm_path variable.
 
 * I audited the code again and fixed a few more cases that weren't
   printing relative paths (notably submodule init and submodule
   foreach).
 
 * More tests.

Thanks for working on this! This series is looking good to me.

 John Keeping (6):
   t7401: make indentation consistent
   t7403: modernize style
   t7403: add missing  chaining
   submodule: show full path in error message
   rev-parse: add --prefix option
   submodule: drop the top-level requirement
 
  Documentation/git-rev-parse.txt |  16 ++
  builtin/rev-parse.c |  24 ++-
  git-submodule.sh| 135 ++
  t/t1513-rev-parse-prefix.sh |  96 ++
  t/t7400-submodule-basic.sh  |  80 +
  t/t7401-submodule-summary.sh| 116 +++-
  t/t7403-submodule-sync.sh   | 388 
 ++--
  t/t7406-submodule-update.sh |  15 ++
  t/t7407-submodule-foreach.sh|  16 ++
  9 files changed, 673 insertions(+), 213 deletions(-)
  create mode 100755 t/t1513-rev-parse-prefix.sh
 

--
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] unpack-trees: don't shift conflicts left and right

[Junio C Hamano]

René Scharfe rene.scha...@lsrfire.ath.cx writes:

 The information is only useful for the unpack_trees callback, and
 info-data is a more appropriate place to hang such a callback
 specific data.
 
 Perhaps we should use info-data field to point at
 
  struct {
  struct unpack_trees_options *o;
  unsigned long df_conflict;
  };
 
 and get rid of info-conflicts field?

 Here's a patch that does so, but it complicates matters quite a bit.
 Did I miss anything (or rather: add too much)?

I do not think so.  These bits are needed per recursion level, and
it cannot be shoved into unpack_trees_options so I suspect that your
patch is the best we can do.  Or, perhaps we can

 - add df_conflict to struct unpack_trees_options;

 - have traverse_info-data point at struct unpack_trees_options as
   before; and

 - save the old value of o-df_conflict on the stack of
   traverse_trees_recursive(), update the field in place, and
   restore it when the recursion returns???

 ---
  tree-walk.h|  1 -
  unpack-trees.c | 38 +-
  2 files changed, 29 insertions(+), 10 deletions(-)

 diff --git a/tree-walk.h b/tree-walk.h
 index ae04b64..4876695 100644
 --- a/tree-walk.h
 +++ b/tree-walk.h
 @@ -46,7 +46,6 @@ struct traverse_info {
   int pathlen;
   struct pathspec *pathspec;
  
 - unsigned long df_conflicts;
   traverse_callback_t fn;
   void *data;
   int show_all_errors;
 diff --git a/unpack-trees.c b/unpack-trees.c
 index b27f2a6..1c1b4de 100644
 --- a/unpack-trees.c
 +++ b/unpack-trees.c
 @@ -416,11 +416,17 @@ static int unpack_index_entry(struct cache_entry *ce,
   return ret;
  }
  
 +struct unpack_callback_info {
 + struct unpack_trees_options *options;
 + unsigned long df_conflicts;
 +};
 +
  static int find_cache_pos(struct traverse_info *, const struct name_entry *);
  
  static void restore_cache_bottom(struct traverse_info *info, int bottom)
  {
 - struct unpack_trees_options *o = info-data;
 + struct unpack_callback_info *uci = info-data;
 + struct unpack_trees_options *o = uci-options;
  
   if (o-diff_index_cached)
   return;
 @@ -429,7 +435,8 @@ static void restore_cache_bottom(struct traverse_info 
 *info, int bottom)
  
  static int switch_cache_bottom(struct traverse_info *info)
  {
 - struct unpack_trees_options *o = info-data;
 + struct unpack_callback_info *uci = info-data;
 + struct unpack_trees_options *o = uci-options;
   int ret, pos;
  
   if (o-diff_index_cached)
 @@ -452,9 +459,14 @@ static int traverse_trees_recursive(int n, unsigned long 
 dirmask,
   int i, ret, bottom;
   struct tree_desc t[MAX_UNPACK_TREES];
   void *buf[MAX_UNPACK_TREES];
 + struct unpack_callback_info *uci = info-data;
 + struct unpack_callback_info newuci;
   struct traverse_info newinfo;
   struct name_entry *p;
  
 + newuci = *uci;
 + newuci.df_conflicts |= df_conflicts;
 +
   p = names;
   while (!p-mode)
   p++;
 @@ -464,7 +476,7 @@ static int traverse_trees_recursive(int n, unsigned long 
 dirmask,
   newinfo.pathspec = info-pathspec;
   newinfo.name = *p;
   newinfo.pathlen += tree_entry_len(p) + 1;
 - newinfo.df_conflicts |= df_conflicts;
 + newinfo.data = newuci;
  
   for (i = 0; i  n; i++, dirmask = 1) {
   const unsigned char *sha1 = NULL;
 @@ -564,8 +576,9 @@ static int unpack_nondirectories(int n, unsigned long 
 mask,
const struct traverse_info *info)
  {
   int i;
 - struct unpack_trees_options *o = info-data;
 - unsigned long conflicts = info-df_conflicts | dirmask;
 + struct unpack_callback_info *uci = info-data;
 + struct unpack_trees_options *o = uci-options;
 + unsigned long conflicts = uci-df_conflicts | dirmask;
  
   /* Do we have *only* directories? Nothing to do */
   if (mask == dirmask  !src[0])
 @@ -644,7 +657,8 @@ static int find_cache_pos(struct traverse_info *info,
 const struct name_entry *p)
  {
   int pos;
 - struct unpack_trees_options *o = info-data;
 + struct unpack_callback_info *uci = info-data;
 + struct unpack_trees_options *o = uci-options;
   struct index_state *index = o-src_index;
   int pfxlen = info-pathlen;
   int p_len = tree_entry_len(p);
 @@ -699,7 +713,8 @@ static struct cache_entry *find_cache_entry(struct 
 traverse_info *info,
   const struct name_entry *p)
  {
   int pos = find_cache_pos(info, p);
 - struct unpack_trees_options *o = info-data;
 + struct unpack_callback_info *uci = info-data;
 + struct unpack_trees_options *o = uci-options;
  
   if (0 = pos)
   return o-src_index-cache[pos];
 @@ -742,7 +757,8 @@ static void debug_unpack_callback(int n,
  static int unpack_callback(int n, unsigned long mask, unsigned long dirmask, 
 struct 

Re: [PATCH] fixup! push: switch default from matching to simple

[Matthieu Moy]

Junio C Hamano gits...@pobox.com writes:

 Note that this has to further change if Ram's triangular push fix
 comes before 2.0.

I didn't follow precisely this topic. In any case, better have this in
the patch, if only as a reminder that this part will need to be updated.

 I am not sure if these original two lines are necessary.  Wouldn't
 it more appropriate to just drop the Without additional configuration
 and go straight to The default behaviour of this command...?

I think it makes sense to avoid having to go through too many sections
to understand the default behavior.

Right now, to know what git push does, the reader reads the
DESCRIPTION and finds nothing, reads the refspec... part and does not
see what happens when it's omitted, then see the EXAMPLE section

git push
= see git push origin

git push origin
= see push.default in git config --help

At least, keeping these lines, we avoid the last indirection.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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] Documentation/git-push.txt: explain better cases where --force is dangerous

[Marc Branchaud]

On 13-06-17 01:52 PM, Matthieu Moy wrote:

The behavior of git push --force is rather clear when it updates only
one remote ref, but running it when pushing several branches can really
be dangerous. Warn the users a bit more and give them the alternative to
push only one branch.

Signed-off-by: Matthieu Moy matthieu@imag.fr
---
  Documentation/git-push.txt | 8 
  1 file changed, 8 insertions(+)

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 938d1ee..9b9e7d1 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -136,6 +136,14 @@ already exists on the remote side.
not an ancestor of the local ref used to overwrite it.
This flag disables the check.  This can cause the
remote repository to lose commits; use it with care.
+   Note that `--force` applies to all the refs that are pushed,
+   hence using it with `push.default` set to `matching` or with
+   multiple push destination configured may override refs other


s/destination/destinations/

M.

--
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] diff: add --ignore-blank-lines option

[Antoine Pelisse]

 + } else if (changes != ULONG_MAX 
 +xch-i1 + changes - (lxch-i1 + lxch-chg1)  
 max_common) {
 + break;

 If we are no longer in interesting zone (changes != ULONG_MAX), it
 means we will stop if the distance is too big.
 changes is used in the calculation to consider the changes we have
 already ignored (xch-i1 - (lxch-i1 + lxch-chg1) will only work if
 xch and lxch are consecutive, we need to add the blank lines we
 ignored).

 And this uses max_common that is much larger than max_ignorable
 because...?

 The last interesting change, with its post context and inter hunk
 gap, together with precontext for this one, is close enough to the
 beginning of this one.  So it is understandable if xch by itself is
 intereseting to use max_common.  Even an interesting one, if that is
 so far from the last interesting one, should not be part of this
 hunk.

 However, if the current one is by itself uninteresting, should we
 still use the max_common, or should this be compared with
 max_ignorable?

Because of the recursive definition, we don't know yet if an
ignorable change will be interesting or not.
We need to make sure it will be close to another interesting change first.
If it is, it will fall in the first if part, and lxch will catch-up.
If not, we will eventually be too far and break.

Re-reading note: OK, This last sentence (If not we will eventually be
too far and break) is actually a bug. We might break before we find
something interesting while we should keep going. For example in such
a case, we should display like this, but won't:

@@ -x,x +x,x @@
+change   --- That is lxch
 1
 2
 3
+   --- Here we leave interesting
 4
 5
+   --- We are too far and quit searching
 6
 7
+
 8
 9
+
 10
 11
+change

 + } else {
 + if (changes == ULONG_MAX)
 + changes = 0;
 + changes += xch-chg2;

 Puzzled beyond guessing.  Also it is curious why here and only here
 we look at chg2 side of the things, not i1/chg1 in this whole thing.

 chg2 being the number of blank line *additions*.

 This is on the else side of if (!xch-ignore), so we are looking at
 ignored hunk, which means there is only blank line change.  Can chg2
 be 0 while chg1 is not zero, i.e. xch being a blank line removal?

Exactly. It can be a blank line removal. But I don't want to consider
it in the calculation.
Here's why:
We have:
1
2
3




4
5
6

and change it to:
change
1
2
3
4
5
6
change

What should be the output of diff --ignore-blank-lines ?

I chose this alternative:
@@ -1,3 +1,4 @@
+change
 1
 2
 3
@@ -7,3 +5,4 @@
 4
 5
 6
+change

While one could have chosen:
@@ -1,10 +1,8 @@
+change
 1
 2
 3
-
-
-
-
 4
 5
 6
+change

 What should happen in that case?  Don't we want to show it, for the
 same reason we want to keep removal, as long as it is close enough
 to the interesting zone?

Nothing is interesting here, we just leave the interesting zone (if
not already left) because everything else failed.
--
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] Documentation/git-push.txt: explain better cases where --force is dangerous

[Junio C Hamano]

Marc Branchaud marcn...@xiplink.com writes:

 On 13-06-17 01:52 PM, Matthieu Moy wrote:
 The behavior of git push --force is rather clear when it updates only
 one remote ref, but running it when pushing several branches can really
 be dangerous. Warn the users a bit more and give them the alternative to
 push only one branch.

 Signed-off-by: Matthieu Moy matthieu@imag.fr
 ---
   Documentation/git-push.txt | 8 
   1 file changed, 8 insertions(+)

 diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
 index 938d1ee..9b9e7d1 100644
 --- a/Documentation/git-push.txt
 +++ b/Documentation/git-push.txt
 @@ -136,6 +136,14 @@ already exists on the remote side.
  not an ancestor of the local ref used to overwrite it.
  This flag disables the check.  This can cause the
  remote repository to lose commits; use it with care.
 +Note that `--force` applies to all the refs that are pushed,
 +hence using it with `push.default` set to `matching` or with
 +multiple push destination configured may override refs other

 s/destination/destinations/

Good eyes.

After I re-read the one, I found that override somewhat a strange
expression.  There is nothing that overrides or to be overriden.

How about putting it like this?

 Documentation/git-push.txt | 9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 8b637d3..21294aa 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -124,6 +124,15 @@ no `push.default` configuration variable is set.
not an ancestor of the local ref used to overwrite it.
This flag disables the check.  This can cause the
remote repository to lose commits; use it with care.
+   Note that `--force` applies to all the refs that are pushed,
+   hence using it with `push.default` set to `matching` or with
+   multiple push destinations configured with `remote.*.push`
+   may push out refs other than the current branch (including
+   local refs that are strictly behind their remote counterpart).
+   To force a push to only one branch, use a `+` in front of the
+   refspec to push (e.g `git push origin +master` to force a push
+   to the `master` branch). See the `refspec...` section above
+   for details.
 
 --repo=repository::
This option is only relevant if no repository argument is
--
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] unpack-trees: don't shift conflicts left and right

[René Scharfe]

Am 17.06.2013 22:44, schrieb Junio C Hamano:
 René Scharfe rene.scha...@lsrfire.ath.cx writes:
 
 The information is only useful for the unpack_trees callback, and
 info-data is a more appropriate place to hang such a callback
 specific data.

 Perhaps we should use info-data field to point at

 struct {
 struct unpack_trees_options *o;
 unsigned long df_conflict;
 };

 and get rid of info-conflicts field?

 Here's a patch that does so, but it complicates matters quite a bit.
 Did I miss anything (or rather: add too much)?
 
 I do not think so.  These bits are needed per recursion level, and
 it cannot be shoved into unpack_trees_options so I suspect that your
 patch is the best we can do.  Or, perhaps we can
 
   - add df_conflict to struct unpack_trees_options;
 
   - have traverse_info-data point at struct unpack_trees_options as
 before; and
 
   - save the old value of o-df_conflict on the stack of
 traverse_trees_recursive(), update the field in place, and
 restore it when the recursion returns???

I'm not sure unpack_trees_options is the right place for that, but it
already has several members that aren't really options.  It would
look something like this:


 tree-walk.h| 1 -
 unpack-trees.c | 9 +++--
 unpack-trees.h | 1 +
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/tree-walk.h b/tree-walk.h
index ae04b64..4876695 100644
--- a/tree-walk.h
+++ b/tree-walk.h
@@ -46,7 +46,6 @@ struct traverse_info {
int pathlen;
struct pathspec *pathspec;
 
-   unsigned long df_conflicts;
traverse_callback_t fn;
void *data;
int show_all_errors;
diff --git a/unpack-trees.c b/unpack-trees.c
index b27f2a6..1c0ead0 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -454,6 +454,10 @@ static int traverse_trees_recursive(int n, unsigned long 
dirmask,
void *buf[MAX_UNPACK_TREES];
struct traverse_info newinfo;
struct name_entry *p;
+   struct unpack_trees_options *o = info-data;
+   unsigned long saved_df_conflicts = o-df_conflicts;
+
+   o-df_conflicts |= df_conflicts;
 
p = names;
while (!p-mode)
@@ -464,7 +468,6 @@ static int traverse_trees_recursive(int n, unsigned long 
dirmask,
newinfo.pathspec = info-pathspec;
newinfo.name = *p;
newinfo.pathlen += tree_entry_len(p) + 1;
-   newinfo.df_conflicts |= df_conflicts;
 
for (i = 0; i  n; i++, dirmask = 1) {
const unsigned char *sha1 = NULL;
@@ -480,6 +483,8 @@ static int traverse_trees_recursive(int n, unsigned long 
dirmask,
for (i = 0; i  n; i++)
free(buf[i]);
 
+   o-df_conflicts = saved_df_conflicts;
+
return ret;
 }
 
@@ -565,7 +570,7 @@ static int unpack_nondirectories(int n, unsigned long mask,
 {
int i;
struct unpack_trees_options *o = info-data;
-   unsigned long conflicts = info-df_conflicts | dirmask;
+   unsigned long conflicts = o-df_conflicts | dirmask;
 
/* Do we have *only* directories? Nothing to do */
if (mask == dirmask  !src[0])
diff --git a/unpack-trees.h b/unpack-trees.h
index 36a73a6..05ee968 100644
--- a/unpack-trees.h
+++ b/unpack-trees.h
@@ -66,6 +66,7 @@ struct unpack_trees_options {
 
struct cache_entry *df_conflict_entry;
void *unpack_data;
+   unsigned long df_conflicts;
 
struct index_state *dst_index;
struct index_state *src_index;

--
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

DNS issue when cloning over HTTP and HTTPS

[LCD 47]

The following snippet illustrates the problem:


$ uname -srvm
Linux 3.9.5-smp #2 SMP Mon Jun 10 02:54:26 CDT 2013 i686

$ git --version
git version 1.8.3

$ git clone https://github.com/torvalds/linux.git
Cloning into 'linux'...
fatal: unable to access 'https://github.com/torvalds/linux.git/': Could not 
resolve host: github.com (Could not contact DNS servers)


Of course, DNS is working fine, and GitHub is accessible from my
machine:


$ dig github.com

;  DiG 9.9.2-P2  github.com
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 20305
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;github.com.INA

;; ANSWER SECTION:
github.com.212INA204.232.175.90

;; AUTHORITY SECTION:
github.com.79055INNSns1.p16.dynect.net.
github.com.79055INNSns2.p16.dynect.net.
github.com.79055INNSns3.p16.dynect.net.
github.com.79055INNSns4.p16.dynect.net.

;; Query time: 0 msec
;; SERVER: 192.168.7.2#53(192.168.7.2)
;; WHEN: Tue Jun 18 00:46:13 2013
;; MSG SIZE  rcvd: 141


$ ping -c 3 github.com
PING github.com (204.232.175.90) 56(84) bytes of data.
64 bytes from github.com (204.232.175.90): icmp_req=1 ttl=52 time=142 ms
64 bytes from github.com (204.232.175.90): icmp_req=2 ttl=52 time=140 ms
64 bytes from github.com (204.232.175.90): icmp_req=3 ttl=52 time=154 ms

--- github.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 140.184/145.555/154.217/6.183 ms

$ nc -v github.com https
github.com [204.232.175.90] 443 (https) open
^C


A packet capture shows what's going on:  Git tries to resolve
github.com over LLMNR rather than DNS, and my router responds with
destination unreachable.  192.168.7.2 is my machine, and 192.168.7.1
is my router:


No. TimeSourceDestination   Length Expert 
Protocol Info
  1 0.00192.168.7.2   192.168.7.1   70
LLMNRStandard query 0xbfe4  A github.com

Frame 1: 70 bytes on wire (560 bits), 70 bytes captured (560 bits)
Ethernet II, Src: IntelCor_94:18:a4 (00:1c:c0:94:18:a4), Dst: 22:4e:7f:5b:02:55 
(22:4e:7f:5b:02:55)
Internet Protocol Version 4, Src: 192.168.7.2 (192.168.7.2), Dst: 192.168.7.1 
(192.168.7.1)
User Datagram Protocol, Src Port: 55585 (55585), Dst Port: 13568 (13568)
Source port: 55585 (55585)
Destination port: 13568 (13568)
Length: 36
Checksum: 0x8f89 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Link-local Multicast Name Resolution (query)
Transaction ID: 0xbfe4
Flags: 0x0100 Standard query
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
github.com: type A, class IN
Name: github.com
Type: A (Host address)
Class: IN (0x0001)

No. TimeSourceDestination   Length Expert 
Protocol Info
  2 0.000254192.168.7.1   192.168.7.2   98
ICMP Destination unreachable (Port unreachable)

Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Ethernet II, Src: 22:4e:7f:5b:02:55 (22:4e:7f:5b:02:55), Dst: IntelCor_94:18:a4 
(00:1c:c0:94:18:a4)
Internet Protocol Version 4, Src: 192.168.7.1 (192.168.7.1), Dst: 192.168.7.2 
(192.168.7.2)
Internet Control Message Protocol
Type: 3 (Destination unreachable)
Code: 3 (Port unreachable)
Checksum: 0x8c86 [correct]
Internet Protocol Version 4, Src: 192.168.7.2 (192.168.7.2), Dst: 
192.168.7.1 (192.168.7.1)
User Datagram Protocol, Src Port: 55585 (55585), Dst Port: 13568 (13568)
Source port: 55585 (55585)
Destination port: 13568 (13568)
Length: 36
Checksum: 0x9684 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Link-local Multicast Name Resolution (query)
Transaction ID: 0xbfe4
Flags: 0x0100 Standard query
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
github.com: type A, class IN
Name: github.com
Type: A (Host address)
Class: IN (0x0001)


Cloning with the git protocol works as expected.

A search on the net shows people having the same problem more than
an year ago, and the solution there seems to imply that Git can't cope
with async DNS in curl:

http://osdir.com/ml/freebsd-ports-bugs/2012-05/msg00095.html

Any idea?

/lcd

PS: Please CC me on replies, as I'm not subscribed to this list.
--
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: DNS issue when cloning over HTTP and HTTPS

[Daniel Stenberg]

On Tue, 18 Jun 2013, LCD 47 wrote:


   Cloning with the git protocol works as expected.

A search on the net shows people having the same problem more than an year 
ago, and the solution there seems to imply that Git can't cope with async 
DNS in curl:


http://osdir.com/ml/freebsd-ports-bugs/2012-05/msg00095.html

   Any idea?


It's not a git problem really. When you build libcurl to use c-ares for asynch 
name resolving you unfortunately don't get a really feature complete 
replacement for all stuff the stock synch resolver can do and I believe you 
(and person from that link from last year) experience that.


The solution for you is to:

a) rebuild libcurl with another resolving backend (there's a synch and 
threaded asynch one to choose from)


 or

b) fix c-ares to work properly in this scenario as well

--

 / daniel.haxx.se
--
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: DNS issue when cloning over HTTP and HTTPS

[LCD 47]

On 18 June 2013, Daniel Stenberg dan...@haxx.se wrote:
 On Tue, 18 Jun 2013, LCD 47 wrote:
 
Cloning with the git protocol works as expected.
 
 A search on the net shows people having the same problem more than an
 year ago, and the solution there seems to imply that Git can't cope
 with async DNS in curl:
 
 http://osdir.com/ml/freebsd-ports-bugs/2012-05/msg00095.html
 
Any idea?
 
 It's not a git problem really. When you build libcurl to use c-ares
 for asynch name resolving you unfortunately don't get a really feature
 complete replacement for all stuff the stock synch resolver can do and
 I believe you (and person from that link from last year) experience
 that.

 The solution for you is to:

 a) rebuild libcurl with another resolving backend (there's a synch and
 threaded asynch one to choose from)

  or

 b) fix c-ares to work properly in this scenario as well

Thank you for the quick and very helpful response.  I rebuilt curl
with the threaded resolver, then I rebuilt Git, and now cloning over
HTTP works fine.  I'll send a bug report to the maintainers of curl and
Git for my Linux distribution then.

/lcd
--
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] unpack-trees: don't shift conflicts left and right

[René Scharfe]

Am 17.06.2013 22:44, schrieb Junio C Hamano:
 René Scharfe rene.scha...@lsrfire.ath.cx writes:
 
 The information is only useful for the unpack_trees callback, and
 info-data is a more appropriate place to hang such a callback
 specific data.

 Perhaps we should use info-data field to point at

 struct {
 struct unpack_trees_options *o;
 unsigned long df_conflict;
 };

 and get rid of info-conflicts field?

 Here's a patch that does so, but it complicates matters quite a bit.
 Did I miss anything (or rather: add too much)?
 
 I do not think so.  These bits are needed per recursion level, and
 it cannot be shoved into unpack_trees_options so I suspect that your
 patch is the best we can do.  Or, perhaps we can
 
   - add df_conflict to struct unpack_trees_options;
 
   - have traverse_info-data point at struct unpack_trees_options as
 before; and
 
   - save the old value of o-df_conflict on the stack of
 traverse_trees_recursive(), update the field in place, and
 restore it when the recursion returns???

How about going into the opposite direction and moving df_conflicts
handling more into traverse_tree?  If the function saved the mask
and dirmask in traverse_info then callbacks could calculate the
cumulated d/f conflicts by walking the info chain, similar to how
make_traverse_path works.  That would match the spirit of that
struct.  Below is a patch for that, for illustration.

We could then remove the mask and dirmask parameters from
traverse_callback_t functions, as the callbacks can then get them
through traverse_info.

René


 tree-walk.c|  2 ++
 tree-walk.h|  2 +-
 unpack-trees.c | 11 ++-
 3 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/tree-walk.c b/tree-walk.c
index 6e30ef9..dae5db7 100644
--- a/tree-walk.c
+++ b/tree-walk.c
@@ -400,6 +400,8 @@ int traverse_trees(int n, struct tree_desc *t, struct 
traverse_info *info)
}
if (!mask)
break;
+   info-mask = mask;
+   info-dirmask = dirmask;
interesting = prune_traversal(e, info, base, interesting);
if (interesting  0)
break;
diff --git a/tree-walk.h b/tree-walk.h
index ae04b64..e308859 100644
--- a/tree-walk.h
+++ b/tree-walk.h
@@ -46,7 +46,7 @@ struct traverse_info {
int pathlen;
struct pathspec *pathspec;
 
-   unsigned long df_conflicts;
+   unsigned long mask, dirmask;
traverse_callback_t fn;
void *data;
int show_all_errors;
diff --git a/unpack-trees.c b/unpack-trees.c
index b27f2a6..58210d0 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -445,7 +445,6 @@ static int switch_cache_bottom(struct traverse_info *info)
 }
 
 static int traverse_trees_recursive(int n, unsigned long dirmask,
-   unsigned long df_conflicts,
struct name_entry *names,
struct traverse_info *info)
 {
@@ -464,7 +463,6 @@ static int traverse_trees_recursive(int n, unsigned long 
dirmask,
newinfo.pathspec = info-pathspec;
newinfo.name = *p;
newinfo.pathlen += tree_entry_len(p) + 1;
-   newinfo.df_conflicts |= df_conflicts;
 
for (i = 0; i  n; i++, dirmask = 1) {
const unsigned char *sha1 = NULL;
@@ -565,12 +563,16 @@ static int unpack_nondirectories(int n, unsigned long 
mask,
 {
int i;
struct unpack_trees_options *o = info-data;
-   unsigned long conflicts = info-df_conflicts | dirmask;
+   unsigned long conflicts = dirmask;
+   const struct traverse_info *previnfo;
 
/* Do we have *only* directories? Nothing to do */
if (mask == dirmask  !src[0])
return 0;
 
+   for (previnfo = info-prev; previnfo; previnfo = previnfo-prev)
+   conflicts |= previnfo-mask  ~previnfo-dirmask;
+
/*
 * Ok, we've filled in up to any potential index entry in src[0],
 * now do the rest.
@@ -820,8 +822,7 @@ static int unpack_callback(int n, unsigned long mask, 
unsigned long dirmask, str
}
}
 
-   if (traverse_trees_recursive(n, dirmask, mask  ~dirmask,
-names, info)  0)
+   if (traverse_trees_recursive(n, dirmask, names, info)  0)
return -1;
return mask;
}

--
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] diff: add --ignore-blank-lines option

[Junio C Hamano]

Antoine Pelisse apeli...@gmail.com writes:

 Re-reading note: OK, This last sentence (If not we will eventually be
 too far and break) is actually a bug. We might break before we find
 something interesting while we should keep going. For example in such
 a case, we should display like this, but won't:

Glad to see that my question has helped ;-)

 This is on the else side of if (!xch-ignore), so we are looking at
 ignored hunk, which means there is only blank line change.  Can chg2
 be 0 while chg1 is not zero, i.e. xch being a blank line removal?

 Exactly. It can be a blank line removal. But I don't want to consider
 it in the calculation.
 Here's why:
 ...
 What should be the output of diff --ignore-blank-lines ?

 I chose this alternative:
 @@ -1,3 +1,4 @@
 +change
  1
  2
  3
 @@ -7,3 +5,4 @@
  4
  5
  6
 +change

 While one could have chosen:
 @@ -1,10 +1,8 @@
 +change
  1
  2
  3
 -
 -
 -
 -
  4
  5
  6
 +change
 ...
 Nothing is interesting here, we just leave the interesting zone (if
 not already left) because everything else failed.

Yes, that asymmetry is what I was wondering if we want to have.  If
we show additional blanks as a significant event, I am not so sure
we can say Nothing is interesting here.

I do not feel strongly either way, but it just felt somewhat
inconsistent.

Thanks.
--
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] unpack-trees: don't shift conflicts left and right

[Junio C Hamano]

René Scharfe rene.scha...@lsrfire.ath.cx writes:

 Am 17.06.2013 22:44, schrieb Junio C Hamano:
 
 ...  Or, perhaps we can
 
   - add df_conflict to struct unpack_trees_options;
 
   - have traverse_info-data point at struct unpack_trees_options as
 before; and
 
   - save the old value of o-df_conflict on the stack of
 traverse_trees_recursive(), update the field in place, and
 restore it when the recursion returns???

 I'm not sure unpack_trees_options is the right place for that, but it
 already has several members that aren't really options.

Yup, most notably the df_conflict_entry singleton sentinel.

 It would look something like this:

Hmm, that does not look too bad, actually.



  tree-walk.h| 1 -
  unpack-trees.c | 9 +++--
  unpack-trees.h | 1 +
  3 files changed, 8 insertions(+), 3 deletions(-)

 diff --git a/tree-walk.h b/tree-walk.h
 index ae04b64..4876695 100644
 --- a/tree-walk.h
 +++ b/tree-walk.h
 @@ -46,7 +46,6 @@ struct traverse_info {
   int pathlen;
   struct pathspec *pathspec;
  
 - unsigned long df_conflicts;
   traverse_callback_t fn;
   void *data;
   int show_all_errors;
 diff --git a/unpack-trees.c b/unpack-trees.c
 index b27f2a6..1c0ead0 100644
 --- a/unpack-trees.c
 +++ b/unpack-trees.c
 @@ -454,6 +454,10 @@ static int traverse_trees_recursive(int n, unsigned long 
 dirmask,
   void *buf[MAX_UNPACK_TREES];
   struct traverse_info newinfo;
   struct name_entry *p;
 + struct unpack_trees_options *o = info-data;
 + unsigned long saved_df_conflicts = o-df_conflicts;
 +
 + o-df_conflicts |= df_conflicts;
  
   p = names;
   while (!p-mode)
 @@ -464,7 +468,6 @@ static int traverse_trees_recursive(int n, unsigned long 
 dirmask,
   newinfo.pathspec = info-pathspec;
   newinfo.name = *p;
   newinfo.pathlen += tree_entry_len(p) + 1;
 - newinfo.df_conflicts |= df_conflicts;
  
   for (i = 0; i  n; i++, dirmask = 1) {
   const unsigned char *sha1 = NULL;
 @@ -480,6 +483,8 @@ static int traverse_trees_recursive(int n, unsigned long 
 dirmask,
   for (i = 0; i  n; i++)
   free(buf[i]);
  
 + o-df_conflicts = saved_df_conflicts;
 +
   return ret;
  }
  
 @@ -565,7 +570,7 @@ static int unpack_nondirectories(int n, unsigned long 
 mask,
  {
   int i;
   struct unpack_trees_options *o = info-data;
 - unsigned long conflicts = info-df_conflicts | dirmask;
 + unsigned long conflicts = o-df_conflicts | dirmask;
  
   /* Do we have *only* directories? Nothing to do */
   if (mask == dirmask  !src[0])
 diff --git a/unpack-trees.h b/unpack-trees.h
 index 36a73a6..05ee968 100644
 --- a/unpack-trees.h
 +++ b/unpack-trees.h
 @@ -66,6 +66,7 @@ struct unpack_trees_options {
  
   struct cache_entry *df_conflict_entry;
   void *unpack_data;
 + unsigned long df_conflicts;
  
   struct index_state *dst_index;
   struct index_state *src_index;
--
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] unpack-trees: don't shift conflicts left and right

[Junio C Hamano]

René Scharfe rene.scha...@lsrfire.ath.cx writes:

 How about going into the opposite direction and moving df_conflicts
 handling more into traverse_tree?  If the function saved the mask
 and dirmask in traverse_info then callbacks could calculate the
 cumulated d/f conflicts by walking the info chain, similar to how
 make_traverse_path works.  That would match the spirit of that
 struct.  Below is a patch for that, for illustration.

 We could then remove the mask and dirmask parameters from
 traverse_callback_t functions, as the callbacks can then get them
 through traverse_info.

Hmph.

 @@ -565,12 +563,16 @@ static int unpack_nondirectories(int n, unsigned long 
 mask,
  {
   int i;
   struct unpack_trees_options *o = info-data;
 - unsigned long conflicts = info-df_conflicts | dirmask;
 + unsigned long conflicts = dirmask;

We grab the dirmask for the current level.

 + const struct traverse_info *previnfo;
  
   /* Do we have *only* directories? Nothing to do */
   if (mask == dirmask  !src[0])
   return 0;
  
 + for (previnfo = info-prev; previnfo; previnfo = previnfo-prev)
 + conflicts |= previnfo-mask  ~previnfo-dirmask;

And OR-in the bits for non-directories in levels that are closer to
the root (i.e. if a path that corresponds to our parent directory is
a non-directory in one of the trees, our path cannot be a file in
that tree).

So the bit-math looks correct here.  conflicts ends up having bits
set for trees that cannot have a non-directory at the path we are
looking at.

But the need to go all the way up in the recursive callframes to get
the union of bitmask to get conflicts looks somewhat ugly.

I dunno.
--
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 1/2] builtin/checkout.c: don't leak memory in check_tracking_name

[Brandon Casey]

From: Brandon Casey draf...@gmail.com

remote_find_tracking() populates the query struct with an allocated
string in the dst member.  So, we do not need to xstrdup() the string,
since we can transfer ownership from the query struct (which will go
out of scope at the end of this function) to our callback struct, but
we must free the string if it will not be used so we will not leak
memory.

Let's do so.

Signed-off-by: Brandon Casey draf...@gmail.com
---
 builtin/checkout.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/builtin/checkout.c b/builtin/checkout.c
index f5b50e5..3be0018 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -838,13 +838,16 @@ static int check_tracking_name(struct remote *remote, 
void *cb_data)
memset(query, 0, sizeof(struct refspec));
query.src = cb-src_ref;
if (remote_find_tracking(remote, query) ||
-   get_sha1(query.dst, cb-dst_sha1))
+   get_sha1(query.dst, cb-dst_sha1)) {
+   free(query.dst);
return 0;
+   }
if (cb-dst_ref) {
+   free(query.dst);
cb-unique = 0;
return 0;
}
-   cb-dst_ref = xstrdup(query.dst);
+   cb-dst_ref = query.dst;
return 0;
 }
 
-- 
1.8.2.415.g63cec41

--
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 2/2] t/t9802: explicitly name the upstream branch to use as a base

[Brandon Casey]

From: Brandon Casey draf...@gmail.com

Prior to commit fa83a33b, the 'git checkout' DWIMery would create a
new local branch if the specified branch name did not exist and it
matched exactly one ref in the remotes namespace.  It searched
the remotes namespace for matching refs using a simple comparison
of the trailing portion of the remote ref names.  This approach
could sometimes produce false positives or negatives.

Since fa83a33b, the DWIMery more strictly excludes the remote name
from the ref comparison by iterating through the remotes that are
configured in the .gitconfig file.  This has the side-effect that
any refs that exist in the remotes namespace, but do not match
the destination side of any remote refspec, will not be used by
the DWIMery.

This change in behavior breaks the tests in t9802 which relied on
the old behavior of searching all refs in the remotes namespace,
since the git-p4 script does not configure any remotes in the
.gitconfig.  Let's work around this in these tests by explicitly
naming the upstream branch to base the new local branch on when
calling 'git checkout'.

Signed-off-by: Brandon Casey draf...@gmail.com
---
 t/t9802-git-p4-filetype.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/t/t9802-git-p4-filetype.sh b/t/t9802-git-p4-filetype.sh
index eeefa67..b0d1d94 100755
--- a/t/t9802-git-p4-filetype.sh
+++ b/t/t9802-git-p4-filetype.sh
@@ -95,7 +95,7 @@ test_expect_success 'gitattributes setting eol=lf produces lf 
newlines' '
git init 
echo * eol=lf .gitattributes 
git p4 sync //depot@all 
-   git checkout master 
+   git checkout -b master p4/master 
test_cmp $cli/f-unix-orig f-unix 
test_cmp $cli/f-win-as-lf f-win
)
@@ -109,7 +109,7 @@ test_expect_success 'gitattributes setting eol=crlf 
produces crlf newlines' '
git init 
echo * eol=crlf .gitattributes 
git p4 sync //depot@all 
-   git checkout master 
+   git checkout -b master p4/master 
test_cmp $cli/f-unix-as-crlf f-unix 
test_cmp $cli/f-win-orig f-win
)
-- 
1.8.2.415.g63cec41

--
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] http.c: don't rewrite the user:passwd string multiple times

[Brandon Casey]

From: Brandon Casey draf...@gmail.com

Curl requires that we manage any strings that we pass to it as pointers.
So, we should not be overwriting this strbuf after we've passed it to
curl.

Additionally, it is unnecessary since we only prompt for the user name
and password once, so we end up overwriting the strbuf with the same
sequence of characters each time.  This is why in practice it has not
caused any problems for git's use of curl; the internal strbuf char
pointer does not change, and get's overwritten with the same string
each time.

But it's unnecessary and potentially dangerous, so let's avoid it.

Signed-off-by: Brandon Casey draf...@gmail.com
---
 http.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/http.c b/http.c
index 92aba59..6828269 100644
--- a/http.c
+++ b/http.c
@@ -228,8 +228,8 @@ static void init_curl_http_auth(CURL *result)
 #else
{
static struct strbuf up = STRBUF_INIT;
-   strbuf_reset(up);
-   strbuf_addf(up, %s:%s,
+   if (!up.len)
+   strbuf_addf(up, %s:%s,
http_auth.username, http_auth.password);
curl_easy_setopt(result, CURLOPT_USERPWD, up.buf);
}
-- 
1.8.3.1.440.gc2bf105

--
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 v2 1/3] t9903: add tests for git-prompt pcmode

[Eduardo R. D'Avila]

git-prompt.sh lacks tests for PROMPT_COMMAND mode.

Add tests for:
* pcmode prompt without colors
* pcmode prompt with colors for bash
* pcmode prompt with colors for zsh

Having these tests enables an upcoming refactor in
a safe way.

Signed-off-by: Eduardo R. D'Avila erdav...@gmail.com
---
254 0   t/t9903-bash-prompt.sh
 t/t9903-bash-prompt.sh | 254 +
 1 file changed, 254 insertions(+)

diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh
index 15521cc..6a88778 100755
--- a/t/t9903-bash-prompt.sh
+++ b/t/t9903-bash-prompt.sh
@@ -10,6 +10,10 @@ test_description='test git-specific bash prompt functions'
 . $GIT_BUILD_DIR/contrib/completion/git-prompt.sh
 
 actual=$TRASH_DIRECTORY/actual
+c_red='\\[\\e[31m\\]'
+c_green='\\[\\e[32m\\]'
+c_lblue='\\[\\e[1;34m\\]'
+c_clear='\\[\\e[0m\\]'
 
 test_expect_success 'setup for prompt tests' '
mkdir -p subdir/subsubdir 
@@ -535,4 +539,254 @@ test_expect_success 'prompt - format string starting with 
dash' '
test_cmp expected $actual
 '
 
+test_expect_success 'prompt - pc mode' '
+   printf BEFORE: (master):AFTER expected 
+   printf  expected_output 
+   (
+   __git_ps1 BEFORE: :AFTER $actual 
+   test_cmp expected_output $actual 
+   printf %s $PS1 $actual
+   ) 
+   test_cmp expected $actual
+'
+
+test_expect_success 'prompt - bash color pc mode - branch name' '
+   printf BEFORE: (${c_green}master${c_clear}${c_clear}):AFTER expected 

+   (
+   GIT_PS1_SHOWCOLORHINTS=y 
+   __git_ps1 BEFORE: :AFTER $actual
+   printf %s $PS1 $actual
+   ) 
+   test_cmp expected $actual
+'
+
+test_expect_success 'prompt - bash color pc mode - detached head' '
+   printf BEFORE: (${c_red}(%s...)${c_clear}${c_clear}):AFTER $(git log 
-1 --format=%h b1^) expected 
+   git checkout b1^ 
+   test_when_finished git checkout master 
+   (
+   GIT_PS1_SHOWCOLORHINTS=y 
+   __git_ps1 BEFORE: :AFTER 
+   printf %s $PS1 $actual
+   ) 
+   test_cmp expected $actual
+'
+
+test_expect_success 'prompt - bash color pc mode - dirty status indicator - 
dirty worktree' '
+   printf BEFORE: (${c_green}master${c_clear} ${c_red}*${c_clear}):AFTER 
expected 
+   echo dirty file 
+   test_when_finished git reset --hard 
+   (
+   GIT_PS1_SHOWDIRTYSTATE=y 
+   GIT_PS1_SHOWCOLORHINTS=y 
+   __git_ps1 BEFORE: :AFTER 
+   printf %s $PS1 $actual
+   ) 
+   test_cmp expected $actual
+'
+
+test_expect_success 'prompt - bash color pc mode - dirty status indicator - 
dirty index' '
+   printf BEFORE: (${c_green}master${c_clear} 
${c_green}+${c_clear}):AFTER expected 
+   echo dirty file 
+   test_when_finished git reset --hard 
+   git add -u 
+   (
+   GIT_PS1_SHOWDIRTYSTATE=y 
+   GIT_PS1_SHOWCOLORHINTS=y 
+   __git_ps1 BEFORE: :AFTER 
+   printf %s $PS1 $actual
+   ) 
+   test_cmp expected $actual
+'
+
+test_expect_success 'prompt - bash color pc mode - dirty status indicator - 
dirty index and worktree' '
+   printf BEFORE: (${c_green}master${c_clear} 
${c_red}*${c_green}+${c_clear}):AFTER expected 
+   echo dirty index file 
+   test_when_finished git reset --hard 
+   git add -u 
+   echo dirty worktree file 
+   (
+   GIT_PS1_SHOWCOLORHINTS=y 
+   GIT_PS1_SHOWDIRTYSTATE=y 
+   __git_ps1 BEFORE: :AFTER 
+   printf %s $PS1 $actual
+   ) 
+   test_cmp expected $actual
+'
+
+test_expect_success 'prompt - bash color pc mode - dirty status indicator - 
before root commit' '
+   printf BEFORE: (${c_green}master${c_clear} 
${c_green}#${c_clear}):AFTER expected 
+   (
+   GIT_PS1_SHOWDIRTYSTATE=y 
+   GIT_PS1_SHOWCOLORHINTS=y 
+   cd otherrepo 
+   __git_ps1 BEFORE: :AFTER 
+   printf %s $PS1 $actual
+   ) 
+   test_cmp expected $actual
+'
+
+test_expect_success 'prompt - bash color pc mode - inside .git directory' '
+   printf BEFORE: (${c_green}GIT_DIR!${c_clear}${c_clear}):AFTER 
expected 
+   echo dirty file 
+   test_when_finished git reset --hard 
+   (
+   GIT_PS1_SHOWDIRTYSTATE=y 
+   GIT_PS1_SHOWCOLORHINTS=y 
+   cd .git 
+   __git_ps1 BEFORE: :AFTER 
+   printf %s $PS1 $actual
+   ) 
+   test_cmp expected $actual
+'
+
+test_expect_success 'prompt - bash color pc mode - stash status indicator' '
+   printf BEFORE: (${c_green}master${c_clear} 
${c_lblue}\$${c_clear}):AFTER expected 
+   echo 2 file 
+   git stash 
+   test_when_finished git stash drop 
+   (
+   GIT_PS1_SHOWSTASHSTATE=y 
+   GIT_PS1_SHOWCOLORHINTS=y 
+   

[PATCH v2 01/13] bash prompt: fix redirection coding style in tests

[SZEDER Gábor]

From: SZEDER Gábor sze...@ira.uka.de

Use 'file' instead of ' file', in accordance with the coding
guidelines.

Signed-off-by: SZEDER Gábor sze...@ira.uka.de
---
 t/t9903-bash-prompt.sh | 232 -
 1 file changed, 116 insertions(+), 116 deletions(-)

diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh
index 15521cc4..7c7f8b97 100755
--- a/t/t9903-bash-prompt.sh
+++ b/t/t9903-bash-prompt.sh
@@ -14,98 +14,98 @@ actual=$TRASH_DIRECTORY/actual
 test_expect_success 'setup for prompt tests' '
mkdir -p subdir/subsubdir 
git init otherrepo 
-   echo 1  file 
+   echo 1 file 
git add file 
test_tick 
git commit -m initial 
git tag -a -m msg1 t1 
git checkout -b b1 
-   echo 2  file 
+   echo 2 file 
git commit -m second b1 file 
-   echo 3  file 
+   echo 3 file 
git commit -m third b1 file 
git tag -a -m msg2 t2 
git checkout -b b2 master 
-   echo 0  file 
+   echo 0 file 
git commit -m second b2 file 
-   echo 00  file 
+   echo 00 file 
git commit -m another b2 file 
-   echo 000  file 
+   echo 000 file 
git commit -m yet another b2 file 
git checkout master
 '
 
 test_expect_success 'gitdir - from command line (through $__git_dir)' '
-   echo $TRASH_DIRECTORY/otherrepo/.git  expected 
+   echo $TRASH_DIRECTORY/otherrepo/.git expected 
(
__git_dir=$TRASH_DIRECTORY/otherrepo/.git 
-   __gitdir  $actual
+   __gitdir $actual
) 
test_cmp expected $actual
 '
 
 test_expect_success 'gitdir - repo as argument' '
-   echo otherrepo/.git  expected 
-   __gitdir otherrepo  $actual 
+   echo otherrepo/.git expected 
+   __gitdir otherrepo $actual 
test_cmp expected $actual
 '
 
 test_expect_success 'gitdir - remote as argument' '
-   echo remote  expected 
-   __gitdir remote  $actual 
+   echo remote expected 
+   __gitdir remote $actual 
test_cmp expected $actual
 '
 
 test_expect_success 'gitdir - .git directory in cwd' '
-   echo .git  expected 
-   __gitdir  $actual 
+   echo .git expected 
+   __gitdir $actual 
test_cmp expected $actual
 '
 
 test_expect_success 'gitdir - .git directory in parent' '
-   echo $(pwd -P)/.git  expected 
+   echo $(pwd -P)/.git expected 
(
cd subdir/subsubdir 
-   __gitdir  $actual
+   __gitdir $actual
) 
test_cmp expected $actual
 '
 
 test_expect_success 'gitdir - cwd is a .git directory' '
-   echo .  expected 
+   echo . expected 
(
cd .git 
-   __gitdir  $actual
+   __gitdir $actual
) 
test_cmp expected $actual
 '
 
 test_expect_success 'gitdir - parent is a .git directory' '
-   echo $(pwd -P)/.git  expected 
+   echo $(pwd -P)/.git expected 
(
cd .git/refs/heads 
-   __gitdir  $actual
+   __gitdir $actual
) 
test_cmp expected $actual
 '
 
 test_expect_success 'gitdir - $GIT_DIR set while .git directory in cwd' '
-   echo $TRASH_DIRECTORY/otherrepo/.git  expected 
+   echo $TRASH_DIRECTORY/otherrepo/.git expected 
(
GIT_DIR=$TRASH_DIRECTORY/otherrepo/.git 
export GIT_DIR 
-   __gitdir  $actual
+   __gitdir $actual
) 
test_cmp expected $actual
 '
 
 test_expect_success 'gitdir - $GIT_DIR set while .git directory in parent' '
-   echo $TRASH_DIRECTORY/otherrepo/.git  expected 
+   echo $TRASH_DIRECTORY/otherrepo/.git expected 
(
GIT_DIR=$TRASH_DIRECTORY/otherrepo/.git 
export GIT_DIR 
cd subdir 
-   __gitdir  $actual
+   __gitdir $actual
) 
test_cmp expected $actual
 '
@@ -119,36 +119,36 @@ test_expect_success 'gitdir - non-existing $GIT_DIR' '
 '
 
 test_expect_success 'gitdir - gitfile in cwd' '
-   echo $(pwd -P)/otherrepo/.git  expected 
-   echo gitdir: $TRASH_DIRECTORY/otherrepo/.git  subdir/.git 
+   echo $(pwd -P)/otherrepo/.git expected 
+   echo gitdir: $TRASH_DIRECTORY/otherrepo/.git subdir/.git 
test_when_finished rm -f subdir/.git 
(
cd subdir 
-   __gitdir  $actual
+   __gitdir $actual
) 
test_cmp expected $actual
 '
 
 test_expect_success 'gitdir - gitfile in parent' '
-   echo $(pwd -P)/otherrepo/.git  expected 
-   echo gitdir: $TRASH_DIRECTORY/otherrepo/.git  subdir/.git 
+   echo $(pwd -P)/otherrepo/.git expected 
+   echo gitdir: $TRASH_DIRECTORY/otherrepo/.git subdir/.git 
test_when_finished rm -f subdir/.git 
(
cd subdir/subsubdir 
-   __gitdir  $actual
+ 

[PATCH v2 2/3] git-prompt.sh: refactor colored prompt code

[Eduardo R. D'Avila]

__git_ps1_colorize_gitstring() sets color codes and
builds the prompt gitstring. It has duplicated code
to handle color codes for bash and zsh shells.
__git_ps1() also has duplicated logic to build the
prompt gitstring.

Remove duplication of logic to build gitstring in
__git_ps1_colorize_gitstring() and __git_ps1().

Leave in __git_ps1_colorize_gitstring() only logic
to set color codes.

Signed-off-by: Eduardo R. D'Avila erdav...@gmail.com
---
26  59  contrib/completion/git-prompt.sh
6   6   t/t9903-bash-prompt.sh
 contrib/completion/git-prompt.sh | 85 
 t/t9903-bash-prompt.sh   | 12 +++---
 2 files changed, 32 insertions(+), 65 deletions(-)

diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 86a4f3f..70515cc 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -225,8 +225,8 @@ __git_ps1_show_upstream ()
 }
 
 # Helper function that is meant to be called from __git_ps1.  It
-# builds up a gitstring injecting color codes into the appropriate
-# places.
+# injects color codes into the appropriate gitstring variables used
+# to build a gitstring.
 __git_ps1_colorize_gitstring ()
 {
if [[ -n ${ZSH_VERSION-} ]]; then
@@ -234,74 +234,40 @@ __git_ps1_colorize_gitstring ()
local c_green='%F{green}'
local c_lblue='%F{blue}'
local c_clear='%f'
-   local bad_color=$c_red
-   local ok_color=$c_green
-   local branch_color=$c_clear
-   local flags_color=$c_lblue
-   local branchstring=$c${b##refs/heads/}
-
-   if [ $detached = no ]; then
-   branch_color=$ok_color
-   else
-   branch_color=$bad_color
-   fi
-
-   gitstring=$branch_color$branchstring$c_clear
-
-   if [ -n $w$i$s$u$r$p ]; then
-   gitstring=$gitstring$z
-   fi
-   if [ $w = * ]; then
-   gitstring=$gitstring$bad_color$w
-   fi
-   if [ -n $i ]; then
-   gitstring=$gitstring$ok_color$i
-   fi
-   if [ -n $s ]; then
-   gitstring=$gitstring$flags_color$s
-   fi
-   if [ -n $u ]; then
-   gitstring=$gitstring$bad_color$u
-   fi
-   gitstring=$gitstring$c_clear$r$p
-   return
+   else
+   # Using \[ and \] around colors
+   # is necessary to prevent wrapping issues!
+   local c_red='\[\e[31m\]'
+   local c_green='\[\e[32m\]'
+   local c_lblue='\[\e[1;34m\]'
+   local c_clear='\[\e[0m\]'
fi
-   local c_red='\e[31m'
-   local c_green='\e[32m'
-   local c_lblue='\e[1;34m'
-   local c_clear='\e[0m'
local bad_color=$c_red
local ok_color=$c_green
-   local branch_color=$c_clear
local flags_color=$c_lblue
-   local branchstring=$c${b##refs/heads/}
 
+   local branch_color=
if [ $detached = no ]; then
branch_color=$ok_color
else
branch_color=$bad_color
fi
+   c=$branch_color$c
 
-   # Setting gitstring directly with \[ and \] around colors
-   # is necessary to prevent wrapping issues!
-   gitstring=\[$branch_color\]$branchstring\[$c_clear\]
-
-   if [ -n $w$i$s$u$r$p ]; then
-   gitstring=$gitstring$z
-   fi
+   z=$c_clear$z
if [ $w = * ]; then
-   gitstring=$gitstring\[$bad_color\]$w
+   w=$bad_color$w
fi
if [ -n $i ]; then
-   gitstring=$gitstring\[$ok_color\]$i
+   i=$ok_color$i
fi
if [ -n $s ]; then
-   gitstring=$gitstring\[$flags_color\]$s
+   s=$flags_color$s
fi
if [ -n $u ]; then
-   gitstring=$gitstring\[$bad_color\]$u
+   u=$bad_color$u
fi
-   gitstring=$gitstring\[$c_clear\]$r$p
+   r=$c_clear$r
 }
 
 # __git_ps1 accepts 0 or 1 arguments (i.e., format string)
@@ -443,19 +409,20 @@ __git_ps1 ()
fi
 
local z=${GIT_PS1_STATESEPARATOR- }
+
+   # NO color option unless in PROMPT_COMMAND mode
+   if [ $pcmode = yes ]  [ -n ${GIT_PS1_SHOWCOLORHINTS-} ]; 
then
+   __git_ps1_colorize_gitstring
+   fi
+
local f=$w$i$s$u
+   local gitstring=$c${b##refs/heads/}${f:+$z$f}$r$p
+
if [ $pcmode = yes ]; then
-   local gitstring=
-   if [ -n ${GIT_PS1_SHOWCOLORHINTS-} ]; then
-   __git_ps1_colorize_gitstring
-   else
-   

[PATCH v2 00/13] bash prompt speedup

[SZEDER Gábor]

From: SZEDER Gábor sze...@ira.uka.de

Hi,

displaying the git-specific bash prompt on Windows/MinGW takes quite
long, long enough to be noticeable.  This is mainly caused by the
numerous fork()s and exec()s to create subshells and run git or other
commands, which are rather expensive on Windows.

This patch series eliminates many command substitutions and commands
in __git_ps1() from top to bottom by replacing them with bash builtins
or consolidating them.  A few timing results are shown in the log
message of patch 10.


SZEDER Gábor (13):
  bash prompt: fix redirection coding style in tests
  bash prompt: fix here document indentation in interactive rebase test
  completion, bash prompt: move __gitdir() tests to completion test
suite
  bash prompt: add a test for symbolic link symbolic refs
  bash prompt: return early from __git_ps1() when not in a git
repository
  bash prompt: run 'git rev-parse --git-dir' directly instead of
__gitdir()
  bash prompt: use bash builtins to find out rebase state
  bash prompt: use bash builtins to find out current branch
  bash prompt: use bash builtins to get detached HEAD abbrev. object
name
  bash prompt: combine 'git rev-parse' executions
  bash prompt: use bash builtins to check stash state
  bash prompt: avoid command substitution when checking for untracked
files
  bash prompt: avoid command substitution when finalizing gitstring

 contrib/completion/git-completion.bash |   2 -
 contrib/completion/git-prompt.sh   | 223 ---
 t/t9902-completion.sh  | 134 ++
 t/t9903-bash-prompt.sh | 319 +++--
 4 files changed, 345 insertions(+), 333 deletions(-)

-- 
1.8.3.1.487.g8f4672d

--
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 v2 02/13] bash prompt: fix here document indentation in interactive rebase test

[SZEDER Gábor]

From: SZEDER Gábor sze...@ira.uka.de

Also move the shebang line into the here document.

Signed-off-by: SZEDER Gábor sze...@ira.uka.de
---
 t/t9903-bash-prompt.sh | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh
index 7c7f8b97..b0af5d5f 100755
--- a/t/t9903-bash-prompt.sh
+++ b/t/t9903-bash-prompt.sh
@@ -248,12 +248,12 @@ test_expect_success 'prompt - inside bare repository' '
 
 test_expect_success 'prompt - interactive rebase' '
printf  (b1|REBASE-i 2/3) expected
-   echo #!$SHELL_PATH fake_editor.sh 
-   cat fake_editor.sh \EOF 
-echo exec echo $1
-echo edit $(git log -1 --format=%h) $1
-echo exec echo $1
-EOF
+   cat fake_editor.sh -EOF 
+   #!$SHELL_PATH
+   echo exec echo \$1
+   echo edit \$(git log -1 --format=%h) \$1
+   echo exec echo \$1
+   EOF
test_when_finished rm -f fake_editor.sh 
chmod a+x fake_editor.sh 
test_set_editor $TRASH_DIRECTORY/fake_editor.sh 
-- 
1.8.3.1.487.g8f4672d

--
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 3/3] git-prompt.sh: enable color prompt in non-pcmode

[Eduardo R. D'Avila]

The use of colors in a prompt is only possible in
pcmode (using the variable PROMPT_COMMAND).

Enable color prompt in non-pcmode (using the variable
PS1) for both Bash and ZSH.

Signed-off-by: Eduardo R. D'Avila erdav...@gmail.com
---
15  9   contrib/completion/git-prompt.sh
19  0   t/t9903-bash-prompt.sh
 contrib/completion/git-prompt.sh | 24 +++-
 t/t9903-bash-prompt.sh   | 19 +++
 2 files changed, 34 insertions(+), 9 deletions(-)

diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 70515cc..c5c75e7 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -13,7 +13,7 @@
 #3a) Change your PS1 to call __git_ps1 as
 #command-substitution:
 #Bash: PS1='[\u@\h \W$(__git_ps1  (%s))]\$ '
-#ZSH:  PS1='[%n@%m %c$(__git_ps1  (%s))]\$ '
+#ZSH:  setopt PROMPT_SUBST ; PS1='[%n@%m %c$(__git_ps1  (%s))]\$ '
 #the optional argument will be used as format string.
 #3b) Alternatively, if you are using bash, __git_ps1 can be
 #used for PROMPT_COMMAND with two parameters, pre and
@@ -235,12 +235,18 @@ __git_ps1_colorize_gitstring ()
local c_lblue='%F{blue}'
local c_clear='%f'
else
-   # Using \[ and \] around colors
-   # is necessary to prevent wrapping issues!
-   local c_red='\[\e[31m\]'
-   local c_green='\[\e[32m\]'
-   local c_lblue='\[\e[1;34m\]'
-   local c_clear='\[\e[0m\]'
+   local c_red='\e[31m'
+   local c_green='\e[32m'
+   local c_lblue='\e[1;34m'
+   local c_clear='\e[0m'
+   if [ $pcmode = yes ]; then
+   # Using \[ and \] around colors
+   # is necessary to prevent wrapping issues!
+   c_red=\[$c_red\]
+   c_green=\[$c_green\]
+   c_lblue=\[$c_lblue\]
+   c_clear=\[$c_clear\]
+   fi
fi
local bad_color=$c_red
local ok_color=$c_green
@@ -411,7 +417,7 @@ __git_ps1 ()
local z=${GIT_PS1_STATESEPARATOR- }
 
# NO color option unless in PROMPT_COMMAND mode
-   if [ $pcmode = yes ]  [ -n ${GIT_PS1_SHOWCOLORHINTS-} ]; 
then
+   if [ -n ${GIT_PS1_SHOWCOLORHINTS-} ]; then
__git_ps1_colorize_gitstring
fi
 
@@ -422,7 +428,7 @@ __git_ps1 ()
gitstring=$(printf -- $printf_format $gitstring)
PS1=$ps1pc_start$gitstring$ps1pc_end
else
-   printf -- $printf_format $gitstring
+   printf -- ${printf_format//%s/%b} $gitstring
fi
fi
 }
diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh
index 1101adf..7dccc1c 100755
--- a/t/t9903-bash-prompt.sh
+++ b/t/t9903-bash-prompt.sh
@@ -789,4 +789,23 @@ test_expect_success 'prompt - zsh color pc mode - 
untracked files status indicat
test_cmp expected $actual
 '
 
+test_expect_success 'prompt - bash color ps1 mode - untracked files status 
indicator' '
+   printf  (\e[32mmaster\e[0m) expected 
+   (
+   GIT_PS1_SHOWCOLORHINTS=y 
+   __git_ps1 $actual
+   ) 
+   test_cmp expected $actual
+'
+
+test_expect_success 'prompt - zsh color ps1 mode - untracked files status 
indicator' '
+   printf  (%%F{green}master%%f) expected 
+   (
+   GIT_PS1_SHOWCOLORHINTS=y 
+   ZSH_VERSION=5.0.0 
+   __git_ps1 $actual
+   ) 
+   test_cmp expected $actual
+'
+
 test_done
-- 
1.8.3.1.440.g82707f8

--
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 v2 06/13] bash prompt: run 'git rev-parse --git-dir' directly instead of __gitdir()

[SZEDER Gábor]

From: SZEDER Gábor sze...@ira.uka.de

__git_ps1() finds out the path to the repository by using the
__gitdir() helper function.  __gitdir() is basically just a wrapper
around 'git rev-parse --git-dir', extended with support for
recognizing a remote repository given as argument, to use the path
given on the command line, and with a few shortcuts to recognize a git
repository in cwd or at $GIT_DIR quickly without actually running 'git
rev-parse'.  However, the former two is only necessary for the
completion script but makes no sense for the bash prompt, while the
latter shortcuts are performance optimizations __git_ps1() can do
without (they just avoid the overhead of fork()+exec()ing a git
process).

Run 'git rev-parse --git-dir' directly in __git_ps1(), because it will
allow this patch series to combine several $(git rev-parse ...)
command substitutions in the main code path, and the overall
performance benefit will far outweight the loss of those few shortcuts
in __gitdir().  Furthermore, since __gitdir() is not needed anymore
for the prompt, remove it from the prompt script finally eliminating
its duplication between the prompt and completion scripts.  Also
remove the comment from the completion script warning about this code
duplication.

Signed-off-by: SZEDER Gábor sze...@ira.uka.de
---
 contrib/completion/git-completion.bash |  2 --
 contrib/completion/git-prompt.sh   | 28 ++--
 2 files changed, 2 insertions(+), 28 deletions(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index 56c52c66..e0c8d6a1 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -33,8 +33,6 @@ esac
 # returns location of .git repo
 __gitdir ()
 {
-   # Note: this function is duplicated in git-prompt.sh
-   # When updating it, make sure you update the other one to match.
if [ -z ${1-} ]; then
if [ -n ${__git_dir-} ]; then
echo $__git_dir
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 96b496cc..0fc1d317 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -80,30 +80,6 @@
 # GIT_PS1_SHOWCOLORHINTS to a nonempty value. The colors are based on
 # the colored output of git status -sb.
 
-# __gitdir accepts 0 or 1 arguments (i.e., location)
-# returns location of .git repo
-__gitdir ()
-{
-   # Note: this function is duplicated in git-completion.bash
-   # When updating it, make sure you update the other one to match.
-   if [ -z ${1-} ]; then
-   if [ -n ${__git_dir-} ]; then
-   echo $__git_dir
-   elif [ -n ${GIT_DIR-} ]; then
-   test -d ${GIT_DIR-} || return 1
-   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
-   else
-   echo $1
-   fi
-}
-
 # stores the divergence from upstream in $p
 # used by GIT_PS1_SHOWUPSTREAM
 __git_ps1_show_upstream ()
@@ -335,8 +311,8 @@ __git_ps1 ()
;;
esac
 
-   local g=$(__gitdir)
-   if [ -z $g ]; then
+   local g=
+   if ! g=$(git rev-parse --git-dir 2/dev/null); then
if [ $pcmode = yes ]; then
#In PC mode PS1 always needs to be set
PS1=$ps1pc_start$ps1pc_end
-- 
1.8.3.1.487.g8f4672d

--
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 v2 08/13] bash prompt: use bash builtins to find out current branch

[SZEDER Gábor]

From: SZEDER Gábor sze...@ira.uka.de

__git_ps1() runs the '$(git symbolic-ref HEAD)' command substitution
to find out whether we are on a branch and to find out the name of
that branch.  This imposes the overhead of fork()ing a subshell and
fork()+exec()ing a git process.

Since HEAD is in most cases a single-line file and the symbolic ref
format is quite simple to recognize and parse, read and parse it using
only bash builtins, thereby sparing all that fork()+exec() overhead.
However, HEAD can also be a symlink symbolic ref (due to
'core.preferSymlinkRefs'), so do this only if HEAD is not a symlink.

Signed-off-by: SZEDER Gábor sze...@ira.uka.de
---
 contrib/completion/git-prompt.sh | 46 
 1 file changed, 28 insertions(+), 18 deletions(-)

diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 26380787..4e5c8efa 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -355,25 +355,35 @@ __git_ps1 ()
r=|BISECTING
fi
 
-   test -n $b ||
-   b=$(git symbolic-ref HEAD 2/dev/null) || {
-   detached=yes
-   b=$(
-   case ${GIT_PS1_DESCRIBE_STYLE-} in
-   (contains)
-   git describe --contains HEAD ;;
-   (branch)
-   git describe --contains --all HEAD ;;
-   (describe)
-   git describe HEAD ;;
-   (* | default)
-   git describe --tags --exact-match HEAD ;;
-   esac 2/dev/null) ||
+   if [ -n $b ]; then
+   :
+   elif [ -h $g/HEAD ]; then
+   # symlink symbolic ref
+   b=$(git symbolic-ref HEAD 2/dev/null)
+   else
+   local head=
+   read head 2/dev/null $g/HEAD || return
+   # is it a symbolic ref?
+   b=${head#ref: }
+   if [ $head = $b ]; then
+   detached=yes
+   b=$(
+   case ${GIT_PS1_DESCRIBE_STYLE-} in
+   (contains)
+   git describe --contains HEAD ;;
+   (branch)
+   git describe --contains --all HEAD ;;
+   (describe)
+   git describe HEAD ;;
+   (* | default)
+   git describe --tags --exact-match HEAD 
;;
+   esac 2/dev/null) ||
 
-   b=$(cut -c1-7 $g/HEAD 2/dev/null)... ||
-   b=unknown
-   b=($b)
-   }
+   b=$(cut -c1-7 $g/HEAD 2/dev/null)... ||
+   b=unknown
+   b=($b)
+   fi
+   fi
fi
 
if [ -n $step ]  [ -n $total ]; then
-- 
1.8.3.1.487.g8f4672d

--
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 v2 07/13] bash prompt: use bash builtins to find out rebase state

[SZEDER Gábor]

From: SZEDER Gábor sze...@ira.uka.de

During an ongoing interactive rebase __git_ps1() finds out the name of
the rebased branch, the total number of patches and the number of the
current patch by executing a '$(cat .git/rebase-merge/FILE)' command
substitution for each.  That is not quite the most efficient way to
read single line single word files, because it imposes the overhead of
fork()ing a subshell and fork()+exec()ing 'cat' several times.

Use the 'read' bash builtin instead to avoid those overheads.

Signed-off-by: SZEDER Gábor sze...@ira.uka.de
---
 contrib/completion/git-prompt.sh | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 0fc1d317..26380787 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -325,9 +325,9 @@ __git_ps1 ()
local step=
local total=
if [ -d $g/rebase-merge ]; then
-   b=$(cat $g/rebase-merge/head-name 2/dev/null)
-   step=$(cat $g/rebase-merge/msgnum 2/dev/null)
-   total=$(cat $g/rebase-merge/end 2/dev/null)
+   read b 2/dev/null $g/rebase-merge/head-name
+   read step 2/dev/null $g/rebase-merge/msgnum
+   read total 2/dev/null $g/rebase-merge/end
if [ -f $g/rebase-merge/interactive ]; then
r=|REBASE-i
else
@@ -335,10 +335,10 @@ __git_ps1 ()
fi
else
if [ -d $g/rebase-apply ]; then
-   step=$(cat $g/rebase-apply/next 2/dev/null)
-   total=$(cat $g/rebase-apply/last 2/dev/null)
+   read step 2/dev/null $g/rebase-apply/next
+   read total 2/dev/null $g/rebase-apply/last
if [ -f $g/rebase-apply/rebasing ]; then
-   b=$(cat $g/rebase-apply/head-name 
2/dev/null)
+   read b 2/dev/null $g/rebase-apply/head-name
r=|REBASE
elif [ -f $g/rebase-apply/applying ]; then
r=|AM
-- 
1.8.3.1.487.g8f4672d

--
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 v2 03/13] completion, bash prompt: move __gitdir() tests to completion test suite

[SZEDER Gábor]

From: SZEDER Gábor sze...@ira.uka.de

Currently __gitdir() is duplicated in the git completion and prompt
scripts, while its tests are in the prompt test suite.  This patch
series is about to change __git_ps1() in a way that it won't need
__gitdir() anymore and __gitdir() will be removed from the prompt
script.

So move all __gitdir() test from the prompt test suite over to the
completion test suite.  Update the setup tests so that they perform
only those steps that are necessary for each test suite.

Signed-off-by: SZEDER Gábor sze...@ira.uka.de
---
 t/t9902-completion.sh  | 134 +
 t/t9903-bash-prompt.sh | 128 --
 2 files changed, 134 insertions(+), 128 deletions(-)

diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 81a1657e..5469dee8 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -122,6 +122,140 @@ test_gitcomp_nl ()
 
 invalid_variable_name='${foo.bar}'
 
+actual=$TRASH_DIRECTORY/actual
+
+test_expect_success 'setup for __gitdir tests' '
+   mkdir -p subdir/subsubdir 
+   git init otherrepo
+'
+
+test_expect_success '__gitdir - from command line (through $__git_dir)' '
+   echo $TRASH_DIRECTORY/otherrepo/.git expected 
+   (
+   __git_dir=$TRASH_DIRECTORY/otherrepo/.git 
+   __gitdir $actual
+   ) 
+   test_cmp expected $actual
+'
+
+test_expect_success '__gitdir - repo as argument' '
+   echo otherrepo/.git expected 
+   __gitdir otherrepo $actual 
+   test_cmp expected $actual
+'
+
+test_expect_success '__gitdir - remote as argument' '
+   echo remote expected 
+   __gitdir remote $actual 
+   test_cmp expected $actual
+'
+
+test_expect_success '__gitdir - .git directory in cwd' '
+   echo .git expected 
+   __gitdir $actual 
+   test_cmp expected $actual
+'
+
+test_expect_success '__gitdir - .git directory in parent' '
+   echo $(pwd -P)/.git expected 
+   (
+   cd subdir/subsubdir 
+   __gitdir $actual
+   ) 
+   test_cmp expected $actual
+'
+
+test_expect_success '__gitdir - cwd is a .git directory' '
+   echo . expected 
+   (
+   cd .git 
+   __gitdir $actual
+   ) 
+   test_cmp expected $actual
+'
+
+test_expect_success '__gitdir - parent is a .git directory' '
+   echo $(pwd -P)/.git expected 
+   (
+   cd .git/refs/heads 
+   __gitdir $actual
+   ) 
+   test_cmp expected $actual
+'
+
+test_expect_success '__gitdir - $GIT_DIR set while .git directory in cwd' '
+   echo $TRASH_DIRECTORY/otherrepo/.git expected 
+   (
+   GIT_DIR=$TRASH_DIRECTORY/otherrepo/.git 
+   export GIT_DIR 
+   __gitdir $actual
+   ) 
+   test_cmp expected $actual
+'
+
+test_expect_success '__gitdir - $GIT_DIR set while .git directory in parent' '
+   echo $TRASH_DIRECTORY/otherrepo/.git expected 
+   (
+   GIT_DIR=$TRASH_DIRECTORY/otherrepo/.git 
+   export GIT_DIR 
+   cd subdir 
+   __gitdir $actual
+   ) 
+   test_cmp expected $actual
+'
+
+test_expect_success '__gitdir - non-existing $GIT_DIR' '
+   (
+   GIT_DIR=$TRASH_DIRECTORY/non-existing 
+   export GIT_DIR 
+   test_must_fail __gitdir
+   )
+'
+
+test_expect_success '__gitdir - gitfile in cwd' '
+   echo $(pwd -P)/otherrepo/.git expected 
+   echo gitdir: $TRASH_DIRECTORY/otherrepo/.git subdir/.git 
+   test_when_finished rm -f subdir/.git 
+   (
+   cd subdir 
+   __gitdir $actual
+   ) 
+   test_cmp expected $actual
+'
+
+test_expect_success '__gitdir - gitfile in parent' '
+   echo $(pwd -P)/otherrepo/.git expected 
+   echo gitdir: $TRASH_DIRECTORY/otherrepo/.git subdir/.git 
+   test_when_finished rm -f subdir/.git 
+   (
+   cd subdir/subsubdir 
+   __gitdir $actual
+   ) 
+   test_cmp expected $actual
+'
+
+test_expect_success SYMLINKS '__gitdir - resulting path avoids symlinks' '
+   echo $(pwd -P)/otherrepo/.git expected 
+   mkdir otherrepo/dir 
+   test_when_finished rm -rf otherrepo/dir 
+   ln -s otherrepo/dir link 
+   test_when_finished rm -f link 
+   (
+   cd link 
+   __gitdir $actual
+   ) 
+   test_cmp expected $actual
+'
+
+test_expect_success '__gitdir - not a git repository' '
+   (
+   cd subdir/subsubdir 
+   GIT_CEILING_DIRECTORIES=$TRASH_DIRECTORY 
+   export GIT_CEILING_DIRECTORIES 
+   test_must_fail __gitdir
+   )
+'
+
 test_expect_success '__gitcomp - trailing space - options' '
test_gitcomp --re --dry-run --reuse-message= --reedit-message=
--reset-author -EOF
diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh

[PATCH v2 09/13] bash prompt: use bash builtins to get detached HEAD abbrev. object name

[SZEDER Gábor]

From: SZEDER Gábor sze...@ira.uka.de

When describing a detached HEAD according to the $GIT_PS1_DESCRIBE
environment variable fails, __git_ps1() runs the '$(cut -c1-7
.git/HEAD)' command substitution to put the 7 hexdigits abbreviated
commit object name in the prompt.  This imposes the overhead of
fork()ing a subshell and fork()+exec()ing 'cut'.

Thanks to the previous patch at this point the contents of HEAD has
already been read into a variable, so we can get the 7 hexdigits using
only parameter expansions, sparing the fork()+exec() overhead.

Since zsh doesn't implement substring expansion we can't just use
${head:0:7}, hence the remove everything except the first 7 chars
parameter expansion combination.

Signed-off-by: SZEDER Gábor sze...@ira.uka.de
---
 contrib/completion/git-prompt.sh | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 4e5c8efa..10ec6902 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -378,9 +378,8 @@ __git_ps1 ()
(* | default)
git describe --tags --exact-match HEAD 
;;
esac 2/dev/null) ||
-
-   b=$(cut -c1-7 $g/HEAD 2/dev/null)... ||
-   b=unknown
+   # detached head abbreviated object name
+   b=${head%${head#???}}...
b=($b)
fi
fi
-- 
1.8.3.1.487.g8f4672d

--
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 v2 04/13] bash prompt: add a test for symbolic link symbolic refs

[SZEDER Gábor]

From: SZEDER Gábor sze...@ira.uka.de

Signed-off-by: SZEDER Gábor sze...@ira.uka.de
---
 t/t9903-bash-prompt.sh | 9 +
 1 file changed, 9 insertions(+)

diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh
index 1047c664..48460ef6 100755
--- a/t/t9903-bash-prompt.sh
+++ b/t/t9903-bash-prompt.sh
@@ -40,6 +40,15 @@ test_expect_success 'prompt - branch name' '
test_cmp expected $actual
 '
 
+test_expect_success SYMLINKS 'prompt - branch name - symlink symref' '
+   printf  (master) expected 
+   test_when_finished git checkout master 
+   test_config core.preferSymlinkRefs true 
+   git checkout master 
+   __git_ps1 $actual 
+   test_cmp expected $actual
+'
+
 test_expect_success 'prompt - detached head' '
printf  ((%s...)) $(git log -1 --format=%h b1^) expected 
git checkout b1^ 
-- 
1.8.3.1.487.g8f4672d

--
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 v2 05/13] bash prompt: return early from __git_ps1() when not in a git repository

[SZEDER Gábor]

From: SZEDER Gábor sze...@ira.uka.de

... to gain one level of indentation for the bulk of the function.

(The patch looks quite unreadable, you'd better check it with 'git
diff -w'.)

Signed-off-by: SZEDER Gábor sze...@ira.uka.de
---
 contrib/completion/git-prompt.sh | 201 ---
 1 file changed, 101 insertions(+), 100 deletions(-)

diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 07a6218d..96b496cc 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -341,121 +341,122 @@ __git_ps1 ()
#In PC mode PS1 always needs to be set
PS1=$ps1pc_start$ps1pc_end
fi
+   return
+   fi
+
+   local r=
+   local b=
+   local step=
+   local total=
+   if [ -d $g/rebase-merge ]; then
+   b=$(cat $g/rebase-merge/head-name 2/dev/null)
+   step=$(cat $g/rebase-merge/msgnum 2/dev/null)
+   total=$(cat $g/rebase-merge/end 2/dev/null)
+   if [ -f $g/rebase-merge/interactive ]; then
+   r=|REBASE-i
+   else
+   r=|REBASE-m
+   fi
else
-   local r=
-   local b=
-   local step=
-   local total=
-   if [ -d $g/rebase-merge ]; then
-   b=$(cat $g/rebase-merge/head-name 2/dev/null)
-   step=$(cat $g/rebase-merge/msgnum 2/dev/null)
-   total=$(cat $g/rebase-merge/end 2/dev/null)
-   if [ -f $g/rebase-merge/interactive ]; then
-   r=|REBASE-i
+   if [ -d $g/rebase-apply ]; then
+   step=$(cat $g/rebase-apply/next 2/dev/null)
+   total=$(cat $g/rebase-apply/last 2/dev/null)
+   if [ -f $g/rebase-apply/rebasing ]; then
+   b=$(cat $g/rebase-apply/head-name 
2/dev/null)
+   r=|REBASE
+   elif [ -f $g/rebase-apply/applying ]; then
+   r=|AM
else
-   r=|REBASE-m
-   fi
-   else
-   if [ -d $g/rebase-apply ]; then
-   step=$(cat $g/rebase-apply/next 2/dev/null)
-   total=$(cat $g/rebase-apply/last 2/dev/null)
-   if [ -f $g/rebase-apply/rebasing ]; then
-   b=$(cat $g/rebase-apply/head-name 
2/dev/null)
-   r=|REBASE
-   elif [ -f $g/rebase-apply/applying ]; then
-   r=|AM
-   else
-   r=|AM/REBASE
-   fi
-   elif [ -f $g/MERGE_HEAD ]; then
-   r=|MERGING
-   elif [ -f $g/CHERRY_PICK_HEAD ]; then
-   r=|CHERRY-PICKING
-   elif [ -f $g/REVERT_HEAD ]; then
-   r=|REVERTING
-   elif [ -f $g/BISECT_LOG ]; then
-   r=|BISECTING
+   r=|AM/REBASE
fi
+   elif [ -f $g/MERGE_HEAD ]; then
+   r=|MERGING
+   elif [ -f $g/CHERRY_PICK_HEAD ]; then
+   r=|CHERRY-PICKING
+   elif [ -f $g/REVERT_HEAD ]; then
+   r=|REVERTING
+   elif [ -f $g/BISECT_LOG ]; then
+   r=|BISECTING
+   fi
 
-   test -n $b ||
-   b=$(git symbolic-ref HEAD 2/dev/null) || {
-   detached=yes
-   b=$(
-   case ${GIT_PS1_DESCRIBE_STYLE-} in
-   (contains)
-   git describe --contains HEAD ;;
-   (branch)
-   git describe --contains --all HEAD ;;
-   (describe)
-   git describe HEAD ;;
-   (* | default)
-   git describe --tags --exact-match HEAD 
;;
-   esac 2/dev/null) ||
+   test -n $b ||
+   b=$(git symbolic-ref HEAD 2/dev/null) || {
+   detached=yes
+   b=$(
+   case ${GIT_PS1_DESCRIBE_STYLE-} in
+   (contains)
+   git describe --contains HEAD ;;
+   (branch)
+   git 

[PATCH v2 13/13] bash prompt: avoid command substitution when finalizing gitstring

[SZEDER Gábor]

From: SZEDER Gábor sze...@ira.uka.de

Before setting $PS1, __git_ps1() uses a command substitution to
redirect the output from a printf into a variable.  Spare the overhead
of fork()ing a subshell by using 'printf -v var' to directly assign
the output to a variable.

zsh's printf doesn't support the '-v var' option, so stick with the
command substitution when under zsh.

Signed-off-by: SZEDER Gábor sze...@ira.uka.de
---
 contrib/completion/git-prompt.sh | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 77575b2d..a8e78f42 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -447,7 +447,11 @@ __git_ps1 ()
else
gitstring=$c${b##refs/heads/}${f:+$z$f}$r$p
fi
-   gitstring=$(printf -- $printf_format $gitstring)
+   if [[ -n ${ZSH_VERSION-} ]]; then
+   gitstring=$(printf -- $printf_format $gitstring)
+   else
+   printf -v gitstring -- $printf_format $gitstring
+   fi
PS1=$ps1pc_start$gitstring$ps1pc_end
else
# NO color option unless in PROMPT_COMMAND mode
-- 
1.8.3.1.487.g8f4672d

--
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 v2 12/13] bash prompt: avoid command substitution when checking for untracked files

[SZEDER Gábor]

From: SZEDER Gábor sze...@ira.uka.de

When enabled, the bash prompt can indicate the presence of untracked
files with a '%' sign.  __git_ps1() checks for untracked files by running the
'$(git ls-files --others --exclude-standard)' command substitution,
and displays the indicator when there is no output.

Avoid this command substitution by additionally passing
'--error-unmatch *', and checking the command's return value.

Signed-off-by: SZEDER Gábor sze...@ira.uka.de
---
 contrib/completion/git-prompt.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 208e2ec7..77575b2d 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -428,7 +428,7 @@ __git_ps1 ()
 
if [ -n ${GIT_PS1_SHOWUNTRACKEDFILES-} ] 
   [ $(git config --bool bash.showUntrackedFiles) != false 
] 
-  [ -n $(git ls-files --others --exclude-standard) ]
+  git ls-files --others --exclude-standard --error-unmatch -- 
'*' /dev/null 2/dev/null
then
u=%${ZSH_VERSION+%}
fi
-- 
1.8.3.1.487.g8f4672d

--
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 v2 10/13] bash prompt: combine 'git rev-parse' executions

[SZEDER Gábor]

From: SZEDER Gábor sze...@ira.uka.de

From the four '$(git rev-parse --opt)' command substitutions
__git_ps1() executes three in its main code path:

 - the first to get the path to the .git directory ('--git-dir'),
 - the second to check whether we're inside the .git directory
   ('--is-inside-git-dir'),
 - and the last, depending on the results of the second, either
   * to check whether it's a bare repo ('--is-bare-repository'), or
   * to check whether inside a work tree ('--is-inside-work-tree').

Naturally, this imposes the overhead of fork()ing three subshells and
fork()+exec()ing three git commands.

Combine these four 'git rev-parse' queries into one and use bash
parameter expansions to parse the combined output, i.e. to separate
the path to the .git directory from the true/false of
'--is-inside-git-dir', etc.  This way we can eliminate two of the
three subshells and git commands.

The whole series speeds up the bash prompt on Windows/MSysGit
considerably.  Here are some timing results in two scenarios, repeated
10 times:

At the top of the work tree, before:

$ time for i in {0..9} ; do prompt=$(__git_ps1) ; done

real0m1.716s
user0m0.301s
sys 0m0.772s

  After:

real0m0.686s
user0m0.075s
sys 0m0.287s

In a subdirectory, during rebase, stash status indicator enabled,
before:

real0m3.557s
user0m0.495s
sys 0m1.767s

  After:

real0m0.702s
user0m0.045s
sys 0m0.409s

Signed-off-by: SZEDER Gábor sze...@ira.uka.de
---
 contrib/completion/git-prompt.sh | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 10ec6902..b73cebf7 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -311,8 +311,9 @@ __git_ps1 ()
;;
esac
 
-   local g=
-   if ! g=$(git rev-parse --git-dir 2/dev/null); then
+   local repo_info=
+   if ! repo_info=$(git rev-parse --git-dir --is-inside-git-dir \
+   --is-bare-repository --is-inside-work-tree 2/dev/null); then
if [ $pcmode = yes ]; then
#In PC mode PS1 always needs to be set
PS1=$ps1pc_start$ps1pc_end
@@ -320,6 +321,13 @@ __git_ps1 ()
return
fi
 
+   local inside_worktree=${repo_info##*$'\n'}
+   repo_info=${repo_info%$'\n'*}
+   local bare_repo=${repo_info##*$'\n'}
+   repo_info=${repo_info%$'\n'*}
+   local inside_gitdir=${repo_info##*$'\n'}
+   local g=${repo_info%$'\n'*}
+
local r=
local b=
local step=
@@ -396,13 +404,13 @@ __git_ps1 ()
local c=
local p=
 
-   if [ true = $(git rev-parse --is-inside-git-dir 2/dev/null) ]; then
-   if [ true = $(git rev-parse --is-bare-repository 
2/dev/null) ]; then
+   if [ true = $inside_gitdir ]; then
+   if [ true = $bare_repo ]; then
c=BARE:
else
b=GIT_DIR!
fi
-   elif [ true = $(git rev-parse --is-inside-work-tree 2/dev/null) ]; 
then
+   elif [ true = $inside_worktree ]; then
if [ -n ${GIT_PS1_SHOWDIRTYSTATE-} ] 
   [ $(git config --bool bash.showDirtyState) != false ]
then
-- 
1.8.3.1.487.g8f4672d

--
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 v2 11/13] bash prompt: use bash builtins to check stash state

[SZEDER Gábor]

From: SZEDER Gábor sze...@ira.uka.de

When the environment variable $GIT_PS1_SHOWSTASHSTATE is set
__git_ps1() checks the presence of stashes by running 'git rev-parse
--verify refs/stash'.  This command not only checks that the
'refs/stash' ref exists but also, well, verifies that it's a valid
ref.

However, we don't need to be that thorough for the bash prompt.  We
can omit that verification and only check whether 'refs/stash' exists
or not.  Since 'git pack-refs' never packs 'refs/stash', it's a matter
of checking the existence of a ref file.  Perform this check using
only bash builtins to spare the overhead of fork()+exec()ing a git
process.

Signed-off-by: SZEDER Gábor sze...@ira.uka.de
---
 contrib/completion/git-prompt.sh | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index b73cebf7..208e2ec7 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -421,8 +421,9 @@ __git_ps1 ()
i=#
fi
fi
-   if [ -n ${GIT_PS1_SHOWSTASHSTATE-} ]; then
-   git rev-parse --verify refs/stash /dev/null 21  
s=$
+   if [ -n ${GIT_PS1_SHOWSTASHSTATE-} ] 
+  [ -r $g/refs/stash ]; then
+   s=$
fi
 
if [ -n ${GIT_PS1_SHOWUNTRACKEDFILES-} ] 
-- 
1.8.3.1.487.g8f4672d

--
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