From: Edmundo Carmona Antoranz
checkout will refuse to print progress information if it's not connected
to a TTY. These patches will add two options:
--progress-no-tty: enable printing progress info even if not using a TTY
--progress-lf: print progress information using LFs instead of CR
From: Edmundo Carmona Antoranz
--progress-no-tty: option to write progress even if not working on a TTY
--progress-lf: option to print progress using LF instead of CR
Signed-off-by: Edmundo Carmona Antoranz
---
builtin/checkout.c | 12 ++--
progress.c | 8 +++-
progress.h
From: Edmundo Carmona Antoranz
Signed-off-by: Edmundo Carmona Antoranz
---
Documentation/git-checkout.txt | 10 ++
1 file changed, 10 insertions(+)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index e269fb1..4ff270c 100644
--- a/Documentation/git
t now 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
+3d4
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 li
---
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 *tz_st
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
On Sun, Jan 22, 2017 at 4:25 PM, Junio C Hamano wrote:
> Edmundo Carmona Antoranz 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.e. the
> tip of history), but I do not t
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 this information alrea
---
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 cha
e -t still work 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
wrote:
> ---
> builtin/blame.c | 78
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
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
---
Documentation/blame-options.txt | 5 +
Documentation/git-blame.txt | 2 +-
builtin/blame.c | 13 +
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
---
Documentation/blame-options.txt | 4
Documentation
On Mon, Jan 30, 2017 at 5:26 PM, Jeff King wrote:
> On Mon, Jan 30, 2017 at 01:08:41PM -0800, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > On Tue, Jan 17, 2017 at 11:24:02PM -0600, Edmundo Carmona Antoranz wrote:
>> >
>> >> For a ver
---
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 no_whole_fil
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 yo
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
wrote:
> I'm thinking of something like this:
>
&g
everse.
Thanks in advance.
On Mon, Jan 30, 2017 at 8:37 PM, Edmundo Carmona Antoranz
wrote:
> 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 Thu, Feb 2, 2017 at 10:46 PM, Edmundo Carmona Antoranz
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.
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 i
On Mon, Feb 6, 2017 at 6:38 AM, Edmundo Carmona Antoranz
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
"4e59582ff"
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 "promising
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 boundary commit for
On Fri, Feb 17, 2017 at 1:01 AM, Edmundo Carmona Antoranz
wrote:
> 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 "v
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 wrote:
> From: Edmundo Carmona Antoranz
>
> --progress-no-tty: option to write progress even if not working
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 (refs/remotes/svn/trunk
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 | cvs2sv
On Thu, Oct 29, 2015 at 4:05 PM, Jeff King wrote:
> On Sat, Oct 24, 2015 at 08:59:28AM -0600, Edmundo Carmona wrote:
>
>> From: Edmundo Carmona Antoranz
>>
>> checkout will refuse to print progress information if it's not connected
>> to a TTY. These patches
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
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 callchain for educational pu
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
> ter
nd not working on a terminal
+*/
+ opts.show_progress = !opts.quiet && opts.show_progress &&
+(opts.show_progress >= 0 || isatty(2));
+
if (conflict_style) {
opts.merge = 1; /* implied */
git_xmerge_co
- removed static variable show_progress
- processing if progress will be shown or not right
after running parse_options()
Signed-off-by: Edmundo Carmona Antoranz
---
builtin/checkout.c | 32 +++-
1 file changed, 15 insertions(+), 17 deletions(-)
diff --git a
On Sat, Oct 31, 2015 at 10:57 AM, Edmundo Carmona Antoranz
wrote:
> + /*
> +* Final processing of show_progress
> +* Any of these 3 conditions will make progress output be skipped:
> +* - selected --quiet
> +* - selected --no-progress
> +
On Sat, Oct 31, 2015 at 11:10 AM, Edmundo Carmona Antoranz
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 a message to majord...@vger.ke
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
> opts.show_p
I just noticed something interesting.
On Sat, Oct 31, 2015 at 11:42 AM, Edmundo Carmona Antoranz
wrote:
> 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)
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
- removed static variable show_progress
- processing if progress will be shown or not right
after running parse_options()
Signed-off-by: Edmundo Carmona Antoranz
---
builtin/checkout.c | 38 +-
1 file changed, 21 insertions(+), 17 deletions(-)
diff --git a
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
> what is in 'pu', and Junio wi
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.
---
Documentation/git-checkout.txt
On Sun, Nov 1, 2015 at 11:22 AM, Edmundo Carmona Antoranz
wrote:
> + /*
> +* Final processing of show_progress
> +* - User selected --progress: show progress
> +* - user selected --no-progress: skip progress
> +* - User didn't specify:
>
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
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 unnecessary braces
>
Ok. WIll d
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
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] rather than
> repeating my
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 status even if the
>>> > +
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 to a terminal, regardless o
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
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
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 reporting even if not
>> +
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 reporting even if not
>> +
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
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
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 --no-progress clone --progress"
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 kidding, man! Way to go, P
t blame testfile1.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
On Mon, Nov 16, 2015 at 7:07 PM, Edmundo Carmona Antoranz
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 provided. Somethi
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
wrote:
> On Mon, Nov 16, 2015 at 7:07 PM, Edmundo Carmona Antoranz
> wrote:
>> - if (
t blame testfile1.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
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 work on
> a file at a give
On Tue, Nov 17, 2015 at 5:37 PM, Edmundo Carmona Antoranz
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 both, do I create a single
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
---
builtin/blame.c | 5 +++--
t/annotate-tests.sh | 20
On Tue, Nov 17, 2015 at 7:20 PM, Edmundo Carmona Antoranz
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 coming from
"b
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
wrote:
> On Tue, Nov 17, 2015 at 7:20 PM, Edmundo Carmona Antoranz
>
Will also affect annotate
Signed-off-by: Edmundo Carmona Antoranz
---
Documentation/blame-options.txt | 7 +++
Documentation/git-blame.txt | 9 -
builtin/blame.c | 39 ---
3 files changed, 51 insertions(+), 4 deletions
Hey, guys!
Time for some more patch destruction.
On Sat, Nov 21, 2015 at 11:11 PM, Edmundo Carmona Antoranz
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
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) {
ent
On Sat, Nov 21, 2015 at 11:27 PM, Edmundo Carmona Antoranz
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 binary flag in opt
&g
Will also affect annotate
Signed-off-by: Edmundo Carmona Antoranz
---
Documentation/blame-options.txt | 7 +++
Documentation/git-blame.txt | 9 -
builtin/blame.c | 25 +++--
3 files changed, 38 insertions(+), 3 deletions(-)
diff --git a
, Johannes Sixt wrote:
> Am 22.11.2015 um 17:02 schrieb Edmundo Carmona Antoranz:
>>
>> Will also affect annotate
>>
>> Signed-off-by: Edmundo Carmona Antoranz
>> ---
>> Documentation/blame-options.txt | 7 +++
>> Documentation/git-blame.txt
Nice to see you back, Junio!
On Sun, Nov 22, 2015 at 8:08 PM, Junio C Hamano wrote:
> Edmundo Carmona Antoranz writes:
>
>> Will also affect annotate
>
> Is that a good thing? In any case, make it understandable without
> the title line (i.e. make it a full sentence, endi
* 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
On Sun, Nov 22, 2015 at 11:12 PM, Edmundo Carmona Antoranz
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 overkill so I joined
* 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
On Mon, Nov 23, 2015 at 7:07 PM, Edmundo Carmona Antoranz
wrote:
> {
> struct rev_info *revs = sb->revs;
> struct commit *commit = prio_queue_get(&sb->commits);
> + struct progress_info *pi = NULL;
Switched to using pointer to make it more elegant.
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 none so far so I'
* 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
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 review.
Is there so
Hey, Eric!
On Tue, Dec 8, 2015 at 2:22 AM, Eric Sunshine wrote:
> On Tue, Nov 24, 2015 at 11:36 PM, Edmundo Carmona Antoranz
> wrote:
>> * created struct progress_info in builtin/blame.c
>> this struct holds the information used to display progress so
>> that only
--progress can't be used with --incremental or
porcelain formats.
git-annotate inherits the option as well
Helped-by: Eric Sunshine
Signed-off-by: Edmundo Carmona Antoranz
---
Documentation/blame-options.txt | 7 +++
Documentation/git-blame.txt | 3 ++-
builtin/bl
On Sat, Dec 12, 2015 at 5:57 PM, Edmundo Carmona Antoranz
wrote:
> + if (incremental || (output_option & OUTPUT_PORCELAIN)) {
> + if (show_progress > 0)
> + die("--progress can't be used with --increment
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]: http://thread.gmane.org/g
On Sat, Dec 12, 2015 at 6:30 PM, Edmundo Carmona Antoranz
wrote:
>>
>> The 'show_progress = 0' seems unnecessary. What if you did something
>> like this instead?
>>
>> if (show_progress > 0 && (incremental ||
>> (output_opti
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
>> or porcelain. So, if you ch
--progress can't be used with --incremental or
porcelain formats.
git-annotate inherits the option as well
Helped-by: Eric Sunshine
Signed-off-by: Edmundo Carmona Antoranz
---
Documentation/blame-options.txt | 7 +++
Documentation/git-blame.txt | 3 ++-
builtin/bl
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 peo
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 perl I have seen that the
files
are built?
Thanks in advance.
On Wed, Dec 16, 2015 at 6:36 AM, Edmundo Carmona Antoranz
wrote:
> 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 expe
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 som
On Fri, Dec 18, 2015 at 11:28 AM, Edmundo Carmona Antoranz
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 with, the thing
---
wt-status.c | 49 +++--
wt-status.h | 1 +
2 files changed, 44 insertions(+), 6 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 0bccef542f..2a7627b331 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1118,11 +1118,24 @@ static void show_mer
t-rebuash.sh
new file mode 100644
index 00..93c14cb9cc
--- /dev/null
+++ b/git-rebuash.sh
@@ -0,0 +1,324 @@
+#!/bin/bash
+# Copyright 2019 Edmundo Carmona Antoranz
+
+# Released under the terms of GPLv2
+
+# Rebuash will be used mainly when you want to squash and rebase
+# so that you don&#x
On Sat, Jun 29, 2019 at 11:18 PM Edmundo Carmona Antoranz
wrote:
>
> ---
> wt-status.c | 49 +++--
> wt-status.h | 1 +
> 2 files changed, 44 insertions(+), 6 deletions(-)
>
I bet there are more things to do... like:
- what happen
On Sun, Jun 30, 2019 at 12:54 AM Jeff King wrote:
>
>
> and then do:
>
> git merge --squash feature
>
> I get the same merge that rebuash is doing (with R6 as the merge base,
> so we see F5 and R7 conflicting with each other). And then when I finish
> it with "git commit", the result is a linear
On Sun, Jun 30, 2019 at 4:39 PM Jeff King wrote:
>
>
> But perhaps the squashed version is easier to work with for further
> modifications? I'm not sure how, though. Certainly in your example
> rewriting changes in F1 with "rebase --interactive" would be a pain. But
> I think the end-state of the
On Mon, Jul 1, 2019 at 12:51 PM Junio C Hamano wrote:
>
>
> That part is understandable, but is "rebase-and-squash" a tool
> intended to be used by the contributor to respond to that request?
>
> Wouldn't the developer just do
>
> git checkout topic
> git fetch
> git rebase
---
builtin/merge.c | 63 +
1 file changed, 32 insertions(+), 31 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index 6e99aead46..d5745a7888 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -64,6 +64,7 @@ static int option_edit = -
On Fri, Jul 5, 2019 at 10:56 AM Edmundo Carmona Antoranz
wrote:
>
> ---
> builtin/merge.c | 63 +
> 1 file changed, 32 insertions(+), 31 deletions(-)
>
This would be a first step in order to achieve the dream of having
rebase/squ
1 - 100 of 117 matches
Mail list logo
