[cc:+torsten]
On Mon, Jun 11, 2018 at 9:46 PM, Anthony Sottile wrote:
> On Wed, Jun 6, 2018 at 10:22 AM, Eric Sunshine
> wrote:
>> Thanks for pointing that out. In that case, it's following existing
>> practice, thus certainly not worth a re-roll.
>
> Anything else for me to do here? (sorry!
brian m. carlson wrote:
> On Mon, Jun 11, 2018 at 12:01:03PM -0700, Jonathan Nieder wrote:
>> 1. Hash to be used for command output to the terminal
>> 2. Hash used in pack files
>> 3. Additional hashes (beyond (2)) that we can look up using the
>> translation table
>> 4. Additional hashes
On Mon, Jun 11, 2018 at 12:01:03PM -0700, Jonathan Nieder wrote:
> Hi,
>
> brian m. carlson wrote:
> > I plan on introducing an array of hash algorithms into struct repository
> > (and wrapper macros) which stores, in order, the output hash, and if
> > used, the additional input hash.
>
>
On Wed, Jun 6, 2018 at 10:22 AM, Eric Sunshine wrote:
> On Wed, Jun 6, 2018 at 1:18 PM, Anthony Sottile wrote:
>> On Wed, Jun 6, 2018 at 10:17 AM, Eric Sunshine
>> wrote:
>>> On Wed, Jun 6, 2018 at 1:15 PM, Eric Sunshine
>>> wrote:
On Mon, Jun 4, 2018 at 4:17 PM, Anthony Sottile wrote:
On Mon, Jun 11, 2018 at 08:09:47PM +0200, Duy Nguyen wrote:
> I'm actually thinking that putting the_hash_algo inside struct
> repository is a mistake. We have code that's supposed to work without
> a repo and it shows this does not really make sense to forcefully use
> a partially-valid repo.
On Mon, Jun 11, 2018 at 04:09:05AM -0400, Eric Sunshine wrote:
> On Mon, Jun 4, 2018 at 7:52 PM, brian m. carlson
> wrote:
> > test_expect_success 'lookup with almost duplicate values' '
> > + # n-1 5s
> > + root=$(test_translate 555 \
> > +
On Mon, Jun 11, 2018 at 03:47:43AM -0400, Eric Sunshine wrote:
> On Mon, Jun 04, 2018 at 11:52:20PM +, brian m. carlson wrote:
> > Add a test function helper, test_translate, that will produce its first
> > argument if the hash in use is SHA-1 and the second if its argument is
> > NewHash.
On Mon, Jun 11, 2018 at 4:27 PM Ævar Arnfjörð Bjarmason
wrote:
> >
> > And no, I'm not a cryptographer. But honestly, length extension
> > attacks were how both md5 and sha1 were broken in practice, so I'm
> > just going "why would we go with a crypto choice that has that known
> > weakness?
On Tue, 12 Jun 2018, Ævar Arnfjörð Bjarmason wrote:
From a performance standpoint, I have to say (once more) that crypto
performance actually mattered a lot less than I originally thought it
would. Yes, there are phases that do care, but they are rare.
One real-world case is rebasing[1]. As
On Thu, Jun 7, 2018 at 12:04 PM Jonathan Tan wrote:
>
> This is a continuation of the object store refactoring effort.
>
> We cannot truly free an object store without ensuring that any generated
> bitmaps are first freed, so here are patches to drastically reduce the
> lifetime of any bitmaps
On Sat, Jun 9, 2018 at 4:26 AM René Scharfe wrote:
>
> Am 17.04.2018 um 23:30 schrieb Stefan Beller:
> > +static void parse_color_fields(const char *s)
> > +{
> > + struct string_list l = STRING_LIST_INIT_DUP;
> > + struct string_list_item *item;
> > + enum { EXPECT_DATE, EXPECT_COLOR
On Mon, Jun 11 2018, Linus Torvalds wrote:
> On Mon, Jun 11, 2018 at 12:29 PM Jonathan Nieder wrote:
>>
>> Yves Orton and Linus Torvalds prefer[5] SHA3 over SHA2 because of how
>> it is constructed.
>
> Yeah, I really think that it's a mistake to switch to something that
> has the same problem
On Sat, Jun 9, 2018 at 4:04 AM Duy Nguyen wrote:
>
> On Tue, Jun 05, 2018 at 05:31:41PM +0200, Duy Nguyen wrote:
> > I do not know how to reproduce this (and didn't bother to look deeply
> > into it after I found it was not a trivial fix) but one of my "git
> > fetch" showed
> >
> > warning:
Ævar Arnfjörð Bjarmason writes:
> ...And this seems to conflict with what Junio's summarized in
> xmqqvaapb3r1@gitster-ct.c.googlers.com. I.e. (if I'm reading it
> correctly) it's not correct to say that we unlink the existing file,
> then replace it, don't we create a new one, and then
Taylor Blau writes:
> Since it's past the date that I said I would re-roll this, I wanted to
> provide a quick update. I am back in the office, and have discovered a
> new wrinkle that `--invert --not -e ...` prints a column offset of 1,
> when it should recover the pattern and display the
On Mon, Jun 11, 2018 at 12:29:42PM -0700, Jonathan Nieder wrote:
> brian m. carlson wrote:
>
> > == Discussion of Candidates
> >
> > I've implemented and tested the following algorithms, all of which are
> > 256-bit (in alphabetical order):
>
> Thanks for this. Where can I read your code?
Jeff King writes:
> On Mon, Jun 11, 2018 at 03:08:42PM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > On Mon, Jun 04, 2018 at 10:57:30PM +0900, Junio C Hamano wrote:
>> >
>> >> * jk/index-pack-maint (2018-06-01) 2 commits
>> >> (merged to 'next' on 2018-06-04 at c553a485e8)
>>
On Mon, Jun 11, 2018 at 03:08:42PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Mon, Jun 04, 2018 at 10:57:30PM +0900, Junio C Hamano wrote:
> >
> >> * jk/index-pack-maint (2018-06-01) 2 commits
> >> (merged to 'next' on 2018-06-04 at c553a485e8)
> >> + index-pack: handle
Jeff King writes:
> On Mon, Jun 04, 2018 at 10:57:30PM +0900, Junio C Hamano wrote:
>
>> * jk/index-pack-maint (2018-06-01) 2 commits
>> (merged to 'next' on 2018-06-04 at c553a485e8)
>> + index-pack: handle --strict checks of non-repo packs
>> + prepare_commit_graft: treat non-repository as
On Mon, Jun 4, 2018 at 10:48 PM Bert Wesarg wrote:
>
> On Wed, Apr 11, 2018 at 12:50 AM, Junio C Hamano wrote:
> > Chris Maes writes:
> >
> >> Is there any hope from here that anyone will pick up this / these
> >> changes? Will anyone else be assigned the main responsible for this
> >> git-gui
In partial_clone_get_default_filter_spec(), the
core_partial_clone_filter_default variable may be NULL; ensure that it
is not NULL before using it.
Signed-off-by: Jonathan Tan
---
This was noticed by someone else at $DAY_JOB when trying to use a
partial clone with no core.partialclonefilter set.
On Fri, Jun 8, 2018 at 10:15 AM Derrick Stolee wrote:
>
> On 6/8/2018 9:18 AM, Robert P. J. Day wrote:
> >for one of my courses, i wanted to write a section about the various
> > techniques for dealing with whitespace issues in git, so i started
What do you mean by white space issues?
That
On Mon, Jun 11 2018, Clemens Buchacher wrote:
> When replacing files with new content during checkout, we do not write
> to them in place. Instead we unlink and recreate the files in order to
> let the system figure out ownership and permissions for the new file,
> taking umask into account.
On Mon, Jun 11, 2018 at 6:58 AM Robert P. J. Day wrote:
>
> Signed-off-by: Robert P. J. Day
The code is
Reviewed-by: Stefan Beller
Is this patch missing three dashes between commit message and the patch itself?
How did you send this patch?
>
> diff --git a/Documentation/diff-options.txt
On Sat, Jun 09 2018, brian m. carlson wrote:
[Expanding the CC list to what we had in the last "what hash" thread[1]
last year].
> == Discussion of Candidates
>
> I've implemented and tested the following algorithms, all of which are
> 256-bit (in alphabetical order):
>
> * BLAKE2b (libb2)
> *
On Mon, Jun 11, 2018 at 11:50:46AM -0700, Jonathan Tan wrote:
> Here's an paragraph to be added to the end of the commit message. I can
> send a reroll with the exact same code but with the updated commit
> message if Junio requests it.
>
> [additional paragraph begin]
>
> This patch raises two
On Mon, Jun 11, 2018 at 10:35:40AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > If you don't even have symbolic-ref handy, you can do:
> >
> > echo "ref: refs/heads/new-branch" >.git/HEAD
> >
> > That's not generally recommended, since future versions of Git may
> > change the ref
Hi Derrick,
On Thu, Jun 7, 2018 at 7:03 AM Derrick Stolee wrote:
>
> This new 'git midx' builtin will be the plumbing access for writing,
> reading, and checking multi-pack-index (MIDX) files. The initial
> implementation is a no-op.
Let's talk about the name for a second:
.idx files are
+Cc: Orgad Shaneh
On Mon, Jun 11, 2018 at 08:35:41PM +, Edward Thomson wrote:
> On Sun, Jun 10, 2018 at 09:44:45PM +0200, Clemens Buchacher wrote:
> >
> > It is safe to do this on Linux file systems, even if open file handles
> > still exist, because unlink only removes the directory
When replacing files with new content during checkout, we do not write
to them in place. Instead we unlink and recreate the files in order to
let the system figure out ownership and permissions for the new file,
taking umask into account.
It is safe to do this on Linux file systems, even if open
On Sun, Jun 10, 2018 at 09:44:45PM +0200, Clemens Buchacher wrote:
>
> It is safe to do this on Linux file systems, even if open file handles
> still exist, because unlink only removes the directory reference to the
> file. On Windows, however, a file cannot be deleted until all handles to
> it
On Mon, Jun 11, 2018 at 11:02:42AM -0700, Junio C Hamano wrote:
>
> Aside from us not having to worry about emulating the umask, another
> reason why we prefer "create, complete the write, and then finally
> rename" over "overwrite and let it fail in the middle" is that the
> former makes sure we
On Mon, Jun 11, 2018 at 12:29 PM Jonathan Nieder wrote:
>
> Yves Orton and Linus Torvalds prefer[5] SHA3 over SHA2 because of how
> it is constructed.
Yeah, I really think that it's a mistake to switch to something that
has the same problem SHA1 had.
That doesn't necessarily mean SHA3, but it
Hi Junio,
On Mon, Jun 11, 2018 at 10:44 AM, Junio C Hamano wrote:
> Elijah Newren writes:
>
>> In short, while interactive-based and merge-based rebases handle
>> directory rename detection fine, am-based rebases do not. This
>> inconsistency may frustrate or surprise users.
>
> FWIW, I
On Wed, May 30, 2018 at 09:12:10AM -0700, Taylor Blau wrote:
> On Wed, May 30, 2018 at 09:09:08AM -0700, Taylor Blau wrote:
> > [...]
> >
> > I have these patches mostly updated on my copy (available at
> > https://github.com/ttaylorr/git/compare/tb/grep-column) but am out of
> > the office for
Hi,
brian m. carlson wrote:
> == Discussion of Candidates
>
> I've implemented and tested the following algorithms, all of which are
> 256-bit (in alphabetical order):
Thanks for this. Where can I read your code?
[...]
> I also rejected some other candidates. I couldn't find any reference or
Hi Derrick,
On Thu, Jun 7, 2018 at 7:03 AM Derrick Stolee wrote:
>
> The multi-pack-index (MIDX) feature generalizes the existing pack-
> index (IDX) feature by indexing objects across multiple pack-files.
>
> Describe the basic file format, using a 12-byte header followed by
> a lookup table for
Hello,
Am 11. Juni 2018 um 20:04:19, Junio C Hamano
(gits...@pobox.com(mailto:gits...@pobox.com)) schrieb:
> Leif Middelschulte writes:
>
> > From: Leif Middelschulte
> >
> > The output shall behave more similar to ordinary file merges' output to
> > provide
> > a more consistent user
On Thu, Jun 7, 2018 at 7:03 AM Derrick Stolee wrote:
>
> Signed-off-by: Derrick Stolee
> ---
> Documentation/technical/midx.txt | 109 +++
> 1 file changed, 109 insertions(+)
> create mode 100644 Documentation/technical/midx.txt
>
> diff --git
Hi,
brian m. carlson wrote:
> Since there's been a lot of questions recently about the state of the
> NewHash work, I thought I'd send out a summary.
Yay!
[...]
> I plan on introducing an array of hash algorithms into struct repository
> (and wrapper macros) which stores, in order, the output
On Sat, 9 Jun 2018 02:04:38 -0400
Jeff King wrote:
> This function used to be idempotent, so any code which wanted to use the
> global bitmap_git could call it "just in case". After your patch, it's
> not. I think it's probably OK, since such functions would generally now
> take a bitmap_git
From: SZEDER Gábor
Subject: completion: correct zsh detection when run from git-completion.zsh
v2.18.0-rc0~90^2 (completion: reduce overhead of clearing cached
--options, 2018-04-18) worked around a bug in bash's "set" builtin on
MacOS by using compgen instead. It was careful to avoid breaking
On Mon, Jun 11, 2018 at 6:05 PM Duy Nguyen wrote:
>
> On Sat, Jun 9, 2018 at 9:58 PM Elijah Newren wrote:
> > I read over the rest. Found a small grammatical error in a commit
> > message. Found multiple places that still need conversion, from
> > pushing up _index usages to callers of
On Sat, Jun 9, 2018 at 10:57 PM brian m. carlson
wrote:
>
> Since there's been a lot of questions recently about the state of the
> NewHash work, I thought I'd send out a summary.
>
> == Status
>
> I have patches to make the entire codebase work, including passing all
> tests, when Git is
Leif Middelschulte writes:
> From: Leif Middelschulte
>
> The output shall behave more similar to ordinary file merges' output to
> provide
> a more consistent user experience.
>
> Signed-off-by: Leif Middelschulte
> ---
> merge-recursive.c | 4 ++--
> 1 file changed, 2 insertions(+), 2
"brian m. carlson" writes:
>> +file prevent creating new files at the same path. Note that Git will not
>> +update read/write permissions according to umask.
>
> I'm wondering if it's worth a mention that running out of disk space (or
> quota) will cause data to be truncated.
Aside from
On Sun, Jun 10 2018, Clemens Buchacher wrote:
> When replacing files with new content during checkout, we do not write
> to them in-place. Instead we unlink and re-create the files in order to
> let the system figure out ownership and permissions for the new file,
> taking umask into account.
>
Jonathan Nieder writes:
> Hi,
>
> SZEDER Gábor wrote:
>
>> Being in RC phase, I'm all for aiming for a minimal solution.
>> However, I don't think that the better fix would be erm.. any "less
>> minimal":
>>
>> diff --git a/contrib/completion/git-completion.bash
>>
On Mon, Jun 11, 2018 at 02:04:11AM +, brian m. carlson wrote:
> On Sun, Jun 10, 2018 at 09:44:45PM +0200, Clemens Buchacher wrote:
> > + file prevent creating new files at the same path. Note that Git will not
> > + update read/write permissions according to umask.
>
> I'm wondering if
Elijah Newren writes:
> In short, while interactive-based and merge-based rebases handle
> directory rename detection fine, am-based rebases do not. This
> inconsistency may frustrate or surprise users.
FWIW, I actually do not quite think it is universally a good idea to
infer that I would
Jeff King writes:
> If you don't even have symbolic-ref handy, you can do:
>
> echo "ref: refs/heads/new-branch" >.git/HEAD
>
> That's not generally recommended, since future versions of Git may
> change the ref storage format, but it would work with any current
> version of Git.
Makes one
From: Leif Middelschulte
The output shall behave more similar to ordinary file merges' output to provide
a more consistent user experience.
Signed-off-by: Leif Middelschulte
---
merge-recursive.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/merge-recursive.c
Junio C Hamano writes:
> Rick van Hattem writes:
>
>> The `git-completion.zsh` unsets the `$ZSH_VERSION` which makes this check
>> moot. The result (at least for me) is that zsh segfaults because of all the
>> variables it's unsetting.
>> ---
>
> Overlong line, lack of sign-off.
>
>> # Clear
On Mon, Jun 11, 2018 at 6:44 PM Elijah Newren wrote:
> > What about merge-recursive.c? Given that this whole thing will take
> > many release cycles to finish, your work may get merged before mine
> > and I could do the conversion now (and resolve conflicts and resubmit
> > later). Of course if
Hi,
My blog post is also up.
https://prertik.github.io/post/week-06
And nice blog post, Alban. :-)
Cheers,
Pratik
On Mon, Jun 11, 2018 at 9:24 AM, Duy Nguyen wrote:
>> I was just about to send you an email to ask if you were continuing on
>> with the series. I need diff-lib.c converted in order to make the
>> changes Junio suggested to index_has_changes at
>>
On Mon, Jun 11, 2018 at 6:11 PM Elijah Newren wrote:
>
> Hi Duy,
>
> On Mon, Jun 11, 2018 at 9:05 AM, Duy Nguyen wrote:
> > On Sat, Jun 9, 2018 at 9:58 PM Elijah Newren wrote:
> >> I read over the rest. Found a small grammatical error in a commit
> >> message. Found multiple places that still
Duy Nguyen writes:
> On Mon, Jun 4, 2018 at 3:53 PM, Junio C Hamano wrote:
>> * "git pull -recurse-submodules --rebase", when the submodule
>
> One dash is missing in --recurse-submodules
Thanks, will fix.
On Tue, Jun 5, 2018 at 12:14 AM, Elijah Newren wrote:
> On Sun, Jun 3, 2018 at 8:19 PM, Junio C Hamano wrote:
>> Elijah Newren writes:
>>
>>> `git merge-recursive` does a three-way merge between user-specified trees
>>> base, head, and remote. Since the user is allowed to specify head, we can
Lars Schneider writes:
>> On 04 Jun 2018, at 06:53, Junio C Hamano wrote:
>>
>> A release candidate Git v2.18.0-rc1 is now available for testing
>> at the usual places. It is comprised of 842 non-merge commits
>> since v2.17.0, contributed by 65 people, 20 of which are new faces.
>>
>> ...
Hi Duy,
On Mon, Jun 11, 2018 at 9:05 AM, Duy Nguyen wrote:
> On Sat, Jun 9, 2018 at 9:58 PM Elijah Newren wrote:
>> I read over the rest. Found a small grammatical error in a commit
>> message. Found multiple places that still need conversion, from
>> pushing up _index usages to callers of
Hi Phillip,
On Mon, Jun 11, 2018 at 8:16 AM, Phillip Wood wrote:
> On 11/06/18 15:42, Elijah Newren wrote:
>> However, we have a bigger problem with empty commits, in that there
>> are really three modes rather than two:
>>* Automatically drop empty commits (default for am-based rebase)
>>
On Sat, Jun 9, 2018 at 9:58 PM Elijah Newren wrote:
> I read over the rest. Found a small grammatical error in a commit
> message. Found multiple places that still need conversion, from
> pushing up _index usages to callers of ll-merge.c and sha1-file.c
> instead of having them in those files,
Hi all!
During a recent rebase operation on one of my repositories a number of commits
unexpectedly ended up getting squashed into other commits. After some
experiments it turned out that the 'reword' instruction seems to squash the
referenced commit into the preceding commit if there's a
On 11/06/18 16:19, Elijah Newren wrote:
Hi Phillip
On Sun, Jun 10, 2018 at 12:40 PM, Phillip Wood
wrote:
Documentation/git-rebase.txt | 15 +--
git-rebase.sh | 17 +
t/t3422-rebase-incompatible-options.sh | 10 +-
Another thing I missed...
On Sun, Jun 10, 2018 at 12:40 PM, Phillip Wood
wrote:
> On 07/06/18 06:06, Elijah Newren wrote:
>> Some exceptions I left out:
>>
>>* --merge and --interactive are technically incompatible since they are
>> supposed to run different underlying scripts, but
Hi Alban, it's great to see you making progress with this.
I don't want to add to your workload but a couple of things that might
be nice to have in the future would be
1) avoid rewriting the todo list and running the editor if
GIT_SEQUENCE_EDITOR is ':', especially when creating the todo
Hi Phillip
On Sun, Jun 10, 2018 at 12:40 PM, Phillip Wood
wrote:
>> Documentation/git-rebase.txt | 15 +--
>> git-rebase.sh | 17 +
>> t/t3422-rebase-incompatible-options.sh | 10 +-
>> 3 files changed, 35
Hi Elijah
On 11/06/18 15:42, Elijah Newren wrote:
Hi Phillip,
On Sun, Jun 10, 2018 at 12:26 PM, Phillip Wood
wrote:
On 07/06/18 06:07, Elijah Newren wrote:
Signed-off-by: Elijah Newren
---
git-rebase.sh | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git
On Sun, Jun 10, 2018 at 3:56 AM, René Scharfe wrote:
> Am 10.11.2017 um 20:05 schrieb Elijah Newren:
>> +static struct dir_rename_entry *check_dir_renamed(const char *path,
>> + struct hashmap *dir_renames)
>> {
>> + char temp[PATH_MAX];
>> +
Hi Phillip,
On Sun, Jun 10, 2018 at 12:26 PM, Phillip Wood
wrote:
> On 07/06/18 06:07, Elijah Newren wrote:
>>
>> Signed-off-by: Elijah Newren
>> ---
>> git-rebase.sh | 6 +-
>> 1 file changed, 1 insertion(+), 5 deletions(-)
>>
>> diff --git a/git-rebase.sh b/git-rebase.sh
>> index
Hi,
I published a new blog post about last week:
https://blog.pa1ch.fr/posts/2018/06/11/en/gsoc2018-week-6.html
Any feedback is welcome! :)
Cheers,
Alban
Signed-off-by: Robert P. J. Day
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index f466600972..30aad8396d 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -64,7 +64,7 @@ ifndef::git-format-patch[]
endif::git-format-patch[]
This patch rewrites the edit-todo functionality from shell to C. This is
part of the effort to rewrite interactive rebase in C.
Alban Gruin (1):
rebase--interactive: rewrite the edit-todo functionality in C
builtin/rebase--helper.c | 13 -
git-rebase--interactive.sh | 11
This rewrites the edit-todo functionality from shell to C.
To achieve that, a new command mode, `edit-todo`, is added, and the
`write-edit-todo` flag is removed, as the shell script does not need to
write the edit todo help message to the todo list anymore.
The shell version is then stripped in
On 6/7/2018 1:13 PM, Eric Sunshine wrote:
On Thu, Jun 7, 2018 at 10:12 AM, wrote:
Test json-writer output using perl script.
Signed-off-by: Jeff Hostetler
---
diff --git a/t/t0019/parse_json.perl b/t/t0019/parse_json.perl
@@ -0,0 +1,52 @@
+#!/usr/bin/perl
+use strict;
+use warnings;
+use
On 6/8/2018 4:07 PM, René Scharfe wrote:
Am 07.06.2018 um 16:12 schrieb g...@jeffhostetler.com:
From: Jeff Hostetler
[...]
+ if (jw->first_stack.buf[jw->first_stack.len - 1] == '1')
+ jw->first_stack.buf[jw->first_stack.len - 1] = '0';
+ else
+
On 6/8/2018 2:05 AM, René Scharfe wrote:
Am 07.06.2018 um 16:12 schrieb g...@jeffhostetler.com:
From: Jeff Hostetler
Add a series of jw_ routines and "struct json_writer" structure to compose
[...]
TEST_PROGRAMS_NEED_X += test-index-version
+TEST_PROGRAMS_NEED_X += test-json-writer>
On 6/8/2018 4:32 PM, René Scharfe wrote:
Am 07.06.2018 um 16:12 schrieb g...@jeffhostetler.com:
Makefile| 2 +
json-writer.c | 419
json-writer.h | 113 +
t/helper/test-json-writer.c | 572
Jeff,
On Mon, Jun 11, 2018 at 01:53:57AM -0400, Jeff King wrote:
> On Mon, Jun 11, 2018 at 01:28:23AM -0400, Eric Sunshine wrote:
>
> > On Mon, Jun 11, 2018 at 12:47 AM, Jeff King wrote:
> > > Subject: fetch-pack: don't try to fetch peeled values with --all
> > > [...]
> > > Original report and
Hi Elijah
On 10/06/18 02:14, Elijah Newren wrote:
>
> Hi Dscho,
>
> On Sat, Jun 9, 2018 at 3:04 PM, Johannes Schindelin
> wrote:
>> On Thu, 7 Jun 2018, Elijah Newren wrote:
>>
>>> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
>>> index 451252c173..28d1658d7a 100644
From: Phillip Wood
recount_edited_hunk() introduced in commit 2b8ea7f3c7 ("add -p:
calculate offset delta for edited patches", 2018-03-05) required all
context lines to start with a space, empty lines are not counted. This
was intended to avoid any recounting problems if the user had
introduced
On Mon, Jun 11, 2018 at 05:18:13AM -0400, Jeff King wrote:
> > >> +sleep 1; # is interrupted by SIGCHLD
> > >> +if (!$exited) {
> > >> +close($out);
> > >> +die "Command did not exit after reading whole body";
> > >> +}
> >
> > > Also, do we need to protect ourselves against
On Tue, Jun 05, 2018 at 01:18:08AM +0300, Max Kirillov wrote:
> > On Sun, Jun 03, 2018 at 12:27:49AM +0300, Max Kirillov wrote:
> > Since this is slightly less efficient, and because it only matters if
> > the web server does not already close the pipe, should this have a
> > run-time
On Sun, Jun 10, 2018 at 06:07:27PM +0300, Max Kirillov wrote:
> On Mon, Jun 04, 2018 at 12:44:09AM -0400, Jeff King wrote:
> > On Sun, Jun 03, 2018 at 12:27:49AM +0300, Max Kirillov wrote:
> >> + env \
> >> + CONTENT_TYPE=application/x-git-upload-pack-request \
> >> +
Early versions of the fsck .gitmodules detection code
actually required a tree to be at the root of a commit for
it to be checked for .gitmodules. What we ended up with in
159e7b080b (fsck: detect gitmodules files, 2018-05-02),
though, finds a .gitmodules file in _any_ tree (see that
commit for
Commit 159e7b080b (fsck: detect gitmodules files,
2018-05-02) taught fsck to look at the content of
.gitmodules files. If the object turns out not to be a blob
at all, we just complain and punt on checking the content.
And since this was such an obvious and trivial code path, I
didn't even bother
On Sat, Jun 09, 2018 at 11:46:13AM +0200, SZEDER Gábor wrote:
> I add few more lines of context here:
>
> tree=$(
> {
> printf "100644 blob $content\t$tricky\n" &&
>
> > printf "12 blob
On Mon, Jun 11, 2018 at 02:14:41AM -0400, Jeff King wrote:
> On Sun, Jun 10, 2018 at 12:00:57AM +, brian m. carlson wrote:
>
> > I also have to look at this issue from the interests of what is best for
> > the FLOSS community and for users as a whole. Adding in functionality
> > that sends
On Mon, Jun 4, 2018 at 7:52 PM, brian m. carlson
wrote:
> Compute test values of the appropriate size instead of hard-coding
> 40-character values. Rename the echo20 function to echoid, since the
> values may be of varying sizes.
>
> Signed-off-by: brian m. carlson
> ---
> diff --git
On Mon, Jun 4, 2018 at 7:52 PM, brian m. carlson
wrote:
> Adjust the test so that it computes variables for object IDs instead of
> using hard-coded hashes.
>
> Signed-off-by: brian m. carlson
> ---
> diff --git a/t/t0002-gitfile.sh b/t/t0002-gitfile.sh
> @@ -89,14 +89,16 @@ test_expect_success
On Mon, Jun 04, 2018 at 11:52:20PM +, brian m. carlson wrote:
> Add a test function helper, test_translate, that will produce its first
> argument if the hash in use is SHA-1 and the second if its argument is
> NewHash. Implement a mode that can read entries from a file as well for
>
On Sun, Jun 10, 2018 at 12:00:57AM +, brian m. carlson wrote:
> I also have to look at this issue from the interests of what is best for
> the FLOSS community and for users as a whole. Adding in functionality
> that sends off usage data from a command-line tool, especially one that
> is as
On Sun, Jun 10, 2018 at 12:44:25AM +0200, Johannes Sixt wrote:
> > I agree with Peff: this is something you as a user need to be aware of,
> > and need to make sure you configure your Git just like you want. As long
> > as this is a purely opt-in feature, it is useful and helpful.
>
> The
94 matches
Mail list logo
