Re: gitpacker progress report and a question

[Eric S. Raymond]

Felipe Contreras :
> Most of those old projects have a linear history,

INTERCAL didn't.  There were two branches for platform ports.

> But different commit/author and respective dates, and merges? Sounds
> like overkill.

I felt it was important that the metadata format be able to specify
git's entire metadata and DAG semantics.  Otherwise, as sure as the
sun rises, *somebody* would run into a corner case not covered, and
(quite rightly) curse me for a shortsighted fool who had done a
half-assed job.

I don't do half-assed jobs.  Not ever, no way, nohow.
-- 
http://www.catb.org/~esr/";>Eric S. Raymond
--
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

pandora sale is certainly worth it

[gillberts]

pandora sale    is one of the most sought
after items of jewellery. This is for many reasons. Firstly, a Pandora
diamond or necklace can be bought initially, but after the first purchase,
consumers will both want to and need to buy more Pandora jewellery to add to
their initial purchase.
pandora jewellery uk    is therefore
extremely popular in the uk and will continue to be popular for many years
to come. Hopefully this news article has given you enough of an overview
about Pandora jewellery. There are thousands of different drops and charms
consumers can purchase, and the ones they buy is up to them but there are
millions of different mixtures so they really will never have the same
combination as a friend, relative or neighbour. The main problem with one of
these home broadband speed estimates have been their difficult to rely on
nature. OFCOM, the telecoms regulator, has recently expressed its concerns
in the matter as more and more ISPs provide claims of the ability to provide
rates of speed higher than is realistically possible.

www.pandorajewelrybuy.co.uk













--
View this message in context: 
http://git.661346.n2.nabble.com/pandora-sale-is-certainly-worth-it-tp7572063.html
Sent from the git mailing list archive at Nabble.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 0/4] t4041 (diff-submodule-option): minor cleanup

[Ramkumar Ramachandra]

Hi,

This is the result of one lazy afternoon.

Ram

Ramkumar Ramachandra (4):
  t4041 (diff-submodule-option): parse digests sensibly
  t4041 (diff-submodule-option): rewrite add_file() routine
  t4041 (diff-submodule-option): modernize style
  t4041 (diff-submodule-option): change tense of test names

 t/t4041-diff-submodule-option.sh |  484 +++---
 1 files changed, 240 insertions(+), 244 deletions(-)

-- 
1.7.8.1.362.g5d6df.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

[PATCH 1/4] t4041 (diff-submodule-option): parse digests sensibly

[Ramkumar Ramachandra]

`git rev-list --max-count=1 HEAD` is a roundabout way of saying `git
rev-parse --verify HEAD`; replace a bunch of instances of the former
with the latter.  Also, don't unnecessarily `cut -c1-7` the rev-parse
output when the `--short` option is available.

