Re: [PATCH v3 4/4] commit: rewrite read_graft_line

Ah! I presumed two separate loops, one throwing away oids and second one actually filling a table - this makes more sense. I was just about to send v4, but will rewrite the last patch and we'll see how it looks like. -- | ← Ceci n'est pas une pipe Patryk Obara

Re: Submodule regression in 2.14?

> In the past "submodule..update=none" was an easy way > to selectively disable certain Submodules. > > How would I do this with Git 2.14? submodule..active = false > My gut feeling is that all commands should respect the > "submodule..update=none" setting. Well my gut feeling was that the

Re: Submodule regression in 2.14?

On Fri, Aug 18, 2017 at 9:50 AM, Junio C Hamano wrote: > I am not sure if I follow. Submodules are not trees and one of the > reasons people may want to separate things into different modules is > so that they can treat them differently. If submodules allow you > a richer set

Re: [PATCH v3 4/4] commit: rewrite read_graft_line

Patryk Obara writes: > Ah! I presumed two separate loops, one throwing away oids and second > one actually filling a table - this makes more sense. I was just about > to send v4, but will rewrite the last patch and we'll see how it looks > like. Yeah, it is

Re: [PATCH v4 4/4] commit: rewrite read_graft_line

Actually, I don't think I needed to remove free(graft) line, but I don't know if freeing NULL is considered ok in git code. Let me know if I should bring it back, please. -- | ← Ceci n'est pas une pipe Patryk Obara

Re: [PATCH v4 4/4] commit: rewrite read_graft_line

Patryk Obara writes: > Actually, I don't think I needed to remove free(graft) line, but I don't > know if freeing NULL is considered ok in git code. Let me know if I > should bring it back, please. Calling free(var) when var may or may not be NULL is perfectly fine. We

Re:

Hello, I wish to seek for your assistance in a deal that will be of mutual benefit for the both of us from Camp Stanley in Uijeongbu. Please contact me for details, God bless you.

Re: [PATCH v4 4/4] commit: rewrite read_graft_line

Patryk Obara writes: > Actually, I don't think I needed to remove free(graft) line, but I don't > know if freeing NULL is considered ok in git code. Let me know if I > should bring it back, please. Either free(graft) or assert(!graft) is fine, but we should have one of

[PATCH v4 2/4] commit: replace the raw buffer with strbuf in read_graft_line

This simplifies function declaration and allows for use of strbuf_rtrim instead of modifying buffer directly. Signed-off-by: Patryk Obara --- builtin/blame.c | 2 +- commit.c| 23 +++ commit.h| 2 +- 3 files changed, 13

[PATCH v4 4/4] commit: rewrite read_graft_line

Old implementation determined number of hashes by dividing length of line by length of hash, which works only if all hash representations have same length. New graft line parser works in two phases: 1. In first phase line is scanned to verify correctness and compute number of hashes, then

[PATCH v4 1/4] sha1_file: fix definition of null_sha1

The array is declared in cache.h as: extern const unsigned char null_sha1[GIT_MAX_RAWSZ]; Definition in sha1_file.c must match. Signed-off-by: Patryk Obara --- sha1_file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sha1_file.c b/sha1_file.c

[PATCH v4 3/4] commit: allocate array using object_id size

struct commit_graft aggregates an array of object_id's, which have size >= GIT_MAX_RAWSZ bytes. This change prevents memory allocation error when size of object_id is larger than GIT_SHA1_RAWSZ. Signed-off-by: Patryk Obara --- commit.c | 3 ++- 1 file changed, 2

[PATCH v4 0/4] Modernize read_graft_line implementation

Changes since v3: - Commit replacing raw buffer does not store temporary pointer to strbuf internals any more. - Commit message of patch 4 explains all alternative approaches considered so far. - Patch 4 uses two-phases to parse graft line, without code repetition. I have my reservations

Re: [PATCH v4 4/4] commit: rewrite read_graft_line

Ok, so that's an option - in this instance free is not actually needed because it can be triggered only in phase 0, but it would add a bit of robustness. -- | ← Ceci n'est pas une pipe Patryk Obara

