Re: Whether Git supports directory level access or not?

[Junio C Hamano]

Jacob Keller jacob.kel...@gmail.com writes:

 However, in-repo per-directory permissions make no sense, as there
 would be no way to generate commits.

That may be the case for the current generation of Git, but I do not
think you have to be so pessimistic.

Suppose that an imaginary future version of Git allowed you to
hide one directory from you.  That is:

 * A commit object records tree. git cat-file -t HEAD^{tree}
   or git ls-tree HEAD lets you inspect its contents;

 * The hidden directory shows up as one of the subtrees of that
   output.  It may say

 04 tree b4006c408979a0c6261dbfaeaa36639457469ad4   hidden

 * However, your repository lack b4006c40... object.  So if you did
   git ls-tree HEAD:hidden, you would get no such tree object.

 * This imaginary future version of Git has a new implementation of
   the index (both on-disk and in-core) that lets you keep just the
   tree entry for an unmodified directory, without having to store
   any of the files and subdirectories in it.

 * All the other machinery of this imaginary future version of Git
   are aware of the fact that hidden thing is not visible, or even
   available, to your clone of the project repository.  That means
   fsck does not complain about missing object b4006c40..., push
   knows it should not consider it an error that you cannot enumerate
   and send objects that are reachable from b4006c40..., etc.

With such a Git, you can modify anything outside the parts of the
project tree that are hidden from you, and make a commit.  The tree
recorded in a new commit object would record the same

 04 tree b4006c408979a0c6261dbfaeaa36639457469ad4   hidden

for the hidden directory, and you can even push it back to update
the parts for other people to see your work outside the hidden
area.

All the other machinery that would need to accomodate such a
hidden directory would span the entire plumbing layer and
transports.  The wire protocol would need to be updated, especially
the part that determines what needs to be sent and received, which
is currently purely on commit ancestry, needs to become aware of the
paths.

I am *NOT* saying that this is easy.  I'd imagine if we gather all
the competent Gits in a room and have them work on it and doing
nothing else for six months, we would have some system that works.
It would be a lot of work.

I think it may be worth doing in the longer term, and it will likely
to have other benefits as side effects.

 - For example, did you notice that my description above does not
   mention permission even once?  Yes, that's right.  This does
   not have to be limited to permissions.  The user may have decided
   that the hidden part of that directory structure is not
   interesting and said git clone --exclude=hidden when she made
   her clone to set it up.

 - Also notice that the new implementation of the index that
   lazily expands subtrees does not say anythying about a directory
   that is hidden---it just said an unmodified directory and
   that was deliberate.  Even when you are not doing a narrow
   clone, keeping an untouched tree without expanding its subtrees
   and blobs flatted into the index may make it faster when you are
   working on a series of many small commits each of which touches
   only a handful of files.

I might agree with you that in-repo per-directory permissions make
no sense, but the reason to say so would not be because there
would be no way to generate commits.
--
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 v8 00/11] add options to for-each-ref

[Karthik Nayak]

v7 of this patch series can be found here :
http://article.gmane.org/gmane.comp.version-control.git/273233

This is a continuation of my GSoC project to unify git tag -l, git
branch -l and for-each-ref. Continued from this patch series :
http://thread.gmane.org/gmane.comp.version-control.git/271563

Changes in v8:
[04/11]: Change pertain to to points at, Grammatical change.
[05/11], [04/11]: Random spaces left in macro definition
[10/11]: Mention the movement of code from tag.c

Thanks to Matthieu Moy for suggestions on the previous versions.

-- 
Regards,
Karthik Nayak
--
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 v8 04/11] for-each-ref: add '--points-at' option

[Karthik Nayak]

Add the '--points-at' option provided by 'ref-filter'. The
option lets the user to list only refs which points at the
given object.

Add documentation and tests for the same.

Based-on-patch-by: Jeff King p...@peff.net
Mentored-by: Christian Couder christian.cou...@gmail.com
Mentored-by: Matthieu Moy matthieu@grenoble-inp.fr
Signed-off-by: Karthik Nayak karthik@gmail.com
---
 Documentation/git-for-each-ref.txt |  3 +++
 builtin/for-each-ref.c |  9 +++--
 t/t6302-for-each-ref-filter.sh | 20 
 3 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-for-each-ref.txt 
b/Documentation/git-for-each-ref.txt
index 7f8d9a5..ff0283b 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -10,6 +10,7 @@ SYNOPSIS
 [verse]
 'git for-each-ref' [--count=count] [--shell|--perl|--python|--tcl]
   [(--sort=key)...] [--format=format] [pattern...]
+  [--points-at object]
 
 DESCRIPTION
 ---
@@ -62,6 +63,8 @@ OPTIONS
the specified host language.  This is meant to produce
a scriptlet that can directly be `eval`ed.
 
+--points-at object::
+   Only list refs which points at the given object.
 
 FIELD NAMES
 ---
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index 7919206..ae5419e 100644
--- a/builtin/for-each-ref.c
+++ b/builtin/for-each-ref.c
@@ -7,6 +7,7 @@
 
 static char const * const for_each_ref_usage[] = {
N_(git for-each-ref [options] [pattern]),
+   N_(git for-each-ref [--points-at object]),
NULL
 };
 
@@ -34,9 +35,15 @@ int cmd_for_each_ref(int argc, const char **argv, const char 
*prefix)
OPT_STRING(  0 , format, format, N_(format), N_(format to 
use for the output)),
OPT_CALLBACK(0 , sort, sorting_tail, N_(key),
N_(field name to sort on), 
parse_opt_ref_sorting),
+   OPT_CALLBACK(0, points-at, filter.points_at,
+N_(object), N_(print only refs which points at 
the given object),
+parse_opt_object_name),
OPT_END(),
};
 