Signed-off-by: Ramkumar Ramachandra 
---
 t/t4041-diff-submodule-option.sh |   14 +++---
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/t/t4041-diff-submodule-option.sh b/t/t4041-diff-submodule-option.sh
index 5377639..cfb71e5 100755
--- a/t/t4041-diff-submodule-option.sh
+++ b/t/t4041-diff-submodule-option.sh
@@ -21,7 +21,7 @@ add_file () {
test_tick &&
git commit -m "Add $name"
done >/dev/null
-   git rev-parse --verify HEAD | cut -c1-7
+   git rev-parse --short --verify HEAD
cd "$owd"
 }
 commit_file () {
@@ -33,7 +33,7 @@ test_create_repo sm1 &&
 add_file . foo >/dev/null
 
 head1=$(add_file sm1 foo1 foo2)
-fullhead1=$(cd sm1; git rev-list --max-count=1 $head1)
+fullhead1=$(cd sm1; git rev-parse --verify $head1)
 
 test_expect_success 'added submodule' "
git add sm1 &&
@@ -116,8 +116,8 @@ EOF
test_cmp expected actual
 "
 
-fullhead2=$(cd sm1; git rev-list --max-count=1 $head2)
 test_expect_success 'modified submodule(forward) --submodule=short' "
+fullhead2=$(cd sm1; git rev-parse --verify $head2)
git diff --submodule=short >actual &&
cat >expected <<-EOF &&
 diff --git a/sm1 b/sm1
@@ -135,7 +135,7 @@ commit_file sm1 &&
 head3=$(
cd sm1 &&
git reset --hard HEAD~2 >/dev/null &&
-   git rev-parse --verify HEAD | cut -c1-7
+   git rev-parse --short --verify HEAD
 )
 
 test_expect_success 'modified submodule(backward)' "
@@ -220,8 +220,8 @@ EOF
 rm -f sm1 &&
 test_create_repo sm1 &&
 head6=$(add_file sm1 foo6 foo7)
-fullhead6=$(cd sm1; git rev-list --max-count=1 $head6)
 test_expect_success 'nonexistent commit' "
+fullhead6=$(cd sm1; git rev-parse --verify $head6)
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
 Submodule sm1 $head4...$head6 (commits not present)
@@ -318,8 +318,8 @@ EOF
 "
 
 (cd sm1; git commit -mchange foo6 >/dev/null) &&
-head8=$(cd sm1; git rev-parse --verify HEAD | cut -c1-7) &&
 test_expect_success 'submodule is modified' "
+head8=$(cd sm1; git rev-parse --short --verify HEAD) &&
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
 Submodule sm1 $head6..$head8:
@@ -461,7 +461,7 @@ EOF
test_cmp expected actual
 "
 
-fullhead7=$(cd sm2; git rev-list --max-count=1 $head7)
+fullhead7=$(cd sm2; git rev-parse --verify $head7)
 
 test_expect_success 'given commit --submodule=short' "
git diff-index -p --submodule=short HEAD^ >actual &&
-- 
1.7.8.1.362.g5d6df.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

[PATCH 2/4] t4041 (diff-submodule-option): rewrite add_file() routine

[Ramkumar Ramachandra]

Instead of "cd there and then come back", use the "cd there in a
subshell" pattern.  Also fix '&&' chaining in one place.

Suggested-by: Junio C Hamano 
Signed-off-by: Ramkumar Ramachandra 
---
 t/t4041-diff-submodule-option.sh |   13 +
 1 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/t/t4041-diff-submodule-option.sh b/t/t4041-diff-submodule-option.sh
index cfb71e5..103c690 100755
--- a/t/t4041-diff-submodule-option.sh
+++ b/t/t4041-diff-submodule-option.sh
@@ -11,18 +11,15 @@ This test tries to verify the sanity of the --submodule 
option of git diff.
 . ./test-lib.sh
 
 add_file () {
-   sm=$1
-   shift
-   owd=$(pwd)
-   cd "$sm"
-   for name; do
+   (cd "$1" &&
+   shift &&
+   for name; do
echo "$name" > "$name" &&
git add "$name" &&
test_tick &&
git commit -m "Add $name"
-   done >/dev/null
-   git rev-parse --short --verify HEAD
-   cd "$owd"
+   done >/dev/null &&
+   git rev-parse --short --verify HEAD)
 }
 commit_file () {
test_tick &&
-- 
1.7.8.1.362.g5d6df.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

[PATCH 3/4] t4041 (diff-submodule-option): modernize style

[Ramkumar Ramachandra]

- Enclose tests in single quotes as opposed to double quotes.  This is
  the prevalent style in other tests.
- Remove the unused variable $head4_full.
- Indent the expected output so that it lines up with the rest of the
  test text.

Signed-off-by: Ramkumar Ramachandra 
---
 t/t4041-diff-submodule-option.sh |  459 +++---
 1 files changed, 229 insertions(+), 230 deletions(-)

diff --git a/t/t4041-diff-submodule-option.sh b/t/t4041-diff-submodule-option.sh
index 103c690..f61c664 100755
--- a/t/t4041-diff-submodule-option.sh
+++ b/t/t4041-diff-submodule-option.sh
@@ -32,41 +32,41 @@ add_file . foo >/dev/null
 head1=$(add_file sm1 foo1 foo2)
 fullhead1=$(cd sm1; git rev-parse --verify $head1)
 
-test_expect_success 'added submodule' "
+test_expect_success 'added submodule' '
git add sm1 &&
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
-Submodule sm1 000...$head1 (new submodule)
-EOF
+   Submodule sm1 000...$head1 (new submodule)
+   EOF
test_cmp expected actual
-"
+'
 
-test_expect_success 'added submodule, set diff.submodule' "
+test_expect_success 'added submodule, set diff.submodule' '
git config diff.submodule log &&
git add sm1 &&
git diff --cached >actual &&
cat >expected <<-EOF &&
-Submodule sm1 000...$head1 (new submodule)
-EOF
+   Submodule sm1 000...$head1 (new submodule)
+   EOF
git config --unset diff.submodule &&
test_cmp expected actual
-"
+'
 
-test_expect_success '--submodule=short overrides diff.submodule' "
+test_expect_success '--submodule=short overrides diff.submodule' '
test_config diff.submodule log &&
git add sm1 &&
git diff --submodule=short --cached >actual &&
cat >expected <<-EOF &&
-diff --git a/sm1 b/sm1
-new file mode 16
-index 000..$head1
 /dev/null
-+++ b/sm1
-@@ -0,0 +1 @@
-+Subproject commit $fullhead1
-EOF
+   diff --git a/sm1 b/sm1
+   new file mode 16
+   index 000..$head1
+   --- /dev/null
+   +++ b/sm1
+   @@ -0,0 +1 @@
+   +Subproject commit $fullhead1
+   EOF
test_cmp expected actual
-"
+'
 
 test_expect_success 'diff.submodule does not affect plumbing' '
test_config diff.submodule log &&
@@ -86,47 +86,47 @@ test_expect_success 'diff.submodule does not affect 
plumbing' '
 commit_file sm1 &&
 head2=$(add_file sm1 foo3)
 
-test_expect_success 'modified submodule(forward)' "
+test_expect_success 'modified submodule(forward)' '
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
-Submodule sm1 $head1..$head2:
-  > Add foo3
-EOF
+   Submodule sm1 $head1..$head2:
+ > Add foo3
+   EOF
test_cmp expected actual
-"
+'
 
-test_expect_success 'modified submodule(forward)' "
+test_expect_success 'modified submodule(forward)' '
git diff --submodule=log >actual &&
cat >expected <<-EOF &&
-Submodule sm1 $head1..$head2:
-  > Add foo3
-EOF
+   Submodule sm1 $head1..$head2:
+ > Add foo3
+   EOF
test_cmp expected actual
-"
+'
 
-test_expect_success 'modified submodule(forward) --submodule' "
+test_expect_success 'modified submodule(forward) --submodule' '
git diff --submodule >actual &&
cat >expected <<-EOF &&
-Submodule sm1 $head1..$head2:
-  > Add foo3
-EOF
+   Submodule sm1 $head1..$head2:
+ > Add foo3
+   EOF
test_cmp expected actual
-"
+'
 
-test_expect_success 'modified submodule(forward) --submodule=short' "
 fullhead2=$(cd sm1; git rev-parse --verify $head2)
+test_expect_success 'modified submodule(forward) --submodule=short' '
git diff --submodule=short >actual &&
cat >expected <<-EOF &&
-diff --git a/sm1 b/sm1
-index $head1..$head2 16
 a/sm1
-+++ b/sm1
-@@ -1 +1 @@
--Subproject commit $fullhead1
-+Subproject commit $fullhead2
-EOF
+   diff --git a/sm1 b/sm1
+   index $head1..$head2 16
+   --- a/sm1
+   +++ b/sm1
+   @@ -1 +1 @@
+   -Subproject commit $fullhead1
+   +Subproject commit $fullhead2
+   EOF
test_cmp expected actual
-"
+'
 
 commit_file sm1 &&
 head3=$(
@@ -135,29 +135,28 @@ head3=$(
git rev-parse --short --verify HEAD
 )
 
-test_expect_success 'modified submodule(backward)' "
+test_expect_success 'modified submodule(backward)' '
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
-Submodule sm1 $head2..$head3 (rewind):
-  < Add foo3
-  < Add foo2
-EOF
+   Submodule sm1 $head2..$head3 (rewind):
+ < Add foo3
+ < Add foo2
+   EOF
test_cmp expected actual
-"
+'
 
-head4=$(add_file sm1 foo4 foo5) &&
-head4_full=$(GIT_DIR=sm1/.git git rev-parse --verify HEAD)
-test_expect_success 'modified submodule(backward and forward)' "
+head4=$(add_file sm1 foo4 foo5)
+test_expect_success 'modified submodule(backward and forward)' '
 

[PATCH 4/4] t4041 (diff-submodule-option): change tense of test names

[Ramkumar Ramachandra]

Change the tense of test names from past to present, as this is the
prevalent style.

Signed-off-by: Ramkumar Ramachandra 
---
 t/t4041-diff-submodule-option.sh |   24 
 1 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/t/t4041-diff-submodule-option.sh b/t/t4041-diff-submodule-option.sh
index f61c664..25cefba 100755
--- a/t/t4041-diff-submodule-option.sh
+++ b/t/t4041-diff-submodule-option.sh
@@ -32,7 +32,7 @@ add_file . foo >/dev/null
 head1=$(add_file sm1 foo1 foo2)
 fullhead1=$(cd sm1; git rev-parse --verify $head1)
 
-test_expect_success 'added submodule' '
+test_expect_success 'add submodule' '
git add sm1 &&
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
@@ -41,7 +41,7 @@ test_expect_success 'added submodule' '
test_cmp expected actual
 '
 
-test_expect_success 'added submodule, set diff.submodule' '
+test_expect_success 'add submodule, set diff.submodule' '
git config diff.submodule log &&
git add sm1 &&
git diff --cached >actual &&
@@ -86,7 +86,7 @@ test_expect_success 'diff.submodule does not affect plumbing' 
'
 commit_file sm1 &&
 head2=$(add_file sm1 foo3)
 
-test_expect_success 'modified submodule(forward)' '
+test_expect_success 'modify submodule(forward)' '
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
Submodule sm1 $head1..$head2:
@@ -95,7 +95,7 @@ test_expect_success 'modified submodule(forward)' '
test_cmp expected actual
 '
 
-test_expect_success 'modified submodule(forward)' '
+test_expect_success 'modify submodule(forward)' '
git diff --submodule=log >actual &&
cat >expected <<-EOF &&
Submodule sm1 $head1..$head2:
@@ -104,7 +104,7 @@ test_expect_success 'modified submodule(forward)' '
test_cmp expected actual
 '
 
-test_expect_success 'modified submodule(forward) --submodule' '
+test_expect_success 'modify submodule(forward) --submodule' '
git diff --submodule >actual &&
cat >expected <<-EOF &&
Submodule sm1 $head1..$head2:
@@ -114,7 +114,7 @@ test_expect_success 'modified submodule(forward) 
--submodule' '
 '
 
 fullhead2=$(cd sm1; git rev-parse --verify $head2)
-test_expect_success 'modified submodule(forward) --submodule=short' '
+test_expect_success 'modify submodule(forward) --submodule=short' '
git diff --submodule=short >actual &&
cat >expected <<-EOF &&
diff --git a/sm1 b/sm1
@@ -135,7 +135,7 @@ head3=$(
git rev-parse --short --verify HEAD
 )
 
-test_expect_success 'modified submodule(backward)' '
+test_expect_success 'modify submodule(backward)' '
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
Submodule sm1 $head2..$head3 (rewind):
@@ -146,7 +146,7 @@ test_expect_success 'modified submodule(backward)' '
 '
 
 head4=$(add_file sm1 foo4 foo5)
-test_expect_success 'modified submodule(backward and forward)' '
+test_expect_success 'modify submodule(backward and forward)' '
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
Submodule sm1 $head2...$head4:
@@ -166,7 +166,7 @@ git add sm1 &&
 rm -f sm1 &&
 mv sm1-bak sm1
 
-test_expect_success 'typechanged submodule(submodule->blob), --cached' '
+test_expect_success 'typechange submodule(submodule->blob), --cached' '
git diff --submodule=log --cached >actual &&
cat >expected <<-EOF &&
Submodule sm1 $head4...000 (submodule deleted)
@@ -181,7 +181,7 @@ test_expect_success 'typechanged 
submodule(submodule->blob), --cached' '
test_cmp expected actual
 '
 
-test_expect_success 'typechanged submodule(submodule->blob)' '
+test_expect_success 'typechange submodule(submodule->blob)' '
git diff --submodule=log >actual &&
cat >expected <<-EOF &&
diff --git a/sm1 b/sm1
@@ -198,7 +198,7 @@ test_expect_success 'typechanged 
submodule(submodule->blob)' '
 
 rm -rf sm1 &&
 git checkout-index sm1
-test_expect_success 'typechanged submodule(submodule->blob)' '
+test_expect_success 'typechange submodule(submodule->blob)' '
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
Submodule sm1 $head4...000 (submodule deleted)
@@ -226,7 +226,7 @@ test_expect_success 'nonexistent commit' '
 '
 
 commit_file
-test_expect_success 'typechanged submodule(blob->submodule)' '
+test_expect_success 'typechange submodule(blob->submodule)' '
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
diff --git a/sm1 b/sm1
-- 
1.7.8.1.362.g5d6df.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: Python extension commands in git - request for policy change

[Felipe Contreras]

On Tue, Nov 27, 2012 at 8:54 AM, David Aguilar  wrote:
> On Mon, Nov 26, 2012 at 5:11 AM, Felipe Contreras
>  wrote:

>> http://www.mediawiki.org/wiki/Git/Graphical_User_Interfaces
>
> *cough* git-cola *cough*
>
> it runs everywhere.  Yes, windows too. It's written in python.
> It's been actively maintained since 2007.

% sudo pacman -S git-cola
error: target not found: git-cola

http://aur.archlinux.org/packages/gi/git-cola/git-cola.tar.gz
% makepkg

==> Missing Dependencies:
  -> python2-pyqt>=4.3
==> Checking buildtime dependencies...
==> Missing Dependencies:
  -> asciidoc
  -> docbook-xsl
  -> rsync
  -> xmlto
  -> python2-sphinx>=1.1.3

Sorry, no.

I'm not sure if you have been following, but msysgit doesn't seem to
have good support for python, let alone Qt. In my view the fact that
it uses python is not a good thing.

> It's "modern" and has features that don't exist anywhere else.
>
> It even has tests.  It even comes with a building full of willing
> guinea-pigs^Wtesters that let me know right away when
> anything goes wrong.
>
> It uses Qt but that's really the whole point of Qt -> cross-platform.
> (not sure how that wiki page ended up saying Gnome/GTK?)

Yes, Qt is cross-platform *in theory*, but have you used any Qt
application in Windows? I haven't.

> The DAG aka git-dag (in its master branch, about to be released)
> is nicer looking then gitk IMO.  gitk still has some features
> that are better too--there's no silver bullet, but the delta
> is pretty small.

If you mean this one:
http://1.1.1.5/bmi/git-cola.github.com/images/dag.png

Then I wholeheartedly disagree.

> The only point this doesn't fulfill is dependency-free-ness.
> With that requirement the answer can *only* be tcl/tk.
> So saying, "go look for one you won't find it" is really
> a tautology.  It's not even an entertaining one.

That's the whole point; there is nothing else. If there was something
else, there would be something else. But there isn't.

> When the requirement is, "what is the best user experience
> possible", then you use a mature GUI library.  These are different
> requirements and probably different use cases.

But those are not the requirements.

> Anyways, just sayin', you make it sound like this stuff doesn't
> exist, but it does.  I've never proposed it for mainline
> git because I'm very aware of the dependency requirements.

A lot of stuff exists. And people use a lot of those. But they don't
fulfill the requirements that I think gitk does perfectly.

> But, if git "recommended" it I would very much appreciate the
> extra eyes and contributions.  Being in mainline git could
> possibly help with that.  A submodule under contrib/
> would be an interesting experiment.

It might be, if somebody actually tried to submit the code. But I
honestly doubt so.

> In any case, I think documenting the python standards
> (even if within contrib/ only) is a good thing.
>
> We'd be increasing the overall portability by documenting
> what we support and sticking to it, just
> like what is done for shell scripts and perl versions.
> Eric is helping make that happen, let's not  throw
> out the baby with the bathwater.  FWIW, I would also make
> my python expertise available.

Nobody has argued that there shouldn't be guidelines for python code.
What I have objected is to 'strict rules'.

> This thread has gotten into meta-meta territory --
> it's discussing code that has not yet even been written,
> and going off on all sorts of tangents.

That is the point; why should we change the policy for code that
hasn't been written yet? That's not how things evolve in git as far as
I have seen.

> BTW, Felipe, if you're going to be rewriting python code to ruby,
> please, pretty please rewrite that darn GUI ;-)

I would need to write a widget toolkit first =/ I think I'll pass. gitk is fine.

Cheers.

-- 
Felipe Contreras
--
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: gitpacker progress report and a question

[Felipe Contreras]

On Tue, Nov 27, 2012 at 9:36 AM, Eric S. Raymond  wrote:
> Felipe Contreras :
>> Most of those old projects have a linear history,
>
> INTERCAL didn't.  There were two branches for platform ports.

Fine:

tag v0.1 gst-av-0.1.tar "Release 0.1"
tag v0.2 gst-av-0.2.tar "Release 0.2"
checkout port1
tag v0.2-p1 gst-av-0.2-p1.tar "Release 0.2 p1"
checkout port2 v0.2
tag v0.2-p2 gst-av-0.2-p2.tar "Release 0.2 p2"
checkout master
tag v0.3 gst-av-0.3.tar "Release 0.3"

Problem solved.

>> But different commit/author and respective dates, and merges? Sounds
>> like overkill.
>
> I felt it was important that the metadata format be able to specify
> git's entire metadata and DAG semantics.  Otherwise, as sure as the
> sun rises, *somebody* would run into a corner case not covered, and
> (quite rightly) curse me for a shortsighted fool who had done a
> half-assed job.

I'm willing to bet that won't happen.

> I don't do half-assed jobs.  Not ever, no way, nohow.

So you prefer code that is way more complicated that it needs to be,
and with a higher likelihood of introducing bugs? There's a point of
diminishing returns where the code that nobody uses causes bugs for
real use-cases. That's not good.

I prefer code that does one thing, and does it well. And when the need
arises, evolve.

Cheers.

-- 
Felipe Contreras
--
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 0.5/4] t4041 (diff-submodule-option): don't hardcode SHA-1 in expected outputs

[Ramkumar Ramachandra]

Ugh, line wrapping breaks my patch.  I've attached a copy.

Ram


0001-t4041-diff-submodule-option-don-t-hardcode-SHA-1-in-.patch
Description: Binary data

Re: Python extension commands in git - request for policy change

[Sitaram Chamarty]

On Tue, Nov 27, 2012 at 1:24 PM, David Aguilar  wrote:

> *cough* git-cola *cough*
>
> it runs everywhere.  Yes, windows too. It's written in python.
> It's been actively maintained since 2007.
>
> It's "modern" and has features that don't exist anywhere else.
>
> It even has tests.  It even comes with a building full of willing
> guinea-pigs^Wtesters that let me know right away when
> anything goes wrong.
>
> It uses Qt but that's really the whole point of Qt -> cross-platform.
> (not sure how that wiki page ended up saying Gnome/GTK?)
>
> The DAG aka git-dag (in its master branch, about to be released)
> is nicer looking then gitk IMO.  gitk still has some features
> that are better too--there's no silver bullet, but the delta
> is pretty small.

Gitk does a lot of things that people don't realise, since they're not
really documented and you have to scrounge around on the UI.  The
thing is, it's just about the most awesome tool for code archeology I
have seen.

I realise (from looking at the doc page) that git-cola helps you do
all sorts of things, but those are all things I am happier doing at
the command line.

Gitk does precisely those things which *require* a GUI, where the
amount of information presented overwhelms a text interface.  The
display is concisely designed to give you the maximum information at a
minimum space use.  For example, a little black square when a commit
has a note attached.  Even hovering over the arrow-heads, on complex
trees where the line gets broken, does something meaningful.

if I had to pin it down, the feature I use most often is "Show origin
of this line".  Other features I use often are
  - review a commit file by file (f and b keys, also spacebar and 'd')
  - search by SHA1 (4 digits appear to be enough, regardless of how
big your repo is),
  - search for commits changing path/dir (while still showing all the
commits; i.e., this is not 'git-dag -- README.txt' but within gitk you
search up and down for commits touching README.txt
  - and navigating the commit tree looking for stuff

http://sitaramc.github.com/1-basic-usage/gitk.html is my attempt to
document some of the stuff I have found and use.

One final point: the DAG on the right wastes enormous amounts of
space.  Purely subjectively, it is almost jarring on the senses.  (If
you reduce it, it becomes unreadable).

With all due respect, git-cola/dag isn't anywhere near what gitk does,
at least for people who are not afraid of the command line and only
need the GUI to visualise a truly complex tree.
--
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: Python extension commands in git - request for policy change

[David Aguilar]

On Tue, Nov 27, 2012 at 1:17 AM, Sitaram Chamarty  wrote:
> On Tue, Nov 27, 2012 at 1:24 PM, David Aguilar  wrote:
>
>> *cough* git-cola *cough*
>>
>> it runs everywhere.  Yes, windows too. It's written in python.
>> It's been actively maintained since 2007.
>>
>> It's "modern" and has features that don't exist anywhere else.
>>
>> It even has tests.  It even comes with a building full of willing
>> guinea-pigs^Wtesters that let me know right away when
>> anything goes wrong.
>>
>> It uses Qt but that's really the whole point of Qt -> cross-platform.
>> (not sure how that wiki page ended up saying Gnome/GTK?)
>>
>> The DAG aka git-dag (in its master branch, about to be released)
>> is nicer looking then gitk IMO.  gitk still has some features
>> that are better too--there's no silver bullet, but the delta
>> is pretty small.
>
> Gitk does a lot of things that people don't realise, since they're not
> really documented and you have to scrounge around on the UI.  The
> thing is, it's just about the most awesome tool for code archeology I
> have seen.
>
> I realise (from looking at the doc page) that git-cola helps you do
> all sorts of things, but those are all things I am happier doing at
> the command line.

Ditto.  There's actually a few small things I use it for,
mainly for teasing apart commits.  These days you can use git-gui
for that, but in the old days it was the only way to interactively
select individual lines and stage/unstage/revert them, etc.
I don't think we can line-by-line revert in git-gui yet, though.

Some other small things that I use: ctrl-g, type something
for grep, hit enter twice and I'm in my editor on that
(or any other selected) line.  'spacebar' does xdg-open,
and 'enter' launches the editor in the status widget;
small things.  I, too, do most stuff on the command line.

The grep thing is a good example.  You have tons of output,
you see the one line that you care about, and you want to jump
there.  Clicking on that line and hitting enter is the minimal
effort to do that.  You don't have to click because we also
have keyboard navigation.  I have a feeling that there's probably
something I'm missing, though.. another way of working (emacs?)
that would render all of this custom GUI stuff pointless.

What I learned about users:

The commit editor is the #1 thing that got my coworkers finally
writing better commit messages. It forces the subject/description
separation and shows yellow, red when the subject gets too long.
It also auto-wraps.  IMO it makes sense for git-gui to do
the same these days.

> Gitk does precisely those things which *require* a GUI, where the
> amount of information presented overwhelms a text interface.  The
> display is concisely designed to give you the maximum information at a
> minimum space use.  For example, a little black square when a commit
> has a note attached.  Even hovering over the arrow-heads, on complex
> trees where the line gets broken, does something meaningful.
>
> if I had to pin it down, the feature I use most often is "Show origin
> of this line".  Other features I use often are
>   - review a commit file by file (f and b keys, also spacebar and 'd')
>   - search by SHA1 (4 digits appear to be enough, regardless of how
> big your repo is),
>   - search for commits changing path/dir (while still showing all the
> commits; i.e., this is not 'git-dag -- README.txt' but within gitk you
> search up and down for commits touching README.txt
>   - and navigating the commit tree looking for stuff
>
> http://sitaramc.github.com/1-basic-usage/gitk.html is my attempt to
> document some of the stuff I have found and use.

Wow, this is awesome.

> One final point: the DAG on the right wastes enormous amounts of
> space.  Purely subjectively, it is almost jarring on the senses.  (If
> you reduce it, it becomes unreadable).
>
> With all due respect, git-cola/dag isn't anywhere near what gitk does,
> at least for people who are not afraid of the command line and only
> need the GUI to visualise a truly complex tree.

This is really great feedback.
cc:ing Guillaume since he had similar ideas.

thx,
-- 
David
--
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 5/5] git-send-email: allow edit invalid email address

[Krzysztof Mazur]

On Mon, Nov 26, 2012 at 03:50:30PM -0800, Junio C Hamano wrote:
> Krzysztof Mazur  writes:
> 
> > On Mon, Nov 26, 2012 at 02:58:58PM -0800, Junio C Hamano wrote:
> >> Krzysztof Mazur  writes:
> >> 
> >> >> Not having this new code inside "elsif (/^e/) { }" feels somewhat
> >> >> sloppy, even though it is not *too* bad.  Also do we know this
> >> >
> >> > ok, I will fix that.
> >> >
> >> >> function will never be used for addresses other than recipients' (I
> >> >> gave a cursory look to see what is done to the $sender and it does
> >> >> not seem to go through this function, tho)?
> >> >
> >> > Yes, this function is called only from validate_address_just()
> >> > to filter @initial_to, @initial_cc, @bcc_list as early as possible,
> >> > and filter @to and @cc added in each email.
> >> 
> >> Thanks; when merged to 'pu', this series seems to break t9001.  I'll
> >> push the result out with breakages but could you take a look?
> >> 
> >
> > Sorry, I tested final version only on an ancient perl 5.8.8 and it really
> > worked there. The third patch is broken:
> >
> > diff --git a/git-send-email.perl b/git-send-email.perl
> > index 9996735..f3bbc16 100755
> > --- a/git-send-email.perl
> > +++ b/git-send-email.perl
> > @@ -1472,7 +1472,7 @@ sub unique_email_list {
> > my @emails;
> >  
> > foreach my $entry (@_) {
> > -   my $clean = extract_valid_address_or_die($entry))
> > +   my $clean = extract_valid_address_or_die($entry);
> 
> Ah, ok, I wasn't looking closely enough.  Thanks for a quick
> turnaround.  Will requeue and push out.

I rechecked that and I've just sent some older broken version. The
patch that I've sent had date Date: Thu, 22 Nov 2012 19:00:25 +0100,
but on my tree I have commit from Date: Thu Nov 22 19:01:55 2012 +0100,
which is exactly the same as the fixed version in your tree.

Thanks,

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

Antw: Re: diff support for the Eiffel language?

[Ulrich Windl]

Hi!

I managed to have some success, although it's not perfect. Unfortunately the
Eiffel grammar does not allow a 100% solution. Example:

---
local
  x : BOOLEAN
---
declares a local variable named `x', while

---
  x : BOOLEAN
   do ... end
---

Declares a function named `x'. Formal generic parameters like `x :
ARRAY[ARRAY[STRING]]' make things more complicate. Anyway, here's my solution
(probably incomplete):
---
% git config --local -e
[diff "Eiffel"]
xfuncname =
"!^[[:space:]]*(check|class|[Cc]reate|else|elseif|end|ensure|do|!|feature|from|indexing|inherit|is|local|loop|note|require|then|until)[[:space:]]*\n\
^[[:space:]]*(class[[:space:]]*[[:alpha:]_][[:alnum:]_]*)\n\
^[[:space:]]*([[:alpha:]_][[:alnum:]_]*[[:space:]]*\\([^(\")]+:[^(\")]+\\)[[:space:]]*:[[:space:]*[[:alpha:]_][[:alnum:]_]*[[:space:]]*[^[:space:]\"]?[^\"=]*)[[:space:]]*$\n\

^[[:space:]]*([[:alpha:]_][[:alnum:]_]*[[:space:]]*\\([^(\")]+:[^(\")]+\\))[[:space:]]*$\n\

^[[:space:]]*([[:alpha:]_][[:alnum:]_]*[[:space:]]*:[[:space:]*[[:alpha:]_][[:alnum:]_]*[[:space:]]*[^[:space:]\"]?[^\"=]*)[[:space:]]*$\n\
^[[:space:]]*([[:alpha:]_][[:alnum:]_]*)[[:space:]]*$"
% cat .git/info/attributes
*.e diff=Eiffel
---

Regards,
Ulrich

>>> Johannes Sixt  schrieb am 22.10.2012 um 15:35 in
Nachricht <50854b90.50...@viscovery.net>:
> Am 10/22/2012 15:06, schrieb Ævar Arnfjörð Bjarmason:
> > On Mon, Oct 22, 2012 at 1:58 PM, Ulrich Windl 
> >  wrote:
> >> However there's one little thing I noticed with "git diff": The
> >> conte4xt lines (staring with "@@") show the current function (in Perl
> >> and C), but they show the current "feature clause" in Eiffel (as
> >> opposed to the expected current feature). I wonder how hard it is to
> >> fix it (Observed in git 1.7.7 of openSUSE 12.1).
> > 
> > See git.git's e90d065 for an example of adding a new diff pattern.
> 
> It's not necessary to wait until there is built-in support for a new 
> language.
> 
> For example, for Windows resource files, I have
> 
> *.rcdiff=winres
> 
> in .gitattributes or .git/info/attributes and
> 
> [diff "winres"]
> xfuncname =
>
"!^(BEGIN|END|FONT|CAPTION|STYLE)\n^[a-zA-Z_][a-zA-Z_0-9]*.*\n^[[:space:]]*(
> [[:alnum:]_]+,
> *DIALOG.*)"
> 
> in .git/config (the xfuncname is all on a single line). The first part
> beginning at ! up to \n tells to ignore the specified matches. The other
> parts separated by \n tell the things to put in the hunk header. You can
> have "ignore" parts (with exlamation mark) and "take this" parts (without)
> in any order that is convenient, as long as the last one is "take this".
> 
> -- 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: [RFC/PATCH] l10n: de.po: translate 825 new messages

[Thomas Rast]

>  #: builtin/pack-refs.c:6
>  msgid "git pack-refs [options]"
> -msgstr ""
> +msgstr "git pack-refs [Optionen]"
>  
>  #: builtin/pack-refs.c:14
>  msgid "pack everything"
> -msgstr ""
> +msgstr "packt alles"
>  
>  #: builtin/pack-refs.c:15
>  msgid "prune loose refs (default)"
> -msgstr ""
> +msgstr "entfernt lose Referenzen (Standard)"
>  
>  #: builtin/prune-packed.c:7
>  msgid "git prune-packed [-n|--dry-run] [-q|--quiet]"
> -msgstr ""
> +msgstr "git prune-packed [-n|--dry-run] [-q|--quite]"
>  
>  #: builtin/prune.c:12
>  msgid "git prune [-n] [-v] [--expire ] [--] [...]"
> -msgstr ""
> +msgstr "git prune [-n] [-v] [--expire ] [--] [...]"
>  
>  #: builtin/prune.c:132
> -#, fuzzy
>  msgid "do not remove, show only"
> -msgstr "Würde nicht entfernen %s\n"
> +msgstr "nicht entfernen, nur anzeigen"
>  
>  #: builtin/prune.c:133
> -#, fuzzy
>  msgid "report pruned objects"
> -msgstr "kann Objekt %s nicht lesen"
> +msgstr "meldet entfernte Objekte"
>  
>  #: builtin/prune.c:136
>  msgid "expire objects older than "
> -msgstr ""
> +msgstr "lässt Objekte älter als  verfallen"
>  
>  #: builtin/push.c:14
> -#, fuzzy
>  msgid "git push [] [ [...]]"
> -msgstr "git apply [Optionen] [...]"
> +msgstr "git push [] [ [...]]"
>  
>  #: builtin/push.c:45
>  msgid "tag shorthand without "
> @@ -7141,55 +7098,53 @@ msgid "--all and --mirror are incompatible"
>  msgstr "--all und --mirror sind inkompatibel"
>  
>  #: builtin/push.c:382
> -#, fuzzy
>  msgid "repository"
> -msgstr "ungültiges Projektarchiv '%s'"
> +msgstr "Projektarchiv"
>  
>  #: builtin/push.c:383
>  msgid "push all refs"
> -msgstr ""
> +msgstr "versendet alle Referenzen"
>  
>  #: builtin/push.c:384
>  msgid "mirror all refs"
> -msgstr ""
> +msgstr "spiegelt alle Referenzen"
>  
>  #: builtin/push.c:386
> -#, fuzzy
>  msgid "delete refs"
> -msgstr "gelöscht"
> +msgstr "löscht Referenzen"
>  
>  #: builtin/push.c:387
>  msgid "push tags (can't be used with --all or --mirror)"
>  msgstr ""
> +"versendet Markierungen (kann nicht mit --all oder --mirror benutzt werden)"
>  
>  #: builtin/push.c:390
> -#, fuzzy
>  msgid "force updates"
> -msgstr "Aktualisierung erzwungen"
> +msgstr "erzwingt Aktualisierung"
>  
>  #: builtin/push.c:391
>  msgid "check"
> -msgstr ""
> +msgstr "Überprüfung"
>  
>  #: builtin/push.c:392
>  msgid "control recursive pushing of submodules"
> -msgstr ""
> +msgstr "steuert rekursives Versenden von Unterprojekten"
>  
>  #: builtin/push.c:394
>  msgid "use thin pack"
> -msgstr ""
> +msgstr "benutzt kleinere Pakete"
>  
>  #: builtin/push.c:395 builtin/push.c:396
>  msgid "receive pack program"
> -msgstr ""
> +msgstr "Programm zum Empfangen von Paketen"
>  
>  #: builtin/push.c:397
>  msgid "set upstream for git pull/status"
> -msgstr ""
> +msgstr "setzt externes Projektarchiv für \"git pull/status\""
>  
>  #: builtin/push.c:400
>  msgid "prune locally removed refs"
> -msgstr ""
> +msgstr "entfernt lokal gelöschte Referenzen"
>  
>  #: builtin/push.c:410
>  msgid "--delete is incompatible with --all, --mirror and --tags"
> @@ -7205,155 +7160,160 @@ msgid ""
>  "[-u [--exclude-per-directory=] | -i]] [--no-sparse-checkout] [--"
>  "index-output=] (--empty |  [ []])"
>  msgstr ""
> +"git read-tree [[-m [--trivial] [--aggressive] | --reset | 
> --prefix=] "
> +"[-u [--exclude-per-directory=] | -i]] [--no-sparse-checkout] [--"
> +"index-output=] (--empty |  [ "
> +"[]])"
>  
>  #: builtin/read-tree.c:108
> -#, fuzzy
>  msgid "write resulting index to "
> -msgstr "beschädigte Bereitstellungsdatei"
> +msgstr "schreibt resultierende Bereitstellung nach "
>  
>  #: builtin/read-tree.c:111
> -#, fuzzy
>  msgid "only empty the index"
> -msgstr "Konnte die Bereitstellung nicht lesen"
> +msgstr "leert nur die Bereitstellung"
>  
>  #: builtin/read-tree.c:113
> -#, fuzzy
>  msgid "Merging"
> -msgstr "Zusammenführung:"
> +msgstr "Zusammenführung"
>  
>  #: builtin/read-tree.c:115
>  msgid "perform a merge in addition to a read"
> -msgstr ""
> +msgstr "führt eine Zusammenführung zusätzlich zum Lesen aus"
>  
>  #: builtin/read-tree.c:117
>  msgid "3-way merge if no file level merging required"
>  msgstr ""
> +"3-Wege-Zusammenführung, wenn keine Zusammenführung auf Dateiebene "
> +"erforderlich ist"
>  
>  #: builtin/read-tree.c:119
>  msgid "3-way merge in presence of adds and removes"
>  msgstr ""
> +"3-Wege-Zusammenführung bei Vorhandensein von hinzugefügten/entfernten 
> Zeilen"
>  
>  #: builtin/read-tree.c:121
>  msgid "same as -m, but discard unmerged entries"
> -msgstr ""
> +msgstr "genau wie -m, verwirft aber nicht zusammengeführte Einträge"
>  
>  #: builtin/read-tree.c:122
> -#, fuzzy
>  msgid "/"
> -msgstr "Verzeichnis/Datei"
> +msgstr "/"
>  
>  #: builtin/read-tree.c:123
>  msgid "read the tree into the index under /"
> -msgstr ""
> +msgstr "liest den Baum in die Bereitstellung unter /"
>  
>  #: builtin/read-tree.c:126
>  msgid "update working tree with merge result"
> -msgstr ""
> +msgstr "aktualisiert Arbeitsbaum mit Ergebnis der Zu

Re: [PATCH] Third try at documenting command integration requirements.

[Michael Haggerty]

On 11/26/2012 10:41 PM, Eric S. Raymond wrote:
> The next things on my git to-do list are 
> [...]
> 2. Submit a doc patch containing guidelines that (a) Python scripts should
>check for their floor version and error out gracefully if they won't
>run with the host's interpreter, and (b) Python scripts sbould be
>2.6-compatible.

OK, now let's discuss *which* minimum Python version that git should
support in the hypothetical new world...

Data point: Mercurial supports Python 2.4 - 2.7 with the following
explanation [1]:

We will continue to support Python 2.4 as long as it doesn't
present a significant barrier to development. Given that Python 2.5
and later don't contain any features that we're dying to use, that
may be a long time off. [...]

We also will continue to support Python 2.x as long as there is a
significant installed base in the form of Red Hat Enterprise Linux
and Ubuntu LTS users. RHEL 5, which uses Python 2.4, will reach the
end of the "production 2" portion of its lifecycle in Q1 2014 and
the end of its regular lifecycle in 2017.

It would be a shame to leave RHEL 5 users behind if Python is used to
implement important git functionality.  Python 2.4 is missing some of
Python's shiny new features, but still quite OK.  What features would
you miss the most if we were to target Python 2.4 instead of 2.6?

Michael

[1] http://mercurial.selenic.com/wiki/SupportedPythonVersions

-- 
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH] l10n: de.po: translate 825 new messages

[Thomas Rast]

Hi Ralf,

This is the middle third of my review.  Sorry for the long wait!  I hope
it can still be useful.

Also, sorry for the other mail that I just sent out seconds ago.  That
was what I wanted to save as "to be done in the last third", but
I accidentally hit the wrong key and sent it out.

- Thomas


> @@ -4459,6 +4423,8 @@ msgstr ""
>  #: builtin/fmt-merge-msg.c:13
>  msgid "git fmt-merge-msg [-m ] [--log[=]|--no-log] [--file 
> ]"
>  msgstr ""
> +"git fmt-merge-msg [-m ] [--log[=]|--no-log] [--file "
> +"]"
>  
>  #: builtin/fmt-merge-msg.c:653 builtin/fmt-merge-msg.c:656 builtin/grep.c:786
>  #: builtin/merge.c:188 builtin/show-branch.c:656 builtin/show-ref.c:192
> @@ -4468,115 +4434,111 @@ msgstr "Anzahl"
>  
>  #: builtin/fmt-merge-msg.c:654
>  msgid "populate log with at most  entries from shortlog"
> -msgstr ""
> +msgstr "fügt Historie mit höchstens  Einträgen von \"shortlog\" 
> hinzu"

I don't really share your apparent aversion to just using "" :-)

>  #: builtin/for-each-ref.c:994
>  msgid "quote placeholders suitably for shells"
> -msgstr ""
> +msgstr "quotiert Platzhalter geeignet für Shells"
[...]
>  #: builtin/for-each-ref.c:996
>  msgid "quote placeholders suitably for perl"
> +msgstr "quotiert Platzhalter geeignet für Perl"
[etc]

"quote" is a hard one, and "quotiert" sounds very wrong to me.  How
about weaseling out along the lines of

  Formatiert Platzhalter als {Shell|Perl|Python|TCL} Zeichenfolge

or even "Shell-String".

>  #: builtin/for-each-ref.c:1003
>  msgid "show only  matched refs"
> -msgstr ""
> +msgstr "zeigt nur  passende Referenzen"

This should be  if you insist on translating the 'n'.

>  #: builtin/for-each-ref.c:1006
>  msgid "field name to sort on"
> -msgstr ""
> +msgstr "Name des Felder zum Sortieren"

Feld_s_?

Or just "sortiere nach diesem Feld".

>  #: builtin/fsck.c:618
>  msgid "make index objects head nodes"
> -msgstr ""
> +msgstr "erzeugt Kopfknoten der Bereitstellungsobjekte"

The English version is equally obscure, but this refers to (also)
walking the objects listed in the index.  Furthermore, --cache is
actually the default if you don't list any objects to walk.

>  #: builtin/fsck.c:620
>  msgid "also consider packs and alternate objects"
> -msgstr ""
> +msgstr "betrachtet auch Pakete und wechselnde Objekte"

The glossary tells me pack -> Archiv.

An alternate object [store] is essentially a pointer to the object store
of another repository.  It may best be left untranslated, as it's a
pretty advanced feature.

>  #: builtin/grep.c:741
>  msgid "match patterns only at word boundaries"
> -msgstr ""
> +msgstr "findet Muster nur innerhalb von Wörtern"

The translation gets the purpose wrong: the option forces a
word-boundary match on either side of the pattern, so that you will find
only one or more words matching the pattern.  The manpage has a precise
definition:

Match the pattern only at word boundary (either begin at the
beginning of a line, or preceded by a non-word character; end at
the end of a line or followed by a non-word character).

Maybe "suche nur ganze Wörter" would suffice as a concise description.

>  #: builtin/grep.c:817
>  msgid "indicate hit with exit status without output"
> -msgstr ""
> +msgstr "kennzeichnet Übereinstimmungen mit Beendigungsstatus, ohne Ausgabe"

The "indicate" should be "zeigen" or some such, since it only tells
whether there were any matches at all.

I spent some time looking for a better translation of "exit status", but
couldn't find anything helpful (such as a German translation of diff(1)
or a Wikipedia page on "exit status").

>  #: builtin/hash-object.c:77
>  msgid "process file as it were from this path"
> -msgstr ""
> +msgstr "verarbeitet Datei, wie es von diesem Pfad wäre"

als ob sie von diesem Pfad wäre?

>  #: builtin/help.c:47
>  msgid "show info page"
> -msgstr ""
> +msgstr "zeigt Informationsseite"

info here refers to GNU info, presumably it should be left as
"info-Seite" or some such.

>  #: builtin/index-pack.c:1106
>  msgid "confusion beyond insanity"
> @@ -5150,12 +5111,12 @@ msgstr "Fehler beim Auflösen der Unterschiede"
>  #: builtin/index-pack.c:1112
>  #, c-format
>  msgid "completed with %d local objects"
> -msgstr ""
> +msgstr "fertiggestellt mit %d lokalen Objekten"

*vervollständigt* mit %d lokalen Objekten

>  #: builtin/log.c:102
>  msgid "decorate options"
> -msgstr ""
> +msgstr "Ausgabeoptionen"

'decorate' is the option to mark commits by the refs pointing at them,
and should probably not be translated.

The English version is quite tautological though, since it just turns
into

--decorate[=...]  decorate options

>  #: builtin/log.c:1091
>  msgid "don't include a patch matching a commit upstream"
>  msgstr ""
> +"schließt keine Patches ein, die einer Version im externen Projektarchiv "
> +"entsprechen"

Upstream refers to the notional upstream state, which does not even have
to be a branch here.  I.e., if you say

  git format-patch --ignore-if-in

Re: Python extension commands in git - request for policy change

[Magnus Bäck]

On Sunday, November 25, 2012 at 06:40 EST,
 Felipe Contreras  wrote:

> On Sun, Nov 25, 2012 at 11:44 AM, Michael Haggerty
>  wrote:

[...]

> > On the contrary, there is *constant* traffic on the mailing list
> > about incompatibilities between different shell implementations (sh,
> > dash, bash, etc), not to mention those in other utilities (sed,
> > grep, etc) that one is forced to work with in shell scripts.
> > Compatibility is a *huge* pain when developing shell code for git.
> > The fact that users typically don't encounter such problems is due
> > to the hard work of POSIX lawyers on the mailing list correcting the
> > compatibility errors of mortal programmers.
>
> *Theoretical* incompatibilities on probably obscure systems. *I* have
> never seen such compatibility issues *in practice*.

While "constant traffic" probably overstates the issue, these are not
theoretical problems. I recall at least three cases in the last year
or so where Git has seen breakage with Solaris or Mac OS X because
of sed or tr incompatibilities, and I don't even read this list that
thoroughly.

[...]

-- 
Magnus Bäck
ba...@google.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: [msysGit] Re: Python extension commands in git - request for policy change

[Johannes Schindelin]

Hi David,

On Mon, 26 Nov 2012, David Aguilar wrote:

> *cough* git-cola *cough*

If you had a couple of free cycles to help us get Python/Qt compiled in
msysGit, I will be happy to make a Git for Windows package including
git-cola.

Ciao,
Dscho
--
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] Extend runtime prefix computation

[Michael Weiser]

Support determining the binaries' installation path at runtime even if
called without any path components (i.e. via search path). Implement
fallback to compiled-in prefix if determination fails or is impossible.

Signed-off-by: Michael Weiser 
---
- Has two very minor memory leaks - function is called only once per
  program execution. Do we care? Alternative: Use static buffer instead.

 exec_cmd.c |   68 ++-
 1 files changed, 53 insertions(+), 15 deletions(-)

diff --git a/exec_cmd.c b/exec_cmd.c
index 125fa6f..d50d7f8 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -4,28 +4,22 @@
 #define MAX_ARGS   32
 
 static const char *argv_exec_path;
-static const char *argv0_path;
+static const char *argv0_path = NULL;
 
 const char *system_path(const char *path)
 {
-#ifdef RUNTIME_PREFIX
-   static const char *prefix;
-#else
static const char *prefix = PREFIX;
-#endif
struct strbuf d = STRBUF_INIT;
 
if (is_absolute_path(path))
return path;
 
 #ifdef RUNTIME_PREFIX
-   assert(argv0_path);
-   assert(is_absolute_path(argv0_path));
-
-   if (!prefix &&
-   !(prefix = strip_path_suffix(argv0_path, GIT_EXEC_PATH)) &&
-   !(prefix = strip_path_suffix(argv0_path, BINDIR)) &&
-   !(prefix = strip_path_suffix(argv0_path, "git"))) {
+   if (!argv0_path ||
+   !is_absolute_path(argv0_path) ||
+   (!(prefix = strip_path_suffix(argv0_path, GIT_EXEC_PATH)) &&
+!(prefix = strip_path_suffix(argv0_path, BINDIR)) &&
+!(prefix = strip_path_suffix(argv0_path, "git" {
prefix = PREFIX;
trace_printf("RUNTIME_PREFIX requested, "
"but prefix computation failed.  "
@@ -41,20 +35,64 @@ const char *system_path(const char *path)
 const char *git_extract_argv0_path(const char *argv0)
 {
const char *slash;
+   char *abs_argv0 = NULL;
 
if (!argv0 || !*argv0)
return NULL;
slash = argv0 + strlen(argv0);
 
+   /* walk to the first slash from the end */
while (argv0 <= slash && !is_dir_sep(*slash))
slash--;
 
+   /* if there was a slash ... */
if (slash >= argv0) {
-   argv0_path = xstrndup(argv0, slash - argv0);
-   return slash + 1;
+   /* ... it's either an absolute path */
+   if (is_absolute_path(argv0)) {
+   /* FIXME: memory leak here */
+   argv0_path = xstrndup(argv0, slash - argv0);
+   return slash + 1;
+   }
+
+   /* ... or a relative path, in which case we have to make it
+* absolute first and do the whole thing again */
+   abs_argv0 = xstrdup(real_path(argv0));
+   } else {
+   /* argv0 is no path at all, just a name. Resolve it into a
+* path. Unfortunately, this gets system specific. */
+#if defined(__linux__)
+   struct stat st;
+   if (!stat("/proc/self/exe", &st)) {
+   abs_argv0 = xstrdup(real_path("/proc/self/exe"));
+   }
+#elif defined(__APPLE__)
+   /* Mac OS X has realpath, which incidentally allocates its own
+* memory, which in turn is why we do all the xstrdup's in the
+* other cases. */
+   abs_argv0 = realpath(argv0, NULL);
+#endif
+
+   /* if abs_argv0 is still NULL here, something failed above or
+* we are on an unsupported system. system_path() will warn
+* and fall back to the static prefix */
+   if (!abs_argv0) {
+   argv0_path = NULL;
+   return argv0;
+   }
}
 
-   return argv0;
+   /* abs_argv0 is an absolute path now for which memory was allocated
+* with malloc */
+
+   slash = abs_argv0 + strlen(abs_argv0);
+   while (abs_argv0 <= slash && !is_dir_sep(*slash))
+   slash--;
+
+   /* FIXME: memory leaks here */
+   argv0_path = xstrndup(abs_argv0, slash - abs_argv0);
+   slash = xstrdup(slash + 1);
+   free(abs_argv0);
+   return slash;
 }
 
 void git_set_argv_exec_path(const char *exec_path)
-- 
1.7.3.4
-- 
Vorstandsvorsitzender/Chairman of the board of management:
Gerd-Lothar Leonhart
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Michael Heinrichs, 
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Philippe Miltin
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196

--
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 v6 p2 3/9] transport-helper: trivial code shuffle

[Junio C Hamano]

Felipe Contreras  writes:

> Just shuffle the die() part to make it more explicit, and cleanup the
> code-style.
>
> Signed-off-by: Felipe Contreras 
> ---
>  transport-helper.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/transport-helper.c b/transport-helper.c
> index 32ad877..0c95101 100644
> --- a/transport-helper.c
> +++ b/transport-helper.c
> @@ -775,6 +775,9 @@ static int push_refs_with_export(struct transport 
> *transport,
>   char *private;
>   unsigned char sha1[20];
>  
> + if (ref->deletion)
> + die("remote-helpers do not support ref deletion");
> +
>   if (!data->refspecs)
>   continue;

This is not just "just shuffle the die to make it explicit" but it
does change the semantics; earlier ref->deletion was perfectly fine
as long as data->refspecs is not given, but the new code always
dies.

If this semantic change is a good thing, please explain why it is so
in the log message.  If the change is "it does not matter because
when data->refspecs is not given and ref->deletion is set, we die
later elsewhere in the code anyway", then it needs to be described.


Thanks.

> @@ -784,10 +787,6 @@ static int push_refs_with_export(struct transport 
> *transport,
>   }
>   free(private);
>  
> - if (ref->deletion) {
> - die("remote-helpers do not support ref deletion");
> - }
> -
>   if (ref->peer_ref)
>   string_list_append(&revlist_args, ref->peer_ref->name);
--
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: improve phrasing in git-push.txt

[Junio C Hamano]

Sounds better; 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 7/7] push: clarify rejection of update to non-commit-ish

[Junio C Hamano]

Chris Rorvick  writes:

>> With this code, the old must be a commit but new can be a tag that
>> points at a commit?  Why?
>
> The old must not be a tag because fast-forwarding from it is
> potentially destructive; a tag would likely be left dangling in this
> case.  This is not true for the new, though.   I'm not sure
> fast-forwarding from a commit to a tag is useful, but I didn't see a
> reason to prevent it either.   The refs/tags/ hierarchy is excluded
> from fast-forwarding before this check, and refs/heads/ is already
> protected against anything but commits.  So it seems very unlikely
> that someone would accidentally make use of this behavior.
>
> So, fast-forwarding to a tag seemed fairly benign and unlikely to
> cause confusion, so I leaned towards allowing it in case someone found
> a use case for it.

Sounds sensible.

Perhaps some of that thinking behind this change (i.e. earlier
we checked the forwardee was any commit-ish, but the new code only
allows a commit object if it were to be fast-forwarded) belongs to
the log message?

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 5/7] push: require force for refs under refs/tags/

[Junio C Hamano]

Chris Rorvick  writes:

> On Mon, Nov 26, 2012 at 12:57 PM, Junio C Hamano  wrote:
>> Chris Rorvick  writes:
>>
>>> diff --git a/remote.c b/remote.c
>>> index 4a6f822..012b52f 100644
>>> --- a/remote.c
>>> +++ b/remote.c
>>> @@ -1315,14 +1315,18 @@ void set_ref_status_for_push(struct ref 
>>> *remote_refs, int send_mirror,
>>>*
>>>* (1) if the old thing does not exist, it is OK.
>>>*
>>> -  * (2) if you do not have the old thing, you are not allowed
>>> +  * (2) if the destination is under refs/tags/ you are
>>> +  * not allowed to overwrite it; tags are expected
>>> +  * to be static once created
>>> +  *
>>> +  * (3) if you do not have the old thing, you are not allowed
>>>* to overwrite it; you would not know what you are losing
>>>* otherwise.
>>>*
>>> -  * (3) if both new and old are commit-ish, and new is a
>>> +  * (4) if both new and old are commit-ish, and new is a
>>>* descendant of old, it is OK.
>>>*
>>> -  * (4) regardless of all of the above, removing :B is
>>> +  * (5) regardless of all of the above, removing :B is
>>>* always allowed.
>>>*/
>>
>> We may want to reword (0) to make it clear that --force
>> (and +A:B) can be used to defeat all the other rules.
>
> On that note, having (5) be "regardless of all of the above ..." seems
> a little awkward.  That would seem to fit better towards the top.

Sure.  (0) you can always force; (1) you can always delete; and then
other requirements.  That may indeed read better.

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] Support for git aliasing for tcsh completion

[Junio C Hamano]

The patch was linewrapped so I had to fix it up; please double check
what will be queued on 'pu' to make sure that I did not miss
necessary whitespaces or added unnecessary ones when I rejoined long
lines.

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: Interesting git-format-patch bug

[Junio C Hamano]

per...@pluto.rain.com (Perry Hutchison) writes:

> Junio C Hamano  wrote:
>> "Olsen, Alan R"  writes:
>> > I found an interesting bug in git-format-patch.
>> >
>> > Say you have a branch A.  You create branch B and add a patch to
>> > it. You then merge that patch into branch A. After the merge,
>> > some other process (we will call it 'gerrit') uses annotate and
>> > changes the comment on the patch that exists on branch B.
>> >
>> > Now someone runs git-format-patch for the last n patches on
>> > branch A.  You should just get the original patch that was
>> > merged over to branch A.  What you get is the patch that was
>> > merged to branch A *and* the patch with the modified commit
>> > comment on branch B. (Double the patches, double the
>> > clean-up...)
>>
>> As you literally have patches that do essentially the same or
>> similar things on two branches that was merged, you cannot
>> expect to export each individual commit into a patch and not
>> have conflicts among them.  So I do not think there is no
>> answer than "don't do that".
>
> To me, this seems to miss Alan's point:  only one patch was merged
> to branch A,...

Are you sure about this part?

I thought Alan's description was that he originally had this

x-A
 \ \
  B-M (a)

and then "some other process" made it like so:

x-A
|\ \
| B-M
 \   \
  B'--M' (a)

and then you ask to linealize the last n patches starting from the
rewritten M'.

If that "some other process" instead created a history like this:

x-A---\
|\ \   \ 
| B-M   \
 \   \
  B'--M' (a)

then the redone-merge M' will not see the old B that was fixed later
to B' in the history, but then format-patch would not show B so we
wouldn't be having this discussion thread.

It is possible that "some other process" may (ab)use the parent
field to record the evolution of B, to create a topology like this:

x-A---\
|\ \   \
| B-M   \
 \ \ \
  \-B'M' (a)

in which case M' has parent B' but B' has a (phoney) parent B.

So again, it all depends on what "some other process" does to the
history when it rewrites it, and if somebody wants to fiter cruft in
the resulting history when flattening it, the knowledge of what
"some other process" does need to help that process.

Which is what I already said, I guess ;-)

> so git-format-patch applied to branch A should find
> only one patch.  It can be argued either way whether that one-patch
> report should include the gerrit annotations, but surely the
> application of gerrit on branch B, _after the merge to branch A
> has already been performed_, should not cause an additional patch
> to magically appear on branch A.
--
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 1/4] t4041 (diff-submodule-option): parse digests sensibly

[Junio C Hamano]

Ramkumar Ramachandra  writes:

> `git rev-list --max-count=1 HEAD` is a roundabout way of saying `git
> rev-parse --verify HEAD`; replace a bunch of instances of the former
> with the latter.  Also, don't unnecessarily `cut -c1-7` the rev-parse
> output when the `--short` option is available.
>
> Signed-off-by: Ramkumar Ramachandra 
> ---
>  t/t4041-diff-submodule-option.sh |   14 +++---
>  1 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/t/t4041-diff-submodule-option.sh 
> b/t/t4041-diff-submodule-option.sh
> index 5377639..cfb71e5 100755
> --- a/t/t4041-diff-submodule-option.sh
> +++ b/t/t4041-diff-submodule-option.sh
> @@ -21,7 +21,7 @@ add_file () {
>   test_tick &&
>   git commit -m "Add $name"
>   done >/dev/null
> - git rev-parse --verify HEAD | cut -c1-7
> + git rev-parse --short --verify HEAD
>   cd "$owd"
>  }
>  commit_file () {
> @@ -33,7 +33,7 @@ test_create_repo sm1 &&
>  add_file . foo >/dev/null
>  
>  head1=$(add_file sm1 foo1 foo2)
> -fullhead1=$(cd sm1; git rev-list --max-count=1 $head1)
> +fullhead1=$(cd sm1; git rev-parse --verify $head1)

That still is a roundabout way to say "git rev-parse --verify HEAD",
no?  Why feed a shortened one to get the expanded result when you
know the full representation of HEAD is what you want?

>  test_expect_success 'added submodule' "
>   git add sm1 &&
> @@ -116,8 +116,8 @@ EOF
>   test_cmp expected actual
>  "
>  
> -fullhead2=$(cd sm1; git rev-list --max-count=1 $head2)
>  test_expect_success 'modified submodule(forward) --submodule=short' "
> +fullhead2=$(cd sm1; git rev-parse --verify $head2)
>   git diff --submodule=short >actual &&
>   cat >expected <<-EOF &&
>  diff --git a/sm1 b/sm1
> @@ -135,7 +135,7 @@ commit_file sm1 &&
>  head3=$(
>   cd sm1 &&
>   git reset --hard HEAD~2 >/dev/null &&
> - git rev-parse --verify HEAD | cut -c1-7
> + git rev-parse --short --verify HEAD
>  )
>  
>  test_expect_success 'modified submodule(backward)' "
> @@ -220,8 +220,8 @@ EOF
>  rm -f sm1 &&
>  test_create_repo sm1 &&
>  head6=$(add_file sm1 foo6 foo7)
> -fullhead6=$(cd sm1; git rev-list --max-count=1 $head6)
>  test_expect_success 'nonexistent commit' "
> +fullhead6=$(cd sm1; git rev-parse --verify $head6)
>   git diff-index -p --submodule=log HEAD >actual &&
>   cat >expected <<-EOF &&
>  Submodule sm1 $head4...$head6 (commits not present)
> @@ -318,8 +318,8 @@ EOF
>  "
>  
>  (cd sm1; git commit -mchange foo6 >/dev/null) &&
> -head8=$(cd sm1; git rev-parse --verify HEAD | cut -c1-7) &&
>  test_expect_success 'submodule is modified' "
> +head8=$(cd sm1; git rev-parse --short --verify HEAD) &&
>   git diff-index -p --submodule=log HEAD >actual &&
>   cat >expected <<-EOF &&
>  Submodule sm1 $head6..$head8:
> @@ -461,7 +461,7 @@ EOF
>   test_cmp expected actual
>  "
>  
> -fullhead7=$(cd sm2; git rev-list --max-count=1 $head7)
> +fullhead7=$(cd sm2; git rev-parse --verify $head7)
>  
>  test_expect_success 'given commit --submodule=short' "
>   git diff-index -p --submodule=short HEAD^ >actual &&
--
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 0/6] Improve remote helper documentation

[Max Horn]

Various remote helper capabilities and commands were not
documented, in particular 'export', or documented in a misleading
way (e.g. 'for-push' was listed as a ref attribute understood by
git, which is not the case). This patch series changes that, and
also address some other things in the remote helper documentation
that I found jarring when reading through it.

Note that the description of export and (im|ex)port-marks probably can be
improved, and I hope that somebody who knows more about them
than me and/or is better at writing documentation will do just that.
But I felt it was better to provide something than to do nothing
and only complain, as I did previously on this subject ;-).

Max Horn (6):
  Document invocation first, then input format
  Document missing remote helper capabilities
  Fix grammar
  Rearrange the description of remote helper capabilities
  Make clearer which commands must be supported for which capabilities
  Remove 'for-push' from ref list attributes list, link to subsections

 Documentation/git-remote-helpers.txt | 241 ---
 1 file changed, 136 insertions(+), 105 deletions(-)

-- 
1.8.0.393.gcc9701d

--
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 6/6] Remove 'for-push' from ref list attributes list, link to subsections

[Max Horn]

The documentation was misleading in that it gave the impression that
'for-push' could be used as a ref attribute in the output of the
'list' command. That is wrong.

Signed-off-by: Max Horn 
---
 Documentation/git-remote-helpers.txt | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/Documentation/git-remote-helpers.txt 
b/Documentation/git-remote-helpers.txt
index 023dcca..081cb06 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -227,6 +227,8 @@ Support for this command is mandatory.
the name; unrecognized attributes are ignored. The list ends
with a blank line.
 +
+See REF LIST ATTRIBUTES for a list of currently defined options.
++
 Supported if the helper has the "fetch" or "import" capability.
 
 'list for-push'::
@@ -248,6 +250,8 @@ Supported if the helper has the "push" or "export" 
capability.
for it).  Options should be set before other commands,
and may influence the behavior of those commands.
 +
+See OPTIONS for a list of currently defined options.
++
 Supported if the helper has the "option" capability.
 
 'fetch'  ::
@@ -256,7 +260,7 @@ Supported if the helper has the "option" capability.
per line, terminated with a blank line.
Outputs a single blank line when all fetch commands in the
same batch are complete. Only objects which were reported
-   in the ref list with a sha1 may be fetched this way.
+   in the output of 'list' with a sha1 may be fetched this way.
 +
 Optionally may output a 'lock ' line indicating a file under
 GIT_DIR/objects/pack which is keeping a pack until refs can be
@@ -360,10 +364,9 @@ capabilities reported by the helper.
 REF LIST ATTRIBUTES
 ---
 
-'for-push'::
-   The caller wants to use the ref list to prepare push
-   commands.  A helper might chose to acquire the ref list by
-   opening a different type of connection to the destination.
+The 'list' command produces a list of refs in which each ref
+may be followed by a list of attributes. The following ref list
+attributes are defined.
 
 'unchanged'::
This ref is unchanged since the last import or fetch, although
-- 
1.8.0.393.gcc9701d

--
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 4/6] Rearrange the description of remote helper capabilities

[Max Horn]

This also remove some duplication in the descriptions
(e.g. refspec was explained twice with similar level of detail)

Signed-off-by: Max Horn 
---
 Documentation/git-remote-helpers.txt | 134 +++
 1 file changed, 56 insertions(+), 78 deletions(-)

diff --git a/Documentation/git-remote-helpers.txt 
b/Documentation/git-remote-helpers.txt
index 7eb43d7..7ac1461 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -88,81 +88,17 @@ Each remote helper is expected to support only a subset of 
commands.
 The operations a helper supports are declared to git in the response
 to the `capabilities` command (see COMMANDS, below).
 
-'option'::
-   For specifying settings like `verbosity` (how much output to
-   write to stderr) and `depth` (how much history is wanted in the
-   case of a shallow clone) that affect how other commands are
-   carried out.
-
-'connect'::
-   For fetching and pushing using git's native packfile protocol
-   that requires a bidirectional, full-duplex connection.
-
-'push'::
-   For listing remote refs and pushing specified objects from the
-   local object store to remote refs.
-
-'fetch'::
-   For listing remote refs and fetching the associated history to
-   the local object store.
-
-'export'::
-   For listing remote refs and pushing specified objects from a
-   fast-import stream to remote refs.
-
-'import'::
-   For listing remote refs and fetching the associated history as
-   a fast-import stream.
-
-'refspec' ::
-   This modifies the 'import' capability, allowing the produced
-   fast-import stream to modify refs in a private namespace
-   instead of writing to refs/heads or refs/remotes directly.
-   It is recommended that all importers providing the 'import'
-   capability use this.
-+
-A helper advertising the capability
-`refspec refs/heads/*:refs/svn/origin/branches/*`
-is saying that, when it is asked to `import refs/heads/topic`, the
-stream it outputs will update the `refs/svn/origin/branches/topic`
-ref.
-+
-This capability can be advertised multiple times.  The first
-applicable refspec takes precedence.  The left-hand of refspecs
-advertised with this capability must cover all refs reported by
-the list command.  If no 'refspec' capability is advertised,
-there is an implied `refspec *:*`.
-
-'bidi-import'::
-   The fast-import commands 'cat-blob' and 'ls' can be used by 
remote-helpers
-   to retrieve information about blobs and trees that already exist in
-   fast-import's memory. This requires a channel from fast-import to the
-   remote-helper.
-   If it is advertised in addition to "import", git establishes a pipe from
-   fast-import to the remote-helper's stdin.
-   It follows that git and fast-import are both connected to the
-   remote-helper's stdin. Because git can send multiple commands to
-   the remote-helper it is required that helpers that use 'bidi-import'
-   buffer all 'import' commands of a batch before sending data to 
fast-import.
-   This is to prevent mixing commands and fast-import responses on the
-   helper's stdin.
-
-'export-marks' ::
-   This modifies the 'export' capability, instructing git to dump the
-   internal marks table to  when complete. For details,
-   read up on '--export-marks=' in linkgit:git-fast-export[1].
-
-'import-marks' ::
-   This modifies the 'export' capability, instructing git to load the
-   marks specified in  before processing any input. For details,
-   read up on '--import-marks=' in linkgit:git-fast-export[1].
+In the following, we list all defined capabilities and for
+each we list which commands a helper with that capability
+must provide.
 
 Capabilities for Pushing
-
+
 'connect'::
Can attempt to connect to 'git receive-pack' (for pushing),
-   'git upload-pack', etc for communication using the
-   packfile protocol.
+   'git upload-pack', etc for communication using
+   git's native packfile protocol. This
+   requires a bidirectional, full-duplex connection.
 +
 Supported commands: 'connect'.
 
@@ -186,11 +122,12 @@ Other frontends may have some other order of preference.
 
 
 Capabilities for Fetching
-~
+^
 'connect'::
Can try to connect to 'git upload-pack' (for fetching),
'git receive-pack', etc for communication using the
-   packfile protocol.
+   git's native packfile protocol. This
+   requires a bidirectional, full-duplex connection.
 +
 Supported commands: 'connect'.
 
@@ -212,14 +149,27 @@ connecting (see the 'connect' command under COMMANDS).
 When choosing between 'fetch' and 'import', git prefers 'fetch'.
 Other frontends may have some other order of preference.
 
+Miscellaneous capabilities
+^^
+
+'op

[PATCH 2/6] Document missing remote helper capabilities

[Max Horn]

The 'export' and '(im|ex)port-marks' capabilities were not
documented at all

Signed-off-by: Max Horn 
---
 Documentation/git-remote-helpers.txt | 45 +---
 1 file changed, 42 insertions(+), 3 deletions(-)

diff --git a/Documentation/git-remote-helpers.txt 
b/Documentation/git-remote-helpers.txt
index 9a7e583..db63541 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -106,6 +106,10 @@ to the `capabilities` command (see COMMANDS, below).
For listing remote refs and fetching the associated history to
the local object store.
 
+'export'::
+   For listing remote refs and pushing specified objects from a
+   fast-import stream to remote refs.
+
 'import'::
For listing remote refs and fetching the associated history as
a fast-import stream.
@@ -143,6 +147,16 @@ there is an implied `refspec *:*`.
This is to prevent mixing commands and fast-import responses on the
helper's stdin.
 
+'export-marks' ::
+   This modifies the 'export' capability, instructing git to dump the
+   internal marks table to  when complete. For details,
+   read up on '--export-marks=' in linkgit:git-fast-export[1].
+
+'import-marks' ::
+   This modifies the 'export' capability, instructing git to load the
+   marks specified in  before processing any input. For details,
+   read up on '--import-marks=' in linkgit:git-fast-export[1].
+
 Capabilities for Pushing
 
 'connect'::
@@ -158,9 +172,18 @@ Supported commands: 'connect'.
 +
 Supported commands: 'list for-push', 'push'.
 
-If a helper advertises both 'connect' and 'push', git will use
-'connect' if possible and fall back to 'push' if the helper requests
-so when connecting (see the 'connect' command under COMMANDS).
+'export'::
+   Can discover remote refs and push specified objects from a
+   fast-import stream to remote refs.
++
+Supported commands: 'list for-push', 'export'.
+
+If a helper advertises 'connect', git will use it if possible and
+fall back to another capability if the helper requests so when
+connecting (see the 'connect' command under COMMANDS).
+When choosing between 'push' and 'export', git prefers 'push'.
+Other frontends may have some other order of preference.
+
 
 Capabilities for Fetching
 ~
@@ -307,6 +330,22 @@ stdin.
 +
 Supported if the helper has the 'import' capability.
 
+'export'::
+   Instructs the remote helper that any subsequent input is
+   part of a fast-import stream (generated by 'git fast-export')
+   containing objects which should be pushed to the remote.
++
+Especially useful for interoperability with a foreign versioning
+system.
++
+The 'export-marks' and 'import-marks' capabilities, if specified,
+affect this command in so far as they are passed on to 'git
+fast-export', which then will load/store a table of marks for
+local objects. This can be used to implement for incremental
+operations.
++
+Supported if the helper has the 'export' capability.
+
 'connect' ::
Connects to given service. Standard input and standard output
of helper are connected to specified service (git prefix is
-- 
1.8.0.393.gcc9701d

--
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/6] Fix grammar

[Max Horn]

Signed-off-by: Max Horn 
---
 Documentation/git-remote-helpers.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/git-remote-helpers.txt 
b/Documentation/git-remote-helpers.txt
index db63541..7eb43d7 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -235,9 +235,9 @@ Commands are given by the caller on the helper's standard 
input, one per line.
 'capabilities'::
Lists the capabilities of the helper, one per line, ending
with a blank line. Each capability may be preceded with '*',
-   which marks them mandatory for git version using the remote
-   helper to understand (unknown mandatory capability is fatal
-   error).
+   which marks them mandatory for git versions using the remote
+   helper to understand. Any unknown mandatory capability is a
+   fatal error.
 
 'list'::
Lists the refs, one per line, in the format " 
-- 
1.8.0.393.gcc9701d

--
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/6] Document invocation first, then input format

[Max Horn]

In the distant past, the order was 'Invocation', 'Commands',
'Capabilities', ...

Then it was decided that before giving a list of Commands, there
should be an overall description of the 'Input format', which was
a wise decision. However, this description was put as the very
first thing, with the rationale that any implementor would want
to know that first.

However, it seems an implementor would actually first need to
know how the remote helper will be invoked, so moving
'Invocation' to the front again seems logical. Moreover, we now
don't switch from discussing the input format to the invocation
style and then back to input related stuff.

Signed-off-by: Max Horn 
---
 Documentation/git-remote-helpers.txt | 62 ++--
 1 file changed, 31 insertions(+), 31 deletions(-)

diff --git a/Documentation/git-remote-helpers.txt 
b/Documentation/git-remote-helpers.txt
index 5ce4cda..9a7e583 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -35,6 +35,37 @@ transport protocols, such as 'git-remote-http', 
'git-remote-https',
 'git-remote-ftp' and 'git-remote-ftps'. They implement the capabilities
 'fetch', 'option', and 'push'.
 
+INVOCATION
+--
+
+Remote helper programs are invoked with one or (optionally) two
+arguments. The first argument specifies a remote repository as in git;
+it is either the name of a configured remote or a URL. The second
+argument specifies a URL; it is usually of the form
+'://', but any arbitrary string is possible.
+The 'GIT_DIR' environment variable is set up for the remote helper
+and can be used to determine where to store additional data or from
+which directory to invoke auxiliary git commands.
+
+When git encounters a URL of the form '://', where
+'' is a protocol that it cannot handle natively, it
+automatically invokes 'git remote-' with the full URL as
+the second argument. If such a URL is encountered directly on the
+command line, the first argument is the same as the second, and if it
+is encountered in a configured remote, the first argument is the name
+of that remote.
+
+A URL of the form '::' explicitly instructs git to
+invoke 'git remote-' with '' as the second
+argument. If such a URL is encountered directly on the command line,
+the first argument is '', and if it is encountered in a
+configured remote, the first argument is the name of that remote.
+
+Additionally, when a configured remote has 'remote..vcs' set to
+'', git explicitly invokes 'git remote-' with
+'' as the first argument. If set, the second argument is
+'remote..url'; otherwise, the second argument is omitted.
+
 INPUT FORMAT
 
 
@@ -173,37 +204,6 @@ advertised with this capability must cover all refs 
reported by
 the list command.  If no 'refspec' capability is advertised,
 there is an implied `refspec *:*`.
 
-INVOCATION
---
-
-Remote helper programs are invoked with one or (optionally) two
-arguments. The first argument specifies a remote repository as in git;
-it is either the name of a configured remote or a URL. The second
-argument specifies a URL; it is usually of the form
-'://', but any arbitrary string is possible.
-The 'GIT_DIR' environment variable is set up for the remote helper
-and can be used to determine where to store additional data or from
-which directory to invoke auxiliary git commands.
-
-When git encounters a URL of the form '://', where
-'' is a protocol that it cannot handle natively, it
-automatically invokes 'git remote-' with the full URL as
-the second argument. If such a URL is encountered directly on the
-command line, the first argument is the same as the second, and if it
-is encountered in a configured remote, the first argument is the name
-of that remote.
-
-A URL of the form '::' explicitly instructs git to
-invoke 'git remote-' with '' as the second
-argument. If such a URL is encountered directly on the command line,
-the first argument is '', and if it is encountered in a
-configured remote, the first argument is the name of that remote.
-
-Additionally, when a configured remote has 'remote..vcs' set to
-'', git explicitly invokes 'git remote-' with
-'' as the first argument. If set, the second argument is
-'remote..url'; otherwise, the second argument is omitted.
-
 COMMANDS
 
 
-- 
1.8.0.393.gcc9701d

--
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 5/6] Make clearer which commands must be supported for which capabilities

[Max Horn]

In particular, document 'list for-push' separately from 'list',
as the former needs only be supported for the 'push' capability,
and the latter only for fetch/import/export. In particular,
a hypothetically 'push-only' helper only needs to support the
former, not the latter.

Signed-off-by: Max Horn 
---
 Documentation/git-remote-helpers.txt | 21 -
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/Documentation/git-remote-helpers.txt 
b/Documentation/git-remote-helpers.txt
index 7ac1461..023dcca 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -216,6 +216,8 @@ Commands are given by the caller on the helper's standard 
input, one per line.
which marks them mandatory for git versions using the remote
helper to understand. Any unknown mandatory capability is a
fatal error.
++
+Support for this command is mandatory.
 
 'list'::
Lists the refs, one per line, in the format " 
@@ -225,9 +227,18 @@ Commands are given by the caller on the helper's standard 
input, one per line.
the name; unrecognized attributes are ignored. The list ends
with a blank line.
 +
-If 'push' is supported this may be called as 'list for-push'
-to obtain the current refs prior to sending one or more 'push'
-commands to the helper.
+Supported if the helper has the "fetch" or "import" capability.
+
+'list for-push'::
+   Similar to 'list', except that it is used if and only if
+   the caller wants to the resulting ref list to prepare
+   push commands.
+   A helper supporting both push and fetch can use this
+   to distinguish for which operation the output of 'list'
+   is going to be used, possibly reducing the amount
+   of work that needs to be performed.
++
+Supported if the helper has the "push" or "export" capability.
 
 'option'  ::
Sets the transport helper option  to .  Outputs a
@@ -306,7 +317,7 @@ sequence has to be buffered before starting to send data to 
fast-import
 to prevent mixing of commands and fast-import responses on the helper's
 stdin.
 +
-Supported if the helper has the 'import' capability.
+Supported if the helper has the "import" capability.
 
 'export'::
Instructs the remote helper that any subsequent input is
@@ -322,7 +333,7 @@ fast-export', which then will load/store a table of marks 
for
 local objects. This can be used to implement for incremental
 operations.
 +
-Supported if the helper has the 'export' capability.
+Supported if the helper has the "export" capability.
 
 'connect' ::
Connects to given service. Standard input and standard output
-- 
1.8.0.393.gcc9701d

--
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 4/4] t4041 (diff-submodule-option): change tense of test names

