Re: [lmi] Proposed workflow for proprietary repository

[Vadim Zeitlin]

On Mon, 7 Mar 2016 20:03:09 +0000 Greg Chicares <address@hidden> wrote:

GC> Would you mind showing me how you'd do it?

 I'll need a bit more time to test it before sending it here but I wanted
to answer your questions already:

GC> I'm still trying to learn git, one command at a time, and I haven't
GC> really studied the commands that might be used here. I'm not even sure
GC> which to use:
GC>   git-revert (does it return us to the original sha1sum?)

 No, git-revert creates a new commit undoing the old one, i.e. it
(intentionally) keeps the fact of commit being applied and then reverted in
the repository history. It should be used when you want to revert a change
which is already public, i.e. had been pushed outside of the repository.

GC> or one of these--but I see many warnings that they're dangerous:
GC>   git-checkout (but we don't want to create a branch--we want one trunk)

 git-checkout is confusing because it can be used for many different
things, its "-b" option, for checking out a branch, is just one of its
modes, but it can also be used to undo the changes to the files in the
working directory by checking them out from some existing revision, usually
just HEAD. I.e. if you have done something to experiment in a local file
foo.cpp and want to completely undo and *lose* the changes, then you could
do "git checkout HEAD -- foo.cpp" which replaces the copy in the working
directory with the HEAD version. To make things even more confusing, "HEAD"
can be (and usually is) omitted because it's the default.

GC>   git-reset --hard (and then git-push)

 Yes, this is the command to use to really revert everything to the old
state. It's very dangerous because it's one of the few git commands which
can result in losing even the already committed data (although it can be
usually still recovered using reflog) as well as losing all the uncommitted
changes *without* asking for confirmation. You must always check that you
don't have any uncommitted changes you don't want to lose by running "git
status" before using this command.

 But in this case this is exactly what we need: we want to pretend that the
last commit never happened at all, so we need to run "git reset --hard
HEAD~" to make as if our branch had always been at this, previous, commit
and never moved from it.


 I don't know what is the moral of this story of 3 git commands for
reverting changes. Most people use this as an example proving how confusing
git is and maybe they're right, especially the use of "git checkout" for
reverting the uncommitted changes is hard to defend from the UI point of
view, even if it makes perfect sense from the point of view of how git
works. But maybe it's also worth noticing that many of the other VCS don't
have the possibility to do everything that git can do, e.g. subversion does
have a logically named "svn revert", but it only replaces revert such as it
is done by "git checkout" and there is no way to do what "git revert" does
which is quite useful too.

GC> I guess we'd want git-reset in this case: we want to reload our last saved
GC> game, as though we had never tried to "attack dragon with cursed spoon -9".

 Exactly.

 The script I have in mind would basically just:

1. Check that the working tree has no modifications.
2. Apply the patch.
3. Check the new SHA-1.
4. Do "git reset --hard HEAD~" if it doesn't match.

 Regards,
VZ