| Submitter | Gábor Stefanik |
|---|---|
| Date | Oct. 17, 2016, 6:27 p.m. |
| Message ID | <a41abe53dbc2c28d3b65.1476728849@GSTEFANIK.NavnGo.local> |
| Download | mbox | patch |
| Permalink | /patch/17156/ |
| State | Accepted |
| Headers | show |
Comments
On 10/17/2016 08:55 PM, Kevin Bullock wrote: >> On Oct 17, 2016, at 13:45, Gábor STEFANIK <Gabor.STEFANIK@nng.com> wrote: >> >> -----Original Message----- >>> From: Kevin Bullock [mailto:kbullock+mercurial@ringworld.org] >>> Sent: Monday, October 17, 2016 8:37 PM >>> To: Gábor STEFANIK <Gabor.STEFANIK@nng.com> >>> Cc: mercurial-devel@mercurial-scm.org >>> Subject: Re: [PATCH v3] update: enable copy tracing for backwards and non- >>> linear updates >>> >>>> On Oct 17, 2016, at 13:27, Gábor Stefanik <gabor.stefanik@nng.com> >>> wrote: >>>> >>>> # HG changeset patch >>>> # User Gábor Stefanik <gabor.stefanik@nng.com> # Date 1472155346 -7200 >>>> # Thu Aug 25 22:02:26 2016 +0200 >>>> # Node ID a41abe53dbc2c28d3b656f2a138da26949cf91d3 >>>> # Parent 3fc51a50bec71bb34c11beaaa6686d521ac706b1 >>>> update: enable copy tracing for backwards and non-linear updates >>> >>> Urk. It's generally confusing to send just one updated patch to the end of an >>> in-flight series (but it's good you at least flagged it v3). >>> >>> Since 1-7 of the v2 series are queued already, can you resend current >>> versions of 8-12 as a v4? >> >> Done. >> >> It was Pierre-Yves's request to separate the last patch from the series, since it's not related to graft. >> But if there's disagreement on this, I'm more than happy to have it treated as part of the series. Actually, my initial request was to not include this one in the original batch (and I missed the fact he did) and then to send that one when the first series would be in. However, This patch seems to work just fine with only the initial first 5 that are pushed. So resending it independently was a good idea. So despite the general confusion on various sides, the end result of Gábor sending this on its own ended up being pretty good. I've pushed this patch. > Fair enough, I wasn't aware of that. In that case I would've said to resend just 8-11, but it's fine that you resent them as one chunk. For the record, I would have preferred that part of the series to not be sent again as a V4. The V2 was still in review and no change had been requested to it. Having it resent is increasing list traffic, patch tracking work and confusion on my side for no visible benefit. Kevin, any reason why you requested that ? Cheers,
On 10/17/2016 10:41 PM, Pierre-Yves David wrote: > > > On 10/17/2016 08:55 PM, Kevin Bullock wrote: >>> On Oct 17, 2016, at 13:45, Gábor STEFANIK <Gabor.STEFANIK@nng.com> >>> wrote: >>> >>> -----Original Message----- >>>> From: Kevin Bullock [mailto:kbullock+mercurial@ringworld.org] >>>> Sent: Monday, October 17, 2016 8:37 PM >>>> To: Gábor STEFANIK <Gabor.STEFANIK@nng.com> >>>> Cc: mercurial-devel@mercurial-scm.org >>>> Subject: Re: [PATCH v3] update: enable copy tracing for backwards >>>> and non- >>>> linear updates >>>> >>>>> On Oct 17, 2016, at 13:27, Gábor Stefanik <gabor.stefanik@nng.com> >>>> wrote: >>>>> >>>>> # HG changeset patch >>>>> # User Gábor Stefanik <gabor.stefanik@nng.com> # Date 1472155346 -7200 >>>>> # Thu Aug 25 22:02:26 2016 +0200 >>>>> # Node ID a41abe53dbc2c28d3b656f2a138da26949cf91d3 >>>>> # Parent 3fc51a50bec71bb34c11beaaa6686d521ac706b1 >>>>> update: enable copy tracing for backwards and non-linear updates >>>> >>>> Urk. It's generally confusing to send just one updated patch to the >>>> end of an >>>> in-flight series (but it's good you at least flagged it v3). >>>> >>>> Since 1-7 of the v2 series are queued already, can you resend current >>>> versions of 8-12 as a v4? >>> >>> Done. >>> >>> It was Pierre-Yves's request to separate the last patch from the >>> series, since it's not related to graft. >>> But if there's disagreement on this, I'm more than happy to have it >>> treated as part of the series. > > Actually, my initial request was to not include this one in the original > batch (and I missed the fact he did) and then to send that one when the > first series would be in. > > However, This patch seems to work just fine with only the initial first > 5 that are pushed. So resending it independently was a good idea. > > So despite the general confusion on various sides, the end result of > Gábor sending this on its own ended up being pretty good. I've pushed > this patch. > >> Fair enough, I wasn't aware of that. In that case I would've said to >> resend just 8-11, but it's fine that you resent them as one chunk. > > For the record, I would have preferred that part of the series to not be > sent again as a V4. The V2 was still in review and no change had been > requested to it. Having it resent is increasing list traffic, patch > tracking work and confusion on my side for no visible benefit. > Kevin, any reason why you requested that ? Ha, I just connected the dots. A V4 was sent to contains the update to the last patch. I got confused because that patch was in my mind independent and not included in that series at all. Sorry for the confusion and associated grumpyness. Cheers,
On 10/17/2016 10:52 PM, Kevin Bullock wrote: >> On Oct 17, 2016, at 15:51, Kevin Bullock <kbullock+mercurial@ringworld.org> wrote: >> >>> On Oct 17, 2016, at 15:45, Pierre-Yves David <pierre-yves.david@ens-lyon.org> wrote: >>> >>> On 10/17/2016 10:41 PM, Pierre-Yves David wrote: >>>> >>>> On 10/17/2016 08:55 PM, Kevin Bullock wrote: >>>>> Fair enough, I wasn't aware of that. In that case I would've said to >>>>> resend just 8-11, but it's fine that you resent them as one chunk. >>>> >>>> For the record, I would have preferred that part of the series to not be >>>> sent again as a V4. The V2 was still in review and no change had been >>>> requested to it. Having it resent is increasing list traffic, patch >>>> tracking work and confusion on my side for no visible benefit. >>>> Kevin, any reason why you requested that ? >>> >>> Ha, I just connected the dots. A V4 was sent to contains the update to the last patch. I got confused because that patch was in my mind independent and not included in that series at all. Sorry for the confusion and associated grumpyness. >> >> Yeah, I was just trying to establish positively what part of the series was still active. Once part of a series is queued and another part is sliced off as a separate patch, I and our review tooling are both likely to drop the remainder on the floor (whether that's the intent or not). >> >> As I understand it now, you've queued #5 out of v4 and the rest of v4 is still under review. Is that right? > > ...and sometime soon we'll have improved tooling that can understand queuing non-contiguous parts of a series. Yep, I've queued patch #5 of the v4 (because I picked it up when it was Patch 1 of another series (flagged V3)). Does this confusing statement lift your confusion?
Patch
diff -r 3fc51a50bec7 -r a41abe53dbc2 mercurial/merge.py --- a/mercurial/merge.py Tue Oct 11 04:39:47 2016 +0200 +++ b/mercurial/merge.py Thu Aug 25 22:02:26 2016 +0200 @@ -1555,15 +1555,16 @@ pas = [p1] # deprecated config: merge.followcopies - followcopies = False + followcopies = repo.ui.configbool('merge', 'followcopies', True) if overwrite: pas = [wc] + followcopies = False elif pas == [p2]: # backwards - pas = [wc.p1()] - elif not branchmerge and not wc.dirty(missing=True): - pass - elif pas[0] and repo.ui.configbool('merge', 'followcopies', True): - followcopies = True + pas = [p1] + elif not pas[0]: + followcopies = False + if not branchmerge and not wc.dirty(missing=True): + followcopies = False ### calculate phase actionbyfile, diverge, renamedelete = calculateupdates( diff -r 3fc51a50bec7 -r a41abe53dbc2 tests/test-merge-local.t --- a/tests/test-merge-local.t Tue Oct 11 04:39:47 2016 +0200 +++ b/tests/test-merge-local.t Thu Aug 25 22:02:26 2016 +0200 @@ -66,7 +66,7 @@ merging zzz1_merge_ok merging zzz2_merge_bad warning: conflicts while merging zzz2_merge_bad! (edit, then use 'hg resolve --mark') - 2 files updated, 1 files merged, 3 files removed, 1 files unresolved + 2 files updated, 1 files merged, 2 files removed, 1 files unresolved use 'hg resolve' to retry unresolved file merges [1] @@ -104,7 +104,7 @@ merging zzz1_merge_ok merging zzz2_merge_bad warning: conflicts while merging zzz2_merge_bad! (edit, then use 'hg resolve --mark') - 2 files updated, 1 files merged, 3 files removed, 1 files unresolved + 2 files updated, 1 files merged, 2 files removed, 1 files unresolved use 'hg resolve' to retry unresolved file merges [1] diff -r 3fc51a50bec7 -r a41abe53dbc2 tests/test-mq-subrepo.t --- a/tests/test-mq-subrepo.t Tue Oct 11 04:39:47 2016 +0200 +++ b/tests/test-mq-subrepo.t Thu Aug 25 22:02:26 2016 +0200 @@ -304,6 +304,7 @@ record this change to '.hgsub'? [Ynesfdaq?] y warning: subrepo spec file '.hgsub' not found + warning: subrepo spec file '.hgsub' not found abort: uncommitted changes in subrepository 'sub' [255] % update substate when adding .hgsub w/clean updated subrepo @@ -319,6 +320,7 @@ record this change to '.hgsub'? [Ynesfdaq?] y warning: subrepo spec file '.hgsub' not found + warning: subrepo spec file '.hgsub' not found path sub source sub revision b2fdb12cd82b021c3b7053d67802e77b6eeaee31 diff -r 3fc51a50bec7 -r a41abe53dbc2 tests/test-up-local-change.t --- a/tests/test-up-local-change.t Tue Oct 11 04:39:47 2016 +0200 +++ b/tests/test-up-local-change.t Thu Aug 25 22:02:26 2016 +0200 @@ -67,6 +67,10 @@ summary: 2 $ hg --debug up 0 + starting 4 threads for background file closing (?) + searching for copies back to rev 0 + unmatched files in local (from topological common ancestor): + b resolving manifests branchmerge: False, force: False, partial: False ancestor: 1e71731e6fbb, local: 1e71731e6fbb+, remote: c19d34741b0a @@ -222,4 +226,20 @@ 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg st +test updating backwards through a rename + + $ hg mv a b + $ hg ci -m b + $ echo b > b + $ hg up -q 0 + $ hg st + M a + $ hg diff --nodates + diff -r cb9a9f314b8b a + --- a/a + +++ b/a + @@ -1,1 +1,1 @@ + -a + +b + $ cd ..