Re: Non-zero exit code without error

Thanks. I know it is hard to get an idea without being able to reproduce it. I think there is no alternative without debugging it with GDB. I’ve tried your suggestions and nothing has changed. I’ve also update the GIT as you suggested, but it is still the same. Just to see, if GIT server causes

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Arif Khokar wrote: > On 02/13/2017 09:37 AM, Johannes Schindelin wrote: > >I actually had expected *you* to put in a little bit of an effort, too. In > >fact, I was very disappointed that you did not even look into porting that > >script to use public-inbox instead of

Re: Developing git with IDE

On Tue, Feb 14, 2017 at 12:15:00AM +0100, Oleg Taranenko wrote: > being last decade working with java & javascript I completely lost > relation to c/c++ world. Trying to get into git internals I'm facing > with issue what IDE is more suitable for developing git @ macos ? > > Have googled, but

Re: [PATCH v2] remote helpers: avoid blind fall-back to ".git" when setting GIT_DIR

On Thu, Dec 29, 2016 at 07:48:45PM -0500, Jeff King wrote: > On Thu, Dec 29, 2016 at 04:11:14PM -0800, Jonathan Nieder wrote: > > > Thanks. Here's the patch again, now with commit messages and a test. > > Thanks for the analysis and sorry for the slow turnaround. > > Thanks for following up.

Re: [PATCH] mingw: use OpenSSL's SHA-1 routines

Am 13.02.2017 um 23:38 schrieb Johannes Schindelin: In addition, you build from a custom MINGW/MSys1 setup, correct? Correct. Specifically, I use the build tools from "msysgit" times, but build outside the premanufactured build environement; i.e., the "THIS_IS_MSYSGIT" section in

Re: [PATCH 0/7] grep rev/path parsing fixes

On Tue, Feb 14, 2017 at 01:00:21AM -0500, Jeff King wrote: > On Mon, Feb 13, 2017 at 08:20:37PM -0500, Jeff King wrote: > > > > If there is a repo and "foo" is a rev, the "--no-index or --untracked > > > cannot be used with revs." error would occur. If there is a repo and > > > "foo" is not a

[PATCH 7/7] grep: do not diagnose misspelt revs with --no-index

If we are using --no-index, then our arguments cannot be revs in the first place. Not only is it pointless to diagnose them, but if we are not in a repository, we should not be trying to resolve any names. Signed-off-by: Jeff King --- builtin/grep.c | 2 +- t/t7810-grep.sh | 5

[PATCH 6/7] grep: avoid resolving revision names in --no-index case

We disallow the use of revisions with --no-index, but we don't actually check and complain until well after we've parsed the revisions. This is the cause of a few problems: 1. We shouldn't be calling get_sha1() at all when we aren't in a repository, as it might access the ref or object

[PATCH 5/7] grep: fix "--" rev/pathspec disambiguation

If we see "git grep pattern rev -- file" then we apply the usual rev/pathspec disambiguation rules: any "rev" before the "--" must be a revision, and we do not need to apply the verify_non_filename() check. But there are two bugs here: 1. We keep a seen_dashdash flag to handle this case, but

[PATCH 4/7] grep: re-order rev-parsing loop

We loop over the arguments, but every branch of the loop hits either a "continue" or a "break". Surely we can make this simpler. The final conditional is: if (arg is a rev) { ... handle rev ... continue; } break; We can rewrite this as: if (arg is not a rev)

[PATCH 3/7] t7810: make "--no-index --" test more robust

This makes sure that we actually use the pathspecs after "--" correctly (as opposed to just seeing if grep errored out). Signed-off-by: Jeff King --- This could be squashed into the previous patch. I didn't end up using the "nongit" helper, because we actually have to do some

[PATCH 2/7] grep: do not unnecessarily query repo for "--"

From: Jonathan Tan When running a command of the form git grep --no-index pattern -- path in the absence of a Git repository, an error message will be printed: fatal: BUG: setup_git_env called without repository This is because "git grep" tries to interpret "--"

