git-gui resets author on amend

[Orgad Shaneh]

Hi,

Amending a commit using git gui resets its author, unlike plain git
commit --amend.

- Orgad
--
To unsubscribe from this list: send the line 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] submodule: add verbose mode for add/update

[Orgad Shaneh]

Executes checkout without -q
---
 git-submodule.sh | 24 +++-
 1 file changed, 19 insertions(+), 5 deletions(-)

diff --git a/git-submodule.sh b/git-submodule.sh
index a33f68d..5c4e057 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,11 +5,11 @@
 # Copyright (c) 2007 Lars Hjemli

 dashless=$(basename $0 | sed -e 's/-/ /')
-USAGE=[--quiet] add [-b branch] [-f|--force] [--name name]
[--reference repository] [--] repository [path]
+USAGE=[--quiet] add [-b branch] [-f|--force] [--name name]
[--reference repository] [-v|--verbose] [--] repository [path]
or: $dashless [--quiet] status [--cached] [--recursive] [--] [path...]
or: $dashless [--quiet] init [--] [path...]
or: $dashless [--quiet] deinit [-f|--force] [--] path...
-   or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch]
[-f|--force] [--rebase] [--reference repository] [--merge]
[--recursive] [--] [path...]
+   or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch]
[-f|--force] [--rebase] [--reference repository] [--merge]
[--recursive] [-v|--verbose] [--] [path...]
or: $dashless [--quiet] summary [--cached|--files]
[--summary-limit n] [commit] [--] [path...]
or: $dashless [--quiet] foreach [--recursive] command
or: $dashless [--quiet] sync [--recursive] [--] [path...]
@@ -319,12 +319,16 @@ module_clone()
  rel=$(echo $a | sed -e 's|[^/][^/]*|..|g')
  (
  clear_local_git_env
+ if test -z $verbose
+ then
+ subquiet=-q
+ fi
  cd $sm_path 
  GIT_WORK_TREE=. git config core.worktree $rel/$b 
  # ash fails to wordsplit ${local_branch:+-B $local_branch...}
  case $local_branch in
- '') git checkout -f -q ${start_point:+$start_point} ;;
- ?*) git checkout -f -q -B $local_branch ${start_point:+$start_point} ;;
+ '') git checkout -f $subquiet ${start_point:+$start_point} ;;
+ ?*) git checkout -f $subquiet -B $local_branch
${start_point:+$start_point} ;;
  esac
  ) || die $(eval_gettext Unable to setup cloned submodule '\$sm_path')
 }
@@ -380,6 +384,9 @@ cmd_add()
  --depth=*)
  depth=$1
  ;;
+ -v|--verbose)
+ verbose=1
+ ;;
  --)
  shift
  break
@@ -786,6 +793,9 @@ cmd_update()
  --depth=*)
  depth=$1
  ;;
+ -v|--verbose)
+ verbose=1
+ ;;
  --)
  shift
  break
@@ -913,7 +923,11 @@ Maybe you want to use 'update --init'?)
  must_die_on_failure=
  case $update_module in
  checkout)
- command=git checkout $subforce -q
+ if test -z $verbose
+ then
+ subquiet=-q
+ fi
+ command=git checkout $subforce $subquiet
  die_msg=$(eval_gettext Unable to checkout '\$sha1' in submodule
path '\$displaypath')
  say_msg=$(eval_gettext Submodule path '\$displaypath': checked out
'\$sha1')
  ;;
-- 
1.9.0.msysgit.0
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] submodule: add verbose mode for add/update

[Orgad Shaneh]

From: Orgad Shaneh org...@gmail.com

Executes checkout without -q

Signed-off-by: Orgad Shaneh org...@gmail.com
---
 Documentation/git-submodule.txt |  7 +--
 git-submodule.sh| 24 +++-
 t/t7406-submodule-update.sh |  9 +
 3 files changed, 33 insertions(+), 7 deletions(-)

diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 21cb59a..1867e94 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -10,13 +10,13 @@ SYNOPSIS
 
 [verse]
 'git submodule' [--quiet] add [-b branch] [-f|--force] [--name name]
- [--reference repository] [--depth depth] [--] repository 
[path]
+ [--reference repository] [--depth depth] [-v|--verbose] [--] 
repository [path]
 'git submodule' [--quiet] status [--cached] [--recursive] [--] [path...]
 'git submodule' [--quiet] init [--] [path...]
 'git submodule' [--quiet] deinit [-f|--force] [--] path...
 'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch]
  [-f|--force] [--rebase|--merge|--checkout] [--reference 
repository]
- [--depth depth] [--recursive] [--] [path...]
+ [--depth depth] [--recursive] [-v|--verbose] [--] [path...]
 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) n]
  [commit] [--] [path...]
 'git submodule' [--quiet] foreach [--recursive] command
@@ -363,6 +363,9 @@ for linkgit:git-clone[1]'s `--reference` and `--shared` 
options carefully.
clone with a history truncated to the specified number of revisions.
See linkgit:git-clone[1]
 
+--verbose::
+  This option is valid for add and update commands. Show output of
+  checkout.
 
 path...::
Paths to submodule(s). When specified this will restrict the command
diff --git a/git-submodule.sh b/git-submodule.sh
index a33f68d..5c4e057 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,11 +5,11 @@
 # Copyright (c) 2007 Lars Hjemli
 
 dashless=$(basename $0 | sed -e 's/-/ /')
-USAGE=[--quiet] add [-b branch] [-f|--force] [--name name] [--reference 
repository] [--] repository [path]
+USAGE=[--quiet] add [-b branch] [-f|--force] [--name name] [--reference 
repository] [-v|--verbose] [--] repository [path]
or: $dashless [--quiet] status [--cached] [--recursive] [--] [path...]
or: $dashless [--quiet] init [--] [path...]
or: $dashless [--quiet] deinit [-f|--force] [--] path...
-   or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] 
[-f|--force] [--rebase] [--reference repository] [--merge] [--recursive] [--] 
[path...]
+   or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] 
[-f|--force] [--rebase] [--reference repository] [--merge] [--recursive] 
[-v|--verbose] [--] [path...]
or: $dashless [--quiet] summary [--cached|--files] [--summary-limit n] 
[commit] [--] [path...]
or: $dashless [--quiet] foreach [--recursive] command
or: $dashless [--quiet] sync [--recursive] [--] [path...]
@@ -319,12 +319,16 @@ module_clone()
rel=$(echo $a | sed -e 's|[^/][^/]*|..|g')
(
clear_local_git_env
+   if test -z $verbose
+   then
+   subquiet=-q
+   fi
cd $sm_path 
GIT_WORK_TREE=. git config core.worktree $rel/$b 
# ash fails to wordsplit ${local_branch:+-B $local_branch...}
case $local_branch in
-   '') git checkout -f -q ${start_point:+$start_point} ;;
-   ?*) git checkout -f -q -B $local_branch 
${start_point:+$start_point} ;;
+   '') git checkout -f $subquiet ${start_point:+$start_point} ;;
+   ?*) git checkout -f $subquiet -B $local_branch 
${start_point:+$start_point} ;;
esac
) || die $(eval_gettext Unable to setup cloned submodule 
'\$sm_path')
 }
@@ -380,6 +384,9 @@ cmd_add()
--depth=*)
depth=$1
;;
+   -v|--verbose)
+   verbose=1
+   ;;
--)
shift
break
@@ -786,6 +793,9 @@ cmd_update()
--depth=*)
depth=$1
;;
+   -v|--verbose)
+   verbose=1
+   ;;
--)
shift
break
@@ -913,7 +923,11 @@ Maybe you want to use 'update --init'?)
must_die_on_failure=
case $update_module in
checkout)
-   command=git checkout $subforce -q
+   if test -z $verbose
+   then
+   subquiet=-q
+   fi
+   command=git checkout $subforce

Re: [PATCH] submodule: add verbose mode for add/update

[Orgad Shaneh]

On Wed, Mar 12, 2014 at 6:15 PM, Jens Lehmann jens.lehm...@web.de wrote:

 Am 12.03.2014 14:42, schrieb Orgad Shaneh:
  From: Orgad Shaneh org...@gmail.com

 You don't need the line above when you are the sender ;-)

  Executes checkout without -q

 That's a bit terse. What about:

 Add the verbose flag to add and update which displays the
  progress of the actual submodule checkout when given. This
  is useful for checkouts that take a long time, as the user
  can then see the progress.

  Signed-off-by: Orgad Shaneh org...@gmail.com
  ---
   Documentation/git-submodule.txt |  7 +--
   git-submodule.sh| 24 +++-
   t/t7406-submodule-update.sh |  9 +
   3 files changed, 33 insertions(+), 7 deletions(-)
 
  diff --git a/Documentation/git-submodule.txt 
  b/Documentation/git-submodule.txt
  index 21cb59a..1867e94 100644
  --- a/Documentation/git-submodule.txt
  +++ b/Documentation/git-submodule.txt
  @@ -10,13 +10,13 @@ SYNOPSIS
   
   [verse]
   'git submodule' [--quiet] add [-b branch] [-f|--force] [--name name]
  -   [--reference repository] [--depth depth] [--] repository 
  [path]
  +   [--reference repository] [--depth depth] [-v|--verbose] 
  [--] repository [path]
   'git submodule' [--quiet] status [--cached] [--recursive] [--] [path...]
   'git submodule' [--quiet] init [--] [path...]
   'git submodule' [--quiet] deinit [-f|--force] [--] path...
   'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch]
  [-f|--force] [--rebase|--merge|--checkout] [--reference 
  repository]
  -   [--depth depth] [--recursive] [--] [path...]
  +   [--depth depth] [--recursive] [-v|--verbose] [--] [path...]
   'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) 
  n]
  [commit] [--] [path...]
   'git submodule' [--quiet] foreach [--recursive] command
  @@ -363,6 +363,9 @@ for linkgit:git-clone[1]'s `--reference` and `--shared` 
  options carefully.
clone with a history truncated to the specified number of revisions.
See linkgit:git-clone[1]
 
  +--verbose::
  +  This option is valid for add and update commands. Show output of
  +  checkout.

 The above looks whitespace-damaged, you should use TABs here to
 indent (just like the other options do).

   path...::
Paths to submodule(s). When specified this will restrict the command
  diff --git a/git-submodule.sh b/git-submodule.sh
  index a33f68d..5c4e057 100755
  --- a/git-submodule.sh
  +++ b/git-submodule.sh
  @@ -5,11 +5,11 @@
   # Copyright (c) 2007 Lars Hjemli
 
   dashless=$(basename $0 | sed -e 's/-/ /')
  -USAGE=[--quiet] add [-b branch] [-f|--force] [--name name] 
  [--reference repository] [--] repository [path]
  +USAGE=[--quiet] add [-b branch] [-f|--force] [--name name] 
  [--reference repository] [-v|--verbose] [--] repository [path]
  or: $dashless [--quiet] status [--cached] [--recursive] [--] [path...]
  or: $dashless [--quiet] init [--] [path...]
  or: $dashless [--quiet] deinit [-f|--force] [--] path...
  -   or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] 
  [-f|--force] [--rebase] [--reference repository] [--merge] [--recursive] 
  [--] [path...]
  +   or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] 
  [-f|--force] [--rebase] [--reference repository] [--merge] [--recursive] 
  [-v|--verbose] [--] [path...]
  or: $dashless [--quiet] summary [--cached|--files] [--summary-limit 
  n] [commit] [--] [path...]
  or: $dashless [--quiet] foreach [--recursive] command
  or: $dashless [--quiet] sync [--recursive] [--] [path...]
  @@ -319,12 +319,16 @@ module_clone()
rel=$(echo $a | sed -e 's|[^/][^/]*|..|g')
(
clear_local_git_env
  + if test -z $verbose
  + then
  + subquiet=-q
  + fi
cd $sm_path 
GIT_WORK_TREE=. git config core.worktree $rel/$b 
# ash fails to wordsplit ${local_branch:+-B 
  $local_branch...}
case $local_branch in
  - '') git checkout -f -q ${start_point:+$start_point} ;;
  - ?*) git checkout -f -q -B $local_branch 
  ${start_point:+$start_point} ;;
  + '') git checkout -f $subquiet ${start_point:+$start_point} 
  ;;
  + ?*) git checkout -f $subquiet -B $local_branch 
  ${start_point:+$start_point} ;;

 Wouldn't it be better to use the ${subquiet:+$subquiet} notation
 here like the other optional arguments do? After all the subquiet
 isn't always set.