+   memset(array, 0, sizeof(array));
+   memset(filter, 0, sizeof(filter));
+
parse_options(argc, argv, prefix, opts, for_each_ref_usage, 0);
if (maxcount  0) {
error(invalid --count argument: `%d', maxcount);
@@ -55,8 +62,6 @@ int cmd_for_each_ref(int argc, const char **argv, const char 
*prefix)
/* for warn_ambiguous_refs */
git_config(git_default_config, NULL);
 
-   memset(array, 0, sizeof(array));
-   memset(filter, 0, sizeof(filter));
filter.name_patterns = argv;
filter_refs(array, filter, FILTER_REFS_ALL | 
FILTER_REFS_INCLUDE_BROKEN);
ref_array_sort(sorting, array);
diff --git a/t/t6302-for-each-ref-filter.sh b/t/t6302-for-each-ref-filter.sh
index 44d2f24..457991f 100755
--- a/t/t6302-for-each-ref-filter.sh
+++ b/t/t6302-for-each-ref-filter.sh
@@ -17,4 +17,24 @@ test_expect_success 'setup some history and refs' '
git update-ref refs/odd/spot master
 '
 
+test_expect_success 'filtering with --points-at' '
+   cat expect -\EOF 
+   refs/heads/master
+   refs/odd/spot
+   refs/tags/three
+   EOF
+   git for-each-ref --format=%(refname) --points-at=master actual 
+   test_cmp expect actual
+'
+
+test_expect_success 'check signed tags with --points-at' '
+   sed -e s/Z$// expect -\EOF 
+   refs/heads/side Z
+   refs/tags/four Z
+   refs/tags/signed-tag four
+   EOF
+   git for-each-ref --format=%(refname) %(*subject) --points-at=side 
actual 
+   test_cmp expect actual
+'
+
 test_done
-- 
2.4.5

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

[PATCH v8 03/11] ref-filter: implement '--points-at' option

[Karthik Nayak]

In 'tag -l' we have '--points-at' option which lets users
list only tags of a given object. Implement this option in
'ref-filter.{c,h}' so that other commands can benefit from this.

This is duplicated from tag.c, we will eventually remove that
when we port tag.c to use ref-filter APIs.

Based-on-patch-by: Jeff King p...@peff.net
Mentored-by: Christian Couder christian.cou...@gmail.com
Mentored-by: Matthieu Moy matthieu@grenoble-inp.fr
Signed-off-by: Karthik Nayak karthik@gmail.com
---
 builtin/tag.c |  4 
 ref-filter.c  | 35 +++
 ref-filter.h  |  1 +
 3 files changed, 40 insertions(+)

diff --git a/builtin/tag.c b/builtin/tag.c
index e36c43e..280981f 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -56,6 +56,10 @@ static int match_pattern(const char **patterns, const char 
*ref)
return 0;
 }
 
+/*
+ * This is currently duplicated in ref-filter.c, and will eventually be
+ * removed as we port tag.c to use the ref-filter APIs.
+ */
 static const unsigned char *match_points_at(const char *refname,
const unsigned char *sha1)
 {
diff --git a/ref-filter.c b/ref-filter.c
index c4004db..58e532c 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -842,6 +842,38 @@ static int match_name_as_path(const char **pattern, const 
char *refname)
return 0;
 }
 
+/*
+ * Given a ref (sha1, refname), check if the ref belongs to the array
+ * of sha1s. If the given ref is a tag, check if the given tag points
+ * at one of the sha1s in the given sha1 array.
+ * the given sha1_array.
+ * NEEDSWORK:
+ * 1. Only a single level of inderection is obtained, we might want to
+ * change this to account for multiple levels (e.g. annotated tags
+ * pointing to annotated tags pointing to a commit.)
+ * 2. As the refs are cached we might know what refname peels to without
+ * the need to parse the object via parse_object(). peel_ref() might be a
+ * more efficient alternative to obtain the pointee.
+ */
+static const unsigned char *match_points_at(struct sha1_array *points_at,
+   const unsigned char *sha1,
+   const char *refname)
+{
+   const unsigned char *tagged_sha1 = NULL;
+   struct object *obj;
+
+   if (sha1_array_lookup(points_at, sha1) = 0)
+   return sha1;
+   obj = parse_object(sha1);
+   if (!obj)
+   die(_(malformed object at '%s'), refname);
+   if (obj-type == OBJ_TAG)
+   tagged_sha1 = ((struct tag *)obj)-tagged-sha1;
+   if (tagged_sha1  sha1_array_lookup(points_at, tagged_sha1) = 0)
+   return tagged_sha1;
+   return NULL;
+}
+
 /* Allocate space for a new ref_array_item and copy the objectname and flag to 
it */
 static struct ref_array_item *new_ref_array_item(const char *refname,
 const unsigned char 
*objectname,
@@ -880,6 +912,9 @@ static int ref_filter_handler(const char *refname, const 
struct object_id *oid,
if (*filter-name_patterns  
!match_name_as_path(filter-name_patterns, refname))
return 0;
 
+   if (filter-points_at.nr  !match_points_at(filter-points_at, 
oid-hash, refname))
+   return 0;
+
/*
 * We do not open the object yet; sort may only need refname
 * to do its job and the resulting list may yet to be pruned
diff --git a/ref-filter.h b/ref-filter.h
index 6997984..c2856b8 100644
--- a/ref-filter.h
+++ b/ref-filter.h
@@ -42,6 +42,7 @@ struct ref_array {
 
 struct ref_filter {
const char **name_patterns;
+   struct sha1_array points_at;
 };
 
 struct ref_filter_cbdata {
-- 
2.4.5

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

Re: Subject: [PATCH] git am: Transform and skip patches via new hook

[Eric Sunshine]

On Tue, Jul 7, 2015 at 3:52 AM, Robert Collins
robe...@robertcollins.net wrote:
 From 0428b0a1248fb84c584a5a6c1f110770c6615d5e Mon Sep 17 00:00:00 2001
 From: Robert Collins rbtcoll...@hp.com
 Date: Tue, 7 Jul 2015 15:43:24 +1200
 Subject: [PATCH] git am: Transform and skip patches via new hook

Drop the From sha1, Date:, and Subject: headers. From sha1 is
meaningful only in your repository, thus not useful here, and git-am
will pluck the other information directly from your email, so they are
redundant. The From: header, however, should be kept since it
differs from your sending email address.

 A thing I need to do quite a lot of is extracting stuff from
 Python to backported libraries. This involves changing nearly
 every patch but its automatable.

 Using a new hook (applypatch-transform) was sufficient to meet all my
 needs and should be acceptable upstream as far as I can tell.

For a commit message, you want to explain the problem you're solving,
in what way the the current implementation is lacking, and justify why
your solution is desirable (possibly citing alternate approaches you
discarded). Unfortunately, the above paragraphs don't really tell us
much about why applypatch-tranforms is needed or how it solves a
problem which can't be solved with some other existing mechanism. You
do mention that it satisfies your needs, but we don't know
specifically what those are.

The above paragraphs might be perfectly suitable as additional
commentary to supplement the commit messages, however, such commentary
should be placed below the --- line under your sign-off and above
the diffstat.

 Signed-Off-By: Robert Collins rbtcoll...@hp.com

This is typically written Signed-off-by:.

More below.

 ---
  Documentation/git-am.txt |  6 ++---
  Documentation/githooks.txt   | 15 
  git-am.sh| 15 
  templates/hooks--applypatch-transform.sample | 36 
 
  4 files changed, 69 insertions(+), 3 deletions(-)
  create mode 100755 templates/hooks--applypatch-transform.sample

 diff --git a/git-am.sh b/git-am.sh
 index 8733071..796efea 100755
 --- a/git-am.sh
 +++ b/git-am.sh
 @@ -869,6 +869,21 @@ To restore the original branch and stop patching
 run \\$cmdline --abort\.

   case $resolved in
   '')
 + # Attempt to rewrite the patch.
 + hook=$(git rev-parse --git-path hooks/applypatch-transform)
 + if test -x $hook
 + then
 + $hook $dotest/patch $dotest/final-commit
 + status=$?
 + if test $status -eq 1
 + then
 + go_next
 + elif test $status -ne 0
 + then
 + stop_here $this
 + fi
 + fi

This indentation looks botched, as if the patch was pasted into your
email client and the client mangled the whitespace. git-send-email may
be of use here.

 diff --git a/templates/hooks--applypatch-transform.sample
 b/templates/hooks--applypatch-transform.sample
 new file mode 100755
 index 000..97cd789
 --- /dev/null
 +++ b/templates/hooks--applypatch-transform.sample
 @@ -0,0 +1,36 @@
 +#!/bin/sh
 +#
 +# An example hook script to transform a patch taken from an email
 +# by git am.
 +#
 +# The hook should exit with non-zero status after issuing an
 +# appropriate message if it wants to stop the commit.  The hook is
 +# allowed to edit the patch file.
 +#
 +# To enable this hook, rename this file to applypatch-transform.
 +#
 +# This example changes the path of Lib/unittest/mock.py to mock.py
 +# Lib/unittest/tests/testmock to tests and Misc/NEWS to NEWS, and
 +# finally skips any patches that did not alter mock.py or its tests.

It's not clear even from this example what applypatch-transform buys
you over simply running your patches through some transformation and
filtering script *before* feeding them to git-am. The answer to that
question is the sort of thing which should be in the commit message to
justify the patch.

 +set -eux
 +
 +patch_path=$1
 +
 +# Pull out mock.py
 +filterdiff --clean --strip 3 --addprefix=a/ -i
 'a/Lib/unittest/mock.py' $patch_path  $patch_path.mock
 +# And the tests
 +filterdiff --clean --strip 5 --addprefix=a/tests/ -i
 'a/Lib/unittest/test/testmock/' $patch_path  $patch_path.tests
 +# Lastly we want to pick up any NEWS entries.
 +filterdiff --strip 2 --addprefix=a/ -i a/Misc/NEWS $patch_path 
 $patch_path.NEWS
 +cat $patch_path.mock $patch_path.tests  $patch_path
 +filtered=$(cat $patch_path)
 +if [ -n ${filtered} ]; then
 +  cat $patch_path.NEWS  $patch_path
 +  exitcode=0
 +else
 +  exitcode=1
 +fi
 +
 +rm $patch_path.mock $patch_path.tests $patch_path.NEWS
 +exit $exitcode
 --
 2.1.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

Re: [PATCH] index-pack: fix allocation of sorted_by_pos array

[Junio C Hamano]

Duy Nguyen pclo...@gmail.com writes:

 I keep tripping over this real_type vs type in this code. What do
 you think about renaming type field to in_pack_type and
 real_type to canon_type (or final_type)? Real does not really
 say anything in this context..

An unqualified name type does bother me for the word to express
what representation the piece of data uses (i.e. is it a delta, or
is it a base object of tree type, or what).  I think I tried to
unconfuse myself by saying representation type in in-code
comments, reviews and log messages when it is not clear which kind
between in-pack representation or Git object type of that stored
data a sentence is talking about, and I agree in_pack_type would
be a vast improvement over just type.

To me personally real- and final- mean about the same thing
(i.e. what is the real type of the object that is stored?) in the
context of this codepath.

Especially, if the other one is renamed with in_pack_ prefix,
real_type is not just clear enough but is probably better because
it explains what it is from its meaning (i.e. it is the type of
the Git object, not how it is represented in the pack-stream) than
final_type that is named after how it is computed (i.e. it makes
sense to you only if you know that an in-pack type this is delta
does not have the full information and you have to traverse the
delta chain and you will finally find out what it is when you hit
the base representation).

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

Re: No one understands diff3 Temporary merge branch conflict markers

[Matthieu Moy]

Edward Anderson nil...@nilbus.com writes:

 I have the diff3 conflictstyle enabled and want to be able to
 understand how to understand its output when there are criss-cross
 merges requiring temporary merge branches.  Eg:

  HEAD
   print(A);
 ||| merged common ancestors
  Temporary merge branch 1
   print(B);
 ===
   print(C);
  feature

I guess you are seeing the result of the recursive-merge.

 The details are too advanced for this discussion, but the default
 recursive merge strategy that git uses solves the answer by
 merging a and b into a temporary commit and using *that* as the
 merge base.

That is the point. We don't have a good common ancestor, so Git builds
one by merging the common ancestors. Then, two things can happen:

* The merge of the common ancestors is conflict-free. Then, we get a
  sane common ancestor.

* The merge has conflicts. In this case, the common ancestor that Git
  built has conflict markers. It is not a big issue, since when merging
  A, B, and ancestor(A, B), the result of the merge is either A or B,
  but never comes from ancestor(A, B). So, you never get to see the
  temporary ancestor(A, B), *except* when you request the common
  ancestor in the merge conflict.

It gets nasty since you get recursive merge conflicts, but you don't see
the recursivity. Let me try to indent your conflict:

 1  HEAD
 2 unless admin
 3   fail Unauthorized.new(Admin only)
 4 end
 5 ||| merged common ancestors
 6  Temporary merge branch 1
 7 unless admin
 8   fail Unauthorized.new(Admin only)
 9 end
10 ||| merged common ancestors
11 unless admin
12   fail Unauthorized.new
13 end
14 ===
15 fail Unauthorized.new unless admin
16  Temporary merge branch 2
17 ===
18 unless admin
19 fail Unauthorized.new(Admin only)
20   fail Unauthorized.new
21 end
22  feature

 It seems lines 6-16 are a conflict that occurred when merging the
 merge-bases.

Yes.

 That conflict could be resolved by merging the change in Temporary
 merge branch 1 (add Admin only) with Temporary merge branch 2
 (convert multi-line unless to single-line) as this:

fail Unauthorized.new(Admin only) unless admin

That is probably what you would do if you resolved the conflict
manually, but while merging the common ancestors, Git found an ancestor
of an ancestor that was different from both ancestors being merged, and
there was a conflict. Asking you to resolve this conflict would be
essentially a loss of time since Git knows that the result won't appear
in the final merge, but only in the merge base.

 1  HEAD
 2 unless feature.enabled_for_user?(UserIdLookup.new(params).user_id)
 3   fail Unauthorized.new(Requires setting #{label}.)
 4 ||| merged common ancestors
 5  Temporary merge branch 1
 6 unless feature.enabled_for_user?(params[:user_id])
 7   fail Unauthorized.new(Requires setting #{label}.)
 8 ===
 9 unless feature.enabled_for_user?(params[:user_id])
10   fail Unauthorized.new(Requires setting #{label}.)
11  feature

 This is the full conflict, and it doesn't seem to balance.

Right: I guess the merge-base was stg like

 Temporary merge branch 1
unless feature.enabled_for_user?(params[:user_id])
  fail Unauthorized.new(Requires setting #{label}.)
|||
blabla 1
===
blabla 2
 Temporary merge branch 2

But then, the actual merge happens, using this as merge-base. A conflict
occurs when the commits being merged and the merge-base are all
different. In your case, I guess the commits being merged were identical
on the next different hunks (the line blablabla 1 probably was in both
commits being merged, which allowed the merge algorithm to move to the
next hunk), and there were no conflict in this hunk, hence you don't see
the merge base.

I hope this helps on the light and understanding part of your
question. Now, as of what to do when I get this?, I would say: the
recursive merge-base was computed internally, but not really meant to be
shown to the user. You should probably ignore it and resolve the merge
by looking only at the 2 sides of the conflict (ours and theirs).
Sorry, this is probably not the answer you expected, but it's the best I
can give ;-).

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

[PATCH v8 07/11] for-each-ref: add '--merged' and '--no-merged' options

[Karthik Nayak]

Add the '--merged' and '--no-merged' options provided by 'ref-filter'.
The '--merged' option lets the user to only list refs merged into the
named commit. The '--no-merged' option lets the user to only list refs
not merged into the named commit.

Add documentation and tests for the same.

Based-on-patch-by: Jeff King p...@peff.net
Mentored-by: Christian Couder christian.cou...@gmail.com
Mentored-by: Matthieu Moy matthieu@grenoble-inp.fr
Signed-off-by: Karthik Nayak karthik@gmail.com
---
 Documentation/git-for-each-ref.txt | 10 +-
 builtin/for-each-ref.c |  3 +++
 t/t6302-for-each-ref-filter.sh | 23 +++
 3 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/Documentation/git-for-each-ref.txt 
b/Documentation/git-for-each-ref.txt
index ff0283b..2842195 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -10,7 +10,7 @@ SYNOPSIS
 [verse]
 'git for-each-ref' [--count=count] [--shell|--perl|--python|--tcl]
   [(--sort=key)...] [--format=format] [pattern...]
-  [--points-at object]
+  [--points-at object] [(--merged | --no-merged) [object]]
 
 DESCRIPTION
 ---
@@ -66,6 +66,14 @@ OPTIONS
 --points-at object::
Only list refs which points at the given object.
 
+--merged [object]::
+   Only list refs whose tips are reachable from the
+   specified commit (HEAD if not specified).
+
+--no-merged [object]::
+   Only list refs whose tips are not reachable from the
+   specified commit (HEAD if not specified).
+
 FIELD NAMES
 ---
 
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index ae5419e..7521850 100644
--- a/builtin/for-each-ref.c
+++ b/builtin/for-each-ref.c
@@ -8,6 +8,7 @@
 static char const * const for_each_ref_usage[] = {
N_(git for-each-ref [options] [pattern]),
N_(git for-each-ref [--points-at object]),
+   N_(git for-each-ref [(--merged | --no-merged) [object]]),
NULL
 };
 
@@ -38,6 +39,8 @@ int cmd_for_each_ref(int argc, const char **argv, const char 
*prefix)
OPT_CALLBACK(0, points-at, filter.points_at,
 N_(object), N_(print only refs which points at 
the given object),
 parse_opt_object_name),
+   OPT_MERGED(filter, N_(print only refs that are merged)),
+   OPT_NO_MERGED(filter, N_(print only refs that are not 
merged)),
OPT_END(),
};
 
diff --git a/t/t6302-for-each-ref-filter.sh b/t/t6302-for-each-ref-filter.sh
index 457991f..73dbf53 100755
--- a/t/t6302-for-each-ref-filter.sh
+++ b/t/t6302-for-each-ref-filter.sh
@@ -37,4 +37,27 @@ test_expect_success 'check signed tags with --points-at' '
test_cmp expect actual
 '
 
+test_expect_success 'filtering with --merged' '
+   cat expect -\EOF 
+   refs/heads/master
+   refs/odd/spot
+   refs/tags/one
+   refs/tags/three
+   refs/tags/two
+   EOF
+   git for-each-ref --format=%(refname) --merged=master actual 
+   test_cmp expect actual
+'
+
+test_expect_success 'filtering with --no-merged' '
+   cat expect -\EOF 
+   refs/heads/side
+   refs/tags/double-tag
+   refs/tags/four
+   refs/tags/signed-tag
+   EOF
+   git for-each-ref --format=%(refname) --no-merged=master actual 
+   test_cmp expect actual
+'
+
 test_done
-- 
2.4.5

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

[PATCH v8 08/11] parse-option: rename parse_opt_with_commit()

[Karthik Nayak]

Rename parse_opt_with_commit() to parse_opt_commits() to show
that it can be used to obtain a list of commits and is not
constricted to usage of '--contains' option.

Mentored-by: Christian Couder christian.cou...@gmail.com
Mentored-by: Matthieu Moy matthieu@grenoble-inp.fr
Signed-off-by: Karthik Nayak karthik@gmail.com
---
 builtin/branch.c   | 4 ++--
 builtin/tag.c  | 4 ++--
 parse-options-cb.c | 2 +-
 parse-options.h| 2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/builtin/branch.c b/builtin/branch.c
index e63102e..ae9a0eb 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -832,13 +832,13 @@ int cmd_branch(int argc, const char **argv, const char 
*prefix)
OPTION_CALLBACK, 0, contains, with_commit, 
N_(commit),
N_(print only branches that contain the commit),
PARSE_OPT_LASTARG_DEFAULT,
-   parse_opt_with_commit, (intptr_t)HEAD,
+   parse_opt_commits, (intptr_t)HEAD,
},
{
OPTION_CALLBACK, 0, with, with_commit, N_(commit),
N_(print only branches that contain the commit),
PARSE_OPT_HIDDEN | PARSE_OPT_LASTARG_DEFAULT,
-   parse_opt_with_commit, (intptr_t) HEAD,
+   parse_opt_commits, (intptr_t) HEAD,
},
OPT__ABBREV(abbrev),
 
diff --git a/builtin/tag.c b/builtin/tag.c
index 280981f..7af45a0 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -603,13 +603,13 @@ int cmd_tag(int argc, const char **argv, const char 
*prefix)
OPTION_CALLBACK, 0, contains, with_commit, 
N_(commit),
N_(print only tags that contain the commit),
PARSE_OPT_LASTARG_DEFAULT,
-   parse_opt_with_commit, (intptr_t)HEAD,
+   parse_opt_commits, (intptr_t)HEAD,
},
{
OPTION_CALLBACK, 0, with, with_commit, N_(commit),
N_(print only tags that contain the commit),
PARSE_OPT_HIDDEN | PARSE_OPT_LASTARG_DEFAULT,
-   parse_opt_with_commit, (intptr_t)HEAD,
+   parse_opt_commits, (intptr_t)HEAD,
},
{
OPTION_CALLBACK, 0, points-at, points_at, 
N_(object),
diff --git a/parse-options-cb.c b/parse-options-cb.c
index de75411..632f10f 100644
--- a/parse-options-cb.c
+++ b/parse-options-cb.c
@@ -77,7 +77,7 @@ int parse_opt_verbosity_cb(const struct option *opt, const 
char *arg,
return 0;
 }
 
-int parse_opt_with_commit(const struct option *opt, const char *arg, int unset)
+int parse_opt_commits(const struct option *opt, const char *arg, int unset)
 {
unsigned char sha1[20];
struct commit *commit;
diff --git a/parse-options.h b/parse-options.h
index 1478818..583690c 100644
--- a/parse-options.h
+++ b/parse-options.h
@@ -224,7 +224,7 @@ extern int parse_opt_expiry_date_cb(const struct option *, 
const char *, int);
 extern int parse_opt_color_flag_cb(const struct option *, const char *, int);
 extern int parse_opt_verbosity_cb(const struct option *, const char *, int);
 extern int parse_opt_object_name(const struct option *, const char *, int);
-extern int parse_opt_with_commit(const struct option *, const char *, int);
+extern int parse_opt_commits(const struct option *, const char *, int);
 extern int parse_opt_tertiary(const struct option *, const char *, int);
 extern int parse_opt_string_list(const struct option *, const char *, int);
 extern int parse_opt_noop_cb(const struct option *, const char *, int);
-- 
2.4.5

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

[PATCH v8 06/11] ref-filter: implement '--merged' and '--no-merged' options

[Karthik Nayak]

In 'branch -l' we have '--merged' option which only lists refs (branches)
merged into the named commit and '--no-merged' option which only lists
refs (branches) not merged into the named commit. Implement these two
options in ref-filter.{c,h} so that other commands can benefit from this.

Based-on-patch-by: Jeff King p...@peff.net
Mentored-by: Christian Couder christian.cou...@gmail.com
Mentored-by: Matthieu Moy matthieu@grenoble-inp.fr
Signed-off-by: Karthik Nayak karthik@gmail.com
---
 builtin/branch.c |  4 
 ref-filter.c | 73 
 ref-filter.h |  8 +++
 3 files changed, 81 insertions(+), 4 deletions(-)

diff --git a/builtin/branch.c b/builtin/branch.c
index ddd90e6..e63102e 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -635,6 +635,10 @@ static int print_ref_list(int kinds, int detached, int 
verbose, int abbrev, stru
cb.pattern = pattern;
cb.ret = 0;
for_each_rawref(append_ref, cb);
+   /*
+* The following implementation is currently duplicated in ref-filter. 
It
+* will eventually be removed when we port branch.c to use ref-filter 
APIs.
+*/
if (merge_filter != NO_FILTER) {
struct commit *filter;
filter = lookup_commit_reference_gently(merge_filter_ref, 0);
diff --git a/ref-filter.c b/ref-filter.c
index b4753ab..148b7cd 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -9,6 +9,7 @@
 #include tag.h
 #include quote.h
 #include ref-filter.h
+#include revision.h
 
 typedef enum { FIELD_STR, FIELD_ULONG, FIELD_TIME } cmp_type;
 
@@ -898,6 +899,7 @@ static int ref_filter_handler(const char *refname, const 
struct object_id *oid,
struct ref_filter_cbdata *ref_cbdata = cb_data;
struct ref_filter *filter = ref_cbdata-filter;
struct ref_array_item *ref;
+   struct commit *commit = NULL;
 
if (flag  REF_BAD_NAME) {
  warning(ignoring ref with broken name %s, refname);
@@ -916,11 +918,23 @@ static int ref_filter_handler(const char *refname, const 
struct object_id *oid,
return 0;
 
/*
+* A merge filter is applied on refs pointing to commits. Hence
+* obtain the commit using the 'oid' available and discard all
+* non-commits early. The actual filtering is done later.
+*/
+   if (filter-merge_commit) {
+   commit = lookup_commit_reference_gently(oid-hash, 1);
+   if (!commit)
+   return 0;
+   }
+
+   /*
 * We do not open the object yet; sort may only need refname
 * to do its job and the resulting list may yet to be pruned
 * by maxcount logic.
 */
ref = new_ref_array_item(refname, oid-hash, flag);
+   ref-commit = commit;
 
REALLOC_ARRAY(ref_cbdata-array-items, ref_cbdata-array-nr + 1);
ref_cbdata-array-items[ref_cbdata-array-nr++] = ref;
@@ -946,6 +960,50 @@ void ref_array_clear(struct ref_array *array)
array-nr = array-alloc = 0;
 }
 
+static void do_merge_filter(struct ref_filter_cbdata *ref_cbdata)
+{
+   struct rev_info revs;
+   int i, old_nr;
+   struct ref_filter *filter = ref_cbdata-filter;
+   struct ref_array *array = ref_cbdata-array;
+   struct commit **to_clear = xcalloc(sizeof(struct commit *), array-nr);
+
+   init_revisions(revs, NULL);
+
+   for (i = 0; i  array-nr; i++) {
+   struct ref_array_item *item = array-items[i];
+   add_pending_object(revs, item-commit-object, item-refname);
+   to_clear[i] = item-commit;
+   }
+
+   filter-merge_commit-object.flags |= UNINTERESTING;
+   add_pending_object(revs, filter-merge_commit-object, );
+
+   revs.limited = 1;
+   if (prepare_revision_walk(revs))
+   die(_(revision walk setup failed));
+
+   old_nr = array-nr;
+   array-nr = 0;
+
+   for (i = 0; i  old_nr; i++) {
+   struct ref_array_item *item = array-items[i];
+   struct commit *commit = item-commit;
+
+   int is_merged = !!(commit-object.flags  UNINTERESTING);
+
+   if (is_merged == (filter-merge == REF_FILTER_MERGED_INCLUDE))
+   array-items[array-nr++] = array-items[i];
+   else
+   free_array_item(item);
+   }
+
+   for (i = 0; i  old_nr; i++)
+   clear_commit_marks(to_clear[i], ALL_REV_FLAGS);
+   clear_commit_marks(filter-merge_commit, ALL_REV_FLAGS);
+   free(to_clear);
+}
+
 /*
  * API for filtering a set of refs. Based on the type of refs the user
  * has requested, we iterate through those refs and apply filters
@@ -955,17 +1013,24 @@ void ref_array_clear(struct ref_array *array)
 int filter_refs(struct ref_array *array, struct ref_filter *filter, unsigned 
int type)
 {
struct ref_filter_cbdata ref_cbdata;
+   int ret = 0;
 

[PATCH v8 09/11] parse-options.h: add macros for '--contains' option

[Karthik Nayak]

Add a macro for using the '--contains' option in parse-options.h
also include an optional '--with' option macro which performs the
same action as '--contains'.

Make tag.c and branch.c use this new macro.

Mentored-by: Christian Couder christian.cou...@gmail.com
Mentored-by: Matthieu Moy matthieu@grenoble-inp.fr
Signed-off-by: Karthik Nayak karthik@gmail.com
---
 builtin/branch.c | 14 ++
 builtin/tag.c| 14 ++
 parse-options.h  |  7 +++
 3 files changed, 11 insertions(+), 24 deletions(-)

diff --git a/builtin/branch.c b/builtin/branch.c
index ae9a0eb..c443cd8 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -828,18 +828,8 @@ int cmd_branch(int argc, const char **argv, const char 
*prefix)
OPT__COLOR(branch_use_color, N_(use colored output)),
OPT_SET_INT('r', remotes, kinds, N_(act on 
remote-tracking branches),
REF_REMOTE_BRANCH),
-   {
-   OPTION_CALLBACK, 0, contains, with_commit, 
N_(commit),
-   N_(print only branches that contain the commit),
-   PARSE_OPT_LASTARG_DEFAULT,
-   parse_opt_commits, (intptr_t)HEAD,
-   },
-   {
-   OPTION_CALLBACK, 0, with, with_commit, N_(commit),
-   N_(print only branches that contain the commit),
-   PARSE_OPT_HIDDEN | PARSE_OPT_LASTARG_DEFAULT,
-   parse_opt_commits, (intptr_t) HEAD,
-   },
+   OPT_CONTAINS(with_commit, N_(print only branches that contain 
the commit)),
+   OPT_WITH(with_commit, N_(print only branches that contain the 
commit)),
OPT__ABBREV(abbrev),
 
OPT_GROUP(N_(Specific git-branch actions:)),
diff --git a/builtin/tag.c b/builtin/tag.c
index 7af45a0..767162e 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -595,23 +595,13 @@ int cmd_tag(int argc, const char **argv, const char 
*prefix)
 
OPT_GROUP(N_(Tag listing options)),
OPT_COLUMN(0, column, colopts, N_(show tag list in 
columns)),
+   OPT_CONTAINS(with_commit, N_(print only tags that contain the 
commit)),
+   OPT_WITH(with_commit, N_(print only tags that contain the 
commit)),
{
OPTION_CALLBACK, 0, sort, tag_sort, N_(type), 
N_(sort tags),
PARSE_OPT_NONEG, parse_opt_sort
},
{
-   OPTION_CALLBACK, 0, contains, with_commit, 
N_(commit),
-   N_(print only tags that contain the commit),
-   PARSE_OPT_LASTARG_DEFAULT,
-   parse_opt_commits, (intptr_t)HEAD,
-   },
-   {
-   OPTION_CALLBACK, 0, with, with_commit, N_(commit),
-   N_(print only tags that contain the commit),
-   PARSE_OPT_HIDDEN | PARSE_OPT_LASTARG_DEFAULT,
-   parse_opt_commits, (intptr_t)HEAD,
-   },
-   {
OPTION_CALLBACK, 0, points-at, points_at, 
N_(object),
N_(print only tags of the object), 0, 
parse_opt_object_name
},
diff --git a/parse-options.h b/parse-options.h
index 583690c..7ea22b2 100644
--- a/parse-options.h
+++ b/parse-options.h
@@ -246,5 +246,12 @@ extern int parse_opt_noop_cb(const struct option *, const 
char *, int);
OPT_COLOR_FLAG(0, color, (var), (h))
 #define OPT_COLUMN(s, l, v, h) \
{ OPTION_CALLBACK, (s), (l), (v), N_(style), (h), PARSE_OPT_OPTARG, 
parseopt_column_callback }
+#define _OPT_CONTAINS_OR_WITH(name, variable, help, flag) \
+   { OPTION_CALLBACK, 0, name, (variable), N_(commit), (help), \
+ PARSE_OPT_LASTARG_DEFAULT | flag, \
+ parse_opt_commits, (intptr_t) HEAD \
+   }
+#define OPT_CONTAINS(v, h) _OPT_CONTAINS_OR_WITH(contains, v, h, 0)
+#define OPT_WITH(v, h) _OPT_CONTAINS_OR_WITH(with, v, h, PARSE_OPT_HIDDEN)
 
 #endif
-- 
2.4.5

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

[PATCH v8 10/11] ref-filter: implement '--contains' option

[Karthik Nayak]

'tag -l' and 'branch -l' have two different ways of finding
out if a certain ref contains a commit. Implement both these
methods in ref-filter and give the caller of ref-filter API
the option to pick which implementation to be used.

'branch -l' uses 'is_descendant_of()' from commit.c which is
left as the default implementation to be used.

'tag -l' uses a more specific algorithm since ffc4b80. This
implementation is used whenever the 'with_commit_tag_algo' bit
is set in 'struct ref_filter'.

Mentored-by: Christian Couder christian.cou...@gmail.com
Mentored-by: Matthieu Moy matthieu@grenoble-inp.fr
Signed-off-by: Karthik Nayak karthik@gmail.com
---
 builtin/tag.c |   5 +++
 ref-filter.c  | 114 +-
 ref-filter.h  |   3 ++
 3 files changed, 121 insertions(+), 1 deletion(-)

diff --git a/builtin/tag.c b/builtin/tag.c
index 767162e..071d001 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -86,6 +86,11 @@ static int in_commit_list(const struct commit_list *want, 
struct commit *c)
return 0;
 }
 
+/*
+ * The entire code segment for supporting the --contains option has been
+ * copied over to ref-filter.{c,h}. This will be deleted evetually when
+ * we port tag.c to use ref-filter APIs.
+ */
 enum contains_result {
CONTAINS_UNKNOWN = -1,
CONTAINS_NO = 0,
diff --git a/ref-filter.c b/ref-filter.c
index 148b7cd..dd0709d 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -818,6 +818,114 @@ static void get_ref_atom_value(struct ref_array_item 
*ref, int atom, struct atom
*v = ref-value[atom];
 }
 
+enum contains_result {
+   CONTAINS_UNKNOWN = -1,
+   CONTAINS_NO = 0,
+   CONTAINS_YES = 1
+};
+
+/*
+ * Mimicking the real stack, this stack lives on the heap, avoiding stack
+ * overflows.
+ *
+ * At each recursion step, the stack items points to the commits whose
+ * ancestors are to be inspected.
+ */
+struct contains_stack {
+   int nr, alloc;
+   struct contains_stack_entry {
+   struct commit *commit;
+   struct commit_list *parents;
+   } *contains_stack;
+};
+
+static int in_commit_list(const struct commit_list *want, struct commit *c)
+{
+   for (; want; want = want-next)
+   if (!hashcmp(want-item-object.sha1, c-object.sha1))
+   return 1;
+   return 0;
+}
+
+/*
+ * Test whether the candidate or one of its parents is contained in the list.
+ * Do not recurse to find out, though, but return -1 if inconclusive.
+ */
+static enum contains_result contains_test(struct commit *candidate,
+   const struct commit_list *want)
+{
+   /* was it previously marked as containing a want commit? */
+   if (candidate-object.flags  TMP_MARK)
+   return 1;
+   /* or marked as not possibly containing a want commit? */
+   if (candidate-object.flags  UNINTERESTING)
+   return 0;
+   /* or are we it? */
+   if (in_commit_list(want, candidate)) {
+   candidate-object.flags |= TMP_MARK;
+   return 1;
+   }
+
+   if (parse_commit(candidate)  0)
+   return 0;
+
+   return -1;
+}
+
+static void push_to_contains_stack(struct commit *candidate, struct 
contains_stack *contains_stack)
+{
+   ALLOC_GROW(contains_stack-contains_stack, contains_stack-nr + 1, 
contains_stack-alloc);
+   contains_stack-contains_stack[contains_stack-nr].commit = candidate;
+   contains_stack-contains_stack[contains_stack-nr++].parents = 
candidate-parents;
+}
+
+static enum contains_result contains_tag_algo(struct commit *candidate,
+   const struct commit_list *want)
+{
+   struct contains_stack contains_stack = { 0, 0, NULL };
+   int result = contains_test(candidate, want);
+
+   if (result != CONTAINS_UNKNOWN)
+   return result;
+
+   push_to_contains_stack(candidate, contains_stack);
+   while (contains_stack.nr) {
+   struct contains_stack_entry *entry = 
contains_stack.contains_stack[contains_stack.nr - 1];
+   struct commit *commit = entry-commit;
+   struct commit_list *parents = entry-parents;
+
+   if (!parents) {
+   commit-object.flags |= UNINTERESTING;
+   contains_stack.nr--;
+   }
+   /*
+* If we just popped the stack, parents-item has been marked,
+* therefore contains_test will return a meaningful 0 or 1.
+*/
+   else switch (contains_test(parents-item, want)) {
+   case CONTAINS_YES:
+   commit-object.flags |= TMP_MARK;
+   contains_stack.nr--;
+   break;
+   case CONTAINS_NO:
+   entry-parents = parents-next;
+   break;
+   case CONTAINS_UNKNOWN:
+   

[PATCH v8 11/11] for-each-ref: add '--contains' option

[Karthik Nayak]

Add the '--contains' option provided by 'ref-filter'. The '--contains'
option lists only refs which contain the mentioned commit (HEAD if no
commit is explicitly given).

Add documentation and tests for the same.

Mentored-by: Christian Couder christian.cou...@gmail.com
Mentored-by: Matthieu Moy matthieu@grenoble-inp.fr
Signed-off-by: Karthik Nayak karthik@gmail.com
---
 Documentation/git-for-each-ref.txt |  5 +
 builtin/for-each-ref.c |  2 ++
 t/t6302-for-each-ref-filter.sh | 15 +++
 3 files changed, 22 insertions(+)

diff --git a/Documentation/git-for-each-ref.txt 
b/Documentation/git-for-each-ref.txt
index 2842195..e49d578 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -11,6 +11,7 @@ SYNOPSIS
 'git for-each-ref' [--count=count] [--shell|--perl|--python|--tcl]
   [(--sort=key)...] [--format=format] [pattern...]
   [--points-at object] [(--merged | --no-merged) [object]]
+  [--contains [object]]
 
 DESCRIPTION
 ---
@@ -74,6 +75,10 @@ OPTIONS
Only list refs whose tips are not reachable from the
specified commit (HEAD if not specified).
 
+--contains [object]::
+   Only list tags which contain the specified commit (HEAD if not
+   specified).
+
 FIELD NAMES
 ---
 
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index 7521850..40f343b 100644
--- a/builtin/for-each-ref.c
+++ b/builtin/for-each-ref.c
@@ -9,6 +9,7 @@ static char const * const for_each_ref_usage[] = {
N_(git for-each-ref [options] [pattern]),
N_(git for-each-ref [--points-at object]),
N_(git for-each-ref [(--merged | --no-merged) [object]]),
+   N_(git for-each-ref [--contains [object]]),
NULL
 };
 
@@ -41,6 +42,7 @@ int cmd_for_each_ref(int argc, const char **argv, const char 
*prefix)
 parse_opt_object_name),
OPT_MERGED(filter, N_(print only refs that are merged)),
OPT_NO_MERGED(filter, N_(print only refs that are not 
merged)),
+   OPT_CONTAINS(filter.with_commit, N_(print only refs which 
contain the commit)),
OPT_END(),
};
 
diff --git a/t/t6302-for-each-ref-filter.sh b/t/t6302-for-each-ref-filter.sh
index 73dbf53..9969a08 100755
--- a/t/t6302-for-each-ref-filter.sh
+++ b/t/t6302-for-each-ref-filter.sh
@@ -60,4 +60,19 @@ test_expect_success 'filtering with --no-merged' '
test_cmp expect actual
 '
 
+test_expect_success 'filtering with --contains' '
+   cat expect -\EOF 
+   refs/heads/master
+   refs/heads/side
+   refs/odd/spot
+   refs/tags/double-tag
+   refs/tags/four
+   refs/tags/signed-tag
+   refs/tags/three
+   refs/tags/two
+   EOF
+   git for-each-ref --format=%(refname) --contains=two actual 
+   test_cmp expect actual
+'
+
 test_done
-- 
2.4.5

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

Re: refspecs with '*' as part of pattern

[Junio C Hamano]

Daniel Barkalow barka...@iabervon.iabervon.org writes:

 On Mon, 6 Jul 2015, Junio C Hamano wrote:

 I cannot seem to be able to find related discussions around that
 patch, so this is only my guess, but I suspect that this is to
 discourage people from doing something like:
 
  refs/tags/*:refs/tags/foo-*
 
 which would open can of worms (e.g. imagine you fetch with that
 pathspec and then push with refs/tags/*:refs/tags/* back there;
 would you now get foo-v1.0.0 and foo-foo-v1.0.0 for their v1.0.0
 tag?) we'd prefer not having to worry about.

 That wouldn't be it, since refs/tags/*:refs/tags/foo/* would have the same 
 problem, assuming you didn't set up the push refspec carefully.

Thanks, I was wondering where you were ;-)  Nice to hear from you
from time to time.

 I think it was mostly that it would be too easy to accidentally do 
 something you don't want by having some other character instead of a 
 slash, like refs/heads/*:refs/heads-*.

Hmm, interesting thought.

But refs/heads/*:refs/heade/* would not be saved, so I do not think
that is it, either.
--
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: No one understands diff3 Temporary merge branch conflict markers

[Junio C Hamano]

Matthieu Moy matthieu@grenoble-inp.fr writes:

 ... I would say: the
 recursive merge-base was computed internally, but not really meant to be
 shown to the user.

I wonder if the output becomes easier to read if we unconditionally
turned off diff3-style for inner merges.
--
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] index-pack: fix allocation of sorted_by_pos array

[Jeff King]

On Tue, Jul 07, 2015 at 08:49:19AM -0700, Junio C Hamano wrote:

 Duy Nguyen pclo...@gmail.com writes:
 
  I keep tripping over this real_type vs type in this code. What do
  you think about renaming type field to in_pack_type and
  real_type to canon_type (or final_type)? Real does not really
  say anything in this context..
 
 An unqualified name type does bother me for the word to express
 what representation the piece of data uses (i.e. is it a delta, or
 is it a base object of tree type, or what).  I think I tried to
 unconfuse myself by saying representation type in in-code
 comments, reviews and log messages when it is not clear which kind
 between in-pack representation or Git object type of that stored
 data a sentence is talking about, and I agree in_pack_type would
 be a vast improvement over just type.

I think this is doubly confusing because pack-objects _does_ use
in_pack_type. And its type is therefore the real object type. Which
is the opposite of index-pack, which uses type for the in-pack type.
So at the very least, we should harmonize these two uses.

 Especially, if the other one is renamed with in_pack_ prefix,
 real_type is not just clear enough but is probably better because
 it explains what it is from its meaning (i.e. it is the type of
 the Git object, not how it is represented in the pack-stream) than
 final_type that is named after how it is computed (i.e. it makes
 sense to you only if you know that an in-pack type this is delta
 does not have the full information and you have to traverse the
 delta chain and you will finally find out what it is when you hit
 the base representation).

Yeah, I agree real_type is fine when paired with in_pack_type. We might
consider modifying pack-objects.h to match (on top of just moving
index-pack to in_pack_type).

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

[PATCH v8 01/11] t6302: for-each-ref tests for ref-filter APIs

[Karthik Nayak]

Add a test suite for testing the ref-filter APIs used
by for-each-ref. We just intialize the test suite for now.
More tests will be added in the following patches as more
options are added to for-each-ref.

Based-on-patch-by: Jeff King p...@peff.net
Mentored-by: Christian Couder christian.cou...@gmail.com
Mentored-by: Matthieu Moy matthieu@grenoble-inp.fr
Signed-off-by: Karthik Nayak karthik@gmail.com
---
 t/t6302-for-each-ref-filter.sh | 20 
 1 file changed, 20 insertions(+)
 create mode 100755 t/t6302-for-each-ref-filter.sh

diff --git a/t/t6302-for-each-ref-filter.sh b/t/t6302-for-each-ref-filter.sh
new file mode 100755
index 000..44d2f24
--- /dev/null
+++ b/t/t6302-for-each-ref-filter.sh
@@ -0,0 +1,20 @@
+#!/bin/sh
+
+test_description='test for-each-refs usage of ref-filter APIs'
+
+. ./test-lib.sh
+. $TEST_DIRECTORY/lib-gpg.sh
+
+test_expect_success 'setup some history and refs' '
+   test_commit one 
+   test_commit two 
+   test_commit three 
+   git checkout -b side 
+   test_commit four 
+   git tag -s -m A signed tag message signed-tag 
+   git tag -s -m Annonated doubly double-tag signed-tag 
+   git checkout master 
+   git update-ref refs/odd/spot master
+'
+
+test_done
-- 
2.4.5

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

[PATCH v8 02/11] tag: libify parse_opt_points_at()

[Karthik Nayak]

Rename 'parse_opt_points_at()' to 'parse_opt_object_name()' and
move it from 'tag.c' to 'parse-options'. This now acts as a common
parse_opt function which accepts an objectname and stores it into
a sha1_array.

Based-on-patch-by: Jeff King p...@peff.net
Mentored-by: Christian Couder christian.cou...@gmail.com
Mentored-by: Matthieu Moy matthieu@grenoble-inp.fr
Signed-off-by: Karthik Nayak karthik@gmail.com
---
 builtin/tag.c  | 21 ++---
 parse-options-cb.c | 17 +
 parse-options.h|  1 +
 3 files changed, 20 insertions(+), 19 deletions(-)

diff --git a/builtin/tag.c b/builtin/tag.c
index 5f6cdc5..e36c43e 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -546,23 +546,6 @@ static int strbuf_check_tag_ref(struct strbuf *sb, const 
char *name)
return check_refname_format(sb-buf, 0);
 }
 
-static int parse_opt_points_at(const struct option *opt 
__attribute__((unused)),
-   const char *arg, int unset)
-{
-   unsigned char sha1[20];
-
-   if (unset) {
-   sha1_array_clear(points_at);
-   return 0;
-   }
-   if (!arg)
-   return error(_(switch 'points-at' requires an object));
-   if (get_sha1(arg, sha1))
-   return error(_(malformed object name '%s'), arg);
-   sha1_array_append(points_at, sha1);
-   return 0;
-}
-
 static int parse_opt_sort(const struct option *opt, const char *arg, int unset)
 {
int *sort = opt-value;
@@ -625,8 +608,8 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
parse_opt_with_commit, (intptr_t)HEAD,
},
{
-   OPTION_CALLBACK, 0, points-at, NULL, N_(object),
-   N_(print only tags of the object), 0, 
parse_opt_points_at
+   OPTION_CALLBACK, 0, points-at, points_at, 
N_(object),
+   N_(print only tags of the object), 0, 
parse_opt_object_name
},
OPT_END()
};
diff --git a/parse-options-cb.c b/parse-options-cb.c
index be8c413..de75411 100644
--- a/parse-options-cb.c
+++ b/parse-options-cb.c
@@ -4,6 +4,7 @@
 #include commit.h
 #include color.h
 #include string-list.h
+#include sha1-array.h
 
 /*- some often used options -*/
 
@@ -92,6 +93,22 @@ int parse_opt_with_commit(const struct option *opt, const 
char *arg, int unset)
return 0;
 }
 
+int parse_opt_object_name(const struct option *opt, const char *arg, int unset)
+{
+   unsigned char sha1[20];
+
+   if (unset) {
+   sha1_array_clear(opt-value);
+   return 0;
+   }
+   if (!arg)
+   return -1;
+   if (get_sha1(arg, sha1))
+   return error(_(malformed object name '%s'), arg);
+   sha1_array_append(opt-value, sha1);
+   return 0;
+}
+
 int parse_opt_tertiary(const struct option *opt, const char *arg, int unset)
 {
int *target = opt-value;
diff --git a/parse-options.h b/parse-options.h
index ca865f6..1478818 100644
--- a/parse-options.h
+++ b/parse-options.h
@@ -223,6 +223,7 @@ extern int parse_opt_approxidate_cb(const struct option *, 
const char *, int);
 extern int parse_opt_expiry_date_cb(const struct option *, const char *, int);
 extern int parse_opt_color_flag_cb(const struct option *, const char *, int);
 extern int parse_opt_verbosity_cb(const struct option *, const char *, int);
+extern int parse_opt_object_name(const struct option *, const char *, int);
 extern int parse_opt_with_commit(const struct option *, const char *, int);
 extern int parse_opt_tertiary(const struct option *, const char *, int);
 extern int parse_opt_string_list(const struct option *, const char *, int);
-- 
2.4.5

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

Re: Git grep does not support multi-byte characters (like UTF-8)

[Junio C Hamano]

Plamen Totev plamen.to...@abv.bg writes:

 pickaxe search also uses kwsearch so the case insensitive search with
 it does not work (e.g. git log -i -S).  Maybe this is a less of a
 problem here as one is expected to search for exact string (hence
 knows the case)

You reasoned correctly, I think.  Pickaxe, as one of the building
blocks to implement Linus's ultimate change tracking tool [*1*],
should never pay attention to -i.  It is a step to finding the
commit that touches the exact code block given (i.e. how do you
drill down? part of $gmane/217 message).

Thanks.

[Footnote]
*1* http://article.gmane.org/gmane.comp.version-control.git/217
--
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 v8 05/11] ref-filter: add parse_opt_merge_filter()

[Karthik Nayak]

Add 'parse_opt_merge_filter()' to parse '--merged' and '--no-merged'
options and write macros for the same.

This is copied from 'builtin/branch.c' which will eventually be removed
when we port 'branch.c' to use ref-filter APIs.

Based-on-patch-by: Jeff King p...@peff.net
Mentored-by: Christian Couder christian.cou...@gmail.com
Mentored-by: Matthieu Moy matthieu@grenoble-inp.fr
Signed-off-by: Karthik Nayak karthik@gmail.com
---
 builtin/branch.c |  4 
 ref-filter.c | 19 +++
 ref-filter.h | 11 +++
 3 files changed, 34 insertions(+)

diff --git a/builtin/branch.c b/builtin/branch.c
index b42e5b6..ddd90e6 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -745,6 +745,10 @@ static void rename_branch(const char *oldname, const char 
*newname, int force)
strbuf_release(newsection);
 }
 
+/*
+ * This function is duplicated in ref-filter. It will eventually be removed
+ * when we port branch.c to use ref-filter APIs.
+ */
 static int opt_parse_merge_filter(const struct option *opt, const char *arg, 
int unset)
 {
merge_filter = ((opt-long_name[0] == 'n')
diff --git a/ref-filter.c b/ref-filter.c
index 58e532c..b4753ab 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -1139,3 +1139,22 @@ int parse_opt_ref_sorting(const struct option *opt, 
const char *arg, int unset)
s-atom = parse_ref_filter_atom(arg, arg+len);
return 0;
 }
+
+int parse_opt_merge_filter(const struct option *opt, const char *arg, int 
unset)
+{
+   struct ref_filter *rf = opt-value;
+   unsigned char sha1[20];
+
+   rf-merge = starts_with(opt-long_name, no)
+   ? REF_FILTER_MERGED_OMIT
+   : REF_FILTER_MERGED_INCLUDE;
+
+   if (get_sha1(arg, sha1))
+   die(_(malformed object name %s), arg);
+
+   rf-merge_commit = lookup_commit_reference_gently(sha1, 0);
+   if (!rf-merge_commit)
+   return opterror(opt, must point to a commit, 0);
+
+   return 0;
+}
diff --git a/ref-filter.h b/ref-filter.h
index c2856b8..443cfa7 100644
--- a/ref-filter.h
+++ b/ref-filter.h
@@ -50,6 +50,15 @@ struct ref_filter_cbdata {
struct ref_filter *filter;
 };
 
+/*  Macros for checking --merged and --no-merged options */
+#define _OPT_MERGED_NO_MERGED(option, filter, h) \
+   { OPTION_CALLBACK, 0, option, (filter), N_(commit), (h), \
+ PARSE_OPT_LASTARG_DEFAULT | PARSE_OPT_NONEG, \
+ parse_opt_merge_filter, (intptr_t) HEAD \
+   }
+#define OPT_MERGED(f, h) _OPT_MERGED_NO_MERGED(merged, f, h)
+#define OPT_NO_MERGED(f, h) _OPT_MERGED_NO_MERGED(no-merged, f, h)
+
 /*
  * API for filtering a set of refs. Based on the type of refs the user
  * has requested, we iterate through those refs and apply filters
@@ -71,5 +80,7 @@ void show_ref_array_item(struct ref_array_item *info, const 
char *format, int qu
 int parse_opt_ref_sorting(const struct option *opt, const char *arg, int 
unset);
 /*  Default sort option based on refname */
 struct ref_sorting *ref_default_sorting(void);
+/*  Function to parse --merged and --no-merged options */
+int parse_opt_merge_filter(const struct option *opt, const char *arg, int 
unset);
 
 #endif /*  REF_FILTER_H  */
-- 
2.4.5

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

Re: [PATCH 02/12] t4150: am fails if index is dirty

[Paul Tan]

On Sun, Jul 5, 2015 at 11:38 PM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
 On 2015-07-02 20:16, Paul Tan wrote:

 diff --git a/t/t4150-am.sh b/t/t4150-am.sh
 index 3f54bdf..0a19136 100755
 --- a/t/t4150-am.sh
 +++ b/t/t4150-am.sh
 @@ -154,6 +154,17 @@ test_expect_success 'am applies patch correctly' '
   test $(git rev-parse second^) = $(git rev-parse HEAD^)
  '

 +test_expect_success 'am fails if index is dirty' '
 + test_when_finished rm -fr dirtyfile 

 Seeing as you `git add` that file further down, how about `git rm -f 
 dirtfile` here?

But git rm -f would fail if the file is not in the index, no? (Which
could happen if the git-reset or git-checkout fails) Anyway, the
purpose of the rm -f is to remove the dirtyfile, and not to clean up
the index (we would use git reset --hard for that).

(But yeah, I see that Junio noticed correctly that it should not be a
rm -fr, but a rm -f instead.)

Thanks,
Paul
--
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: undocumented core.sharedRepository=2 set by git init --shared=world

[Torsten Bögershausen]

On 2015-07-06 21.25, Joey Hess wrote:
 joey@darkstar:~/tmpgit init --shared=world testrepo
 Initialized empty shared Git repository in /home/joey/tmp/testrepo/.git/
 joey@darkstar:~/tmpgrep shared testrepo/.git/config 
   sharedrepository = 2
 
 This magic value of 2 seems to be undocumented, as is the magic value of 1
 that's equvilant to group.
 
 I think it would be better to have git init put in world or group and not
 these magic values. 
Thanks for the report.
Changing the behavior of Git may cause problems with
- older versions of Git
- Other implementations of Git, like JGit, libgit2, ...

Did you check what these implementations do ?

Anyway, I suppose they ought to be documented too.
 
Yes.
Do you want to send a patch ?

--
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: Whether Git supports directory level access or not?

[Torsten Bögershausen]

On 07.07.15 08:40, saur...@stockal.com wrote:
 Hi,
 
 Please let me know whether Git supports directory level access or not.
 
 For example :- Consider the structure with one repository consisting of sub 
 directories for each product.
 main_repo:
dir1 dir
dir2 dir
shared-dir dir
private dir
 One group(user) of developers has access to dir1 and shared-dir while the 
 other group(user) has access to dir2 and shared-resources.
 Just for context, both dir1 and dir2 require shared-dir to be checked out for 
 building the products.
 
 And private dir is only accessible by admin(repo owner).
 
 Regards
 Saurabh gaur

Git is a distributed VCS.
If you do a clone, all information is available on your local machine.

Solution:
Use a different repo for private stuff, in your example you need 4 repos,
which has the advantage that each product has it's own repo.

HTH



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

Want know whether Git support directory love access?

[saurabh]

Hi,

Please let me know whether Git supports directory level access or not.

For example :- Consider the structure with one repository consisting of 
sub directories for each product.

main_repo:
   dir1 dir
   dir2 dir
   shared-dir dir
   private dir
One group(user) of developers has access to dir1 and shared-dir while 
the other group(user) has access to dir2 and shared-resources.
Just for context, both dir1 and dir2 require shared-dir to be checked 
out for building the products.


And private dir is only accessible by admin(repo owner).

Regards
Saurabh gaur
--
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 grep does not support multi-byte characters (like UTF-8)

[Plamen Totev]

Nguyen, thanks for the help and the patch. Also the escaping suggested by 
Scharfe seems as good choice. But i dig some more into the problem and I found 
some other thing. That's why I replied on the main thread not on the patch. I 
hope you'll excuse me if this is a bad practice.

git grep -i -P also does not works because the PCRE_UTF8 is not set and pcre 
library does not treat the string as UTF-8.

pickaxe search also uses kwsearch so the case insensitive search with it does 
not work (e.g. git log -i -S).  Maybe this is a less of a problem here as one 
is expected to search for exact string (hence knows the case)

There is a interesting corner case. is_fixed treats all patterns containing 
nulls as fixed. So what about if the string contains non-ASCII symbols as well 
as nulls and the search is case insensitive :) I have to admin that my 
knowledge in UTF-8 is not enough to answer the question if this could occur 
during normal usage. For example the second byte in multi-byte symbol is NULL. 
I would guess that's not true as it would break a lot of programs that depend 
on NULL delimited string but it's good if somebody could confirm.

GNU grep indeed uses escaped regular expressions when the string is using 
multi-byte encoding and the search is case insensitive. If the encoding is 
UTF-8 then this strategy could be used in git too. Especially that git already 
have support and helper functions to work with UTF-8. As for the other 
multi-byte encodings - I think the things would become more complicated. As far 
I know in UTF-8 the '{' character for example is two bytes not one. Maybe 
really a support could be added only for the UTF-8 and if the string is not 
UTF-8 to issue a warning.

So maybe the following makes sense when a grep search is performed:
* check if the multi-byte encoding is used. If it's and the search is case 
insensitive and the encoding is not UTF-8 give a warning;
* if pcre is used and the string is UTF-8 encoded set the PCRE_UTF8 flag;
* if the search is case insensitive, the string is fixed and the encoding  used 
is UTF-8 use regcomp instead of kwsearch and escape any regex special 
characters in the pattern;

And the question with the behavior of pickaxe search remains open. Using kwset 
does not work with case insensitive non-ASCII searches. Instead of fixing 
grep.c maybe it's better if new function is introduced that performs keyword 
searches so it could be used by both grep, diffcore-pickaxe and any other code 
in the future that may require such functionality. Or maybe diffcore-pickaxe 
should use grep instead of directly kwset/regcomp

Regards,
Plamen Totev



 Оригинално писмо  
От: Duy Nguyen pclo...@gmail.com 
Относно: Re: Git grep does not support multi-byte characters (like UTF-8) 
До: Plamen Totev plamen.to...@abv.bg 
Изпратено на: 06.07.2015 15:23 

 I think we over-optimized a bit. If you your system provides regex 
 with locale support (e.g. Linux) and you don't explicitly use fallback 
 regex implementation, it should work. I suppose your test patterns 
 look fixed (i.e. no regex special characters)? Can you try just add 
 . and see if case insensitive matching works? 

This is indeed the problem. When I added the . the matching works just fine.
--
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: undocumented core.sharedRepository=2 set by git init --shared=world

[John Keeping]

On Tue, Jul 07, 2015 at 10:14:28AM +0200, Johannes Schindelin wrote:
 Hi Joey,
 
 On 2015-07-06 21:25, Joey Hess wrote:
  joey@darkstar:~/tmpgit init --shared=world testrepo
  Initialized empty shared Git repository in /home/joey/tmp/testrepo/.git/
  joey@darkstar:~/tmpgrep shared testrepo/.git/config 
  sharedrepository = 2
  
  This magic value of 2 seems to be undocumented, as is the magic value of 1
  that's equvilant to group.
  
  I think it would be better to have git init put in world or group and 
  not
  these magic values. Anyway, I suppose they ought to be documented too.
 
 The rationale can be found here:
 https://github.com/git/git/blob/v2.4.5/builtin/init-db.c#L413-L418
 
   /* We do not spell group and such, so that
* the configuration can be read by older version
* of git. Note, we use octal numbers for new share modes,
* and compatibility values for PERM_GROUP and
* PERM_EVERYBODY.
*/
 
 I am sympathetic to your wish, of course, and I am sure that you
 understand why we cannot simply break other people's setups to satisfy
 it.

That comment was added in 94df250 (shared repository: optionally allow
reading to others., 2006-06-09) which was in 1.4.1.  I suspect that is
now sufficiently old that it no longer matters.
--
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 09/12] t4150: am with post-applypatch hook

[Paul Tan]

On Sun, Jul 5, 2015 at 11:58 PM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
 On 2015-07-02 20:16, Paul Tan wrote:

 diff --git a/t/t4150-am.sh b/t/t4150-am.sh
 index dd6fe81..62b678c 100755
 --- a/t/t4150-am.sh
 +++ b/t/t4150-am.sh
 @@ -275,6 +275,48 @@ test_expect_success 'am with failing pre-applypatch 
 hook' '
   test_cmp_rev first HEAD
  '

 +test_expect_success 'am with post-applypatch hook' '
 + test_when_finished rm -f .git/hooks/post-applypatch 
 + rm -fr .git/rebase-apply 
 + git reset --hard 
 + git checkout first 
 + mkdir -p .git/hooks 
 + cat .git/hooks/post-applypatch -\EOF 
 + #!/bin/sh
 + git rev-parse HEAD head.actual
 + git diff second diff.actual
 + exit 0
 + EOF
 + chmod +x .git/hooks/post-applypatch 
 + git am patch1 
 + test_path_is_missing .git/rebase-apply 
 + test_cmp_rev second HEAD 
 + git rev-parse second head.expected 
 + test_cmp head.expected head.actual 
 + git diff second diff.expected 
 + test_cmp diff.expected diff.actual
 +'
 +
 +test_expect_success 'am with failing post-applypatch hook' '
 + test_when_finished rm -f .git/hooks/post-applypatch 
 + rm -fr .git/rebase-apply 
 + git reset --hard 
 + git checkout first 
 + mkdir -p .git/hooks 
 + cat .git/hooks/post-applypatch -\EOF 
 + #!/bin/sh
 + git rev-parse HEAD head.actual
 + exit 1
 + EOF
 + chmod +x .git/hooks/post-applypatch 
 + git am patch1 
 + test_path_is_missing .git/rebase-apply 
 + git diff --exit-code second 
 + test_cmp_rev second HEAD 
 + git rev-parse second head.expected 
 + test_cmp head.expected head.actual
 +'

 These 2 tests as well as the previous patches look to me as if they could be 
 refactored (the paradigm is the same: add a certain hook after resetting and 
 then apply the patch, verify that the hook ran/failed)... do you think there 
 is a chance for that?

I had a look, but I think that while it is true that the overall
sequence of each test is the same, the details differ enough that
there's no obvious way to refactor the tests sensibly. For example,
the contents of the hook scripts are not the same, as we need to check
that the hooks are run at the correct stage of git-am execution. And
as such, the verification tests are also different as well.

Junio did correctly point out though that we can shave off 2 lines if
the write_script helper is used (the shebang and the chmod).

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

Re: [PATCH v3 18/23] checkout: retire --to option

[Eric Sunshine]

On Mon, Jul 6, 2015 at 3:41 PM, Junio C Hamano gits...@pobox.com wrote:
 Eric Sunshine sunsh...@sunshineco.com writes:
 Now that git worktree add has achieved user-facing feature-parity with
 git checkout --to, retire the latter.
 [...]
 This effectively reverts changes to checkout.c by 529fef2 (checkout:
 support checking out into a new working directory, 2014-11-30) with the
 exception of merge_working_tree() and switch_branches() which still
 require specialized knowledge that a the checkout is occurring in a
 newly-created linked worktree (signaled to them by the private
 GIT_CHECKOUT_NEW_WORKTREE environment variable).

 I do not quite understand why we still need the hidden environment
 variable.  Is this a sign that the implementation is shared too much
 between unrelated codepaths (or to put it another way, perhaps API
 functions that are not best fit are being used)?

Duy had responded[1][2] to my inquiry about these two remaining bits
of checkout.c code with intimate knowledge of the initial
linked-worktree checkout (merge_working_tree  switch_branches), but I
don't know the checkout code well enough (yet) to fully understand his
responses or to answer your question satisfactorily. This is also why
I was afraid to rip out those final two bits of code, even though in
my own testing, having ripped them out locally, I was unable to
trigger any sort of bad behavior, as far as I could tell. Thus, I
wasn't sure if those two bits of code were needed, and was hoping
someone more qualified (Duy, for instance) would be able to provide a
more authoritative answer.

Having now re-read and finally digested Duy's response about
switch_branches(), when I rip out the `new_worktree_mode` check
locally, I find that I can trigger the misleading warning about an
orphaned commit, so that bit of code still serves a practical purpose.
This doesn't justify that such ugly intimacy between git-worktree and
git-checkout is desirable; only that it still seems to be needed until
git reset --hard can be swapped in to replace git checkout.

[1]: http://article.gmane.org/gmane.comp.version-control.git/273225
[2]: http://article.gmane.org/gmane.comp.version-control.git/273226

 Stepping back a bit, with or without the new linked worktree
 feature, when you came across a repository whose working tree does
 not have any file (i.e. somebody ran git ls-files | xargs rm), you
 do not know and care what is in .git/index right now, you do not
 know and care what branch its .git/HEAD points at, but you *do* know
 what branch you want to be on (or where you want its HEAD detached
 at), what would be the command you would use?

 The state immediately after a new worktree is constructed by
 populating /path/main/.git/worktrees/test-next/ and pointing it from
 /path/other/test-next/.git but before the index or the files under
 /path/other/test-next/ are populated is exactly that situation, no?
 Wouldn't symbolic-ref HEAD the-branch-i-want (or update-ref HEAD
 the-commit-i-want in the detached case) followed by reset --hard
 the more natural thing to use, instead of merge-working-tree and
 switch-branches that are implementation details of checkout?

It seems so to me. I didn't repeat it in the v3 cover letter, but the
v2 cover letter said this (which still holds true for v3):

v2 does not attempt either of the suggestions by Junio[*3*] or
Duy[*4*] for eliminating git-checkout from the equation, which
would allow us to remove the final couple bits of code in
git-checkout which require intimate knowledge that the checkout
is occurring in a newly created linked worktree. This series is
already too long, and I didn't want it to grow further by
implementing either of those ideas. Instead, this series leaves
git-worktree at a state where one or the other of those
suggestions can be done as follow-on patches touching only the
underlying machinery, without affecting the user-facing
interface.

[*3*]: via private email which suggested using git-reset --hard
   rather than git checkout to populate the new linked
   worktree.
[*4*]: 
http://thread.gmane.org/gmane.comp.version-control.git/273032/focus=273226

In order to use git reset --hard in place of git checkout,
git-worktree will need to handle -b/-B, --detach, --force (and
possibly --track and --orphan) itself. I'm still in the process of
familiarizing myself with the code needed to perform those actions, as
well as whatever else is needed to make git reset --hard a reality,
so I am not yet in a position to say now much time or work will be
required to swap out git checkout for git reset --hard. As such, I
didn't want to hold up the series for an unknown amount of time while
studying the issue; and, as the series stands, the remaining ugly
intimate knowledge between git-worktree and git-checkout is
behind-the-scenes and localized (not affecting the user experience).
--
To unsubscribe from this list: send the line unsubscribe git 

Re: [PATCH 09/12] t4150: am with post-applypatch hook

[Johannes Schindelin]

Hi Paul,

On 2015-07-07 08:47, Paul Tan wrote:
 On Sun, Jul 5, 2015 at 11:58 PM, Johannes Schindelin
 johannes.schinde...@gmx.de wrote:
 On 2015-07-02 20:16, Paul Tan wrote:

 diff --git a/t/t4150-am.sh b/t/t4150-am.sh
 index dd6fe81..62b678c 100755
 --- a/t/t4150-am.sh
 +++ b/t/t4150-am.sh
 @@ -275,6 +275,48 @@ test_expect_success 'am with failing pre-applypatch 
 hook' '
   test_cmp_rev first HEAD
  '

 +test_expect_success 'am with post-applypatch hook' '
 + test_when_finished rm -f .git/hooks/post-applypatch 
 + rm -fr .git/rebase-apply 
 + git reset --hard 
 + git checkout first 
 + mkdir -p .git/hooks 
 + cat .git/hooks/post-applypatch -\EOF 
 + #!/bin/sh
 + git rev-parse HEAD head.actual
 + git diff second diff.actual
 + exit 0
 + EOF
 + chmod +x .git/hooks/post-applypatch 
 + git am patch1 
 + test_path_is_missing .git/rebase-apply 
 + test_cmp_rev second HEAD 
 + git rev-parse second head.expected 
 + test_cmp head.expected head.actual 
 + git diff second diff.expected 
 + test_cmp diff.expected diff.actual
 +'
 +
 +test_expect_success 'am with failing post-applypatch hook' '
 + test_when_finished rm -f .git/hooks/post-applypatch 
 + rm -fr .git/rebase-apply 
 + git reset --hard 
 + git checkout first 
 + mkdir -p .git/hooks 
 + cat .git/hooks/post-applypatch -\EOF 
 + #!/bin/sh
 + git rev-parse HEAD head.actual
 + exit 1
 + EOF
 + chmod +x .git/hooks/post-applypatch 
 + git am patch1 
 + test_path_is_missing .git/rebase-apply 
 + git diff --exit-code second 
 + test_cmp_rev second HEAD 
 + git rev-parse second head.expected 
 + test_cmp head.expected head.actual
 +'

 These 2 tests as well as the previous patches look to me as if they could be 
 refactored (the paradigm is the same: add a certain hook after resetting and 
 then apply the patch, verify that the hook ran/failed)... do you think there 
 is a chance for that?
 
 I had a look, but I think that while it is true that the overall
 sequence of each test is the same, the details differ enough that
 there's no obvious way to refactor the tests sensibly. For example,
 the contents of the hook scripts are not the same, as we need to check
 that the hooks are run at the correct stage of git-am execution. And
 as such, the verification tests are also different as well.

Yeah, makes sense. Thanks for the clarification!

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

Re: [PATCH v4 27/44] builtin-am: implement --[no-]scissors

[Paul Tan]

On Sun, Jun 28, 2015 at 10:05 PM, Paul Tan pyoka...@gmail.com wrote:
 diff --git a/builtin/am.c b/builtin/am.c
 index 2387726..55989e5 100644
 --- a/builtin/am.c
 +++ b/builtin/am.c
 @@ -74,6 +74,12 @@ enum keep_type {
 KEEP_NON_PATCH  /* pass -b flag to git-mailinfo */
  };

 +enum scissors_type {
 +   SCISSORS_UNSET = -1,
 +   SCISSORS_TRUE,  /* pass --scissors to git-mailinfo */
 +   SCISSORS_FALSE  /* pass --no-scissors to git-mailinfo */
 +};
 +

Heh, the improved test coverage[1] caught a bug here. Whooops.

[1] http://thread.gmane.org/gmane.comp.version-control.git/273254/focus=273264

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

Re: [PATCH v3 23/23] checkout: retire --ignore-other-worktrees in favor of --force

[Eric Sunshine]

On Mon, Jul 6, 2015 at 3:40 PM, Junio C Hamano gits...@pobox.com wrote:
 Eric Sunshine sunsh...@sunshineco.com writes:
 As a safeguard, checking out a branch already checked out by a different
 worktree is disallowed. This behavior can be overridden with
 --ignore-other-worktrees, however, this option is neither obvious nor
 particularly discoverable. As a common safeguard override, --force is
 more likely to come to mind. Therefore, overload it to also suppress the
 check for a branch already checked out elsewhere.

 I hate to be asking this again but why is it a good idea to allow
 'ignore-other-worktrees' in the first place (let alone making it
 more discoverable)?  You'll have multiple working trees, either
 using the new git worktree or using the old contrib/workdir, for
 one of the two reasons:

  * You need a separate work area to build a new history.

  * You need a separate work area to expand the contents of a
specific commit.

 Here create binary by running make falls into the latter category;
 as far as Git is concerned, you are only looking at, not extending
 the history of any specific branch.

 If you are extending the history of some branch, then you would want
 to be on that branch.  Why would you want to have another worktree
 that will get into a confusing state once you create that commit on
 the checked out branch in this newly created worktree?

 Wasn't the whole point of making the primary repository aware of the
 secondary worktrees via the linked checkout mechanism because that
 confusion was the biggest sore point of the old contrib/workdir
 implementation?

Having never used contrib/get-new-workdir, and not being involved in
the choice, nor recall seeing justification for disallowing the a
branch to be checked out in multiple locations, I lack insight to
answer. I do recall Mark pointing out that this restriction posed a
barrier for his migration from git-new-workdir to git checkout
--to[1], and Duy adding --ignore-other-worktrees in response. Mark
presented a use-case here [2], but then the discussion petered out.

I likewise probably lack understanding of the finer points to make a
cogent argument for or against.

[1]: http://thread.gmane.org/gmane.comp.version-control.git/260387/focus=260411
[2]: http://article.gmane.org/gmane.comp.version-control.git/260645
--
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

Whether Git supports directory level access or not?

[saurabh]

Hi,

Please let me know whether Git supports directory level access or not.

For example :- Consider the structure with one repository consisting of 
sub directories for each product.

main_repo:
   dir1 dir
   dir2 dir
   shared-dir dir
   private dir
One group(user) of developers has access to dir1 and shared-dir while 
the other group(user) has access to dir2 and shared-resources.
Just for context, both dir1 and dir2 require shared-dir to be checked 
out for building the products.


And private dir is only accessible by admin(repo owner).

Regards
Saurabh gaur
--
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: Whether Git supports directory level access or not?

[Jacob Keller]

Hi

On Mon, Jul 6, 2015 at 11:40 PM,  saur...@stockal.com wrote:
 Hi,

 Please let me know whether Git supports directory level access or not.

 For example :- Consider the structure with one repository consisting of sub
 directories for each product.
 main_repo:
dir1 dir
dir2 dir
shared-dir dir
private dir
 One group(user) of developers has access to dir1 and shared-dir while the
 other group(user) has access to dir2 and shared-resources.
 Just for context, both dir1 and dir2 require shared-dir to be checked out
 for building the products.

 And private dir is only accessible by admin(repo owner).

 Regards
 Saurabh gaur
 --
 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

I do not believe this is possible with git. How would this even make
sense? You can do something with sub-repositories on the server end,
where each directory is its own repository with different access
rights (and servers like gerrit or other git server setups have
various controls which enable more complex access control beyond just
Unix paths)

However, in-repo per-directory permissions make no sense, as there
would be no way to generate commits.

Regards,
Jake
--
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: refspecs with '*' as part of pattern

[Jacob Keller]

On Mon, Jul 6, 2015 at 7:33 PM, Jacob Keller jacob.kel...@gmail.com wrote:
 On Mon, Jul 6, 2015 at 7:20 PM, Daniel Barkalow
 barka...@iabervon.iabervon.org wrote:
 On Mon, 6 Jul 2015, Junio C Hamano wrote:

 Jacob Keller jacob.kel...@gmail.com writes:

  I've been looking at the refspecs for git fetch, and noticed that
  globs are partially supported. I wanted to use something like:
 
  refs/tags/some-prefix-*:refs/tags/some-prefix-*
 
  as a refspec, so that I can fetch only tags which have a specific
  prefix. I know that I could use namespaces to separate tags, but
  unfortunately, I am unable to fix the tag format. The specific
  repository in question is also generating several tags which are not
  relevant to me, in formats that are not really useful for human
  consumption. I am also not able to fix this less than useful practice.
 
  However, I noticed that refspecs only support * as a single component.
  The match algorithm works perfectly fine, as documented in
  abd2bde78bd9 (Support '*' in the middle of a refspec)
 
  What is the reason for not allowing slightly more arbitrary
  expressions? Obviously no more than one *...

 I cannot seem to be able to find related discussions around that
 patch, so this is only my guess, but I suspect that this is to
 discourage people from doing something like:

   refs/tags/*:refs/tags/foo-*

 which would open can of worms (e.g. imagine you fetch with that
 pathspec and then push with refs/tags/*:refs/tags/* back there;
 would you now get foo-v1.0.0 and foo-foo-v1.0.0 for their v1.0.0
 tag?) we'd prefer not having to worry about.

 That wouldn't be it, since refs/tags/*:refs/tags/foo/* would have the same
 problem, assuming you didn't set up the push refspec carefully.

 I think it was mostly that it would be too easy to accidentally do
 something you don't want by having some other character instead of a
 slash, like refs/heads/*:refs/heads-*.

 Aside from the increased risk of hard-to-spot typos leading to very weird
 behavior, nothing actually goes wrong; in fact, I've been using git with
 that check removed for ages because I wanted a refspec like
 refs/heads/something-*:refs/heads/*. And it works fine as a local patch,
 since you don't need your refspec handling to interoperate with other
 repositories.

 -Daniel
 *This .sig left intentionally blank*


 Which is why I suggested a patch that adds this behavior conditionally
 and only for fetch. This way you don't have to use a local patch, and
 it wouldn't hit normal users. Ideally we can add a flag that only
 enables it for refspecs that don't interoperate.

 Does this seem ok? If so I will go ahead and try to work up a patch

 Regards,
 Jake

I am working up a patch to try and get this configurable. I'll
hopefully send it out tomorrow morning sometime.

Regards,
Jake
--
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

Subject: [PATCH] git am: Transform and skip patches via new hook

[Robert Collins]

From 0428b0a1248fb84c584a5a6c1f110770c6615d5e Mon Sep 17 00:00:00 2001
From: Robert Collins rbtcoll...@hp.com
Date: Tue, 7 Jul 2015 15:43:24 +1200
Subject: [PATCH] git am: Transform and skip patches via new hook

A thing I need to do quite a lot of is extracting stuff from
Python to backported libraries. This involves changing nearly
every patch but its automatable.

Using a new hook (applypatch-transform) was sufficient to meet all my
needs and should be acceptable upstream as far as I can tell.

Signed-Off-By: Robert Collins rbtcoll...@hp.com
---
 Documentation/git-am.txt |  6 ++---
 Documentation/githooks.txt   | 15 
 git-am.sh| 15 
 templates/hooks--applypatch-transform.sample | 36 
 4 files changed, 69 insertions(+), 3 deletions(-)
 create mode 100755 templates/hooks--applypatch-transform.sample

diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index dbea6e7..9ddcd87 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -215,9 +215,9 @@ errors in the From: lines).

 HOOKS
 -
-This command can run `applypatch-msg`, `pre-applypatch`,
-and `post-applypatch` hooks.  See linkgit:githooks[5] for more
-information.
+This command can run `applypatch-msg`, `applypatch-transform`,
+`pre-applypatch`, and `post-applypatch` hooks.  See
+linkgit:githooks[5] for more information.

 SEE ALSO
 
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index 7ba0ac9..251b604 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -45,6 +45,21 @@ the commit after inspecting the message file.
 The default 'applypatch-msg' hook, when enabled, runs the
 'commit-msg' hook, if the latter is enabled.

+applypatch-transform
+
+
+This hook is invoked by 'git am' before attempting to apply
+patches.  It takes two parameters - the path to the patch on
+disk, and the path to the proposed commit message (which may
+be absent).  Like applypatch-msg, both files may be edited.
+
+Exiting with 1 will cause 'git am' to skip the patch. Exiting
+with any other non-zero value will cause 'git am' to abort.
+
+The sample 'applypatch-transform' hook demonstrates mangling
+a patch from one tree shape to another while discarding irrelevant
+patches.
+
 pre-applypatch
 ~~

diff --git a/git-am.sh b/git-am.sh
index 8733071..796efea 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -869,6 +869,21 @@ To restore the original branch and stop patching
run \\$cmdline --abort\.

  case $resolved in
  '')
+ # Attempt to rewrite the patch.
+ hook=$(git rev-parse --git-path hooks/applypatch-transform)
+ if test -x $hook
+ then
+ $hook $dotest/patch $dotest/final-commit
+ status=$?
+ if test $status -eq 1
+ then
+ go_next
+ elif test $status -ne 0
+ then
+ stop_here $this
+ fi
+ fi
+
  # When we are allowed to fall back to 3-way later, don't give
  # false errors during the initial attempt.
  squelch=
diff --git a/templates/hooks--applypatch-transform.sample
b/templates/hooks--applypatch-transform.sample
new file mode 100755
index 000..97cd789
--- /dev/null
+++ b/templates/hooks--applypatch-transform.sample
@@ -0,0 +1,36 @@
+#!/bin/sh
+#
+# An example hook script to transform a patch taken from an email
+# by git am.
+#
+# The hook should exit with non-zero status after issuing an
+# appropriate message if it wants to stop the commit.  The hook is
+# allowed to edit the patch file.
+#
+# To enable this hook, rename this file to applypatch-transform.
+#
+# This example changes the path of Lib/unittest/mock.py to mock.py
+# Lib/unittest/tests/testmock to tests and Misc/NEWS to NEWS, and
+# finally skips any patches that did not alter mock.py or its tests.
+
+set -eux
+
+patch_path=$1
+
+# Pull out mock.py
+filterdiff --clean --strip 3 --addprefix=a/ -i
'a/Lib/unittest/mock.py' $patch_path  $patch_path.mock
+# And the tests
+filterdiff --clean --strip 5 --addprefix=a/tests/ -i
'a/Lib/unittest/test/testmock/' $patch_path  $patch_path.tests
+# Lastly we want to pick up any NEWS entries.
+filterdiff --strip 2 --addprefix=a/ -i a/Misc/NEWS $patch_path 
$patch_path.NEWS
+cat $patch_path.mock $patch_path.tests  $patch_path
+filtered=$(cat $patch_path)
+if [ -n ${filtered} ]; then
+  cat $patch_path.NEWS  $patch_path
+  exitcode=0
+else
+  exitcode=1
+fi
+
+rm $patch_path.mock $patch_path.tests $patch_path.NEWS
+exit $exitcode
-- 
2.1.0


-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
--
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: undocumented core.sharedRepository=2 set by git init --shared=world

[Johannes Schindelin]

Hi Joey,

On 2015-07-06 21:25, Joey Hess wrote:
 joey@darkstar:~/tmpgit init --shared=world testrepo
 Initialized empty shared Git repository in /home/joey/tmp/testrepo/.git/
 joey@darkstar:~/tmpgrep shared testrepo/.git/config 
   sharedrepository = 2
 
 This magic value of 2 seems to be undocumented, as is the magic value of 1
 that's equvilant to group.
 
 I think it would be better to have git init put in world or group and not
 these magic values. Anyway, I suppose they ought to be documented too.

The rationale can be found here: 
https://github.com/git/git/blob/v2.4.5/builtin/init-db.c#L413-L418

/* We do not spell group and such, so that
 * the configuration can be read by older version
 * of git. Note, we use octal numbers for new share modes,
 * and compatibility values for PERM_GROUP and
 * PERM_EVERYBODY.
 */

I am sympathetic to your wish, of course, and I am sure that you understand why 
we cannot simply break other people's setups to satisfy it.

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

Re: [PATCH v2 00/12] Improve git-am test coverage

[Johannes Schindelin]

Hi Paul

On 2015-07-07 16:08, Paul Tan wrote:
 This is a re-roll of [v1]. Thanks Junio, Johannes, Paolo, Stefan for the
 reviews last round. Interdiff below.

Interdiff looks good to me!

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

Re: Git force push fails after a rejected push (unpack failed)?

[Jeff King]

On Tue, Jul 07, 2015 at 09:31:25PM +0200, X H wrote:

 For the moment, I'm the only one pushing to the remote, always with
 the same user (second user is planned). I use git-for-windows which is
 based on MSYS2. I have mounted the network share with noacl option so
 permissions should be handled by the Windows share. I'm in a group
 which has read/write access. I have not configured
 core.sharedrepository, I don't think it is useful with noacl since
 unix group are not used in this case. The permission for the folder
 above the file with permission denied is rw, but this file is read
 only so if git try to modify it it won't work.

Ah, so this is not a push to a server, but to a share mounted on the
local box?

That is leaving my realm of expertise. I'm not sure if it could be a
misconfiguration in your share setup, or that git is trying to do
something that would work on a Unix machine, but not on a Windows share.
You might want to ask on the msysgit list:

  https://groups.google.com/forum/#!forum/msysgit

 Why does git try to write a file with the same name? If I amend a
 commit isn't the sha modified?

Yes, but remember that git stores all of the objects for all of the
commits. So for some reason your push is perhaps trying to send an
object that the other side already has. Usually this does not happen
(the receiver says I already have these commits, do not bother sending
their objects), but it's possible that you have an object that is not
referenced by any commit, or a similar situation. It's hard to say
without looking at the repository.

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

Re: [PATCH v5 00/44] Make git-am a builtin

[Junio C Hamano]

Paul Tan pyoka...@gmail.com writes:

 This patch series depends on pt/pull-builtin.

 This is a re-roll of [v4]. Thanks Torsten, Stefan, Junio for the reviews last
 round. Interdiff below.

 Previous versions:

 [WIP v1] http://thread.gmane.org/gmane.comp.version-control.git/270048
 [WIP v2] http://thread.gmane.org/gmane.comp.version-control.git/271381
 [WIP v3] http://thread.gmane.org/gmane.comp.version-control.git/271967
 [v4] http://thread.gmane.org/gmane.comp.version-control.git/272876

 git-am is a commonly used command for applying a series of patches from a
 mailbox to the current branch. Currently, it is implemented by the shell 
 script
 git-am.sh. However, compared to C, shell scripts have certain deficiencies:
 they need to spawn a lot of processes, introduce a lot of dependencies and
 cannot take advantage of git's internal caches.

 This patch series rewrites git-am.sh into optimized C builtin/am.c, and is
 part of my GSoC project to rewrite git-pull and git-am into C builtins[1].

 [1] https://gist.github.com/pyokagan/1b7b0d1f4dab6ba3cef1

Is it really a rewrite into optimized C, or just C?  I suspect
it is the latter.

This seems to apply cleanly to 'master' but fails to compile, as it
depends on some new stuff that are not even in 'next' yet, e.g.
argv_array_pushv() that is from pt/pull-builtin, and it does not
apply cleanly on top of that branch, either.

I'll see what's the cleanest way to queue this would be.  Perhaps
merge pt/builtin-pull on a copy of 'master' and then apply these, or
something like that.

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

Re: Git grep does not support multi-byte characters (like UTF-8)

[Plamen Totev]

Junio C Hamano gits...@pobox.com writes:

 Plamen Totev plamen.to...@abv.bg writes: 
 
  pickaxe search also uses kwsearch so the case insensitive search with 
  it does not work (e.g. git log -i -S). Maybe this is a less of a 
  problem here as one is expected to search for exact string (hence 
  knows the case) 
 
 You reasoned correctly, I think. Pickaxe, as one of the building 
 blocks to implement Linus's ultimate change tracking tool [*1*], 
 should never pay attention to -i. It is a step to finding the 
 commit that touches the exact code block given (i.e. how do you 
 drill down? part of $gmane/217 message). 
 
 Thanks. 
 
 [Footnote] 
 *1* http://article.gmane.org/gmane.comp.version-control.git/217

Now that I read the link again and gave the matter a thought I'm not so sure.
In some contexts the case of the words does not matter. In SQL for example.
Let's consider a SQL script file that contains the following line:

select name, address from customers;

At some point we decide to change the coding style to:

SELECT name, address FROM customers;

What should pickaxe search return - the first commit where the line is 
introduced
or the commit with the refactoring? From this point of view I think the -i 
switch makes sense.
The SQL is not the only case insensitive language - BASIC and Pascal come into 
my mind 
(those two I was using while I was in the high school :)).

Also I think it makes sense (maybe even more?) for natural languages.
For example after editing a text a sentence could be split into two.
Then the first word of the second sentence may change its case.
Of course the natural languages always  complicate the things a bit.
An ultimate tracking tools should be able to handle typo fixes, punctuation 
changes, etc.

But I'm getting a bit off-topic. What I wanted to say is that in some contexts 
it makes sense
(at least to me) to have case insensitive pickaxe search.
Or I'm missing something and there is a better tools to use is such cases?

Regards,
Plamen Totev
--
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

[GSOC] Update 4: Unification of tag -l, branch -l and for-each-ref

[Karthik Nayak]

Hello All,

As part of GSoC I'm working on the Unification of 'for-each-ref', 'tag -l'
and 'branch -l'. Sorry for the lack of update since Jun 14, was a
little busy with an exam I had. Now thats over, I will be working more
on the project.

Current Progress:

1. Building ref-filter.{c,h} from for-each-ref.
This is the process of creating an initial library for the unification
by moving most of the code from for-each-ref to ref-filter.{c,h}.
Merged into next

2. Add options to ref-filter.
This includes the porting of --points-at, --contains, --merged,
--no-merged options from builtin/branch.c and builtin/tag.c, Also the
implementation of these options into for-each-ref.
The last version (v8) is posted here:
http://thread.gmane.org/gmane.comp.version-control.git/273569
Currently waiting for comments.

3. Port builtin/tag.c to use ref-filter.
Here we port tag.c to use ref-filter and also port the --format,
--sort and --merged and --no-merged options to builtin/tag.c.
The RFC version is posted and I'm waiting for comments from the list:
thread.gmane.org/gmane.comp.version-control.git/272654
Will post v2 soon.

Next Plans:
I'm currently working on porting over builtin/branch.c to use
ref-filter.{c,h}, will be pushing intermediate code to my Github repository.
Currently looking at what all branch.c needs in ref-filter and adding respective
options to ref-filter.
https://github.com/KarthikNayak/git

Thanks to everyone who has helped :)

-- 
Regards,
Karthik Nayak
--
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 v5 00/44] Make git-am a builtin

[Paul Tan]

On Wed, Jul 8, 2015 at 2:52 AM, Junio C Hamano gits...@pobox.com wrote:
 Paul Tan pyoka...@gmail.com writes:
 This patch series rewrites git-am.sh into optimized C builtin/am.c, and is
 part of my GSoC project to rewrite git-pull and git-am into C builtins[1].

 [1] https://gist.github.com/pyokagan/1b7b0d1f4dab6ba3cef1

 Is it really a rewrite into optimized C, or just C?  I suspect
 it is the latter.

Well, optimized in comparison to the shell script ;-) We don't
replicate the shell script in its entirety, but optimize the code
where it is obvious and sensible. It's not the most optimized (and I
will gladly accept any suggestions where there are obvious
optimizations to be made), but I do consider it an improvement in
terms of efficiency, while keeping the overall structure of the code
close to the shell script for easy review.

I'll remove the word though, because it's true that the main purpose
of this patch series is to make it work first.

 This seems to apply cleanly to 'master' but fails to compile, as it
 depends on some new stuff that are not even in 'next' yet, e.g.
 argv_array_pushv() that is from pt/pull-builtin, and it does not
 apply cleanly on top of that branch, either.

I tried applying the series, and yeah it conflicts with 1570856
(config.c: avoid xmmap error messages, 2015-05-28) because the
pt/pull-builtin branch in pu is based on an old version of master.
That's the only conflict though, it applies cleanly otherwise.

 I'll see what's the cleanest way to queue this would be.  Perhaps
 merge pt/builtin-pull on a copy of 'master' and then apply these, or
 something like that.

Thanks.

Regards,
Paul
--
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 v5 19/44] builtin-am: implement --3way, am.threeWay

[Junio C Hamano]

Paul Tan pyoka...@gmail.com writes:

 @@ -82,6 +84,8 @@ struct am_state {
   /* number of digits in patch filename */
   int prec;
  
 + int threeway;
 +
   int quiet;
  
   int append_signoff;

These one line surrounded by blank on both sides starts to get
irritating, and the structure looksq horrifying after you apply all
these patches.  Perhaps have a clean-up patch at the end to make
them look more like this?

struct am_state {
/* state directory path */
char *dir;

/* current and last patch numbers, 1-indexed */
int cur;
int last;

/* commit metadata and message */
char *author_name;
char *author_email;
char *author_date;
char *msg;
size_t msg_len;

/* when --rebasing, records the original commit the patch came from */
unsigned char orig_commit[GIT_SHA1_RAWSZ];

/* number of digits in patch filename */
int prec;

/* various operating modes and command line options */
int interactive;
int threeway;
int quiet;
int append_signoff;
int utf8;
int committer_date_is_author_date;
int ignore_date;
int allow_rerere_autoupdate;
const char *sign_commit;
int rebasing;

/* one of the enum keep_type values */
int keep;

/* pass -m flag to git-mailinfo */
int message_id;

/* one of the enum scissors_type values */
int scissors;

/* used when spawning git apply via run_command() */
struct argv_array git_apply_opts;

/* override error message when patch failure occurs */
const char *resolvemsg;
};
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] log: add log.follow config option

[David Turner]

From: David Turner dtur...@twitter.com

Many users prefer to always use --follow with logs.  Rather than
aliasing the command, an option might be more convenient for some.
---
 Documentation/git-log.txt   |  7 +++
 builtin/log.c   |  7 +++
 diff.c  |  5 +++--
 diff.h  |  1 +
 revision.c  | 15 ---
 t/t4206-log-follow-harder-copies.sh | 35 +++
 6 files changed, 65 insertions(+), 5 deletions(-)

diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 5692945..5a23085 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -184,6 +184,13 @@ log.date::
`--date` option.)  Defaults to default, which means to write
dates like `Sat May 8 19:35:34 2010 -0500`.
 
+log.follow::
+   If a single file argument is given to git log, it will act as
+   if the `--follow` option was also used.  This adds no new
+   functionality over what --follow already provides (in other words,
+   it cannot be used to follow multiple files).  It's just a
+   convenience.
+
 log.showRoot::
If `false`, `git log` and related commands will not treat the
initial commit as a big creation event.  Any root commits in
diff --git a/builtin/log.c b/builtin/log.c
index 8781049..9b6abef 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -31,6 +31,7 @@ static const char *default_date_mode = NULL;
 
 static int default_abbrev_commit;
 static int default_show_root = 1;
+static int default_follow = 0;
 static int decoration_style;
 static int decoration_given;
 static int use_mailmap_config;
@@ -102,6 +103,8 @@ static void cmd_log_init_defaults(struct rev_info *rev)
 {
if (fmt_pretty)
get_commit_format(fmt_pretty, rev);
+   if (default_follow)
+   DIFF_OPT_SET(rev-diffopt, DEFAULT_FOLLOW_RENAMES);
rev-verbose_header = 1;
DIFF_OPT_SET(rev-diffopt, RECURSIVE);
rev-diffopt.stat_width = -1; /* use full terminal width */
@@ -390,6 +393,10 @@ static int git_log_config(const char *var, const char 
*value, void *cb)
default_show_root = git_config_bool(var, value);
return 0;
}
+   if (!strcmp(var, log.follow)) {
+   default_follow = git_config_bool(var, value);
+   return 0;
+   }
if (skip_prefix(var, color.decorate., slot_name))
return parse_decorate_color_config(var, slot_name, value);
if (!strcmp(var, log.mailmap)) {
diff --git a/diff.c b/diff.c
index 87b16d5..135b222 100644
--- a/diff.c
+++ b/diff.c
@@ -3815,9 +3815,10 @@ int diff_opt_parse(struct diff_options *options, const 
char **av, int ac)
DIFF_OPT_SET(options, FIND_COPIES_HARDER);
else if (!strcmp(arg, --follow))
DIFF_OPT_SET(options, FOLLOW_RENAMES);
-   else if (!strcmp(arg, --no-follow))
+   else if (!strcmp(arg, --no-follow)) {
DIFF_OPT_CLR(options, FOLLOW_RENAMES);
-   else if (!strcmp(arg, --color))
+   DIFF_OPT_CLR(options, DEFAULT_FOLLOW_RENAMES);
+   } else if (!strcmp(arg, --color))
options-use_color = 1;
else if (skip_prefix(arg, --color=, arg)) {
int value = git_config_colorbool(NULL, arg);
diff --git a/diff.h b/diff.h
index c7ad42a..f7208ad 100644
--- a/diff.h
+++ b/diff.h
@@ -91,6 +91,7 @@ typedef struct strbuf *(*diff_prefix_fn_t)(struct 
diff_options *opt, void *data)
 #define DIFF_OPT_DIRSTAT_BY_LINE (1  28)
 #define DIFF_OPT_FUNCCONTEXT (1  29)
 #define DIFF_OPT_PICKAXE_IGNORE_CASE (1  30)
+#define DIFF_OPT_DEFAULT_FOLLOW_RENAMES (1  31)
 
 #define DIFF_OPT_TST(opts, flag)((opts)-flags  DIFF_OPT_##flag)
 #define DIFF_OPT_TOUCHED(opts, flag)((opts)-touched_flags  
DIFF_OPT_##flag)
diff --git a/revision.c b/revision.c
index 3ff8723..ae6d4c3 100644
--- a/revision.c
+++ b/revision.c
@@ -2322,12 +2322,21 @@ int setup_revisions(int argc, const char **argv, struct 
rev_info *revs, struct s
 
if (revs-prune_data.nr) {
copy_pathspec(revs-pruning.pathspec, revs-prune_data);
-   /* Can't prune commits with rename following: the paths 
change.. */
-   if (!DIFF_OPT_TST(revs-diffopt, FOLLOW_RENAMES))
-   revs-prune = 1;
+
if (!revs-full_diff)
copy_pathspec(revs-diffopt.pathspec,
  revs-prune_data);
+
+   if (DIFF_OPT_TST(revs-diffopt, DEFAULT_FOLLOW_RENAMES) 
+   revs-diffopt.pathspec.nr == 1)
+   DIFF_OPT_SET(revs-diffopt, FOLLOW_RENAMES);
+
+   /* Can't prune commits with rename following: the paths 
change.. */
+   if (!DIFF_OPT_TST(revs-diffopt, FOLLOW_RENAMES)) {
+   revs-prune = 1;
+   } else {
+  

Re: [PATCH v5 18/44] cache-tree: introduce write_index_as_tree()

[Junio C Hamano]

Paul Tan pyoka...@gmail.com writes:

 A caller may wish to write a temporary index as a tree. However,
 write_cache_as_tree() assumes that the index was read from, and will
 write to, the default index file path. Introduce write_index_as_tree()
 which removes this limitation by allowing the caller to specify its own
 index_state and index file path.

 Signed-off-by: Paul Tan pyoka...@gmail.com
 ---
  cache-tree.c | 29 +
  cache-tree.h |  1 +
  2 files changed, 18 insertions(+), 12 deletions(-)

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

Re: [PATCH v3 22/23] worktree: add: auto-vivify new branch when branch is omitted

[Junio C Hamano]

Eric Sunshine sunsh...@sunshineco.com writes:

 Which may be something we would want to have a test for, though.

 Good idea. How about the following as a squash-in?

Sounds sensible.

At this point we do not have worktree list, but if we gained that,
we may want to add this as one more postcondition after the failed
worktree add:

   git worktree list actual 
   ! grep precious actual

but that should happen in the series that adds worktree list ;-)

 --- 8 ---
 From: Eric Sunshine sunsh...@sunshineco.com
 Subject: [PATCH] fixup! worktree: add: auto-vivify new branch when branch 
 is omitted

 ---
  t/t2025-worktree-add.sh | 9 +
  1 file changed, 9 insertions(+)

 diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
 index 8fe242f..ead8aa2 100755
 --- a/t/t2025-worktree-add.sh
 +++ b/t/t2025-worktree-add.sh
 @@ -150,4 +150,13 @@ test_expect_success 'add with branch omitted' '
   test_cmp_rev HEAD bat
  '
  
 +test_expect_success 'add auto-vivify does not clobber existing branch' '
 + test_commit c1 
 + test_commit c2 
 + git branch precious HEAD~1 
 + test_must_fail git worktree add precious 
 + test_cmp_rev HEAD~1 precious 
 + test_path_is_missing precious
 +'
 +
  test_done
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 23/23] checkout: retire --ignore-other-worktrees in favor of --force

[Junio C Hamano]

Eric Sunshine sunsh...@sunshineco.com writes:

 Is receive.denyCurrentBranch worth mentioning as an argument? Although
 pushing a branch into a non-bare repo where that branch is already
 checked out is normally disallowed, receive.denyCurrentBranch
 overrides the safeguard. Presumably, the user has experience and
 knowledge to know that git reset --hard will be required to sync
 things up.

Or the user knows that he does not have a shell access to the box in
the first place.  I do not see much relevance to this discussion.

I would not mind git worktree add -f to disable the no multiple
checkouts of the same branch safety, but I do not think it is
sensible to remove -i-o-w and conflate everything into --force.
That would force people to disable other safety measures at the same
time (e.g. protect local changes from differences between the
current and next branches).
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] convert enum date_mode into a struct

[Junio C Hamano]

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

 ...  However, the tricky case is where we use the
 enum labels as constants, like:

   show_date(t, tz, DATE_NORMAL);

 Ideally we could say:

   show_date(t, tz, { DATE_NORMAL });

 but of course C does not allow that.
 ...
   3. Provide a wrapper that generates the correct struct on
  the fly. The big downside is that we end up pointing to
  a single global, which makes our wrapper non-reentrant.
  But show_date is already not reentrant, so it does not
  matter.

 This patch implements 3, along with a minor macro to keep
 the size of the callers sane.

Another big downside is that DATE_NORMAL is defined to be 0.

This makes it very cumbersome to merge a side branch that uses an
outdated definition of show_date() and its friends and tell them
to show date normally.  The compiler does not help detecting
places that need to be adjusted during merge and instead just pass
a NULL pointer as a pointer to the new struct.

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

Re: [PATCH 2/3] convert enum date_mode into a struct

[Jeff King]

On Tue, Jul 07, 2015 at 01:37:08PM -0700, Junio C Hamano wrote:

3. Provide a wrapper that generates the correct struct on
   the fly. The big downside is that we end up pointing to
   a single global, which makes our wrapper non-reentrant.
   But show_date is already not reentrant, so it does not
   matter.
 
  This patch implements 3, along with a minor macro to keep
  the size of the callers sane.
 
 Another big downside is that DATE_NORMAL is defined to be 0.
 
 This makes it very cumbersome to merge a side branch that uses an
 outdated definition of show_date() and its friends and tell them
 to show date normally.  The compiler does not help detecting
 places that need to be adjusted during merge and instead just pass
 a NULL pointer as a pointer to the new struct.

My assumption was that using the raw 0 is something we would frowned
upon in new code. There was a single historical instance that I fixed in
the series, but I wouldn't expect new ones (and actually, that instance
was 1, which would be caught by the compiler).

However, if you're concerned, I think we could have show_date massage a
NULL date, like:

diff --git a/date.c b/date.c
index 8f91569..a04d089 100644
--- a/date.c
+++ b/date.c
@@ -173,6 +173,10 @@ const char *show_date(unsigned long time, int tz, const 
struct date_mode *mode)
 {
struct tm *tm;
static struct strbuf timebuf = STRBUF_INIT;
+   static const struct fallback_mode = { DATE_NORMAL };
+
+   if (!mode)
+   mode = fallback_mode;
 
if (mode-type == DATE_RAW) {
strbuf_reset(timebuf);


That would also allow people to explicitly call:

  show_date(t, tz, NULL);

to get the default format, though I personally prefer spelling it out.

I guess we _could_ introduce:

  #define DATE_MODE(x) ((struct date_mode *)(x))

and then take any numeric value, under the assumption that the first
page of memory will never be a valid pointer:

diff --git a/date.c b/date.c
index 8f91569..f388fee 100644
--- a/date.c
+++ b/date.c
@@ -173,6 +173,18 @@ const char *show_date(unsigned long time, int tz, const 
struct date_mode *mode)
 {
struct tm *tm;
static struct strbuf timebuf = STRBUF_INIT;
+   struct date_mode fallback;
+
+   /* hysterical compatibility */
+   if (mode  1024) {
+   if (mode == DATE_STRFTIME)
+   die(BUG: nice try);
+   fallback.type = mode;
+   mode = fallback;
+   }
+
+   if (!mode)
+   mode = fallback_mode;
 
if (mode-type == DATE_RAW) {
strbuf_reset(timebuf);

That's kind of nasty, but at least it's hidden from the callers.

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

Re: No one understands diff3 Temporary merge branch conflict markers

[Matthieu Moy]

Junio C Hamano gits...@pobox.com writes:

 Matthieu Moy matthieu@grenoble-inp.fr writes:

 ... I would say: the
 recursive merge-base was computed internally, but not really meant to be
 shown to the user.

 I wonder if the output becomes easier to read if we unconditionally
 turned off diff3-style for inner merges.

Or replace the whole conflict markers with Sorry, cannot compute a
merge base text when doing the recursive merge to build the merge base.

I don't know that area well enough to have a real opinion.

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

Re: [PATCH 2/3] convert enum date_mode into a struct

[Jeff King]

On Tue, Jul 07, 2015 at 02:05:52PM -0700, Junio C Hamano wrote:

 And that is because DATE_NORMAL is defined to be 0; we can claim
 that the compiler is being stupid to take one of the enum
 date_mode_type values that happens to be 0 and misinterpret it as
 the program wanted to pass a NULL pointer to a structure, but that
 is not what happened.

Ah, I didn't think the compiler would coerce an enum into a pointer
constant. That seems kind of insane. But it is indeed what gcc does.

In that case, we can indeed do the NULL-pointer thing I mentioned. Which
is not even _that_ ugly; it follows the standard.

The cast DATE_RELATIVE to a pointer and uncast it on the other side
thing _does_ violate the standard. It is not needed for this, but it
would make the DATE_MODE() macro reentrant.

  +   static const struct fallback_mode = { DATE_NORMAL };
 
 Yes, that is nasty.  Renumbering the enum to begin with 1 may be a
 much saner solution, unless somebody does

I am worried more about somebody who does memset(0) on a struct, and
expects that to default to DATE_NORMAL.

 In any case, I did another evil merge to fix it.

OK. Do you want to leave it be, then, or would you prefer me to do the
NULL fallback? Or we could bump the enum to start with 1, and then
explicitly treat 0 as a synonym for DATE_NORMAL (in case it comes in
through a memset or similar).

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

Re: [PATCH 2/3] convert enum date_mode into a struct

[Junio C Hamano]

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

 My assumption was that using the raw 0 is something we would frowned
 upon in new code. There was a single historical instance that I fixed in
 the series, but I wouldn't expect new ones (and actually, that instance
 was 1, which would be caught by the compiler).

That is not the problem.

The code on the side branch may add a new callsite, something like
this:

show_ident_date(ident_split, DATE_NORMAL);

based on the current codebase (e.g. 'master' as of today).

The merge goes cleanly, it compiles, even though the new function
signature of show_ident_date(), similar to the updated show_date(),
takes a pointer to a struct where they used to take DATE_$format
constants.

And that is because DATE_NORMAL is defined to be 0; we can claim
that the compiler is being stupid to take one of the enum
date_mode_type values that happens to be 0 and misinterpret it as
the program wanted to pass a NULL pointer to a structure, but that
is not what happened.

 However, if you're concerned, I think we could have show_date massage a
 NULL date, like:

 diff --git a/date.c b/date.c
 index 8f91569..a04d089 100644
 --- a/date.c
 +++ b/date.c
 @@ -173,6 +173,10 @@ const char *show_date(unsigned long time, int tz, const 
 struct date_mode *mode)
  {
   struct tm *tm;
   static struct strbuf timebuf = STRBUF_INIT;
 + static const struct fallback_mode = { DATE_NORMAL };

Yes, that is nasty.  Renumbering the enum to begin with 1 may be a
much saner solution, unless somebody does

if (!mode-type)
/* we know DATE_NORMAL is zero, he he */
do the normal thing;

In any case, I did another evil merge to fix it.

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

Re: [PATCH 2/3] convert enum date_mode into a struct

[Junio C Hamano]

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

 OK. Do you want to leave it be, then, or would you prefer me to do the
 NULL fallback? Or we could bump the enum to start with 1, and then
 explicitly treat 0 as a synonym for DATE_NORMAL (in case it comes in
 through a memset or similar).

I didn't think about the memset() initialization, and keeping the
normal case to be 0 makes tons of sense.

I'd prefer to see the stale code dump core rather than leaving it
stale without anybody noticing.  Hopefully the date-mode change can
hit 'master' fairly soon after the upcoming release, so unless a fix
that involves show_date() need to be written and applied to 2.4
codebase and upwards at the same time, I do not think it is a huge
issue.

Thanks.

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

RE: Git installer questions

[McChesney, Adam]

I am curious as whether or not the windows installer has silent install flags 
that are configurable for automated installation? I was looking about the 
documentation and haven't been able to find them, if it does exist in the 
documentation could you point me to where they might be?

Thanks,
Adam Mcchesney 

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

Re: [PATCH v2] log: add log.follow config option

[Matthieu Moy]

Hi,

Thanks for your patch. Below are some comments. Some of them are just me
thinking out loudly (don't take it badly if I'm being negative), some
are more serious, but all are fixable.

David Turner dtur...@twopensource.com writes:

 From: David Turner dtur...@twitter.com

If you configure your commiter id and your From field to the same value,
you can avoid this distracting From: header.

You're lacking a Signed-off-by trailer.

 +log.follow::
 + If a single file argument is given to git log, it will act as
 + if the `--follow` option was also used.  This adds no new
 + functionality over what --follow already provides (in other words,
 + it cannot be used to follow multiple files).  It's just a
 + convenience.

Missing `...` around the second --follow.

I would write this as:

This has the same limitations as --follow, i.e. it cannot be
used to follow multiple files and does not work well on
non-linear history.

and drop the it's just a convenience part.

 --- a/builtin/log.c
 +++ b/builtin/log.c
 @@ -31,6 +31,7 @@ static const char *default_date_mode = NULL;
  
  static int default_abbrev_commit;
  static int default_show_root = 1;
 +static int default_follow = 0;

I tend to disagree with this rule, but in Git we usually omit the = 0
for static variables, which are already initialized to 0 by default.

 + /* Can't prune commits with rename following: the paths 
 change.. */
 + if (!DIFF_OPT_TST(revs-diffopt, FOLLOW_RENAMES)) {
 + revs-prune = 1;
 + } else {
 + revs-diff = 1;
 + }

Useless braces.

 + git log --name-status --pretty=format:%s  path1  current'

Whitespace: here an elsewhere, you have two spaces before path1, and we
usually stick the  to the filename like current.

 --- a/t/t4206-log-follow-harder-copies.sh
 +++ b/t/t4206-log-follow-harder-copies.sh
 @@ -53,4 +53,39 @@ test_expect_success \
  'validate the output.' \
  'compare_diff_patch current expected'
  
 +test_expect_success \
 +'git config log.follow works like --follow' \
 +'test_config log.follow true 
 + git log --name-status --pretty=format:%s  path1  current'
 +
 +test_expect_success \
 +'validate the output.' \
 +'compare_diff_patch current expected'

I would squash these two tests. As-is, the first one doesn't really test
anything (well, just that git log doesn't crash with log.follow).

I think you meant test_cmp, not compare_diff_patch, as you don't need
the similarity index and index ... filtering that compare_diff_patch
does before test_cmp.

That said, I see that you are mimicking surrounding code, which is a
good thing for consistancy. I think the best would be to write tests in
t4202-log.sh, which already tests the --follow option, and uses a more
modern coding style which you can mimick.
t4206-log-follow-harder-copies.sh is really about finding copies in
--follow. Another option is to start your series with a patch like
t4206: modernize style.

Or you can just accept that the current style in this file is subpar and
continue with it.

 +test_expect_success \
 +'git config log.follow does not die with multiple paths' \
 +'test_config log.follow true 
 + git log path0 path1  current 

You are creating 'current' but not using it.

 + wc -l current'

What is the intent of this wc -l current? You're not checking its
output ...

 +test_expect_success \
 +'git config log.follow does not die with no paths' \
 +'test_config log.follow true 
 + git log --  current 

One more creation of current which isn't used ...

 + wc -l current'
 +
 +test_expect_success \
 +'git config log.follow is overridden by --no-follow' \
 +'test_config log.follow true 
 + git log --no-follow --name-status --pretty=format:%s  path1  current'

... because you're overwriting it here.

 +cat expected \EOF
 +Copy path1 from path0
 +Apath1
 +EOF

Put everything in test_expect_..., including creation of expected file.
For more info, read t/README and its Do's, don'ts  things to keep in
mind section.

 +test_expect_success \
 +'validate the output.' \
 +'compare_diff_patch current expected'
 +
  test_done

Cheers,

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

Re: [PATCH v2] log: add log.follow config option

[Junio C Hamano]

David Turner dtur...@twopensource.com writes:

 diff --git a/revision.c b/revision.c
 index 3ff8723..ae6d4c3 100644
 --- a/revision.c
 +++ b/revision.c
 @@ -2322,12 +2322,21 @@ int setup_revisions(int argc, const char **argv, 
 struct rev_info *revs, struct s
  
   if (revs-prune_data.nr) {
   copy_pathspec(revs-pruning.pathspec, revs-prune_data);
 - /* Can't prune commits with rename following: the paths 
 change.. */
 - if (!DIFF_OPT_TST(revs-diffopt, FOLLOW_RENAMES))
 - revs-prune = 1;
 +
   if (!revs-full_diff)
   copy_pathspec(revs-diffopt.pathspec,
 revs-prune_data);
 +
 + if (DIFF_OPT_TST(revs-diffopt, DEFAULT_FOLLOW_RENAMES) 
 + revs-diffopt.pathspec.nr == 1)
 + DIFF_OPT_SET(revs-diffopt, FOLLOW_RENAMES);
 +
 + /* Can't prune commits with rename following: the paths 
 change.. */
 + if (!DIFF_OPT_TST(revs-diffopt, FOLLOW_RENAMES)) {
 + revs-prune = 1;
 + } else {
 + revs-diff = 1;
 + }
   }
   if (revs-combine_merges)
   revs-ignore_merges = 0;

It is unfortunate that we have to waste one DIFF_OPT bit and touch
revision.c for something that is just a convenience.  Because
setup_revisions() does not have a way to let you flip the settings
depending on the number of pathspecs specified, I do not think of a
solution that does not have to touch a low level foundation part of
the codebase, which I'd really want to avoid.

But I wonder why your patch needs to touch so much.

Your changes to other files make sure that diffopt has the
DEFAULT_FOLLOW_RENAMES when (1) the configuration is set and (2) the
command line did not override it with --no-follow.  And these look
very sensible.

Isn't the only thing left to do in this codepath, after the DEFAULT_
is set up correctly, to set FOLLOW_RENAMES when (1) DEFAULT_ is set
and (2) you have only one path?

And once FOLLOW_RENAMES is set or unset according to the end-user
visible semantics, i.e. just for a convenience, setting log.follow
adds --follow to the command line if and only if there is only one
pathspec, I do not see why existing code needs to be modified in
any other way.

IOW, I'd like to know why we need more than something like this
change to this file, instead of the above?  We didn't muck with
revs-diff in the original when FOLLOW_RENAMES was set, but now it
does, for example.

diff --git a/revision.c b/revision.c
index 3ff8723..f7bd229 100644
--- a/revision.c
+++ b/revision.c
@@ -2270,6 +2270,10 @@ int setup_revisions(int argc, const char **argv, struct 
rev_info *revs, struct s
got_rev_arg = 1;
}
 
+   if (DIFF_OPT_TST(revs-diffopt, DEFAULT_FOLLOW_RENAMES) 
+   revs-diffopt.pathspec.nr == 1)
+   DIFF_OPT_SET(revs-diffopt, FOLLOW_RENAMES);
+
if (prune_data.nr) {
/*
 * If we need to introduce the magic a lone ':' means no
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3] log: add log.follow config option

[David Turner]

Many users prefer to always use --follow with logs.  Rather than
aliasing the command, an option might be more convenient for some.

Signed-off-by: David Turner dtur...@twopensource.com
---
 Documentation/git-log.txt |  6 ++
 builtin/log.c |  7 +++
 diff.c|  5 +++--
 diff.h|  1 +
 revision.c| 14 +++---
 t/t4202-log.sh| 23 +++
 6 files changed, 51 insertions(+), 5 deletions(-)

diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 5692945..79bf4d4 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -184,6 +184,12 @@ log.date::
`--date` option.)  Defaults to default, which means to write
dates like `Sat May 8 19:35:34 2010 -0500`.
 
+log.follow::
+   If a single file argument is given to git log, it will act as
+   if the `--follow` option was also used.  This has the same
+   limitations as `--follow`, i.e. it cannot be used to follow
+   multiple files and does not work well on non-linear history.
+
 log.showRoot::
If `false`, `git log` and related commands will not treat the
initial commit as a big creation event.  Any root commits in
diff --git a/builtin/log.c b/builtin/log.c
index 8781049..6a068f7 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -31,6 +31,7 @@ static const char *default_date_mode = NULL;
 
 static int default_abbrev_commit;
 static int default_show_root = 1;
+static int default_follow;
 static int decoration_style;
 static int decoration_given;
 static int use_mailmap_config;
@@ -102,6 +103,8 @@ static void cmd_log_init_defaults(struct rev_info *rev)
 {
if (fmt_pretty)
get_commit_format(fmt_pretty, rev);
+   if (default_follow)
+   DIFF_OPT_SET(rev-diffopt, DEFAULT_FOLLOW_RENAMES);
rev-verbose_header = 1;
DIFF_OPT_SET(rev-diffopt, RECURSIVE);
rev-diffopt.stat_width = -1; /* use full terminal width */
@@ -390,6 +393,10 @@ static int git_log_config(const char *var, const char 
*value, void *cb)
default_show_root = git_config_bool(var, value);
return 0;
}
+   if (!strcmp(var, log.follow)) {
+   default_follow = git_config_bool(var, value);
+   return 0;
+   }
if (skip_prefix(var, color.decorate., slot_name))
return parse_decorate_color_config(var, slot_name, value);
if (!strcmp(var, log.mailmap)) {
diff --git a/diff.c b/diff.c
index 87b16d5..135b222 100644
--- a/diff.c
+++ b/diff.c
@@ -3815,9 +3815,10 @@ int diff_opt_parse(struct diff_options *options, const 
char **av, int ac)
DIFF_OPT_SET(options, FIND_COPIES_HARDER);
else if (!strcmp(arg, --follow))
DIFF_OPT_SET(options, FOLLOW_RENAMES);
-   else if (!strcmp(arg, --no-follow))
+   else if (!strcmp(arg, --no-follow)) {
DIFF_OPT_CLR(options, FOLLOW_RENAMES);
-   else if (!strcmp(arg, --color))
+   DIFF_OPT_CLR(options, DEFAULT_FOLLOW_RENAMES);
+   } else if (!strcmp(arg, --color))
options-use_color = 1;
else if (skip_prefix(arg, --color=, arg)) {
int value = git_config_colorbool(NULL, arg);
diff --git a/diff.h b/diff.h
index c7ad42a..f7208ad 100644
--- a/diff.h
+++ b/diff.h
@@ -91,6 +91,7 @@ typedef struct strbuf *(*diff_prefix_fn_t)(struct 
diff_options *opt, void *data)
 #define DIFF_OPT_DIRSTAT_BY_LINE (1  28)
 #define DIFF_OPT_FUNCCONTEXT (1  29)
 #define DIFF_OPT_PICKAXE_IGNORE_CASE (1  30)
+#define DIFF_OPT_DEFAULT_FOLLOW_RENAMES (1  31)
 
 #define DIFF_OPT_TST(opts, flag)((opts)-flags  DIFF_OPT_##flag)
 #define DIFF_OPT_TOUCHED(opts, flag)((opts)-touched_flags  
DIFF_OPT_##flag)
diff --git a/revision.c b/revision.c
index 3ff8723..5b0c2be 100644
--- a/revision.c
+++ b/revision.c
@@ -2322,12 +2322,20 @@ int setup_revisions(int argc, const char **argv, struct 
rev_info *revs, struct s
 
if (revs-prune_data.nr) {
copy_pathspec(revs-pruning.pathspec, revs-prune_data);
-   /* Can't prune commits with rename following: the paths 
change.. */
-   if (!DIFF_OPT_TST(revs-diffopt, FOLLOW_RENAMES))
-   revs-prune = 1;
+
if (!revs-full_diff)
copy_pathspec(revs-diffopt.pathspec,
  revs-prune_data);
+
+   if (DIFF_OPT_TST(revs-diffopt, DEFAULT_FOLLOW_RENAMES) 
+   revs-diffopt.pathspec.nr == 1)
+   DIFF_OPT_SET(revs-diffopt, FOLLOW_RENAMES);
+
+   /* Can't prune commits with rename following: the paths 
change.. */
+   if (!DIFF_OPT_TST(revs-diffopt, FOLLOW_RENAMES))
+   revs-prune = 1;
+   else
+   revs-diff = 1;
}
if (revs-combine_merges)

Re: Git force push fails after a rejected push (unpack failed)?

[Eric Sunshine]

On Tue, Jul 7, 2015 at 3:49 PM, Jeff King p...@peff.net wrote:
 On Tue, Jul 07, 2015 at 09:31:25PM +0200, X H wrote:

 For the moment, I'm the only one pushing to the remote, always with
 the same user (second user is planned). I use git-for-windows which is
 based on MSYS2. I have mounted the network share with noacl option so
 permissions should be handled by the Windows share. I'm in a group
 which has read/write access. I have not configured
 core.sharedrepository, I don't think it is useful with noacl since
 unix group are not used in this case. The permission for the folder
 above the file with permission denied is rw, but this file is read
 only so if git try to modify it it won't work.

 Ah, so this is not a push to a server, but to a share mounted on the
 local box?

 That is leaving my realm of expertise. I'm not sure if it could be a
 misconfiguration in your share setup, or that git is trying to do
 something that would work on a Unix machine, but not on a Windows share.
 You might want to ask on the msysgit list:

   https://groups.google.com/forum/#!forum/msysgit

Is this possibly another case of Windows virus scanner interference?
That could account for its variable nature.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 5/7] refs: new public ref function: safe_create_reflog

[David Turner]

On Mon, 2015-07-06 at 18:21 +0200, Michael Haggerty wrote:

snip changes applied; will re-roll.

  +
  +int safe_create_reflog(const char *refname, struct strbuf *err, int 
  force_create)
  +{
  +   int ret;
  +   struct strbuf sb = STRBUF_INIT;
  +
  +   ret = log_ref_setup(refname, sb, err, force_create);
  +   strbuf_release(sb);
  +   return ret;
  +}
  +
 
 Is it really necessary to have two functions, safe_create_reflog() and
 log_ref_setup()? I don't see any of the callers doing anything special
 with the sb_logfile argument from the latter, so maybe it could be
 inlined into safe_create_reflog()? Maybe I'm overlooking something.

log_ref_write_1 does use the sb_logfile argument.

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

Re: [PATCH v6 3/4] status: give more information during rebase -i

[Junio C Hamano]

By the way, does this have any potential interaction with 16cf51c7
(git-rebase--interactive.sh: add config option for custom
instruction format, 2015-06-13)?  I _think_ that the other topic
should only affect the collapsed format, so there hopefully
shouldn't be a problem, but just double checking if you folks
considered the ramifications already.

Thanks.

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

What's cooking in git.git (Jul 2015, #02; Tue, 7)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.

As there is at least one new topic in 2.5-rc that has a real and
severe breakage (I haven't merged the fix for it to 'master' yet),
we may probably need to delay the final by at least a few weeks.

Projects from GSoC students and Ensimag students have also been a
pleasure to work with.  I'd have to say that this year is much
better than some previous years.

You can find the changes described here in the integration branches
of the repositories listed at

http://git-blame.blogspot.com/p/git-public-repositories.html

--
[New Topics]

* es/worktree-add (2015-07-07) 23 commits
 - checkout: retire --ignore-other-worktrees in favor of --force
 - worktree: add: auto-vivify new branch when branch is omitted
 - worktree: add: make -b/-B default to HEAD when branch is omitted
 - worktree: extract basename computation to new function
 - checkout: require worktree unconditionally
 - checkout: retire --to option
 - tests: worktree: retrofit checkout --to tests for worktree add
 - worktree: add -b/-B options
 - worktree: add --detach option
 - worktree: add --force option
 - worktree: introduce add command
 - checkout: drop 'checkout_opts' dependency from prepare_linked_checkout
 - checkout: make --to unconditionally verbose
 - checkout: prepare_linked_checkout: drop now-unused 'new' argument
 - checkout: relocate --to's no branch specified check
 - checkout: fix bug with --to and relative HEAD
 - Documentation/git-worktree: add EXAMPLES section
 - Documentation/git-worktree: add high-level 'lock' overview
 - Documentation/git-worktree: split technical info from general description
 - Documentation/git-worktree: add BUGS section
 - Documentation: move linked worktree description from checkout to worktree
 - Documentation/git-worktree: associate options with commands
 - Documentation/git-checkout: fix incorrect worktree prune command
 (this branch uses nd/multiple-work-trees.)

 Update to the linked checkout in 2.5.0-rc1; while I very much
 like what I see in this series, I think it does not work well with
 the date-based release schedule for v2.5, and as we've been
 labelling the feature with experimental, UI will change warning,
 I am tempted to cook this (or a reroll of it) in 'next' and shoot
 for a refined version of it in 2.6, rather than delaying 2.5 final.

 An alternative obviously is to slip 2.5 final for a few weeks,
 waiting for this and possibly other hotfix topics to mature.

 Undecided.


* jc/fix-alloc-sortbuf-in-index-pack (2015-07-04) 1 commit
  (merged to 'next' on 2015-07-06 at c05da06)
 + index-pack: fix allocation of sorted_by_pos array

 Another hotfix for what is in 2.5-rc but not in 2.4

 The alternative to slip 2.5 final for a few weeks starting to
 become more and more attractive...


* jc/unexport-git-pager-in-use-in-pager (2015-07-03) 1 commit
 - pager: do not leak GIT_PAGER_IN_USE to the pager

 When you say !ENTER while running say git log, you'd confuse
 yourself in the resulting shell, that may look as if you took
 control back to the original shell you spawned git log from but
 that isn't what is happening.  To that new shell, we leaked
 GIT_PAGER_IN_USE environment variable that was meant as a local
 communication between the original Git and subprocesses that was
 spawned by it after we launched the pager, which caused many
 interesting things to happen, e.g. git diff | cat still paints
 its output in color by default.

 Stop leaking that environment variable to the pager's half of the
 fork; we only need it on Git side when we spawn the pager.

 Will merge to 'next'.


* mh/strbuf-read-file-returns-ssize-t (2015-07-03) 1 commit
 - strbuf: strbuf_read_file() should return ssize_t

 Will merge to 'next'.


* mm/branch-doc-updates (2015-07-06) 2 commits
 - Documentation/branch: document -M and -D in terms of --force
 - Documentation/branch: document -d --force and -m --force

 Will merge to 'next'.


* pt/am-tests (2015-07-07) 12 commits
 - t3901: test git-am encoding conversion
 - t3418: non-interactive rebase --continue with rerere enabled
 - t4150: tests for am --[no-]scissors
 - t4150: am with post-applypatch hook
 - t4150: am with pre-applypatch hook
 - t4150: am with applypatch-msg hook
 - t4150: am --resolved fails if index has unmerged entries
 - t4150: am --resolved fails if index has no changes
 - t4150: am refuses patches when paused
 - t4151: am --abort will keep dirty index intact
 - t4150: am fails if index is dirty
 - t4150: am.messageid really adds the message id

 Will merge to 'next'.


* kn/for-each-tag-branch (2015-07-07) 11 commits
 - for-each-ref: add '--contains' option
 - ref-filter: implement '--contains' option
 - parse-options.h: add macros for '--contains' option
 - parse-option: rename parse_opt_with_commit()
 - for-each-ref: add '--merged' and 

Re: refspecs with '*' as part of pattern

[Jacob Keller]

On Tue, Jul 7, 2015 at 9:28 AM, Junio C Hamano gits...@pobox.com wrote:
 Daniel Barkalow barka...@iabervon.iabervon.org writes:

 On Mon, 6 Jul 2015, Junio C Hamano wrote:

 I cannot seem to be able to find related discussions around that
 patch, so this is only my guess, but I suspect that this is to
 discourage people from doing something like:

  refs/tags/*:refs/tags/foo-*

 which would open can of worms (e.g. imagine you fetch with that
 pathspec and then push with refs/tags/*:refs/tags/* back there;
 would you now get foo-v1.0.0 and foo-foo-v1.0.0 for their v1.0.0
 tag?) we'd prefer not having to worry about.

 That wouldn't be it, since refs/tags/*:refs/tags/foo/* would have the same
 problem, assuming you didn't set up the push refspec carefully.

 Thanks, I was wondering where you were ;-)  Nice to hear from you
 from time to time.

 I think it was mostly that it would be too easy to accidentally do
 something you don't want by having some other character instead of a
 slash, like refs/heads/*:refs/heads-*.

 Hmm, interesting thought.

 But refs/heads/*:refs/heade/* would not be saved, so I do not think
 that is it, either.

In this case, I'm more in favor of just allowing these refs because
the user already has to manually change the refspecs, which is
something many users will never do. I also think that given the above
comments, we're not really protecting the user from anything extra...
aside from adding more pain because the globs don't work as expected.

I did submit a patch (from my @intel.com address since I can't seem to
get git-for-windows to send from my home computer) but I am willing to
re-work to drop the setting if everyone is ok with that...

Thoughts?

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

Re: [msysGit] Re: [PATCH 13/17] engine.pl: provide more debug print statements

[Philip Oakley]

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

On 25.06.2015 02:03, Philip Oakley wrote:


--- a/contrib/buildsystems/engine.pl
+++ b/contrib/buildsystems/engine.pl
@@ -41,6 +41,7 @@ EOM
  # Parse command-line options
  while (@ARGV) {
  my $arg = shift @ARGV;
+ #print Arg: $arg \n;
  if ($arg eq -h || $arg eq --help || $arg eq -?) {
  showUsage();
  exit(0);
@@ -129,6 +130,7 @@ sub parseMakeOutput
  print Parsing GNU Make output to figure out build
structure...\n;
  my $line = 0;
  while (my $text = shift @makedry) {
+ #print Make: $text\n; # show the makedry line


Please never commit code that's been commented out. Also see

http://dev.solita.fi/2013/07/04/whats-in-a-good-commit.html

;-)


The gif was fun, even if it's a little OTT. It does smack of religious
dogma though ;-)



--


Hi Sebastian,

It's deactivated code, not dead code [1].

I'd deliberately included this 'code', as per the commit message because
I saw this as a clear part of aiding future maintenance, and it matches
the rest of the code style, i.e. the judicious placement of a comment
that says 'here's the place to pick out the status when debugging' -
perhaps it's my engineering experience that sees the benefits.

These were the key debug points I used - other's I've removed from the 
series.


Philip


[1] In one of the replies to
http://embeddedgurus.com/barr-code/2013/02/dead-code-the-law-and-unintended-consequences/

: as per DO178B safety critical software development guideline
document Terms Dead code and Deactivated Code have distinct 
meanings:


Dead code : Dead code is source code (and it is a part of binary code)
that is not executed in the final system and it will be not having
traceability to any requirements (one can say unintentional code).

Deactivated code: code which is commented out or removed via #ifdef's
(it is not a part of final binary code) and it will be having
traceability to its low level requirements (its a intentional code and
it can be activated in some configurations through hardware traps for
debugging or other purposes.


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

Re: [PATCH v6 1/7] refs.c: add err arguments to reflog functions

[David Turner]

On Mon, 2015-07-06 at 17:53 +0200, Michael Haggerty wrote:
 On 06/29/2015 10:17 PM, David Turner wrote:
  Add an err argument to log_ref_setup that can explain the reason
  for a failure. This then eliminates the need to manage errno through
  this function since we can just add strerror(errno) to the err string
  when meaningful. No callers relied on errno from this function for
  anything else than the error message.
  
  Also add err arguments to private functions write_ref_to_lockfile,
  log_ref_write_1, commit_ref_update. This again eliminates the need to
  manage errno in these functions.
  
  Update of a patch by Ronnie Sahlberg.
 
 First a general comment: we have a convention, not yet very well adhered
 to, that error messages should start with lower-case letters. I know
 that in many cases you are just carrying along pre-existing error
 messages that are capitalized. But at a minimum, please avoid adding new
 error messages that are capitalized. And if you are feeling ambitious,
 feel free to lower-case some existing ones :-)

I'll save lowercasing messages for other patches, but I'll try to take
care with new messages.

...

 Above, the call to close(logfd) could clobber errno. It would be better
 to exchange the calls.

Done, thanks.

 Since you are passing err into log_ref_write(), I assume that it would
 already have an error message written to it by the time you enter into
 this block. Yet in the block you append more text to it.
 
 It seems to me that you either want to clear err and replace it with
 your own message, or create a new message that looks like
 
 Cannot update the ref '%s': %s
 
 where the second %s is replaced with the error from log_ref_write().

Done, thanks.

  @@ -3317,7 +3322,8 @@ static int commit_ref_update(struct ref_lock *lock,
head_sha1, head_flag);
  if (head_ref  (head_flag  REF_ISSYMREF) 
  !strcmp(head_ref, lock-ref_name))
  -   log_ref_write(HEAD, lock-old_oid.hash, sha1, logmsg);
  +   log_ref_write(HEAD, lock-old_oid.hash, sha1, logmsg,
  + err);
 
 Here you don't check for errors from log_ref_write(). So it might or
 might not have written something to err. If it has, is that error
 handled correctly?

That was the case before this patch too. But I guess I might as well
check.

 Previously, the error generated here was cannot update the ref '%s'.
 But now that you are letting write_ref_to_lockfile() fill err, the error
 message will be something from that function. This might be OK or it
 might not. If you think it is, it would be worth a word or two of
 justification in the commit message.

Will adjust commit message.

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

[PATCH] git: add optional support for full pattern in fetch refspecs

[Jacob Keller]

This patch updates the refs.c check_refname_component logic in order to
allow for the possibility of using arbitrary patterns in fetch refspecs.
Specifically, patterns similar to `refs/tags/prefix-*:refs/tags/prefix-*`.

In order to ensure that standard users do not accidentally setup refspecs
which could cause issues, tie this feature to
remote.name.arbitrary_pattern boolean configuration option. This ensures
that no user will have this enabled on accident.

The primary reason against this is the ability to pull refs incorrectly
and then later push them again. Ie:

refs/tags/some-prefix-*:/refs/tags/other-prefix-*

This ref will essentially re-name the references locally. This is
generally not what you would want but there is no easy way to validate
this doesn't occur. Note this can already occur to normal pattern refspecs
via `refs/tags/*:refs/tags/namespace/*` refspecs, but these are a bit more
difficult to typo.

However, the additional functionality is useful for specifying to pull
certain patterns of refs, and can be useful if the power user decides to
enable it for a given remote.

Signed-off-by: Jacob Keller jacob.kel...@gmail.com
Cc: Daniel Barkalow barka...@iabervon.iabervon.org
Cc: Junio C Hamano gits...@pobox.com
---
 Documentation/config.txt   |  7 +
 Documentation/git-check-ref-format.txt | 12 ++---
 builtin/check-ref-format.c |  2 ++
 refs.c | 48 ++
 refs.h | 15 ++-
 remote.c   |  2 ++
 remote.h   |  1 +
 7 files changed, 61 insertions(+), 26 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 3e37b93ed2ac..626492de7a7f 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2331,6 +2331,13 @@ remote.name.prune::
remote (as if the `--prune` option was given on the command line).
Overrides `fetch.prune` settings, if any.
 
+remote.name.arbitrarypattern::
+   When set to true, fetching from this remote will allow arbitrary complex
+   patterns for the fetch refspecs. For example,
+   refs/tags/prefix-*:refs/tags/prefix-* will work as expected. Care 
should be
+   taken as you could fetch refs into names that don't exist on the remote 
and
+   may end up pushing them again later by accident.
+
 remotes.group::
The list of remotes which are fetched by git remote update
group.  See linkgit:git-remote[1].
diff --git a/Documentation/git-check-ref-format.txt 
b/Documentation/git-check-ref-format.txt
index fc02959ba4ab..caab0e3037fa 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -43,8 +43,8 @@ Git imposes the following rules on how references are named:
   caret `^`, or colon `:` anywhere.
 
 . They cannot have question-mark `?`, asterisk `*`, or open
-  bracket `[` anywhere.  See the `--refspec-pattern` option below for
-  an exception to this rule.
+  bracket `[` anywhere.  See the `--refspec-pattern` and `--arbitrary-pattern`
+  options below for exceptions to this rule.
 
 . They cannot begin or end with a slash `/` or contain multiple
   consecutive slashes (see the `--normalize` option below for an
@@ -95,7 +95,13 @@ OPTIONS
(as used with remote repositories).  If this option is
enabled, refname is allowed to contain a single `*`
in place of a one full pathname component (e.g.,
-   `foo/*/bar` but not `foo/bar*`).
+   `foo/*/bar` but not `foo/bar*`). If '--arbitrary-pattern' is set, then
+   a single `foo/bar*baz` pattern will be accepted.
+
+--arbitrary-pattern::
+   If '--refspec-pattern' is set, allow arbitrary patterns instead of the
+   default simple case. Implies '--refspec-pattern'. Note that only one '*'
+   pattern will be accepted.
 
 --normalize::
Normalize 'refname' by removing any leading slash (`/`)
diff --git a/builtin/check-ref-format.c b/builtin/check-ref-format.c
index fd915d59841e..e0b8d00d5337 100644
--- a/builtin/check-ref-format.c
+++ b/builtin/check-ref-format.c
@@ -70,6 +70,8 @@ int cmd_check_ref_format(int argc, const char **argv, const 
char *prefix)
flags = ~REFNAME_ALLOW_ONELEVEL;
else if (!strcmp(argv[i], --refspec-pattern))
flags |= REFNAME_REFSPEC_PATTERN;
+   else if (!strcmp(argv[i], --arbitrary-pattern))
+   flags |= REFNAME_ARBITRARY_PATTERN | 
REFNAME_REFSPEC_PATTERN;
else
usage(builtin_check_ref_format_usage);
}
diff --git a/refs.c b/refs.c
index 7ac05cf21a25..e4c24bfc778c 100644
--- a/refs.c
+++ b/refs.c
@@ -20,11 +20,12 @@ struct ref_lock {
  * 2: ., look for a preceding . to reject .. in refs
  * 3: {, look for a preceding @ to reject @{ in refs
  * 4: A bad character: ASCII control characters, ~, ^, : or SP
+ * 5: 

Re: Whether Git supports directory level access or not?

[Jacob Keller]

On Tue, Jul 7, 2015 at 10:03 AM, Junio C Hamano gits...@pobox.com wrote:
 Jacob Keller jacob.kel...@gmail.com writes:

 However, in-repo per-directory permissions make no sense, as there
 would be no way to generate commits.

 That may be the case for the current generation of Git, but I do not
 think you have to be so pessimistic.

 Suppose that an imaginary future version of Git allowed you to
 hide one directory from you.  That is:

  * A commit object records tree. git cat-file -t HEAD^{tree}
or git ls-tree HEAD lets you inspect its contents;

  * The hidden directory shows up as one of the subtrees of that
output.  It may say

  04 tree b4006c408979a0c6261dbfaeaa36639457469ad4   hidden

  * However, your repository lack b4006c40... object.  So if you did
git ls-tree HEAD:hidden, you would get no such tree object.

  * This imaginary future version of Git has a new implementation of
the index (both on-disk and in-core) that lets you keep just the
tree entry for an unmodified directory, without having to store
any of the files and subdirectories in it.

  * All the other machinery of this imaginary future version of Git
are aware of the fact that hidden thing is not visible, or even
available, to your clone of the project repository.  That means
fsck does not complain about missing object b4006c40..., push
knows it should not consider it an error that you cannot enumerate
and send objects that are reachable from b4006c40..., etc.

 With such a Git, you can modify anything outside the parts of the
 project tree that are hidden from you, and make a commit.  The tree
 recorded in a new commit object would record the same

  04 tree b4006c408979a0c6261dbfaeaa36639457469ad4   hidden

 for the hidden directory, and you can even push it back to update
 the parts for other people to see your work outside the hidden
 area.

 All the other machinery that would need to accomodate such a
 hidden directory would span the entire plumbing layer and
 transports.  The wire protocol would need to be updated, especially
 the part that determines what needs to be sent and received, which
 is currently purely on commit ancestry, needs to become aware of the
 paths.

 I am *NOT* saying that this is easy.  I'd imagine if we gather all
 the competent Gits in a room and have them work on it and doing
 nothing else for six months, we would have some system that works.
 It would be a lot of work.

 I think it may be worth doing in the longer term, and it will likely
 to have other benefits as side effects.

  - For example, did you notice that my description above does not
mention permission even once?  Yes, that's right.  This does
not have to be limited to permissions.  The user may have decided
that the hidden part of that directory structure is not
interesting and said git clone --exclude=hidden when she made
her clone to set it up.

  - Also notice that the new implementation of the index that
lazily expands subtrees does not say anythying about a directory
that is hidden---it just said an unmodified directory and
that was deliberate.  Even when you are not doing a narrow
clone, keeping an untouched tree without expanding its subtrees
and blobs flatted into the index may make it faster when you are
working on a series of many small commits each of which touches
only a handful of files.

 I might agree with you that in-repo per-directory permissions make
 no sense, but the reason to say so would not be because there
 would be no way to generate commits.

Actually as you laid out here, it does make sense I had just assumed
you would need the tree object to actually be able to generate the
commits. It does sound like a lot of work though.

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

Re: [PATCH v2] log: add log.follow config option

[David Turner]

On Tue, 2015-07-07 at 23:42 +0200, Matthieu Moy wrote:
 Hi,
 
 Thanks for your patch. Below are some comments. Some of them are just me
 thinking out loudly (don't take it badly if I'm being negative), some
 are more serious, but all are fixable.

Thanks for the feedback!

 David Turner dtur...@twopensource.com writes:
 
  From: David Turner dtur...@twitter.com
 
 If you configure your commiter id and your From field to the same value,
 you can avoid this distracting From: header.
 
 You're lacking a Signed-off-by trailer.

Oops.  Cherry-picked over from internal repo.  Will fix.

snip (suggestions applied)

  + git log --name-status --pretty=format:%s  path1  current'
 
 Whitespace: here an elsewhere, you have two spaces before path1, and we
 usually stick the  to the filename like current.

  --- a/t/t4206-log-follow-harder-copies.sh
  +++ b/t/t4206-log-follow-harder-copies.sh
  @@ -53,4 +53,39 @@ test_expect_success \
   'validate the output.' \
   'compare_diff_patch current expected'
   
  +test_expect_success \
  +'git config log.follow works like --follow' \
  +'test_config log.follow true 
  + git log --name-status --pretty=format:%s  path1  current'
  +
  +test_expect_success \
  +'validate the output.' \
  +'compare_diff_patch current expected'
 
 I would squash these two tests. As-is, the first one doesn't really test
 anything (well, just that git log doesn't crash with log.follow).
 
 I think you meant test_cmp, not compare_diff_patch, as you don't need
 the similarity index and index ... filtering that compare_diff_patch
 does before test_cmp.
 
 That said, I see that you are mimicking surrounding code, which is a
 good thing for consistancy. I think the best would be to write tests in
 t4202-log.sh, which already tests the --follow option, and uses a more
 modern coding style which you can mimick.
 t4206-log-follow-harder-copies.sh is really about finding copies in
 --follow. Another option is to start your series with a patch like
 t4206: modernize style.

I'm going to move over to t4202.  My next re-roll will include fixes for
everything you raised.  

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

Re: [PATCH v3 23/23] checkout: retire --ignore-other-worktrees in favor of --force

[Eric Sunshine]

On Tue, Jul 7, 2015 at 12:20 PM, Junio C Hamano gits...@pobox.com wrote:
 Eric Sunshine sunsh...@sunshineco.com writes:
 I would not mind git worktree add -f to disable the no multiple
 checkouts of the same branch safety, but I do not think it is
 sensible to remove -i-o-w and conflate everything into --force.
 That would force people to disable other safety measures at the same
 time (e.g. protect local changes from differences between the
 current and next branches).

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

Re: [PATCH v4 04/44] builtin-am: implement patch queue mechanism

[Paul Tan]

On Mon, Jun 29, 2015 at 1:08 PM, Stefan Beller sbel...@google.com wrote:
 (optional nit, bikeshedding)
 In conjunction with the previous patch I just wonder when we put a
 TODO and when we want to put a NEEDSWORK, or if we're being
 inconsistent here as both issues will be resolved in a later patch
 in the series.

That's a code style thing that I don't personally have a strong opinion about.

Not sure if the following means anything, but on master,

git grep '\bTODO\b' | wc -l
102

git grep '\bNEEDSWORK\b' | wc -l
45

git log -G'\bTODO\b --oneline | wc -l
185

git log -G'\bNEEDSWORK\b' --oneline | wc -l
120

So it does seem that temporary stuff is usually tagged with
NEEDSWORK, rather than TODO.

Anyway, it's probably better to be consistent, so I will switch to NEEDSWORK.

Thanks,
Paul
--
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: undocumented core.sharedRepository=2 set by git init --shared=world

[John Keeping]

On Tue, Jul 07, 2015 at 01:32:13PM +0200, Johannes Schindelin wrote:
 Hi John,
 
 On 2015-07-07 11:10, John Keeping wrote:
  On Tue, Jul 07, 2015 at 10:14:28AM +0200, Johannes Schindelin wrote:
  Hi Joey,
 
  On 2015-07-06 21:25, Joey Hess wrote:
   joey@darkstar:~/tmpgit init --shared=world testrepo
   Initialized empty shared Git repository in /home/joey/tmp/testrepo/.git/
   joey@darkstar:~/tmpgrep shared testrepo/.git/config
sharedrepository = 2
  
   This magic value of 2 seems to be undocumented, as is the magic value of 
   1
   that's equvilant to group.
  
   I think it would be better to have git init put in world or group 
   and not
   these magic values. Anyway, I suppose they ought to be documented too.
 
  The rationale can be found here:
  https://github.com/git/git/blob/v2.4.5/builtin/init-db.c#L413-L418
 
 /* We do not spell group and such, so that
  * the configuration can be read by older version
  * of git. Note, we use octal numbers for new share modes,
  * and compatibility values for PERM_GROUP and
  * PERM_EVERYBODY.
  */
 
  I am sympathetic to your wish, of course, and I am sure that you
  understand why we cannot simply break other people's setups to satisfy
  it.
  
  That comment was added in 94df250 (shared repository: optionally allow
  reading to others., 2006-06-09) which was in 1.4.1.  I suspect that is
  now sufficiently old that it no longer matters.
 
 I understand your point of view. With my maintainer hat on I have to
 say, though, that things like that require a major version change.
 Users tend to appreciate such a careful maintenance.

However, there has been a major version since the new syntax was
introduced (in the same commit mentioned above), so this only affects
users who initialize a repository with (say) 2.6.0 or later and then try
to use 1.4.0 or earlier to operate on it.

That means using two versions of Git released more than 9 years apart to
operate on the same repository.  IMHO even careful maintenance can
declare that an unsupported configuration.
--
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 grep does not support multi-byte characters (like UTF-8)

[Duy Nguyen]

On Tue, Jul 7, 2015 at 3:58 PM, Plamen Totev plamen.to...@abv.bg wrote:
 Nguyen, thanks for the help and the patch. Also the escaping suggested by 
 Scharfe seems as good choice. But i dig some more into the problem and I 
 found some other thing. That's why I replied on the main thread not on the 
 patch. I hope you'll excuse me if this is a bad practice.

So far this is very good reporting. I can't complain :)

 git grep -i -P also does not works because the PCRE_UTF8 is not set and pcre 
 library does not treat the string as UTF-8.

We do prefer utf-8, but i don't know if we can assume utf-8 everywhere
yet. I guess it's ok in this case.

 pickaxe search also uses kwsearch so the case insensitive search with it does 
 not work (e.g. git log -i -S).  Maybe this is a less of a problem here as one 
 is expected to search for exact string (hence knows the case)

Will fix (i'm close to being done with git-grep, not counting the pcre
bug you just found)

 There is a interesting corner case. is_fixed treats all patterns containing 
 nulls as fixed. So what about if the string contains non-ASCII symbols as 
 well as nulls and the search is case insensitive :) I have to admin that my 
 knowledge in UTF-8 is not enough to answer the question if this could occur 
 during normal usage. For example the second byte in multi-byte symbol is 
 NULL. I would guess that's not true as it would break a lot of programs that 
 depend on NULL delimited string but it's good if somebody could confirm.

For utf-8, if NUL occurs in a byte stream, it must be ASCII NUL, not
part of any multibyte character. Utf-8 is really well tuned for C
strings.

 GNU grep indeed uses escaped regular expressions when the string is using 
 multi-byte encoding and the search is case insensitive. If the encoding is 
 UTF-8 then this strategy could be used in git too. Especially that git 
 already have support and helper functions to work with UTF-8. As for the 
 other multi-byte encodings - I think the things would become more 
 complicated. As far I know in UTF-8 the '{' character for example is two 
 bytes not one. Maybe really a support could be added only for the UTF-8 and 
 if the string is not UTF-8 to issue a warning.

In the worst case we could reuse the trick we do elsewhere in git:
convert to utf-8 with iconv, do whatever we need to (escaping...) then
convert back before feeding it to regcomp and friends.

 So maybe the following makes sense when a grep search is performed:
 * check if the multi-byte encoding is used. If it's and the search is case 
 insensitive and the encoding is not UTF-8 give a warning;
 * if pcre is used and the string is UTF-8 encoded set the PCRE_UTF8 flag;
 * if the search is case insensitive, the string is fixed and the encoding  
 used is UTF-8 use regcomp instead of kwsearch and escape any regex special 
 characters in the pattern;

 And the question with the behavior of pickaxe search remains open. Using 
 kwset does not work with case insensitive non-ASCII searches. Instead of 
 fixing grep.c maybe it's better if new function is introduced that performs 
 keyword searches so it could be used by both grep, diffcore-pickaxe and any 
 other code in the future that may require such functionality. Or maybe 
 diffcore-pickaxe should use grep instead of directly kwset/regcomp

That would function be called grep. More refactor would be needed.
git grep regcomp reveals some many places. Many some of them would
benefit from kws if we provide this new function you mentioned.

 Regards,
 Plamen Totev



 Оригинално писмо 
От: Duy Nguyen pclo...@gmail.com
Относно: Re: Git grep does not support multi-byte characters (like UTF-8)
До: Plamen Totev plamen.to...@abv.bg
Изпратено на: 06.07.2015 15:23

 I think we over-optimized a bit. If you your system provides regex
 with locale support (e.g. Linux) and you don't explicitly use fallback
 regex implementation, it should work. I suppose your test patterns
 look fixed (i.e. no regex special characters)? Can you try just add
 . and see if case insensitive matching works?

 This is indeed the problem. When I added the . the matching works just fine.



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

Re: [PATCH v3 23/23] checkout: retire --ignore-other-worktrees in favor of --force

[Eric Sunshine]

On Tue, Jul 7, 2015 at 4:24 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
 On Mon, Jul 6, 2015 at 3:40 PM, Junio C Hamano gits...@pobox.com wrote:
 If you are extending the history of some branch, then you would want
 to be on that branch.  Why would you want to have another worktree
 that will get into a confusing state once you create that commit on
 the checked out branch in this newly created worktree?

 Wasn't the whole point of making the primary repository aware of the
 secondary worktrees via the linked checkout mechanism because that
 confusion was the biggest sore point of the old contrib/workdir
 implementation?

 I [...] probably lack understanding of the finer points to make a
 cogent argument for or against.

Is receive.denyCurrentBranch worth mentioning as an argument? Although
pushing a branch into a non-bare repo where that branch is already
checked out is normally disallowed, receive.denyCurrentBranch
overrides the safeguard. Presumably, the user has experience and
knowledge to know that git reset --hard will be required to sync
things up.

Using --force or --ignore-other-worktrees (or whatever) to override
git-checkout's normal safeguard against checking out a branch into
more than one linked-worktree parallels receive.denyCurrentBranch,
doesn't it? There is a certain amount of precedent elsewhere in Git
for allowing a person to shoot himself in the foot.
--
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 v7 07/10] send-email: reduce dependencies impact on parse_address_line

