Re: reftable [v4]: new ref storage format

On Tue, Aug 1, 2017 at 6:51 PM, Michael Haggerty wrote: > On Tue, Aug 1, 2017 at 4:27 PM, Shawn Pearce wrote: >> On Mon, Jul 31, 2017 at 11:41 PM, Michael Haggerty >> wrote: >>> On Sun, Jul 30, 2017 at 8:51 PM, Shawn Pearce

Re: reftable [v4]: new ref storage format

On Tue, Aug 1, 2017 at 4:27 PM, Shawn Pearce wrote: > On Mon, Jul 31, 2017 at 11:41 PM, Michael Haggerty > wrote: >> On Sun, Jul 30, 2017 at 8:51 PM, Shawn Pearce wrote: >>> 4th iteration of the reftable storage format. >>> [...]

Re: reftable [v4]: new ref storage format

On Tue, Aug 1, 2017 at 1:23 PM, Shawn Pearce wrote: > On Mon, Jul 31, 2017 at 11:41 PM, Michael Haggerty > wrote: >> On Sun, Jul 30, 2017 at 8:51 PM, Shawn Pearce wrote: >>> 4th iteration of the reftable storage format. >>> [...]

Re: [PATCH v2 0/5] Fsck for lazy objects, and (now) actual invocation of loader

On Tue, 01 Aug 2017 10:11:38 -0700 Junio C Hamano wrote: > Let's step back a bit and think what already happens in the pre- > lazy-object world. We record cut-off commits when a depth limited > clone is created in "shallow". These essentially are promises, > saying something

[GIT PULL] l10n updates for 2.14.0 round 2

Hi Junio, Would you please pull the following git l10n updates. The following changes since commit 91d443d0d8dd942dcfc322ea200edddb9cef2b4e: l10n: git.pot: v2.14.0 round 2 (9 new, 2 removed) (2017-07-24 22:00:44 +0800) are available in the git repository at:

Re: reftable [v4]: new ref storage format

On Tue, Aug 1, 2017 at 4:27 PM, Shawn Pearce wrote: > On Mon, Jul 31, 2017 at 11:41 PM, Michael Haggerty > wrote: >> On Sun, Jul 30, 2017 at 8:51 PM, Shawn Pearce wrote: >>> 4th iteration of the reftable storage format. >>> [...]

Re: reftable [v4]: new ref storage format

On Mon, Jul 31, 2017 at 11:41 PM, Michael Haggerty wrote: > On Sun, Jul 30, 2017 at 8:51 PM, Shawn Pearce wrote: >> 4th iteration of the reftable storage format. >> [...] > > Before we commit to Shawn's reftable proposal, I wanted to explore > what a

Re: [GSoC][PATCH 06/13] submodule: port submodule subcommand 'deinit' from shell to C

On Tue, Aug 1, 2017 at 3:12 AM, Stefan Beller wrote: > On Mon, Jul 31, 2017 at 1:56 PM, Prathamesh Chavan wrote: >> The same mechanism is used even for porting this submodule >> subcommand, as used in the ported subcommands till now. >> The function

Re: [GSoC][PATCH 04/13] submodule: port submodule subcommand 'status' from shell to C

On Tue, Aug 1, 2017 at 2:42 AM, Stefan Beller wrote: > On Mon, Jul 31, 2017 at 1:56 PM, Prathamesh Chavan wrote: >> This aims to make git-submodule 'status' a built-in. Hence, the function >> cmd_status() is ported from shell to C. This is done by

Re: [PATCH 1/2] doc: fix small issues in SubmittingPatches

From: "Stefan Beller" Further, remove duplicated space character. https://en.wikipedia.org/wiki/Sentence_spacing seems like a globally controversial thing. (I assumed it was some sort of local dialect before researching it properly) I personally do not mind one way or

Re: core.autocrlf=true causes `git apply` to fail on patch generated with `git diff-index HEAD --patch`

Here's where I'm hitting the problem described: https://github.com/pre-commit/pre-commit/issues/570 Note that `git -c core.autocrlf=false` apply patch fixes this situation, but breaks others. Here's a testcase where `git -c core.autocrlf=false apply patch` causes a *different* patch failure:

Re: [RFC] Moving main git-subtree development. to GitHub

gree...@obbligato.org (David A. Greene) writes: > Going forward, I would like to do the main feature and bug fix work on > GitHub and periodically subtree-merge to git's main repository under > contrib when the code has stabilized and we are reasonably confident > interfaces are stable. This

Re: [PATCH] hash: Allow building with the external sha1dc library

