Re: [PATCH v5 02/11] ref-filter: make `color` use `ref_formatting_state`
Karthik Nayak karthik@gmail.com writes:
Make the `color` atom a pseudo atom and ensure that it uses
`ref_formatting_state`.
Actually, I think this is an incorrect change.
Previously, %(color:...) was taking effect immediately, and after this
patch, it takes effect starting from the next atom.
Try this:
git for-each-ref --format '%(color:red)red %(color:reset)normal'
Before your patch, I get 'red' as red, and 'normal' as normal. After
your patch, I get no color at all, since %(color:...) just stores
information that is never used because I have no real atom.
--- a/ref-filter.h
+++ b/ref-filter.h
@@ -19,11 +19,13 @@
struct atom_value {
const char *s;
unsigned long ul; /* used for sorting when not FIELD_STR */
- unsigned int pseudo_atom : 1; /* atoms which aren't placeholders for
ref attributes */
+ unsigned int pseudo_atom : 1, /* atoms which aren't placeholders for
ref attributes */
+ color : 1;
};
As a consequence of the remark above, I think the name and comment of
the field are misleading. There are 3 kinds of atoms:
* Placeholders for ref attributes
* Atoms that take action immediately, but that are not ref attributes
like %(color)
* Atoms that only act as modifiers for the next atom. Perhaps they could
be called prefix atoms or modifier atoms.
--
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
git branch command is incompatible with bash
Hello!
I hope posting this to this mailing list is okay, this is the first ever
mail that I submit to a technical mailing list.
When using the git branch command, git uses a '*' to denote the current
branch. Therefore, in bash this:
$ branchName=$(git branch -q)
$ echo $branchName
produces a directory listing, because the '*' is interpreded by the
shell.
While an (unwieldly) workaround exists:
$ branchName=$(git symbolic-ref -q HEAD)
$ branchName=${branch##refs/heads/}
it would still be nice, if there were a --current flag, that returned
only the current branch name, omitting the star:
$ branchName=$(git branch --current -q)
$ echo $branchName
master
--
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] clone: fix repo name when cloning a server's root
On Mon, Jul 27, 2015 at 6:48 PM, Patrick Steinhardt p...@pks.im wrote: When cloning a repository from a server's root, that is the URL's path component is a '/' only, we fail to generate a sensible repository name when the URL contains authentication data. This is especially bad when cloning URLs like 'ssh://user:pas...@example.com/', which results in a repository 'pas...@example.com' being created. Improve the behavior by also regarding '@'-signs as a separator when scanning the URL. In the mentioned case this would instead result in a directory 'example.com' being created. My initial reaction was, if you put password on the command line, you deserve it. However, as we improve this heuristics, perhaps it's better to export parse_connect_url() from connect.c and use it here? We would have more robust parsing. You can create a repo named example.com given the url ssh://user:p...@example.com:123/. Maybe it's overkill? Signed-off-by: Patrick Steinhardt p...@pks.im --- I was not able to come by with a useful test as that would require being able to clone a root directory. I couldn't find anything in the current tests that looks like what I want to do. Does anybody have an idea on how to achieve this? There's t/t1509/prepare-chroot.sh that will prepare a chroot for this purpose. You'll need linux, busybox and chroot permission. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 01/10] ref-filter: add option to align atoms to the left
Karthik Nayak karthik@gmail.com writes: I've been working on the same branch, and that's why I didn't really provide interdiff's, You can keep working on the same branch and tag versions you send to the list. This state is what I sent to the list as vX is something that does not change in time hence a tag avoids mistakenly changing it. -- 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
Log messages beginning # and git rebase -i
git commit will happily let you specify log messages beginning with #. But then on git rebase -i, when squashing some commits, the editing for the combined log message treats lines beginning with # as comments. This means that if you are not careful the commit message can get lost on rebasing. I suggest that git rebase should add an extra space at the start of existing log message lines which begin with #. That is a bit of a kludge but it is better than losing them because they got mixed up with comments. -- Ed Avis e...@waniasset.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] clone: fix repo name when cloning a server's root
When cloning a repository from a server's root, that is the URL's path component is a '/' only, we fail to generate a sensible repository name when the URL contains authentication data. This is especially bad when cloning URLs like 'ssh://user:pas...@example.com/', which results in a repository 'pas...@example.com' being created. Improve the behavior by also regarding '@'-signs as a separator when scanning the URL. In the mentioned case this would instead result in a directory 'example.com' being created. Signed-off-by: Patrick Steinhardt p...@pks.im --- I was not able to come by with a useful test as that would require being able to clone a root directory. I couldn't find anything in the current tests that looks like what I want to do. Does anybody have an idea on how to achieve this? builtin/clone.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/builtin/clone.c b/builtin/clone.c index a72ff7e..aaf38b2 100644 --- a/builtin/clone.c +++ b/builtin/clone.c @@ -164,11 +164,13 @@ static char *guess_dir_name(const char *repo, int is_bundle, int is_bare) /* * Find last component, but be prepared that repo could have -* the form remote.example.com:foo.git, i.e. no slash -* in the directory part. +* the form remote.example.com:foo.git, i.e. no slash in +* the directory part, or user:passw...@remote.example.com/, +* that is the path component may be empty. */ start = end; - while (repo start !is_dir_sep(start[-1]) start[-1] != ':') + while (repo start !is_dir_sep(start[-1]) start[-1] != ':' +start[-1] != '@') start--; /* -- 2.4.6 -- 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] clone: fix repo name when cloning a server's root
On Mon, Jul 27, 2015 at 07:51:30PM +0700, Duy Nguyen wrote: On Mon, Jul 27, 2015 at 6:48 PM, Patrick Steinhardt p...@pks.im wrote: When cloning a repository from a server's root, that is the URL's path component is a '/' only, we fail to generate a sensible repository name when the URL contains authentication data. This is especially bad when cloning URLs like 'ssh://user:pas...@example.com/', which results in a repository 'pas...@example.com' being created. Improve the behavior by also regarding '@'-signs as a separator when scanning the URL. In the mentioned case this would instead result in a directory 'example.com' being created. My initial reaction was, if you put password on the command line, you deserve it. However, as we improve this heuristics, perhaps it's better to export parse_connect_url() from connect.c and use it here? We would have more robust parsing. You can create a repo named example.com given the url ssh://user:p...@example.com:123/. Maybe it's overkill? Sure, specifying passwords on command line should not be done easily. Still those heuristics fail for everything that does not include an additional [:/] when the URL's path is empty. So I guess using parse_connect_url() would be the most sane solution for this, as it will also fix the case when you specify a port, which would currently use the port as directory name. I'll whip up a new version that uses parse_connect_url(). Signed-off-by: Patrick Steinhardt p...@pks.im --- I was not able to come by with a useful test as that would require being able to clone a root directory. I couldn't find anything in the current tests that looks like what I want to do. Does anybody have an idea on how to achieve this? There's t/t1509/prepare-chroot.sh that will prepare a chroot for this purpose. You'll need linux, busybox and chroot permission. Thanks for the hint. Patrick signature.asc Description: Digital signature
Re: [PATCH v5 02/11] ref-filter: make `color` use `ref_formatting_state`
Karthik Nayak karthik@gmail.com writes:
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -1195,6 +1197,11 @@ void ref_array_sort(struct ref_sorting *sorting,
struct ref_array *array)
static void ref_formatting(struct ref_formatting_state *state,
struct atom_value *v, struct strbuf *value)
{
+ if (state-color) {
+ strbuf_addstr(value, state-color);
+ free(state-color);
+ state-color = NULL;
+ }
strbuf_addf(value, %s, v-s);
}
@@ -1266,6 +1273,13 @@ static void emit(const char *cp, const char *ep)
}
}
+static void apply_pseudo_state(struct ref_formatting_state *state,
+struct atom_value *v)
+{
+ if (v-color)
+ state-color = (char *)v-s;
+}
+
void show_ref_array_item(struct ref_array_item *info, const char *format,
int quote_style)
{
const char *cp, *sp, *ep;
It's not clear enough in the code and history that these these two
functions are symmetrical.
You can find better names. 'apply_pseudo_state' seems wrong it two ways:
it does not _apply_ the state, but it stores it. And it's a pseudo-atom
related state, but not a pseudo-state.
How about
ref_formatting - apply_formatting_state
apply_pseudo_state - store_formatting_state
?
Actually, I would even call these functions right from
show_ref_array_item, so that the result look like this:
if (atomv-pseudo_atom)
store_formatting_state(state, atomv);
else {
apply_formatting_state(state, atomv);
reset_formatting_state(state);
print_value(state, atomv);
}
In the history, if you are to introduce a dumb version of ref_formatting
in PATCH 1, I think you should also introduce a dumb (actually, totally
empty) version of apply_pseudo_state. Then, further patches would just
add a few lines in each function, and ...
@@ -1281,7 +1295,10 @@ void show_ref_array_item(struct ref_array_item *info,
const char *format, int qu
if (cp sp)
emit(cp, sp);
get_ref_atom_value(info, parse_ref_filter_atom(sp + 2, ep),
atomv);
- print_value(state, atomv);
+ if (atomv-pseudo_atom)
+ apply_pseudo_state(state, atomv);
+ else
+ print_value(state, atomv);
}
... this hunk would belong to PATCH 1.
--
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 01/11] ref-filter: introduce 'ref_formatting_state'
Karthik Nayak karthik@gmail.com writes:
+static void ref_formatting(struct ref_formatting_state *state,
+struct atom_value *v, struct strbuf *value)
{
- struct strbuf sb = STRBUF_INIT;
- switch (quote_style) {
+ strbuf_addf(value, %s, v-s);
+}
You're taking 'state' as argument, but you're not using it in the
function for now. Perhaps add a temporary comment like:
static void ref_formatting(...)
{
/* Formatting according to 'state' will be applied here */
strbuf_addf(...)
}
Or perhaps it's OK like this.
-static void print_value(struct atom_value *v, int quote_style)
+static void print_value(struct ref_formatting_state *state, struct
atom_value *v)
Changing the position of the v parameter makes the patch a bit harder to
read. I would have written in this order:
static void print_value(struct atom_value *v, struct ref_formatting_state
*state)
So the patch reads as encapsulate quote_style in a struct more
straightforwardly.
@@ -1257,6 +1269,10 @@ static void emit(const char *cp, const char *ep)
void show_ref_array_item(struct ref_array_item *info, const char *format,
int quote_style)
{
const char *cp, *sp, *ep;
+ struct ref_formatting_state state;
I still found it a bit hard to read, and I would have appreciated a
comment here, like
/*
* Some (pseudo) atom have no immediate side effect, but only
* affect the next atom. Store the relevant information from
* these atoms in the 'state' variable for use when displaying
* the next atom.
*/
With this in mind, it becomes more obvious that you also need to reset
the state after using it, which you forgot to do. See:
$ ./git for-each-ref --format '%(padright:30)|%(refname)|%(refname)|'
refs/tags/v2.4.\*
|refs/tags/v2.4.0 |refs/tags/v2.4.0 |
|refs/tags/v2.4.0-rc0 |refs/tags/v2.4.0-rc0 |
|refs/tags/v2.4.0-rc1 |refs/tags/v2.4.0-rc1 |
|refs/tags/v2.4.0-rc2 |refs/tags/v2.4.0-rc2 |
|refs/tags/v2.4.0-rc3 |refs/tags/v2.4.0-rc3 |
|refs/tags/v2.4.1 |refs/tags/v2.4.1 |
|refs/tags/v2.4.2 |refs/tags/v2.4.2 |
|refs/tags/v2.4.3 |refs/tags/v2.4.3 |
|refs/tags/v2.4.4 |refs/tags/v2.4.4 |
|refs/tags/v2.4.5 |refs/tags/v2.4.5 |
|refs/tags/v2.4.6 |refs/tags/v2.4.6 |
I think only the first column should have padding, not the second. You
can fix this with a patch like this:
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -1431,6 +1431,14 @@ static void apply_pseudo_state(struct
ref_formatting_state *state,
state-ifexists = v-s;
}
+static void reset_formatting_state(struct ref_formatting_state *state)
+{
+ int quote_style = state-quote_style;
+ memset(state, 0, sizeof(*state));
+ state-quote_style = quote_style;
+}
+
+
/*
* If 'lines' is greater than 0, print that many lines from the given
* object_id 'oid'.
@@ -1492,8 +1500,11 @@ void show_ref_array_item(struct ref_array_item *info,
const char *format,
get_ref_atom_value(info, parse_ref_filter_atom(sp + 2, ep),
atomv);
if (atomv-pseudo_atom)
apply_pseudo_state(state, atomv);
- else
+ else {
print_value(state, atomv);
+ reset_formatting_state(state);
+ }
+
}
if (*cp) {
sp = cp + strlen(cp);
--
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 03/11] ref-filter: add option to pad atoms to the right
Karthik Nayak karthik@gmail.com writes: --- a/t/t6302-for-each-ref-filter.sh +++ b/t/t6302-for-each-ref-filter.sh @@ -81,4 +81,20 @@ test_expect_success 'filtering with --contains' ' test_cmp expect actual ' +test_expect_success 'padding to the right using `padright`' ' + cat expect -\EOF + refs/heads/master| + refs/heads/side | + refs/odd/spot| + refs/tags/double-tag | + refs/tags/four | + refs/tags/one| + refs/tags/signed-tag | + refs/tags/three | + refs/tags/two| + EOF + git for-each-ref --format=%(padright:25)%(refname)| actual + test_cmp expect actual +' + test_done See my remark on previous patch: this test is not sufficient. You do not only need to check that %(padright) is taken into account, but you also need to check that it is taken into account for the right atom and only this one. I'd suggest --format '%(refname)%(padright:25)|%(refname)|%(refname)|' Only the middle column should be padded. -- 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 07/11] ref-filter: add option to match literal pattern
Karthik Nayak karthik@gmail.com writes: --- a/ref-filter.c +++ b/ref-filter.c @@ -946,6 +946,32 @@ 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 path prefix (e.g. a refname refs/heads/master * matches a pattern refs/heads/) or a wildcard (e.g. the same ref * matches refs/heads/m*,too). Nit: you used to s/,too/, too/ in the comment in a previous version. I think I already suggested saying explicitly ... matches a pattern refs/heads/ but not refs/heads/m), but I won't insist on that. Just a reminder in case you missed it. -- 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 02/11] ref-filter: make `color` use `ref_formatting_state`
Matthieu Moy matthieu@grenoble-inp.fr writes: Karthik Nayak karthik@gmail.com writes: Make the `color` atom a pseudo atom and ensure that it uses `ref_formatting_state`. Actually, I think this is an incorrect change. Previously, %(color:...) was taking effect immediately, and after this patch, it takes effect starting from the next atom. ... As a consequence of the remark above, I think the name and comment of the field are misleading. There are 3 kinds of atoms: * Placeholders for ref attributes * Atoms that take action immediately, but that are not ref attributes like %(color) * Atoms that only act as modifiers for the next atom. Perhaps they could be called prefix atoms or modifier atoms. My fault. I briefly thought that it may be simpler to treat %(color) just as a different way to express a literal that cannot be typed from the keyboard, but your different kind of atom is a much better way to think about it. What is necessary is that, just like the updated print_value() knows about the formatting state, emit() needs to be told about the same formatting state. Some of these state affecting atoms may take effect on what is output by emit() (e.g. color is obviously an example, the hypotethical one that counts the current output column and uses that knowledge to align the output to certain columns, instead of right pad to make the next column 30-columns wide one, which is in this series, is another). Thanks for finding this, and Karthik, sorry for an incomplete suggestion based on a faulty thinking. -- 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 07/11] ref-filter: add option to match literal pattern
On Mon, Jul 27, 2015 at 9:27 PM, Karthik Nayak karthik@gmail.com wrote: On Mon, Jul 27, 2015 at 6:24 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Karthik Nayak karthik@gmail.com writes: --- a/ref-filter.c +++ b/ref-filter.c @@ -946,6 +946,32 @@ 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 path prefix (e.g. a refname refs/heads/master * matches a pattern refs/heads/) or a wildcard (e.g. the same ref * matches refs/heads/m*,too). Nit: you used to s/,too/, too/ in the comment in a previous version. That's carried over from a previous patch, ill change it. I think I already suggested saying explicitly ... matches a pattern refs/heads/ but not refs/heads/m), but I won't insist on that. Just a reminder in case you missed it. Sorry, I missed that out. Thanks for reminding. If I remember right, I didn't change that cause It didn't pertain to this commit. I forgot to mention it in your previous mail. -- Regards, Karthik Nayak -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git am and then git am -3 regression?
Paul Tan pyoka...@gmail.com writes: Junio, how do you want to proceed? I'd expect that builtin series would graduate in 2 releases from now at the latest, if not earlier. Let's just revert the regressing change from the scripted version and have it implemented in the builtin one in the meantime. I do not think it is worth adding features to the scripted one at this point. 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 v5 07/11] ref-filter: add option to match literal pattern
On Mon, Jul 27, 2015 at 6:24 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Karthik Nayak karthik@gmail.com writes: --- a/ref-filter.c +++ b/ref-filter.c @@ -946,6 +946,32 @@ 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 path prefix (e.g. a refname refs/heads/master * matches a pattern refs/heads/) or a wildcard (e.g. the same ref * matches refs/heads/m*,too). Nit: you used to s/,too/, too/ in the comment in a previous version. That's carried over from a previous patch, ill change it. I think I already suggested saying explicitly ... matches a pattern refs/heads/ but not refs/heads/m), but I won't insist on that. Just a reminder in case you missed it. Sorry, I missed that out. Thanks for reminding. -- Regards, Karthik Nayak -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 07/11] ref-filter: add option to match literal pattern
Karthik Nayak karthik@gmail.com writes: On Mon, Jul 27, 2015 at 9:27 PM, Karthik Nayak karthik@gmail.com wrote: On Mon, Jul 27, 2015 at 6:24 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Karthik Nayak karthik@gmail.com writes: --- a/ref-filter.c +++ b/ref-filter.c @@ -946,6 +946,32 @@ 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 path prefix (e.g. a refname refs/heads/master * matches a pattern refs/heads/) or a wildcard (e.g. the same ref * matches refs/heads/m*,too). Nit: you used to s/,too/, too/ in the comment in a previous version. That's carried over from a previous patch, ill change it. I think I already suggested saying explicitly ... matches a pattern refs/heads/ but not refs/heads/m), but I won't insist on that. Just a reminder in case you missed it. Sorry, I missed that out. Thanks for reminding. If I remember right, I didn't change that cause It didn't pertain to this commit. I forgot to mention it in your previous mail. The but not refs/heads/m part makes sense in this patch to document explicitly the difference with the other function. But again, it's just a suggestion, you chose whether to apply it or not. -- 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 v4 05/10] ref-filter: add support to sort by version
Karthik Nayak karthik@gmail.com writes:
On Sun, Jul 26, 2015 at 4:10 AM, Junio C Hamano gits...@pobox.com wrote:
Without looking at the callers, s-version looks like a misdesign
that should be updated to use the same cmp_type mechanism? That
would lead to even more obvious construct that is easy to enhance,
i.e.
switch (cmp_type) {
case CMP_VERSION:
...
case CMP_STRING:
...
case CMP_NUMBER:
...
}
I dunno.
Other than that (and the structure of that format-state stuff we
discussed separately), the series was a pleasant read.
Thanks.
That was the previous design, but Duy asked me to do this so
that we could support all atoms. And I agree with him on this.
http://article.gmane.org/gmane.comp.version-control.git/273888
I am not objecting, but $gmane/273888 does not immediately read, at
least to me, as suggesting using a mechanism different from cmp_type
but a dedicated field s-version. Puzzled...
--
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 03/11] ref-filter: add option to pad atoms to the right
Matthieu Moy matthieu@grenoble-inp.fr writes: See my remark on previous patch: this test is not sufficient. You do not only need to check that %(padright) is taken into account, but you also need to check that it is taken into account for the right atom and only this one. I'd suggest --format '%(refname)%(padright:25)|%(refname)|%(refname)|' Only the middle column should be padded. This actually raises an interesting point. It is equally valid to view that format string as requesting to pad the first | with 24 spaces; in other words, %(padright:N) would apply to the next span, be it a literal string up to the next %(atom), or the %(atom) that comes immediately after it. The thing is, the above _might_ be an OK way to ask the middle refname to be padded, but I somehow find it very unnatural and unintuitive to expect that this: --format '%(padright:25)A Very Long Irrelevancy%(refname)' would do nothing to A Very Long Irrelevancy and affects the refname that comes much later in the format string. Or we could simply forbid certain atoms followed by an non-empty literal as an error. My preference between the three is %(padright:4), etc. to apply to the next span, but I can live with it is an error to pad-right a far-away %(atom). -- 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 02/11] ref-filter: make `color` use `ref_formatting_state`
On Mon, Jul 27, 2015 at 6:17 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Karthik Nayak karthik@gmail.com writes:
Make the `color` atom a pseudo atom and ensure that it uses
`ref_formatting_state`.
Actually, I think this is an incorrect change.
Previously, %(color:...) was taking effect immediately, and after this
patch, it takes effect starting from the next atom.
Try this:
git for-each-ref --format '%(color:red)red %(color:reset)normal'
Before your patch, I get 'red' as red, and 'normal' as normal. After
your patch, I get no color at all, since %(color:...) just stores
information that is never used because I have no real atom.
--- a/ref-filter.h
+++ b/ref-filter.h
@@ -19,11 +19,13 @@
struct atom_value {
const char *s;
unsigned long ul; /* used for sorting when not FIELD_STR */
- unsigned int pseudo_atom : 1; /* atoms which aren't placeholders for
ref attributes */
+ unsigned int pseudo_atom : 1, /* atoms which aren't placeholders for
ref attributes */
+ color : 1;
};
As a consequence of the remark above, I think the name and comment of
the field are misleading. There are 3 kinds of atoms:
* Placeholders for ref attributes
* Atoms that take action immediately, but that are not ref attributes
like %(color)
* Atoms that only act as modifiers for the next atom. Perhaps they could
be called prefix atoms or modifier atoms.
Thats right, Junio and I missed out the second part and overlapped it
over with the
third part. Thanks for seeing it through.
--
Regards,
Karthik Nayak
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clone: fix repo name when cloning a server's root
Duy Nguyen pclo...@gmail.com writes: I was not able to come by with a useful test as that would require being able to clone a root directory. I couldn't find anything in the current tests that looks like what I want to do. Does anybody have an idea on how to achieve this? There's t/t1509/prepare-chroot.sh that will prepare a chroot for this purpose. You'll need linux, busybox and chroot permission. If you do not use ssh:// or file://, it should be trivial to arrange, no? http://site/repo will typically not be serving /repo from the root of the filesystem. -- 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 01/11] ref-filter: introduce 'ref_formatting_state'
On Mon, Jul 27, 2015 at 6:12 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Karthik Nayak karthik@gmail.com writes:
+static void ref_formatting(struct ref_formatting_state *state,
+struct atom_value *v, struct strbuf *value)
{
- struct strbuf sb = STRBUF_INIT;
- switch (quote_style) {
+ strbuf_addf(value, %s, v-s);
+}
You're taking 'state' as argument, but you're not using it in the
function for now. Perhaps add a temporary comment like:
static void ref_formatting(...)
{
/* Formatting according to 'state' will be applied here */
strbuf_addf(...)
}
Or perhaps it's OK like this.
I thought it'd be OK since it doesn't have any adverse effect, but I added
the comment you suggested nonetheless.
-static void print_value(struct atom_value *v, int quote_style)
+static void print_value(struct ref_formatting_state *state, struct
atom_value *v)
Changing the position of the v parameter makes the patch a bit harder to
read. I would have written in this order:
static void print_value(struct atom_value *v, struct ref_formatting_state
*state)
So the patch reads as encapsulate quote_style in a struct more
straightforwardly.
I need to be more careful about things like this, thanks.
@@ -1257,6 +1269,10 @@ static void emit(const char *cp, const char *ep)
void show_ref_array_item(struct ref_array_item *info, const char *format,
int quote_style)
{
const char *cp, *sp, *ep;
+ struct ref_formatting_state state;
I still found it a bit hard to read, and I would have appreciated a
comment here, like
/*
* Some (pseudo) atom have no immediate side effect, but only
* affect the next atom. Store the relevant information from
* these atoms in the 'state' variable for use when displaying
* the next atom.
*/
This seems good, will add this.
With this in mind, it becomes more obvious that you also need to reset
the state after using it, which you forgot to do. See:
$ ./git for-each-ref --format '%(padright:30)|%(refname)|%(refname)|'
refs/tags/v2.4.\*
|refs/tags/v2.4.0 |refs/tags/v2.4.0 |
|refs/tags/v2.4.0-rc0 |refs/tags/v2.4.0-rc0 |
|refs/tags/v2.4.0-rc1 |refs/tags/v2.4.0-rc1 |
|refs/tags/v2.4.0-rc2 |refs/tags/v2.4.0-rc2 |
|refs/tags/v2.4.0-rc3 |refs/tags/v2.4.0-rc3 |
|refs/tags/v2.4.1 |refs/tags/v2.4.1 |
|refs/tags/v2.4.2 |refs/tags/v2.4.2 |
|refs/tags/v2.4.3 |refs/tags/v2.4.3 |
|refs/tags/v2.4.4 |refs/tags/v2.4.4 |
|refs/tags/v2.4.5 |refs/tags/v2.4.5 |
|refs/tags/v2.4.6 |refs/tags/v2.4.6 |
I think only the first column should have padding, not the second. You
can fix this with a patch like this:
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -1431,6 +1431,14 @@ static void apply_pseudo_state(struct
ref_formatting_state *state,
state-ifexists = v-s;
}
+static void reset_formatting_state(struct ref_formatting_state *state)
+{
+ int quote_style = state-quote_style;
+ memset(state, 0, sizeof(*state));
+ state-quote_style = quote_style;
+}
+
+
/*
* If 'lines' is greater than 0, print that many lines from the given
* object_id 'oid'.
@@ -1492,8 +1500,11 @@ void show_ref_array_item(struct ref_array_item *info,
const char *format,
get_ref_atom_value(info, parse_ref_filter_atom(sp + 2, ep),
atomv);
if (atomv-pseudo_atom)
apply_pseudo_state(state, atomv);
- else
+ else {
print_value(state, atomv);
+ reset_formatting_state(state);
+ }
+
}
if (*cp) {
sp = cp + strlen(cp);
If you saw the last patch series, i had them reset individually, I
missed that by mistake.
But what you're doing seems good, will integrate this. thanks :D
--
Regards,
Karthik Nayak
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 03/11] ref-filter: add option to pad atoms to the right
Junio C Hamano gits...@pobox.com writes: Matthieu Moy matthieu@grenoble-inp.fr writes: See my remark on previous patch: this test is not sufficient. You do not only need to check that %(padright) is taken into account, but you also need to check that it is taken into account for the right atom and only this one. I'd suggest --format '%(refname)%(padright:25)|%(refname)|%(refname)|' Only the middle column should be padded. This actually raises an interesting point. It is equally valid to view that format string as requesting to pad the first | with 24 spaces; in other words, %(padright:N) would apply to the next span, be it a literal string up to the next %(atom), or the %(atom) that comes immediately after it. For an arbitrary %(modifier), I'd agree, but in the particular case of %(padright), I think it only makes sense if applied to something of variable length. The thing is, the above _might_ be an OK way to ask the middle refname to be padded, but I somehow find it very unnatural and unintuitive to expect that this: --format '%(padright:25)A Very Long Irrelevancy%(refname)' Yes, but on the other hand we already have: git log --format='%|(50)A very long irrevlevancy|%an|' that pads/truncate %an. So, consistancy would dictate that Karthik's version is the right one. My preference between the three is %(padright:4), etc. to apply to the next span, but I can live with it is an error to pad-right a far-away %(atom). I think there are valid argument for the 3 versions. I'm fine with any of them, as long as there's a test that shows which one is picked. -- 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 07/11] ref-filter: add option to match literal pattern
On Mon, Jul 27, 2015 at 9:36 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Karthik Nayak karthik@gmail.com writes: On Mon, Jul 27, 2015 at 9:27 PM, Karthik Nayak karthik@gmail.com wrote: On Mon, Jul 27, 2015 at 6:24 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Karthik Nayak karthik@gmail.com writes: --- a/ref-filter.c +++ b/ref-filter.c @@ -946,6 +946,32 @@ 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 path prefix (e.g. a refname refs/heads/master * matches a pattern refs/heads/) or a wildcard (e.g. the same ref * matches refs/heads/m*,too). Nit: you used to s/,too/, too/ in the comment in a previous version. That's carried over from a previous patch, ill change it. I think I already suggested saying explicitly ... matches a pattern refs/heads/ but not refs/heads/m), but I won't insist on that. Just a reminder in case you missed it. Sorry, I missed that out. Thanks for reminding. If I remember right, I didn't change that cause It didn't pertain to this commit. I forgot to mention it in your previous mail. The but not refs/heads/m part makes sense in this patch to document explicitly the difference with the other function. But again, it's just a suggestion, you chose whether to apply it or not. I think it's a valid add-on, will include it :) -- Regards, Karthik Nayak -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 02/11] ref-filter: make `color` use `ref_formatting_state`
On Mon, Jul 27, 2015 at 6:36 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Karthik Nayak karthik@gmail.com writes:
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -1195,6 +1197,11 @@ void ref_array_sort(struct ref_sorting *sorting,
struct ref_array *array)
static void ref_formatting(struct ref_formatting_state *state,
struct atom_value *v, struct strbuf *value)
{
+ if (state-color) {
+ strbuf_addstr(value, state-color);
+ free(state-color);
+ state-color = NULL;
+ }
strbuf_addf(value, %s, v-s);
}
@@ -1266,6 +1273,13 @@ static void emit(const char *cp, const char *ep)
}
}
+static void apply_pseudo_state(struct ref_formatting_state *state,
+struct atom_value *v)
+{
+ if (v-color)
+ state-color = (char *)v-s;
+}
+
void show_ref_array_item(struct ref_array_item *info, const char *format,
int quote_style)
{
const char *cp, *sp, *ep;
It's not clear enough in the code and history that these these two
functions are symmetrical.
You can find better names. 'apply_pseudo_state' seems wrong it two ways:
it does not _apply_ the state, but it stores it. And it's a pseudo-atom
related state, but not a pseudo-state.
How about
ref_formatting - apply_formatting_state
apply_pseudo_state - store_formatting_state
?
Yes, your suggested naming scheme is better. Ill adopt this.
Actually, I would even call these functions right from
show_ref_array_item, so that the result look like this:
if (atomv-pseudo_atom)
store_formatting_state(state, atomv);
else {
apply_formatting_state(state, atomv);
reset_formatting_state(state);
print_value(state, atomv);
}
This would eliminate that extra strbuf in print_value() wouldn't it,
but this would also mean
that we replace the value in atomv to hold the new formatted value.
Sounds good to me.
Thanks :)
In the history, if you are to introduce a dumb version of ref_formatting
in PATCH 1, I think you should also introduce a dumb (actually, totally
empty) version of apply_pseudo_state. Then, further patches would just
add a few lines in each function, and ...
@@ -1281,7 +1295,10 @@ void show_ref_array_item(struct ref_array_item *info,
const char *format, int qu
if (cp sp)
emit(cp, sp);
get_ref_atom_value(info, parse_ref_filter_atom(sp + 2, ep),
atomv);
- print_value(state, atomv);
+ if (atomv-pseudo_atom)
+ apply_pseudo_state(state, atomv);
+ else
+ print_value(state, atomv);
}
... this hunk would belong to PATCH 1.
I'll add a placeholder for this in the PATCH 1. Thanks :D
--
Regards,
Karthik Nayak
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 02/11] ref-filter: make `color` use `ref_formatting_state`
On Mon, Jul 27, 2015 at 7:58 PM, Junio C Hamano gits...@pobox.com wrote: Matthieu Moy matthieu@grenoble-inp.fr writes: Karthik Nayak karthik@gmail.com writes: Make the `color` atom a pseudo atom and ensure that it uses `ref_formatting_state`. Actually, I think this is an incorrect change. Previously, %(color:...) was taking effect immediately, and after this patch, it takes effect starting from the next atom. ... As a consequence of the remark above, I think the name and comment of the field are misleading. There are 3 kinds of atoms: * Placeholders for ref attributes * Atoms that take action immediately, but that are not ref attributes like %(color) * Atoms that only act as modifiers for the next atom. Perhaps they could be called prefix atoms or modifier atoms. My fault. I briefly thought that it may be simpler to treat %(color) just as a different way to express a literal that cannot be typed from the keyboard, but your different kind of atom is a much better way to think about it. Yes even I agree with this. What is necessary is that, just like the updated print_value() knows about the formatting state, emit() needs to be told about the same formatting state. Some of these state affecting atoms may take effect on what is output by emit() (e.g. color is obviously an example, the hypotethical one that counts the current output column and uses that knowledge to align the output to certain columns, instead of right pad to make the next column 30-columns wide one, which is in this series, is another). This depends on whether these modifier atoms should effect only succeeding atoms or any string. Since there is a conversation about this topic on the other patch, let's continue this discussion there. Thanks for finding this, and Karthik, sorry for an incomplete suggestion based on a faulty thinking. I don't see why you have to be sorry, you were trying to help :) -- Regards, Karthik Nayak -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 05/10] ref-filter: add support to sort by version
On Mon, Jul 27, 2015 at 8:54 PM, Junio C Hamano gits...@pobox.com wrote:
Karthik Nayak karthik@gmail.com writes:
On Sun, Jul 26, 2015 at 4:10 AM, Junio C Hamano gits...@pobox.com wrote:
Without looking at the callers, s-version looks like a misdesign
that should be updated to use the same cmp_type mechanism? That
would lead to even more obvious construct that is easy to enhance,
i.e.
switch (cmp_type) {
case CMP_VERSION:
...
case CMP_STRING:
...
case CMP_NUMBER:
...
}
I dunno.
Other than that (and the structure of that format-state stuff we
discussed separately), the series was a pleasant read.
Thanks.
That was the previous design, but Duy asked me to do this so
that we could support all atoms. And I agree with him on this.
http://article.gmane.org/gmane.comp.version-control.git/273888
I am not objecting, but $gmane/273888 does not immediately read, at
least to me, as suggesting using a mechanism different from cmp_type
but a dedicated field s-version. Puzzled...
What I mean was since version/v aren't atoms as such, their processing is
done before we parse through atoms and fill used_atoms and used_atom_type.
cmp_type is obtained from the used_atom_type, which isn't filled by
version/v.
Hence the dedicated field, just like reverse.
--
Regards,
Karthik Nayak
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] completion: Add '--edit-todo' to rebase
Signed-off-by: Thomas Braun thomas.br...@virtuell-zuhause.de
---
John Keeping j...@keeping.me.uk hat am 13. Juli 2015 um 15:11 geschrieben:
git-rebase.sh contains:
if test $action = edit-todo test $type != interactive
then
die $(gettext The --edit-todo action can only be used during
interactive
rebase.)
fi
I wonder if it's worth doing a similar check here, which presumably
means testing if $dir/interactive exists.
Good point. Thanks for the hint.
contrib/completion/git-completion.bash | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index c97c648..b03050e 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1668,7 +1668,11 @@ _git_rebase ()
{
local dir=$(__gitdir)
if [ -d $dir/rebase-apply ] || [ -d $dir/rebase-merge ]; then
- __gitcomp --continue --skip --abort
+ if [ -d $dir/interactive ]; then
+ __gitcomp --continue --skip --abort --edit-todo
+ else
+ __gitcomp --continue --skip --abort
+ fi
return
fi
__git_complete_strategy return
--
2.4.5.windows.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 03/11] ref-filter: add option to pad atoms to the right
Karthik Nayak karthik@gmail.com writes: On Mon, Jul 27, 2015 at 9:24 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Yes, but on the other hand we already have: git log --format='%|(50)A very long irrevlevancy|%an|' that pads/truncate %an. So, consistancy would dictate that Karthik's version is the right one. Sorry but I didn't understand what you're trying to say here, Matthieu. The git log equivalent of %(padright:N) is %|(N), and it behaves the same way as your current implementation of %(padright) (except for the missing reset in your v5). So, if we want to be consistant with git log, we should keep the apply to next atom, even if it's far away in the format string semantics. Note that consistancy is not the only criterion for choice, so I'm not saying we should absolutely do this, just that there's an argument in favor of it. -- 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 03/11] ref-filter: add option to pad atoms to the right
On Mon, Jul 27, 2015 at 9:24 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Junio C Hamano gits...@pobox.com writes: Matthieu Moy matthieu@grenoble-inp.fr writes: See my remark on previous patch: this test is not sufficient. You do not only need to check that %(padright) is taken into account, but you also need to check that it is taken into account for the right atom and only this one. I'd suggest --format '%(refname)%(padright:25)|%(refname)|%(refname)|' Only the middle column should be padded. This actually raises an interesting point. It is equally valid to view that format string as requesting to pad the first | with 24 spaces; in other words, %(padright:N) would apply to the next span, be it a literal string up to the next %(atom), or the %(atom) that comes immediately after it. For an arbitrary %(modifier), I'd agree, but in the particular case of %(padright), I think it only makes sense if applied to something of variable length I agree with Matthieu here, Other than atom values, any user defined string would be of known size, hence padding for such things would make no sense. The thing is, the above _might_ be an OK way to ask the middle refname to be padded, but I somehow find it very unnatural and unintuitive to expect that this: --format '%(padright:25)A Very Long Irrelevancy%(refname)' Yes, but on the other hand we already have: git log --format='%|(50)A very long irrevlevancy|%an|' that pads/truncate %an. So, consistancy would dictate that Karthik's version is the right one. Sorry but I didn't understand what you're trying to say here, Matthieu. My preference between the three is %(padright:4), etc. to apply to the next span, but I can live with it is an error to pad-right a far-away %(atom). I think there are valid argument for the 3 versions. I'm fine with any of them, as long as there's a test that shows which one is picked. Makes sense, thanks both of you :) -- Regards, Karthik Nayak -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 03/11] ref-filter: add option to pad atoms to the right
On Mon, Jul 27, 2015 at 6:20 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: u also need to check that it is taken into account for the right atom and only this one. I'd suggest --format '%(refname)%(padright:25)|%(refname)|%(refname)|' I guess this is more accurate, Thanks. -- Regards, Karthik Nayak -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 03/11] ref-filter: add option to pad atoms to the right
Matthieu Moy matthieu@grenoble-inp.fr writes: Yes, but on the other hand we already have: git log --format='%|(50)A very long irrevlevancy|%an|' that pads/truncate %an. So, consistancy would dictate that Karthik's version is the right one. Interesting. Although that %(50) looks simply a bug to me which we may want to fix. I wonder if there is a good reason why the above should not be spelled as --format=A very long irrelevancy%(50)%an. -- 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 1/5] refs: Introduce pseudoref and per-worktree ref concepts
Add glossary entries for both concepts.
Pseudorefs and per-worktree refs do not yet have special handling,
because the files refs backend already handles them correctly. Later,
we will make the LMDB backend call out to the files backend to handle
per-worktree refs.
Signed-off-by: David Turner dtur...@twopensource.com
---
Documentation/glossary-content.txt | 21 +
refs.c | 23 +++
refs.h | 2 ++
3 files changed, 46 insertions(+)
diff --git a/Documentation/glossary-content.txt
b/Documentation/glossary-content.txt
index ab18f4b..67952f3 100644
--- a/Documentation/glossary-content.txt
+++ b/Documentation/glossary-content.txt
@@ -411,6 +411,27 @@ exclude;;
core Git. Porcelains expose more of a def_SCM,SCM
interface than the def_plumbing,plumbing.
+[[def_per_worktree_ref]]per-worktree ref::
+ Refs that are per-def_worktree,worktree, rather than
+ global. This is presently only def_HEAD,HEAD, but might
+ later include other unusual refs.
+
+[[def_pseudoref]]pseudoref::
+ Pseudorefs are a class of files under `$GIT_DIR` which behave
+ like refs for the purposes of rev-parse, but which are treated
+ specially by git. Psuedorefs both have names are all-caps,
+ and always start with a line consisting of a
+ def_sha1,SHA-1 followed by whitespace. So, HEAD is not a
+ pseudoref, because it is sometimes a symbolic ref. They might
+ optionally some additional data. `MERGE_HEAD` and
+ `CHERRY_PICK_HEAD` are examples. Unlike
+ def_per_worktree_ref,per-worktree refs, these files cannot
+ be symbolic refs, and never have reflogs. They also cannot be
+ updated through the normal ref update machinery. Instead,
+ they are updated by directly writing to the files. However,
+ they can be read as if they were refs, so `git rev-parse
+ MERGE_HEAD` will work.
+
[[def_pull]]pull::
Pulling a def_branch,branch means to def_fetch,fetch it and
def_merge,merge it. See also linkgit:git-pull[1].
diff --git a/refs.c b/refs.c
index 0b96ece..0d10b7b 100644
--- a/refs.c
+++ b/refs.c
@@ -2848,6 +2848,29 @@ static int delete_ref_loose(struct ref_lock *lock, int
flag, struct strbuf *err)
return 0;
}
+int is_per_worktree_ref(const char *refname)
+{
+ return !strcmp(refname, HEAD);
+}
+
+static int is_pseudoref(const char *refname)
+{
+ const char *c;
+
+ if (strchr(refname, '/'))
+ return 0;
+
+ if (is_per_worktree_ref(refname))
+ return 0;
+
+ for (c = refname; *c; ++c) {
+ if (!isupper(*c) *c != '-' *c != '_')
+ return 0;
+ }
+
+ return 1;
+}
+
int delete_ref(const char *refname, const unsigned char *old_sha1,
unsigned int flags)
{
diff --git a/refs.h b/refs.h
index e4e46c3..bd5526e 100644
--- a/refs.h
+++ b/refs.h
@@ -445,6 +445,8 @@ extern int parse_hide_refs_config(const char *var, const
char *value, const char
extern int ref_is_hidden(const char *);
+int is_per_worktree_ref(const char *refname);
+
enum expire_reflog_flags {
EXPIRE_REFLOGS_DRY_RUN = 1 0,
EXPIRE_REFLOGS_UPDATE_REF = 1 1,
--
2.0.4.315.gad8727a-twtrsrc
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/5] pseudorefs
This version of the pseudorefs patch series is much simpler. Instead of forbidding update_ref and delete_ref from updating pseudorefs, these functions now just special-case pseudorefs. So we can use update_ref to write pseudorefs in a rebase and sequencer, and we don't need to rewrite so much code. In addition, I made typo fixes suggested by Eric Sunshine and Philip Oakley. -- 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] tests: Remove some direct access to .git/logs
Alternate refs backends might store reflogs somewhere other than .git/logs. Change most test code that directly accesses .git/logs to instead use git reflog commands. There are still a few tests which need direct access to reflogs: to check reflog permissions, to manually create reflogs from scratch, to save/restore reflogs, to check the format of raw reflog data, and to remove not just reflog contents, but the reflogs themselves. All cases which don't need direct access have been modified. Signed-off-by: David Turner dtur...@twopensource.com --- This is a follow-up to the patch series that introduced --create-reflog Many tests need to be changed in order to pass under alternate refs backends. This particular set of issues happens to be easy to clean up, so I'm sending this patch now. --- t/t1400-update-ref.sh | 5 ++--- t/t1410-reflog.sh | 24 t/t1411-reflog-show.sh| 2 +- t/t1503-rev-parse-verify.sh | 9 +++-- t/t3200-branch.sh | 12 ++-- t/t3210-pack-refs.sh | 2 +- t/t3404-rebase-interactive.sh | 10 +- t/t3903-stash.sh | 2 +- t/t5312-prune-corruption.sh | 2 +- t/t6501-freshen-objects.sh| 2 +- t/t7509-commit.sh | 13 - 11 files changed, 37 insertions(+), 46 deletions(-) diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh index d787bf5..8bf1559 100755 --- a/t/t1400-update-ref.sh +++ b/t/t1400-update-ref.sh @@ -155,12 +155,11 @@ test_expect_success (not) changed .git/$m ' rm -f .git/$m -: a repository with working tree always has reflog these days... -: .git/logs/refs/heads/master +rm -f .git/logs/refs/heads/master test_expect_success \ create $m (logged by touch) \ 'GIT_COMMITTER_DATE=2005-05-26 23:30 \ -git update-ref HEAD '$A' -m Initial Creation +git update-ref --create-reflog HEAD '$A' -m Initial Creation test '$A' = $(cat .git/'$m')' test_expect_success \ update $m (logged by touch) \ diff --git a/t/t1410-reflog.sh b/t/t1410-reflog.sh index 779d4e3..b79049f 100755 --- a/t/t1410-reflog.sh +++ b/t/t1410-reflog.sh @@ -100,7 +100,8 @@ test_expect_success setup ' check_fsck - test_line_count = 4 .git/logs/refs/heads/master + git reflog refs/heads/master output + test_line_count = 4 output ' test_expect_success rewind ' @@ -116,7 +117,8 @@ test_expect_success rewind ' check_have A B C D E F G H I J K L - test_line_count = 5 .git/logs/refs/heads/master + git reflog refs/heads/master output + test_line_count = 5 output ' test_expect_success 'corrupt and check' ' @@ -134,7 +136,8 @@ test_expect_success 'reflog expire --dry-run should not touch reflog' ' --stale-fix \ --all - test_line_count = 5 .git/logs/refs/heads/master + git reflog refs/heads/master output + test_line_count = 5 output check_fsck missing blob $F ' @@ -147,7 +150,8 @@ test_expect_success 'reflog expire' ' --stale-fix \ --all - test_line_count = 2 .git/logs/refs/heads/master + git reflog refs/heads/master output + test_line_count = 2 output check_fsck dangling commit $K ' @@ -213,7 +217,8 @@ test_expect_success 'delete' ' test_expect_success 'rewind2' ' test_tick git reset --hard HEAD~2 - test_line_count = 4 .git/logs/refs/heads/master + git reflog refs/heads/master output + test_line_count = 4 output ' test_expect_success '--expire=never' ' @@ -222,7 +227,8 @@ test_expect_success '--expire=never' ' --expire=never \ --expire-unreachable=never \ --all - test_line_count = 4 .git/logs/refs/heads/master + git reflog refs/heads/master output + test_line_count = 4 output ' test_expect_success 'gc.reflogexpire=never' ' @@ -230,7 +236,8 @@ test_expect_success 'gc.reflogexpire=never' ' git config gc.reflogexpire never git config gc.reflogexpireunreachable never git reflog expire --verbose --all - test_line_count = 4 .git/logs/refs/heads/master + git reflog refs/heads/master output + test_line_count = 4 output ' test_expect_success 'gc.reflogexpire=false' ' @@ -238,7 +245,8 @@ test_expect_success 'gc.reflogexpire=false' ' git config gc.reflogexpire false git config gc.reflogexpireunreachable false git reflog expire --verbose --all - test_line_count = 4 .git/logs/refs/heads/master + git reflog refs/heads/master output + test_line_count = 4 output git config --unset gc.reflogexpire git config --unset gc.reflogexpireunreachable diff --git a/t/t1411-reflog-show.sh b/t/t1411-reflog-show.sh index 6f47c0d..d568b35 100755 --- a/t/t1411-reflog-show.sh +++ b/t/t1411-reflog-show.sh @@ -138,7 +138,7 @@
Re: [PATCH v5 03/11] ref-filter: add option to pad atoms to the right
On Tue, Jul 28, 2015 at 12:17 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Karthik Nayak karthik@gmail.com writes: On Mon, Jul 27, 2015 at 9:24 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Yes, but on the other hand we already have: git log --format='%|(50)A very long irrevlevancy|%an|' that pads/truncate %an. So, consistancy would dictate that Karthik's version is the right one. Sorry but I didn't understand what you're trying to say here, Matthieu. The git log equivalent of %(padright:N) is %|(N), and it behaves the same way as your current implementation of %(padright) (except for the missing reset in your v5). So, if we want to be consistant with git log, we should keep the apply to next atom, even if it's far away in the format string semantics. Note that consistancy is not the only criterion for choice, so I'm not saying we should absolutely do this, just that there's an argument in favor of it. I didn't know that, thanks, I think I'll let Junio make the call here :) -- Regards, Karthik Nayak -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] notes: replace pseudorefs with real refs
All-caps files like NOTES_MERGE_REF are pseudorefs, and thus are per-worktree. We don't want multiple notes merges happening at once (in different worktrees), so we want to make these refs true refs. So, we lowercase NOTES_MERGE_REF and friends. That way, backends that distinguish between pseudorefs and real refs can correctly handle notes merges. This will also enable us to prevent pseudorefs from being updated by the ref update machinery e.g. git update-ref. Signed-off-by: David Turner dtur...@twopensource.com --- Documentation/git-notes.txt | 12 ++--- builtin/notes.c | 38 notes-merge.c | 10 ++-- notes-merge.h | 8 ++-- t/t3310-notes-merge-manual-resolve.sh | 86 +-- t/t3311-notes-merge-fanout.sh | 6 +-- 6 files changed, 80 insertions(+), 80 deletions(-) diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt index 851518d..82fa3fd 100644 --- a/Documentation/git-notes.txt +++ b/Documentation/git-notes.txt @@ -103,7 +103,7 @@ merge:: If conflicts arise and a strategy for automatically resolving conflicting notes (see the -s/--strategy option) is not given, the manual resolver is used. This resolver checks out the -conflicting notes in a special worktree (`.git/NOTES_MERGE_WORKTREE`), +conflicting notes in a special worktree (`.git/notes_merge_worktree`), and instructs the user to manually resolve the conflicts there. When done, the user can either finalize the merge with 'git notes merge --commit', or abort the merge with @@ -189,11 +189,11 @@ OPTIONS --commit:: Finalize an in-progress 'git notes merge'. Use this option when you have resolved the conflicts that 'git notes merge' - stored in .git/NOTES_MERGE_WORKTREE. This amends the partial + stored in .git/notes_merge_worktree. This amends the partial merge commit created by 'git notes merge' (stored in - .git/NOTES_MERGE_PARTIAL) by adding the notes in - .git/NOTES_MERGE_WORKTREE. The notes ref stored in the - .git/NOTES_MERGE_REF symref is updated to the resulting commit. + .git/notes_merge_partial) by adding the notes in + .git/notes_merge_worktree. The notes ref stored in the + .git/notes_merge_ref symref is updated to the resulting commit. --abort:: Abort/reset a in-progress 'git notes merge', i.e. a notes merge @@ -241,7 +241,7 @@ NOTES MERGE STRATEGIES The default notes merge strategy is manual, which checks out conflicting notes in a special work tree for resolving notes conflicts -(`.git/NOTES_MERGE_WORKTREE`), and instructs the user to resolve the +(`.git/notes_merge_worktree`), and instructs the user to resolve the conflicts in that work tree. When done, the user can either finalize the merge with 'git notes merge --commit', or abort the merge with diff --git a/builtin/notes.c b/builtin/notes.c index 63f95fc..e0b8a02 100644 --- a/builtin/notes.c +++ b/builtin/notes.c @@ -670,14 +670,14 @@ static int merge_abort(struct notes_merge_options *o) int ret = 0; /* -* Remove .git/NOTES_MERGE_PARTIAL and .git/NOTES_MERGE_REF, and call -* notes_merge_abort() to remove .git/NOTES_MERGE_WORKTREE. +* Remove .git/notes_merge_partial and .git/notes_merge_ref, and call +* notes_merge_abort() to remove .git/notes_merge_worktree. */ - if (delete_ref(NOTES_MERGE_PARTIAL, NULL, 0)) - ret += error(Failed to delete ref NOTES_MERGE_PARTIAL); - if (delete_ref(NOTES_MERGE_REF, NULL, REF_NODEREF)) - ret += error(Failed to delete ref NOTES_MERGE_REF); + if (delete_ref(notes_merge_partial, NULL, 0)) + ret += error(Failed to delete ref notes_merge_partial); + if (delete_ref(notes_merge_ref, NULL, REF_NODEREF)) + ret += error(Failed to delete ref notes_merge_ref); if (notes_merge_abort(o)) ret += error(Failed to remove 'git notes merge' worktree); return ret; @@ -694,16 +694,16 @@ static int merge_commit(struct notes_merge_options *o) int ret; /* -* Read partial merge result from .git/NOTES_MERGE_PARTIAL, -* and target notes ref from .git/NOTES_MERGE_REF. +* Read partial merge result from .git/notes_merge_partial, +* and target notes ref from .git/notes_merge_ref. */ - if (get_sha1(NOTES_MERGE_PARTIAL, sha1)) - die(Failed to read ref NOTES_MERGE_PARTIAL); + if (get_sha1(notes_merge_partial, sha1)) + die(Failed to read ref notes_merge_partial); else if (!(partial = lookup_commit_reference(sha1))) - die(Could not find commit from NOTES_MERGE_PARTIAL.); + die(Could not find commit from notes_merge_partial.); else if (parse_commit(partial)) - die(Could not parse commit from
[PATCH 3/5] pseudorefs: create and use pseudoref update and delete functions
Pseudorefs should not be updated through the ref transaction
API, because alternate ref backends still need to store pseudorefs
in GIT_DIR (instead of wherever they store refs). Instead,
change update_ref and delete_ref to call pseudoref-specific
functions.
Signed-off-by: David Turner dtur...@twopensource.com
---
refs.c | 100 +++--
1 file changed, 92 insertions(+), 8 deletions(-)
diff --git a/refs.c b/refs.c
index 0d10b7b..119ac9c 100644
--- a/refs.c
+++ b/refs.c
@@ -2871,12 +2871,87 @@ static int is_pseudoref(const char *refname)
return 1;
}
+static int write_pseudoref(const char *pseudoref, const unsigned char *sha1,
+ const unsigned char *old_sha1, struct strbuf *err)
+{
+ const char *filename;
+ int fd;
+ static struct lock_file lock;
+ struct strbuf buf = STRBUF_INIT;
+ int ret = -1;
+
+ strbuf_addf(buf, %s\n, sha1_to_hex(sha1));
+
+ filename = git_path(%s, pseudoref);
+ fd = hold_lock_file_for_update(lock, filename, LOCK_DIE_ON_ERROR);
+ if (fd 0) {
+ strbuf_addf(err, Could not open '%s' for writing: %s,
+ filename, strerror(errno));
+ return -1;
+ }
+
+ if (old_sha1) {
+ unsigned char actual_old_sha1[20];
+ read_ref(pseudoref, actual_old_sha1);
+ if (hashcmp(actual_old_sha1, old_sha1)) {
+ strbuf_addf(err, Unexpected sha1 when writing %s,
pseudoref);
+ rollback_lock_file(lock);
+ goto done;
+ }
+ }
+
+ if (write_in_full(fd, buf.buf, buf.len) != buf.len) {
+ strbuf_addf(err, Could not write to '%s', filename);
+ rollback_lock_file(lock);
+ goto done;
+ }
+
+ commit_lock_file(lock);
+ ret = 0;
+done:
+ strbuf_release(buf);
+ return ret;
+}
+
+static int delete_pseudoref(const char *pseudoref, const unsigned char
*old_sha1)
+{
+ static struct lock_file lock;
+ const char *filename;
+
+ filename = git_path(%s, pseudoref);
+
+ if (old_sha1 !is_null_sha1(old_sha1)) {
+ int fd;
+ unsigned char actual_old_sha1[20];
+
+ fd = hold_lock_file_for_update(lock, filename,
+ LOCK_DIE_ON_ERROR);
+ if (fd 0)
+ die_errno(_(Could not open '%s' for writing),
filename);
+ read_ref(pseudoref, actual_old_sha1);
+ if (hashcmp(actual_old_sha1, old_sha1)) {
+ warning(Unexpected sha1 when deleting %s, pseudoref);
+ return -1;
+ }
+
+ unlink(filename);
+ rollback_lock_file(lock);
+ } else {
+ unlink(filename);
+ }
+
+ return 0;
+}
+
int delete_ref(const char *refname, const unsigned char *old_sha1,
unsigned int flags)
{
struct ref_transaction *transaction;
struct strbuf err = STRBUF_INIT;
+ if (is_pseudoref(refname))
+ return delete_pseudoref(refname, old_sha1);
+
transaction = ref_transaction_begin(err);
if (!transaction ||
ref_transaction_delete(transaction, refname, old_sha1,
@@ -3970,17 +4045,25 @@ int update_ref(const char *msg, const char *refname,
const unsigned char *new_sha1, const unsigned char *old_sha1,
unsigned int flags, enum action_on_err onerr)
{
- struct ref_transaction *t;
+ struct ref_transaction *t = NULL;
struct strbuf err = STRBUF_INIT;
+ int ret = 0;
- t = ref_transaction_begin(err);
- if (!t ||
- ref_transaction_update(t, refname, new_sha1, old_sha1,
- flags, msg, err) ||
- ref_transaction_commit(t, err)) {
+ if (is_pseudoref(refname) 0) {
+ ret = write_pseudoref(refname, new_sha1, old_sha1, err);
+ } else {
+ t = ref_transaction_begin(err);
+ if (!t ||
+ ref_transaction_update(t, refname, new_sha1, old_sha1,
+ flags, msg, err) ||
+ ref_transaction_commit(t, err)) {
+ ret = 1;
+ ref_transaction_free(t);
+ }
+ }
+ if (ret) {
const char *str = update_ref failed for ref '%s': %s;
- ref_transaction_free(t);
switch (onerr) {
case UPDATE_REFS_MSG_ON_ERR:
error(str, refname, err.buf);
@@ -3995,7 +4078,8 @@ int update_ref(const char *msg, const char *refname,
return 1;
}
strbuf_release(err);
- ref_transaction_free(t);
+ if (t)
+ ref_transaction_free(t);
[PATCH 4/5] rebase: use update_ref
Instead of manually writing a pseudoref (in one case) and shelling out
to git update-ref (in another), use the update_ref function. This
is much simpler.
Signed-off-by: David Turner dtur...@twopensource.com
---
bisect.c | 37 -
1 file changed, 8 insertions(+), 29 deletions(-)
diff --git a/bisect.c b/bisect.c
index 857cf59..33ac88d 100644
--- a/bisect.c
+++ b/bisect.c
@@ -19,7 +19,6 @@ static struct object_id *current_bad_oid;
static const char *argv_checkout[] = {checkout, -q, NULL, --, NULL};
static const char *argv_show_branch[] = {show-branch, NULL, NULL};
-static const char *argv_update_ref[] = {update-ref, --no-deref,
BISECT_HEAD, NULL, NULL};
static const char *term_bad;
static const char *term_good;
@@ -675,34 +674,16 @@ static int is_expected_rev(const struct object_id *oid)
return res;
}
-static void mark_expected_rev(char *bisect_rev_hex)
-{
- int len = strlen(bisect_rev_hex);
- const char *filename = git_path(BISECT_EXPECTED_REV);
- int fd = open(filename, O_CREAT | O_TRUNC | O_WRONLY, 0600);
-
- if (fd 0)
- die_errno(could not create file '%s', filename);
-
- bisect_rev_hex[len] = '\n';
- write_or_die(fd, bisect_rev_hex, len + 1);
- bisect_rev_hex[len] = '\0';
-
- if (close(fd) 0)
- die(closing file %s: %s, filename, strerror(errno));
-}
-
-static int bisect_checkout(char *bisect_rev_hex, int no_checkout)
+static int bisect_checkout(const unsigned char *bisect_rev, int no_checkout)
{
+ char bisect_rev_hex[GIT_SHA1_HEXSZ + 1];
- mark_expected_rev(bisect_rev_hex);
+ memcpy(bisect_rev_hex, sha1_to_hex(bisect_rev), GIT_SHA1_HEXSZ + 1);
+ update_ref(NULL, BISECT_EXPECTED_REV, bisect_rev, NULL, 0,
UPDATE_REFS_DIE_ON_ERR);
argv_checkout[2] = bisect_rev_hex;
if (no_checkout) {
- argv_update_ref[3] = bisect_rev_hex;
- if (run_command_v_opt(argv_update_ref, RUN_GIT_CMD))
- die(update-ref --no-deref HEAD failed on %s,
- bisect_rev_hex);
+ update_ref(NULL, BISECT_HEAD, bisect_rev, NULL, 0,
UPDATE_REFS_DIE_ON_ERR);
} else {
int res;
res = run_command_v_opt(argv_checkout, RUN_GIT_CMD);
@@ -804,7 +785,7 @@ static void check_merge_bases(int no_checkout)
handle_skipped_merge_base(mb);
} else {
printf(Bisecting: a merge base must be tested\n);
- exit(bisect_checkout(sha1_to_hex(mb), no_checkout));
+ exit(bisect_checkout(mb, no_checkout));
}
}
@@ -948,7 +929,6 @@ int bisect_next_all(const char *prefix, int no_checkout)
struct commit_list *tried;
int reaches = 0, all = 0, nr, steps;
const unsigned char *bisect_rev;
- char bisect_rev_hex[GIT_SHA1_HEXSZ + 1];
read_bisect_terms(term_bad, term_good);
if (read_bisect_refs())
@@ -986,11 +966,10 @@ int bisect_next_all(const char *prefix, int no_checkout)
}
bisect_rev = revs.commits-item-object.sha1;
- memcpy(bisect_rev_hex, sha1_to_hex(bisect_rev), GIT_SHA1_HEXSZ + 1);
if (!hashcmp(bisect_rev, current_bad_oid-hash)) {
exit_if_skipped_commits(tried, current_bad_oid);
- printf(%s is the first %s commit\n, bisect_rev_hex,
+ printf(%s is the first %s commit\n, sha1_to_hex(bisect_rev),
term_bad);
show_diff_tree(prefix, revs.commits-item);
/* This means the bisection process succeeded. */
@@ -1003,7 +982,7 @@ int bisect_next_all(const char *prefix, int no_checkout)
(roughly %d step%s)\n, nr, (nr == 1 ? : s),
steps, (steps == 1 ? : s));
- return bisect_checkout(bisect_rev_hex, no_checkout);
+ return bisect_checkout(bisect_rev, no_checkout);
}
static inline int log2i(int n)
--
2.0.4.315.gad8727a-twtrsrc
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] sequencer: replace write_cherry_pick_head with update_ref
Now update_ref (via write_pseudoref) does almost exactly what
write_cherry_pick_head did, so we can remove write_cherry_pick_head
and just use update_ref.
Signed-off-by: David Turner dtur...@twopensource.com
---
sequencer.c | 23 ---
1 file changed, 4 insertions(+), 19 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index c4f4b7d..554a704 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -158,23 +158,6 @@ static void free_message(struct commit *commit, struct
commit_message *msg)
unuse_commit_buffer(commit, msg-message);
}
-static void write_cherry_pick_head(struct commit *commit, const char
*pseudoref)
-{
- const char *filename;
- int fd;
- struct strbuf buf = STRBUF_INIT;
-
- strbuf_addf(buf, %s\n, sha1_to_hex(commit-object.sha1));
-
- filename = git_path(%s, pseudoref);
- fd = open(filename, O_WRONLY | O_CREAT, 0666);
- if (fd 0)
- die_errno(_(Could not open '%s' for writing), filename);
- if (write_in_full(fd, buf.buf, buf.len) != buf.len || close(fd))
- die_errno(_(Could not write to '%s'), filename);
- strbuf_release(buf);
-}
-
static void print_advice(int show_hint, struct replay_opts *opts)
{
char *msg = getenv(GIT_CHERRY_PICK_HELP);
@@ -607,9 +590,11 @@ static int do_pick_commit(struct commit *commit, struct
replay_opts *opts)
* write it at all.
*/
if (opts-action == REPLAY_PICK !opts-no_commit (res == 0 || res
== 1))
- write_cherry_pick_head(commit, CHERRY_PICK_HEAD);
+ update_ref(NULL, CHERRY_PICK_HEAD, commit-object.sha1, NULL,
+ REF_NODEREF, UPDATE_REFS_DIE_ON_ERR);
if (opts-action == REPLAY_REVERT ((opts-no_commit res == 0) ||
res == 1))
- write_cherry_pick_head(commit, REVERT_HEAD);
+ update_ref(NULL, REVERT_HEAD, commit-object.sha1, NULL,
+ REF_NODEREF, UPDATE_REFS_DIE_ON_ERR);
if (res) {
error(opts-action == REPLAY_REVERT
--
2.0.4.315.gad8727a-twtrsrc
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] graph.c: visual difference on subsequent series
Any reason why this patch wasn't included / reviewed?
Thanks,
A.
On 2014-11-10 08:33:32, Antoine Beaupré wrote:
For projects with separate history lines and, thus, multiple root-commits, the
linear arrangement of `git log --graph --oneline` does not allow the user to
spot where the sequence ends, giving the impression that it's a contiguous
history. E.g.
History sequence A: a1 -- a2 -- a3 (root-commit)
History sequence B: b1 -- b2 -- b3 (root-commit)
git log --graph --oneline
* a1
* a2
* a3
* b1
* b2
* b3
In a GUI tool, the root-commit of each series would stand out on the graph.
This modification changes the commit char to a different symbol ('o'), so
users
of the command-line graph tool can easily identify root-commits and make sense
of where each series is limited to.
git log --graph --oneline
* a1
* a2
o a3
* b1
* b2
o b3
The 'o' character was chosen because it is the same character used in rev-list
to mark root commits.
This patch is similar than the one provided by Milton Soares Filho in
1382734287.31768.1.git.send.email.milton.soares.fi...@gmail.com but was
implemented independently and uses the 'o' character instead of 'x'.
Other solutions were discarded for those reasons:
* line delimiters: we want to keep one commit per line
* tree indentation: it makes little sense with commit trees without
common history, and is more complicated to implement
Signed-off-by: Antoine Beaupré anar...@koumbit.org
---
revision.c | 8 ++--
t/t4202-log.sh | 10 +-
t/t6016-rev-list-graph-simplify-history.sh | 14 +++---
3 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/revision.c b/revision.c
index 75dda92..5f21e24 100644
--- a/revision.c
+++ b/revision.c
@@ -3246,8 +3246,12 @@ char *get_revision_mark(const struct rev_info *revs,
const struct commit *commit
return ;
else
return ;
- } else if (revs-graph)
- return *;
+ } else if (revs-graph) {
+ if (commit-parents)
+ return *;
+ else
+ return o;
+ }
else if (revs-cherry_mark)
return +;
return ;
diff --git a/t/t4202-log.sh b/t/t4202-log.sh
index 99ab7ca..d11876e 100755
--- a/t/t4202-log.sh
+++ b/t/t4202-log.sh
@@ -244,7 +244,7 @@ cat expect EOF
* fourth
* third
* second
-* initial
+o initial
EOF
test_expect_success 'simple log --graph' '
@@ -272,7 +272,7 @@ cat expect \EOF
|/
* third
* second
-* initial
+o initial
EOF
test_expect_success 'log --graph with merge' '
@@ -338,7 +338,7 @@ cat expect \EOF
|
| second
|
-* commit tags/side-1~3
+o commit tags/side-1~3
Author: A U Thor aut...@example.com
initial
@@ -410,7 +410,7 @@ cat expect \EOF
* | third
|/
* second
-* initial
+o initial
EOF
test_expect_success 'log --graph with merge' '
@@ -799,7 +799,7 @@ cat expect \EOF
| -one
| +ichi
|
-* commit COMMIT_OBJECT_NAME
+o commit COMMIT_OBJECT_NAME
Author: A U Thor aut...@example.com
initial
diff --git a/t/t6016-rev-list-graph-simplify-history.sh
b/t/t6016-rev-list-graph-simplify-history.sh
index f7181d1..74b6fc3 100755
--- a/t/t6016-rev-list-graph-simplify-history.sh
+++ b/t/t6016-rev-list-graph-simplify-history.sh
@@ -81,7 +81,7 @@ test_expect_success '--graph --all' '
echo |/| expected
echo * | $A2 expected
echo |/expected
- echo * $A1 expected
+ echo o $A1 expected
git rev-list --graph --all actual
test_cmp expected actual
'
@@ -111,7 +111,7 @@ test_expect_success '--graph --simplify-by-decoration' '
echo |/| expected
echo * | $A2 expected
echo |/expected
- echo * $A1 expected
+ echo o $A1 expected
git rev-list --graph --all --simplify-by-decoration actual
test_cmp expected actual
'
@@ -139,7 +139,7 @@ test_expect_success '--graph --simplify-by-decoration
prune branch B' '
echo * | $A3 expected
echo |/expected
echo * $A2 expected
- echo * $A1 expected
+ echo o $A1 expected
git rev-list --graph --simplify-by-decoration --all actual
test_cmp expected actual
'
@@ -156,7 +156,7 @@ test_expect_success '--graph --full-history -- bar.txt' '
echo | |/expected
echo * | $A3 expected
echo |/expected
- echo * $A2 expected
+ echo o $A2 expected
git rev-list --graph --full-history --all -- bar.txt actual
test_cmp expected actual
'
@@ -170,7 +170,7 @@ test_expect_success '--graph --full-history
--simplify-merges -- bar.txt' '
echo * | $A5 expected
echo * | $A3 expected
echo |/
Re: [PATCH] graph.c: visual difference on subsequent series
Antoine Beaupré anar...@koumbit.org writes: Any reason why this patch wasn't included / reviewed? ... This patch is similar than the one provided by Milton Soares Filho in 1382734287.31768.1.git.send.email.milton.soares.fi...@gmail.com but was implemented independently and uses the 'o' character instead of 'x'. The reason why Milton's patch was not taken after discussion [*1*] was not because its implementation was poor, but its design was not good. By overriding '*' '' or '' with x, it made it impossible to distinguish a root on the left side branch and a root on the right side branch. Is the design of your independent implementation the same except that 'o' is used instead of 'x'? Independent implementation does not make the same design magically better, if that is the case ;-) If the design is different, please explain how your patch solves the issue with Milton's design in your log message. For example, you could use the column arrangement to solve it, e.g. History sequence A: a1 -- a2 -- a3 (root-commit) History sequence B: b1 -- b2 -- b3 (root-commit) $ git log --graph --oneline A B * a1 * a2 * a3 * b1 * b2 * b3 $ git log --graph --oneline --left-right A...B a1 a2 a3 b1 b2 b3 I am not saying that the above would be the only way to do so; there may be other ways to solve the issue. [Reference] *1* http://thread.gmane.org/gmane.comp.version-control.git/236708/focus=236843 -- 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] tests: Remove some direct access to .git/logs
David Turner dtur...@twopensource.com writes:
-: a repository with working tree always has reflog these days...
-: .git/logs/refs/heads/master
+rm -f .git/logs/refs/heads/master
This looks quite different from how other tests are updated (which
looked a lot more sensible). The original has the effect of (1)
ensuring that the log exists/is enabled for 'master' branch and (2)
that log is emptied. The updated has a quite different effect,
but only when you are using filesystem based backend.
test_expect_success \
create $m (logged by touch) \
'GIT_COMMITTER_DATE=2005-05-26 23:30 \
- git update-ref HEAD '$A' -m Initial Creation
+ git update-ref --create-reflog HEAD '$A' -m Initial Creation
test '$A' = $(cat .git/'$m')'
And this update compensates for the earlier remove 'master' reflog
(where it should have been ensure creation and empty it) by
creating, but it is unclear what would happen when we start using
different ref backends. Earlier we did not remove reflog from the
backend, and we say create here---it would hopefully not error
out, but it does not quite feel right. Perhaps create and
immediately prune all instead? That feels like more in line with
the way the other change in this patch do things.
- test_line_count = 4 .git/logs/refs/heads/master
+ git reflog refs/heads/master output
+ test_line_count = 4 output
'
These all look sensible.
diff --git a/t/t1411-reflog-show.sh b/t/t1411-reflog-show.sh
index 6f47c0d..d568b35 100755
--- a/t/t1411-reflog-show.sh
+++ b/t/t1411-reflog-show.sh
@@ -138,7 +138,7 @@ test_expect_success '--date magic does not override
explicit @{0} syntax' '
: expect
test_expect_success 'empty reflog file' '
git branch empty
- : .git/logs/refs/heads/empty
+ git reflog expire --expire=all refs/heads/empty
This one is what I was talking about in the earlier part of this
message. This looks very sensible.
test_expect_success 'fails silently when using -q with deleted reflogs' '
ref=$(git rev-parse HEAD)
- : .git/logs/refs/test
- git update-ref -m message for refs/test refs/test $ref
+ git update-ref --create-reflog -m message for refs/test refs/test
$ref
I cannot tell without enough pre-context, but I assume that we know
there is no reflog for refs/test when this test piece starts---in
which case this change looks sensible.
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 467e6c1..dc76754 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -961,13 +961,13 @@ test_expect_success 'rebase -i produces readable
reflog' '
set_fake_editor
git rebase -i --onto I F branch-reflog-test
cat expect -\EOF
- rebase -i (start): checkout I
- rebase -i (pick): G
- rebase -i (pick): H
rebase -i (finish): returning to refs/heads/branch-reflog-test
+ rebase -i (pick): H
+ rebase -i (pick): G
+ rebase -i (start): checkout I
EOF
;-)
- tail -n 4 .git/logs/HEAD |
- sed -e s/.*// actual
+ git reflog HEAD -n4 |
This may happen to work but teaches a bad habit to readers. Always
order your command line by starting with dashed-options, then refs
and then pathspecs.
diff --git a/t/t7509-commit.sh b/t/t7509-commit.sh
index 9ac7940..db9774e 100755
--- a/t/t7509-commit.sh
+++ b/t/t7509-commit.sh
@@ -90,22 +90,10 @@ sha1_file() {
remove_object() {
rm -f $(sha1_file $*)
}
-no_reflog() {
- cp .git/config .git/config.saved
- echo [core] logallrefupdates = false .git/config
- test_when_finished mv -f .git/config.saved .git/config
-
- if test -e .git/logs
- then
- mv .git/logs .
- test_when_finished mv logs .git/
- fi
-}
test_expect_success '--amend option with empty author' '
git cat-file commit Initial tmp
sed s/author [^]* /author / tmp empty-author
- no_reflog
sha=$(git hash-object -t commit -w empty-author)
test_when_finished remove_object $sha
git checkout $sha
@@ -119,7 +107,6 @@ test_expect_success '--amend option with empty author' '
test_expect_success '--amend option with missing author' '
git cat-file commit Initial tmp
sed s/author [^]* /author / tmp malformed
- no_reflog
sha=$(git hash-object -t commit -w malformed)
test_when_finished remove_object $sha
git checkout $sha
I can understand that .git/logs/ cannot be relied upon when you move
your ref backend out of filesystem, but that does not quite explain
why this change makes sense. Puzzled...
--
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 branch command is incompatible with bash
Am 27.07.2015 um 14:12 schrieb Anatol Rudolph:
When using the git branch command, git uses a '*' to denote the current
branch. Therefore, in bash this:
$ branchName=$(git branch -q)
$ echo $branchName
produces a directory listing, because the '*' is interpreded by the
shell.
Of course. You would write the last line as
echo $branchName
These are shell fundamentals.
While an (unwieldly) workaround exists:
$ branchName=$(git symbolic-ref -q HEAD)
$ branchName=${branch##refs/heads/}
If you want to do that in a script, this is not a work-around, but it is
how you should do it. But you may want to use option --short to save the
second line.
it would still be nice, if there were a --current flag, that returned
only the current branch name, omitting the star:
$ branchName=$(git branch --current -q)
$ echo $branchName
master
Try
branchName=$(git rev-parse --abbrev-ref HEAD)
-- Hannes
--
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: [ANNOUNCE] Git v2.5.0
On Mon, Jul 27, 2015 at 10:47 PM, Junio C Hamano gits...@pobox.com wrote: The latest feature release Git v2.5.0 is now available at the usual places. It is comprised of 583 non-merge commits since v2.4.0, contributed by 70 people, 21 of which are new faces. ... Git 2.5 Release Notes = Updates since v2.4 -- UI, Workflows Features ... * A replacement for contrib/workdir/git-new-workdir that does not rely on symbolic links and make sharing of objects and refs safer by making the borrowee and borrowers aware of each other. Consider this as still an experimental feature; its UI is still likely to change. It might be helpful to list what the replacement actually is in this entry. -- Mikael Magnusson -- 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
[ANNOUNCE] Git v2.5.0
The latest feature release Git v2.5.0 is now available at the
usual places. It is comprised of 583 non-merge commits since
v2.4.0, contributed by 70 people, 21 of which are new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repositories all have a copy of the 'v2.5.0'
tag and the 'master' branch that the tag points at:
url = https://kernel.googlesource.com/pub/scm/git/git
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
New contributors whose contributions weren't in v2.4.0 are as follows.
Welcome to the Git development community!
Allen Hubbe, Ariel Faigon, Blair Holloway, Christian Neukirchen,
Danny Lin, Enrique Tobis, Frans Klaver, Fredrik Medley, Joe
Cridge, Lars Kellogg-Stedman, Lawrence Siebert, Lex Spoon, Luke
Mewburn, Miguel Torroja, Mike Edgar, Ossi Herrala, Panagiotis
Astithas, Quentin Neill, Remi Lespinet, Sébastien Guimmara,
and Thomas Schneider.
Returning contributors who helped this release are as follows.
Thanks for your continued support.
Alexander Shopov, Alex Henrie, brian m. carlson, Carlos Martín
Nieto, Charles Bailey, Clemens Buchacher, David Aguilar,
David Turner, Dennis Kaarsemaker, Dimitriy Ryazantcev, Elia
Pinto, Eric Sunshine, Fredrik Gustafsson, Jean-Noel Avila, Jeff
King, Jiang Xin, Jim Hill, Johannes Schindelin, Johannes Sixt,
Jonathan Nieder, Junio C Hamano, Karsten Blees, Karthik Nayak,
Luke Diamand, Matthieu Moy, Max Kirillov, Michael Coleman,
Michael Haggerty, Michael J Gruber, Mike Hommey, Nguyễn
Thái Ngọc Duy, Patrick Steinhardt, Paul Tan, Peter Krefting,
Phil Hord, Phillip Sz, Ralf Thielow, Ramsay Allan Jones, René
Scharfe, Richard Hansen, Sebastian Schuberth, Stefan Beller,
SZEDER Gábor, Thomas Braun, Thomas Gummerer, Tony Finch,
Torsten Bögershausen, Trần Ngọc Quân, and Vitor Antunes.
Git 2.5 Release Notes
=
Updates since v2.4
--
UI, Workflows Features
* The bash completion script (in contrib/) learned a few options that
git revert takes.
* Whitespace breakages in deleted and context lines can also be
painted in the output of git diff and friends with the new
--ws-error-highlight option.
* List of commands shown by git help are grouped along the workflow
elements to help early learners.
* git p4 now detects the filetype (e.g. binary) correctly even when
the files are opened exclusively.
* git p4 attempts to better handle branches in Perforce.
* git p4 learned --changes-block-size n to read the changes in
chunks from Perforce, instead of making one call to p4 changes
that may trigger too many rows scanned error from Perforce.
* More workaround for Perforce's row number limit in git p4.
* Unlike $EDITOR and $GIT_EDITOR that can hold the path to the
command and initial options (e.g. /path/to/emacs -nw), 'git p4'
did not let the shell interpolate the contents of the environment
variable that name the editor $P4EDITOR (and $EDITOR, too).
This release makes it in line with the rest of Git, as well as with
Perforce.
* A new short-hand branch@{push} denotes the remote-tracking branch
that tracks the branch at the remote the branch would be pushed
to.
* git show-branch --topics HEAD (with no other arguments) did not
do anything interesting. Instead, contrast the given revision
against all the local branches by default.
* A replacement for contrib/workdir/git-new-workdir that does not
rely on symbolic links and make sharing of objects and refs safer
by making the borrowee and borrowers aware of each other.
Consider this as still an experimental feature; its UI is still
likely to change.
* Tweak the sample store backend of the credential helper to honor
XDG configuration file locations when specified.
* A heuristic we use to catch mistyped paths on the command line
git cmd revs pathspec is to make sure that all the non-rev
parameters in the later part of the command line are names of the
files in the working tree, but that means git grep $str -- \*.c
must always be disambiguated with --, because nobody sane will
create a file whose name literally is asterisk-dot-see. Loosen the
heuristic to declare that with a wildcard string the user likely
meant to give us a pathspec.
* git merge FETCH_HEAD learned that the previous git fetch could
be to create an Octopus merge, i.e. recording multiple branches
that are not marked as not-for-merge; this allows us to lose an
old style invocation git merge msg HEAD $commits... in the
implementation of git pull script; the old style syntax can now
be deprecated (but not removed yet).
* Filter scripts were run with
Re: git branch command is incompatible with bash
Johannes Sixt j...@kdbg.org writes: Try branchName=$(git rev-parse --abbrev-ref HEAD) Hmm, interesting. $ git checkout --orphan notyet $ git rev-parse --abbrev-ref HEAD $ git symbolic-ref --short HEAD -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
What's cooking in git.git (Jul 2015, #07; Mon, 27)
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Git 2.5 final was tagged and tarballs were pushed out. Accumulated
fixes also went to a new maintenance release 2.4.7. Let's wait and
see for a few days for any regressions before opening the 'master'
branch for topics that have been waiting in 'next', as usual.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--
[New Topics]
* da/subtree-date-confusion (2015-07-23) 1 commit
- contrib/subtree: ignore log.date configuration
git subtree (in contrib/) depended on git log output to be
stable, which was a no-no. Apply a workaround to force a
particular date format.
Will merge to 'next'.
* db/send-pack-user-signingkey (2015-07-21) 1 commit
- builtin/send-pack.c: respect user.signingkey
The low-level git send-pack did not honor 'user.signingkey'
configuration variable when sending a signed-push.
Will merge to 'next'.
* jk/refspec-parse-wildcard (2015-07-27) 2 commits
- refs: loosen restriction on wildcard * refspecs
- refs: cleanup comments regarding check_refname_component()
Allow an asterisk as a substring (as opposed to the entirety) of
a path component for both side of a refspec, e.g.
refs/heads/o*:refs/remotes/heads/i*.
Will merge to 'next'.
* jx/do-not-crash-receive-pack-wo-head (2015-07-22) 1 commit
- receive-pack: crash when checking with non-exist HEAD
Will merge to 'next'.
* kd/pull-rebase-autostash (2015-07-22) 1 commit
- pull: allow dirty tree when rebase.autostash enabled
(this branch uses pt/pull-builtin; is tangled with pt/am-builtin.)
Teach git pull --rebase to pay attention to rebase.autostash
configuration.
* es/doc-clean-outdated-tools (2015-07-25) 5 commits
- Documentation/git-tools: drop references to defunct tools
- Documentation/git-tools: drop references to defunct tools
- Documentation/git-tools: fix item text formatting
- Documentation/git-tools: improve discoverability of Git wiki
- Documentation/git: drop outdated Cogito reference
Will merge to 'next'.
--
[Stalled]
* jc/clone-bundle (2015-04-30) 1 commit
- repack: optionally create a clone.bundle
Waiting for further work.
Still an early WIP.
* jh/strbuf-read-use-read-in-full (2015-06-01) 1 commit
- strbuf_read(): skip unnecessary strbuf_grow() at eof
Avoid one extra iteration and strbuf_grow() of 8kB in
strbuf_read().
Looked reasonable; perhaps a log message clarification is needed.
Expecting a reroll.
* mg/index-read-error-messages (2015-06-01) 2 commits
- messages: uniform error messages for index write
- show-index: uniform error messages for index read
The tip was RFC.
Expecting a reroll.
* hv/submodule-config (2015-06-15) 4 commits
- do not die on error of parsing fetchrecursesubmodules option
- use new config API for worktree configurations of submodules
- extract functions for submodule config set and lookup
- implement submodule config API for lookup of .gitmodules values
The gitmodules API accessed from the C code learned to cache stuff
lazily.
Needs another reroll? ($gmane/273743).
* jk/log-missing-default-HEAD (2015-06-03) 1 commit
- log: diagnose empty HEAD more clearly
git init empty git -C empty log said bad default revision 'HEAD',
which was found to be a bit confusing to new users.
What's the status of this one?
* bc/object-id (2015-06-17) 10 commits
. remote.c: use struct object_id in many functions
. object-id: use struct object_id in struct object
. remote.c: use struct object_id in ref_newer()
. transport-helper.c: use struct object_id in push_refs_with_export()
. connect.c: use struct object_id in get_remote_heads()
. remote-curl: use struct object_id in parse_fetch()
. fetch-pack: use struct object_id in add_sought_entry_mem()
. object_id: convert struct ref to use object_id.
. sha1_file: introduce has_object_file() helper
. refs: convert some internal functions to use object_id
More transition from unsigned char[40] to struct object_id.
While GSoC and other topics are actively moving existing code
around, this cannot go in; ejected from 'pu'.
* wp/sha1-name-negative-match (2015-06-08) 2 commits
- sha1_name.c: introduce '^{/!-negative pattern}' notation
- test for '!' handling in rev-parse's named commits
Introduce branch^{/!-pattern} notation to name a commit
reachable from branch that does not match the given pattern.
Expecting a reroll.
* mk/utf8-no-iconv-warn (2015-06-08) 1 commit
- utf8.c: print warning about disabled iconv
Warn when a reencoding is requested in a build without iconv
support, as the end user is likely to get an unexpected result. I
think the same level of safety should be added to a build with
iconv
[ANNOUNCE] Git v2.4.7
The latest maintenance release Git v2.4.7 is now available at the usual places. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories all have a copy of the 'v2.4.7' tag and the 'maint' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v2.4.7 Release Notes Fixes since v2.4.6 -- * A minor regression to git fsck in v2.2 era was fixed; it complained about a body-less tag object when it lacked a separator empty line after its header to separate it with a non-existent body. * We used to ask libCURL to use the most secure authentication method available when talking to an HTTP proxy only when we were told to talk to one via configuration variables. We now ask libCURL to always use the most secure authentication method, because the user can tell libCURL to use an HTTP proxy via an environment variable without using configuration variables. * When you say !ENTER while running say git log, you'd confuse yourself in the resulting shell, that may look as if you took control back to the original shell you spawned git log from but that isn't what is happening. To that new shell, we leaked GIT_PAGER_IN_USE environment variable that was meant as a local communication between the original Git and subprocesses that was spawned by it after we launched the pager, which caused many interesting things to happen, e.g. git diff | cat still paints its output in color by default. Stop leaking that environment variable to the pager's half of the fork; we only need it on Git side when we spawn the pager. * Avoid possible ssize_t to int truncation. * git config failed to update the configuration file when the underlying filesystem is incapable of renaming a file that is still open. * A minor bugfix when pack bitmap is used with rev-list --count. * An ancient test framework enhancement to allow color was not entirely correct; this makes it work even when tput needs to read from the ~/.terminfo under the user's real HOME directory. * Fix a small bug in our use of umask() return value. * git rebase did not exit with failure when format-patch it invoked failed for whatever reason. * Disable have we lost a race with competing repack? check while receiving a huge object transfer that runs index-pack. Also contains typofixes, documentation updates and trivial code clean-ups. Changes since v2.4.6 are as follows: Clemens Buchacher (1): rebase: return non-zero error code if format-patch fails Enrique Tobis (1): http: always use any proxy auth method available Jeff King (4): index-pack: avoid excessive re-reading of pack directory docs: clarify that --encoding can produce invalid sequences rev-list: disable --use-bitmap-index when pruning commits check_and_freshen_file: fix reversed success-check Junio C Hamano (3): fsck: it is OK for a tag and a commit to lack the body pager: do not leak GIT_PAGER_IN_USE to the pager Git 2.4.7 Karsten Blees (1): config.c: fix writing config files on Windows network shares Lawrence Siebert (1): rev-list: add --count to usage guide Matthieu Moy (2): Documentation/branch: document -d --force and -m --force Documentation/branch: document -M and -D in terms of --force Michael Haggerty (1): strbuf: strbuf_read_file() should return ssize_t Richard Hansen (2): Revert test-lib.sh: do tests for color support after changing HOME test-lib.sh: fix color support when tput needs ~/.terminfo Torsten Bögershausen (1): git-checkout.txt: document git checkout pathspec better -- 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: [ANNOUNCE] Git v2.5.0
Mikael Magnusson mika...@gmail.com writes: On Mon, Jul 27, 2015 at 10:47 PM, Junio C Hamano gits...@pobox.com wrote: The latest feature release Git v2.5.0 is now available at the usual places. It is comprised of 583 non-merge commits since v2.4.0, contributed by 70 people, 21 of which are new faces. ... Git 2.5 Release Notes = Updates since v2.4 -- UI, Workflows Features ... * A replacement for contrib/workdir/git-new-workdir that does not rely on symbolic links and make sharing of objects and refs safer by making the borrowee and borrowers aware of each other. Consider this as still an experimental feature; its UI is still likely to change. It might be helpful to list what the replacement actually is in this entry. Did you read Its UI is still likely to change ;-)? It earlier was parked at checkout --to, it is parked at worktree add today, but who knows where it will end up. It would be harmful to say that here as if we are already encouraging its use. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] pseudorefs
David Turner dtur...@twopensource.com writes: This version of the pseudorefs patch series is much simpler. Instead of forbidding update_ref and delete_ref from updating pseudorefs, these functions now just special-case pseudorefs. So we can use update_ref to write pseudorefs in a rebase and sequencer, and we don't need to rewrite so much code. The resulting update_ref/delete_ref look quite straight-forward, too. Thanks. In addition, I made typo fixes suggested by Eric Sunshine and Philip Oakley. -- 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 1/2] t/t7509: remove unnecessary manipulation of reflog
Remove unnecessary reflog manipulation. The test does not rely in any
way on this reflog manipulation, and the case that the test
exercises is unrelated to reflogs.
Signed-off-by: David Turner dtur...@twopensource.com
---
This version of the patch series addresses Junio's comments on v1.
---
t/t7509-commit.sh | 13 -
1 file changed, 13 deletions(-)
diff --git a/t/t7509-commit.sh b/t/t7509-commit.sh
index 9ac7940..db9774e 100755
--- a/t/t7509-commit.sh
+++ b/t/t7509-commit.sh
@@ -90,22 +90,10 @@ sha1_file() {
remove_object() {
rm -f $(sha1_file $*)
}
-no_reflog() {
- cp .git/config .git/config.saved
- echo [core] logallrefupdates = false .git/config
- test_when_finished mv -f .git/config.saved .git/config
-
- if test -e .git/logs
- then
- mv .git/logs .
- test_when_finished mv logs .git/
- fi
-}
test_expect_success '--amend option with empty author' '
git cat-file commit Initial tmp
sed s/author [^]* /author / tmp empty-author
- no_reflog
sha=$(git hash-object -t commit -w empty-author)
test_when_finished remove_object $sha
git checkout $sha
@@ -119,7 +107,6 @@ test_expect_success '--amend option with empty author' '
test_expect_success '--amend option with missing author' '
git cat-file commit Initial tmp
sed s/author [^]* /author / tmp malformed
- no_reflog
sha=$(git hash-object -t commit -w malformed)
test_when_finished remove_object $sha
git checkout $sha
--
2.0.4.315.gad8727a-twtrsrc
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Log messages beginning # and git rebase -i
On Mon, Jul 27, 2015 at 7:38 AM, Ed Avis e...@waniasset.com wrote: git commit will happily let you specify log messages beginning with #. But then on git rebase -i, when squashing some commits, the editing for the combined log message treats lines beginning with # as comments. This means that if you are not careful the commit message can get lost on rebasing. I suggest that git rebase should add an extra space at the start of existing log message lines which begin with #. That is a bit of a kludge but it is better than losing them because they got mixed up with comments. 'git rebase --interactive' respects the core.commentChar configuration variable, which you can set to some value other than '#'. -- 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] tests: Remove some direct access to .git/logs
On Mon, 2015-07-27 at 14:47 -0700, Junio C Hamano wrote:
David Turner dtur...@twopensource.com writes:
-: a repository with working tree always has reflog these days...
-: .git/logs/refs/heads/master
+rm -f .git/logs/refs/heads/master
This looks quite different from how other tests are updated (which
looked a lot more sensible). The original has the effect of (1)
ensuring that the log exists/is enabled for 'master' branch and (2)
that log is emptied. The updated has a quite different effect,
but only when you are using filesystem based backend.
Yes, this is one of the areas where we need to do more work for
alternate backends -- for instance, we could provide a git reflog
remove command to replace that rm. As the commit message notes, this
patch is a subset of what's necessary for multiple backends.
There are a number of other tests that e.g. rm -r .git/logs, which we
would also need to change for alternate backends.
test_expect_success \
create $m (logged by touch) \
'GIT_COMMITTER_DATE=2005-05-26 23:30 \
-git update-ref HEAD '$A' -m Initial Creation
+git update-ref --create-reflog HEAD '$A' -m Initial Creation
test '$A' = $(cat .git/'$m')'
And this update compensates for the earlier remove 'master' reflog
(where it should have been ensure creation and empty it) by
creating, but it is unclear what would happen when we start using
different ref backends. Earlier we did not remove reflog from the
backend, and we say create here---it would hopefully not error
out, but it does not quite feel right. Perhaps create and
immediately prune all instead? That feels like more in line with
the way the other change in this patch do things.
If we create and immediately prune all, we'll lose the initial creation
entry, which we presumably want to test.
test_expect_success 'fails silently when using -q with deleted reflogs' '
ref=$(git rev-parse HEAD)
- : .git/logs/refs/test
- git update-ref -m message for refs/test refs/test $ref
+ git update-ref --create-reflog -m message for refs/test refs/test
$ref
I cannot tell without enough pre-context, but I assume that we know
there is no reflog for refs/test when this test piece starts---in
which case this change looks sensible.
Yes, that is correct.
- tail -n 4 .git/logs/HEAD |
- sed -e s/.*// actual
+ git reflog HEAD -n4 |
This may happen to work but teaches a bad habit to readers. Always
order your command line by starting with dashed-options, then refs
and then pathspecs.
Will fix on reroll.
diff --git a/t/t7509-commit.sh b/t/t7509-commit.sh
index 9ac7940..db9774e 100755
--- a/t/t7509-commit.sh
+++ b/t/t7509-commit.sh
@@ -90,22 +90,10 @@ sha1_file() {
remove_object() {
rm -f $(sha1_file $*)
}
-no_reflog() {
- cp .git/config .git/config.saved
- echo [core] logallrefupdates = false .git/config
- test_when_finished mv -f .git/config.saved .git/config
-
- if test -e .git/logs
- then
- mv .git/logs .
- test_when_finished mv logs .git/
- fi
-}
test_expect_success '--amend option with empty author' '
git cat-file commit Initial tmp
sed s/author [^]* /author / tmp empty-author
- no_reflog
sha=$(git hash-object -t commit -w empty-author)
test_when_finished remove_object $sha
git checkout $sha
@@ -119,7 +107,6 @@ test_expect_success '--amend option with empty author' '
test_expect_success '--amend option with missing author' '
git cat-file commit Initial tmp
sed s/author [^]* /author / tmp malformed
- no_reflog
sha=$(git hash-object -t commit -w malformed)
test_when_finished remove_object $sha
git checkout $sha
I can understand that .git/logs/ cannot be relied upon when you move
your ref backend out of filesystem, but that does not quite explain
why this change makes sense. Puzzled...
It turns out that the removed portion of the test is totally
unnecessary; the tests are completely unrelated to reflogs.
On the reroll, I'll split this into a separate patch with its own
explanation.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-add-interactive: edit current file in editor
Adds a new option 'o' to the 'add -p' command that lets you open and edit the
current file.
The existing 'e' mode is used to manually edit the hunk. The new 'o' option
allows you to open and edit the file without having to quit the loop. The hunks
are updated when the editing is done, and the user will be able to review the
updated hunks. Without this option you would have to quit the loop, edit the
file, and execute 'add -p filename' again.
I would appreciate it if you could let me know what you think about this
option. I will write more tests if there is any interest at all.
Thank you. :)
---
Documentation/git-add.txt | 1 +
git-add--interactive.perl | 11 ++-
t/t3701-add-interactive.sh | 6 ++
3 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index fe5282f..6752eb0 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -312,6 +312,7 @@ patch::
K - leave this hunk undecided, see previous hunk
s - split the current hunk into smaller hunks
e - manually edit the current hunk
+ o - open this file in editor
? - print help
+
After deciding the fate for all hunks, if there is any hunk
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 77876d4..a44f3b3 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -1175,6 +1175,7 @@ k - leave this hunk undecided, see previous undecided hunk
K - leave this hunk undecided, see previous hunk
s - split the current hunk into smaller hunks
e - manually edit the current hunk
+o - open this file in editor
? - print help
EOF
}
@@ -1359,7 +1360,7 @@ sub patch_update_file {
$hunk[$ix]{TYPE} eq 'deletion' ? ' deletion' :
' this hunk'),
$patch_mode_flavour{TARGET},
- [y,n,q,a,d,/$other,?]? ;
+ [y,n,q,a,d,o,/$other,?]? ;
my $line = prompt_single_character;
last unless defined $line;
if ($line) {
@@ -1378,6 +1379,14 @@ sub patch_update_file {
}
next;
}
+ elsif ($line =~ /^o/) {
+ chomp(my $editor = run_cmd_pipe(qw(git var
GIT_EDITOR)));
+ system('sh', '-c', $editor.' $@', $editor,
$path);
+ ($head, @hunk) = parse_diff($path);
+ $num = scalar @hunk;
+ $ix = 0;
+ next;
+ }
elsif ($other =~ /g/ $line =~ /^g(.*)/) {
my $response = $1;
my $no = $ix 10 ? $ix - 10 : 0;
diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
index deae948..e5dd1c6 100755
--- a/t/t3701-add-interactive.sh
+++ b/t/t3701-add-interactive.sh
@@ -98,6 +98,12 @@ test_expect_success 'dummy edit works' '
test_cmp expected diff
'
+test_expect_success 'dummy open works' '
+ (echo o; echo a) | git add -p
+ git diff diff
+ test_cmp expected diff
+'
+
test_expect_success 'setup patch' '
cat patch EOF
@@ -1,1 +1,4 @@
--
2.5.0.rc3.2.g6f9504c.dirty
--
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: Log messages beginning # and git rebase -i
On Tue, Jul 28, 2015 at 6:25 AM, Eric Sunshine sunsh...@sunshineco.com wrote: On Mon, Jul 27, 2015 at 7:38 AM, Ed Avis e...@waniasset.com wrote: git commit will happily let you specify log messages beginning with #. But then on git rebase -i, when squashing some commits, the editing for the combined log message treats lines beginning with # as comments. This means that if you are not careful the commit message can get lost on rebasing. I suggest that git rebase should add an extra space at the start of existing log message lines which begin with #. That is a bit of a kludge but it is better than losing them because they got mixed up with comments. 'git rebase --interactive' respects the core.commentChar configuration variable, which you can set to some value other than '#'. Yeah. I recommend setting it to 'auto' so it will pick an unused character as separator (most of the time, don't push it too hard) -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] pseudorefs: create and use pseudoref update and delete functions
On Mon, 2015-07-27 at 16:08 -0400, David Turner wrote:
+ if (is_pseudoref(refname) 0) {
Whoa, that's not right. Will fix that in the next re-roll.
--
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 01/10] ref-filter: add option to align atoms to the left
On Mon, Jul 27, 2015 at 2:39 PM, Jacob Keller jacob.kel...@gmail.com wrote:
On Sun, Jul 26, 2015 at 5:39 PM, Duy Nguyen pclo...@gmail.com wrote:
On Sun, Jul 26, 2015 at 11:08 AM, Eric Sunshine sunsh...@sunshineco.com
wrote:
You can generate an interdiff with git diff branchname-v4
branchname-v5, for instance.
Off topic. But what stops me from doing this often is it creates a big
mess in git tag -l. Do we have an option to hide away some
insignificant: tags? reflog might be an option if we have something
like foo@{/v2} to quickly retrieve the reflog entry whose message
contains v2.
You can normally find the previous commit via the reflog. Various
changes to the settings can make the reflog be maintained for longer
if you have longer lived patch series. That's how I would suggest it,
rather than branches, as I tend not to keep old versions around on
separate tags or branches.
The problem with foo@{/v2} is that people don't always keep values
inside the message it self, but maybe foo@{/pattern} would be a
useful extension?
reflog message is different from commit message. I was referring
to the first one (which is out of user control), perhaps you were
referring to the second one? I don't expect people to add v2 to
manually. If we have something like foo@{/v2} then we can teach
send-email (or format-patch) to add a reflog entry with v2 in it.
But maybe we're abusing reflog..
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Indenting lines starting with die in shell after ||
Hi Christian, On 2015-07-27 11:20, Christian Couder wrote: It looks like we are very inconsistent in shell scripts about indenting lines starting with die after a line that ends with ||, like: quite long command || die command failed For example in git-rebase--interactive.sh, there is often, but not always, an extra tab before the die. That is most likely my fault: I used to add that extra tab. It appears to me as if the convention in Git (and in my current coding style) is not to add an extra tab. Ciao, Dscho -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-add-interactive: edit current file in editor
On Mon, Jul 27, 2015 at 4:41 PM, Sina Siadat sia...@gmail.com wrote: Adds a new option 'o' to the 'add -p' command that lets you open and edit the current file. The existing 'e' mode is used to manually edit the hunk. The new 'o' option allows you to open and edit the file without having to quit the loop. The hunks are updated when the editing is done, and the user will be able to review the updated hunks. Without this option you would have to quit the loop, edit the file, and execute 'add -p filename' again. I would appreciate it if you could let me know what you think about this option. I will write more tests if there is any interest at all. Thank you. :) Absolutely want and would use this change every day. My standard model of commit flow is: hack commit hack commit hack commit rest head add -i ; commit add -i ; commit and sometimes I end up with code that I need to actually change, not just edit diff hunks for, but change in the final file. This would make my flow way easier, especially as I could manage hunks while editing files. 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: git am and then git am -3 regression?
Jeff King p...@peff.net writes: Yeah, having to worry about two implementations of git am is a real pain. If we are close on merging the builtin version, it makes sense to me to hold off on the am.threeway feature until that is merged. Trying to fix the ordering of the script that is going away isn't a good use of anybody's time. So, the best option seems to be: 1) Revert d96a275 (git-am: add am.threeWay config variable, 2015-06-04) 2) Include the C port of d96a275 together with tests and docs verbatim from d96a275 into Paul's series. Actually, doing 1) is probably a good idea anyway, there's no reason to hold the release for such minor feature. -- 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: git am and then git am -3 regression?
On Mon, Jul 27, 2015 at 10:09:43AM +0200, Matthieu Moy wrote: Yeah, having to worry about two implementations of git am is a real pain. If we are close on merging the builtin version, it makes sense to me to hold off on the am.threeway feature until that is merged. Trying to fix the ordering of the script that is going away isn't a good use of anybody's time. So, the best option seems to be: 1) Revert d96a275 (git-am: add am.threeWay config variable, 2015-06-04) 2) Include the C port of d96a275 together with tests and docs verbatim from d96a275 into Paul's series. Actually, doing 1) is probably a good idea anyway, there's no reason to hold the release for such minor feature. I think step 1 is done already for v2.5.0, in 15dc5b5. We _could_ fix it in the script version for the upcoming cycle, but if we are merging builtin-am during this cycle, I do not see the point. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 01/11] ref-filter: introduce 'ref_formatting_state'
Introduce 'ref_formatting' structure to hold values of pseudo atoms
which help only in formatting. This will eventually be used by atoms
like `color` and the `padright` atom which will be introduced in a
later patch.
Helped-by: Junio C Hamano gits...@pobox.com
Mentored-by: Christian Couder christian.cou...@gmail.com
Mentored-by: Matthieu Moy matthieu@grenoble-inp.fr
Signed-off-by: Karthik Nayak karthik@gmail.com
---
ref-filter.c | 46 +++---
ref-filter.h | 5 +
2 files changed, 36 insertions(+), 15 deletions(-)
diff --git a/ref-filter.c b/ref-filter.c
index 7561727..a3625e8 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -10,6 +10,8 @@
#include quote.h
#include ref-filter.h
#include revision.h
+#include utf8.h
+#include git-compat-util.h
typedef enum { FIELD_STR, FIELD_ULONG, FIELD_TIME } cmp_type;
@@ -620,7 +622,7 @@ static void populate_value(struct ref_array_item *ref)
const char *name = used_atom[i];
struct atom_value *v = ref-value[i];
int deref = 0;
- const char *refname;
+ const char *refname = NULL;
const char *formatp;
struct branch *branch = NULL;
@@ -1190,30 +1192,40 @@ void ref_array_sort(struct ref_sorting *sorting, struct
ref_array *array)
qsort(array-items, array-nr, sizeof(struct ref_array_item *),
compare_refs);
}
-static void print_value(struct atom_value *v, int quote_style)
+static void ref_formatting(struct ref_formatting_state *state,
+ struct atom_value *v, struct strbuf *value)
{
- struct strbuf sb = STRBUF_INIT;
- switch (quote_style) {
+ strbuf_addf(value, %s, v-s);
+}
+
+static void print_value(struct ref_formatting_state *state, struct atom_value
*v)
+{
+ struct strbuf value = STRBUF_INIT;
+ struct strbuf formatted = STRBUF_INIT;
+
+ ref_formatting(state, v, value);
+
+ switch (state-quote_style) {
case QUOTE_NONE:
- fputs(v-s, stdout);
+ fputs(value.buf, stdout);
break;
case QUOTE_SHELL:
- sq_quote_buf(sb, v-s);
+ sq_quote_buf(formatted, value.buf);
break;
case QUOTE_PERL:
- perl_quote_buf(sb, v-s);
+ perl_quote_buf(formatted, value.buf);
break;
case QUOTE_PYTHON:
- python_quote_buf(sb, v-s);
+ python_quote_buf(formatted, value.buf);
break;
case QUOTE_TCL:
- tcl_quote_buf(sb, v-s);
+ tcl_quote_buf(formatted, value.buf);
break;
}
- if (quote_style != QUOTE_NONE) {
- fputs(sb.buf, stdout);
- strbuf_release(sb);
- }
+ if (state-quote_style != QUOTE_NONE)
+ fputs(formatted.buf, stdout);
+ strbuf_release(formatted);
+ strbuf_release(value);
}
static int hex1(char ch)
@@ -1257,6 +1269,10 @@ static void emit(const char *cp, const char *ep)
void show_ref_array_item(struct ref_array_item *info, const char *format, int
quote_style)
{
const char *cp, *sp, *ep;
+ struct ref_formatting_state state;
+
+ memset(state, 0, sizeof(state));
+ state.quote_style = quote_style;
for (cp = format; *cp (sp = find_next(cp)); cp = ep + 1) {
struct atom_value *atomv;
@@ -1265,7 +1281,7 @@ void show_ref_array_item(struct ref_array_item *info,
const char *format, int qu
if (cp sp)
emit(cp, sp);
get_ref_atom_value(info, parse_ref_filter_atom(sp + 2, ep),
atomv);
- print_value(atomv, quote_style);
+ print_value(state, atomv);
}
if (*cp) {
sp = cp + strlen(cp);
@@ -1278,7 +1294,7 @@ void show_ref_array_item(struct ref_array_item *info,
const char *format, int qu
if (color_parse(reset, color) 0)
die(BUG: couldn't parse 'reset' as a color);
resetv.s = color;
- print_value(resetv, quote_style);
+ print_value(state, resetv);
}
putchar('\n');
}
diff --git a/ref-filter.h b/ref-filter.h
index 6bf27d8..f24e3ef 100644
--- a/ref-filter.h
+++ b/ref-filter.h
@@ -19,6 +19,11 @@
struct atom_value {
const char *s;
unsigned long ul; /* used for sorting when not FIELD_STR */
+ unsigned int pseudo_atom : 1; /* atoms which aren't placeholders for
ref attributes */
+};
+
+struct ref_formatting_state {
+ int quote_style;
};
struct ref_sorting {
--
2.4.6
--
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 05/11] ref-filter: support printing N lines from tag annotation
From: Karthik Nayak karthik@gmail.com
In 'tag.c' we can print N lines from the annotation of the tag using
the '-nnum' option. Copy code from 'tag.c' to 'ref-filter' and
modify 'ref-filter' to support printing of N lines from the annotation
of tags.
Mentored-by: Christian Couder christian.cou...@gmail.com
Mentored-by: Matthieu Moy matthieu@grenoble-inp.fr
Signed-off-by: Karthik Nayak karthik@gmail.com
---
builtin/for-each-ref.c | 2 +-
builtin/tag.c | 4
ref-filter.c | 51 +-
ref-filter.h | 9 +++--
4 files changed, 62 insertions(+), 4 deletions(-)
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index 40f343b..e4a4f8a 100644
--- a/builtin/for-each-ref.c
+++ b/builtin/for-each-ref.c
@@ -74,7 +74,7 @@ int cmd_for_each_ref(int argc, const char **argv, const char
*prefix)
if (!maxcount || array.nr maxcount)
maxcount = array.nr;
for (i = 0; i maxcount; i++)
- show_ref_array_item(array.items[i], format, quote_style);
+ show_ref_array_item(array.items[i], format, quote_style, 0);
ref_array_clear(array);
return 0;
}
diff --git a/builtin/tag.c b/builtin/tag.c
index 471d6b1..0fc7557 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -185,6 +185,10 @@ static enum contains_result contains(struct commit
*candidate,
return contains_test(candidate, want);
}
+/*
+ * Currently duplicated in ref-filter, will eventually be removed as
+ * we port tag.c to use ref-filter APIs.
+ */
static void show_tag_lines(const struct object_id *oid, int lines)
{
int i;
diff --git a/ref-filter.c b/ref-filter.c
index 6e01b44..1605252 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -1306,7 +1306,51 @@ static void apply_pseudo_state(struct
ref_formatting_state *state,
state-pad_to_right = v-ul;
}
-void show_ref_array_item(struct ref_array_item *info, const char *format, int
quote_style)
+/*
+ * If 'lines' is greater than 0, print that many lines from the given
+ * object_id 'oid'.
+ */
+static void show_tag_lines(const struct object_id *oid, int lines)
+{
+ int i;
+ unsigned long size;
+ enum object_type type;
+ char *buf, *sp, *eol;
+ size_t len;
+
+ buf = read_sha1_file(oid-hash, type, size);
+ if (!buf)
+ die_errno(unable to read object %s, oid_to_hex(oid));
+ if (type != OBJ_COMMIT type != OBJ_TAG)
+ goto free_return;
+ if (!size)
+ die(an empty %s object %s?,
+ typename(type), oid_to_hex(oid));
+
+ /* skip header */
+ sp = strstr(buf, \n\n);
+ if (!sp)
+ goto free_return;
+
+ /* only take up to lines lines, and strip the signature from a tag */
+ if (type == OBJ_TAG)
+ size = parse_signature(buf, size);
+ for (i = 0, sp += 2; i lines sp buf + size; i++) {
+ if (i)
+ printf(\n);
+ eol = memchr(sp, '\n', size - (sp - buf));
+ len = eol ? eol - sp : size - (sp - buf);
+ fwrite(sp, len, 1, stdout);
+ if (!eol)
+ break;
+ sp = eol + 1;
+ }
+free_return:
+ free(buf);
+}
+
+void show_ref_array_item(struct ref_array_item *info, const char *format,
+int quote_style, unsigned int lines)
{
const char *cp, *sp, *ep;
struct ref_formatting_state state;
@@ -1339,6 +1383,11 @@ void show_ref_array_item(struct ref_array_item *info,
const char *format, int qu
resetv.s = color;
print_value(state, resetv);
}
+ if (lines 0) {
+ struct object_id oid;
+ hashcpy(oid.hash, info-objectname);
+ show_tag_lines(oid, lines);
+ }
putchar('\n');
}
diff --git a/ref-filter.h b/ref-filter.h
index 62ad979..570fc3a 100644
--- a/ref-filter.h
+++ b/ref-filter.h
@@ -64,6 +64,7 @@ struct ref_filter {
struct commit *merge_commit;
unsigned int with_commit_tag_algo : 1;
+ unsigned int lines;
};
struct ref_filter_cbdata {
@@ -95,8 +96,12 @@ int parse_ref_filter_atom(const char *atom, const char *ep);
int verify_ref_format(const char *format);
/* Sort the given ref_array as per the ref_sorting provided */
void ref_array_sort(struct ref_sorting *sort, struct ref_array *array);
-/* Print the ref using the given format and quote_style */
-void show_ref_array_item(struct ref_array_item *info, const char *format, int
quote_style);
+/*
+ * Print the ref using the given format and quote_style. If 'lines' 0,
+ * print that many lines of the the given ref.
+ */
+void show_ref_array_item(struct ref_array_item *info, const char *format,
+int quote_style, unsigned int lines);
/* Callback function for parsing the sort option */
int
[PATCH v5 09/11] tag.c: use 'ref-filter' APIs
From: Karthik Nayak karthik@gmail.com
Make 'tag.c' use 'ref-filter' APIs for iterating through refs sorting
and printing of refs. This removes most of the code used in 'tag.c'
replacing it with calls to the 'ref-filter' library.
Make 'tag.c' use the 'filter_refs()' function provided by 'ref-filter'
to filter out tags based on the options set.
For printing tags we use 'show_ref_array_item()' function provided by
'ref-filter'.
We improve the sorting option provided by 'tag.c' by using the sorting
options provided by 'ref-filter'. This causes the test 'invalid sort
parameter on command line' in t7004 to fail, as 'ref-filter' throws an
error for all sorting fields which are incorrect. The test is changed
to reflect the same.
Modify documentation for the same.
Mentored-by: Christian Couder christian.cou...@gmail.com
Mentored-by: Matthieu Moy matthieu@grenoble-inp.fr
Signed-off-by: Karthik Nayak karthik@gmail.com
---
Documentation/git-tag.txt | 16 ++-
builtin/tag.c | 342 ++
t/t7004-tag.sh| 8 +-
3 files changed, 50 insertions(+), 316 deletions(-)
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 84f6496..3ac4a96 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -13,7 +13,7 @@ SYNOPSIS
tagname [commit | object]
'git tag' -d tagname...
'git tag' [-n[num]] -l [--contains commit] [--points-at object]
- [--column[=options] | --no-column] [--create-reflog] [pattern...]
+ [--column[=options] | --no-column] [--create-reflog] [--sort=key]
[pattern...]
'git tag' -v tagname...
DESCRIPTION
@@ -94,14 +94,16 @@ OPTIONS
using fnmatch(3)). Multiple patterns may be given; if any of
them matches, the tag is shown.
---sort=type::
- Sort in a specific order. Supported type is refname
- (lexicographic order), version:refname or v:refname (tag
+--sort=key::
+ Sort based on the key given. Prefix `-` to sort in
+ descending order of the value. You may use the --sort=key option
+ multiple times, in which case the last key becomes the primary
+ key. Also supports version:refname or v:refname (tag
names are treated as versions). The version:refname sort
order can also be affected by the
- versionsort.prereleaseSuffix configuration variable. Prepend
- - to reverse sort order. When this option is not given, the
- sort order defaults to the value configured for the 'tag.sort'
+ versionsort.prereleaseSuffix configuration variable.
+ The keys supported are the same as those in `git for-each-ref`.
+ Sort order defaults to the value configured for the 'tag.sort'
variable if it exists, or lexicographic order otherwise. See
linkgit:git-config[1].
diff --git a/builtin/tag.c b/builtin/tag.c
index e96bae2..1e8d1b2 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -28,278 +28,32 @@ static const char * const git_tag_usage[] = {
NULL
};
-#define STRCMP_SORT 0 /* must be zero */
-#define VERCMP_SORT 1
-#define SORT_MASK 0x7fff
-#define REVERSE_SORT0x8000
-
-static int tag_sort;
-
static unsigned int colopts;
-static int match_pattern(const char **patterns, const char *ref)
-{
- /* no pattern means match everything */
- if (!*patterns)
- return 1;
- for (; *patterns; patterns++)
- if (!wildmatch(*patterns, ref, 0, NULL))
- return 1;
- return 0;
-}
-
-/*
- * This is currently duplicated in ref-filter.c, and will eventually be
- * removed as we port tag.c to use the ref-filter APIs.
- */
-static const unsigned char *match_points_at(const char *refname,
- const unsigned char *sha1,
- struct sha1_array *points_at)
-{
- const unsigned char *tagged_sha1 = NULL;
- struct object *obj;
-
- if (sha1_array_lookup(points_at, sha1) = 0)
- return sha1;
- obj = parse_object(sha1);
- if (!obj)
- die(_(malformed object at '%s'), refname);
- if (obj-type == OBJ_TAG)
- tagged_sha1 = ((struct tag *)obj)-tagged-sha1;
- if (tagged_sha1 sha1_array_lookup(points_at, tagged_sha1) = 0)
- return tagged_sha1;
- return NULL;
-}
-
-static int in_commit_list(const struct commit_list *want, struct commit *c)
-{
- for (; want; want = want-next)
- if (!hashcmp(want-item-object.sha1, c-object.sha1))
- return 1;
- return 0;
-}
-
-/*
- * The entire code segment for supporting the --contains option has been
- * copied over to ref-filter.{c,h}. This will be deleted evetually when
- * we port tag.c to use ref-filter APIs.
- */
-enum contains_result {
- CONTAINS_UNKNOWN = -1,
- CONTAINS_NO = 0,
- CONTAINS_YES = 1
-};
-
-/*
- * Test whether the
[PATCH v5 10/11] tag.c: implement '--format' option
From: Karthik Nayak karthik@gmail.com
Implement the '--format' option provided by 'ref-filter'.
This lets the user list tags as per desired format similar
to the implementation in 'git for-each-ref'.
Add tests and documentation for the same.
Mentored-by: Christian Couder christian.cou...@gmail.com
Mentored-by: Matthieu Moy matthieu@grenoble-inp.fr
Signed-off-by: Karthik Nayak karthik@gmail.com
---
Documentation/git-tag.txt | 15 ++-
builtin/tag.c | 11 +++
t/t7004-tag.sh| 16
3 files changed, 37 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 3ac4a96..75703c5 100644
--- 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] [--create-reflog] [--sort=key]
[pattern...]
+ [--column[=options] | --no-column] [--create-reflog] [--sort=key]
+ [--format=format] [pattern...]
'git tag' -v tagname...
DESCRIPTION
@@ -158,6 +159,18 @@ 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 `%(refname:short)`. It also
+ interpolates `%%` to `%`, and `%xx` where `xx` are hex digits
+ interpolates to character with hex code `xx`; for example
+ `%00` interpolates to `\0` (NUL), `%09` to `\t` (TAB) and
+ `%0a` to `\n` (LF). The fields are same as those in `git
+ for-each-ref`.
+
CONFIGURATION
-
diff --git a/builtin/tag.c b/builtin/tag.c
index 1e8d1b2..7de49c4 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -30,10 +30,9 @@ static const char * const git_tag_usage[] = {
static unsigned int colopts;
-static int list_tags(struct ref_filter *filter, struct ref_sorting *sorting)
+static int list_tags(struct ref_filter *filter, struct ref_sorting *sorting,
const char *format)
{
struct ref_array array;
- char *format;
int i;
memset(array, 0, sizeof(array));
@@ -43,7 +42,7 @@ static int list_tags(struct ref_filter *filter, struct
ref_sorting *sorting)
if (filter-lines)
format = %(padright:16)%(refname:short);
- else
+ else if (!format)
format = %(refname:short);
verify_ref_format(format);
@@ -327,6 +326,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
struct strbuf err = STRBUF_INIT;
struct ref_filter filter;
static struct ref_sorting *sorting = NULL, **sorting_tail = sorting;
+ const char *format = NULL;
struct option options[] = {
OPT_CMDMODE('l', list, cmdmode, N_(list tag names), 'l'),
{ OPTION_INTEGER, 'n', NULL, filter.lines, N_(n),
@@ -359,6 +359,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
OPTION_CALLBACK, 0, points-at, filter.points_at,
N_(object),
N_(print only tags of the object), 0,
parse_opt_object_name
},
+ OPT_STRING( 0 , format, format, N_(format), N_(format to
use for the output)),
OPT_END()
};
@@ -398,8 +399,10 @@ int cmd_tag(int argc, const char **argv, const char
*prefix)
copts.padding = 2;
run_column_filter(colopts, copts);
}
+ if (format (filter.lines != -1))
+ die(_(--format and -n are incompatible));
filter.name_patterns = argv;
- ret = list_tags(filter, sorting);
+ ret = list_tags(filter, sorting, format);
if (column_active(colopts))
stop_column_filter();
return ret;
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index 1f066aa..1809011 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -1519,4 +1519,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
+ refname : refs/tags/foo1.10
+ refname : refs/tags/foo1.3
+ refname : refs/tags/foo1.6
+ refname : refs/tags/foo1.6-rc1
+ refname : refs/tags/foo1.6-rc2
+ EOF
+ git tag -l --format=refname : %(refname) foo* actual
+ test_cmp expect actual
+'
+
test_done
--
2.4.6
--
To
[PATCH v5 08/11] tag.c: use 'ref-filter' data structures
From: Karthik Nayak karthik@gmail.com
Make 'tag.c' use 'ref-filter' data structures and make changes to
support the new data structures. This is a part of the process
of porting 'tag.c' to use 'ref-filter' APIs.
This is a temporary step before porting 'tag.c' to use 'ref-filter'
completely. As this is a temporary step, most of the code
introduced here will be removed when 'tag.c' is ported over to use
'ref-filter' APIs
Mentored-by: Christian Couder christian.cou...@gmail.com
Mentored-by: Matthieu Moy matthieu@grenoble-inp.fr
Signed-off-by: Karthik Nayak karthik@gmail.com
---
builtin/tag.c | 106 +++---
1 file changed, 57 insertions(+), 49 deletions(-)
diff --git a/builtin/tag.c b/builtin/tag.c
index 0fc7557..e96bae2 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -17,6 +17,7 @@
#include gpg-interface.h
#include sha1-array.h
#include column.h
+#include ref-filter.h
static const char * const git_tag_usage[] = {
N_(git tag [-a | -s | -u key-id] [-f] [-m msg | -F file]
tagname [head]),
@@ -34,15 +35,6 @@ static const char * const git_tag_usage[] = {
static int tag_sort;
-struct tag_filter {
- const char **patterns;
- int lines;
- int sort;
- struct string_list tags;
- struct commit_list *with_commit;
-};
-
-static struct sha1_array points_at;
static unsigned int colopts;
static int match_pattern(const char **patterns, const char *ref)
@@ -61,19 +53,20 @@ static int match_pattern(const char **patterns, const char
*ref)
* removed as we port tag.c to use the ref-filter APIs.
*/
static const unsigned char *match_points_at(const char *refname,
- const unsigned char *sha1)
+ const unsigned char *sha1,
+ struct sha1_array *points_at)
{
const unsigned char *tagged_sha1 = NULL;
struct object *obj;
- if (sha1_array_lookup(points_at, sha1) = 0)
+ if (sha1_array_lookup(points_at, sha1) = 0)
return sha1;
obj = parse_object(sha1);
if (!obj)
die(_(malformed object at '%s'), refname);
if (obj-type == OBJ_TAG)
tagged_sha1 = ((struct tag *)obj)-tagged-sha1;
- if (tagged_sha1 sha1_array_lookup(points_at, tagged_sha1) = 0)
+ if (tagged_sha1 sha1_array_lookup(points_at, tagged_sha1) = 0)
return tagged_sha1;
return NULL;
}
@@ -228,12 +221,24 @@ free_return:
free(buf);
}
+static void ref_array_append(struct ref_array *array, const char *refname)
+{
+ size_t len = strlen(refname);
+ struct ref_array_item *ref = xcalloc(1, sizeof(struct ref_array_item) +
len + 1);
+ memcpy(ref-refname, refname, len);
+ ref-refname[len] = '\0';
+ REALLOC_ARRAY(array-items, array-nr + 1);
+ array-items[array-nr++] = ref;
+}
+
static int show_reference(const char *refname, const struct object_id *oid,
int flag, void *cb_data)
{
- struct tag_filter *filter = cb_data;
+ struct ref_filter_cbdata *data = cb_data;
+ struct ref_array *array = data-array;
+ struct ref_filter *filter = data-filter;
- if (match_pattern(filter-patterns, refname)) {
+ if (match_pattern(filter-name_patterns, refname)) {
if (filter-with_commit) {
struct commit *commit;
@@ -244,12 +249,12 @@ static int show_reference(const char *refname, const
struct object_id *oid,
return 0;
}
- if (points_at.nr !match_points_at(refname, oid-hash))
+ if (filter-points_at.nr !match_points_at(refname,
oid-hash, filter-points_at))
return 0;
if (!filter-lines) {
- if (filter-sort)
- string_list_append(filter-tags, refname);
+ if (tag_sort)
+ ref_array_append(array, refname);
else
printf(%s\n, refname);
return 0;
@@ -264,36 +269,36 @@ static int show_reference(const char *refname, const
struct object_id *oid,
static int sort_by_version(const void *a_, const void *b_)
{
- const struct string_list_item *a = a_;
- const struct string_list_item *b = b_;
- return versioncmp(a-string, b-string);
+ const struct ref_array_item *a = *((struct ref_array_item **)a_);
+ const struct ref_array_item *b = *((struct ref_array_item **)b_);
+ return versioncmp(a-refname, b-refname);
}
-static int list_tags(const char **patterns, int lines,
-struct commit_list *with_commit, int sort)
+static int list_tags(struct ref_filter *filter, int sort)
{
- struct tag_filter filter;
+ struct ref_array array;
+
[PATCH v5 11/11] tag.c: implement '--merged' and '--no-merged' options
From: Karthik Nayak karthik@gmail.com
Using 'ref-filter' APIs implement the '--merged' and '--no-merged'
options into 'tag.c'. The '--merged' option lets the user to only
list tags merged into the named commit. The '--no-merged' option
lets the user to only list tags not merged into the named commit.
If no object is provided it assumes HEAD as the object.
Add documentation and tests for the same.
Mentored-by: Christian Couder christian.cou...@gmail.com
Mentored-by: Matthieu Moy matthieu@grenoble-inp.fr
Signed-off-by: Karthik Nayak karthik@gmail.com
---
Documentation/git-tag.txt | 7 ++-
builtin/tag.c | 6 +-
t/t7004-tag.sh| 27 +++
3 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 75703c5..c2785d9 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -14,7 +14,7 @@ SYNOPSIS
'git tag' -d tagname...
'git tag' [-n[num]] -l [--contains commit] [--points-at object]
[--column[=options] | --no-column] [--create-reflog] [--sort=key]
- [--format=format] [pattern...]
+ [--format=format] [--[no-]merged [commit]] [pattern...]
'git tag' -v tagname...
DESCRIPTION
@@ -171,6 +171,11 @@ This option is only applicable when listing tags without
annotation lines.
`%0a` to `\n` (LF). The fields are same as those in `git
for-each-ref`.
+--[no-]merged [commit]::
+ Only list tags whose tips are reachable, or not reachable
+ if '--no-merged' is used, from the specified commit ('HEAD'
+ if not specified).
+
CONFIGURATION
-
diff --git a/builtin/tag.c b/builtin/tag.c
index 7de49c4..fc01117 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -23,7 +23,7 @@ static const char * const git_tag_usage[] = {
N_(git tag [-a | -s | -u key-id] [-f] [-m msg | -F file]
tagname [head]),
N_(git tag -d tagname...),
N_(git tag -l [-n[num]] [--contains commit] [--points-at object]
- \n\t\t[pattern...]),
+ \n\t\t[--[no-]merged [commit]] [pattern...]),
N_(git tag -v tagname...),
NULL
};
@@ -353,6 +353,8 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
OPT_COLUMN(0, column, colopts, N_(show tag list in
columns)),
OPT_CONTAINS(filter.with_commit, N_(print only tags that
contain the commit)),
OPT_WITH(filter.with_commit, N_(print only tags that contain
the commit)),
+ OPT_MERGED(filter, N_(print only tags that are merged)),
+ OPT_NO_MERGED(filter, N_(print only tags that are not
merged)),
OPT_CALLBACK(0 , sort, sorting_tail, N_(key),
N_(field name to sort on),
parse_opt_ref_sorting),
{
@@ -413,6 +415,8 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
die(_(--contains option is only allowed with -l.));
if (filter.points_at.nr)
die(_(--points-at option is only allowed with -l.));
+ if (filter.merge_commit)
+ die(_(--merged and --no-merged option are only allowed with
-l));
if (cmdmode == 'd')
return for_each_tag_name(argv, delete_tag);
if (cmdmode == 'v')
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index 1809011..5b73539 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -1535,4 +1535,31 @@ test_expect_success '--format should list tags as per
format given' '
test_cmp expect actual
'
+test_expect_success 'setup --merged test tags' '
+ git tag mergetest-1 HEAD~2
+ git tag mergetest-2 HEAD~1
+ git tag mergetest-3 HEAD
+'
+
+test_expect_success '--merged cannot be used in non-list mode' '
+ test_must_fail git tag --merged=mergetest-2 foo
+'
+
+test_expect_success '--merged shows merged tags' '
+ cat expect -\EOF
+ mergetest-1
+ mergetest-2
+ EOF
+ git tag -l --merged=mergetest-2 mergetest-* actual
+ test_cmp expect actual
+'
+
+test_expect_success '--no-merged show unmerged tags' '
+ cat expect -\EOF
+ mergetest-3
+ EOF
+ git tag -l --no-merged=mergetest-2 mergetest-* actual
+ test_cmp expect actual
+'
+
test_done
--
2.4.6
--
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 00/11] port tag.c to use ref-filter APIs
This is part of my GSoC project to unify git tag -l, git branch -l,
git for-each-ref. This patch series is continued from: Git (next)
https://github.com/git/git/commit/bf5418f49ff0cebc6e5ce04ad1417e1a47c81b61
Version 4 can be found here
http://article.gmane.org/gmane.comp.version-control.git/274579
Changes in this version (interdiff at the end):
* Change the way ref_formatting_state is used and the sequence of its
usage in the
series.
* Separate the introduction of ref_formatting_state from its usage.
* Removed the inefficient removal of path in match_pattern().
* Improve coding style in the implementation of sorting based on version.
* Changed the tests for sorting based on version, to use
'for-each-ref' rather than 'tag.c'
which already has a working sort based on version.
* Other small grammatical changes.
* Change the atom name from 'align' to 'padright'.
[PATCH v5 01/11] ref-filter: introduce 'ref_formatting_state'
[PATCH v5 02/11] ref-filter: make `color` use `ref_formatting_state`
[PATCH v5 03/11] ref-filter: add option to pad atoms to the right
[PATCH v5 04/11] ref-filter: add option to filter only tags
[PATCH v5 05/11] ref-filter: support printing N lines from tag
[PATCH v5 06/11] ref-filter: add support to sort by version
[PATCH v5 07/11] ref-filter: add option to match literal pattern
[PATCH v5 08/11] tag.c: use 'ref-filter' data structures
[PATCH v5 09/11] tag.c: use 'ref-filter' APIs
[PATCH v5 10/11] tag.c: implement '--format' option
[PATCH v5 11/11] tag.c: implement '--merged' and '--no-merged'
Interdiff:
diff --git a/Documentation/git-for-each-ref.txt
b/Documentation/git-for-each-ref.txt
index 224dc8c..2b60aee 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -127,6 +127,12 @@ color::
Change output color. Followed by `:colorname`, where names
are described in `color.branch.*`.
+padright::
+Pad succeeding atom to the right. Followed by `:value`,
+where `value` states the total length of atom including the
+padding. If the `value` is greater than the atom length, then
+no padding is performed.
+
In addition to the above, for commit and tag objects, the header
field names (`tree`, `parent`, `object`, `type`, and `tag`) can
be used to specify the value in the header field.
diff --git a/builtin/tag.c b/builtin/tag.c
index 8a7f684..fc01117 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -41,13 +41,11 @@ static int list_tags(struct ref_filter *filter,
struct ref_sorting *sorting, con
filter-lines = 0;
if (filter-lines)
-format = %(align:16)%(refname:short);
+format = %(padright:16)%(refname:short);
else if (!format)
format = %(refname:short);
verify_ref_format(format);
-if (!sorting)
-sorting = ref_default_sorting();
filter_refs(array, filter, FILTER_REFS_TAGS);
ref_array_sort(sorting, array);
@@ -134,7 +132,7 @@ static int parse_sorting_string(const char *arg,
struct ref_sorting **sorting_ta
if (*arg == '-') {
s-reverse = 1;
arg++;
- }
+}
if (skip_prefix(arg, version:, arg) ||
skip_prefix(arg, v:, arg))
s-version = 1;
diff --git a/ref-filter.c b/ref-filter.c
index c686c03..597b189 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -56,7 +56,7 @@ static struct {
{ flag },
{ HEAD },
{ color },
-{ align },
+{ padright },
};
/*
@@ -601,8 +601,7 @@ static inline char *copy_advance(char *dst, const char *src)
/*
* Parse the object referred by ref, and grab needed value.
*/
-static void populate_value(struct ref_formatting_state *state,
- struct ref_array_item *ref)
+static void populate_value(struct ref_array_item *ref)
{
void *buf;
struct object *obj;
@@ -664,8 +663,9 @@ static void populate_value(struct
ref_formatting_state *state,
if (color_parse(name + 6, color) 0)
die(_(unable to parse format));
-state-color = xstrdup(color);
+v-s = xstrdup(color);
v-pseudo_atom = 1;
+v-color = 1;
continue;
} else if (!strcmp(name, flag)) {
char buf[256], *cp = buf;
@@ -693,17 +693,17 @@ static void populate_value(struct
ref_formatting_state *state,
else
v-s = ;
continue;
-} else if (starts_with(name, align:)) {
+} else if (starts_with(name, padright:)) {
const char *valp = NULL;
-skip_prefix(name, align:, valp);
+skip_prefix(name, padright:, valp);
if (!valp[0])
-die(_(no value given with 'align:'));
-if (strtoul_ui(valp, 10, state-pad_to_right))
-die(_(positive integer expected after ':' in align:%u\n),
-state-pad_to_right);
+die(_(no value given with 'padright:'));
+if (strtoul_ui(valp, 10, (unsigned int *)v-ul))
+
[PATCH v5 02/11] ref-filter: make `color` use `ref_formatting_state`
Make the `color` atom a pseudo atom and ensure that it uses
`ref_formatting_state`.
---
ref-filter.c | 19 ++-
ref-filter.h | 4 +++-
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/ref-filter.c b/ref-filter.c
index a3625e8..cc25c85 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -662,6 +662,8 @@ static void populate_value(struct ref_array_item *ref)
if (color_parse(name + 6, color) 0)
die(_(unable to parse format));
v-s = xstrdup(color);
+ v-pseudo_atom = 1;
+ v-color = 1;
continue;
} else if (!strcmp(name, flag)) {
char buf[256], *cp = buf;
@@ -1195,6 +1197,11 @@ void ref_array_sort(struct ref_sorting *sorting, struct
ref_array *array)
static void ref_formatting(struct ref_formatting_state *state,
struct atom_value *v, struct strbuf *value)
{
+ if (state-color) {
+ strbuf_addstr(value, state-color);
+ free(state-color);
+ state-color = NULL;
+ }
strbuf_addf(value, %s, v-s);
}
@@ -1266,6 +1273,13 @@ static void emit(const char *cp, const char *ep)
}
}
+static void apply_pseudo_state(struct ref_formatting_state *state,
+ struct atom_value *v)
+{
+ if (v-color)
+ state-color = (char *)v-s;
+}
+
void show_ref_array_item(struct ref_array_item *info, const char *format, int
quote_style)
{
const char *cp, *sp, *ep;
@@ -1281,7 +1295,10 @@ void show_ref_array_item(struct ref_array_item *info,
const char *format, int qu
if (cp sp)
emit(cp, sp);
get_ref_atom_value(info, parse_ref_filter_atom(sp + 2, ep),
atomv);
- print_value(state, atomv);
+ if (atomv-pseudo_atom)
+ apply_pseudo_state(state, atomv);
+ else
+ print_value(state, atomv);
}
if (*cp) {
sp = cp + strlen(cp);
diff --git a/ref-filter.h b/ref-filter.h
index f24e3ef..7687879 100644
--- a/ref-filter.h
+++ b/ref-filter.h
@@ -19,11 +19,13 @@
struct atom_value {
const char *s;
unsigned long ul; /* used for sorting when not FIELD_STR */
- unsigned int pseudo_atom : 1; /* atoms which aren't placeholders for
ref attributes */
+ unsigned int pseudo_atom : 1, /* atoms which aren't placeholders for
ref attributes */
+ color : 1;
};
struct ref_formatting_state {
int quote_style;
+ char *color;
};
struct ref_sorting {
--
2.4.6
--
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 03/11] ref-filter: add option to pad atoms to the right
Add a new atom padright and support %(padright:X) where X is a
number. This will align the succeeding atom value to the left
followed by spaces for a total length of X characters. If X is less
than the item size, the entire atom value is printed.
Add tests and documentation for the same.
Helped-by: Duy Nguyen pclo...@gmail.com
Helped-by: Junio C Hamano gits...@pobox.com
Mentored-by: Christian Couder christian.cou...@gmail.com
Mentored-by: Matthieu Moy matthieu@grenoble-inp.fr
Signed-off-by: Karthik Nayak karthik@gmail.com
---
Documentation/git-for-each-ref.txt | 6 ++
ref-filter.c | 24
ref-filter.h | 4 +++-
t/t6302-for-each-ref-filter.sh | 16
4 files changed, 49 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-for-each-ref.txt
b/Documentation/git-for-each-ref.txt
index e49d578..45dd7f8 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -127,6 +127,12 @@ color::
Change output color. Followed by `:colorname`, where names
are described in `color.branch.*`.
+padright::
+ Pad succeeding atom to the right. Followed by `:value`,
+ where `value` states the total length of atom including the
+ padding. If the `value` is greater than the atom length, then
+ no padding is performed.
+
In addition to the above, for commit and tag objects, the header
field names (`tree`, `parent`, `object`, `type`, and `tag`) can
be used to specify the value in the header field.
diff --git a/ref-filter.c b/ref-filter.c
index cc25c85..7ab34be 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -55,6 +55,7 @@ static struct {
{ flag },
{ HEAD },
{ color },
+ { padright },
};
/*
@@ -691,6 +692,18 @@ static void populate_value(struct ref_array_item *ref)
else
v-s = ;
continue;
+ } else if (starts_with(name, padright:)) {
+ const char *valp = NULL;
+
+ skip_prefix(name, padright:, valp);
+ if (!valp[0])
+ die(_(no value given with 'padright:'));
+ if (strtoul_ui(valp, 10, (unsigned int *)v-ul))
+ die(_(positive integer expected after ':' in
padright:%u\n),
+ (unsigned int)v-ul);
+ v-pseudo_atom = 1;
+ v-pad_to_right = 1;
+ continue;
} else
continue;
@@ -1202,6 +1215,15 @@ static void ref_formatting(struct ref_formatting_state
*state,
free(state-color);
state-color = NULL;
}
+ if (state-pad_to_right) {
+ if (!is_utf8(v-s))
+ strbuf_addf(value, %-*s, state-pad_to_right, v-s);
+ else {
+ int utf8_compensation = strlen(v-s) -
utf8_strwidth(v-s);
+ strbuf_addf(value, %-*s, state-pad_to_right +
utf8_compensation, v-s);
+ }
+ return;
+ }
strbuf_addf(value, %s, v-s);
}
@@ -1278,6 +1300,8 @@ static void apply_pseudo_state(struct
ref_formatting_state *state,
{
if (v-color)
state-color = (char *)v-s;
+ if (v-pad_to_right)
+ state-pad_to_right = v-ul;
}
void show_ref_array_item(struct ref_array_item *info, const char *format, int
quote_style)
diff --git a/ref-filter.h b/ref-filter.h
index 7687879..63b8175 100644
--- a/ref-filter.h
+++ b/ref-filter.h
@@ -20,12 +20,14 @@ struct atom_value {
const char *s;
unsigned long ul; /* used for sorting when not FIELD_STR */
unsigned int pseudo_atom : 1, /* atoms which aren't placeholders for
ref attributes */
- color : 1;
+ color : 1,
+ pad_to_right : 1;
};
struct ref_formatting_state {
int quote_style;
char *color;
+ unsigned int pad_to_right;
};
struct ref_sorting {
diff --git a/t/t6302-for-each-ref-filter.sh b/t/t6302-for-each-ref-filter.sh
index 505a360..daaa27a 100755
--- a/t/t6302-for-each-ref-filter.sh
+++ b/t/t6302-for-each-ref-filter.sh
@@ -81,4 +81,20 @@ test_expect_success 'filtering with --contains' '
test_cmp expect actual
'
+test_expect_success 'padding to the right using `padright`' '
+ cat expect -\EOF
+ refs/heads/master|
+ refs/heads/side |
+ refs/odd/spot|
+ refs/tags/double-tag |
+ refs/tags/four |
+ refs/tags/one|
+ refs/tags/signed-tag |
+ refs/tags/three |
+ refs/tags/two|
+ EOF
+ git for-each-ref --format=%(padright:25)%(refname)| actual
+ test_cmp expect actual
+'
+
test_done
[PATCH v5 07/11] ref-filter: add option to match literal pattern
From: Karthik Nayak karthik@gmail.com
Since 'ref-filter' only has an option to match path names add an
option for plain fnmatch pattern-matching.
This is to support the pattern matching options which are used in `git
tag -l` and `git branch -l` where we can match patterns like `git tag
-l foo*` which would match all tags which has a foo* pattern.
Mentored-by: Christian Couder christian.cou...@gmail.com
Mentored-by: Matthieu Moy matthieu@grenoble-inp.fr
Signed-off-by: Karthik Nayak karthik@gmail.com
---
builtin/for-each-ref.c | 1 +
ref-filter.c | 38 +-
ref-filter.h | 3 ++-
3 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index e4a4f8a..3ad6a64 100644
--- a/builtin/for-each-ref.c
+++ b/builtin/for-each-ref.c
@@ -68,6 +68,7 @@ int cmd_for_each_ref(int argc, const char **argv, const char
*prefix)
git_config(git_default_config, NULL);
filter.name_patterns = argv;
+ filter.match_as_path = 1;
filter_refs(array, filter, FILTER_REFS_ALL |
FILTER_REFS_INCLUDE_BROKEN);
ref_array_sort(sorting, array);
diff --git a/ref-filter.c b/ref-filter.c
index 26eb26c..597b189 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -946,6 +946,32 @@ 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/mas) or a wildcard (e.g. the same ref
+ * matches refs/heads/mas*, too).
+ */
+static int match_pattern(const char **patterns, const char *refname)
+{
+ /*
+* When no '--format' option is given we need to skip the prefix
+* for matching refs of tags and branches.
+*/
+ if (skip_prefix(refname, refs/tags/, refname))
+ ;
+ else if (skip_prefix(refname, refs/heads/, refname))
+ ;
+ else if (skip_prefix(refname, refs/remotes/, 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
* matches refs/heads/m*,too).
@@ -969,6 +995,16 @@ static int match_name_as_path(const char **pattern, const
char *refname)
return 0;
}
+/* Return 1 if the refname matches one of the patterns, otherwise 0. */
+static int filter_pattern_match(struct ref_filter *filter, const char *refname)
+{
+ if (!*filter-name_patterns)
+ return 1; /* No pattern always matches */
+ if (filter-match_as_path)
+ return match_name_as_path(filter-name_patterns, refname);
+ return match_pattern(filter-name_patterns, refname);
+}
+
/*
* Given a ref (sha1, refname), check if the ref belongs to the array
* of sha1s. If the given ref is a tag, check if the given tag points
@@ -1037,7 +1073,7 @@ static int ref_filter_handler(const char *refname, const
struct object_id *oid,
return 0;
}
- if (*filter-name_patterns
!match_name_as_path(filter-name_patterns, refname))
+ if (!filter_pattern_match(filter, refname))
return 0;
if (filter-points_at.nr !match_points_at(filter-points_at,
oid-hash, refname))
diff --git a/ref-filter.h b/ref-filter.h
index 5406721..a27745f 100644
--- a/ref-filter.h
+++ b/ref-filter.h
@@ -64,7 +64,8 @@ struct ref_filter {
} merge;
struct commit *merge_commit;
- unsigned int with_commit_tag_algo : 1;
+ unsigned int with_commit_tag_algo : 1,
+ match_as_path : 1;
unsigned int lines;
};
--
2.4.6
--
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 04/11] ref-filter: add option to filter only tags
From: Karthik Nayak karthik@gmail.com
Add a functions called 'for_each_tag_ref_fullpath()' to refs.{c,h}
which iterates through each tag ref without trimming the path.
Add an option in 'filter_refs()' to use 'for_each_tag_ref_fullpath()'
and filter refs. This type checking is done by adding a
'FILTER_REFS_TAGS' in 'ref-filter.h'
Mentored-by: Christian Couder christian.cou...@gmail.com
Mentored-by: Matthieu Moy matthieu@grenoble-inp.fr
Signed-off-by: Karthik Nayak karthik@gmail.com
---
ref-filter.c | 2 ++
ref-filter.h | 1 +
refs.c | 5 +
refs.h | 1 +
4 files changed, 9 insertions(+)
diff --git a/ref-filter.c b/ref-filter.c
index 7ab34be..6e01b44 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -1152,6 +1152,8 @@ int filter_refs(struct ref_array *array, struct
ref_filter *filter, unsigned int
ret = for_each_rawref(ref_filter_handler, ref_cbdata);
else if (type FILTER_REFS_ALL)
ret = for_each_ref(ref_filter_handler, ref_cbdata);
+ else if (type FILTER_REFS_TAGS)
+ ret = for_each_tag_ref_fullpath(ref_filter_handler,
ref_cbdata);
else if (type)
die(filter_refs: invalid type);
diff --git a/ref-filter.h b/ref-filter.h
index 63b8175..62ad979 100644
--- a/ref-filter.h
+++ b/ref-filter.h
@@ -15,6 +15,7 @@
#define FILTER_REFS_INCLUDE_BROKEN 0x1
#define FILTER_REFS_ALL 0x2
+#define FILTER_REFS_TAGS 0x4
struct atom_value {
const char *s;
diff --git a/refs.c b/refs.c
index 0b96ece..23ce483 100644
--- a/refs.c
+++ b/refs.c
@@ -2108,6 +2108,11 @@ int for_each_tag_ref(each_ref_fn fn, void *cb_data)
return for_each_ref_in(refs/tags/, fn, cb_data);
}
+int for_each_tag_ref_fullpath(each_ref_fn fn, void *cb_data)
+{
+ return do_for_each_ref(ref_cache, refs/tags/, fn, 0, 0, cb_data);
+}
+
int for_each_tag_ref_submodule(const char *submodule, each_ref_fn fn, void
*cb_data)
{
return for_each_ref_in_submodule(submodule, refs/tags/, fn, cb_data);
diff --git a/refs.h b/refs.h
index e4e46c3..9eee2de 100644
--- a/refs.h
+++ b/refs.h
@@ -174,6 +174,7 @@ extern int head_ref(each_ref_fn fn, void *cb_data);
extern int for_each_ref(each_ref_fn fn, void *cb_data);
extern int for_each_ref_in(const char *prefix, each_ref_fn fn, void *cb_data);
extern int for_each_tag_ref(each_ref_fn fn, void *cb_data);
+extern int for_each_tag_ref_fullpath(each_ref_fn fn, void *cb_data);
extern int for_each_branch_ref(each_ref_fn fn, void *cb_data);
extern int for_each_remote_ref(each_ref_fn fn, void *cb_data);
extern int for_each_replace_ref(each_ref_fn fn, void *cb_data);
--
2.4.6
--
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 01/10] ref-filter: add option to align atoms to the left
On Sun, Jul 26, 2015 at 5:39 PM, Duy Nguyen pclo...@gmail.com wrote:
On Sun, Jul 26, 2015 at 11:08 AM, Eric Sunshine sunsh...@sunshineco.com
wrote:
You can generate an interdiff with git diff branchname-v4
branchname-v5, for instance.
Off topic. But what stops me from doing this often is it creates a big
mess in git tag -l. Do we have an option to hide away some
insignificant: tags? reflog might be an option if we have something
like foo@{/v2} to quickly retrieve the reflog entry whose message
contains v2.
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
You can normally find the previous commit via the reflog. Various
changes to the settings can make the reflog be maintained for longer
if you have longer lived patch series. That's how I would suggest it,
rather than branches, as I tend not to keep old versions around on
separate tags or branches.
The problem with foo@{/v2} is that people don't always keep values
inside the message it self, but maybe foo@{/pattern} would be a
useful extension?
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
Indenting lines starting with die in shell after ||
Hi, It looks like we are very inconsistent in shell scripts about indenting lines starting with die after a line that ends with ||, like: quite long command || die command failed For example in git-rebase--interactive.sh, there is often, but not always, an extra tab before the die. It looks like there are no rules about that in Documentation/CodingGuidelines. Also emacs in shell-script mode is reluctant to add a tab in front of die in such a case. I wonder if we should state a preference for no extra tab in Documentation/CodingGuidelines. Thanks, Christian. -- 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
