Re: Shallow Push?

[Samuel Williams]

> What is the receiving repository expected to have?  Does it have
everything that is required to checkout the back-then latest HEAD
the last time a push was made into it, and you are pushing an
update?

Yes, something like that

On 9 April 2015 at 15:54, Junio C Hamano  wrote:
> Samuel Williams  writes:
>
>> Is it possible to only push what is required to checkout the latest HEAD?
>
> What is the receiving repository expected to have?  Does it have
> everything that is required to checkout the back-then latest HEAD
> the last time a push was made into it, and you are pushing an
> update?
>
--
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] diff-tree: do not show the sha1 of the given head with --quiet

[Sebastian Schuberth]

"--quite" is documented to "Disable all output of the program". Yet
calling diff-tree with a single commit like

$ git diff-tree --quiet c925fe2

was logging

c925fe23684455735c3bb1903803643a24a58d8f

to the console despite "--quite" being given. This is inconsistent with
both the docs and the behavior if more than a single commit is passed to
diff-tree. Moreover, the output of that single line seems to be documented
nowhere except in a comment for a test. Fix this inconsistency by making
diff-tree really output nothing if "--quiet" is given and fix the test
accordingly.

Signed-off-by: Sebastian Schuberth 
---
 log-tree.c| 3 ++-
 t/t4035-diff-quiet.sh | 3 +--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/log-tree.c b/log-tree.c
index 01beb11..3c98234 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -741,7 +741,8 @@ int log_tree_diff_flush(struct rev_info *opt)
}
 
if (opt->loginfo && !opt->no_commit_id) {
-   show_log(opt);
+   if (!DIFF_OPT_TST(&opt->diffopt, QUICK))
+   show_log(opt);
if ((opt->diffopt.output_format & ~DIFF_FORMAT_NO_OUTPUT) &&
opt->verbose_header &&
opt->commit_format != CMIT_FMT_ONELINE &&
diff --git a/t/t4035-diff-quiet.sh b/t/t4035-diff-quiet.sh
index 461f4bb..9a8225f 100755
--- a/t/t4035-diff-quiet.sh
+++ b/t/t4035-diff-quiet.sh
@@ -40,11 +40,10 @@ test_expect_success 'git diff-tree HEAD^ HEAD -- b' '
test_expect_code 1 git diff-tree --quiet HEAD^ HEAD -- b >cnt &&
test_line_count = 0 cnt
 '
-# this diff outputs one line: sha1 of the given head
 test_expect_success 'echo HEAD | git diff-tree --stdin' '
echo $(git rev-parse HEAD) |
test_expect_code 1 git diff-tree --quiet --stdin >cnt &&
-   test_line_count = 1 cnt
+   test_line_count = 0 cnt
 '
 test_expect_success 'git diff-tree HEAD HEAD' '
test_expect_code 0 git diff-tree --quiet HEAD HEAD >cnt &&

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

Re: [PATCH 2/2] Fix sed usage in tests to work around broken xpg4/sed on Solaris

[Johannes Schindelin]

Hi,

On 2015-07-20 18:07, Junio C Hamano wrote:
> Johannes Sixt  writes:
> 
>>> I really wonder why the previous ">file+ && mv -f file+ file" dance
>>> needs to be replaced?
>>
>> The sed must be replaced because some versions on Solaris choke on the
>> incomplete last line in the file.
> 
> Switching from sed to perl is not being questioned.
> 
> I think Dscho is asking about the use of "-i", when the original
> idiom ">target+ && mv -f target+ target" worked perfectly fine.
> 
> I.e.
> 
>   perl -p -e '...' file >file+ &&
> mv file+ file

Thanks for translating from Dscho to English.

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: What's cooking in git.git (Jul 2015, #01; Wed, 1)

[Tony Finch]

Jakub Narębski  wrote:
>

Thanks for the review!

> > * tf/gitweb-project-listing (2015-03-19) 5 commits
> >  - gitweb: make category headings into links when they are directories
> >  - gitweb: optionally set project category from its pathname
> >  - gitweb: add a link under the search box to clear a project filter
> >  - gitweb: if the PATH_INFO is incomplete, use it as a project_filter
> >
> >  Update gitweb to make it more pleasant to deal with a hierarchical
> >  forest of repositories.

By the way, you can see this patch series in action at
https://git.csx.cam.ac.uk/x/ucs/

> Second one, "gitweb: if the PATH_INFO is incomplete, use it as a
> project_filter" looks interesting and quite useful. Though it doesn't
> do much: it allows for handcrafted URL, and provides mechanism to
> create breadcrumbs. It doesn't use this feature in its output...
> Well, I think it doesn't: I cannot check it at this moment.

Hmm, I think this means I need a better commit message.

This patch fixes the ugly query-parameter URLs in the breadcrumbs that
you get even in path-info mode. Have a look at the breadcrumbs on the
following pages:

https://git.csx.cam.ac.uk/g/ucs/git/git.git (unpatched)
https://git.csx.cam.ac.uk/x/ucs/git/git.git (patched)

If you click on the antepenultimate /git/ in the breadcumbs you get query
parameters without the patch and path_info with the patch. With the patch
the breadcrumbs match the URL.

> What is missing is a support for query parameters path, and not only
> path info.

Query parameter support is already present, in the form of project
filters.

> Thought some thought is needed for generating (or not) breadcrumbs
> if path_info is turned off.

That already works in unpatched gitweb.

> The third, "gitweb: add a link under the search box to clear a project
> filter" notices a problem... then solves it in strange way. IMVHO
> a better solution would be to add "List all projects" URL together
> with " / " (or other separator) conditionally, if $project_filter
> is set. Or have "List all projects" and add "List projects$limit"
> if $project_filter is set.

Yes, that is exactly what the patch does. I used a suffix "if" to align
the print statements and markup:
+   if $project_filter;

Compare and contrast the search box on these pages:

https://git.csx.cam.ac.uk/g/ucs/?a=project_list;pf=u/fanf2
https://git.csx.cam.ac.uk/x/ucs/u/fanf2/

Perhaps you would prefer the following?

--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -5549,10 +5549,14 @@ sub git_project_search_form {
  "\n" .
  $cgi->submit(-name => 'btnS', -value => 'Search') .
  $cgi->end_form() . "\n" .
- $cgi->a({-href => href(project => undef, searchtext => undef,
-project_filter => $project_filter)},
- esc_html("List all projects$limit")) . "\n";
-   print "\n";
+ $cgi->a({-href => $my_uri}, esc_html("List all projects"));
+   if ($project_filter) {
+   print " / " .
+   $cgi->a({-href => href(project => undef, action => 
"project_list",
+  project_filter => $project_filter)},
+   esc_html("List projects$limit"));
+   }
+   print "\n\n";
 }

 # entry for given @keys needs filling if at least one of keys in list

> The last two, which form the crux of this patch series, looks like
> a good idea, though not without a few caveats. I am talking here
> only about conceptual level, not about how it is coded (which has
> few issues as well):
>
> - I think that non-bare repositories "repo/.git" should be
>   treated as one directory entry, i.e. gitweb should not create
>   a separate category for "repo/".  This is admittedly a corner
>   case, but useful for git-instaweb

Yes, that's a bug, thanks for spotting it!

> - I think that people would want to be able to configure how
>   many levels of directory hierarchy gets turned into categories.
>   Perhaps only top level should be turned into category? Deep
>   hierarchies means deep categories (usually with very few
>   repositories) with current implementation.

Good question. I was assuming flat-ish directory hierarchies, but that's
clearly not very true, e.g. https://git.kernel.org/cgit/

I think it would be right to make this a %feature since categories already
nearly fit the %feature per-project override style.

I will send a new version of the series shortly.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Viking, North Utsire: Westerly 4 or 5, occasionally 6 at first, backing
southerly 3 or 4. Moderate becoming slight. Occasional rain in north. Good,
occasionally moderate.

Re: What's cooking in git.git (Jul 2015, #01; Wed, 1)

[Jakub Narębski]

On 2015-07-22, Tony Finch wrote:
> Jakub Narębski  wrote:
> 
> Thanks for the review!
> 
>>> * tf/gitweb-project-listing (2015-03-19) 5 commits
>>>  - gitweb: make category headings into links when they are directories
>>>  - gitweb: optionally set project category from its pathname
>>>  - gitweb: add a link under the search box to clear a project filter
>>>  - gitweb: if the PATH_INFO is incomplete, use it as a project_filter
>>>
>>>  Update gitweb to make it more pleasant to deal with a hierarchical
>>>  forest of repositories.
> 
> By the way, you can see this patch series in action at
> https://git.csx.cam.ac.uk/x/ucs/

Thanks. I don't have my computer set up completely yet (after reinstall).

>> Second one, "gitweb: if the PATH_INFO is incomplete, use it as a
>> project_filter" looks interesting and quite useful. Though it doesn't
>> do much: it allows for handcrafted URL, and provides mechanism to
>> create breadcrumbs. It doesn't use this feature in its output...
>> Well, I think it doesn't: I cannot check it at this moment.
> 
> Hmm, I think this means I need a better commit message.
> 
> This patch fixes the ugly query-parameter URLs in the breadcrumbs that
> you get even in path-info mode. Have a look at the breadcrumbs on the
> following pages:
> 
> https://git.csx.cam.ac.uk/g/ucs/git/git.git (unpatched)
> https://git.csx.cam.ac.uk/x/ucs/git/git.git (patched)
> 
> If you click on the antepenultimate /git/ in the breadcumbs you get query
> parameters without the patch and path_info with the patch. With the patch
> the breadcrumbs match the URL.

Ah. Yes, the patch itself looks all right, but it definitely needs
a better (or at least enhanced) commit message if it is about *adding*
path info counterpart to existing query parameter project_filter -
- it is (also) about uniquifying URLs used in breadcrumbs when gitweb
uses path info links.

Current version is (if I have it correctly):

gitweb: if the PATH_INFO is incomplete, use it as a project_filter

Previously gitweb would ignore partial PATH_INFO. For example,
it would produce a project list for the top URL
https://www.example.org/projects/
and a project summary for
https://www.example.org/projects/git/git.git
but if you tried to list just the git-related projects with
https://www.example.org/projects/git/
you would get a list of all projects, same as the top URL.

As well as fixing that omission, this change also makes gitweb
generate PATH_INFO-style URLs for project filter links, such
as in the breadcrumbs.

A question about implementation: why emptying $path_info in
evaluate_path_info()?

>> What is missing is a support for query parameters path, and not only
>> path info.
> 
> Query parameter support is already present, in the form of project
> filters.
> 
>> Thought some thought is needed for generating (or not) breadcrumbs
>> if path_info is turned off.
> 
> That already works in unpatched gitweb.

Right.

>> The third, "gitweb: add a link under the search box to clear a project
>> filter" notices a problem... then solves it in strange way. IMVHO
>> a better solution would be to add "List all projects" URL together
>> with " / " (or other separator) conditionally, if $project_filter
>> is set. Or have "List all projects" and add "List projects$limit"
>> if $project_filter is set.
> 
> Yes, that is exactly what the patch does. I used a suffix "if" to align
> the print statements and markup:
> +   if $project_filter;
> 
> Compare and contrast the search box on these pages:
> 
> https://git.csx.cam.ac.uk/g/ucs/?a=project_list;pf=u/fanf2
> https://git.csx.cam.ac.uk/x/ucs/u/fanf2/
> 
> Perhaps you would prefer the following?
> 
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -5549,10 +5549,14 @@ sub git_project_search_form {
>   "\n" .
>   $cgi->submit(-name => 'btnS', -value => 'Search') .
>   $cgi->end_form() . "\n" .
> - $cgi->a({-href => href(project => undef, searchtext => undef,
> -project_filter => $project_filter)},
> - esc_html("List all projects$limit")) . "\n";
> -   print "\n";
> + $cgi->a({-href => $my_uri}, esc_html("List all projects"));
> +   if ($project_filter) {
> +   print " / " .
> +   $cgi->a({-href => href(project => undef, action => 
> "project_list",
> +  project_filter => 
> $project_filter)},
> +   esc_html("List projects$limit"));
> +   }
> +   print "\n\n";
>  }
> 
>  # entry for given @keys needs filling if at least one of keys in list

Yes, it is eminently more readable. 

Postfix controls are discouraged, especially with multi-line constructs
c.f. Perl::Critic::Policy::ControlStructures::ProhibitPostfixControls

>> The last two, which form the crux of this patch series, looks like
>> a good idea, though not without 

Re: [PATCH] diff-tree: do not show the sha1 of the given head with --quiet

[Johannes Schindelin]

On 2015-07-22 11:29, Sebastian Schuberth wrote:
> "--quite" is documented to "Disable all output of the program".

s/--quite/quiet/
--
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] diff-tree: do not show the sha1 of the given head with --quiet

[Sebastian Schuberth]

"--quiet" is documented to "Disable all output of the program". Yet
calling diff-tree with a single commit like

$ git diff-tree --quiet c925fe2

was logging

c925fe23684455735c3bb1903803643a24a58d8f

to the console despite "--quiet" being given. This is inconsistent with
both the docs and the behavior if more than a single commit is passed to
diff-tree. Moreover, the output of that single line seems to be documented
nowhere except in a comment for a test. Fix this inconsistency by making
diff-tree really output nothing if "--quiet" is given and fix the test
accordingly.

Signed-off-by: Sebastian Schuberth 
---
 log-tree.c| 3 ++-
 t/t4035-diff-quiet.sh | 3 +--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/log-tree.c b/log-tree.c
index 01beb11..3c98234 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -741,7 +741,8 @@ int log_tree_diff_flush(struct rev_info *opt)
}
 
