Re: [PATCH] push: fix typo in advice message

2013-07-28 Thread Jeff King
On Mon, Jul 29, 2013 at 06:23:52AM +0200, Ralf Thielow wrote:

> Signed-off-by: Ralf Thielow 
> ---
>  builtin/push.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/builtin/push.c b/builtin/push.c
> index 6d36c24..04abd2d 100644
> --- a/builtin/push.c
> +++ b/builtin/push.c
> @@ -250,7 +250,7 @@ static const char message_advice_ref_fetch_first[] =
>   N_("Updates were rejected because the remote contains work that you 
> do\n"
>  "not have locally. This is usually caused by another repository 
> pushing\n"
>  "to the same ref. You may want to first integrate the remote 
> changes\n"
> -"(e.g., 'git pull ...') before pushing again.\n"
> +"(e.g. 'git pull ...') before pushing again.\n"

I do not think the comma is a typo. In American English it is usually
preferred, but googling "comma after e.g." seems to indicate that it is
not in British English.

Grep shows that we use both styles in quite a few places.

-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] l10n: de.po: translate 99 new messages

2013-07-28 Thread Ralf Thielow
Translate 99 new messages came from git.pot update in
28b3cff (l10n: git.pot: v1.8.4 round 1 (99 new, 46 removed)).

Signed-off-by: Ralf Thielow 
---
 po/de.po | 366 +++
 1 file changed, 180 insertions(+), 186 deletions(-)

diff --git a/po/de.po b/po/de.po
index ee5e786..ce6287f 100644
--- a/po/de.po
+++ b/po/de.po
@@ -6,11 +6,11 @@
 msgid ""
 msgstr ""
 "Project-Id-Version: git 1.8.4\n"
 "Report-Msgid-Bugs-To: Git Mailing List \n"
 "POT-Creation-Date: 2013-07-26 14:19+0800\n"
-"PO-Revision-Date: 2012-10-02 19:35+0200\n"
+"PO-Revision-Date: 2013-07-28 18:42+0200\n"
 "Last-Translator: Ralf Thielow \n"
 "Language-Team: German <>\n"
 "Language: de\n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
@@ -570,13 +570,13 @@ msgstr[0] ""
 msgstr[1] ""
 "\n"
 "Haben Sie eines von diesen gemeint?"
 
 #: help.c:443
-#, fuzzy, c-format
+#, c-format
 msgid "%s: %s - %s"
-msgstr "%s: %s"
+msgstr "%s: %s - %s"
 
 #: merge.c:56
 msgid "failed to read the cache"
 msgstr "Lesen des Zwischenspeichers fehlgeschlagen"
 
@@ -953,16 +953,16 @@ msgstr ""
 "  (benutzen Sie \"git pull\" um Ihren Branch mit dem Remote-Branch "
 "zusammenzuführen)\n"
 
 #: run-command.c:80
 msgid "open /dev/null failed"
-msgstr ""
+msgstr "Öffnen von /dev/null fehlgeschlagen"
 
 #: run-command.c:82
 #, c-format
 msgid "dup2(%d,%d) failed"
-msgstr ""
+msgstr "dup2(%d,%d) fehlgeschlagen"
 
 #: sequencer.c:206 builtin/merge.c:790 builtin/merge.c:903
 #: builtin/merge.c:1013 builtin/merge.c:1023
 #, c-format
 msgid "Could not open '%s' for writing"
@@ -1221,10 +1221,22 @@ msgid ""
 "\n"
 "where \"$br\" is somehow empty and a 40-hex ref is created. Please\n"
 "examine these refs and maybe delete them. Turn this message off by\n"
 "running \"git config advice.object_name_warning false\""
 msgstr ""
+"Git erzeugt normalerweise keine Referenzen die mit\n"
+"40 Hex-Zeichen enden, da diese ignoriert werden wenn\n"
+"Sie diese angeben. Diese Referenzen könnten ausversehen\n"
+"erzeugt worden sein. Zum Beispiel,\n"
+"\n"
+"  git checkout -b $br $(git rev-parse ...)\n"
+"\n"
+"wobei \"$br\" leer ist und eine 40-Hex-Referenz erzeugt\n"
+"wurde. Bitte prüfen Sie diese Referenzen und löschen\n"
+"Sie sie gegebenenfalls. Unterdrücken Sie diese Meldung\n"
+"indem Sie \"git config advice.object_name_warning false\"\n"
+"ausführen."
 
 #: sha1_name.c:1097
 msgid "HEAD does not point to a branch"
 msgstr "HEAD zeigt auf keinen Branch"
 