[Junio C Hamano]

Ramkumar Ramachandra  writes:

> Change the tense of test names from past to present, as this is the
> prevalent style.
>
> Signed-off-by: Ramkumar Ramachandra 
> ---

I see most of them are not "past" but "past particle" used as if
they are adjectives.

For example, I think this test

> -test_expect_success 'added submodule' '

tries to say "See what happens to an added submodule".

The same for the others.

> -test_expect_success 'modified submodule(forward)' '

"See what is shown for modified submodule."

> -test_expect_success 'typechanged submodule(submodule->blob), --cached' '

"See what is shown for typechanged one, when --cached option is
given".

So I do not think this patch is needed; the current wording looks
not so grammatically kosher, but still is understandable.  Updated
result isn't.
--
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] Third try at documenting command integration requirements.

[Eric S. Raymond]

Michael Haggerty :
> OK, now let's discuss *which* minimum Python version that git should
> support in the hypothetical new world...

By all means!
 
> It would be a shame to leave RHEL 5 users behind if Python is used to
> implement important git functionality.  Python 2.4 is missing some of
> Python's shiny new features, but still quite OK.  What features would
> you miss the most if we were to target Python 2.4 instead of 2.6?

Off the top of my head...the 'with' statement, the conditional
expression, and built-in JSON support.  Other developers would be
likely to kick about the string format() method; personally I'm
cheerfully old-school about that.

