[PATCH v3] run-command: add hint when a hook is ignored

[Damien Marié]

When an hook is present but the file is not set as executable then git will
ignore the hook.
For now this is silent which can be confusing.

This commit adds this warning to improve the situation:

  hint: The 'pre-commit' hook was ignored because it's not set as executable.
  hint: You can disable this warning with `git config advice.ignoredHook false`

To allow the old use-case of enabling/disabling hooks via the executable flag a
new setting is introduced: advice.ignoredHook.

Signed-off-by: Damien Marié <dam...@dam.io>
---
 Documentation/config.txt   |  3 +++
 advice.c   |  2 ++
 advice.h   |  1 +
 contrib/completion/git-completion.bash |  1 +
 run-command.c  | 18 +++
 t/t7520-ignored-hook-warning.sh| 41 ++
 6 files changed, 66 insertions(+)
 create mode 100755 t/t7520-ignored-hook-warning.sh

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1ac0ae6adb046..9abca499f725c 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -351,6 +351,9 @@ advice.*::
addEmbeddedRepo::
Advice on what to do when you've accidentally added one
git repo inside of another.
+   ignoredHook::
+   Advice shown if an hook is ignored because the it's not
+   set as executable.
 --
 
 core.fileMode::
diff --git a/advice.c b/advice.c
index d81e1cb7425b0..970bd2b71bf53 100644
--- a/advice.c
+++ b/advice.c
@@ -17,6 +17,7 @@ int advice_set_upstream_failure = 1;
 int advice_object_name_warning = 1;
 int advice_rm_hints = 1;
 int advice_add_embedded_repo = 1;
