[PATCH 00/11] Add 'git multi-pack-index verify' command

The multi-pack-index file provides faster lookups in repos with many packfiles by duplicating the information from multiple pack-indexes into a single file. This series allows us to verify a multi-pack-index using 'git multi-pack-index verify' and 'git fsck' (when core.multiPackIndex is true).

[PATCH 00/11] fetch: make sure submodule oids are fetched

This is a resend of [1] and was rebased to origin/master and all review comments have been addressed. Thanks, Stefan [1] https://public-inbox.org/git/20180808221752.195419-1-sbel...@google.com/ Stefan Beller (11): string_list: print_string_list to use trace_printf string-list.h: add

[GSoC] [PATCH 00/11] A minimal builtin rebase

This patch series provides the bare minimum to run more than the trivial rebase (i.e. `git rebase `). Here, I have implemented essential options needed to make this a builtin rebase. Ofcourse, to accomplish the task of builtin rebase, I had to do essential optimizations and add certain shield

Re: [PATCH 00/11]

On Wed, May 16, 2018 at 03:21:07PM -0700, Stefan Beller wrote: > > If you have time, yes translate them all. I don't see how any of these > > strings are meant for script. If not, just _() the new string you > > added is fine. > > > With a majority of call sites dying like this though, I wonder

[PATCH 00/11]

> If you have time, yes translate them all. I don't see how any of these > strings are meant for script. If not, just _() the new string you > added is fine. > With a majority of call sites dying like this though, I wonder if we > should just add repo_read_index_or_die() with die() inside. Then

[PATCH 00/11] completion: path completion improvements: speedup and quoted paths

So, the highlights of this patch series are: - At the top of the worktree in linux.git with over 62k files the time needed for 'git rm ' goes down from 2.15s to 0.052s. - Same place, uniquely completing Makefile with 'git rm Mak' goes down from 2.16s to 0.033s. - Completing paths

Re: [PATCH 00/11] Make the test suite pass with '-x' and /bin/sh

On Sat, Mar 3, 2018 at 8:12 AM, Jeff King wrote: > On Sat, Feb 24, 2018 at 12:39:40AM +0100, SZEDER Gábor wrote: > >> The first patch is the most important: with a couple of well-placed file >> descriptor redirections it ensures that the stderr of the test helper >> functions

Re: [PATCH 00/11] Make the test suite pass with '-x' and /bin/sh

On Sat, Feb 24, 2018 at 12:39:40AM +0100, SZEDER Gábor wrote: > The first patch is the most important: with a couple of well-placed file > descriptor redirections it ensures that the stderr of the test helper > functions running git commands only contain the stderr of the tested > command,

Re: [PATCH 00/11] Moving global state into the repository object (part 2)

On Thu, Mar 1, 2018 at 2:09 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> On Wed, Feb 28, 2018 at 9:59 AM, Junio C Hamano wrote: >>> Duy Nguyen writes: >>> Looking at the full-series diff though, it

Re: [PATCH 00/11] Make the test suite pass with '-x' and /bin/sh

On Sat, Feb 24, 2018 at 12:39 AM, SZEDER Gábor wrote: > This patch series makes '-x' tracing of tests work reliably even when > running them with /bin/sh, and setting TEST_SHELL_PATH=bash will be > unnecessary. > > make GIT_TEST_OPTS='-x --verbose-log' test > > passes on

Re: [PATCH 00/11] Reduce pack-objects memory footprint

On Fri, Mar 02, 2018 at 07:14:01AM +0700, Duy Nguyen wrote: > > We have a big repo, and this gets repacked on 6-8GB of memory on dev > > KVMs, so we're under a fair bit of memory pressure. git-gc slows things > > down a lot. > > > > It would be really nice to have something that made it use

Re: [PATCH 00/11] Reduce pack-objects memory footprint

On Thu, Mar 1, 2018 at 8:33 PM, Ævar Arnfjörð Bjarmason wrote: > > On Thu, Mar 01 2018, Nguyễn Thái Ngọc Duy jotted: > >> The array of object_entry in pack-objects can take a lot of memory >> when pack-objects is run in "pack everything" mode. On linux-2.6.git, >> this array