esac
) || die $(eval_gettext Unable to setup cloned submodule 
  '\$sm_path')
   }
  @@ -380,6 +384,9 @@ cmd_add()
--depth=*)
depth=$1
;;
  + -v|--verbose)
  + verbose=1

[PATCH] git-submodule: respect -q for add/update

[Orgad Shaneh]

Signed-off-by: Orgad Shaneh org...@gmail.com
---
 git-submodule.sh |   17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/git-submodule.sh b/git-submodule.sh
index aac575e..dd57abb 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -266,6 +266,11 @@ cmd_add()
 
repo=$1
sm_path=$2
+   quiet=
+   if test -n $GIT_QUIET
+   then
+   quiet=-q
+   fi
 
if test -z $sm_path; then
sm_path=$(echo $repo |
@@ -332,8 +337,8 @@ Use -f if you really want to add it. 2
cd $sm_path 
# ash fails to wordsplit ${branch:+-b $branch...}
case $branch in
-   '') git checkout -f -q ;;
-   ?*) git checkout -f -q -B $branch origin/$branch ;;
+   '') git checkout -f $quiet ;;
+   ?*) git checkout -f $quiet -B $branch 
origin/$branch ;;
esac
) || die $(eval_gettext Unable to checkout submodule 
'\$sm_path')
fi
@@ -527,6 +532,12 @@ cmd_update()
shift
done
 
+   quiet=
+   if test -n $GIT_QUIET
+   then
+   quiet=-q
+   fi
+
if test -n $init
then
cmd_init -- $@ || return
@@ -619,7 +630,7 @@ Maybe you want to use 'update --init'?)
must_die_on_failure=yes
;;
*)
-   command=git checkout $subforce -q
+   command=git checkout $subforce $quiet
die_msg=$(eval_gettext Unable to checkout 
'\$sha1' in submodule path '\$sm_path')
say_msg=$(eval_gettext Submodule path 
'\$sm_path': checked out '\$sha1')
;;
-- 
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

[PATCH] Fix path normalization for SMB shares

[Orgad Shaneh]

SMB shared are accessed using //server/share/directory...
notation.

normalize_path_copy used to leave only a single slash, which
invalidated the path.

Fix suggested by Nguyen Thai Ngoc Duy

Signed-off-by: Orgad Shaneh org...@gmail.com
---
 path.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/path.c b/path.c
index 66acd24..6cd9c0b 100644
--- a/path.c
+++ b/path.c
@@ -503,6 +503,12 @@ int normalize_path_copy(char *dst, const char *src)
*dst++ = *src++;
*dst++ = *src++;
}
+#ifdef WIN32
+   else if (is_dir_sep(src[0])  is_dir_sep(src[1])) {
+   *dst++ = '/';
+   src++;
+   }
+#endif
dst0 = dst;
 
if (is_dir_sep(*src)) {
-- 
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

[PATCH] commit: configure submodules

[Orgad Shaneh]

As reported on the mailing list[1], ignore submodule config is not
respected on commit.

[1] 
http://git.661346.n2.nabble.com/submodule-ignore-is-not-respected-on-commit-td7539238.html

Signed-off-by: Orgad Shaneh org...@gmail.com
---
 builtin/commit.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/builtin/commit.c b/builtin/commit.c
index 62028e7..7a83cae 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1452,6 +1452,7 @@ int cmd_commit(int argc, const char **argv, const char 
*prefix)
usage_with_options(builtin_commit_usage, 
builtin_commit_options);
 
wt_status_prepare(s);
+   gitmodules_config();
git_config(git_commit_config, s);
determine_whence(s);
s.colopts = 0;
-- 
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: [PATCH] commit: configure submodules

[Orgad Shaneh]

On Mon, Sep 24, 2012 at 8:34 PM, Junio C Hamano gits...@pobox.com wrote:

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

  Am 24.09.2012 18:27, schrieb Junio C Hamano:
  Junio C Hamano gits...@pobox.com writes:
  In any case, the log message I suggested in the review needs to be
  updated in the reroll to make it clear that this is about reading
  from .gitmodules, not configuration.  AFAICS, gitmodule_config()
  does not even read from $GIT_DIR/config, right?
 
  OK.  gitmodule_config() does not read $GIT_DIR/config, but
  cmd_status() and cmd_commit() call git_diff_basic_config() that is
  called from git_diff_ui_config() to read submodule.$name.ignore from
  it.  So Orgad's patch is _only_ about submodule.$name.ignore that is
  in in-tree .gitmodule; the log message shouldn't mention config,
  as setting configuration variables work for both status and commit
  just fine.
 
  Yes, I was just checking that call path too to make sure the user
  settings from $GIT_DIR/config really override those found in
  .gitmodules. And of course you are right, while the change to the
  code is sane the commit message still needs some work.

 Here is what I tentatively queued on 'pu' (not pushed out yet).

 -- 8 --
 From: Orgad Shaneh org...@gmail.com
 Date: Sun, 23 Sep 2012 09:37:47 +0200
 Subject: [PATCH] commit: pay attention to submodule.$name.ignore in
  .gitmodules

 git status does not list a submodule with uncommitted working tree
 files as modified when submodule.$name.ignore is set to dirty in
 in-tree .gitmodules file.  Both status and commit honor the setting
 in $GIT_DIR/config, but commit does not pick it up from .gitmodules,
 which is inconsistent.

 Teach git commit to pay attention to the setting in .gitmodules as
 well.

 Signed-off-by: Orgad Shaneh org...@gmail.com
 Signed-off-by: Junio C Hamano gits...@pobox.com
 ---
  builtin/commit.c | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/builtin/commit.c b/builtin/commit.c
 index 66fdd22..3cb1ef7 100644
 --- a/builtin/commit.c
 +++ b/builtin/commit.c
 @@ -1256,6 +1256,7 @@ int cmd_commit(int argc, const char **argv, const char 
 *prefix)
 struct wt_status s;

 wt_status_prepare(s);
 +   gitmodules_config();
 git_config(git_commit_config, s);
 in_merge = file_exists(git_path(MERGE_HEAD));
 s.in_merge = in_merge;
 --
 1.7.12.1.441.g794a63b


That is not correct. git-config is ignored as well for commit. Maybe
another fix is needed?

- Orgad
--
To unsubscribe from this list: send the line 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] commit: configure submodules

[Orgad Shaneh]

On Mon, Sep 24, 2012 at 9:06 PM, Junio C Hamano gits...@pobox.com wrote:
 Orgad Shaneh org...@gmail.com writes:

 That is not correct. git-config is ignored as well for commit.

 What do you mean?  As far as I can tell, if you have

 [submodule var]
 path = var
 ignore = dirty

 in $GIT_DIR/config, a work-tree-dirty submodule var is not
 reported by git status and git commit without your patch, and
 your patch does not seem to break that.  The only difference your
 patch makes is that if you had the above three-line block in
 the .gitmodules file and not in $GIT_DIR/config, git status
 ignored the dirtyness in the working tree, but git commit did
 notice and report it.

 What am I missing?



I have:
[submodule mod]
url = [...]
ignore = dirty

in .git/config, and I removed the ignore part from .gitmodules to be even.

I made a change inside mod, git status doesn't report its dirtiness,
while git commit does.

git status:
# On branch master
# Changes to be committed:
#   (use git reset HEAD file... to unstage)
#
#   modified:   foo
#
# Changes not staged for commit:
#   (use git add file... to update what will be committed)
#   (use git checkout -- file... to discard changes in working directory)
#
#   modified:   .gitmodules
#

git commit:
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
#   (use git reset HEAD file... to unstage)
#
#   modified:   foo
#
# Changes not staged for commit:
#   (use git add file... to update what will be committed)
#   (use git checkout -- file... to discard changes in working directory)
#   (commit or discard the untracked or modified content in submodules)
#
#   modified:   .gitmodules
#   modified:   mod (modified content)
#

Now I get it! That's because I don't have submodule.mod.path!
config_name_for_path only gets initialized if path exists. Apparently
git submodule init doesn't configure 'path', so it stays
uninitialized.

- Orgad
--
To unsubscribe from this list: send the line 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] submodule: configure submodule.name.path on add and init

[Orgad Shaneh]

In order to read diff options for a submodule, its path must be configured
---
 git-submodule.sh |2 ++
 1 file changed, 2 insertions(+)

diff --git a/git-submodule.sh b/git-submodule.sh
index 3e2045e..f97bb62 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -359,6 +359,7 @@ Use -f if you really want to add it. 2
esac
) || die $(eval_gettext Unable to checkout submodule 
'\$sm_path')
fi
+   git config submodule.$sm_path.path $sm_path
git config submodule.$sm_path.url $realrepo
 
git add $force $sm_path ||
@@ -476,6 +477,7 @@ cmd_init()
url=$(resolve_relative_url $url) || exit
;;
esac
+   git config submodule.$name.path $name ||
git config submodule.$name.url $url ||
die $(eval_gettext Failed to register url for 
submodule path '\$sm_path')
 
-- 
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: [PATCH] submodule: configure submodule.name.path on add and init

[Orgad Shaneh]

On Mon, Sep 24, 2012 at 9:30 PM, Orgad Shaneh org...@gmail.com wrote:
 In order to read diff options for a submodule, its path must be configured
 ---
  git-submodule.sh |2 ++
  1 file changed, 2 insertions(+)

 diff --git a/git-submodule.sh b/git-submodule.sh
 index 3e2045e..f97bb62 100755
 --- a/git-submodule.sh
 +++ b/git-submodule.sh
 @@ -359,6 +359,7 @@ Use -f if you really want to add it. 2
 esac
 ) || die $(eval_gettext Unable to checkout submodule 
 '\$sm_path')
 fi
 +   git config submodule.$sm_path.path $sm_path
 git config submodule.$sm_path.url $realrepo

 git add $force $sm_path ||
 @@ -476,6 +477,7 @@ cmd_init()
 url=$(resolve_relative_url $url) || exit
 ;;
 esac
 +   git config submodule.$name.path $name ||
 git config submodule.$name.url $url ||
 die $(eval_gettext Failed to register url for 
 submodule path '\$sm_path')

 --
 1.7.10.4


Oops, || should have been 

- Orgad
--
To unsubscribe from this list: send the line 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] commit: configure submodules

[Orgad Shaneh]

On Mon, Sep 24, 2012 at 9:56 PM, Jens Lehmann jens.lehm...@web.de wrote:
 Am 24.09.2012 21:16, schrieb Orgad Shaneh:
 On Mon, Sep 24, 2012 at 9:06 PM, Junio C Hamano gits...@pobox.com wrote:
 Orgad Shaneh org...@gmail.com writes:

 That is not correct. git-config is ignored as well for commit.

 What do you mean?  As far as I can tell, if you have

 [submodule var]
 path = var
 ignore = dirty

 in $GIT_DIR/config, a work-tree-dirty submodule var is not
 reported by git status and git commit without your patch, and
 your patch does not seem to break that.  The only difference your
 patch makes is that if you had the above three-line block in
 the .gitmodules file and not in $GIT_DIR/config, git status
 ignored the dirtyness in the working tree, but git commit did
 notice and report it.

 What am I missing?



 I have:
 [submodule mod]
 url = [...]
 ignore = dirty

 in .git/config, and I removed the ignore part from .gitmodules to be even.

 I made a change inside mod, git status doesn't report its dirtiness,
 while git commit does.

 git status:
 # On branch master
 # Changes to be committed:
 #   (use git reset HEAD file... to unstage)
 #
 #   modified:   foo
 #
 # Changes not staged for commit:
 #   (use git add file... to update what will be committed)
 #   (use git checkout -- file... to discard changes in working directory)
 #
 #   modified:   .gitmodules
 #

 git commit:
 # Please enter the commit message for your changes. Lines starting
 # with '#' will be ignored, and an empty message aborts the commit.
 # On branch master
 # Changes to be committed:
 #   (use git reset HEAD file... to unstage)
 #
 #   modified:   foo
 #
 # Changes not staged for commit:
 #   (use git add file... to update what will be committed)
 #   (use git checkout -- file... to discard changes in working directory)
 #   (commit or discard the untracked or modified content in submodules)
 #
 #   modified:   .gitmodules
 #   modified:   mod (modified content)
 #

 Now I get it! That's because I don't have submodule.mod.path!
 config_name_for_path only gets initialized if path exists. Apparently
 git submodule init doesn't configure 'path', so it stays
 uninitialized.

 But submodule.mod.path should only be set in .gitmodules, not in
 $GIT_DIR/config. Did you just remove the ignore setting from
 .gitmodules or the path too?

