t no, not nested rebases.
> >
> > The closest we thought about was re-scheduling the latest commits,
> > which is now harder because of the `--rebase-merges` mode.
> >
> > But I think it would be doable. Your idea of a "nested" rebase actually
> > op
On Mon, Nov 26, 2018 at 09:03:37PM +0100, SZEDER Gábor wrote:
> Test scripts checking 'git daemon' stop the daemon with a TERM signal,
> and the 'stop_git_daemon' helper checks the daemon's exit status to
> make sure that it indeed died because of that signal.
>
> This check is bogus since
On Tue, 4 Dec 2018 at 03:23, Junio C Hamano wrote:
>
> Martin Ågren writes:
>
> > Some items that should be in "Performance, Internal Implementation,
> > Development Support etc." have ended up in "UI, Workflows & Features"
> > and "Fixes since v2.19". Move them, and do s/uses/use/ while at it.
On Mon, 3 Dec 2018 at 22:21, Eric Sunshine wrote:
> [es: retain diff coloring when going to stdout]
>
> Signed-off-by: Martin Ågren
> Signed-off-by: Eric Sunshine
> ---
>
> This is a re-roll of Martin's v2[1]. The only difference from v2 is that
> it retain
On Dec 3, 2018, at 8:50 PM, Jeff King wrote:
>
> I don't suppose this is leaving those incoming-* directories sitting
> around so we can inspect their permissions (it's suppose to clean them
> up, so I doubt it). If you're up for it, it might be interesting to
> patch Git to inspect the umask
On Mon, Dec 03, 2018 at 08:19:12PM -0800, Jamie Zawinski wrote:
> On Dec 3, 2018, at 8:09 PM, Jeff King wrote:
> >
> > but it works fine. Might there be some effective-uid trickiness with the
> > way the server side of git is invoked? Or is this a network mount where
> > the filesystem uid
On Dec 3, 2018, at 8:19 PM, Jamie Zawinski wrote:
>
> (Oh, I didn't check what umask was, but it should have been 022...)
Typo, I mean to say 002.
--
Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
On Dec 3, 2018, at 8:09 PM, Jeff King wrote:
>
> but it works fine. Might there be some effective-uid trickiness with the
> way the server side of git is invoked? Or is this a network mount where
> the filesystem uid might not match the process uid?
Huh. They're on the same ext4 fs (it's an AWS
On Mon, Dec 03, 2018 at 07:27:13PM -0800, Jamie Zawinski wrote:
> I think sharedrepository=group stopped working some time between
> 2.10.5 (works) and 2.12.4 (does not). 2.19.2 also does not.
Hmm. Given the time-frame and the fact that your strace shows problems
writing into the
Elijah Newren writes:
>> +Updates files in the working tree to match the version in the index
>> +or the specified tree.
>> +
>> +'git restore-files' [--from=] ...::
>
> and ? I understand and ,
> or but have no clue why it'd be okay to specify
> and together. What does that even mean?
I
Jonathan Nieder writes:
> Stefan Beller wrote:
>> On Mon, Dec 3, 2018 at 3:23 PM Jonathan Nieder wrote:
>
>>> I was curious about what versions of Gerrit this is designed to
>>> support (or in other words whether it's a bug fix or a feature).
Well, bf1a11f0 ("sideband: highlight keywords in
Johannes Sixt writes:
> Am 03.12.18 um 21:42 schrieb Martin Ågren:
>> On Mon, 3 Dec 2018 at 18:35, Johannes Sixt wrote:
>>> I actually did not test the result, because I don't have the
>>> infrastructure.
>>
>> I've tested with asciidoc and Asciidoctor, html and man-page. Looks
>> good.
>
>
Junio C Hamano writes:
> If "git clean" takes a pathspec, perhaps you can give a negative
> pathspec to exclude whatever you do not want to get cleaned,
> something like
>
> git clean '*.o' ':!precious.o'
>
> to say "presious.o is ignored (hence normally expendable), but I do
> not want to
Martin Ågren writes:
> We have three double-quote characters, which is one too many or too few.
> Dropping the last one seems to match the original intention best.
Thanks for spotting. The actual original intention was that the
user says two things:
first saying "add only what does
Martin Ågren writes:
> I had to read this sentence a few times to understand it. Let's try to
> clarify it.
Great. Thanks.
>
> Signed-off-by: Martin Ågren
> ---
> Documentation/RelNotes/2.20.0.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
Martin Ågren writes:
> Some items that should be in "Performance, Internal Implementation,
> Development Support etc." have ended up in "UI, Workflows & Features"
> and "Fixes since v2.19". Move them, and do s/uses/use/ while at it.
>
> Signed-off-by: Martin Ågren
> ---
I agree with the early
Jeff King writes:
> That said, our C99 designated initializer weather-balloons haven't
> gotten any complaints yet. So I think you could actually do:
>
> struct setup_revision_opt s_r_opt = {
> .allow_exclude_promisor_objects = 1,
> };
> ...
> setup_revisions(...);
>
> which is
On Mon, Dec 03, 2018 at 03:37:35PM -0800, Jonathan Tan wrote:
> Signed-off-by: Jonathan Tan
> ---
> Documentation/technical/packfile-uri.txt | 83
> Documentation/technical/protocol-v2.txt | 6 +-
> 2 files changed, 88 insertions(+), 1 deletion(-)
> create mode 100644
Eric Sunshine writes:
> This is a re-roll of Martin's v2[1]. The only difference from v2 is that
> it retains coloring when emitting to the terminal (plus an in-code
> comment was simplified).
>
> The regression introduced by d8981c3f88, in which the range-diff only
>
On Thu, Nov 29, 2018 at 2:01 PM Nguyễn Thái Ngọc Duy wrote:
>
> v3 sees switch-branch go back to switch-branch (in v2 it was
> checkout-branch). checkout-files is also renamed restore-files (v1 was
> restore-paths). Hopefully we won't see another rename.
I started reading through the patches. I
On Thu, Nov 29, 2018 at 2:03 PM Nguyễn Thái Ngọc Duy wrote:
>
> "git checkout" doing too many things is a source of confusion for many
> users (and it even bites old timers sometimes). To rememdy that, the
> command is now split in two: switch-branch and checkout-files. The
"checkout-files"
On Mon, Dec 3, 2018 at 3:37 PM Jonathan Tan wrote:
>
> Subsequent patches will change how the output of pack-objects is
> processed, so extract that processing into its own function.
>
> Currently, at most 1 character can be buffered (in the "buffered" local
> variable). One of those patches will
Thanks for bringing this design to the list!
> diff --git a/Documentation/technical/protocol-v2.txt
> b/Documentation/technical/protocol-v2.txt
> index 345c00e08c..2cb1c41742 100644
> --- a/Documentation/technical/protocol-v2.txt
> +++ b/Documentation/technical/protocol-v2.txt
> @@ -313,7 +313,8
On Mon, Dec 3, 2018 at 3:37 PM Jonathan Tan wrote:
>
> There is a potential issue: a server which produces both the URIs and
> the packfile at roughly the same time (like the implementation in this
> patch set) will not have sideband access until it has concluded sending
> the URIs. Among other
> diff --git a/pkt-line.c b/pkt-line.c
> index 04d10bbd0..ce9e42d10 100644
> --- a/pkt-line.c
> +++ b/pkt-line.c
> @@ -346,6 +346,10 @@ enum packet_read_status packet_read_with_status(int fd,
> char **src_buffer,
> return PACKET_READ_EOF;
> }
>
> + if
Stefan Beller wrote:
> On Mon, Dec 3, 2018 at 3:23 PM Jonathan Nieder wrote:
>> I was curious about what versions of Gerrit this is designed to
>> support (or in other words whether it's a bug fix or a feature).
>> Looking at examples like [1], it seems that Gerrit historically always
>> used
On Mon, Dec 3, 2018 at 3:23 PM Jonathan Nieder wrote:
> I was curious about what versions of Gerrit this is designed to
> support (or in other words whether it's a bug fix or a feature).
> Looking at examples like [1], it seems that Gerrit historically always
> used "ERROR:" so the 59a255aef0
Jonathan Nieder wrote:
> Stefan Beller wrote:
>> /*
>> * Match case insensitively, so we colorize output from existing
>> @@ -95,7 +95,8 @@ static void maybe_colorize_sideband(struct strbuf *dest,
>> const char *src, int n)
>> * messages. We only
Hi,
Stefan Beller wrote:
> When bf1a11f0a1 (sideband: highlight keywords in remote sideband output,
> 2018-08-07) was introduced, it was carefully considered which strings
> would be highlighted. However 59a255aef0 (sideband: do not read beyond
> the end of input, 2018-08-18) brought in a
On Mon, Dec 03, 2018 at 02:30:44PM -0800, Matthew DeVore wrote:
> Here is a one-liner to do it. It is Perl line noise, so it's not very cute,
> thought that is subjective. The output shown below is for the Git project
> (not Linux) repository as I've currently synced it:
>
> $ git rev-list
On 12/02/2018 05:23 AM, Ævar Arnfjörð Bjarmason wrote:
On Sun, Dec 02 2018, Robert P. J. Day wrote:
as part of an upcoming git class i'm delivering, i thought it would
be amusing to demonstrate the maximum length of colliding SHA-1
prefixes in a repository (in my case, i use the linux
| 4 ++--
> 5 files changed, 16 insertions(+), 11 deletions(-)
Thanks, this version looks good to me.
One style nit that I don't think is worth a re-roll, but that Junio
might want to tweak while applying:
> diff --git a/revision.c b/revision.c
> index 13e0519c02..f6b32e6a42
On Sun, Dec 02, 2018 at 09:07:47PM +1100, Robert White wrote:
> `git log --pretty short` gives the error message "ambiguous argument
> 'short'". To get the expected result, you need to use `git log
> --pretty=short`. However, `git log --since yesterday` and `git log
> --since=yesterday` both work
On 12/03/2018 01:24 PM, Jeff King wrote:
@@ -297,7 +296,8 @@ struct setup_revision_opt {
const char *def;
void (*tweak)(struct rev_info *, struct setup_revision_opt *);
const char *submodule; /* TODO: drop this and use rev_info->repo */
- int assume_dashdash;
+
On Sun, Dec 02, 2018 at 11:52:50AM +0100, René Scharfe wrote:
> > And for mu.git, a ~20k object repo:
> >
> > Test origin/master
> > peff/jk/loose-cache avar/check-collisions-config
> >
> >
On 12/03/2018 01:15 PM, Jeff King wrote:
That said, our C99 designated initializer weather-balloons haven't
gotten any complaints yet. So I think you could actually do:
struct setup_revision_opt s_r_opt = {
.allow_exclude_promisor_objects = 1,
};
I like this way best, so I'll
On Thu, Nov 29, 2018 at 7:33 AM Duy Nguyen wrote:
>
> On Wed, Nov 28, 2018 at 9:30 PM Stefan Beller wrote:
> >
> > On Wed, Nov 28, 2018 at 12:09 PM Duy Nguyen wrote:
> > >
> > > On Wed, Nov 28, 2018 at 9:01 PM Duy Nguyen wrote:
> > > > should we do
> > > > something about detached HEAD in this
On Mon, Dec 03, 2018 at 06:53:22PM +0100, Duy Nguyen wrote:
> On Sat, Dec 01, 2018 at 03:02:09PM -0500, Jeff King wrote:
> > I sometimes add "x false" to the top of the todo list to stop and create
> > new commits before the first one.
>
> And here I've been doing the same by "edit" the first
it's quite natural
> > to me to type things like 'git rebase -i @^^^' while already rebasing.
> > But I suppose this has already been discussed.
>
> Varieties of this have been discussed, but no, not nested rebases.
>
> The closest we thought about was re-scheduling the late
On Mon, Dec 03, 2018 at 02:31:37PM +, Phillip Wood wrote:
> > How would I move past the test that fails to continue? I guess "git
> > rebase --edit-todo" and then manually remove it (and any other remaining
> > test lines)?
>
> Perhaps we could teach git rebase --skip to skip a rescheduled
On Mon, Dec 03, 2018 at 11:23:56AM -0800, Matthew DeVore wrote:
> Put the allow_exclude_promisor_objects flag in setup_revision_opt. When
> it was in rev_info, it was unclear when it was used, since rev_info is
> passed to functions that don't use the flag. This resulted in
> unnecessary setting
On Mon, Dec 03, 2018 at 11:10:49AM -0800, Matthew DeVore wrote:
> > > + memset(_r_opt, 0, sizeof(s_r_opt));
> > > + s_r_opt.allow_exclude_promisor_objects = 1;
> > > + setup_revisions(ac, av, , _r_opt);
> >
> > I wonder if a static initializer for setup_revision_opt is worth it. It
> > would
Hi Hannes,
On Mon, 3 Dec 2018, Johannes Sixt wrote:
> The text body of section Behavioral Differences is typeset as code,
> but should be regular text. Remove the indentation to achieve that.
>
> While here, prettify the language:
>
> - use "the x backend" instead of "x-based rebase";
> - use
Am 03.12.18 um 21:42 schrieb Martin Ågren:
On Mon, 3 Dec 2018 at 18:35, Johannes Sixt wrote:
I actually did not test the result, because I don't have the
infrastructure.
I've tested with asciidoc and Asciidoctor, html and man-page. Looks
good.
Thank you so much!
-- Hannes
commands like "log", to which it
>didn't make much sense. This has been corrected.
>(merge 669b1d2aae md/exclude-promisor-objects-fix later to maint).
>
> * The "container" mode of TravisCI is going away. Our .travis.yml
>file is getting prepared f
On Mon, 3 Dec 2018 at 18:35, Johannes Sixt wrote:
> I actually did not test the result, because I don't have the
> infrastructure.
I've tested with asciidoc and Asciidoctor, html and man-page. Looks
good.
Martin
Hi Junio,
> A release candidate Git v2.20.0-rc2 is now available for testing
> at the usual places. It is comprised of 934 non-merge commits
> since v2.19.0, contributed by 76 people, 25 of which are new faces.
Here are a few suggested tweaks after reading the draft release notes.
Nothing
on the head, and then it's quite natural
> > to me to type things like 'git rebase -i @^^^' while already rebasing.
> > But I suppose this has already been discussed.
>
> Varieties of this have been discussed, but no, not nested rebases.
Interesting :)
> The closest we t
On 12/01/2018 11:44 AM, Jeff King wrote:
repo_init_revisions(the_repository, , NULL);
save_commit_buffer = 0;
- revs.allow_exclude_promisor_objects_opt = 1;
- setup_revisions(ac, av, , NULL);
+
+ memset(_r_opt, 0, sizeof(s_r_opt));
+
Hi Duy,
On Mon, 3 Dec 2018, Duy Nguyen wrote:
> On Sat, Dec 01, 2018 at 03:02:09PM -0500, Jeff King wrote:
> > I sometimes add "x false" to the top of the todo list to stop and create
> > new commits before the first one.
>
> And here I've been doing the same by "edit" the first commit, add a
>
ption (and a
> > > > > config
> > > > > setting) to re-schedule failed `exec` commands? Like so:
> > > >
> > > > Your proposition would do in most cases, however it is not possible to
> > > > make a distinction between reschedulable and non-re
On Sat, Dec 01, 2018 at 03:02:09PM -0500, Jeff King wrote:
> I sometimes add "x false" to the top of the todo list to stop and create
> new commits before the first one.
And here I've been doing the same by "edit" the first commit, add a
new commit then reorder them in the second interactive
On Sat, Dec 01, 2018 at 03:02:09PM -0500, Jeff King wrote:
> On Thu, Nov 29, 2018 at 09:32:48AM +0100, Johannes Schindelin wrote:
>
> > > > Would it not make more sense to add a command-line option (and a config
> > > > setting) to re-schedule failed `exec` comman
On 01/12/2018 20:02, Jeff King wrote:
On Thu, Nov 29, 2018 at 09:32:48AM +0100, Johannes Schindelin wrote:
Would it not make more sense to add a command-line option (and a config
setting) to re-schedule failed `exec` commands? Like so:
Your proposition would do in most cases, however
On Fri, 30 Nov 2018 at 10:32, Eric Sunshine wrote:
>
> On Thu, Nov 29, 2018 at 11:27 PM Junio C Hamano wrote:
> > Junio C Hamano writes:
> > So how about doing this on top of 'master' instead? As this leaks
> > *no* information wrt how range-diff machinery should behave from the
> >
> > Would something like git clean --exclude=file-pattern work as a
> > compromise notion? Files matching the pattern would not be cleaned
> > regardless of .gitignore or their potential preciousness status
> > long-term. Multiple repetitions of the --exclude option might be
> > supportable. I
Carlo Marcelo Arenas Belón writes:
> ea2d20d4c2 ("t5004: avoid using tar for checking emptiness of archive",
> 2013-05-09), introduced a fake empty tar archive to allow for portable
> tests of emptiness without having to invoke tar
>
> 4318094047 ("archive: don't add empty directories to
Frank Schäfer writes:
> Hi Junio,
>
> Am 29.11.18 um 03:11 schrieb Junio C Hamano:
> [...]
>> This was misspoken a bit. Let's revise it to
>>
>> When producing a colored output (not limited to whitespace
>> error coloring of diff output) for contents that are not
>> marked as
"H.Merijn Brand" writes:
> When $PATH contains the current directory as .:PATH, PATH:., PATH:.:PATH,
> or (maybe worse) as :PATH, PATH:, or PATH::PATH - as an empty entry is
> identical to having dot in $PATH - this test used to fail
It is totally unclear what "this test" refers to. Let's
Jeff King writes:
> Since the test is ultimately checking "can we run should-not-run from
> the current directory", might it be simpler to actually try that as the
> precondition? I.e., something like:
> ...
A nice egg of columbus. It also would save us from mischievous
users who have
Am 02.12.18 um 20:31 schrieb Frank Schäfer:
Am 29.11.18 um 03:11 schrieb Junio C Hamano:
[...]
This was misspoken a bit. Let's revise it to
When producing a colored output (not limited to whitespace
error coloring of diff output) for contents that are not
marked as
Hi Peff,
On Sat, 1 Dec 2018, Jeff King wrote:
> On Thu, Nov 29, 2018 at 09:32:48AM +0100, Johannes Schindelin wrote:
>
> > > > Would it not make more sense to add a command-line option (and a config
> > > > setting) to re-schedule failed `exec` commands? Like so:
Thomas Gummerer writes:
> Agreed, I think --{no-,}overlay is a much better name for the option,
> I'll use that for my patch series (I hope to send that soon after 2.20
> is released).
OK.
> I must admit that I was not aware that the mode is called overlay
> mode, before you explained it to
Jiang Xin writes:
> Git v2.20.0-rc2 has been released, and there are 5 new messages need to
> be translated. So let's start new round of l10n for Git 2.20.0.
A huge thanks, as always, to the translation team. Jiang, sorry to
see that -rc2 slipped just after you sent out the round 2 message
and
"Randall S. Becker" writes:
> Would something like git clean --exclude=file-pattern work as a
> compromise notion? Files matching the pattern would not be cleaned
> regardless of .gitignore or their potential preciousness status
> long-term. Multiple repetitions of the --exclude option might be
Hi Junio,
Am 29.11.18 um 03:11 schrieb Junio C Hamano:
[...]
> This was misspoken a bit. Let's revise it to
>
> When producing a colored output (not limited to whitespace
> error coloring of diff output) for contents that are not
> marked as eol=crlf (and other historical
On 11/30, Junio C Hamano wrote:
>
> I am unsure about the wisdom of calling it "--index", though.
>
> The "--index" option is "the command can work only on the index, or
> only on the working tree files, or on both the index and the working
> tree files, and this option tells it to work in the
On December 2, 2018 8:26, Ævar Arnfjörð Bjarmason wrote:
>
> On Sat, Dec 01 2018, Cameron Boehmer wrote:
>
> > 1) add a new flag
> > -l, --local
> > Do not consult git config --global core.excludesFile in
> > determining what files git ignores. This is useful in conjunction with
> > -x/-X to
On Sun, 2 Dec 2018, Duy Nguyen wrote:
> On Sun, Dec 2, 2018 at 6:05 PM Robert P. J. Day wrote:
> > > Patch update>> 2
> > > staged unstaged path
> > > * 1:unchanged+1/-0 README.md
> > > * 2:unchanged+1/-0 contrib/README
> > > 3:unchanged
On Sun, Dec 2, 2018 at 6:05 PM Robert P. J. Day wrote:
> > Patch update>> 2
> > staged unstaged path
> > * 1:unchanged+1/-0 README.md
> > * 2:unchanged+1/-0 contrib/README
> > 3:unchanged+1/-0 t/README
> > Patch update>>
> >
> >
On Sun, 2 Dec 2018, SZEDER Gábor wrote:
> On Sun, Dec 02, 2018 at 11:30:19AM -0500, Robert P. J. Day wrote:
> >
> > testing adding by patch for the very first time (i've just never
> > needed this), and reading the "progit" book and reading the man page,
> > and the impression i'm getting is
On Sun, 2 Dec 2018, SZEDER Gábor wrote:
> On Sun, Dec 02, 2018 at 11:30:19AM -0500, Robert P. J. Day wrote:
> >
> > testing adding by patch for the very first time (i've just never
> > needed this), and reading the "progit" book and reading the man page,
> > and the impression i'm getting is
On Sun, 2 Dec 2018, Kevin Daudt wrote:
> On Sun, Dec 02, 2018 at 11:30:19AM -0500, Robert P. J. Day wrote:
> >
> > testing adding by patch for the very first time (i've just never
> > needed this), and reading the "progit" book and reading the man page,
> > and the impression i'm getting is
On Sun, Dec 02, 2018 at 11:30:19AM -0500, Robert P. J. Day wrote:
>
> testing adding by patch for the very first time (i've just never
> needed this), and reading the "progit" book and reading the man page,
> and the impression i'm getting is that running "git add -p" (going
> straight to patch
On Sun, Dec 02, 2018 at 11:30:19AM -0500, Robert P. J. Day wrote:
>
> testing adding by patch for the very first time (i've just never
> needed this), and reading the "progit" book and reading the man page,
> and the impression i'm getting is that running "git add -p" (going
> straight to patch
On Sun, 2 Dec 2018, Ævar Arnfjörð Bjarmason wrote:
> On Sun, Dec 02 2018, Robert P. J. Day wrote:
>
> > as part of an upcoming git class i'm delivering, i thought it
> > would be amusing to demonstrate the maximum length of colliding
> > SHA-1 prefixes in a repository (in my case, i use the
On Fri, Feb 09 2018, Nguyễn Thái Ngọc Duy wrote:
> +static int show_gitcomp(struct parse_opt_ctx_t *ctx,
> + const struct option *opts)
> +{
Says it returns 'static int'...
> [...]
> + exit(0);
Then just exits...
> + /* lone --git-completion-helper is
On Sat, Dec 01 2018, Cameron Boehmer wrote:
> 1) add a new flag
> -l, --local
> Do not consult git config --global core.excludesFile in
> determining what files git ignores. This is useful in conjunction with
> -x/-X to preserve user files while removing build artifacts.
Or perhaps a
On Sun, Dec 02 2018, Robert P. J. Day wrote:
> as part of an upcoming git class i'm delivering, i thought it would
> be amusing to demonstrate the maximum length of colliding SHA-1
> prefixes in a repository (in my case, i use the linux kernel git repo
> for most of my examples).
>
> is
56*100 loose objects0.32(0.17+0.02)
>>> 0.04(0.02+0.00) -87.5%
>>> 0008.5: index-pack with 256*250 loose objects0.57(0.41+0.03)
>>> 0.04(0.02+0.00) -93.0%
>>> 0008.6: index-pack with 256*500 loose objects1.02(0.83+0.06)
>&
On Sun, Dec 2, 2018 at 11:13 AM Robert White wrote:
>
> `git log --pretty short` gives the error message "ambiguous argument
> 'short'". To get the expected result, you need to use `git log
> --pretty=short`. However, `git log --since yesterday` and `git log
> --since=yesterday` both work as
Junio C Hamano writes:
> Cameron Boehmer writes:
>
>> 1) add a new flag
>> -l, --local
>> Do not consult git config --global core.excludesFile in
>> determining what files git ignores. This is useful in conjunction with
>> -x/-X to preserve user files while removing build artifacts.
> ...
>
On Sat, Dec 01, 2018 at 09:28:47PM -0500, Eric Sunshine wrote:
> On Sat, Dec 1, 2018 at 3:02 PM Jeff King wrote:
> > On Thu, Nov 29, 2018 at 09:32:48AM +0100, Johannes Schindelin wrote:
> > > In reality, I think that it would even make sense to change the default to
> > > reschedule failed
FWIW this patch doesn't have any other siblings and subject should had
been just [PATCH]; apologize for the confusion and the spam (including
that other duplicated email, and most likely this one)
Carlo
On Sat, Dec 1, 2018 at 3:02 PM Jeff King wrote:
> On Thu, Nov 29, 2018 at 09:32:48AM +0100, Johannes Schindelin wrote:
> > In reality, I think that it would even make sense to change the default to
> > reschedule failed `exec` commands. Which is why I suggested to also add a
> > config option.
>
Cameron Boehmer writes:
> 1) add a new flag
> -l, --local
> Do not consult git config --global core.excludesFile in
> determining what files git ignores. This is useful in conjunction with
> -x/-X to preserve user files while removing build artifacts.
This does not belong to the "clean"
On Thu, Nov 29, 2018 at 09:32:48AM +0100, Johannes Schindelin wrote:
> > > Would it not make more sense to add a command-line option (and a config
> > > setting) to re-schedule failed `exec` commands? Like so:
> >
> > Your proposition would do in most cas
On Wed, Nov 28, 2018 at 03:56:29PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> On Thu, Nov 22 2018, Jeff King wrote:
>
> > On Thu, Nov 22, 2018 at 02:17:01AM -0800, Carlo Arenas wrote:
> >> PS. upstreaming the PERL_PATH fix is likely to be good to do soonish
> >> as I presume at least all BSD
On Wed, Nov 28, 2018 at 02:27:08PM +0100, SZEDER Gábor wrote:
> > Curiously, the act.err file also has 54 NUL bytes before the "fatal:"
> > message.
>
> I think those NUL bytes come from the file system.
>
> The contents of 'act.err' from the previous test ('fetch gzipped
> empty') is usually:
On Tue, Nov 27, 2018 at 09:48:57PM +0100, René Scharfe wrote:
> > +static int quick_has_loose(struct repository *r,
> > + const unsigned char *sha1)
> > +{
> > + int subdir_nr = sha1[0];
> > + struct object_id oid;
> > + struct object_directory *odb;
> > +
> > +
On Fri, Nov 30, 2018 at 05:32:47PM -0800, Matthew DeVore wrote:
> > Speaking of which, would this flag work better as a field in
> > setup_revision_opt, which is passed to setup_revisions()? The intent
> > seem to be to influence how we parse command-line arguments, and that's
> > where other
On Sat, Dec 01, 2018 at 06:07:57PM +0100, H.Merijn Brand wrote:
> When $PATH contains the current directory as .:PATH, PATH:., PATH:.:PATH,
> or (maybe worse) as :PATH, PATH:, or PATH::PATH - as an empty entry is
> identical to having dot in $PATH - this test used to fail
Good catch. The test
Thanks both. Agree with Junio it would be better if squashed; apologize
for not catching it earlier, but the following might help to make it
visible for anyone that care to run the linter:
$ make test-lint-shell-syntax
Carlo
-- >8 --
From: =?UTF-8?q?Carlo=20Marcelo=20Arenas=20Bel=C3=B3n?=
Elijah Newren writes:
> Thanks for the patch!
>
> On Fri, Nov 30, 2018 at 6:52 PM Carlo Marcelo Arenas Belón
> ...
> Oops. Thanks for catching. To be honest, we don't even need -a, -R,
> etc. -- it was just a habit for me to add -a after cp. A simple cp
> would do, though what you have here
On Wed, Nov 28, 2018 at 10:54 PM Ævar Arnfjörð Bjarmason
wrote:
> But we must have some viable way to repair warts in the tools, and
> losing user data is a *big* wart.
>
> I don't think something like the endgame you've described in
>
Hi,
Thanks for the patch!
On Fri, Nov 30, 2018 at 6:52 PM Carlo Marcelo Arenas Belón
wrote:
>
> b8cd1bb713 ("t6036, t6043: increase code coverage for file collision
> handling", 2018-11-07) uses this GNU extension that is not available in a
> POSIX complaint
This is an extraordinarily long
On Fri, Nov 30, 2018 at 6:58 PM Bryan Turner wrote:
>
> Here's a (very ugly) patch I threw together on top of your code:
...snip
Gmail butchered my patch, so here it is as an attachment.
Bryan
short-size-reads.patch
Description: Binary data
On Fri, Nov 30, 2018 at 5:05 PM Farhan Khan wrote:
>
> Hi all,
>
> I am writing an implementation of the git HTTP pack protocol in C. It
> just does a request to clone a repository. It works pretty well for
> small repositories, but seems to fail on larger repositories and I do
> not understand
On 11/21/2018 08:40 AM, Jeff King wrote:
On Mon, Oct 22, 2018 at 06:13:42PM -0700, Matthew DeVore wrote:
diff --git a/builtin/prune.c b/builtin/prune.c
index 41230f8215..11284d0bf3 100644
--- a/builtin/prune.c
+++ b/builtin/prune.c
@@ -120,6 +120,7 @@ int cmd_prune(int argc, const char
Hi,
On Fri, 30 Nov 2018, Phillip Wood wrote:
> > diff --git a/sequencer.c b/sequencer.c
> > index 900899ef20..11692d0b98 100644
> > --- a/sequencer.c
> > +++ b/sequencer.c
> > @@ -4394,24 +4394,29 @@ int sequencer_make_script(FILE *out, int argc, const
> > char **argv,
> > return 0;
> > }
>
201 - 300 of 100366 matches
Mail list logo
