Page MenuHomePhabricator

martinvonz (Martin von Zweigbergk)
User

Projects

User Details

User Since
Jun 28 2017, 5:28 PM (158 w, 2 d)

Recent Activity

Today

martinvonz added a comment to D8725: rebase: remove now unnecessary logic to allow empty commit when branch changes.

Could you include in the commit message which commit added the code and which commit made it unnecessary? "the previous patch/commit" is an okay way of saying that , IMO, even though it requires the reviewer to queue the two patches right after each other for the description to make sense.

In this case, I could use the Differential revision (D8724) to refer to the other patch. Would that also make sense? (I wonder why you didn’t mention this possibility — is it because the repository should be self-contained?)

Fri, Jul 10, 1:19 PM
martinvonz added a comment to D8725: rebase: remove now unnecessary logic to allow empty commit when branch changes.

Could you include in the commit message which commit added the code and which commit made it unnecessary? "the previous patch/commit" is an okay way of saying that , IMO, even though it requires the reviewer to queue the two patches right after each other for the description to make sense.

Fri, Jul 10, 11:18 AM
martinvonz added a comment to D8721: scmutil: allowing different files to be prefetched per revision.

Should we have an entry in the release notes about this or have we given up on documenting API changes? I'm fine with either, as long as we have some policy.

Fri, Jul 10, 10:53 AM

Wed, Jul 8

martinvonz added inline comments to D8653: copies: handle more cases where a file got replaced by a copy.
Wed, Jul 8, 2:01 PM

Mon, Jun 29

martinvonz committed rHG5797dbb630df: locks: expect repo lock, not wlock, when writing to .hg/strip-backup/.
locks: expect repo lock, not wlock, when writing to .hg/strip-backup/
Mon, Jun 29, 8:03 AM
martinvonz committed rHG6118ad07b98d: graft: leverage cmdutil.check_incompatible_arguments() for --abort/--stop.
graft: leverage cmdutil.check_incompatible_arguments() for --abort/--stop
Mon, Jun 29, 8:03 AM
martinvonz closed D8666: locks: expect repo lock, not wlock, when writing to .hg/strip-backup/.
Mon, Jun 29, 6:33 AM
martinvonz closed D8669: graft: leverage cmdutil.check_incompatible_arguments() for --abort/--stop.
Mon, Jun 29, 6:33 AM
martinvonz closed D8668: graft: leverage cmdutil.check_incompatible_arguments() for --no-commit.
Mon, Jun 29, 6:32 AM
martinvonz committed rHG27f24dd2a45d: locks: expect repo lock, not wlock, when writing to .hg/strip-backup/.
locks: expect repo lock, not wlock, when writing to .hg/strip-backup/
Mon, Jun 29, 6:32 AM
martinvonz closed D8667: graft: leverage cmdutil.check_at_most_one_arg() for --abort/--stop/--continue.
Mon, Jun 29, 6:32 AM
martinvonz committed rHG5ebcb357d2a5: graft: leverage cmdutil.check_incompatible_arguments() for --abort/--stop.
graft: leverage cmdutil.check_incompatible_arguments() for --abort/--stop
Mon, Jun 29, 6:32 AM
martinvonz committed rHGc63a297fb964: graft: leverage cmdutil.check_incompatible_arguments() for --no-commit.
graft: leverage cmdutil.check_incompatible_arguments() for --no-commit
Mon, Jun 29, 6:31 AM
martinvonz committed rHG7d494425167c: graft: leverage cmdutil.check_at_most_one_arg() for --abort/--stop/--continue.
graft: leverage cmdutil.check_at_most_one_arg() for --abort/--stop/--continue
Mon, Jun 29, 6:31 AM

Thu, Jun 25

