The 'colornext' atom allows us to color only the succeeding atom with
a particular color. This resets any previous color preferences set. It
is not compatible with `padright`. This is required for printing
formats like `git branch -vv` where the upstream is colored in blue.
Mentored-by: Christian
Remove show_detached() and make detached HEAD to be rolled into
regular ref_list by adding REF_DETACHED_HEAD as a kind of branch and
supporting the same in append_ref().
Bump get_head_description() to the top.
Based-on-patch-by: Jeff King
Mentored-by: Christian Couder
Mentored-by: Matthieu Moy
Make 'branch.c' use 'ref-filter' data structures and make changes to
support the new data structures. This is a part of the process of
porting 'branch.c' to use 'ref-filter' APIs.
This is a temporary step before porting 'branch.c' to use 'ref-filter'
completely. As this is a temporary step, most o
From: Karthik Nayak
Remove unnecessary variables from ref_list and ref_item
which were used for width computation. Make other changes
accordingly. This patch is a precursor for porting branch.c
to use ref-filter APIs.
Based-on-patch-by: Jeff King
Mentored-by: Christian Couder
Mentored-by: Matt
The 'ifexists' atom allows us to print a required format if the
preceeding atom has a value. If the preceeding atom has no value then
the format given is not printed. e.g. to print "[]" we can
now use the format "%(ifexists:[%s])%(refname)".
Add documentation and test for the same.
Mentored-by: C
From: Karthik Nayak
Add an option in 'filter_refs()' to use 'for_each_branch_ref()'
and filter refs. This type checking is done by adding a
'FILTER_REFS_BRANCHES' in 'ref-filter.h'.
Add an option in 'ref_filter_handler()' to filter different
types of branches by calling 'filter_branch_kind()' wh
We check if given ref is the current branch in print_ref_list(). Move
this check to print_ref_item() where it is checked right before
printing.
Based-on-patch-by: Jeff King
Mentored-by: Christian Couder
Mentored-by: Matthieu Moy
Signed-off-by: Karthik Nayak
---
builtin/branch.c | 29
Based-on-patch-by: Jeff King
Mentored-by: Christian Couder
Mentored-by: Matthieu Moy
Signed-off-by: Karthik Nayak
---
builtin/branch.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index ba9cbad..8d0521e 100644
--- a
From: Karthik Nayak
Add support for %(objectname:size=X) where X is a number.
This will print the first X characters of an objectname.
The minimum value for X is 5. Hence any value lesser than
5 will default to 5 characters.
Mentored-by: Christian Couder
Mentored-by: Matthieu Moy
Signed-off-by
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: Gmane (v6)
http://article.gmane.org/gmane.comp.version-control.git/274726
This is a RFC version and I'm sending to ensure that I'm on the right path.
This version also doesn
From: Karthik Nayak
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' i
From: Karthik Nayak
Add support to sort by version using the "v:refname" and
"version:refname" option. This is achieved by using the 'versioncmp()'
function as the comparing function for qsort.
This option is included to support sorting by versions in `git tag -l`
which will eventaully be ported
From: Karthik Nayak
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
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.
Helpe
From: Karthik Nayak
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
From: Karthik Nayak
In 'tag.c' we can print N lines from the annotation of the tag using
the '-n' 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
Mentored-by: Matthieu Moy
Signed-of
From: Karthik Nayak
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
From: Karthik Nayak
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
Mentored-by: Matthieu Moy
Signed-off-by
From: Karthik Nayak
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
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
Mentored-by: Christian Couder
Mentored-by: Matthieu M
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 5 can be found here:
http://article.gmane.org/gmane.comp.version-control.git/274
On Mon, Jul 27, 2015 at 4:41 PM, Sina Siadat 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 loo
On Tue, Jul 28, 2015 at 6:25 AM, Eric Sunshine wrote:
> On Mon, Jul 27, 2015 at 7:38 AM, Ed Avis 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 beg
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
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 use
On Mon, Jul 27, 2015 at 7:38 AM, Ed Avis 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
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 scra
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
---
This version of the patch series addresses Junio's comments on v1.
---
t/t7509-commit.sh | 13 ---
On Mon, 2015-07-27 at 14:47 -0700, Junio C Hamano wrote:
> David Turner 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 (whic
David Turner 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
Mikael Magnusson writes:
> On Mon, Jul 27, 2015 at 10:47 PM, Junio C Hamano 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 Re
Johannes Sixt 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 mess
David Turner 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)
ensu
On Mon, Jul 27, 2015 at 10:47 PM, Junio C Hamano 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
> =
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
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
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 a
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.
O
Antoine Beaupré 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
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 scra
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
---
sequencer.c | 23 ---
1 file changed, 4 insertions(+), 19 deletions(-)
diff --git a/sequ
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
---
bisect.c | 37 -
1 file changed, 8 insertions(+), 29 deletions(-)
diff -
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
---
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 pseudo
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
-
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 cod
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 sequenc
Matthieu Moy 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
On Tue, Jul 28, 2015 at 12:17 AM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> On Mon, Jul 27, 2015 at 9:24 PM, Matthieu Moy
>> wrote:
>>> Yes, but on the other hand we already have:
>>>
>>> git log --format='%<|(50)A very long irrevlevancy|%an|'
>>>
>>> that pads/truncate %an. So, consist
Karthik Nayak writes:
> On Mon, Jul 27, 2015 at 9:24 PM, Matthieu Moy
> 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.
>
On Mon, Jul 27, 2015 at 6:20 PM, Matthieu Moy
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 u
On Mon, Jul 27, 2015 at 9:24 PM, Matthieu Moy
wrote:
> Junio C Hamano writes:
>
>> Matthieu Moy 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 i
Signed-off-by: Thomas Braun
---
> John Keeping 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
> interactiv
On Mon, Jul 27, 2015 at 7:58 PM, Junio C Hamano wrote:
> Matthieu Moy writes:
>
>> Karthik Nayak 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 e
On Mon, Jul 27, 2015 at 6:36 PM, Matthieu Moy
wrote:
> Karthik Nayak 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,
>>
On Mon, Jul 27, 2015 at 8:54 PM, Junio C Hamano wrote:
> Karthik Nayak writes:
>
>> On Sun, Jul 26, 2015 at 4:10 AM, Junio C Hamano 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
On Mon, Jul 27, 2015 at 9:36 PM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> On Mon, Jul 27, 2015 at 9:27 PM, Karthik Nayak wrote:
>>> On Mon, Jul 27, 2015 at 6:24 PM, Matthieu Moy
>>> wrote:
Karthik Nayak writes:
> --- a/ref-filter.c
> +++ b/ref-filter.c
> @@ -946,6
Karthik Nayak writes:
> On Mon, Jul 27, 2015 at 9:27 PM, Karthik Nayak wrote:
>> On Mon, Jul 27, 2015 at 6:24 PM, Matthieu Moy
>> wrote:
>>> Karthik Nayak writes:
>>>
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -946,6 +946,32 @@ static int commit_contains(struct ref_filter *filter,
On Mon, Jul 27, 2015 at 6:17 PM, Matthieu Moy
wrote:
> Karthik Nayak 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
>
On Mon, Jul 27, 2015 at 9:27 PM, Karthik Nayak wrote:
> On Mon, Jul 27, 2015 at 6:24 PM, Matthieu Moy
> wrote:
>> Karthik Nayak writes:
>>
>>> --- a/ref-filter.c
>>> +++ b/ref-filter.c
>>> @@ -946,6 +946,32 @@ static int commit_contains(struct ref_filter *filter,
>>> struct commit *commit)
>>
>
On Mon, Jul 27, 2015 at 6:24 PM, Matthieu Moy
wrote:
> Karthik Nayak 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,
Junio C Hamano writes:
> Matthieu Moy 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 sugge
Matthieu Moy 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)%(pad
On Mon, Jul 27, 2015 at 6:12 PM, Matthieu Moy
wrote:
> Karthik Nayak 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) {
Karthik Nayak writes:
> On Sun, Jul 26, 2015 at 4:10 AM, Junio C Hamano 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.
Duy Nguyen 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-ch
Matthieu Moy writes:
> Karthik Nayak 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
Paul Tan 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
Karthik Nayak 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 *v
On Mon, Jul 27, 2015 at 07:51:30PM +0700, Duy Nguyen wrote:
> On Mon, Jul 27, 2015 at 6:48 PM, Patrick Steinhardt 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
Karthik Nayak 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
On Mon, Jul 27, 2015 at 6:48 PM, Patrick Steinhardt 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
Karthik Nayak 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 <
Karthik Nayak 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
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 $branchNa
Karthik Nayak 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 's
Karthik Nayak 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 a
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
'pa
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
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.
On Mon, Jul 27, 2015 at 2:39 PM, Jacob Keller wrote:
> On Sun, Jul 26, 2015 at 5:39 PM, Duy Nguyen wrote:
>> On Sun, Jul 26, 2015 at 11:08 AM, Eric Sunshine
>> wrote:
>>> You can generate an interdiff with "git diff branchname-v4
>>> branchname-v5", for instance.
>>
>> Off topic. But what stops
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 loo
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
Jeff King 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
On Sun, Jul 26, 2015 at 5:39 PM, Duy Nguyen wrote:
> On Sun, Jul 26, 2015 at 11:08 AM, Eric Sunshine
> 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 t
From: Karthik Nayak
Add support to sort by version using the "v:refname" and
"version:refname" option. This is achieved by using the 'versioncmp()'
function as the comparing function for qsort.
This option is included to support sorting by versions in `git tag -l`
which will eventaully be ported
From: Karthik Nayak
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
Mentored-by: Matthieu Moy
Signed-off-by
From: Karthik Nayak
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
From: Karthik Nayak
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
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/
From: Karthik Nayak
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' i
From: Karthik Nayak
In 'tag.c' we can print N lines from the annotation of the tag using
the '-n' 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
Mentored-by: Matthieu Moy
Signed-of
From: Karthik Nayak
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
From: Karthik Nayak
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
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.
Helpe
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
Mentored-by: Christian Couder
Mentored-by: Matthieu M
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/2745
97 matches
Mail list logo