+int advice_ignored_hook = 1;
 
 static struct {
const char *name;
@@ -38,6 +39,7 @@ static struct {
{ "objectnamewarning", _object_name_warning },
{ "rmhints", _rm_hints },
{ "addembeddedrepo", _add_embedded_repo },
+   { "ignoredhook", _ignored_hook},
 
/* make this an alias for backward compatibility */
{ "pushnonfastforward", _push_update_rejected }
diff --git a/advice.h b/advice.h
index c84a44531c7d8..f525d6f89cb44 100644
--- a/advice.h
+++ b/advice.h
@@ -19,6 +19,7 @@ extern int advice_set_upstream_failure;
 extern int advice_object_name_warning;
 extern int advice_rm_hints;
 extern int advice_add_embedded_repo;
+extern int advice_ignored_hook;
 
 int git_default_advice_config(const char *var, const char *value);
 __attribute__((format (printf, 1, 2)))
diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index d93441747523a..a331ccc556b01 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2350,6 +2350,7 @@ _git_config ()
advice.rmHints
advice.statusHints
advice.statusUoption
+   advice.ignoredHook
alias.
am.keepcr
am.threeWay
diff --git a/run-command.c b/run-command.c
index b5e6eb37c0eb3..288abbba5afd7 100644
--- a/run-command.c
+++ b/run-command.c
@@ -5,6 +5,7 @@
 #include "argv-array.h"
 #include "thread-utils.h"
 #include "strbuf.h"
+#include "string-list.h"
 
 void child_process_init(struct child_process *child)
 {
@@ -1169,11 +1170,28 @@ const char *find_hook(const char *name)
strbuf_reset();
strbuf_git_path(, "hooks/%s", name);
if (access(path.buf, X_OK) < 0) {
+   int err = errno;
+
 #ifdef STRIP_EXTENSION
strbuf_addstr(, STRIP_EXTENSION);
if (access(path.buf, X_OK) >= 0)
return path.buf;
+   if (errno == EACCES)
+   err = errno;
 #endif
+
+   if (err == EACCES && advice_ignored_hook) {
+   static struct string_list advise_given = 
STRING_LIST_INIT_DUP;
+   
+   if (!string_list_lookup(_given, name)) {
+   string_list_insert(_given, name);
+   advise(_("The '%s' hook was ignored because "
+   "it's not set as 
executable.\n"
+   "You can disable this 
warning with "
+   "`git config 
advice.ignoredHook false`."),
+   path.buf);
+   }
+   }
return NULL;
}
return path.buf;
diff --git a/t/t7520-ignored-hook-warning.sh b/t/t7520-ignored-hook-warning.sh
new file mode 100755
index 0..634fb7f23a040
--- /dev/null
+++ b/t/t7520-ignored-hook-warning.sh
@@ -0,0 +1,41 @@
+#!/bin/sh
+
+test_description=

Re: [PATCH v2] run-command: add hint when a hook is ignored

[Damien]

Thanks for the help, a new patch is coming with those fixes applied.

On Fri, Oct 6, 2017 at 7:53 AM, Junio C Hamano  wrote:
> Junio C Hamano  writes:
>
>> I think it is easier to reason about if this were not "else if", but
>> just a simple "if".
>
> And here are two small suggested changes to the code portion of your
> patch.
>
>  - break if / else if cascade into two independent if / if
>statements for clarity.
>
>  - give the "ignored hook" advice only once per 
>pair.
>
>
>
>  run-command.c | 19 +--
>  1 file changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/run-command.c b/run-command.c
> index 0f8a5f7fa2..0e60dd2075 100644
> --- a/run-command.c
> +++ b/run-command.c
> @@ -5,6 +5,7 @@
>  #include "argv-array.h"
>  #include "thread-utils.h"
>  #include "strbuf.h"
> +#include "string-list.h"
>
>  void child_process_init(struct child_process *child)
>  {
> @@ -1170,19 +1171,25 @@ const char *find_hook(const char *name)
> strbuf_git_path(, "hooks/%s", name);
> if (access(path.buf, X_OK) < 0) {
> int err = errno;
> +
>  #ifdef STRIP_EXTENSION
> strbuf_addstr(, STRIP_EXTENSION);
> if (access(path.buf, X_OK) >= 0)
> return path.buf;
> -   else if (errno == EACCES)
> +   if (errno == EACCES)
> err = errno;
>  #endif
> if (err == EACCES && advice_ignored_hook) {
> -   advise(_(
> -   "The '%s' hook was ignored because "
> -   "it's not set as executable.\n"
> -   "You can disable this warning with "
> -   "`git config advice.ignoredHook false`."), 
> path.buf);
> +   static struct string_list advise_given = 
> STRING_LIST_INIT_DUP;
> +
> +   if (!string_list_lookup(_given, name)) {
> +   string_list_insert(_given, name);
> +   advise(_("The '%s' hook was ignored because "
> +"it's not set as executable.\n"
> +"You can disable this warning with "
> +"`git config advice.ignoredHook 
> false`."),
> +  path.buf);
> +   }
> }
> return NULL;
> }
> --
> 2.15.0-rc0-155-g07e9c1a78d
>

[PATCH v2] run-command: add hint when a hook is ignored

[Damien Marié]

When an hook is present but the file is not set as executable then git will
ignore the hook.
For now this is silent which can be confusing.

This commit adds this warning to improve the situation:

  hint: The 'pre-commit' hook was ignored because it's not set as executable.
  hint: You can disable this warning with `git config advice.ignoredHook false`

To allow the old use-case of enabling/disabling hooks via the executable flag a
new setting is introduced: advice.ignoredHook.

Signed-off-by: Damien Marié <dam...@dam.io>
---
 Documentation/config.txt   |  3 ++
 advice.c   |  2 +
 advice.h   |  1 +
 contrib/completion/git-completion.bash |  1 +
 run-command.c  | 10 +
 t/t7519-ignored-hook-warning.sh| 67 ++
 6 files changed, 84 insertions(+)
 create mode 100755 t/t7519-ignored-hook-warning.sh

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1ac0ae6adb046..9abca499f725c 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -351,6 +351,9 @@ advice.*::
addEmbeddedRepo::
Advice on what to do when you've accidentally added one
git repo inside of another.
+   ignoredHook::
+   Advice shown if an hook is ignored because the it's not
+   set as executable.
 --
 
 core.fileMode::
diff --git a/advice.c b/advice.c
index d81e1cb7425b0..970bd2b71bf53 100644
--- a/advice.c
+++ b/advice.c
@@ -17,6 +17,7 @@ int advice_set_upstream_failure = 1;
 int advice_object_name_warning = 1;
 int advice_rm_hints = 1;
 int advice_add_embedded_repo = 1;
+int advice_ignored_hook = 1;
 
 static struct {
const char *name;
@@ -38,6 +39,7 @@ static struct {
{ "objectnamewarning", _object_name_warning },
{ "rmhints", _rm_hints },
{ "addembeddedrepo", _add_embedded_repo },
+   { "ignoredhook", _ignored_hook},
 
/* make this an alias for backward compatibility */
{ "pushnonfastforward", _push_update_rejected }
diff --git a/advice.h b/advice.h
index c84a44531c7d8..f525d6f89cb44 100644
--- a/advice.h
+++ b/advice.h
@@ -19,6 +19,7 @@ extern int advice_set_upstream_failure;
 extern int advice_object_name_warning;
 extern int advice_rm_hints;
 extern int advice_add_embedded_repo;
+extern int advice_ignored_hook;
 
 int git_default_advice_config(const char *var, const char *value);
 __attribute__((format (printf, 1, 2)))
diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index d93441747523a..a331ccc556b01 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2350,6 +2350,7 @@ _git_config ()
advice.rmHints
advice.statusHints
advice.statusUoption
+   advice.ignoredHook
alias.
am.keepcr
am.threeWay
diff --git a/run-command.c b/run-command.c
index b5e6eb37c0eb3..9456355595cc1 100644
--- a/run-command.c
+++ b/run-command.c
@@ -1169,11 +1169,21 @@ const char *find_hook(const char *name)
strbuf_reset();
strbuf_git_path(, "hooks/%s", name);
if (access(path.buf, X_OK) < 0) {
+   int err = errno;
 #ifdef STRIP_EXTENSION
strbuf_addstr(, STRIP_EXTENSION);
if (access(path.buf, X_OK) >= 0)
return path.buf;
+   else if (errno == EACCES)
+   err = errno;
 #endif
+   if (err == EACCES && advice_ignored_hook) {
+   advise(_(
+   "The '%s' hook was ignored because "
+   "it's not set as executable.\n"
+   "You can disable this warning with "
+   "`git config advice.ignoredHook false`."), 
path.buf);
+   }
return NULL;
}
return path.buf;
diff --git a/t/t7519-ignored-hook-warning.sh b/t/t7519-ignored-hook-warning.sh
new file mode 100755
index 0..59052a4429111
--- /dev/null
+++ b/t/t7519-ignored-hook-warning.sh
@@ -0,0 +1,67 @@
+#!/bin/sh
+
+test_description='ignored hook warning'
+
+. ./test-lib.sh
+
+# install hook that always succeeds
+HOOKDIR="$(git rev-parse --git-dir)/hooks"
+HOOK="$HOOKDIR/pre-commit"
+mkdir -p "$HOOKDIR"
+cat > "$HOOK" <&1 >/dev/null | grep hint
+then
+false
+else
+true
+fi
+
+'
+
+chmod -x "$HOOK"
+
+test_expect_success POSIXPERM 'warning if hook not set as executable' '
+
+if git commit -m "more" 2>&1 >/dev/null | grep hint
+then
+true
+else
+false
+fi
+'
+
+test_expect_succes

Re: [PATCH] run-command.c: add hint when hook is not executable

[Damien]

On Wed, Oct 4, 2017 at 6:40 AM, Junio C Hamano <gits...@pobox.com> wrote:
> Damien <dam...@dam.io> writes:
>
>> ---
>
> Please explain why this change makes sense to those who find this
> commit in "git log" output six months down the line, without having
> read the original thread that motivated you to add this feature
> above this line with three dashes.  Use your full name on the From:
> header of your mail (or alternatively, you can use an in-body "From:"
> to override what your MUA places there) and add sign-off with the
> same name (cf. Documentation/SubmittingPatches).

Thanks, I'm gonna post another version via submitGit. I'm not sure
how to send the "cover letter" via submitGit so I'm just gonna explain
the patch here and then send it in another message.

First, I changed the name of the config to "advice.ignoredHook"
since it's more generic and it will allow us to add other cases
such as the bad permission case..

> But for the purpose of your patch, you now do care.  access(X_OK)
> may have failed with EACCESS (i.e. you have no permission to run the
> script), in which case your new advise() call may make sense.  But
> it may have failed with ENOENT or ENOTDIR.  And your new advise()
> call is a disaster, if the user didn't even have such a hook.

For sure, the previous version was really broken. I've now added a
EACCES check. But I see two shortcomings left:

  - the message is shown twice (for a "pre-commit" hook at least)
  - I tried to take into account the STRIP_EXTENSION case but
it's not tested yet

> Writing a test would have helped notice this, I would think.  You'd
> need at least the following variations to cover possibilities:

As you will see, I've added tests but my scripting skills are a bit
lacking and I used a simple "if...then false else true". I've tried
`grep -v` and similar things but this solution is the only one that
I found that really works.

Thanks for the review, see PATCH in a coming email.

[PATCH] run-command.c: add hint when hook is not executable

[Damien]

---
 Documentation/config.txt   | 2 ++
 advice.c   | 2 ++
 advice.h   | 1 +
 contrib/completion/git-completion.bash | 1 +
 run-command.c  | 4 
 5 files changed, 10 insertions(+)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1ac0ae6adb046..83b1884cf22fc 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -351,6 +351,8 @@ advice.*::
addEmbeddedRepo::
Advice on what to do when you've accidentally added one
git repo inside of another.
+   hookNotExecutable::
+   Shown when an hook is there but not executable.
 --
 
 core.fileMode::
diff --git a/advice.c b/advice.c
index d81e1cb7425b0..969ba149daeec 100644
--- a/advice.c
+++ b/advice.c
@@ -17,6 +17,7 @@ int advice_set_upstream_failure = 1;
 int advice_object_name_warning = 1;
 int advice_rm_hints = 1;
 int advice_add_embedded_repo = 1;
+int advice_hook_not_executable = 1;
 
 static struct {
const char *name;
@@ -38,6 +39,7 @@ static struct {
{ "objectnamewarning", _object_name_warning },
{ "rmhints", _rm_hints },
{ "addembeddedrepo", _add_embedded_repo },
+   { "hooknotexecutable", _hook_not_executable},
 
/* make this an alias for backward compatibility */
{ "pushnonfastforward", _push_update_rejected }
diff --git a/advice.h b/advice.h
index c84a44531c7d8..061492976b362 100644
--- a/advice.h
+++ b/advice.h
@@ -19,6 +19,7 @@ extern int advice_set_upstream_failure;
 extern int advice_object_name_warning;
 extern int advice_rm_hints;
 extern int advice_add_embedded_repo;
+extern int advice_hook_not_executable;
 
 int git_default_advice_config(const char *var, const char *value);
 __attribute__((format (printf, 1, 2)))
diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index d93441747523a..6324db0c44f17 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2350,6 +2350,7 @@ _git_config ()
advice.rmHints
advice.statusHints
advice.statusUoption
+   advice.hookNotExecutable
alias.
am.keepcr
am.threeWay
diff --git a/run-command.c b/run-command.c
index b5e6eb37c0eb3..95d93a23bf87e 100644
--- a/run-command.c
+++ b/run-command.c
@@ -1174,6 +1174,10 @@ const char *find_hook(const char *name)
if (access(path.buf, X_OK) >= 0)
return path.buf;
 #endif
+   if (advice_hook_not_executable) {
+   advise(_("The '%s' hook was ignored because it's not 
set as executable."
+   "\nYou can disable this warning with `git 
config advice.hookNotExecutable false`"), name);
+   }
return NULL;
}
return path.buf;

--
https://github.com/git/git/pull/411

hooks are ignored if there are not marked as executable

[Damien]

Hi,

If you do `echo my_script > .git/hooks/pre-commit` and then `git commit`,
The hook is just gonna be ignored.
But if you do `chmod +x .git/hooks/pre-commit`, then it's executed.

I think ignoring a hook is misleading and not newbie friendly, an error
message to signal an incorrectly configured hook could be better.
At least as a warning to be backward-compatible.

Thanks,
Damien

[PATCH v2] git-check-ref-format: clarify man for --normalize

[Damien Regad]

Use of 'iff' may be confusing to people not familiar with this term.

Improving the --normalize option's documentation to remove the use of
'iff', and clearly describe what happens when the condition is not met.
---
 Documentation/git-check-ref-format.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/git-check-ref-format.txt
b/Documentation/git-check-ref-format.txt
index 8611a99..92777ce 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -100,10 +100,10 @@ OPTIONS
 --normalize::
Normalize 'refname' by removing any leading slash (`/`)
characters and collapsing runs of adjacent slashes between
-   name components into a single slash.  Iff the normalized
+   name components into a single slash.  If the normalized
refname is valid then print it to standard output and exit
-   with a status of 0.  (`--print` is a deprecated way to spell
-   `--normalize`.)
+   with a status of 0, otherwise exit with a non-zero status.
+   (`--print` is a deprecated way to spell `--normalize`.)


 EXAMPLES
-- 
2.7.4

Re: [PATCH] git-check-ref-format: fix typo in man page

[Damien Regad]

Thanks all for the feedback.

On 2017-02-19 21:40, Philip Oakley wrote:
> For those not familiar with 'iff', then a change to the doc is worthwhile.

Exactly. Not being a native English speaker, I had never seen 'iff' used
before. Now that you guys have pointed me to its meaning I guess it
makes sense in this context.

That being said, IMHO software documentation is not a mathematics
textbook, and should be written in "plain" English, so

On 2017-02-19 03:27, Jeff King wrote:
> So maybe an overall improvement would be something like:
>
>   If the normalized refname is valid then print it to standard output
>   and exit with a status of 0. Otherwise, exit with a non-zero status.

I'll submit a revised patch shortly, following your suggestion.

Cheers
Damien

[PATCH] git-check-ref-format: fix typo in man page

[Damien Regad]

---
 Documentation/git-check-ref-format.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/git-check-ref-format.txt
b/Documentation/git-check-ref-format.txt
index 8611a99..377c85a 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -100,7 +100,7 @@ OPTIONS
 --normalize::
Normalize 'refname' by removing any leading slash (`/`)
characters and collapsing runs of adjacent slashes between
-   name components into a single slash.  Iff the normalized
+   name components into a single slash.  If the normalized
refname is valid then print it to standard output and exit
with a status of 0.  (`--print` is a deprecated way to spell
`--normalize`.)
-- 
2.7.4

Re: Our cumbersome mailing list workflow

[Damien Robert]

 A bot could subscribe to the list and create branches in a public repo.
 (This idea feels familiar -- didn't somebody attempt this already?)

Thomas Rast maintains git notes that link git commits to their gmane
discussion, you can get them with

[remote mailnotes]
  url = git://github.com/trast/git.git
  fetch = refs/heads/notes/*:refs/notes/*

There is gmane branch and a message-id branch, its pretty usefull.

--
To unsubscribe from this list: send the line 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: Summary of the problems with git pull

[Damien Robert]

Felipe Contreras  wrote in message
5366db742d494_18f9e4b308aa@nysa.notmuch:
 == git update ==
 
 Another proposed solution is to have a new command: `git update`. This
 command would be similar to `git pull --ff-only` by default, but it
 could be configured to do merges instead, and when doing so in reverse.

Thanks for the nice summary.

As a user, I am very much in favor of adding a `git update` command. In
fact I already have a ruby script that does such a thing (fast-forward all my
local branches that have an upstream configured), so it would be nice to
have it directly in git core.

--
To unsubscribe from this list: send the line 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 stash pop` UX Problem

[Damien Robert]

Matthieu Moy  wrote in message vpqzjlf5q2z@anie.imag.fr:
 Maybe status should display a stash count if that count is  0, as
 this is part of the state of the repo.
 Maybe it would help some users, but not me for example. My main use of
 git stash is a safe replacement for git reset --hard: when I want to
 discard changes, but keep them safe just in case.
 So, my stash count is almost always 0, and I don't want to hear about
 it.

Related to your comment, I adapted git-stash
  https://gist.github.com/DamienRobert/9227034
to have the following (mis)features:

- There is a global --ref option that allows to specify the reference the
  stash will use (by default this is refs/mystash, git-stash.sh uses
  refs/stash).

  This allows to differenciate between different uses of stashes: save WIP
  before switching branch; keep a backup before a git reset;...

- There is a new command `git mystash dosave` that works like git stash but
  does not reset the worktree afterwards. Note that `git stash create`
  already does that, but it handles options differently than `git stash
  save`. `git mystash dosave` can be seen as a wrapper around `git stash
  create`.
  The reason is that while `git stash create` is intended for scripts, `git
  mystash dosave` is intended for the UI. One example of when we don't want
  to drop the worktree is when we want to do a `git checkout -m -- paths`
  but we want to save the current state in case the merge has conflicts.

- `git stash branch` pops the stash once the branch is created. I did not
  like this feature so `git mystash branch` does not pop the stash; use `git
  mystash popbranch` to have the original meaning of `git stash branch`.

- `git mystash save` (and `git stash dosave`) has a new option
  `--on-branch` which stores the stash onto the current branch rather than
  in $ref_stash. The idea is that when I use `git stash` for a WIP, then
  when I come back to the original branch I always forget that I had a
  stash for this branch, and if there were several WIP in between it can be
  hard to remember which stash to apply. With `--on-branch`, when I come
  back to the original branch I am now on the stash, and I know I just need
  to apply it. For that `git mystash apply` (or `git mystash pop`) also has
  a `--on-branch` option that tells it to use the stash on the current
  branch.

- `git mystash info` gives informations about a stash.

So obviously not all of these would be good for inclusion into git, but
maybe some of them would be somewhat worth it. When I have the time I'll
try to write tests and send proper patches.

-- 
Damien Robert
--
To unsubscribe from this list: send the line 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-p4: exception when cloning a perforce repository

[Damien Gérard]

On 18 Jan 2014, at 19:22, Pete Wyckoff p...@padd.com wrote:

 dam...@iwi.me wrote on Thu, 16 Jan 2014 17:02 +0100:
 
 On 16 Jan 2014, at 15:45, Pete Wyckoff p...@padd.com wrote:
 
 Oh cool, that helps a lot.  P4 is just broken here, so we can get
 away with being a bit sloppy in git.  I'll try just pretending
 empty symlinks are not in the repo.  Hopefully you'll have a
 future commit in your p4 repo that brings back bn.h properly.
 
 Thanks !
 I would love to use git instead of perforce if possible :)
 
 Still not sure about how I'll test this.
 
 I can test for you, no probleme with that.
 
 Any chance you can give this a go?  I've a bigger patch in
 a longer series, but this should be the minimal fix.  If it
 works, I'll ship it to Junio.

Yeah it seems to work fine !
I’ve finally imported all 152620 changesets :)

Thanks !

(git pull from this morning + patch)


 
 Thanks,
 
   -- Pete
 
 8
 
 From 8556ab04dd126184e26a380b7ed08998fd33debe Mon Sep 17 00:00:00 2001
 From: Pete Wyckoff p...@padd.com
 Date: Thu, 16 Jan 2014 18:34:09 -0500
 Subject: [PATCH] git p4: work around p4 bug that causes empty symlinks
 MIME-Version: 1.0
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: 8bit
 
 Damien Gérard highlights an interesting problem.  Some p4
 repositories end up with symlinks that have an empty target.  It
 is not possible to create this with current p4, but they do
 indeed exist.
 
 The effect in git p4 is that p4 print on the symlink returns an
 empty string, confusing the curret symlink-handling code.
 
 In p4, syncing to a change that includes such a bogus symlink
 creates errors:
 
//depot/empty-symlink - updating /home/me/p4/empty-symlink
rename: /home/me/p4/empty-symlink: No such file or directory
 
 and leaves no symlink.
 
 Replicate the p4 behavior by ignoring these bogus symlinks.  If
 they are fixed in later revisions, the symlink will be replaced
 properly.
 
 Reported-by: Damien Gérard dam...@iwi.me
 Signed-off-by: Pete Wyckoff p...@padd.com
 ---
 git-p4.py | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)
 
 diff --git a/git-p4.py b/git-p4.py
 index 5ea8bb8..e798ecf 100755
 --- a/git-p4.py
 +++ b/git-p4.py
 @@ -2075,7 +2075,14 @@ class P4Sync(Command, P4UserMap):
 # p4 print on a symlink sometimes contains target\n;
 # if it does, remove the newline
 data = ''.join(contents)
 -if data[-1] == '\n':
 +if not data:
 +# Some version of p4 allowed creating a symlink that pointed
 +# to nothing.  This causes p4 errors when checking out such
 +# a change, and errors here too.  Work around it by ignoring
 +# the bad symlink; hopefully a future change fixes it.
 +print \nIgnoring empty symlink in %s % file['depotFile']
 +return
 +elif data[-1] == '\n':
 contents = [data[:-1]]
 else:
 contents = [data]
 -- 
 1.8.5.2.320.g99957e5
 
 

--
To unsubscribe from this list: send the line 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-p4: exception when cloning a perforce repository

[Damien Gérard]

On 18 Jan 2014, at 19:22, Pete Wyckoff p...@padd.com wrote:

 dam...@iwi.me wrote on Thu, 16 Jan 2014 17:02 +0100:
 
 On 16 Jan 2014, at 15:45, Pete Wyckoff p...@padd.com wrote:
 
 Oh cool, that helps a lot.  P4 is just broken here, so we can get
 away with being a bit sloppy in git.  I'll try just pretending
 empty symlinks are not in the repo.  Hopefully you'll have a
 future commit in your p4 repo that brings back bn.h properly.
 
 Thanks !
 I would love to use git instead of perforce if possible :)
 
 Still not sure about how I'll test this.
 
 I can test for you, no probleme with that.
 
 Any chance you can give this a go?  I've a bigger patch in
 a longer series, but this should be the minimal fix.  If it
 works, I'll ship it to Junio.
 

Just for info, it works but it seems there are still some issues when a git 
repository is present within the perforce repo :

error: Invalid path 'Tools/Doc/bin/yuidoc/.git/FETCH_HEAD'
error: Invalid path 'Tools/Doc/bin/yuidoc/.git/HEAD'
error: Invalid path 'Tools/Doc/bin/yuidoc/.git/ORIG_HEAD’
[...]

Those files have been added then removed in another commit

I’ve have to make git reset —hard ‘HEAD^’  git p4 sync to a clean staging 
area right after the clone.




 Thanks,
 
   -- Pete
 
 8
 
 From 8556ab04dd126184e26a380b7ed08998fd33debe Mon Sep 17 00:00:00 2001
 From: Pete Wyckoff p...@padd.com
 Date: Thu, 16 Jan 2014 18:34:09 -0500
 Subject: [PATCH] git p4: work around p4 bug that causes empty symlinks
 MIME-Version: 1.0
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: 8bit
 
 Damien Gérard highlights an interesting problem.  Some p4
 repositories end up with symlinks that have an empty target.  It
 is not possible to create this with current p4, but they do
 indeed exist.
 
 The effect in git p4 is that p4 print on the symlink returns an
 empty string, confusing the curret symlink-handling code.
 
 In p4, syncing to a change that includes such a bogus symlink
 creates errors:
 
//depot/empty-symlink - updating /home/me/p4/empty-symlink
rename: /home/me/p4/empty-symlink: No such file or directory
 
 and leaves no symlink.
 
 Replicate the p4 behavior by ignoring these bogus symlinks.  If
 they are fixed in later revisions, the symlink will be replaced
 properly.
 
 Reported-by: Damien Gérard dam...@iwi.me
 Signed-off-by: Pete Wyckoff p...@padd.com
 ---
 git-p4.py | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)
 
 diff --git a/git-p4.py b/git-p4.py
 index 5ea8bb8..e798ecf 100755
 --- a/git-p4.py
 +++ b/git-p4.py
 @@ -2075,7 +2075,14 @@ class P4Sync(Command, P4UserMap):
 # p4 print on a symlink sometimes contains target\n;
 # if it does, remove the newline
 data = ''.join(contents)
 -if data[-1] == '\n':
 +if not data:
 +# Some version of p4 allowed creating a symlink that pointed
 +# to nothing.  This causes p4 errors when checking out such
 +# a change, and errors here too.  Work around it by ignoring
 +# the bad symlink; hopefully a future change fixes it.
 +print \nIgnoring empty symlink in %s % file['depotFile']
 +return
 +elif data[-1] == '\n':
 contents = [data[:-1]]
 else:
 contents = [data]
 -- 
 1.8.5.2.320.g99957e5
 
 

--
To unsubscribe from this list: send the line 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-p4: exception when cloning a perforce repository

[Damien Gérard]

On 16 Jan 2014, at 14:08, Pete Wyckoff p...@padd.com wrote:

 dam...@iwi.me wrote on Wed, 15 Jan 2014 09:56 +0100:
 p4 fstat  //depot/openssl/0.9.8j/openssl/include/openssl/bn.h@59702 
 ... depotFile //depot/openssl/0.9.8j/openssl/include/openssl/bn.h
 ... headAction edit
 ... headType symlink
 ... headTime 1237906419
 ... headRev 2
 ... headChange 59702
 ... headModTime 1231329423
 
 p4 print -q //depot/openssl/0.9.8j/openssl/include/openssl/bn.h#2 | od -c
 000
 
 p4 print  //depot/openssl/0.9.8j/openssl/include/openssl/bn.h#1
 //depot/openssl/0.9.8j/openssl/include/openssl/bn.h#1 - add change 59574 
 (text)
 p4 print  //depot/openssl/0.9.8j/openssl/include/openssl/bn.h#2
 //depot/openssl/0.9.8j/openssl/include/openssl/bn.h#2 - edit change 59702 
 (symlink)
 
 That's interesting.  When I do the equivalent p4 print commands
 it shows something like this.
 
 arf-git-test$ p4 fstat //depot/bn.h
 ... depotFile //depot/bn.h
 ... clientFile /dev/shm/trash directory.t9802-git-p4-filetype/cli/bn.h
 ... isMapped 
 ... headAction edit
 ... headType symlink
 ... headTime 1389876870
 ... headRev 2
 ... headChange 8
 ... headModTime 1389876870
 ... haveRev 2
 
 arf-git-test$ p4 print //depot/bn.h#1
 //depot/bn.h#1 - add change 7 (text)
 file-text
 
 arf-git-test$ p4 print //depot/bn.h#2
 //depot/bn.h#2 - edit change 8 (symlink)
 /elsewhere/bn.h
 
 I don't know how you manage to get a symlink with an empty
 destination like that.
 
 I'll work on a way to hack around this failure.  In the mean time,
 if you're game, it might be fun to see what p4 does with such a
 repository.  You could make a client for just that little subdir,
 check out at 59702 and see what is there:
 
 mkdir testmess
 cd testmess
 cat EOF | p4 client -i
 Client: testmess
 Description: testmess
 Root: $(pwd)
 View: //depot/openssl/0.9.8j/openssl/include/openssl/... //testmess/...
 EOF
 
 then take a look at how p4 represents the empty symlink
 in the filesystem:
 
 p4 sync @59702
 ls -la bn.h

I’ve tried exactly your commands, and I’ve got an empty folder..

{14:38}~/p4/testmess ➭ p4 sync @59702
//depot/openssl/0.9.8j/openssl/include/openssl/aes.h#2 - refreshing 
/home/dgerard/p4/testmess/aes.h
//depot/openssl/0.9.8j/openssl/include/openssl/asn1.h#2 - refreshing 
/home/dgerard/p4/testmess/asn1.h
//depot/openssl/0.9.8j/openssl/include/openssl/asn1_mac.h#2 - refreshing 
/home/dgerard/p4/testmess/asn1_mac.h
//depot/openssl/0.9.8j/openssl/include/openssl/asn1t.h#2 - refreshing 
/home/dgerard/p4/testmess/asn1t.h
//depot/openssl/0.9.8j/openssl/include/openssl/bio.h#2 - refreshing 
/home/dgerard/p4/testmess/bio.h
//depot/openssl/0.9.8j/openssl/include/openssl/blowfish.h#2 - refreshing 
/home/dgerard/p4/testmess/blowfish.h
//depot/openssl/0.9.8j/openssl/include/openssl/bn.h#2 - refreshing 
/home/dgerard/p4/testmess/bn.h
//depot/openssl/0.9.8j/openssl/include/openssl/buffer.h#2 - refreshing 
/home/dgerard/p4/testmess/buffer.h
[…]


{14:39}~/p4/testmess ➭ ls -la
total 12
drwxr-xr-x 2 dgerard dgerard 4096 janv. 16 14:37 .
drwxr-xr-x 4 dgerard dgerard 4096 janv. 16 14:34 ..
-rw-r--r-- 1 dgerard dgerard   93 janv. 16 14:37 .perforce  


Then I tried to sync the previous changeset, which is ok :

{14:44}~/p4/testmess ➭ p4 sync -f @59701
//depot/openssl/0.9.8j/openssl/include/openssl/aes.h#1 - updating 
/home/dgerard/p4/testmess/aes.h
[…]

{14:44}~/p4/testmess ➭ l
total 0
-r--r--r-- 1 dgerard dgerard 0 janv. 16 14:44 aes.h
-r--r--r-- 1 dgerard dgerard 0 janv. 16 14:44 asn1.h
-r--r--r-- 1 dgerard dgerard 0 janv. 16 14:44 asn1_mac.h
-r--r--r-- 1 dgerard dgerard 0 janv. 16 14:44 asn1t.h
-r--r--r-- 1 dgerard dgerard 0 janv. 16 14:44 bio.h
-r--r--r-- 1 dgerard dgerard 0 janv. 16 14:44 blowfish.h
-r--r--r-- 1 dgerard dgerard 0 janv. 16 14:44 bn.h
-r--r--r-- 1 dgerard dgerard 0 janv. 16 14:44 buffer.h
[…]



However, when trying to sync to the appropriate changeset :

{14:44}~/p4/testmess ➭ p4 sync -f @59702
//depot/openssl/0.9.8j/openssl/include/openssl/aes.h#2 - updating 
/home/dgerard/p4/testmess/aes.h
rename: /home/dgerard/p4/testmess/aes.h: No such file or directory
//depot/openssl/0.9.8j/openssl/include/openssl/asn1.h#2 - updating 
/home/dgerard/p4/testmess/asn1.h
rename: /home/dgerard/p4/testmess/asn1.h: No such file or directory
//depot/openssl/0.9.8j/openssl/include/openssl/asn1_mac.h#2 - updating 
/home/dgerard/p4/testmess/asn1_mac.h
rename: /home/dgerard/p4/testmess/asn1_mac.h: No such file or directory
//depot/openssl/0.9.8j/openssl/include/openssl/asn1t.h#2 - updating 
/home/dgerard/p4/testmess/asn1t.h
rename: /home/dgerard/p4/testmess/asn1t.h: No such file or directory
//depot/openssl/0.9.8j/openssl/include/openssl/bio.h#2 - updating 
/home/dgerard/p4/testmess/bio.h
rename: /home/dgerard/p4/testmess/bio.h: No such file or directory
//depot/openssl/0.9.8j/openssl/include/openssl/blowfish.h#2 - updating 
/home/dgerard/p4/testmess/blowfish.h
rename: /home/dgerard/p4/testmess/blowfish.h: No such file or directory

Re: git-p4: exception when cloning a perforce repository

[Damien Gérard]

On 16 Jan 2014, at 15:45, Pete Wyckoff p...@padd.com wrote:

 Oh cool, that helps a lot.  P4 is just broken here, so we can get
 away with being a bit sloppy in git.  I'll try just pretending
 empty symlinks are not in the repo.  Hopefully you'll have a
 future commit in your p4 repo that brings back bn.h properly.

Thanks !
I would love to use git instead of perforce if possible :)

 Still not sure about how I'll test this.

I can test for you, no probleme with that.


 
 Thanks,
 
   -- Pete
 

--
To unsubscribe from this list: send the line 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-p4: exception when cloning a perforce repository

[Damien Gérard]

On 15 Jan 2014, at 00:24, Pete Wyckoff p...@padd.com wrote:

 p...@padd.com wrote on Mon, 13 Jan 2014 19:18 -0500:
 dam...@iwi.me wrote on Mon, 13 Jan 2014 14:37 +0100:
 I am trying to clone a perforce repository via git and I am having the 
 following backtrace :
 
 {14:20}~/projects/:master ✗ ➭ git p4 clone //depot/@all .
 Importing revision …
 [...]
 Importing revision 59702 (45%)Traceback (most recent call last):
 [..]
  File /opt/git/libexec/git-core/git-p4, line 2078, in streamOneP4File
if data[-1] == '\n':
 IndexError: string index out of range
 
 git —version: git version 1.8.5.2.309.ga25014b [last commit from master 
 from github.com/git/git]
 os : ubuntu 13.10
 
 This code:
 
if type_base == symlink:
git_mode = 12
# p4 print on a symlink sometimes contains target\n;
# if it does, remove the newline
data = ''.join(contents)
  ==   if data[-1] == '\n':
contents = [data[:-1]]
else:
contents = [data]
 
 means that data is an empty string.  Implies you've got a
 symlink pointing to nothing.  Is that even possible?

It does not seem so but I am so sure.


 It could be this is a regression introduced at 1292df1 (git-p4:
 Fix occasional truncation of symlink contents., 2013-08-08).  The
 old way of doing data[:-1] unconditionally would have worked but
 was broken for other reasons.
 
 Could you investigate the symlink a bit?  We're looking for
 one in change 59702 that points to nowhere.  Maybe do:
 
$ p4 describe -s 59702
 
 and see if you can figure out which of those could be a symlink, then
 inspect it:
 
$ p4 fstat //depot/symlink@59702
(probably shows it is headRev 1)
 
$ p4 print -q //depot/symlink#1
 
$ p4 print -q //depot/symlink#1 | od -c
 
 Thanks for checking this depot info first.
 
 I've tried to hack a test that produces a null symlink,
 and having done so, find an error later on trying to
 generate a symlink that points to .  So the easy
 fix of checking for an empty string is unlikely to work
 for your repo.
 
 Curious as to how you managed to generate such a thing.
 If you find the file, and can get at the p4 depot, the
 full ,v file would be interesting too.
 



Indeed, those files are symlinks actually.  But it sems they are all valid.


Here is what I can get :

Change 59702 by ##@VS9 on 2009/03/24 15:53:39

OpenSSL 0.9.8j

Affected files ...

... //depot/openssl/0.9.8j/openssl/include/openssl/aes.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/asn1.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/asn1_mac.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/asn1t.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/bio.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/blowfish.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/bn.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/buffer.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/cast.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/comp.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/conf.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/conf_api.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/crypto.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/des.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/des_old.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/dh.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/dsa.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/dso.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/dtls1.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/e_os2.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/ebcdic.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/ec.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/ecdh.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/ecdsa.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/engine.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/err.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/evp.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/fips.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/fips_rand.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/hmac.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/idea.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/krb5_asn.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/kssl.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/lhash.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/md2.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/md4.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/md5.h#2 edit
... //depot/openssl/0.9.8j/openssl/include/openssl/obj_mac.h#2 edit
... 

git-p4: exception when cloning a perforce repository

[Damien Gérard]

Hi !

I am trying to clone a perforce repository via git and I am having the 
following backtrace :

{14:20}~/projects/:master ✗ ➭ git p4 clone //depot/@all .
Importing revision …
[...]
Importing revision 59702 (45%)Traceback (most recent call last):
  File /opt/git/libexec/git-core/git-p4, line 3287, in module
main()
  File /opt/git/libexec/git-core/git-p4, line 3281, in main
if not cmd.run(args):
  File /opt/git/libexec/git-core/git-p4, line 3155, in run
if not P4Sync.run(self, depotPaths):
  File /opt/git/libexec/git-core/git-p4, line 3008, in run
self.importChanges(changes)
  File /opt/git/libexec/git-core/git-p4, line 2680, in importChanges
self.initialParent)
  File /opt/git/libexec/git-core/git-p4, line 2304, in commit
self.streamP4Files(new_files)
  File /opt/git/libexec/git-core/git-p4, line 2218, in streamP4Files
cb=streamP4FilesCbSelf)
  File /opt/git/libexec/git-core/git-p4, line 482, in p4CmdList
