Re: [PATCH 2/5] difftool: Eliminate global variables

[Sebastian Schuberth]

On 23.07.2012 05:42, David Aguilar wrote:


Organize the script so that it has a single main() function which
calls out to dir_diff() and file_diff() functions. This eliminates
dir-diff-specific variables that do not need to be calculated when
performing a regular file-diff.


Funny, I just have prepared a patch along the same lines so that one can 
call git-difftool -h and --tool-help also outside a repository, see 
below. Does you patch offer the same? If so, I'll drop mine.


---
 git-difftool.perl | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/git-difftool.perl b/git-difftool.perl
index ae1e052..e7b71c9 100755
--- a/git-difftool.perl
+++ b/git-difftool.perl
@@ -25,8 +25,9 @@ use Git;
 my @tools;
 my @working_tree;
 my $rc;
-my $repo = Git-repository();
-my $repo_path = $repo-repo_path();
+my $repo;
+my $repo_path;
+my $workdir;

 sub usage
 {
@@ -62,8 +63,6 @@ sub find_worktree
return $worktree;
 }

-my $workdir = find_worktree();
-
 sub filter_tool_scripts
 {
if (-d $_) {
@@ -293,6 +292,11 @@ if (defined($help)) {
 if (defined($tool_help)) {
print_tool_help();
 }
+
+$repo = Git-repository();
+$repo_path = $repo-repo_path();
+$workdir = find_worktree();
+
 if (defined($difftool_cmd)) {
if (length($difftool_cmd)  0) {
$ENV{GIT_DIFF_TOOL} = $difftool_cmd;
--
1.7.11.msysgit.2
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] difftool: Eliminate global variables

[David Aguilar]

On Sun, Jul 22, 2012 at 11:13 PM, Sebastian Schuberth
sschube...@gmail.com wrote:
 On 23.07.2012 05:42, David Aguilar wrote:

 Organize the script so that it has a single main() function which
 calls out to dir_diff() and file_diff() functions. This eliminates
 dir-diff-specific variables that do not need to be calculated when
 performing a regular file-diff.


 Funny, I just have prepared a patch along the same lines so that one can
 call git-difftool -h and --tool-help also outside a repository, see below.
 Does you patch offer the same? If so, I'll drop mine.

It *should*. I did not consider this case but that is indeed the
desired behavior.

What my patch did not offer was a test to ensure this behavior...



 ---
  git-difftool.perl | 12 
  1 file changed, 8 insertions(+), 4 deletions(-)

 diff --git a/git-difftool.perl b/git-difftool.perl
 index ae1e052..e7b71c9 100755
 --- a/git-difftool.perl
 +++ b/git-difftool.perl
 @@ -25,8 +25,9 @@ use Git;
  my @tools;
  my @working_tree;

  my $rc;
 -my $repo = Git-repository();
 -my $repo_path = $repo-repo_path();
 +my $repo;
 +my $repo_path;
 +my $workdir;

  sub usage
  {
 @@ -62,8 +63,6 @@ sub find_worktree

 return $worktree;
  }

 -my $workdir = find_worktree();
 -
  sub filter_tool_scripts
  {
 if (-d $_) {
 @@ -293,6 +292,11 @@ if (defined($help)) {
  if (defined($tool_help)) {
 print_tool_help();
  }
 +
 +$repo = Git-repository();
 +$repo_path = $repo-repo_path();
 +$workdir = find_worktree();
 +
  if (defined($difftool_cmd)) {
 if (length($difftool_cmd)  0) {
 $ENV{GIT_DIFF_TOOL} = $difftool_cmd;
 --
 1.7.11.msysgit.2



-- 
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 2/5] difftool: Eliminate global variables

[David Aguilar]

On Sun, Jul 22, 2012 at 11:30 PM, Sebastian Schuberth
sschube...@gmail.com wrote:
 On Mon, Jul 23, 2012 at 8:21 AM, David Aguilar dav...@gmail.com wrote:

 Funny, I just have prepared a patch along the same lines so that one can
 call git-difftool -h and --tool-help also outside a repository, see below.
 Does you patch offer the same? If so, I'll drop mine.

 It *should*. I did not consider this case but that is indeed the
 desired behavior.

 What my patch did not offer was a test to ensure this behavior...

 Well, I'm not asking for a test. From my side, I'd be happy if you
 could just try it and confirm that it works, as I currently cannot
 easily apply your patch.

Heheh.. I was hoping you could provide a test ;-)

I just tried it now.  They work outside of a repository.
-- 
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 2/5] difftool: Eliminate global variables

[Sebastian Schuberth]

On Mon, Jul 23, 2012 at 8:44 AM, David Aguilar dav...@gmail.com wrote:

 Well, I'm not asking for a test. From my side, I'd be happy if you
 could just try it and confirm that it works, as I currently cannot
 easily apply your patch.

 Heheh.. I was hoping you could provide a test ;-)

;-)

 I just tried it now.  They work outside of a repository.

Great, thanks! I'm dropping my patch then.

-- 
Sebastian Schuberth
--
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] Various merge / diff tool related minor clean-ups and improvements

[Sebastian Schuberth]

This series introduce various minor clean-ups and improvements to the merge / 
diff tool scripts and documentation.

Sebastian Schuberth (4):
  Use variables for the lists of tools that support merging / diffing
  Explicitly list all valid diff tools and document --tool-help as an
option
  Make sure to use Araxis' compare and not e.g. ImageMagick's
  Add a few more code comments and blank lines in guess_merge_tool

 Documentation/git-difftool.txt |  9 ++---
 contrib/completion/git-completion.bash | 11 +--
 git-mergetool--lib.sh  |  6 ++
 mergetools/araxis  |  8 +++-
 4 files changed, 28 insertions(+), 6 deletions(-)

-- 
1.7.11.msysgit.2


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

[PATCH v2 0/5] Various merge / diff tool related minor clean-ups and improvements

[Sebastian Schuberth]

This series introduces various minor clean-ups and improvements to the merge / 
diff tool scripts and documentation.

Sorry, the first version was missing a patch.

Sebastian Schuberth (5):
  Sort the list of tools that support both merging and diffing
alphabetically
  Use variables for the lists of tools that support merging / diffing
  Explicitly list all valid diff tools and document --tool-help as an
option
  Make sure to use Araxis' compare and not e.g. ImageMagick's
  Add a few more code comments and blank lines in guess_merge_tool

 Documentation/git-difftool.txt |  9 ++---
 contrib/completion/git-completion.bash | 15 +++
 git-mergetool--lib.sh  |  6 ++
 mergetools/araxis  |  8 +++-
 4 files changed, 30 insertions(+), 8 deletions(-)

-- 
1.7.11.msysgit.2

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

[PATCH v2 2/5] Use variables for the lists of tools that support merging / diffing

[Sebastian Schuberth]

Also, add a few comments that clarify the meaning of these variables.

Signed-off-by: Sebastian Schuberth sschube...@gmail.com
---
 contrib/completion/git-completion.bash | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index f2c4894..6b9b79d 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1325,17 +1325,24 @@ _git_diff ()
__git_complete_revlist_file
 }
 
+# Tools that support both merging and diffing.
 __git_mergetools_common=araxis bc3 diffuse ecmerge emerge gvimdiff
kdiff3 meld opendiff p4merge tkdiff vimdiff xxdiff
 
 
+# Tools that support diffing.
+__git_difftools=$__git_mergetools_common kcompare
+
+# Tools that support merging.
+__git_mergetools=$__git_mergetools_common tortoisemerge
+
 _git_difftool ()
 {
__git_has_doubledash  return
 
case $cur in
--tool=*)
-   __gitcomp $__git_mergetools_common kompare  
${cur##--tool=}
+   __gitcomp $__git_difftools  ${cur##--tool=}
return
;;
--*)
@@ -1623,7 +1630,7 @@ _git_mergetool ()
 {
case $cur in
--tool=*)
-   __gitcomp $__git_mergetools_common tortoisemerge  
${cur##--tool=}
+   __gitcomp $__git_mergetools  ${cur##--tool=}
return
;;
--*)
-- 
1.7.11.msysgit.2


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

Re: git with large files...

[Kalle Launiala]

2012/7/23 Sitaram Chamarty sitar...@gmail.com:
 On Mon, Jul 23, 2012 at 2:24 AM, Junio C Hamano gits...@pobox.com wrote:
 mer...@stonehenge.com (Randal L. Schwartz) writes:

 Darek == Darek Bridges darek.brid...@me.com writes:

 Darek I use git for many things, but I am trying to work out the
 Darek workflow to use git for deployment.

 Don't.

 Yeah, don't think 'git checkout' is a way to 'deploy'.  Using Git
 as a transport measure is probably fine.

 You can also try
 http://sitaramc.github.com/the-list-and-irc/deploy.html.  Whether it's
 saying you *can* use git for deploying something, or you *can* but
 *should not*, or you *cannot*, will depend on your own thoughts on the
 matter ;-)

Nice summary list of options!

If you combine that with several key concepts:
1. You plan and design to deploy - hence you have separate deploy
repositories dedicated for that
2. You design for modularity and complete audit trail, hence you have this:
http://abstractiondev.files.wordpress.com/2011/12/git-distribution-overview.png

You can combine the staging with any approach, that *tries* to
maintain the local version copy. But if any problem arises in
pull/fetch, simply trash that part and get it from fresh (or just use
the git archive approach).

Now this model would introduce complete and as detailed security
enforcement - as the deployment can validate with certificates (from
the additional catalogue-metadata binding, whether there is authorized
party confirmed signature available for the wished deployable
version).

I don't see much overhead in any of the steps here - and the
deployment is as detailed and as securely controlled as desired. With
just Git (and well, possibly GnuPG or alike common tool for digital
certificate work).

Everything is also transparent - which is very important in having
that complete control and audit trail.
--
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/5] Sort the list of tools that support both merging and diffing alphabetically

[Sebastian Schuberth]

Signed-off-by: Sebastian Schuberth sschube...@gmail.com
---
 contrib/completion/git-completion.bash | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index 5be9dee..f2c4894 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1325,8 +1325,8 @@ _git_diff ()
__git_complete_revlist_file
 }
 
-__git_mergetools_common=diffuse ecmerge emerge kdiff3 meld opendiff
-   tkdiff vimdiff gvimdiff xxdiff araxis p4merge bc3
+__git_mergetools_common=araxis bc3 diffuse ecmerge emerge gvimdiff
+   kdiff3 meld opendiff p4merge tkdiff vimdiff xxdiff
 
 
 _git_difftool ()
-- 
1.7.11.msysgit.2


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

[PATCH v2 4/5] Make sure to use Araxis' compare and not e.g. ImageMagick's

[Sebastian Schuberth]

Signed-off-by: Sebastian Schuberth sschube...@gmail.com
---
 mergetools/araxis | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/mergetools/araxis b/mergetools/araxis
index 64f97c5..aeba1b9 100644
--- a/mergetools/araxis
+++ b/mergetools/araxis
@@ -16,5 +16,11 @@ merge_cmd () {
 }
 
 translate_merge_tool_path() {
-   echo compare
+   # Make sure to use Araxis' compare and not e.g. ImageMagick's.
+   if ls $(dirname $(which compare))/Araxis* /dev/null 21
+   then
+   echo compare
+   else
+   echo $1
+   fi
 }
-- 
1.7.11.msysgit.2


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

Re: [PATCH v2 0/7] i18n for git-am, git-rebase and git-merge

[Jiang Xin]

2012/7/23 Junio C Hamano gits...@pobox.com:
 I find one test case failed, and correct it in PATCH 3/7.

 That test used i18ncmp already, so the update to expected string
 would be sufficient.  I was worried if there were existing tests
 that have been expecting that the output from am/rebase/merge would
 not be i18n'ised and using test_cmp expect actual to compare their
 output with expected result.

If build git with GETTEXT_POISON and test, lots of test cases failed.
It seems that we haven't run these test cases for i18n for a long time.

test of t0006-date.sh failed, because of i18n in commit 7d29af.

7d29a i18n: mark relative dates for translation

test of t0040-parse-options.sh failed, because of i18n in commit 54e6dc7:

54e6d i18n: parseopt: lookup help and argument translations when
showing usage

I will try to fix them in next version of the patches.

Test Summary Report
---
./t0006-date.sh(Wstat: 256 Tests:
45 Failed: 11)
  Failed tests:  1-11
  Non-zero exit status: 1
./t0050-filesystem.sh  (Wstat: 0 Tests: 10
Failed: 0)
  TODO passed:   6
./t0040-parse-options.sh   (Wstat: 256 Tests:
36 Failed: 4)
  Failed tests:  1, 11-12, 27
  Non-zero exit status: 1
./t1502-rev-parse-parseopt.sh  (Wstat: 256 Tests:
8 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
./t1450-fsck.sh(Wstat: 256 Tests:
16 Failed: 1)
  Failed test:  13
  Non-zero exit status: 1
./t1300-repo-config.sh (Wstat: 256 Tests:
104 Failed: 1)
  Failed test:  48
  Non-zero exit status: 1
./t2006-checkout-index-basic.sh(Wstat: 256 Tests:
2 Failed: 2)
  Failed tests:  1-2
  Non-zero exit status: 1
./t2107-update-index-basic.sh  (Wstat: 256 Tests:
3 Failed: 1)
  Failed test:  2
  Non-zero exit status: 1
./t3004-ls-files-basic.sh  (Wstat: 256 Tests:
4 Failed: 2)
  Failed tests:  3-4
  Non-zero exit status: 1
./t3200-branch.sh  (Wstat: 256 Tests:
82 Failed: 2)
  Failed tests:  3, 10
  Non-zero exit status: 1
./t3406-rebase-message.sh  (Wstat: 256 Tests:
6 Failed: 1)
  Failed test:  6
  Non-zero exit status: 1
./t3400-rebase.sh  (Wstat: 256 Tests:
26 Failed: 4)
  Failed tests:  5-8
  Non-zero exit status: 1
./t3501-revert-cherry-pick.sh  (Wstat: 256 Tests:
7 Failed: 2)
  Failed tests:  2-3
  Non-zero exit status: 1
./t4006-diff-mode.sh   (Wstat: 256 Tests:
7 Failed: 4)
  Failed tests:  4-7
  Non-zero exit status: 1
./t4012-diff-binary.sh (Wstat: 256 Tests:
13 Failed: 2)
  Failed tests:  7-8
  Non-zero exit status: 1
./t4035-diff-quiet.sh  (Wstat: 256 Tests:
20 Failed: 3)
  Failed tests:  16, 18, 20
  Non-zero exit status: 1
./t4120-apply-popt.sh  (Wstat: 256 Tests:
8 Failed: 2)
  Failed tests:  3, 5
  Non-zero exit status: 1
./t4133-apply-filenames.sh (Wstat: 256 Tests:
2 Failed: 1)
  Failed test:  2
  Non-zero exit status: 1
./t4200-rerere.sh  (Wstat: 256 Tests:
25 Failed: 2)
  Failed tests:  24-25
  Non-zero exit status: 1
./t4205-log-pretty-formats.sh  (Wstat: 256 Tests:
13 Failed: 1)
  Failed test:  12
  Non-zero exit status: 1
./t4202-log.sh (Wstat: 256 Tests:
33 Failed: 1)
  Failed test:  33
  Non-zero exit status: 1
./t3903-stash.sh   (Wstat: 256 Tests:
46 Failed: 1)
  Failed test:  45
  Non-zero exit status: 1
./t5300-pack-object.sh (Wstat: 256 Tests:
33 Failed: 2)
  Failed tests:  32-33
  Non-zero exit status: 1
./t5505-remote.sh  (Wstat: 256 Tests:
68 Failed: 9)
  Failed tests:  2-3, 6-9, 13, 15, 46
  Non-zero exit status: 1
./t5530-upload-pack-error.sh   (Wstat: 256 Tests:
10 Failed: 1)
  Failed test:  3
  Non-zero exit status: 1
./t6500-gc.sh  (Wstat: 256 Tests:
3 Failed: 2)
  Failed tests:  2-3
  Non-zero exit status: 1
./t6042-merge-rename-corner-cases.sh   (Wstat: 256 Tests:
26 Failed: 1)
  Failed test:  18
  Non-zero exit status: 1
./t6022-merge-rename.sh(Wstat: 256 Tests:
46 Failed: 3)
  Failed tests:  12, 15-16
  Non-zero exit status: 1
./t7008-grep-binary.sh (Wstat: 0 Tests: 20
Failed: 0)
  TODO passed:   12
./t7508-status.sh  (Wstat: 256 Tests:
76 Failed: 1)
  Failed test:  5
  Non-zero exit status: 1
./t7600-merge.sh   (Wstat: 256 Tests:
48 Failed: 1)
  Failed test:  3
  Non-zero exit status: 1
./t9903-bash-prompt.sh (Wstat: 256 Tests:

[PATCH v2 5/5] Add a few more code comments and blank lines in guess_merge_tool

[Sebastian Schuberth]

Signed-off-by: Sebastian Schuberth sschube...@gmail.com
---
 git-mergetool--lib.sh | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index ed630b2..ac9a8f0 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -112,14 +112,17 @@ run_merge_tool () {
 }
 
 guess_merge_tool () {
+   # Add tools that can either do merging or diffing, but not both.
if merge_mode
then
tools=tortoisemerge
else
tools=kompare
fi
+
if test -n $DISPLAY
then
+   # Prefer GTK-based tools under Gnome.
if test -n $GNOME_DESKTOP_SESSION_ID
then
tools=meld opendiff kdiff3 tkdiff xxdiff $tools
@@ -128,6 +131,8 @@ guess_merge_tool () {
fi
tools=$tools gvimdiff diffuse ecmerge p4merge araxis bc3
fi
+
+   # Prefer vimdiff if vim is the default editor.
case ${VISUAL:-$EDITOR} in
*vim*)
tools=$tools vimdiff emerge
@@ -136,6 +141,7 @@ guess_merge_tool () {
tools=$tools emerge vimdiff
;;
esac
+
echo 2 merge tool candidates: $tools
 
# Loop over each candidate and stop when a valid merge tool is found.
-- 
1.7.11.msysgit.2


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

Re: [PATCH v2 0/7] i18n for git-am, git-rebase and git-merge

[Nguyen Thai Ngoc Duy]

On Mon, Jul 23, 2012 at 2:32 PM, Jiang Xin worldhello@gmail.com wrote:
 If build git with GETTEXT_POISON and test, lots of test cases failed.
 It seems that we haven't run these test cases for i18n for a long time.

Gaah.. I should have resent the poison-fix series but so far
procrastination is winning. Will do it soon.
-- 
Duy
--
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] Explicitly list all valid diff tools and document --tool-help as an option

[Sebastian Schuberth]

Signed-off-by: Sebastian Schuberth sschube...@gmail.com
---
 Documentation/git-difftool.txt | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
index 31fc2e3..5dd54f1 100644
--- a/Documentation/git-difftool.txt
+++ b/Documentation/git-difftool.txt
@@ -36,9 +36,12 @@ OPTIONS
 
 -t tool::
 --tool=tool::
-   Use the diff tool specified by tool.  Valid values include
-   emerge, kompare, meld, and vimdiff. Run `git difftool --tool-help`
-   for the list of valid tool settings.
+   Use the diff tool specified by tool.  Valid diff tools are:
+   araxis, bc3, diffuse, ecmerge, emerge, gvimdiff, kcompare, kdiff3,
+   meld, opendiff, p4merge, tkdiff, vimdiff and xxdiff.
+
+--tool-help::
+   List the supported and available diff tools.
 +
 If a diff tool is not specified, 'git difftool'
 will use the configuration variable `diff.tool`.  If the
-- 
1.7.11.msysgit.2


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

Re: [PATCH 2/2] git-remote-mediawiki: allow page names with a ':'

[Matthieu Moy]

Dan Johnson computerdr...@gmail.com writes:

 On Tue, Jul 17, 2012 at 10:06 AM, Matthieu Moy matthieu@imag.fr wrote:
 Traditionnally, pages named Foo:Bar are page 'Bar' in namespace 'Foo'.
 However, it is also possible to call a page Foo:Bar if 'Foo' is not a
 namespace. In this case, the actual name of the page is 'Foo:Bar', in the
 main namespace. Since we can't tell with only the filename, query the
 wiki for a namespace 'Foo' in these cases, but deal with the case where
 no such namespace is found.

 Might not be worth fixing, and it's just a typo in the commit message, but:
 s/Traditionnally/Traditionally/
 ?

Thanks, but the topic is in next already, so it's too late to fix the
commit message.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: GSOC remote-svn

[Matthieu Moy]

Florian Achleitner florian.achleitner.2.6...@gmail.com writes:

 But my remote-helper didn't advertise the refspec capability, so transport-
 helper assumed it imports to refs/heads/master, which is the default import 
 refspec.

The man page for git-remote-helpers says:

refspec refspec
[...] It is recommended that all importers providing the import
capability use this.

I'm not sure I fully understand the rationale, but one difference
between refs/remote name/* and refs/remotes/remote name is that
refs/remotes/ is automatically updated by Git on push, while the private
namespace isn't (it only receives updates when importing).

I played a bit with that it git-remote-mediawiki. There's a
configuration variable mediawiki.dumbPush that controls what push
does. It can either export the local history without touching local
metadata (and then, it is expected that the user does a git pull
--rebase right after to re-import the history), or update the local
metadata (private ref, and notes that keep the local commit -
remote revision number map), so that the next git pull says
Already up to date..

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/7] i18n for git-am, git-rebase and git-merge

[Jiang Xin]

2012/7/23 Nguyen Thai Ngoc Duy pclo...@gmail.com:
 On Mon, Jul 23, 2012 at 2:32 PM, Jiang Xin worldhello@gmail.com wrote:
 If build git with GETTEXT_POISON and test, lots of test cases failed.
 It seems that we haven't run these test cases for i18n for a long time.

 Gaah.. I should have resent the poison-fix series but so far
 procrastination is winning. Will do it soon.

So, I will just try to fix what I am responsible for.

-- 
Jiang Xin
--
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: GSOC remote-svn

[Jonathan Nieder]

Florian Achleitner wrote:

 But when I fetch from a git repo that imported from svn, the notes are not 
 fetched automatically. In this case I currently loose marks and notes.
 What can I do?

In the long term, git will need to be tweaked to automatically fetch
notes along with branches by default.  There are other reasons not
related to remote helpers to want this, too.

In the short term, we can document which ref the notes are expected to
be fetched to.  Maybe someone interested would provide commands like
git remote-testsvn --clone repo and git remote-testsvn
--add-remote nickname repo as a stopgap to set up the appropriate
fetch refspec automatically so the user doesn't have to worry about
it.

Thanks,
Jonathan
--
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] Add a svnrdump-simulator replaying a dump file for testing.

[Florian Achleitner]

To ease testing without depending on a reachable svn server, this
compact python script mimics parts of svnrdumps behaviour.
It requires the remote url to start with sim://.
Start and end revisions are evaluated.
If the requested revision doesn't exist, as it is the case with
incremental imports, if no new commit was added, it returns 1
(like svnrdump).
To allow using the same dump file for simulating multiple
incremental imports the highest revision can be limited by setting
the environment variable SVNRMAX to that value. This simulates the
situation where higher revs don't exist yet.
---
 contrib/svn-fe/svnrdump_sim.py |   53 
 1 file changed, 53 insertions(+)
 create mode 100755 contrib/svn-fe/svnrdump_sim.py

diff --git a/contrib/svn-fe/svnrdump_sim.py b/contrib/svn-fe/svnrdump_sim.py
new file mode 100755
index 000..4701d76
--- /dev/null
+++ b/contrib/svn-fe/svnrdump_sim.py
@@ -0,0 +1,53 @@
+#!/usr/bin/python
+
+Simulates svnrdump by replaying an existing dump from a file, taking care
+of the specified revision range.
+To simulate incremental imports the environment variable SVNRMAX can be set
+to the highest revision that should be available.
+
+import sys, os
+
+
+def getrevlimit():
+   var = 'SVNRMAX'
+   if os.environ.has_key(var):
+   return os.environ[var]
+   return None
+   
+def writedump(url, lower, upper):
+   if url.startswith('sim://'):
+   filename = url[6:]
+   if filename[-1] == '/': filename = filename[:-1] #remove 
terminating slash
+   else:
+   raise ValueError('sim:// url required')
+   f = open(filename, 'r');
+   state = 'header'
+   wroterev = False
+   while(True):
+   l = f.readline()
+   if l == '': break
+   if state == 'header' and l.startswith('Revision-number: '):
+   state = 'prefix'
+   if state == 'prefix' and l == 'Revision-number: %s\n' % lower:
+   state = 'selection'
+   if not upper == 'HEAD' and state == 'selection' and l == 
'Revision-number: %s\n' % upper:
+   break;
+
+   if state == 'header' or state == 'selection':
+   if state == 'selection': wroterev = True
+   sys.stdout.write(l)
+   return wroterev
+
+if __name__ == __main__:
+   if not (len(sys.argv) in (3, 4, 5)):
+   print usage: %s dump URL -rLOWER:UPPER
+   sys.exit(1)
+   if not sys.argv[1] == 'dump': raise NotImplementedError('only dump is 
suppported.')
+   url = sys.argv[2]
+   r = ('0', 'HEAD')
+   if len(sys.argv) == 4 and sys.argv[3][0:2] == '-r':
+   r = sys.argv[3][2:].lstrip().split(':')
+   if not getrevlimit() is None: r[1] = getrevlimit()
+   if writedump(url, r[0], r[1]): ret = 0
+   else: ret = 1
+   sys.exit(ret)
\ No newline at end of file
-- 
1.7.9.5

--
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] Add a svnrdump-simulator replaying a dump file for testing.

[Jonathan Nieder]

Florian Achleitner wrote:

 To ease testing without depending on a reachable svn server, this
 compact python script mimics parts of svnrdumps behaviour.

Thanks.  Mind if I forge your sign-off?
--
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] Add a svnrdump-simulator replaying a dump file for testing.

[Florian Achleitner]

On Monday 23 July 2012 07:59:21 Jonathan Nieder wrote:
 Florian Achleitner wrote:
  To ease testing without depending on a reachable svn server, this
  compact python script mimics parts of svnrdumps behaviour.
 
 Thanks.  Mind if I forge your sign-off?

Ups. No problem, anyways I've added it locally, so here's the new version ..
--
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] Add a svnrdump-simulator replaying a dump file for testing.

[Florian Achleitner]

To ease testing without depending on a reachable svn server, this
compact python script mimics parts of svnrdumps behaviour.
It requires the remote url to start with sim://.
Start and end revisions are evaluated.
If the requested revision doesn't exist, as it is the case with
incremental imports, if no new commit was added, it returns 1
(like svnrdump).
To allow using the same dump file for simulating multiple
incremental imports the highest revision can be limited by setting
the environment variable SVNRMAX to that value. This simulates the
situation where higher revs don't exist yet.

Signed-off-by: Florian Achleitner florian.achleitner.2.6...@gmail.com
---

I had to fix the missing sign-off anyways..

 contrib/svn-fe/svnrdump_sim.py |   53 

 1 file changed, 53 insertions(+)
 create mode 100755 contrib/svn-fe/svnrdump_sim.py

diff --git a/contrib/svn-fe/svnrdump_sim.py b/contrib/svn-fe/svnrdump_sim.py
new file mode 100755
index 000..4701d76
--- /dev/null
+++ b/contrib/svn-fe/svnrdump_sim.py
@@ -0,0 +1,53 @@
+#!/usr/bin/python
+
+Simulates svnrdump by replaying an existing dump from a file, taking care
+of the specified revision range.
+To simulate incremental imports the environment variable SVNRMAX can be set
+to the highest revision that should be available.
+
+import sys, os
+
+
+def getrevlimit():
+   var = 'SVNRMAX'
+   if os.environ.has_key(var):
+   return os.environ[var]
+   return None
+   
+def writedump(url, lower, upper):
+   if url.startswith('sim://'):
+   filename = url[6:]
+   if filename[-1] == '/': filename = filename[:-1] #remove 
terminating slash
+   else:
+   raise ValueError('sim:// url required')
+   f = open(filename, 'r');
+   state = 'header'
+   wroterev = False
+   while(True):
+   l = f.readline()
+   if l == '': break
+   if state == 'header' and l.startswith('Revision-number: '):
+   state = 'prefix'
+   if state == 'prefix' and l == 'Revision-number: %s\n' % lower:
+   state = 'selection'
+   if not upper == 'HEAD' and state == 'selection' and l == 
'Revision-
number: %s\n' % upper:
+   break;
+
+   if state == 'header' or state == 'selection':
+   if state == 'selection': wroterev = True
+   sys.stdout.write(l)
+   return wroterev
+
+if __name__ == __main__:
+   if not (len(sys.argv) in (3, 4, 5)):
+   print usage: %s dump URL -rLOWER:UPPER
+   sys.exit(1)
+   if not sys.argv[1] == 'dump': raise NotImplementedError('only dump is 
suppported.')
+   url = sys.argv[2]
+   r = ('0', 'HEAD')
+   if len(sys.argv) == 4 and sys.argv[3][0:2] == '-r':
+   r = sys.argv[3][2:].lstrip().split(':')
+   if not getrevlimit() is None: r[1] = getrevlimit()
+   if writedump(url, r[0], r[1]): ret = 0
+   else: ret = 1
+   sys.exit(ret)
\ No newline at end of file
-- 
1.7.9.5

--
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] Add a svnrdump-simulator replaying a dump file for testing.

[Junio C Hamano]

Florian Achleitner florian.achleitner.2.6...@gmail.com writes:

 It requires the remote url to start with sim://.
 Start and end revisions are evaluated.

It is a bit unclear where start and end comes from, and if
evaluated is the most important aspect of the handling of these
two values.  Do you mean the tool takes start and end revisions as
arguments?  If so, describe how.  E.g. as two arguments (-rSTART
-rEND)? As an argument that shows a range (-rSTART-END? -rSTART,END)?

Do not answer with It is in the code (I cheated and peeked to find
out it is -rSTART:END, but the reader should not have to peek).

 If the requested revision doesn't exist, as it is the case with
 incremental imports, if no new commit was added, it returns 1
 (like svnrdump).

This sentence does not parse for me.  What is it trying to say?
Requested revision does not exist _where_?  It is unclear how
incremental import and revision doesn't exist are related.  no
new commit was added to _what_ by _whom_?  I presume that nobody is
adding new commit _to_ an existing dump file, and the only thing
this script does is to read and selectively write part of a dump file,
so that would not add any new commit either.

Puzzled.
--
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] Add a svnrdump-simulator replaying a dump file for testing.

[Matthieu Moy]

Florian Achleitner florian.achleitner.2.6...@gmail.com writes:

 I had to fix the missing sign-off anyways..

  contrib/svn-fe/svnrdump_sim.py |   53 
 

You also have whitespace damages (i.e. line wrapping introduced by your
mailer). Using git-send-email avoids this kind of problem (there are
also some advices for some mailers in Documentation/SubmittingPatches).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/5] difftool: Use symlinks when diffing against the worktree

[Junio C Hamano]

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

 Teach difftool's --dir-diff mode to use symlinks to represent
 files from the working copy, and make it the default behavior
 for the non-Windows platforms.

 Using symlinks is simpler and safer since we do not need to
 worry about copying files back into the worktree.
 The old behavior is still available as --no-symlinks.

 Signed-off-by: David Aguilar dav...@gmail.com
 ---
 Handles the case where an editor unlinks the original symlink,
 replacing it with a file.

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

Re: [PATCH v2 2/5] Use variables for the lists of tools that support merging / diffing

[Junio C Hamano]

Sebastian Schuberth sschube...@gmail.com writes:

 Also, add a few comments that clarify the meaning of these variables.

 Signed-off-by: Sebastian Schuberth sschube...@gmail.com
 ---
  contrib/completion/git-completion.bash | 11 +--
  1 file changed, 9 insertions(+), 2 deletions(-)

 diff --git a/contrib/completion/git-completion.bash 
 b/contrib/completion/git-completion.bash
 index f2c4894..6b9b79d 100755
 --- a/contrib/completion/git-completion.bash
 +++ b/contrib/completion/git-completion.bash
 @@ -1325,17 +1325,24 @@ _git_diff ()
   __git_complete_revlist_file
  }
  
 +# Tools that support both merging and diffing.
  __git_mergetools_common=araxis bc3 diffuse ecmerge emerge gvimdiff
   kdiff3 meld opendiff p4merge tkdiff vimdiff xxdiff
  

As the set of merge capable tools is not a superset of diff capable
tools (tortoise can only merge but not diff), perhaps rename this to
__git_diffmerge_tools or something?

 +# Tools that support diffing.
 +__git_difftools=$__git_mergetools_common kcompare
 +
 +# Tools that support merging.
 +__git_mergetools=$__git_mergetools_common tortoisemerge
 +

This patch makes sense to me, but at the same time makes [PATCH 1/5]
a Meh, methinks.

  _git_difftool ()
  {
   __git_has_doubledash  return
  
   case $cur in
   --tool=*)
 - __gitcomp $__git_mergetools_common kompare  
 ${cur##--tool=}
 + __gitcomp $__git_difftools  ${cur##--tool=}
   return
   ;;
   --*)
 @@ -1623,7 +1630,7 @@ _git_mergetool ()
  {
   case $cur in
   --tool=*)
 - __gitcomp $__git_mergetools_common tortoisemerge  
 ${cur##--tool=}
 + __gitcomp $__git_mergetools  ${cur##--tool=}
   return
   ;;
   --*)
--
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/5] Explicitly list all valid diff tools and document --tool-help as an option

[Junio C Hamano]

Sebastian Schuberth sschube...@gmail.com writes:

 Signed-off-by: Sebastian Schuberth sschube...@gmail.com
 ---
  Documentation/git-difftool.txt | 9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)

 diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
 index 31fc2e3..5dd54f1 100644
 --- a/Documentation/git-difftool.txt
 +++ b/Documentation/git-difftool.txt
 @@ -36,9 +36,12 @@ OPTIONS
  
  -t tool::
  --tool=tool::
 - Use the diff tool specified by tool.  Valid values include
 - emerge, kompare, meld, and vimdiff. Run `git difftool --tool-help`
 - for the list of valid tool settings.

I thought we say include because we really do not want to list
millions of tools here, so mild NAK on this part.

 + Use the diff tool specified by tool.  Valid diff tools are:
 + araxis, bc3, diffuse, ecmerge, emerge, gvimdiff, kcompare, kdiff3,
 + meld, opendiff, p4merge, tkdiff, vimdiff and xxdiff.
 +
 +--tool-help::
 + List the supported and available diff tools.

This part is a good addition (but it already is mentioned in the
description of --tool above, so it is more or less a Meh).

  +
  If a diff tool is not specified, 'git difftool'
  will use the configuration variable `diff.tool`.  If 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 v2 4/5] Make sure to use Araxis' compare and not e.g. ImageMagick's

[Junio C Hamano]

Sebastian Schuberth sschube...@gmail.com writes:

 Signed-off-by: Sebastian Schuberth sschube...@gmail.com
 ---
  mergetools/araxis | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

 diff --git a/mergetools/araxis b/mergetools/araxis
 index 64f97c5..aeba1b9 100644
 --- a/mergetools/araxis
 +++ b/mergetools/araxis
 @@ -16,5 +16,11 @@ merge_cmd () {
  }
  
  translate_merge_tool_path() {
 - echo compare
 + # Make sure to use Araxis' compare and not e.g. ImageMagick's.
 + if ls $(dirname $(which compare))/Araxis* /dev/null 21

Use of which in scripts that are meant to be portable is a no-no.
Some platforms would say compare is /usr/local/bin/compare instead
of saying /usr/local/bin/compare.

 + then
 + echo compare
 + else
 + echo $1
 + fi
  }
--
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

mergetool: support --tool-help option like difftool does

[Junio C Hamano]

This way we do not have to risk the list of tools go out of sync
between the implementation and the documentation.

Signed-off-by: Junio C Hamano gits...@pobox.com
---
Junio C Hamano gits...@pobox.com writes:

 +--tool-help::
 +List the supported and available diff tools.

 This part is a good addition (but it already is mentioned in the
 description of --tool above, so it is more or less a Meh).

I noticed that the main while loop has style violations in its
case/esac, but I left it as-is.  Reindenting it would be a low
hanging fruit janitor patch that would be a separate topic.

 git-mergetool--lib.sh |  6 +-
 git-mergetool.sh  | 42 +-
 2 files changed, 46 insertions(+), 2 deletions(-)

diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index ed630b2..f730253 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -111,7 +111,7 @@ run_merge_tool () {
return $status
 }
 
-guess_merge_tool () {
+list_merge_tool_candidates () {
if merge_mode
then
tools=tortoisemerge
@@ -136,6 +136,10 @@ guess_merge_tool () {
tools=$tools emerge vimdiff
;;
esac
+}
+
+guess_merge_tool () {
+   list_merge_tool_candidates
echo 2 merge tool candidates: $tools
 
# Loop over each candidate and stop when a valid merge tool is found.
diff --git a/git-mergetool.sh b/git-mergetool.sh
index a9f23f7..0db0c44 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -8,7 +8,7 @@
 # at the discretion of Junio C Hamano.
 #
 
-USAGE='[--tool=tool] [-y|--no-prompt|--prompt] [file to merge] ...'
+USAGE='[--tool=tool] [--tool-help] [-y|--no-prompt|--prompt] [file to merge] 
...'
 SUBDIRECTORY_OK=Yes
 OPTIONS_SPEC=
 TOOL_MODE=merge
@@ -284,11 +284,51 @@ merge_file () {
 return 0
 }
 
+show_tool_help () {
+   TOOL_MODE=merge
+   list_merge_tool_candidates
+   unavailable= available= LF='
+'
+   for i in $tools
+   do
+   merge_tool_path=$(translate_merge_tool_path $i)
+   if type $merge_tool_path /dev/null 21
+   then
+   available=$available$i$LF
+   else
+   unavailable=$unavailable$i$LF
+   fi
+   done
+   if test -n $available
+   then
+   echo 'git mergetool --tool=tool' may be set to one of the 
following:
+   echo $available | sort | sed -e 's/^/ /'
+   else
+   echo No suitable tool for 'git mergetool --tool=tool' found.
+   fi
+   if test -n $unavailable
+   then
+   echo
+   echo 'The following tools are valid, but not currently 
available:'
+   echo $unavailable | sort | sed -e 's/^/   /'
+   fi
+   if test -n $unavailable$available
+   then
+   echo
+   echo Some of the tools listed above only work in a windowed
+   echo environment. If run in a terminal-only session, they will 
fail.
+   fi
+   exit 0
+}
+
 prompt=$(git config --bool mergetool.prompt || echo true)
 
 while test $# != 0
 do
 case $1 in
+   --tool-help)
+   show_tool_help
+   ;;
-t|--tool*)
case $#,$1 in
*,*=*)
--
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: empty ident name trashes commit message

[Jeff King]

On Sat, Jul 21, 2012 at 03:26:26PM +0100, Ramana Kumar wrote:

 If I forget to set user.email and user.name config options and do a commit
 (possibly the --amend option also required to make this show up), then git
 1.7.11.2 will drops me into an editor for a commit message, then after that
 complain with the fatal message:
 
*** Please tell me who you are.
 [...]

Hmm. I think this is an artifact of running --amend. In the normal case,
we check the author ident beforehand. But in the --amend case, we take
the existing author, but then fail trying to generate the committer
ident. So we could probably do better by checking both explicitly
beforehand.

fatal: empty ident name (for ramana.ku...@gmail.com) not allowed

Usually we would fall back to your name from /etc/passwd. I guess it is
blank on your system.

 The commit message I wrote is now lost. This is bad behaviour - the error
 should happen before one writes the commit message, or the message should be
 saved somewhere.

It's not lost. It's in .git/COMMIT_EDITMSG.

We could probably do a better job of informing the user of this when
commit dies prematurely.

-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] Solve git-submodule issues with detached work trees

[Jens Lehmann]

Am 23.07.2012 07:09, schrieb Junio C Hamano:
 Daniel Graña dan...@gmail.com writes:
 
 A common way to track dotfiles with git is using GIT_DIR and
 GIT_WORK_TREE to move repository out of ~/.git with something like:

 git init --bare ~/.dotfiles
 alias dotfiles=GIT_DIR=~/.dotfiles GIT_WORK_TREE=~ git

 dotfiles add ~/.bashrc
 dotfiles commit -a -m add my bashrc
 ...

 but git-submodule complains when trying to add submodules:

 dotfiles submodule add http://path.to/submodule
 fatal: working tree '/home/user' already exists.

 git --git-dir ~/.dotfiles submodule add http://path.to/submodule
 fatal: /usr/lib/git-core/git-submodule cannot be used without a
 working tree.

 Signed-off-by: Daniel Graña dan...@gmail.com
 ---
 
 I think this is in line with what we discussed earlier on list when
 the interaction between GIT_DIR/GIT_WORK_TREE and submodules came up
 the last time.  Jens?

Yes, I think this is the only way submodules in current git can
be used with the GIT_DIR and GIT_WORK_TREE environment variables:
set them when adding or initializing the submodule and always use
the same settings when accessing them later. Daniel's dotfile
alias achieves exactly that, so his fix looks good. But I agree
the tests should be improved as you already pointed out.
--
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: empty ident name trashes commit message

[Ramana Kumar]

On Mon, Jul 23, 2012 at 6:27 PM, Jeff King p...@peff.net wrote:
 On Sat, Jul 21, 2012 at 03:26:26PM +0100, Ramana Kumar wrote:

 If I forget to set user.email and user.name config options and do a commit
 (possibly the --amend option also required to make this show up), then git
 1.7.11.2 will drops me into an editor for a commit message, then after that
 complain with the fatal message:

*** Please tell me who you are.
 [...]

 Hmm. I think this is an artifact of running --amend. In the normal case,
 we check the author ident beforehand. But in the --amend case, we take
 the existing author, but then fail trying to generate the committer
 ident. So we could probably do better by checking both explicitly
 beforehand.

Indeed.

 Usually we would fall back to your name from /etc/passwd. I guess it is
 blank on your system.

 The commit message I wrote is now lost. [...]

 It's not lost. It's in .git/COMMIT_EDITMSG.

 We could probably do a better job of informing the user of this when
 commit dies prematurely.

 -Peff

I agree, and thank you very much for those two useful pieces of
information! (names stored in /etc/passwd and saving of
.git/COMMIT_EDITMSG).
--
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

Enhanced git branch list (proposal)

[John Bartholomew]

I find the output of `git branch' to be quite bare, and would like to
see more information; most importantly, what the state of the branch
is in relation to its upstream. For some time I have been using my
own script to do this. It produces output like this:

$ git lsb
  commodity-market-lua [behind 'brianetta/commodity-market-lua' by 2
commits]
  filesystem [up-to-date with 'jpab/filesystem']
  fix-ring-blending [ahead of 'jpab/fix-ring-blending' by 1 commit]
  galaxy-refactor
  galaxy-refactor-2 [diverged from 'jpab/galaxy-refactor', by 6
commits/626 commits (us/them)]
  hud-pitch-ladder [up-to-date with 'jpab/hud-pitch-ladder']
= issue-1388
  issue-695
  lmr-mtllib-improvements
  marcel-stations
* master [up-to-date with 'jpab/master']
  refcounted-body [up-to-date with 'jpab/refcounted-body']
  string-formatter [up-to-date with 'jpab/string-formatter']

The first column indicates the relation to HEAD: '*' marks the current
head, '=' marks a branch which is identical with the current HEAD.

Branches which have a configured upstream (branch.remote and
branch.merge are set) show the relation to the corresponding remote
branch.

Some key text ('up-to-date', 'ahead', 'behind' or 'diverged', and the
name of the current HEAD) is displayed with colour if colour is
enabled.

Arguments can be passed to show remote branches (for all remotes, or
for a specified remote), or all branches, and to show each branch
in relation to a specified target branch instead of the configured
remote tracking branch.

I would like to know whether there is any interest in incorporating
this functionality into the main git distribution, either as a
separate command, or within `git branch'. For my purposes I have it
aliased under the name `git lsb' for `list branches'.

You can examine the script I'm using for this at:

https://github.com/johnbartholomew/gitvoodoo/blob/master/bin/git-xbranch

Regards,

John B

--
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] Solve git-submodule issues with detached work trees

[Junio C Hamano]

Jens Lehmann jens.lehm...@web.de writes:

 Am 23.07.2012 07:09, schrieb Junio C Hamano:
 Daniel Graña dan...@gmail.com writes:
 
 A common way to track dotfiles with git is using GIT_DIR and
 GIT_WORK_TREE to move repository out of ~/.git with something like:

 git init --bare ~/.dotfiles
 alias dotfiles=GIT_DIR=~/.dotfiles GIT_WORK_TREE=~ git

 dotfiles add ~/.bashrc
 dotfiles commit -a -m add my bashrc
 ...

 but git-submodule complains when trying to add submodules:

 dotfiles submodule add http://path.to/submodule
 fatal: working tree '/home/user' already exists.

 git --git-dir ~/.dotfiles submodule add http://path.to/submodule
 fatal: /usr/lib/git-core/git-submodule cannot be used without a
 working tree.

 Signed-off-by: Daniel Graña dan...@gmail.com
 ---
 
 I think this is in line with what we discussed earlier on list when
 the interaction between GIT_DIR/GIT_WORK_TREE and submodules came up
 the last time.  Jens?

 Yes, I think this is the only way submodules in current git can
 be used with the GIT_DIR and GIT_WORK_TREE environment variables:
 set them when adding or initializing the submodule and always use
 the same settings when accessing them later. Daniel's dotfile
 alias achieves exactly that, so his fix looks good. But I agree
 the tests should be improved as you already pointed out.

Thanks for a quick review.  The the only way ... in current git can
be used part makes it sound as if it is a somewhat suboptimal ugly
workaround, but if that is what you meant, what is a more optimal
and less ugly way that you have in mind?

If you want to move .git out of way with GIT_DIR and if you want to
sit somewhere different from the top of your working tree, you must
use GIT_WORK_TREE (or core.worktree) to tell where the top resides,
whether your project use submodules or not, so I do not think it is
an ugly workaround but is the one true way to use such a dismembered
layout, I would think.
--
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] Solve git-submodule issues with detached work trees

[Daniel Graña]

On Mon, Jul 23, 2012 at 2:38 PM, Jens Lehmann jens.lehm...@web.de wrote:
 Am 23.07.2012 07:09, schrieb Junio C Hamano:
 Daniel Graña dan...@gmail.com writes:

 A common way to track dotfiles with git is using GIT_DIR and
 GIT_WORK_TREE to move repository out of ~/.git with something like:

 git init --bare ~/.dotfiles
 alias dotfiles=GIT_DIR=~/.dotfiles GIT_WORK_TREE=~ git

 dotfiles add ~/.bashrc
 dotfiles commit -a -m add my bashrc
 ...

 but git-submodule complains when trying to add submodules:

 dotfiles submodule add http://path.to/submodule
 fatal: working tree '/home/user' already exists.

 git --git-dir ~/.dotfiles submodule add http://path.to/submodule
 fatal: /usr/lib/git-core/git-submodule cannot be used without a
 working tree.

 Signed-off-by: Daniel Graña dan...@gmail.com
 ---

 I think this is in line with what we discussed earlier on list when
 the interaction between GIT_DIR/GIT_WORK_TREE and submodules came up
 the last time.  Jens?

 Yes, I think this is the only way submodules in current git can
 be used with the GIT_DIR and GIT_WORK_TREE environment variables:
 set them when adding or initializing the submodule and always use
 the same settings when accessing them later. Daniel's dotfile
 alias achieves exactly that, so his fix looks good. But I agree
 the tests should be improved as you already pointed out.

Hi Jens, Junio.

Thanks for reviewing the patch, glad to hear this is acceptable way to
fix my itch.

I will work soon on getting the test cases improved and the patch
submitted without line wrapping.

thanks again,
Daniel.
--
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] Solve git-submodule issues with detached work trees

[Richard Hartmann]

On Mon, Jul 23, 2012 at 7:09 AM, Junio C Hamano gits...@pobox.com wrote:

 I think this is in line with what we discussed earlier on list when
 the interaction between GIT_DIR/GIT_WORK_TREE and submodules came up
 the last time.  Jens?

Yes, it is.

I still have your email marked as TODO to get back to you as I am
still unsure how to solve this whole mess in a way that works with
vcsh[1].


Richard

PS: Thanks for being so dedicated you all. I really do appreciate this
more than you most likely suspect.

[1] vcsh
--
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] Solve git-submodule issues with detached work trees

[Richard Hartmann]

PPS: Yes, I know that I am replying in a patch thread. I will try it asap.
--
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] Use variables for the lists of tools that support merging / diffing

[Sebastian Schuberth]

Also, add a few comments that clarify the meaning of these variables and
sort the list of tools alphabetically.

Signed-off-by: Sebastian Schuberth sschube...@gmail.com
---
 contrib/completion/git-completion.bash | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index 5be9dee..4a76120 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1325,17 +1325,24 @@ _git_diff ()
__git_complete_revlist_file
 }
 
-__git_mergetools_common=diffuse ecmerge emerge kdiff3 meld opendiff
-   tkdiff vimdiff gvimdiff xxdiff araxis p4merge bc3
+# Tools that support both merging and diffing.
+__git_diffmerge_tools=araxis bc3 diffuse ecmerge emerge gvimdiff
+   kdiff3 meld opendiff p4merge tkdiff vimdiff xxdiff
 
 
+# Tools that support diffing.
+__git_difftools=$__git_diffmerge_tools kcompare
+
+# Tools that support merging.
+__git_mergetools=$__git_diffmerge_tools tortoisemerge
+
 _git_difftool ()
 {
__git_has_doubledash  return
 
case $cur in
--tool=*)
-   __gitcomp $__git_mergetools_common kompare  
${cur##--tool=}
+   __gitcomp $__git_difftools  ${cur##--tool=}
return
;;
--*)
@@ -1623,7 +1630,7 @@ _git_mergetool ()
 {
case $cur in
--tool=*)
-   __gitcomp $__git_mergetools_common tortoisemerge  
${cur##--tool=}
+   __gitcomp $__git_mergetools  ${cur##--tool=}
return
;;
--*)
-- 
1.7.11.msysgit.2


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

Cannot delete weirdly named branch

[abhisek...@gmail.com]

Hi,

I am a new user to git and I found an interesting behavior in git. I
am not sure if this is a bug, but I thought I would report this
anyway!

So I can create a local branch called --tracking like this:
git checkout -b --tracking origin/somebranch
I messed up the syntax while trying to create a tracking branch, but
this resulted in a local branch called --tracking.

Now I cannot delete this branch. Running:
git branch -d --tracking
gives an error: unknown option `tracking'

Using quotes around the name does not help. Is there another command I
can use to delete this branch?

Thank you!
--
Abhisek
Live Long and Prosper
--
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: Enhanced git branch list (proposal)

[Thomas Rast]

John Bartholomew jpa.bartholo...@gmail.com writes:

 I find the output of `git branch' to be quite bare, and would like to
 see more information; most importantly, what the state of the branch
 is in relation to its upstream.

That is already present: just run git branch -vv.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Cannot delete weirdly named branch

[Junio C Hamano]

abhisek...@gmail.com abhisek...@gmail.com writes:

 Now I cannot delete this branch. Running:
 git branch -d --tracking
 gives an error: unknown option `tracking'

I do not think this is supposed to work, but it does by accident.

$ git branch -d -- --tracking
Deleted branch --tracking (was 8670e20).

A more recent git would not let you create such a branch to begin
with. Perhaps time to upgrade?
--
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: empty ident name trashes commit message

[Jeff King]

On Mon, Jul 23, 2012 at 01:27:26PM -0400, Jeff King wrote:

 On Sat, Jul 21, 2012 at 03:26:26PM +0100, Ramana Kumar wrote:
 
  If I forget to set user.email and user.name config options and do a commit
  (possibly the --amend option also required to make this show up), then git
  1.7.11.2 will drops me into an editor for a commit message, then after that
  complain with the fatal message:
  
 *** Please tell me who you are.
  [...]
 
 Hmm. I think this is an artifact of running --amend. In the normal case,
 we check the author ident beforehand. But in the --amend case, we take
 the existing author, but then fail trying to generate the committer
 ident. So we could probably do better by checking both explicitly
 beforehand.

It seems we already had such a check, but it was not done correctly.
This is fixed by patch 2 below.

  The commit message I wrote is now lost. This is bad behaviour - the error
  should happen before one writes the commit message, or the message should be
  saved somewhere.
 
 It's not lost. It's in .git/COMMIT_EDITMSG.
 
 We could probably do a better job of informing the user of this when
 commit dies prematurely.

And patch 3 improves this situation.

  [1/3]: advice: pass varargs to strbuf_vaddf, not strbuf_addf
  [2/3]: commit: check committer identity more strictly
  [3/3]: commit: give a hint when a commit message has been abandoned

-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

[PATCH 1/3] advice: pass varargs to strbuf_vaddf, not strbuf_addf

[Jeff King]

The advise() function takes a variable number of arguments
and converts them into a va_list object to pass to strbuf
for handling. However, we accidentally called strbuf_addf
(that takes a variable number of arguments) instead of
strbuf_vaddf (that takes a va_list).

This bug dates back to v1.7.8.1-1-g23cb5bf, but we never
noticed because none of the current callers passes a string
with a format specifier in it. And the compiler did not
notice because the format string is not available at
compile time.

Signed-off-by: Jeff King p...@peff.net
---
 advice.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/advice.c b/advice.c
index a492eea..edfbd4a 100644
--- a/advice.c
+++ b/advice.c
@@ -32,7 +32,7 @@ void advise(const char *advice, ...)
const char *cp, *np;
 
va_start(params, advice);
-   strbuf_addf(buf, advice, params);
+   strbuf_vaddf(buf, advice, params);
va_end(params);
 
for (cp = buf.buf; *cp; cp = np) {
-- 
1.7.10.5.40.g059818d

--
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/3] commit: check committer identity more strictly

[Jeff King]

The identity of the committer will ultimately be pulled from
the ident code by commit_tree(). However, we make an attempt
to check the author and committer identity early, before the
user has done any manual work like inputting a commit
message. That lets us abort without them having to worry
about salvaging the work from .git/COMMIT_EDITMSG.

The early check for committer ident does not use the
IDENT_STRICT flag, meaning that it would not find an empty
name field. The motivation was presumably because we did not
want to be too restrictive, as later calls might be more lax
(for example, when we create the reflog entry, we do not
care too much about a real name). However, because
commit_tree will always get a strict identity to put in the
commit object itself, there is no point in being lax only to
die later (and in fact it is harmful, because the user will
have wasted time typing their commit message).

Incidentally, this bug was masked prior to 060d4bb, as the
initial loose call would taint the later strict call. So the
commit would succeed (albeit with a bogus committer line in
the commit object), and nobody noticed that our early check
did not match the later one.

Signed-off-by: Jeff King p...@peff.net
---
 builtin/commit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/builtin/commit.c b/builtin/commit.c
index 95eeab1..20cef95 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -725,7 +725,7 @@ static int prepare_to_commit(const char *index_file, const 
char *prefix,
strbuf_release(sb);
 
/* This checks if committer ident is explicitly given */
-   strbuf_addstr(committer_ident, git_committer_info(0));
+   strbuf_addstr(committer_ident, git_committer_info(IDENT_STRICT));
if (use_editor  include_status) {
char *ai_tmp, *ci_tmp;
if (whence != FROM_COMMIT)
-- 
1.7.10.5.40.g059818d

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

[PATCH 3/3] commit: give a hint when a commit message has been abandoned

[Jeff King]

If we launch an editor for the user to create a commit
message, they may put significant work into doing so.
Typically we try to check common mistakes that could cause
the commit to fail early, so that we die before the user
goes to the trouble.

We may still experience some errors afterwards, though; in
this case, the user is given no hint that their commit
message has been saved. Let's tell them where it is.

Signed-off-by: Jeff King p...@peff.net
---
I did not bother protecting this with advice.* config, as it is unlikely
to come up regularly. If somebody cares, they are welcome to add it on
top.

 builtin/commit.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/builtin/commit.c b/builtin/commit.c
index 20cef95..149e07d 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -116,6 +116,16 @@ static enum {
STATUS_FORMAT_PORCELAIN
 } status_format = STATUS_FORMAT_LONG;
 
+static int mention_abandoned_message;
+static void maybe_mention_abandoned_message(void)
+{
+   if (!mention_abandoned_message)
+   return;
+   advise(_(Your commit message has been saved in '%s' and will be\n
+overwritten by the next invocation of \git commit\.),
+  git_path(commit_editmsg));
+}
+
 static int opt_parse_m(const struct option *opt, const char *arg, int unset)
 {
struct strbuf *buf = opt-value;
@@ -848,6 +858,8 @@ static int prepare_to_commit(const char *index_file, const 
char *prefix,
_(Please supply the message using either -m or -F 
option.\n));
exit(1);
}
+   atexit(maybe_mention_abandoned_message);
+   mention_abandoned_message = 1;
}
 
if (!no_verify 
@@ -1532,11 +1544,13 @@ int cmd_commit(int argc, const char **argv, const char 
*prefix)
if (template_untouched(sb)  !allow_empty_message) {
rollback_index_files();
fprintf(stderr, _(Aborting commit; you did not edit the 
message.\n));
+   mention_abandoned_message = 0;
exit(1);
}
if (message_is_empty(sb)  !allow_empty_message) {
rollback_index_files();
fprintf(stderr, _(Aborting commit due to empty commit 
message.\n));
+   mention_abandoned_message = 0;
exit(1);
}
 
@@ -1579,6 +1593,7 @@ int cmd_commit(int argc, const char **argv, const char 
*prefix)
die(_(cannot update HEAD ref));
}
 
+   mention_abandoned_message = 0;
unlink(git_path(CHERRY_PICK_HEAD));
unlink(git_path(REVERT_HEAD));
unlink(git_path(MERGE_HEAD));
-- 
1.7.10.5.40.g059818d
--
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: mergetool: support --tool-help option like difftool does

[Sebastian Schuberth]

On 23.07.2012 19:21, Junio C Hamano wrote:

 This way we do not have to risk the list of tools go out of sync
 between the implementation and the documentation.
 
 Signed-off-by: Junio C Hamano gits...@pobox.com

Thanks! I've squashed this with

[PATCH v2 5/5] Add a few more code comments and blank lines in guess_merge_tool

and parts of

[PATCH 3/5] Explicitly list all valid diff tools and document --tool-help as an 
option

and adjusted the docs for git-mergetool accordingly.

-- 
Sebastian Schuberth
--
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] mergetool: support --tool-help option like difftool does

[Sebastian Schuberth]

This way we do not have to risk the list of tools go out of sync
between the implementation and the documentation. Adjust the documentation
accordingly to not explicitly list the tools but refer to --tool-help.

Signed-off-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Sebastian Schuberth sschube...@gmail.com
---
 Documentation/git-difftool.txt  |  7 ---
 Documentation/git-mergetool.txt |  8 
 git-mergetool--lib.sh   | 11 ++-
 git-mergetool.sh| 42 -
 4 files changed, 59 insertions(+), 9 deletions(-)

diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
index 31fc2e3..0bdfe35 100644
--- a/Documentation/git-difftool.txt
+++ b/Documentation/git-difftool.txt
@@ -36,9 +36,10 @@ OPTIONS
 
 -t tool::
 --tool=tool::
-   Use the diff tool specified by tool.  Valid values include
-   emerge, kompare, meld, and vimdiff. Run `git difftool --tool-help`
-   for the list of valid tool settings.
+   Use the diff tool specified by tool.
+
+--tool-help::
+   List all supported values for tool.
 +
 If a diff tool is not specified, 'git difftool'
 will use the configuration variable `diff.tool`.  If the
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 2a49de7..99e53b1 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -26,10 +26,10 @@ OPTIONS
 ---
 -t tool::
 --tool=tool::
-   Use the merge resolution program specified by tool.
-   Valid merge tools are:
-   araxis, bc3, diffuse, ecmerge, emerge, gvimdiff, kdiff3,
-   meld, opendiff, p4merge, tkdiff, tortoisemerge, vimdiff and xxdiff.
+   Use the merge tool specified by tool.
+
+--tool-help::
+   List all supported values for tool.
 +
 If a merge resolution program is not specified, 'git mergetool'
 will use the configuration variable `merge.tool`.  If the
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index ed630b2..f0865d4 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -111,15 +111,18 @@ run_merge_tool () {
return $status
 }
 
-guess_merge_tool () {
+list_merge_tool_candidates () {
+   # Add tools that can either do merging or diffing, but not both.
if merge_mode
then
tools=tortoisemerge
else
tools=kompare
fi
+
if test -n $DISPLAY
then
+   # Prefer GTK-based tools under Gnome.
if test -n $GNOME_DESKTOP_SESSION_ID
then
tools=meld opendiff kdiff3 tkdiff xxdiff $tools
@@ -128,6 +131,8 @@ guess_merge_tool () {
fi
tools=$tools gvimdiff diffuse ecmerge p4merge araxis bc3
fi
+
+   # Prefer vimdiff if vim is the default editor.
case ${VISUAL:-$EDITOR} in
*vim*)
tools=$tools vimdiff emerge
@@ -136,6 +141,10 @@ guess_merge_tool () {
tools=$tools emerge vimdiff
;;
esac
+}
+
+guess_merge_tool () {
+   list_merge_tool_candidates
echo 2 merge tool candidates: $tools
 
# Loop over each candidate and stop when a valid merge tool is found.
diff --git a/git-mergetool.sh b/git-mergetool.sh
index a9f23f7..0db0c44 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -8,7 +8,7 @@
 # at the discretion of Junio C Hamano.
 #
 
-USAGE='[--tool=tool] [-y|--no-prompt|--prompt] [file to merge] ...'
+USAGE='[--tool=tool] [--tool-help] [-y|--no-prompt|--prompt] [file to merge] 
...'
 SUBDIRECTORY_OK=Yes
 OPTIONS_SPEC=
 TOOL_MODE=merge
@@ -284,11 +284,51 @@ merge_file () {
 return 0
 }
 
+show_tool_help () {
+   TOOL_MODE=merge
+   list_merge_tool_candidates
+   unavailable= available= LF='
+'
+   for i in $tools
+   do
+   merge_tool_path=$(translate_merge_tool_path $i)
+   if type $merge_tool_path /dev/null 21
+   then
+   available=$available$i$LF
+   else
+   unavailable=$unavailable$i$LF
+   fi
+   done
+   if test -n $available
+   then
+   echo 'git mergetool --tool=tool' may be set to one of the 
following:
+   echo $available | sort | sed -e 's/^/ /'
+   else
+   echo No suitable tool for 'git mergetool --tool=tool' found.
+   fi
+   if test -n $unavailable
+   then
+   echo
+   echo 'The following tools are valid, but not currently 
available:'
+   echo $unavailable | sort | sed -e 's/^/   /'
+   fi
+   if test -n $unavailable$available
+   then
+   echo
+   echo Some of the tools listed above only work in a windowed
+   echo environment. If run in a terminal-only session, they will 
fail.
+   fi
+   exit 0
+}
+
 prompt=$(git config --bool mergetool.prompt || echo 

[GSoC] Designing a faster index format - Progress report week 14

[Thomas Gummerer]

== Work done in the previous 13 weeks ==

- Definition of a tentative index file v5 format [1]. This differs
  from the proposal in making it possible to bisect the directory
  entries and file entries, to do a binary search. The exact bits
  for each section were also defined. To further compress the index,
  along with prefix compression, the stat data is hashed, since
  it's only used for equality comparison, but the plain data is
  never used.
  Thanks to Michael Haggerty, Nguyen Thai Ngoc Duy, Thomas Rast
  and Robin Rosenberg for feedback.
- Prototype of a converter from the index format v2/v3 to the index
  format v5. [2] The converter reads the index from a git repository,
  can output parts of the index (header, index entries as in
  git ls-files --debug, cache tree as in test-dump-cache-tree, or
  the reuc data). Then it writes the v5 index file format to
  .git/index-v5. Thanks to Michael Haggerty for the code review.
- Prototype of a reader for the new index file format. [3] The
  reader has mainly the purpose to show the algorithm used to read
  the index lexicographically sorted after the full name which is
  required by the current internal memory format. Big thanks for
  reviewing this code and giving me advice on refactoring goes
  to Michael Haggerty.
- Read the on-disk index file format and translate it to the current
  in memory format. This doesn't include reading any of the current
  extensions, which are now part of the main index. The code again
  is on github. [4] Thanks for reviewing the first steps to Thomas
  Rast.
- Read the cache-tree data (formerly an extension, now it's integrated
  with the rest of the directory data) from the new ondisk format.
  There are still a few optimizations to do in this algorithm.
- Started implementing the API (suggested by Duy), but it's still
  in the very early stages. There is one commit for this on GitHub [1],
  but it's a very early work in progress.
- Started implementing the writer, which extracts the directories from
  the in-memory format, and writes the header and the directories to
  disk. The algorithm uses a hash-table instead of a simple list,
  to avoid many corner cases.
- Implemented writing the file block to disk, and basic tests from the
  test suite are running fine, not including tests that require
  conflicted data or the cache-tree to work, which both are not
  implemented yet.
- Started implementing a patch to introduce a ce_namelen field in
  struct cache_entry and drop the name length from the flags. [5]
  Thanks to Junio, Duy and Thomas for reviews and suggestions for
  improving it.
- Implemented the cache-tree and conflict data writing to the
  index-v5 file.

== Work done in the last week ==

- Fixed a few bugs in cache-tree and conflict writing in my index-v5
  code.
- I visited Thomas in Zuerich this weekend, as some of you may
  have noticed on the mailing list, thanks a lot for the
  hospitality. And thanks also to Tomas for the company on saturday
  night.
- With the help of Thomas I fixed the resolve undo data writing,
  and a couple more bugs in my code, so that the test suite passes
  with INDEX_VERSION_DEFAULT = 5.
- We added a POC, for partial loading in git grep. This is still a
  pretty hacky implementation, but it demonstrates pretty well
  how much can be gained. Here are the timings Thomas posted on
  IRC yesterday. The improvements of ls-files are not drastic
  compared to index-v4, but git greps in subdirs benefit a lot
  from partial loading.

  Test  this tree
  ---
  0002.2: v[23]: ls-files   0.13(0.11+0.02)
  0002.3: v[23]: grep nonexistent -- subdir 0.12(0.10+0.02)
  0002.5: v4: ls-files  0.11(0.09+0.01)
  0002.6: v4: grep nonexistent -- subdir0.10(0.08+0.02)
  0002.8: v5: ls-files  0.10(0.07+0.02)
  0002.9: v5: grep nonexistent -- subdir0.01(0.00+0.00)

- All changes again are in my repository on github, in case someone
  wants to try them out. [4]

== Outlook for the next week ==

- Refactoring of the code. There are still some code smells in the
  current code, which need to be refactored.
- There are also still some possible optimizations for the code,
  which will be included.
- I'll also bring the reader up to date again, and make it possible
  for it to update a single index entry, to test the implementation 
  of rereading a entry when the crc is wrong (for the future partial
  write, both writer and reader side still have to be implemented).

[1] https://github.com/tgummerer/git/wiki/Index-file-format-v5
[2] https://github.com/tgummerer/git/blob/pythonprototype/git-convert-index.py
[3] https://github.com/tgummerer/git/blob/pythonprototype/git-read-index-v5.py
[4] https://github.com/tgummerer/git/tree/index-v5
[5] http://thread.gmane.org/gmane.comp.version-control.git/200997
--
To unsubscribe from this list: send the line 

Re: [PATCH 2/2] Document rev^! and rev^@ as revision specifiers

[Junio C Hamano]

Max Horn m...@quendi.de writes:

 
 On 06.07.2012, at 21:18, Junio C Hamano wrote:

 Max Horn m...@quendi.de writes:
 
 +'rev{caret}!', e.g. 'HEAD{caret}!'::
 +  A suffix '{caret}' followed by an exclamation mark
 +  means commit 'rev' but forces all of its parents to be excluded. For
 +  commands that deal with a single revision, this is the same as 'rev.
 
 Is this sentence correct?  git commit -C 'HEAD^!' might be a
 command that expects a single revision, but I do not think it is the
 same as git commit -C HEAD.
 
 Ignoring the exact words I used for the moment, what I meant is
 that these two commands should be functionally
 equivalent. Aren't they?
 
 No.  When a single commit is wanted HEAD^! shouldn't be used, and
 they cannot be functionally equivalent.  I haven't tried but I think
 commit -C HEAD^!  would give you a syntax error.

 Indeed, it says
  fatal: could not lookup commit HEAD^!

 I'll iterate over this once more.

Let's do this instead.

-- 8 --
Subject: Enumerate revision range specifiers in the documentation

It was a bit hard to learn how rev^@, rev^! and various other
forms of range specification are used, because they were discussed
mostly in the prose part of the documentation, unlike various forms
of extended SHA-1 expressions that are listed in enumerated list.

Also add a few more examples showing use of rev, rev..rev and
rev^! forms, stolen from a patch by Max Horn.

Signed-off-by: Junio C Hamano gits...@pobox.com
---
 Documentation/revisions.txt | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index f4f6f28..6506ec6 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -218,13 +218,44 @@ and its parent commits exist.  The 'r1{caret}@' notation 
means all
 parents of 'r1'.  'r1{caret}!' includes commit 'r1' but excludes
 all of its parents.
 
+To summarize:
+
+'rev'::
+   Include commits that are reachable from (i.e. ancestors of)
+   rev.
+
+'{caret}rev'::
+   Exclude commits that are reachable from (i.e. ancestors of)
+   rev.
+
+'rev1..rev2'::
+   Include commits that are reachable from rev2 but exclude
+   those that are reachable from rev1.
+
+'rev1...rev2'::
+   Include commits that are reachable from either rev1 or
+   rev2 but exclude those that are reachable from both.
+
+'rev{caret}@', e.g. 'HEAD{caret}@'::
+  A suffix '{caret}' followed by an at sign is the same as listing
+  all parents of 'rev' (meaning, include anything reachable from
+  its parents, but not the commit itself).
+
+'rev{caret}!', e.g. 'HEAD{caret}!'::
+  A suffix '{caret}' followed by an exclamation mark is the same
+  as giving commit 'rev' and then all its parents prefixed with
+  '{caret}' to exclude them (and their ancestors).
+
 Here are a handful of examples:
 
DG H D
D F  G H I J D F
^G D H D
^D B E I J F B
+   B..C C
B...CG H D E B C
^D B C   E I J F B C
+   CI J F C
C^@  I J F
+   C^!  C
F^! DG H D F
--
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] Add a svnrdump-simulator replaying a dump file for testing.

[Florian Achleitner]

On Monday 23 July 2012 18:24:40 Matthieu Moy wrote:
 You also have whitespace damages (i.e. line wrapping introduced by your
 mailer). Using git-send-email avoids this kind of problem (there are
 also some advices for some mailers in Documentation/SubmittingPatches).

Damn. That's usually no problem with kmail either, if the config is right.
I've already used git-send-email several times.
But for replying to threads and adding several Cc: addresses it's a little 
cumbersome.
How do you do that in a nice way?

--
Florian
--
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] Make sure to use Araxis' compare and not e.g. ImageMagick's

[Sebastian Schuberth]

Signed-off-by: Sebastian Schuberth sschube...@gmail.com
---
 mergetools/araxis | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/mergetools/araxis b/mergetools/araxis
index 64f97c5..f8899f8 100644
--- a/mergetools/araxis
+++ b/mergetools/araxis
@@ -16,5 +16,12 @@ merge_cmd () {
 }
 
 translate_merge_tool_path() {
-   echo compare
+   # Only accept compare in a path that contains araxis to not
+   # accidently use e.g. ImageMagick's compare.
+   if type compare | grep -i araxis /dev/null 21
+   then
+   echo compare
+   else
+   echo $1
+   fi
 }
-- 
1.7.11.msysgit.2

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

Re: [PATCH] Add a svnrdump-simulator replaying a dump file for testing.

[Matthieu Moy]

Florian Achleitner florian.achleitner.2.6...@gmail.com writes:

 On Monday 23 July 2012 18:24:40 Matthieu Moy wrote:
 You also have whitespace damages (i.e. line wrapping introduced by your
 mailer). Using git-send-email avoids this kind of problem (there are
 also some advices for some mailers in Documentation/SubmittingPatches).

 Damn. That's usually no problem with kmail either, if the config is right.
 I've already used git-send-email several times.
 But for replying to threads and adding several Cc: addresses it's a little 
 cumbersome.
 How do you do that in a nice way?

For the threading itself, I usually find the message-id, and use
git send-email --in-reply-to='cut-and-pasted-id'. The painful part
is when you want to reproduce a Cc: list, but I have no magic trick for
that ;-).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mergetool: support --tool-help option like difftool does

[Junio C Hamano]

Sebastian Schuberth sschube...@gmail.com writes:

 This way we do not have to risk the list of tools go out of sync
 between the implementation and the documentation. Adjust the documentation
 accordingly to not explicitly list the tools but refer to --tool-help.

 Signed-off-by: Junio C Hamano gits...@pobox.com
 Signed-off-by: Sebastian Schuberth sschube...@gmail.com
 ---
  Documentation/git-difftool.txt  |  7 ---
  Documentation/git-mergetool.txt |  8 
  git-mergetool--lib.sh   | 11 ++-
  git-mergetool.sh| 42 
 -
  4 files changed, 59 insertions(+), 9 deletions(-)

 diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
 index 31fc2e3..0bdfe35 100644
 --- a/Documentation/git-difftool.txt
 +++ b/Documentation/git-difftool.txt
 @@ -36,9 +36,10 @@ OPTIONS
  
  -t tool::
  --tool=tool::
 - Use the diff tool specified by tool.  Valid values include
 - emerge, kompare, meld, and vimdiff. Run `git difftool --tool-help`
 - for the list of valid tool settings.
 + Use the diff tool specified by tool.

I do not see how it is an improvement to drop the most common ones.
People sometimes read documentation without having an access to
shell to run cmd --tool-help, and a list of handful of well known
ones would serve as a good hint to let the reader know the kind of
commands the front-end is capable of spawning, which in turn help
such a reader to imagine how the command is used to judge if it is
something the reader wants to use.

 +
 +--tool-help::
 + List all supported values for tool.
  +
  If a diff tool is not specified, 'git difftool'
  will use the configuration variable `diff.tool`.  If the
 diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
 index 2a49de7..99e53b1 100644
 --- a/Documentation/git-mergetool.txt
 +++ b/Documentation/git-mergetool.txt
 @@ -26,10 +26,10 @@ OPTIONS
  ---
  -t tool::
  --tool=tool::
 - Use the merge resolution program specified by tool.
 - Valid merge tools are:
 - araxis, bc3, diffuse, ecmerge, emerge, gvimdiff, kdiff3,
 - meld, opendiff, p4merge, tkdiff, tortoisemerge, vimdiff and xxdiff.
 + Use the merge tool specified by tool.

Likewise.  Dropping araxis, bc3, etc. to trim the list to 4-5 items
that people would know what they are would make sense, though.  The
purpose of the list is not to tell if the reader's favorite tool is
supported or not---it is to hint the flavor of what kind of things
the command spawned would be capable of.

 +
 +--tool-help::
 + List all supported values for tool.
  +
  If a merge resolution program is not specified, 'git mergetool'
  will use the configuration variable `merge.tool`.  If the
 diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
 index ed630b2..f0865d4 100644
 --- a/git-mergetool--lib.sh
 +++ b/git-mergetool--lib.sh
 @@ -111,15 +111,18 @@ run_merge_tool () {
   return $status
  }
  
 -guess_merge_tool () {
 +list_merge_tool_candidates () {
 + # Add tools that can either do merging or diffing, but not both.
   if merge_mode
   then
   tools=tortoisemerge
   else
   tools=kompare
   fi
 +
   if test -n $DISPLAY
   then
 + # Prefer GTK-based tools under Gnome.
   if test -n $GNOME_DESKTOP_SESSION_ID
   then
   tools=meld opendiff kdiff3 tkdiff xxdiff $tools
 @@ -128,6 +131,8 @@ guess_merge_tool () {
   fi
   tools=$tools gvimdiff diffuse ecmerge p4merge araxis bc3
   fi
 +
 + # Prefer vimdiff if vim is the default editor.
   case ${VISUAL:-$EDITOR} in
   *vim*)
   tools=$tools vimdiff emerge
 @@ -136,6 +141,10 @@ guess_merge_tool () {
   tools=$tools emerge vimdiff
   ;;
   esac
 +}
 +
 +guess_merge_tool () {
 + list_merge_tool_candidates
   echo 2 merge tool candidates: $tools
  
   # Loop over each candidate and stop when a valid merge tool is found.
 diff --git a/git-mergetool.sh b/git-mergetool.sh
 index a9f23f7..0db0c44 100755
 --- a/git-mergetool.sh
 +++ b/git-mergetool.sh
 @@ -8,7 +8,7 @@
  # at the discretion of Junio C Hamano.
  #
  
 -USAGE='[--tool=tool] [-y|--no-prompt|--prompt] [file to merge] ...'
 +USAGE='[--tool=tool] [--tool-help] [-y|--no-prompt|--prompt] [file to merge] 
 ...'
  SUBDIRECTORY_OK=Yes
  OPTIONS_SPEC=
  TOOL_MODE=merge
 @@ -284,11 +284,51 @@ merge_file () {
  return 0
  }
  
 +show_tool_help () {
 + TOOL_MODE=merge
 + list_merge_tool_candidates
 + unavailable= available= LF='
 +'
 + for i in $tools
 + do
 + merge_tool_path=$(translate_merge_tool_path $i)
 + if type $merge_tool_path /dev/null 21
 + then
 + available=$available$i$LF
 + else
 + unavailable=$unavailable$i$LF
 + fi
 + done
 + if 

Re: [PATCH] Add a svnrdump-simulator replaying a dump file for testing.

[Jeff King]

On Mon, Jul 23, 2012 at 09:46:49PM +0200, Matthieu Moy wrote:

  Damn. That's usually no problem with kmail either, if the config is right.
  I've already used git-send-email several times.
  But for replying to threads and adding several Cc: addresses it's a little 
  cumbersome.
  How do you do that in a nice way?
 
 For the threading itself, I usually find the message-id, and use
 git send-email --in-reply-to='cut-and-pasted-id'. The painful part
 is when you want to reproduce a Cc: list, but I have no magic trick for
 that ;-).

I save a copy of the message I am replying to (usually my cover letter,
which I generated by just replying in my MUA) into a well-known location
(I use a mutt hot-key to do this), and then run it through this
monstrosity:

  get_reply_headers() {
perl -ne '
  if (defined $opt  /^\s+(.*)/) {
$val .=  $1;
next;
  }
  if (defined $opt) {
print --$opt=, quotemeta($val),  ;
$opt = $val = undef;
  }
  if (/^(cc|to):\s*(.*)/i) {
$opt = lc($1);
$val = $2;
  }
  elsif (/^message-id:\s*(.*)/i) {
$opt = in-reply-to;
$val = $1;
  }
'
  }

which can be used on the command line of format-patch or send-email, like:

  eval git format-patch $(get_reply_headers your-patch-file)

I put the result in an mbox, then review and send it out in mutt (using
the resend-message command), but you could invoke send-email directly,
or format-patch into a file for review and send it with send-email.

-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

[PATCH] Add a svnrdump-simulator replaying a dump file for testing.

[Florian Achleitner]

To ease testing without depending on a reachable svn server, this
compact python script mimics parts of svnrdumps behaviour.
It requires the remote url to start with sim://.
Eventual slashes at the end of the url are stripped.
The url specifies the path of the svn dump file (as created by
svnrdump). Selectable parts of it, or the whole file, are written
to stdout. The part is selectable by giving start and end revision
on the command line.

Start and end revisions can be specified on the command line
(-rSTART:END, like for svnrdump).
Only revisions between START and excluding END are replayed from
the dumpfile specified by the url. END can also be HEAD.

If the start revision specified on the command line doesn't exist
in the dump file, it returns 1.
This emulates the behaviour of svnrdump when STARTHEAD, i.e. the
requested start revision doesn't exist on the server.

To allow using the same dump file for simulating multiple
incremental imports the highest visible revision can be limited by
setting the environment variable SVNRMAX to that value. This
effectively limits HEAD to simulate the situation where higher
revs don't exist yet.

Signed-off-by: Florian Achleitner florian.achleitner.2.6...@gmail.com
---
 contrib/svn-fe/svnrdump_sim.py |   53 
 1 file changed, 53 insertions(+)
 create mode 100755 contrib/svn-fe/svnrdump_sim.py

diff --git a/contrib/svn-fe/svnrdump_sim.py b/contrib/svn-fe/svnrdump_sim.py
new file mode 100755
index 000..4701d76
--- /dev/null
+++ b/contrib/svn-fe/svnrdump_sim.py
@@ -0,0 +1,53 @@
+#!/usr/bin/python
+
+Simulates svnrdump by replaying an existing dump from a file, taking care
+of the specified revision range.
+To simulate incremental imports the environment variable SVNRMAX can be set
+to the highest revision that should be available.
+
+import sys, os
+
+
+def getrevlimit():
+   var = 'SVNRMAX'
+   if os.environ.has_key(var):
+   return os.environ[var]
+   return None
+   
+def writedump(url, lower, upper):
+   if url.startswith('sim://'):
+   filename = url[6:]
+   if filename[-1] == '/': filename = filename[:-1] #remove 
terminating slash
+   else:
+   raise ValueError('sim:// url required')
+   f = open(filename, 'r');
+   state = 'header'
+   wroterev = False
+   while(True):
+   l = f.readline()
+   if l == '': break
+   if state == 'header' and l.startswith('Revision-number: '):
+   state = 'prefix'
+   if state == 'prefix' and l == 'Revision-number: %s\n' % lower:
+   state = 'selection'
+   if not upper == 'HEAD' and state == 'selection' and l == 
'Revision-number: %s\n' % upper:
+   break;
+
+   if state == 'header' or state == 'selection':
+   if state == 'selection': wroterev = True
+   sys.stdout.write(l)
+   return wroterev
+
+if __name__ == __main__:
+   if not (len(sys.argv) in (3, 4, 5)):
+   print usage: %s dump URL -rLOWER:UPPER
+   sys.exit(1)
+   if not sys.argv[1] == 'dump': raise NotImplementedError('only dump is 
suppported.')
+   url = sys.argv[2]
+   r = ('0', 'HEAD')
+   if len(sys.argv) == 4 and sys.argv[3][0:2] == '-r':
+   r = sys.argv[3][2:].lstrip().split(':')
+   if not getrevlimit() is None: r[1] = getrevlimit()
+   if writedump(url, r[0], r[1]): ret = 0
+   else: ret = 1
+   sys.exit(ret)
\ No newline at end of file
-- 
1.7.9.5

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

Re: [PATCH] mergetool: support --tool-help option like difftool does

[Sebastian Schuberth]

On Mon, Jul 23, 2012 at 9:52 PM, Junio C Hamano gits...@pobox.com wrote:

  -t tool::
  --tool=tool::
 - Use the diff tool specified by tool.  Valid values include
 - emerge, kompare, meld, and vimdiff. Run `git difftool --tool-help`
 - for the list of valid tool settings.
 + Use the diff tool specified by tool.

 I do not see how it is an improvement to drop the most common ones.
 People sometimes read documentation without having an access to
 shell to run cmd --tool-help, and a list of handful of well known
 ones would serve as a good hint to let the reader know the kind of
 commands the front-end is capable of spawning, which in turn help
 such a reader to imagine how the command is used to judge if it is
 something the reader wants to use.

I don't agree. What most common ones are depends on your platform
and is sort of subjective. So it should be either all or non here.
Your argument about people not having shell access is a valid one, but
still that would mean to list all tools in my opinion. And listing all
tools again thwarts our goal to reduce the number of places where new
merge / diff tools need to be added. For people adding new merge /
diff tools it is just clearer what places need to be modified if there
are no places that list an arbitrary subset of tools.

-- 
Sebastian Schuberth
--
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] Solve git-submodule issues with detached work trees

[Junio C Hamano]

Jens Lehmann jens.lehm...@web.de writes:

 We could get rid of the core.worktree setting by assuming that the
 directory a gitfile was found in is the root of the repo's work
 tree (unless configured otherwise).

Now you lost me.  If you have .git that is not a directory but is a
gitfile, then you do not need GIT_DIR nor GIT_WORK_TREE in the first
place, no?
--
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] Add a svnrdump-simulator replaying a dump file for testing.

[Junio C Hamano]

Florian Achleitner florian.achleitner.2.6...@gmail.com writes:

 To ease testing without depending on a reachable svn server, this
 compact python script mimics parts of svnrdumps behaviour.
 It requires the remote url to start with sim://.
 Eventual slashes at the end of the url are stripped.

s/ventual/xcess/ perhaps?

 The url specifies the path of the svn dump file (as created by
 svnrdump). Selectable parts of it, or the whole file, are written
 to stdout. The part is selectable by giving start and end revision
 on the command line.

 Start and end revisions can be specified on the command line
 (-rSTART:END, like for svnrdump).
 Only revisions between START and excluding END are replayed from
 the dumpfile specified by the url. END can also be HEAD.

 If the start revision specified on the command line doesn't exist
 in the dump file, it returns 1.
 This emulates the behaviour of svnrdump when STARTHEAD, i.e. the
 requested start revision doesn't exist on the server.

Much more understandable than before.

 To allow using the same dump file for simulating multiple
 incremental imports the highest visible revision can be limited by
 setting the environment variable SVNRMAX to that value. This
 effectively limits HEAD to simulate the situation where higher
 revs don't exist yet.

It is unclear how this is different from giving the ceiling by
specifying it as the END in -rSTART:END command line.  Is this
feature really needed?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mergetool: support --tool-help option like difftool does

[David Aguilar]

On Mon, Jul 23, 2012 at 1:14 PM, Sebastian Schuberth
sschube...@gmail.com wrote:
 On Mon, Jul 23, 2012 at 9:52 PM, Junio C Hamano gits...@pobox.com wrote:

  -t tool::
  --tool=tool::
 - Use the diff tool specified by tool.  Valid values include
 - emerge, kompare, meld, and vimdiff. Run `git difftool --tool-help`
 - for the list of valid tool settings.
 + Use the diff tool specified by tool.

 I do not see how it is an improvement to drop the most common ones.
 People sometimes read documentation without having an access to
 shell to run cmd --tool-help, and a list of handful of well known
 ones would serve as a good hint to let the reader know the kind of
 commands the front-end is capable of spawning, which in turn help
 such a reader to imagine how the command is used to judge if it is
 something the reader wants to use.

 I don't agree. What most common ones are depends on your platform
 and is sort of subjective. So it should be either all or non here.

Let's please leave this section as-is.

This part of the documentation has had a fair amount of churn.
Specifically, it would get touched every time a new tool was added.

The point of bf73fc212a159210398b6d46ed5e9101c650e7db was to change it
*one last time* into something that is helpful, but not a substitute
for the real list output by --tool-help.

If any changes are done then it should be to make git-mergetool.txt
match the advice given in git-difftool.txt.

 Your argument about people not having shell access is a valid one, but
 still that would mean to list all tools in my opinion. And listing all
 tools again thwarts our goal to reduce the number of places where new
 merge / diff tools need to be added. For people adding new merge /
 diff tools it is just clearer what places need to be modified if there
 are no places that list an arbitrary subset of tools.

Yes, indeed, it is arbitrary.  It does have some merit, though--it is
also a good compromise between unhelpful (listing nothing) and painful
to maintain (listing everything).
-- 
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] Make sure to use Araxis' compare and not e.g. ImageMagick's

[Junio C Hamano]

Sebastian Schuberth sschube...@gmail.com writes:

 Signed-off-by: Sebastian Schuberth sschube...@gmail.com
 ---
  mergetools/araxis | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

 diff --git a/mergetools/araxis b/mergetools/araxis
 index 64f97c5..f8899f8 100644
 --- a/mergetools/araxis
 +++ b/mergetools/araxis
 @@ -16,5 +16,12 @@ merge_cmd () {
  }
  
  translate_merge_tool_path() {
 - echo compare
 + # Only accept compare in a path that contains araxis to not
 + # accidently use e.g. ImageMagick's compare.
 + if type compare | grep -i araxis /dev/null 21
 + then
 + echo compare
 + else
 + echo $1
 + fi
  }

I do not use araxis, and I do not know how rigid its installation
procedure is to prevent the end user from naming a path that does
not have the string in it.

For example, when the user tells it to install in /home/ss/bin, if
it installs its compare program in /home/ss/bin/araxis/compare
without allowing the /araxis/ part to be stripped away, the above
heuristics is sufficiently safe.  Otherwise, it is not.

It is unclear from your proposed commit log message what assurance
do we have that it is installed under such a path and why the
heuristics the patch implements is the sane way forward.

Please convince me.
--
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/3] commit: give a hint when a commit message has been abandoned

[Junio C Hamano]

Jeff King p...@peff.net writes:

 If we launch an editor for the user to create a commit
 message, they may put significant work into doing so.
 Typically we try to check common mistakes that could cause
 the commit to fail early, so that we die before the user
 goes to the trouble.

 We may still experience some errors afterwards, though; in
 this case, the user is given no hint that their commit
 message has been saved. Let's tell them where it is.

Liberal use of atexit() for something like this makes me cringe
somewhat.


 Signed-off-by: Jeff King p...@peff.net
 ---
 I did not bother protecting this with advice.* config, as it is unlikely
 to come up regularly. If somebody cares, they are welcome to add it on
 top.

  builtin/commit.c | 15 +++
  1 file changed, 15 insertions(+)

 diff --git a/builtin/commit.c b/builtin/commit.c
 index 20cef95..149e07d 100644
 --- a/builtin/commit.c
 +++ b/builtin/commit.c
 @@ -116,6 +116,16 @@ static enum {
   STATUS_FORMAT_PORCELAIN
  } status_format = STATUS_FORMAT_LONG;
  
 +static int mention_abandoned_message;
 +static void maybe_mention_abandoned_message(void)
 +{
 + if (!mention_abandoned_message)
 + return;
 + advise(_(Your commit message has been saved in '%s' and will be\n
 +  overwritten by the next invocation of \git commit\.),
 +git_path(commit_editmsg));
 +}
 +
  static int opt_parse_m(const struct option *opt, const char *arg, int unset)
  {
   struct strbuf *buf = opt-value;
 @@ -848,6 +858,8 @@ static int prepare_to_commit(const char *index_file, 
 const char *prefix,
   _(Please supply the message using either -m or -F 
 option.\n));
   exit(1);
   }
 + atexit(maybe_mention_abandoned_message);
 + mention_abandoned_message = 1;
   }
  
   if (!no_verify 
 @@ -1532,11 +1544,13 @@ int cmd_commit(int argc, const char **argv, const 
 char *prefix)
   if (template_untouched(sb)  !allow_empty_message) {
   rollback_index_files();
   fprintf(stderr, _(Aborting commit; you did not edit the 
 message.\n));
 + mention_abandoned_message = 0;
   exit(1);
   }
   if (message_is_empty(sb)  !allow_empty_message) {
   rollback_index_files();
   fprintf(stderr, _(Aborting commit due to empty commit 
 message.\n));
 + mention_abandoned_message = 0;
   exit(1);
   }
  
 @@ -1579,6 +1593,7 @@ int cmd_commit(int argc, const char **argv, const char 
 *prefix)
   die(_(cannot update HEAD ref));
   }
  
 + mention_abandoned_message = 0;
   unlink(git_path(CHERRY_PICK_HEAD));
   unlink(git_path(REVERT_HEAD));
   unlink(git_path(MERGE_HEAD));
--
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/3] commit: check committer identity more strictly

[Junio C Hamano]

Jeff King p...@peff.net writes:

 Incidentally, this bug was masked prior to 060d4bb, as the
 initial loose call would taint the later strict call. So the
 commit would succeed (albeit with a bogus committer line in
 the commit object), and nobody noticed that our early check
 did not match the later one.

 Signed-off-by: Jeff King p...@peff.net
 ---
  builtin/commit.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/builtin/commit.c b/builtin/commit.c
 index 95eeab1..20cef95 100644
 --- a/builtin/commit.c
 +++ b/builtin/commit.c
 @@ -725,7 +725,7 @@ static int prepare_to_commit(const char *index_file, 
 const char *prefix,
   strbuf_release(sb);
  
   /* This checks if committer ident is explicitly given */
 - strbuf_addstr(committer_ident, git_committer_info(0));
 + strbuf_addstr(committer_ident, git_committer_info(IDENT_STRICT));
   if (use_editor  include_status) {
   char *ai_tmp, *ci_tmp;
   if (whence != FROM_COMMIT)

Looks sensible.  Is this something we can detect in automated tests,
or is it too cumbersome to set up?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] commit: give a hint when a commit message has been abandoned

[Jeff King]

On Mon, Jul 23, 2012 at 01:49:55PM -0700, Junio C Hamano wrote:

 Jeff King p...@peff.net writes:
 
  If we launch an editor for the user to create a commit
  message, they may put significant work into doing so.
  Typically we try to check common mistakes that could cause
  the commit to fail early, so that we die before the user
  goes to the trouble.
 
  We may still experience some errors afterwards, though; in
  this case, the user is given no hint that their commit
  message has been saved. Let's tell them where it is.
 
 Liberal use of atexit() for something like this makes me cringe
 somewhat.

I don't like it either, but there's not really a better way. The die()
that Ramana triggered in the initial report is deep inside the ident
code. The only other option would be to hook into die_routine, which I
think is even uglier.

-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 2/3] commit: check committer identity more strictly

[Jeff King]

On Mon, Jul 23, 2012 at 01:51:25PM -0700, Junio C Hamano wrote:

  diff --git a/builtin/commit.c b/builtin/commit.c
  index 95eeab1..20cef95 100644
  --- a/builtin/commit.c
  +++ b/builtin/commit.c
  @@ -725,7 +725,7 @@ static int prepare_to_commit(const char *index_file, 
  const char *prefix,
  strbuf_release(sb);
   
  /* This checks if committer ident is explicitly given */
  -   strbuf_addstr(committer_ident, git_committer_info(0));
  +   strbuf_addstr(committer_ident, git_committer_info(IDENT_STRICT));
  if (use_editor  include_status) {
  char *ai_tmp, *ci_tmp;
  if (whence != FROM_COMMIT)
 
 Looks sensible.  Is this something we can detect in automated tests,
 or is it too cumbersome to set up?

Sorry, I meant to mention that in the cover letter. No, we can't test
this easily, because the code path in question is triggered by finding a
blank name in /etc/passwd. We'd have to override our getpwent lookup.

-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 3/3] commit: give a hint when a commit message has been abandoned

[Junio C Hamano]

Jeff King p...@peff.net writes:

 On Mon, Jul 23, 2012 at 01:49:55PM -0700, Junio C Hamano wrote:

 Jeff King p...@peff.net writes:
 
  If we launch an editor for the user to create a commit
  message, they may put significant work into doing so.
  Typically we try to check common mistakes that could cause
  the commit to fail early, so that we die before the user
  goes to the trouble.
 
  We may still experience some errors afterwards, though; in
  this case, the user is given no hint that their commit
  message has been saved. Let's tell them where it is.
 
 Liberal use of atexit() for something like this makes me cringe
 somewhat.

 I don't like it either, but there's not really a better way. The die()
 that Ramana triggered in the initial report is deep inside the ident
 code. The only other option would be to hook into die_routine, which I
 think is even uglier.

Then I would rather not worry about it.  A documentation update is
probably a good first step, though.
--
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] Make sure to use Araxis' compare and not e.g. ImageMagick's

[Sebastian Schuberth]

On Mon, Jul 23, 2012 at 10:47 PM, Junio C Hamano gits...@pobox.com wrote:

 For example, when the user tells it to install in /home/ss/bin, if
 it installs its compare program in /home/ss/bin/araxis/compare
 without allowing the /araxis/ part to be stripped away, the above
 heuristics is sufficiently safe.  Otherwise, it is not.

To the best of my knowledge, Araxis does not enforce any naming
convention for the path it gets installed in. That means the user may
indeed install the program in a path that does not contain araxis. I
was aware of this when writing the patch, but should have probably
made it more clear in the commit message.

 It is unclear from your proposed commit log message what assurance
 do we have that it is installed under such a path and why the
 heuristics the patch implements is the sane way forward.

We have no such assurance. That's why you correctly call it a
heuristics after all: it may fail. Personally, I've valued the gain of
the patch to not list araxis as an available diff tool by git
difftool --tool-help when in fact just ImageMagick is in PATH higher
than the loss to support araxis installations that are in a path not
containung araxis but are in PATH.

Please feel free to ignore the patch if you feel the heuristics is not
sufficiently safe. I'm currently unable to come up with a safer
solution while maintaining portability, i.e. not use which or doing
rather laborious string parsing on the output of type.

-- 
Sebastian Schuberth
--
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/3] commit: give a hint when a commit message has been abandoned

[Jeff King]

On Mon, Jul 23, 2012 at 02:00:19PM -0700, Junio C Hamano wrote:

  Liberal use of atexit() for something like this makes me cringe
  somewhat.
 
  I don't like it either, but there's not really a better way. The die()
  that Ramana triggered in the initial report is deep inside the ident
  code. The only other option would be to hook into die_routine, which I
  think is even uglier.
 
 Then I would rather not worry about it.  A documentation update is
 probably a good first step, though.

I'm OK with dropping this one; the likely cause is ident problems, and
the previous patch already helped with that (the next likely is probably
commit hooks failing, but that is just a guess).

Here's a documentation patch.

-- 8 --
Subject: [PATCH] commit: document the temporary commit message file

We do not document COMMIT_EDITMSG at all, but users may want
to know about it for two reasons:

  1. They may want to tell their editor to configure itself
 for formatting a commit message.

  2. If a commit is aborted by an error, the user may want
 to recover the commit message they typed.

Let's put a note in git-commit(1).
---
 Documentation/git-commit.txt | 9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index f400835..87297dc 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -407,6 +407,15 @@ This command can run `commit-msg`, `prepare-commit-msg`, 
`pre-commit`,
 and `post-commit` hooks.  See linkgit:githooks[5] for more
 information.
 
+FILES
+-
+
+`$GIT_DIR/COMMIT_EDITMSG`::
+   This file contains the commit message of a commit in progress.
+   If `git-commit` exits due to an error before creating a commit,
+   any commit message that has been provided by the user (e.g., in
+   an editor session) will be available in this file, but will be
+   overwritten by the next invocation of `git-commit`.
 
 SEE ALSO
 
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mergetool: support --tool-help option like difftool does

[Junio C Hamano]

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

 On Mon, Jul 23, 2012 at 1:14 PM, Sebastian Schuberth
 sschube...@gmail.com wrote:
 On Mon, Jul 23, 2012 at 9:52 PM, Junio C Hamano gits...@pobox.com wrote:

  -t tool::
  --tool=tool::
 - Use the diff tool specified by tool.  Valid values include
 - emerge, kompare, meld, and vimdiff. Run `git difftool --tool-help`
 - for the list of valid tool settings.
 + Use the diff tool specified by tool.

 I do not see how it is an improvement to drop the most common ones.
 People sometimes read documentation without having an access to
 shell to run cmd --tool-help, and a list of handful of well known
 ones would serve as a good hint to let the reader know the kind of
 commands the front-end is capable of spawning, which in turn help
 such a reader to imagine how the command is used to judge if it is
 something the reader wants to use.

 I don't agree. What most common ones are depends on your platform
 and is sort of subjective. So it should be either all or non here.

 Let's please leave this section as-is.

Yes.  

There are only five or six classes of environment that matter in the
real world for the purpose of giving well known examples: Windows,
MacOS X, Gnome, KDE and Linux terminal.  By picking a representative
one from each and listing them, the end result would have at least
one that people from various platforms have _heard of_ and can guess
what they do.  The most common is secondary, and well known is
the keyword.  Can guess what they do is the point of the phrase
Valid values _include_.  Even if you are hard-core Emacs user, it
is likely that you've heard of vimdiff---and in that case, including
vimdiff would be enough.  Likewise for showing kompare to Gnome users.

Unlike POSIXy folks, where IRIX or Solaris users are likely to have
heard of Gnome tools even if they do not use the environment on
their platforms, Windows users tend to be isolated bunch, so it
would not hurt to include at least one well-known Windows-only tool
in the list.

 Yes, indeed, it is arbitrary.  It does have some merit, though--it is
 also a good compromise between unhelpful (listing nothing) and painful
 to maintain (listing everything).

Here is a v2, with documentation updates.

-- 8 --
Subject: [PATCH] mergetool: support --tool-help option like difftool does

This way we do not have to risk the list of tools going out of sync
between the implementation and the documentation.

In the same spirit as bf73fc2 (difftool: print list of valid tools
with '--tool-help', 2012-03-29), trim the list of merge backends in
the documentation.  We do not want to have a complete of valid tools
there; we only want a list to help people guess what kind of things
the tools that can be specified there, and refer them to --tool-help
for a complete list.

Signed-off-by: Junio C Hamano gits...@pobox.com
---
 Documentation/git-mergetool.txt |  6 +++---
 git-mergetool--lib.sh   |  6 +-
 git-mergetool.sh| 42 -
 3 files changed, 49 insertions(+), 5 deletions(-)

diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 2a49de7..d1e08d2 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -27,9 +27,9 @@ OPTIONS
 -t tool::
 --tool=tool::
Use the merge resolution program specified by tool.
-   Valid merge tools are:
-   araxis, bc3, diffuse, ecmerge, emerge, gvimdiff, kdiff3,
-   meld, opendiff, p4merge, tkdiff, tortoisemerge, vimdiff and xxdiff.
+   Valid values include emerge, gvimdiff, kdiff3,
+   meld, vimdiff, and tortoisemerge. Run `git mergetool --tool-help`
+   for the list of valid tool settings.
 +
 If a merge resolution program is not specified, 'git mergetool'
 will use the configuration variable `merge.tool`.  If the
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index ed630b2..f730253 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -111,7 +111,7 @@ run_merge_tool () {
return $status
 }
 
-guess_merge_tool () {
+list_merge_tool_candidates () {
if merge_mode
then
tools=tortoisemerge
@@ -136,6 +136,10 @@ guess_merge_tool () {
tools=$tools emerge vimdiff
;;
esac
+}
+
+guess_merge_tool () {
+   list_merge_tool_candidates
echo 2 merge tool candidates: $tools
 
# Loop over each candidate and stop when a valid merge tool is found.
diff --git a/git-mergetool.sh b/git-mergetool.sh
index a9f23f7..0db0c44 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -8,7 +8,7 @@
 # at the discretion of Junio C Hamano.
 #
 
-USAGE='[--tool=tool] [-y|--no-prompt|--prompt] [file to merge] ...'
+USAGE='[--tool=tool] [--tool-help] [-y|--no-prompt|--prompt] [file to merge] 
...'
 SUBDIRECTORY_OK=Yes
 OPTIONS_SPEC=
 TOOL_MODE=merge
@@ -284,11 +284,51 @@ merge_file () {
 return 0
 }
 
+show_tool_help () {
+   

Re: [PATCH] Make sure to use Araxis' compare and not e.g. ImageMagick's

[Andreas Schwab]

Sebastian Schuberth sschube...@gmail.com writes:

 Please feel free to ignore the patch if you feel the heuristics is not
 sufficiently safe. I'm currently unable to come up with a safer
 solution while maintaining portability, i.e. not use which or doing
 rather laborious string parsing on the output of type.

How about looking at compare --version?

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
And now for something completely different.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mergetool: support --tool-help option like difftool does

[Sebastian Schuberth]

On Mon, Jul 23, 2012 at 11:16 PM, Junio C Hamano gits...@pobox.com wrote:

 There are only five or six classes of environment that matter in the
 real world for the purpose of giving well known examples: Windows,
 MacOS X, Gnome, KDE and Linux terminal.  By picking a representative
 one from each and listing them, the end result would have at least
 one that people from various platforms have _heard of_ and can guess
 what they do.  The most common is secondary, and well known is

I completely agree with this. So we should take the chance and add a
Windows representative to the list of difftools, no?

 Unlike POSIXy folks, where IRIX or Solaris users are likely to have
 heard of Gnome tools even if they do not use the environment on
 their platforms, Windows users tend to be isolated bunch, so it
 would not hurt to include at least one well-known Windows-only tool
 in the list.

Heh. I believe POSIX folks are no less isolated. (How many
Windows-only tools would you recognize by name?) They're just isolated
in a bigger world ;-)

 Here is a v2, with documentation updates.

This drops the explicit mention of --tool-help as an option in the
documentation compared to my patch. Do you want to keep --tool-help
being mentioned inline as part of the --tool option documentation
only?

-- 
Sebastian Schuberth
--
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] Make sure to use Araxis' compare and not e.g. ImageMagick's

[Sebastian Schuberth]

On Mon, Jul 23, 2012 at 11:24 PM, Junio C Hamano gits...@pobox.com wrote:

 Does Araxis compare take --version and behave in a way that is
 cheaply controllable?  If it opens a GUI window and pops up a dialog
 that says Option not understood, then it is not controllable,

Araxis opens up a GUI dialog with usage info in that case, so it's not
controllable, unfortunately.

-- 
Sebastian Schuberth
--
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] Make sure to use Araxis' compare and not e.g. ImageMagick's

[David Aguilar]

On Mon, Jul 23, 2012 at 2:24 PM, Junio C Hamano gits...@pobox.com wrote:
 Sebastian Schuberth sschube...@gmail.com writes:

 We have no such assurance. That's why you correctly call it a
 heuristics after all

 ImageMagick compare takes --version and says something like
 this to its standard output:

 $ compare --version
 Version: ImageMagick 6.6.0-4 2012-05-02 Q16
 http://www.imagemagick.org
 Copyright: Copyright (C) 1999-2010 ImageMagick Studio LLC

 Does Araxis compare take --version and behave in a way that is
 cheaply controllable?  If it opens a GUI window and pops up a dialog
 that says Option not understood, then it is not controllable,
 but if it quickly dies with No such option sent to the standard
 error output, or sending its version string to the standard output,
 then we could use something like:

 case $(compare --version 2/dev/null) in
 Araxis compare version*)
 echo compare ;;
 *)
 echo $1 ;;
 esac

 instead, and that would be more robust than the path based
 heuristics.

