| durin42 | |
| marmoute |
| hg-reviewers |
The simplest way I'm aware of to unmark a file as copied after
committing is this:
hg uncommit --keep <dest> hg forget <dest> hg add <dest> hg amend
This patch teaches hg copy --forget a -r argument to simplify that into:
hg copy --forget -r . <dest>
In addition to being simpler, it doesn't touch the working copy, so it
can easily be used even if the destination file has been modified in
the working copy.
I'll teach hg copy without --forget to work with -r next.
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
I'm conflicted on rolling the uncopy && amend action into the uncopy command like this. Could users not (without this patch) do hg uncopy foo && hg amend?
Oh. Ew.
I'm really not sure how I feel about that, but it does feel like this change is probably the best path forward.
I'm out of time to review today (need to go make supper), but I'm at least +0 on this patch...
I've started to think that the working copy should really be a commit and I find that helpful. If you think about it that way, it makes sense that hg uncopy foo (or more explicitly hg uncopy -r 'wdir()' foo unmarks copies in the working copy and hg uncopy -r <some other commit> foo unmarks copies in some other commit.
I don't feel very good with this because this makes hg uncopy a history editing command. Something like hg uncopy --after which makes the changes in wdir which can be committed afterwards sounds best, but I am not sure if that's possible.
That's a good thing in my opinion :)
Something like hg uncopy --after which makes the changes in wdir which can be committed afterwards sounds best, but I am not sure if that's possible.
Yeah, not really possible (Augie had the same comment on one of these patches).
Something like hg uncopy --after which makes the changes in wdir which can be committed afterwards sounds best, but I am not sure if that's possible.
Yeah, not really possible (Augie had the same comment on one of these patches).
Can we update the dirstate to represent such copy related information ? (both for adding or removing a copy).
Something that really bother me with this kind of command rewriting history is that it can result in an absurd amount of rewrite.
The usual way to change something in mercurial is:
If command like hg copy start rewriting history, each smallest atomic operation result rewriting one (or multiple) changesets. This is a slippery slope I would rather not walk on.
I think we should explore being able to record this in dirstate and use regular amend to record the change.
| mercurial/cmdutil.py | ||
|---|---|---|
| 1765 | Why can we do it for merge commit ? | |
| 1766 | I prefer this kind of shortcut to be exceptional. Maybe this need to move out of cmdutil ? | |
| 1769 | bonus point for using precheck ☺ | |
I completely disagree :P I think it's a good thing to allow it to work on other commits. Of course it's better if the user thinks of it before they commit, but when they don't, we should still make it as easy as possible.
| mercurial/cmdutil.py | ||
|---|---|---|
| 1765 | Because I didn't feel like implementing support for it yet. Can be done in a follow-up, IMO. | |
| 1766 | I agree (of course). There are already several cases in this file. I thought about the cycle for a few minutes and it wasn't clear how it should be broken. How do you suggest we resolve the cycle? | |
| 1769 | Thanks :) | |
I had a longer discussion with @martinvonz on IRC on about this feature, he also pointed out to D7631 doing similar work for hg absorb.
From that discussion I understand there is a wider objective for many mercurial commands to gain the ability to use a specific revision in place of the working copy. (eg: hg amend, hg aborb, hg copy, etc…)
The idea is quite interresting and can unlock powerfull capabilities. However, this is a rather big UX project, I think we need a step back and think about this idea on a large scale. I am thinking at least a Plan page with a wider study of the command that could be impacted how the UI will be consistent. This allows a wider set of the community to chim in on such a big project.
A concret issue I current have with the plan is the planned --rev flag usage. To me, and other people around me, something like hg amend --rev X would means "amend change from the working copy into revision X". likewise hg absorb --rev REVSET would absorb the working copy change into the REVSET set of revisions. So the use of --rev is surprising to some and should be discussed. Maybe the --change flag (used, but hg status and hg diff) would be more suitable? Maybe a global flag --change-as-wdir that would work for any commands ?
This is the kind of question I would like to see discussed more widely before we invest more in this idea (Idea, that I find interresting overall). I added this as a topic for the upcoming sprint.
(Sorry for the delay this will involves, I wish the idea had explicitly surfaced earlier).
I'm fine with marking the use of -r experimental. I don't like the idea of delaying this feature two months. Any problem with marking it experimental for now? As usual with experimental features, that will allow us to rename the flag (and change other behavior) before we take it out of experimental.
I believe we need wider discussion about this before going further, this is an interresting change but we cannot rush it. This not necessarly result in a to a 1.5 month delay if a proper community discussion happens before that. Can you create and fill a Plan page and start a community discussion around this?
I'm fine with marking the use of -r experimental. I don't like the idea of delaying this feature two months. Any problem with marking it experimental for now? As usual with experimental features, that will allow us to rename the flag (and change other behavior) before we take it out of experimental.
Aside from (obviously) @marmoute, both Jordi and I had an instant reaction of "what?" when we learned what --rev meant.
I think that this goes against the intuition of at least a few people that are very accustomed to hg. While being able to operate on any particular rev could be a good - even great - idea in general, I am very uneasy about using --rev to qualify that target. I don't know if --target-rev is an option, but something similar would be much clearer that an already *extremely* common flag. This would shift the semantics of --rev in some commands and not in others.
I'm fine with --target-rev if that's what people prefer. I find it a bit weird to not use --rev` but that may just be because I'm been thinking of the working copy as a commit for longer than most.
Actually, after thinking more about it, I'd like to keep --rev (still experimental) as the name. We already have hg files, hg grep, and hg parents, which have the same behavior as the --rev I'm using here (i.e. default to the working copy but allow the user to choose a commit to work on instead).
Why can we do it for merge commit ?