Re: git alias for options

On Fri, Feb 17, 2017 at 02:34:15PM -0800, hIpPy wrote: > I think the conversation has drifted away from what I am asking / hoping for. Yeah, the usual answer to "can we have custom options" is "use a custom alias". But I agree they are not quite the same thing. > Say I want an alias for option

Re: [PATCH 0/5] A series of performance enhancements in the memihash and name-cache area

On Fri, Feb 17, 2017 at 09:58:21PM -0800, Junio C Hamano wrote: > Jeff Hostetler writes: > > > I'll try to put together a before/after perf-test to better > > demonstrate this. > > I didn't pick up the series while watching these exchanges, as I > didn't know how quick

Re: [PATCH 0/5] A series of performance enhancements in the memihash and name-cache area

Jeff Hostetler writes: > I'll try to put together a before/after perf-test to better > demonstrate this. I didn't pick up the series while watching these exchanges, as I didn't know how quick your turnaround would be, but now a few days have passed. Just to make sure we

Re: [PATCH 0/5] A series of performance enhancements in the memihash and name-cache area

Jeff King writes: > On Wed, Feb 15, 2017 at 09:27:53AM -0500, Jeff Hostetler wrote: > >> I have some informal numbers in a spreadsheet. I was seeing >> a 8-9% speed up on a status on my gigantic repo. >> >> I'll try to put together a before/after perf-test to better >>

Re: [PATCH 3/5] name-hash: precompute hash values during preload-index