Araxis compare (the one I have) does not accept --version.

Also, the GraphicsMagick (ImageMagick fork) compare does not have
--version, but it does have compare version:

$ compare version
GraphicsMagick 1.3.12 2010-03-08 Q8 http://www.GraphicsMagick.org/
Copyright (C) 2002-2010 GraphicsMagick Group.
Additional copyrights and licenses apply to this software.
See http://www.GraphicsMagick.org/www/Copyright.html for details.
...


If we care to blacklist *Magick compare, then we may be able to call
compare version and parse the output looking for Magic.

I tested ImageMagick compare and it also understands compare version.


Araxis compare prints nothing when compare version is called.
Likely because it thinks it has nothing to do.  It does the same if I
say compare blahblah, and returns exit status 0.  So its output is
useless.

It seems like the best we can do is specifically blacklist the *Magick
compare commands so that they do not show up as false positives.
And the only way to identify them is to parse their output, since all
commands return status 0 for compare version.


Another possibility is to parse the output of compare (no args) and
grep for merge.  The name Araxis Merge is never actually printed,
but the help text for -merge does appear yep.. it's a heuristic.

Sebastian, are you testing on Windows?  The araxis compare I used is
OS X.  Does compare version open a GUI window for you?  For me it
does not.
What about compare -h, or just compare ?
-- 
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 3/3] commit: give a hint when a commit message has been abandoned