[PATCH 1/7] grep: move thread initialization a little lower

Originally, we set up the threads for grep before parsing the non-option arguments. In 53b8d931b (grep: disable threading in non-worktree case, 2011-12-12), the thread code got bumped lower in the function because it now needed to know whether we got any revision arguments. That put a big block

[PATCH 0/7] grep rev/path parsing fixes

On Mon, Feb 13, 2017 at 08:20:37PM -0500, Jeff King wrote: > > If there is a repo and "foo" is a rev, the "--no-index or --untracked > > cannot be used with revs." error would occur. If there is a repo and > > "foo" is not a rev, this command would proceed as usual. If there is no > > repo, the

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

On Mon, Feb 13, 2017 at 08:41:51PM -0800, Junio C Hamano wrote: > Arif Khokar writes: > > > One concern I have regarding this idea is whether or not SMTP servers > > typically replace a Message-Id header set by the client. > > The clients are supposed to give

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

On 02/13/2017 11:41 PM, Junio C Hamano wrote: Arif Khokar writes: One concern I have regarding this idea is whether or not SMTP servers typically replace a Message-Id header set by the client. The clients are supposed to give Message-IDs, but because some clients

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

Arif Khokar writes: > One concern I have regarding this idea is whether or not SMTP servers > typically replace a Message-Id header set by the client. The clients are supposed to give Message-IDs, but because some clients fail to do so, SMTP server implementations are

Re: [PATCH 1/2 v3] revision.c: args starting with "-" might be a revision

Hey Junio, > > See the 3-patch series I just sent out. I didn't think it through > very carefully (especially the error message the other caller > produces), but the whole thing _smells_ correct to me. Okay, got it! I will write-up those changes, and make sure nothing bad happens. (Also, the

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

On 02/13/2017 10:56 PM, Arif Khokar wrote: I wasn't aware of that expectation. My idea was to use NNTP as a way to facilitate the development of a new git utility that would serve as the inverse of git-send-email (sort of like the relationship between git format-patch and git am), rather than

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

On 02/13/2017 09:37 AM, Johannes Schindelin wrote: Hi Arif, On Mon, 13 Feb 2017, Arif Khokar wrote: Thanks for the link. One thing that comes to mind that is that it may be better to just download the patches and then manually apply them afterwords rather than doing it in the script itself.

Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

On 02/13/2017 02:21 PM, Junio C Hamano wrote: Arif Khokar writes: ... I still think it would be better to be able to list the message-id values in the header or body of the cover letter message of a patch series (preferably the former) in order to facilitate

[PATCH v2 04/19] builtin/fast-export: convert to struct object_id

In addition to converting to struct object_id, write some hardcoded buffer sizes in terms of GIT_SHA1_RAWSZ. Signed-off-by: brian m. carlson --- builtin/fast-export.c | 58 +-- 1 file changed, 29 insertions(+), 29

[PATCH v2 02/19] builtin/diff-tree: convert to struct object_id

Convert most leaf functions to struct object_id. Rewrite several hardcoded numbers in terms of GIT_SHA1_HEXSZ, using an intermediate variable where that makes sense. Signed-off-by: brian m. carlson --- builtin/diff-tree.c | 38

[PATCH v2 11/19] builtin/replace: convert to struct object_id

Convert various uses of unsigned char [20] to struct object_id. Rename replace_object_sha1 to rename_object_oid. Finally, specify a constant in terms of GIT_SHA1_HEXSZ. Signed-off-by: brian m. carlson --- builtin/replace.c | 112

[PATCH v2 08/19] builtin/clone: convert to struct object_id

Signed-off-by: brian m. carlson --- builtin/clone.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/builtin/clone.c b/builtin/clone.c index 3f63edbbf9..b4c929bb8a 100644 --- a/builtin/clone.c +++ b/builtin/clone.c @@ -681,7 +681,7 @@

[PATCH v2 10/19] Convert remaining callers of resolve_refdup to object_id

