Re: [PATCH 1/2] checkout: progress on non-tty. progress with lf

unsigned percent = n * 100 / progress->total; if (percent != progress->last_percent || progress_update) { Thanks! On Sat, Oct 24, 2015 at 8:59 AM, Edmundo Carmona <eantor...@gmail.com> wrote: > From: Edmundo Carmona Antoranz <eantor...@gmail.com> > > --pr

Re: [PATCH 0/2] checkout: added two options to control progress output

On Thu, Oct 29, 2015 at 4:05 PM, Jeff King <p...@peff.net> wrote: > On Sat, Oct 24, 2015 at 08:59:28AM -0600, Edmundo Carmona wrote: > >> From: Edmundo Carmona Antoranz <eantor...@gmail.com> >> >> checkout will refuse to print progress information if it's not

Re: git svn clone clone php/pear/Net_LDAP2 misses tags and branches

Using -r single-revision-number (against tha same repo), I was not able to pull much (on that revision only the standard layout was set up so nothing would come out for git) Did you try with -r revision-number:HEAD? . . . r255572 = 73d7692d844ee6baae8b4b2e5fc0f07a4118d09e

Re: git svn clone clone php/pear/Net_LDAP2 misses tags and branches

I think there's something "odd" in the way that branch was created. If I take a look at another branch: $ svn log -v --stop-on-copy https://svn.php.net/repository/pear/packages/Net_LDAP2/tags/RELEASE_2_0_0RC2 r255575 |

[PATCH v1] blame: avoid checking if a file exists on the working tree if a revision is provided

stfile1.txt HEAD fatal: cannot stat path 'testfile1.txt': No such file or directory After: $ git blame testfile1.txt fatal: Cannot lstat 'testfile1.txt': No such file or directory $ git blame testfile1.txt HEAD ^da1a96f testfile2.txt (Edmundo Carmona Antoranz 2015-11-10 17:52:00 -0600 1) testfile 2

[PATCH v2] blame: avoid checking if a file exists on the working tree if a revision is provided

stfile1.txt HEAD fatal: cannot stat path 'testfile1.txt': No such file or directory After: $ git blame testfile1.txt fatal: Cannot lstat 'testfile1.txt': No such file or directory $ git blame testfile1.txt HEAD ^da1a96f testfile2.txt (Edmundo Carmona Antoranz 2015-11-10 17:52:00 -0600 1) testfile 2

Re: [PATCH v1] blame: avoid checking if a file exists on the working tree if a revision is provided

On Mon, Nov 16, 2015 at 7:07 PM, Edmundo Carmona Antoranz <eantor...@gmail.com> wrote: > - if (!file_exists(path)) > - die_errno("cannot stat path '%s'", path); Two things: 1 What I would love to do is check if revisions were pr

Re: [PATCH v1] blame: avoid checking if a file exists on the working tree if a revision is provided

Ok... I think I got how to check revisions / file existence after revisions have been set up. Sending next patch version On Mon, Nov 16, 2015 at 7:16 PM, Edmundo Carmona Antoranz <eantor...@gmail.com> wrote: > On Mon, Nov 16, 2015 at 7:07 PM, Edmundo Carmona Antoranz > <eant

[PATCH v4] checkout: add --progress option

Under normal circumstances, and like other git commands, git checkout will write progress info to stderr if attached to a terminal. This option allows progress to be forced even if not using a terminal. Also, progress can be skipped if using option --no-progress. Signed-off-by: Edmundo Carmona

Re: [PATCH] checkout: add --progress option

On Sat, Oct 31, 2015 at 6:45 PM, Eric Sunshine wrote: > Patches in 'next' are pretty much set in stone, and those in 'master' > definitely are, but 'pu' is volatile, so just send the entire patch > revised, tagged v2 (or v3, etc.), rather than sending a patch to fix >

Re: [PATCH v5] checkout: add --progress option

Oh, man... I'm sorry... I didn't notice them. Let me go over them to see what we can do. On Sun, Nov 1, 2015 at 1:13 PM, Eric Sunshine wrote: > I'll assume that you simply overlooked the remainder of my v4 review > comments, so I'll merely provide a reference to them[1]

[PATCH v5] checkout: add --progress option

Under normal circumstances, and like other git commands, git checkout will write progress info to stderr if attached to a terminal. This option allows progress to be forced even if not using a terminal. Also, progress can be skipped if using option --no-progress. Signed-off-by: Edmundo Carmona

[PATCH v3] checkout: add --progress option

Under normal circumstances, and like other git commands, git checkout will write progress info to stderr if attached to a terminal. This option allows progress to be forced even if not using a terminal. Also, progress can be skipped if using option --no-progress. ---

Re: [PATCH v3] checkout: add --progress option

On Sun, Nov 1, 2015 at 11:22 AM, Edmundo Carmona Antoranz <eantor...@gmail.com> wrote: > + /* > +* Final processing of show_progress > +* - User selected --progress: show progress > +* - user selected --no-progress: skip progress > +*

Re: [PATCH v4] checkout: add --progress option

On Sun, Nov 1, 2015 at 11:52 AM, Eric Sunshine wrote: >> + if (opts.quiet) { >> + opts.show_progress = 0; >> + } else { >> + opts.show_progress = isatty(2); >> + } > > Style: drop

[PATCH v8] checkout: add --progress option

Under normal circumstances, and like other git commands, git checkout will write progress info to stderr if attached to a terminal. This option allows progress to be forced even if not using a terminal. Also, progress can be skipped if using option --no-progress. Signed-off-by: Edmundo Carmona

[PATCH v7] checkout: add --progress option

Under normal circumstances, and like other git commands, git checkout will write progress info to stderr if attached to a terminal. This option allows progress to be forced even if not using a terminal. Also, progress can be skipped if using option --no-progress. Signed-off-by: Edmundo Carmona

Re: [PATCH v6] checkout: add --progress option

On Sun, Nov 1, 2015 at 3:06 PM, Eric Sunshine wrote: >> +--[no-]progress:: >> + Progress status is reported on the standard error stream >> + by default when it is attached to a terminal, unless --quiet >> + is specified. This flag enables progress

Re: [PATCH v4] checkout: add --progress option

On Sun, Nov 1, 2015 at 1:29 PM, Eric Sunshine wrote: >>> > +--progress:: >>> > + Progress status is reported on the standard error stream >>> > + by default when it is attached to a terminal, unless -q >>> > + is specified. This flag forces progress

[PATCH v6] checkout: add --progress option

Under normal circumstances, and like other git commands, git checkout will write progress info to stderr if attached to a terminal. This option allows progress to be forced even if not using a terminal. Also, progress can be skipped if using option --no-progress. Signed-off-by: Edmundo Carmona

Re: [PATCH v4] checkout: add --progress option

On Sun, Nov 1, 2015 at 2:15 PM, Eric Sunshine wrote: > > Progress status is reported on the standard error stream by > default when it is attached to a terminal, unless `--quiet` is > specified. This flag enables progress reporting even if not > attached

Re: [PATCH v7] checkout: add --progress option

On Sun, Nov 1, 2015 at 3:15 PM, Eric Sunshine wrote: >> +--[no-]progress:: >> + Progress status is reported on the standard error stream >> + by default when it is attached to a terminal, unless `--quiet` >> + is specified. This flag enables progress

Re: [PATCH] checkout: add --progress option

One line got wrapped around, hope that's not a problem to understand the whole concept. > +/* > + * Any of these conditions will make progress output be skipped: > + * - selected --quiet > + * - selected --no-progress > + * - (didn't select --progress nor --no-progress) and not working on a >

Re: [PATCH] checkout: add --progress option

progress && +(opts.show_progress >= 0 || isatty(2)); + if (conflict_style) { opts.merge = 1; /* implied */ git_xmerge_config("merge.conflictstyle", conflict_style, NULL); On Fri, Oct 30, 2015 at 6:58 PM, Edm

Re: [PATCH] checkout: add --progress option

On Fri, Oct 30, 2015 at 1:37 PM, Junio C Hamano wrote: > > Actually, using a single variable is my preference. In this case I > wanted to illustrate that the value parsed by parse_options() does > not have to be the one that is used in the final location deep in > the

Re: About global --progress option

On Thu, Nov 5, 2015 at 12:11 AM, Junio C Hamano wrote: > Besides, I am not convinced that you are bringing in a net positive > value by allowing "git --no-progress clone". You would need to > think what to do when you get two conflicting options (e.g. should > "git

About global --progress option

Hi, everybody! Coming back from my patch about the --[no-]progress option for checkout (it's already in next, J), I'd like to build into the idea of the single --[no-]progress option for git as a whole. So, in order to know what/how things should be developed, let's start with a tiny survey

Re: What's cooking in git.git (Nov 2015, #02; Fri, 6)

On Fri, Nov 6, 2015 at 5:41 PM, Junio C Hamano wrote: > I'll be offline for a few weeks, and Jeff King graciously agreed to > help shepherd the project forward in the meantime as an interim > maintainer. Please be gentle. Be gentle? To Jeff??? But he's an ass Just

Re: [PATCH] checkout: refactor of --progress option

On Sat, Oct 31, 2015 at 11:10 AM, Edmundo Carmona Antoranz <eantor...@gmail.com> wrote: > by the second item on the outer short-circuited if: I meant: ...short-circuited _and operator_, sorry. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of

Re: [PATCH] checkout: add --progress option

On Sat, Oct 31, 2015 at 11:37 AM, Junio C Hamano wrote: > I do find what Peff showed us a lot easier to follow. > > if (opts.show_progress < 0) { > if (opts.quiet) > opts.show_progress = 0; > else >

Re: [PATCH] checkout: refactor of --progress option

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

Re: [PATCH] checkout: add --progress option

I just noticed something interesting. On Sat, Oct 31, 2015 at 11:42 AM, Edmundo Carmona Antoranz <eantor...@gmail.com> wrote: > On Sat, Oct 31, 2015 at 11:37 AM, Junio C Hamano <gits...@pobox.com> wrote: >> I do find what Peff showed us a lot easier to follow. >> >&g

[PATCH v2] checkout: refactor of --progress option

- removed static variable show_progress - processing if progress will be shown or not right after running parse_options() Signed-off-by: Edmundo Carmona Antoranz <eantor...@gmail.com> --- builtin/checkout.c | 38 +- 1 file changed, 21 insertions(

[PATCH] checkout: add --progress option

Under normal circumstances, and like other git commands, git checkout will write progress info to stderr if attached to a terminal. This option allows progress to be forced even if not using a terminal. Also, progress can be skipped if using option --no-progress. Signed-off-by: Edmundo Carmona

[PATCH] checkout: refactor of --progress option

- removed static variable show_progress - processing if progress will be shown or not right after running parse_options() Signed-off-by: Edmundo Carmona Antoranz <eantor...@gmail.com> --- builtin/checkout.c | 32 +++- 1 file changed, 15 insertions(+), 17 del

Re: [PATCH] checkout: refactor of --progress option

On Sat, Oct 31, 2015 at 10:57 AM, Edmundo Carmona Antoranz <eantor...@gmail.com> wrote: > + /* > +* Final processing of show_progress > +* Any of these 3 conditions will make progress output be skipped: > +* - selected --quiet > +* - s

Re: [PATCH v2] blame: avoid checking if a file exists on the working tree if a revision is provided

On Tue, Nov 17, 2015 at 5:37 PM, Edmundo Carmona Antoranz <eantor...@gmail.com> wrote: > So, do I forget about the blame patch (given that I'm not fixing an > advertised syntax, even if it's supported) and fix annotate instead or > do I fix both? And if I should swing for bo

Re: [PATCH v2] blame: avoid checking if a file exists on the working tree if a revision is provided

On Mon, Nov 16, 2015 at 11:11 PM, Eric Sunshine wrote: > > This subject is a bit long; try to keep it to about 72 characters or less. > > More importantly, though, it doesn't give us a high level overview of > the purpose of the patch, which is that it is fixing blame to

[PATCH v1] annotate: skip checking working tree if a revision is provided

If a file has been deleted/renamed, annotate refuses to work because the file does not exist on the working tree anymore (even if the path provided does match a blob on said revision). Signed-off-by: Edmundo Carmona Antoranz <eantor...@gmail.com> --- builtin/blame.c | 5 +++-- t/an

Re: What's cooking in git.git (Dec 2015, #02; Fri, 4)

Hi, Junio, Jeff! On Fri, Dec 4, 2015 at 5:15 PM, Junio C Hamano wrote: > * ec/annotate-deleted (2015-11-20) 1 commit > - annotate: skip checking working tree if a revision is provided > > Usability fix for annotate-specific " " syntax with deleted > files. > > Waiting for

Re: [PATCH v5] blame: add support for --[no-]progress option

Hey, Eric! On Tue, Dec 8, 2015 at 2:22 AM, Eric Sunshine <sunsh...@sunshineco.com> wrote: > On Tue, Nov 24, 2015 at 11:36 PM, Edmundo Carmona Antoranz > <eantor...@gmail.com> wrote: >> * created struct progress_info in builtin/blame.c >> this struct holds t

Re: Help debugging git-svn

On Wed, Dec 16, 2015 at 1:41 AM, Eric Wong wrote: > > Any chance you can reproduce this on a Linux system? > I do not use non-Free systems and have no debugging experience > there at all. > My wish But it's a big resounding "no". >> With my very flawed knowledge of

Re: [PATCH v6] blame: add support for --[no-]progress option

On Sat, Dec 12, 2015 at 6:17 PM, Eric Sunshine wrote: > Right here below the "---" line would be a good place to explain what > changed since the previous version. As an aid for reviewers, it's also > helpful to provide a link to the previous round, like this[1]. > > [1]:

Re: [PATCH v6] blame: add support for --[no-]progress option

On Sat, Dec 12, 2015 at 6:30 PM, Edmundo Carmona Antoranz <eantor...@gmail.com> wrote: >> >> The 'show_progress = 0' seems unnecessary. What if you did something >> like this instead? >> >> if (show_progress > 0 && (incremental || &

Re: [PATCH v6] blame: add support for --[no-]progress option

On Sat, Dec 12, 2015 at 6:37 PM, Eric Sunshine wrote: >> >> Because, if the user didn't provide --[no-]progress option, then the >> value in show_progress will move forward being -1 and then in >> assign_blame, there will be progress output if you chose --incremental >>

[PATCH v7] blame: add support for --[no-]progress option

--progress can't be used with --incremental or porcelain formats. git-annotate inherits the option as well Helped-by: Eric Sunshine <sunsh...@sunshineco.com> Signed-off-by: Edmundo Carmona Antoranz <eantor...@gmail.com> --- Documentation/blame-options.txt | 7 +++ Docum

[PATCH v6] blame: add support for --[no-]progress option

--progress can't be used with --incremental or porcelain formats. git-annotate inherits the option as well Helped-by: Eric Sunshine <sunsh...@sunshineco.com> Signed-off-by: Edmundo Carmona Antoranz <eantor...@gmail.com> --- Documentation/blame-options.txt | 7 +++ Docum

Re: [PATCH v6] blame: add support for --[no-]progress option

On Sat, Dec 12, 2015 at 5:57 PM, Edmundo Carmona Antoranz <eantor...@gmail.com> wrote: > + if (incremental || (output_option & OUTPUT_PORCELAIN)) { > + if (show_progress > 0) > + die("--progress can't be used with --incremen

Help debugging git-svn

Hello, Eric, Everybody! I need your help getting git-svn to clone a repository. I had already cloned it once but then a few months ago I discovered the authors map file and it's like the first time I did a checkout using git well, perhaps not that much, but close. Seeing the real names of

Re: Help debugging git-svn

in advance. On Wed, Dec 16, 2015 at 6:36 AM, Edmundo Carmona Antoranz <eantor...@gmail.com> wrote: > On Wed, Dec 16, 2015 at 1:41 AM, Eric Wong <normalper...@yhbt.net> wrote: >> >> Any chance you can reproduce this on a Linux system? >> I do not use non-Free systems

Forcing git to pack objects

Hi! Recently I was running manually a git gc --prune command (wanted to shrink my 2.8G .git directory by getting rid of loose objects) and I ended up running out of space on my HD. After freaking out a little bit (didn't know if the repo would end up in a 'stable' state), I ended up freeing up

Re: Help debugging git-svn

On Fri, Dec 18, 2015 at 11:28 AM, Edmundo Carmona Antoranz <eantor...@gmail.com> wrote: > Ok I came up with another idea to avoid having to deal with the > old svn history (I'm having no problems fetching/dcommitting with my > current repo). I already have the branches I work

Re: [PATCH v4] blame: add support for --[no-]progress option

On Mon, Nov 23, 2015 at 11:57 PM, Torsten Bögershausen wrote: > Minor remark: The '*' should be close to the variable: "struct progress_info > *pi" Nice catch, Torsten. I had already caught it as the standard... that one slipped by. Was waiting for more comments to show up, but

[PATCH v5] blame: add support for --[no-]progress option

* created struct progress_info in builtin/blame.c this struct holds the information used to display progress so that only one additional parameter is passed to found_guilty_entry(). * --[no-]progress option is also inherited by git-annotate. Signed-off-by: Edmundo Carmona Antoranz <ean

Re: [PATCH v1] annotate: skip checking working tree if a revision is provided

On Tue, Nov 17, 2015 at 7:20 PM, Edmundo Carmona Antoranz <eantor...@gmail.com> wrote: > + if (!revs.pending.nr && !file_exists(path)) > + die_errno("cannot stat path '%s'", path); > + I was wondering if I should only check the path that is co

Re: [PATCH v1] annotate: skip checking working tree if a revision is provided

And I did't say it right. The execution path where dashdash_pos is 0 is coming from "annotate". Sorry for my confusion on the previous mail. On Fri, Nov 20, 2015 at 7:25 PM, Edmundo Carmona Antoranz <eantor...@gmail.com> wrote: > On Tue, Nov 17, 2015 at 7:20 PM, Edmundo Carmona

[PATCH v3] blame: add support for --[no-]progress option

* created struct progress_info in builtin/blame.c this struct holds the information used to display progress so that only one additional parameter is passed to found_guilty_entry(). * --[no-]progress option is also inherited by git-annotate. Signed-off-by: Edmundo Carmona Antoranz <ean

Re: [PATCH v3] blame: add support for --[no-]progress option

On Sun, Nov 22, 2015 at 11:12 PM, Edmundo Carmona Antoranz <eantor...@gmail.com> wrote: > +struct progress_info { > + struct progress *progress; > + int blamed_lines; > +}; > + This is valid, right? Adding 2 more parameters to found_guilty_entry() sounded like an

Re: [PATCH v2] blame: add support for --[no-]progress option

Nice to see you back, Junio! On Sun, Nov 22, 2015 at 8:08 PM, Junio C Hamano <gits...@pobox.com> wrote: > Edmundo Carmona Antoranz <eantor...@gmail.com> writes: > >> Will also affect annotate > > Is that a good thing? In any case, make it understandable witho

Re: [PATCH v1] blame: add support for --[no-]progress option

I think I found where to calculate the number of blamed lines without having to do it from scratch every cycle. It's where the list of sb->ent is getting its nodes pointed around here: for (;;) { struct blame_entry *next = ent->next; found_guilty_entry(ent); if (next) {

[PATCH v1] blame: add support for --[no-]progress option

Will also affect annotate Signed-off-by: Edmundo Carmona Antoranz <eantor...@gmail.com> --- Documentation/blame-options.txt | 7 +++ Documentation/git-blame.txt | 9 - builtin/blame.c | 39 --- 3 files changed, 51 inse

[PATCH v2] blame: add support for --[no-]progress option

Will also affect annotate Signed-off-by: Edmundo Carmona Antoranz <eantor...@gmail.com> --- Documentation/blame-options.txt | 7 +++ Documentation/git-blame.txt | 9 - builtin/blame.c | 25 +++-- 3 files changed, 38 insertions(+), 3 del

Re: [PATCH v1] blame: add support for --[no-]progress option

On Sat, Nov 21, 2015 at 11:27 PM, Edmundo Carmona Antoranz <eantor...@gmail.com> wrote: > -static void assign_blame(struct scoreboard *sb, int opt) > +static void assign_blame(struct scoreboard *sb, int opt, int show_progress) > > Would it be better to include show_progress as a

Re: [PATCH v1] blame: add support for --[no-]progress option

Hey, guys! Time for some more patch destruction. On Sat, Nov 21, 2015 at 11:11 PM, Edmundo Carmona Antoranz <eantor...@gmail.com> wrote: -static void assign_blame(struct scoreboard *sb, int opt) +static void assign_blame(struct scoreboard *sb, int opt, int show_progress) Would it be

Re: [PATCH v2] blame: add support for --[no-]progress option

t;j...@kdbg.org> wrote: > Am 22.11.2015 um 17:02 schrieb Edmundo Carmona Antoranz: >> >> Will also affect annotate >> >> Signed-off-by: Edmundo Carmona Antoranz <eantor...@gmail.com> >> --- >> Documentation/blame-options.txt | 7 +++ >> Do

Re: [PATCH v4] blame: add support for --[no-]progress option

On Mon, Nov 23, 2015 at 7:07 PM, Edmundo Carmona Antoranz <eantor...@gmail.com> wrote: > { > struct rev_info *revs = sb->revs; > struct commit *commit = prio_queue_get(>commits); > + struct progress_info *pi = NULL; Switched to using pointer

[PATCH v4] blame: add support for --[no-]progress option

* created struct progress_info in builtin/blame.c this struct holds the information used to display progress so that only one additional parameter is passed to found_guilty_entry(). * --[no-]progress option is also inherited by git-annotate. Signed-off-by: Edmundo Carmona Antoranz <ean

Re: A little help understanding output from git blame --reverse

On Mon, Feb 6, 2017 at 6:38 AM, Edmundo Carmona Antoranz <eantor...@gmail.com> wrote: > I'm "difflaming" HEAD~100 (02db2d0421b97fcb6211) and HEAD > (066fb0494e6398eb). Specifically file abspath.c. I just noticed that I'm standing on a private branch. Replace HEAD for "

A little help understanding output from git blame --reverse

Hi! While doing some research developing difflame I found some output from git blame --reverse that I can't quite understand. Perhaps another set of eyeballs could help me. I'm "difflaming" HEAD~100 (02db2d0421b97fcb6211) and HEAD (066fb0494e6398eb). Specifically file abspath.c. If we diff (as

Re: difflame

On Thu, Feb 2, 2017 at 10:46 PM, Edmundo Carmona Antoranz <eantor...@gmail.com> wrote: > I have been "scripting around git blame --reverse" for some days now. > Mind taking a look? I've been working on blame-deletions for this. blame-deletions branch, that is Sorry for the previous top-posting.

Re: difflame

on around git blame --reverse. Thanks in advance. On Mon, Jan 30, 2017 at 8:37 PM, Edmundo Carmona Antoranz <eantor...@gmail.com> wrote: > Maybe a little work on blame to get the actual revision where some > lines were "deleted"? > > Something like git blame --

Re: [PATCH] blame: add option to print tips (--tips)

On Sun, Jan 22, 2017 at 4:58 PM, Junio C Hamano wrote: > > What is the target audience? If you are trying to write a script > that reads output by "git blame", you are strongly discouraged > unless you are reading from "git blame --porcelain" which is more > compact and has

Re: [PATCH] blame: add option to print tips (--tips)

HA1_HEXSZ + 1]; cee7f245dc: git-pickaxe: blame rewritten. cee7f245dc builtin-pickaxe.c (Junio C Hamano 2006-10-19 16:00:04 -0700 1942) int show_raw_time = !!(opt & OUTPUT_RAW_TIMESTAMP); f2aea1696f: blame: add option to print tips (--tips) f2aea1696f builtin/blame.c (Edmundo

Re: Does it make sense to show tips on blame?

On Sun, Jan 22, 2017 at 4:25 PM, Junio C Hamano <gits...@pobox.com> wrote: > Edmundo Carmona Antoranz <eantor...@gmail.com> writes: > > What does the word "tip" mean in this context? The word is often > used to mean the commits directly pointed at by branches (i.

[PATCH] blame: add option to print tips (--tips)

--- builtin/blame.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/builtin/blame.c b/builtin/blame.c index 126b8c9e5..4bc449f40 100644 --- a/builtin/blame.c +++ b/builtin/blame.c @@ -1884,6 +1884,7 @@ static const char *format_time(unsigned long time, const char

Re: [PATCH] [draft]blame: add --aggregate option

in aggregation. In relation to the previous conversation about "tips", I think a better name could be "hints" and it could be added on top of the aggregation. On Mon, Jan 23, 2017 at 8:10 PM, Edmundo Carmona Antoranz <eantor...@gmail.com> wrote: > --- > built

[PATCH] [draft]blame: add --aggregate option

--- builtin/blame.c | 78 + 1 file changed, 51 insertions(+), 27 deletions(-) diff --git a/builtin/blame.c b/builtin/blame.c index 126b8c9e5..9e8403303 100644 --- a/builtin/blame.c +++ b/builtin/blame.c @@ -1884,6 +1884,7 @@ static const

[PATCH v1 3/3] blame: add --color option

Revision information will be highlighted so that it's easier to tell from content of the file being "blamed". Signed-off-by: Edmundo Carmona Antoranz <eantor...@gmail.com> --- Documentation/blame-options.txt | 5 + Documentation/git-blame.txt | 2 +-

[PATCH v1 2/3] blame: add --hint option

When printing aggregate information about revisions, this option allows to add the 1-line summary of the revision to provide the reader with some additional context about the revision itself. Signed-off-by: Edmundo Carmona Antoranz <eantor...@gmail.com> --- Documentation/blame-options.tx

[PATCH v1 1/3] blame: add --aggregate option

To avoid taking up so much space on normal output printing duplicate information on consecutive lines that "belong" to the same revision, this option allows to print a single line with the information about the revision before the lines of content themselves. Signed-off-by: Edmun

Re: difflame

. On Mon, Jan 30, 2017 at 5:26 PM, Jeff King <p...@peff.net> wrote: > On Mon, Jan 30, 2017 at 01:08:41PM -0800, Junio C Hamano wrote: > >> Jeff King <p...@peff.net> writes: >> >> > On Tue, Jan 17, 2017 at 11:24:02PM -0600, Edmundo Carmona Antoranz wrote: >&

Re: difflame

Maybe a little work on blame to get the actual revision where some lines were "deleted"? Something like git blame --blame-deletion that could be based on --reverse? On Mon, Jan 30, 2017 at 7:35 PM, Edmundo Carmona Antoranz <eantor...@gmail.com> wrote: > I'm thinkin

Re: [PATCH] blame: draft of line format

I'm basing in on the "pretty API" so that we don't have to reinvent the wheel. I have already noticed that many of the formatting options available for pretty are not working... I'm sure it would require some work setting up the call to pretty api but the basic is laid out there. Let me know of

[PATCH] blame: draft of line format

--- builtin/blame.c | 24 1 file changed, 24 insertions(+) diff --git a/builtin/blame.c b/builtin/blame.c index 126b8c9e5..89c1a862d 100644 --- a/builtin/blame.c +++ b/builtin/blame.c @@ -52,6 +52,7 @@ static int xdl_opts; static int abbrev = -1; static int

Does it make sense to show tips on blame?

Hi! I'm having fun with difflame. I added support for an option called 'tips' which would display 1-line summary of a block of added lines that belong to the same revision, in order to provide context while reading difflame output without having to run an additional git show command. Output is

Re: difflame improvements

On Fri, Feb 17, 2017 at 1:01 AM, Edmundo Carmona Antoranz <eantor...@gmail.com> wrote: > On Thu, Feb 16, 2017 at 11:17 PM, Jeff King <p...@peff.net> wrote: > >> This isn't difflame's fault; that's what "git blame" tells you about >> that line. But sin

Re: difflame improvements

On Thu, Feb 16, 2017 at 11:17 PM, Jeff King wrote: > This isn't difflame's fault; that's what "git blame" tells you about > that line. But since I already told difflame "v2.6.5..HEAD", it would > probably make sense to similarly limit the blame to that range. That > turns up a

difflame improvements

Hi! I've been working on detecting revisions where a "real" deletion was made and I think I advanced a lot in that front. I still have to work on many scenarios (renamed files, for example... also performance) but at least I'm using a few runs against git-scm history and the results are

difflame

on the project itself: ✔ ~/difflame [master L|⚑ 1] 23:21 $ ./difflame.py HEAD~3 HEAD~ diff --git a/README.txt b/README.txt new file mode 100644 index 000..a82aa27 --- /dev/null +++ b/README.txt @@ -0,0 +1,11 @@ +3d426842 (Edmundo Carmona Antoranz 2017-01-17 22:26:18 -0600 1) difflame +3d426842

blame --line-porcelain is providing me with funny output

Hi, everybody! As part of my improvements to difflame I want to use revision information as provided by blame --line-porcelain so that I can avoid some git calls to cat-file -p to get revision information hoping that information would be a match. However I'm not finding that to be the case. $

Re: [PATCH] bisect: add quit command

I found out about "git bisect reset HEAD" while working on "git bisect quit" but I think it's still worth it. Let me know. On Sat, Mar 25, 2017 at 3:17 PM, Edmundo Carmona Antoranz <eantor...@gmail.com> wrote: > git bisect quit will call git reset HEAD so th

[PATCH] bisect: add quit command

git bisect quit will call git reset HEAD so that the working tree remains at the current revision --- Documentation/git-bisect.txt | 12 git-bisect.sh| 11 ++- 2 files changed, 22 insertions(+), 1 deletion(-) diff --git a/Documentation/git-bisect.txt

Re: [PATCH] blame: draft of line format

On Tue, Jan 31, 2017 at 1:41 PM, Jeff King <p...@peff.net> wrote: > On Mon, Jan 30, 2017 at 08:28:30PM -0600, Edmundo Carmona Antoranz wrote: > >> +static void pretty_info(char* revid, struct blame_entry *ent, struct strbuf >> *rev_buffer) >> +{ >> +

difflame improvements

full_revision e5b218e4 (Edmundo 2017-02-01 370) return full_revision 91b7d3f5 (Edmundo 2017-01-31 371) Notice how the revision reported in both difflame calls is the same: $ git show b1a66932 commit b1a66932704245fd653f8d48c0a718f168f334a7 Author: Edmundo Carmona Antoranz <whoca...@gmail.co