Re: none

Mihir Mehta writes: > Thanks, Junio. Instead of removing that part of the patch, I opted to > expand it to make it a little clearer (in my opinion) than it was > before. Let me know if this works. I am mildly negative on that change. "Omitting both would give an empty diff" would be

[PATCH v2 09/11] builtin rebase: start a new rebase only if none is in progress

From: Pratik Karki To run a new rebase, there needs to be a check to assure that no other rebase is in progress. New rebase operation cannot start until an ongoing rebase operation completes or is terminated. Signed-off-by: Pratik Karki Signed-off-by: Johannes Schindelin --- builtin/rebase.c

Re: [PATCH 09/11] builtin rebase: start a new rebase only if none is in progress

Hi Stefan, On Wed, 8 Aug 2018, Stefan Beller wrote: > On Wed, Aug 8, 2018 at 6:51 AM Pratik Karki wrote: > > > > diff --git a/builtin/rebase.c b/builtin/rebase.c > > index 8a7bf3d468..a261f552f1 100644 > > --- a/builtin/rebase.c > > +++ b/builtin/rebase.c > > @@ -455,6 +481,26 @@ int

Re: [PATCH 09/11] builtin rebase: start a new rebase only if none is in progress

On Wed, Aug 8, 2018 at 6:51 AM Pratik Karki wrote: > > To run a new rebase, there needs to be a check to assure that no other > rebase is in progress. New rebase operation cannot start until an > ongoing rebase operation completes or is terminated. > > Signed-off-by: Pratik Karki > --- >

[PATCH 09/11] builtin rebase: start a new rebase only if none is in progress

To run a new rebase, there needs to be a check to assure that no other rebase is in progress. New rebase operation cannot start until an ongoing rebase operation completes or is terminated. Signed-off-by: Pratik Karki --- builtin/rebase.c | 48 +++- 1

Re: [PATCH 1/1] git-p4: unshelve: use action==add instead of rev==none

>> This was actually discussed in a separate thread [1] some time ago with >> patches proposed by Thandesha and me. >> I haven't yet got time to cook a final patch, which addresses both >> Thandesha's and mine use-cases though, >> so this wasn't submitted to Junio yet. >> In the meantime, I

Re: [PATCH 1/1] git-p4: unshelve: use action==add instead of rev==none

On 23 May 2018 at 17:41, Mazo, Andrey wrote: >> The last one (i.e. "even if it is verbose, if fileSize is not >> reported, do not write the verbose output") does not look like it is >> limited to the unshelve feature, so it might, even though it is a >> one-liner, deserve to

Re: [PATCH 1/1] git-p4: unshelve: use action==add instead of rev==none

> The last one (i.e. "even if it is verbose, if fileSize is not > reported, do not write the verbose output") does not look like it is > limited to the unshelve feature, so it might, even though it is a > one-liner, deserve to be a separate preparatory patch if you want. > But I do not feel

Re: [PATCH 1/1] git-p4: unshelve: use action==add instead of rev==none

Luke Diamand writes: >> However, instead of a separate patch, wouldn't it be better to squash >> it into the previous one? So 'make test' would succeed on every >> commit even with a newer p4 version. > > Junio? > > I can squash together the original commit and the two fixes

Re: [PATCH 1/1] git-p4: unshelve: use action==add instead of rev==none

lem arises because when a file is added in a P4 >> shelved changelist, the depot revision is shown as "none" >> if using the older p4d (which makes sense - the file doesn't >> yet exist, so can't have a revision), but as "1" in the newer >> versions of

Re: [PATCH 1/1] git-p4: unshelve: use action==add instead of rev==none

On Tue, May 22, 2018 at 10:41 AM, Luke Diamand <l...@diamand.org> wrote: > SZEDER Gábor found that the unshelve tests fail with newer > versions of Perforce (2016 vs 2015). > > The problem arises because when a file is added in a P4 > shelved changelist, the depot revis

[PATCH 1/1] git-p4: unshelve: use action==add instead of rev==none