[Junio C Hamano]

Jeff King p...@peff.net writes:

 Here's a documentation patch.

 -- 8 --
 Subject: [PATCH] commit: document the temporary commit message file

 We do not document COMMIT_EDITMSG at all, but users may want
 to know about it for two reasons:

   1. They may want to tell their editor to configure itself
  for formatting a commit message.

   2. If a commit is aborted by an error, the user may want
  to recover the commit message they typed.

 Let's put a note in git-commit(1).
 ---
  Documentation/git-commit.txt | 9 +
  1 file changed, 9 insertions(+)

 diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
 index f400835..87297dc 100644
 --- a/Documentation/git-commit.txt
 +++ b/Documentation/git-commit.txt
 @@ -407,6 +407,15 @@ This command can run `commit-msg`, `prepare-commit-msg`, 
 `pre-commit`,
  and `post-commit` hooks.  See linkgit:githooks[5] for more
  information.
  
 +FILES
 +-
 +
 +`$GIT_DIR/COMMIT_EDITMSG`::
 + This file contains the commit message of a commit in progress.
 + If `git-commit` exits due to an error before creating a commit,
 + any commit message that has been provided by the user (e.g., in
 + an editor session) will be available in this file, but will be
 + overwritten by the next invocation of `git-commit`.
  
  SEE ALSO
  