On Tue, 01 Aug 2017 21:55:45 +0200, Ævar Arnfjörð Bjarmason wrote: > > > On Tue, Aug 01 2017, Takashi Iwai jotted: > > > On Tue, 01 Aug 2017 17:56:00 +0200, > > Junio C Hamano wrote: > >> > >> Takashi Iwai writes: > >> > >> > On Fri, 28 Jul 2017 17:58:14 +0200, > >> > Ævar

Re: core.autocrlf=true causes `git apply` to fail on patch generated with `git diff-index HEAD --patch`

On 08/01/2017 08:24 PM, Anthony Sottile wrote: Here's my minimal reproduction -- it's slightly far-fetched in that it involves*committing crlf* and then using `autocrlf=true` (commit lf, check out crlf). ``` #!/bin/bash set -ex rm -rf foo git init foo cd foo # Commit crlf into repository

Re: [PATCH] convert any hard coded .gitmodules file string to the MACRO

Stefan Beller writes: >>> @@ -233,18 +233,18 @@ void gitmodules_config(void) >>> strbuf_addstr(_path, "/.gitmodules"); >> >> >> Did you mean to also change "/.gitmodules" ?? > > Goog point. We should pick that up as well. However as we do not have > a macro

Re: reftable [v4]: new ref storage format

On Mon, Jul 31, 2017 at 11:41 PM, Michael Haggerty wrote: > On Sun, Jul 30, 2017 at 8:51 PM, Shawn Pearce wrote: >> 4th iteration of the reftable storage format. >> [...] > > Before we commit to Shawn's reftable proposal, I wanted to explore > what a

Re: git-fast-export doesn't support mergetag header

David Turner writes: > It looks to me like git-fast-export doesn't export the mergetag > header on a commit. Is this intentional, or an oversight? Most likely the latter, combined with that probably not many people use the tool with histories with merges in them

Re: [PATCH v2 0/5] Fsck for lazy objects, and (now) actual invocation of loader

Jonathan Nieder writes: > If we are deeply worried about this kind of broken connectivity, there > is another case to care about: the server can "promise" to serve > requests for some object (e.g., the tree pointed to by the server's > "master") and then decide it does not

git-fast-export doesn't support mergetag header

It looks to me like git-fast-export doesn't export the mergetag header on a commit. Is this intentional, or an oversight?

Re: [PATCH] hash: Allow building with the external sha1dc library

On Tue, Aug 01 2017, Takashi Iwai jotted: > On Tue, 01 Aug 2017 17:56:00 +0200, > Junio C Hamano wrote: >> >> Takashi Iwai writes: >> >> > On Fri, 28 Jul 2017 17:58:14 +0200, >> > Ævar Arnfjörð Bjarmason wrote: >> >> ... >> >> * We now have much of the same header code

[ANNOUNCE] Git v2.13.4

The latest maintenance release Git v2.13.4 is now available at the usual places. There is no update that is particulary important or controversial in this release; it is primarily to flush the safer fixes that have already been in the 'master' branch in preparation for the v2.14.0 release down to

Re: [PATCH 3/2] ls-files: only recurse on active submodules

Brandon Williams writes: > On 08/01, Paul Jolly wrote: >> > It looks like it was merged to master. This should be the relevant >> > commit: 188dce131 (ls-files: use repository object, 2017-06-22). >> >> I was just typing a response to my response. Apologies, I was testing >>

Re: [PATCH 10/10] worktree: add "remove" command

On Sat, Jun 25, 2016 at 3:54 AM, Nguyễn Thái Ngọc Duy wrote: > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > diff --git a/builtin/worktree.c b/builtin/worktree.c > @@ -600,6 +601,81 @@ static int move_worktree(int ac, const char **av, const > char *prefix) >

core.autocrlf=true causes `git apply` to fail on patch generated with `git diff-index HEAD --patch`

Here's my minimal reproduction -- it's slightly far-fetched in that it involves *committing crlf* and then using `autocrlf=true` (commit lf, check out crlf). ``` #!/bin/bash set -ex rm -rf foo git init foo cd foo # Commit crlf into repository git config --local core.autocrlf false python3 -c

Re: [PATCH 08/10] worktree: add "move" commmand

