On Sat, Sep 01, 2018 at 10:29:25PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > Anyway. Not that exciting, and kind of obviously dumb in retrospect. But
> > I think it was worth analyzing to see what went wrong. If there's an
> > immediate lesson, it is probably: add tests even for changes that
On Saturday, September 1, 2018 7:18:34 PM MST Eric Sunshine wrote:
> > diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
> > @@ -682,4 +682,12 @@ test_expect_success '--dry-run with conflicts fixed
> > from a merge' ' +test_expect_failure '--dry-run --short' '
> > + # setup two branches
On Sun, Sep 02, 2018 at 12:17:53AM +0200, Ævar Arnfjörð Bjarmason wrote:
> > Here are the steps to reproduce it:
> > $ git clone git://github.com/lucvoo/sparse-dev.git
> > $ cd
> > $ git co index-corruption
> > $ git rm -r validation/ Documentation/
> > $ git commit -m -p
> > $ git
On Sat, Sep 1, 2018 at 10:18 PM Eric Sunshine wrote:
> On Sat, Sep 1, 2018 at 7:53 PM Stephen P. Smith wrote:
> > The test demonstrates that the setting of the commitable flag is
> > broken.
>
> s/commitable/committable/
Looking at patch 3/3, I see that this misspelling exists in the code
On Sat, Sep 1, 2018 at 7:53 PM Stephen P. Smith wrote:
> Add test for commit --dry-run --short.
The first line of a commit message typically mentions the area or
module being touched. It's also customary not to capitalize the first
word and to omit the final period. So, for instance:
t7501:
On 6 August 2018 at 17:26, Jeff King wrote:
> I suspect it still has a bug, which is that it is handling this
> first-parent-goes-left case, but probably gets the straight-parent case
> wrong. But at least in this form, I think it is obvious to see where
> that bug is (the "three" in the comment
A couple of years ago, during a patch review Junio found that the
commitable bit as implemented in wt-status.c was broken.
Stephen P. Smith (3):
Move has_unmerged earlier in the file.
Add test for commit --dry-run --short.
wt-status.c: Set the commitable flag in the collect phase.
Move has_unmerged up in the file so that has_unmerged can be called in
wt_status_collect where we need to place a merge check.
Signed-off-by: Stephen P. Smith
---
wt-status.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/wt-status.c
In an update to fix a bug with "commit --dry-run" it was found that
the commitable flag was broken. The update was, at the time, accepted
as it was better than the previous version. [1]
Since the setting of the commitable flag had been done in
wt_longstatus_print_updated, move it to
Add test for commit with --dry-run --short for a new file of zero
length.
The test demonstrates that the setting of the commitable flag is
broken.
Signed-off-by: Stephen P. Smith
---
t/t7501-commit.sh | 8
1 file changed, 8 insertions(+)
diff --git a/t/t7501-commit.sh
On 9/1/2018 4:29 PM, Ævar Arnfjörð Bjarmason wrote:
B.t.w. for Ben or anyone else who knows about the fsmonitor part of
this: I've long been running the whole test suite with
`GIT_FSMONITOR_TEST=$PWD/t7519/fsmonitor-all prove ...` (also along with
GIT_TEST_SPLIT_INDEX=) after all the main
On Sat, Sep 01 2018, Luc Van Oostenryck wrote:
> Hi,
>
> I've just had a scary error:
> error: index uses $?+? extension, which we do not understand
> fatal: index file corrupt
>
> Things were quickly recovered by deleting the index but it clearly
> looks to a but to me.
>
> Here
Hi,
I've just had a scary error:
error: index uses $?+? extension, which we do not understand
fatal: index file corrupt
Things were quickly recovered by deleting the index but it clearly
looks to a but to me.
Here are the steps to reproduce it:
$ git clone
On Mon, 2018-08-06 at 13:02 -0400, Randall S. Becker wrote:
>
> Any idea when this is going to be in an official release, and exactly
> what the settings will be for "Not Developer". I assume DEVELOPER=0
> and DEVOPTS=error, which is the current behaviour, correct? I am the
> platform maintainer
On Sat, Sep 01 2018, Jeff King wrote:
> On Sat, Sep 01, 2018 at 03:48:13AM -0400, Jeff King wrote:
>
>> Commit 6a1e32d532 (pack-objects: reuse on-disk deltas for
>> thin "have" objects, 2018-08-21) taught pack-objects a new
>> optimization trick. Since this wasn't meant to change
>>
On Fri, Aug 31, 2018 at 02:40:12PM -0400, Eric Sunshine wrote:
> On Fri, Aug 31, 2018 at 2:21 PM Torsten Bögershausen wrote:
> > Out of interest: why do we use a "tmp" file here?
> > Would it make more sense to chain the 'tr' with 'sed' and skip the
> > tmp file ?
> >
> > tr
On Fri, Aug 31, 2018 at 2:39 PM Johannes Schindelin
wrote:
>
> Hi,
>
> On Thu, 30 Aug 2018, Stefan Beller wrote:
>
> > On Thu, Aug 30, 2018 at 12:20 PM Jeff King wrote:
> > >
> > > [...] Myers does not promise to find the absolute minimal diff. [...]
> >
> > The `Myers` (our default) diff
On Sat, Sep 01 2018, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Aug 16 2018, Ævar Arnfjörð Bjarmason wrote:
>
>> On Thu, Aug 16 2018, Jeff King wrote:
>>
>>> On Thu, Aug 16, 2018 at 08:54:25AM +0200, Ulrich Windl wrote:
>>>
I'd like to point out some minor issue observed while processing
On Thu, Aug 16 2018, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Aug 16 2018, Jeff King wrote:
>
>> On Thu, Aug 16, 2018 at 08:54:25AM +0200, Ulrich Windl wrote:
>>
>>> I'd like to point out some minor issue observed while processing some
>>> 5-object repository with many binary objects, but
On Thu, Aug 30, 2018 at 10:39:20PM -0700, Stephen P. Smith wrote:
> diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
> index 810d4cea7..fc69da816 100755
> --- a/t/t7501-commit.sh
> +++ b/t/t7501-commit.sh
> @@ -682,4 +682,14 @@ test_expect_success '--dry-run with conflicts fixed from
> a merge'
On 08/29, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > Yeah that makes sense. Maybe something like this?
> >
> > (replying to here to keep
> > the patches in one thread)
> >
> > Documentation/technical/rerere.txt | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git
On Fri, Aug 31, 2018 at 10:16:49AM +0200, Christian Couder wrote:
> > 2. To get our landing page and list of projects in order (and also
> > micro-projects for applicants). This can probably build on the
> > previous round at:
> >
> >https://git.github.io/Outreachy-15/
> >
> >
On Fri, Aug 31, 2018 at 01:30:05PM +0300, Оля Тележная wrote:
> I was Outreachy intern last winter. I guess I need to speak up: I will
> be happy if my feedback helps you.
> At first, I want to repeat all thanks to Outreachy organizers and Git
> mentors. That was unique experience and I am so
On Sat, Sep 01, 2018 at 03:48:13AM -0400, Jeff King wrote:
> Commit 6a1e32d532 (pack-objects: reuse on-disk deltas for
> thin "have" objects, 2018-08-21) taught pack-objects a new
> optimization trick. Since this wasn't meant to change
> user-visible behavior, but only produce smaller packs more
In the early days of the bitmap code, there was a single
static bitmap_index struct that was used behind the scenes,
and any bitmap-related functions could lazily check
bitmap_git.loaded to see if they needed to read the on-disk
data.
But since 3ae5fa0768 (pack-bitmap: remove bitmap_git global
Since it was introduced in fff42755ef (pack-bitmap: add
support for bitmap indexes, 2013-12-21), this function has
freed the result after traversing it. That is an artifact of
the early days of the bitmap code, when we had a single
static "struct bitmap_index". Back then, it was intended
that you
Commit 6a1e32d532 (pack-objects: reuse on-disk deltas for
thin "have" objects, 2018-08-21) taught pack-objects a new
optimization trick. Since this wasn't meant to change
user-visible behavior, but only produce smaller packs more
quickly, testing focused on t/perf/p5311.
However, since people
Commit 30cdc33fba (pack-bitmap: save "have" bitmap from
walk, 2018-08-21) introduced a new function for looking at
the "have" side of a bitmap walk. Because it only makes
sense to do so after we've finished the walk, we added an
extra safety assertion, making sure that bitmap_git->result
is
On Fri, Aug 31, 2018 at 06:55:58PM -0400, Jeff King wrote:
> On Fri, Aug 31, 2018 at 05:23:17PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> > On Tue, Aug 21 2018, Jeff King wrote:
> >
> > > +int bitmap_has_sha1_in_uninteresting(struct bitmap_index *bitmap_git,
> > > +
Hi Olga,
On Fri, Aug 31, 2018 at 12:30 PM, Оля Тележная wrote:
> Hi everyone,
>
> I was Outreachy intern last winter. I guess I need to speak up: I will
> be happy if my feedback helps you.
> At first, I want to repeat all thanks to Outreachy organizers and Git
> mentors. That was unique
30 matches
Mail list logo
