The first two patches fix errors causing `make hdr-check` to fail. The third is
legacy from v1 but provides code cleanup so we leave it. Finally, the last
patch is a patch which improves the portability and correctness of `hdr-check`.
Changes since v1:
* Reordered patches to put fixes first
* To
Here's a series that shifts the focus slightly to warning about
git-filter-branch usage and avoiding it ourselves. I have retained
patch 4 but left it marked as RFC for further discussion. It appears
that folks generally seem to agree the first three patches are good
to include now -- assuming my
On 23/08/19 11:12PM, Bert Wesarg wrote:
> On Fri, Aug 23, 2019, 18:44 Pratyush Yadav wrote:
>
> > On 23/08/19 08:04AM, Bert Wesarg wrote:
> > > On Fri, Aug 23, 2019 at 12:51 AM Pratyush Yadav
> > wrote:
> > > >
> > > > On 22/08/19 03:34PM, Junio C Hamano wrote:
> > [...]
> > > as I'm the one who
Am 24.08.19 um 08:57 schrieb Bert Wesarg:
> On Sat, Aug 24, 2019 at 1:43 AM David Aguilar wrote:
>> On the other hand, if I had to actually move my hand over to a mouse or
>> trackpad and actually "click" on something then I would be super
>> annoyed. That would be simply horrible with RSI in min
On Sat, Aug 24, 2019 at 08:57:22AM +0200, Bert Wesarg wrote:
> On Sat, Aug 24, 2019 at 1:43 AM David Aguilar wrote:
> > On the other hand, if I had to actually move my hand over to a mouse or
> > trackpad and actually "click" on something then I would be super
> > annoyed. That would be simply ho
On Sat, Aug 24, 2019 at 1:43 AM David Aguilar wrote:
>
> I have a very strong opinion about the confirmation dialog, so I'll just
> mention that here since Hannes is on this thread.
>
> In cola we do have a confirmation dialog, and I strongly believe this is
> the correct behavior because it's an
On Sat, Aug 24, 2019 at 1:43 AM David Aguilar wrote:
>
> On Fri, Aug 23, 2019 at 03:31:03AM +0530, Pratyush Yadav wrote:
> > Hi,
> >
> > This series adds the ability to revert selected lines and hunks in
> > git-gui. Partially based on the patch by Bert Wesarg [0].
> >
> > The commits can be found
On Fri, Aug 23, 2019 at 03:31:03AM +0530, Pratyush Yadav wrote:
> Hi,
>
> This series adds the ability to revert selected lines and hunks in
> git-gui. Partially based on the patch by Bert Wesarg [0].
>
> The commits can be found in the topic branch 'py/revert-hunks-lines'
> at https://github.com
On 23/08/19 08:04AM, Bert Wesarg wrote:
> On Fri, Aug 23, 2019 at 12:51 AM Pratyush Yadav
> wrote:
> >
> > On 22/08/19 03:34PM, Junio C Hamano wrote:
[...]
> as I'm the one who use this feature for more than 7 years, I can only
> object to this. I'm happy to have the confirmation dialog for the
Bert Wesarg writes:
> The thing is, that the partial revert "just don't happen by accident".
> Here are the minimum user actions needed to get to this dialog:
>
> 1. whole-file revert
>
> - do a Ctrl+J, more or less anywhere in the GUI
>
> 2. hunk revert/revert one unselected line
>
> - right cli
On Fri, Aug 23, 2019 at 12:51 AM Pratyush Yadav wrote:
>
> On 22/08/19 03:34PM, Junio C Hamano wrote:
> > Pratyush Yadav writes:
> >
> > > This series adds the ability to revert selected lines and hunks in
> > > git-gui. Partially based on the patch by Bert Wesarg [0].
> > >
> > > The commits can
On 22/08/19 03:34PM, Junio C Hamano wrote:
> Pratyush Yadav writes:
>
> > This series adds the ability to revert selected lines and hunks in
> > git-gui. Partially based on the patch by Bert Wesarg [0].
> >
> > The commits can be found in the topic branch 'py/revert-hunks-lines'
> > at https://gi
Pratyush Yadav writes:
> This series adds the ability to revert selected lines and hunks in
> git-gui. Partially based on the patch by Bert Wesarg [0].
>
> The commits can be found in the topic branch 'py/revert-hunks-lines'
> at https://github.com/prati0100/git-gui/tree/py/revert-hunks-lines
>
>
Hi,
This series adds the ability to revert selected lines and hunks in
git-gui. Partially based on the patch by Bert Wesarg [0].
The commits can be found in the topic branch 'py/revert-hunks-lines'
at https://github.com/prati0100/git-gui/tree/py/revert-hunks-lines
Once reviewed, pull the commits
Thanks for the review, Eric. I've incorporated all of your suggestions
and, while I was doing that, I found a couple more places for cleanup.
Currently, format-patch only puts "*** SUBJECT HERE ***" when a cover
letter is generated. However, it is already smart enough to be able to
populate the co
On 2019.07.29 22:29, Martin Ågren wrote:
> On Fri, 19 Jul 2019 at 01:56, Josh Steadmon wrote:
> > This series revives an old suggestion [...] to make merge honor
> > pre-commit hook or a separate pre-merge hook. Since pre-commit does not
> > receive any arguments (which the hook could use tell bet
On 2019.07.29 22:09, Martin Ågren wrote:
> On Fri, 19 Jul 2019 at 01:56, Josh Steadmon wrote:
> > * Martin's objection on 1/4 that the sample hook would always exit
> > successfully is (I believe) incorrect. To test this, I ran
> > "/bin/true && exec test 0 == 1" in a /bin/sh subshell, and it
On Fri, 19 Jul 2019 at 01:56, Josh Steadmon wrote:
> This series revives an old suggestion [...] to make merge honor
> pre-commit hook or a separate pre-merge hook. Since pre-commit does not
> receive any arguments (which the hook could use tell between commit and
> merge) and in order to keep exi
On Fri, 19 Jul 2019 at 01:56, Josh Steadmon wrote:
> * Martin's objection on 1/4 that the sample hook would always exit
> successfully is (I believe) incorrect. To test this, I ran
> "/bin/true && exec test 0 == 1" in a /bin/sh subshell, and it
> correctly had a non-zero exit status.
I retr
(I'm resending this cover letter with fixed Message-Id so that threading
@ public-inbox works properly. Sorry for the noise.)
I would like to revive discussion on this series; I have addressed most
of the review comments on the original series sent by Michael, with the
following exceptions:
* Mar
I would like to revive discussion on this series; I have addressed most
of the review comments on the original series sent by Michael, with the
following exceptions:
* Martin's objection on 1/4 that the sample hook would always exit
successfully is (I believe) incorrect. To test this, I ran
"/
git-mergetool spawns an enormous amount of processes. For this reason,
the test script, t7610, is exceptionally slow, in particular, on
Windows. Most of the processes are invocations of git. There are
also some that can be replaced with shell builtins.
I've measured the number of processes and the
This is a reworked/extended version of the single patch "rebase: fix
garbled progress display with '-x'" at:
https://public-inbox.org/git/20190430142556.20921-1-szeder@gmail.com/T/#u
Changes:
- Add a helper function to clear the whole line on the terminal,
using an ANSI escape sequen
From: Phillip Wood
refs/rewritten/ is now cleaned up on --quit as well as --abort. I've
also added a patch to make sequencer_remove_state() to return any
errors, so rebase now always reports any errors that occur when
cleaning up the state directory.
These patches are still based on pw/rebase-i-
> Kyle Meyer writes:
>
> [...]
>
>> diff --git a/git-submodule.sh b/git-submodule.sh
>> index 514ede2596..6c74656027 100755
>> --- a/git-submodule.sh
>> +++ b/git-submodule.sh
>> @@ -234,10 +234,18 @@ cmd_add()
>> if test -z "$force" &&
>> ! git add --dry-run --ignore-missing --n
This patch series fixes two progress display issues:
- When showing throughput, and the both the total and the throughput
change units in the same update, than the previously shown
progress bar is not cleaned up properly:
Receiving objects: 25% (2901/11603), 772.01 KiB | 733.00 K
This is version 2 of a small patch series to fix tag related issues in
`git replace --graft` that Andreas Schwab reported in:
https://public-inbox.org/git/mvmd0mcsjkf@suse.de/
The first version of this patch series was:
https://public-inbox.org/git/20190328171722.9753-1-chrisc...@tuxfamily.o
Version 2 addresses progress-related concerns raised in the previous version
of the midx verify code.
This version also extends the existing progress.[ch] code and adds a
"sparse" mode that automatically ensures the 100% message is issued.
Hi,
Duy Nguyen wrote:
> Poking this thread before it goes completely dead...
I've been meaning to send out a re-rolled version. I didn't
realize 2 weeks had slipped by already. :/
> On Sat, Mar 2, 2019 at 12:34 AM Todd Zullinger wrote:
>>
>> The completion.commands config var must be set in ei
Being rather a power user of the interactive rebase, I discovered recently
that one of my scripts ran into an odd problem where an interactive rebase
appended new commands to the todo list, and the interactive rebase failed to
validate the (short) OIDs. But when I tried to fix things via git rebase
It was reported by Nazri Ramliy that ORIG_HEAD was set incorrectly again,
this time caused by the shortcut to call git am directly, without detouring
to a Unix shell script.
Patch 2/4 might look like something completely unrelated, but without it,
the update to HEAD might use an incorrect reflog m
Hi Junio,
On Fri, 18 Jan 2019, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > Especially on Windows, where Unix shell scripting is a foreign endeavor, and
> > an expensive one at that, we really want to avoid running through the Bash.
> >
> > This not only makes
Junio C Hamano writes:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
>> Especially on Windows, where Unix shell scripting is a foreign endeavor, and
>> an expensive one at that, we really want to avoid running through the Bash.
>>
>> This not only makes everything faster, but also more ro
"Johannes Schindelin via GitGitGadget"
writes:
> Especially on Windows, where Unix shell scripting is a foreign endeavor, and
> an expensive one at that, we really want to avoid running through the Bash.
>
> This not only makes everything faster, but also more robust, as the Bash we
> use on Wind
Especially on Windows, where Unix shell scripting is a foreign endeavor, and
an expensive one at that, we really want to avoid running through the Bash.
This not only makes everything faster, but also more robust, as the Bash we
use on Windows relies on a derivative of the Cygwin runtime, which in
Jonathan Tan writes:
> We could make the caller of demultiplex_sideband() store the outbuf, but
> at this point, it might be better to refactor packet_reader into its own
> file and have it depend on both pkt-line.h and sideband.h.
I do not know or too deeply care about the pkt-line / sideband
d
> > Ah...yes, you're right. I forgot to build before running the tests. I'll
> > take a look.
>
> Thanks.
Thanks once again for taking a look. It turns out that it's because
progress messages are sometimes split across PKT-LINEs depending on your
luck, and we need to retain the "leftover" on a \2
Jonathan Tan writes:
>> Jonathan Tan writes:
>>
>> >> Jonathan Tan writes:
>> >>
>> >> > Like v1, this is on origin/ms/packet-err-check.
>> >>
>> >> By the way, when merged to 'pu' as one of the earlier topic, t5409
>> >> starts to fail under --stress.
>> >>
>> >> $ git checkout 'origin/p
> Jonathan Tan writes:
>
> >> Jonathan Tan writes:
> >>
> >> > Like v1, this is on origin/ms/packet-err-check.
> >>
> >> By the way, when merged to 'pu' as one of the earlier topic, t5409
> >> starts to fail under --stress.
> >>
> >>$ git checkout 'origin/pu^{/^Merge branch .jt/fetch-v2-s
Jonathan Tan writes:
>> Jonathan Tan writes:
>>
>> > Like v1, this is on origin/ms/packet-err-check.
>>
>> By the way, when merged to 'pu' as one of the earlier topic, t5409
>> starts to fail under --stress.
>>
>> $ git checkout 'origin/pu^{/^Merge branch .jt/fetch-v2-sideband}'
>>
> Jonathan Tan writes:
>
> > Like v1, this is on origin/ms/packet-err-check.
>
> By the way, when merged to 'pu' as one of the earlier topic, t5409
> starts to fail under --stress.
>
> $ git checkout 'origin/pu^{/^Merge branch .jt/fetch-v2-sideband}'
> $ make
> $ cd t && sh ./
Jonathan Tan writes:
> Like v1, this is on origin/ms/packet-err-check.
By the way, when merged to 'pu' as one of the earlier topic, t5409
starts to fail under --stress.
$ git checkout 'origin/pu^{/^Merge branch .jt/fetch-v2-sideband}'
$ make
$ cd t && sh ./t5409-col*.sh
Jonathan Tan writes:
> @@ -474,6 +474,7 @@ void packet_reader_init(struct packet_reader *reader, int
> fd,
> reader->buffer = packet_buffer;
> reader->buffer_size = sizeof(packet_buffer);
> reader->options = options;
> + reader->me = "git";
> }
This was somewhat unexpecte
Like v1, this is on origin/ms/packet-err-check.
Thanks, Junio, for your reviews.
Jonathan Tan (4):
pkt-line: introduce struct packet_writer
sideband: reverse its dependency on pkt-line
{fetch,upload}-pack: sideband v2 fetch response
tests: define GIT_TEST_SIDEBAND_ALL
Documentation/tech
Junio C Hamano writes:
> Sergey Organov , Sergey Organov
> writes:
>
>> Hi Junio,
>>
>> What's the status of these patches?
>
> The status of these patches is "Just updated on the list", as far as
> I am concerned, and its cover letter would have described what's
> improved relative to the previ
Sergey Organov , Sergey Organov
writes:
> Hi Junio,
>
> What's the status of these patches?
The status of these patches is "Just updated on the list", as far as
I am concerned, and its cover letter would have described what's
improved relative to the previous round better than whatever answer
I
Hi Junio,
What's the status of these patches?
Thanks,
-- Sergey
Sergey Organov writes:
> When cherry-picking multiple commits, it's impossible to have both
> merge- and non-merge commits on the same command-line. Not specifying
> '-m 1' results in cherry-pick refusing to handle merge commits,
When cherry-picking multiple commits, it's impossible to have both
merge- and non-merge commits on the same command-line. Not specifying
'-m 1' results in cherry-pick refusing to handle merge commits, while
specifying '-m 1' fails on non-merge commits.
This patch series allow '-m 1' for non-merge
Hi Daniel,
On 16-May-17 6:00 AM, Daniel Ferreira wrote:
This is the second version of a patch series to start porting
git-add--interactive from Perl to C.
Series:
v1:
https://public-inbox.org/git/1494009820-2090-1-git-send-email-bnm...@gmail.com/
Travis CI build: https://travis-ci.org/theiost
Roger Strain writes:
> After doing some testing at scale, determined that one call was
> taking too long; replaced that with an alternate call which
> returns the same data significantly faster.
Curious where the time goes. Do you know?
> Also, if anyone has any other feedback on these I'd rea
After doing some testing at scale, determined that one call was taking too
long; replaced that with an alternate call which returns the same data
significantly faster.
Also, if anyone has any other feedback on these I'd really love to hear it.
It's working better for us (as in, it actually gene
Josh Steadmon writes:
> Yes, the version on my desktop sends version=2 when archiving:
>
> ∫ which git
> /usr/bin/git
> ∫ git --version
> git version 2.19.0.605.g01d371f741-goog
> ∫ GIT_TRACE_PACKET=${HOME}/server_trace git daemon \
> --enable=upload-archive \
> --base-path=${HOME}/src/bare-r
On 2018.09.27 15:20, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
> > 1. Clients sending version=2 when they do not, in fact, speak protocol
> > v2 for a service is a (serious) bug. (Separately from this
> > series) we should fix it.
> >
> > 2. That bug is already in the wild, ala
Jonathan Nieder writes:
> 1. Clients sending version=2 when they do not, in fact, speak protocol
> v2 for a service is a (serious) bug. (Separately from this
> series) we should fix it.
>
> 2. That bug is already in the wild, alas. Fortunately the semantics of
> GIT_PROTOCOL as a
Jonathan Tan writes:
> To answer Junio's questions in [1], I think it's best to include the
> full patch set that I'm developing, so here it is. The original patch is
> now patch 3 of this set.
Yeah, taking it out of context did make its purpose fuzzy. Without
the other patches in the series th
To answer Junio's questions in [1], I think it's best to include the
full patch set that I'm developing, so here it is. The original patch is
now patch 3 of this set.
[1] https://public-inbox.org/git/xmqq8t3pnphe@gitster-ct.c.googlers.com/
Rearranging Junio's questions:
> ... ah, do you mean
Hi Derrick
On Thu, 27 Sep 2018 at 21:16, Derrick Stolee wrote:
> Thanks! This version satisfies my concerns and looks good to me.
>
> Reviewed-by: Derrick Stolee
Thanks for the spectacularly snappy review. I don't expect commit graphs
to help my use cases a lot, but I still wanted to try them o
On 9/27/2018 3:12 PM, Martin Ågren wrote:
This v2 starts with the same two patches as v1 did, then goes on to
change "[commit] graph file" to "commit-graph file" with a dash, to
match other instances as well as Derrick's feedback.
Thanks! This version satisfies my concerns and looks good to me.
This v2 starts with the same two patches as v1 did, then goes on to
change "[commit] graph file" to "commit-graph file" with a dash, to
match other instances as well as Derrick's feedback.
Martin Ågren (4):
git-commit-graph.txt: fix bullet lists
git-commit-graph.txt: typeset more in monospace
On 2018.09.27 11:20, Stefan Beller wrote:
> On Wed, Sep 26, 2018 at 6:25 PM Josh Steadmon wrote:
> >
> > This is the second version of my series to add a new protocol v2 command
> > for archiving, with support for HTTP(S).
> >
> > NEEDSWORK: a server built with this series is not backwards-compati
Stefan Beller wrote:
> On Wed, Sep 26, 2018 at 6:25 PM Josh Steadmon wrote:
>> I've been discussing workarounds for this with Jonathan Nieder, but
>> please let me know if you have any suggestions for v3 of this series.
>
> Care to open the discussion to the list? What are the different
> approac
On Wed, Sep 26, 2018 at 6:25 PM Josh Steadmon wrote:
>
> This is the second version of my series to add a new protocol v2 command
> for archiving, with support for HTTP(S).
>
> NEEDSWORK: a server built with this series is not backwards-compatible
> with clients that set GIT_PROTOCOL=version=2 or
This is the second version of my series to add a new protocol v2 command
for archiving, with support for HTTP(S).
NEEDSWORK: a server built with this series is not backwards-compatible
with clients that set GIT_PROTOCOL=version=2 or configure
protocol.version=2. The old client will unconditionally
Hi,
On Mon, 6 Aug 2018, Eric Sunshine wrote:
> On Mon, Aug 6, 2018 at 9:20 PM Hilco Wijbenga
> wrote:
> > But your suggestion did make me think about what behaviour I would
> > like to see, exactly. I like that Git removes commits that no longer
> > serve any purpose (because I've included thei
I reported a couple of times that t5552 is not passing reliably. It has now
reached next, and will no doubt infect master soon.
Turns out that it is not a Windows-specific issue, even if it occurs a lot
more often on Windows than elsewhere. (And even if it is apparently
impossible to trigger on L
On Thu, Aug 9, 2018 at 10:16 AM Ben Peart wrote:
> In fact, in the other [1] patch series, we're detecting the number of
> cache entries that are the same as the cache tree and using that to
> traverse_by_cache_tree(). At that point, couldn't we copy the
> corresponding cache tree entries over to
On Wed, Aug 8, 2018 at 10:53 PM Ben Peart wrote:
>
>
>
> On 8/1/2018 12:38 PM, Duy Nguyen wrote:
> > On Tue, Jul 31, 2018 at 01:31:31PM -0400, Ben Peart wrote:
> >>
> >>
> >> On 7/31/2018 12:50 PM, Ben Peart wrote:
> >>>
> >>>
> >>> On 7/31/2018 11:31 AM, Duy Nguyen wrote:
> >>
>
> > In t
On 8/8/2018 4:53 PM, Ben Peart wrote:
On 8/1/2018 12:38 PM, Duy Nguyen wrote:
On Tue, Jul 31, 2018 at 01:31:31PM -0400, Ben Peart wrote:
On 7/31/2018 12:50 PM, Ben Peart wrote:
On 7/31/2018 11:31 AM, Duy Nguyen wrote:
In the performance game of whack-a-mole, that call to repair
c
On 8/1/2018 12:38 PM, Duy Nguyen wrote:
On Tue, Jul 31, 2018 at 01:31:31PM -0400, Ben Peart wrote:
On 7/31/2018 12:50 PM, Ben Peart wrote:
On 7/31/2018 11:31 AM, Duy Nguyen wrote:
In the performance game of whack-a-mole, that call to repair cache-tree
is now looking quite expensive.
Eric Sunshine writes:
> On Mon, Aug 6, 2018 at 9:20 PM Hilco Wijbenga
> wrote:
>> But your suggestion did make me think about what behaviour I would
>> like to see, exactly. I like that Git removes commits that no longer
>> serve any purpose (because I've included their changes in earlier
>> co
On Mon, Aug 6, 2018 at 9:20 PM Hilco Wijbenga wrote:
> But your suggestion did make me think about what behaviour I would
> like to see, exactly. I like that Git removes commits that no longer
> serve any purpose (because I've included their changes in earlier
> commits). So I would not want to ke
On Tue, Jul 31, 2018 at 11:22 PM, Eric Sunshine wrote:
> On Tue, Jul 31, 2018 at 9:30 PM Hilco Wijbenga
> wrote:
>> On Tue, Jul 31, 2018 at 12:33 AM, Eric Sunshine
>> wrote:
>> > This is a re-roll of [1] which fixes sequencer bugs resulting in commit
>> > object corruption when "rebase -i --ro
On Wed, Aug 1, 2018 at 7:25 PM brian m. carlson
wrote:
> On Tue, Jul 31, 2018 at 03:33:27AM -0400, Eric Sunshine wrote:
> > This is a re-roll of [1] which fixes sequencer bugs resulting in commit
> > object corruption when "rebase -i --root" swaps in a new commit as root.
> > Unfortunately, those
On Tue, Jul 31, 2018 at 03:33:27AM -0400, Eric Sunshine wrote:
> This is a re-roll of [1] which fixes sequencer bugs resulting in commit
> object corruption when "rebase -i --root" swaps in a new commit as root.
> Unfortunately, those bugs made it into v2.18.0 and have already
> corrupted at least
On Tue, Jul 31, 2018 at 01:31:31PM -0400, Ben Peart wrote:
>
>
> On 7/31/2018 12:50 PM, Ben Peart wrote:
> >
> >
> > On 7/31/2018 11:31 AM, Duy Nguyen wrote:
>
> >>
> >>> In the performance game of whack-a-mole, that call to repair cache-tree
> >>> is now looking quite expensive...
> >>
> >> Y
On Tue, Jul 31, 2018 at 9:30 PM Hilco Wijbenga wrote:
> On Tue, Jul 31, 2018 at 12:33 AM, Eric Sunshine
> wrote:
> > This is a re-roll of [1] which fixes sequencer bugs resulting in commit
> > object corruption when "rebase -i --root" swaps in a new commit as root.
> > Unfortunately, those bugs
Hi Eric,
On Tue, Jul 31, 2018 at 12:33 AM, Eric Sunshine wrote:
> This is a re-roll of [1] which fixes sequencer bugs resulting in commit
> object corruption when "rebase -i --root" swaps in a new commit as root.
> Unfortunately, those bugs made it into v2.18.0 and have already
> corrupted at lea
On 7/31/2018 12:50 PM, Ben Peart wrote:
On 7/31/2018 11:31 AM, Duy Nguyen wrote:
In the performance game of whack-a-mole, that call to repair cache-tree
is now looking quite expensive...
Yeah and I think we can whack that mole too. I did some measurement.
Best case possible, we just n
On 7/31/2018 11:31 AM, Duy Nguyen wrote:
On Mon, Jul 30, 2018 at 8:10 PM Ben Peart wrote:
I ran "git checkout" on a large repo and averaged the results of 3 runs.
This clearly demonstrates the benefit of the optimized unpack_trees()
as even the final "diff-index" is essentially a 3rd call
On Mon, Jul 30, 2018 at 8:10 PM Ben Peart wrote:
> I ran "git checkout" on a large repo and averaged the results of 3 runs.
> This clearly demonstrates the benefit of the optimized unpack_trees()
> as even the final "diff-index" is essentially a 3rd call to unpack_trees().
>
> baselinene
On Tue, Jul 31, 2018 at 6:46 AM Eric Sunshine wrote:
> Anyhow, thanks for reading over the series. I appreciate it even if
> our "sense of priority" doesn't always align (as evidenced by your
> review comments and my responses).
To be clear, the changes you suggest all make sense, and would be
we
Hi Eric
On 31/07/18 11:46, Eric Sunshine wrote:
> On Tue, Jul 31, 2018 at 6:06 AM Phillip Wood
> wrote:
>> On 31/07/18 08:33, Eric Sunshine wrote:
>>> Patch 2/4 of this series conflicts with Akinori MUSHA's
>>> 'am/sequencer-author-script-fix' which takes a stab at fixing one of the
>>> four (or
On Tue, Jul 31, 2018 at 6:06 AM Phillip Wood wrote:
> On 31/07/18 08:33, Eric Sunshine wrote:
> > Patch 2/4 of this series conflicts with Akinori MUSHA's
> > 'am/sequencer-author-script-fix' which takes a stab at fixing one of the
> > four (or so) bugs fixed by this series (namely, adding a missin
Hi Eric
On 31/07/18 08:33, Eric Sunshine wrote:
This is a re-roll of [1] which fixes sequencer bugs resulting in commit
object corruption when "rebase -i --root" swaps in a new commit as root.
Unfortunately, those bugs made it into v2.18.0 and have already
corrupted at least one repository (a lo
This is a re-roll of [1] which fixes sequencer bugs resulting in commit
object corruption when "rebase -i --root" swaps in a new commit as root.
Unfortunately, those bugs made it into v2.18.0 and have already
corrupted at least one repository (a local project of mine). Patches 3/4
and 4/4 are new.
On 7/29/2018 6:33 AM, Nguyễn Thái Ngọc Duy wrote:
This series speeds up unpack_trees() a bit by using cache-tree.
unpack-trees could bit split in three big parts
- the actual tree unpacking and running n-way merging
- update worktree, which could be expensive depending on how much I/O
is i
On 7/29/2018 6:33 AM, Nguyễn Thái Ngọc Duy wrote:
This series speeds up unpack_trees() a bit by using cache-tree.
unpack-trees could bit split in three big parts
- the actual tree unpacking and running n-way merging
- update worktree, which could be expensive depending on how much I/O
is i
This series speeds up unpack_trees() a bit by using cache-tree.
unpack-trees could bit split in three big parts
- the actual tree unpacking and running n-way merging
- update worktree, which could be expensive depending on how much I/O
is involved
- repair cache-tree
This series focuses on the
On Thu, Jul 19, 2018 at 04:32:59PM -0400, Jeff King wrote:
> This is a patch series to address the discussion in the thread at:
>
> https://public-inbox.org/git/20180713204350.ga16...@sigill.intra.peff.net/
>
> Basically, the question was: can we declare strcpy banned and have a
> linter save
LGTM, thanks for the v2.
This series introduces an "auto" value for git send-email
--transfer-encoding that uses 8bit when possible (i.e. when lines are
998 octets or shorter) and quoted-printable otherwise; it then makes
this the default behavior. It also makes --validate aware of transfer
encoding so it doesn't complain
As a GSoC project, I have been working on the builtin rebase.
The motivation behind the rewrite of rebase i.e. from shell script to C
are for following reasons:
1. Writing shell scripts and getting it to production is much faster
than doing the equivalent in C but lacks in performance and ex
This series replaces the contents of jk/branch-l-0-deprecation,
jk/branch-l-1-removal, and jk/branch-l-2-reincarnation.
It implements the idea discussed in the subthread in:
https://public-inbox.org/git/xmqqzi0hety4@gitster-ct.c.googlers.com/
Namely that "branch -l" would warn about deprec
On Tue, Jun 12, 2018 at 11:10 PM Todd Zullinger wrote:
>
> This replaces my 2/2 "use in-tree Git.pm for tests" with
> Luis's improved version. It also adds Luis's fix to ensure
> the proper exit status on test failures and a minor
> whitespace cleanup.
>
> Is it alright to forge your signoff Luis
This replaces my 2/2 "use in-tree Git.pm for tests" with
Luis's improved version. It also adds Luis's fix to ensure
the proper exit status on test failures and a minor
whitespace cleanup.
Is it alright to forge your signoff Luis?
Luis Marsano (2):
git-credential-netrc: use in-tree Git.pm for t
v2 first fixes a bug in --ita-invisible-in-index that accidentally
affects diffing a worktree and a tree. This caused a regression when
v1's 1/2 turned this option on by default.
Other than that, 4/4 should address Junio's comments on v1's 2/2.
Nguyễn Thái Ngọc Duy (4):
diff: ignore --ita-[in]v
This splits the `rebase --preserve-merges` functionnality from
git-rebase--interactive.sh. All the dead code left by the duplication of
git-rebase--interactive.sh is also removed. This will make it easier to rewrite
this script in C.
This patch series is based of js/sequencer-and-root-commits.
Ch
On Fri, May 11, 2018 at 1:37 AM, Jeff King wrote:
> On Thu, May 10, 2018 at 12:58:45PM -0700, Stefan Beller wrote:
>
>> This series replaces the two commits that were queued on
>> sb/object-store-replace,
>> fixing memory leaks that were recently introduced.
>>
>> Compared to v1, I merged the two
On Thu, May 10, 2018 at 12:58:45PM -0700, Stefan Beller wrote:
> This series replaces the two commits that were queued on
> sb/object-store-replace,
> fixing memory leaks that were recently introduced.
>
> Compared to v1, I merged the two independent series from yesterday,
> rewrote the commit m
This series replaces the two commits that were queued on
sb/object-store-replace,
fixing memory leaks that were recently introduced.
Compared to v1, I merged the two independent series from yesterday,
rewrote the commit message to clear up Junios confusion and addresses Peffs
comments for the pac
1 - 100 of 261 matches
Mail list logo