I agree that 2.4 is still quite OK.  I'm a little concerned that dropping that
far back might store up some transition problems for the day we decide to
make the jump to Python 3.

On the other hand, I think gating features on RHEL5 might be
excessively cautious.  According to [1], RHEL will red-zone within 30
days if it hasn't done so already ([1] says "Q4").  And RHEL6 (with
Python 2.6) has been shipping for two years.

Policy suggestion: we aim to stay friendly for every version of RHEL that
is still in Support 1.  I doubt anyone will code anything critical 
in Python before Dec 31st - I'm certainly not planning to!

[1] http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux RHEL5 is going
-- 
http://www.catb.org/~esr/";>Eric S. Raymond
--
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/4] t4041 (diff-submodule-option): rewrite add_file() routine

[Junio C Hamano]

Ramkumar Ramachandra  writes:

> Instead of "cd there and then come back", use the "cd there in a
> subshell" pattern.  Also fix '&&' chaining in one place.
>
> Suggested-by: Junio C Hamano 
> Signed-off-by: Ramkumar Ramachandra 
> ---
>  t/t4041-diff-submodule-option.sh |   13 +
>  1 files changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/t/t4041-diff-submodule-option.sh 
> b/t/t4041-diff-submodule-option.sh
> index cfb71e5..103c690 100755
> --- a/t/t4041-diff-submodule-option.sh
> +++ b/t/t4041-diff-submodule-option.sh
> @@ -11,18 +11,15 @@ This test tries to verify the sanity of the --submodule 
> option of git diff.
>  . ./test-lib.sh
>  
>  add_file () {
> + (cd "$1" &&
> + shift &&
> + for name; do
>   echo "$name" > "$name" &&
>   git add "$name" &&
>   test_tick &&
>   git commit -m "Add $name"
> + done >/dev/null &&
> + git rev-parse --short --verify HEAD)

While at it, why not do the "indent with a single tab", and other
style fixes?  e.g.

(
cd "$1" &&
shift &&
for name
do
echo "$name" >"$name" &&
git add $name" &&
test_tick &&
git commit -m "Add $name" || exit
done >/dev/null &&
git rev-parse --short --verify HEAD
)

The "|| exit" is needed to catch failures inside the loop (not that
"git commit" there is likely to fail, so it is just for
completeness).

--
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 v4 0/4] git-submodule add: Add --local-branch option

[Heiko Voigt]

Hi,

On Mon, Nov 26, 2012 at 04:00:15PM -0500, W. Trevor King wrote:
> From: "W. Trevor King" 
> 
> On Fri, Nov 23, 2012 at 12:54:02PM -0500, W. Trevor King wrote:
> > We could add
> >
> >   $ git submodule update --branch
> >
> > to checkout the gitlinked SHA1 as submodule..branch in each of
> > the submodules, leaving the submodules on the .gitmodules-configured
> > branch.  Effectively (for each submodule):
> >
> >   $ git branch -f $branch $sha1
> >   $ git checkout $branch
> 
> I haven't gotten any feedback on this as an idea, but perhaps someone
> will comment on it as a patch series ;).

I am not sure I understand you correctly. You are suggesting that the
branch option as an alias for the registered SHA1 in the superproject?

I though the goal of your series was that you want to track submodules
branch which come from the remote side?

Doing the above does not assist you much in that does it?

I would think more of some convention like:

$ git checkout -t origin/$branch

when first initialising the submodule with e.g.

$ git submodule update --init --branch

Then later calls of

$ git submodule update --branch

would have a branch configured to pull from. I imagine that results in
a similar behavior gerrit is doing on the server side?

> Changes since v3:
> 
> * --record=??? is now --local-branch=???
> * Dropped patches 2 ($submodule_ export) and 3 (motivating documentation)
> * Added local git-config overrides of .gitmodules' submodule..branch
> * Added `submodule update --branch`

I would prefer if we could squash all these commits together into one
since it seems to me one logical step, using the new variable for update
belongs together with its configuration on initialization.

How about reusing the -b|--branch option for add? Since we only change
the behavior when submodule.$name.update is set to branch it seems
reasonable to me. Opinions?

> Because you need to recurse through submodules for `update --branch`
> even if "$subsha1" == "$sha1", I had to amend the conditional
> controlling that block.  This broke one of the existing tests, which I
> "fixed" in patch 4.  I think a proper fix would involve rewriting
> 
>   (clear_local_git_env; cd "$sm_path" &&
>( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&
> test -z "$rev") || git-fetch)) ||
>   die "$(eval_gettext "Unable to fetch in submodule path '\$sm_path'")"
> 
> but I'm not familiar enough with rev-list to want to dig into that
> yet.  If feedback for the earlier three patches is positive, I'll work
> up a clean fix and resubmit.

You probably need to separate your handling here. The comparison of the
currently checked out sha1 and the recorded sha1 is an optimization
which skips unnecessary fetching in case the submodules commits are
already correct. This code snippet checks whether the to be checked out
sha1 is already local and also skips the fetch if it is. We should not
break that.

Maybe we need an else block here and possibly extract the current code
inside the if statement into a function. E.g. that the final code looks
something like this:

if test "$subsha1" != "$sha1"
then
handle_on_demand_fetch_update ...
else
handle_tracked_branch_update ...
fi

Not sure about the function names though. If we decide to go that route:
The extraction into a function should go in an extra preparation patch
which does not change any functionality.

I will reply to the patches for further comments.

Cheers Heiko
--
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: Python extension commands in git - request for policy change

[Eric S. Raymond]

Magnus Bäck :
> While "constant traffic" probably overstates the issue, these are not
> theoretical problems. I recall at least three cases in the last year
> or so where Git has seen breakage with Solaris or Mac OS X because
> of sed or tr incompatibilities, and I don't even read this list that
> thoroughly.

This is exactly the sort of of pain experience would lead me to
expect.  

OK, this is where I assume the full Old Fart position (30-year
old-school Unix guy, author of "The Art of Unix Programming", can
remember the years before Perl and still has sh idioms in his
fingertips) and say "Get with the 21st century, people! Or at least
1990..."

As a general scripting language shell sucks *really badly* compared to
anything new-school. Performance, portability, you name it, it's a
mess.  It's not so much the shell interpreters itself that are the
portabilty problem, but (as Magnus implicitly points out) all those
userland dependencies on sed and tr and awk and even variants of
expr(!) that get dragged in the second you try to get any actual work
done.

Can we cease behaving like we're still pounding keys on 110-baud
teletypes now?  Some old-school Unix habits have persisted long past
the point that they're even remotely sane.  Shell programming at any
volume above a few lines of throwaway code is one of them - it's
*nuts* and we should *stop doing it*.

(Yes, I too still make this mistake occasionally out of ancient reflex.
But I know I shouldn't, and I always end up regretting it.)
-- 
http://www.catb.org/~esr/";>Eric S. Raymond
--
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 v4 3/4] git-submodule update: Add --branch option

[Heiko Voigt]

On Mon, Nov 26, 2012 at 04:00:18PM -0500, W. Trevor King wrote:
> From: "W. Trevor King" 
> 
> This allows users to checkout the current
> superproject-recorded-submodule-sha as a branch, avoiding the detached
> head state that the standard submodule update creates.  This may be
> useful for the existing --rebase/--merge workflows which already avoid
> detached heads.
> 
> It is also useful if you want easy tracking of upstream branches.  The
> particular upstream branch to be tracked is configured locally with
> .git/modules//config.  With the new option Ævar's suggested
> 
>   $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitm
> odules submodule.$name.branch) && git pull'
> 
> reduces to a
> 
>   $ git submodule update --branch
> 
> after each supermodule .gitmodules edit, and a
> 
>   $ git submodule foreach 'git pull'
> 
> whenever you feel like updating the submodules.  Your still on you're
> own to commit (or not) the updated submodule hashes in the
> superproject's .gitmodules.
> 
> Signed-off-by: W. Trevor King 
> ---
>  Documentation/git-submodule.txt | 20 +++--
>  git-submodule.sh| 48 +--
>  t/t7406-submodule-update.sh | 50 
> -
>  3 files changed, 98 insertions(+), 20 deletions(-)
> 
> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
> index d0b4436..34392a1 100644
> --- a/Documentation/git-submodule.txt
> +++ b/Documentation/git-submodule.txt
> @@ -13,7 +13,7 @@ SYNOPSIS
> [-f|--force] [--reference ] [--]  []
>  'git submodule' [--quiet] status [--cached] [--recursive] [--] [...]
>  'git submodule' [--quiet] init [--] [...]
> -'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]
> +'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--branch] 
> [--rebase]
> [--reference ] [--merge] [--recursive] [--] 
> [...]
>  'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) 
> ]
> [commit] [--] [...]
> @@ -136,11 +136,11 @@ init::
>  
>  update::
>   Update the registered submodules, i.e. clone missing submodules and
> - checkout the commit specified in the index of the containing repository.
> - This will make the submodules HEAD be detached unless `--rebase` or
> - `--merge` is specified or the key `submodule.$name.update` is set to
> - `rebase`, `merge` or `none`. `none` can be overridden by specifying
> - `--checkout`.
> + checkout the commit specified in the index of the containing
> + repository.  This will make the submodules HEAD be detached unless
> + `--branch`, `--rebase`, `--merge` is specified or the key
> + `submodule.$name.update` is set to `branch`, `rebase`, `merge` or
> + `none`. `none` can be overridden by specifying `--checkout`.
>  +
>  If the submodule is not yet initialized, and you just want to use the
>  setting as stored in .gitmodules, you can automatically initialize the
> @@ -207,7 +207,13 @@ OPTIONS
>  
>  -b::
>  --branch::
> - Branch of repository to add as submodule.
> + When used with the add command, gives the branch of repository to
> + add as submodule.
> ++
> +When used with the update command, checks out a branch named
> +`submodule..branch` (as set by `--local-branch`) pointing at the
> +current HEAD SHA-1.  This is useful for commands like `update
> +--rebase` that do not work on detached heads.

Since you are reusing this option for update it further convinces me
that reusing it for add makes sense and simplifies the logic for users.

I think an optional argument for --branch would be nice in the update
case:

$ git submodule update --branch=master

would then allow a user that has not configured anything (except the
branch tracking info in the submodule of course) to pull all submodules
master branches.

> diff --git a/git-submodule.sh b/git-submodule.sh
> index c51b6ae..28eb4b1 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -627,7 +631,7 @@ Maybe you want to use 'update --init'?")"
>   die "$(eval_gettext "Unable to find current revision in 
> submodule path '\$sm_path'")"
>   fi
>  
> - if test "$subsha1" != "$sha1" -o -n "$force"
> + if test "$subsha1" != "$sha1" -o -n "$force" -o 
> "$update_module" = "branch"

As said before I think separating your code from the current update
logic will simplify the handling below.

>   then
>   subforce=$force
>   # If we don't already have a -f flag and the submodule 
> has never been checked out
> @@ -650,16 +654,21 @@ Maybe you want to use 'update --init'?")"
>   case ";$cloned_modules;" in
>   *";$name;"*)
>   # then there is no local change to integrate
> - update_module= ;;
> +   

Re: [PATCH v4 0/4] git-submodule add: Add --local-branch option

[W. Trevor King]

On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote:
> I would prefer if we could squash all these commits together into
> one since it seems to me one logical step, using the new variable
> for update belongs together with its configuration on
> initialization.

Works for me.  I could also try to rework the patch boundaries if a
monolithic patch is not acceptable.  I agree that the current
documentation assignments are fairly arbitrary.  If I don't hear from
anyone in favor of keeping them separate, v5 will be monolithic.

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature

Re: [PATCH] diff: Fixes shortstat number of files

[Junio C Hamano]

Antoine Pelisse  writes:

> Indeed stat seems to be broken on master by commit 74faaa16 from Linus 
> Torvalds
>
> There are three separated issues here:
>  - unmerged files are marked as "interesting" in stat and probably
> shouldn't, with some patch like this:
>
> data->is_interesting = p->status != 0;
>
> if (!one || !two) {
> data->is_unmerged = 1;
> +   data->is_interesting = 0;
> return;
> }
>
> By the way, I don't get the point of this code then:
>
> else if (data->files[i]->is_unmerged) {
> fprintf(options->file, "%s", line_prefix);
> show_name(options->file, prefix, name, len);
> fprintf(options->file, " Unmerged\n");
> continue;
> }
>
> and
>
> if (file->is_unmerged) {
> /* "Unmerged" is 8 characters */
> bin_width = bin_width < 8 ? 8 : bin_width;
> continue;
> }
>
> Are we ever supposed to print that ? I feel like it could be removed.

Yes, we have been showing two entries in --stat output:

 file | Unmerged
 file | 4 

and that is not going to change.

There are a few problems in diff.c around --stat area, partially
caused by Linus's patch (like s/is_rename/is_interesting/ change
started ignoring unmerged entries in the diff queue and made the
existing loop not go into the codepath we see above), and largely
caused by the earlier change that introduced when --stat-count was
added (the second loop that decrements total_files does so only for
the paths within the "count" horizon determined by the first loop;
total_files must be adjusted for _all_ uninteresting and unchanged
filepairs and exclude unmerged entries).

Also the initialization of data->is_interesting is wrong.  These
days, p->status is never zero.

I'll send out a fix later today.
--
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: Re: [PATCH v4 0/4] git-submodule add: Add --local-branch option

[Heiko Voigt]

Hi,

I just realized that I gave you an confusing suggestion.

On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote:
>   if test "$subsha1" != "$sha1"
>   then
>   handle_on_demand_fetch_update ...
>   else
>   handle_tracked_branch_update ...
>   fi

That obviously does not work. Here I meant of course something like:

if test "$update_module" = "branch"
then
handle_tracked_branch_update ...
else
handle_on_demand_fetch_update ...
fi

Cheers Heiko
--
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 v4 0/4] git-submodule add: Add --local-branch option

[W. Trevor King]

On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote:
> On Mon, Nov 26, 2012 at 04:00:15PM -0500, W. Trevor King wrote:
> > From: "W. Trevor King" 
> > 
> > On Fri, Nov 23, 2012 at 12:54:02PM -0500, W. Trevor King wrote:
> > > We could add
> > >
> > >   $ git submodule update --branch
> > >
> > > to checkout the gitlinked SHA1 as submodule..branch in each of
> > > the submodules, leaving the submodules on the .gitmodules-configured
> > > branch.  Effectively (for each submodule):
> > >
> > >   $ git branch -f $branch $sha1
> > >   $ git checkout $branch
> > 
> > I haven't gotten any feedback on this as an idea, but perhaps someone
> > will comment on it as a patch series ;).
> 
> I am not sure I understand you correctly. You are suggesting that the
> branch option as an alias for the registered SHA1 in the superproject?
> 
> I though the goal of your series was that you want to track submodules
> branch which come from the remote side?

That's what I'd initially thought, but when I went to implement
`update --pull`, I realized that

  $ git submodule foreach 'git checkout $(git config --file 
$toplevel/.gitmodules submodule.$name.branch) && …'

is using submodule..branch as the local branch name.  The remote
branch name was actually setup in .git/modules//config during
the initial "clone -b  …".

The v4 series leaves the remote branch amigious, but it helps you
point the local branch at the right hash so that future calls to

  $ git submodule foreach 'git pull'

can use the branch's .git/modules//config settings.

> I would think more of some convention like:
> 
>   $ git checkout -t origin/$branch
> 
> when first initialising the submodule with e.g.
> 
>   $ git submodule update --init --branch
> 
> Then later calls of
> 
>   $ git submodule update --branch
> 
> would have a branch configured to pull from. I imagine that results in
> a similar behavior gerrit is doing on the server side?

That sounds like it's doing pretty much the same thing.  Can you think
of a test that would distinguish it from my current v4 implementation?

> > Changes since v3:
> > 
> > * --record=??? is now --local-branch=???
> > * Dropped patches 2 ($submodule_ export) and 3 (motivating documentation)
> > * Added local git-config overrides of .gitmodules' submodule..branch
> > * Added `submodule update --branch`
> 
> I would prefer if we could squash all these commits together into one
> since it seems to me one logical step, using the new variable for update
> belongs together with its configuration on initialization.
> 
> How about reusing the -b|--branch option for add? Since we only change
> the behavior when submodule.$name.update is set to branch it seems
> reasonable to me. Opinions?

That was the approach I used in v1, but people were concerned that we
would be stomping on previously unclaimed config space.  Since noone
has pointed out other uses besides Gerrit's very similar case, I'm not
sure if that is still an issue.

> > Because you need to recurse through submodules for `update --branch`
> > even if "$subsha1" == "$sha1", I had to amend the conditional
> > controlling that block.  This broke one of the existing tests, which I
> > "fixed" in patch 4.  I think a proper fix would involve rewriting
> > 
> >   (clear_local_git_env; cd "$sm_path" &&
> >( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&
> > test -z "$rev") || git-fetch)) ||
> >   die "$(eval_gettext "Unable to fetch in submodule path '\$sm_path'")"
> > 
> > but I'm not familiar enough with rev-list to want to dig into that
> > yet.  If feedback for the earlier three patches is positive, I'll work
> > up a clean fix and resubmit.
> 
> You probably need to separate your handling here. The comparison of the
> currently checked out sha1 and the recorded sha1 is an optimization
> which skips unnecessary fetching in case the submodules commits are
> already correct. This code snippet checks whether the to be checked out
> sha1 is already local and also skips the fetch if it is. We should not
> break that.

Agreed.  However, determining if the target $sha1 is local should have
nothing to do with the current checked out $subsha1.

Thanks for the feedback!
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature

Re: [PATCH v4 3/4] git-submodule update: Add --branch option

[W. Trevor King]

On Tue, Nov 27, 2012 at 07:51:42PM +0100, Heiko Voigt wrote:
> On Mon, Nov 26, 2012 at 04:00:18PM -0500, W. Trevor King wrote:
> >  -b::
> >  --branch::
> > -   Branch of repository to add as submodule.
> > +   When used with the add command, gives the branch of repository to
> > +   add as submodule.
> > ++
> > +When used with the update command, checks out a branch named
> > +`submodule..branch` (as set by `--local-branch`) pointing at the
> > +current HEAD SHA-1.  This is useful for commands like `update
> > +--rebase` that do not work on detached heads.
> 
> Since you are reusing this option for update it further convinces me
> that reusing it for add makes sense and simplifies the logic for users.
> 
> I think an optional argument for --branch would be nice in the update
> case:
> 
>   $ git submodule update --branch=master
> 
> would then allow a user that has not configured anything (except the
> branch tracking info in the submodule of course) to pull all submodules
> master branches.