Re: [PATCH 00/11] Reduce pack-objects memory footprint

On Thu, Mar 01 2018, Nguyễn Thái Ngọc Duy jotted: > The array of object_entry in pack-objects can take a lot of memory > when pack-objects is run in "pack everything" mode. On linux-2.6.git, > this array alone takes roughly 800MB. > > This series reorders some fields and reduces field size... to

[PATCH 00/11] Reduce pack-objects memory footprint

The array of object_entry in pack-objects can take a lot of memory when pack-objects is run in "pack everything" mode. On linux-2.6.git, this array alone takes roughly 800MB. This series reorders some fields and reduces field size... to keep this struct smaller. Its size goes from 136 bytes to 96

Re: [PATCH 00/11] Moving global state into the repository object (part 2)

Hi, Stefan Beller wrote: > On Wed, Feb 28, 2018 at 9:57 AM, Junio C Hamano wrote: >> Wait a minute. Is that topic ever shown to work well together with >> other topics in flight and are now ready to be built upon? I had an >> impression that it is just starting to get

Re: [PATCH 00/11] Moving global state into the repository object (part 2)

Stefan Beller writes: > On Wed, Feb 28, 2018 at 9:59 AM, Junio C Hamano wrote: >> Duy Nguyen writes: >> >>> Looking at the full-series diff though, it makes me wonder if we >>> should keep prepare_packed_git() private (i.e. how we

Re: [PATCH 00/11] Moving global state into the repository object (part 2)

On Wed, Feb 28, 2018 at 11:02 AM, Junio C Hamano wrote: > OK, so I finally picked up the last round, which wasn't even in my > private build. I had the previous round but hadn't convinced myself > that my conflict resolution with other topics in flight that were > still mushy

Re: [PATCH 00/11] Moving global state into the repository object (part 2)

Junio C Hamano writes: > Stefan Beller writes: > >> This applies on top of origin/sb/object-store and is the continuation of >> that series, adding the repository as a context argument to functions. > > Wait a minute. Is that topic ever shown to work well

Re: [PATCH 00/11] Moving global state into the repository object (part 2)

On Wed, Feb 28, 2018 at 9:59 AM, Junio C Hamano wrote: > Duy Nguyen writes: > >> Looking at the full-series diff though, it makes me wonder if we >> should keep prepare_packed_git() private (i.e. how we initialize the >> object store, packfile included, is a

Re: [PATCH 00/11] Moving global state into the repository object (part 2)

On Wed, Feb 28, 2018 at 9:57 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> This applies on top of origin/sb/object-store and is the continuation of >> that series, adding the repository as a context argument to functions. > > Wait a minute. Is

Re: [PATCH 00/11] Moving global state into the repository object (part 2)

Duy Nguyen writes: > Looking at the full-series diff though, it makes me wonder if we > should keep prepare_packed_git() private (i.e. how we initialize the > object store, packfile included, is a private matter). How about > something like this on top? Yup, that looks

Re: [PATCH 00/11] Moving global state into the repository object (part 2)

Stefan Beller writes: > This applies on top of origin/sb/object-store and is the continuation of > that series, adding the repository as a context argument to functions. Wait a minute. Is that topic ever shown to work well together with other topics in flight and are now

Re: [PATCH 00/11] Moving global state into the repository object (part 2)

On 2/27/2018 9:15 PM, Duy Nguyen wrote: On Tue, Feb 27, 2018 at 05:05:57PM -0800, Stefan Beller wrote: This applies on top of origin/sb/object-store and is the continuation of that series, adding the repository as a context argument to functions. This series focusses on packfile handling,

Re: [PATCH 00/11] Moving global state into the repository object (part 2)

On Tue, Feb 27, 2018 at 05:05:57PM -0800, Stefan Beller wrote: > This applies on top of origin/sb/object-store and is the continuation of > that series, adding the repository as a context argument to functions. > > This series focusses on packfile handling, exposing (re)prepare_packed_git > and

[PATCH 00/11] Moving global state into the repository object (part 2)

This applies on top of origin/sb/object-store and is the continuation of that series, adding the repository as a context argument to functions. This series focusses on packfile handling, exposing (re)prepare_packed_git and find_pack_entry to a repository argument. Looking at the diffstat of

[PATCH 00/11] Make the test suite pass with '-x' and /bin/sh

This patch series makes '-x' tracing of tests work reliably even when running them with /bin/sh, and setting TEST_SHELL_PATH=bash will be unnecessary. make GIT_TEST_OPTS='-x --verbose-log' test passes on my setup and on all Travis CI build jobs (though neither me nor Travis CI run all tests,

Re: [PATCH 00/11] Some fixes and bunch of object_id conversions

On 20 January 2018 at 21:58, brian m. carlson wrote: > When I've made changes to the sha1_file functions, I've traditionally > moved them away from using "sha1_file" to "object_file" to ensure that > we make it a bit more obvious that they handle object_id structs

Re: [PATCH 00/11] Some fixes and bunch of object_id conversions

On Thu, Jan 18, 2018 at 03:50:52PM +0100, Patryk Obara wrote: > * brian m. carlson implemented vtable for hash algorithm selection and pushed > the repository format front - thanks to him it's now quite easy to > experimentally replace hashing functions and, e.g. do some performance > testing.

[PATCH 00/11] document & test fetch pruning + WIP fetch.pruneTags

Michael Giuffrida noted that the git-remote docs were very confusing, and upthread I said I wanted this shiny related thing in 11/11. Along the way I fixed up fetch tests & documentation to hopefully be a lot less confusing. I think 1-10/11 of this makes sense for inclusion as-is (pending review

Re: [PATCH 00/11] Some fixes and bunch of object_id conversions

On Thu, 18 Jan 2018 15:50:52 +0100 Patryk Obara wrote: > Patch 1 is not directly related to object_id conversions but helped with > debugging t5540, which kept failing on master for me (spoiler: it was Fedora > fault). It helps with debugging of failing git-push over

[PATCH 00/11] Some fixes and bunch of object_id conversions

This patch series puts some mundane groundwork for experimentation with a new hashing algorithm in git-hash-object. Some time has passed since my last patches, and I see, that work on new hashing algorithm progressed nicely since then: * brian m. carlson implemented vtable for hash algorithm

Re: [PATCH 00/11] various lockfile-leaks and -fixes

Martin Ågren writes: > On 2 October 2017 at 08:30, Junio C Hamano wrote: > ... >> Thanks, both. Let's merge this to 'next' soonish. > > Thanks both of you for your comments. Based on them, I have made the > following notes: > ... > Especially 9-11

Re: [PATCH 00/11] various lockfile-leaks and -fixes

On 2 October 2017 at 08:30, Junio C Hamano wrote: > Jeff King writes: > >> I've read through each and with the exception of patches 10 and 11, they >> all look good to me. >> >> For 10 and 11, I think you've convinced me that the current behavior is >> buggy. I

Re: [PATCH 00/11] various lockfile-leaks and -fixes

Jeff King writes: > I've read through each and with the exception of patches 10 and 11, they > all look good to me. > > For 10 and 11, I think you've convinced me that the current behavior is > buggy. I do wonder if the subtleties might be easier to understand as a > single patch,

Re: [PATCH 00/11] various lockfile-leaks and -fixes

On Sun, Oct 01, 2017 at 04:56:01PM +0200, Martin Ågren wrote: > A recent series allowed `struct lock_file`s to be freed [1], so I wanted > to get rid of the "simple" leaks of this kind. I found a couple of > lock-related cleanups along the way and it resulted in this series. It > feels a bit

Re: [PATCH 00/11] various lockfile-leaks and -fixes

Martin Ågren writes: > Martin Ågren (11): > sha1_file: do not leak `lock_file` > treewide: prefer lockfiles on the stack > lockfile: fix documentation on `close_lock_file_gently()` > tempfile: fix documentation on `delete_tempfile()` > cache-tree: simplify

[PATCH 00/11] various lockfile-leaks and -fixes

A recent series allowed `struct lock_file`s to be freed [1], so I wanted to get rid of the "simple" leaks of this kind. I found a couple of lock-related cleanups along the way and it resulted in this series. It feels a bit scary at eleven patches -- especially as this is about locking -- but I

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Ævar Arnfjörð Bjarmason writes: > It seems pretty haphazard to me, is it even documented somewhere? > > I'm talking about an establish process backed up by code, where for > example I can add an experimental feature in v2.14.0, it'll be subject > to change & warn unless you

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

On Tue, May 16, 2017 at 11:06 AM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> This and many other discussions on-list basically come down to: >> >> 1. Someone wants to change X. >> 2. This would have user impact Y. >> 3. We have no way to

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Ævar Arnfjörð Bjarmason writes: > This and many other discussions on-list basically come down to: > > 1. Someone wants to change X. > 2. This would have user impact Y. > 3. We have no way to quantify Y. > 4. X doesn't happen out of fear of unquantifiable Y. You forgot the step

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

On Tue, May 16, 2017 at 2:37 AM, Junio C Hamano wrote: > Johannes Schindelin writes: > >> On Fri, 12 May 2017, Junio C Hamano wrote: >> >>> Is it really hurting us having to support these old information >>> sources we treat as read-only? >> >>

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Johannes Schindelin writes: > On Fri, 12 May 2017, Junio C Hamano wrote: > >> Is it really hurting us having to support these old information >> sources we treat as read-only? > > Well, you frequently complain about my patches, claiming that they place > unnecessary

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Hi Junio, On Sat, 13 May 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > On Fri, 12 May 2017, Junio C Hamano wrote: > >> ... > >> FWIW, I do not think there is any reason for people to be using > >> .git/remotes/, but for .git/branches/, I do not

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Jonathan Nieder writes: > Johannes Schindelin wrote: >> On Fri, 12 May 2017, Junio C Hamano wrote: > >>> And this one is also important. I do not think we had to touch any >>> code that handles .git/remotes/ or .git/branches when we extended >>> the .git/config based

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Johannes Schindelin writes: > On Fri, 12 May 2017, Junio C Hamano wrote: >> ... >> FWIW, I do not think there is any reason for people to be using >> .git/remotes/, but for .git/branches/, I do not think I can offer a >> more efficient and easier to use alternative

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Johannes Schindelin wrote: > On Fri, 12 May 2017, Junio C Hamano wrote: >> And this one is also important. I do not think we had to touch any >> code that handles .git/remotes/ or .git/branches when we extended >> the .git/config based configuration for remotes, simply because the >> old data

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Hi Junio, On Fri, 12 May 2017, Junio C Hamano wrote: > Junio C Hamano writes: > > > Johannes Schindelin writes: > > > >> Git uses the config for remote/upstream information in favor of the > >> previously-used .git/remotes/ and .git/branches/ for

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Junio C Hamano writes: > Johannes Schindelin writes: > >> Git uses the config for remote/upstream information in favor of the >> previously-used .git/remotes/ and .git/branches/ for a decade now. > > The last time I thought about trying this

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Hi Peff, On Fri, 12 May 2017, Jeff King wrote: > On Thu, May 11, 2017 at 03:47:33PM +0200, Johannes Schindelin wrote: > > > Git uses the config for remote/upstream information in favor of the > > previously-used .git/remotes/ and .git/branches/ for a decade now. > > > > Nothing in Git writes

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Hi Junio, On Fri, 12 May 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > Git uses the config for remote/upstream information in favor of the > > previously-used .git/remotes/ and .git/branches/ for a decade now. > > The last time I thought about

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

On Thu, May 11, 2017 at 03:47:33PM +0200, Johannes Schindelin wrote: > Git uses the config for remote/upstream information in favor of the > previously-used .git/remotes/ and .git/branches/ for a decade now. > > Nothing in Git writes to these files any longer, and the most prominent > user of

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Johannes Schindelin writes: > Git uses the config for remote/upstream information in favor of the > previously-used .git/remotes/ and .git/branches/ for a decade now. The last time I thought about trying this several years ago, I found that people who need to grab

[PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Git uses the config for remote/upstream information in favor of the previously-used .git/remotes/ and .git/branches/ for a decade now. Nothing in Git writes to these files any longer, and the most prominent user of .git/branches/ (Cogito) is long abandoned. It is time to start not only

Re: [PATCH 00/11] nd/worktree-move update

On Sat, Feb 4, 2017 at 1:25 AM, Junio C Hamano wrote: > Even if you think "the right way" is to add to the iterators, I > suspect that we can still do incremental fixes? I agree with the > order of importance Michael listed in his message (i.e. the index > and the HEAD first,

Re: [PATCH 00/11] nd/worktree-move update

Junio C Hamano writes: > I do not recall seeing that. I however deliberately ignored another > statement because I thought it enough to answer, which was: Oops. "because I didn't think I thought it enough to answer" was what I meant.

Re: [PATCH 00/11] nd/worktree-move update

Duy Nguyen writes: > On Fri, Feb 3, 2017 at 3:21 AM, Junio C Hamano wrote: >> Johannes Schindelin writes: >> >>> Also, the more important reply was Peff's reply that suggested that the >>> proposed fix was incomplete, as it

Re: [PATCH 00/11] nd/worktree-move update

On Fri, Feb 3, 2017 at 3:21 AM, Junio C Hamano wrote: > Johannes Schindelin writes: > >> Also, the more important reply was Peff's reply that suggested that the >> proposed fix was incomplete, as it misses --unpack-unreachable: >>

Re: [PATCH 00/11] nd/worktree-move update

Johannes Schindelin writes: > Also, the more important reply was Peff's reply that suggested that the > proposed fix was incomplete, as it misses --unpack-unreachable: > https://public-inbox.org/git/20160601160143.ga9...@sigill.intra.peff.net/ While I think that

Re: [PATCH 00/11] nd/worktree-move update

Hi Duy, On Thu, 2 Feb 2017, Johannes Schindelin wrote: > Hi Duy, > > On Thu, 2 Feb 2017, Duy Nguyen wrote: > > > On Thu, Feb 2, 2017 at 5:37 PM, Johannes Schindelin > > wrote: > > > > > > On Thu, 2 Feb 2017, Duy Nguyen wrote: > > > > > >> You meant this one [1]?

Re: [PATCH 00/11] nd/worktree-move update

Hi Duy, On Thu, 2 Feb 2017, Duy Nguyen wrote: > On Thu, Feb 2, 2017 at 5:37 PM, Johannes Schindelin > wrote: > > > > On Thu, 2 Feb 2017, Duy Nguyen wrote: > > > >> On Thu, Feb 2, 2017 at 4:43 PM, Johannes Schindelin > >> wrote: > >> > >

Re: [PATCH 00/11] nd/worktree-move update

On Thu, Feb 2, 2017 at 5:37 PM, Johannes Schindelin wrote: > Hi Duy, > > On Thu, 2 Feb 2017, Duy Nguyen wrote: > >> On Thu, Feb 2, 2017 at 4:43 PM, Johannes Schindelin >> wrote: >> > >> > On Thu, 2 Feb 2017, Duy Nguyen wrote: >> > >> >> On

Re: [PATCH 00/11] nd/worktree-move update

Hi Duy, On Thu, 2 Feb 2017, Duy Nguyen wrote: > On Thu, Feb 2, 2017 at 4:43 PM, Johannes Schindelin > wrote: > > > > On Thu, 2 Feb 2017, Duy Nguyen wrote: > > > >> On Thu, Feb 2, 2017 at 4:16 PM, Johannes Schindelin > >> wrote: > >> > >

Re: [PATCH 00/11] nd/worktree-move update

On Thu, Feb 2, 2017 at 4:43 PM, Johannes Schindelin wrote: > Hi Duy, > > On Thu, 2 Feb 2017, Duy Nguyen wrote: > >> On Thu, Feb 2, 2017 at 4:16 PM, Johannes Schindelin >> wrote: >> > Hi Duy, >> > >> > On Thu, 2 Feb 2017, Nguyễn Thái Ngọc

Re: [PATCH 00/11] nd/worktree-move update

Hi Duy, On Thu, 2 Feb 2017, Duy Nguyen wrote: > On Thu, Feb 2, 2017 at 4:16 PM, Johannes Schindelin > wrote: > > Hi Duy, > > > > On Thu, 2 Feb 2017, Nguyễn Thái Ngọc Duy wrote: > > > >> This squashes two changes from Johannes and Ramsay: [...] > > > > Sorry, I lost

Re: [PATCH 00/11] nd/worktree-move update

On Thu, Feb 2, 2017 at 4:16 PM, Johannes Schindelin wrote: > Hi Duy, > > On Thu, 2 Feb 2017, Nguyễn Thái Ngọc Duy wrote: > >> This squashes two changes from Johannes and Ramsay: [...] > > Sorry, I lost track of the worktree discussions... Could you remind me > which

Re: [PATCH 00/11] nd/worktree-move update

Hi Duy, On Thu, 2 Feb 2017, Nguyễn Thái Ngọc Duy wrote: > This squashes two changes from Johannes and Ramsay: [...] Sorry, I lost track of the worktree discussions... Could you remind me which patch is supposed to fix my continuous reflog corruption? Thanks, Dscho

[PATCH 00/11] nd/worktree-move update

This squashes two changes from Johannes and Ramsay: diff --git a/builtin/worktree.c b/builtin/worktree.c index 339c622e20..a1c91f1542 100644 --- a/builtin/worktree.c +++ b/builtin/worktree.c @@ -528,7 +528,7 @@ static int unlock_worktree(int ac, const char **av, const char *prefix) static

Re: [PATCH 00/11] git worktree (re)move

Junio C Hamano writes: > Duy Nguyen writes: > >> The following patch should fix it if that's the same thing you saw. I >> could pile it on worktree-move series, or you can make it a separate >> one-patch series. What's your preference? > > Giving a stable

Re: [PATCH 00/11] git worktree (re)move

Duy Nguyen writes: > The following patch should fix it if that's the same thing you saw. I > could pile it on worktree-move series, or you can make it a separate > one-patch series. What's your preference? Giving a stable output to the users is probably a good preparatory fix

Re: [PATCH 00/11] git worktree (re)move

On Wed, Nov 16, 2016 at 8:05 PM, Duy Nguyen wrote: > diff --git a/worktree.c b/worktree.c > index f7869f8..fe92d6f 100644 > --- a/worktree.c > +++ b/worktree.c > @@ -173,6 +173,13 @@ static void mark_current_worktree(struct worktree > **worktrees) > free(git_dir); > }

Re: [PATCH 00/11] git worktree (re)move

On Sat, Nov 12, 2016 at 06:53:44PM -0800, Junio C Hamano wrote: > not ok 12 - move worktree > # > # git worktree move source destination && > # test_path_is_missing source && > # git worktree list --porcelain | grep "^worktree" >actual && > #

[PATCH 00/11] git worktree (re)move

This is mostly a resend from last time [1]. The main difference is patch 10/11 to prevent moving a worktree that contains submodules because these .git files may need rewritten to point to the right place. I'm leaving the rewriting .git files for future (preferably done by "submodules guys"). [1]

Re: [PATCH 00/11] Resumable clone

Junio C Hamano wrote: > Eric Wong writes: > > >> [primeclone] > >>url = http://location/pack-$NAME.pack > >>filetype = pack > > > > If unconfigured, I wonder if a primeclone pack can be inferred by > > the existence of a pack bitmap (or merely being

Re: [PATCH 00/11] Resumable clone

Junio C Hamano writes: > Junio C Hamano writes: > > What "git clone" should have been was: > > * Parse command line arguments; > > * Create a new repository and go into it; this step would > require us to have parsed the command line for

Re: [PATCH 00/11] Resumable clone

Junio C Hamano writes: >>> git clone --resume >> >> I think calling "git fetch" should resume, actually. >> It would reduce the learning curve and seems natural to me: >> "fetch" is jabout grabbing whatever else appeared since the >> last clone/fetch happened. > > I hate say

Re: [PATCH 00/11] Resumable clone

Eric Wong writes: >> [primeclone] >> url = http://location/pack-$NAME.pack >> filetype = pack > > If unconfigured, I wonder if a primeclone pack can be inferred by > the existence of a pack bitmap (or merely being the biggest+oldest > pack for dumb HTTP). That would

Re: [PATCH 00/11] Resumable clone

Kevin Wern wrote: > Hey, all, > > It's been a while (sent a very short patch in May), but I've > still been working on the resumable clone feature and checking up on > the mailing list for any updates. After submitting the prime-clone > service alone, I figured

Re: [PATCH 00/11] Resumable clone

Kevin Wern writes: > It's been a while (sent a very short patch in May), but I've > still been working on the resumable clone feature and checking up on > the mailing list for any updates. After submitting the prime-clone > service alone, I figured implementing the whole

[PATCH 00/11] Resumable clone

Hey, all, It's been a while (sent a very short patch in May), but I've still been working on the resumable clone feature and checking up on the mailing list for any updates. After submitting the prime-clone service alone, I figured implementing the whole thing would be the best way to understand

Re: [PATCH 00/11] nd/icase updates

Nguyễn Thái Ngọc Duy writes: > This update drops 1/12, which is an unnecessary change, and changes a > couple of echo/printf to test_write_lines. One of those echo uses > backlashes and causes problems with Debian dash. > > Interdiff therefore is not really interesting

[PATCH 00/11] nd/icase updates

This update drops 1/12, which is an unnecessary change, and changes a couple of echo/printf to test_write_lines. One of those echo uses backlashes and causes problems with Debian dash. Interdiff therefore is not really interesting diff --git a/builtin/grep.c b/builtin/grep.c index

[PATCH 00/11] Completion fixes and improvements

Hi, Here's a bunch of patches I've been using for a long time. I don't recall if I've sent some of these before. Here they are in case anybody is interested. Cheers. Felipe Contreras (11): completion: add missing fetch options completion: bash: remove old wrappers completion: bash:

Re: [RFC/WIP PATCH 00/11] Protocol version 2, again!

On Thu, Jun 4, 2015 at 6:09 AM, Jeff King p...@peff.net wrote: On Mon, Jun 01, 2015 at 10:49:45AM -0700, Stefan Beller wrote: However the client side with builtin/fetch, builtin/fetch-pack, fetch-pack is a bit of a mystery to me, as I cannot fully grasp the difference between * connect.{h,c}

Re: [RFC/WIP PATCH 00/11] Protocol version 2, again!

On Mon, Jun 01, 2015 at 10:49:45AM -0700, Stefan Beller wrote: However the client side with builtin/fetch, builtin/fetch-pack, fetch-pack is a bit of a mystery to me, as I cannot fully grasp the difference between * connect.{h,c} * remote.{h.c} * transport.{h.c} there. All of it seems to

Re: [RFC/WIP PATCH 00/11] Protocol version 2, again!

On Tue, Jun 2, 2015 at 12:49 AM, Stefan Beller sbel...@google.com wrote: However the client side with builtin/fetch, builtin/fetch-pack, fetch-pack is a bit of a mystery to me, as I cannot fully grasp the difference between * connect.{h,c} * remote.{h.c} * transport.{h.c} there. All of it

Re: [RFC/WIP PATCH 00/11] Protocol version 2, again!

On Wed, May 27, 2015 at 12:08 AM, Jeff King p...@peff.net wrote: On Wed, May 27, 2015 at 02:18:18AM -0400, Jeff King wrote: The new protocol works just like the old protocol, except for the capabilities negotiation being before any exchange of real data. I like this approach. [...] So

Re: [RFC/WIP PATCH 00/11] Protocol version 2, again!

On Tue, May 26, 2015 at 03:01:04PM -0700, Stefan Beller wrote: Just give us something to play around with - Peff at GitMerge 2015 Sounds like something I would say. The new protocol works just like the old protocol, except for the capabilities negotiation being before any exchange of

Re: [RFC/WIP PATCH 00/11] Protocol version 2, again!

On Wed, May 27, 2015 at 02:18:18AM -0400, Jeff King wrote: The new protocol works just like the old protocol, except for the capabilities negotiation being before any exchange of real data. I like this approach. [...] So now I've read through all the patches. I still like it. :) There's

[RFC/WIP PATCH 00/11] Protocol version 2, again!

Just give us something to play around with - Peff at GitMerge 2015 This is another approach for updating the pack protocol of Git. While in the previous attempts I tried to come up with the perfect specification of the new protocol I realized that such an approach doesn't lead anywhere. So

Re: [PATCH 00/11] Allow reference values to be checked in a transaction

Michael Haggerty mhag...@alum.mit.edu writes: The main purpose of this series is to simplify the interface to reference transactions as follows: * Remove the need to supply an explicit have_old parameter to ref_transaction_update() and ref_transaction_delete(). Instead, check the

Re: [PATCH 00/11] Allow reference values to be checked in a transaction

On Mon, Feb 9, 2015 at 12:40 PM, Michael Haggerty mhag...@alum.mit.edu wrote: I am not sure what advantages this would bring. A better history for bisection? I cannot speak for Michael, but my understanding was to have mh/reflog-expire and sb/atomic-push-fix merged now that 2.3 is out and

Re: [PATCH 00/11] Allow reference values to be checked in a transaction

Michael Haggerty mhag...@alum.mit.edu writes: On 02/09/2015 08:05 PM, Stefan Beller wrote: On Mon, Feb 9, 2015 at 10:41 AM, Junio C Hamano gits...@pobox.com wrote: Michael Haggerty mhag...@alum.mit.edu writes: [...] This patch series applies on top of master merged together with

Re: [PATCH 00/11] Allow reference values to be checked in a transaction

On 02/09/2015 08:05 PM, Stefan Beller wrote: On Mon, Feb 9, 2015 at 10:41 AM, Junio C Hamano gits...@pobox.com wrote: Michael Haggerty mhag...@alum.mit.edu writes: [...] This patch series applies on top of master merged together with sb/atomic-push, which in turn depends on mh/reflog-expire.

Re: [PATCH 00/11] Allow reference values to be checked in a transaction

On Mon, Feb 9, 2015 at 10:41 AM, Junio C Hamano gits...@pobox.com wrote: Michael Haggerty mhag...@alum.mit.edu writes: The main purpose of this series is to simplify the interface to reference transactions as follows: * Remove the need to supply an explicit have_old parameter to

[PATCH 00/11] Allow reference values to be checked in a transaction

The main purpose of this series is to simplify the interface to reference transactions as follows: * Remove the need to supply an explicit have_old parameter to ref_transaction_update() and ref_transaction_delete(). Instead, check the old_sha1 if and only if it is non-NULL. * Allow NULL to

[PATCH 00/11] git_config callers rewritten with the new config-set API

The ta/config-set API is more or less solidified. This series builds on the top of 4c715ebb in pu (ta/config-set). On top of it, it also requires series [1] (Rewrite `git_config()` using config-set API) for proper error checking. This series is the first batch of patches which rewrites the

Re: [PATCH 00/11] git_config callers rewritten with the new config-set API

Tanay Abhra tanay...@gmail.com writes: This series is the first batch of patches which rewrites the existing callers using a non-callback approach. This series aims to, * rewrite the existing callers, as you can see from the diff stat the bew API provides a much concise and clear control

[PATCH 00/11] Add transaction support for reflog

This patch series is based on the ref-transaction series and is available at https://github.com/rsahlberg/git/tree/ref-transactions-reflog This patch series adds transaction support for updating the reflog. Ronnie Sahlberg (11): refs.c make ref_transaction_create a wrapper to

[PATCH 00/11] Use ref transactions from most callers

This patch series changes most of the places where the ref functions for locking and writing refs to instead use the new ref transaction API. There are still three more places where write_ref_sha1() is called from outside of refs.c but those all will require more complex work and review so those

Re: [PATCH 00/11] More preparatory work for multiparent tree-walker

On Wed, Feb 12, 2014 at 09:25:51AM -0800, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: Kirill Smelkov k...@mns.spb.ru writes: Sorry for the confusion. Could you please do the following: Patches should be applied over to ks/tree-diff-walk (74aa4a18). Before applying

  1   2   >