Just the ignore, and my patch of course.

If it is not set in $GIT_DIR/config, then config_name_for_path is not
initialized, and if it is not initialized, then
set_diffopt_flags_from_submodule_config does nothing
(handle_ignore_submodules_arg is not called). That is the main
problem.

- Orgad
--
To unsubscribe from this list: send the line 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 gui replaces amend message when prepare-commit-msg hook is used

[Orgad Shaneh]

Hi,

If a prepare-commit-msg hook is used, git gui executes it for New Commit.

If the New Commit is selected, and then immediately Amend (before
the hook returns), when the hook returns the message is replaced with
the one produced by the hook.

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

Re: git gui replaces amend message when prepare-commit-msg hook is used

[Orgad Shaneh]

On Thu, Jul 4, 2013 at 1:01 PM, Fredrik Gustafsson iv...@iveqy.com wrote:
 On Thu, Jul 04, 2013 at 12:47:28PM +0300, Orgad Shaneh wrote:
 If a prepare-commit-msg hook is used, git gui executes it for New Commit.

 If the New Commit is selected, and then immediately Amend (before
 the hook returns), when the hook returns the message is replaced with
 the one produced by the hook.

 I don't get it. The message from the hook is replaced with the message
 from the hook?

 What I don't get is how you can amend to a commit that doesn't yet
 exists. How is that possible?

 --
 Med vänliga hälsningar
 Fredrik Gustafsson

 tel: 0733-608274
 e-post: iv...@iveqy.com

Did I say anything about a commit that doesn't exist? I have a commit
which I want to amend. If I click the Amend button before the hook is
done, this commit's message is replaced (in the editor, not the actual
commit) with the hook's result.

The message that should appear in the editor should come from the
amended commit, not from the hook.

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

Re: git gui replaces amend message when prepare-commit-msg hook is used

[Orgad Shaneh]

On Thu, Jul 4, 2013 at 1:34 PM, John Keeping j...@keeping.me.uk wrote:
 On Thu, Jul 04, 2013 at 12:47:28PM +0300, Orgad Shaneh wrote:
 Hi,

 If a prepare-commit-msg hook is used, git gui executes it for New Commit.

 If the New Commit is selected, and then immediately Amend (before
 the hook returns), when the hook returns the message is replaced with
 the one produced by the hook.

 I think this is a problem with the hook you are running.  The hook is
 given arguments specifying the message file and optionally the source of
 whatever is already in the file (see githooks(5) for details).

 It sounds like your hook is blindly overwriting the file, rather than
 preserving its contents in the cases where you wish to do so.

Let me try to explain.

When git gui is executed, it calls the prepare-commit-msg script with
.git/PREPARE_COMMIT_MSG as an argument.

When amend is selected, the hook is *not* called at all (what would it
prepare? The message is already committed)

Use the following hook to reproduce:
--- snip ---
#!/bin/sh

sleep 5
echo $@  /tmp/hook.log
echo 'Hello hook'  $1
--- snip ---

Now run git gui (or press F5 if it is already running), and before 5
seconds pass, click Amend last commit. You'll see the commit's
message, but when the 5 seconds pass it is replaced with Hello hook.
That's the bug.

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

Re: git gui replaces amend message when prepare-commit-msg hook is used

[Orgad Shaneh]

On Thu, Jul 4, 2013 at 2:19 PM, John Keeping j...@keeping.me.uk wrote:
 On Thu, Jul 04, 2013 at 01:59:10PM +0300, Orgad Shaneh wrote:
 On Thu, Jul 4, 2013 at 1:34 PM, John Keeping j...@keeping.me.uk wrote:
  On Thu, Jul 04, 2013 at 12:47:28PM +0300, Orgad Shaneh wrote:
  Hi,
 
  If a prepare-commit-msg hook is used, git gui executes it for New 
  Commit.
 
  If the New Commit is selected, and then immediately Amend (before
  the hook returns), when the hook returns the message is replaced with
  the one produced by the hook.
 
  I think this is a problem with the hook you are running.  The hook is
  given arguments specifying the message file and optionally the source of
  whatever is already in the file (see githooks(5) for details).
 
  It sounds like your hook is blindly overwriting the file, rather than
  preserving its contents in the cases where you wish to do so.

 Let me try to explain.

 When git gui is executed, it calls the prepare-commit-msg script with
 .git/PREPARE_COMMIT_MSG as an argument.

 When amend is selected, the hook is *not* called at all (what would it
 prepare? The message is already committed)

 Use the following hook to reproduce:
 --- snip ---
 #!/bin/sh

 sleep 5
 echo $@  /tmp/hook.log
 echo 'Hello hook'  $1
 --- snip ---

 Now run git gui (or press F5 if it is already running), and before 5
 seconds pass, click Amend last commit. You'll see the commit's
 message, but when the 5 seconds pass it is replaced with Hello hook.
 That's the bug.

 Yes, and that's a bug in the hook.  The hook is called with a second
 argument commit but it is ignoring this and blindly overwriting the
 message.  githooks(5) says:

 prepare-commit-msg
 This hook is invoked by git commit right after preparing the default
 log message, and before the editor is started.

 It takes one to three parameters. The first is the name of the
 file that contains the commit log message. The second is the
 source of the commit message, and can be: message (if a -m or -F
 option was given); template (if a -t option was given or the
 configuration option commit.template is set); merge (if the
 commit is a merge or a .git/MERGE_MSG file exists); squash (if a
 .git/SQUASH_MSG file exists); or commit, followed by a commit
 SHA1 (if a -c, -C or --amend option was given).

 If the exit status is non-zero, git commit will abort.

 The purpose of the hook is to edit the message file in place,
 and it is not suppressed by the --no-verify option. A non-zero
 exit means a failure of the hook and aborts the commit. It
 should not be used as replacement for pre-commit hook.

 Your problem is that your hook script is not checking $2 so it is
 overwriting the message even when you do not want to do so.

No, it isn't. Not by git-gui at least. Check /tmp/hook.log with the
hook I provided...

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

Re: git gui replaces amend message when prepare-commit-msg hook is used

[Orgad Shaneh]

On Thu, Jul 4, 2013 at 3:42 PM, Antoine Pelisse apeli...@gmail.com wrote:
 Your problem is that your hook script is not checking $2 so it is
 overwriting the message even when you do not want to do so.

 No, it isn't. Not by git-gui at least. Check /tmp/hook.log with the
 hook I provided...

 So what you mean is that the hook is not executed with the correct parameters?
 Could you please provide the output of the /tmp/hook.log file (I can't
 reproduce right now) ?

It only runs for New commit (possibly with merge or squash as
arguments). In my case the log is:
.git/PREPARE_COMMIT_MSG
.git/PREPARE_COMMIT_MSG
.git/PREPARE_COMMIT_MSG
...

Not running the hook for amend is another problem.

What I referred to was that handling the hook's result is done without
checking if the state has changed while it was running, like Fredrik
has already pointed out.

- Orgad
--
To unsubscribe from this list: send the line 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: relative objects/info/alternates doesn't work on remote SMB repo

[Orgad Shaneh]

On Thu, Aug 30, 2012 at 3:34 PM, Orgad and Raizel Shaneh
org...@gmail.com wrote:

 On Thu, Aug 30, 2012 at 4:22 PM, Nguyen Thai Ngoc Duy pclo...@gmail.com
 wrote:
  On Thu, Aug 30, 2012 at 8:12 PM, Orgad and Raizel Shaneh
  org...@gmail.com wrote:
  Could be path normalization. What does git rev-parse --git-dir say?
  Try to run it at top working directory and a subdirectory as well.
 
  If you set GIT_OBJECT_DIRECTORY environment variable to
  //server/share/foo/repo/.git/objects, does it work?
 
  git rev-parse --git-dir in a subdirectory has //server
 
  Hmm where is your git repository? That does not look like a git
  repository's path.
 

 Let me try to explain again.
 I have /d/share/bare, which is a bare repository, and /d/share/repo
 which is a clone with a relative path to bare/.git/objects in its
 .git/objects/info/alternates

 D:\share is configured as a SMB shared folder. It is accessed using
 //server/share.
 I do not clone from this directory, but work directly in it using 'cd
 //server/share', then performing git operations.

  setting GIT_OBJECT_DIRECTORY prints fatal: bad object HEAD on git
  status.
 
  I guessed you put your repo in .../repo/.git, but I was probably
  wrong. Try setting again, pointing GIT_OBJECT_DIRECTORY to the
  objects directory inside your repository. I just want to make see if
  it's because git miscalculates this path. If setting the env variable
  works, then it probably does.
  --
  Duy

 Same result. fatal: bad object HEAD. Tried even using a full (local)
 path to the objects dir.

 - Orgad

Any news? This still doesn't work with 1.8.0.

- Orgad
--
To unsubscribe from this list: send the line 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] gitweb: fix error when highlight is enabled

[Orgad Shaneh]

Use of uninitialized value in substitution iterator at gitweb.cgi line 1560

Signed-off-by: Orgad Shaneh org...@gmail.com
---
 gitweb/gitweb.perl |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0f207f2..862b9cd 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1556,7 +1556,7 @@ sub sanitize {
return undef unless defined $str;
 
$str = to_utf8($str);
-   $str =~ s|([[:cntrl:]])|($1 =~ /[\t\n\r]/ ? $1 : quot_cec($1))|eg;
+   $str =~ s|([[:cntrl:]])|($1 =~ /([\t\n\r])/ ? $1 : quot_cec($1))|eg;
return $str;
 }
 
-- 
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

[PATCH] gitweb: fix error in sanitize when highlight is enabled

[Orgad Shaneh]

$1 becomes undef by internal regex, since it has no capture groups.

Match against accpetable control characters using index() instead of a regex.

Signed-off-by: Orgad Shaneh org...@gmail.com
---
 gitweb/gitweb.perl |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0f207f2..6d5aeab 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1556,7 +1556,7 @@ sub sanitize {
return undef unless defined $str;
 
$str = to_utf8($str);
-   $str =~ s|([[:cntrl:]])|($1 =~ /[\t\n\r]/ ? $1 : quot_cec($1))|eg;
+   $str =~ s|([[:cntrl:]])|(index(\t\n\r, $1) != -1 ? $1 : 
quot_cec($1))|eg;
return $str;
 }
 
-- 
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: rev-parse fails on objects that contain colon

[Orgad Shaneh]

On Sun, Feb 17, 2013 at 10:37 AM, Orgad Shaneh org...@gmail.com wrote:
 $ git stash save foo:bar
 HEAD is now at 9f88dce Foo
 $ git stash pop foo:bar
 fatal: Invalid object name 'foo'.
 $ git rev-parse foo:bar
 foo:bar
 fatal: Invalid object name 'foo'.

 Tested on Windows (msysGit) and Linux.

 - Orgad

Oops! stash pop requires explicit stash. Disregard my message...

- Orgad
--
To unsubscribe from this list: send the line 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] rebase: use -f for checkout

[Orgad Shaneh]

If a file's case is changed on rename (Foo - foo), rebase
fails on Windows because the file already exists.

The change is safe, because if working directory is not clean
rebase fails before checking out.
---
 git-rebase.sh |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/git-rebase.sh b/git-rebase.sh
index b2f1c76..28fdc32 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -522,7 +522,7 @@ test $type = interactive  run_specific_rebase
 
 # Detach HEAD and reset the tree
 say $(gettext First, rewinding head to replay your work on top of it...)
-git checkout -q $onto^0 || die could not detach HEAD
+git checkout -fq $onto^0 || die could not detach HEAD
 git update-ref ORIG_HEAD $orig_head
 
 # If the $onto is a proper descendant of the tip of the branch, then
-- 
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

[PATCH] submodule: add verbose mode for add/update

[Orgad Shaneh]

Executes checkout without -q
---
 git-submodule.sh |   24 +++-
 1 file changed, 19 insertions(+), 5 deletions(-)

