[PATCH v3] refs: loosen restrictions on wildcard '*' refspecs
From: Jacob Keller jacob.kel...@gmail.com
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 jacob.kel...@gmail.com
Cc: Daniel Barkalow barka...@iabervon.iabervon.org
Cc: Junio C Hamano gits...@pobox.com
---
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 refname as a reference name pattern for a refspec
(as used with remote repositories). If this option is
enabled, refname is allowed to contain a single `*`
- in place of a one full pathname component (e.g.,
- `foo/*/bar` but not `foo/bar*`).
+ 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] == '*'
-
Re: [PATCH] userdiff: add support for Fountain documents
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
Re: [PATCH v3] refs: loosen restrictions on wildcard '*' refspecs
On Wed, 2015-07-22 at 09:06 -0700, Jacob Keller wrote:
From: Jacob Keller jacob.kel...@gmail.com
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 jacob.kel...@gmail.com
Cc: Daniel Barkalow barka...@iabervon.iabervon.org
Cc: Junio C Hamano gits...@pobox.com
---
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 refname as a reference name pattern for a refspec
(as used with remote repositories). If this option is
enabled, refname is allowed to contain a single `*`
- in place of a one full pathname component (e.g.,
- `foo/*/bar` but not `foo/bar*`).
+ 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
On Wed, Jul 22, 2015 at 11:21 AM, David Turner dtur...@twopensource.com wrote:
On Wed, 2015-07-22 at 09:06 -0700, Jacob Keller wrote:
From: Jacob Keller jacob.kel...@gmail.com
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 jacob.kel...@gmail.com
Cc: Daniel Barkalow barka...@iabervon.iabervon.org
Cc: Junio C Hamano gits...@pobox.com
---
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 refname as a reference name pattern for a refspec
(as used with remote repositories). If this option is
enabled, refname is allowed to contain a single `*`
- in place of a one full pathname component (e.g.,
- `foo/*/bar` but not `foo/bar*`).
+ 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
From: Jacob Keller jacob.kel...@gmail.com
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 jacob.kel...@gmail.com
Cc: Daniel Barkalow barka...@iabervon.iabervon.org
Cc: Junio C Hamano gits...@pobox.com
---
* 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 refname as a reference name pattern for a refspec
(as used with remote repositories). If this option is
enabled, refname is allowed to contain a single `*`
- in place of a one full pathname component (e.g.,
- `foo/*/bar` but not `foo/bar*`).
+ 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
Re: What's cooking in git.git (Jul 2015, #01; Wed, 1)
W dniu 2015-07-22 o 15:19, Tony Finch pisze: Jakub Narębski jna...@gmail.com 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 v5] pull: allow dirty tree when rebase.autostash enabled
Kevin Daudt m...@ikke.info 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: Feature Request: Passing a number as an option to git tags for displaying latest tags
On Wed, Jul 22, 2015 at 10:17 AM, Halil Öztürk haliloztur...@gmail.com 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] receive-pack: crash when checking with non-exist HEAD
Jiang Xin worldhello@gmail.com 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: Feature Request: Passing a number as an option to git tags for displaying latest tags
Junio C Hamano gits...@pobox.com 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-something tag to the commit that introduces the bug (and fix-something 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: [PATCH v3 9/9] tag.c: implement '--merged' and '--no-merged' options
Karthik Nayak karthik@gmail.com writes: +--merged [commit]:: + Only list tags whose tips are reachable from the + specified commit (HEAD if not specified). + +--no-merged [commit]:: + 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 v3 1/9] ref-filter: add option to align atoms to the left
Karthik Nayak karthik@gmail.com 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: [PATCH v3 5/9] ref-filter: add option to match literal pattern
Karthik Nayak karthik@gmail.com 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: [PATCH v3 8/9] tag.c: implement '--format' option
Karthik Nayak karthik@gmail.com writes: --- a/Documentation/git-tag.txt +++ b/Documentation/git-tag.txt @@ -13,7 +13,8 @@ SYNOPSIS tagname [commit | object] 'git tag' -d tagname... 'git tag' [-n[num]] -l [--contains commit] [--points-at object] - [--column[=options] | --no-column] [--sort=key] [pattern...] + [--column[=options] | --no-column] [--sort=key] [--format=format] + [pattern...] 'git tag' -v tagname... 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. +format:: + 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] diff-tree: do not show the sha1 of the given head with --quiet
Sebastian Schuberth sschube...@gmail.com 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
Feature Request: Passing a number as an option to git tags for displaying latest tags
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 v5] pull: allow dirty tree when rebase.autostash enabled
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 m...@ikke.info 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 m...@ikke.info
Helped-by: Paul Tan pyoka...@gmail.com
---
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 m...@ikke.info
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 m...@ikke.info
Signed-off-by: Paul Tan pyoka...@gmail.com
---
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: [PATCH v4] refs: loosen restrictions on wildcard '*' refspecs
Jacob Keller jacob.e.kel...@intel.com 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: Shallow Push?
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 gits...@pobox.com wrote: Samuel Williams space.ship.travel...@gmail.com 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
Re: [PATCH 2/2] Fix sed usage in tests to work around broken xpg4/sed on Solaris
Hi, On 2015-07-20 18:07, Junio C Hamano wrote: Johannes Sixt j...@kdbg.org 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)
Jakub Narębski jna...@gmail.com 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 {
/span\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)) . br /\n;
- print /div\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 br /\n/div\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.finch d...@dotat.at http://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] diff-tree: do not show the sha1 of the given head with --quiet
--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 sschube...@gmail.com
---
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)
On 2015-07-22, Tony Finch wrote:
Jakub Narębski jna...@gmail.com 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 {
/span\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)) . br /\n;
- print /div\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 br /\n/div\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 a few caveats. I am talking here
only about conceptual level, not about how it is coded (which has
few issues as well):
- I
Re: What's cooking in git.git (Jul 2015, #01; Wed, 1)
Jakub Narębski jna...@gmail.com 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.finch d...@dotat.at http://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: [PATCH v5] pull: allow dirty tree when rebase.autostash enabled
On Wed, Jul 22, 2015 at 12:42:17PM -0700, Junio C Hamano wrote: Kevin Daudt m...@ikke.info 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
Re: [PATCH 3/3] doc: give examples for send-email cc-cmd operation
Philip Oakley philipoak...@iee.org 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: Feature Request: Passing a number as an option to git tags for displaying latest tags
Halil Öztürk haliloztur...@gmail.com 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: Feature Request: Passing a number as an option to git tags for displaying latest tags
Halil Öztürk haliloztur...@gmail.com 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-something tag to the commit that introduces the bug (and fix-something 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: Git tag: pre-receive hook issue
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
[RFC/PATCH] log: add log.firstparent option
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 joshar...@gmail.com --- 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 p...@peff.net --- 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
Re: Config variables and scripting // was Re: [RFC/PATCH] log: add log.firstparent option
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: [PATCH] receive-pack: crash when checking with non-exist HEAD
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
Config variables and scripting // was Re: [RFC/PATCH] log: add log.firstparent option
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
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: What's cooking in git.git (Jul 2015, #01; Wed, 1)
Jakub Narębski jna...@gmail.com 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.finch d...@dotat.at http://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
Jacob Keller jacob.e.kel...@intel.com writes: From: Jacob Keller jacob.kel...@gmail.com 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
[PATCH 2/2] refs: loosen restriction on wildcard * refspecs
From: Jacob Keller jacob.kel...@gmail.com
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 jacob.kel...@gmail.com
Cc: Daniel Barkalow barka...@iabervon.iabervon.org
Cc: Junio C Hamano gits...@pobox.com
---
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 refname as a reference name pattern for a refspec
(as used with remote repositories). If this option is
enabled, refname is allowed to contain a single `*`
- in place of a one full pathname component (e.g.,
- `foo/*/bar` but not `foo/bar*`).
+ 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
From: Jacob Keller jacob.kel...@gmail.com
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 jacob.kel...@gmail.com
Cc: Daniel Barkalow barka...@iabervon.iabervon.org
Cc: Junio C Hamano gits...@pobox.com
---
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
From: Jacob Keller jacob.kel...@gmail.com 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: [PATCH 2/2] refs: loosen restriction on wildcard * refspecs
On Wed, Jul 22, 2015 at 3:04 PM, Junio C Hamano gits...@pobox.com wrote: Jacob Keller jacob.e.kel...@intel.com writes: From: Jacob Keller jacob.kel...@gmail.com 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
Re: [PATCH v2b 00/16, 2 updates] Make the msvc-build scripts work again
On 21/07/15 20:25, Junio C Hamano wrote: Philip Oakley philipoak...@iee.org 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] diff-tree: do not show the sha1 of the given head with --quiet
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
--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 sschube...@gmail.com
---
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