[Torsten Bögershausen]

#!/usr/bin/perl

Should we have hard-coded PATH to perl here ?

/usr/bin/perl --version
This is perl, v5.10.0 built for darwin-thread-multi-2level
(with 2 registered patches, see perl -V for more detail)

 +
 +my $is_passing = Test::More-builder-is_passing;
 +exit($is_passing ? 0 : 1);
 

This seems to give problems:
debug=t verbose=t ./t9000-addresses.sh

Initialized empty Git repository in /Users/me/projects/git/git.pu/t/trash 
directory.t9000-addresses/.git/
# run 0: Perl address parsing function (perl 
/Users/me/projects/git/git.pu/t/t9000/test.pl)
ok 1 - use Git;
ok 2 - same output : Jane
ok 3 - same output : j...@example.com
ok 4 - same output : j...@example.com
ok 5 - same output : Jane j...@example.com
ok 6 - same output : Jane Doe j...@example.com
ok 7 - same output : Jane j...@example.com
ok 8 - same output : Doe, Jane j...@example.com
ok 9 - same output : Jane@:;\.,()Doe j...@example.com
ok 10 - same output : Jane!\#$%'*+-/=?^_{|}~Doe' j...@example.com
ok 11 - same output : j...@example.com
ok 12 - same output : Jane j...@example.com
ok 13 - same output : Jane Doe jdoe@   example.com  
ok 14 - same output : Jane   Doe   j...@example.com  
ok 15 - same output : Jane @ Doe @ Jane @ Doe
ok 16 - same output : Jane, 'Doe' j...@example.com
ok 17 - same output : 'Doe, Jane' j...@example.com
ok 18 - same output : Jane Doe j...@example.com
ok 19 - same output : Jane' Doe j...@example.com
ok 20 - same output : Jane Doe j...@example.com j...@example.com
ok 21 - same output : Jane\ Doe j...@example.com
ok 22 - same output : Doe, jane j...@example.com
ok 23 - same output : Jane Doe j...@example.com
ok 24 - same output : 'Jane 'Doe' j...@example.com
not ok 25 - same output : Jane\ Doe j...@example.com # TODO known breakage
#   Failed (TODO) test 'same output : Jane\ Doe j...@example.com'
#   at /Users/me/projects/git/git.pu/t/t9000/test.pl line 62.
# Structures begin differing at:
#  $got-[0] = 'Jane \ Doe j...@example.com'
# $expected-[0] = 'Jane\ Doe j...@example.com'
not ok 26 - same output : Doe, Jane j...@example.com # TODO known breakage
#   Failed (TODO) test 'same output : Doe, Jane j...@example.com'
#   at /Users/me/projects/git/git.pu/t/t9000/test.pl line 62.
# Structures begin differing at:
#  $got-[0] = 'Doe, Ja ne j...@example.com'
# $expected-[0] = 'Doe, Ja ne j...@example.com'
not ok 27 - same output : Doe, Katarina Jane j...@example.com # TODO known 
breakage
#   Failed (TODO) test 'same output : Doe, Katarina Jane j...@example.com'
#   at /Users/me/projects/git/git.pu/t/t9000/test.pl line 62.
# Structures begin differing at:
#  $got-[0] = 'Doe, Katarina Jane j...@example.com'
# $expected-[0] = 'Doe, Katarina Jane j...@example.com'
not ok 28 - same output : Jane@:;\.,()Doe j...@example.com # TODO known 
breakage
#   Failed (TODO) test 'same output : Jane@:;\.,()Doe j...@example.com'
#   at /Users/me/projects/git/git.pu/t/t9000/test.pl line 62.
# Structures begin differing at:
#  $got-[1] = '\.'
# $expected-[1] = '\.'
not ok 29 - same output : Jane j...@example.com # TODO known breakage
#   Failed (TODO) test 'same output : Jane j...@example.com'
#   at /Users/me/projects/git/git.pu/t/t9000/test.pl line 62.
# Structures begin differing at:
#  $got-[0] = 'Jane'
# $expected-[0] = 'janej...@example.com'
not ok 30 - same output : j...@example.com Jane Doe # TODO known breakage
#   Failed (TODO) test 'same output : j...@example.com Jane Doe'
#   at /Users/me/projects/git/git.pu/t/t9000/test.pl line 62.
# Structures begin differing at:
#  $got-[0] = 'Jane Doe j...@example.com'
# $expected-[0] = 'jdoe@example.comJaneDoe'
not ok 31 - same output : Jane j...@example.com Doe # TODO known breakage
#   Failed (TODO) test 'same output : Jane j...@example.com Doe'
#   at /Users/me/projects/git/git.pu/t/t9000/test.pl line 62.
# Structures begin differing at:
#  $got-[0] = 'Jane Doe j...@example.com'
# $expected-[0] = 'Jane jdoe@example.comDoe'
not ok 32 - same output : Jane Kata rina ,Doe j...@example.com # TODO 
known breakage
#   Failed (TODO) test 'same output : Jane Kata rina ,Doe 
j...@example.com'
#   at /Users/me/projects/git/git.pu/t/t9000/test.pl line 62.
# Structures begin differing at:
#  $got-[0] = 'Jane  Kat a ri na ,Doe j...@example.com'
# $expected-[0] = 'Jane  Kat a ri na ,Doe j...@example.com'
not ok 33 - same output : Jane Doe # TODO known breakage
#   Failed (TODO) test 'same output : Jane Doe'
#   at /Users/me/projects/git/git.pu/t/t9000/test.pl line 62.
# Structures begin differing at:
#  $got-[0] = 'Jane'
# $expected-[0] = 'Jane Doe'
not ok 34 - same output : Jane Doe j...@example.com # TODO known breakage
#   Failed (TODO) test 'same output : Jane Doe j...@example.com'
#   at /Users/me/projects/git/git.pu/t/t9000/test.pl line 62.
# Structures begin differing at:
#  $got-[0] = 'Jane'
# $expected-[0] = 'Jane Doe 