There are a few leaf functions in various files that call resolve_refdup. Convert these functions to use struct object_id internally to prepare for transitioning resolve_refdup itself. Signed-off-by: brian m. carlson --- builtin/notes.c| 18

[PATCH v2 01/19] builtin/commit: convert to struct object_id

Convert most leaf functions to use struct object_id. Signed-off-by: brian m. carlson --- builtin/commit.c | 46 +++--- 1 file changed, 23 insertions(+), 23 deletions(-) diff --git a/builtin/commit.c b/builtin/commit.c index

[PATCH v2 13/19] refs: convert each_reflog_ent_fn to struct object_id

Make each_reflog_ent_fn take two struct object_id pointers instead of two pointers to unsigned char. Convert the various callbacks to use struct object_id as well. Also, rename fsck_handle_reflog_sha1 to fsck_handle_reflog_oid. Signed-off-by: brian m. carlson ---

[PATCH v2 00/19] object_id part 6

This is another series in the continuing conversion to struct object_id. This series converts more of the builtin directory and some of the refs code to use struct object_id. Additionally, it implements an nth_packed_object_oid function which provides a struct object_id version of the

[PATCH v2 07/19] builtin/branch: convert to struct object_id

Signed-off-by: brian m. carlson --- builtin/branch.c | 26 +- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/builtin/branch.c b/builtin/branch.c index 9d30f55b0b..faf472ff8f 100644 --- a/builtin/branch.c +++

[PATCH v2 05/19] builtin/fmt-merge-message: convert to struct object_id

Convert most of the code to use struct object_id, including struct origin_data and struct merge_parents. Convert several instances of hardcoded numbers into references to GIT_SHA1_HEXSZ. Signed-off-by: brian m. carlson --- builtin/fmt-merge-msg.c | 70

[PATCH v2 15/19] refs: simplify parsing of reflog entries

The current code for reflog entries uses a lot of hard-coded constants, making it hard to read and modify. Use parse_oid_hex and two temporary variables to simplify the code and reduce the use of magic constants. Signed-off-by: brian m. carlson ---

[PATCH v2 18/19] builtin/merge-base: convert to struct object_id

Convert the remaining uses of unsigned char [20] to struct object_id. Signed-off-by: brian m. carlson --- builtin/merge-base.c | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/builtin/merge-base.c

[PATCH v2 19/19] wt-status: convert to struct object_id

Convert the remaining uses of unsigned char [20] to struct object_id. Signed-off-by: brian m. carlson --- wt-status.c | 44 ++-- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/wt-status.c b/wt-status.c index

[PATCH v2 14/19] hex: introduce parse_oid_hex

Introduce a function, parse_oid_hex, which parses a hexadecimal object ID and if successful, sets a pointer to just beyond the last character. This allows for simpler, more robust parsing without needing to hard-code integer values throughout the codebase. Signed-off-by: brian m. carlson

[PATCH v2 06/19] builtin/grep: convert to struct object_id

Convert several functions to use struct object_id, and rename them so that they no longer refer to SHA-1. Signed-off-by: brian m. carlson --- builtin/grep.c | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git

[PATCH v2 17/19] Convert object iteration callbacks to struct object_id

Convert each_loose_object_fn and each_packed_object_fn to take a pointer to struct object_id. Update the various callbacks. Convert several 40-based constants to use GIT_SHA1_HEXSZ. Signed-off-by: brian m. carlson --- builtin/cat-file.c | 8

[PATCH v2 09/19] builtin/merge: convert to struct object_id

Additionally convert several uses of the constant 40 into GIT_SHA1_HEXSZ. Signed-off-by: brian m. carlson --- builtin/merge.c | 134 1 file changed, 66 insertions(+), 68 deletions(-) diff --git

[PATCH v2 03/19] builtin/describe: convert to struct object_id

Convert the functions in this file and struct commit_name to struct object_id. Signed-off-by: brian m. carlson --- builtin/describe.c | 50 +- 1 file changed, 25 insertions(+), 25 deletions(-) diff --git