martinvonz created D8669: graft: leverage cmdutil.check_incompatible_arguments() for --abort/--stop.
Thu, Jun 25, 6:58 PM
martinvonz created D8668: graft: leverage cmdutil.check_incompatible_arguments() for --no-commit.
Thu, Jun 25, 6:58 PM
martinvonz created D8667: graft: leverage cmdutil.check_at_most_one_arg() for --abort/--stop/--continue.
Thu, Jun 25, 6:58 PM
martinvonz created D8666: locks: expect repo lock, not wlock, when writing to .hg/strip-backup/.
Thu, Jun 25, 3:24 PM
martinvonz committed rHG3fadbdc47aed: merge with stable.
merge with stable
Thu, Jun 25, 1:37 PM
martinvonz closed D8665: merge: don't grab wlock when merging in memory.
Thu, Jun 25, 12:29 PM
martinvonz committed rHGd1471dbbdd63: merge: don't grab wlock when merging in memory.
merge: don't grab wlock when merging in memory
Thu, Jun 25, 12:29 PM
martinvonz closed D8657: procutil: make recent fix for zombies compatible with py2.
Thu, Jun 25, 11:43 AM
martinvonz committed rHG95c672c07116: procutil: make recent fix for zombies compatible with py2.
procutil: make recent fix for zombies compatible with py2
Thu, Jun 25, 11:43 AM
martinvonz added a comment to D8657: procutil: make recent fix for zombies compatible with py2.