Re: [bug] Git submodule command interprets switch as argument and switch

On Thu, Aug 17, 2017 at 10:16 PM, R0b0t1 wrote: > The issue is as follows: > > R0b0t1@host:~/devel/project$ git submodule add > https://github.com/user/project -f > Cloning into '/home/R0b0t1/devel/project/-f'... > > My .gitignore's first line is *, and then I explicitly allow

Re: [PATCH 2/2] Documentation/git-for-each-ref: clarify peeling of tags for --format

Michael J Gruber writes: > `*` in format strings means peeling of tag objects so that object field > names refer to the object that the tag object points at, instead of the > tag object itself. > > Currently, this is documented using grammar that is clearly inspired by >

Re: [bug] Git submodule command interprets switch as argument and switch

Hi, R0b0t1 wrote: > The issue is as follows: > > R0b0t1@host:~/devel/project$ git submodule add > https://github.com/user/project -f > Cloning into '/home/R0b0t1/devel/project/-f'... Thanks for reporting. Confusingly, I think this is intended behavior. "git help submodule" explains:

Re: [PATCH v3 4/4] commit: rewrite read_graft_line

Patryk Obara writes: > Junio C Hamano wrote: >> >> If I were doing the two-pass thing, I'd probably write a for loop >> that runs exactly twice, where the first iteration parses into a >> single throw-away oid struct only to count, and the second

Re: [PATCH v4 2/3] builtin/branch: stop supporting the use of --set-upstream option

On 18 August 2017 at 18:30, Junio C Hamano wrote: > Kaartic Sivaraam writes: > >> On Friday 18 August 2017 01:25 AM, Junio C Hamano wrote: >>> Martin Ågren writes: >>> On 17 August 2017 at 04:54, Kaartic Sivaraam

Re: [PATCH] add test for bug in git-mv with nested submodules

On Thu, Aug 17, 2017 at 12:05:56PM -0700, Stefan Beller wrote: > On Thu, Aug 17, 2017 at 3:34 AM, Heiko Voigt wrote: > > When using git-mv with a submodule it will detect that and update the > > paths for its configurations (.gitmodules, worktree and gitfile). This > > does not

Re: [PATCH] add test for bug in git-mv with nested submodules

> I just copied the shortcut that they were adding themselfes as submodule > in 'setup submodule'. The whole setup of submodules in this test is like > this. This way we already had a nested submodule structure which I could > just add. > > I agree that this is unrealistic so I can change that in

Re: Submodule regression in 2.14?

Stefan Beller writes: > On Thu, Aug 17, 2017 at 7:13 PM, Junio C Hamano wrote: >> Stefan Beller writes: >> >>> Are you saying this might be a design mistake and >>> the .update ought to be respected by all the other >>> commands? For

Re: Submodule regression in 2.14?

Stefan Beller writes: >> In the past "submodule..update=none" was an easy way >> to selectively disable certain Submodules. >> >> How would I do this with Git 2.14? > > submodule..active = false > >> My gut feeling is that all commands should respect the >>

Re: [bug] Git submodule command interprets switch as argument and switch

On Fri, Aug 18, 2017 at 3:38 PM, Jonathan Nieder wrote: > Hi, > > R0b0t1 wrote: > >> The issue is as follows: >> >> R0b0t1@host:~/devel/project$ git submodule add >> https://github.com/user/project -f >> Cloning into '/home/R0b0t1/devel/project/-f'... > > Thanks for reporting.

Re: Revision resolution for remote-helpers?

Hi, Mike Hommey wrote: > My thought is that a string like :: could be used > wherever a committish is expected. That would call some helper > and request to resolve revision, and the helper would provide a git > commit as a response. I like this idea. > The reason for the :: prefix is that it

[PATCH v3 18/23] pack: move find_pack_entry_one(), is_pack_valid()

Signed-off-by: Jonathan Tan --- cache.h | 8 --- packfile.c | 76 - packfile.h | 9 ++-- sha1_file.c | 73 -- 4 files changed, 82

[PATCH v3 03/23] pack: move pack_report()