cb(entry)
  File /opt/git/libexec/git-core/git-p4, line 2212, in streamP4FilesCbSelf
self.streamP4FilesCb(entry)
  File /opt/git/libexec/git-core/git-p4, line 2167, in streamP4FilesCb
self.streamOneP4File(self.stream_file, self.stream_contents)
  File /opt/git/libexec/git-core/git-p4, line 2078, in streamOneP4File
if data[-1] == '\n':
IndexError: string index out of range


git —version: git version 1.8.5.2.309.ga25014b [last commit from master from 
github.com/git/git]
os : ubuntu 13.10


Any ideas ? :)

Best regards,
Damien--
To unsubscribe from this list: send the line 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: Add a bugzilla website

[Damien Wyart]

* ycollette.nos...@free.fr ycollette.nos...@free.fr [2013-11-15 08:44]:
 I just wanted to ask a question: why is there no bugzilla website for
 git ? It's better to put bugs into such a tool to follow there
 evolution than to manage bugs via a developpment mailing list ...

http://thread.gmane.org/gmane.comp.version-control.git/191835/focus=192464

-- 
Damien Wyart
--
To unsubscribe from this list: send the line 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-archive and submodules

[Damien Regad]

Robert Quattlebaum darco at deepdarc.com writes:
 I got too busy to continue working to get it included. Please feel free to