@@ -1447,15 +1459,12 @@ msgstr "Eine \"am\"-Sitzung ist im Gange."
 #: wt-status.c:825
 msgid "The current patch is empty."
 msgstr "Der aktuelle Patch ist leer."
 
 #: wt-status.c:829
-#, fuzzy
 msgid "  (fix conflicts and then run \"git am --continue\")"
-msgstr ""
-"  (beheben Sie die Konflikte und führen Sie dann \"git rebase --continue\" "
-"aus)"
+msgstr "  (beheben Sie die Konflikte und führen Sie dann \"git am --continue\" 
aus)"
 
 #: wt-status.c:831
 msgid "  (use \"git am --skip\" to skip this patch)"
 msgstr "  (benutzen Sie \"git am --skip\" um diesen Patch auszulassen)"
 
@@ -1538,26 +1547,20 @@ msgstr ""
 #: wt-status.c:954
 msgid "You are currently cherry-picking."
 msgstr "Sie führen gerade \"cherry-pick\" aus."
 
 #: wt-status.c:958
-#, fuzzy
 msgid "  (fix conflicts and run \"git cherry-pick --continue\")"
-msgstr ""
-"  (beheben Sie die Konflikte und führen Sie dann \"git revert --continue\" "
-"aus)"
+msgstr "  (beheben Sie die Konflikte und führen Sie dann \"git cherry-pick 
--continue\" aus)"
 
 #: wt-status.c:961
-#, fuzzy
 msgid "  (all conflicts fixed: run \"git cherry-pick --continue\")"
-msgstr "  (alle Konflikte behoben: führen Sie \"git revert --continue\" aus)"
+msgstr "  (alle Konflikte behoben: führen Sie \"git cherry-pick --continue\" 
aus)"
 
 #: wt-status.c:963
-#, fuzzy
 msgid "  (use \"git cherry-pick --abort\" to cancel the cherry-pick operation)"
-msgstr ""
-"  (benutzen Sie \"git revert --abort\" um die Revert-Operation abzubrechen)"
+msgstr "  (benutzen Sie \"git cherry-pick --abort\" um die 
Cherry-Pick-Operation abzubrechen)"
 
 #: wt-status.c:972
 #, c-format
 msgid "You are currently reverting commit %s."
 msgstr "Sie sind gerade an einem Revert von Commit '%s'."
@@ -1595,13 +1598,12 @@ msgstr ""
 #: wt-status.c:1173
 msgid "On branch "
 msgstr "Auf Branch "
 
 #: wt-status.c:1180
-#, fuzzy
 msgid "rebase in progress; onto "
-msgstr "Kein Rebase im Gange?"
+msgstr "Rebase im Gange; auf "
 
 #: wt-status.c:1187
 msgid "HEAD detached at "
 msgstr "HEAD losgelöst bei "
 
@@ -2221,11 +2223,11 @@ msgstr "make_cache_entry für Pfad '%s' fehlgeschlagen"
 #, c-format
 msgid "unable to remove %s from index"
 msgstr "konnte %s nicht aus der Staging-Area entfernen"
 
 #: builtin/apply.c:3851
-#, fuzzy, c-format
+#, c-format
 msgid "corrupt patch for submodule %s"
 msgstr "fehlerhafter Patch für Submodul %s"
 
 #: builtin/apply.c:3855
 #, c-format
@@ -3096,13 +3098,12 @@ msgstr "Eingabepfade sind durch ein NUL Zeichen 
abgeschlo

[PATCH] git-rebase: fix typo

2013-07-28 Thread Ralf Thielow
Signed-off-by: Ralf Thielow 
---
 git-rebase.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/git-rebase.sh b/git-rebase.sh