Re: undocumented core.sharedRepository=2 set by git init --shared=world

[Johannes Schindelin]

Hi John,

On 2015-07-07 11:10, John Keeping wrote:
 On Tue, Jul 07, 2015 at 10:14:28AM +0200, Johannes Schindelin wrote:
 Hi Joey,

 On 2015-07-06 21:25, Joey Hess wrote:
  joey@darkstar:~/tmpgit init --shared=world testrepo
  Initialized empty shared Git repository in /home/joey/tmp/testrepo/.git/
  joey@darkstar:~/tmpgrep shared testrepo/.git/config
 sharedrepository = 2
 
  This magic value of 2 seems to be undocumented, as is the magic value of 1
  that's equvilant to group.
 
  I think it would be better to have git init put in world or group and 
  not
  these magic values. Anyway, I suppose they ought to be documented too.

 The rationale can be found here:
 https://github.com/git/git/blob/v2.4.5/builtin/init-db.c#L413-L418

  /* We do not spell group and such, so that
   * the configuration can be read by older version
   * of git. Note, we use octal numbers for new share modes,
   * and compatibility values for PERM_GROUP and
   * PERM_EVERYBODY.
   */

 I am sympathetic to your wish, of course, and I am sure that you
 understand why we cannot simply break other people's setups to satisfy
 it.
 
 That comment was added in 94df250 (shared repository: optionally allow
 reading to others., 2006-06-09) which was in 1.4.1.  I suspect that is
 now sufficiently old that it no longer matters.