pick up where I left off. 
 
 On Apr 20, 2012, at 2:32 PM, André Caron andre.l.caron at gmail.com wrote:
  Since you've touched this only last year, I'd like to know where you
  were at and I can see if I can pick up where you left off (unless you
  want to finish yourself).

Greetings

I was just wondering whether there been any progress on this topic since
last year... André ?

Cheers
Damien



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

Bug? ignored files overwritten by checkout

[Damien Robert]

git init
git commit --allow-empty -m init
git checkout -b test
echo foo  foo
git add foo
git commit -am 'add foo'
git checkout master
echo 'Important data'  foo #[1]
echo foo  .gitignore
git checkout test

If I tried a `git checkout test` after [1], I would get the error message 
error: The following untracked working tree files would be overwritten by 
checkout: foo
But after adding foo to .gitignore, I am able to checkout to branch test
without warning. Of course this overwrites foo to the version in test.

I tested this in version 1.8.3.4 and 1.7.10.4.

--
To unsubscribe from this list: send the line 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: Remove old forgotten command: whatchanged

[Damien Robert]

Matthieu Moy  wrote in message vpqfvukdy39@anie.imag.fr:
 that confuses users.
 
 ... but I do agree that the doc is really confusing. It would be much
 better if the doc could be reduced to:
 
 This is a synonym for linkgit:git-log[1] --raw --some --other ---options.
 Please refer to the documentation of that command.