Sounds good to me.  Remember that this is checking the branch and
pointing it at $sha1 (preparing for the pull), not pulling remote
branches.  The pull happens in a later

  $ git submodules foreach 'git pull'

> > diff --git a/git-submodule.sh b/git-submodule.sh
> > index c51b6ae..28eb4b1 100755
> > --- a/git-submodule.sh
> > +++ b/git-submodule.sh
> > @@ -627,7 +631,7 @@ Maybe you want to use 'update --init'?")"
> > die "$(eval_gettext "Unable to find current revision in 
> > submodule path '\$sm_path'")"
> > fi
> >  
> > -   if test "$subsha1" != "$sha1" -o -n "$force"
> > +   if test "$subsha1" != "$sha1" -o -n "$force" -o 
> > "$update_module" = "branch"
> 
> As said before I think separating your code from the current update
> logic will simplify the handling below.

This felt less invasive (it avoids duplicating the recursion logic),
but I don't mind breaking it into a separate function/block.

> > must_die_on_failure=
> > case "$update_module" in
> > rebase)
> > command="git rebase"
> > -   die_msg="$(eval_gettext "Unable to rebase 
> > '\$sha1' in submodule path '\$sm_path'")"
> > +   die_msg="$(eval_gettext "Unable to rebase 
> > '\$sha1' in submodule path '\$sm_path'")" 
> > say_msg="$(eval_gettext "Submodule path 
> > '\$sm_path': rebased into '\$sha1'")"
> > -   must_die_on_failure=yes
> > +   must_die_on_failure=yes
> 
> Please always cleanup whitespace changes.

Oops, sloppy me.  Will fix.

> > then
> > -   die_with_status 2 "$die_msg"
> > -   else
> > -   err="${err};$die_msg"
> > -   continue
> > +   if (clear_local_git_env; cd "$sm_path" &&
> > +   git branch -f "$branch" "$sha1" &&
> > +   git checkout "$branch")
> 
> You wrote in earlier emails that you wanted to protect the user from
> non-fastforward changes. So I would expect a
> 
>   $ git pull --ff-only

I'm not pulling here, I'm doing a regular `submodule update`, and
after that's done I checkout the branch pointing at the $sha1 to which
the branch was just updated.  All the submodule-state-clobbering
caveats of a usual `submodule update` still apply to this new
`submodule update --branch`, and I'm fine with that.

> BTW, I am more and more convinced that an automatically manufactured
> commit on update with --branch should be the default.

Again, there's nothing to update.  The pull happens in a separate
step.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature

Re: Operations on unborn branch

[Junio C Hamano]

Martin von Zweigbergk  writes:

> simplify a lot of things (maybe I'm biased because of the things I
> have happened to work on?)

Yes.  Do not waste time on it.
--
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: Interesting git-format-patch bug

[Olsen, Alan R]

[Sorry for the top posting. Outlook is crap.]

You are correct. I should only get one copy of the patch on branch A. Branch B 
was modified after the merge and git-format-patch includes the original patch 
from the merge and a duplicate copy with the changed comments.  Note that this 
patch only has different comments. The body of the patch is exactly the same.

How gerrit mangles things is out of my control.  I would prefer that they 
cherry-pick instead of merges. I have to live with the bad choices of both 
gerrit and developers in this case.

I guess I will have to diagram out a better example of what is happening here.

-Original Message-
From: Perry Hutchison [mailto:per...@pluto.rain.com] 
Sent: Monday, November 26, 2012 8:15 PM
To: gits...@pobox.com
Cc: git@vger.kernel.org; Olsen, Alan R
Subject: Re: Interesting git-format-patch bug

Junio C Hamano  wrote:
> "Olsen, Alan R"  writes:
> > I found an interesting bug in git-format-patch.
> >
> > Say you have a branch A.  You create branch B and add a patch to it. 
> > You then merge that patch into branch A. After the merge, some other 
> > process (we will call it 'gerrit') uses annotate and changes the 
> > comment on the patch that exists on branch B.
> >
> > Now someone runs git-format-patch for the last n patches on branch 
> > A.  You should just get the original patch that was merged over to 
> > branch A.  What you get is the patch that was merged to branch A 
> > *and* the patch with the modified commit comment on branch B. 
> > (Double the patches, double the
> > clean-up...)
>
> As you literally have patches that do essentially the same or similar 
> things on two branches that was merged, you cannot expect to export 
> each individual commit into a patch and not have conflicts among them.  
> So I do not think there is no answer than "don't do that".

To me, this seems to miss Alan's point:  only one patch was merged to branch A, 
so git-format-patch applied to branch A should find only one patch.  It can be 
argued either way whether that one-patch report should include the gerrit 
annotations, but surely the application of gerrit on branch B, _after the merge 
to branch A has already been performed_, should not cause an additional patch 
to magically appear on branch A.

  
--
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-gui: textconv not used on unstaged files

[Peter Oberndorfer]

On 2012-11-26 21:54, Junio C Hamano wrote:
> Peter Oberndorfer  writes:
>
>> Does anybody have a idea which git command would output the diff
>> of a untracked file against /dev/null?
> The "--no-index" option is meant as a bolt-on to let you use various
> features of "git diff" that is missing from other people's "diff" in
> a context where git does not know anything about that file.  It
> should be usable even outside a git repository.
>
> $ git diff --no-index /dev/null new-file.txt
>
> I do not know offhand (and didn't bother to check) if textconv
> applies, though.  It does need access to a git repository as it
> reads from the $GIT_DIR/config to learn what to do.
Hi,

this seems to work when adding the --textconv option.
I will try to see if I can modify git gui to use this command
when clicking a unstaged file.

Thanks,
Greetings Peter
--
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: Operations on unborn branch

[Martin von Zweigbergk]

On Tue, Nov 27, 2012 at 12:25 PM, Junio C Hamano  wrote:
> Martin von Zweigbergk  writes:
>
>> simplify a lot of things (maybe I'm biased because of the things I
>> have happened to work on?)
>
> Yes.  Do not waste time on it.

Yes, no way I would waste time on that; I was mostly just curious.

What I might spend time on is to fix cherry-pick.
--
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 3/6] Fix grammar

[Junio C Hamano]

Max Horn  writes:

> Subject: Re: [PATCH 3/6] Fix grammar

Please run "git shortlog -200 --no-merges" from the tip of your
topic branch before sending a series out, and see if you can
immediately identify what area each of your patches affects.

> Signed-off-by: Max Horn 
> ---
>  Documentation/git-remote-helpers.txt | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-remote-helpers.txt 
> b/Documentation/git-remote-helpers.txt
> index db63541..7eb43d7 100644
> --- a/Documentation/git-remote-helpers.txt
> +++ b/Documentation/git-remote-helpers.txt
> @@ -235,9 +235,9 @@ Commands are given by the caller on the helper's standard 
> input, one per line.
>  'capabilities'::
>   Lists the capabilities of the helper, one per line, ending
>   with a blank line. Each capability may be preceded with '*',
> - which marks them mandatory for git version using the remote
> - helper to understand (unknown mandatory capability is fatal
> - error).
> + which marks them mandatory for git versions using the remote
> + helper to understand. Any unknown mandatory capability is a
> + fatal error.
>  
>  'list'::
>   Lists the refs, one per line, in the format " 
--
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

Millisecond precision in timestamps?

[Eric S. Raymond]

Because I do a lot of work on repository conversion tools, I've had
to learn a lot of detail about ontological mismatches between
version-control systems - especially places where you lose metadata
moving between them.

In general, git metadata can carry forward almost all the metadata in
a Subversion repository.  Among the handful of minor exceptions (empty
directories, flow structure, certain kinds of mergeinfos) there is one
that stands out because it seems to be an implementation detail rather
than a consequence of fundamentally different design decisions.

I refer to the one-second precision of git timestamps.  Subversion
stores its commit and property-change timestamps to microsecond
precision; conversion tools have to throw the subsecond part of
this information away.

Has going to timestamps with the full precision of the system clock
been considered and rejected, or am I the first to bring this up?

If I were to write refactoring patches that treated "timestamp" as
an ADT, with a view towards hiding the difference between int and
float timestamps and eventually experimenting with float ones, 
would they be accepted?
-- 
http://www.catb.org/~esr/";>Eric S. Raymond

Every Communist must grasp the truth, 'Political power grows out of
the barrel of a gun.'
-- Mao Tse-tung, 1938, inadvertently endorsing the Second Amendment.
--
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: Python extension commands in git - request for policy change

[Sitaram Chamarty]

On Wed, Nov 28, 2012 at 12:05 AM, Eric S. Raymond  wrote:
> Magnus Bäck :
>> While "constant traffic" probably overstates the issue, these are not
>> theoretical problems. I recall at least three cases in the last year
>> or so where Git has seen breakage with Solaris or Mac OS X because
>> of sed or tr incompatibilities, and I don't even read this list that
>> thoroughly.
>
> This is exactly the sort of of pain experience would lead me to
> expect.
>
> OK, this is where I assume the full Old Fart position (30-year
> old-school Unix guy, author of "The Art of Unix Programming", can
> remember the years before Perl and still has sh idioms in his
> fingertips) and say "Get with the 21st century, people! Or at least
> 1990..."
>
> As a general scripting language shell sucks *really badly* compared to
> anything new-school. Performance, portability, you name it, it's a
> mess.  It's not so much the shell interpreters itself that are the
> portabilty problem, but (as Magnus implicitly points out) all those
> userland dependencies on sed and tr and awk and even variants of
> expr(!) that get dragged in the second you try to get any actual work
> done.

Not always.  There are several situations where a shell script that
makes good use of grep, cut, etc., is definitely much cleaner and more
elegant than anything you can do in a "propah" programming language.

If the price of doing that is sticking to a base set of primitives,
it's a small price to pay, not much different from sticking to python
2.7 or perl 5.8 or whatever.

Shell *is* the universal scripting language, not perl (even though we
all know it is what God himself used to create the world -- see xkcd
224 if you don't believe me!), not python, not Ruby.

-- 
sitaram
--
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: difftool -d symlinks, under what conditions

[Matt McClure]

On Tuesday, November 27, 2012, David Aguilar wrote:
> It seems that there is an edge case here that we are not
> accounting for: unmodified worktree paths, when checked out
> into the temporary directory, can be edited by the tool when
> comparing against older commits.  These edits will be lost.

Yes. That is exactly my desired use case. I want to make edits while
I'm reviewing the diff.

>
> When we can do that then we avoid needing to have a temporary
> directory altogether for any dir-diffs that involve the worktree.

I think the temporary directory is still a good thing. Without it, the
directory diff tool would have no way to distinguish a file added in
the diff from a file that was preexisting and unmodified.

--
Matt McClure
http://www.matthewlmcclure.com
http://www.mapmyfitness.com/profile/matthewlmcclure
--
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 v4 4/4] Hack fix for 'submodule update does not fetch already present commits'

[W. Trevor King]

On Tue, Nov 27, 2012 at 02:01:05PM -0500, W. Trevor King wrote:
> On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote:
> > On Mon, Nov 26, 2012 at 04:00:15PM -0500, W. Trevor King wrote:
> > > Because you need to recurse through submodules for `update --branch`
> > > even if "$subsha1" == "$sha1", I had to amend the conditional
> > > controlling that block.  This broke one of the existing tests, which I
> > > "fixed" in patch 4.  I think a proper fix would involve rewriting
> > > 
> > >   (clear_local_git_env; cd "$sm_path" &&
> > >( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&
> > > test -z "$rev") || git-fetch)) ||
> > >   die "$(eval_gettext "Unable to fetch in submodule path '\$sm_path'")"
> > > 
> > > but I'm not familiar enough with rev-list to want to dig into that
> > > yet.  If feedback for the earlier three patches is positive, I'll work
> > > up a clean fix and resubmit.
> > 
> > You probably need to separate your handling here. The comparison of the
> > currently checked out sha1 and the recorded sha1 is an optimization
> > which skips unnecessary fetching in case the submodules commits are
> > already correct. This code snippet checks whether the to be checked out
> > sha1 is already local and also skips the fetch if it is. We should not
> > break that.
> 
> Agreed.  However, determining if the target $sha1 is local should have
> nothing to do with the current checked out $subsha1.

Erm, I clearly wasn't getting enough sleep heading into yesterday,
because when I drop the hack patch #4, reinstall, and retest, I no
longer get the bad-fetch error.  I'm not quite sure what was going on,
but please pretend I never mentioned it ;).

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature

[PATCH 0/5] "diff --stat" counting fixes

[Junio C Hamano]

It turns out that there are at least two bugs in the diffstat
counting code.  This series comes on top of the earlier 74faaa1 (Fix
"git diff --stat" for interesting - but empty - file changes,
2012-10-17) to fix them.

Junio C Hamano (5):
  test: add failing tests for "diff --stat" to t4049
  diff --stat: status of unmodified pair in diff-q is not zero
  diff --stat: use "file" temporary variable to refer to data->files[i]
  diff --stat: move the "total count" logic to the last loop
  diff --stat: do not count "unmerged" entries

 diff.c | 49 +-
 t/t4049-diff-stat-count.sh | 46 ++-
 2 files changed, 72 insertions(+), 23 deletions(-)

-- 
1.8.0.1.331.g808d2af

--
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/5] test: add failing tests for "diff --stat" to t4049

[Junio C Hamano]

There are a few problems in diff.c around --stat area, partially
caused by the recent 74faaa1 (Fix "git diff --stat" for interesting
- but empty - file changes, 2012-10-17), and largely caused by the
earlier change that introduced when --stat-count was added.

Add a few test pieces to t4049 to expose the issues.

Signed-off-by: Junio C Hamano 
---
 t/t4049-diff-stat-count.sh | 46 +-
 1 file changed, 45 insertions(+), 1 deletion(-)

diff --git a/t/t4049-diff-stat-count.sh b/t/t4049-diff-stat-count.sh
index 7b3ef00..e212b11 100755
--- a/t/t4049-diff-stat-count.sh
+++ b/t/t4049-diff-stat-count.sh
@@ -4,12 +4,17 @@
 test_description='diff --stat-count'
 . ./test-lib.sh
 
-test_expect_success setup '
+test_expect_success 'setup' '
>a &&
>b &&
>c &&
>d &&
git add a b c d &&
+   git commit -m initial
+'
+
+test_expect_success 'limit output to 2 (simple)' '
+   git reset --hard &&
chmod +x c d &&
echo a >a &&
echo b >b &&
@@ -23,4 +28,43 @@ test_expect_success setup '
test_i18ncmp expect actual
 '
 
+test_expect_failure 'binary changes do not count in lines' '
+   git reset --hard &&
+   chmod +x c d &&
+   echo a >a &&
+   echo b >b &&
+   cat "$TEST_DIRECTORY"/test-binary-1.png >d &&
+   cat >expect <<-\EOF
+a | 1 +
+b | 1 +
+...
+4 files changed, 2 insertions(+)
+   EOF
+   git diff --stat --stat-count=2 >actual &&
+   test_i18ncmp expect actual
+'
+
+test_expect_failure 'exclude unmerged entries from total file count' '
+   git reset --hard &&
+   echo a >a &&
+   echo b >b &&
+   git ls-files -s a >x &&
+   git rm -f d &&
+   for stage in 1 2 3
+   do
+   sed -e "s/ 0a/ $stage   d/" x
+   done |
+   git update-index --index-info &&
+   echo d >d &&
+   chmod +x c d &&
+   cat >expect <<-\EOF
+a | 1 +
+b | 1 +
+...
+4 files changed, 3 insertions(+)
+   EOF
+   git diff --stat --stat-count=2 >actual &&
+   test_i18ncmp expect actual
+'
+
 test_done
-- 
1.8.0.1.331.g808d2af

--
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/5] diff --stat: status of unmodified pair in diff-q is not zero

[Junio C Hamano]

It is spelled DIFF_STATUS_UNKNOWN these days, and is different from zero.

Signed-off-by: Junio C Hamano 
---
 diff.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/diff.c b/diff.c
index 95bbad6..ce6baa4 100644
--- a/diff.c
+++ b/diff.c
@@ -2411,7 +2411,7 @@ static void builtin_diffstat(const char *name_a, const 
char *name_b,
}
 
data = diffstat_add(diffstat, name_a, name_b);
-   data->is_interesting = p->status != 0;
+   data->is_interesting = p->status != DIFF_STATUS_UNKNOWN;
 
if (!one || !two) {
data->is_unmerged = 1;
-- 
1.8.0.1.331.g808d2af

--
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/5] diff --stat: use "file" temporary variable to refer to data->files[i]

[Junio C Hamano]

The generated code shouldn't change but it is easier to read.

Signed-off-by: Junio C Hamano 
---
 diff.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/diff.c b/diff.c