On Sat, Jun 25, 2016 at 3:54 AM, Nguyễn Thái Ngọc Duy wrote: > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > diff --git a/builtin/worktree.c b/builtin/worktree.c > +static int move_worktree(int ac, const char **av, const char *prefix) > +{ > + [...] > +

Re: [PATCH 07/10] worktree.c: add update_worktree_location()

On Sat, Jun 25, 2016 at 3:54 AM, Nguyễn Thái Ngọc Duy wrote: > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > diff --git a/worktree.c b/worktree.c > +int update_worktree_location(struct worktree *wt, const char *path_) > +{ > + struct strbuf path =

Re: [PATCH 05/10] copy.c: convert copy_file() to copy_dir_recursively()

Sorry for the (more than a year) late review. I realize that a subsequent version of this patch series renders a few of the review comments meaningless, but I'm including them in case the code is revived later. On Sat, Jun 25, 2016 at 3:54 AM, Nguyễn Thái Ngọc Duy wrote: >

Re: [PATCH 3/2] ls-files: only recurse on active submodules

On 08/01, Paul Jolly wrote: > > It looks like it was merged to master. This should be the relevant > > commit: 188dce131 (ls-files: use repository object, 2017-06-22). > > I was just typing a response to my response. Apologies, I was testing > locally with the wrong compiled version of git. > >

Re: [PATCH 3/2] ls-files: only recurse on active submodules

> It looks like it was merged to master. This should be the relevant > commit: 188dce131 (ls-files: use repository object, 2017-06-22). I was just typing a response to my response. Apologies, I was testing locally with the wrong compiled version of git. Confirmed fixed for me in e2d9c4613 at

Re: [PATCH 3/2] ls-files: only recurse on active submodules

On 08/01, Paul Jolly wrote: > > > > > Thanks for the quick response. > > > > Course, let me know if you find anything else! :D > > > > Brandon - doesn't look like this change has made it's way into master: > > https://github.com/git/git/blob/master/builtin/ls-files.c > > Is there a plan to

Re: [PATCH 3/2] ls-files: only recurse on active submodules

>> Thanks for the quick response. > > Course, let me know if you find anything else! :D Brandon - doesn't look like this change has made it's way into master: https://github.com/git/git/blob/master/builtin/ls-files.c Is there a plan to merge it? Thanks

Re: [RFC] Moving main git-subtree development. to GitHub

Hi, David A. Greene wrote: > Essentially, > I would like to do a "beta" release of the new code while not impacting > existing users of git-subtree in contrib. Sounds like a sensible goal. In-tree, you can do that by saying "please

Re: [PATCH 2/2] doc: add another way to identify if a patch has been merged

On Tue, Aug 1, 2017 at 9:05 AM, Kaartic Sivaraam wrote: > Signed-off-by: Kaartic Sivaraam > --- > Documentation/SubmittingPatches | 4 > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/SubmittingPatches

Re: [PATCH v2 0/5] Fsck for lazy objects, and (now) actual invocation of loader

Hi, Junio C Hamano wrote: > Can we do something similar, i.e. maintain minimum set of cut-off > points and adjust that set incrementally, just sufficient to ensure > the integrity of objects locally created and not yet safely stored > away by pushing them the "other side"? This sounds like a

Re: [PATCH 1/2] doc: fix small issues in SubmittingPatches

On Tue, Aug 1, 2017 at 8:59 AM, Kaartic Sivaraam wrote: > On Mon, 2017-07-31 at 13:23 -0700, Stefan Beller wrote: >> On Sun, Jul 30, 2017 at 9:18 AM, Kaartic Sivaraam >> wrote: >> > Replace the dashed version of a command with

Re: [PATCH] convert any hard coded .gitmodules file string to the MACRO

On Tue, Aug 1, 2017 at 6:14 AM, Jeff Hostetler wrote: > > > On 7/31/2017 7:11 PM, Stefan Beller wrote: >> >> I used these commands: >>$ cat sem.cocci >>@@ >>@@ >>- ".gitmodules" >>+ GITMODULES_FILE >> >>$ spatch --in-place --sp-file sem.cocci

Re: [PATCH v2 0/5] Fsck for lazy objects, and (now) actual invocation of loader

Jonathan Tan writes: > Well, the fsck can still detect issues like corrupt objects (as you > mention above) and dangling heads, which might be real issues. But it is > true that it does not give you the guarantee you describe. Which makes it pretty much useless. The

Re: reftable [v4]: new ref storage format

On Mon, Jul 31, 2017 at 4:43 PM, Shawn Pearce wrote: > On Mon, Jul 31, 2017 at 12:42 PM, Junio C Hamano wrote: >> >> As a block cannot be longer than 16MB, allocating uint32 to a >> restart offset may be a bit overkill. I do not know if it is worth >>

Re: [PATCH] hash: Allow building with the external sha1dc library

On Tue, 01 Aug 2017 17:56:00 +0200, Junio C Hamano wrote: > > Takashi Iwai writes: > > > On Fri, 28 Jul 2017 17:58:14 +0200, > > Ævar Arnfjörð Bjarmason wrote: > >> ... > >> * We now have much of the same header code copy/pasted between > >> sha1dc_git.h and sha1dc_git_ext.h,

[PATCH 2/2] doc: add another way to identify if a patch has been merged

Signed-off-by: Kaartic Sivaraam --- Documentation/SubmittingPatches | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 886fe3650..7197709ee 100644 --- a/Documentation/SubmittingPatches

[PATCH 1/2] doc: fix small issues in SubmittingPatches

Replace the dashed version of a command with undashed version and quote it. Use double quotes to quote a git command for consistency. Signed-off-by: Kaartic Sivaraam --- Documentation/SubmittingPatches | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

Re: [PATCH] hash: Allow building with the external sha1dc library

Takashi Iwai writes: > On Fri, 28 Jul 2017 17:58:14 +0200, > Ævar Arnfjörð Bjarmason wrote: >> ... >> * We now have much of the same header code copy/pasted between >> sha1dc_git.h and sha1dc_git_ext.h, did you consider just always >> including the former but making what it's

Re: [PATCH 1/2] doc: fix small issues in SubmittingPatches

On Mon, 2017-07-31 at 13:23 -0700, Stefan Beller wrote: > On Sun, Jul 30, 2017 at 9:18 AM, Kaartic Sivaraam > wrote: > > Replace the dashed version of a command with undashed > > version and quote it. > > I like it, but similar as below, we'd want to go for >

Re: reftable [v4]: new ref storage format

On Tue, Aug 1, 2017 at 6:54 AM, Dave Borowitz wrote: > On Sun, Jul 30, 2017 at 11:51 PM, Shawn Pearce wrote: >> - Ref-like files (FETCH_HEAD, MERGE_HEAD) also use type 0x3. > >> - Combine reflog storage with ref storage for small transactions. >> -

Re: reftable [v4]: new ref storage format

On Sun, Jul 30, 2017 at 11:51 PM, Shawn Pearce wrote: > - Ref-like files (FETCH_HEAD, MERGE_HEAD) also use type 0x3. > - Combine reflog storage with ref storage for small transactions. > - Separate reflog storage for base refs and historical logs. How is the stash

Re: [PATCH] convert any hard coded .gitmodules file string to the MACRO

On 7/31/2017 7:11 PM, Stefan Beller wrote: I used these commands: $ cat sem.cocci @@ @@ - ".gitmodules" + GITMODULES_FILE $ spatch --in-place --sp-file sem.cocci builtin/*.c *.c *.h Feel free to regenerate or squash it in or have it as a separate commit. Signed-off-by:

[PATCH v4 4/4] interpret-trailers: fix documentation typo

From: Paolo Bonzini Self-explanatory... trailer.ifexists is documented with the right name, but after a while it switches to ifexist. Signed-off-by: Paolo Bonzini --- Documentation/git-interpret-trailers.txt | 4 ++-- 1 file changed, 2 insertions(+),

[PATCH v4 3/4] interpret-trailers: add options for actions

From: Paolo Bonzini Allow using non-default values for trailers without having to set them up in .gitconfig first. For example, if you have the following configuration trailer.signed-off-by.where = end you may use "--where before" when a patch author forgets his

[PATCH v4 1/4] trailers: export action enums and corresponding lookup functions

From: Paolo Bonzini Separate the mechanical changes out of the next patch. The functions are changed to take a pointer to enum, because struct conf_info is not going to be public. Set the default values explicitly in default_conf_info, since they are not anymore close to

[PATCH v4 2/4] trailers: introduce struct new_trailer_item

From: Paolo Bonzini This will provide a place to store the current state of the --where, --if-exists and --if-missing options. Signed-off-by: Paolo Bonzini --- builtin/interpret-trailers.c | 41 + trailer.c

[PATCH v4 0/4] interpret-trailers: add --where, --if-exists, --if-missing

From: Paolo Bonzini These options are useful to experiment with "git interpret-trailers" without having to tinker with .gitconfig (Junio said git should ahve done this first and only added configuration afterwards). It can be useful in the case where you want a different

Re: reftable [v4]: new ref storage format

On Sun, Jul 30, 2017 at 8:51 PM, Shawn Pearce wrote: > 4th iteration of the reftable storage format. > [...] Before we commit to Shawn's reftable proposal, I wanted to explore what a contrasting design that is not block based would look like. So I threw together a sketch of