[PATCH v2 12/19] reflog-walk: convert struct reflog_info to struct object_id

Convert struct reflog_info to use struct object_id by changing the structure definition and applying the following semantic patch: @@ struct reflog_info E1; @@ - E1.osha1 + E1.ooid.hash @@ struct reflog_info *E1; @@ - E1->osha1 + E1->ooid.hash @@ struct reflog_info E1; @@ - E1.nsha1 +

[PATCH v2 16/19] sha1_file: introduce an nth_packed_object_oid function

There are places in the code where we would like to provide a struct object_id *, yet read the hash directly from the pack. Provide an nth_packed_object_oid function that is similar to the nth_packed_object_sha1 function. In order to avoid a potentially invalid cast, nth_packed_object_oid

Re: [PATCH for NEXT] grep: do not unnecessarily query repo for "--"

On Mon, Feb 13, 2017 at 04:11:59PM -0800, Jonathan Tan wrote: > When running a command of the form > > git grep --no-index pattern -- path > > in the absence of a Git repository, an error message will be printed: > > fatal: BUG: setup_git_env called without repository > > This is because

Re: [PATCH] completion: complete modified files for checkout with '--'

On Tue, Feb 14, 2017 at 12:33 AM, wrote: > From: Cornelius Weig > > The command line completion for git-checkout bails out when seeing '--' > as an isolated argument. For git-checkout this signifies the start of a > list of files which are

Re: [RFC-PATCHv2] submodules: add a background story

On 02/08, Stefan Beller wrote: > +STATES > +-- > + > +When working with submodules, you can think of them as in a state machine. > +So each submodule can be in a different state, the following indicators are > used: > + > +* the existence of the setting of 'submodule..url' in the > +

Re: [PATCH v3 0/5] stash: support pathspec argument

On Mon, Feb 13, 2017 at 04:36:22PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > Maybe it is just me and my muscle memory, but "git stash -p" is quite a > > common command for me[1]. And I have typed "git stash -p foo" many times > > and been annoyed that it didn't work.

Re: [PATCH v3 0/5] stash: support pathspec argument

On Mon, Feb 13, 2017 at 03:50:43PM -0800, Junio C Hamano wrote: > Thomas Gummerer writes: > > >> My "-p" suggestion suffers from a similar problem if you treat it as > >> "you can omit the 'push' if you say "-p", rather than "if -p is the > >> first option, it is a synonym

[PATCH for NEXT] grep: do not unnecessarily query repo for "--"

When running a command of the form git grep --no-index pattern -- path in the absence of a Git repository, an error message will be printed: fatal: BUG: setup_git_env called without repository This is because "git grep" tries to interpret "--" as a rev. "git grep" has always tried to first

Re: [PATCH 11/11] refs: split and make get_*_ref_store() public API

