Signed-off-by: Elijah Newren
---
merge-recursive.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 09c249b93e..5538038178 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -998,10 +998,10 @@ static int
handle_change_delete() has a block of code displaying one of four nearly
identical messages. Each contains about half a dozen variable
interpolations, which use nearly identical variables as well. Someone
trying to parse this may be slowed down trying to parse the differences
and why they are
This patch series contains several small code cleanups for
merge-recursive.
Changes since v2:
* Now built on master (the topics this depended on have graduated);
merges cleanly with next and pu.
* Patch #2 has a few additional argument alignment fixes; some in
code added by topics
We had an enum of rename types which included RENAME_DIR; this name felt
misleading since it was not about an entire directory but was a status for
each individual file add that occurred within a renamed directory.
Since this type is for signifying that the files in question were being
renamed
Signed-off-by: Elijah Newren
---
merge-recursive.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index ac27abbd4c..921f8e2d2d 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -539,7 +539,7 @@ static void
These functions were added because processing of these conflicts needed
to be deferred until process_entry() in order to get D/F conflicts and
such right. The number of these has grown over time, and now include
some whose name is misleading:
* conflict_rename_normal() is for handling normal
Various refactorings throughout the code have left lots of alignment
issues that were driving me crazy; fix them.
Acked-by: Johannes Schindelin
Signed-off-by: Elijah Newren
---
merge-recursive.c | 75 ---
1 file changed, 38 insertions(+), 37
Hi Luis,
Luis Marsano wrote:
> Thanks for looking into this and addressing these issues.
And thank you for digging further. :)
> On Thu, Jun 7, 2018 at 1:20 AM Todd Zullinger wrote:
>> I noticed failures from the contrib/credential/netrc tests
>> while building 2.18.0 release candidates. I
On Sat, Jun 09, 2018 at 11:50:32PM +0100, Philip Oakley wrote:
> I just want to remind folks that Gmane disappeared as a regular list because
> of a legal challenge, the SCO v IBM Unix court case keeps rumbling on, so
> clarifying the legal case for:
> a) holding the 'personal git meta data', and
Hi Dscho,
On Sat, Jun 9, 2018 at 3:11 PM, Johannes Schindelin
wrote:
> On Thu, 7 Jun 2018, Elijah Newren wrote:
>
>> am-based rebases suffer from an reduced ability to detect directory
>> renames upstream, which is fundamental to the fact that it throws away
>> information about the history: in
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
>> --- a/Documentation/git-rebase.txt
>> +++
Sorry to intrude, but I can't send a patch to the maillist using qq.com SMTP
server.
Sorry to intrude, but I can't send a patch to the maillist using
qq.com and 163.com SMTP server.
On Sat, Jun 09, 2018 at 08:56:00AM +0200, Johannes Sixt wrote:
> Am 09.06.2018 um 00:20 schrieb Ævar Arnfjörð Bjarmason:
> >
> > On Fri, Jun 08 2018, Johannes Sixt wrote:
> > Can you elaborate on how someone who can maintain inject malicious code
> > into your git package + config would be
Hi Dscho,
On Sat, Jun 9, 2018 at 2:45 PM, Johannes Schindelin
wrote:
> On Thu, 7 Jun 2018, Elijah Newren wrote:
>
>> While 'quiet' and 'interactive' may sound like antonyms, the interactive
>> machinery actually has logic that implements several
>> interactive_rebase=implied cases (--exec,
From: "Theodore Y. Ts'o"
Sent: Friday, June 08, 2018 3:53 AM
On Fri, Jun 08, 2018 at 01:21:29AM +0200, Peter Backes wrote:
On Thu, Jun 07, 2018 at 03:38:49PM -0700, David Lang wrote:
> > Again: The GDPR certainly allows you to keep a proof of copyright
> > privately if you have it. However, it
== Discussion of Candidates
I've implemented and tested the following algorithms, all of which are
256-bit (in alphabetical order):
* BLAKE2b (libb2)
* BLAKE2bp (libb2)
* KangarooTwelve (imported from the Keccak Code Package)
* SHA-256 (OpenSSL)
* SHA-512/256 (OpenSSL)
* SHA3-256 (OpenSSL)
*
Am 09.06.2018 um 22:43 schrieb Johannes Schindelin:
On Sat, 9 Jun 2018, Johannes Sixt wrote:
When you want usage data, ask your users for feedback. Look over their
shoulders. But do not ask the software itself to gather usage data. It will be
abused.
Do not offer open source software that has
Hi Elijah,
On Thu, 7 Jun 2018, Elijah Newren wrote:
> am-based rebases suffer from an reduced ability to detect directory
> renames upstream, which is fundamental to the fact that it throws away
> information about the history: in particular, it dispenses with the
> original commits involved by
Hi Elijah,
On Thu, 7 Jun 2018, Elijah Newren wrote:
> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
> index 451252c173..28d1658d7a 100644
> --- a/Documentation/git-rebase.txt
> +++ b/Documentation/git-rebase.txt
> @@ -275,6 +275,10 @@ branch on top of the branch.
Hi Elijah,
On Thu, 7 Jun 2018, Elijah Newren wrote:
> While 'quiet' and 'interactive' may sound like antonyms, the interactive
> machinery actually has logic that implements several
> interactive_rebase=implied cases (--exec, --keep-empty, --rebase-merges)
> which won't pop up an editor.
On Sat, Jun 09 2018, 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.
Thanks for all your work on this.
> I know that we have long tried to avoid discussing the specific
> algorithm to use, in
Thanks for looking into this and addressing these issues.
On Thu, Jun 7, 2018 at 1:20 AM Todd Zullinger wrote:
>
> Hi,
>
> I noticed failures from the contrib/credential/netrc tests
> while building 2.18.0 release candidates. I was surprised
> to see the tests being run when called with a
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 converted to use a 256-bit hash algorithm.
Obviously, such a Git is
Hi Hannes,
On Sat, 9 Jun 2018, Johannes Sixt wrote:
> Am 09.06.2018 um 00:20 schrieb Ævar Arnfjörð Bjarmason:
> >
> > On Fri, Jun 08 2018, Johannes Sixt wrote:
> >
> > > Am 08.06.2018 um 18:00 schrieb Thomas Braun:
> > > > I for my part would much rather prefer that to be a compile time
> > >
On Sat, Jun 09 2018, Elijah Newren wrote:
> On Sat, Jun 9, 2018 at 12:01 PM, Christoph Böhmwalder
> wrote:
>> Hi,
>>
>> Since this is a use case that actually comes up quite often in
>> day-to-day use, especially among git beginners, I was wondering: is
>> there a specific reason why a command
On Sat, Jun 09, 2018 at 01:04:30PM -0700, Elijah Newren wrote:
> Upon reading the subject and before reading the body, I assumed you
> were going to ask for a 'git pull --force' that would throw away
> *uncommitted* changes (i.e. do a 'git reset --hard HEAD' before the
> rest of the pull). But
Hi Kyle,
On Sat, Jun 9, 2018 at 8:19 AM, Kyle Meyer wrote:
> Signed-off-by: Kyle Meyer
> ---
> Documentation/gitworkflows.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt
> index 926e044d0..ca11c7bda
Hi Peff,
On Sat, 9 Jun 2018, Jeff King wrote:
> On Sat, Jun 09, 2018 at 08:31:58AM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> > 1) I really don't see the basis for this argument that they'd need to
> >patch it out, they're not patching out e.g. GIT_TRACE now, which has
> >all the same
On Sat, Jun 9, 2018 at 12:01 PM, Christoph Böhmwalder
wrote:
> Hi,
>
> Since this is a use case that actually comes up quite often in
> day-to-day use, especially among git beginners, I was wondering: is
> there a specific reason why a command like "fetch changes from remote,
> overwriting
On Thu, Jun 7, 2018 at 12:44 AM, Elijah Newren wrote:
> On Wed, Jun 6, 2018 at 9:49 AM, Nguyễn Thái Ngọc Duy
> wrote:
>> v4 fixes some commit messages and killed a couple more the_index
>> references after I tried to merge this with 'pu'
>
> Thanks for tackling this. The first 8 patches look
On Sat, Jun 9, 2018 at 11:45 AM, Duy Nguyen wrote:
> On Sat, Jun 9, 2018 at 8:10 PM Elijah Newren wrote:
>>
>> On Wed, Jun 6, 2018 at 10:02 AM, Nguyễn Thái Ngọc Duy
>> wrote:
>> > diff --git a/merge-recursive.c b/merge-recursive.c
>> > index b404ebac7c..4f054d6dbb 100644
>> > ---
Hi,
Since this is a use case that actually comes up quite often in
day-to-day use, especially among git beginners, I was wondering: is
there a specific reason why a command like "fetch changes from remote,
overwriting everything in my current working directory including all
commits I've made"
On Sat, Jun 9, 2018 at 8:10 PM Elijah Newren wrote:
>
> On Wed, Jun 6, 2018 at 10:02 AM, Nguyễn Thái Ngọc Duy
> wrote:
> > diff --git a/merge-recursive.c b/merge-recursive.c
> > index b404ebac7c..4f054d6dbb 100644
> > --- a/merge-recursive.c
> > +++ b/merge-recursive.c
> > @@ -315,7 +315,7 @@
On Thu, Jun 7, 2018 at 4:07 PM Derrick Stolee wrote:
>
> If a 'git repack' command replaces existing packfiles, then we must
> clear the existing multi-pack-index before moving the packfiles it
> references.
I think there are other places where we add or remove pack files and
need to
On Wed, Jun 6, 2018 at 10:02 AM, Nguyễn Thái Ngọc Duy wrote:
> diff --git a/merge-recursive.c b/merge-recursive.c
> index b404ebac7c..4f054d6dbb 100644
> --- a/merge-recursive.c
> +++ b/merge-recursive.c
> @@ -315,7 +315,7 @@ static int add_cacheinfo(struct merge_options *o,
> struct
On Thu, Jun 7, 2018 at 4:07 PM Derrick Stolee wrote:
>
> If the multi-pack-index contains a packfile, then we do not need to add
> that packfile to the packed_git linked list or the MRU list.
Because...?
I think I see the reason, but I'd like it spelled out to avoid any
misunderstanding.
>
>
On Thu, Jun 7, 2018 at 4:06 PM Derrick Stolee wrote:
>
> Signed-off-by: Derrick Stolee
> ---
> packfile.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/packfile.c b/packfile.c
> index 638e113972..059b2aa097 100644
> --- a/packfile.c
> +++ b/packfile.c
> @@ -819,11
On Thu, Jun 7, 2018 at 4:06 PM Derrick Stolee wrote:
> @@ -565,8 +632,11 @@ static void find_abbrev_len_for_pack(struct packed_git
> *p,
>
> static void find_abbrev_len_packed(struct min_abbrev_data *mad)
> {
> + struct midxed_git *m;
> struct packed_git *p;
>
> + for (m =
On Wed, Jun 6, 2018 at 10:02 AM, Nguyễn Thái Ngọc Duy wrote:
> Since attr checking API now take the index, there's no need to set an
> index in advance with this call. Most call sites are straightforward
> because they either pass the_index or NULL (which defaults back to
> the_index previously).
On Thu, Jun 7, 2018 at 6:55 PM Derrick Stolee wrote:
>
> Signed-off-by: Derrick Stolee
> ---
> midx.c | 96 --
> midx.h | 2 ++
> object-store.h | 1 +
> packfile.c | 8 -
> 4 files changed, 104 insertions(+), 3
On Thu, Jun 7, 2018 at 7:02 PM Derrick Stolee wrote:
>
> Signed-off-by: Derrick Stolee
> ---
> midx.c | 22 ++
> midx.h | 2 ++
> object-store.h | 7 +++
> packfile.c | 6 +-
> 4 files changed, 36 insertions(+), 1 deletion(-)
>
> diff --git
On Thu, Jun 7, 2018 at 7:02 PM Derrick Stolee wrote:
> +static size_t write_midx_large_offsets(struct hashfile *f, uint32_t
> nr_large_offset,
> + struct pack_midx_entry *objects,
> uint32_t nr_objects)
> +{
> + struct pack_midx_entry *list = objects;
On Thu, Jun 7, 2018 at 4:06 PM Derrick Stolee wrote:
> @@ -117,9 +123,13 @@ struct midxed_git *load_midxed_git(const char
> *object_dir)
> die("MIDX missing required pack lookup chunk");
> if (!m->chunk_pack_names)
> die("MIDX missing required pack-name
On Thu, Jun 7, 2018 at 4:07 PM Derrick Stolee wrote:
>
> Signed-off-by: Derrick Stolee
> ---
> Documentation/technical/pack-format.txt | 4 ++
> builtin/midx.c | 2 +
> midx.c | 50 +++--
> object-store.h
On Thu, Jun 7, 2018 at 4:06 PM Derrick Stolee wrote:
>
> Before writing a list of objects and their offsets to a multi-pack-index
> (MIDX), we need to collect the list of objects contained in the
> packfiles. There may be multiple copies of some objects, so this list
> must be deduplicated.
Can
On Thu, Jun 7, 2018 at 7:01 PM Derrick Stolee wrote:
>
> Signed-off-by: Derrick Stolee
> ---
> Documentation/technical/pack-format.txt | 5 +++
> builtin/midx.c | 7
> midx.c | 56 +++--
> object-store.h
Derrick Stolee writes:
First, this commit seems to try to do two things at once, and in its
current form it should be split into adding destroy_commit_graph() and
into grafts / replacements check. Those are separate and unconnected
features, and should be in separate patches, in my opinion.
>
On 9 June 2018 at 00:41, Ævar Arnfjörð Bjarmason wrote:
> Instead of trying really hard to find an unambiguous SHA-1 we can with
> core.validateAbbrev=false, and preferably combined with the new
> support for relative core.abbrev values (such as +4) unconditionally
> print a short SHA-1 without
On 9 June 2018 at 00:41, Ævar Arnfjörð Bjarmason wrote:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index ab641bf5a9..abf07be7b6 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -919,6 +919,12 @@ core.abbrev::
> in your repository,
Signed-off-by: Kyle Meyer
---
Documentation/gitworkflows.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt
index 926e044d0..ca11c7bda 100644
--- a/Documentation/gitworkflows.txt
+++
On 9 June 2018 at 16:24, Martin Ågren wrote:
> On 9 June 2018 at 00:41, Ævar Arnfjörð Bjarmason wrote:
>> For no good reason the --abbrev= command-line option was less strict
>> than the core.abbrev config option, which came down to the latter
>> using git_config_int() which rejects an empty
On 9 June 2018 at 00:41, Ævar Arnfjörð Bjarmason wrote:
> For no good reason the --abbrev= command-line option was less strict
> than the core.abbrev config option, which came down to the latter
> using git_config_int() which rejects an empty string, but the rest of
> the parsing using strtoul()
On 9 June 2018 at 11:56, Ævar Arnfjörð Bjarmason wrote:
>
> On Sat, Jun 09 2018, Martin Ågren wrote:
>
>> On 9 June 2018 at 00:41, Ævar Arnfjörð Bjarmason wrote:
>>> The "log" family of commands does its own parsing for --abbrev in
>>> revision.c, so having dedicated tests for it makes sense.
>>
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 } next = EXPECT_COLOR;
> +
> + colorfield_nr = 0;
> +
> +
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: Submodule in commit be2db96a6c506464525f588da59cade0cedddb5e
> at
On Sat, Jun 09 2018, Martin Ågren wrote:
> On 9 June 2018 at 00:41, Ævar Arnfjörð Bjarmason wrote:
>> The "log" family of commands does its own parsing for --abbrev in
>> revision.c, so having dedicated tests for it makes sense.
>
>> +for i in $(test_seq 4 40)
>
> I've just been skimming so
> +test_expect_success 'fsck detects non-blob .gitmodules' '
> + git init non-blob &&
> + (
> + cd non-blob &&
> +
> + # As above, make the funny tree directly to avoid index
> + # restrictions.
> + mkdir subdir &&
> + cp
> As a result, there's no need to create a commit in our
> tests. Let's drop it in the name of simplicity.
>
> Signed-off-by: Jeff King
> ---
> t/t7415-submodule-names.sh | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/t/t7415-submodule-names.sh b/t/t7415-submodule-names.sh
> index
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
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
Here's a v2 which fixes the comment typo and drops the unnecessary
commit creation in the tests. I've added a preparatory patch to do the
same cleanup in the existing test for consistency.
As before, these should apply on 'maint'.
[1/2]: t7415: don't bother creating commit for symlink test
On Sat, Jun 09, 2018 at 10:50:36AM +0200, Martin Ågren wrote:
> On 9 June 2018 at 10:32, Jeff King wrote:
> > Except it _does_ do one non-trivial thing, which is call the
> > report() function, which wants us to pass a pointer to a
> > "struct object". Which we don't have (we have only a "struct
On Sat, Jun 09, 2018 at 10:45:15AM +0200, Duy Nguyen wrote:
> > It seems like we could refactor report() to just take the
> > object_id itself. But we pass the object pointer along to
> > a callback function, and indeed this ends up in
> > builtin/fsck.c's objreport() which does want to look at
>
On Sat, Jun 09, 2018 at 04:38:54AM -0400, Eric Sunshine wrote:
> On Sat, Jun 9, 2018 at 4:32 AM, Jeff King wrote:
> > 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
On 9 June 2018 at 10:32, Jeff King wrote:
> Except it _does_ do one non-trivial thing, which is call the
> report() function, which wants us to pass a pointer to a
> "struct object". Which we don't have (we have only a "struct
> object_id"). So we erroneously passed the NULL object, which
On Sat, Jun 9, 2018 at 10:34 AM Jeff King wrote:
>
> 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
On 9 June 2018 at 00:41, Ævar Arnfjörð Bjarmason wrote:
> The "log" family of commands does its own parsing for --abbrev in
> revision.c, so having dedicated tests for it makes sense.
> +for i in $(test_seq 4 40)
I've just been skimming so might have missed something, but I see
several
On Sat, Jun 9, 2018 at 4:32 AM, Jeff King wrote:
> 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
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 9, 2018 at 8:32 AM Ævar Arnfjörð Bjarmason wrote:
> Let's say you're in a corporate environment with Linux, OSX and Windows
> boxes, but all of whom have some shared mounts provisioned & ability to
> ship an /etc/gitconfig (wherever that lives on Windows).
>
> It's much easier to just
On Sat, Jun 09, 2018 at 09:04:16AM +0200, Johannes Sixt wrote:
> > AFAICT this telemetry data is the same thing, but for performance. When
> > somebody says "why does this command take so long", wouldn't it be nice
> > for us to be able to tell them to flip a switch that will collect data
> > on
Am 09.06.2018 um 08:51 schrieb Jeff King:
I actually think this could be useful for normal users, too. We have
GIT_TRACE for dumping debug output, and we sometimes ask users to turn
it on to help diagnose a problem (not to mention that we use it
ourselves).
The BIG difference is in "we ask the
On Sat, Jun 09, 2018 at 08:31:58AM +0200, Ævar Arnfjörð Bjarmason wrote:
> 1) I really don't see the basis for this argument that they'd need to
>patch it out, they're not patching out e.g. GIT_TRACE now, which has
>all the same sort of concerns, it's just a format that's more of a
>
Am 09.06.2018 um 00:20 schrieb Ævar Arnfjörð Bjarmason:
On Fri, Jun 08 2018, Johannes Sixt wrote:
Am 08.06.2018 um 18:00 schrieb Thomas Braun:
I for my part would much rather prefer that to be a compile time
option so that I don't need to check on every git update on windows
if this is now
On Sat, Jun 09, 2018 at 07:03:53AM +0200, Duy Nguyen wrote:
> > > Am 08.06.2018 um 18:00 schrieb Thomas Braun:
> > >> I for my part would much rather prefer that to be a compile time
> > >> option so that I don't need to check on every git update on windows
> > >> if this is now enabled or not.
On Sat, Jun 09 2018, Duy Nguyen wrote:
> On Sat, Jun 9, 2018 at 12:22 AM Ævar Arnfjörð Bjarmason
> wrote:
>>
>>
>> On Fri, Jun 08 2018, Johannes Sixt wrote:
>>
>> > Am 08.06.2018 um 18:00 schrieb Thomas Braun:
>> >> I for my part would much rather prefer that to be a compile time
>> >> option
On Fri, Jun 08, 2018 at 09:25:29PM +0300, Vitaly Potyarkin wrote:
> # Truncating file names with Unicode characters
>
> When shortening file names that contain Unicode characters, git performs
> truncation without awareness of two-byte characters. That often leads to
> splitting a character in
On Thu, Jun 07, 2018 at 12:04:14PM -0700, Jonathan Tan wrote:
> Add a function to free struct bitmap_index instances, and use it where
> needed (except when rebuild_existing_bitmaps() is used, since it creates
> references to the bitmaps within the struct bitmap_index passed to it).
>
> Note
On Thu, Jun 07, 2018 at 12:04:13PM -0700, Jonathan Tan wrote:
> Remove the bitmap_git global variable. Instead, generate on demand an
> instance of struct bitmap_index for code that needs to access it.
>
> This allows us significant control over the lifetime of instances of
> struct
80 matches
Mail list logo