if (opt->loginfo && !opt->no_commit_id) {
-   show_log(opt);
+   if (!DIFF_OPT_TST(&opt->diffopt, QUICK))
+   show_log(opt);
if ((opt->diffopt.output_format & ~DIFF_FORMAT_NO_OUTPUT) &&
opt->verbose_header &&
opt->commit_format != CMIT_FMT_ONELINE &&
diff --git a/t/t4035-diff-quiet.sh b/t/t4035-diff-quiet.sh
index 461f4bb..9a8225f 100755
--- a/t/t4035-diff-quiet.sh
+++ b/t/t4035-diff-quiet.sh
@@ -40,11 +40,10 @@ test_expect_success 'git diff-tree HEAD^ HEAD -- b' '
test_expect_code 1 git diff-tree --quiet HEAD^ HEAD -- b >cnt &&
test_line_count = 0 cnt
 '
-# this diff outputs one line: sha1 of the given head
 test_expect_success 'echo HEAD | git diff-tree --stdin' '
echo $(git rev-parse HEAD) |
test_expect_code 1 git diff-tree --quiet --stdin >cnt &&
-   test_line_count = 1 cnt
+   test_line_count = 0 cnt
 '
 test_expect_success 'git diff-tree HEAD HEAD' '
test_expect_code 0 git diff-tree --quiet HEAD HEAD >cnt &&

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

Re: What's cooking in git.git (Jul 2015, #01; Wed, 1)

[Tony Finch]

Jakub Narębski  wrote:
>
> A question about implementation: why emptying $path_info in
> evaluate_path_info()?

That was for consistency with other parts of the subroutine which (mostly)
remove items from the global $path_info variable when they are added to
%input_params. But since $path_info isn't used after it has been parsed, I
suppose it is redundant.

> >> - I think that people would want to be able to configure how
> >>   many levels of directory hierarchy gets turned into categories.
> >>   Perhaps only top level should be turned into category? Deep
> >>   hierarchies means deep categories (usually with very few
> >>   repositories) with current implementation.
> >
> > Good question. I was assuming flat-ish directory hierarchies, but that's
> > clearly not very true, e.g. https://git.kernel.org/cgit/
> >
> > I think it would be right to make this a %feature since categories already
> > nearly fit the %feature per-project override style.
>
> On the other hand $projects_list_group_categories is a global gitweb
> configuration variable, and $projects_list_directory_is_category was
> patterned after it.

Yes... Which do you prefer? :-)

> A few thoughts about implementation:

Helpful, thanks!

> - can we turn category header into link even if the category didn't
>   came from $projects_list_directory_is_category?

That would mean changing the project filter to match categories as well as
paths. I don't know if this is the right thing to do; perhaps it is,
because the current behaviour of my category headings is a bit surprising.

At the moment, clicking on the "git" category heading on the page linked
below takes you to a page that does not list all the repos that were under
the category heading on the main page.

https://git.csx.cam.ac.uk/x/ucs/

> - even if $projects_list_directory_is_category is true, the category
>   could came from 'category' file, or otherwise manually set category,
>   though I wonder how we can easily detect this...

Yes - I use this to list my personal/experimental repos alongside
the production repos.

I'm not sure why gitweb would need to detect this or what it would do in
response. At the moment it "just works", apart from the oddity with
categories vs project filters i described above.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Viking, North Utsire: Westerly 4 or 5, occasionally 6 at first, backing
southerly 3 or 4. Moderate becoming slight. Occasional rain in north. Good,
occasionally moderate.

[PATCH v3] refs: loosen restrictions on wildcard '*' refspecs

[Jacob Keller]

From: Jacob Keller 

Update the check_refname_component logic in order to allow for a less
strict refspec format in regards to REFNAME_REFSPEC_PATTERN. Previously
the '*' could only replace a single full component, and could not
replace arbitrary text. Now, refs such as `foo/bar*:foo/bar*` will be
accepted. This allows for somewhat more flexibility in references and
does not break any current users. The ref matching code already allows
this but the check_refname_format did not. Note this does also allow
refs such as `foo/bar*:foe/baz*`, that is, arbitrary renames. This was
already possible with namespace sections before, but now is possible
even as part of the pattern section. Since users have to explicitly type
these into the configuration it does not seem an issue.

Also streamline the code by making this new check part of
check_refname_component instead of checking after we error during
check_refname_format, which fits better with how other issues in refname
components are checked.

Signed-off-by: Jacob Keller 
Cc: Daniel Barkalow 
Cc: Junio C Hamano 
---

I updated the patch description a bit. This is also re-based onto the
next/ branch in-case. This is mostly a resend so that anyone interested
in review has another chance to see the patch.

 Documentation/git-check-ref-format.txt |  4 ++--
 refs.c | 39 +++---
 refs.h |  4 ++--
 t/t1402-check-ref-format.sh|  8 ---
 4 files changed, 31 insertions(+), 24 deletions(-)

diff --git a/Documentation/git-check-ref-format.txt 
b/Documentation/git-check-ref-format.txt
index fc02959ba4ab..9044dfaadae1 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -94,8 +94,8 @@ OPTIONS
Interpret  as a reference name pattern for a refspec
(as used with remote repositories).  If this option is
enabled,  is allowed to contain a single `*`
-   in place of a one full pathname component (e.g.,
-   `foo/*/bar` but not `foo/bar*`).
+   in the refspec (e.g., `foo/bar*/baz` or `foo/bar*baz/`
+   but not `foo/bar*/baz*`).
 
 --normalize::
Normalize 'refname' by removing any leading slash (`/`)
diff --git a/refs.c b/refs.c
index ce8cd8d45001..3002015ff289 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: check for patterns to reject unless REFNAME_REFSPEC_PATTERN is set
  */
 static unsigned char refname_disposition[256] = {
1, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4,
4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4,
-   4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, 2, 1,
+   4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 5, 0, 0, 0, 2, 1,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, 0, 4,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 4, 0, 4, 0,
@@ -71,11 +72,13 @@ static unsigned char refname_disposition[256] = {
  * - any path component of it begins with ".", or
  * - it has double dots "..", or
  * - it has ASCII control character, "~", "^", ":" or SP, anywhere, or
- * - it ends with a "/".
- * - it ends with ".lock"
- * - it contains a "\" (backslash)
+ * - it ends with a "/", or
+ * - it ends with ".lock", or
+ * - it contains a "\" (backslash), or
+ * - it contains a "@{" portion, or
+ * - it contains a '*' unless REFNAME_REFSPEC_PATTERN is set
  */
-static int check_refname_component(const char *refname, int flags)
+static int check_refname_component(const char *refname, int *flags)
 {
const char *cp;
char last = '\0';
@@ -96,6 +99,16 @@ static int check_refname_component(const char *refname, int 
flags)
break;
case 4:
return -1;
+   case 5:
+   if (!(*flags & REFNAME_REFSPEC_PATTERN))
+   return -1; /* refspec can't be a pattern */
+
+   /*
+* Unset the pattern flag so that we only accept a 
single glob for
+* the entire refspec.
+*/
+   *flags &= ~ REFNAME_REFSPEC_PATTERN;
+   break;
}
last = ch;
}
@@ -120,18 +133,10 @@ int check_refname_format(const char *refname, int flags)
 
while (1) {
/* We are at the start of a path component. */
-   component_len = check_refname_component(refname, flags);
-   if (component_len <= 0) {
-   if ((flags & REFNAME_REFSPEC_PATTERN) &&
-   refname[0] == '*' &&
-   (refname[1] == '\0' || refname[1] == 
'/')) {
-

Re: [PATCH] userdiff: add support for Fountain documents

[Zoë Blade]

Hi again Junio!

Yes, your more elegant and accurate regex sounds much better than the way I was 
trying it. :)  Please, go ahead and use yours instead.  Thank you for your help!

Thanks,
Zoë.--
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

Feature Request: Passing a number as an option to git tags for displaying latest tags

[Halil Öztürk]

Hello team,

Passing a number as an option to "git tags" command should display latest tags.

e.g. "git tags -5" will display last 5 tags only.

Similar behavior to "git log -5"

Thanks,
Halil
--
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] refs: loosen restrictions on wildcard '*' refspecs

[David Turner]

On Wed, 2015-07-22 at 09:06 -0700, Jacob Keller wrote:
> From: Jacob Keller 
> 
> Update the check_refname_component logic in order to allow for a less
> strict refspec format in regards to REFNAME_REFSPEC_PATTERN. Previously
> the '*' could only replace a single full component, and could not
> replace arbitrary text. Now, refs such as `foo/bar*:foo/bar*` will be
> accepted. This allows for somewhat more flexibility in references and
> does not break any current users. The ref matching code already allows
> this but the check_refname_format did not. Note this does also allow
> refs such as `foo/bar*:foe/baz*`, that is, arbitrary renames. This was
> already possible with namespace sections before, but now is possible
> even as part of the pattern section. Since users have to explicitly type
> these into the configuration it does not seem an issue.
> 
> Also streamline the code by making this new check part of
> check_refname_component instead of checking after we error during
> check_refname_format, which fits better with how other issues in refname
> components are checked.
> 
> Signed-off-by: Jacob Keller 
> Cc: Daniel Barkalow 
> Cc: Junio C Hamano 
> ---
> 
> I updated the patch description a bit. This is also re-based onto the
> next/ branch in-case. This is mostly a resend so that anyone interested
> in review has another chance to see the patch.
> 
>  Documentation/git-check-ref-format.txt |  4 ++--
>  refs.c | 39 
> +++---
>  refs.h |  4 ++--
>  t/t1402-check-ref-format.sh|  8 ---
>  4 files changed, 31 insertions(+), 24 deletions(-)
> 
> diff --git a/Documentation/git-check-ref-format.txt 
> b/Documentation/git-check-ref-format.txt
> index fc02959ba4ab..9044dfaadae1 100644
> --- a/Documentation/git-check-ref-format.txt
> +++ b/Documentation/git-check-ref-format.txt
> @@ -94,8 +94,8 @@ OPTIONS
>   Interpret  as a reference name pattern for a refspec
>   (as used with remote repositories).  If this option is
>   enabled,  is allowed to contain a single `*`
> - in place of a one full pathname component (e.g.,
> - `foo/*/bar` but not `foo/bar*`).
> + in the refspec (e.g., `foo/bar*/baz` or `foo/bar*baz/`
> + but not `foo/bar*/baz*`).
>  
>  --normalize::
>   Normalize 'refname' by removing any leading slash (`/`)
> diff --git a/refs.c b/refs.c
> index ce8cd8d45001..3002015ff289 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: check for patterns to reject unless REFNAME_REFSPEC_PATTERN is set

How about this:
+ 5: *, reject unless REFNAME_REFSPEC_PATTERN is set

(I guess it's possible that we would later allow other pattern chars,
but we could change the message then).



--
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] refs: loosen restrictions on wildcard '*' refspecs

[Jacob Keller]

On Wed, Jul 22, 2015 at 11:21 AM, David Turner  wrote:
> On Wed, 2015-07-22 at 09:06 -0700, Jacob Keller wrote:
>> From: Jacob Keller 
>>
>> Update the check_refname_component logic in order to allow for a less
>> strict refspec format in regards to REFNAME_REFSPEC_PATTERN. Previously
>> the '*' could only replace a single full component, and could not
>> replace arbitrary text. Now, refs such as `foo/bar*:foo/bar*` will be
>> accepted. This allows for somewhat more flexibility in references and
>> does not break any current users. The ref matching code already allows
>> this but the check_refname_format did not. Note this does also allow
>> refs such as `foo/bar*:foe/baz*`, that is, arbitrary renames. This was
>> already possible with namespace sections before, but now is possible
>> even as part of the pattern section. Since users have to explicitly type
>> these into the configuration it does not seem an issue.
>>
>> Also streamline the code by making this new check part of
>> check_refname_component instead of checking after we error during
>> check_refname_format, which fits better with how other issues in refname
>> components are checked.
>>
>> Signed-off-by: Jacob Keller 
>> Cc: Daniel Barkalow 
>> Cc: Junio C Hamano 
>> ---
>>
>> I updated the patch description a bit. This is also re-based onto the
>> next/ branch in-case. This is mostly a resend so that anyone interested
>> in review has another chance to see the patch.
>>
>>  Documentation/git-check-ref-format.txt |  4 ++--
>>  refs.c | 39 
>> +++---
>>  refs.h |  4 ++--
>>  t/t1402-check-ref-format.sh|  8 ---
>>  4 files changed, 31 insertions(+), 24 deletions(-)
>>
>> diff --git a/Documentation/git-check-ref-format.txt 
>> b/Documentation/git-check-ref-format.txt
>> index fc02959ba4ab..9044dfaadae1 100644
>> --- a/Documentation/git-check-ref-format.txt
>> +++ b/Documentation/git-check-ref-format.txt
>> @@ -94,8 +94,8 @@ OPTIONS
>>   Interpret  as a reference name pattern for a refspec
>>   (as used with remote repositories).  If this option is
>>   enabled,  is allowed to contain a single `*`
>> - in place of a one full pathname component (e.g.,
>> - `foo/*/bar` but not `foo/bar*`).
>> + in the refspec (e.g., `foo/bar*/baz` or `foo/bar*baz/`
>> + but not `foo/bar*/baz*`).
>>
>>  --normalize::
>>   Normalize 'refname' by removing any leading slash (`/`)
>> diff --git a/refs.c b/refs.c
>> index ce8cd8d45001..3002015ff289 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: check for patterns to reject unless REFNAME_REFSPEC_PATTERN is set
>
> How about this:
> + 5: *, reject unless REFNAME_REFSPEC_PATTERN is set
>
> (I guess it's possible that we would later allow other pattern chars,
> but we could change the message then).
>
>
>

Ok that makes sense

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

[PATCH v4] refs: loosen restrictions on wildcard '*' refspecs

[Jacob Keller]

From: Jacob Keller 

Update the check_refname_component logic in order to allow for a less
strict refspec format in regards to REFNAME_REFSPEC_PATTERN. Previously
the '*' could only replace a single full component, and could not
replace arbitrary text. Now, refs such as `foo/bar*:foo/bar*` will be
accepted. This allows for somewhat more flexibility in references and
does not break any current users. The ref matching code already allows
this but the check_refname_format did not. Note this does also allow
refs such as `foo/bar*:foe/baz*`, that is, arbitrary renames. This was
already possible with namespace sections before, but now is possible
even as part of the pattern section. Since users have to explicitly type
these into the configuration it does not seem an issue.

Also streamline the code by making this new check part of
check_refname_component instead of checking after we error during
check_refname_format, which fits better with how other issues in refname
components are checked.

Signed-off-by: Jacob Keller 
Cc: Daniel Barkalow 
Cc: Junio C Hamano 
---

* Changed since v3
- updated the description of 5 in refs.c as suggested by David Turner

 Documentation/git-check-ref-format.txt |  4 ++--
 refs.c | 39 +++---
 refs.h |  4 ++--
 t/t1402-check-ref-format.sh|  8 ---
 4 files changed, 31 insertions(+), 24 deletions(-)

diff --git a/Documentation/git-check-ref-format.txt 
b/Documentation/git-check-ref-format.txt
index fc02959ba4ab..9044dfaadae1 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -94,8 +94,8 @@ OPTIONS
Interpret  as a reference name pattern for a refspec
(as used with remote repositories).  If this option is
enabled,  is allowed to contain a single `*`
-   in place of a one full pathname component (e.g.,
-   `foo/*/bar` but not `foo/bar*`).
+   in the refspec (e.g., `foo/bar*/baz` or `foo/bar*baz/`
+   but not `foo/bar*/baz*`).
 
 --normalize::
Normalize 'refname' by removing any leading slash (`/`)
diff --git a/refs.c b/refs.c
index ce8cd8d45001..a65f16fedaa0 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: *, reject unless REFNAME_REFSPEC_PATTERN is set
  */
 static unsigned char refname_disposition[256] = {
1, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4,
4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4,
-   4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, 2, 1,
+   4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 5, 0, 0, 0, 2, 1,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, 0, 4,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 4, 0, 4, 0,
@@ -71,11 +72,13 @@ static unsigned char refname_disposition[256] = {
  * - any path component of it begins with ".", or
  * - it has double dots "..", or
  * - it has ASCII control character, "~", "^", ":" or SP, anywhere, or
- * - it ends with a "/".
- * - it ends with ".lock"
- * - it contains a "\" (backslash)
+ * - it ends with a "/", or
+ * - it ends with ".lock", or
+ * - it contains a "\" (backslash), or
+ * - it contains a "@{" portion, or
+ * - it contains a '*' unless REFNAME_REFSPEC_PATTERN is set
  */
-static int check_refname_component(const char *refname, int flags)
+static int check_refname_component(const char *refname, int *flags)
 {
const char *cp;
char last = '\0';
@@ -96,6 +99,16 @@ static int check_refname_component(const char *refname, int 
flags)
break;
case 4:
return -1;
+   case 5:
+   if (!(*flags & REFNAME_REFSPEC_PATTERN))
+   return -1; /* refspec can't be a pattern */
+
+   /*
+* Unset the pattern flag so that we only accept a 
single glob for
+* the entire refspec.
+*/
+   *flags &= ~ REFNAME_REFSPEC_PATTERN;
+   break;
}
last = ch;
}
@@ -120,18 +133,10 @@ int check_refname_format(const char *refname, int flags)
 
while (1) {
/* We are at the start of a path component. */
-   component_len = check_refname_component(refname, flags);
-   if (component_len <= 0) {
-   if ((flags & REFNAME_REFSPEC_PATTERN) &&
-   refname[0] == '*' &&
-   (refname[1] == '\0' || refname[1] == 
'/')) {
-   /* Accept one wildcard as a full refname 
component. */
-   flags &= ~REFNAME_REFSPE

Re: Feature Request: Passing a number as an option to git tags for displaying latest tags

[Jacob Keller]

On Wed, Jul 22, 2015 at 10:17 AM, Halil Öztürk  wrote:
> Hello team,
>
> Passing a number as an option to "git tags" command should display latest 
> tags.
>
> e.g. "git tags -5" will display last 5 tags only.
>
> Similar behavior to "git log -5"
>
> Thanks,
> Halil
> --
> 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


While interesting, this would only really work for annotated tags. How
would you define order? tags are normally shown in sorted lexical
order (or version-order if you pass the --sort parameter).
Non-annotated tags do not contain the date time, and using the
commit's date information may not be accurate. While it is possible to
say show "the 5 most recent tags on a particular branch of history"
that would be using the log to determine this.

What exactly would you expect the behavior to be with tags? That might
help figure out what could be done instead.

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 v3 1/9] ref-filter: add option to align atoms to the left

[Matthieu Moy]

Karthik Nayak  writes:

> + strtoul_ui(valp, 10, &ref->align_value);
> + if (ref->align_value < 1)
> + die(_("Value should be greater than zero"));

You're not checking the return value of strtoul_ui, which returns -1
before assigning align_value if the value can't be parsed. As a result,
you're testing an undefined value in the 'if' statement in this case.

You should test the return value and issue a distinct error message in
this case like

if (strtoul_ui(valp, 10, &ref->align_value))
die(_("positive integer expected after ':' in align:%u\n",
ref_align_value));

-- 
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: Feature Request: Passing a number as an option to git tags for displaying latest tags

[Andreas Schwab]

Halil Öztürk  writes:

> Passing a number as an option to "git tags" command should display latest 
> tags.

How do you define "the latest tags"?  By tag creation?  Lightweight
tags don't have any kind of creation time attached.

Andreas.

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

Re: [PATCH 3/3] doc: give examples for send-email cc-cmd operation

[Junio C Hamano]

"Philip Oakley"  writes:

>>   It is an
>> unacceptable hack for us to encourage in the longer term.  It may
>> happen to work with the current implementation, but it does so
>> merely by depending on the implementation too much.
>>
>> If it is so common to want to spray all your patches to exactly the
>> same list of recipients that is unconditionally determined, having
>
> It wasn't 'unconditional spraying' ;-), rather I'd carefully select
> who to send to for each series, ...

I meant unconditional in the sense that all messages in the series
will get exactly the same cc: list (instead of the cc-cmd inspecting
each message and deciding whom to include conditionally).

>> I would think that it would probably be the best way to address "I
>> often want to cc these recipients, but not always" is to keep a list
>> of aliases, each entry of which expands to the recipients, and say
>> "--cc=group" from the command line to have it expanded to the set of
>> recipients.

I think one of the topics that was reviewed and queued during this
cycle will help the above (it may not be in 'master' yet hence not
in 2.5, but there always is the next release), where it made sure
that alias expansion happens more consistently than before.

--
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] pull: allow dirty tree when rebase.autostash enabled

[Kevin Daudt]

On Tue, Jul 07, 2015 at 11:59:56AM +0800, Paul Tan wrote:
> On Mon, Jul 06, 2015 at 01:39:47PM -0700, Junio C Hamano wrote:
> > Kevin Daudt  writes:
> > 
> > > rebase learned to stash changes when it encounters a dirty work tree, but
> > > git pull --rebase does not.
> > >
> > > Only verify if the working tree is dirty when rebase.autostash is not
> > > enabled.
> > >
> > > Signed-off-by: Kevin Daudt 
> > > Helped-by: Paul Tan 
> > > ---
> > 
> > I applied it, tried to run today's integration cycle, and then ended
> > up ejecting it from my tree for now, as this seemed to break 5520
> > when merged to 'pu' X-<.
> > 
> > Well, that is partly expected, as Paul's builtin/pull.c does not
> > know about it (yet).
> 
> Yeah, sorry about that.
> 
> Here's a modified patch for the C code.
> 
> Regards,
> Paul
> 
> --- >8 ---
> From: Kevin Daudt 
> Date: Sat, 4 Jul 2015 23:42:38 +0200
> 
> rebase learned to stash changes when it encounters a dirty work tree,
> but git pull --rebase does not.
> 
> Only verify if the working tree is dirty when rebase.autostash is not
> enabled.
> 
> Signed-off-by: Kevin Daudt 
> Signed-off-by: Paul Tan 
> ---
>  builtin/pull.c  |  6 +-
>  t/t5520-pull.sh | 11 +++
>  2 files changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/builtin/pull.c b/builtin/pull.c
> index 722a83c..b7bc1ff 100644
> --- a/builtin/pull.c
> +++ b/builtin/pull.c
> @@ -823,10 +823,14 @@ int cmd_pull(int argc, const char **argv, const char 
> *prefix)
>   hashclr(orig_head);
>  
>   if (opt_rebase) {
> + int autostash = 0;
> +
>   if (is_null_sha1(orig_head) && !is_cache_unborn())
>   die(_("Updating an unborn branch with changes added to 
> the index."));
>  
> - die_on_unclean_work_tree(prefix);
> + git_config_get_bool("rebase.autostash", &autostash);
> + if (!autostash)
> + die_on_unclean_work_tree(prefix);
>  
>   if (get_rebase_fork_point(rebase_fork_point, repo, *refspecs))
>   hashclr(rebase_fork_point);
> diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
> index f4a7193..a0013ee 100755
> --- a/t/t5520-pull.sh
> +++ b/t/t5520-pull.sh
> @@ -245,6 +245,17 @@ test_expect_success '--rebase fails with multiple 
> branches' '
>   test modified = "$(git show HEAD:file)"
>  '
>  
> +test_expect_success 'pull --rebase succeeds with dirty working directory and 
> rebase.autostash set' '
> + test_config rebase.autostash true &&
> + git reset --hard before-rebase &&
> + echo dirty >new_file &&
> + git add new_file &&
> + git pull --rebase . copy &&
> + test_cmp_rev HEAD^ copy &&
> + test "$(cat new_file)" = dirty &&
> + test "$(cat file)" = "modified again"
> +'
> +
>  test_expect_success 'pull.rebase' '
>   git reset --hard before-rebase &&
>   test_config pull.rebase true &&
> -- 
> 2.5.0.rc1.21.gbd65f2d.dirty
> 

Any news about this? Is it still waiting for something?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Feature Request: Passing a number as an option to git tags for displaying latest tags

[Junio C Hamano]

Halil Öztürk  writes:

> Passing a number as an option to "git tags" command should display latest 
> tags.
>
> e.g. "git tags -5" will display last 5 tags only.

I think this conflates two unrelated things.

 - Ordering tags not by refnames (i.e. default) but by "time".

 - Limiting the output by count.

The latter is what "| head -n 5" and/or "| tail -n 5" are for, so it
would be at most "nice to have"; I am indifferent in the sense that
I won't work on it, but I'd take a look if somebody sent a patch
that was cleanly done.

The former, sort by "time", is interesting, but you need to define
what to do with various corner cases.  For example, some people may
be have one or more of the following desires:

 * My project did not use tags for a long time, and started using it
   recently starting from v1.1.0.  The first release only said
   "Frotz version 1.0.0" in its commit log message.  I retroactively
   did "git tag -s -m 'Frotz 1.1.0' v1.1.0" on that commit.

   In such a case, it is likely that I would want the sorting done
   based on the committer date on the underlying commit, not the
   tag's tagger date.

 * When a bug is found, it is customary in my project to add a
   "break-" tag to the commit that introduces the bug
   (and "fix-" tag to the commit that fixes it).

   When I want to find recently discovered breakages, I want the
   tags whose names match "break-*" sorted by tagger dates, not the
   underlying commit's committer dates.

The necessary ordering machinery to do the above already exists in
"for-each-ref".  There is a GSoC project that works to unify various
features spread across "for-each-ref", "branch -l" and "tag -l" and
make them available to all of the three.


--
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 5/9] ref-filter: add option to match literal pattern

[Matthieu Moy]

Karthik Nayak  writes:

> --- a/ref-filter.c
> +++ b/ref-filter.c
> @@ -943,9 +943,23 @@ static int commit_contains(struct ref_filter *filter, 
> struct commit *commit)
>  
>  /*
>   * Return 1 if the refname matches one of the patterns, otherwise 0.
> + * A pattern can be a literal prefix (e.g. a refname "refs/heads/master"
> + * matches a pattern "refs/heads/m") or a wildcard (e.g. the same ref
> + * matches "refs/heads/m*", too).
> + */
> +static int match_pattern(const char **patterns, const char *refname)
> +{
> + for (; *patterns; patterns++)
> + if (!wildmatch(*patterns, refname, 0, NULL))
> + return 1;
> + return 0;
> +}
> +
> +/*
> + * Return 1 if the refname matches one of the patterns, otherwise 0.
>   * A pattern can be path prefix (e.g. a refname "refs/heads/master"
>   * matches a pattern "refs/heads/") or a wildcard (e.g. the same ref

While you're there, why not say explicitly

   * A pattern can be path prefix (e.g. a refname "refs/heads/master"
   * matches a pattern "refs/heads/" but not "refs/heads/m")
 ^^
   ...

(I find it frustrating when the docstrings for two function look
identical and I have to find out the 1-character difference to
understand ...)

-- 
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: Feature Request: Passing a number as an option to git tags for displaying latest tags

[Junio C Hamano]

Junio C Hamano  writes:

> The former, sort by "time", is interesting, but you need to define
> what to do with various corner cases.  For example, some people may
> have one or more of the following desires:
>
>  * My project did not use tags for a long time, and started using it
>recently starting from v1.1.0.  The first release only said
>"Frotz version 1.0.0" in its commit log message.  I retroactively
>did "git tag -s -m 'Frotz 1.1.0' v1.1.0" on that commit.

Obviously, I meant "git tag -s -m 'Frotz 1.0.0' v1.0.0" here.

>In such a case, it is likely that I would want the sorting done
>based on the committer date on the underlying commit, not the
>tag's tagger date.
>
>  * When a bug is found, it is customary in my project to add a
>"break-" tag to the commit that introduces the bug
>(and "fix-" tag to the commit that fixes it).
>
>When I want to find recently discovered breakages, I want the
>tags whose names match "break-*" sorted by tagger dates, not the
>underlying commit's committer dates.

Another use case may be one in which older tags are interesting.  In
other words, you need to be able to sort in reverse, too.

> The necessary ordering machinery to do the above already exists in
> "for-each-ref".  There is a GSoC project that works to unify various
> features spread across "for-each-ref", "branch -l" and "tag -l" and
> make them available to all of the three.

And the above is still true even with reverse-order use case.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What's cooking in git.git (Jul 2015, #01; Wed, 1)

[Jakub Narębski]

W dniu 2015-07-22 o 15:19, Tony Finch pisze:
> Jakub Narębski  wrote:
>>
>> A question about implementation: why emptying $path_info in
>> evaluate_path_info()?
> 
> That was for consistency with other parts of the subroutine which (mostly)
> remove items from the global $path_info variable when they are added to
> %input_params. But since $path_info isn't used after it has been parsed, I
> suppose it is redundant.

If it is for consistency, better leave it in my opinion.

 - I think that people would want to be able to configure how
   many levels of directory hierarchy gets turned into categories.
   Perhaps only top level should be turned into category? Deep
   hierarchies means deep categories (usually with very few
   repositories) with current implementation.
>>>
>>> Good question. I was assuming flat-ish directory hierarchies, but that's
>>> clearly not very true, e.g. https://git.kernel.org/cgit/
>>>
>>> I think it would be right to make this a %feature since categories already
>>> nearly fit the %feature per-project override style.
>>
>> On the other hand $projects_list_group_categories is a global gitweb
>> configuration variable, and $projects_list_directory_is_category was
>> patterned after it.
> 
> Yes... Which do you prefer? :-)

Hmmm... does it makes sense to have per-repository override?  If yes,
then we need to use %features. If not... I am not sure, %features is
newer than global (or rather package) variables for gitweb configuration,
which must be left for legacy config support (and few are needed before
%features are parsed).

>> A few thoughts about implementation:
> 
> Helpful, thanks!
> 
>> - can we turn category header into link even if the category didn't
>>   came from $projects_list_directory_is_category?
> 
> That would mean changing the project filter to match categories as well as
> paths. I don't know if this is the right thing to do; perhaps it is,
> because the current behaviour of my category headings is a bit surprising.
> 
> At the moment, clicking on the "git" category heading on the page linked
> below takes you to a page that does not list all the repos that were under
> the category heading on the main page.
> 
> https://git.csx.cam.ac.uk/x/ucs/

I thought gitweb had a way to list all projects belonging to given category,
but I see that it doesn't.  So you need to find out if 'category' came from
category or from pathname, to decide whether to link it using 'projects_list'
action and 'project_filter' parameter (or their PATH_INFO version), or not.

This can be done either by checking that category name is directory (though
we could have false positives here), or when adding categories denote where
it came from (e.g. with additional field).  I think the second is better,
if we are to hyperlink category-from-pathname headings.

There is interesting corner case: what if some projects use category, and
some have the same category from pathname?  Clicking on category if 
hyper-linked would show only a subset of projects inside category. (I think
this is the oddity you noticed.)

>> - even if $projects_list_directory_is_category is true, the category
>>   could came from 'category' file, or otherwise manually set category,
>>   though I wonder how we can easily detect this...
> 
> Yes - I use this to list my personal/experimental repos alongside
> the production repos.
> 
> I'm not sure why gitweb would need to detect this or what it would do in
> response. At the moment it "just works", apart from the oddity with
> categories vs project filters i described above.

What if there is synthetic category that has no representative in the
path hierarchy?  Then "project_filter" link would lead to strange empty
list of projects...

For example http://git.zx2c4.com/ (cgit) uses "Mirrors" category...

We could either abuse "project_filter" for categories, or add a new
query parameter "project_category" or "cat" in short. In either case
it would not have PATH_INFO URL unless category came from directory.

Food for thought
-- 
Jakub Narębski



--
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] refs: loosen restrictions on wildcard '*' refspecs

[Junio C Hamano]

Jacob Keller  writes:

> diff --git a/refs.c b/refs.c
> index ce8cd8d45001..a65f16fedaa0 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: *, reject unless REFNAME_REFSPEC_PATTERN is set

The fact that this patch does not have to change the description for
'4:' is an indication that the original description for '4:' was
incomplete.  Otherwise the original would have listed "*" among
others like "~", "^", and this patch would have updated it.

This mixes a fix/cleanup with an enhancement.

>   */
>  static unsigned char refname_disposition[256] = {
>   1, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4,
>   4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4,
> - 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, 2, 1,
> + 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 5, 0, 0, 0, 2, 1,
>   0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, 0, 4,
>   0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
>   0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 4, 0, 4, 0,
> @@ -71,11 +72,13 @@ static unsigned char refname_disposition[256] = {
>   * - any path component of it begins with ".", or
>   * - it has double dots "..", or
>   * - it has ASCII control character, "~", "^", ":" or SP, anywhere, or
> - * - it ends with a "/".
> - * - it ends with ".lock"
> - * - it contains a "\" (backslash)
> + * - it ends with a "/", or
> + * - it ends with ".lock", or
> + * - it contains a "\" (backslash), or
> + * - it contains a "@{" portion, or
> + * - it contains a '*' unless REFNAME_REFSPEC_PATTERN is set
>   */

This also mixes a fix/cleanup with an enhancement.  The original
should have had these ", or" but it didn't.

Can you split this patch into two, i.e.

 * [1/2] is to only clean-up the places these two hunks apply,
   without changing the behaviour at all.

   Please make sure that updated description for "4:" covers
   everything that is "a bad character".  We noticed the lack of '*'
   only because of your patch, but I do not know (and did not check)
   if that was the only thing that was missing.

 * [2/2] is what you really wanted to do with this patch,
   i.e. updating the entry for '*' in the disposition table and all
   changes outside the above two hunks.

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 8/9] tag.c: implement '--format' option

[Matthieu Moy]

Karthik Nayak  writes:

> --- a/Documentation/git-tag.txt
> +++ b/Documentation/git-tag.txt
> @@ -13,7 +13,8 @@ SYNOPSIS
>[ | ]
>  'git tag' -d ...
>  'git tag' [-n[]] -l [--contains ] [--points-at ]
> - [--column[=] | --no-column] [--sort=] [...]
> + [--column[=] | --no-column] [--sort=] [--format=]
> + [...]
>  'git tag' -v ...
>  
>  DESCRIPTION
> @@ -155,6 +156,19 @@ This option is only applicable when listing tags without 
> annotation lines.
>   The object that the new tag will refer to, usually a commit.
>   Defaults to HEAD.
>  
> +::
> + A string that interpolates `%(fieldname)` from the
> + object pointed at by a ref being shown.  If `fieldname`
> + is prefixed with an asterisk (`*`) and the ref points
> + at a tag object, the value for the field in the object
> + tag refers is used.  When unspecified, defaults to
> + `%(objectname) SPC %(objecttype) TAB %(refname)`.

I think this last sentence is taken from for-each-ref where it is true,
but for 'git tag', the default is just %(refname:short), as written
here:

> - else
> + else if (!format)
>   format = "%(refname:short)";

right?

> --- a/t/t7004-tag.sh
> +++ b/t/t7004-tag.sh
> @@ -1507,4 +1507,20 @@ EOF"
>   test_cmp expect actual
>  '
>  
> +test_expect_success '--format cannot be used with -n' '
> + test_must_fail git tag -l -n4 --format="%(refname)"
> +'
> +
> +test_expect_success '--format should list tags as per format given' '
> + cat >expect <<-\EOF &&
> + foo1.10
> + foo1.3
> + foo1.6
> + foo1.6-rc1
> + foo1.6-rc2
> + EOF
> + git tag -l --format="%(refname)" "foo*" >actual &&
> + test_cmp expect actual
> +'

This tests the pattern argument, but the the test still passes if I
remove the --format option, so it does not test what it claims.

Also, why does "git tag"'s %(refname) behave like "git for-each-ref"'s
%(refname:short)? I find it very confusing as I think --format's
argument should be interpreted the same way for all ref-listing
commands. Actually I didn't find a way to have "git tag" display the
full refname other than with --format "refs/tags/%(refname)".

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

Re: [PATCH v3 9/9] tag.c: implement '--merged' and '--no-merged' options

[Matthieu Moy]

Karthik Nayak  writes:

> +--merged []::
> + Only list tags whose tips are reachable from the
> + specified commit (HEAD if not specified).
> +
> +--no-merged []::
> + Only list tags whose tips are not reachable from the
> + specified commit (HEAD if not specified).

You may want to spell it `HEAD` (with backticks).

-- 
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 v5] pull: allow dirty tree when rebase.autostash enabled

[Junio C Hamano]

Kevin Daudt  writes:

> On Tue, Jul 07, 2015 at 11:59:56AM +0800, Paul Tan wrote:
>
> Any news about this? Is it still waiting for something?

Paul's patch was buried in the noise and I didn't notice it.

I'd prefer to see a new feature like this, that did not exist in the
original, be done on top of the "rewrite pull in C" topic, which
will need a bit more time to mature and be merged to 'master'.

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 tag: pre-receive hook issue

[Jakub Narębski]

On 2015-07-19, Jacob Keller wrote:

> git describe will tell you if the commit you're passing it is
> associated with an annotated tag. I do not understand who this
> information can help you implement any policy, so understanding what
> the policy you want is would be the most helpful.

One policy I can think of that may have use of checking if commit
is tagged is requiring some extra restrictions on the commit that
is being tagged, for example that the only file that it can touch
is version.h / VERSION-FILE, and no code changes at all.

-- 
Jakub Narębski
--
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] receive-pack: crash when checking with non-exist HEAD

[Junio C Hamano]

Jiang Xin  writes:

> If HEAD of a repository points to a conflict reference, such as:
>
> * There exist a reference named 'refs/heads/jx/feature1', but HEAD
>   points to 'refs/heads/jx', or
>
> * There exist a reference named 'refs/heads/feature', but HEAD points
>   to 'refs/heads/feature/bad'.
>
> When we push to delete a reference for this repo, such as:
>
> git push /path/to/bad-head-repo.git :some/good/reference
>
> The git-receive-pack process will crash.

I see a similar "if head_name is NULL, don't bother." check in
is_ref_checked_out() so in that sense this is a correct fix to the
immediate problem.  That check came from 986e8239 (receive-pack:
detect push to current branch of non-bare repo, 2008-11-08).

This is a tangent, but if HEAD points at an unborn branch that
cannot be created, wouldn't all other things break?  

For example, in order to "git commit" from such a state to create
the root commit on that branch, existing unrelated branches whose
names collide with the branch must be removed, which would mean one
of two things, either (1) you end up losing many unrelated work, or
(2) the command refuses to work, not letting you to record the
commit.  Neither is satisfactory, but we seem to choose (2), which
is at least the safer of the two:

$ git checkout master
$ git checkout --orphan master/1
$ git commit -m foo
fatal: cannot lock ref 'HEAD': 'refs/heads/master' exists;
cannot create 'refs/heads/master/1'

We may want to avoid putting us in such a situation in the first
place.  Giving "checkout --orphan" an extra check might be a simple
small thing we can do, i.e.

$ git checkout master
$ git checkout --orphan master/1
fatal: 'master' branch exists, cannot create 'master/1'

But I suspect it would not protect us from different avenues that
can cause this kind of thing; e.g. to prevent this:

$ git branch -D next
$ git checkout --orphan next/1
$ git fetch origin master:refs/heads/next

creation of a ref "refs/heads/next" here must notice HEAD points
at "refs/heads/next/1" (that does not yet exist) and do something
intelligent about it.

>  builtin/receive-pack.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
> index 94d0571..04cb5a1 100644
> --- a/builtin/receive-pack.c
> +++ b/builtin/receive-pack.c
> @@ -911,7 +911,7 @@ static const char *update(struct command *cmd,
> struct shallow_info *si)
>   return "deletion prohibited";
> }
>
> -   if (!strcmp(namespaced_name, head_name)) {
> +   if (head_name && !strcmp(namespaced_name, head_name)) {
>   switch (deny_delete_current) {
>   case DENY_IGNORE:
> break;
--
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] diff-tree: do not show the sha1 of the given head with --quiet

[Junio C Hamano]

Sebastian Schuberth  writes:

> "--quite" is documented to "Disable all output of the program". Yet
> calling diff-tree with a single commit like
>
> $ git diff-tree --quiet c925fe2
>
> was logging
>
> c925fe23684455735c3bb1903803643a24a58d8f

At this point, unfortunately I think we need to call that a
documentation bug.  The "output" it refers to is output from the
"diff" portion, not the "poor-man's log" portion, of the program,
where diff-tree was the workhorse behind scripted "git log" that
gave the commit object name as the preamble for each commit it
shows information about.
--
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] pull: allow dirty tree when rebase.autostash enabled

[Kevin Daudt]

On Wed, Jul 22, 2015 at 12:42:17PM -0700, Junio C Hamano wrote:
> Kevin Daudt  writes:
> 
> > On Tue, Jul 07, 2015 at 11:59:56AM +0800, Paul Tan wrote:
> >
> > Any news about this? Is it still waiting for something?
> 
> Paul's patch was buried in the noise and I didn't notice it.
> 
> I'd prefer to see a new feature like this, that did not exist in the
> original, be done on top of the "rewrite pull in C" topic, which
> will need a bit more time to mature and be merged to 'master'.
> 
> Thanks.

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

[PATCH 2/2] refs: loosen restriction on wildcard "*" refspecs

[Jacob Keller]

From: Jacob Keller 

Modify logic of check_refname_component and add a new disposition
regarding "*". Allow refspecs that contain a single "*" if
REFNAME_REFSPEC_PATTERN is set. Change the function to pass the flags as
a pointer, and clear REFNAME_REFSPEC_PATTERN after the first "*" so that
only a single "*" is accepted.

This loosens restrictions on refspecs by allowing patterns that have
a "*" within a component instead of only as the whole component. Also
remove the code that hangled refspec patterns in check_refname_format
since it is now handled via the check_refname_component logic.

Now refs such as `for/bar*:foo/bar*` and even `foo/bar*:foo/baz*` will
be accepted. This allows users more control over what is fetched where.
Since users must modify the default by hand to make use of this
functionality it is not considered a large risk. Any refspec which
functioned before shall continue functioning with the new logic.

Signed-off-by: Jacob Keller 
Cc: Daniel Barkalow 
Cc: Junio C Hamano 
---
 Documentation/git-check-ref-format.txt |  4 ++--
 refs.c | 36 +++---
 refs.h |  4 ++--
 t/t1402-check-ref-format.sh|  8 +---
 4 files changed, 29 insertions(+), 23 deletions(-)

diff --git a/Documentation/git-check-ref-format.txt 
b/Documentation/git-check-ref-format.txt
index fc02959ba4ab..9044dfaadae1 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -94,8 +94,8 @@ OPTIONS
Interpret  as a reference name pattern for a refspec
(as used with remote repositories).  If this option is
enabled,  is allowed to contain a single `*`
-   in place of a one full pathname component (e.g.,
-   `foo/*/bar` but not `foo/bar*`).
+   in the refspec (e.g., `foo/bar*/baz` or `foo/bar*baz/`
+   but not `foo/bar*/baz*`).
 
 --normalize::
Normalize 'refname' by removing any leading slash (`/`)
diff --git a/refs.c b/refs.c
index 8c08fc0489eb..16a1d8305579 100644
--- a/refs.c
+++ b/refs.c
@@ -20,12 +20,13 @@ 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, and
- *"*", ":", "?", "[", "\", "^", "~", SP, or TAB
+ *":", "?", "[", "\", "^", "~", SP, or TAB
+ * 5: *, reject unless REFNAME_REFSPEC_PATTERN is set
  */
 static unsigned char refname_disposition[256] = {
1, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4,
4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4,
-   4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, 2, 1,
+   4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 5, 0, 0, 0, 2, 1,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, 0, 4,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 4, 0, 4, 0,
@@ -72,12 +73,13 @@ static unsigned char refname_disposition[256] = {
  * - any path component of it begins with ".", or
  * - it has double dots "..", or
  * - it has ASCII control characters, or
- * - it has "*", ":", "?", "[", "\", "^", "~", SP, or TAB anywhere, or
+ * - it has ":", "?", "[", "\", "^", "~", SP, or TAB anywhere, or
+ * - it has "*" anywhere unless REFNAME_REFSPEC_PATTERN is set, or
  * - it ends with a "/", or
  * - it ends with ".lock", or
  * - it contains a "@{" portion
  */
-static int check_refname_component(const char *refname, int flags)
+static int check_refname_component(const char *refname, int *flags)
 {
const char *cp;
char last = '\0';
@@ -98,6 +100,16 @@ static int check_refname_component(const char *refname, int 
flags)
break;
case 4:
return -1;
+   case 5:
+   if (!(*flags & REFNAME_REFSPEC_PATTERN))
+   return -1; /* refspec can't be a pattern */
+
+   /*
+* Unset the pattern flag so that we only accept a 
single glob for
+* the entire refspec.
+*/
+   *flags &= ~ REFNAME_REFSPEC_PATTERN;
+   break;
}
last = ch;
}
@@ -122,18 +134,10 @@ int check_refname_format(const char *refname, int flags)
 
while (1) {
/* We are at the start of a path component. */
-   component_len = check_refname_component(refname, flags);
-   if (component_len <= 0) {
-   if ((flags & REFNAME_REFSPEC_PATTERN) &&
-   refname[0] == '*' &&
-   (refname[1] == '\0' || refname[1] == 
'/')) {
-   /* Accept one wildcard as a full refname 
component. */
-   flags &= ~REFNAME_REFSPEC_PATTERN;
-   component_len = 1;
-   

[PATCH 1/2] refs: cleanup comments regarding check_refname_component

[Jacob Keller]

From: Jacob Keller 

Correctly specify all characters which are rejected under the '4'
disposition, including '*' even though it does gain special treatment by
callers of check_refname_component.

Cleanup comment style for rejected refs by inserting a ", or" at the end
of each statement.

Signed-off-by: Jacob Keller 
Cc: Daniel Barkalow 
Cc: Junio C Hamano 
---
 refs.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/refs.c b/refs.c
index ce8cd8d45001..8c08fc0489eb 100644
--- a/refs.c
+++ b/refs.c
@@ -19,7 +19,8 @@ struct ref_lock {
  * 1: End-of-component
  * 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
+ * 4: A bad character: ASCII control characters, and
+ *"*", ":", "?", "[", "\", "^", "~", SP, or TAB
  */
 static unsigned char refname_disposition[256] = {
1, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4,
@@ -70,10 +71,11 @@ static unsigned char refname_disposition[256] = {
  *
  * - any path component of it begins with ".", or
  * - it has double dots "..", or
- * - it has ASCII control character, "~", "^", ":" or SP, anywhere, or
- * - it ends with a "/".
- * - it ends with ".lock"
- * - it contains a "\" (backslash)
+ * - it has ASCII control characters, or
+ * - it has "*", ":", "?", "[", "\", "^", "~", SP, or TAB anywhere, or
+ * - it ends with a "/", or
+ * - it ends with ".lock", or
+ * - it contains a "@{" portion
  */
 static int check_refname_component(const char *refname, int flags)
 {
-- 
2.4.3

--
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 v5 0/2] refs: cleanup and new behavior

[Jacob Keller]

From: Jacob Keller 

As per Junio's suggestion, break cleanup/fix and new functionality into
separate patches. Also update description of the new functionality.

The first patch is entirely cleanup of comments with no functionality
change at all (indeed only changes to comment text!). It now correctly
highlights all characters which are disallowed. Discovered by creating a
test function that printed out the whole list.

The second patch introduces the new functionality for "*" and details
how it is now checked per-component. It also explains how the flags are
now passed as a pointer so that we can reject any multi-"*" reference,
by clearing the REFNAME_REFSPEC_PATTERN bit.

Change since v4
- split the cleanup to a separate patch and included all missing values
  from the disposition "4" on the comments.

Jacob Keller (2):
  refs: cleanup comments regarding check_refname_component
  refs: loosen restriction on wildcard "*" refspecs

 Documentation/git-check-ref-format.txt |  4 ++--
 refs.c | 44 +++---
 refs.h |  4 ++--
 t/t1402-check-ref-format.sh|  8 ---
 4 files changed, 34 insertions(+), 26 deletions(-)

-- 
2.4.3

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

Re: What's cooking in git.git (Jul 2015, #01; Wed, 1)

[Tony Finch]

Jakub Narębski  wrote:
>
> Food for thought

Yes, very helpful, thanks. I got mobbed by other things today so I won't
be able to get back to this until next week.

Tony (off for a few days holiday).
-- 
f.anthony.n.finchhttp://dotat.at/
Lundy, Fastnet, Irish Sea, Shannon: West or southwest, veering north later in
Shannon and Fastnet, 4 or 5. Slight or moderate, occasionally rough at first
in north Shannon. Rain or showers. Good, occasionally poor.

Re: [PATCH 2/2] refs: loosen restriction on wildcard "*" refspecs

[Junio C Hamano]

Jacob Keller  writes:

> From: Jacob Keller 
>
> Modify logic of check_refname_component and add a new disposition
> regarding "*". Allow refspecs that contain a single "*" if
> REFNAME_REFSPEC_PATTERN is set. Change the function to pass the flags as
> a pointer, and clear REFNAME_REFSPEC_PATTERN after the first "*" so that
> only a single "*" is accepted.
>
> This loosens restrictions on refspecs by allowing patterns that have
> a "*" within a component instead of only as the whole component. Also
> remove the code that hangled refspec patterns in check_refname_format
> since it is now handled via the check_refname_component logic.
>
> Now refs such as `for/bar*:foo/bar*` and even `foo/bar*:foo/baz*` will
> be accepted. This allows users more control over what is fetched where.
> Since users must modify the default by hand to make use of this
> functionality it is not considered a large risk. Any refspec which
> functioned before shall continue functioning with the new logic.


Thanks.  Now I can read the changes to the code in these two commits
and see that they both make sense ;-)

The above description seem to use "ref" and "refspec" rather
liberally, so I'll rewrite some parts of it to clarify while
queuing.

By the way, have you run test suite before sending this (or any
previous round of this) patch?  This seems to break t5511-refspec.sh
for me.

 

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

Re: [PATCH v2b 00/16, 2 updates] Make the msvc-build scripts work again

[Ramsay Jones]

On 21/07/15 20:25, Junio C Hamano wrote:
> "Philip Oakley"  writes:
> 
>> ... Ideally, if part of this
>> mainstream Git, it would get picked up automatically by them
>> (rather than being local 'fixes' endlessly carried forward).
> 
> Actually, that is not "ideal", but what I want to avoid.
> 
> As I do not do Windows, it simply is wrong for me to apply changes
> that are very likely to affect Windows folks without seeing their
> support first, which they may end up having to revert on their end
> and endlessly carry that revert forward.  That is why I very much
> prefer to see changes get there first and then forwarded in my
> direction once they are happy with them.
> 
>> There has been no activity here on the 'create a visual studio project'
>> aspects in the last few years. Any changes listed in the logs relate to
>> ensuring that the MSVC compiler will run as part of a regular Makefile
>> run (IIUC). The last significant commit was 74cf9bd (engine.pl: Fix a
>> recent breakage of the buildsystem generator, 2010-01-22) Ramsay Jones,
>> so that's five and a half years.
> 
> I think Ramsay is still around on the list; I do not know if he
> still does Windows, though.

[Sorry for not noticing this sooner, but I'm currently moving home
(among other things) and, as a result, I have not been able to
devote much time to the list ... (or anything else ;-) ]

I don't do much with MinGW or MSVC these days (I do still try to
keep cygwin running - it's currently not in good shape). My MSVC
installation is somewhat old (2008 I believe) and confined to my
old 32-bit laptop (which doesn't get booted up too often now).

I had a quick squint at the patches and, at first glance, they
looked quite reasonable to me, but I have not tested them. I can't
promise to test them anytime soon (and my MSVC may be too old for
these patches?). Sorry! :(

[If I find some time soon, I will give them a try and let you know.]

ATB,
Ramsay Jones


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

Re: [PATCH 2/2] refs: loosen restriction on wildcard "*" refspecs

[Jacob Keller]

On Wed, Jul 22, 2015 at 3:04 PM, Junio C Hamano  wrote:
> Jacob Keller  writes:
>
>> From: Jacob Keller 
>>
>> Modify logic of check_refname_component and add a new disposition
>> regarding "*". Allow refspecs that contain a single "*" if
>> REFNAME_REFSPEC_PATTERN is set. Change the function to pass the flags as
>> a pointer, and clear REFNAME_REFSPEC_PATTERN after the first "*" so that
>> only a single "*" is accepted.
>>
>> This loosens restrictions on refspecs by allowing patterns that have
>> a "*" within a component instead of only as the whole component. Also
>> remove the code that hangled refspec patterns in check_refname_format
>> since it is now handled via the check_refname_component logic.
>>
>> Now refs such as `for/bar*:foo/bar*` and even `foo/bar*:foo/baz*` will
>> be accepted. This allows users more control over what is fetched where.
>> Since users must modify the default by hand to make use of this
>> functionality it is not considered a large risk. Any refspec which
>> functioned before shall continue functioning with the new logic.
>
>
> Thanks.  Now I can read the changes to the code in these two commits
> and see that they both make sense ;-)
>
> The above description seem to use "ref" and "refspec" rather
> liberally, so I'll rewrite some parts of it to clarify while
> queuing.
>
> By the way, have you run test suite before sending this (or any
> previous round of this) patch?  This seems to break t5511-refspec.sh
> for me.
>
>
>

Looks like another location I forgot to update. I can send a re-spin
if you need with the following diff. Basically looks like the tests
just didn't get updated to count the new behavior is valid.

diff --git i/t/t5511-refspec.sh w/t/t5511-refspec.sh
index de6db86ccff0..7bfca7962d41 100755
--- i/t/t5511-refspec.sh
+++ w/t/t5511-refspec.sh
@@ -71,11 +71,11 @@ test_refspec fetch ':refs/remotes/frotz/HEAD-to-me'
 test_refspec push ':refs/remotes/frotz/delete me'  invalid
 test_refspec fetch ':refs/remotes/frotz/HEAD to me'invalid

-test_refspec fetch 'refs/heads/*/for-linus:refs/remotes/mine/*-blah' invalid
-test_refspec push 'refs/heads/*/for-linus:refs/remotes/mine/*-blah' invalid
+test_refspec fetch 'refs/heads/*/for-linus:refs/remotes/mine/*-blah'
+test_refspec push 'refs/heads/*/for-linus:refs/remotes/mine/*-blah'

-test_refspec fetch 'refs/heads*/for-linus:refs/remotes/mine/*' invalid
-test_refspec push 'refs/heads*/for-linus:refs/remotes/mine/*' invalid
+test_refspec fetch 'refs/heads*/for-linus:refs/remotes/mine/*'
+test_refspec push 'refs/heads*/for-linus:refs/remotes/mine/*'

 test_refspec fetch 'refs/heads/*/*/for-linus:refs/remotes/mine/*' invalid
 test_refspec push 'refs/heads/*/*/for-linus:refs/remotes/mine/*' invalid




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

[RFC/PATCH] log: add log.firstparent option

[Jeff King]

This patch adds an option to turn on --first-parent all the
time, along with the corresponding --no-first-parent to
disable it. The "why" of this requires a bit of backstory.

Some projects (like git.git) encourage frequent rebasing to
generate a set of clean, bisectable patches for each topic.
The messy sequence of bug-ridden and bug-fixup commits is
lost in the rebase, and not part of the final history.

But other projects prefer to keep the messy history intact.
For one thing, it makes collaboration on a topic easier, as
developers can simply pull from each other during the messy
development. And two, that history may later be useful when
tracking down a bug, because it gives more insight into the
actual thought process of the developer.

But in this latter case you want _two_ views of history. You
may want to see the "simple" version in which a series of
fully-formed topics hit the branch (and you would like to
see the diff of their final form). Or you may want to see
the messy details, because you are digging into a bug
related to the topic.

One proposal we have seen in the past is to keep the messy
history as a "shadow" parent of the real commits. That is,
to introduce a new parent-like header into the commit
object, but not traverse it by default in "git log". So it
remains hidden until you ask to dig into a particular topic
(presumably with a "log --show-messy-parents" option or
similar). So by default you get the simple view, but can dig
further if you wish.

But we can observe that such shadow parents can be
implemented as real parents; the problem isn't one of the
underlying data structure, but how we present it in "git
log". In other words, a perfectly reasonable workflow is:

  - make your messy commits on a side branch

  - do a non-fast-forward merge to bring them into master.
The commit message for this merge should be meaningful
and describe the topic as a whole.

  - view the simple history with "git log --first-parent -m"

  - view the complex history with "git log"

But since you probably want to view the simple history most
of the time, it would be nice to be able to default to that,
and switch to the more complicated view with a command line
option. Hence this patch.

Suggested-by: Josh Bleecher Snyder 
---
This came out of a discussion I had with Josh as OSCON. I
don't think I would personally use it, because git.git is
not a messy-workflow project. But I think that GitHub pushes
people into this sort of workflow (the PR becomes the
interesting unit of change), and my understanding is that
Gerrit does, as well.

There are probably some other things we (and others) could
do to help support it:

  - currently "--first-parent -p" needs "-m" to show
anything useful; this is being discussed elsewhere, and
it would be nice if it Just Worked (and showed the diff
between the merge and the first-parent)

  - the commit messages for merges are often not great. A
few versions ago, I think, we started opening the editor
for merges, which is good. GitHub's PR-merge includes
the PR subject in the commit message, but not all of the
rationale and discussion. And in both git-generated and
GitHub-generated messages, the subject isn't amazing
(it's "merge topic jk/some-shorthand", which is barely
tolerable if you use good branch names; it could be
something like the subject-line of the cover letter for
the patch series).

So I think this could easily be improved by GitHub (we
have the PR subject and body, after all). It's harder
for a mailing list project like git.git, because Git
never actually sees the subject line. I think it would
require teaching git-am the concept of a patch series.

I don't know offhand what Gerrit merges look like.

  - we already have merge.ff to default to making extra
merge commits. And if you use GitHub's UI to do the
merge, it uses --no-ff. I don't think we would want
these to become the default, so there's probably nothing
else to be done there.

Signed-off-by: Jeff King 
---
 Documentation/config.txt |  4 
 builtin/log.c|  6 ++
 revision.c   |  2 ++
 t/t4202-log.sh   | 30 ++
 4 files changed, 42 insertions(+)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 3e37b93..e9c3763 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1802,6 +1802,10 @@ log.mailmap::
If true, makes linkgit:git-log[1], linkgit:git-show[1], and
linkgit:git-whatchanged[1] assume `--use-mailmap`.
 
+log.firstparent::
+   If true, linkgit:git-log[1] will default to `--first-parent`;
+   can be overridden by supplying `--no-first-parent`.
+
 mailinfo.scissors::
If true, makes linkgit:git-mailinfo[1] (and therefore
linkgit:git-am[1]) act by default as if the --scissors option
diff --git a/builtin/log.c b/builtin/log.c
index 8781049..3e9b034 100644
--- a/builti

Config variables and scripting // was Re: [RFC/PATCH] log: add log.firstparent option

[David Aguilar]

On Wed, Jul 22, 2015 at 06:23:44PM -0700, Jeff King wrote:
> This patch adds an option to turn on --first-parent all the
> time, along with the corresponding --no-first-parent to
> disable it.

[Putting on my scripter hat]

I sometimes think, "it would be really helpful if we had a way
to tell Git that it should ignore config variables".

This is especially helpful for script writers.   It's pretty
easy to break existing scripts by introducing new config knobs.

For example, "user.name" and "user.email" can be whitelisted by
the calling script and and everything else would just use the
stock defaults.

That way, script writers don't have to do version checks to
figuring out when and when not to include flags like
--no-first-parent, etc.

Would something like,

GIT_CONFIG_WHITELIST="user.email user.name" \
git ...

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

Re: Config variables and scripting // was Re: [RFC/PATCH] log: add log.firstparent option

[Jeff King]

On Wed, Jul 22, 2015 at 09:40:10PM -0700, David Aguilar wrote:

> On Wed, Jul 22, 2015 at 06:23:44PM -0700, Jeff King wrote:
> > This patch adds an option to turn on --first-parent all the
> > time, along with the corresponding --no-first-parent to
> > disable it.
> 
> [Putting on my scripter hat]
> 
> I sometimes think, "it would be really helpful if we had a way
> to tell Git that it should ignore config variables".
> 
> This is especially helpful for script writers.   It's pretty
> easy to break existing scripts by introducing new config knobs.

I think the purpose of --no-first-parent here is slightly orthogonal. It
is meant to help the user during the odd time that they need to
countermand their config.

Script writers should not care here, because they should not be parsing
the output of the porcelain "log" command in the first place. It already
has many gotchas (e.g., log.date, log.abbrevCommit).

I am sympathetic, though. There are some things that git-log can do that
rev-list cannot, so people end up using it in scripts. I think you can
avoid it with a "rev-list | diff-tree" pipeline, though I'm not 100%
sure if that covers all cases. But I would much rather see a solution
along the lines of making the plumbing cover more cases, rather than
trying to make the porcelain behave in a script.

> That way, script writers don't have to do version checks to
> figuring out when and when not to include flags like
> --no-first-parent, etc.

One trick you can do is:

  git -c log.firstparent=false log ...

Older versions of git will ignore the unknown config option, and newer
ones will override anything the user has in their config file.

> Would something like,
> 
>   GIT_CONFIG_WHITELIST="user.email user.name" \
>   git ...
> 
> be a sensible interface to such a feature?

I dunno.  That's at least easy to implement. But the existing suggested
interface is really "run the plumbing", and then it automatically has a
sensible set of config options for each command, so that scripts don't
have to make their own whitelist (e.g., diff-tree still loads userdiff
config, but not anything that would change the output drastically, like
diff.mnemonicprefix).

-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: Config variables and scripting // was Re: [RFC/PATCH] log: add log.firstparent option

[Jeff King]

On Wed, Jul 22, 2015 at 10:14:45PM -0700, Jeff King wrote:

> Script writers should not care here, because they should not be parsing
> the output of the porcelain "log" command in the first place. It already
> has many gotchas (e.g., log.date, log.abbrevCommit).
> 
> I am sympathetic, though. There are some things that git-log can do that
> rev-list cannot, so people end up using it in scripts. I think you can
> avoid it with a "rev-list | diff-tree" pipeline, though I'm not 100%
> sure if that covers all cases. But I would much rather see a solution
> along the lines of making the plumbing cover more cases, rather than
> trying to make the porcelain behave in a script.

Ah, I see in a nearby thread that you just recently fixed a problem with
git-subtree and log.date, so I see now why you are so interested. :)

And I was also reminded by that usage of why rev-list is annoying in
scripts: even with "--format", it insists on writing the "commit ..."
header. I wonder if we could fix that...

-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] receive-pack: crash when checking with non-exist HEAD

[Jeff King]

On Wed, Jul 22, 2015 at 01:30:00PM -0700, Junio C Hamano wrote:

> I see a similar "if head_name is NULL, don't bother." check in
> is_ref_checked_out() so in that sense this is a correct fix to the
> immediate problem.  That check came from 986e8239 (receive-pack:
> detect push to current branch of non-bare repo, 2008-11-08).

Yeah, I think this patch makes sense for the same reason as the check in
986e8239: if our HEAD ref does not point to a branch, we cannot possibly
be trying to delete it.

I do think the check is a little racy, though I'm not sure it is easy to
fix. E.g., imagine one client pushes to create refs/heads/master just as
somebody else is trying to delete it. I don't think this is much
different than the case where somebody redirects HEAD to
refs/heads/master as we are trying to delete it, though. The checks are
inherently racy because they are not done under locks (you would need to
lock both HEAD and refs/heads/master in that case). It's probably not a
big deal in practice.

> This is a tangent, but if HEAD points at an unborn branch that
> cannot be created, wouldn't all other things break?  
> 
> For example, in order to "git commit" from such a state to create
> the root commit on that branch, existing unrelated branches whose
> names collide with the branch must be removed, which would mean one
> of two things, either (1) you end up losing many unrelated work, or
> (2) the command refuses to work, not letting you to record the
> commit.  Neither is satisfactory, but we seem to choose (2), which
> is at least the safer of the two:
> 
> $ git checkout master
> $ git checkout --orphan master/1
> $ git commit -m foo
> fatal: cannot lock ref 'HEAD': 'refs/heads/master' exists;
> cannot create 'refs/heads/master/1'

Yeah, that seems sensible. I think the "way out" for the user here would
presumably be:

  git symbolic-ref HEAD refs/heads/something-else

though of course they could also rename the other ref.

> We may want to avoid putting us in such a situation in the first
> place.  Giving "checkout --orphan" an extra check might be a simple
> small thing we can do, i.e.
> 
> $ git checkout master
> $ git checkout --orphan master/1
> fatal: 'master' branch exists, cannot create 'master/1'
> 
> But I suspect it would not protect us from different avenues that
> can cause this kind of thing; e.g. to prevent this:
> 
> $ git branch -D next
> $ git checkout --orphan next/1
> $ git fetch origin master:refs/heads/next
> 
> creation of a ref "refs/heads/next" here must notice HEAD points
> at "refs/heads/next/1" (that does not yet exist) and do something
> intelligent about it.

Right. You'd have to teach the is_refname_available() check to always
check what HEAD points to, and consider it as "taken", even if the ref
itself doesn't exist. But what about other symbolic refs? The
"refs/remotes/origin/HEAD" symref may point to
"refs/remotes/origin/master" even though "refs/remotes/origin/master/1"
exists. I doubt that will cause real problems in practice, but it points
out that special cases like "the value of HEAD is magic and reserved"
will later end up being insufficient as the code is extended.

I think I'd be willing to simply punt on the whole thing as being too
rare to come up in practice.

-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: Config variables and scripting // was Re: [RFC/PATCH] log: add log.firstparent option

[Jacob Keller]

On Wed, Jul 22, 2015 at 10:48 PM, Jeff King  wrote:
> On Wed, Jul 22, 2015 at 10:14:45PM -0700, Jeff King wrote:
>
>> Script writers should not care here, because they should not be parsing
>> the output of the porcelain "log" command in the first place. It already
>> has many gotchas (e.g., log.date, log.abbrevCommit).
>>
>> I am sympathetic, though. There are some things that git-log can do that
>> rev-list cannot, so people end up using it in scripts. I think you can
>> avoid it with a "rev-list | diff-tree" pipeline, though I'm not 100%
>> sure if that covers all cases. But I would much rather see a solution
>> along the lines of making the plumbing cover more cases, rather than
>> trying to make the porcelain behave in a script.
>
> Ah, I see in a nearby thread that you just recently fixed a problem with
> git-subtree and log.date, so I see now why you are so interested. :)
>
> And I was also reminded by that usage of why rev-list is annoying in
> scripts: even with "--format", it insists on writing the "commit ..."
> header. I wonder if we could fix that...
>
> -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

Agreed. Fix the plumbing instead and document how/why to use it
instead of the porcelain. We might do better to help clearly document
which commands are porcelain and which are plumbing maybe by
referencing which plumbings to use in place of various porcelain
commands. I know, for example, that git status already does this.

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: Config variables and scripting // was Re: [RFC/PATCH] log: add log.firstparent option

[Jeff King]

On Wed, Jul 22, 2015 at 11:32:49PM -0700, Jacob Keller wrote:

> Agreed. Fix the plumbing instead and document how/why to use it
> instead of the porcelain. We might do better to help clearly document
> which commands are porcelain and which are plumbing maybe by
> referencing which plumbings to use in place of various porcelain
> commands. I know, for example, that git status already does this.

"man git" already has such a list (which is generated from the
annotations in command-list.txt). But I agree that it would probably be
helpful to point people directly from "git log" to "git rev-list" and
vice versa.

-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: Config variables and scripting // was Re: [RFC/PATCH] log: add log.firstparent option

[Jacob Keller]

On Wed, Jul 22, 2015 at 11:53 PM, Jeff King  wrote:
> "man git" already has such a list (which is generated from the
> annotations in command-list.txt). But I agree that it would probably be
> helpful to point people directly from "git log" to "git rev-list" and
> vice versa.
>
> -Peff

That's good. I just know that I've had many a co-worker complain
because the man page felt too technical because they accidentally
found their way into a plumbing section. If I heard a specific case of
confusion again in the future I'll try to work up a patch for it.

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