I understand your point of view. With my maintainer hat on I have to say, 
though, that things like that require a major version change. Users tend to 
appreciate such a careful maintenance.

Ciao,
Johannes
--
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 v7 6/8] git-reflog: add exists command

[David Turner]

Theis are necessary because alternate ref backends might store reflogs
somewhere other than .git/logs.  Code that now directly manipulates
.git/logs should instead go through git-reflog.

Signed-off-by: David Turner dtur...@twopensource.com
---
 Documentation/git-reflog.txt |  4 
 builtin/reflog.c | 33 -
 t/t1411-reflog-show.sh   |  5 +
 3 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt
index 5e7908e..4b08fc7 100644
--- a/Documentation/git-reflog.txt
+++ b/Documentation/git-reflog.txt
@@ -23,6 +23,7 @@ depending on the subcommand:
[--dry-run] [--verbose] [--all | refs...]
 'git reflog delete' [--rewrite] [--updateref]
[--dry-run] [--verbose] ref@\{specifier\}...
+'git reflog exists' ref
 
 Reference logs, or reflogs, record when the tips of branches and
 other references were updated in the local repository. Reflogs are
@@ -52,6 +53,9 @@ argument must be an _exact_ entry (e.g. `git reflog delete
 master@{2}`). This subcommand is also typically not used directly by
 end users.
 