diff --git a/git-submodule.sh b/git-submodule.sh
index 79bfaac..f7964ad 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,11 +5,11 @@
 # Copyright (c) 2007 Lars Hjemli
 
 dashless=$(basename $0 | sed -e 's/-/ /')
-USAGE=[--quiet] add [-b branch] [-f|--force] [--name name] [--reference 
repository] [--] repository [path]
+USAGE=[--quiet] add [-b branch] [-f|--force] [--name name] [--reference 
repository] [-v|--verbose] [--] repository [path]
or: $dashless [--quiet] status [--cached] [--recursive] [--] [path...]
or: $dashless [--quiet] init [--] [path...]
or: $dashless [--quiet] deinit [-f|--force] [--] path...
-   or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] 
[-f|--force] [--rebase] [--reference repository] [--merge] [--recursive] [--] 
[path...]
+   or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] 
[-f|--force] [--rebase] [--reference repository] [--merge] [--recursive] 
[-v|--verbose] [--] [path...]
or: $dashless [--quiet] summary [--cached|--files] [--summary-limit n] 
[commit] [--] [path...]
or: $dashless [--quiet] foreach [--recursive] command
or: $dashless [--quiet] sync [--recursive] [--] [path...]
@@ -309,6 +309,9 @@ cmd_add()
custom_name=$2
shift
;;
+   -v|--verbose)
+   VERBOSE=1
+   ;;
--)
shift
break
@@ -408,11 +411,15 @@ Use -f if you really want to add it. 2
module_clone $sm_path $sm_name $realrepo $reference || 
exit
(
clear_local_git_env
+   if test -z $VERBOSE
+   then
+   subquiet=-q
+   fi
cd $sm_path 
# ash fails to wordsplit ${branch:+-b $branch...}
case $branch in
-   '') git checkout -f -q ;;
-   ?*) git checkout -f -q -B $branch origin/$branch ;;
+   '') git checkout -f $subquiet ;;
+   ?*) git checkout -f $subquiet -B $branch 
origin/$branch ;;
esac
) || die $(eval_gettext Unable to checkout submodule 
'\$sm_path')
fi
@@ -676,6 +683,9 @@ cmd_update()
--checkout)
update=checkout
;;
+   -v|--verbose)
+   VERBOSE=1
+   ;;
--)
shift
break
@@ -799,7 +809,11 @@ Maybe you want to use 'update --init'?)
must_die_on_failure=yes
;;
*)
-   command=git checkout $subforce -q
+   if test -z $VERBOSE
+   then
+   subquiet=-q
+   fi
+   command=git checkout $subforce $subquiet
die_msg=$(eval_gettext Unable to checkout 
'\$sha1' in submodule path '\$prefix\$sm_path')
say_msg=$(eval_gettext Submodule path 
'\$prefix\$sm_path': checked out '\$sha1')
;;
-- 
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

[PATCH] submodule: add verbose mode for add/update

[Orgad Shaneh]

When 'git submodule add/update' is run there is no output during
checkout. This can take a significant amount of time and it would
be nice if user could enable some feedback to see what's going on.

Add the -v/--verbose option to both add and update which suppresses
the -q normally given to checkout so the user sees progress output
from the checkout command.

Signed-off-by: Orgad Shaneh org...@gmail.com
---
 Documentation/git-submodule.txt |   10 --
 git-submodule.sh|   24 +++-
 2 files changed, 27 insertions(+), 7 deletions(-)

diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 74d5bdc..6abfd5d 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -10,13 +10,13 @@ SYNOPSIS
 
 [verse]
 'git submodule' [--quiet] add [-b branch] [-f|--force] [--name name]
- [--reference repository] [--] repository [path]
+ [--reference repository] [-v|--verbose] [--] repository 
[path]
 'git submodule' [--quiet] status [--cached] [--recursive] [--] [path...]
 'git submodule' [--quiet] init [--] [path...]
 'git submodule' [--quiet] deinit [-f|--force] [--] path...
 'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch]
  [-f|--force] [--rebase] [--reference repository]
- [--merge] [--recursive] [--] [path...]
+ [--merge] [--recursive] [-v|--verbose] [--] [path...]
 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) n]
  [commit] [--] [path...]
 'git submodule' [--quiet] foreach [--recursive] command
@@ -324,6 +324,12 @@ for linkgit:git-clone[1]'s `--reference` and `--shared` 
options carefully.
only in the submodules of the current repo, but also
in any nested submodules inside those submodules (and so on).
 
+-v::
+--verbose::
+   This option makes the checkout operation more verbose.
+   By default, a quiet checkout is performed. Specifying --verbose
+   provides progress information to the user.
+
 path...::
Paths to submodule(s). When specified this will restrict the command
to only operate on the submodules found at the specified paths.
diff --git a/git-submodule.sh b/git-submodule.sh
index 79bfaac..f7964ad 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,11 +5,11 @@
 # Copyright (c) 2007 Lars Hjemli
 
 dashless=$(basename $0 | sed -e 's/-/ /')
-USAGE=[--quiet] add [-b branch] [-f|--force] [--name name] [--reference 
repository] [--] repository [path]
+USAGE=[--quiet] add [-b branch] [-f|--force] [--name name] [--reference 
repository] [-v|--verbose] [--] repository [path]
or: $dashless [--quiet] status [--cached] [--recursive] [--] [path...]
or: $dashless [--quiet] init [--] [path...]
or: $dashless [--quiet] deinit [-f|--force] [--] path...
-   or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] 
[-f|--force] [--rebase] [--reference repository] [--merge] [--recursive] [--] 
[path...]
+   or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] 
[-f|--force] [--rebase] [--reference repository] [--merge] [--recursive] 
[-v|--verbose] [--] [path...]
or: $dashless [--quiet] summary [--cached|--files] [--summary-limit n] 
[commit] [--] [path...]
or: $dashless [--quiet] foreach [--recursive] command
or: $dashless [--quiet] sync [--recursive] [--] [path...]
@@ -309,6 +309,9 @@ cmd_add()
custom_name=$2
shift
;;
+   -v|--verbose)
+   VERBOSE=1
+   ;;
--)
shift
break
@@ -408,11 +411,15 @@ Use -f if you really want to add it. 2
module_clone $sm_path $sm_name $realrepo $reference || 
exit
(
clear_local_git_env
+   if test -z $VERBOSE
+   then
+   subquiet=-q
+   fi
cd $sm_path 
# ash fails to wordsplit ${branch:+-b $branch...}
case $branch in
-   '') git checkout -f -q ;;
-   ?*) git checkout -f -q -B $branch origin/$branch ;;
+   '') git checkout -f $subquiet ;;
+   ?*) git checkout -f $subquiet -B $branch 
origin/$branch ;;
esac
) || die $(eval_gettext Unable to checkout submodule 
'\$sm_path')
fi
@@ -676,6 +683,9 @@ cmd_update()
--checkout)
update=checkout
;;
+   -v|--verbose)
+   VERBOSE=1
+   ;;
--)
shift
break
@@ -799,7 +809,11 @@ Maybe you want to use 'update --init

Fwd: [PATCH] submodule: add verbose mode for add/update

[Orgad Shaneh]

On Wed, Apr 10, 2013 at 11:00 PM, Jens Lehmann jens.lehm...@web.de wrote:

 Am 10.04.2013 20:24, schrieb Orgad Shaneh:
  Executes checkout without -q

 Nice, looks like you picked the proposal I made last September:
   http://permalink.gmane.org/gmane.comp.version-control.git/204747

Took me a while, but I finally got to it :)

 The change is looking good, but you still need to document the
 new option in Documentation/git-submodule.txt too please.

 And the commit message is still too short, as I said in that
 other thread:

 On Tue, Sep 4, 2012 at 6:28 PM, Jens Lehmann jens.lehm...@web.de wrote:
  Before the Signed-off-by is the place where you should have
  explained why this would be a worthwhile change ;-)

 And you answered to that with something that would really make
 sense as first part of the commit message, because you explain
 *why* you do that change:

 Am 05.09.2012 13:42, schrieb Orgad and Raizel Shaneh:
  When I run 'git submodule update' I don't expect to be in the dark
  until the submodule/s finishes checkout, this sometimes can take a
  significant amount of time and feedback is expected.

 Another paragraph after that should explain *how* you do it.

 So what about the following as commit message:
 --
 When 'git submodule add/update' is run there is no output during
 checkout. This can take a significant amount of time and it would
 be nice if user could enable some feedback to see what's going on.

 Add the -v/--verbose option to both add and update which suppresses
 the -q normally given to checkout so the user sees progress output
 from the checkout command.

 Your Signed-off-by goes here
 --

 I'm looking forward to your next iteration.

Done quicker this time ;-)

Thanks a lot for your review (previous and current). It was very helpful!

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

Re: [PATCH] git-gui: Do not reset author details on amend

[Orgad Shaneh]

ping?

