On Thu, Jul 18, 2019 at 11:40 PM Edmundo Carmona Antoranz
wrote:
>
> Using --squash made git stop regardless of conflicts so that the
> user could finish the operation with a later call to git-commit.
>
> Now --squash --commit allows for the operation to finish with the
> new
will be set to squashed revisions by calling
squash_message()), sets the reflog message to specify that it was
a merge-squash operation and removes the $GIT_DIR/SQUASH_MSG file
if needed.
Signed-off-by: Edmundo Carmona Antoranz
---
builtin/merge.c
On Wed, Jul 17, 2019 at 6:41 PM Edmundo Carmona Antoranz
wrote:
>
>
> Does it make sense to keep this file in those two situations?
yes it does. disregard the question.
On Wed, Jul 17, 2019 at 12:07 PM Junio C Hamano wrote:
>
> Sure. I started skimming and then gave up after seeing that quite a
> lot of code has been shuffled around without much explanation (e.g.
> printing of "Squash commit -- not updating HEAD" is gone from the
> callee and now it is a respons
On Fri, Jul 12, 2019 at 11:18 PM Edmundo Carmona Antoranz
wrote:
>
> Option -m can be used to defined the message for the revision instead
> of the default message that contains all squashed revisions info.
>
I have noticed that just adding the support for -m in squash is more
compl
On Fri, Jul 12, 2019 at 11:18 PM Edmundo Carmona Antoranz
wrote:
> @@ -1342,18 +1354,8 @@ int cmd_merge(int argc, const char **argv, const char
> *prefix)
> if (verbosity < 0)
> show_diffstat = 0;
>
> - if (squash) {
> - i
defined the message for the revision instead
of the default message that contains all squashed revisions info.
Signed-off-by: Edmundo Carmona Antoranz
---
builtin/merge.c | 109 +---
1 file changed, 57 insertions(+), 52 deletions(-)
diff --git a/builtin
in the loop where
an automerge succeeds. Also group the actions that are
performed after an automerge succeeds together to a single
location, outside and after the loop.
Signed-off-by: Edmundo Carmona Antoranz
---
builtin/merge.c | 53 +++--
1 file ch
On Mon, Jul 8, 2019 at 2:15 PM Junio C Hamano wrote:
> In the body of the proposed commit log message, please finish each
> sentence with a full-stop.
Ok
>
> These bullets are all subjective, and do not add any value to what
> you already said in the second sentence.
Ok
>
> These are facts th
On Sat, Jul 6, 2019 at 6:00 PM Edmundo Carmona Antoranz
wrote:
> @@ -1645,6 +1631,7 @@ int cmd_merge(int argc, const char **argv, const char
> *prefix)
> * auto resolved the merge cleanly.
> */
> if (automerge_was_ok) {
> + write_tree_tr
will run through best_strategy
- Easier to see that in case of ret being 2, cycle will continue
- Keep a single break case (when automerge succedes and a revision will
be created)
- Put together closing actions when automerge succedes if a revision
will be created
Signed-off-by: Edmundo Carmona
variable ret used in cmd_merge introduced in d5a35c114ab was already
a local variable used inside a for loop inside the function.
for-local variable is being renamed to ret_try_merge to avoid shadow.
---
builtin/merge.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff
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
---
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 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
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 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 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
---
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
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
wrote:
> git bisect quit will call git reset HEAD so that the working tree
>
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 b/Documen
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.
$ git
On Tue, Jan 31, 2017 at 1:41 PM, Jeff King 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)
>> +{
>> + struct pretty_print_cont
HE[revision] =
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
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
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
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 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!
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 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.
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?
>
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
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
---
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
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
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
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 +
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
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
---
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
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
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
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
---
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
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
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
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
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
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
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
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
--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 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
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: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 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
--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
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
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
* 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 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'
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.
* 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
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
, 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
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
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
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
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
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
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
>
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
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 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
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
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
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 (
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
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 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
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"
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
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: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
>> +
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
>> +
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 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
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
>>> > +
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
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
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.
---
Documentation/git-checkout.txt
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
- 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
1 - 100 of 114 matches
Mail list logo