+The exists subcommand checks whether a ref has a reflog.  It exists
+with zero status if the reflog exists, and non-zero status if it does
+not.
 
 OPTIONS
 ---
diff --git a/builtin/reflog.c b/builtin/reflog.c
index c2eb8ff..7ed0e85 100644
--- a/builtin/reflog.c
+++ b/builtin/reflog.c
@@ -13,6 +13,8 @@ static const char reflog_expire_usage[] =
 git reflog expire [--expire=time] [--expire-unreachable=time] [--rewrite] 
[--updateref] [--stale-fix] [--dry-run | -n] [--verbose] [--all] refs...;
 static const char reflog_delete_usage[] =
 git reflog delete [--rewrite] [--updateref] [--dry-run | -n] [--verbose] 
refs...;
+static const char reflog_exists_usage[] =
+git reflog exists ref;
 
 static unsigned long default_reflog_expire;
 static unsigned long default_reflog_expire_unreachable;
@@ -699,12 +701,38 @@ static int cmd_reflog_delete(int argc, const char **argv, 
const char *prefix)
return status;
 }
 
+static int cmd_reflog_exists(int argc, const char **argv, const char *prefix)
+{
+   int i, start = 0;
+
+   for (i = 1; i  argc; i++) {
+   const char *arg = argv[i];
+   if (!strcmp(arg, --)) {
+   i++;
+   break;
+   }
+   else if (arg[0] == '-')
+   usage(reflog_exists_usage);
+   else
+   break;
+   }
+
+   start = i;
+
+   if (argc - start != 1)
+   usage(reflog_exists_usage);
+
+   if (check_refname_format(argv[start], REFNAME_ALLOW_ONELEVEL))
+   die(invalid ref format: %s, argv[start]);
+   return !reflog_exists(argv[start]);
+}
+
 /*
  * main reflog
  */
 
 static const char reflog_usage[] =
-git reflog [ show | expire | delete ];
+git reflog [ show | expire | delete | exists ];
 
 int cmd_reflog(int argc, const char **argv, const char *prefix)
 {
@@ -724,5 +752,8 @@ int cmd_reflog(int argc, const char **argv, const char 
*prefix)
if (!strcmp(argv[1], delete))
return cmd_reflog_delete(argc - 1, argv + 1, prefix);
 
+   if (!strcmp(argv[1], exists))
+   return cmd_reflog_exists(argc - 1, argv + 1, prefix);
+
return cmd_log_reflog(argc, argv, prefix);
 }
diff --git a/t/t1411-reflog-show.sh b/t/t1411-reflog-show.sh
index 6f47c0d..3eb4f10 100755
--- a/t/t1411-reflog-show.sh
+++ b/t/t1411-reflog-show.sh
@@ -166,4 +166,9 @@ test_expect_success 'git log -g -p shows diffs vs. parents' 
'
test_cmp expect actual
 '
 
+test_expect_success 'reflog exists works' '
+   git reflog exists refs/heads/master 
+   ! git reflog exists refs/heads/nonexistent
+'
+
 test_done
-- 
2.0.5.499.g01f6352.dirty-twtrsrc

--
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 v7 4/8] refs: Break out check for reflog autocreation

[David Turner]

This is just for clarity.

Signed-off-by: David Turner dtur...@twopensource.com
---
 refs.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/refs.c b/refs.c
index e891bed..e694359 100644
--- a/refs.c
+++ b/refs.c
@@ -3118,6 +3118,16 @@ static int copy_msg(char *buf, const char *msg)
return cp - buf;
 }
 