Signed-off-by: Jonathan Tan --- cache.h | 2 -- packfile.c | 24 packfile.h | 2 ++ sha1_file.c | 24 4 files changed, 26 insertions(+), 26 deletions(-) diff --git a/cache.h b/cache.h index aa2b4d390..a0497d469

[PATCH v3 11/23] pack: move {,re}prepare_packed_git and approximate_object_count

Signed-off-by: Jonathan Tan --- builtin/gc.c | 1 + bulk-checkin.c | 1 + cache.h| 15 connected.c| 2 +- fetch-pack.c | 1 + http-backend.c | 1 + packfile.c | 217 + packfile.h

[PATCH v3 05/23] pack: move release_pack_memory()

The function unuse_one_window() needs to be temporarily made global. Its scope will be restored to static in a subsequent commit. Signed-off-by: Jonathan Tan --- git-compat-util.h | 2 -- packfile.c| 49 +

[PATCH v3 20/23] pack: move find_pack_entry() and make it global

This function needs to be global as it is used by sha1_file.c and will be used by packfile.c. Signed-off-by: Jonathan Tan --- packfile.c | 53 + packfile.h | 2 ++ sha1_file.c | 53

[PATCH v3 10/23] pack: move install_packed_git()

Signed-off-by: Jonathan Tan --- cache.h | 1 - packfile.c | 11 ++- packfile.h | 2 ++ sha1_file.c | 9 - 4 files changed, 12 insertions(+), 11 deletions(-) diff --git a/cache.h b/cache.h index 3625509f9..c4d8bee52 100644 --- a/cache.h +++

[PATCH v3 12/23] pack: move unpack_object_header_buffer()

Signed-off-by: Jonathan Tan --- cache.h | 1 - packfile.c | 25 + packfile.h | 2 ++ sha1_file.c | 25 - 4 files changed, 27 insertions(+), 26 deletions(-) diff --git a/cache.h b/cache.h index 63765d481..75cc0c497

[PATCH v3 08/23] pack: move unuse_pack()

Signed-off-by: Jonathan Tan --- cache.h | 1 - packfile.c | 9 + packfile.h | 1 + sha1_file.c | 9 - 4 files changed, 10 insertions(+), 10 deletions(-) diff --git a/cache.h b/cache.h index a27018210..0313b0b8d 100644 --- a/cache.h +++ b/cache.h

[PATCH v3 09/23] pack: move add_packed_git()

Signed-off-by: Jonathan Tan --- cache.h | 1 - connected.c | 1 + packfile.c | 53 + packfile.h | 1 + sha1_file.c | 61 - 5 files changed, 55

[PATCH v3 04/23] pack: move open_pack_index(), parse_pack_index()

alloc_packed_git() in packfile.c is duplicated from sha1_file.c. In a subsequent commit, alloc_packed_git() will be removed from sha1_file.c. Signed-off-by: Jonathan Tan --- builtin/count-objects.c | 1 + builtin/fsck.c | 1 + builtin/pack-objects.c | 1

Re: [PATCH v2 00/25] Move exported packfile funcs to its own file

On Fri, 11 Aug 2017 15:41:28 -0400 Ben Peart wrote: > Nice to see the pack file functions being refactored out. I looked at > the end result and it looked good to me. Thanks. > Do you have the energy to do a similar refactoring for the remaining > public functions

What's cooking in git.git (Aug 2017, #04; Fri, 18)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. The top part of the draft release

[PATCH v3 01/23] pack: move pack name-related functions

Currently, sha1_file.c and cache.h contain many functions, both related to and unrelated to packfiles. This makes both files very large and causes an unclear separation of concerns. Create a new file, packfile.c, to hold all packfile-related functions currently in sha1_file.c. It has a

[PATCH v3 00/23] Move exported packfile funcs to its own file

> You'd need to double check, but I think the topics that cause > trouble are rs/find-apck-entry-bisection and jk/drop-sha1-entry-pos; > you can start from v2.14.1 and merge these topics on top and then > build your change on top. That would allow you to start cooking > before both of them

Git makes a merge commit but as a normal (non-merge) commit