index 0039ecf..8d7659a 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -159,7 +159,7 @@ finish_rebase () {
die "$(eval_gettext "Cannot store \$stash_sha1")"
gettext 'Applying autostash resulted in conflicts.
 Your changes are safe in the stash.
-You can run "git stash pop" or "git stash drop" it at any time.
+You can run "git stash pop" or "git stash drop" at any time.
 '
fi
fi
-- 
1.8.2.1873.gfc589a4

--
To unsubscribe from this list: send the line "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] push: fix typo in advice message

2013-07-28 Thread Ralf Thielow
Signed-off-by: Ralf Thielow 
---
 builtin/push.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/builtin/push.c b/builtin/push.c
index 6d36c24..04abd2d 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -250,7 +250,7 @@ static const char message_advice_ref_fetch_first[] =
N_("Updates were rejected because the remote contains work that you 
do\n"
   "not have locally. This is usually caused by another repository 
pushing\n"
   "to the same ref. You may want to first integrate the remote 
changes\n"
-  "(e.g., 'git pull ...') before pushing again.\n"
+  "(e.g. 'git pull ...') before pushing again.\n"
   "See the 'Note about fast-forwards' in 'git push --help' for 
details.");
 
 static const char message_advice_ref_already_exists[] =
-- 
1.8.2.1873.gfc589a4

--
To unsubscribe from this list: send the line "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] imap-send: use Apple's Security framework for base64 encoding

2013-07-28 Thread Jonathan Nieder
Hi,

David Aguilar wrote:

> --- a/imap-send.c
> +++ b/imap-send.c
> @@ -22,14 +22,11 @@
>   *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
>   */
>  
> -#include "cache.h"
> -#include "exec_cmd.h"
> -#include "run-command.h"
> -#include "prompt.h"
>  #ifdef NO_OPENSSL
>  typedef void *SSL;
>  #else
>  #ifdef APPLE_COMMON_CRYPTO
> +/* git-compat-util.h overwrites ctype.h; this must be included first */
>  #include 

Thanks for your work on this.

Currently each translation unit of git includes git-compat-util.h or a
header like cache.h that includes git-compat-util.h before doing
anything else, since otherwise feature test macros are not set before
the first system header is included.

The above (CommonCrypto needing to be included before some of the
definitions from git-compat-util.h) suggests to me that CommonCrypto
should just be included directly from git-compat-util.h in some
appropriate place.  That way any other header that needs CommonCrypto
routines only has to include git-compat-util.h first as usual and
doesn't have to worry about the order of other #includes.  Could that
work?

Thanks and hope that helps,
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


Re: [PATCH V2] TIG: Fix to reinstate proper operation with no arguments

2013-07-28 Thread Jonas Fonseca
On Wed, Jul 24, 2013 at 8:50 AM, Drew Northup  wrote:
> This time, knowing for sure now that format->buf is not being used in
> the extant code path for any other purpose, I went ahead and
> initialized the whole thing to be sure that we don't find any other
> ghosts hiding in that buffer between uses. Just initializing the
> first byte fixes the near term problem but does not prevent the buffer
> initialization issue that this bug highlighted from rising up again
> later on.

Thanks applied with minor tidyup.

> diff --git a/tig.c b/tig.c
> index ba9ba98..c65bc43 100644
> --- a/tig.c
> +++ b/tig.c
> @@ -3104,8 +3104,12 @@ format_expand_arg(struct format_context *format, const 
> char *name)
>  static bool
>  format_append_arg(struct format_context *format, const char ***dst_argv, 
> const char *arg)
>  {
> +   int i;

Added space after the declaration.

> format->bufpos = 0;
>
> +   for (i = 0; i < SIZEOF_STR; i++)

Changed this to use sizeof(format->buf) instead.

> +   format->buf[i] = 0;
> +
> while (arg) {
> char *next = strstr(arg, "%(");
> int len = next ? next - arg : strlen(arg);
> --
> 1.8.0
>

-- 
Jonas Fonseca
--
To unsubscribe from this list: send the line "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: What's cooking in git.git (Jul 2013, #07; Sun, 21)

2013-07-28 Thread Jens Lehmann
Am 22.07.2013 22:47, schrieb Jens Lehmann:
> Am 22.07.2013 09:48, schrieb Duy Nguyen:
>> On Mon, Jul 22, 2013 at 2:32 PM, Jens Lehmann  wrote:
>>> Am 22.07.2013 08:57, schrieb Junio C Hamano:
 * jl/submodule-mv (2013-04-23) 5 commits
  . submodule.c: duplicate real_path's return value
  . rm: delete .gitmodules entry of submodules removed from the work tree
  . Teach mv to update the path entry in .gitmodules for moved submodules
  . Teach mv to move submodules using a gitfile
  . Teach mv to move submodules together with their work trees

  "git mv A B" when moving a submodule A does "the right thing",
  inclusing relocating its working tree and adjusting the paths in
  the .gitmodules file.

  Ejected from 'pu', as it conflicts with nd/magic-pathspec.
>>>
>>> So I'll base my upcoming re-roll on pu, right?
>>
>> The conflicted part is the use of common_prefix. I think you might be
>> able to avoid the conflict by using quote.c:path_relative() instead of
>> common_prefix() and prepending "../" manually. Or not, I did not read
>> path_relative() carefully, nor your connect_work_tree_and_git_dir().
> 
> Thanks for the pointers, I'll look into that.

Yup, relative_path() seems to be the solution here (and makes the
connect_work_tree_and_git_dir() function much shorter :-).

What worries me is that even though t7001 breaks because of this
conflict (just like it should) when run inside the t directory by
itself, the prove and normal test runs did not report any failures.
I have no idea what is going on here ...
--
To unsubscribe from this list: send the line "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] editor: use canonicalized absolute path

2013-07-28 Thread Ramkumar Ramachandra
By improving the relative_path() algorithm, e02ca72 (path.c: refactor
relative_path(), not only strip prefix, 2013-06-25) uncovered a latent
bug.  While most editor applications like cat and vim handle
non-canonicalized relative paths fine, emacs does not.  This is due to a
long-standing bug in emacs, where it refuses to resolve symlinks in the
supplied path:

  #!/bin/sh
  mkdir z z/a z/b
  echo moodle >z/a/file
  ln -s z/b
  cd b
  emacs ../a/file # fail: opens /tmp/a/file

Even if emacs were to be patched to fix this bug now, we still need to
support users running older versions.

Co-authored-by: Nguyễn Thái Ngọc Duy 
Signed-off-by: Ramkumar Ramachandra 
---
 Urgent candidate for maint.  I wrote to emacs-devel, but nobody seems
 to be interested; the sources are horrendously unmaintainable, and
 the project should die soon.

 editor.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/editor.c b/editor.c
index 27bdecd..0abbd8d 100644
--- a/editor.c
+++ b/editor.c
@@ -37,7 +37,7 @@ int launch_editor(const char *path, struct strbuf *buffer, 
const char *const *en
return error("Terminal is dumb, but EDITOR unset");
 
if (strcmp(editor, ":")) {
-   const char *args[] = { editor, path, NULL };
+   const char *args[] = { editor, real_path(path), NULL };
struct child_process p;
int ret, sig;
 
-- 
1.8.4.rc0.2.g7ba4592

--
To unsubscribe from this list: send the line "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 v3] gitk: Add a "Save file as" menu item

2013-07-28 Thread Andreas Amann
Previously, there was no easy way to save a particular file from the
currently selected revision.

This patch adds a menu item "Save file as" to the file list popup
menu, which opens a file selection dialog to determine the name under
which a file should be saved.  The default filename is of the form
"[shortid] basename".  If the current revision is the index, the
default pattern is of the form "[index] basename".  This works for
both, the "Patch" and "Tree" view.  The menu item is disabled for the
"local uncommitted changes" fake revision.

Signed-off-by: Andreas Amann 
---
 gitk | 36 
 1 file changed, 36 insertions(+)

The previous version V2 of the patch did not work, when gitk was started
in a subdirectory of the repo and a file was saved from tree view.  This
is now fixed. 

diff --git a/gitk b/gitk
index 5cd00d8..6b66f18 100755
--- a/gitk
+++ b/gitk
@@ -2595,6 +2595,7 @@ proc makewindow {} {
{mc "Highlight this too" command {flist_hl 0}}
{mc "Highlight this only" command {flist_hl 1}}
{mc "External diff" command {external_diff}}
+   {mc "Save file as" command {save_file_as}}
{mc "Blame parent commit" command {external_blame 1}}
 }
 $flist_menu configure -tearoff 0
@@ -3378,6 +3379,7 @@ proc sel_flist {w x y} {
 proc pop_flist_menu {w X Y x y} {
 global ctext cflist cmitmode flist_menu flist_menu_file
 global treediffs diffids
+global nullid
 
 stopfinding
 set l [lindex [split [$w index "@$x,$y"] "."] 0]
@@ -3395,6 +3397,12 @@ proc pop_flist_menu {w X Y x y} {
 }
 # Disable "External diff" item in tree mode
 $flist_menu entryconf 2 -state $xdiffstate
+set savefilestate "normal"
+if {[lindex $diffids 0] eq $nullid} {
+   set savefilestate "disabled"
+}
+# Disable "Save file as" item "local uncommited changes" revision
+$flist_menu entryconf 3 -state $savefilestate
 tk_popup $flist_menu $X $Y
 }
 
@@ -3496,6 +3504,34 @@ proc external_diff_get_one_file {diffid filename 
diffdir} {
   "revision $diffid"]
 }
 
+proc save_file_as {} {
+global nullid nullid2
+global flist_menu_file cmitmode
+global diffids
+
+set diffid [lindex $diffids 0]
+if {$diffid == $nullid} {
+   return
+} elseif {$diffid == $nullid2} {
+   set diffidtext [mc "index"]
+   set diffid ""
+   set whattext $diffidtext
+} else {
+   set diffidtext [shortids $diffid]
+   set whattext "[mc "revision"] $diffidtext"
+}
+set diffid $diffid:
+if {$cmitmode eq "tree"} {
+   set diffid $diffid./
+}
+set difffile "\[$diffidtext\] [file tail $flist_menu_file]"
+set difffile [tk_getSaveFile -initialfile $difffile -title [mc "Save file 
as"] -parent .]
+if {$difffile eq {}} {
+   return
+}
+save_file_from_commit $diffid$flist_menu_file $difffile $whattext
+}
+
 proc external_diff {} {
 global nullid nullid2
 global flist_menu_file
-- 
1.8.3.3


Andreas Amann  writes:
> Previously, there was no easy way to save a particular file from the
> currently selected revision.
>
> This patch adds a menu item "Save file as" to the file list popup
> menu, which opens a file selection dialog to determine the name under
> which a file should be saved.  The default filename is of the form
> "[shortid] basename".  If the current revision is the index, the
> default pattern is of the form "[index] basename".  This works for
> both, the "Patch" and "Tree" view.  The menu item is disabled for the
> "local uncommitted changes" fake revision.
>
> Signed-off-by: Andreas Amann 
> ---
>  gitk | 32 
>  1 file changed, 32 insertions(+)
>
> diff --git a/gitk b/gitk
> index 5cd00d8..b5a70b5 100755
> --- a/gitk
> +++ b/gitk
> @@ -2595,6 +2595,7 @@ proc makewindow {} {
>   {mc "Highlight this too" command {flist_hl 0}}
>   {mc "Highlight this only" command {flist_hl 1}}
>   {mc "External diff" command {external_diff}}
> + {mc "Save file as" command {save_file_as}}
>   {mc "Blame parent commit" command {external_blame 1}}
>  }
>  $flist_menu configure -tearoff 0
> @@ -3378,6 +3379,7 @@ proc sel_flist {w x y} {
>  proc pop_flist_menu {w X Y x y} {
>  global ctext cflist cmitmode flist_menu flist_menu_file
>  global treediffs diffids
> +global nullid
>  
>  stopfinding
>  set l [lindex [split [$w index "@$x,$y"] "."] 0]
> @@ -3395,6 +3397,12 @@ proc pop_flist_menu {w X Y x y} {
>  }
>  # Disable "External diff" item in tree mode
>  $flist_menu entryconf 2 -state $xdiffstate
> +set savefilestate "normal"
> +if {[lindex $diffids 0] eq $nullid} {
> + set savefilestate "disabled"
> +}
> +# Disable "Save file as" item "local uncommited changes" revision
> +$flist_menu entryconf 3 -state $savefilestate
>  tk_popup $flist_menu $X $Y
>  }
>  
> @@ -3496,6 +3504,30 @@ proc external_diff_get_one_file {diffid filename 
> dif

Re: [BUG] git_path() returns relative paths

2013-07-28 Thread Ramkumar Ramachandra
Duy Nguyen wrote:
> How about something like this as a workaround for emacs?

Even if we do manage to patch Emacs now, we still need to support
older versions: so yeah, this is an urgent candidate for maint.  I'm
waiting for the word from Emacs-Devel before writing out a commit
message.
--
To unsubscribe from this list: send the line "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: [BUG] git_path() returns relative paths

2013-07-28 Thread Ramkumar Ramachandra
Duy Nguyen wrote:
> In the no-submodules symlink test case, the path given to the editor
> is .git/COMMIT_EDITMSG, no following ".." back in the symlink target.

Thanks, and sorry about the stupidity.  I just patched
builtin/commit.c to check this.

> This bug can be reproduced without git involved:

I'm taking this up with Emacs-Devel; you are CC'ed.
--
To unsubscribe from this list: send the line "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: [BUG] git_path() returns relative paths

2013-07-28 Thread Duy Nguyen
On Sun, Jul 28, 2013 at 3:49 PM, Ramkumar Ramachandra
 wrote:
> Duy Nguyen wrote:
>> I think instead of letting the kernel walk the path, emacs does it by
>> itself.
>
> If this were true, shouldn't we be able to reproduce the behavior with
> my no-submodules symlink testcase?  How can it resolve symlinks in one
> case, and not in the other case?

In the no-submodules symlink test case, the path given to the editor
is .git/COMMIT_EDITMSG, no following ".." back in the symlink target.
This bug can be reproduced without git involved:

mkdir z z/a z/b
echo ha >z/a/file
ln -s z/b
cd b
cat ../a/file
emacs ../a/file # fail to open 'file'
-- 
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


Re: [PATCH] builtins: search builtin commands via binary search.

2013-07-28 Thread Eric Sunshine
On Sat, Jul 27, 2013 at 4:49 AM, Stefan Beller
 wrote:
> I was fiddling around with make now to include the suggestion of Eric to
> check the arguments for being sorted in make. However I do not
> seem to fully understand the syntax yet.
> My approach would have been:
>
> sorted_internal_cmds: git.c
> { awk '/cmd_struct commands/,/};/ { if (match($2,/"/)) print $2 }' 
> builtin.actual && \
> sort builtin.expect && \
> cmp -s builtin.expect builtin.actual && \
> rm builtin.expect builtin.actual \
> }
>
> all:: sorted_internal_cmds
>
> But then there is
> $ make
> ...
> }
> /bin/sh: 5: Syntax error: end of file unexpected (expecting "}")
>
> So I suspect the { within the shell code inside the awk parameter is messing 
> up?

As Andreas noted, you need a semicolon before the closing shell '}',
however it's not clear why you added the braces since they are not
needed. The following works (after fixing whitespace corruption):

-->8--
diff --git a/Makefile b/Makefile
index ef442eb..82e727c 100644
--- a/Makefile
+++ b/Makefile
@@ -1681,6 +1681,15 @@ shell_compatibility_test:
please_set_SHELL_PATH_to_a_more_modern_shell
 strip: $(PROGRAMS) git$X
  $(STRIP) $(STRIP_OPTS) $^

+.PHONY: sorted_internal_cmds
+all:: sorted_internal_cmds
+
+sorted_internal_cmds: git.c
+ @awk '/cmd_struct commands/,/};/ { if (match($$2,/"/)) print $$2 }'
builtin.actual && \
+ sort builtin.expect && \
+ cmp -s builtin.expect builtin.actual && \
+ rm builtin.expect builtin.actual
+
 ### Target-specific flags and dependencies

 # The generic compilation pattern rule and automatically
-->8--

Note the $$2 in awk expression. Also the .PHONY is a good idea.

However, perhaps, it is better for this check to be part of the test
suite. It might look like this (after fixing whitespace corruption):

-->8--
diff --git a/t/t-basic.sh b/t/t-basic.sh
index 10be52b..e5ba504 100755
--- a/t/t-basic.sh
+++ b/t/t-basic.sh
@@ -387,6 +387,14 @@ test_expect_success 'tests clean up even on failures' "
 
 # Basics of the basics

+# git.c commands[] of builtins is properly sorted
+test_expect_success 'builtin commands[] sorted' '
+ awk "/cmd_struct commands/,/};/ { if (match(\$2,/\"/)) print \$2 }" \
+ <../../git.c >actual && \
+ sort expect && \
+ test_cmp expect actual
+'
+
 # updating a new file without --add should fail.
 test_expect_success 'git update-index without --add should fail adding' '
  test_must_fail git update-index should-be-empty
-->8--

I'm not sure that referencing ../../git.c from within the test suite
is kosher. Perhaps Jonathan can say something about that.
--
To unsubscribe from this list: send the line "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: [BUG] git_path() returns relative paths

2013-07-28 Thread Ramkumar Ramachandra
Duy Nguyen wrote:
> I think instead of letting the kernel walk the path, emacs does it by
> itself.

If this were true, shouldn't we be able to reproduce the behavior with
my no-submodules symlink testcase?  How can it resolve symlinks in one
case, and not in the other case?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html