index ce6baa4..e4e70e5 100644
--- a/diff.c
+++ b/diff.c
@@ -1470,8 +1470,8 @@ static void show_stats(struct diffstat_t *data, struct 
diff_options *options)
for (i = 0; (i < count) && (i < data->nr); i++) {
struct diffstat_file *file = data->files[i];
uintmax_t change = file->added + file->deleted;
-   if (!data->files[i]->is_interesting &&
-(change == 0)) {
+
+   if (!file->is_interesting && (change == 0)) {
count++; /* not shown == room for one more */
continue;
}
@@ -1586,13 +1586,13 @@ static void show_stats(struct diffstat_t *data, struct 
diff_options *options)
 */
for (i = 0; i < count; i++) {
const char *prefix = "";
-   char *name = data->files[i]->print_name;
-   uintmax_t added = data->files[i]->added;
-   uintmax_t deleted = data->files[i]->deleted;
+   struct diffstat_file *file = data->files[i];
+   char *name = file->print_name;
+   uintmax_t added = file->added;
+   uintmax_t deleted = file->deleted;
int name_len;
 
-   if (!data->files[i]->is_interesting &&
-(added + deleted == 0)) {
+   if (!file->is_interesting && (added + deleted == 0)) {
total_files--;
continue;
}
@@ -1611,7 +1611,7 @@ static void show_stats(struct diffstat_t *data, struct 
diff_options *options)
name = slash;
}
 
-   if (data->files[i]->is_binary) {
+   if (file->is_binary) {
fprintf(options->file, "%s", line_prefix);
show_name(options->file, prefix, name, len);
fprintf(options->file, " %*s", number_width, "Bin");
@@ -1628,7 +1628,7 @@ static void show_stats(struct diffstat_t *data, struct 
diff_options *options)
fprintf(options->file, "\n");
continue;
}
-   else if (data->files[i]->is_unmerged) {
+   else if (file->is_unmerged) {
fprintf(options->file, "%s", line_prefix);
show_name(options->file, prefix, name, len);
fprintf(options->file, " Unmerged\n");
@@ -1668,10 +1668,10 @@ static void show_stats(struct diffstat_t *data, struct 
diff_options *options)
fprintf(options->file, "\n");
}
for (i = count; i < data->nr; i++) {
-   uintmax_t added = data->files[i]->added;
-   uintmax_t deleted = data->files[i]->deleted;
-   if (!data->files[i]->is_interesting &&
-(added + deleted == 0)) {
+   struct diffstat_file *file = data->files[i];
+   uintmax_t added = file->added;
+   uintmax_t deleted = file->deleted;
+   if (!file->is_interesting && (added + deleted == 0)) {
total_files--;
continue;
}
-- 
1.8.0.1.331.g808d2af

--
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 5/5] diff --stat: do not count "unmerged" entries

[Junio C Hamano]

Even though we show a separate *UNMERGED* entry in the patch and
diffstat output (or in the --raw format, for that matter) in
addition to and separately from the diff against the specified stage
(defaulting to #2) for unmerged paths, they should not be counted in
the total number of files affected---that would lead to counting the
same path twice.

The separation done by the previous step makes this fix simple and
straightforward.  Among the filepairs in diff_queue, paths that
weren't modified, and the extra "unmerged" entries do not count as
total number of files.

Signed-off-by: Junio C Hamano 
---
 diff.c | 6 --
 t/t4049-diff-stat-count.sh | 2 +-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/diff.c b/diff.c
index 4105260..26ede82 100644
--- a/diff.c
+++ b/diff.c
@@ -1669,12 +1669,14 @@ static void show_stats(struct diffstat_t *data, struct 
diff_options *options)
struct diffstat_file *file = data->files[i];
uintmax_t added = file->added;
uintmax_t deleted = file->deleted;
-   if (!file->is_interesting && (added + deleted == 0)) {
+
+   if (file->is_unmerged ||
+   (!file->is_interesting && (added + deleted == 0))) {
total_files--;
continue;
}
 
-   if (!file->is_binary && !file->is_unmerged) {
+   if (!file->is_binary) {
adds += added;
dels += deleted;
}
diff --git a/t/t4049-diff-stat-count.sh b/t/t4049-diff-stat-count.sh
index 70ee073..37f50cd 100755
--- a/t/t4049-diff-stat-count.sh
+++ b/t/t4049-diff-stat-count.sh
@@ -44,7 +44,7 @@ test_expect_success 'binary changes do not count in lines' '
test_i18ncmp expect actual
 '
 
-test_expect_failure 'exclude unmerged entries from total file count' '
+test_expect_success 'exclude unmerged entries from total file count' '
git reset --hard &&
echo a >a &&
echo b >b &&
-- 
1.8.0.1.331.g808d2af

--
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 4/5] diff --stat: move the "total count" logic to the last loop

[Junio C Hamano]

The diffstat generation logic, with --stat-count limit, is
implemented as three loops.

 - The first counts the width necessary to show stats up to
   specified number of entries, and notes up to how many entries in
   the data we need to iterate to show the graph;

 - The second iterates that many times to draw the graph, adjusts
   the number of "total modified files", and counts the total
   added/deleted lines for the part that was shown in the graph;

 - The third iterates over the remainder and only does the part to
   count "total added/deleted lines" and to adjust "total modified
   files" without drawing anything.

Move the logic to count added/deleted lines and modified files from
the second loop to the third loop.

This incidentally fixes a bug.  The third loop was not filtering
binary changes (counted in bytes) from the total added/deleted as it
should.  The second loop implemented this correctly, so if a binary
change appeared earlier than the --stat-count cutoff, the code
counted number of added/deleted lines correctly, but if it appeared
beyond the cutoff, the number of lines would have mixed with the
byte count in the buggy third loop.

Signed-off-by: Junio C Hamano 
---
 diff.c | 21 -
 t/t4049-diff-stat-count.sh |  2 +-
 2 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/diff.c b/diff.c
index e4e70e5..4105260 100644
--- a/diff.c
+++ b/diff.c
@@ -1498,7 +1498,7 @@ static void show_stats(struct diffstat_t *data, struct 
diff_options *options)
if (max_change < change)
max_change = change;
}
-   count = i; /* min(count, data->nr) */
+   count = i; /* where we can stop scanning in data->files[] */
 
/*
 * We have width = stat_width or term_columns() columns total.
@@ -1592,10 +1592,9 @@ static void show_stats(struct diffstat_t *data, struct 
diff_options *options)
uintmax_t deleted = file->deleted;
int name_len;
 
-   if (!file->is_interesting && (added + deleted == 0)) {
-   total_files--;
+   if (!file->is_interesting && (added + deleted == 0))
continue;
-   }
+
/*
 * "scale" the filename
 */
@@ -1640,8 +1639,6 @@ static void show_stats(struct diffstat_t *data, struct 
diff_options *options)
 */
add = added;
del = deleted;
-   adds += add;
-   dels += del;
 
if (graph_width <= max_change) {
int total = add + del;
@@ -1667,7 +1664,8 @@ static void show_stats(struct diffstat_t *data, struct 
diff_options *options)
show_graph(options->file, '-', del, del_c, reset);
fprintf(options->file, "\n");
}
-   for (i = count; i < data->nr; i++) {
+
+   for (i = 0; i < data->nr; i++) {
struct diffstat_file *file = data->files[i];
uintmax_t added = file->added;
uintmax_t deleted = file->deleted;
@@ -1675,8 +1673,13 @@ static void show_stats(struct diffstat_t *data, struct 
diff_options *options)
total_files--;
continue;
}
-   adds += added;
-   dels += deleted;
+
+   if (!file->is_binary && !file->is_unmerged) {
+   adds += added;
+   dels += deleted;
+   }
+   if (i < count)
+   continue;
if (!extra_shown)
fprintf(options->file, "%s ...\n", line_prefix);
extra_shown = 1;
diff --git a/t/t4049-diff-stat-count.sh b/t/t4049-diff-stat-count.sh
index e212b11..70ee073 100755
--- a/t/t4049-diff-stat-count.sh
+++ b/t/t4049-diff-stat-count.sh
@@ -28,7 +28,7 @@ test_expect_success 'limit output to 2 (simple)' '
test_i18ncmp expect actual
 '
 
-test_expect_failure 'binary changes do not count in lines' '
+test_expect_success 'binary changes do not count in lines' '
git reset --hard &&
chmod +x c d &&
echo a >a &&
-- 
1.8.0.1.331.g808d2af

--
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 3/6] Fix grammar

[Max Horn]

On 27.11.2012, at 21:39, Junio C Hamano wrote:

> Max Horn  writes:
> 
>> Subject: Re: [PATCH 3/6] Fix grammar
> 
> Please run "git shortlog -200 --no-merges" from the tip of your
> topic branch before sending a series out, and see if you can
> immediately identify what area each of your patches affects.

First off: I apologize for the inconvenience my stumbling causes :-(, and I'll 
try to learn and do better next time I send this or another series.

In this particular case, I am not 100% sure if I understood you correctly, i.e. 
what exactly you are trying to tell me. Is it (in a nutshell) that the subject 
lines of my commits suck, as they don't identify which area of code they touch? 
At least that's the thing I notice when looking at that shortlog... Bad, of 
course...

If this is indeed it, would a commit message like

   git-remote-helper.txt: minor grammar fix

be OK? If this is indeed it, I'll be happy to reroll and resubmit the series 
accordingly. If I am mistaken and something else / more is wrong, please be so 
kind and let me know, too.


Sorry once more and thank you very much for your feedback,
Max

> 
>> Signed-off-by: Max Horn 
>> ---
>> Documentation/git-remote-helpers.txt | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>> 
>> diff --git a/Documentation/git-remote-helpers.txt 
>> b/Documentation/git-remote-helpers.txt
>> index db63541..7eb43d7 100644
>> --- a/Documentation/git-remote-helpers.txt
>> +++ b/Documentation/git-remote-helpers.txt
>> @@ -235,9 +235,9 @@ Commands are given by the caller on the helper's 
>> standard input, one per line.
>> 'capabilities'::
>>  Lists the capabilities of the helper, one per line, ending
>>  with a blank line. Each capability may be preceded with '*',
>> -which marks them mandatory for git version using the remote
>> -helper to understand (unknown mandatory capability is fatal
>> -error).
>> +which marks them mandatory for git versions using the remote
>> +helper to understand. Any unknown mandatory capability is a
>> +fatal error.
>> 
>> 'list'::
>>  Lists the refs, one per line, in the format " 
> --
> 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
> 

--
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: Millisecond precision in timestamps?

[Shawn Pearce]

On Tue, Nov 27, 2012 at 12:48 PM, Eric S. Raymond  wrote:
> Because I do a lot of work on repository conversion tools, I've had
> to learn a lot of detail about ontological mismatches between
> version-control systems - especially places where you lose metadata
> moving between them.
>
> In general, git metadata can carry forward almost all the metadata in
> a Subversion repository.  Among the handful of minor exceptions (empty
> directories, flow structure, certain kinds of mergeinfos) there is one
> that stands out because it seems to be an implementation detail rather
> than a consequence of fundamentally different design decisions.
>
> I refer to the one-second precision of git timestamps.  Subversion
> stores its commit and property-change timestamps to microsecond
> precision; conversion tools have to throw the subsecond part of
> this information away.
>
> Has going to timestamps with the full precision of the system clock
> been considered and rejected, or am I the first to bring this up?
>
> If I were to write refactoring patches that treated "timestamp" as
> an ADT, with a view towards hiding the difference between int and
> float timestamps and eventually experimenting with float ones,
> would they be accepted?

JGit would fortunately ignore a floating point timestamp specification
if given in a commit, but I don't know about other Git
implementations... like say 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: Millisecond precision in timestamps?

[Pyeron, Jason J CTR (US)]

> -Original Message-
> From: Eric S. Raymond
> Sent: Tuesday, November 27, 2012 3:48 PM
> 
> Because I do a lot of work on repository conversion tools, I've had
> to learn a lot of detail about ontological mismatches between
> version-control systems - especially places where you lose metadata
> moving between them.
> 
> In general, git metadata can carry forward almost all the metadata in
> a Subversion repository.  Among the handful of minor exceptions (empty
> directories, flow structure, certain kinds of mergeinfos) there is one
> that stands out because it seems to be an implementation detail rather
> than a consequence of fundamentally different design decisions.
> 
> I refer to the one-second precision of git timestamps.  Subversion
> stores its commit and property-change timestamps to microsecond
> precision; conversion tools have to throw the subsecond part of
> this information away.
> 
> Has going to timestamps with the full precision of the system clock
> been considered and rejected, or am I the first to bring this up?
> 
> If I were to write refactoring patches that treated "timestamp" as
> an ADT, with a view towards hiding the difference between int and
> float timestamps and eventually experimenting with float ones,

Do you really mean floating point numbers with approximate imprecise values?




smime.p7s
Description: S/MIME cryptographic signature

Re: Python extension commands in git - request for policy change

[Guillaume DE BURE]

Le mardi 27 novembre 2012 02:51:04 David Aguilar a écrit :
> On Tue, Nov 27, 2012 at 1:17 AM, Sitaram Chamarty  
wrote:
> > On Tue, Nov 27, 2012 at 1:24 PM, David Aguilar  wrote:
> >> *cough* git-cola *cough*
> >> 
> >> it runs everywhere.  Yes, windows too. It's written in python.
> >> It's been actively maintained since 2007.
> >> 
> >> It's "modern" and has features that don't exist anywhere else.
> >> 
> >> It even has tests.  It even comes with a building full of willing
> >> guinea-pigs^Wtesters that let me know right away when
> >> anything goes wrong.
> >> 
> >> It uses Qt but that's really the whole point of Qt -> cross-platform.
> >> (not sure how that wiki page ended up saying Gnome/GTK?)
> >> 
> >> The DAG aka git-dag (in its master branch, about to be released)
> >> is nicer looking then gitk IMO.  gitk still has some features
> >> that are better too--there's no silver bullet, but the delta
> >> is pretty small.
> > 
> > Gitk does a lot of things that people don't realise, since they're not
> > really documented and you have to scrounge around on the UI.  The
> > thing is, it's just about the most awesome tool for code archeology I
> > have seen.
> > 
> > I realise (from looking at the doc page) that git-cola helps you do
> > all sorts of things, but those are all things I am happier doing at
> > the command line.
> 
> Ditto.  There's actually a few small things I use it for,
> mainly for teasing apart commits.  These days you can use git-gui
> for that, but in the old days it was the only way to interactively
> select individual lines and stage/unstage/revert them, etc.
> I don't think we can line-by-line revert in git-gui yet, though.
> 
> Some other small things that I use: ctrl-g, type something
> for grep, hit enter twice and I'm in my editor on that
> (or any other selected) line.  'spacebar' does xdg-open,
> and 'enter' launches the editor in the status widget;
> small things.  I, too, do most stuff on the command line.
> 
> The grep thing is a good example.  You have tons of output,
> you see the one line that you care about, and you want to jump
> there.  Clicking on that line and hitting enter is the minimal
> effort to do that.  You don't have to click because we also
> have keyboard navigation.  I have a feeling that there's probably
> something I'm missing, though.. another way of working (emacs?)
> that would render all of this custom GUI stuff pointless.
> 
> What I learned about users:
> 
> The commit editor is the #1 thing that got my coworkers finally
> writing better commit messages. It forces the subject/description
> separation and shows yellow, red when the subject gets too long.
> It also auto-wraps.  IMO it makes sense for git-gui to do
> the same these days.
> 
> > Gitk does precisely those things which *require* a GUI, where the
> > amount of information presented overwhelms a text interface.  The
> > display is concisely designed to give you the maximum information at a
> > minimum space use.  For example, a little black square when a commit
> > has a note attached.  Even hovering over the arrow-heads, on complex
> > trees where the line gets broken, does something meaningful.
> > 
> > if I had to pin it down, the feature I use most often is "Show origin
> > of this line".  Other features I use often are
> > 
> >   - review a commit file by file (f and b keys, also spacebar and 'd')
> >   - search by SHA1 (4 digits appear to be enough, regardless of how
> > 
> > big your repo is),
> > 
> >   - search for commits changing path/dir (while still showing all the
> > 
> > commits; i.e., this is not 'git-dag -- README.txt' but within gitk you
> > search up and down for commits touching README.txt
> > 
> >   - and navigating the commit tree looking for stuff
> > 
> > http://sitaramc.github.com/1-basic-usage/gitk.html is my attempt to
> > document some of the stuff I have found and use.
> 
> Wow, this is awesome.
> 
> > One final point: the DAG on the right wastes enormous amounts of
> > space.  Purely subjectively, it is almost jarring on the senses.  (If
> > you reduce it, it becomes unreadable).
> > 
> > With all due respect, git-cola/dag isn't anywhere near what gitk does,
> > at least for people who are not afraid of the command line and only
> > need the GUI to visualise a truly complex tree.
> 
> This is really great feedback.
> cc:ing Guillaume since he had similar ideas.
> 
> thx,

Thanks David for cc:ing me. I'm sorry I was quite below the radar lately, had 
too much work to get back on the dag. What I would really like for the dag is 
to become as useful as the treeview in git extensions 
(http://code.google.com/p/gitextensions/), where it is the central place for 
checkout, merge, cherry picks... 

My only complaint with git extensions is that it is poorly integrated on my 
linux desktop, due to framework choice (let's not start a flame war here, it's 
not the point). On the other hand, git-cola is quite easy to hack on thanks to 
its python roots, well integrat

Re: [PATCH 3/6] Fix grammar

[Junio C Hamano]

Max Horn  writes:

> If this is indeed it, would a commit message like
>
>git-remote-helper.txt: minor grammar fix

Perfect.  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: Millisecond precision in timestamps?

[Junio C Hamano]

Shawn Pearce  writes:

> JGit would fortunately ignore a floating point timestamp specification
> if given in a commit, but I don't know about other Git
> implementations... like say git. :-)

fsck_ident() in fsck.c rejects anything but " [1-9][0-9]* " after
the author and committer ident (i.e. the timestamp has to be
integral number of seconds since the epoch, not before it, nor
with fractional seconds).

--
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 6/5] diff --shortstat: do not count "unmerged" entries

[Junio C Hamano]

Fix the same issue as the previous one for "git diff --stat";
unmerged entries was doubly-counted.

Signed-off-by: Junio C Hamano 
---
 diff.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/diff.c b/diff.c
index 26ede82..374b235 100644
--- a/diff.c
+++ b/diff.c
@@ -1701,9 +1701,8 @@ static void show_shortstats(struct diffstat_t *data, 
struct diff_options *option
int added = data->files[i]->added;
int deleted= data->files[i]->deleted;
 
-   if (data->files[i]->is_unmerged)
-   continue;
-   if (!data->files[i]->is_interesting && (added + deleted == 0)) {
+   if (data->files[i]->is_unmerged ||
+   (!data->files[i]->is_interesting && (added + deleted == 
0))) {
total_files--;
} else if (!data->files[i]->is_binary) { /* don't count bytes */
adds += added;
-- 
1.8.0.1.337.gd2c5e06

--
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] git-remote-helpers.txt: document missing capabilities

[Max Horn]

Specifically, document the 'export' and '(im|ex)port-marks'
capabilities as well as the export command, which were
undocumented (but in active use).

Signed-off-by: Max Horn 
---
 Documentation/git-remote-helpers.txt | 45 +---
 1 file changed, 42 insertions(+), 3 deletions(-)

diff --git a/Documentation/git-remote-helpers.txt 
b/Documentation/git-remote-helpers.txt
index 9a7e583..db63541 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -106,6 +106,10 @@ to the `capabilities` command (see COMMANDS, below).
For listing remote refs and fetching the associated history to
the local object store.
 
+'export'::
+   For listing remote refs and pushing specified objects from a
+   fast-import stream to remote refs.
+
 'import'::
For listing remote refs and fetching the associated history as
a fast-import stream.
@@ -143,6 +147,16 @@ there is an implied `refspec *:*`.
This is to prevent mixing commands and fast-import responses on the
helper's stdin.
 
+'export-marks' ::
+   This modifies the 'export' capability, instructing git to dump the
+   internal marks table to  when complete. For details,
+   read up on '--export-marks=' in linkgit:git-fast-export[1].
+
+'import-marks' ::
+   This modifies the 'export' capability, instructing git to load the
+   marks specified in  before processing any input. For details,
+   read up on '--import-marks=' in linkgit:git-fast-export[1].
+
 Capabilities for Pushing
 
 'connect'::
@@ -158,9 +172,18 @@ Supported commands: 'connect'.
 +
 Supported commands: 'list for-push', 'push'.
 
-If a helper advertises both 'connect' and 'push', git will use
-'connect' if possible and fall back to 'push' if the helper requests
-so when connecting (see the 'connect' command under COMMANDS).
+'export'::
+   Can discover remote refs and push specified objects from a
+   fast-import stream to remote refs.
++
+Supported commands: 'list for-push', 'export'.
+
+If a helper advertises 'connect', git will use it if possible and
+fall back to another capability if the helper requests so when
+connecting (see the 'connect' command under COMMANDS).
+When choosing between 'push' and 'export', git prefers 'push'.
+Other frontends may have some other order of preference.
+
 
 Capabilities for Fetching
 ~
@@ -307,6 +330,22 @@ stdin.
 +
 Supported if the helper has the 'import' capability.
 
+'export'::
+   Instructs the remote helper that any subsequent input is
+   part of a fast-import stream (generated by 'git fast-export')
+   containing objects which should be pushed to the remote.
++
+Especially useful for interoperability with a foreign versioning
+system.
++
+The 'export-marks' and 'import-marks' capabilities, if specified,
+affect this command in so far as they are passed on to 'git
+fast-export', which then will load/store a table of marks for
+local objects. This can be used to implement for incremental
+operations.
++
+Supported if the helper has the 'export' capability.
+
 'connect' ::
Connects to given service. Standard input and standard output
of helper are connected to specified service (git prefix is
-- 
1.8.0.393.gcc9701d

--
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] git-remote-helpers.txt: document invocation before input format

[Max Horn]

In the distant past, the order things were documented was
'Invocation', 'Commands', 'Capabilities', ...

Then it was decided that before giving a list of Commands, there
should be an overall description of the 'Input format', which was
a wise decision. However, this description was put as the very
first thing, with the rationale that any implementor would want
to know that first.

However, it seems an implementor would actually first need to
know how the remote helper will be invoked, so moving
'Invocation' to the front again seems logical. Moreover, we now
don't switch from discussing the input format to the invocation
style and then back to input related stuff.

Signed-off-by: Max Horn 
---
 Documentation/git-remote-helpers.txt | 62 ++--
 1 file changed, 31 insertions(+), 31 deletions(-)

diff --git a/Documentation/git-remote-helpers.txt 
b/Documentation/git-remote-helpers.txt
index 5ce4cda..9a7e583 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -35,6 +35,37 @@ transport protocols, such as 'git-remote-http', 
'git-remote-https',
 'git-remote-ftp' and 'git-remote-ftps'. They implement the capabilities
 'fetch', 'option', and 'push'.
 
+INVOCATION
+--
+
+Remote helper programs are invoked with one or (optionally) two
+arguments. The first argument specifies a remote repository as in git;
+it is either the name of a configured remote or a URL. The second
+argument specifies a URL; it is usually of the form
+'://', but any arbitrary string is possible.
+The 'GIT_DIR' environment variable is set up for the remote helper
+and can be used to determine where to store additional data or from
+which directory to invoke auxiliary git commands.
+
+When git encounters a URL of the form '://', where
+'' is a protocol that it cannot handle natively, it
+automatically invokes 'git remote-' with the full URL as
+the second argument. If such a URL is encountered directly on the
+command line, the first argument is the same as the second, and if it
+is encountered in a configured remote, the first argument is the name
+of that remote.
+
+A URL of the form '::' explicitly instructs git to
+invoke 'git remote-' with '' as the second
+argument. If such a URL is encountered directly on the command line,
+the first argument is '', and if it is encountered in a
+configured remote, the first argument is the name of that remote.
+
+Additionally, when a configured remote has 'remote..vcs' set to
+'', git explicitly invokes 'git remote-' with
+'' as the first argument. If set, the second argument is
+'remote..url'; otherwise, the second argument is omitted.
+
 INPUT FORMAT
 
 
@@ -173,37 +204,6 @@ advertised with this capability must cover all refs 
reported by
 the list command.  If no 'refspec' capability is advertised,
 there is an implied `refspec *:*`.
 
-INVOCATION
---
-
-Remote helper programs are invoked with one or (optionally) two
-arguments. The first argument specifies a remote repository as in git;
-it is either the name of a configured remote or a URL. The second
-argument specifies a URL; it is usually of the form
-'://', but any arbitrary string is possible.
-The 'GIT_DIR' environment variable is set up for the remote helper
-and can be used to determine where to store additional data or from
-which directory to invoke auxiliary git commands.
-
-When git encounters a URL of the form '://', where
-'' is a protocol that it cannot handle natively, it
-automatically invokes 'git remote-' with the full URL as
-the second argument. If such a URL is encountered directly on the
-command line, the first argument is the same as the second, and if it
-is encountered in a configured remote, the first argument is the name
-of that remote.
-
-A URL of the form '::' explicitly instructs git to
-invoke 'git remote-' with '' as the second
-argument. If such a URL is encountered directly on the command line,
-the first argument is '', and if it is encountered in a
-configured remote, the first argument is the name of that remote.
-
-Additionally, when a configured remote has 'remote..vcs' set to
-'', git explicitly invokes 'git remote-' with
-'' as the first argument. If set, the second argument is
-'remote..url'; otherwise, the second argument is omitted.
-
 COMMANDS
 
 
-- 
1.8.0.393.gcc9701d

--
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] git-remote-helpers.txt: clarify options & ref list attributes

[Max Horn]

The documentation was misleading in that it gave the impression that
'for-push' could be used as a ref attribute in the output of the
'list' command. That is wrong.

Also, explicitly point out the connection between the commands
'list' and 'options' on the one hand, and the sections
'REF LIST ATTRIBUTES' and 'OPTIONS' on the other hand.

Signed-off-by: Max Horn 
---
 Documentation/git-remote-helpers.txt | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/Documentation/git-remote-helpers.txt 
b/Documentation/git-remote-helpers.txt
index 023dcca..e1df01d 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -227,6 +227,8 @@ Support for this command is mandatory.
the name; unrecognized attributes are ignored. The list ends
with a blank line.
 +
+See REF LIST ATTRIBUTES for a list of currently defined options.
++
 Supported if the helper has the "fetch" or "import" capability.
 
 'list for-push'::
@@ -248,6 +250,8 @@ Supported if the helper has the "push" or "export" 
capability.
for it).  Options should be set before other commands,
and may influence the behavior of those commands.
 +
+See OPTIONS for a list of currently defined options.
++
 Supported if the helper has the "option" capability.
 
 'fetch'  ::
@@ -256,7 +260,7 @@ Supported if the helper has the "option" capability.
per line, terminated with a blank line.
Outputs a single blank line when all fetch commands in the
same batch are complete. Only objects which were reported
-   in the ref list with a sha1 may be fetched this way.
+   in the output of 'list' with a sha1 may be fetched this way.
 +
 Optionally may output a 'lock ' line indicating a file under
 GIT_DIR/objects/pack which is keeping a pack until refs can be
@@ -360,10 +364,9 @@ capabilities reported by the helper.
 REF LIST ATTRIBUTES
 ---
 
-'for-push'::
-   The caller wants to use the ref list to prepare push
-   commands.  A helper might chose to acquire the ref list by
-   opening a different type of connection to the destination.
+The 'list' command produces a list of refs in which each ref
+may be followed by a list of attributes. The following ref list
+attributes are defined.
 
 'unchanged'::
This ref is unchanged since the last import or fetch, although
@@ -371,6 +374,10 @@ REF LIST ATTRIBUTES
 
 OPTIONS
 ---
+
+The following options are defined and (under suitable circumstances)
+set by git if the remote helper has the 'option' capability.
+
 'option verbosity' ::
Changes the verbosity of messages displayed by the helper.
A value of 0 for  means that processes operate
-- 
1.8.0.393.gcc9701d

--
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 6/6] git-remote-helpers.txt: clarify ref list attributes, link to subsections

[Max Horn]

The documentation was misleading in that it gave the impression that
'for-push' could be used as a ref attribute in the output of the
'list' command. That is wrong.

Also, explicitly point out the connection between the commands
'list' and 'options' on the one hand, and the sections
'REF LIST ATTRIBUTES' and 'OPTIONS' on the other hand.

Signed-off-by: Max Horn 
---
 Documentation/git-remote-helpers.txt | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/Documentation/git-remote-helpers.txt 
b/Documentation/git-remote-helpers.txt
index 023dcca..e1df01d 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -227,6 +227,8 @@ Support for this command is mandatory.
the name; unrecognized attributes are ignored. The list ends
with a blank line.
 +
+See REF LIST ATTRIBUTES for a list of currently defined options.
++
 Supported if the helper has the "fetch" or "import" capability.
 
 'list for-push'::
@@ -248,6 +250,8 @@ Supported if the helper has the "push" or "export" 
capability.
for it).  Options should be set before other commands,
and may influence the behavior of those commands.
 +
+See OPTIONS for a list of currently defined options.
++
 Supported if the helper has the "option" capability.
 
 'fetch'  ::
@@ -256,7 +260,7 @@ Supported if the helper has the "option" capability.
per line, terminated with a blank line.
Outputs a single blank line when all fetch commands in the
same batch are complete. Only objects which were reported
-   in the ref list with a sha1 may be fetched this way.
+   in the output of 'list' with a sha1 may be fetched this way.
 +
 Optionally may output a 'lock ' line indicating a file under
 GIT_DIR/objects/pack which is keeping a pack until refs can be
@@ -360,10 +364,9 @@ capabilities reported by the helper.
 REF LIST ATTRIBUTES
 ---
 
-'for-push'::
-   The caller wants to use the ref list to prepare push
-   commands.  A helper might chose to acquire the ref list by
-   opening a different type of connection to the destination.
+The 'list' command produces a list of refs in which each ref
+may be followed by a list of attributes. The following ref list
+attributes are defined.
 
 'unchanged'::
This ref is unchanged since the last import or fetch, although
@@ -371,6 +374,10 @@ REF LIST ATTRIBUTES
 
 OPTIONS
 ---
+
+The following options are defined and (under suitable circumstances)
+set by git if the remote helper has the 'option' capability.
+
 'option verbosity' ::
Changes the verbosity of messages displayed by the helper.
A value of 0 for  means that processes operate
-- 
1.8.0.393.gcc9701d

--
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] git-remote-helpers.txt: rearrange description of capabilities

[Max Horn]

This also remove some duplication in the descriptions
(e.g. refspec was explained twice with similar level of detail).

Signed-off-by: Max Horn 
---
 Documentation/git-remote-helpers.txt | 134 +++
 1 file changed, 56 insertions(+), 78 deletions(-)

diff --git a/Documentation/git-remote-helpers.txt 
b/Documentation/git-remote-helpers.txt
index 7eb43d7..7ac1461 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -88,81 +88,17 @@ Each remote helper is expected to support only a subset of 
commands.
 The operations a helper supports are declared to git in the response
 to the `capabilities` command (see COMMANDS, below).
 
-'option'::
-   For specifying settings like `verbosity` (how much output to
-   write to stderr) and `depth` (how much history is wanted in the
-   case of a shallow clone) that affect how other commands are
-   carried out.
-
-'connect'::
-   For fetching and pushing using git's native packfile protocol
-   that requires a bidirectional, full-duplex connection.
-
-'push'::
-   For listing remote refs and pushing specified objects from the
-   local object store to remote refs.
-
-'fetch'::
-   For listing remote refs and fetching the associated history to
-   the local object store.
-
-'export'::
-   For listing remote refs and pushing specified objects from a
-   fast-import stream to remote refs.
-
-'import'::
-   For listing remote refs and fetching the associated history as
-   a fast-import stream.
-
-'refspec' ::
-   This modifies the 'import' capability, allowing the produced
-   fast-import stream to modify refs in a private namespace
-   instead of writing to refs/heads or refs/remotes directly.
-   It is recommended that all importers providing the 'import'
-   capability use this.
-+
-A helper advertising the capability
-`refspec refs/heads/*:refs/svn/origin/branches/*`
-is saying that, when it is asked to `import refs/heads/topic`, the
-stream it outputs will update the `refs/svn/origin/branches/topic`
-ref.
-+
-This capability can be advertised multiple times.  The first
-applicable refspec takes precedence.  The left-hand of refspecs
-advertised with this capability must cover all refs reported by
-the list command.  If no 'refspec' capability is advertised,
-there is an implied `refspec *:*`.
-
-'bidi-import'::
-   The fast-import commands 'cat-blob' and 'ls' can be used by 
remote-helpers
-   to retrieve information about blobs and trees that already exist in
-   fast-import's memory. This requires a channel from fast-import to the
-   remote-helper.
-   If it is advertised in addition to "import", git establishes a pipe from
-   fast-import to the remote-helper's stdin.
-   It follows that git and fast-import are both connected to the
-   remote-helper's stdin. Because git can send multiple commands to
-   the remote-helper it is required that helpers that use 'bidi-import'
-   buffer all 'import' commands of a batch before sending data to 
fast-import.
-   This is to prevent mixing commands and fast-import responses on the
-   helper's stdin.
-
-'export-marks' ::
-   This modifies the 'export' capability, instructing git to dump the
-   internal marks table to  when complete. For details,
-   read up on '--export-marks=' in linkgit:git-fast-export[1].
-
-'import-marks' ::
-   This modifies the 'export' capability, instructing git to load the
-   marks specified in  before processing any input. For details,
-   read up on '--import-marks=' in linkgit:git-fast-export[1].
+In the following, we list all defined capabilities and for
+each we list which commands a helper with that capability
+must provide.
 
 Capabilities for Pushing
-
+
 'connect'::
Can attempt to connect to 'git receive-pack' (for pushing),
-   'git upload-pack', etc for communication using the
-   packfile protocol.
+   'git upload-pack', etc for communication using
+   git's native packfile protocol. This
+   requires a bidirectional, full-duplex connection.
 +
 Supported commands: 'connect'.
 
@@ -186,11 +122,12 @@ Other frontends may have some other order of preference.
 
 
 Capabilities for Fetching
-~
+^
 'connect'::
Can try to connect to 'git upload-pack' (for fetching),
'git receive-pack', etc for communication using the
-   packfile protocol.
+   git's native packfile protocol. This
+   requires a bidirectional, full-duplex connection.
 +
 Supported commands: 'connect'.
 
@@ -212,14 +149,27 @@ connecting (see the 'connect' command under COMMANDS).
 When choosing between 'fetch' and 'import', git prefers 'fetch'.
 Other frontends may have some other order of preference.
 
+Miscellaneous capabilities
+^^
+
+'o

[PATCH v2 3/6] git-remote-helpers.txt: minor grammar fix

[Max Horn]

Signed-off-by: Max Horn 
---
 Documentation/git-remote-helpers.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/git-remote-helpers.txt 
b/Documentation/git-remote-helpers.txt
index db63541..7eb43d7 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -235,9 +235,9 @@ Commands are given by the caller on the helper's standard 
input, one per line.
 'capabilities'::
Lists the capabilities of the helper, one per line, ending
with a blank line. Each capability may be preceded with '*',
-   which marks them mandatory for git version using the remote
-   helper to understand (unknown mandatory capability is fatal
-   error).
+   which marks them mandatory for git versions using the remote
+   helper to understand. Any unknown mandatory capability is a
+   fatal error.
 
 'list'::
Lists the refs, one per line, in the format " 
-- 
1.8.0.393.gcc9701d

--
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] git-remote-helpers.txt: clarify command <-> capability correspondences

[Max Horn]

In particular, document 'list for-push' separately from 'list', as
the former needs only be supported for the push/export
capabilities, and the latter only for fetch/import. Indeed, a
hypothetically 'push-only' helper would only need to support the
former, not the latter.

Signed-off-by: Max Horn 
---
 Documentation/git-remote-helpers.txt | 21 -
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/Documentation/git-remote-helpers.txt 
b/Documentation/git-remote-helpers.txt
index 7ac1461..023dcca 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -216,6 +216,8 @@ Commands are given by the caller on the helper's standard 
input, one per line.
which marks them mandatory for git versions using the remote
helper to understand. Any unknown mandatory capability is a
fatal error.
++
+Support for this command is mandatory.
 
 'list'::
Lists the refs, one per line, in the format " 
@@ -225,9 +227,18 @@ Commands are given by the caller on the helper's standard 
input, one per line.
the name; unrecognized attributes are ignored. The list ends
with a blank line.
 +
-If 'push' is supported this may be called as 'list for-push'
-to obtain the current refs prior to sending one or more 'push'
-commands to the helper.
+Supported if the helper has the "fetch" or "import" capability.
+
+'list for-push'::
+   Similar to 'list', except that it is used if and only if
+   the caller wants to the resulting ref list to prepare
+   push commands.
+   A helper supporting both push and fetch can use this
+   to distinguish for which operation the output of 'list'
+   is going to be used, possibly reducing the amount
+   of work that needs to be performed.
++
+Supported if the helper has the "push" or "export" capability.
 
 'option'  ::
Sets the transport helper option  to .  Outputs a
@@ -306,7 +317,7 @@ sequence has to be buffered before starting to send data to 
fast-import
 to prevent mixing of commands and fast-import responses on the helper's
 stdin.
 +
-Supported if the helper has the 'import' capability.
+Supported if the helper has the "import" capability.
 
 'export'::
Instructs the remote helper that any subsequent input is
@@ -322,7 +333,7 @@ fast-export', which then will load/store a table of marks 
for
 local objects. This can be used to implement for incremental
 operations.
 +
-Supported if the helper has the 'export' capability.
+Supported if the helper has the "export" capability.
 
 'connect' ::
Connects to given service. Standard input and standard output
-- 
1.8.0.393.gcc9701d

--
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] Improve remote helper documentation

[Max Horn]

Various remote helper capabilities and commands were not
documented, in particular 'export', or documented in a misleading
way (e.g. 'for-push' was listed as a ref attribute understood by
git, which is not the case). This patch series changes that, and
also address some other things in the remote helper documentation
that I found jarring when reading through it.

Note that the description of export and (im|ex)port-marks probably can be
improved, and I hope that somebody who knows more about them
than me and/or is better at writing documentation will do just that.
But I felt it was better to provide something than to do nothing
and only complain, as I did previously on this subject ;-).

Max Horn (6):
  git-remote-helpers.txt: document invocation before input format
  git-remote-helpers.txt: document missing capabilities
  git-remote-helpers.txt: minor grammar fix
  git-remote-helpers.txt: rearrange description of capabilities
  git-remote-helpers.txt: clarify command <-> capability correspondences
  git-remote-helpers.txt: clarify options & ref list attributes

 Documentation/git-remote-helpers.txt | 245 ---
 1 file changed, 140 insertions(+), 105 deletions(-)

-- 
1.8.0.393.gcc9701d

--
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: Millisecond precision in timestamps?

[Eric S. Raymond]

Junio C Hamano :
> fsck_ident() in fsck.c rejects anything but " [1-9][0-9]* " after
> the author and committer ident (i.e. the timestamp has to be
> integral number of seconds since the epoch, not before it, nor
> with fractional seconds).

Is this architecturally significant?  It sounds like another
implementation detail.
-- 
http://www.catb.org/~esr/";>Eric S. Raymond
--
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 6/6] git-remote-helpers.txt: clarify ref list attributes, link to subsections

[Max Horn]

Ouch. This one should *not* have been sent (the "[PATCH v2 6/6]" one is the 
correct one). Very sorry :(. I'll triple check next time.
Max

On 28.11.2012, at 00:03, Max Horn wrote:

> The documentation was misleading in that it gave the impression that
> 'for-push' could be used as a ref attribute in the output of the
> 'list' command. That is wrong.
> 
> Also, explicitly point out the connection between the commands
> 'list' and 'options' on the one hand, and the sections
> 'REF LIST ATTRIBUTES' and 'OPTIONS' on the other hand.
> 
> Signed-off-by: Max Horn 
> ---
> Documentation/git-remote-helpers.txt | 17 -
> 1 file changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/git-remote-helpers.txt 
> b/Documentation/git-remote-helpers.txt
> index 023dcca..e1df01d 100644
> --- a/Documentation/git-remote-helpers.txt
> +++ b/Documentation/git-remote-helpers.txt
> @@ -227,6 +227,8 @@ Support for this command is mandatory.
>   the name; unrecognized attributes are ignored. The list ends
>   with a blank line.
> +
> +See REF LIST ATTRIBUTES for a list of currently defined options.
> ++
> Supported if the helper has the "fetch" or "import" capability.
> 
> 'list for-push'::
> @@ -248,6 +250,8 @@ Supported if the helper has the "push" or "export" 
> capability.
>   for it).  Options should be set before other commands,
>   and may influence the behavior of those commands.
> +
> +See OPTIONS for a list of currently defined options.
> ++
> Supported if the helper has the "option" capability.
> 
> 'fetch'  ::
> @@ -256,7 +260,7 @@ Supported if the helper has the "option" capability.
>   per line, terminated with a blank line.
>   Outputs a single blank line when all fetch commands in the
>   same batch are complete. Only objects which were reported
> - in the ref list with a sha1 may be fetched this way.
> + in the output of 'list' with a sha1 may be fetched this way.
> +
> Optionally may output a 'lock ' line indicating a file under
> GIT_DIR/objects/pack which is keeping a pack until refs can be
> @@ -360,10 +364,9 @@ capabilities reported by the helper.
> REF LIST ATTRIBUTES
> ---
> 
> -'for-push'::
> - The caller wants to use the ref list to prepare push
> - commands.  A helper might chose to acquire the ref list by
> - opening a different type of connection to the destination.
> +The 'list' command produces a list of refs in which each ref
> +may be followed by a list of attributes. The following ref list
> +attributes are defined.
> 
> 'unchanged'::
>   This ref is unchanged since the last import or fetch, although
> @@ -371,6 +374,10 @@ REF LIST ATTRIBUTES
> 
> OPTIONS
> ---
> +
> +The following options are defined and (under suitable circumstances)
> +set by git if the remote helper has the 'option' capability.
> +
> 'option verbosity' ::
>   Changes the verbosity of messages displayed by the helper.
>   A value of 0 for  means that processes operate
> -- 
> 1.8.0.393.gcc9701d
> 
> --
> 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
> 

--
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: Possible vulnerability to SHA-1 collisions

[Jeff King]

On Sat, Nov 24, 2012 at 10:09:31AM -0800, Shawn O. Pearce wrote:

> On Sat, Nov 24, 2012 at 3:12 AM, Michael Hirshleifer <111...@caltech.edu> 
> wrote:
> > Evil Guy creates 2 files, 1 evil and 1 innocuous, with the same SHA-1
> > checksum (including Git header). Mr. Evil creates a local branch with an
> > innocuous name like “test-bugfix”, and adds a commit containing a reference
> > to the evil file. Separately, using a sockpuppet, Evil Guy creates an
> > innocuous bugfix (very likely to be accepted) containing the innocuous file,
> > and submits it to Good Guy. Before Good Guy can commit the bugfix, Evil Guy
> > pushes the evil branch to Github, and then immediately deletes it; or
> > equivalently --force pushes any innocuous commit on top of it. (This is
> > unlikely to arouse suspicion, and he can always say he deleted it because it
> > didn’t work.)
> 
> Here you assume Evil Guy has write access to the same repository as
> Good Guy. Lets assume this is possible, e.g. Evil Guy is actually
> impersonating White Hat because he managed to steal White Hat's
> credentials through a compromised host. Typically Evil Guy doesn't
> have write access to Good Guy's repository, and thus can't introduce
> objects into it without Good Guy being the one that creates the
> objects.
> 
> But lets just keep he assumption that Evil Guy can write to the same
> repository as Good Guy, and that he managed to create the bad branch
> and delete it, leaving the bad object in an unreachable state for 2
> weeks.

Actually, it is somewhat easier on GitHub, because we share objects
between forks of a repository via the alternates mechanism. So if you
can publicly fork the project and push a branch to your fork, you can
write to the shared object database. This applies not just to GitHub,
but to any hosting service which shares object databases between
projects (I do not know offhand if other hosting providers like Google
Code do this).

But as you noted later in your email, the byte-for-byte comparison on
object collision will let us detect this case when the good guy tries to
push and abort.

-Peff

PS I also think the OP's "sockpuppet creates innocuous bugfix" above is
   easier said than done. We do not have SHA-1 collisions yet, but if
   the md5 attacks are any indication, the innocuous file will not be
   completely clean; it will need to have some embedded binary goo that
   is mutated randomly during the collision process (which is why the
   md5 attacks were demonstrated with postscript files which _rendered_
   to look good, but contained a chunk of random bytes in a spot ignored
   by the postscript interpreter).
--
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/3] Add option to transpose parents of merge commit