While merging if I do certain actions then the merge commit is made with the merge message but as a normal (non-merge) commit. Repro steps: - Set GIT_MERGE_AUTOEDIT=yes (set other than "no") in .bashrc - Make a merge commit with no conflicts. (external text editor shows the generated merge

[PATCH] pull: respect submodule update configuration

From: Lars Schneider Do not override the submodule configuration in the call to update the submodules, but give a weaker default. Reported-by: Lars Schneider Signed-off-by: Stefan Beller --- Personally I dislike this

Re: Revision resolution for remote-helpers?

Mike Hommey wrote[1]: > On Fri, Aug 18, 2017 at 03:06:37PM -0700, Jonathan Nieder wrote: >> Mike Hommey wrote: >>> The reason for the :: prefix is that it matches the :: >>> prefix used for remote helpers. >>> >>> Now, there are a few caveats: [...] >>> - msys likes to completely fuck up command

Re: [PATCH] pull: respect submodule update configuration

On Fri, Aug 18, 2017 at 3:04 PM, Stefan Beller wrote: > From: Lars Schneider eh, that is what I get for amending to Lars patch.

[PATCH v3 14/23] pack: move unpack_object_header()

Signed-off-by: Jonathan Tan --- cache.h | 1 - packfile.c | 26 ++ packfile.h | 1 + sha1_file.c | 26 -- 4 files changed, 27 insertions(+), 27 deletions(-) diff --git a/cache.h b/cache.h index

[PATCH v3 15/23] pack: move clear_delta_base_cache(), packed_object_info(), unpack_entry()

Both sha1_file.c and packfile.c now need read_object(), so a copy of read_object() was created in packfile.c. This patch makes both mark_bad_packed_object() and has_packed_and_bad() global. Unlike most of the other patches in this series, these 2 functions need to remain global. Signed-off-by:

[PATCH v3 19/23] pack: move find_sha1_pack()

Signed-off-by: Jonathan Tan --- cache.h | 3 --- http-push.c | 1 + http-walker.c | 1 + packfile.c| 13 + packfile.h| 3 +++ sha1_file.c | 13 - 6 files changed, 18 insertions(+), 16 deletions(-) diff --git a/cache.h

[PATCH v3 07/23] pack: move use_pack()

The function open_packed_git() needs to be temporarily made global. Its scope will be restored to static in a subsequent commit. Signed-off-by: Jonathan Tan --- cache.h | 1 - packfile.c | 303 ++--

[PATCH v3 02/23] pack: move static state variables

sha1_file.c declares some static variables that store packfile-related state. Move them to packfile.c. They are temporarily made global, but subsequent commits will restore their scope back to static. Signed-off-by: Jonathan Tan --- packfile.c | 14 ++

[PATCH v3 06/23] pack: move pack-closing functions

The function close_pack_fd() needs to be temporarily made global. Its scope will be restored to static in a subsequent commit. Signed-off-by: Jonathan Tan --- builtin/am.c | 1 + builtin/clone.c| 1 + builtin/fetch.c| 1 + builtin/merge.c

[PATCH v3 22/23] pack: move has_pack_index()

Signed-off-by: Jonathan Tan --- cache.h | 2 -- packfile.c | 8 packfile.h | 2 ++ sha1_file.c | 8 4 files changed, 10 insertions(+), 10 deletions(-) diff --git a/cache.h b/cache.h index 286891df4..dcbe37a3f 100644 --- a/cache.h +++ b/cache.h

[PATCH v3 21/23] pack: move has_sha1_pack()

Signed-off-by: Jonathan Tan --- builtin/prune-packed.c | 1 + cache.h| 2 -- diff.c | 1 + packfile.c | 6 ++ packfile.h | 2 ++ revision.c | 1 + sha1_file.c| 6 -- 7 files changed,

[PATCH v3 17/23] pack: move check_pack_index_ptr(), nth_packed_object_offset()

Signed-off-by: Jonathan Tan --- cache.h | 16 packfile.c | 33 + packfile.h | 16 sha1_file.c | 33 - 4 files changed, 49 insertions(+), 49 deletions(-) diff --git

[PATCH v3 13/23] pack: move get_size_from_delta()

Signed-off-by: Jonathan Tan --- cache.h | 1 - packfile.c | 40 packfile.h | 1 + sha1_file.c | 39 --- 4 files changed, 41 insertions(+), 40 deletions(-) diff --git a/cache.h

[PATCH v3 16/23] pack: move nth_packed_object_{sha1,oid}

Signed-off-by: Jonathan Tan --- cache.h | 14 -- packfile.c | 31 +++ packfile.h | 16 +++- sha1_file.c | 31 --- 4 files changed, 46 insertions(+), 46 deletions(-) diff --git

[PATCH v3 23/23] pack: move for_each_packed_object()

Signed-off-by: Jonathan Tan --- builtin/cat-file.c | 1 + cache.h| 7 +-- packfile.c | 40 packfile.h | 11 +++ reachable.c| 1 + sha1_file.c| 40

Re: [RFC PATCH] Updated "imported object" design

On Fri, 18 Aug 2017 10:18:37 -0400 Ben Peart wrote: > > But if there was a good way to refer to the "anti-projection" in a > > virtualized system (that is, the "real" thing or "object" behind the > > "virtual" thing or "image"), then maybe the "virtualized" language is > >

Re: Bug?: git archive exclude pathspec and gitattributes export-ignore

Am 14.08.2017 um 18:43 schrieb René Scharfe: > The real solution is probably to teach tree-walk.c::do_match() how to > handle attributes and then inject ":(attr:-export-ignore)" as a default > internal pathspec in archive.c::parse_pathspec_arg() instead of handling > it in

[PATCH 4/4] archive: queue directories for all types of pathspecs

When read_tree_recursive() encounters a directory excluded by a pathspec then it enters it anyway because it might contain included entries. It calls the callback function before it is able to decide if the directory is actually needed. For that reason git archive adds directories to a queue and

[PATCH 2/4] archive: factor out helper functions for handling attributes

Add helpers for accessing attributes that encapsulate the details of how to retrieve their values. Signed-off-by: Rene Scharfe --- archive.c | 31 +++ 1 file changed, 23 insertions(+), 8 deletions(-) diff --git a/archive.c b/archive.c index

[PATCH 3/4] archive: don't queue excluded directories

Reject directories with the attribute export-ignore already while queuing them. This prevents read_tree_recursive() from descending into them and this avoids write_archive_entry() rejecting them later on, which queue_or_write_archive_entry() is not prepared for. Borrow the existing strbuf to

[PATCH 1/4] t5001: add tests for export-ignore attributes and exclude pathspecs

Demonstrate mishandling of the attribute export-ignore by git archive when used together with pathspecs. Wildcard pathspecs can even cause it to abort. And a directory excluded without a wildcard is still included as an empty folder in the archive. Test-case-by: David Adam

Re: [PATCH v3 2/4] commit: replace the raw buffer with strbuf in read_graft_line

On Fri, Aug 18, 2017 at 03:59:36AM +0200, Patryk Obara wrote: > diff --git a/commit.c b/commit.c > index 8b28415..019e733 100644 > --- a/commit.c > +++ b/commit.c > @@ -134,17 +134,18 @@ int register_commit_graft(struct commit_graft *graft, > int ignore_dups) > return 0; > } > > -struct