Reminder that this is intended for stable (since that's where the py3-only fix is)

Thu, Jun 25, 10:51 AM
martinvonz created D8665: merge: don't grab wlock when merging in memory.
Thu, Jun 25, 10:20 AM
martinvonz created D8657: procutil: make recent fix for zombies compatible with py2.
Thu, Jun 25, 3:13 AM

Tue, Jun 23

martinvonz created D8653: copies: handle more cases where a file got replaced by a copy.
Tue, Jun 23, 1:04 PM
martinvonz created D8652: tests: test more cases where a file got replaced by a copy.
Tue, Jun 23, 1:03 PM
martinvonz closed D8649: help: document meaning of '%' in graphlog output.
Tue, Jun 23, 6:13 AM
martinvonz closed D8650: copies: implement __repr__ on branch_copies for debugging.
Tue, Jun 23, 6:13 AM
martinvonz committed rHGcfd06649a1b8: copies: implement __repr__ on branch_copies for debugging.
copies: implement __repr__ on branch_copies for debugging
Tue, Jun 23, 6:13 AM
martinvonz committed rHG3d41172f2ac9: help: document meaning of '%' in graphlog output.
help: document meaning of '%' in graphlog output
Tue, Jun 23, 6:13 AM
martinvonz created D8650: copies: implement __repr__ on branch_copies for debugging.
Tue, Jun 23, 3:10 AM
martinvonz created D8649: help: document meaning of '%' in graphlog output.
Tue, Jun 23, 1:21 AM

Mon, Jun 22

martinvonz added a comment to D8646: update: suggest --merge while `hg up` across topo branches.

We have not made this change before because there is no hg update --abort. Do we have that feature yet (I haven't followed all the changes recently)?

Mon, Jun 22, 1:04 AM

Thu, Jun 11

martinvonz planned changes to D8596: merge: mark copies in in-memory context when merging.
Thu, Jun 11, 1:47 PM
martinvonz added inline comments to D8596: merge: mark copies in in-memory context when merging.
Thu, Jun 11, 10:35 AM
martinvonz updated the diff for D8596: merge: mark copies in in-memory context when merging.
Thu, Jun 11, 10:34 AM
martinvonz updated the diff for D8616: merge: chain copies with existing copies in working copy.
Thu, Jun 11, 10:34 AM
martinvonz added inline comments to D8616: merge: chain copies with existing copies in working copy.
Thu, Jun 11, 9:51 AM

Jun 10 2020

martinvonz updated the diff for D8616: merge: chain copies with existing copies in working copy.
Jun 10 2020, 1:54 PM
martinvonz updated the diff for D8596: merge: mark copies in in-memory context when merging.
Jun 10 2020, 1:54 PM
martinvonz updated the diff for D8595: copies: make _chain() and _filter() public.
Jun 10 2020, 1:54 PM
martinvonz added inline comments to D8596: merge: mark copies in in-memory context when merging.
Jun 10 2020, 1:54 PM
martinvonz added a comment to D8587: metadata: move computation related to files touched in a dedicated module.

Worth mentioning in relnotes? (This has been queued, so that would be a followup.)

I don't think so, what would you mention ?

We have a section for API changes. This patch affects many functions. (I suppose you might argue that we don't need to mention changes in private APIs (name prefixed by _), but these are not all private.)

These are private API used by experimental feature. I really do not expect that to affect anyone.

Jun 10 2020, 11:11 AM
martinvonz added a comment to D8587: metadata: move computation related to files touched in a dedicated module.

Worth mentioning in relnotes? (This has been queued, so that would be a followup.)

I don't think so, what would you mention ?

Jun 10 2020, 11:05 AM
martinvonz added a comment to D8587: metadata: move computation related to files touched in a dedicated module.

Worth mentioning in relnotes? (This has been queued, so that would be a followup.)

Jun 10 2020, 10:58 AM

Jun 9 2020

martinvonz added a comment to D8552: fix: use context to fetch mergestate instead of loading it directly.

@martinvonz can you clarify why mergestate on an overlayworkingctx would never make sense ?

That makes sense. What I said does not make sense is to check for unresolved merge conflicts (before starting an operation).

Checking for unresolved merge conflict on an overlayworkingctx does not make sense because the overlayctx is new and therefor will always be conflict free ?

I view overlayworkingctx as something that exists for creating commits without touching the working copy and without caring about the working copy state. In the code here, we explicitly care about the working copy state (because we're going to modify it).

Ah, interesting. That angle hadn't occurred to me. I don't think I'm wholly convinced, but maybe we need an explicit mechanism for "get the wdir" as contrasted with "get a context for the wdir".
I think I'll at least remove this patch from the stack for now...

Question @martinvonz : do you think overlayworkingctx should also not read the local mergestate, but instead should use an in-memory one? I'm not sure how you're envisioning the abstraction boundary there...

Jun 9 2020, 5:28 PM
martinvonz added a comment to D8563: localrepo: get mergestate via context.

Is your concern about the creation of new "independant" wctc (by each call of repo[None]) instead of reusing the same wctx for the full operation ?

Jun 9 2020, 12:46 PM
martinvonz added a comment to D8552: fix: use context to fetch mergestate instead of loading it directly.

@martinvonz can you clarify why mergestate on an overlayworkingctx would never make sense ?

That makes sense. What I said does not make sense is to check for unresolved merge conflicts (before starting an operation).

Checking for unresolved merge conflict on an overlayworkingctx does not make sense because the overlayctx is new and therefor will always be conflict free ?

Jun 9 2020, 12:43 PM
martinvonz added a comment to D7177: rebase: introduce optional parent mapping.

Maybe another option is to allow multiple -d arguments for this case? Something like hg rebase -r C -d B -d D. I haven't thought through BC, but I think that's what I'd prefer if we were writing rebase from scratch. I know we can't support hg rebase -r C -d 'B + D' for backward-compatibility reasons (because we already support that -- it rebases to the highest revnum in the set).

That's interresting. How would that works with a practical case ?

The example I have was meant to be a practical example for how to do it in the case given in the patch description :) But let me know if you meant some other aspect of "how it works". As I said, I'm not sure ant the BC bit of it at least.

I meant how that would work in general, esepcially case more complicated than the basic base shown by @joerg.sonnenberger.

Jun 9 2020, 12:15 PM
martinvonz added a comment to D8596: merge: mark copies in in-memory context when merging.

This is not meant for review; I'm sending it now in case it'll be useful for @durin42's work on merge-diffs. I also included the rest of the stack to explain why I wrote the code.

Can you add a RFC tag to this then ?

I had marked it "Changes Planned" but I've fixed the issues and the version I uploaded a day or two ago is ready for review .

Okay, (It would help if you reply to your own comment to state this clearly, which you now did)

Jun 9 2020, 12:06 PM
martinvonz added a comment to D7177: rebase: introduce optional parent mapping.

Maybe another option is to allow multiple -d arguments for this case? Something like hg rebase -r C -d B -d D. I haven't thought through BC, but I think that's what I'd prefer if we were writing rebase from scratch. I know we can't support hg rebase -r C -d 'B + D' for backward-compatibility reasons (because we already support that -- it rebases to the highest revnum in the set).

That's interresting. How would that works with a practical case ?

Jun 9 2020, 10:26 AM
martinvonz added a comment to D8599: rebase: remove now-unused arguments from rebasenode().

This patch seems related to D8596 which @martinvonz pointed as "not meant to be merged". What should we do with this diff ? is it intended for landing ? If not could get we it out of need-review and marke it RFC ?

Jun 9 2020, 10:12 AM
martinvonz added a comment to D8598: rebase: drop duplicate call to copies.graftcopies().

This patch seems related to D8596 which @martinvonz pointed as "not meant to be merged". What should we do with this diff ? is it intended for landing ? If not could get we it out of need-review and marke it RFC ?

Jun 9 2020, 10:12 AM
martinvonz added a comment to D8597: rebase: use merge.graft() instead of merge.update().

This patch seems related to D8596 which @martinvonz pointed as "not meant to be merged". What should we do with this diff ? is it intended for landing ? If not could get we it out of need-review and marke it RFC ?

Jun 9 2020, 10:12 AM
martinvonz added a comment to D8616: merge: chain copies with existing copies in working copy.

This patch seems related to D8596 which @martinvonz pointed as "not meant to be merged". What should we do with this diff ? is it intended for landing ? If not could get we it out of need-review and marke it RFC ?

Jun 9 2020, 10:11 AM
martinvonz added a comment to D8595: copies: make _chain() and _filter() public.

This patch seems related to D8596 which @martinvonz pointed as "not meant to be merged". What should we do with this diff ? is it intended for landing ? If not could get we it out of need-review and marke it RFC ?

Jun 9 2020, 10:11 AM
martinvonz added a comment to D8596: merge: mark copies in in-memory context when merging.

This is not meant for review; I'm sending it now in case it'll be useful for @durin42's work on merge-diffs. I also included the rest of the stack to explain why I wrote the code.

Can you add a RFC tag to this then ?

Jun 9 2020, 10:04 AM
martinvonz closed D8615: merge: move an inspection of the dirstate from record to calculate phase.
Jun 9 2020, 6:10 AM
martinvonz closed D8606: context: fix creation of ProgrammingError to not use non-existent field.
Jun 9 2020, 6:10 AM
martinvonz committed rHG818b4f19ef23: merge: move an inspection of the dirstate from record to calculate phase.
merge: move an inspection of the dirstate from record to calculate phase
Jun 9 2020, 6:10 AM
martinvonz committed rHGb2e5ec0c596b: context: fix creation of ProgrammingError to not use non-existent field.
context: fix creation of ProgrammingError to not use non-existent field
Jun 9 2020, 6:09 AM
martinvonz committed rHG33ef8841da62: help: explain in `hg help flags` that unambiguous prefixes are allowed.
help: explain in `hg help flags` that unambiguous prefixes are allowed
Jun 9 2020, 6:09 AM
martinvonz closed D8607: help: explain in `hg help flags` that unambiguous prefixes are allowed.
Jun 9 2020, 6:09 AM

Jun 8 2020

martinvonz added a comment to D8563: localrepo: get mergestate via context.

@martinvonz do you mean that these patch break normal behavior if taken without other patch ?

Jun 8 2020, 2:27 PM
martinvonz added a comment to D8552: fix: use context to fetch mergestate instead of loading it directly.

@martinvonz can you clarify why mergestate on an overlayworkingctx would never make sense ?

Jun 8 2020, 2:00 PM

Jun 5 2020

martinvonz updated the summary of D8599: rebase: remove now-unused arguments from rebasenode().
Jun 5 2020, 9:40 PM
martinvonz updated the summary of D8598: rebase: drop duplicate call to copies.graftcopies().
Jun 5 2020, 9:39 PM
martinvonz updated the summary of D8597: rebase: use merge.graft() instead of merge.update().
Jun 5 2020, 9:39 PM
martinvonz created D8616: merge: chain copies with existing copies in working copy.
Jun 5 2020, 9:39 PM
martinvonz updated the summary of D8596: merge: mark copies in in-memory context when merging.
Jun 5 2020, 9:37 PM
martinvonz updated the summary of D8595: copies: make _chain() and _filter() public.
Jun 5 2020, 9:37 PM
martinvonz created D8615: merge: move an inspection of the dirstate from record to calculate phase.
Jun 5 2020, 9:37 PM

Jun 4 2020

martinvonz retitled D8606: context: fix creation of ProgrammingError to not use non-existent field from context: fix creation of a ProgrammingError to not use non-existent field to context: fix creation of ProgrammingError to not use non-existent field.
Jun 4 2020, 11:03 AM
martinvonz created D8607: help: explain in `hg help flags` that unambiguous prefixes are allowed.
Jun 4 2020, 2:50 AM
martinvonz created D8606: context: fix creation of ProgrammingError to not use non-existent field.
Jun 4 2020, 12:53 AM

May 30 2020

martinvonz added a comment to D7177: rebase: introduce optional parent mapping.

Maybe another option is to allow multiple -d arguments for this case? Something like hg rebase -r C -d B -d D. I haven't thought through BC, but I think that's what I'd prefer if we were writing rebase from scratch. I know we can't support hg rebase -r C -d 'B + D' for backward-compatibility reasons (because we already support that -- it rebases to the highest revnum in the set).

May 30 2020, 2:08 PM

May 29 2020

martinvonz updated subscribers of D8596: merge: mark copies in in-memory context when merging.

This is not meant for review; I'm sending it now in case it'll be useful for @durin42's work on merge-diffs. I also included the rest of the stack to explain why I wrote the code.

May 29 2020, 12:00 PM
martinvonz created D8599: rebase: remove now-unused arguments from rebasenode().
May 29 2020, 11:58 AM
martinvonz created D8598: rebase: drop duplicate call to copies.graftcopies().
May 29 2020, 11:58 AM
martinvonz created D8596: merge: mark copies in in-memory context when merging.
May 29 2020, 11:58 AM
martinvonz created D8597: rebase: use merge.graft() instead of merge.update().
May 29 2020, 11:58 AM
martinvonz created D8595: copies: make _chain() and _filter() public.
May 29 2020, 11:57 AM

May 26 2020

martinvonz committed rHGfd3b94f1712d: merge with stable.
merge with stable
May 26 2020, 12:18 PM

May 19 2020

martinvonz added a comment to D8552: fix: use context to fetch mergestate instead of loading it directly.

I think I'd prefer to leave code that doesn't use overlayworkingctx unchanged. I don't see any reason to get the merge state from the context if we know that the context is a regular workingctx.

I'd rather it was globally-consistent that if you need a mergestate, you load it via a context, so that more code will implicitly be right for in-memory operations.

May 19 2020, 4:39 PM
martinvonz added inline comments to D8567: mergestate: implement trivial in-memory mergestate.
May 19 2020, 3:20 AM
martinvonz added a comment to D8563: localrepo: get mergestate via context.

It looks like the latter two hunks in this file will need to be able to read the merge state from an overlayworkingctx. Maybe that's coming in a later patch, but I think it would be easier to follow if this code was changed only then (very much related to my comment on an earlier patch).

May 19 2020, 2:30 AM
martinvonz added a comment to D8552: fix: use context to fetch mergestate instead of loading it directly.

I think I'd prefer to leave code that doesn't use overlayworkingctx unchanged. I don't see any reason to get the merge state from the context if we know that the context is a regular workingctx.

May 19 2020, 2:23 AM
martinvonz added a comment to D8550: mergestate: split out merge state handling code from main merge module.

Also update the release notes to mention the API change?

May 19 2020, 2:17 AM

May 18 2020

martinvonz committed rHGf445a4f7e8a7: relnotes: copy "next" to "5.4" and clear "next".
relnotes: copy "next" to "5.4" and clear "next"
May 18 2020, 11:42 AM
martinvonz closed D8546: relnotes: copy "next" to "5.4" and clear "next".
May 18 2020, 11:42 AM
martinvonz created D8546: relnotes: copy "next" to "5.4" and clear "next".
May 18 2020, 11:33 AM

May 16 2020

martinvonz added inline comments to D8489: rebase: avoid clobbering wdir() with --dry-run or --confirm (issue6291).
May 16 2020, 2:05 AM

May 12 2020

D8522: fastexport: adjust output to be more canonical is now accepted and ready to land.

Thanks for the quick fix and the added test case!

May 12 2020, 6:07 PM
martinvonz committed rHGd2741ab1f8b7: tests: show poor error message for `hg cp -A --at-rev . non-existent dst`.
tests: show poor error message for `hg cp -A --at-rev . non-existent dst`
May 12 2020, 4:05 PM
martinvonz committed rHGc5574408254a: copy: give better error message when no source paths found with --at-rev.
copy: give better error message when no source paths found with --at-rev
May 12 2020, 4:05 PM
martinvonz committed rHG1cdc80280286: copy: to find copy source, walk parent of revision we're marking copies in.
copy: to find copy source, walk parent of revision we're marking copies in
May 12 2020, 4:05 PM
martinvonz committed rHGaf9970501021: tests: show that `hg cp -A --at-rev .` doesn't work for renames.
tests: show that `hg cp -A --at-rev .` doesn't work for renames
May 12 2020, 4:05 PM
martinvonz added inline comments to D8486: fastexport: adjust output to be more canonical.
May 12 2020, 1:08 PM