Very sensible, modulo s/git-commit/git commit/ and lack of S-o-b.

I also wondered if something like the following might be useful, but
it probably falls into the water under the bridge category.

 builtin/commit.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/builtin/commit.c b/builtin/commit.c
index 149e07d..83bcee4 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -768,6 +768,11 @@ static int prepare_to_commit(const char *index_file, const 
char *prefix,
with '#' will be kept; you may remove them
 yourself if you want to.\n
An empty message aborts the commit.\n));
+   status_printf(s, GIT_COLOR_NORMAL,
+ _(The file '%s' keeps a copy of the log 
message\n
+   you edited, if you wish to inspect it later.\n
+   It will be wiped by the next invocation of 
'git commit'.\n),
+ git_path(COMMIT_EDITMSG));
if (only_include_assumed)
status_printf_ln(s, GIT_COLOR_NORMAL,
%s, only_include_assumed);
--
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/3] commit: give a hint when a commit message has been abandoned

[Junio C Hamano]

Jeff King p...@peff.net writes:

 On Mon, Jul 23, 2012 at 02:35:01PM -0700, Junio C Hamano wrote:
 ...
 I also wondered if something like the following might be useful, but
 it probably falls into the water under the bridge category.
 
  builtin/commit.c | 5 +
  1 file changed, 5 insertions(+)
 
 diff --git a/builtin/commit.c b/builtin/commit.c
 index 149e07d..83bcee4 100644
 --- a/builtin/commit.c
 +++ b/builtin/commit.c
 @@ -768,6 +768,11 @@ static int prepare_to_commit(const char *index_file, 
 const char *prefix,
  with '#' will be kept; you may remove them
   yourself if you want to.\n
  An empty message aborts the commit.\n));
 +status_printf(s, GIT_COLOR_NORMAL,
 +  _(The file '%s' keeps a copy of the log 
 message\n
 +you edited, if you wish to inspect it later.\n
 +It will be wiped by the next invocation of 
 'git commit'.\n),
 +  git_path(COMMIT_EDITMSG));

 That seems excessive, as it is inside the file itself. Unless your
 editor is terrible, it already shows you that information.