Dear Talented

Dear Talented, I am Talent Scout For BLUE SKY FILM STUDIO, Present Blue sky Studio a Film Corporation Located in the United State, is Soliciting for the Right to use Your Photo/Face and Personality as One of the Semi -Major Role/ Character in our Upcoming ANIMATED Stereoscope 3D Movie-The Story

Re: [PATCH] check-ref-format: require a repository for --branch

On Thu, Aug 17, 2017 at 02:30:53PM -0700, Junio C Hamano wrote: > > I'm not sure I buy that. What does "turning it into a branch name" even > > mean when you are not in a repository? Clearly @{-1} must fail. And > > everything else is just going to output the exact input you provided. > > This

Re: Revision resolution for remote-helpers?

On Fri, Aug 18, 2017 at 08:15:09AM -0400, Jeff King wrote: > On Fri, Aug 18, 2017 at 03:42:08PM +0900, Mike Hommey wrote: > > > I was thinking it could be useful to have a special syntax for revisions > > that would query a helper program. The helper program could use a > > similar protocol to

Re: Revision resolution for remote-helpers?

On Fri, Aug 18, 2017 at 03:06:37PM -0700, Jonathan Nieder wrote: > Hi, > > Mike Hommey wrote: > > > My thought is that a string like :: could be used > > wherever a committish is expected. That would call some helper > > and request to resolve revision, and the helper would provide a git > >