If I may chime in as a user: what really confused me about git whatchanged
is this part of man gitcore-tutorial:

   To see the whole history of our pitiful little git-tutorial project,
   you can do

   $ git log


   which shows just the log messages, or if we want to see the log
   together with the associated patches use the more complex (and much
   more powerful)

   $ git whatchanged -p


   and you will see exactly what has changed in the repository over its
   short history.

I had to go look at the source code to realize that nowadays git log and
git whatchanged are basically the same functions with different defaults. A
pointer to that in the man page of git whatchanged would definitively be
helpful.

--
To unsubscribe from this list: send the line 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: Remove old forgotten command: whatchanged

[Damien Robert]

Junio C Hamano  wrote in message
7v61vg9eht@alter.siamese.dyndns.org:
 The tutorial was written in fairly early days of Git's history, in
 order to primarily help those who want to use the plumbing command
 to script their own Porcelain commands.  As it says at the very
 beginning, the end-user tutorial to use Git's Porcelain is
 gittutorial.txt and the user manual, not this document.

Yes, and even if it's old, it is a really well done tutorial to understand the
internals of git. I read it after gittutorial and gittutorial-2. It's just
that I was surprised to learn about this command, much more powerful than
git-log. To me it looked a lot like git log --raw, and I found git log -p
more useful, so I was wondering what I was missing until I read the source
to see that nowadays the two commands were mostly the same.

 The above section primarily explains the use of diff-tree and it was
 appropriate back when git-whatchanged was a script.  The intent of
 the whole document, not just this section, was to tickle the
 curiousity of the users and encourage them to see how the above
 much more powerful whatchanged was implemented by going to the
 source.