+static int should_autocreate_reflog(const char *refname)
+{
+   if (!log_all_ref_updates)
+   return 0;
+   return starts_with(refname, refs/heads/) ||
+   starts_with(refname, refs/remotes/) ||
+   starts_with(refname, refs/notes/) ||
+   !strcmp(refname, HEAD);
+}
+
 /* This function will fill in *err and return -1 on failure */
 int log_ref_setup(const char *refname, struct strbuf *sb_logfile, struct 
strbuf *err)
 {
@@ -3128,11 +3138,7 @@ int log_ref_setup(const char *refname, struct strbuf 
*sb_logfile, struct strbuf
logfile = sb_logfile-buf;
/* make sure the rest of the function can't change logfile */
sb_logfile = NULL;
-   if (log_all_ref_updates 
-   (starts_with(refname, refs/heads/) ||
-starts_with(refname, refs/remotes/) ||
-starts_with(refname, refs/notes/) ||
-!strcmp(refname, HEAD))) {
+   if (should_autocreate_reflog(refname)) {
if (safe_create_leading_directories(logfile)  0) {
strbuf_addf(err, unable to create directory for %s. 
%s, logfile, strerror(errno));
-- 
2.0.5.499.g01f6352.dirty-twtrsrc

--
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 v7 3/8] bisect: treat BISECT_HEAD as a ref

[David Turner]

Instead of directly writing to and reading from files in
$GIT_DIR, use ref API to interact with BISECT_HEAD.

Signed-off-by: David Turner dtur...@twopensource.com
---
 git-bisect.sh | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/git-bisect.sh b/git-bisect.sh
index ae3fec2..2fd8ea6 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -35,7 +35,7 @@ _x40=$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40
 
 bisect_head()
 {
-   if test -f $GIT_DIR/BISECT_HEAD
+   if bisect_head_exists
then
echo BISECT_HEAD
else
@@ -209,6 +209,10 @@ check_expected_revs() {
done
 }
 
+bisect_head_exists() {
+   git rev-parse --quiet --verify BISECT_HEAD /dev/null
+}
+
 bisect_skip() {
all=''
for arg in $@
@@ -310,7 +314,7 @@ bisect_next() {
bisect_next_check good
 
# Perform all bisection computation, display and checkout
-   git bisect--helper --next-all $(test -f $GIT_DIR/BISECT_HEAD  echo 
--no-checkout)
+   git bisect--helper --next-all $(bisect_head_exists  echo 
--no-checkout)
res=$?
 
# Check if we should exit because bisection is finished
@@ -377,7 +381,7 @@ bisect_reset() {
usage ;;
esac
 
-   if ! test -f $GIT_DIR/BISECT_HEAD  ! git checkout $branch --
+   if ! bisect_head_exists  ! git checkout $branch --
then
die $(eval_gettext Could not check out original HEAD 
'\$branch'.
 Try 'git bisect reset commit'.)
-- 
2.0.5.499.g01f6352.dirty-twtrsrc

--
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 v7 1/8] refs.c: add err arguments to reflog functions

[David Turner]

Add an err argument to log_ref_setup that can explain the reason
for a failure. This then eliminates the need to manage errno through
this function since we can just add strerror(errno) to the err string
when meaningful. No callers relied on errno from this function for
anything else than the error message.

Also add err arguments to private functions write_ref_to_lockfile,
log_ref_write_1, commit_ref_update. This again eliminates the need to
manage errno in these functions.

Some error messages change slightly.  For instance, we sometimes lose
cannot update ref and instead only show the specific cause of ref
update failure.

Update of a patch by Ronnie Sahlberg.

Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: David Turner dtur...@twopensource.com
---
 builtin/checkout.c |   8 ++--
 refs.c | 130 +
 refs.h |   4 +-
 3 files changed, 79 insertions(+), 63 deletions(-)

diff --git a/builtin/checkout.c b/builtin/checkout.c
index c018ab3..93f63d3 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -624,16 +624,18 @@ static void update_refs_for_switch(const struct 
checkout_opts *opts,
struct strbuf log_file = STRBUF_INIT;
int ret;
const char *ref_name;
+   struct strbuf err = STRBUF_INIT;
 
ref_name = mkpath(refs/heads/%s, 
opts-new_orphan_branch);
temp = log_all_ref_updates;
log_all_ref_updates = 1;
-   ret = log_ref_setup(ref_name, log_file);
+   ret = log_ref_setup(ref_name, log_file, err);
log_all_ref_updates = temp;
strbuf_release(log_file);
if (ret) {
-   fprintf(stderr, _(Can not do reflog 
for '%s'\n),
-   opts-new_orphan_branch);
+   fprintf(stderr, _(Can not do reflog 
for '%s'. %s\n),
+   opts-new_orphan_branch, 
err.buf);
+   strbuf_release(err);
return;
}
}
diff --git a/refs.c b/refs.c
index fb568d7..e891bed 100644
--- a/refs.c
+++ b/refs.c
@@ -2975,9 +2975,11 @@ static int rename_ref_available(const char *oldname, 
const char *newname)
return ret;
 }
 
-static int write_ref_to_lockfile(struct ref_lock *lock, const unsigned char 
*sha1);
+static int write_ref_to_lockfile(struct ref_lock *lock,
+const unsigned char *sha1, struct strbuf *err);
 static int commit_ref_update(struct ref_lock *lock,
-const unsigned char *sha1, const char *logmsg);
+const unsigned char *sha1, const char *logmsg,
+struct strbuf *err);
 
 int rename_ref(const char *oldrefname, const char *newrefname, const char 
*logmsg)
 {
@@ -3038,9 +3040,10 @@ int rename_ref(const char *oldrefname, const char 
*newrefname, const char *logms
}
hashcpy(lock-old_oid.hash, orig_sha1);
 
-   if (write_ref_to_lockfile(lock, orig_sha1) ||
-   commit_ref_update(lock, orig_sha1, logmsg)) {
-   error(unable to write current sha1 into %s, newrefname);
+   if (write_ref_to_lockfile(lock, orig_sha1, err) ||
+   commit_ref_update(lock, orig_sha1, logmsg, err)) {
+   error(unable to write current sha1 into %s: %s, newrefname, 
err.buf);
+   strbuf_release(err);
goto rollback;
}
 
@@ -3056,9 +3059,11 @@ int rename_ref(const char *oldrefname, const char 
*newrefname, const char *logms
 
flag = log_all_ref_updates;
log_all_ref_updates = 0;
-   if (write_ref_to_lockfile(lock, orig_sha1) ||
-   commit_ref_update(lock, orig_sha1, NULL))
-   error(unable to write current sha1 into %s, oldrefname);
+   if (write_ref_to_lockfile(lock, orig_sha1, err) ||
+   commit_ref_update(lock, orig_sha1, NULL, err)) {
+   error(unable to write current sha1 into %s: %s, oldrefname, 
err.buf);
+   strbuf_release(err);
+   }
log_all_ref_updates = flag;
 
  rollbacklog:
@@ -3113,8 +3118,8 @@ static int copy_msg(char *buf, const char *msg)
return cp - buf;
 }
 
-/* This function must set a meaningful errno on failure */
-int log_ref_setup(const char *refname, struct strbuf *sb_logfile)
+/* This function will fill in *err and return -1 on failure */
+int log_ref_setup(const char *refname, struct strbuf *sb_logfile, struct 
strbuf *err)
 {
int logfd, oflags = O_APPEND | O_WRONLY;
char *logfile;
@@ 

[PATCH v7 8/8] git-stash: use update-ref --create-reflog instead of creating files

[David Turner]

This is in support of alternate ref backends which don't necessarily
store reflogs as files.

Signed-off-by: David Turner dtur...@twopensource.com
---
 git-stash.sh | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/git-stash.sh b/git-stash.sh
index 8e9e2cd..1d5ba7a 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -183,9 +183,7 @@ store_stash () {
stash_msg=Created via \git stash store\.
fi
 
-   # Make sure the reflog for stash is kept.
-   : $(git rev-parse --git-path logs/$ref_stash)
-   git update-ref -m $stash_msg $ref_stash $w_commit
+   git update-ref --create-reflog -m $stash_msg $ref_stash $w_commit
ret=$?
test $ret != 0  test -z $quiet 
die $(eval_gettext Cannot update \$ref_stash with \$w_commit)
@@ -262,7 +260,7 @@ save_stash () {
say $(gettext No local changes to save)
exit 0
fi
-   test -f $(git rev-parse --git-path logs/$ref_stash) ||
+   git reflog exists $ref_stash ||
clear_stash || die $(gettext Cannot initialize stash)
 
create_stash $stash_msg $untracked
-- 
2.0.5.499.g01f6352.dirty-twtrsrc

--
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 v7 2/8] cherry-pick: treat CHERRY_PICK_HEAD and REVERT_HEAD as refs

[David Turner]

Instead of directly writing to and reading from files in
$GIT_DIR, use ref API to interact with CHERRY_PICK_HEAD
and REVERT_HEAD.

Signed-off-by: David Turner dtur...@twopensource.com
---
 branch.c |  4 ++--
 builtin/commit.c |  6 +++---
 builtin/merge.c  |  2 +-
 contrib/completion/git-prompt.sh |  4 ++--
 git-gui/lib/commit.tcl   |  2 +-
 sequencer.c  | 31 ++-
 t/t7509-commit.sh|  4 ++--
 wt-status.c  |  6 ++
 8 files changed, 23 insertions(+), 36 deletions(-)

diff --git a/branch.c b/branch.c
index b002435..ec598aa 100644
--- a/branch.c
+++ b/branch.c
@@ -302,8 +302,8 @@ void create_branch(const char *head,
 
 void remove_branch_state(void)
 {
-   unlink(git_path(CHERRY_PICK_HEAD));
-   unlink(git_path(REVERT_HEAD));
+   delete_ref(CHERRY_PICK_HEAD, NULL, REF_NODEREF);
+   delete_ref(REVERT_HEAD, NULL, REF_NODEREF);
unlink(git_path(MERGE_HEAD));
unlink(git_path(MERGE_RR));
unlink(git_path(MERGE_MSG));
diff --git a/builtin/commit.c b/builtin/commit.c
index b5b1158..53c7e90 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -168,7 +168,7 @@ static void determine_whence(struct wt_status *s)
 {
if (file_exists(git_path(MERGE_HEAD)))
whence = FROM_MERGE;
-   else if (file_exists(git_path(CHERRY_PICK_HEAD))) {
+   else if (ref_exists(CHERRY_PICK_HEAD)) {
whence = FROM_CHERRY_PICK;
if (file_exists(git_path(SEQ_DIR)))
sequencer_in_use = 1;
@@ -1777,8 +1777,8 @@ int cmd_commit(int argc, const char **argv, const char 
*prefix)
}
ref_transaction_free(transaction);
 
-   unlink(git_path(CHERRY_PICK_HEAD));
-   unlink(git_path(REVERT_HEAD));
+   delete_ref(CHERRY_PICK_HEAD, NULL, REF_NODEREF);
+   delete_ref(REVERT_HEAD, NULL, REF_NODEREF);
unlink(git_path(MERGE_HEAD));
unlink(git_path(MERGE_MSG));
unlink(git_path(MERGE_MODE));
diff --git a/builtin/merge.c b/builtin/merge.c
index 46aacd6..3e2ae2f 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -1206,7 +1206,7 @@ int cmd_merge(int argc, const char **argv, const char 
*prefix)
else
die(_(You have not concluded your merge (MERGE_HEAD 
exists).));
}
-   if (file_exists(git_path(CHERRY_PICK_HEAD))) {
+   if (ref_exists(CHERRY_PICK_HEAD)) {
if (advice_resolve_conflict)
die(_(You have not concluded your cherry-pick 
(CHERRY_PICK_HEAD exists).\n
Please, commit your changes before you merge.));
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 366f0bc..e2c5583 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -415,9 +415,9 @@ __git_ps1 ()
fi
elif [ -f $g/MERGE_HEAD ]; then
r=|MERGING
-   elif [ -f $g/CHERRY_PICK_HEAD ]; then
+   elif git rev-parse --quiet --verify CHERRY_PICK_HEAD 
/dev/null; then
r=|CHERRY-PICKING
-   elif [ -f $g/REVERT_HEAD ]; then
+   elif git rev-parse --quiet --verify REVERT_HEAD /dev/null; 
then
r=|REVERTING
elif [ -f $g/BISECT_LOG ]; then
r=|BISECTING
diff --git a/git-gui/lib/commit.tcl b/git-gui/lib/commit.tcl
index 864b687..2b08b13 100644
--- a/git-gui/lib/commit.tcl
+++ b/git-gui/lib/commit.tcl
@@ -409,7 +409,7 @@ A rescan will be automatically started now.
catch {file delete [gitdir MERGE_MSG]}
catch {file delete [gitdir SQUASH_MSG]}
catch {file delete [gitdir GITGUI_MSG]}
-   catch {file delete [gitdir CHERRY_PICK_HEAD]}
+   catch {git update-ref -d --no-deref CHERRY_PICK_HEAD}
 
# -- Let rerere do its thing.
#
diff --git a/sequencer.c b/sequencer.c
index f8421a8..90396ba 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -158,21 +158,10 @@ static void free_message(struct commit *commit, struct 
commit_message *msg)
unuse_commit_buffer(commit, msg-message);
 }
 
-static void write_cherry_pick_head(struct commit *commit, const char 
*pseudoref)
+static void write_cherry_pick_head(struct commit *commit, const char *ref)
 {
-   const char *filename;
-   int fd;
-   struct strbuf buf = STRBUF_INIT;
-
-   strbuf_addf(buf, %s\n, sha1_to_hex(commit-object.sha1));
-
-   filename = git_path(%s, pseudoref);
-   fd = open(filename, O_WRONLY | O_CREAT, 0666);
-   if (fd  0)
-   die_errno(_(Could not open '%s' for writing), filename);
-   if (write_in_full(fd, buf.buf, buf.len) != buf.len || close(fd))
-   die_errno(_(Could not write to '%s'), filename);
-   strbuf_release(buf);
+   update_ref(NULL, ref, 

[PATCH v7 5/8] refs: new public ref function: safe_create_reflog

[David Turner]

The safe_create_reflog function creates a reflog, if it does not
already exist.

The log_ref_setup function becomes private and gains a force_create
parameter to force the creation of a reflog even if log_all_ref_updates
is false or the refname is not one of the special refnames.

The new parameter also reduces the need to store, modify, and restore
the log_all_ref_updates global before reflog creation.

In a moment, we will use this to add reflog creation commands to
git-reflog.

Signed-off-by: David Turner dtur...@twopensource.com
---
 builtin/checkout.c | 16 +---
 refs.c | 25 +
 refs.h |  2 +-
 3 files changed, 27 insertions(+), 16 deletions(-)

diff --git a/builtin/checkout.c b/builtin/checkout.c
index 93f63d3..c840f33 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -620,24 +620,18 @@ static void update_refs_for_switch(const struct 
checkout_opts *opts,
if (opts-new_branch) {
if (opts-new_orphan_branch) {
if (opts-new_branch_log  !log_all_ref_updates) {
-   int temp;
-   struct strbuf log_file = STRBUF_INIT;
-   int ret;
-   const char *ref_name;
+   char *refname;
struct strbuf err = STRBUF_INIT;
 
-   ref_name = mkpath(refs/heads/%s, 
opts-new_orphan_branch);
-   temp = log_all_ref_updates;
-   log_all_ref_updates = 1;
-   ret = log_ref_setup(ref_name, log_file, err);
-   log_all_ref_updates = temp;
-   strbuf_release(log_file);
-   if (ret) {
+   refname = mkpathdup(refs/heads/%s, 
opts-new_orphan_branch);
+   if (safe_create_reflog(refname, err, 1)) {
+   free(refname);
fprintf(stderr, _(Can not do reflog 
for '%s'. %s\n),
opts-new_orphan_branch, 
err.buf);
strbuf_release(err);
return;
}
+   free(refname);
}
}
else
diff --git a/refs.c b/refs.c
index e694359..01b0af5 100644
--- a/refs.c
+++ b/refs.c
@@ -3128,8 +3128,14 @@ static int should_autocreate_reflog(const char *refname)
!strcmp(refname, HEAD);
 }
 
-/* This function will fill in *err and return -1 on failure */
-int log_ref_setup(const char *refname, struct strbuf *sb_logfile, struct 
strbuf *err)
+/*
+ * Create a reflog for a ref.  If force_create = 0, the reflog will
+ * only be created for certain refs (those for which
+ * should_autocreate_reflog returns non-zero.  Otherwise, it will be
+ * created regardless of the ref name.  This function will fill in
+ * *err and return -1 on failure
+ */
+static int log_ref_setup(const char *refname, struct strbuf *sb_logfile, 
struct strbuf *err, int force_create)
 {
int logfd, oflags = O_APPEND | O_WRONLY;
char *logfile;
@@ -3138,7 +3144,7 @@ int log_ref_setup(const char *refname, struct strbuf 
*sb_logfile, struct strbuf
logfile = sb_logfile-buf;
/* make sure the rest of the function can't change logfile */
sb_logfile = NULL;
-   if (should_autocreate_reflog(refname)) {
+   if (force_create || should_autocreate_reflog(refname)) {
if (safe_create_leading_directories(logfile)  0) {
strbuf_addf(err, unable to create directory for %s. 
%s, logfile, strerror(errno));
@@ -3173,6 +3179,17 @@ int log_ref_setup(const char *refname, struct strbuf 
*sb_logfile, struct strbuf
return 0;
 }
 
+
+int safe_create_reflog(const char *refname, struct strbuf *err, int 
force_create)
+{
+   int ret;
+   struct strbuf sb = STRBUF_INIT;
+
+   ret = log_ref_setup(refname, sb, err, force_create);
+   strbuf_release(sb);
+   return ret;
+}
+
 static int log_ref_write_fd(int fd, const unsigned char *old_sha1,
const unsigned char *new_sha1,
const char *committer, const char *msg)
@@ -3209,7 +3226,7 @@ static int log_ref_write_1(const char *refname, const 
unsigned char *old_sha1,
if (log_all_ref_updates  0)
log_all_ref_updates = !is_bare_repository();
 
-   result = log_ref_setup(refname, sb_log_file, err);
+   result = log_ref_setup(refname, sb_log_file, err, 0);
 
if (result)
return result;
diff --git a/refs.h b/refs.h
index debdefc..3b90e16 100644
--- a/refs.h
+++ b/refs.h
@@ -228,7 +228,7 @@ int 

Re: [PATCH v3 23/23] checkout: retire --ignore-other-worktrees in favor of --force

[Mark Levedahl]

On 07/06/2015 03:40 PM, Junio C Hamano wrote:
If you are extending the history of some branch, then you would want 
to be on that branch. Why would you want to have another worktree that 
will get into a confusing state once you create that commit on the 
checked out branch in this newly created worktree? Wasn't the whole 
point of making the primary repository aware of the secondary 
worktrees via the linked checkout mechanism because that confusion 
was the biggest sore point of the old contrib/workdir implementation? 


The only issue I have with git-new-workdir is that git-gc in one 
worktree is unaware of what is in use in another so can prune things 
away. The linked worktrees here nicely solve that problem.


The main use I have of maintaining multiple checkouts of one branch is 
for testing / analysis (where said tests can take days to weeks to run). 
Disallowing use of git's normal mechanism of tracking what is checked 
out in each such tree forces use of another system to do so, just 
imposing different difficulties for this use case. I note that 1) code 
must be ADDED to git to prevent such duplicate checkouts which otherwise 
cause no difficulty to git itself, and 2) adding those checks requires 
additional work to avoid the fallout. I have yet to hear what the upside 
of such a restriction is, I only see downsides.


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

Re: [PATCH v6 6/7] git-reflog: add create and exists functions

[David Turner]

On Mon, 2015-07-06 at 18:51 +0200, Michael Haggerty wrote:

  +{
  +   int i, status = 0, start = 0;
 
 It looks like start is initialized unconditionally after the first loop,
 so the initialization here is a red herring.

Will fix.

 So, I have a philosophical question here with a practical side...
 
 It appears that this command allows you to create a reflog for a
 reference that doesn't yet exist. At first blush, this seems to make
 sense. Suppose you want the creation of a reference to be logged. Then
 you can first turn on its reflog, then create it.
 
 But I think this is going to create problems. Reflogs are rather
 intimately connected to their references. For example, writes to a
 reflog are guarded by locking the corresponding reference. And currently
 a reflog file is deleted when the corresponding reference is deleted.
 Also, there are constraints about which references can coexist; for
 example, references refs/heads/foo and refs/heads/foo/bar cannot
 exist at the same time, because (at least when using the filesystem
 backend), refs/heads/foo would have to be both a file and a directory
 at the same time. So if one of these references already exists, it would
 be an error to create a reflog for the other one.
 
 Similarly, if there is a reflog file for one of these references that
 was created by this command, but there is not yet a corresponding
 reference, then any command that later tries to create the other
 reference will not be able to create the reflog for *that* reference
 because it will conflict with the existing reflog. I doubt that the
 reference creation is smart enough to deal with this situation.
 
 So all in all, I think it is unwise to allow a reflog to be created
 without its corresponding reference.
 
 This, in turn, suggests one or both of the following alternatives:
 
 1. Allow git reflog create, but only for references that already exist.

This turns out not to work for git stash, which wants to create a reflog
for stash creation.

 2. If we want to allow a reflog to be created at the same time as the
 corresponding reference, the reference-creation commands (git branch,
 git tag, git update-ref, and maybe some others) probably need a new
 option like --create-reflog (and, for symmetry, probably
 --no-create-reflog).

git branch should already autocreate reflogs, since the refs it creates
are under refs/heads.

 At the API level, it might make sense for the ref-transaction functions
 to get a new REF_FORCE_CREATE_REFLOG flag or something.

Junio was opposed to the converse flag, so I'm going to just add
manually add code to create reflogs.


--
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 v7 7/8] update-ref and tag: add --create-reflog arg

[David Turner]

Allow the creation of a ref (e.g. stash) with a reflog already in
place. For most refs (e.g. those under refs/heads), this happens
automatically, but for others, we need this option.

Currently, git does this by pre-creating the reflog, but alternate ref
backends might store reflogs somewhere other than .git/logs.  Code
that now directly manipulates .git/logs should instead use git
plumbing commands.

I also added --create-reflog to git tag, just for completeness.

In a moment, we will use this argument to make git stash work with
alternate ref backends.

Signed-off-by: David Turner dtur...@twopensource.com
---
 Documentation/git-tag.txt|  5 -
 Documentation/git-update-ref.txt |  5 -
 builtin/tag.c|  5 +
 builtin/update-ref.c | 17 +++--
 t/t1400-update-ref.sh| 38 ++
 t/t7004-tag.sh   |  9 -
 6 files changed, 74 insertions(+), 5 deletions(-)

diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 034d10d..2312980 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -13,7 +13,7 @@ SYNOPSIS
tagname [commit | object]
 'git tag' -d tagname...
 'git tag' [-n[num]] -l [--contains commit] [--points-at object]
-   [--column[=options] | --no-column] [pattern...]
+   [--column[=options] | --no-column] [--create-reflog] [pattern...]
[pattern...]
 'git tag' -v tagname...
 
@@ -143,6 +143,9 @@ This option is only applicable when listing tags without 
annotation lines.
all, 'whitespace' removes just leading/trailing whitespace lines and
'strip' removes both whitespace and commentary.
 
+--create-reflog::
+   Create a reflog for the tag.
+
 tagname::
The name of the tag to create, delete, or describe.
The new tag name must pass all checks defined by
diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt
index c8f5ae5..969bfab 100644
--- a/Documentation/git-update-ref.txt
+++ b/Documentation/git-update-ref.txt
@@ -8,7 +8,7 @@ git-update-ref - Update the object name stored in a ref safely
 SYNOPSIS
 
 [verse]
-'git update-ref' [-m reason] (-d ref [oldvalue] | [--no-deref] ref 
newvalue [oldvalue] | --stdin [-z])
+'git update-ref' [-m reason] (-d ref [oldvalue] | [--no-deref] 
[--create-reflog] ref newvalue [oldvalue] | --stdin [-z])
 
 DESCRIPTION
 ---
@@ -67,6 +67,9 @@ performs all modifications together.  Specify commands of the 
form:
verify SP ref [SP oldvalue] LF
option SP opt LF
 
+With `--create-reflog`, update-ref will create a reflog for each ref
+even if one would not ordinarily be created.
+
 Quote fields containing whitespace as if they were strings in C source
 code; i.e., surrounded by double-quotes and with backslash escapes.
 Use 40 0 characters or the empty string to specify a zero value.  To
diff --git a/builtin/tag.c b/builtin/tag.c
index 5f6cdc5..896f434 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -579,6 +579,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
struct create_tag_options opt;
char *cleanup_arg = NULL;
int annotate = 0, force = 0, lines = -1;
+   int create_reflog = 0;
int cmdmode = 0;
const char *msgfile = NULL, *keyid = NULL;
struct msg_arg msg = { 0, STRBUF_INIT };
@@ -605,6 +606,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
OPT_STRING('u', local-user, keyid, N_(key-id),
N_(use another key to sign the tag)),
OPT__FORCE(force, N_(replace the tag if exists)),
+   OPT_BOOL(0, create-reflog, create_reflog, 
N_(create_reflog)),
 
OPT_GROUP(N_(Tag listing options)),
OPT_COLUMN(0, column, colopts, N_(show tag list in 
columns)),
@@ -730,6 +732,9 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
if (annotate)
create_tag(object, tag, buf, opt, prev, object);
 
+   if (create_reflog  safe_create_reflog(ref.buf, err, 1))
+   die(failed to create reflog for %s: %s, ref.buf, err.buf);
+
transaction = ref_transaction_begin(err);
if (!transaction ||
ref_transaction_update(transaction, ref.buf, object, prev,
diff --git a/builtin/update-ref.c b/builtin/update-ref.c
index 6763cf1..d570e5e 100644
--- a/builtin/update-ref.c
+++ b/builtin/update-ref.c
@@ -14,6 +14,7 @@ static const char * const git_update_ref_usage[] = {
 
 static char line_termination = '\n';
 static int update_flags;
+int create_reflog;
 static const char *msg;
 
 /*
@@ -198,6 +199,9 @@ static const char *parse_cmd_update(struct ref_transaction 
*transaction,
if (*next != line_termination)
die(update %s: extra input: %s, refname, next);
 
+   if (create_reflog  safe_create_reflog(refname, err, 1))
+   die(failed to create 

Re: Git grep does not support multi-byte characters (like UTF-8)

[Duy Nguyen]

On Wed, Jul 8, 2015 at 1:08 AM, Plamen Totev plamen.to...@abv.bg wrote:
 Junio C Hamano gits...@pobox.com writes:

 Plamen Totev plamen.to...@abv.bg writes:

  pickaxe search also uses kwsearch so the case insensitive search with
  it does not work (e.g. git log -i -S). Maybe this is a less of a
  problem here as one is expected to search for exact string (hence
  knows the case)

 You reasoned correctly, I think. Pickaxe, as one of the building
 blocks to implement Linus's ultimate change tracking tool [*1*],
 should never pay attention to -i. It is a step to finding the
 commit that touches the exact code block given (i.e. how do you
 drill down? part of $gmane/217 message).

 Thanks.

 [Footnote]
 *1* http://article.gmane.org/gmane.comp.version-control.git/217

 Now that I read the link again and gave the matter a thought I'm not so sure.
 In some contexts the case of the words does not matter. In SQL for example.
 Let's consider a SQL script file that contains the following line:

 select name, address from customers;

 At some point we decide to change the coding style to:

 SELECT name, address FROM customers;

On top of this, pickaxe already supports icase even kws is used. But
it only works for ascii, so either we fix it and support non-ascii, or
we remove icase support entirely from diffcore_pickaxe(). I vote the
former.
-- 
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3] log: add log.follow config option

[David Turner]

Many users prefer to always use --follow with logs.  Rather than
aliasing the command, an option might be more convenient for some.

Signed-off-by: David Turner dtur...@twopensource.com
---
 Documentation/git-log.txt |  6 ++
 builtin/log.c |  7 +++
 diff.c|  5 +++--
 diff.h|  1 +
 revision.c| 17 +++--
 t/t4202-log.sh| 23 +++
 6 files changed, 51 insertions(+), 8 deletions(-)

diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 5692945..79bf4d4 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -184,6 +184,12 @@ log.date::
`--date` option.)  Defaults to default, which means to write
dates like `Sat May 8 19:35:34 2010 -0500`.
 
+log.follow::
+   If a single file argument is given to git log, it will act as
+   if the `--follow` option was also used.  This has the same
+   limitations as `--follow`, i.e. it cannot be used to follow
+   multiple files and does not work well on non-linear history.
+
 log.showRoot::
If `false`, `git log` and related commands will not treat the
initial commit as a big creation event.  Any root commits in
diff --git a/builtin/log.c b/builtin/log.c
index 8781049..6a068f7 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -31,6 +31,7 @@ static const char *default_date_mode = NULL;
 
 static int default_abbrev_commit;
 static int default_show_root = 1;
+static int default_follow;
 static int decoration_style;
 static int decoration_given;
 static int use_mailmap_config;
@@ -102,6 +103,8 @@ static void cmd_log_init_defaults(struct rev_info *rev)
 {
if (fmt_pretty)
get_commit_format(fmt_pretty, rev);
+   if (default_follow)
+   DIFF_OPT_SET(rev-diffopt, DEFAULT_FOLLOW_RENAMES);
rev-verbose_header = 1;
DIFF_OPT_SET(rev-diffopt, RECURSIVE);
rev-diffopt.stat_width = -1; /* use full terminal width */
@@ -390,6 +393,10 @@ static int git_log_config(const char *var, const char 
*value, void *cb)
default_show_root = git_config_bool(var, value);
return 0;
}
+   if (!strcmp(var, log.follow)) {
+   default_follow = git_config_bool(var, value);
+   return 0;
+   }
if (skip_prefix(var, color.decorate., slot_name))
return parse_decorate_color_config(var, slot_name, value);
if (!strcmp(var, log.mailmap)) {
diff --git a/diff.c b/diff.c
index 87b16d5..135b222 100644
--- a/diff.c
+++ b/diff.c
@@ -3815,9 +3815,10 @@ int diff_opt_parse(struct diff_options *options, const 
char **av, int ac)
DIFF_OPT_SET(options, FIND_COPIES_HARDER);
else if (!strcmp(arg, --follow))
DIFF_OPT_SET(options, FOLLOW_RENAMES);
-   else if (!strcmp(arg, --no-follow))
+   else if (!strcmp(arg, --no-follow)) {
DIFF_OPT_CLR(options, FOLLOW_RENAMES);
-   else if (!strcmp(arg, --color))
+   DIFF_OPT_CLR(options, DEFAULT_FOLLOW_RENAMES);
+   } else if (!strcmp(arg, --color))
options-use_color = 1;
else if (skip_prefix(arg, --color=, arg)) {
int value = git_config_colorbool(NULL, arg);
diff --git a/diff.h b/diff.h
index c7ad42a..f7208ad 100644
--- a/diff.h
+++ b/diff.h
@@ -91,6 +91,7 @@ typedef struct strbuf *(*diff_prefix_fn_t)(struct 
diff_options *opt, void *data)
 #define DIFF_OPT_DIRSTAT_BY_LINE (1  28)
 #define DIFF_OPT_FUNCCONTEXT (1  29)
 #define DIFF_OPT_PICKAXE_IGNORE_CASE (1  30)
+#define DIFF_OPT_DEFAULT_FOLLOW_RENAMES (1  31)
 
 #define DIFF_OPT_TST(opts, flag)((opts)-flags  DIFF_OPT_##flag)
 #define DIFF_OPT_TOUCHED(opts, flag)((opts)-touched_flags  
DIFF_OPT_##flag)
diff --git a/revision.c b/revision.c
index 3ff8723..7c1931b 100644
--- a/revision.c
+++ b/revision.c
@@ -2311,15 +2311,13 @@ int setup_revisions(int argc, const char **argv, struct 
rev_info *revs, struct s
if (revs-diffopt.output_format  ~DIFF_FORMAT_NO_OUTPUT)
revs-diff = 1;
 
-   /* Pickaxe, diff-filter and rename following need diffs */
-   if (revs-diffopt.pickaxe ||
-   revs-diffopt.filter ||
-   DIFF_OPT_TST(revs-diffopt, FOLLOW_RENAMES))
-   revs-diff = 1;
-
if (revs-topo_order)
revs-limited = 1;
 
+   if (DIFF_OPT_TST(revs-diffopt, DEFAULT_FOLLOW_RENAMES) 
+   revs-prune_data.nr == 1)
+   DIFF_OPT_SET(revs-diffopt, FOLLOW_RENAMES);
+
if (revs-prune_data.nr) {
copy_pathspec(revs-pruning.pathspec, revs-prune_data);
/* Can't prune commits with rename following: the paths 
change.. */
@@ -2329,6 +2327,13 @@ int setup_revisions(int argc, const char **argv, struct 
rev_info *revs, struct s
copy_pathspec(revs-diffopt.pathspec,
  

Re: [PATCH v2] log: add log.follow config option

[David Turner]

On Tue, 2015-07-07 at 15:13 -0700, Junio C Hamano wrote:
 David Turner dtur...@twopensource.com writes:
 
  diff --git a/revision.c b/revision.c
  index 3ff8723..ae6d4c3 100644
  --- a/revision.c
  +++ b/revision.c
  @@ -2322,12 +2322,21 @@ int setup_revisions(int argc, const char **argv, 
  struct rev_info *revs, struct s
   
  if (revs-prune_data.nr) {
  copy_pathspec(revs-pruning.pathspec, revs-prune_data);
  -   /* Can't prune commits with rename following: the paths 
  change.. */
  -   if (!DIFF_OPT_TST(revs-diffopt, FOLLOW_RENAMES))
  -   revs-prune = 1;
  +
  if (!revs-full_diff)
  copy_pathspec(revs-diffopt.pathspec,
revs-prune_data);
  +
  +   if (DIFF_OPT_TST(revs-diffopt, DEFAULT_FOLLOW_RENAMES) 
  +   revs-diffopt.pathspec.nr == 1)
  +   DIFF_OPT_SET(revs-diffopt, FOLLOW_RENAMES);
  +
  +   /* Can't prune commits with rename following: the paths 
  change.. */
  +   if (!DIFF_OPT_TST(revs-diffopt, FOLLOW_RENAMES)) {
  +   revs-prune = 1;
  +   } else {
  +   revs-diff = 1;
  +   }
  }
  if (revs-combine_merges)
  revs-ignore_merges = 0;
 
 It is unfortunate that we have to waste one DIFF_OPT bit and touch
 revision.c for something that is just a convenience.  Because
 setup_revisions() does not have a way to let you flip the settings
 depending on the number of pathspecs specified, I do not think of a
 solution that does not have to touch a low level foundation part of
 the codebase, which I'd really want to avoid.
 
 But I wonder why your patch needs to touch so much.
 
 Your changes to other files make sure that diffopt has the
 DEFAULT_FOLLOW_RENAMES when (1) the configuration is set and (2) the
 command line did not override it with --no-follow.  And these look
 very sensible.
 
 Isn't the only thing left to do in this codepath, after the DEFAULT_
 is set up correctly, to set FOLLOW_RENAMES when (1) DEFAULT_ is set
 and (2) you have only one path?

 And once FOLLOW_RENAMES is set or unset according to the end-user
 visible semantics, i.e. just for a convenience, setting log.follow
 adds --follow to the command line if and only if there is only one
 pathspec, I do not see why existing code needs to be modified in
 any other way.
 
 IOW, I'd like to know why we need more than something like this
 change to this file, instead of the above?  We didn't muck with
 revs-diff in the original when FOLLOW_RENAMES was set, but now it
 does, for example.

We did, but we did it earlier.  But I can just rearrange the code.

 diff --git a/revision.c b/revision.c
 index 3ff8723..f7bd229 100644
 --- a/revision.c
 +++ b/revision.c
 @@ -2270,6 +2270,10 @@ int setup_revisions(int argc, const char **argv, 
 struct rev_info *revs, struct s
   got_rev_arg = 1;
   }
  
 + if (DIFF_OPT_TST(revs-diffopt, DEFAULT_FOLLOW_RENAMES) 
 + revs-diffopt.pathspec.nr == 1)
 + DIFF_OPT_SET(revs-diffopt, FOLLOW_RENAMES);
 +
   if (prune_data.nr) {
   /*
* If we need to introduce the magic a lone ':' means no

revs-diffopt.pathspec isn't set up yet then. But prune_data is, so I
can use that. 

Will send a v3.

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

[PATCH v2 04/12] t4150: am refuses patches when paused

[Paul Tan]

Since c95b138 (Fix git-am safety checks, 2006-09-15), when there is a
session in progress, git-am will check the command-line arguments and
standard input to ensure that the user does not pass it any patches.

Add a test for this.

Signed-off-by: Paul Tan pyoka...@gmail.com
---
 t/t4150-am.sh | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/t/t4150-am.sh b/t/t4150-am.sh
index a85e06a..c350967 100755
--- a/t/t4150-am.sh
+++ b/t/t4150-am.sh
@@ -397,6 +397,20 @@ test_expect_success 'am --abort removes a stray directory' 
'
test_path_is_missing .git/rebase-apply
 '
 
+test_expect_success 'am refuses patches when paused' '
+   rm -fr .git/rebase-apply 
+   git reset --hard 
+   git checkout lorem2^^ 
+
+   test_must_fail git am lorem-move.patch 
+   test_path_is_dir .git/rebase-apply 
+   test_cmp_rev lorem2^^ HEAD 
+
+   test_must_fail git am lorem-move.patch 
+   test_path_is_dir .git/rebase-apply 
+   test_cmp_rev lorem2^^ HEAD
+'
+
 test_expect_success 'am --resolved works' '
echo goodbye expected 
rm -fr .git/rebase-apply 
-- 
2.5.0.rc1.76.gf60a929

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

[PATCH v2 03/12] t4151: am --abort will keep dirty index intact

[Paul Tan]

Since 7b3b7e3 (am --abort: keep unrelated commits since the last failure
and warn, 2010-12-21), git-am --abort will not touch the index if on the
previous invocation, git-am failed because the index is dirty. This is
to ensure that the user's modifications to the index are not discarded.

Add a test for this.

Signed-off-by: Paul Tan pyoka...@gmail.com
---
 t/t4151-am-abort.sh | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/t/t4151-am-abort.sh b/t/t4151-am-abort.sh
index 833e7b2..05bdc3e 100755
--- a/t/t4151-am-abort.sh
+++ b/t/t4151-am-abort.sh
@@ -95,6 +95,21 @@ test_expect_success 'am --abort will keep the local commits 
intact' '
test_cmp expect actual
 '
 
+test_expect_success 'am --abort will keep dirty index intact' '
+   git reset --hard initial 
+   echo dirtyfile dirtyfile 
+   cp dirtyfile dirtyfile.expected 
+   git add dirtyfile 
+   test_must_fail git am 0001-*.patch 
+   test_cmp_rev initial HEAD 
+   test_path_is_file dirtyfile 
+   test_cmp dirtyfile.expected dirtyfile 
+   git am --abort 
+   test_cmp_rev initial HEAD 
+   test_path_is_file dirtyfile 
+   test_cmp dirtyfile.expected dirtyfile
+'
+
 test_expect_success 'am -3 stops on conflict on unborn branch' '
git checkout -f --orphan orphan 
git reset 
-- 
2.5.0.rc1.76.gf60a929

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

[PATCH v2 12/12] t3901: test git-am encoding conversion

[Paul Tan]

Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07), git-am
supported the --utf8 and --no-utf8 options, and if set, would pass the
-u flag and the -k flag respectively.

git mailinfo -u will re-code the commit log message and authorship info
in the charset specified by i18n.commitencoding setting, while
git mailinfo -n will disable the re-coding.

Since d84029b (--utf8 is now default for 'git-am', 2007-01-08), --utf8
is set by default in git-am.

Add various encoding conversion tests to t3901 to test git-mailinfo's
encoding conversion. In addition, add a test for --no-utf8 to check that
no encoding conversion will occur if that option is set.

Signed-off-by: Paul Tan pyoka...@gmail.com
---
 t/t3901-i18n-patch.sh | 62 +++
 1 file changed, 62 insertions(+)

diff --git a/t/t3901-i18n-patch.sh b/t/t3901-i18n-patch.sh
index 75cf3ff..b49bdb7 100755
--- a/t/t3901-i18n-patch.sh
+++ b/t/t3901-i18n-patch.sh
@@ -251,4 +251,66 @@ test_expect_success 'rebase --merge (L/U)' '
check_encoding 2 8859
 '
 
+test_expect_success 'am (U/U)' '
+   # Apply UTF-8 patches with UTF-8 commitencoding
+   git config i18n.commitencoding UTF-8 
+   . $TEST_DIRECTORY/t3901-utf8.txt 
+
+   git reset --hard master 
+   git am out-u1 out-u2 
+
+   check_encoding 2
+'
+
+test_expect_success 'am (L/L)' '
+   # Apply ISO-8859-1 patches with ISO-8859-1 commitencoding
+   git config i18n.commitencoding ISO8859-1 
+   . $TEST_DIRECTORY/t3901-8859-1.txt 
+
+   git reset --hard master 
+   git am out-l1 out-l2 
+
+   check_encoding 2 8859
+'
+
+test_expect_success 'am (U/L)' '
+   # Apply ISO-8859-1 patches with UTF-8 commitencoding
+   git config i18n.commitencoding UTF-8 
+   . $TEST_DIRECTORY/t3901-utf8.txt 
+   git reset --hard master 
+
+   # am specifies --utf8 by default.
+   git am out-l1 out-l2 
+
+   check_encoding 2
+'
+
+test_expect_success 'am --no-utf8 (U/L)' '
+   # Apply ISO-8859-1 patches with UTF-8 commitencoding
+   git config i18n.commitencoding UTF-8 
+   . $TEST_DIRECTORY/t3901-utf8.txt 
+
+   git reset --hard master 
+   git am --no-utf8 out-l1 out-l2 2err 
+
+   # commit-tree will warn that the commit message does not contain valid 
UTF-8
+   # as mailinfo did not convert it
+   grep did not conform err 
+
+   check_encoding 2
+'
+
+test_expect_success !MINGW 'am (L/U)' '
+   # Apply UTF-8 patches with ISO-8859-1 commitencoding
+   git config i18n.commitencoding ISO8859-1 
+   . $TEST_DIRECTORY/t3901-8859-1.txt 
+
+   git reset --hard master 
+   # mailinfo will re-code the commit message to the charset specified by
+   # i18n.commitencoding
+   git am out-u1 out-u2 
+
+   check_encoding 2 8859
+'
+
 test_done
-- 
2.5.0.rc1.76.gf60a929

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

[PATCH v2 07/12] t4150: am with applypatch-msg hook

[Paul Tan]

Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07), git-am
will invoke the applypatch-msg hooks just after extracting the patch
message. If the applypatch-msg hook exits with a non-zero status, git-am
abort before even applying the patch to the index.

Add tests for this hook.

Helped-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Paul Tan pyoka...@gmail.com
---

Notes:
v2

* Use write_script() to shave off the shebang line and chmod.

 t/t4150-am.sh | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/t/t4150-am.sh b/t/t4150-am.sh
index c1ec4d5..7878e32 100755
--- a/t/t4150-am.sh
+++ b/t/t4150-am.sh
@@ -199,6 +199,41 @@ test_expect_success 'am applies patch e-mail with 
preceding whitespace' '
test $(git rev-parse second^) = $(git rev-parse HEAD^)
 '
 
+test_expect_success 'am with applypatch-msg hook' '
+   test_when_finished rm -f .git/hooks/applypatch-msg 
+   rm -fr .git/rebase-apply 
+   git reset --hard 
+   git checkout first 
+   mkdir -p .git/hooks 
+   write_script .git/hooks/applypatch-msg -\EOF 
+   cat $1 actual-msg 
+   echo hook-message $1
+   EOF
+   git am patch1 
+   test_path_is_missing .git/rebase-apply 
+   git diff --exit-code second 
+   echo hook-message expected 
+   git log -1 --format=format:%B actual 
+   test_cmp expected actual 
+   git log -1 --format=format:%B second expected 
+   test_cmp expected actual-msg
+'
+
+test_expect_success 'am with failing applypatch-msg hook' '
+   test_when_finished rm -f .git/hooks/applypatch-msg 
+   rm -fr .git/rebase-apply 
+   git reset --hard 
+   git checkout first 
+   mkdir -p .git/hooks 
+   write_script .git/hooks/applypatch-msg -\EOF 
+   exit 1
+   EOF
+   test_must_fail git am patch1 
+   test_path_is_dir .git/rebase-apply 
+   git diff --exit-code first 
+   test_cmp_rev first HEAD
+'
+
 test_expect_success 'setup: new author and committer' '
GIT_AUTHOR_NAME=Another Thor 
GIT_AUTHOR_EMAIL=a.t...@example.com 
-- 
2.5.0.rc1.76.gf60a929

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

[PATCH v2 01/12] t4150: am.messageid really adds the message id

[Paul Tan]

Since a078f73 (git-am: add --message-id/--no-message-id, 2014-11-25),
the am.messageid setting determines whether the --message-id option is
set by default.

Add a test for this.

Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Paul Tan pyoka...@gmail.com
---

Notes:
v2

* don't use git checkout -f as it does not discard unmerged entries.
  Use git reset --hard instead.

 t/t4150-am.sh | 12 
 1 file changed, 12 insertions(+)

diff --git a/t/t4150-am.sh b/t/t4150-am.sh
index b822a39..264f53f 100755
--- a/t/t4150-am.sh
+++ b/t/t4150-am.sh
@@ -563,6 +563,18 @@ test_expect_success 'am --message-id really adds the 
message id' '
test_cmp expected actual
 '
 
+test_expect_success 'am.messageid really adds the message id' '
+   rm -fr .git/rebase-apply 
+   git reset --hard 
+   git checkout HEAD^ 
+   test_config am.messageid true 
+   git am patch1.eml 
+   test_path_is_missing .git/rebase-apply 
+   git cat-file commit HEAD | tail -n1 actual 
+   grep Message-Id patch1.eml expected 
+   test_cmp expected actual
+'
+
 test_expect_success 'am --message-id -s signs off after the message id' '
rm -fr .git/rebase-apply 
git reset --hard 
-- 
2.5.0.rc1.76.gf60a929

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

[PATCH v2 02/12] t4150: am fails if index is dirty

[Paul Tan]

Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07), git-am
will ensure that the index is clean before applying the patch. This is
to prevent changes unrelated to the patch from being committed.

Add a test for this check.

Signed-off-by: Paul Tan pyoka...@gmail.com
---

Notes:
v2

* Should be rm -f dirtyfile instead of rm -rf dirtyfile

* Don't use git checkout -f -- it does not discard unmerged entries.
  Use git reset --hard instead.

 t/t4150-am.sh | 12 
 1 file changed, 12 insertions(+)

diff --git a/t/t4150-am.sh b/t/t4150-am.sh
index 264f53f..a85e06a 100755
--- a/t/t4150-am.sh
+++ b/t/t4150-am.sh
@@ -154,6 +154,18 @@ test_expect_success 'am applies patch correctly' '
test $(git rev-parse second^) = $(git rev-parse HEAD^)
 '
 
+test_expect_success 'am fails if index is dirty' '
+   test_when_finished rm -f dirtyfile 
+   rm -fr .git/rebase-apply 
+   git reset --hard 
+   git checkout first 
+   echo dirtyfile dirtyfile 
+   git add dirtyfile 
+   test_must_fail git am patch1 
+   test_path_is_dir .git/rebase-apply 
+   test_cmp_rev first HEAD
+'
+
 test_expect_success 'am applies patch e-mail not in a mbox' '
rm -fr .git/rebase-apply 
git reset --hard 
-- 
2.5.0.rc1.76.gf60a929

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

[PATCH v2 00/12] Improve git-am test coverage

[Paul Tan]

This is a re-roll of [v1]. Thanks Junio, Johannes, Paolo, Stefan for the
reviews last round. Interdiff below.

Previous versions:

[v1] http://thread.gmane.org/gmane.comp.version-control.git/273254

Increase test coverage of git-am.sh to help prevent regressions that could arise
from the rewrite of git-am.sh to C. This patch series, along with
pt/am-foreign, improved test coverage as measured by kcov from 56.5%[1] to
67.3%[2].

No tests for git-am's interactive mode, though, as test_terminal does not seem
to attach a pseudo-tty to stdin(?), thus making git-am's test -t 0 check fail.

This is part of my GSoC project to rewrite git-am.sh to a C builtin[3].

[1] 
http://pyokagan.github.io/git/20150430132408-a75942b//kcov-merged/git-am.eb79278e.html
[2] 
http://pyokagan.github.io/git/20150702173751-2fdae08//kcov-merged/git-am.eb79278e.html
[3] https://gist.github.com/pyokagan/1b7b0d1f4dab6ba3cef1

Paul Tan (12):
  t4150: am.messageid really adds the message id
  t4150: am fails if index is dirty
  t4151: am --abort will keep dirty index intact
  t4150: am refuses patches when paused
  t4150: am --resolved fails if index has no changes
  t4150: am --resolved fails if index has unmerged entries
  t4150: am with applypatch-msg hook
  t4150: am with pre-applypatch hook
  t4150: am with post-applypatch hook
  t4150: tests for am --[no-]scissors
  t3418: non-interactive rebase --continue with rerere enabled
  t3901: test git-am encoding conversion

 t/t3418-rebase-continue.sh |  19 
 t/t3901-i18n-patch.sh  |  62 +
 t/t4150-am.sh  | 217 +
 t/t4151-am-abort.sh|  15 
 4 files changed, 313 insertions(+)

diff --git a/t/t4150-am.sh b/t/t4150-am.sh
index 94e7c18..67fbf0e 100755
--- a/t/t4150-am.sh
+++ b/t/t4150-am.sh
@@ -182,9 +182,10 @@ test_expect_success 'am applies patch correctly' '
 '
 
 test_expect_success 'am fails if index is dirty' '
-   test_when_finished rm -fr dirtyfile 
+   test_when_finished rm -f dirtyfile 
rm -fr .git/rebase-apply 
-   git checkout -f first 
+   git reset --hard 
+   git checkout first 
echo dirtyfile dirtyfile 
git add dirtyfile 
test_must_fail git am patch1 
@@ -231,12 +232,10 @@ test_expect_success 'am with applypatch-msg hook' '
git reset --hard 
git checkout first 
mkdir -p .git/hooks 
-   cat .git/hooks/applypatch-msg -\EOF 
-   #!/bin/sh
+   write_script .git/hooks/applypatch-msg -\EOF 
cat $1 actual-msg 
echo hook-message $1
EOF
-   chmod +x .git/hooks/applypatch-msg 
git am patch1 
test_path_is_missing .git/rebase-apply 
git diff --exit-code second 
@@ -253,11 +252,9 @@ test_expect_success 'am with failing applypatch-msg hook' '
git reset --hard 
git checkout first 
mkdir -p .git/hooks 
-   cat .git/hooks/applypatch-msg -\EOF 
-   #!/bin/sh
+   write_script .git/hooks/applypatch-msg -\EOF 
exit 1
EOF
-   chmod +x .git/hooks/applypatch-msg 
test_must_fail git am patch1 
test_path_is_dir .git/rebase-apply 
git diff --exit-code first 
@@ -270,17 +267,14 @@ test_expect_success 'am with pre-applypatch hook' '
git reset --hard 
git checkout first 
mkdir -p .git/hooks 
-   cat .git/hooks/pre-applypatch -\EOF 
-   #!/bin/sh
+   write_script .git/hooks/pre-applypatch -\EOF 
git diff first diff.actual
exit 0
EOF
-   chmod +x .git/hooks/pre-applypatch 
git am patch1 
test_path_is_missing .git/rebase-apply 
git diff --exit-code second 
test_cmp_rev second HEAD 
-   test_cmp_rev second^ HEAD^ 
git diff first..second diff.expected 
test_cmp diff.expected diff.actual
 '
@@ -291,11 +285,9 @@ test_expect_success 'am with failing pre-applypatch hook' '
git reset --hard 
git checkout first 
mkdir -p .git/hooks 
-   cat .git/hooks/pre-applypatch -\EOF 
-   #!/bin/sh
+   write_script .git/hooks/pre-applypatch -\EOF 
exit 1
EOF
-   chmod +x .git/hooks/pre-applypatch 
test_must_fail git am patch1 
test_path_is_dir .git/rebase-apply 
git diff --exit-code second 
@@ -308,13 +300,11 @@ test_expect_success 'am with post-applypatch hook' '
git reset --hard 
git checkout first 
mkdir -p .git/hooks 
-   cat .git/hooks/post-applypatch -\EOF 
-   #!/bin/sh
+   write_script .git/hooks/post-applypatch -\EOF 
git rev-parse HEAD head.actual
git diff second diff.actual
exit 0
EOF
-   chmod +x .git/hooks/post-applypatch 
git am patch1 
test_path_is_missing .git/rebase-apply 
test_cmp_rev second HEAD 
@@ -330,12 +320,10 @@ test_expect_success 'am with failing post-applypatch 
hook' '
git reset --hard 
git 

[PATCH v2 06/12] t4150: am --resolved fails if index has unmerged entries

[Paul Tan]

Since c1d1128 (git-am --resolved: more usable error message.,
2006-04-28), git-am --resolved will check to see if there are any
unmerged entries, and will error out with a user-friendly error message
if there are.

Add a test for this.

Signed-off-by: Paul Tan pyoka...@gmail.com
---
 t/t4150-am.sh | 13 +
 1 file changed, 13 insertions(+)

diff --git a/t/t4150-am.sh b/t/t4150-am.sh
index 430ae71..c1ec4d5 100755
--- a/t/t4150-am.sh
+++ b/t/t4150-am.sh
@@ -437,6 +437,19 @@ test_expect_success 'am --resolved fails if index has no 
changes' '
test_cmp_rev lorem2^^ HEAD
 '
 
+test_expect_success 'am --resolved fails if index has unmerged entries' '
+   rm -fr .git/rebase-apply 
+   git reset --hard 
+   git checkout second 
+   test_must_fail git am -3 lorem-move.patch 
+   test_path_is_dir .git/rebase-apply 
+   test_cmp_rev second HEAD 
+   test_must_fail git am --resolved err 
+   test_path_is_dir .git/rebase-apply 
+   test_cmp_rev second HEAD 
+   test_i18ngrep still have unmerged paths err
+'
+
 test_expect_success 'am takes patches from a Pine mailbox' '
rm -fr .git/rebase-apply 
git reset --hard 
-- 
2.5.0.rc1.76.gf60a929

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

[PATCH v2 09/12] t4150: am with post-applypatch hook

[Paul Tan]

Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07),
git-am.sh will invoke the post-applypatch hook after the patch is
applied and a commit is made. The exit code of the hook is ignored.

Add tests for this hook.

Helped-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Paul Tan pyoka...@gmail.com
---

Notes:
v2

* use write_script() to shave off the shebang line and chmod

 t/t4150-am.sh | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/t/t4150-am.sh b/t/t4150-am.sh
index 957c63c..7494240 100755
--- a/t/t4150-am.sh
+++ b/t/t4150-am.sh
@@ -267,6 +267,44 @@ test_expect_success 'am with failing pre-applypatch hook' '
test_cmp_rev first HEAD
 '
 
+test_expect_success 'am with post-applypatch hook' '
+   test_when_finished rm -f .git/hooks/post-applypatch 
+   rm -fr .git/rebase-apply 
+   git reset --hard 
+   git checkout first 
+   mkdir -p .git/hooks 
+   write_script .git/hooks/post-applypatch -\EOF 
+   git rev-parse HEAD head.actual
+   git diff second diff.actual
+   exit 0
+   EOF
+   git am patch1 
+   test_path_is_missing .git/rebase-apply 
+   test_cmp_rev second HEAD 
+   git rev-parse second head.expected 
+   test_cmp head.expected head.actual 
+   git diff second diff.expected 
+   test_cmp diff.expected diff.actual
+'
+
+test_expect_success 'am with failing post-applypatch hook' '
+   test_when_finished rm -f .git/hooks/post-applypatch 
+   rm -fr .git/rebase-apply 
+   git reset --hard 
+   git checkout first 
+   mkdir -p .git/hooks 
+   write_script .git/hooks/post-applypatch -\EOF 
+   git rev-parse HEAD head.actual
+   exit 1
+   EOF
+   git am patch1 
+   test_path_is_missing .git/rebase-apply 
+   git diff --exit-code second 
+   test_cmp_rev second HEAD 
+   git rev-parse second head.expected 
+   test_cmp head.expected head.actual
+'
+
 test_expect_success 'setup: new author and committer' '
GIT_AUTHOR_NAME=Another Thor 
GIT_AUTHOR_EMAIL=a.t...@example.com 
-- 
2.5.0.rc1.76.gf60a929

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

[PATCH v2 11/12] t3418: non-interactive rebase --continue with rerere enabled

[Paul Tan]

Since 8389b52 (git-rerere: reuse recorded resolve., 2006-01-28), git-am
will call git-rerere to re-use recorded merge conflict resolutions if
any occur in a threeway merge.

Add a test to ensure that git-rerere is called by git-am (which handles
the non-interactive rebase).

Signed-off-by: Paul Tan pyoka...@gmail.com
---
 t/t3418-rebase-continue.sh | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/t/t3418-rebase-continue.sh b/t/t3418-rebase-continue.sh
index 2680375..4428b90 100755
--- a/t/t3418-rebase-continue.sh
+++ b/t/t3418-rebase-continue.sh
@@ -40,6 +40,25 @@ test_expect_success 'non-interactive rebase --continue works 
with touched file'
git rebase --continue
 '
 
+test_expect_success 'non-interactive rebase --continue with rerere enabled' '
+   test_config rerere.enabled true 
+   test_when_finished test_might_fail git rebase --abort 
+   git reset --hard commit-new-file-F2-on-topic-branch 
+   git checkout master 
+   rm -fr .git/rebase-* 
+
+   test_must_fail git rebase --onto master master topic 
+   echo Resolved F2 
+   git add F2 
+   cp F2 F2.expected 
+   git rebase --continue 
+
+   git reset --hard commit-new-file-F2-on-topic-branch 
+   git checkout master 
+   test_must_fail git rebase --onto master master topic 
+   test_cmp F2.expected F2
+'
+
 test_expect_success 'rebase --continue can not be used with other options' '
test_must_fail git rebase -v --continue 
test_must_fail git rebase --continue -v
-- 
2.5.0.rc1.76.gf60a929

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

[PATCH v2 08/12] t4150: am with pre-applypatch hook

[Paul Tan]

Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07),
git-am.sg will invoke the pre-applypatch hook after applying the patch
to the index, but before a commit is made. Should the hook exit with a
non-zero status, git am will exit.

Add tests for this hook.

Helped-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Paul Tan pyoka...@gmail.com
---

Notes:
v2

* Use write_script() to shave off the shebang line and chmod.

 t/t4150-am.sh | 33 +
 1 file changed, 33 insertions(+)

diff --git a/t/t4150-am.sh b/t/t4150-am.sh
index 7878e32..957c63c 100755
--- a/t/t4150-am.sh
+++ b/t/t4150-am.sh
@@ -234,6 +234,39 @@ test_expect_success 'am with failing applypatch-msg hook' '
test_cmp_rev first HEAD
 '
 
+test_expect_success 'am with pre-applypatch hook' '
+   test_when_finished rm -f .git/hooks/pre-applypatch 
+   rm -fr .git/rebase-apply 
+   git reset --hard 
+   git checkout first 
+   mkdir -p .git/hooks 
+   write_script .git/hooks/pre-applypatch -\EOF 
+   git diff first diff.actual
+   exit 0
+   EOF
+   git am patch1 
+   test_path_is_missing .git/rebase-apply 
+   git diff --exit-code second 
+   test_cmp_rev second HEAD 
+   git diff first..second diff.expected 
+   test_cmp diff.expected diff.actual
+'
+
+test_expect_success 'am with failing pre-applypatch hook' '
+   test_when_finished rm -f .git/hooks/pre-applypatch 
+   rm -fr .git/rebase-apply 
+   git reset --hard 
+   git checkout first 
+   mkdir -p .git/hooks 
+   write_script .git/hooks/pre-applypatch -\EOF 
+   exit 1
+   EOF
+   test_must_fail git am patch1 
+   test_path_is_dir .git/rebase-apply 
+   git diff --exit-code second 
+   test_cmp_rev first HEAD
+'
+
 test_expect_success 'setup: new author and committer' '
GIT_AUTHOR_NAME=Another Thor 
GIT_AUTHOR_EMAIL=a.t...@example.com 
-- 
2.5.0.rc1.76.gf60a929

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

[PATCH v2 05/12] t4150: am --resolved fails if index has no changes

[Paul Tan]

Since 6d28644 (git-am: do not allow empty commits by mistake.,
2006-02-23), git-am --resolved will check to see if the index has any
changes to prevent the user from creating an empty commit by mistake.

Add a test for this.

Signed-off-by: Paul Tan pyoka...@gmail.com
---
 t/t4150-am.sh | 12 
 1 file changed, 12 insertions(+)

diff --git a/t/t4150-am.sh b/t/t4150-am.sh
index c350967..430ae71 100755
--- a/t/t4150-am.sh
+++ b/t/t4150-am.sh
@@ -425,6 +425,18 @@ test_expect_success 'am --resolved works' '
test_cmp expected another
 '
 
+test_expect_success 'am --resolved fails if index has no changes' '
+   rm -fr .git/rebase-apply 
+   git reset --hard 
+   git checkout lorem2^^ 
+   test_must_fail git am lorem-move.patch 
+   test_path_is_dir .git/rebase-apply 
+   test_cmp_rev lorem2^^ HEAD 
+   test_must_fail git am --resolved 
+   test_path_is_dir .git/rebase-apply 
+   test_cmp_rev lorem2^^ HEAD
+'
+
 test_expect_success 'am takes patches from a Pine mailbox' '
rm -fr .git/rebase-apply 
git reset --hard 
-- 
2.5.0.rc1.76.gf60a929

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

[PATCH v2 10/12] t4150: tests for am --[no-]scissors

[Paul Tan]

Since 017678b (am/mailinfo: Disable scissors processing by default,
2009-08-26), git-am supported the --[no-]scissors option, passing it to
git-mailinfo.

Add tests to ensure that git-am will pass the --scissors option to
git-mailinfo, and that --no-scissors will override the configuration
setting of mailinfo.scissors.

Signed-off-by: Paul Tan pyoka...@gmail.com
---
 t/t4150-am.sh | 48 
 1 file changed, 48 insertions(+)

diff --git a/t/t4150-am.sh b/t/t4150-am.sh
index 7494240..67fbf0e 100755
--- a/t/t4150-am.sh
+++ b/t/t4150-am.sh
@@ -67,6 +67,19 @@ test_expect_success 'setup: messages' '
 
EOF
 
+   cat scissors-msg -\EOF 
+   Test git-am with scissors line
+
+   This line should be included in the commit message.
+   EOF
+
+   cat - scissors-msg no-scissors-msg -\EOF 
+   This line should not be included in the commit message with --scissors 
enabled.
+
+- - 8 - - remove everything above this line - - 8 - -
+
+   EOF
+
signoff=Signed-off-by: $GIT_COMMITTER_NAME $GIT_COMMITTER_EMAIL
 '
 
@@ -105,6 +118,20 @@ test_expect_success setup '
git format-patch --stdout first | sed -e 1d
}  patch1-ws.eml 
 
+   echo scissors-file scissors-file 
+   git add scissors-file 
+   git commit -F scissors-msg 
+   git tag scissors 
+   git format-patch --stdout scissors^ scissors-patch.eml 
+   git reset --hard HEAD^ 
+
+   echo no-scissors-file no-scissors-file 
+   git add no-scissors-file 
+   git commit -F no-scissors-msg 
+   git tag no-scissors 
+   git format-patch --stdout no-scissors^ no-scissors-patch.eml 
+   git reset --hard HEAD^ 
+
sed -n -e 3,\$p msg file 
git add file 
test_tick 
@@ -305,6 +332,27 @@ test_expect_success 'am with failing post-applypatch hook' 
'
test_cmp head.expected head.actual
 '
 
+test_expect_success 'am --scissors cuts the message at the scissors line' '
+   rm -fr .git/rebase-apply 
+   git reset --hard 
+   git checkout second 
+   git am --scissors scissors-patch.eml 
+   test_path_is_missing .git/rebase-apply 
+   git diff --exit-code scissors 
+   test_cmp_rev scissors HEAD
+'
+
+test_expect_success 'am --no-scissors overrides mailinfo.scissors' '
+   rm -fr .git/rebase-apply 
+   git reset --hard 
+   git checkout second 
+   test_config mailinfo.scissors true 
+   git am --no-scissors no-scissors-patch.eml 
+   test_path_is_missing .git/rebase-apply 
+   git diff --exit-code no-scissors 
+   test_cmp_rev no-scissors HEAD
+'
+
 test_expect_success 'setup: new author and committer' '
GIT_AUTHOR_NAME=Another Thor 
GIT_AUTHOR_EMAIL=a.t...@example.com 
-- 
2.5.0.rc1.76.gf60a929

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