The pathname was not the part that was interesting; If you wish to
inspect it later was.

But that is what makes it water under the bridge.  The message will
be gone by the time you really need 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: [PATCH] Make sure to use Araxis' compare and not e.g. ImageMagick's

[Junio C Hamano]

Sebastian Schuberth sschube...@gmail.com writes:

 Personally, I've valued the gain of
 the patch to not list araxis as an available diff tool by git
 difftool --tool-help when in fact just ImageMagick is in PATH higher
 than the loss to support araxis installations that are in a path not
 containung araxis but are in PATH.

I agree that running ImageMagick's compare by accident is one thing
we would want to avoid, but once the problem is diagnosed, it is
something the user can easily work around by futzing %PATH%, I
think.

On the other hand, if the user has bought and installed Araxis, but
we incorrectly identify it as unusable, the user has wasted good
money and there is no easy recourse as far as I can see in your
patch.  That is why I wanted to see a reasonable assurance.

If we limit the problem space by special casing Windows installation
(e.g. check uname -s or something), would it make the problem
easier to solve?  Perhaps it is much more likely that the path the
program is installed in can be safely identified with a call to
type --path compare (bash is the only shell shipped in msysgit,
isn't it?), and its output is likely to contain /Program Files/Araxis/
as a substring, or something?
--
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: [GSoC] Designing a faster index format - Progress report week 13

[Robin Rosenberg]

Junio C Hamano skrev 2012-07-22 23.08:

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


Hum, I'm a bit lost now.

What is the status quo?  I take it JGit does not have any of ctime, dev,
ino etc., and either leaves the existing value or puts a 0
an argument in favor of splitting stat_crc into its fields again?


A difference is that JGit already has such code, and we would be
adding a burden to do so yet again.  It also may not just be JGit,
but anything that wants to be compatible with systems whose
filesystem interface does not give enough data by omitting fields
the current index pays attention to.

It isn't really a discussion about splitting again, but more about
not squishing them into a new field in the first place---IIUC, even
outside Windows, ctime is already problematic on some systems where
background processes muck with extended attributes Git does not pay
attention to. If the patch makes us lose the ability to selectively
ignore changes to certain fields (e.g. changes to dev and ino are
noticed but ctime are ignored) by squishing them into one new field,
wouldn't removing them without adding such a useless field a simpler
way to go?


I wasnt't thinking of splitting, but now I read it again, I do think
it should split. Having size accessible is a good thing, and even better 
if it a 64-bit value so we don't have the modulo-4G problem when looking 
at it. Current size is 4G + 33 bytes, index says 33. Did the

file change or not?

Having access to size make the need for actually
invoking the racy git logic and comparing file content less likely.

As for ctime it is accessible in Java7, though everyone aren't using it 
and JGit code has to run on Java5. An idea is to make an optional 
component, but that doesn't make ctime available everywhere.


-- robin

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

Re: [PATCH] mergetool: support --tool-help option like difftool does

[Junio C Hamano]

Sebastian Schuberth sschube...@gmail.com writes:

 On Mon, Jul 23, 2012 at 11:16 PM, Junio C Hamano gits...@pobox.com wrote:

 There are only five or six classes of environment that matter in the
 real world for the purpose of giving well known examples: Windows,
 MacOS X, Gnome, KDE and Linux terminal.  By picking a representative
 one from each and listing them, the end result would have at least
 one that people from various platforms have _heard of_ and can guess
 what they do.  The most common is secondary, and well known is

 I completely agree with this. So we should take the chance and add a
 Windows representative to the list of difftools, no?

I do not care very deeply either way.  I am more interested in
seeing --tool-list options supported by both so that we can get rid
of hardcoded list from the completion script.

 This drops the explicit mention of --tool-help as an option in the
 documentation compared to my patch. Do you want to keep --tool-help
 being mentioned inline as part of the --tool option documentation
 only?

While I do not think having one would hurt that much, I do not think
a separate entry would add much value either, so I chose not to
clutter the documentation further.  The --tool=tool entry is
enough hint to draw eyes of readers who want to find out what kind
of backends are supported, and --tool-help is mentioned there quite
prominently.
--
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] Make sure to use Araxis' compare and not e.g. ImageMagick's

