Ah. Runaway script.
Doubt the “incompetency” bit. Perhaps less practiced in certain areas. I see no reason to revert; it’s harmless commentary changes, but for the terminally curious:
Starting with a clean, current repository with the local master
branch up to date with its remote:
git revert --no-commit 77ce6b37
leaves the remote unaltered but changes your local master branch. The staging area becomes populated with altered files: those touched by commit 77ce6b37
, but the changes introduced by 77ce6b37
have been removed (reverted) from those files.
Now, if you do nothing else but git commit…
the reverted files become the objects of a new commit. Of course, you are at liberty to further alter your local master branch files before committing.
Omit option --no-commit
and you do not have that liberty, you will immediately commence a commit session with the reverted files (sans changes introduced by 77ce6b37
) being the objects of the new commit.
Whenever I embark upon something remotely dubious (which is nearly every time I do something), I start out creating a new branch:
$ git branch dubious # If `dubious` is not a branch, `git` creates it
$ git switch dubious
Switched to branch 'dubious'
$
From there, all my commits go to branch dubious.
If, from time to time, I want to list changes divergent from master
:
git diff master
gives a Unix-like diff -u
of all the differences between what I’ve done on dubious
and the versions on branch master.
When I’ve convinced myself that every change on dubious
is sane, I:
git switch master
git merge dubious
to migrate changes on dubious
back to master
. Branch dubious
remains extant. This triggers a commit session which will get its own comment and commit hash. When, after testing on master, I’m really convinced that the changes are sane, I commit to the remote repository.
This is, of course, a double-commit strategy. It takes longer. But the additional branch-to-branch commit furnishes ample opportunities to catch errors locally. What is more, you have plenty of ways to diff between dubious
and master
to get fine-grained indications of what you are changing and when those changes have been committed. Finally, if it turns out that dubious
is nothing but a total mess, you can:
git switch master
git branch -D dubious
and master
is clean — so long as you hadn’t merged dubious
into master
at any previous commit. In that case, git revert
on any (or all) of the merge commits is your friend.
Hope this helps.
EDIT: I neglected to mention that git revert…
is best done as soon as possible, before subsequent commits pile on. Try this after other commits have accumulated and git will declare a CONFLICT (content):
and expect you to manually resolve all the conflicts arising from subsequent commits. Painful. Tedious. git revert --abort
cancels the revert operation and gets you back to a safe place.
I should be working on G’MIC tutorials, no (yes, you should)?