pulkit added inline comments.
INLINE COMMENTS
> martinvonz wrote in uncommit.py:140
> Doesn't that mean the whole patch is unnecessary? It pretty much just
> provides an easier way of saying `--config
> experimental.uncommitondirtywdir=yes`, doesn't it?
Nice point. I had to revisit the bug to
navaneeth.suresh added inline comments.
INLINE COMMENTS
> martinvonz wrote in uncommit.py:140
> Doesn't that mean the whole patch is unnecessary? It pretty much just
> provides an easier way of saying `--config
> experimental.uncommitondirtywdir=yes`, doesn't it?
I tried with `--allow-dirty-wo
martinvonz added inline comments.
INLINE COMMENTS
> pulkit wrote in uncommit.py:140
> we have a config for that already, let's prevent to introduce flags for
> config options and vice versa here.
Doesn't that mean the whole patch is unnecessary? It pretty much just provides
an easier way of sa
pulkit added inline comments.
INLINE COMMENTS
> martinvonz wrote in uncommit.py:140
> Could you rename --force to e.g. --allow-dirty-working-copy so it's clearer
> what's being allowed?
we have a config for that already, let's prevent to introduce flags for config
options and vice versa here.
pulkit added a comment.
Your current patch is doing more than one thing. Let's split this up and make
one patch do one thing.
INLINE COMMENTS
> uncommit.py:168
>
> +if old.p2():
> +raise error.Abort(_("outstanding uncommitted merge"))
this merits a different patch and
navaneeth.suresh updated this revision to Diff 14100.
navaneeth.suresh edited the summary of this revision.
navaneeth.suresh retitled this revision from "uncommit: add -f/--force when
possibly hiding data (issue5977)" to "uncommit: add --allowdirtywcopy when
possibly hiding data (issue5977)".
RE