[Sebastian Schuberth]

On Tue, Jul 24, 2012 at 12:22 AM, Junio C Hamano gits...@pobox.com wrote:

 On the other hand, if the user has bought and installed Araxis, but
 we incorrectly identify it as unusable, the user has wasted good
 money and there is no easy recourse as far as I can see in your
 patch.

Agreed.

 If we limit the problem space by special casing Windows installation
 (e.g. check uname -s or something), would it make the problem
 easier to solve?  Perhaps it is much more likely that the path the
 program is installed in can be safely identified with a call to
 type --path compare (bash is the only shell shipped in msysgit,
 isn't it?), and its output is likely to contain /Program Files/Araxis/
 as a substring, or something?

Yes, I could come up with basically a variant of my first version of
the patch that is limited to Windows only and uses type --path
instead of which, but then again this is too non-generic for my
taste. Moreover, as I'm also using Mac OS X, I'd be interested in a
solution that works there, too.

I don't see a good (read generic and concise) solution to the issue. I
think we should just drop my patch and not waste all of our time on it
any more.

-- 
Sebastian Schuberth
--
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] Make sure to use Araxis' compare and not e.g. ImageMagick's

[Sebastian Schuberth]

On 24.07.2012 00:41, Junio C Hamano wrote:

 + if test -f $(dirname $(type --path compare))/AraxisMerge

