File contents in HEAD commit:
A
B
C
D
After I modify the file, the contents is:
A
A2
B
C
D
D2
If I would like to revert the change at line 2 (A2), how can I do this with magit? So the result would have the contents be:
A
B
C
D
D2
The term used by Magit is "discard". Like e.g. "stage" it is considered an "apply variant". k discards the "thing at point". If there is a region that begins inside a hunk and ends inside the same hunk, then it is a "hunk-internal region". If there is such a selection, then the various apply-variant commands operate on the region's content instead of the complete section.
This is documented in Staging and Unstaging and Applying. It is also covered in the Getting Started part of the manual. You might want to give the documentation a chance.
What you have to do, boils down to this: goto A2, type C-SPC followed by k.
Related
The interactive unison command line provides the following help:
Commands:
<ret> or f or <spc> follow unison's recommendation (if any)
n or j go to the next item
p or b or k go back to previous item
<del> or <bsp> revert then go back to previous item
0 go to the start of the list
9 go to the end of the list
5 go forward to the middle of the following items
6 go backward to the middle of the preceding items
R reverse the list of paths
d show differences (curr or match)
x show details (curr or match)
L list all (or matching) following changes tersely
l list all (or matching) following changes with details
A or * match all the following
1 match all the following that propagate from local to saunterblugget
2 match all the following that propagate from saunterblugget to local
C match all the following conflicts
P or = match all the following with only props changes
M match all the following merges
X or ! invert the matching condition
& and the last two matching conditions
| or the last two matching conditions
D or _ delete/pop the active matching condition
U or $ unmatch (select current)
r or u revert to unison's default recommendation (curr or match)
m merge the versions (curr or match)
> or . propagate from from local to saunterblugget (curr or match)
< or , propagate from from saunterblugget to local (curr or match)
] or " resolve conflicts in favor of the newer (curr or match)
[ or ' resolve conflicts in favor of the older (curr or match)
c resolve conflicts in favor of changed (curr or match)
i invert direction of propagation (curr or match)
/ or : skip (curr or match)
% skip all the following
- skip and discard for this session (curr or match)
+ skip and discard all the following
I ignore this path permanently
E permanently ignore files with this extension
N permanently ignore paths ending with this name
s stop reconciling and go to the proceed menu
g proceed immediately to propagating changes
q exit unison without propagating any changes
To me this implies that it is possible, on the command line, to instruct unison to find all files that match some condition and to perform an operation on them, such as skipping them or follow unison's recommendation.
The documentation for unison mentions that it is possible to provide a condition which match certain paths and do things like list all matching files first or last. The documentation does not discuss the manipulation of such conditions with commands like A, &, or |. Other sources of documentation like the wiki and the github project don't seem to provide help about this either.
My question is can someone explain how to use the command line "match" commands?
I'd also like to know things like:
Is the "match" in the command line documentation referring to the same "matching conditions" mentioned in the documentation? If not how does one produce a condition against which to match changes? How does one select matching conditions and manipulate them on the command line?
I think these work sort of how you’d expect, only there’s no obvious feedback that your actions are having any effect.
I think the key is the L command to list pending changes.
At the start L might show a long list of changes with question marks in it:
props <-?-> props foo.txt
props <-?-> props bar.txt
Now if I try to use the match things based on their help summaries, say to select all the files with only props changes and apply from the left, it looks like nothing has happened:
props <-?-> props [] P
Enabling matching condition
props <-?-> props [] >
props <-?-> props [] $
Disabling matching condition
but if I list the files again with L I can see that a bunch of question marks are gone, because the requested change has been set:
props ====> props foo.txt
props ====> props bar.txt
Then you can press g to apply your changes. The UI does seem very awkward to me though, maybe I’m missing something, but it seems to still prompt for all the files you’ve already told it how to handle. One plausible workflow: run unison with g after applying your match stuff—it’ll skip all the files with conflicts—then run unison again to only get prompted about the remaining files it wants help with.
I have a PR on Github that has changes to Files A, B, C, D, E, F and G in it. I want to remove the changes I've made to files B, C, D and E. Is there an easy way to do it without manually going in and removing the differences via file compare?
Ideally, I'd want some kind of checklist where I could tick the files I want to revert the changes back to what they were before I changed anything
You can use the undo commit action without auto-commit.
Then you can only commit the files you want to keep as modified from your previous commit
git revert <commit hash>
In the Magit Refs buffer, you can press tab on a branch (the branch I want to merge in) to see what commits would be added if this branch were merged into the currently checked out branch, and you can press enter on the commits to see their changes. Is there a way to see all those changes unified together?
I don't think the magit diff dwim feature is what I want, because it shows all the changes that are on the current branch but not on the branch I want to merge in. I usually don't care about seeing those changes, because I am mostly interested in what the branch I am merging will change, not everything else that changed.
You can see what a branch will add when merged by using merge preview m p. This can be used from the Magit Refs buffer by navigating point to the branch you want to preview a merge of and typing m p.
Yes, "diff dwim" doesn't really do what I mean here either. That should be improved, open a feature request please.
Meanwhile you can use d r and then type the range (at least with completion). Or you could use d d and then flip the revisions (D f) as well as switch the range style (D r). Together this changes feature..master to master...feature.
Often I need to do replacement with text. I am looking for a way to avoid repeatedly input replacement text.
For example, firstly, I replaced a with b in text;
Secondly, I replaced c with d.
Thirdly, I need to replace a with b again. However, Emacs only store last replacement as default argument.
What is the way to list previous replacement argument, i.e. a to b?
The responses you give to M-% (and other commands that get input from the minibuffer) are kept in the history. Hit the "Up" key to see them.
As the search texts and the replacement texts are kept in the same history, in your case above the history would be a, b, c, d. So, when prompted for the search text, you'd need to hit "Up" four times to come back to a. The history would then change to a, b, c, d, a, so to get back to b as replacement text you'd again need to hit "Up" four times.
You can use M-p instead of "Up" if you prefer.
If you want to see what the previous minibuffer values were without invoking another command you can directly inspect the minibuffer-history variable: C-h v minibuffer-history. This will list all of the values together with the description of this variable.
Let's say we have a base repository R and a fork F. Coders are still making changes in R and F needs to include these changes as they are being added.
How do I tell hg to update F with the latest changes in R without losing the work I am doing on F?
Using the diff tool is a heck of a time-consuming task and it is not helping me move forward.
I am using TortoiseHG.
Are you aware of merge? If you are and your issue is merge conflicts, then your diff tool is how you'll need to proceed.
The way to do this, assuming you are working locally on F and that the tip of F is your current working directory:
... commit all work in F ...
Pull new changesets from R
Right click the tip of the work in R and select "Merge with local"
fill in your commit message "merge in xyz from R"
... do more work in F...
That's it. If the changes in R and F don't overlap, you should be done and ready to move on. If work in R and F both modify the same parts of the same files, you'll need to use your diff tool to resolve those merge conflicts.