Re: ignoring extra bitmap file?

On Thu, Aug 17, 2017 at 09:24:36PM +0200, Andreas Krey wrote: > I'm seeing the message > >remote: warning: ignoring extra bitmap file: > ./objects/pack/pack-2943dc24pack > > and indeed, there is such a thing (two, actually): Only one is the extra. :) The other is doing something

Re: [PATCH v3 4/4] commit: rewrite read_graft_line

Jeff King writes: > So we're probably fine. The two parsing passes are right next to each > other and are sufficiently simple and strict that we don't have to > worry about them diverging. If I were doing the two-pass thing, I'd probably write a for loop that runs exactly twice,

Revision resolution for remote-helpers?

Hi, As you might remember, I'm maintaining a remote helper that allows to talk directly to mercurial servers with git: git-cinnabar. When dealing with "foreign (non-git) repositories", it is often necessary to refer to revisions with their native name. With mercurial, that's a sha1, with svn

Re: Weirdness with git change detection

Jeff King venit, vidit, dixit 11.07.2017 10:24: > On Tue, Jul 11, 2017 at 10:20:43AM +0200, Torsten Bögershausen wrote: > >>> No problem. I actually think it would be interesting if Git could >>> somehow detect and warn about this situation. But the obvious way to do >>> that would be to re-run

Re: [PATCH v3 4/4] commit: rewrite read_graft_line

On Fri, Aug 18, 2017 at 03:59:38AM +0200, Patryk Obara wrote: > Determine the number of object_id's to parse in a single graft line by > counting separators (whitespace characters) instead of dividing by > length of hash representation. > > This way graft parsing code can support different sizes

Re: [Patch size_t V3 00/19] use size_t

On Thu, Aug 17, 2017 at 10:35:54PM +0200, Torsten Bögershausen wrote: > On Wed, Aug 16, 2017 at 10:16:12PM +0200, Martin Koegler wrote: > > From: Martin Koegler > > > > This patchset is for next [24db08a6e8fed761d3bace7f2d5997806e20b9f7]. > > I applied it succesfully,

Re: [PATCH] check-ref-format: require a repository for --branch

Jeff King writes: > I _do_ think it's a misfeature to put it in check-ref-format. It should > be part of rev-parse. Which admittedly is a kitchen sink, but this kind > of resolving is one of the main things it should be doing. And in fact > you can already do: > > git rev-parse

Re: reftable [v6]: new ref storage format

On Wed, Aug 16, 2017 at 12:47 AM, Shawn Pearce wrote: > On Mon, Aug 14, 2017 at 5:13 AM, Michael Haggerty > wrote: >> On 08/07/2017 03:47 AM, Shawn Pearce wrote: >>> 6th iteration of the reftable storage format. > [...] >>> index record >>> >>> An

Re: [PATCH v3 2/4] commit: replace the raw buffer with strbuf in read_graft_line

Jeff King wrote: > AFAICT this is only here to avoid having to s/buf/line->buf/ in the rest > of the function. But I think we should just make that change (you > already did in some of the spots). And IMHO we should do the same for > line->len. When there are two names for the

Re: [PATCH v3 4/4] commit: rewrite read_graft_line

Jeff King wrote: > > So we're probably fine. The two parsing passes are right next to each > other and are sufficiently simple and strict that we don't have to > worry about them diverging. That was my conclusion as well. I added comment before the first pass and avoided any

Re: [RFC PATCH] Updated "imported object" design

On 8/17/2017 5:39 PM, Jonathan Tan wrote: Thanks for your comments. I'll reply to both your e-mails in this one e-mail. This illustrates another place we need to resolve the naming/vocabulary. We should at least be consistent to make it easier to discuss/explain. We obviously went with