We would need additional quotes around the whole path here as the Windows 
installation path is usually something like C:\Program Files\Araxis\Araxis 
Merge and contains spaces.

Moreover, test -f requires the .exe extension to be explicitly present for 
the file to test. But I'd rather not do that because the test would be specific 
to Windows then and e.g. not work on Mac OS X. That's why I'd still like to use 
ls like in my first patch:

 mergetools/araxis | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/mergetools/araxis b/mergetools/araxis
index 64f97c5..c406ead 100644
--- a/mergetools/araxis
+++ b/mergetools/araxis
@@ -16,5 +16,18 @@ merge_cmd () {
 }
 
 translate_merge_tool_path() {
-   echo compare
+   case $BASH_VERSION in
+   ??*)
+   # we can safely use type --path
+   if ls $(dirname $(type --path compare))/Araxis* /dev/null 
21
+   then
+   echo compare
+   else
+   echo $1
+   fi
+   ;;
+   *)
+   echo compare
+   ;;
+   esac
 }

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

Re: [PATCH v2 7/7] build: reconfigure automatically if configure.ac changes

[Stefano Lattarini]

Hi Junio.  I've just noticed a minor typo in the commit message ...

On 07/19/2012 09:50 AM, Stefano Lattarini wrote:
 This provides a reduced but still useful sibling of the Automake's
 automatic Makefile rebuild feature.  It's important to note that
 we take care to enable the new rules only if the tree that has already
 be