> > +/* > + * Return the ref_store instance for the specified submodule. For the > + * main repository, use submodule==NULL; such a call cannot fail. So now we have both a get_main as well as a get_submodule function, but the submodule function can return the main as well? I'd rather see this as

Re: [PATCH] clean: use warning_errno() when appropriate

Jeff King writes: > So in that sense doing the errno dance as close to the caller who cares > is the most _obvious_ thing, even if it isn't the shortest. Yup. > It would be nice if there was a way to annotate a function as > errno-safe, and then transitively compute which other

Re: Continuous Testing of Git on Windows

Johannes Schindelin writes: > That is why I taught the Git for Windows CI job that tests the four > upstream Git integration branches to *also* bisect test breakages and then > upload comments to the identified commit on GitHub Good. I do not think it is useful to

Re: [PATCH 10/11] files-backend: remove submodule_allowed from files_downcast()

On Mon, Feb 13, 2017 at 7:20 AM, Nguyễn Thái Ngọc Duy wrote: > Since submodule or not is irrelevant to files-backend after the last > patch, remove the parameter from files_downcast() and kill > files_assert_main_repository(). > > PS. This implies that all ref operations are

Re: [PATCH 09/11] refs: move submodule code out of files-backend.c

On Mon, Feb 13, 2017 at 7:20 AM, Nguyễn Thái Ngọc Duy wrote: > files-backend is now initialized with a $GIT_DIR. Converting a submodule > path to where real submodule gitdir is located is done in get_ref_store(). > > The new code in init_submodule_ref_store() is basically a

[PATCH] completion: complete modified files for checkout with '--'

From: Cornelius Weig The command line completion for git-checkout bails out when seeing '--' as an isolated argument. For git-checkout this signifies the start of a list of files which are to be checked out. Checkout of files makes only sense for modified files,

Re: [PATCH v6] gc: ignore old gc.log files

David Turner writes: > +static unsigned long gc_log_expire_time; > +static const char *gc_log_expire = "1.day.ago"; OK. > @@ -113,6 +133,8 @@ static void gc_config(void) > git_config_get_bool("gc.autodetach", _auto); > git_config_date_string("gc.pruneexpire",

Re: [PATCH v2 9/9] read_loose_refs(): read refs using resolve_ref_recursively()

Michael Haggerty writes: > I pushed the fixed commit to branch `submodule-hash` in my fork [1]. If > you'd like me to send it to the mailing list again, please let me know. I was tempted to ask you to send it again, because fetching, comparing and then cherry-picking is a

Developing git with IDE

Hi *, being last decade working with java & javascript I completely lost relation to c/c++ world. Trying to get into git internals I'm facing with issue what IDE is more suitable for developing git @ macos ? Have googled, but any my search queries following to non-relevant themes, like

Re: [PATCH 08/11] refs.c: factor submodule code out of get_ref_store()

On Mon, Feb 13, 2017 at 7:20 AM, Nguyễn Thái Ngọc Duy wrote: > This code is going to be expanded a bit soon. Keep it out for > better readability later. > > Signed-off-by: Nguyễn Thái Ngọc Duy > --- Looks good, Thanks, Stefan

new git-diff switch to eliminate leading "+" and "-" characters

The output of git-diff includes lines beginning with "+" and "-" to indicate added and deleted lines. A somewhat common task (at least for me) is to want to copy output from a "diff" (usually the deleted lines) and paste it back into my code. This is quite inconvenient because of the leading

Re: [PATCH 07/11] files-backend: remove the use of git_path()

> + > + if (submodule) { > + refs->submodule = xstrdup_or_null(submodule); drop the _or_null here? So in this patch we have either * submodule set * or gitdir/gitcommondir set which means that we exercise the commondir for regular repos. In the future when we want to be able

Re: [PATCH v3 4/5] stash: introduce new format create

On Mon, Feb 13, 2017 at 04:57:34PM -0500, Jeff King wrote: > Yeah, I think your patch is actually fixing that case. But your search > is only part of the story. You found somebody using "-m" explicitly, but > what about somebody blindly calling: > > git stash create $* > > That's now

Re: [PATCH] mingw: make stderr unbuffered again

Johannes Schindelin writes: > When removing the hack for isatty(), we actually removed more than just > an isatty() hack: we removed the hack where internal data structures of > the MSVC runtime are modified in order to redirect stdout/stderr. > > Instead of using

Re: [RFC PATCH] show decorations at the end of the line

On Mon, Feb 13, 2017 at 01:01:49PM -0800, Junio C Hamano wrote: > Linus Torvalds writes: > > > And if you actually want decorations, and you're parsing them, you are > > *not* going to script it with "--oneline --decorations", because the > > end result is

Re: [PATCH] mingw: use OpenSSL's SHA-1 routines

Hi, On Mon, 13 Feb 2017, Johannes Sixt wrote: > Am 13.02.2017 um 20:42 schrieb Junio C Hamano: > > I have been operating under the assumption that everybody on Windows > > who builds Git works off of Dscho's Git for Windows tree, and patches > > that are specific to Windows from Dscho's are sent

Re: [PATCH 06/11] refs-internal.h: correct is_per_worktree_ref()

On Mon, Feb 13, 2017 at 7:20 AM, Nguyễn Thái Ngọc Duy wrote: > All refs outside refs/ directory is per-worktree, not just HEAD. > > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > refs/refs-internal.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >

[PATCH] mingw: make stderr unbuffered again

When removing the hack for isatty(), we actually removed more than just an isatty() hack: we removed the hack where internal data structures of the MSVC runtime are modified in order to redirect stdout/stderr. Instead of using that hack (that does not work with newer versions of the runtime,

Re: [PATCH v3 0/5] stash: support pathspec argument

On 02/13, Jeff King wrote: > On Mon, Feb 13, 2017 at 10:35:31PM +0100, Matthieu Moy wrote: > > > > Is it really that dangerous, though? The likely outcome is Git saying > > > "nope, you don't have any changes to the file named drop". Of course the > > > user may have meant something different,

Re: [PATCH] clean: use warning_errno() when appropriate

On Mon, Feb 13, 2017 at 01:53:33PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > IOW, I think this may be a case where we should be optimizing for > > programmer time (fewer lines of code, and one less thing to worry about > > in the callers) versus squeezing out every

Re: [PATCH v3 2/5] stash: introduce push verb

On 02/13, Matthieu Moy wrote: > Thomas Gummerer writes: > > > Introduce a new git stash push verb in addition to git stash save. The > > push verb is used to transition from the current command line arguments > > to a more conventional way, in which the message is given as

Re: [PATCH] docs/git-submodule: fix unbalanced quote

Jeff King writes: > However, let's take a step back. Even when rendered > correctly, it's hard to read a long command stuck into the > middle of a paragraph, and the important punctuation is hard > to notice. Yes, I like this reasoning behind the solution very much. Thanks. >

Re: [PATCH v3 4/5] stash: introduce new format create

On Sat, Feb 11, 2017 at 02:51:27PM +, Thomas Gummerer wrote: > > How do we tell the difference between new-style invocations, and > > old-style ones that look new-style? IOW, I think: > > > > git stash create -m works > > > > currently treats "-m works" as the full message, and it would

Re: [PATCH] clean: use warning_errno() when appropriate

Jeff King writes: > IOW, I think this may be a case where we should be optimizing for > programmer time (fewer lines of code, and one less thing to worry about > in the callers) versus squeezing out every instruction. Fair enough. Unless we do the save_errno dance in all the

Re: Incorrect pipe for git log graph when using --name-status option

On Mon, Feb 13, 2017 at 01:43:45PM -0800, hIpPy wrote: > With --name-status: I'm sorry if I nitpick here but I think the > --name-status items should either be preceeded and followed by > blank line OR not (as in oneline) but not just preceded (example > below). Yeah, I agree the output is a bit

Re: [PATCH v3 0/5] stash: support pathspec argument

On Mon, Feb 13, 2017 at 10:35:31PM +0100, Matthieu Moy wrote: > > Is it really that dangerous, though? The likely outcome is Git saying > > "nope, you don't have any changes to the file named drop". Of course the > > user may have meant something different, but I feel like "-p" is a good > >

Re: Incorrect pipe for git log graph when using --name-status option

On Mon, Feb 13, 2017 at 1:27 PM, Jeff King wrote: > On Mon, Feb 13, 2017 at 01:18:40PM -0800, Junio C Hamano wrote: > >> Jeff King writes: >> >> > I think the problem is specifically related to the "terminator" versus >> > "separator" semantics. Try: >> > >> > git

Employee interviews

Is GIT SCM conducting interviews via Google chat? I'm responding to a zip recruiter job listing. Thank You. Just looking for some official company information such as an office address, work phone number, or business email domain. Thank You. CG

Re: Incorrect pipe for git log graph when using --name-status option

On Mon, Feb 13, 2017 at 01:18:40PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > I think the problem is specifically related to the "terminator" versus > > "separator" semantics. Try: > > > > git log --graph --name-status --pretty=format:%h > > > > versus: > > > >

Re: [RFH] Request for Git Merge 2017 impressions for Git Rev News

Hi, On Sat, Feb 11, 2017 at 5:33 PM, Jakub Narębski wrote: > Hello, > > Git Rev News #24 is planned to be released on February 15. It is meant > to cover what happened during the month of January 2017 (and earely > February 2017) and the Git Merge 2017 conference that happened

Re: Incorrect pipe for git log graph when using --name-status option

Jeff King writes: > I think the problem is specifically related to the "terminator" versus > "separator" semantics. Try: > > git log --graph --name-status --pretty=format:%h > > versus: > > git log --graph --name-status --pretty=tformat:%h > > The latter works fine. The

Re: Incorrect pipe for git log graph when using --name-status option

On Mon, Feb 13, 2017 at 12:55:07PM -0800, hIpPy wrote: > I think that requiring to end custom formats with %n with options > is not good. So I think this is a bug. Yes, you don't normally need to do that. I think the problem is specifically related to the "terminator" versus "separator"

[PATCH] docs/git-submodule: fix unbalanced quote

The documentation gives an example of the submodule foreach command that uses both backticks and single-quotes. We stick the whole thing inside "+" markers to make it monospace, but the inside punctuation still needs escaping. We handle the backticks with "{backtick}", and use backslash-escaping

Re: [PATCH] clean: use warning_errno() when appropriate

On Mon, Feb 13, 2017 at 12:38:47PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > I wonder if xmalloc() should be the one doing the saved_errno trick. > > After all, it has only two outcomes: we successfully allocated the > > memory, or we called die(). > > I would be

Re: [RFC PATCH] show decorations at the end of the line

Linus Torvalds writes: > And if you actually want decorations, and you're parsing them, you are > *not* going to script it with "--oneline --decorations", because the > end result is basically impossible to parse already (because it's > ambiguous - think about

Re: [PATCH] mingw: use OpenSSL's SHA-1 routines

Am 13.02.2017 um 20:42 schrieb Junio C Hamano: I have been operating under the assumption that everybody on Windows who builds Git works off of Dscho's Git for Windows tree, and patches that are specific to Windows from Dscho's are sent to me via the list only after they have been in Git for

Re: [PATCH] rm: reuse strbuf for all remove_dir_recursively() calls, again

On Sat, Feb 11, 2017 at 11:51 AM, René Scharfe wrote: > Don't throw the memory allocated for remove_dir_recursively() away after > a single call, use it for the other entries as well instead. > > This change was done before in deb8e15a (rm: reuse strbuf for all >

Re: [PATCH 04/11] files-backend: replace *git_path*() with files_path()

On 13/02/17 15:20, Nguyễn Thái Ngọc Duy wrote: > This centralizes all path rewriting of files-backend.c in one place so > we have easier time removing the path rewriting later. There could be > some hidden indirect git_path() though, I didn't audit the code to the > bottom. > > Side note:

Re: Incorrect pipe for git log graph when using --name-status option

On Mon, Feb 13, 2017 at 11:25 AM, Junio C Hamano wrote: > hIpPy writes: > >> The `git log` command with `graph` and pretty format works correctly >> as expected. >> >> $ git log --graph --pretty=format:'%h' -2 >> * 714a14e >> * 87dce5f >> >> >> However,

Re: Small regression on Windows

Jeff Hostetler writes: > The warning text is being written to stderr and then main thread > sleeps for the 4 seconds. However, stderr has been redirected to > the pipe connected to the console_thread that handles the > coloring/pager. It is in a blocking ReadFile on the

Re: [PATCH] completion: restore removed line continuating backslash

SZEDER Gábor writes: > Recent commit 1cd23e9e0 (completion: don't use __gitdir() for git > commands, 2017-02-03) rewrapped a couple of long lines, and while > doing so it inadvertently removed a '\' from the end of a line, thus > breaking completion for 'git config

Re: [PATCH 03/11] files-backend: add files_path()

On 13/02/17 15:20, Nguyễn Thái Ngọc Duy wrote: > This will be the replacement for both git_path() and git_path_submodule() > in this file. The idea is backend takes a git path and use that, > oblivious of submodule, linked worktrees and such. > > This is the middle step towards that. Eventually

IT System Alerts

Help Desk This e-mail has been sent to you by Outlook Web App If you do not agree to update your account, your email account will be blocked. Click Her to update Sincerely, IT-Service Help Desk

Re: Small regression on Windows

On 2/13/2017 1:00 PM, Johannes Sixt wrote: Please type this, preferably outside of any repo to avoid that it is changed; note the command typo: git -c help.autocorrect=40 ceckout Git waits for 4 seconds, but does not write anything until just before it exits. It bisects to

Re: [PATCH] clean: use warning_errno() when appropriate

Jeff King writes: > I wonder if xmalloc() should be the one doing the saved_errno trick. > After all, it has only two outcomes: we successfully allocated the > memory, or we called die(). I would be lying if I said I did not considered it when I wrote the message you are

Re: [PATCH 02/11] files-backend: convert git_path() to strbuf_git_path()

On 13/02/17 15:20, Nguyễn Thái Ngọc Duy wrote: > git_path() and friends are going to be killed in files-backend.c in near > future. And because there's a risk with overwriting buffer in > git_path(), let's convert them all to strbuf_git_path(). We'll have > easier time killing/converting

[PATCH] docs/gitremote-helpers: fix unbalanced quotes

Each of these options is missing the closing single-quote on the option name. This understandably confuses asciidoc, which ends up rendering a stray quote, like: option cloning {'true|false} Signed-off-by: Jeff King --- Documentation/gitremote-helpers.txt | 6 +++--- 1 file

Re: Bug in 'git describe' if I have two tags on the same commit.

Kevin Daudt writes: > On Sun, Feb 12, 2017 at 01:15:22PM +0100, Istvan Pato wrote: > >> (master) [1] % git show-ref --tag >> 76c634390... refs/tags/1.0.0 >> b77c7cd17... refs/tags/1.1.0 >> b77c7cd17... refs/tags/1.2.0 >> >> (master) % git describe --tags --always >>

Re: [PATCH] squash! completion: fill COMPREPLY directly when completing refs

SZEDER Gábor writes: > On Fri, Feb 10, 2017 at 10:44 PM, Junio C Hamano wrote: > >> Should I expect a reroll to come, or is this the only fix-up to the >> series that begins at <20170203025405.8242-1-szeder@gmail.com>? >> >> No hurries. > > Yes,

Re: [PATCH 01/11] refs-internal.c: make files_log_ref_write() static

On 13/02/17 15:20, Nguyễn Thái Ngọc Duy wrote: > Created in 5f3c3a4e6f (files_log_ref_write: new function - 2015-11-10) > but probably never used outside refs-internal.c > > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > refs/files-backend.c | 3 +++ > refs/refs-internal.h | 4

Re: [PATCH v3 0/5] stash: support pathspec argument

On Mon, Feb 13, 2017 at 03:14:55PM +0100, Matthieu Moy wrote: > I don't remember doing this intentionally. The goal was really to > prevent typos like "git stash -p drop" (which would have been > interpreted as "git stash save -p drop" previously). So, let's consider > this "only messages

Re: [PATCH 2/2 v3] sha1_name: teach get_sha1_1 "-" shorthand for "@{-1}"

Junio C Hamano writes: > Matthieu Moy writes: > >> Siddharth Kannan writes: >> >>> + if (!strcmp(name, "-")) { >>> + name = "@{-1}"; >>> + len = 5; >>> + } >> >> One drawback of this approach

Re: [PATCH 2/2 v3] sha1_name: teach get_sha1_1 "-" shorthand for "@{-1}"

Matthieu Moy writes: > Siddharth Kannan writes: > >> +if (!strcmp(name, "-")) { >> +name = "@{-1}"; >> +len = 5; >> +} > > One drawback of this approach is that further error messages will be > given

  1   2   >