Well in this case you can say that the intent was successful since it made
me read the source code ;)

--
To unsubscribe from this list: send the line 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: [Query] Can we ignore case for commiters name in shortlog?

[Damien Robert]

David Aguilar  wrote in message
cajddkr7yr2jsutcey1mz-sfmq8zdnzr3+s++ooenn5+wd-l...@mail.gmail.com:
 There's a feature that does exactly this.
 http://www.kernel.org/pub/software/scm/git/docs/git-shortlog.html

By the way, the mailmap ignore case which is annoying.
I have commits as damien.olivier.robert+...@gmail.com and a dummy email
address robert@numenor.night-elves. I thought that putting:

Damien Robert damien.olivier.robert+...@gmail.com robert@numenor.night-elves

in the .mailmap would unify the two adresses, but it does not:

git shortlog -se
15  Damien Robert damien.olivier.robert+...@gmail.com
266  Damien Robert damien.olivier.robert+...@gmail.com

as you can see, the Damien.Olivier.Robert+git as been lowercased to
damien.olivier.robert, so I am forced to write a mailmap like this:

Damien Robert damien.olivier.robert+...@gmail.com robert@numenor.night-elves
Damien Robert damien.olivier.robert+...@gmail.com 
damien.olivier.robert+...@gmail.com