Johannes Schindelin writes: > +void precompute_istate_hashes(struct cache_entry *ce) > +{ > + int namelen = ce_namelen(ce); > + > + while (namelen > 0 && !is_dir_sep(ce->name[namelen - 1])) > + namelen--; > + > + if (namelen <= 0) { > +

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

Jeff King writes: >> The updates to the expectation look like this (already squashed). >> The --source decorations in 4202 are also shown at the end, which >> probably is in line with the way --show-decorations adds them at the >> end of the line, but was somewhat surprising from

Re: [PATCH 2/5] hashmap: allow memihash computation to be continued

Johannes Schindelin writes: > diff --git a/hashmap.c b/hashmap.c > index b10b642229c..061b7d61da6 100644 > --- a/hashmap.c > +++ b/hashmap.c > @@ -50,6 +50,20 @@ unsigned int memihash(const void *buf, size_t len) > return hash; > } > > +/* Incoporate another

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

On Fri, Feb 17, 2017 at 08:42:17PM -0500, Jeff King wrote: > > I'm wondering if parse_oid_hex could be useful here as well. > > I know I haven't looked at this chunk nearly as carefully as you have, > but it seems somewhat crazy to me that these functions get the original > "line" in the first

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

On Sat, Feb 18, 2017 at 01:26:07AM +, brian m. carlson wrote: > > > + struct object_id oid; > > > struct tree *tree2; > > > - if (len != 82 || !isspace(line[40]) || get_sha1_hex(line + 41, sha1)) > > > + const int chunksz = GIT_SHA1_HEXSZ + 1; > > > + if (len != 2 * chunksz ||

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

On Sat, Feb 18, 2017 at 01:24:34AM +, Ramsay Jones wrote: > > > On 18/02/17 00:06, brian m. carlson wrote: > > 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

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

On Sat, Feb 18, 2017 at 01:18:11AM +, Ramsay Jones wrote: > > > On 18/02/17 00:06, brian m. carlson wrote: > > 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. > > >

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

On 18/02/17 00:06, brian m. carlson wrote: > 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

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

On 18/02/17 00:06, brian m. carlson wrote: > 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 > --- >

[PATCH] remote: Ignore failure to remove missing branch..merge

If a branch is configured with a default remote but no branch..merge and then the remote is removed, git fails to remove the remote with: "fatal: could not unset 'branch..merge'" Instead, ignore this since it is not an error and shouldn't prevent the remote from being removed. Signed-off-by:

[PATCH v3 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 v3 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 v3 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 v3 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 v3 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 v3 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 v3 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 v3 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 v3 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 v3 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 v3 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 v3 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 replace_object_oid. Finally, specify a constant in terms of GIT_SHA1_HEXSZ. Signed-off-by: brian m. carlson --- builtin/replace.c | 112

[PATCH v3 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 v3 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 v3 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 v3 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 v3 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 v3 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 v3 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 v3 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] tempfile: avoid "ferror | fclose" trick

Jeff King writes: > I'm also not sure that it's all that useful to distinguish errors from > fwrite() versus fclose(). In practice, errors will come from write() in > either case, and the caller does not have much control over when the > flushing happens. So any error saying

Re: [PATCH] Document dotfiles exclusion on template copy

Thanks, will queue.

Re: [PATCH] tempfile: avoid "ferror | fclose" trick

On Fri, Feb 17, 2017 at 03:52:36PM -0800, Junio C Hamano wrote: > > So I think that "easy" thing falls far short of a solution, but it's at > > least easy. I could take it or leave it at this point. > > Well, I already said that earlier in this thread, and ended up > queuing your patch on 'pu'

Re: [PATCH 3/3] rename_ref: replace empty deletion message in HEAD's log

On Fri, Feb 17, 2017 at 06:41:32PM -0500, Kyle Meyer wrote: > Junio C Hamano writes: > > [...] > > > Do we even want these "internal" delete_ref() invocations to be > > logged in HEAD's reflog? I understand that this is inside the > > implementation of renaming an old ref

Re: [PATCH 3/3] rename_ref: replace empty deletion message in HEAD's log

Kyle Meyer writes: > Junio C Hamano writes: > > [...] > >> Do we even want these "internal" delete_ref() invocations to be >> logged in HEAD's reflog? I understand that this is inside the >> implementation of renaming an old ref to a new ref, and reflog >>

Re: [PATCH] mingw: make stderr unbuffered again

Johannes Schindelin writes: > ... there is a different problem here: you stated very explicitly > that it is okay for `pu` to be broken [*1*]. If it were different, if any > breakage would imply that a fix is really, really required lest the patch > series be evicted

Re: [PATCH v5 3/6] stash: refactor stash_create

On Fri, Feb 17, 2017 at 10:41:38PM +, Thomas Gummerer wrote: > Refactor the internal stash_create function to use a -m flag for > specifying the message and -u flag to indicate whether untracked files > should be added to the stash. > > This makes it easier to pass a pathspec argument to

Re: [PATCH v5 6/6] stash: allow pathspecs in the no verb form

On Fri, Feb 17, 2017 at 10:41:41PM +, Thomas Gummerer wrote: > Now that stash_push is used in the no verb form of stash, allow > specifying the command line for this form as well. Always use -- to > disambiguate pathspecs from other non-option arguments. I think that makes sense. > Also

Re: [PATCH 3/3] rename_ref: replace empty deletion message in HEAD's log

Jeff King writes: > On Fri, Feb 17, 2017 at 02:43:50PM -0500, Jeff King wrote: > >> Yes. I think the options are basically (in order of decreasing >> preference in my opinion): >> >> 1. Log a rename entry (same sha1, but note the rename in the free-form >> text). >> >>

Re: [PATCH 2/3] update-ref: pass reflog message argument to delete_refs

On Fri, Feb 17, 2017 at 06:40:28PM -0500, Kyle Meyer wrote: > > For reference, the two things I notice are: > > > > - we prefer test_path_is_missing to "! test -f" these days. > > > > - we don't redirect the output of grep (it's handled already in > > non-verbose mode, and in verbose mode

Re: [PATCH 3/3] rename_ref: replace empty deletion message in HEAD's log

Junio C Hamano writes: [...] > Do we even want these "internal" delete_ref() invocations to be > logged in HEAD's reflog? I understand that this is inside the > implementation of renaming an old ref to a new ref, and reflog > message given to delete_ref() would matter only

Re: [PATCH 2/3] update-ref: pass reflog message argument to delete_refs

Jeff King writes: [...] >> diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh >> index b0ffc0b57..65918d984 100755 >> --- a/t/t1400-update-ref.sh >> +++ b/t/t1400-update-ref.sh >> @@ -85,6 +85,15 @@ test_expect_success "delete $m (by HEAD)" ' >> ' >> rm -f .git/$m >>

Re: [PATCH] tempfile: avoid "ferror | fclose" trick

On Fri, Feb 17, 2017 at 02:40:19PM -0800, Junio C Hamano wrote: > > Right. EIO is almost certainly _not_ the error we saw. But I would > > rather consistently say "I/O error" and have the user scratch their > > head, look up this thread, and say "ah, it was probably a deferred > > error", as

Re: dotfiles in git template dir are not copied

>There was no 'bug' either. It's just the way it is ;-) Sure !

[PATCH] Document dotfiles exclusion on template copy

Since there is no dotfile in the default template directory, there was no point in making the check for . or .. more accurate when copying. Now that you can customize the template directory, it would make sense, but it's actually a good thing to at this because you would not want to have your git

Re: [PATCH 1/3] delete_refs(): accept a reflog message argument

Junio C Hamano writes: > Jeff King writes: > >>> diff --git a/refs.h b/refs.h >>> index 9fbff90e7..81627a63d 100644 >>> --- a/refs.h >>> +++ b/refs.h >>> @@ -277,7 +277,7 @@ int reflog_exists(const char *refname); >>> * be NULL_SHA1. flags is passed through

Re: [PATCH] Document dotfiles exclusion on template copy

-The template directory contains files and directories that will be copied to -the `$GIT_DIR` after it is created. +The template directory contains files and directories whose name do not start +with a dot will be copied to the `$GIT_DIR` after it is created. The template directory

Re: dotfiles in git template dir are not copied

> Thanks for your guidance. I believe I just sent the patch to the mailing list. I just retried with the Gmail SMTP, and now I am sure it worked. Sorry for the noobery.

[PATCH] Document dotfiles exclusion on template copy

Since there is no dotfile in the default template directory, there was no point in making the check for . or .. more accurate when copying. Now that you can customize the template directory, it would make sense, but it's actually a good thing to at this because you would not want to have your git

Re: dotfiles in git template dir are not copied

Thanks for your guidance. I believe I just sent the patch to the mailing list.

Re: Git bisect does not find commit introducing the bug

Hi, On 02/17/2017 11:29 PM, Alex Hoffman wrote: > According to the documentation "git bisect" is designed "to find the > commit that introduced a bug" . > I have found a situation in which it does not returns the commit I expected. > In order to reproduce the problem: For the others who are too

Re: [PATCH v5 0/6] stash: support pathspec argument

Thomas Gummerer writes: > On 02/17, Junio C Hamano wrote: >> Thomas Gummerer writes: >> >> [some people may see this message twice, as I forgot to check if the >> copy I received had "Some A . Body" not enclosed in dq; blindly >> doing "Reply-All"

[ANNOUNCE] Git v2.12.0-rc2

A release candidate Git v2.12.0-rc2 is now available for testing at the usual places. It is comprised of 487 non-merge commits since v2.11.0, contributed by 67 people, 21 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following

Re: [PATCH v5 0/6] stash: support pathspec argument

On 02/17, Junio C Hamano wrote: > Thomas Gummerer writes: > > [some people may see this message twice, as I forgot to check if the > copy I received had "Some A . Body" not enclosed in dq; blindly > doing "Reply-All" ended up listing an invalid address on my Cc: line > and

Re: body-CC-comment regression

Junio C Hamano writes: > Matthieu Moy writes: > >> Junio C Hamano writes: >> >>> That approach may still constrain what those in the former camp can >>> write in the "cruft" part, like they cannot write comma or semicolon >>>

Re: [PATCH v5 0/6] stash: support pathspec argument

Thomas Gummerer writes: [some people may see this message twice, as I forgot to check if the copy I received had "Some A . Body" not enclosed in dq; blindly doing "Reply-All" ended up listing an invalid address on my Cc: line and dropped by vger. apologies] > diff --git

Re: [PATCH] submodule.c: Add missing quotation marks

On 02/18, Phillip Sz wrote: > Hi, > > just found this while translating, sorry if this is intended. > > Best regards, > > Phillip Definitely not intended. Thanks for catching that. > --- > submodule.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/submodule.c

Re: [PATCH v5 0/6] stash: support pathspec argument

On 02/17, Junio C Hamano wrote: > Thomas Gummerer writes: > > > Thanks Matthieu, Peff and Junio for the discussion on v3 and v4. > > > > Changes since v4: > > Dropped patch 1 from the series, as it's already in master > > > > Instead of changing the external interface to

[PATCH] submodule.c: Add missing quotation marks

Hi, just found this while translating, sorry if this is intended. Best regards, Phillip --- submodule.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/submodule.c b/submodule.c index 3b98766a6..b064ed080 100644 --- a/submodule.c +++ b/submodule.c @@ -1181,7 +1181,7 @@

Re: dotfiles in git template dir are not copied

Grégoire PARIS writes: >> You could, for example, have your template directory itself be a git > repository. > > I can and I do and indeed, that might be the reason behind this. > I made a PR to document this : https://github.com/git/git/pull/325 Let's take a look. >

Re: dotfiles in git template dir are not copied

Grégoire PARIS writes: >> I do not think we should change the behaviour >> to copy files whose names begin with a dot. > > So bug turned feature it is :) There was no 'bug' either. It's just the way it is ;-)

Re: dotfiles in git template dir are not copied

Le 17/02/2017 à 23:39, Philip Oakley a écrit : From: "Grégoire PARIS" > You could, for example, have your template directory itself be a git repository. I can and I do and indeed, that might be the reason behind this. I made a PR to document this :

[PATCH v5 5/6] stash: use stash_push for no verb form

Now that we have stash_push, which accepts pathspec arguments, use it instead of stash_save in git stash without any additional verbs. Previously we allowed git stash -- -message, which is no longer allowed after this patch. Messages starting with a hyphen was allowed since 3c2eb80f, ("stash:

Re: [PATCH] tempfile: avoid "ferror | fclose" trick

Jeff King writes: >> If we are trying to make sure that the caller would not say "failed >> to close tempfile: ERRNO" with an ERRNO that is unrelated to any >> stdio opration, I am not sure if the patch improves things. The >> caller did not fail to close (most likely we

[PATCH v5 0/6] stash: support pathspec argument

Thanks Matthieu, Peff and Junio for the discussion on v3 and v4. Changes since v4: Dropped patch 1 from the series, as it's already in master Instead of changing the external interface to git stash create, only refactor the internal create_stash() function to take -m and -u arguments. This also

[PATCH v5 6/6] stash: allow pathspecs in the no verb form

Now that stash_push is used in the no verb form of stash, allow specifying the command line for this form as well. Always use -- to disambiguate pathspecs from other non-option arguments. Also make git stash -p an alias for git stash push -p. This allows users to use git stash -p .

[PATCH v5 3/6] stash: refactor stash_create

Refactor the internal stash_create function to use a -m flag for specifying the message and -u flag to indicate whether untracked files should be added to the stash. This makes it easier to pass a pathspec argument to stash_create in the next patch. The user interface for git stash create stays

[PATCH v5 1/6] stash: introduce push verb

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 an argument to the -m option. This allows us to have pathspecs at the end of the command

[PATCH v5 2/6] stash: add test for the create command line arguments

Currently there is no test showing the expected behaviour of git stash create's command line arguments. Add a test for that to show the current expected behaviour and to make sure future refactorings don't break those expectations. Signed-off-by: Thomas Gummerer ---

[PATCH v5 4/6] stash: teach 'push' (and 'create_stash') to honor pathspec

While working on a repository, it's often helpful to stash the changes of a single or multiple files, and leave others alone. Unfortunately git currently offers no such option. git stash -p can be used to work around this, but it's often impractical when there are a lot of changes over multiple

Re: Re: dotfiles in git template dir are not copied

From: "Grégoire PARIS" > You could, for example, have your template directory itself be a git repository. I can and I do and indeed, that might be the reason behind this. I made a PR to document this : https://github.com/git/git/pull/325 While the PR is a simple one

Re: dotfiles in git template dir are not copied

> I do not think we should change the behaviour > to copy files whose names begin with a dot. So bug turned feature it is :) I amended my commit message accordingly. In my case, my template dir is not at the root of the repository where it is versioned, so it would not be a problem for me,

Re: git alias for options

I think the conversation has drifted away from what I am asking / hoping for. I apologize but I do not feel in the position of submitting patches yet. I'll first need to read some code first before that. I'm coming from the angle where currently I can alias just the command (ex: l for log) not

Re: git alias for options

Jeff King writes: > On Fri, Feb 17, 2017 at 11:10:08PM +0100, Ævar Arnfjörð Bjarmason wrote: > >> The most gentle first step would be to try to turn the existing config >> options where you can override cli-options into some declarative thing >> from the current ad-hoc code we

Git bisect does not find commit introducing the bug

Hi there, According to the documentation "git bisect" is designed "to find the commit that introduced a bug" . I have found a situation in which it does not returns the commit I expected. In order to reproduce the problem: 1. mkdir test; cd test; git clone

Re: git diff --quiet exits with 1 on clean tree with CRLF conversions

On Friday 17 February 2017 at 14:05:17 -0800, Junio C Hamano wrote: > Mike Crowe writes: > > > If "git diff --quiet" finds it necessary to compare actual file contents, > > and a file requires CRLF conversion, then it incorrectly exits with an exit > > code of 1 even if there

Re: body-CC-comment regression

Matthieu Moy writes: > Junio C Hamano writes: > >> That approach may still constrain what those in the former camp can >> write in the "cruft" part, like they cannot write comma or semicolon >> as part of the "cruft", no? > > Right. Indeed, this

Re: [PATCH 3/3] rename_ref: replace empty deletion message in HEAD's log

Jeff King writes: > Thinking on it more, we probably _do_ want two entries. Because the > operations are not atomic, it's possible that we may end up in a > half-way state after the first entry is written. And when debugging such > a case, I'd much rather see the first half of the

Re: git alias for options

On Fri, Feb 17, 2017 at 9:42 PM, Jeff King wrote: > On Fri, Feb 17, 2017 at 02:50:23PM +0100, Ævar Arnfjörð Bjarmason wrote: > >> On Fri, Feb 17, 2017 at 9:23 AM, hIpPy wrote: >> > Git has aliases for git commands. Is there a (an inbuilt) way to alias >> >

Re: [PATCH] tempfile: avoid "ferror | fclose" trick

On Fri, Feb 17, 2017 at 01:42:21PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > On Fri, Feb 17, 2017 at 01:17:06PM -0800, Junio C Hamano wrote: > > > >> Stepping back a bit, would this be really needed? Even if the ferror() > >> does not update errno, the original

Re: git alias for options

On Fri, Feb 17, 2017 at 11:10:08PM +0100, Ævar Arnfjörð Bjarmason wrote: > > A first step in that direction would probably be an environment variable > > to tell Git to suppress command-aliases. Scripts would set that to > > ensure a more vanilla experience. It doesn't fix _existing_ scripts, but

Re: dotfiles in git template dir are not copied

Grégoire PARIS writes: >> You could, for example, have your template directory itself be a git > repository. > > I can and I do and indeed, that might be the reason behind this. An embedded .git was _not_ the reason behind the current behaviour when we wrote it. The

Re: git diff --quiet exits with 1 on clean tree with CRLF conversions

Mike Crowe writes: > If "git diff --quiet" finds it necessary to compare actual file contents, > and a file requires CRLF conversion, then it incorrectly exits with an exit > code of 1 even if there have been no changes. > > The patch below adds a test file that shows the

Re: [PATCH] l10n: de.po: translate 241 messages

Hey, > @@ -916,17 +916,17 @@ msgstr "" > msgid "" > "The merge base %s is %s.\n" > "This means the first '%s' commit is between %s and [%s].\n" > msgstr "" > "Die Merge-Basis %s ist %s.\n" > "Das bedeutet, der erste '%s' Commit befindet sich zwischen %s und [%s]\n" "Das bedeutet, der erste

Re: Re: dotfiles in git template dir are not copied

> You could, for example, have your template directory itself be a git repository. I can and I do and indeed, that might be the reason behind this. I made a PR to document this : https://github.com/git/git/pull/325 -- greg0ire

Re: [PATCH v2 00/19] object_id part 6

On Fri, Feb 17, 2017 at 10:55:03AM +0100, Michael Haggerty wrote: > On 02/14/2017 03:31 AM, brian m. carlson wrote: > > 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

Re: [PATCH] tempfile: avoid "ferror | fclose" trick

Jeff King writes: > On Fri, Feb 17, 2017 at 01:17:06PM -0800, Junio C Hamano wrote: > >> Stepping back a bit, would this be really needed? Even if the ferror() >> does not update errno, the original stdio operation that failed >> would have, no? > > Sure, but we have no clue what

git diff --quiet exits with 1 on clean tree with CRLF conversions

If "git diff --quiet" finds it necessary to compare actual file contents, and a file requires CRLF conversion, then it incorrectly exits with an exit code of 1 even if there have been no changes. The patch below adds a test file that shows the problem. The first test of diff without --quiet

Re: [PATCH] tempfile: avoid "ferror | fclose" trick

On Fri, Feb 17, 2017 at 01:17:06PM -0800, Junio C Hamano wrote: > > I guess we are simultaneously assuming that it is OK to munge errno on > > success in our function, but that fclose() will not do so. Which seems a > > bit hypocritical. Maybe the "if" dance is better. > > Yes. When both

Re: [PATCH] tempfile: avoid "ferror | fclose" trick

Jeff King writes: > On Fri, Feb 17, 2017 at 11:42:25AM +0100, Michael Haggerty wrote: > >> On 02/17/2017 09:07 AM, Jeff King wrote: >> > [...] >> > That's similar to what I wrote earlier, but if we don't mind overwriting >> > errno unconditionally, I think just: >> > >> > errno

Re: [PATCH] tempfile: avoid "ferror | fclose" trick

On Fri, Feb 17, 2017 at 03:54:42PM -0500, Jeff King wrote: > I guess we are simultaneously assuming that it is OK to munge errno on > success in our function, but that fclose() will not do so. Which seems a > bit hypocritical. Maybe the "if" dance is better. So here's that patch with a

Re: [PATCH] tempfile: avoid "ferror | fclose" trick

On Fri, Feb 17, 2017 at 11:42:25AM +0100, Michael Haggerty wrote: > On 02/17/2017 09:07 AM, Jeff King wrote: > > [...] > > That's similar to what I wrote earlier, but if we don't mind overwriting > > errno unconditionally, I think just: > > > > errno = EIO; /* covers ferror(), overwritten by

Re: [PATCH v2 00/16] Remove submodule from files-backend.c

Junio C Hamano writes: > Nguyễn Thái Ngọc Duy writes: > >> I'll be sending two more follow-up series, if you are interested, soon: >> >> 1) v2 of nd/worktree-gc-protection >> ... >> 2) the real worktree-gc-protection >> >> This series adds a bunch of new

Re: dotfiles in git template dir are not copied

On Fri, Feb 17, 2017 at 10:31:37AM +0100, greg0ire wrote: > I noticed yesterday that dotfiles inside the directory configured in > init.templatedir are not copied when creating a new repository. > > Here is the line I think is responsible for this behavior : >

Re: git alias for options

On Fri, Feb 17, 2017 at 02:50:23PM +0100, Ævar Arnfjörð Bjarmason wrote: > On Fri, Feb 17, 2017 at 9:23 AM, hIpPy wrote: > > Git has aliases for git commands. Is there a (an inbuilt) way to alias > > options? If not, what is the reason? > > This has long been on my

Re: body-CC-comment regression

Junio C Hamano writes: > That approach may still constrain what those in the former camp can > write in the "cruft" part, like they cannot write comma or semicolon > as part of the "cruft", no? Right. Indeed, this may be a problem since the use of "#" for stable seem to

  1   2   >