... here, it should read been, not be.  Can you fix that locally
before merging to 'next', or should I send a re-roll?

 configured with './configure', so that users relying on manual
 configuration won't be negatively impacted.

Thanks,
  Stefano
--
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] Solve git-submodule issues with detached work trees

[Jens Lehmann]

Am 23.07.2012 22:34, schrieb Junio C Hamano:
 Jens Lehmann jens.lehm...@web.de writes:
 
 We could get rid of the core.worktree setting by assuming that the
 directory a gitfile was found in is the root of the repo's work
 tree (unless configured otherwise).
 
 Now you lost me.  If you have .git that is not a directory but is a
 gitfile, then you do not need GIT_DIR nor GIT_WORK_TREE in the first
 place, no?

Not inside the submodule, me thinks they only make sense in the
superproject (that's why we clean the environment before working
inside the submodule). But setting the superproject's GIT_WORK_TREE
to something else won't work for an already initialized submodule,
as the core.worktree setting will still point to the old work tree
which was set when the submodule was initialized. One could expect
the submodule's work tree to be $GIT_WORK_TREE/$sm_path when
GIT_WORK_TREE is set, but it 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 v2 6/7] build: make clean should not remove configure-generated files

[Junio C Hamano]

Stefano Lattarini stefano.lattar...@gmail.com writes:

 ... and here we should add invocation:

 ... the make install invocation ...

 falls back to the default prefix of '$HOME', thus installing git
 in the user's home directory -- definitely unexpected.

 Can you fix those nits locally before merging to 'next', or should
 I send a re-roll?

Too late X-.
--
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] Solve git-submodule issues with detached work trees

[Junio C Hamano]

Jens Lehmann jens.lehm...@web.de writes:

 Not inside the submodule, me thinks they only make sense in the
 superproject (that's why we clean the environment before working
 inside the submodule).

Yes, that is fundamental and the only sane behaviour that comes from
what submodules are.  They are free-standing projects.  Not clearing
these environments when Git recurses into submodule was simply a bug
(the original bug was that we added recursion without thinking these
things through).

Hence...

 But setting the superproject's GIT_WORK_TREE
 to something else won't work for an already initialized submodule,

... if you point the _root_ of the toplevel superproject with
GIT_WORK_TREE (and the repository of the superproject with GIT_DIR),
and chdir into one of its submodule's working tree, we shouldn't say
$GIT_WORK_TREE/$smpath is the submodule world.  That will make it
impossible to work only on submodules by setting GIT_WORK_TREE to
point at its root level (and the submodule repository with GIT_DIR).

--
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: [GSoC] Designing a faster index format - Progress report week 14

[Nguyen Thai Ngoc Duy]

On Tue, Jul 24, 2012 at 2:08 AM, Thomas Gummerer t.gumme...@gmail.com wrote:
 - We added a POC, for partial loading in git grep. This is still a
   pretty hacky implementation, but it demonstrates pretty well
   how much can be gained. Here are the timings Thomas posted on
   IRC yesterday. The improvements of ls-files are not drastic
   compared to index-v4, but git greps in subdirs benefit a lot
   from partial loading.

   Test  this tree
   ---
   0002.2: v[23]: ls-files   0.13(0.11+0.02)
   0002.3: v[23]: grep nonexistent -- subdir 0.12(0.10+0.02)
   0002.5: v4: ls-files  0.11(0.09+0.01)
   0002.6: v4: grep nonexistent -- subdir0.10(0.08+0.02)
   0002.8: v5: ls-files  0.10(0.07+0.02)
   0002.9: v5: grep nonexistent -- subdir0.01(0.00+0.00)


Is ls-files improvement not drastic because you do not limit subdir
like grep? I see Thomas Rast put similar partial loading hack to
ls-files.c so I assume it can partial load too. Is partial loading
still fast with when a lot of unmerged entries are present?
-- 
Duy
--
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

[ANNOUNCE] Git v1.7.12-rc0

[Junio C Hamano]

A release candidate Git v1.7.12-rc0 is now available for testing
at the usual places.

The release tarballs are found at:

http://code.google.com/p/git-core/downloads/list

and their SHA-1 checksums are:

09016e819a69b49090756e9bc5c97a4df25c2f78  git-1.7.12.rc0.tar.gz
e85ad0780ff81eacdb05a10762060812bc9367dd  git-htmldocs-1.7.12.rc0.tar.gz
b641a9664c333518ede3b1d8b67d84d18f5b0e14  git-manpages-1.7.12.rc0.tar.gz

Also the following public repositories all have a copy of the v1.7.12-rc0
tag and the master branch that the tag points at:

  url = git://repo.or.cz/alt-git.git
  url = https://code.google.com/p/git-core/
  url = git://git.sourceforge.jp/gitroot/git-core/git.git
  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
  url = https://github.com/gitster/git

Git v1.7.12 Release Notes (draft)
=

Updates since v1.7.11
-

UI, Workflows  Features

 * Git can be told to normalize pathnames it read from readdir(3) and
   all arguments it got from the command line into precomposed UTF-8
   (assuming that they come as decomposed UTF-8), in order to work
   around issues on Mac OS.

   I think there still are other places that need conversion
   (e.g. paths that are read from stdin for some commands), but this
   should be a good first step in the right direction.

 * Per-user $HOME/.gitconfig file can optionally be stored in
   $HOME/.config/git/config instead, which is in line with XDG.

 * The value of core.attributesfile and core.excludesfile default to
   $HOME/.config/attributes and $HOME/.config/ignore respectively when
   these files exist.

 * Logic to disambiguate abbreviated object names have been taught to
   take advantage of object types that are expected in the context,
   e.g. XX in the git describe output v1.2.3-gXX must be a
   commit object, not a blob nor a tree.  This will help us prolong
   the lifetime of abbreviated object names.

 * git apply learned to wiggle the base version and perform three-way
   merge when a patch does not exactly apply to the version you have.

 * Scripted Porcelain writers now have access to the credential API via
   the git credential plumbing command.

 * git help used to always default to man format even on platforms
   where man viewer is not widely available.

 * git clone --local $path started its life as an experiment to
   optionally use link/copy when cloning a repository on the disk, but
   we didn't deprecate it after we made the option a no-op to always
   use the optimization.  The command learned --no-local option to
   turn this off, as a more explicit alternative over use of file://
   URL.

 * git fetch and friends used to say remote side hung up
   unexpectedly when they failed to get response they expect from the
   other side, but one common reason why they don't get expected
   response is that the remote repository does not exist or cannot be
   read. The error message in this case was updated to give better
   hints to the user.

 * git native protocol agents learned to show software version over
   the wire, so that the server log can be examined to see the vintage
   distribution of clients.

 * git help -w $cmd can show HTML version of documentation for
   git-$cmd by setting help.htmlpath to somewhere other than the
   default location where the build procedure installs them locally;
   the variable can even point at a http:// URL.

 * git rebase [-i] --root $tip can now be used to rewrite all the
   history leading to $tip down to the root commit.

 * git rebase -i learned -x cmd to insert exec cmd after
   each commit in the resulting history.

 * git status gives finer classification to various states of paths
   in conflicted state and offer advice messages in its output.

 * git submodule learned to deal with nested submodule structure
   where a module is contained within a module whose origin is
   specified as a relative URL to its superproject's origin.

 * A rather heavy-ish git completion script has been split to create
   a separate git prompting script, to help lazy-autoloading of the
   completion part while making prompting part always available.

 * gitweb pays attention to various forms of credits that are
   similar to Signed-off-by: lines in the commit objects and
   highlights them accordingly.


Foreign Interface

 * mediawiki remote helper (in contrib/) learned to handle file
   attachments.

 * git p4 now uses Jobs: and p4 move when appropriate.

 * vcs-svn has been updated to clean-up compilation, lift 32-bit
   limitations, etc.


Performance, Internal Implementation, etc. (please report possible regressions)

 * Some tests showed false failures caused by a bug in ecryptofs.

 * We no longer use AsciiDoc7 syntax in our documentation and favor a
   more modern style.

 * git am --rebasing codepath was taught to grab authorship, log
   message and the patch text directly out of existing commits.  This
   will help rebasing commits that have