[Kacper Kornet]

When the changes are pushed upstream, and in the meantime someone else
updated upstream branch git advises to use git pull. This results in
history:

 ---A---B---C--
 \ /
  D---E

where B is the local commit. D, E are commits pushed by someone else
when the developer was working on B. However sometimes the following
history is preferable:

---A---D---C'--
\ /
 '-B-'

The difference between C and C' is the order of parents. This change
allow for easier way to obtain this effect by introducing the option
--transpose-parents to git-merge and git-pull, which changes the order
of parents in resulting commit moving the original first parent to
the very end of list of parents.

The transposition is done just before the commit is finalized, so the
meaning of "our" and "their" for conflict resolution is not changed, so
"ours" denotes local version and "theirs" upstream.

Signed-off-by: Kacper Kornet 
---
 Documentation/merge-options.txt |  7 +++
 builtin/commit.c|  8 +++-
 builtin/merge.c | 16 
 commit.c| 11 +++
 commit.h|  2 ++
 git-pull.sh |  4 +++-
 6 files changed, 42 insertions(+), 6 deletions(-)

diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index 0bcbe0a..b4fbfdc 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -88,6 +88,13 @@ option can be used to override --squash.
Synonyms to --stat and --no-stat; these are deprecated and will be
removed in the future.
 
+--transpose-parents::
+   Transpose the parents in the final commit. The change is made
+   just before the commit so the meaning of 'our' and 'their'
+   concepts remains the same (i.e. 'our' means current branch before
+   the merge).
+
+
 ifndef::git-pull[]
 -q::
 --quiet::
diff --git a/builtin/commit.c b/builtin/commit.c
index ee0e884..ab2b844 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1477,6 +1477,7 @@ int cmd_commit(int argc, const char **argv, const char 
*prefix)
} else if (whence == FROM_MERGE) {
struct strbuf m = STRBUF_INIT;
FILE *fp;
+   int reversed_order=0;
 
if (!reflog_msg)
reflog_msg = "commit (merge)";
@@ -1484,10 +1485,13 @@ int cmd_commit(int argc, const char **argv, const char 
*prefix)
while (strbuf_getline(&m, fp, '\n') != EOF) {
if (!strcmp(m.buf, "no-ff"))
allow_fast_forward = 0;
+   if (!strcmp(m.buf, "reversed-order"))
+   reversed_order = 1;
}
fclose(fp);
}
-   pptr = &commit_list_insert(current_head, pptr)->next;
+   if (!reversed_order)
+   pptr = &commit_list_insert(current_head, pptr)->next;
fp = fopen(git_path("MERGE_HEAD"), "r");
if (fp == NULL)
die_errno(_("could not open '%s' for reading"),
@@ -1502,6 +1506,8 @@ int cmd_commit(int argc, const char **argv, const char 
*prefix)
}
fclose(fp);
strbuf_release(&m);
+   if (reversed_order)
+   pptr = &commit_list_insert(current_head, pptr)->next;
if (allow_fast_forward)
parents = reduce_heads(parents);
} else {
diff --git a/builtin/merge.c b/builtin/merge.c
index a96e8ea..41738a5 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -65,6 +65,7 @@ static int abort_current_merge;
 static int show_progress = -1;
 static int default_to_upstream;
 static const char *sign_commit;
+static int reversed_order=0;
 
 static struct strategy all_strategy[] = {
{ "recursive",  DEFAULT_TWOHEAD | NO_TRIVIAL },
@@ -213,6 +214,7 @@ static struct option builtin_merge_options[] = {
{ OPTION_STRING, 'S', "gpg-sign", &sign_commit, N_("key id"),
  N_("GPG sign commit"), PARSE_OPT_OPTARG, NULL, (intptr_t) "" },
OPT_BOOLEAN(0, "overwrite-ignore", &overwrite_ignore, N_("update 
ignored files (default)")),
+   OPT_BOOLEAN(0, "transpose-parents", &reversed_order, N_("reverse order 
of parents")),
OPT_END()
 };
 
@@ -822,9 +824,9 @@ static int merge_trivial(struct commit *head, struct 
commit_list *remoteheads)
 
write_tree_trivial(result_tree);
printf(_("Wonderful.\n"));
-   parent->item = head;
+   parent->item = reversed_order ? remoteheads->item : head;
parent->next = xmalloc(sizeof(*parent->next));
-   parent->next->item = remoteheads->item;
+   parent->next->item = reversed_order ? head : remoteheads->item;
parent->next->next = NULL;
prepare_to_commit(remoteheads);
if

[PATCH v2 1/3] Process MERGE_MODE before MERGE_HEAD

[Kacper Kornet]

It is in preparation to introduce --transpose-parents option to
git-merge, when the content of MERGE_MODE will dictate how the
MERGE_HEAD is interpreted.

Signed-off-by: Kacper Kornet 
---
 builtin/commit.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/builtin/commit.c b/builtin/commit.c
index 1dd2ec5..273332f 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1481,6 +1481,12 @@ int cmd_commit(int argc, const char **argv, const char 
*prefix)
 
if (!reflog_msg)
reflog_msg = "commit (merge)";
+   if (!stat(git_path("MERGE_MODE"), &statbuf)) {
+   if (strbuf_read_file(&sb, git_path("MERGE_MODE"), 0) < 
0)
+   die_errno(_("could not read MERGE_MODE"));
+   if (!strcmp(sb.buf, "no-ff"))
+   allow_fast_forward = 0;
+   }
pptr = &commit_list_insert(current_head, pptr)->next;
fp = fopen(git_path("MERGE_HEAD"), "r");
if (fp == NULL)
@@ -1496,12 +1502,6 @@ int cmd_commit(int argc, const char **argv, const char 
*prefix)
}
fclose(fp);
strbuf_release(&m);
-   if (!stat(git_path("MERGE_MODE"), &statbuf)) {
-   if (strbuf_read_file(&sb, git_path("MERGE_MODE"), 0) < 
0)
-   die_errno(_("could not read MERGE_MODE"));
-   if (!strcmp(sb.buf, "no-ff"))
-   allow_fast_forward = 0;
-   }
if (allow_fast_forward)
parents = reduce_heads(parents);
} else {
-- 
1.8.0.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 v2 2/3] Allow for MERGE_MODE to specify more then one mode

[Kacper Kornet]

Presently only one merge mode exists: non-fast-forward. But in future
the second one (transpose-parents) will be added, so the need to read
all lines of MERGE_MODE.

Signed-off-by: Kacper Kornet 
---
 builtin/commit.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/builtin/commit.c b/builtin/commit.c
index 273332f..ee0e884 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1427,7 +1427,6 @@ int cmd_commit(int argc, const char **argv, const char 
*prefix)
unsigned char sha1[20];
struct ref_lock *ref_lock;
struct commit_list *parents = NULL, **pptr = &parents;
-   struct stat statbuf;
int allow_fast_forward = 1;
struct commit *current_head = NULL;
struct commit_extra_header *extra = NULL;
@@ -1481,11 +1480,12 @@ int cmd_commit(int argc, const char **argv, const char 
*prefix)
 
if (!reflog_msg)
reflog_msg = "commit (merge)";
-   if (!stat(git_path("MERGE_MODE"), &statbuf)) {
-   if (strbuf_read_file(&sb, git_path("MERGE_MODE"), 0) < 
0)
-   die_errno(_("could not read MERGE_MODE"));
-   if (!strcmp(sb.buf, "no-ff"))
-   allow_fast_forward = 0;
+   if((fp = fopen(git_path("MERGE_MODE"), "r"))) {
+   while (strbuf_getline(&m, fp, '\n') != EOF) {
+   if (!strcmp(m.buf, "no-ff"))
+   allow_fast_forward = 0;
+   }
+   fclose(fp);
}
pptr = &commit_list_insert(current_head, pptr)->next;
fp = fopen(git_path("MERGE_HEAD"), "r");
-- 
1.8.0.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 v2 0/3] Add option to change order of parents in merge commit

[Kacper Kornet]

The second version of patches introducing option to change order
of parents in merge commits. The changes in respect to the previous
version:

- I have divided the changes to the preparatory ones, which
  only refactore the code without introducing new functionality, and
  the commit which introduces the new option

- The documentation for the new options has been added

This is not yet a final version, as the tests are missing. But maybe while I'm 
working
on them there will be some comments.

Kacper Kornet (3):
  Process MERGE_MODE before MERGE_HEAD
  Allow for MERGE_MODE to specify more then one mode
  Add option to transpose parents of merge commit

 Documentation/merge-options.txt |  7 +++
 builtin/commit.c| 22 ++
 builtin/merge.c | 16 
 commit.c| 11 +++
 commit.h|  2 ++
 git-pull.sh |  4 +++-
 6 files changed, 49 insertions(+), 13 deletions(-)

-- 
1.8.0.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 v4 2/4] git-submodule init: Record submodule..branch in repository config.

[Jens Lehmann]

Am 26.11.2012 22:00, schrieb W. Trevor King:
> From: "W. Trevor King" 
> 
> This allows users to override the .gitmodules value with a
> per-repository value.

Your intentions makes lots of sense, but your patch does more than
that. Copying the branch setting into .git/config sets the initial
branch setting into stone. That makes it impossible to have a branch
"foo" in the superproject using a branch "bar" in a submodule and
another superproject branch "frotz" using branch "nitfol" for the
same submodule. You should use the branch setting from .git/config
if present and fall back to the branch setting from .gitmodules if
not, which would enable the user to have her own setting if she
doesn't like what upstream provides but would still enable others
to follow different submodule branches in different superproject
branches.

> Signed-off-by: W. Trevor King 
> ---
>  Documentation/config.txt   |  9 +
>  git-submodule.sh   |  7 +++
>  t/t7400-submodule-basic.sh | 18 ++
>  3 files changed, 30 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 11f320b..1304499 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1994,10 +1994,11 @@ status.submodulesummary::
>  submodule..path::
>  submodule..url::
>  submodule..update::
> - The path within this project, URL, and the updating strategy
> - for a submodule.  These variables are initially populated
> - by 'git submodule init'; edit them to override the
> - URL and other values found in the `.gitmodules` file.  See
> +submodule..branch::
> + The path within this project, URL, the updating strategy, and the
> + local branch name for a submodule.  These variables are initially
> + populated by 'git submodule init'; edit them to override the URL and
> + other values found in the `.gitmodules` file.  See
>   linkgit:git-submodule[1] and linkgit:gitmodules[5] for details.
>  
>  submodule..fetchRecurseSubmodules::
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 6eed008..c51b6ae 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -505,6 +505,13 @@ cmd_init()
>   test -n "$(git config submodule."$name".update)" ||
>   git config submodule."$name".update "$upd" ||
>   die "$(eval_gettext "Failed to register update mode for 
> submodule path '\$sm_path'")"
> +
> + # Copy "branch" setting when it is not set yet
> + branch="$(git config -f .gitmodules submodule."$name".branch)"
> + test -z "$branch" ||
> + test -n "$(git config submodule."$name".branch)" ||
> + git config submodule."$name".branch "$branch" ||
> + die "$(eval_gettext "Failed to register branch for submodule 
> path '\$sm_path'")"
>   done
>  }
>  
> diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
> index fc08647..3dc8237 100755
> --- a/t/t7400-submodule-basic.sh
> +++ b/t/t7400-submodule-basic.sh
> @@ -236,6 +236,24 @@ test_expect_success 'submodule add --local-branch= 
> --branch' '
>   )
>  '
>  
> +test_expect_success 'init should register submodule branch in .git/config' '
> + (
> + cd addtest &&
> + git submodule init &&
> + test "$(git config submodule.submod-follow.branch)" = "final"
> + )
> +'
> +
> +test_expect_success 'local config should override .gitmodules branch' '
> + (
> + cd addtest &&
> + rm -fr submod-follow &&
> + git config submodule.submod-follow.branch initial
> + git submodule init &&
> + test "$(git config submodule.submod-follow.branch)" = "initial"
> + )
> +'
> +
>  test_expect_success 'setup - add an example entry to .gitmodules' '
>   GIT_CONFIG=.gitmodules \
>   git config submodule.example.url git://example.com/init.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

[PATCH] configure.ac: fix pthreads detection on Mac OS X

[Max Horn]

The configure script checks whether certain flags are required to use
pthreads. But it did not consider that *none* might be needed (as is the
case on Mac OS X). This lead to configure adding "-mt" to the list of
flags (which does nothing on OS X except producing a warning). This in
turn triggered a compiler warning on every single file.

To solve this, we now first check if pthreads work without extra flags.
This means the check is now order dependant, hence a comment is added
explaining this, and the reasons for it.

Note that it might be possible to write an order independent test, but
it does not seem worth the extra effort required for implementing and
testing such a solution, when this simple solution exists and works.

Signed-off-by: Max Horn 
---

This is actually a revised version from my patch
 "Change configure to check if pthreads are usable without any extra flags"
from July. I simply had forgotten all about it :-(.

Chers,
Max

 configure.ac | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index ad215cc..41ac9a5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1021,7 +1021,17 @@ if test -n "$USER_NOPTHREAD"; then
 # -D_REENTRANT' or some such.
 elif test -z "$PTHREAD_CFLAGS"; then
   threads_found=no
-  for opt in -mt -pthread -lpthread; do
+  # Attempt to compile and link some code using pthreads to determine
+  # required linker flags. The order is somewhat important here: We
+  # first try it without any extra flags, to catch systems where
+  # pthreads are part of the C library, then go on testing various other
+  # flags. We do so to avoid false positives. For example, on Mac OS X
+  # pthreads are part of the C library; moreover, the compiler allows us
+  # to add "-mt" to the CFLAGS (although it will do nothing except
+  # trigger a warning about an unused flag). Hence if we checked for
+  # "-mt" before "" we would end up picking it. But unfortunately this
+  # would then trigger compiler warnings on every single file we compile.
+  for opt in "" -mt -pthread -lpthread; do
  old_CFLAGS="$CFLAGS"
  CFLAGS="$opt $CFLAGS"
  AC_MSG_CHECKING([for POSIX Threads with '$opt'])
-- 
1.8.0.393.gcc9701d

--
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: Re: [PATCH v4 0/4] git-submodule add: Add --local-branch option

[Heiko Voigt]

Hi,

On Tue, Nov 27, 2012 at 02:01:05PM -0500, W. Trevor King wrote:
> On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote:
> The v4 series leaves the remote branch amigious, but it helps you
> point the local branch at the right hash so that future calls to
> 
>   $ git submodule foreach 'git pull'
> 
> can use the branch's .git/modules//config settings.

But IMO thats the functionality which should be implemented in submodule
update and not left to the user.

> > I would think more of some convention like:
> > 
> > $ git checkout -t origin/$branch
> > 
> > when first initialising the submodule with e.g.
> > 
> > $ git submodule update --init --branch
> > 
> > Then later calls of
> > 
> > $ git submodule update --branch
> > 
> > would have a branch configured to pull from. I imagine that results in
> > a similar behavior gerrit is doing on the server side?
> 
> That sounds like it's doing pretty much the same thing.  Can you think
> of a test that would distinguish it from my current v4 implementation?

Well the main difference is that gerrit is automatically updating the
superproject AFAIK. I would like it if we could implement the same
workflow support in the submodule script. It seems to me that this is
already proven to be useful workflow.

I do not have a test but a small draft diff (completely untested, quick and
dirty) to illustrate the approach I am talking about.

You can find the whole change at

https://github.com/hvoigt/git/commits/hv/floating_submodules_draft

and the interesting patch for easy commenting below[1].

> > How about reusing the -b|--branch option for add? Since we only change
> > the behavior when submodule.$name.update is set to branch it seems
> > reasonable to me. Opinions?
> 
> That was the approach I used in v1, but people were concerned that we
> would be stomping on previously unclaimed config space.  Since noone
> has pointed out other uses besides Gerrit's very similar case, I'm not
> sure if that is still an issue.

Could you point me to that mail? I cannot seem to find it in my archive.

> > > Because you need to recurse through submodules for `update --branch`
> > > even if "$subsha1" == "$sha1", I had to amend the conditional
> > > controlling that block.  This broke one of the existing tests, which I
> > > "fixed" in patch 4.  I think a proper fix would involve rewriting
> > > 
> > >   (clear_local_git_env; cd "$sm_path" &&
> > >( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&
> > > test -z "$rev") || git-fetch)) ||
> > >   die "$(eval_gettext "Unable to fetch in submodule path '\$sm_path'")"
> > > 
> > > but I'm not familiar enough with rev-list to want to dig into that
> > > yet.  If feedback for the earlier three patches is positive, I'll work
> > > up a clean fix and resubmit.
> > 
> > You probably need to separate your handling here. The comparison of the
> > currently checked out sha1 and the recorded sha1 is an optimization
> > which skips unnecessary fetching in case the submodules commits are
> > already correct. This code snippet checks whether the to be checked out
> > sha1 is already local and also skips the fetch if it is. We should not
> > break that.
> 
> Agreed.  However, determining if the target $sha1 is local should have
> nothing to do with the current checked out $subsha1.

See my draft or the diff below for an illustration of the splitup.

Cheers Heiko

[1]
diff --git a/git-submodule.sh b/git-submodule.sh
index 9ad4370..3fa1465 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -183,6 +183,7 @@ module_clone()
sm_path=$1
url=$2
reference="$3"
+   branch="$4"
quiet=
if test -n "$GIT_QUIET"
then
@@ -209,6 +210,8 @@ module_clone()
clear_local_git_env
git clone $quiet -n ${reference:+"$reference"} \
--separate-git-dir "$gitdir" "$url" "$sm_path"
+   test -n "$branch" && (cd $sm_path &&
+   git checkout -t origin/$branch)
) ||
die "$(eval_gettext "Clone of '\$url' into submodule path 
'\$sm_path' failed")"
fi
@@ -361,7 +364,7 @@ Use -f if you really want to add it." >&2
 
