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.
Related
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>
I am currently working in GitHub and I am struggling to squash commits together that I made a few days ago. Please bear in mind I'm 15 and don't have the largest range of knowledge in this area. I would really appreciate the help.
Thank you in advance!
Let's say you want to squash together your three most recent commits. Start with the command:
git rebase -i HEAD~3
How this breaks down:
git rebase - You want to edit the current branch's commit history
-i - You want to do this interactively via your favourite command-line text editor
HEAD~3 - You want to start at your most recent commit (HEAD) and incorporate the three commits stemming back from HEAD.
You'll be presented with a text file like so:
pick 543600b3e Some code added
pick e0b77fac3 Some other stuff
pick a97899876 My most recent commit
Your most recent commit will be at the bottom. To squash these commits down, replace the word pick with either of these two words:
squash or s - Squash the commit, keeping the contents of the commit message
fixup or f - Squash the commit, but get rid of the commit message
You'll normally want to keep the top line as pick. After you've made your changes, save and exit (usually ctrl + x then y if you're using Nano) and your commits will be squashed down.
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.
I did commit with merge, after that I did backout in main branch in order to revert last merge.
After some time I need to merge branch, but mercurial says that abort: merging with a working directory ancestor has no effect
But in develop branch I don't see my changes from other branch.
Merge only picks up things that are new since the last merge. For instance:
default: *------------?
\ /
develop: o--o--o--o
Each o represents some commit. We started with the default branch (named default) with just one commit, the one marked * instead of o here. Then we made a develop branch starting with that same first commit, and did some work.
Once the work was ready, we went back to the default branch and used hg merge. This proposed making a new commit, ?. It did so by looking back to *—the commit that we had in common between default and develop—and looking at what we did on the two branches, and combining them.
We did nothing on default, so the combining was easy. Mercurial was able to just take everything we did on develop and put it all into default. Let's fill in the merge as a real commit now:
default: o------------*
\ /
develop: o--o--o--o
Notice that I've moved the *. It's now the new merge. This is the most recent commit that links the two branches.
Meanwhile, hg backout makes a new commit that undoes a previous commit. Specifically you're asking to back out the merge. Let's draw that:
default: o------------*--u
\ /
develop: o--o--o--o
This new commit is sort of like the antimatter version of the merge, in terms of changes made anyway. Everything in default goes back to the way it was before the merge. So I used the letter u (for "undo") instead of the usual round o dot for a more typical commit.
Where's the latest common commit on the two branches, though? The answer should be obvious: it's still *.
Now you ask Mercurial to merge again. It finds the changes in develop since the merge—and there aren't any. There is no new work to merge!
Suppose we check out develop again and make some new commits:
default: o------------*--u
\ /
develop: o--o--o--o------o--o
Now we can hg merge develop into default again, to pick up the changes from the two new commits. But the changes you undid, with commit u (the backout commit), are still un-done. We'll only pick up the changes from the new (since the merge) commits on develop, and we keep the changes made (since the merge) on default, which is to say, the u undo changes:
default: o------------o--u------*
\ / /
develop: o--o--o--o------o--o
If you want all those changes back, you can simple back out the backout. That is, any time before or after adding the new commits on develop, and even before or after merging those new commits, you can undo the undo. Let's turn the u upside down into a "redo" and see how that looks, if we insert it before the next merge:
default: o------------o--u--n-----*
\ / /
develop: o--o--o--o--------o--o
In other words, commit u (the hg backout) un-did the changes from the merge. It does not, and cannot, actually make the merge not happen. So to re-obtain the changes from the merge, you have to undo the undo, which is our n here.
With git I can see the differences in a file relative to any other past commit as:
git diff commit file_name
This shows me the differences in file_name between the version in commit against my current unstaged changes.
With Magit I can choose a given commit with . in the log and compare it with another commit with =. However I do not see my unstaged changes in the log so how can I select them to make the comparison?
Thank you in advance.
When in the main magit view (which you get after calling magit-status), you can press d to get a menu of all diff commands. Then press r (range) to diff against a specific commit (which is prompted in the minibuffer).
If you want the exact equivalent to your git command line and limit the diff to a specific file, then press =f before r (as always with magit, the "popup" is self-explanatory).
The complete sequence to get an equivalent of git diff commit file_name is thus :
d
=ffile_nameRET
rcommitRET