SZEDER Gábor found that the unshelve tests fail with newer versions of Perforce (2016 vs 2015). The problem arises because when a file is added in a P4 shelved changelist, the depot revision is shown as "none" if using the older p4d (which makes sense - the file doesn't yet exist, so

Re: [PATCH v4] daemon: add --log-destination=(stderr|syslog|none)

roup=]]] >>> +[--log-destination=(stderr|syslog|none)] >> >> I micronit, but maybe worthwhile to have a preceeding commit to fix up >> that indentation of --listen and --user. > > I thought the indentation here is intentional, since we’re still in

Re: [PATCH v4] daemon: add --log-destination=(stderr|syslog|none)

Eric Sunshine writes: > On Sun, Feb 4, 2018 at 1:30 PM, Lucas Werkmeister > wrote: >> This new option can be used to override the implicit --syslog of >> ... > Thanks. With the 'log_destination' initialization bug fixed, this > version looks

Re: [PATCH v4] daemon: add --log-destination=(stderr|syslog|none)

On Sun, Feb 4, 2018 at 1:55 PM, Ævar Arnfjörð Bjarmason <ava...@gmail.com> wrote: > On Sun, Feb 04 2018, Lucas Werkmeister jotted: >>[--inetd | >> [--listen=] [--port=] >> [--user= [--group=]]] >> + [--log-destin

Re: [PATCH v4] daemon: add --log-destination=(stderr|syslog|none)

On Sun, Feb 4, 2018 at 1:30 PM, Lucas Werkmeister wrote: > This new option can be used to override the implicit --syslog of > --inetd, or to disable all logging. (While --detach also implies > --syslog, --log-destination=stderr with --detach is useless since > --detach

Re: [PATCH v4] daemon: add --log-destination=(stderr|syslog|none)

On 04.02.2018 19:55, Ævar Arnfjörð Bjarmason wrote: > > On Sun, Feb 04 2018, Lucas Werkmeister jotted: > >> [--inetd | >>[--listen=] [--port=] >>[--user= [--group=]]] >> + [--log-destination=(stderr|syslog|none)] >

Re: [PATCH v4] daemon: add --log-destination=(stderr|syslog|none)

On Sun, Feb 04 2018, Lucas Werkmeister jotted: >[--inetd | > [--listen=] [--port=] > [--user= [--group=]]] > + [--log-destination=(stderr|syslog|none)] I micronit, but maybe worthwhile to have a preceeding commit to fix up that

[PATCH v4] daemon: add --log-destination=(stderr|syslog|none)

.txt +++ b/Documentation/git-daemon.txt @@ -20,6 +20,7 @@ SYNOPSIS [--inetd | [--listen=] [--port=] [--user= [--group=]]] +[--log-destination=(stderr|syslog|none)] [...] DESCRIPTION @@ -80,7 +81,8 @@ OPTIONS do not have t

Re: [PATCH v3] daemon: add --log-destination=(stderr|syslog|none)

cmd_main(int argc, const char **argv) >> + if (skip_prefix(arg, "--log-destination=", )) { >> + if (!strcmp(v, "syslog")) { >> + log_destination = LOG_DESTINATION_SYSLOG; >>

Re: [PATCH v3] daemon: add --log-destination=(stderr|syslog|none)

continue; > + } else if (!strcmp(v, "stderr")) { > + log_destination = LOG_DESTINATION_STDERR; > + continue; > + } else if (!strcmp(v, "none")) { > +

[PATCH v3] daemon: add --log-destination=(stderr|syslog|none)

1db7be..a0106e6aa 100644 --- a/Documentation/git-daemon.txt +++ b/Documentation/git-daemon.txt @@ -20,6 +20,7 @@ SYNOPSIS [--inetd | [--listen=] [--port=] [--user= [--group=]]] +[--log-destination=(stderr|syslog|none)] [...] DE

Re: [PATCH v2] daemon: add --send-log-to=(stderr|syslog|none)

a re-roll. > > I didn’t want to sound like I was just scratching my own itch ;) I hope > this option is useful for other use-cases as well? If the reader does not know that --inetd implies --syslog, then This makes it possible to use --inetd while still logging to standard error. lead

Re: [PATCH v2] daemon: add --send-log-to=(stderr|syslog|none)

gt; + case LOG_TO_SYSLOG: { >> char buf[1024]; >> vsnprintf(buf, sizeof(buf), err, params); >> syslog(priority, "%s", buf); >> - } else { >> + break; >> + } >> +

Re: [PATCH v2] daemon: add --send-log-to=(stderr|syslog|none)

case LOG_TO_SYSLOG: { > char buf[1024]; > vsnprintf(buf, sizeof(buf), err, params); > syslog(priority, "%s", buf); > - } else { > + break; > + } > + case LOG_TO_STDERR: { There aren't

[PATCH v2] daemon: add --send-log-to=(stderr|syslog|none)

[--send-log-to=(stderr|syslog|none)] [...] DESCRIPTION @@ -110,8 +111,26 @@ OPTIONS zero for no limit. --syslog:: - Log to syslog instead of stderr. Note that this option does not imply - --verbose, thus by default only error conditions will be logged. +

[PATCH 04/13] list-objects-filter-blobs-none: add filter to omit all blobs

From: Jeff Hostetler Create a simple filter for traverse_commit_list_worker() to omit all blobs from the result. This filter will be used in a future commit by rev-list and pack-objects to create a "commits and trees" result. This is intended for partial clone and fetch

Re: [PATCH v2] doc: add missing values "none" and "default" for diff.wsErrorHighlight

Andreas Heiduk writes: > The values have eluded documentation so far. While at it streamline > the wording by grouping relevant parts together. > > Signed-off-by: Andreas Heiduk > --- > Documentation/diff-config.txt | 11 +++ >

[PATCH v2] doc: add missing values "none" and "default" for diff.wsErrorHighlight

r `new` + lines of the diff. Multiple values are separated by comma, + `none` resets previous values, `default` reset the list to + `new` and `all` is a shorthand for `old,new,context`. The + whitespace errors are colored with `color.diff.whitespace`. + The command line

Re: [PATCH] doc: add missing "none" value for diff.wsErrorHighlight

Andreas Heiduk <ashei...@gmail.com> writes: > The value has not eluded documentation so far. I am not sure what "has not eluded" means in this context (did you mean "has eluded"?). The patch text itself is not wrong per-se, but if we are to add documentation for

[PATCH] doc: add missing "none" value for diff.wsErrorHighlight

, `new`, `context` and `none`, that specifies how whitespace errors on lines are highlighted with `color.diff.whitespace`. Can be overridden by the command line option `--ws-error-highlight=` diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt index 89c

Re: none

miwilli...@google.com writes: > From 7201fe08ede76e502211a781250c9a0b702a78b2 Mon Sep 17 00:00:00 2001 > From: Mike Williams > Date: Mon, 11 Apr 2016 14:18:39 -0400 > Subject: [PATCH 1/1] wt-status: Remove '!!' from > wt_status_collect_changed_cb > > The

[PATCH 08/12] git submodule update: check for "none" in C

update_module = update; + if (!update_module) + update_module = sub->update; + if (!update_module) + update_module = "checkout"; + if (!strcmp(update_module, "none")) { +

Re: [PATCH] gitk: Fix bad English grammar Matches none Commit Info

known_view_options { {committer t15 . --committer=* {mc Committer:}} {loginfo t15 .. --grep=* {mc Commit Message:}} {allmatch b.. --all-match{mc Matches all Commit Info criteria}} -{igrep b.. --invert-grep {mc Matches none Commit Info criteria

[PATCH] gitk: Fix bad English grammar Matches none Commit Info

:}} {loginfo t15 .. --grep=* {mc Commit Message:}} {allmatch b.. --all-match{mc Matches all Commit Info criteria}} -{igrep b.. --invert-grep {mc Matches none Commit Info criteria}} +{igrep b.. --invert-grep {mc Matches no Commit Info criteria

Re: [PATCH] git-log: added --none-match option

); } else if (!strcmp(arg, --all-match)) { revs-grep_filter.all_match = 1; + } else if (!strcmp(arg, --invert-grep)) { + revs-invert_grep = 1; } else if ((argcount = parse_long_opt(encoding, argv, optarg))) { if (strcmp(optarg, none

Re: [PATCH] git-log: added --none-match option

the original --all-match came from. That was on purpose. I am not quite sure what would be the point of showing only matches from files that match no patterns (option description from your patch below). If a file matches none of the patterns, what matches are there to show? The only useful thing I could

Re: [PATCH] git-log: added --none-match option

Christoph Junghans ott...@gentoo.org writes: The only useful thing I could image is using it in conjunction with --files-with-matches, but that is what --files-without-match is for. Yes, -l was exactly what I had in mind and I was hoping that git grep -l --no-match -e WIP -e TODO -e FIXME -e

[PATCH] git-log: added --none-match option

@@ if it is part of the log message. Limit the commits output to ones that match all given `--grep`, instead of ones that match at least one. +--none-match:: + Limit the commits output to ones that do not match any of the + given `--grep`, instead of ones that match

Re: $GIT_CONFIG should either apply to all commands, or none at all

On Wed, Oct 01, 2014 at 06:15:46PM -0700, Jonathan Nieder wrote: 3) Warn when 'git config' is called with GIT_CONFIG set, explaining that support will eventually be removed and that callers should pass --file= instead. 4) Once we're confident there are no scripts in the wild

Re: $GIT_CONFIG should either apply to all commands, or none at all

Jonathan Nieder jrnie...@gmail.com writes: Yep. One possibility would be to do something like the following (A): 1) advertise in the git-config(1) manpage that the GIT_CONFIG environment variable only affects the behavior of the 'git config' command 2) introduce an environment

Re: $GIT_CONFIG should either apply to all commands, or none at all

Hi, Frédéric Brière wrote[1]: This kind of stuff caused me a lot of hair-pulling: $ git config core.abbrev 32 git log --pretty=oneline --abbrev-commit 89be foo Here's the source of the discrepancy: $ grep abbrev $GIT_CONFIG .git/config git.conf: abbrev=32 .git/config:

Re: [PATCH/RFC] log doc: explain --encoding=none and default output encoding

if the configuration variable is not set). `--encoding=none` lets you view the raw log message without any reencoding. Documentation/pretty-options.txt | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/Documentation/pretty-options.txt b

[PATCH/RFC] log doc: explain --encoding=none and default output encoding

; this option can be used to tell the command to re-code the commit log message in the encoding - preferred by the user. For non plumbing commands this - defaults to UTF-8. + preferred by the user. --encoding=none means to use the + raw log message without paying attention

Re: [PATCH v4 2/2] mergetools/p4merge: create a base if none available

Kevin Bracey ke...@bracey.fi writes: Minor change from v3: that version moved initialisation of src1 higher up, detaching it from its associated comment. This move was only required by earlier versions, so v4 leaves src1 in its original position. The funny filename comment was from

[PATCH v4 2/2] mergetools/p4merge: create a base if none available

Originally, with no base, Git gave P4Merge $LOCAL as a dummy base: p4merge $LOCAL $LOCAL $REMOTE $MERGED Commit 0a0ec7bd changed this to: p4merge empty file $LOCAL $REMOTE $MERGED to avoid the problem of being unable to save in some circumstances with similar inputs. Unfortunately this

[PATCH v3 2/3] mergetools/p4merge: create a base if none available

Originally, with no base, Git gave P4Merge $LOCAL as a dummy base: p4merge $LOCAL $LOCAL $REMOTE $MERGED Commit 0a0ec7bd changed this to: p4merge empty file $LOCAL $REMOTE $MERGED to avoid the problem of being unable to save in some circumstances with similar inputs. Unfortunately this

[PATCH v2 2/3] mergetools/p4merge: create a base if none available

Originally, with no base, Git gave P4Merge $LOCAL as a dummy base: p4merge $LOCAL $LOCAL $REMOTE $MERGED Commit 0a0ec7bd changed this to: p4merge empty file $LOCAL $REMOTE $MERGED to avoid the problem of being unable to save in some circumstances with similar inputs. Unfortunately this

Re: [PATCH 2/2] p4merge: create a virtual base if none available

On 07/03/2013 04:23, David Aguilar wrote: On Wed, Mar 6, 2013 at 12:32 PM, Kevin Bracey ke...@bracey.fi wrote: +make_virtual_base() { + # Copied from git-merge-one-file.sh. I think the reasoning behind these patches is good. How do we feel about this duplication? Bad. Should

[PATCH 2/2] p4merge: create a virtual base if none available

Originally, with no base, Git gave P4Merge $LOCAL as a dummy base: p4merge $LOCAL $LOCAL $REMOTE $MERGED Commit 0a0ec7bd changed this to: p4merge empty file $LOCAL $REMOTE $MERGED to avoid the problem of being unable to save in some circumstances. Unfortunately this approach does not

Re: [PATCH 2/2] p4merge: create a virtual base if none available

On Wed, Mar 6, 2013 at 12:32 PM, Kevin Bracey ke...@bracey.fi wrote: Originally, with no base, Git gave P4Merge $LOCAL as a dummy base: p4merge $LOCAL $LOCAL $REMOTE $MERGED Commit 0a0ec7bd changed this to: p4merge empty file $LOCAL $REMOTE $MERGED to avoid the problem of being

Re: [PATCH 2/2] p4merge: create a virtual base if none available

On Wed, Mar 6, 2013 at 12:32 PM, Kevin Bracey ke...@bracey.fi wrote: +make_virtual_base() { + # Copied from git-merge-one-file.sh. + # This starts with $LOCAL, and uses git apply to + # remove lines that are not in $REMOTE. + cp --

Re: [PATCH 2/2] p4merge: create a virtual base if none available

David Aguilar dav...@gmail.com writes: How do we feel about this duplication? Should we make a common function in the git-sh-setup.sh, or is it okay to have a slightly modified version of this function in two places? It probably is a good idea to have it in one place. That would also solve

[PATCH v6 09/16] remote-hg: fake bookmark when there's none

Or at least no current bookmark. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- contrib/remote-helpers/git-remote-hg | 19 ++- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/contrib/remote-helpers/git-remote-hg

[PATCH v5 10/14] remote-hg: fake bookmark when there's none

Or at least no current bookmark. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- contrib/remote-hg/git-remote-hg | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/contrib/remote-hg/git-remote-hg b/contrib/remote-hg/git-remote-hg index

[PATCH v4 10/13] remote-hg: fake bookmark when there's none

Or at least no current bookmark. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- contrib/remote-hg/git-remote-hg | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/contrib/remote-hg/git-remote-hg b/contrib/remote-hg/git-remote-hg index

libata: don't normalize UNKNOWN to NONE after reset

Jan 8 20:26:12 2008 +0900 Committer: Jeff Garzik [EMAIL PROTECTED] CommitDate: Thu Jan 10 16:53:22 2008 -0500 libata: don't normalize UNKNOWN to NONE after reset After non-classifying reset, ehc-classes[] could contain ATA_DEV_UNKNOWN which used to be normalized to ATA_DEV_NONE

[CIFS] Make sec=none force an anonymous mount

May 5 03:27:49 2007 + Committer: Steve French [EMAIL PROTECTED] CommitDate: Sat May 5 03:27:49 2007 + [CIFS] Make sec=none force an anonymous mount We had a customer report that attempting to make CIFS mount with a null username (i.e. doing an anonymous mount) doesn't work