Related
I have spent a long time reading and trying to figure out git commit --amend, but I still do not understand how the # are used in the editmsg.
I am worried to edit this without knowing what I am doing because I have read that git commit --amend only does the most recent commit,and once I save and exit , it will be counted as a new commit.
I have accidentally committed and pushed (but the push failed) some large files. But I have also written scripts that were supposed to be pushed from the same commit as the large files.
I am trying to delete the lines with the large files in the new commit , but I don't understand how to do this.
This is my commit file below, but I don't understadn if I should delete the lines with the # (I tried this but it didn't work , and the git log is the same ):
the commit message of the one I want to change is here but I don't want to just change the message, I want to delete the large files in the commit so that the push works.
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Date: Thu Feb 8 18:30:32 2018 -0900
#
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
# (use "git push" to publish your local commits)
#
# Changes to be committed:
# new file: script.py
# new file: super_large_file.npy <--- I deleted this line but it appeared again, it is becuase deleting a line with # is ignored? Do I just rewrite the stuff after the # lines?
My question is , why does deleting the line of the large file (including the # ) not work and the commit remains still wanting to push the large file?
Should I just rewrite the commit file without the # ? But I also read that git takes away the # , so I am confused
First, those are comments: removing a line starting with # has no effect in your git repository content.
They include hints and the list of files included with the commit.
I would recommend, in order to actually remove that file from your repo history, to use the new git filter-repo which replaces BFG and git filter-branch.
Note: if you get the following error message when running the above-mentioned commands:
Error: need a version of `git` whose `diff-tree` command has the `--combined-all-paths` option`
it means you have to update git.
First: do that one copy of your local repo (a new clone)
See "Path based filtering":
git filter-repo --path file-to-remove --invert-paths
At the end, you can (if you are the only one working on that repository) do a git push --force
Second, the hints displayed in a commit messages are changing with with Git 2.25.1 (Feb. 2020): "git commit" gives output similar to "git status" when there is nothing to commit, but without honoring the advise.statusHints configuration variable, which has been corrected.
See discussion.
See commit 5c4f55f (17 Dec 2019) by Heba Waly (HebaWaly).
(Merged by Junio C Hamano -- gitster -- in commit 9403e5d, 22 Jan 2020)
commit: honor advice.statusHints when rejecting an empty commit
Signed-off-by: Heba Waly
In ea9882bfc4 (commit: disable status hints when writing to COMMIT_EDITMSG, 2013-09-12) the intent was to disable status hints when writing to COMMIT_EDITMSG, because giving the hints in the "git status" like output in the commit message template are too late to be useful (they say things like "'git add' to stage", but that is only possible after aborting the current "git commit" session).
But there is one case that the hints can be useful: When the current attempt to commit is rejected because no change is recorded in the index.
The message is given and "git commit" errors out, so the hints can immediately be followed by the user.
Teach the codepath to honor the configuration variable.
The hint (now visible in the commit message editor) will be:
no changes added to commit (use "git add" and/or "git commit -a")
I tried a different way than amending the commit , and removed the file completely from my local and github repositories. I am not sure how to keep it in my local repository still, but I don't know if this is necessary because I don't really understand the difference between my local repository and the local drive .
https://help.github.com/articles/removing-files-from-a-repository-s-history/
(I found this link from Bluemoon93's answer on Can't push to GitHub because of large file which I already deleted )
It is a very simple and stupid question,
I am working on 2 tasks and modified 2 sets of files in the code.
Now when I type 'hg ci', it checks in all the files. Can I remove certain files from the checkin i.e. do checking for only one task?
If I remove the files in the 'check in message' will they be removed from the checkin
Thanks for all the answers
This seems like a big flaw, My use case is very simple and general. Most of the time dev are working on various tasks , some are ready , some are not, bug fixes etc.
Now the only simple solution seems to be multiple local repos or clones
Use hg ci <files>... to commit only certain files in your working directory.
If you want to pick file by file you can use the record command. It ships with mercurial, but you have to turn it on if you want to use it by putting: record= in the [extensions] section of your ~/.hgrc.
It goes hunk by hunk, but you can answer for a whole file:
y - record this change
n - skip this change
s - skip remaining changes to this file
f - record remaining changes to this file
d - done, skip remaining changes and files
a - record all changes to all remaining files
q - quit, recording no changes
? - display help
I'll point out that if you're committing some files but not others it's certain that you've not run your test suite on the one change without the other, but maybe that doesn't apply in your case.
This isn't possible with mercurial out of the box. As have been suggested there are several ways of selecting what files you want to commit. To get this function via the commit message template, you would need an extension or a shell script wrapping the commit command. Here's one way to do that:
[alias]
ci = ! hg-partial-commit
hg-partial-commit:
#!/bin/sh
# partial commit
edit=$(mktemp ${TMPDIR:-/tmp}/$(basename $0).XXXXXXXXXXXX)
filelist=$(mktemp ${TMPDIR:-/tmp}/$(basename $0).XXXXXXXXXXXX)
logmessage=$(mktemp ${TMPDIR:-/tmp}/$(basename $0).XXXXXXXXXXXX)
cleanup="rm -f '$edit' '$filelist' '$logmessage'"
trap "$cleanup" 0 1 2 3 15
(
echo user: $(hg debugconfig ui.username)
echo branch: $(hg branch)
hg parents --template 'parent: {rev}:{node|short} {author} {date|isodate}\n'
echo
echo 'Enter commit message. Select files to commit by deleting lines:'
hg status 'set:not unknown()' | sed -e 's/^/#/'
) | sed -e 's/^/HG: /' >"$edit"
${VISUAL:-${EDITOR:-vi}} "$edit"
egrep -v '^HG:' "$edit" >"$logmessage"
egrep '^HG: #' "$edit" | cut -c8- >"$filelist"
hg commit -l "$logmessage" "listfile:$filelist"
$cleanup
The real problem here is the fact that you're doing changes related to different tasks jumbled together. Mercurial has a few ways you can keep things separate.
Task Branches
Suppose you've been working on a task and you've checked in a few times since you last pulled, but things aren't ready to share yet.
o----o----B----o----o----o
Here, B is the revision where you started your changes. What we do is (after making sure our current changes are checked in):
> hg update -r B
<do our work on the other task>
> hg commit
We've now created a new branch with the changes for this task separated from the changes for our original task.
o----o----B----o----o----o
\
----o
We can do this for as many different tasks as we want. The only problem is that sometimes remembering which branch is which can be awkward. This is where features like bookmarks come in useful. A bookmark is a tag which moves forward as commits are made so that it always points at the head of a branch.
Mercurial Queues
MQ adds the ability to work on changes incrementally and move between them by pushing and poping then off a stack (or "Queue" I guess). So if I had a set of uncommitted changes that I needed to split up I'd:
> hg qrecord taska
> hg qrecord taskb
> hg qrecord taskc
I'd use the record extension (or more likely the crecord extension) to select which parts of files I want to select.
If I needed to go back to taska and make some changes:
> hg qpop; hg qpop # pop two off the queue to go back to task a
<Do changes>
> hg qrefresh # update task a with the new changes
When I want to turn the queue into normal changesets:
> hg qpush or hg qpop # get the changes I want converted onto the queue
> hg qfinish -a # converts mq changes to normal changesets
There's other methods too, but that will do for now.
You will unavoidably have to either specify the files that you want to add or the files you want to leave out. If you have a lot of files, as you indicate above, the following steps will simplify the procedure (I'm assuming a UNIX-ish system here, Windows would be slightly different).
First, generate a list of changed files:
hg status -mard -n >/tmp/changedlist.txt
The -mard options will list all files that were modified, added, removed, or delated. The -n option will list them without the status prefix so that all you have is a raw list of files.
Second, edit /tmp/changedlist.txt with your favorite text editor so that it contains only the files you wish to commit.
Third, commit these files:
hg commit `cat /tmp/changedlist.txt`
You will be able to review the files to be committed before actually performing the commit.
Alternatively, you can add more files to a commit incrementally by using
`hg commit --amend file...`
Here, hg commit --amend will not create a new commit, but add the new files to the existing commit. So, you start out with committing just a couple of files, then incrementally adding more until you are done. This still requires you to type all of them in.
For yet another alternative, you can use Mercurial Queues to split a commit in more sophisticated ways, but that's a bit more of an advanced topic.
I am aware of Mercurial for Beginners: The Definitive Practical Guide and answers like Mercurial merge branches? (abort: push creates new remote branches)
Here I've inadvertently created a situation where Mercurial wants to create a new remote head. What's the best way to undo this, and leave little or no trace of this mistake on the remote side?
###> hg push
pushing to http://example.com
searching for changes
abort: push creates new remote heads on branch 'default'!
(did you forget to merge? use push -f to force)
###> hg revert --all -r tip
###> hg update -C
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
###> hg incoming
comparing with http://example.com
searching for changes
no changes found
###> hg summary
parent: 488:e3db024fe901 tip
Misc.
branch: default
commit: (clean)
update: 6 new changesets, 2 branch heads (merge)
###> hg pull
pulling from http://example.com
searching for changes
no changes found
###> hg glog
# changeset: 488:e3db024fe901
| tag: tip
| summary: Misc.
|
o changeset: 487:b207579b9d41
| parent: 480:ce775708800c
| summary: Misc.
|
| o changeset: 486:59a7a5b34c7f
| | user: other
| | summary: fixes
| |
| o changeset: 485:b28264333e18
| | user: other
| | summary: binary
If I merge, it sort of seems OK:
hg merge
abort: outstanding uncommitted merges
But hg diff shows all sorts of changes I did not make. I'm willing to re-apply my changes... how can I bring this all back to a single tip, abandoning all local changes?
It looks like when you've done an hg merge, you haven't committed the resulting changeset.
When you merge in another branch (in your case you may need to specify hg merge 486 to merge in the other users changes), it merges that branch into your working directory. You then need to check that all conflicts are resolved (if there are any) by using a merge tool, or manually editing the files (and then running hg resolve on any conflicts). Once this is done you need to hg commit your new, merged changeset.
This would explain why hg diff gives you lots of changes you didn't make -- they're changes made on the other branch, that you have yet to commit. If you run hg summary or hg parents in your working directory, you should see two parents listed: 486 and 488. You should hg commit this working directory, creating a new merged 489.
If you want to undo the current merge and start again, you're correct in trying to run hg update -C, which will set your working directory back to its original (unmerged) state.
If you want to get rid of your changes (487 and 488 - you state you don't mind re-applying your changes), the easiest option without resorting to extensions is simply to re-clone the repository and continue your work from there.
To get rid of changes (ex 487 and 488):
If you feel (as I do) that re-cloning the repository, as recommended above and even officially recommended here is ridiculous, then you should get MqExtension
Once Mq is enabled, you can easily remove changes you don't want:
hg strip 487
hg strip 488
I did not do merge, but suddenly I am viewing the message the op has posted. When I do a hg pull, in the command line it shows abort !repository default not found.
If i'm working on some files that I don't want to commit, I just save them. I then have other files I want to push to the server, however if someone else has made changes to the repository, and I pull them down, it asks me to merge or rebase.. but either of these options will cause me to lose my local changes that I have not committed.
What are other people doing to get around this? I find the documentation for the shelving extension hard to get my head around.
Note: I'm using Mercurial Eclipse to push and pull files to/from the server.
Any explanation of this would be greatly appreciated! Thanks!
Example:
I'm working on my website in Mercurial Eclipse. I have a new folder and new files that I don't want to commit to the server just yet. I've also modified some existing files and I don't want to make those changes live just yet.
Then something on my website breaks and I need to fix it, it won't let me fix it without rebasing or merging with the most recent tip of the repo and this will cause me to lose all my uncommitted changes.
What should I do with my new folder and files i've edited if I don't want to lose it? Re-cloning seems tedious. Copying the files to a new folder seems tedious as well. I'm sure Shelving or MQ will do what I want, I just don't know how to go about it yet.
With reference to your example situation, here's what I would do (following Ry4an's strategy to just commit the things you're currently working on, but don't want to publish already):
Supposed you start working in a repository like this one:
$ hg status -A
C f1
C f2
$ hg glog
# changeset: 1:7f3c6c86a92f
| tag: tip
| summary: add f2
|
o changeset: 0:03ca1e6d5b86
summary: initial
That is there are 2 files and 2 commits/changesets. You do some work, let's say add a new feature, and then your working copy might look like this:
$ hg status
M f2
? f3
? f4
There are 2 new and 1 modified file. Now you have to fix a bug for which you also need any new changes in a remote repository. Snapshot your current work by committing it and pull the remote changes (in which order you do that does not matter, a pull by default does not touch the state of your working copy):
$ hg commit -A -m "snapshot feature work"
$ hg pull
This may result in a history like this:
o changeset: 3:2284ba62de07 <-- just pulled in
| tag: tip
| parent: 1:7f3c6c86a92f
| summary: edit f1
|
| # changeset: 2:4a19d371a04f <-- your interrupted work
|/ summary: snapshot feature work
|
o changeset: 1:7f3c6c86a92f
| summary: add f2
|
o changeset: 0:03ca1e6d5b86
summary: initial
Now you can update-to/checkout revision 3 and start fixing bugs:
$ hg update 3
.. fix the bug ..
$ hg commit -m "fix a bug"
$ hg glog --limit 3
# changeset: 4:5d3d947fb4af
| tag: tip
| summary: fix a bug
|
o changeset: 3:2284ba62de07
| parent: 1:7f3c6c86a92f
| summary: edit f1
|
| o changeset: 2:4a19d371a04f
|/ summary: snapshot feature work
:
Looks good, let's push your fix, i.e. make it live, while don't publishing your intermediate work:
$ hg push -r 4
This pushes all changes leading to revision 4, your bugfix, but no other branches in your local repository. You could also use -r ., which refers to the parent revision of your working copy, i.e. the revision you just committed.
Finally you can go back to your feature work and continue your work:
$ hg update 2
.. work, commit, work, commit ..
.. finally merge with the other branch, e.g. revision 4
These steps are on the command line, but I think it's not to hard to adapt the general concept to corresponding clicks in the Eclipse Mercurial plugin.
Some extra notes:
You may want to bookmark your snapshot commit, so you don't need to work with revision IDs or numbers.
If you want to publish your feature work in a single commit later, use the collapse extension once you're done.
I'm sure someone will help you find a bad workaround, but the best route is to change you goals -- just commit. Code that hasn't been committed hasn't been written. If you positively can't abide having frequent commits in your history use Mercurial Queues with a queue repository and commit that. You can then pop the changesets, push/pull/merge, and the push them back on, and all you valuable work will be committed in the patch queue.
This question already has answers here:
Mercurial: how to amend the last commit?
(8 answers)
Closed 5 years ago.
I am currently using TortoiseHg (Mercurial) and accidentally committed an incorrect commit message. How do I go about editing this commit message in the repository?
Update: Mercurial has added --amend which should be the preferred option now.
You can rollback the last commit (but only the last one) with hg rollback and then reapply it.
Important: this permanently removes the latest commit (or pull). So if you've done a hg update that commit is no longer in your working directory then it's gone forever. So make a copy first.
Other than that, you cannot change the repository's history (including commit messages), because everything in there is check-summed. The only thing you could do is prune the history after a given changeset, and then recreate it accordingly.
None of this will work if you have already published your changes (unless you can get hold of all copies), and you also cannot "rewrite history" that include GPG-signed commits (by other people).
Well, I used to do this way:
Imagine, you have 500 commits, and your erroneous commit message is in r.498.
hg qimport -r 498:tip
hg qpop -a
joe .hg/patches/498.diff
(change the comment, after the mercurial header)
hg qpush -a
hg qdelete -r qbase:qtip
Good news: hg 2.2 just added git like --amend option.
and in tortoiseHg, you can use "Amend current revision" by select black arrow on the right of commit button
I know this is an old post and you marked the question as answered. I was looking for the same thing recently and I found the histedit extension very useful. The process is explained here:
http://knowledgestockpile.blogspot.com/2010/12/changing-commit-message-of-revision-in.html
Last operation was the commit in question
To change the commit message of the last commit when the last mercurial operation was a commit you can use
$ hg rollback
to roll back the last commit and re-commit it with the new message:
$ hg ci -m 'new message'
But be careful because the rollback command also rolls back following operations:
import
pull
push (with this repository as the destination)
unbundle
(see hg help rollback)
Thus, if you are not sure if the last mercurial command was a hg ci, don't use hg rollback.
Change any other commit message
You can use the mq extension, which is distributed with Mercurial, to change the commit message of any commit.
This approach is only useful when there aren't already cloned repositories in the public that contain the changeset you want to rename because doing so alters the changeset hash of it and all following changesets.
That means that you have to be able to remove all existing clones that include the changeset you want to rename, or else pushing/pulling between them wouldn't work.
To use the mq extension you have to explicitly enable it, e.g. under UNIX check your ~/.hgrc, which should contain following lines:
[extensions]
mq=
Say that you want to change revision X - first qimport imports revisions X and following. Now they are registered as a stack of applied patches. Popping (qpop) the complete stack except X makes X available for changes via qrefresh. After the commit message is changed you have to push all patches again (qpop) to re-apply them, i.e. to recreate the following revisions. The stack of patches isn't needed any, thus it can be removed via qfinish.
Following demo script shows all operations in action. In the example the commit message of third changeset is renamed.
# test.sh
cd $(dirname $0)
set -x -e -u
echo INFO: Delete old stuff
rm -rf .hg `seq 5`
echo INFO: Setup repository with 5 revisions
hg init
echo '[ui]' > .hg/hgrc
echo 'username=Joe User <juser#example.org>' >> .hg/hgrc
echo 'style = compact' >> .hg/hgrc
echo '[extensions]' >> .hg/hgrc
echo 'mq=' >> .hg/hgrc
for i in `seq 5`; do
touch $i && hg add $i && hg ci -m "changeset message $i" $i
done
hg log
echo INFO: Need to rename the commit message on the 3rd revision
echo INFO: Displays all patches
hg qseries
echo INFO: Import all revisions including the 3rd to the last one as patches
hg qimport -r $(hg identify -n -r 'children(2)'):tip
hg qseries
echo INFO: Pop patches
hg qpop -a
hg qseries
hg log
hg parent
hg commit --amend -m 'CHANGED MESSAGE'
hg log
echo INFO: Push all remaining patches
hg qpush -a
hg log
hg qseries
echo INFO: Remove all patches
hg qfinish -a
hg qseries && hg log && hg parent
Copy it to an empty directory an execute it e.g. via:
$ bash test.sh 2>&1 | tee log
The output should include the original changeset message:
+ hg log
[..]
2 53bc13f21b04 2011-08-31 17:26 +0200 juser
changeset message 3
And the rename operation the changed message:
+ hg log
[..]
2 3ff8a832d057 2011-08-31 17:26 +0200 juser
CHANGED MESSAGE
(Tested with Mercurial 4.5.2)
In TortoiseHg, right-click on the revision you want to modify. Choose Modify History->Import MQ. That will convert all the revisions up to and including the selected revision from Mercurial changesets into Mercurial Queue patches. Select the Patch you want to modify the message for, and it should automatically change the screen to the MQ editor. Edit the message which is in the middle of the screen, then click QRefresh. Finally, right click on the patch and choose Modify History->Finish Patch, which will convert it from a patch back into a change set.
Oh, this assumes that MQ is an active extension for TortoiseHG on this repository. If not, you should be able to click File->Settings, click Extensions, and click the mq checkbox. It should warn you that you have to close TortoiseHg before the extension is active, so close and reopen.
EDIT: As pointed out by users, don't use MQ, use commit --amend. This answer is mostly of historic interest now.
As others have mentioned the MQ extension is much more suited for this task, and you don't run the risk of destroying your work. To do this:
Enable the MQ extension, by adding something like this to your hgrc:
[extensions]
mq =
Update to the changeset you want to edit, typically tip:
hg up $rev
Import the current changeset into the queue:
hg qimport -r .
Refresh the patch, and edit the commit message:
hg qrefresh -e
Finish all applied patches (one, in this case) and store them as regular changesets:
hg qfinish -a
I'm not familiar with TortoiseHg, but the commands should be similar to those above. I also believe it's worth mentioning that editing history is risky; you should only do it if you're absolutely certain that the changeset hasn't been pushed to or pulled from anywhere else.
Rollback-and-reapply is realy simple solution, but it can help only with the last commit. Mercurial Queues is much more powerful thing (note that you need to enable Mercurial Queues Extension in order to use "hg q*" commands).
I did it this way. Firstly, don't push your changes or you are out of luck. Grab and install the collapse extension. Commit another dummy changeset. Then use collapse to combine the previous two changesets into one. It will prompt you for a new commit message, giving you the messages that you already have as a starting point. You have effectively changed your original commit message.
One hack i use if the revision i want to edit is not so old:
Let's say you're at rev 500 and you want to edit 497.
hg export -o rev497 497
hg export -o rev498 498
hg export -o rev499 499
hg export -o rev500 500
Edit rev497 file and change the message. (It's after first lines preceded by "#")
hg import rev497
hg import rev498
hg import rev499
hg import rev500
There is another approach with the MQ extension and the debug commands. This is a general way to modify history without losing data. Let me assume the same situation as Antonio.
// set current tip to rev 497
hg debugsetparents 497
hg debugrebuildstate
// hg add/remove if needed
hg commit
hg strip [-n] 498
A little gem in the discussion above - thanks to #Codest and #Kevin Pullin.
In TortoiseHg, there's a dropdown option adjacent to the commit button. Selecting "Amend current revision" brings back the comment and the list of files. SO useful.