[PATCH 2/2] Documentation/git-for-each-ref: clarify peeling of tags for --format

`*` in format strings means peeling of tag objects so that object field names refer to the object that the tag object points at, instead of the tag object itself. Currently, this is documented using grammar that is clearly inspired by classical latin, though missing more than an article in order

[PATCH 1/2] Documentation: use proper wording for ref format strings

Various commands list refs and allow to use a format string for the output that interpolates from the ref as well as the object it points at (for-each-ref; branch and tag in list mode). Currently, the documentation talks about interpolating from the object. This is confusing because a ref points

Re: Revision resolution for remote-helpers?

On Fri, Aug 18, 2017 at 03:42:08PM +0900, Mike Hommey wrote: > I was thinking it could be useful to have a special syntax for revisions > that would query a helper program. The helper program could use a > similar protocol to that of the remote helpers. That sounds like a reasonable thing to

Re: Weirdness with git change detection

On Fri, Aug 18, 2017 at 08:56:03AM +0200, Michael J Gruber wrote: > > The idea being that users could run "git lint" if they suspect something > > funny is going on. I dunno. It may be a dead-end. Most such > > oddities are better detected and handled during actual git operations if > > we can.

Re: [PATCH v3 4/4] commit: rewrite read_graft_line

On Fri, Aug 18, 2017 at 01:30:23PM +0200, Patryk Obara wrote: > > We'd reject such an input totally (though as an interesting side effect, > > you can convince the parser to allocate 20x as much RAM as you send it; > > one oid for each space). > > Grafts are not populated during clone operation,

Re: [PATCH v3 2/4] commit: replace the raw buffer with strbuf in read_graft_line

On Fri, Aug 18, 2017 at 12:12:37PM +0200, Patryk Obara wrote: > Jeff King wrote: > > > AFAICT this is only here to avoid having to s/buf/line->buf/ in the rest > > of the function. But I think we should just make that change (you > > already did in some of the spots). And IMHO we

Re: Submodule regression in 2.14?

> On 17 Aug 2017, at 23:55, Stefan Beller wrote: > > On Thu, Aug 17, 2017 at 2:21 PM, Lars Schneider > wrote: >> >>> Oh, wait. >>> $ git log --oneline v2.13.0..v2.14.1 -- builtin/pull.c >>> c9c63ee558 Merge branch 'sb/pull-rebase-submodule' >>>

Re: [RFC PATCH 2/2] submodule: simplify decision tree whether to or not to fetch

On Thu, Aug 17, 2017 at 10:50:07AM -0700, Brandon Williams wrote: > On 08/17, Stefan Beller wrote: > > On Thu, Aug 17, 2017 at 4:00 AM, Heiko Voigt wrote: > > > To make extending this logic later easier. > > > > > > Signed-off-by: Heiko Voigt > > > --- > > >

Re: [PATCH v4 2/3] builtin/branch: stop supporting the use of --set-upstream option

Kaartic Sivaraam writes: > On Friday 18 August 2017 01:25 AM, Junio C Hamano wrote: >> Martin Ågren writes: >> >>> On 17 August 2017 at 04:54, Kaartic Sivaraam >>> wrote: Helped-by: Martin Ågren

Re: [PATCH v4 2/3] builtin/branch: stop supporting the use of --set-upstream option

Kaartic Sivaraam writes: > On Monday 14 August 2017 02:20 PM, Kaartic Sivaraam wrote: >> >> On Wednesday 09 August 2017 12:03 AM, Martin Ågren wrote: >>> >>> Maybe the final note could be removed? Someone who is looking up >>> --set-upstream because Git just

Re: [RFC PATCH 1/2] implement fetching of moved submodules

On Thu, Aug 17, 2017 at 10:20:13AM -0700, Stefan Beller wrote: > On Thu, Aug 17, 2017 at 3:53 AM, Heiko Voigt wrote: > > We store the changed submodules paths to calculate which submodule needs > > fetching. This does not work for moved submodules since their paths do > > not