else
 
-   module_clone "$sm_path" "$realrepo" "$reference" || exit
+   module_clone "$sm_path" "$realrepo" "$reference" 
"$local_branch" || exit
(
clear_local_git_env
cd "$sm_path" &&
@@ -577,6 +580,12 @@ handle_on_demand_update () {
fi
 }
 
+handle_tracking_branch_update () {
+   (clear_local_git_env; cd "$sm_path" &&
+   git-checkout $branch && git-pull --ff-only) ||
+   die "$(eval_gettext "Unable to pull branch '\$branch' in submodule path 
'\$sm_path'")"
+}
+
 #
 # Update each submodule path to correct revision, using clone and checkout as 
needed
 #
@@ -648,6 +657,7 @@ cmd_update()
clo

Re: Possible vulnerability to SHA-1 collisions

[Aaron Schrab]

At 18:07 -0500 27 Nov 2012, Jeff King  wrote:

PS I also think the OP's "sockpuppet creates innocuous bugfix" above is
  easier said than done. We do not have SHA-1 collisions yet, but if
  the md5 attacks are any indication, the innocuous file will not be
  completely clean; it will need to have some embedded binary goo that
  is mutated randomly during the collision process (which is why the
  md5 attacks were demonstrated with postscript files which _rendered_
  to look good, but contained a chunk of random bytes in a spot ignored
  by the postscript interpreter).


I don't think that really saves us though.  Many formats have parts of 
the file which will be ignored, such as comments in source code.  With 
the suggested type of attack, there isn't a requirement about which 
version of the file is modified.  So the attacker should be able to 
generate a version of a file with an innocuous change, get the SHA-1 for 
that, then add garbage comments to their malicious version of the file 
to try to get the same SHA-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 v3 0/7] New remote-bzr remote helper

[Junio C Hamano]

Felipe Contreras  writes:

> On Mon, Nov 26, 2012 at 5:09 AM, Junio C Hamano  wrote:
>> Felipe Contreras  writes:
>>
>>> On Sun, Nov 11, 2012 at 3:19 PM, Felipe Contreras
>>>  wrote:
 This is a re-roll of the previous series to add support to fetch and push
 special modes, and refactor some related code.
>>>
>>> It seems this one got forgotten, I only see v2 in pu.
>>
>> Oops; I think that was fell through the cracks during the maintainer
>> hand-off.  As the previous one has already been cooking in 'next'
>> for a week or so, I would appreciate if you send incremental updates
>> to fix or enhance what is in there.
>
> Yes, that's what I have planned for the next patches, as I already did
> for remote-hg, but the changes in remote-bzr were a bit bigger.

OK.  Both fc/remote-hg and fc/remote-bzr are slated for 'master'
soonish, but I take the above to mean that fc/remote-hg is ready
while it is better to wait for updates to fc/remote-bzr before
merging it.

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

[RFH/Preview/PATCH] update "howto maintain git"

[Junio C Hamano]

This is still incomplete without a documentation for two scripts,
Meta/Reintegrate and Meta/cook (both are found on my 'todo' branch
and meant to be checked out in the Meta subdirectory of git.git),
that are meant to help the maintainer workflow but can be used by
interested parties, but the old write-up of the procedure has become
really stale and no longer reflects the reality.

Signed-off-by: Junio C Hamano 
---

 * It would help greatly if Peff can point out parts that he found
   too sketchy to be useful, and even better fill these parts
   himself, based on the recent "interim maintainer" experience.

 Documentation/howto/maintain-git.txt | 176 +--
 1 file changed, 106 insertions(+), 70 deletions(-)

diff --git c/Documentation/howto/maintain-git.txt 
w/Documentation/howto/maintain-git.txt
index ea6e4a5..a5713b4 100644
--- c/Documentation/howto/maintain-git.txt
+++ w/Documentation/howto/maintain-git.txt
@@ -12,20 +12,20 @@ How to maintain Git
 
 The maintainer's git time is spent on three activities.
 
- - Communication (60%)
+ - Communication (45%)
 
Mailing list discussions on general design, fielding user
questions, diagnosing bug reports; reviewing, commenting on,
suggesting alternatives to, and rejecting patches.
 
- - Integration (30%)
+ - Integration (50%)
 
Applying new patches from the contributors while spotting and
correcting minor mistakes, shuffling the integration and
testing branches, pushing the results out, cutting the
releases, and making announcements.
 
- - Own development (10%)
+ - Own development (5%)
 
Scratching my own itch and sending proposed patch series out.
 
@@ -39,6 +39,9 @@ The policy.
contain bugfixes and enhancements in any area, including
functionality, performance and usability, without regression.
 
+ - One release cycle for a feature release is expected to last for
+   eight to ten weeks.
+
  - Maintenance releases are numbered as vX.Y.Z.W and are meant
to contain only bugfixes for the corresponding vX.Y.Z feature
release and earlier maintenance releases vX.Y.Z.V (V < W).
@@ -62,12 +65,15 @@ The policy.
  - 'pu' branch is used to publish other proposed changes that do
not yet pass the criteria set for 'next'.
 
- - The tips of 'master', 'maint' and 'next' branches will always
-   fast-forward, to allow people to build their own
-   customization on top of them.
+ - The tips of 'master' and 'maint' branches will not be rewound to
+   allow people to build their own customization on top of them.
+   Early in a new development cycle, 'next' is rewound to the tip of
+   'master' once, but otherwise it will not be rewound until the end
+   of the cycle.
 
- - Usually 'master' contains all of 'maint', 'next' contains all
-   of 'master' and 'pu' contains all of 'next'.
+ - Usually 'master' contains all of 'maint' and 'next' contains all
+   of 'master'.  'pu' contains all the topics merged to 'next', but
+   is rebuilt directly on 'master'.
 
  - The tip of 'master' is meant to be more stable than any
tagged releases, and the users are encouraged to follow it.
@@ -80,11 +86,15 @@ The policy.
 A typical git day for the maintainer implements the above policy
 by doing the following:
 
- - Scan mailing list and #git channel log.  Respond with review
-   comments, suggestions etc.  Kibitz.  Collect potentially
-   usable patches from the mailing list.  Patches about a single
-   topic go to one mailbox (I read my mail in Gnus, and type
-   \C-o to save/append messages in files in mbox format).
+ - Scan mailing list.  Respond with review comments, suggestions
+   etc.  Kibitz.  Collect potentially usable patches from the
+   mailing list.  Patches about a single topic go to one mailbox (I
+   read my mail in Gnus, and type \C-o to save/append messages in
+   files in mbox format).
+
+ - Write his own patches to address issues raised on the list but
+   nobody has stepped up solving.  Send it out just like other
+   contributors do.
 
  - Review the patches in the saved mailboxes.  Edit proposed log
message for typofixes and clarifications, and add Acks
@@ -100,28 +110,25 @@ by doing the following:
- Obviously correct fixes that pertain to the tip of 'master'
  are directly applied to 'master'.
 
+   - Other topics are not handled in this step.
+
This step is done with "git am".
 
  $ git checkout master;# or "git checkout maint"
  $ git am -3 -s mailbox
  $ make test
 
- - Merge downwards (maint->master):
-
- $ git checkout master
- $ git merge maint
- $ make test
-
  - Review the last issue of "What's cooking" message, review the
topics scheduled for merging upwards (topic->master and
-   topic->maint), and merge.
+   topic->maint), and merge.  Use "Meta/cook -w" script (see later)
+   to aid this step.
 
  $ git checkout master;# or "git checkout maint"
  $ git merge ai/topic ;# or "git merge ai/maint-topic"
  $ git log

Re: Millisecond precision in timestamps?

[Shawn Pearce]

On Tue, Nov 27, 2012 at 3:04 PM, Eric S. Raymond  wrote:
> Junio C Hamano :
>> fsck_ident() in fsck.c rejects anything but " [1-9][0-9]* " after
>> the author and committer ident (i.e. the timestamp has to be
>> integral number of seconds since the epoch, not before it, nor
>> with fractional seconds).
>
> Is this architecturally significant?  It sounds like another
> implementation detail.

Well... if we added a fractional seconds to a commit, older versions
of Git will scream loudly and refuse to work with the new commit. That
would create a fork of 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

[PATCH] Documentation/git-push.txt: clarify the "push from satellite" workflow

[Junio C Hamano]

The context of the example to push into refs/remotes/satellite/
hierarchy of the other repository needs to be spelled out explicitly
for the value of this example to be fully appreciated.  Make it so.

Signed-off-by: Junio C Hamano 
---
Brandon Casey  writes:

>> So refs are correct. The context is not sufficiently explained.
>
> Ah, I see.  Yeah, I think that is complex enough to merit an
> extended explanation.

Something like this?

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

diff --git c/Documentation/git-push.txt w/Documentation/git-push.txt
index 6d19d59..8b637d3 100644
--- c/Documentation/git-push.txt
+++ w/Documentation/git-push.txt
@@ -385,11 +385,23 @@ the ones in the examples below) can be configured as the 
default for
A handy way to push the current branch to the same name on the
remote.
 
-`git push origin master:satellite/master dev:satellite/dev`::
+`git push mothership master:satellite/master dev:satellite/dev`::
Use the source ref that matches `master` (e.g. `refs/heads/master`)
to update the ref that matches `satellite/master` (most probably
-   `refs/remotes/satellite/master`) in the `origin` repository, then
+   `refs/remotes/satellite/master`) in the `mothership` repository;
do the same for `dev` and `satellite/dev`.
++
+This is to emulate `git fetch` run on the `mothership` using `git
+push` that is run in the opposite direction in order to integrate
+the work done on `satellite`, and is often necessary when you can
+only make connection in one way (i.e. satellite can ssh into
+mothership but mothership cannot initiate connection to satellite
+because the latter is behind a firewall or does not run sshd).
++
+After running this `git push` on the `satellite` machine, you would
+ssh into the `mothership` and run `git merge` there to complete the
+emulation of `git pull` that were run on `mothership` to pull changes
+made on `satellite`.
 
 `git push origin HEAD:master`::
Push the current branch to the remote ref matching `master` in the
--
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 v6 p2 3/9] transport-helper: trivial code shuffle

[Felipe Contreras]

On Tue, Nov 27, 2012 at 6:00 PM, Junio C Hamano  wrote:
> Felipe Contreras  writes:
>
>> Just shuffle the die() part to make it more explicit, and cleanup the
>> code-style.
>>
>> Signed-off-by: Felipe Contreras 
>> ---
>>  transport-helper.c | 7 +++
>>  1 file changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/transport-helper.c b/transport-helper.c
>> index 32ad877..0c95101 100644
>> --- a/transport-helper.c
>> +++ b/transport-helper.c
>> @@ -775,6 +775,9 @@ static int push_refs_with_export(struct transport 
>> *transport,
>>   char *private;
>>   unsigned char sha1[20];
>>
>> + if (ref->deletion)
>> + die("remote-helpers do not support ref deletion");
>> +
>>   if (!data->refspecs)
>>   continue;
>
> This is not just "just shuffle the die to make it explicit" but it
> does change the semantics; earlier ref->deletion was perfectly fine
> as long as data->refspecs is not given, but the new code always
> dies.
>
> If this semantic change is a good thing, please explain why it is so
> in the log message.  If the change is "it does not matter because
> when data->refspecs is not given and ref->deletion is set, we die
> later elsewhere in the code anyway", then it needs to be described.

refspecs are optional, but when they are not present the code doesn't
work at all. This patch changes the behavior that was totally broken
anyway.

-- 
Felipe Contreras
--
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: Millisecond precision in timestamps?

[Eric S. Raymond]

Shawn Pearce :
> Well... if we added a fractional seconds to a commit, older versions
> of Git will scream loudly and refuse to work with the new commit. That
> would create a fork of Git.

So much for that idea, I guess.  

Unless..I don't know how git's database representations work.  Are they
version-stamped in any way?  If so, some slightly painful hackery would
get around that problem.

I'm being exploratory, here. No proposal to code anything is in the
offing.
-- 
http://www.catb.org/~esr/";>Eric S. Raymond
--
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: Why is this known by git but not by gitk

[Felipe Contreras]

On Tue, Nov 27, 2012 at 6:50 PM, Kevin O'Gorman  wrote:
> I just converted a SourceForge CVS repo to git using cvs2svn.  One
> directory in the result is named CVSROOT and everything would be fine,
> but I wan to know why gitk does not see it.
>
> Git itself does not report it either, but it lets me "git rm -r
> CVSROOT" and stages the change.
>
> I just want to know what's up with this before I commit myself to
> using this converted repo.

Is it present in the .gitignore file?

-- 
Felipe Contreras
--
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 0/7] New remote-bzr remote helper

[Felipe Contreras]

On Wed, Nov 28, 2012 at 12:32 AM, Junio C Hamano  wrote:
> Felipe Contreras  writes:
>
>> On Mon, Nov 26, 2012 at 5:09 AM, Junio C Hamano  wrote:
>>> Felipe Contreras  writes:
>>>
 On Sun, Nov 11, 2012 at 3:19 PM, Felipe Contreras
  wrote:
> This is a re-roll of the previous series to add support to fetch and push
> special modes, and refactor some related code.

 It seems this one got forgotten, I only see v2 in pu.
>>>
>>> Oops; I think that was fell through the cracks during the maintainer
>>> hand-off.  As the previous one has already been cooking in 'next'
>>> for a week or so, I would appreciate if you send incremental updates
>>> to fix or enhance what is in there.
>>
>> Yes, that's what I have planned for the next patches, as I already did
>> for remote-hg, but the changes in remote-bzr were a bit bigger.
>
> OK.  Both fc/remote-hg and fc/remote-bzr are slated for 'master'
> soonish, but I take the above to mean that fc/remote-hg is ready
> while it is better to wait for updates to fc/remote-bzr before
> merging it.

I was waiting on both to be merged, let me see what I have pending and
would be nice to have before the merge.


-- 
Felipe Contreras
--
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: Millisecond precision in timestamps?

[David Lang]

On Tue, 27 Nov 2012, Eric S. Raymond wrote:


Shawn Pearce :

Well... if we added a fractional seconds to a commit, older versions
of Git will scream loudly and refuse to work with the new commit. That
would create a fork of Git.


So much for that idea, I guess.

Unless..I don't know how git's database representations work.  Are they
version-stamped in any way?  If so, some slightly painful hackery would
get around that problem.

I'm being exploratory, here. No proposal to code anything is in the
offing.


Apologies if this was covered earlier in the thread (I missed the beginning)

remember that git is dealing with timestamps generated across different 
machines, and since the times are not assumed to be in sync, let alone to the 
millisecond level, there's not much value to git in that level of presision.


git routinely deals with timestamps that are off by days. If the timestamps are 
within a minute or so, you are in pretty good shape.


David Lang
--
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: Millisecond precision in timestamps?

[Felipe Contreras]

On Wed, Nov 28, 2012 at 1:12 AM, Eric S. Raymond  wrote:
> Shawn Pearce :
>> Well... if we added a fractional seconds to a commit, older versions
>> of Git will scream loudly and refuse to work with the new commit. That
>> would create a fork of Git.
>
> So much for that idea, I guess.
>
> Unless..I don't know how git's database representations work.  Are they
> version-stamped in any way?  If so, some slightly painful hackery would
> get around that problem.

% git cat-file -p HEAD

You'll see exactly how git stores commits. Changing anything in there
must be done carefully.

-- 
Felipe Contreras
--
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: Possible vulnerability to SHA-1 collisions

[Jeff King]

On Tue, Nov 27, 2012 at 06:30:17PM -0500, Aaron Schrab wrote:

> At 18:07 -0500 27 Nov 2012, Jeff King  wrote:
> >PS I also think the OP's "sockpuppet creates innocuous bugfix" above is
> >  easier said than done. We do not have SHA-1 collisions yet, but if
> >  the md5 attacks are any indication, the innocuous file will not be
> >  completely clean; it will need to have some embedded binary goo that
> >  is mutated randomly during the collision process (which is why the
> >  md5 attacks were demonstrated with postscript files which _rendered_
> >  to look good, but contained a chunk of random bytes in a spot ignored
> >  by the postscript interpreter).
> 
> I don't think that really saves us though.  Many formats have parts
> of the file which will be ignored, such as comments in source code.

Agreed, it does not save us unconditionally. It just makes it harder to
execute the attack. Would you take a patch from a stranger that had a
kilobyte of binary garbage in a comment?

A more likely avenue would be a true binary file where nobody is
expected to read the diff.

> With the suggested type of attack, there isn't a requirement about
> which version of the file is modified.  So the attacker should be
> able to generate a version of a file with an innocuous change, get
> the SHA-1 for that, then add garbage comments to their malicious
> version of the file to try to get the same SHA-1.

That's not how birthday collision attacks usually work, though. You do
not get to just mutate the malicious side and leave the innocuous side
untouched. You are mutating both sides over and over and hoping to find
a matching sha1 from the "good" and "evil" sides.

Of course, I have not been keeping up too closely with the efforts to
break sha-1. Maybe there is something more nefarious about the current
attacks. I am just going off my recollection of the md5 collision
attacks.

-Peff
--
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 v4 2/4] git-submodule init: Record submodule..branch in repository config.

[W. Trevor King]

On Wed, Nov 28, 2012 at 12:19:04AM +0100, Jens Lehmann wrote:
> Am 26.11.2012 22:00, schrieb W. Trevor King:
> > From: "W. Trevor King" 
> > 
> > This allows users to override the .gitmodules value with a
> > per-repository value.
> 
> [snip problems].  You should use the branch setting from .git/config
> if present and fall back to the branch setting from .gitmodules if
> not, which would enable the user to have her own setting if she
> doesn't like what upstream provides but would still enable others to
> follow different submodule branches in different superproject
> branches.

Sounds good.  Will fix in v5.

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature

Re: [PATCH v3 0/7] New remote-bzr remote helper

[Felipe Contreras]

On Wed, Nov 28, 2012 at 12:32 AM, Junio C Hamano  wrote:
> Felipe Contreras  writes:
>
>> On Mon, Nov 26, 2012 at 5:09 AM, Junio C Hamano  wrote:
>>> Felipe Contreras  writes:
>>>
 On Sun, Nov 11, 2012 at 3:19 PM, Felipe Contreras
  wrote:
> This is a re-roll of the previous series to add support to fetch and push
> special modes, and refactor some related code.

 It seems this one got forgotten, I only see v2 in pu.
>>>
>>> Oops; I think that was fell through the cracks during the maintainer
>>> hand-off.  As the previous one has already been cooking in 'next'
>>> for a week or so, I would appreciate if you send incremental updates
>>> to fix or enhance what is in there.
>>
>> Yes, that's what I have planned for the next patches, as I already did
>> for remote-hg, but the changes in remote-bzr were a bit bigger.
>
> OK.  Both fc/remote-hg and fc/remote-bzr are slated for 'master'
> soonish, but I take the above to mean that fc/remote-hg is ready
> while it is better to wait for updates to fc/remote-bzr before
> merging it.

Please update remote-bzr to series version 3. The rest of the patches
will be on top of that version.

-- 
Felipe Contreras
--
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: Python extension commands in git - request for policy change

[Jeff King]

On Wed, Nov 28, 2012 at 01:10:34AM +0100, Felipe Contreras wrote:

> > While "constant traffic" probably overstates the issue, these are not
> > theoretical problems. I recall at least three cases in the last year
> > or so where Git has seen breakage with Solaris or Mac OS X because
> > of sed or tr incompatibilities, and I don't even read this list that
> > thoroughly.
> 
> Most of the *constant* traffic is about *theoretical*
> incompatibilities, how much of that are real incompatibilities, it's
> not known. _Some_ of the traffic is about real incompatibilities,
> sure, but you could count only three cases *in a year*. It's not a
> huge amount. And then, how man this year?
> 
> Also, I would like references to those incompatibilities.

Try:

  git log --grep='portab' -- '*.sh'

Not all of the hits are shell portability fixes, but most of them are,
and they are all in response to real, reported issues. The usual
culprits are Solaris, BSD (including OS X), and the occasional GNUism.
And that is only the ones that we fixed in response to bug reports for
commits in the wild. Many more have been caught in review before needing
a separate patch (grepping the list archive for 'portable' and '\.sh'
yields 1800 messages).

So dealing with shell portability is definitely something we do, and it
is a minor pain.

But like you, I think we have been getting along reasonably well with
shell scripts (and where it is not powerful enough, writing C). No
solution is going to be free of portability issues (whether because of
differing versions, because the tool is uncommon on certain platforms,
or whatever). And because git-core's official API is shell-executable
commands, any other language you write ends up looking a lot like shell
anyway.

If people are really hankering to write sub-commands of git in python
(or whatever), I would suggest checking out libgit2 which has a nice set
of python bindings (and ruby bindings, and C# bindings, and so on). It
doesn't have feature parity with git-core yet, but they have been making
a lot of progress.

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