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 -
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 your turnaround would be,
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 won't forget this topic,
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
>> demonstrate this.
>
> Tha
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) {
> + ce->precomputed_hash.nam
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 reading only the
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 chunk of data into a memihash
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 pl
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 || !isspace(line[
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 is
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.
> >
>
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
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
> ---
> builtin/diff-tree.c | 38 +
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: Ross
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 2de5f6cc64..4e288bc513 100644
-
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 5fac8437b0..a8d1faf80d 100644
-
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 ---
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 @@ static void update_head(const st
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 a/builtin/grep.c b/builtin/grep.c
index 2c727e
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 nth_packed_o
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 +-
builtin/receive-pack.c |
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
---
refs/files-backend.c | 11 ++-
1 file
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 +++---
1 file c
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 a/builtin/describe.c b/builtin/describe.c
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 deletions(-)
diff --git a/builtin
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 a/builtin/merge.c b/builtin/merge.c
index a9
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
builtin/count-objects.c | 4 ++--
bu
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 b/builtin/merge-base.c
index db95bc29cf..cfe2a796
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
+++ b/builtin/branch.c
@@ -32,7 +32,7 @@ static cons
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 --
1 file changed, 20 insertion
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
+ E1.noid.ha
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
---
builtin/fsck.c | 16
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
---
cac
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
provide
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 "error closing file"
Thanks, will queue.
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' ;-
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 to a new ref, and ref
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
>> message given to delete_ref() would ma
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 from `pu`, we could easily mo
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 stas
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 mak
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).
>>
>> 2. Log a delete
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
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 if the HEAD happens
>
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
>>
>> +test_expect_
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 oppos
>There was no 'bug' either. It's just the way it is ;-)
Sure !
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 d
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 to ref_transaction_delete().
>>> *
-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 will
> 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.
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 d
Thanks for your guidance. I believe I just sent the patch to the mailing
list.
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 l
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" ended up listing an invalid address on my Cc: l
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 pu
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 dropped by vger. apolog
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
>>> as part of the "cruft", no?
>>
>> Right. Indeed, this may be a proble
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 a/git-stash.sh b/git-stas
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 b
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 git stash create, only
>
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 @@ i
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.
> From: Grégoire PARIS
> Da
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 ;-)
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 : https://github.com/git/git/pull/325
While th
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: sim
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 successfully closed
>> i
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
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 .
Signed-off-b
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 line
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
---
t/t3903-stash.sh | 18 ++
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 t
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 f
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 line change to the document
> 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, but
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 co
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 have for each one.
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 https://github.com/entbugger/git-bisect-
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 have been no changes
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 may be a problem since the use of "#" for stable
>
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 operation logge
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
>> > options? If not, what is the reason?
>>
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 stdio operation that
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
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 primary reason is because w
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 problem.
If "git diff"
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
> 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
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 ob
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 happened in bet
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 corre
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 ferror(
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 = EIO; /* cover
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 justificat
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 fa
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 refs API, enough for revision.c to
>> tr
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 :
> https://github.com/git/git/blob/mast
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 wishlist, because there's a l
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 include commit message, a
1 - 100 of 189 matches
Mail list logo
