On 13/10/2019 08:15, Jeff King wrote:
> On Thu, Oct 10, 2019 at 09:13:42AM -0700, James Coglan via GitGitGadget wrote:
>
>> A final addition to that set of changes fixes the coloring of dashes that
>> are drawn next to octopus merges, in a manner compatible with all these
>> changes. The early com
On Thu, Oct 10, 2019 at 09:13:42AM -0700, James Coglan via GitGitGadget wrote:
> A final addition to that set of changes fixes the coloring of dashes that
> are drawn next to octopus merges, in a manner compatible with all these
> changes. The early commits in this set are refactorings that make t
On 10/10/2019 12:13 PM, James Coglan via GitGitGadget wrote:
> This series of patches are designed to improve the output of the log --graph
> command; their effect can be summed up in the following diagram:
>
> BeforeAfter
> ---
>
> *
>
This series of patches are designed to improve the output of the log --graph
command; their effect can be summed up in the following diagram:
BeforeAfter
---
*
|\
| * *
| |\ |\
|
This started out as yak-shaving exercise to introduce the
"container_of" macro to make hashmap more flexible and
less error-prone.
So far I've ended up finding and fixing two real bugs in
patches 1/11 and 2/11 which should be fast-tracked.
Patches 3-9 are straightforward safety fixes to prevent f
Recently I've been writing 'git -c foo.bar ...' often enough that
typing our long configuration variables got annoying...
So this patch series teaches our Bash completion script to complete
supported configuration variables and their values after 'git -c
', and, while at it, after 'git clone -c '
The multi-pack-index provides a fast way to find an object among a large
list of pack-files. It stores a single pack-reference for each object id, so
duplicate objects are ignored. Among a list of pack-files storing the same
object, the most-recently modified one is used.
Create new subcommands fo
Derrick Stolee writes:
>> - perhaps we may eventually want to allow end users (via their
>>~/.gitconfig) and system administrators (via /etc/gitconfig)
>>define such a macro setting (e.g. setting macro.largeRepoSetting
>>sets pack.usebitmaps=true, pack.useSpars=true, etc.) *after* we
On 6/5/2019 4:39 PM, Junio C Hamano wrote:
> "Derrick Stolee via GitGitGadget" writes:
>
>> This patch series includes a few new config options we created to speed up
>> certain critical commands in VFS for Git. On their own, they would
>> contribute little value as it is hard to discover new con
"Derrick Stolee via GitGitGadget" writes:
> This patch series includes a few new config options we created to speed up
> certain critical commands in VFS for Git. On their own, they would
> contribute little value as it is hard to discover new config variables.
> Instead, I've created this RFC as
On 6/4/2019 10:43 AM, Johannes Schindelin wrote:
> Hi Stolee,
>
> On Mon, 3 Jun 2019, Derrick Stolee via GitGitGadget wrote:
>
>> 1. (Patches 1-3) Introduce a new 'core.size' config setting that takes
>> 'large' as a value. This enables several config values that are
>> beneficial for la
Hi Stolee,
On Mon, 3 Jun 2019, Derrick Stolee via GitGitGadget wrote:
> 1. (Patches 1-3) Introduce a new 'core.size' config setting that takes
> 'large' as a value. This enables several config values that are
> beneficial for large repos.
I find `core.size` a bit non-descriptive. Maybe
On 6/3/2019 4:18 PM, Derrick Stolee via GitGitGadget wrote:
> 1. (Patches 1-3) Introduce a new 'core.size' config setting that takes
> 'large' as a value.
I do want to point out that this "core.size=large" option is probably a
terrible name and could easily be replaced with something better.
This patch series includes a few new config options we created to speed up
certain critical commands in VFS for Git. On their own, they would
contribute little value as it is hard to discover new config variables.
Instead, I've created this RFC as a goal for probably three sequential patch
series:
This is the first leg on the long journey to a fully built-in git add -i
(next up: parts 2 [https://github.com/gitgitgadget/git/pull/171], 3
[https://github.com/gitgitgadget/git/pull/172], 4
[https://github.com/gitgitgadget/git/pull/173], 5
[https://github.com/gitgitgadget/git/pull/174], and 6
[ht
On 20/03/2019 23:05, Ævar Arnfjörð Bjarmason wrote:
On Tue, Mar 19 2019, Phillip Wood wrote:
From: Phillip Wood
When the builtin rebase starts an interactive rebase it parses the
options and then repackages them and forks `rebase--interactive`. This
series refactors rebase--interactive so
Phillip Wood writes:
> From: Phillip Wood
>
> When the builtin rebase starts an interactive rebase it parses the
> options and then repackages them and forks `rebase--interactive`. This
> series refactors rebase--interactive so that interactive rebases can
> be started by the builtin rebase with
On Tue, Mar 19 2019, Phillip Wood wrote:
> From: Phillip Wood
>
> When the builtin rebase starts an interactive rebase it parses the
> options and then repackages them and forks `rebase--interactive`. This
> series refactors rebase--interactive so that interactive rebases can
> be started by th
On 2019.03.19 19:03, Phillip Wood wrote:
> From: Phillip Wood
>
> When the builtin rebase starts an interactive rebase it parses the
> options and then repackages them and forks `rebase--interactive`. This
> series refactors rebase--interactive so that interactive rebases can
> be started by the
From: Phillip Wood
When the builtin rebase starts an interactive rebase it parses the
options and then repackages them and forks `rebase--interactive`. This
series refactors rebase--interactive so that interactive rebases can
be started by the builtin rebase without forking. My motivation was to
Introduce the 'test_atexit' helper function to run cleanup commands
unconditionally at the end of a test script, mainly to reliably stop
daemon processes. 'test_atexit' provides a shorter, simpler, more
consistent, and more robust way to accomplish that compared to the
current situation where test
Nguyễn Thái Ngọc Duy writes:
> This was noticed by Ramsay [1] and I almost forgot.
>
> [1]
> http://public-inbox.org/git/419519f9-1b48-93bb-eead-eacf6b383...@ramsayjones.plus.com
Not forgetting is good ;-)
> diff --git a/repository.c b/repository.c
> --- a/repository.c
> +++
This was noticed by Ramsay [1] and I almost forgot.
[1]
http://public-inbox.org/git/419519f9-1b48-93bb-eead-eacf6b383...@ramsayjones.plus.com
Range-diff:
1: 4478671442 ! 1: 971d2839ab cache.h: flip NO_THE_INDEX_COMPATIBILITY_MACROS
switch
@@ -2,12 +2,11 @@
cache.h: flip NO_
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).
The
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 string_l
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 whic
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 if
> 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 th
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 c
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 running git commands
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, thereby
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 makes me wonder if we
should keep prepare_packed_git() private (i.e. how we i
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 my setup and on all Trav
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 drasti
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 alone takes roughly 80
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
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
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 serious reviews.
>
> And
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 initialize the
>>> object store, packfile included, is a private
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 was correct, so it
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 together with
> other topics in flight
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 private matter). How about
>> somethin
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 that topic ever shown to work well together
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 cleaner.
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 ready to be built upon?
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, exp
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 fi
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 "Dele
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, e.
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 and
> aren't limited to SHA-1.
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.
Go
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
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 HTTP in case of
> internal s
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 sel
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 make me feel like wanting to re-roll this, for
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 do wonder if the subtleties might b
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, but I'm OK eith
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 scary
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 locking logic
> apply: move
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 hope
Æ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 configure core.use_exp
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 quantify Y.
>> 4. X doesn't happen out of
Æ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 0. You need to ans
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?
>>
>> Well, you frequently complain about my patches, clai
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 maintenance burden on you.
>
>
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 think I can offer a
> >> more e
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 configuration for remotes, s
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 based on .git/config to
>> do
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 sou
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 a decade now.
> >
> > The last time I thought a
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 several years ago, I found
> that people who need to g
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 to
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 trying this several years ago, I
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 .gi
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 things from many places still d
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 deprecatin
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, and then other per-w
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.
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 misses --unpack-unreachable:
>>> https://public-inbox.org/git/201606011
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:
>> https://public-inbox.org/git/20160601160143.ga9...@sigill.intra.pe
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 --unpack-unreachable thing is a s
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]? There is nothing substantial si
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:
> >> >
> >> > On Thu, 2 Feb 2017, Duy Nguyen wrote:
> >> >
> >> >>
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 Thu, Feb 2, 2017 at 4:16 PM, Johannes Schindelin
>> >> w
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:
> >> >
> >> > On Thu, 2 Feb 2017, Nguyễn Thái Ngọc Duy wrote:
> >>
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 Duy wrote:
>> >
>> >> This squashes two changes from Johann
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 track of the worktree discussi
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 patch is supposed to fix my con
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
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 void
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 output to the users is probably a good p
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 to what is already
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);
> }
>
> +static int com
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 &&
> # cat
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]
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 the biggest+oldest
> > pack for dumb H
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 --template,
> , --separate-git-dir, et
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 this but it sounds t
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 probably be a nice
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 implementing the whole thing would
1 - 100 of 148 matches
Mail list logo