git shortlog -se
   281  Damien Robert damien.olivier.robert+...@gmail.com

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

git rebase -p and patch equivalent commits

[Damien Robert]

Hi all,
I was wondering if you had any tips on the following workflow:
I work on an experimental feature branch of a project. I have some patches
that I implement in branch patch1 and patch2 on top of the feature branch.
I test if they both work together by merging patch1 and patch2 into a build
branch:
mkdir build  cd build
git init
echo a  a  git add a  git commit -am a
git branch feature
git co -b patch1
echo b  b  git add b  git commit -am b
git co -b patch2 feature
echo c  c  git add c  git commit -am c
git co -b build feature
git merge --no-edit patch1 patch2
Now feature is rebased against master. How would you rebase the branches
patch1, patch2 and build so that they keep the same layout?

I tried to rebase patch1 and patch2, hoping that rebase -p build would use
the rebased commits for the merge but it creates new commits (that are
patch equivalents to patch1 and patch2) and merge them.

So I can think of two ways to proceed:
1) only rebase patch1 and patch2, and then remerge them again in build.
   This start to get complicated if I have some commits in build after the
   merge, I will then need to rebase them on top of the new merge. And for
   a more complicated layout it will get pretty hard to recreate it
   automatically.
2) I can rebase -p the build branch first, and then reset --soft patch1 and
   patch2 so that they point to the right commits in the rebased branch.
   This way looks easier to do with more complicated layout, I just need to
   find a good way of finding where the rebased commits for patch1 and
   patch2 are, and I was thinking of using notes for that.

So my question is: does it look like a sensible approach? Is there an
easier way I am missing?

Thanks!

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