On Thu, May 5, 2016 at 8:22 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Pat, we haven't heard from you for a long time.  Are you still
> around and interested in helping us by maintaining git-gui?
>
> Otherwise we may have to start recruiting a volunteer or two to take
> this over.
>
> Thanks.
>
> Orgad Shaneh <org...@gmail.com> writes:
>
>> git commit --amend preserves the author details unless --reset-author is
>> given.
>>
>> git-gui discards the author details on amend.
>>
>> Fix by reading the author details along with the commit message, and
>> setting the appropriate environment variables required for preserving
>> them.
>>
>> Reported long ago in the mailing list[1].
>>
>> [1] http://article.gmane.org/gmane.comp.version-control.git/243921
>>
>> Signed-off-by: Orgad Shaneh <org...@gmail.com>
>> ---
>>  git-gui/lib/commit.tcl | 19 +++
>>  1 file changed, 19 insertions(+)
>>
>> diff --git a/git-gui/lib/commit.tcl b/git-gui/lib/commit.tcl
>> index 864b687..60edf99 100644
>> --- a/git-gui/lib/commit.tcl
>> +++ b/git-gui/lib/commit.tcl
>> @@ -1,8 +1,13 @@
>>  # git-gui misc. commit reading/writing support
>>  # Copyright (C) 2006, 2007 Shawn Pearce
>>
>> +set author_name ""
>> +set author_email ""
>> +set author_date ""
>> +
>>  proc load_last_commit {} {
>>   global HEAD PARENT MERGE_HEAD commit_type ui_comm
>> + global author_name author_email author_date
>>   global repo_config
>>
>>   if {[llength $PARENT] == 0} {
>> @@ -34,6 +39,10 @@ You are currently in the middle of a merge that has not 
>> been fully completed.  Y
>>   lappend parents [string range $line 7 
>> end]
>>   } elseif {[string match {encoding *} $line]} {
>>   set enc [string tolower [string range 
>> $line 9 end]]
>> + } elseif {[regexp "author 
>> (.*)\\s<(.*)>\\s(\\d.*$)" $line all name email time]} {
>> + set author_name $name
>> + set author_email $email
>> + set author_date $time
>>   }
>>   }
>>   set msg [read $fd]
>> @@ -107,8 +116,12 @@ proc do_signoff {} {
>>
>>  proc create_new_commit {} {
>>   global commit_type ui_comm
>> + global author_name author_email author_date
>>
>>   set commit_type normal
>> + set author_name ""
>> + set author_email ""
>> + set author_date ""
>>   $ui_comm delete 0.0 end
>>   $ui_comm edit reset
>>   $ui_comm edit modified false
>> @@ -327,6 +340,7 @@ proc commit_committree {fd_wt curHEAD msg_p} {
>>   global ui_comm selected_commit_type
>>   global file_states selected_paths rescan_active
>>   global repo_config
>> + global env author_name author_email author_date
>>
>>   gets $fd_wt tree_id
>>   if {[catch {close $fd_wt} err]} {
>> @@ -366,6 +380,11 @@ A rescan will be automatically started now.
>>   }
>>   }
>>
>> + if {$author_name ne ""} {
>> + set env(GIT_AUTHOR_NAME) $author_name
>> + set env(GIT_AUTHOR_EMAIL) $author_email
>> + set env(GIT_AUTHOR_DATE) $author_date
>> + }
>>   # -- Create the commit.
>>   #
>>   set cmd [list commit-tree $tree_id]
--
To unsubscribe from this list: send the line "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] git-gui: Do not reset author details on amend

[Orgad Shaneh]

git commit --amend preserves the author details unless --reset-author is
given.

git-gui discards the author details on amend.

Fix by reading the author details along with the commit message, and
setting the appropriate environment variables required for preserving
them.

Reported long ago in the mailing list[1].

[1] http://article.gmane.org/gmane.comp.version-control.git/243921

Signed-off-by: Orgad Shaneh <org...@gmail.com>
---
 git-gui/lib/commit.tcl | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/git-gui/lib/commit.tcl b/git-gui/lib/commit.tcl
index 864b687..60edf99 100644
--- a/git-gui/lib/commit.tcl
+++ b/git-gui/lib/commit.tcl
@@ -1,8 +1,13 @@
 # git-gui misc. commit reading/writing support
 # Copyright (C) 2006, 2007 Shawn Pearce
 
+set author_name ""
+set author_email ""
+set author_date ""
+
 proc load_last_commit {} {
global HEAD PARENT MERGE_HEAD commit_type ui_comm
+   global author_name author_email author_date
global repo_config
 
if {[llength $PARENT] == 0} {
@@ -34,6 +39,10 @@ You are currently in the middle of a merge that has not been 
fully completed.  Y
lappend parents [string range $line 7 
end]
} elseif {[string match {encoding *} $line]} {
set enc [string tolower [string range 
$line 9 end]]
+   } elseif {[regexp "author 
(.*)\\s<(.*)>\\s(\\d.*$)" $line all name email time]} {
+   set author_name $name
+   set author_email $email
+   set author_date $time
}
}
set msg [read $fd]
@@ -107,8 +116,12 @@ proc do_signoff {} {
 
 proc create_new_commit {} {
global commit_type ui_comm
+   global author_name author_email author_date
 
set commit_type normal
+   set author_name ""
+   set author_email ""
+   set author_date ""
$ui_comm delete 0.0 end
$ui_comm edit reset
$ui_comm edit modified false
@@ -327,6 +340,7 @@ proc commit_committree {fd_wt curHEAD msg_p} {
global ui_comm selected_commit_type
global file_states selected_paths rescan_active
global repo_config
+   global env author_name author_email author_date
 
gets $fd_wt tree_id
if {[catch {close $fd_wt} err]} {
@@ -366,6 +380,11 @@ A rescan will be automatically started now.
}
}
 
+   if {$author_name ne ""} {
+   set env(GIT_AUTHOR_NAME) $author_name
+   set env(GIT_AUTHOR_EMAIL) $author_email
+   set env(GIT_AUTHOR_DATE) $author_date
+   }
# -- Create the commit.
#
set cmd [list commit-tree $tree_id]
-- 
2.8.1

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

[PATCH] merge: Run commit-msg hook

[Orgad Shaneh]

From: Orgad Shaneh <org...@gmail.com>

commit-msg is needed to either validate the commit message or edit it.
Gerrit for instance uses this hook to append its Change-Id footer.

This is relevant to merge commit just like any other commit.

Signed-off-by: Orgad Shaneh <org...@gmail.com>
---
 Documentation/git-merge.txt | 6 +-
 builtin/merge.c | 7 ++-
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index b758d55..59508aa 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -11,7 +11,7 @@ SYNOPSIS
 [verse]
 'git merge' [-n] [--stat] [--no-commit] [--squash] [--[no-]edit]
[-s ] [-X ] [-S[]]
-   [--[no-]allow-unrelated-histories]
+   [--[no-]allow-unrelated-histories] [--no-verify]
[--[no-]rerere-autoupdate] [-m ] [...]
 'git merge'  HEAD ...
 'git merge' --abort
@@ -87,6 +87,10 @@ invocations. The automated message can include the branch 
description.
Allow the rerere mechanism to update the index with the
result of auto-conflict resolution if possible.
 
+--no-verify::
+   This option bypasses the commit-msg hook.
+   See also linkgit:githooks[5].
+
 --abort::
Abort the current conflict resolution process, and
try to reconstruct the pre-merge state.
diff --git a/builtin/merge.c b/builtin/merge.c
index b555a1b..30c03c8 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -51,7 +51,7 @@ static const char * const builtin_merge_usage[] = {
 static int show_diffstat = 1, shortlog_len = -1, squash;
 static int option_commit = 1;
 static int option_edit = -1;
-static int allow_trivial = 1, have_message, verify_signatures;
+static int allow_trivial = 1, have_message, verify_signatures, no_verify;
 static int overwrite_ignore = 1;
 static struct strbuf merge_msg = STRBUF_INIT;
 static struct strategy **use_strategies;
@@ -228,6 +228,7 @@ static struct option builtin_merge_options[] = {
{ OPTION_STRING, 'S', "gpg-sign", _commit, N_("key-id"),
  N_("GPG sign commit"), PARSE_OPT_OPTARG, NULL, (intptr_t) "" },
OPT_BOOL(0, "overwrite-ignore", _ignore, N_("update ignored 
files (default)")),
+   OPT_BOOL(0, "no-verify", _verify, N_("bypass commit-msg hook")),
OPT_END()
 };
 
@@ -809,6 +810,10 @@ static void prepare_to_commit(struct commit_list 
*remoteheads)
if (launch_editor(git_path_merge_msg(), NULL, NULL))
abort_commit(remoteheads, NULL);
}
+   if (!no_verify &&
+   run_commit_hook(0 < option_edit, get_index_file(), "commit-msg",
+   git_path_merge_msg(), NULL))
+   abort_commit(remoteheads, NULL);
read_merge_msg();
strbuf_stripspace(, 0 < option_edit);
if (!msg.len)
-- 
2.8.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] commit: Fix description of no-verify

[Orgad Shaneh]

From: Orgad Shaneh <org...@gmail.com>

include also commit-msg hook.

Signed-off-by: Orgad Shaneh <org...@gmail.com>
---
 builtin/commit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/builtin/commit.c b/builtin/commit.c
index 163dbca..2725712 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1616,7 +1616,7 @@ int cmd_commit(int argc, const char **argv, const char 
*prefix)
OPT_BOOL(0, "interactive", , N_("interactively add 
files")),
OPT_BOOL('p', "patch", _interactive, N_("interactively 
add changes")),
OPT_BOOL('o', "only", , N_("commit only specified files")),
-   OPT_BOOL('n', "no-verify", _verify, N_("bypass pre-commit 
hook")),
+   OPT_BOOL('n', "no-verify", _verify, N_("bypass pre-commit 
and commit-msg hooks")),
OPT_BOOL(0, "dry-run", _run, N_("show what would be 
committed")),
OPT_SET_INT(0, "short", _format, N_("show status 
concisely"),
STATUS_FORMAT_SHORT),
-- 
2.8.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] merge: Run commit-msg hook

[Orgad Shaneh]

Hi,

On Tue, Jul 26, 2016 at 4:02 PM, Johannes Schindelin
<johannes.schinde...@gmx.de> wrote:
> Hi Orgad,
>
> On Tue, 26 Jul 2016, Orgad Shaneh wrote:
>
>> From: Orgad Shaneh <org...@gmail.com>
>
> Again, this is unnecessary if you already send the mail from the same
> address.
>
>> commit-msg is needed to either validate the commit message or edit it.
>> Gerrit for instance uses this hook to append its Change-Id footer.
>>
>> This is relevant to merge commit just like any other commit.
>
> Hmm. This is not very convincing to me, as
>
> - if you call commit-msg in `git merge` now, why not `prepare-commit-msg`?

prepare-commit-msg is already called, a few lines above this addition.

>
> - a merge is a different beast from a simple commit. That is why we have
>   two different commands for them. A hook to edit the merge message may
>   need to know the *second* parent commit, too, for example to generate
>   a diffstat, or to add information about changes in an "evil commit".

That is correct for a post-merge hook. Why should *message validation* differ
between simple and merge commit?

> - if Gerrit is the intended user, would it not make more sense to
>   introduce a new hook, e.g. `merge-msg` (and `prepare-merge-msg`), as you
>   have to teach Gerrit a new trick anyway?

Why is that new? Every commit in gerrit has a Change-Id footer, which is
generated by commit-msg hook. What I currently do for merges that succeed
without conflicts is unconditional commit --amend --no-edit just to
run the hook.
This doesn't make sense.

> - if Gerrit is the intended user, why does it not simply edit the merge
>   message itself? After all, it executes it, and probably crafts a merge
>   message mentioning that this is an automatic merge, anyway, so why not
>   add the Change-Id *then*?

Most Gerrit setups require Change-Id in the commit message that the user
pushes. It is possible to disable this setting, and then you don't need the
Change-Id at all, but then you can't push a new patch set for the change
(unless you copy the Change-Id from gerrit to your commit message).
That's a real pain, I'm not aware of any public gerrit server that
disables this :)

> Ciao,
> Dscho

- Orgad
--
To unsubscribe from this list: send the line "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] commit: Fix description of no-verify

[Orgad Shaneh]

Hi and thanks for your reply.

On Tue, Jul 26, 2016 at 3:55 PM, Johannes Schindelin
<johannes.schinde...@gmx.de> wrote:
> Hi Orgad
>
> On Tue, 26 Jul 2016, Orgad Shaneh wrote:
>
>> From: Orgad Shaneh <org...@gmail.com>
>
> This is unnecessary, as it matches your email address.
>
>> include also commit-msg hook.
>
> This comment was a bit cryptic, until I read the patch. Now I find that
> comment redundant with the patch.

This brings the short help in line with the documentation. I should
have stated that in the commit message.

>
> However, I think that...
>
>> - OPT_BOOL('n', "no-verify", _verify, N_("bypass pre-commit 
>> hook")),
>> + OPT_BOOL('n', "no-verify", _verify, N_("bypass pre-commit 
>> and commit-msg hooks")),
>
>
> ... it may be more desirable to future-proof this simply by saying "bypass
> hooks".

That wouldn't be correct. prepare-commit-msg is not suppressed by this flag.

> In the alternative, it would be good if the commit message could
> convincingly make the case that there are no other hooks that will be
> skipped with -n.
>
> Of course, I could go and look at the source code to convince myself. But
> it is really the duty of the commit message to be already convincing
> enough.
>
> Ciao,
> Dscho

I don't have much experience with submitting patches to Git. How do I
edit the commit message? Submit it as a new patch?

- Orgad
--
To unsubscribe from this list: send the line "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] merge: Run commit-msg hook

[Orgad Shaneh]

Hi again,

On Tue, Jul 26, 2016 at 5:54 PM, Johannes Schindelin
<johannes.schinde...@gmx.de> wrote:
>
> Hi Orgad,
>
> On Tue, 26 Jul 2016, Orgad Shaneh wrote:
>
> > On Tue, Jul 26, 2016 at 4:02 PM, Johannes Schindelin
> > <johannes.schinde...@gmx.de> wrote:
> > >
> > > On Tue, 26 Jul 2016, Orgad Shaneh wrote:
> > >
> > >> commit-msg is needed to either validate the commit message or edit it.
> > >> Gerrit for instance uses this hook to append its Change-Id footer.
> > >>
> > >> This is relevant to merge commit just like any other commit.
> > >
> > > Hmm. This is not very convincing to me, as
> > >
> > > - if you call commit-msg in `git merge` now, why not `prepare-commit-msg`?
> >
> > prepare-commit-msg is already called, a few lines above this addition.
>
> Oh. That would have made a heck of a convincing argument in the commit
> message. Pity it was not mentioned. (Yes, please read that as a strong
> suggestion to fix that in the next patch iteration.)


Done.

>
>
> FWIW I dug out the original submission:
> http://thread.gmane.org/gmane.comp.version-control.git/151297/focus=151435
>
> It seems that there was no discussion about the commit-msg. Which makes me
> wonder why nobody thought of this.
>
> Now, you could make a case that you want to run the commit-msg hook in the
> same spirit as prepare-commit-msg (and mention that apparently nobody
> thought of that when the patch was accepted into builtin/merge.c).
>
> But then I wonder what your argument would be for *not* running the
> pre-commit and the post-commit hooks in `git merge` as well?
>
> Seems like a big inconsistency to me, one that would not be helped by a
> piecemeal patch that does only half the job of resolving the inconsistency.
>
> There was actually a question why the post-commit hook was not run in `git
> merge`:
> http://thread.gmane.org/gmane.comp.version-control.git/168716/focus=168773
> (but it seems nobody cared all that much).


pre-commit seems to have been rejected, though I must admit I don't
fully understand why.
post-commit might make sense, but I wouldn't include it in the same
patch. These are
different issues.

>
> > > - a merge is a different beast from a simple commit. That is why we
> > > have two different commands for them. A hook to edit the merge message
> > > may need to know the *second* parent commit, too, for example to
> > > generate a diffstat, or to add information about changes in an "evil
> > > commit".
> >
> > That is correct for a post-merge hook. Why should *message validation*
> > differ between simple and merge commit?
>
> You yourself do not use the hook for validation. You use it to *edit* the
> message. My examples do the very same thing. Why should they wait for a
> *post-merge* hook to amend the message?


Because commit-msg doesn't know anything about the commit. It only refers
to the message. The commit might even not exist when it is called. If you
need data from the commit, post-merge is the right place.

>
> Otherwise, why wouldn't you use the post-merge hook to add the Change-Id:
> in your use case, too...
>
> > > - if Gerrit is the intended user, would it not make more sense to
> > >   introduce a new hook, e.g. `merge-msg` (and `prepare-merge-msg`), as you
> > >   have to teach Gerrit a new trick anyway?
> >
> > Why is that new? Every commit in gerrit has a Change-Id footer, which is
> > generated by commit-msg hook.
>
> So it already works for Gerrit? Why is this patch needed, then? This is
> confusing.


Gerrit is a server, the user installs a commit-msg hook provided by
Gerrit on the local machine.
This hook currently works only for simple commits and not for
(trivial) merge commits.
That's where this patch comes to the rescue.

>
> > What I currently do for merges that succeed without conflicts is
> > unconditional commit --amend --no-edit just to run the hook.
>
> So you do that manually? Or you taught Gerrit to do that? Please clarify.


Gerrit can't do anything on my machine. It's a web/ssh server. I have my own
post-merge hook that runs commit --amend

> > > - if Gerrit is the intended user, why does it not simply edit the merge
> > >   message itself? After all, it executes it, and probably crafts a merge
> > >   message mentioning that this is an automatic merge, anyway, so why not
> > >   add the Change-Id *then*?
> >
> > Most Gerrit setups require Change-Id in the commit message that the user
> > pushes. It is possible to disable this setting, and then you don't need the
> > Change-Id at all, but then you 

Re: [PATCH] git-gui: Do not reset author details on amend

[Orgad Shaneh]

It's been over 2 months. Can anyone please review and merge it?

Thanks.
- Orgad

On Wed, May 18, 2016 at 9:12 AM, Orgad Shaneh <org...@gmail.com> wrote:
> ping?
>
> On Thu, May 5, 2016 at 8:22 PM, Junio C Hamano <gits...@pobox.com> wrote:
>> Pat, we haven't heard from you for a long time.  Are you still
>> around and interested in helping us by maintaining git-gui?
>>
>> Otherwise we may have to start recruiting a volunteer or two to take
>> this over.
>>
>> Thanks.
>>
>> Orgad Shaneh <org...@gmail.com> writes:
>>
>>> git commit --amend preserves the author details unless --reset-author is
>>> given.
>>>
>>> git-gui discards the author details on amend.
>>>
>>> Fix by reading the author details along with the commit message, and
>>> setting the appropriate environment variables required for preserving
>>> them.
>>>
>>> Reported long ago in the mailing list[1].
>>>
>>> [1] http://article.gmane.org/gmane.comp.version-control.git/243921
>>>
>>> Signed-off-by: Orgad Shaneh <org...@gmail.com>
>>> ---
>>>  git-gui/lib/commit.tcl | 19 +++
>>>  1 file changed, 19 insertions(+)
>>>
>>> diff --git a/git-gui/lib/commit.tcl b/git-gui/lib/commit.tcl
>>> index 864b687..60edf99 100644
>>> --- a/git-gui/lib/commit.tcl
>>> +++ b/git-gui/lib/commit.tcl
>>> @@ -1,8 +1,13 @@
>>>  # git-gui misc. commit reading/writing support
>>>  # Copyright (C) 2006, 2007 Shawn Pearce
>>>
>>> +set author_name ""
>>> +set author_email ""
>>> +set author_date ""
>>> +
>>>  proc load_last_commit {} {
>>>   global HEAD PARENT MERGE_HEAD commit_type ui_comm
>>> + global author_name author_email author_date
>>>   global repo_config
>>>
>>>   if {[llength $PARENT] == 0} {
>>> @@ -34,6 +39,10 @@ You are currently in the middle of a merge that has not 
>>> been fully completed.  Y
>>>   lappend parents [string range $line 7 
>>> end]
>>>   } elseif {[string match {encoding *} $line]} {
>>>   set enc [string tolower [string range 
>>> $line 9 end]]
>>> + } elseif {[regexp "author 
>>> (.*)\\s<(.*)>\\s(\\d.*$)" $line all name email time]} {
>>> + set author_name $name
>>> + set author_email $email
>>> + set author_date $time
>>>   }
>>>   }
>>>   set msg [read $fd]
>>> @@ -107,8 +116,12 @@ proc do_signoff {} {
>>>
>>>  proc create_new_commit {} {
>>>   global commit_type ui_comm
>>> + global author_name author_email author_date
>>>
>>>   set commit_type normal
>>> + set author_name ""
>>> + set author_email ""
>>> + set author_date ""
>>>   $ui_comm delete 0.0 end
>>>   $ui_comm edit reset
>>>   $ui_comm edit modified false
>>> @@ -327,6 +340,7 @@ proc commit_committree {fd_wt curHEAD msg_p} {
>>>   global ui_comm selected_commit_type
>>>   global file_states selected_paths rescan_active
>>>   global repo_config
>>> + global env author_name author_email author_date
>>>
>>>   gets $fd_wt tree_id
>>>   if {[catch {close $fd_wt} err]} {
>>> @@ -366,6 +380,11 @@ A rescan will be automatically started now.
>>>   }
>>>   }
>>>
>>> + if {$author_name ne ""} {
>>> + set env(GIT_AUTHOR_NAME) $author_name
>>> + set env(GIT_AUTHOR_EMAIL) $author_email
>>> + set env(GIT_AUTHOR_DATE) $author_date
>>> + }
>>>   # -- Create the commit.
>>>   #
>>>   set cmd [list commit-tree $tree_id]
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] git-gui: Do not reset author details on amend

[Orgad Shaneh]

4.5 months and counting... :(

- Orgad

On Sun, Jul 10, 2016 at 7:36 AM, Orgad Shaneh <org...@gmail.com> wrote:
> It's been over 2 months. Can anyone please review and merge it?
>
> Thanks.
> - Orgad
>
> On Wed, May 18, 2016 at 9:12 AM, Orgad Shaneh <org...@gmail.com> wrote:
>> ping?
>>
>> On Thu, May 5, 2016 at 8:22 PM, Junio C Hamano <gits...@pobox.com> wrote:
>>> Pat, we haven't heard from you for a long time.  Are you still
>>> around and interested in helping us by maintaining git-gui?
>>>
>>> Otherwise we may have to start recruiting a volunteer or two to take
>>> this over.
>>>
>>> Thanks.
>>>
>>> Orgad Shaneh <org...@gmail.com> writes:
>>>
>>>> git commit --amend preserves the author details unless --reset-author is
>>>> given.
>>>>
>>>> git-gui discards the author details on amend.
>>>>
>>>> Fix by reading the author details along with the commit message, and
>>>> setting the appropriate environment variables required for preserving
>>>> them.
>>>>
>>>> Reported long ago in the mailing list[1].
>>>>
>>>> [1] http://article.gmane.org/gmane.comp.version-control.git/243921
>>>>
>>>> Signed-off-by: Orgad Shaneh <org...@gmail.com>
>>>> ---
>>>>  git-gui/lib/commit.tcl | 19 +++
>>>>  1 file changed, 19 insertions(+)
>>>>
>>>> diff --git a/git-gui/lib/commit.tcl b/git-gui/lib/commit.tcl
>>>> index 864b687..60edf99 100644
>>>> --- a/git-gui/lib/commit.tcl
>>>> +++ b/git-gui/lib/commit.tcl
>>>> @@ -1,8 +1,13 @@
>>>>  # git-gui misc. commit reading/writing support
>>>>  # Copyright (C) 2006, 2007 Shawn Pearce
>>>>
>>>> +set author_name ""
>>>> +set author_email ""
>>>> +set author_date ""
>>>> +
>>>>  proc load_last_commit {} {
>>>>   global HEAD PARENT MERGE_HEAD commit_type ui_comm
>>>> + global author_name author_email author_date
>>>>   global repo_config
>>>>
>>>>   if {[llength $PARENT] == 0} {
>>>> @@ -34,6 +39,10 @@ You are currently in the middle of a merge that has not 
>>>> been fully completed.  Y
>>>>   lappend parents [string range $line 
>>>> 7 end]
>>>>   } elseif {[string match {encoding *} $line]} 
>>>> {
>>>>   set enc [string tolower [string 
>>>> range $line 9 end]]
>>>> + } elseif {[regexp "author 
>>>> (.*)\\s<(.*)>\\s(\\d.*$)" $line all name email time]} {
>>>> + set author_name $name
>>>> + set author_email $email
>>>> + set author_date $time
>>>>   }
>>>>   }
>>>>   set msg [read $fd]
>>>> @@ -107,8 +116,12 @@ proc do_signoff {} {
>>>>
>>>>  proc create_new_commit {} {
>>>>   global commit_type ui_comm
>>>> + global author_name author_email author_date
>>>>
>>>>   set commit_type normal
>>>> + set author_name ""
>>>> + set author_email ""
>>>> + set author_date ""
>>>>   $ui_comm delete 0.0 end
>>>>   $ui_comm edit reset
>>>>   $ui_comm edit modified false
>>>> @@ -327,6 +340,7 @@ proc commit_committree {fd_wt curHEAD msg_p} {
>>>>   global ui_comm selected_commit_type
>>>>   global file_states selected_paths rescan_active
>>>>   global repo_config
>>>> + global env author_name author_email author_date
>>>>
>>>>   gets $fd_wt tree_id
>>>>   if {[catch {close $fd_wt} err]} {
>>>> @@ -366,6 +380,11 @@ A rescan will be automatically started now.
>>>>   }
>>>>   }
>>>>
>>>> + if {$author_name ne ""} {
>>>> + set env(GIT_AUTHOR_NAME) $author_name
>>>> + set env(GIT_AUTHOR_EMAIL) $author_email
>>>> + set env(GIT_AUTHOR_DATE) $author_date
>>>> + }
>>>>   # -- Create the commit.
>>>>   #
>>>>   set cmd [list commit-tree $tree_id]

Re: [PATCH] git-gui: Do not reset author details on amend

[Orgad Shaneh]

On Tue, Sep 27, 2016 at 7:31 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Orgad Shaneh <org...@gmail.com> writes:
>
>> On Tue, Sep 27, 2016 at 12:34 AM, Junio C Hamano <gits...@pobox.com> wrote:
>>> Orgad Shaneh <org...@gmail.com> writes:
>>>
>> I actually see that there is a problem with it:
>> https://github.com/git-for-windows/git/issues/761
>>
>> I'll try to revise it and resubmit.
>
> Are you by chance volunteering to be git-gui maintainer?

No way, sorry. I don't speak TCL at all. Every change is a true pain... ;)

- Orgad

Re: [PATCH] git-gui: Do not reset author details on amend

[Orgad Shaneh]

On Tue, Sep 27, 2016 at 12:34 AM, Junio C Hamano <gits...@pobox.com> wrote:
> Orgad Shaneh <org...@gmail.com> writes:
>
>> On Sun, Jul 10, 2016 at 7:36 AM, Orgad Shaneh <org...@gmail.com> wrote:
>>
>>> On Wed, May 18, 2016 at 9:12 AM, Orgad Shaneh <org...@gmail.com> wrote:
>>>> ping?
>>>>
>>> It's been over 2 months. Can anyone please review and merge it?
>>>
>> 4.5 months and counting... :(
>>>
>>>> On Thu, May 5, 2016 at 8:22 PM, Junio C Hamano <gits...@pobox.com> wrote:
>>>>> Pat, we haven't heard from you for a long time.  Are you still
>>>>> around and interested in helping us by maintaining git-gui?
>>>>>
>>>>> Otherwise we may have to start recruiting a volunteer or two to take
>>>>> this over.
>
> Sorry about that.  No volunteers materialized yet X-<, and I really
> really do not want to apply anything other than trivial patches to
> it myself, as I am not a git-gui user.
>

This patch has been in use in Git for Windows for a decent period of time.

I actually see that there is a problem with it:
https://github.com/git-for-windows/git/issues/761

I'll try to revise it and resubmit.

- Orgad

recursive grep doesn't respect --color=always inside submodules

[Orgad Shaneh]

Hi,

When git grep --color=always is used, and the output is redirected to
a file or a pipe, results inside submodules are not colored. Results
in the supermodule are colored correctly.

- Orgad

fetch-any-blob / ref-in-want proposal

[Orgad Shaneh]

Hi,

Jonathan Tan proposed a design and a patch series for requesting a
specific ref on fetch 4 months ago[1].

Is there any progress with this?

- Orgad

[1] 
https://public-inbox.org/git/ffd92ad9-39fe-c76b-178d-6e3d6a425...@google.com/

Re: fetch-any-blob / ref-in-want proposal

[Orgad Shaneh]

On Mon, Jul 24, 2017 at 7:13 PM, Jonathan Tan <jonathanta...@google.com> wrote:
> On Sun, 23 Jul 2017 09:41:50 +0300
> Orgad Shaneh <org...@gmail.com> wrote:
>
>> Hi,
>>
>> Jonathan Tan proposed a design and a patch series for requesting a
>> specific ref on fetch 4 months ago[1].
>>
>> Is there any progress with this?
>>
>> - Orgad
>>
>> [1] 
>> https://public-inbox.org/git/ffd92ad9-39fe-c76b-178d-6e3d6a425...@google.com/
>
> Do you mean requesting a specific blob (as referenced by your link)? If yes, 
> it is still being discussed. One such discussion is here: [1]
>
> If you mean ref-in-want, I don't recall anything being done since then.
>
> [1] 
> https://public-inbox.org/git/cover.1499800530.git.jonathanta...@google.com/

Sorry, I thought it's the same thing. I mean ref-in-want[1]. This
issue in gerrit[2] was closed, claiming that ref-in-want will solve
it. I just want to know if this is likely to be merged soon enough (I
consider several months "soon enough"), or should I look for other
solutions.

- Orgad

[1] https://public-inbox.org/git/cover.1485381677.git.jonathanta...@google.com/
[2] https://bugs.chromium.org/p/gerrit/issues/detail?id=175#c24

Submodule/contents conflict

[Orgad Shaneh]

Hi,

I've noticed a strange behavior with submodule/content conflict. My
current Git version is 2.12.2, but the problem exists since I
remember.

Branch A has a submodule.
In branch B which diverged from A, I replaced the submodule with its contents.

Now, every time I merge A into B, and A had changed the submodule
reference, all the files inside the ex-submodule directory in B are
being "re-added".

Moreover, aborting the merge prints an error, but seems to work
nevertheless, and if I run git reset --hard all the files in that
directory are actually written to the disk, even though they haven't
changed at all.

When the submodule is small, it might be ok. But in my project we have
a huge submodule with ~16K files, and on each merge all the files are
listed, and even mixed reset takes several minutes.

The following script demonstrates this:
#!/bin/sh

rm -rf super sub
mkdir sub
cd sub
git init
touch foo
git add foo
git commit -m 'Initial commit'
mkdir ../super; cd ../super
git init
git submodule add ../sub
touch foo; git add foo sub
git commit -m 'Initial commit'
git checkout -b update-sub
git update-index --cacheinfo 16,,sub
git commit -m 'Update submodule'
git checkout -b remove-sub HEAD^
git rm sub
mkdir sub
touch sub/foo sub/bar
git add sub
git commit -m 'Replaced submodule with contents'
git checkout -b remove-2 HEAD^
git merge --no-ff remove-sub
git merge update-sub
# Adding sub/foo
# Adding sub/bar
# CONFLICT (modify/delete): sub deleted in HEAD and modified in
update-sub. Version update-sub of sub left in tree at sub~update-sub.
# Automatic merge failed; fix conflicts and then commit the result.
git merge --abort
# error: 'sub' appears as both a file and as a directory
# error: sub: cannot drop to stage #0

- Orgad

bug with git add and .gitignore

[Orgad Shaneh]

Hi,

When a not-ignored file inside an ignore directory is added along with
other files, a false alarm is shown:

git init
echo /d/ > .gitignore
mkdir d
touch d/file foo
git add -f d/file foo
git add d/file
# fine
git add d/file foo
# The following paths are ignored by one of your .gitignore files:
# d
# Use -f if you really want to add them.

I did not try to add a new file in d. It's the same file that is
already indexed.

- Orgad

[PATCH] name-rev: Fix tag lookup on repository with mixed types of tags

[Orgad Shaneh]

Commit 7550424804 (name-rev: include taggerdate in considering the best
name) introduced a bug in name-rev.

If a repository has both annotated and non-annotated tags, annotated
tag will always win, even if it was created decades after the commit.

Consider a repository that always used non-annotated tags, and at some
point started using annotated tags - name-rev --tags will return the
first annotated tags for all the old commits (in our repository it is
followed by ~5067 for one commit, or by ~120^2~21^2~88^2~87 for
another...). This is obviously not what the user expects.

The taggerdate should only be matched if *both tags* have it.
---
 builtin/name-rev.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/builtin/name-rev.c b/builtin/name-rev.c
index 92a5d8a5d2..8f77023482 100644
--- a/builtin/name-rev.c
+++ b/builtin/name-rev.c
@@ -46,11 +46,13 @@ static void name_rev(struct commit *commit,
  commit->util = name;
  goto copy_data;
  } else if (name->taggerdate > taggerdate ||
- (name->taggerdate == taggerdate &&
+ ((taggerdate == ULONG_MAX || name->taggerdate == taggerdate) &&
  name->distance > distance)) {
 copy_data:
  name->tip_name = tip_name;
- name->taggerdate = taggerdate;
+ if (taggerdate != ULONG_MAX) {
+ name->taggerdate = taggerdate;
+ }
  name->generation = generation;
  name->distance = distance;
  } else
-- 
2.13.1.windows.1.1.ga36e14b3aa

Getting first tag per branch for a commit

[Orgad Shaneh]

Hi,

git describe --tags  gives me the first tag that includes this commit.

git tag --contains  shows all the tags that contain the commit.

git branch -a --contains  shows the branches that include this commit.

What I'd like to have is a way to tell the first tag per branch (or
per merge) that the commit appeared on.

I'll use an example from the Git repository. Let's pick commit
32b8c581ec which was first introduced in v2.9.3.

git describe --tags will only show v2.9.3

git tag --contains shows the following list:
v2.10.0
v2.10.0-rc0
v2.10.0-rc1
v2.10.0-rc2
v2.10.1
v2.10.2
v2.10.3
v2.11.0
v2.11.0-rc0
v2.11.0-rc1
v2.11.0-rc2
v2.11.0-rc3
v2.11.1
v2.11.2
v2.12.0
v2.12.0-rc0
v2.12.0-rc1
v2.12.0-rc2
v2.12.1
v2.12.2
v2.12.3
v2.13.0
v2.13.0-rc0
v2.13.0-rc1
v2.13.0-rc2
v2.13.1
v2.13.2
v2.9.3
v2.9.4

What really interests me as a user is the "first in the series" tag
for each version. What I'd expect is:
v2.10.0-rc0
v2.9.3

and I can conclude that if it appeared in 2.9.3 then 2.9.4 also has
it, and if it's in 2.10.0-rc0 then all the following versions (2.10.x
and up) include it.

I think that this can be done by filtering out tags that are connected
to already listed tags by first-parent link.

Is there a way to achieve this kind of "simplified contained in" list?

Related: https://bugs.chromium.org/p/gerrit/issues/detail?id=4331

- Orgad

Re: Getting first tag per branch for a commit

[Orgad Shaneh]

On Mon, Jun 26, 2017 at 12:54 AM, Junio C Hamano <gits...@pobox.com> wrote:
> Orgad Shaneh <org...@gmail.com> writes:
>
>> What I'd like to have is a way to tell the first tag per branch (or
>> per merge) that the commit appeared on.
>
>> I think that this can be done by filtering out tags that are connected
>> to already listed tags by first-parent link.
>
> Yes.  When one tag can be reached by another tag, then the former is
> definitely an earlier tag than the latter.
>
> A trivial way to compute it would require O(n^2) invocations of "git
> merge-base --is-ancestor".  Alternatively, I think you can perhaps
> use "git merge-base --independent".

I think this feature needs to be implemented in Git (by a flag to git describe).
O(n^2) is way too much when you have 20,000 tags.

Unfortunately, I don't feel qualified for implementing it myself. Does anyone
else volunteer? :)

> Having said that, one thing to keep in mind is that a single "first
> tag" may not exist at all.
>
> Consider this topology:
>
>   o---X---.topic
>  / \   \
>  ---o---o---o---o---N---S---o---   maint
>  \   \   \   \
>   o---o---o---M---o---o---T---o--- master
>
> where a topic branch was forked from the maintenance track, which is
> periodically merged to the master branch.  That topic branch has the
> commit of interest, X, which first gets merged to the master branch
> at merge M, which eventually gets tagged as T (i.e. a new feature
> release).  But (wall-clock-wise) after merge M is made and the
> change is tested in the context of the master branch, but before the
> release T happens, the topic may be merged down to the maintenance
> track at merge N.  Then eventually the tip of the maintenance track
> is tagged as S (i.e. a maintenance release).
>
> Topologically, T and S cannot be compared and they both contain X,
> so the question "what is the first tag on 'master' that has commit
> X?" does not have a single unique answer.  Both S and T are eligible.
>
> You could define various heuristics to tiebreak among these tags.
> You may be tempted to compare timestamps of S and T.  If they were
> equal, then you might want to compare timestamps of M and N.
>
> But you'd need to accept that fundamentally there may not be a
> single "first tag".

I accept that. Anyway, this looks to me like a corner case, and I don't mind
having several tags from the same branch for this case.

- Orgad

Out of memory with diff.colormoved enabled

[Orgad Shaneh]

Hi,

git version 2.15.0.rc0 (from debian sid package)

There is an infinite loop when colormoved is used with --ignore-space-change:

git init
seq 20 > test
git add test
sed -i 's/9/42/' test
git -c diff.colormoved diff --ignore-space-change -- test

- Orgad

Lightweight tags are still not considered on git describe --contains

[Orgad Shaneh]

Hi,

There was an issue with lightweight tags that was supposed to be fixed
in Git 2.14 (by branch jc/name-rev-lw-tag).

I also proposed a patch[1], but that was too late, after the other fix
was already in master.

Anyway, I still have the same issue with git 2.14.2.windows.3.

My repository has both annotated and lightweight tags, and git
describe on old commits that's supposed to show an old (lightweight)
tags always shows the first annotated tag.

I rebased my patch on top of master. I'll post it later today.

- Orgad

[1] 
http://lists-archives.com/git/898695-name-rev-fix-tag-lookup-on-repository-with-mixed-types-of-tags.html

Re: Regression[2.14.3->2.15]: Interactive rebase fails if submodule is modified

[Orgad Shaneh]

On Fri, Nov 3, 2017 at 6:20 PM, Johannes Schindelin
<johannes.schinde...@gmx.de> wrote:
> Hi Orgad,
>
> On Fri, 3 Nov 2017, Johannes Schindelin wrote:
>
>> On Thu, 2 Nov 2017, Orgad Shaneh wrote:
>>
>> > I can't reproduce this with a minimal example, but it happens in my 
>> > project.
>
> Whoa, I somehow overlooked the "can't". Sorry.
>
> I inserted a `git diff-files` here, and it printed exactly what I
> expected:
>
> ++ git diff-files
> :16 16 62cab94c8d8cf047bbb60c12def559339300efa4 
>  M  sub
>
>> + git rebase -i HEAD^^
>> + )
>> +'
>
> There must be something else going wrong that we did not replicate here.
> Maybe the `error: cannot rebase: You have unstaged changes.` message was
> caused not by a change in the submodule? Could you run `git diff-files`
> before the rebase?

It's the same before and during the rebase:
$ git diff-files
:16 16 c840225a7cf6bb2ec64da9d35d2c29210bc5e5e8
 M  sub


>
> This does *not* refresh the index, but maybe that is what is going wrong;
> you could call `git update-index --refresh` before the rebase and see
> whether that works around the issue?

Nope.

If I run git submodule update, then rebase --continue works fine, so
it's definitely somehow caused by the submodule.

- Orgad

Re: Regression[2.14.3->2.15]: Interactive rebase fails if submodule is modified

[Orgad Shaneh]

On Sat, Nov 4, 2017 at 8:04 PM, Orgad Shaneh <org...@gmail.com> wrote:
> On Fri, Nov 3, 2017 at 6:20 PM, Johannes Schindelin
> <johannes.schinde...@gmx.de> wrote:
>> Hi Orgad,
>>
>> On Fri, 3 Nov 2017, Johannes Schindelin wrote:
>>
>>> On Thu, 2 Nov 2017, Orgad Shaneh wrote:
>>>
>>> > I can't reproduce this with a minimal example, but it happens in my 
>>> > project.
>>
>> Whoa, I somehow overlooked the "can't". Sorry.
>>
>> I inserted a `git diff-files` here, and it printed exactly what I
>> expected:
>>
>> ++ git diff-files
>> :16 16 62cab94c8d8cf047bbb60c12def559339300efa4 
>>  M  sub
>>
>>> + git rebase -i HEAD^^
>>> + )
>>> +'
>>
>> There must be something else going wrong that we did not replicate here.
>> Maybe the `error: cannot rebase: You have unstaged changes.` message was
>> caused not by a change in the submodule? Could you run `git diff-files`
>> before the rebase?
>
> It's the same before and during the rebase:
> $ git diff-files
> :16 16 c840225a7cf6bb2ec64da9d35d2c29210bc5e5e8
>  M  sub
>
>
>>
>> This does *not* refresh the index, but maybe that is what is going wrong;
>> you could call `git update-index --refresh` before the rebase and see
>> whether that works around the issue?
>
> Nope.
>
> If I run git submodule update, then rebase --continue works fine, so
> it's definitely somehow caused by the submodule.

I just checked out v2.15.0.windows.1 and reverted ff6f1f564c - it
solves the problem. I still have no idea how to minimally reproduce
(in my project it's easily reproducible) :)

- Orgad

Re: Regression[2.14.3->2.15]: Interactive rebase fails if submodule is modified

[Orgad Shaneh]

On Mon, Nov 6, 2017 at 8:37 PM, Brandon Williams  wrote:

> After reading your bug report and the fact that you weren't able to
> reproduce it outside of your project I think i figured out what is
> happening.  Before ff6f1f564c the gitmodules file wasn't being loaded
> unless a codepath explicitly wanted to work with submodules.  Now they
> are being lazy-loaded so if you call into the submodule config subsystem
> it'll work without having to have initialized it before.  I suspect
> that the submodule which is causing the failure has a
> "submodule..ignore" entry in the .gitmodules file or somewhere in
> your repositories config (I actually suspect the latter based on the
> code path).
>
> When rebase calls into the diff machinery to see if there are unstaged
> changes it explicitly requests that submodule's be ignored, but this
> desired gets overridden by your repository's config, clearing the
> ignored flag and making rebase actually pay attention to the fact that
> the submodule has changes in it.
>
> I don't have a patch available to for you to test just yet (but I'll
> have some time later today to write one up) but could you verify that
> (1) you have an ignore entry for the submodule in question in your
> config and (2) removing it from your config avoids the failure?  If
> that's the case then we would be able to put together a reproducible
> recipe for this failure.

You're right. Thanks for the info. I have ignore = dirty, and removing
it from the config solves the problem indeed.

The following script reproduces the bug (it's the same as before, only
added git config):

rm -rf super sub
mkdir sub; cd sub; git init
git commit --allow-empty -m 'Initial commit'
mkdir ../super; cd ../super
git init
git submodule add ../sub
git config submodule.sub.ignore dirty
touch foo; git add foo sub
git commit -m 'Initial commit'
touch a; git add a; git commit -m 'a'
touch b; git add b; git commit -m 'b'
cd sub; git commit --allow-empty -m 'New commit'; cd ..
git rebase -i HEAD^^

- Orgad

Re: Regression[2.14.3->2.15]: Interactive rebase fails if submodule is modified

[Orgad Shaneh]

On Thu, Nov 2, 2017 at 8:34 PM, Stefan Beller <sbel...@google.com> wrote:
> On Thu, Nov 2, 2017 at 1:30 AM, Orgad Shaneh <org...@gmail.com> wrote:
>> I can't reproduce this with a minimal example, but it happens in my project.
>>
>> What I tried to do for reproducing is:
>> rm -rf super sub
>> mkdir sub; cd sub; git init
>> git commit --allow-empty -m 'Initial commit'
>> mkdir ../super; cd ../super
>> git init
>> git submodule add ../sub
>> touch foo; git add foo sub
>> git commit -m 'Initial commit'
>> touch a; git add a; git commit -m 'a'
>> touch b; git add b; git commit -m 'b'
>> cd sub; git commit --allow-empty -m 'New commit'; cd ..
>> git rebase -i HEAD^^
>>
>> Then drop a.
>>
>> In my project I get:
>> error: cannot rebase: You have unstaged changes.
>>
>> This works fine with 2.14.3.
>
>   git log --oneline v2.14.3..v2.15.0 -- submodule.c
> doesn't give any promising hints (i.e. I don't think one of a
> submodule related series introduced this either by chance or
> on purpose)
>
> "rebase -i" was rewritten into C in 570676e011, though
> that series was extensively tested by DScho, so I wouldn't
> want to point fingers here quickly.
>
> Would you be willing to bisect this behavior?

Bisected to ff6f1f564c48def1f8e1852826bab58af5044b06:
submodule-config: lazy-load a repository's .gitmodules file

- Orgad

Regression[2.14.3->2.15]: Interactive rebase fails if submodule is modified

[Orgad Shaneh]

I can't reproduce this with a minimal example, but it happens in my project.

What I tried to do for reproducing is:
rm -rf super sub
mkdir sub; cd sub; git init
git commit --allow-empty -m 'Initial commit'
mkdir ../super; cd ../super
git init
git submodule add ../sub
touch foo; git add foo sub
git commit -m 'Initial commit'
touch a; git add a; git commit -m 'a'
touch b; git add b; git commit -m 'b'
cd sub; git commit --allow-empty -m 'New commit'; cd ..
git rebase -i HEAD^^

Then drop a.

In my project I get:
error: cannot rebase: You have unstaged changes.

This works fine with 2.14.3.

- Orgad

Re: [PATCH] checkout files in-place

[Orgad Shaneh]

On Tue, Jun 12, 2018 at 11:51 AM Edward Thomson
 wrote:
>
> On Tue, Jun 12, 2018 at 09:13:54AM +0300, Orgad Shaneh wrote:
> > Some of my colleagues use an ancient version of Source Insight, which also
> > locks files for write.
>
> If that application is locking files for writing (that is to say, it did
> not specify the `FILE_SHARE_WRITE` bit in the sharing modes during
> `CreateFile`) then this patch would not help.
>
> Applications, generally speaking, should be locking files for write.
> It's the default in Win32 and .NET's file open APIs because few
> applications are prepared to detect and support a file changing out from
> underneath them in the middle of a read.

I agree.

> > It's less important than it was before those fixes, but it is still needed
> > for users of Qt Creator 4.6 (previous versions just avoided mmap, 4.7 uses
> > mmap only for system headers). Other tools on Windows might as well
> > misbehave.
>
> I don't understand what mmap'ing via `CreateFileMapping` has to do with
> this.  It takes an existing `HANDLE` that was opened with `CreateFile`,
> which is where the sharing mode was supplied.

I'm not completely sure. The file is opened using CreateFile[1] with
FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE.
Then this handle is passed to CreateFileMapping[2]. For a reason I don't
understand, when mapping is used, the handle is never released (until
the file is closed), but when it is not used, the file is being read, then the
handle is released.

Maybe Ivan or Nikolai can shed some light on this process.

Anyway, with Qt Creator 4.7 this should be a non-issue, so I'm reluctant about
this change here.

> I would be surprised if there are other tools on Windows that have
> specified `FILE_SHARE_WRITE` but not `FILE_SHARE_DELETE`.  Generally
> speaking, if you don't care about another process changing a file
> underneath you then you should specify both.  If you do then you should
> specify neither.

The problem is that even if you specify FILE_SHARE_WRITE and FILE_SHARE_DELETE,
the file can be unlinked, but it cannot be created with the same name
until its handle
is closed, unless you rename it *before* unlinking.

- Orgad

[1] 
https://github.com/llvm-mirror/llvm/blob/371257e/lib/Support/Windows/Path.inc#L1045
[2] 
https://github.com/llvm-mirror/llvm/blob/371257e/lib/Support/Windows/Path.inc#L836

[PATCH] git-rebase--interactive: fix copy-paste mistake

[Orgad Shaneh]

exec argument is a command, not a commit.

Signed-off-by: Orgad Shaneh <org...@gmail.com>
---
  git-rebase--interactive.sh | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index cbf44f8648..85a72b933e 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -160,7 +160,7 @@ r, reword  = use commit, but edit the commit
message
  e, edit  = use commit, but stop for amending
  s, squash  = use commit, but meld into previous commit
  f, fixup  = like \"squash\", but discard this commit's log message
-x, exec  = run command (the rest of the line) using shell
+x, exec  = run command (the rest of the line) using shell
  d, drop  = remove commit
  l, label  = label current HEAD with a name
  t, reset  = reset HEAD to a label
-- 
2.17.0.windows.1

Re: [PATCH] git-rebase--interactive: fix copy-paste mistake

[Orgad Shaneh]

On Mon, May 28, 2018 at 3:56 PM Johannes Schindelin <
johannes.schinde...@gmx.de> wrote:

> Hi Orgad,

> On Sun, 27 May 2018, Orgad Shaneh wrote:

> > exec argument is a command, not a commit.
> >
> > Signed-off-by: Orgad Shaneh <org...@gmail.com>
> > ---
> >   git-rebase--interactive.sh | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> > index cbf44f8648..85a72b933e 100644
> > --- a/git-rebase--interactive.sh
> > +++ b/git-rebase--interactive.sh
> > @@ -160,7 +160,7 @@ r, reword  = use commit, but edit the commit
> > message
> >   e, edit  = use commit, but stop for amending
> >   s, squash  = use commit, but meld into previous commit
> >   f, fixup  = like \"squash\", but discard this commit's log
message
> > -x, exec  = run command (the rest of the line) using shell
> > +x, exec  = run command (the rest of the line) using shell

> Apart from the white-space (which I *think* might make `git apply` barf on
> this diff), this looks obviously correct to me.

I'm behind a firewall, so I just pasted the patch in gmail, hoping it will
pass correctly :)

> To make it easier for Junio, maybe you can provide a link to a branch in a
> public repository, ready to be fetched?

Pushed to https://github.com/orgads/git -> exec-description branch.

> Thank you for cleaning up my mess,

No prob :)

- Orgad

A bug in git merge

[Orgad Shaneh]

Hi,

If I cherry-pick a commit that added a line, then merge another commit
which removes this line, the line remains in the file instead of being
removed.

The following script demonstrates the bug.

file should be equivalent on both branches

git init
seq 1 20 > file
git add file
git commit -m 'Initial'
sed -i "s/^5/5\n55/" file
git commit -a -m 'Added 55'
git checkout -b other HEAD^
git cherry-pick master
git commit --amend --author 'Author ' --no-edit # generate a new hash
sed -i '/55/d' file
git commit -a -m 'Removed 55'
git checkout master
git merge --no-edit other
git diff other # Should be equal

- Orgad

grep issues

[Orgad Shaneh]

Hi,

I found 2 bugs in grep, using Git for Windows 2.19.1 (but noticed
these several versions ago):

1. git grep --recursive on a worktree (without rev) always matches
against the submodule's HEAD, not its worktree, as it should.
2. When core.autocrlf (or eol=crlf) is used, and a file in the
worktree has CRLF, git grep fails to match $ against EOL.

For example:
git init
echo 'file eol=crlf' > .gitattributes
echo ABCD > file
git add file
git commit -m 'CRLF'
rm file
git checkout -f file
git grep 'D$' file # Nothing
git grep 'D$' HEAD -- file # Found!

- Orgad