[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Set working copy to a specific SHA1

From: Vadim Zeitlin
Subject: Re: [lmi] Set working copy to a specific SHA1
Date: Thu, 13 Apr 2017 01:01:36 +0200

On Wed, 12 Apr 2017 13:27:24 +0000 Greg Chicares <address@hidden> wrote:

GC> Vadim--I think I've found a good solution to the problem below, but would
GC> you handle it differently?

 In short: I, personally, would, but I'm not sure my solution is really
better as it would result in entering the awkward "detached HEAD" state
which can be confusing.

GC> Kim maintains an lmi repository from which she prepares releases; she never
GC> commits from it. She wants to release code from five commits ago:
GC> git log --abbrev-commit --pretty=oneline
GC> ae5c2ad Satisfy library dependencies for native builds
GC> d90ded4 Do not use 'wine' to run native binaries
GC> bac897e Prefer getchar() to getch()
GC> fba8064 Install native toolchain in chroot
GC> 9c7870a Install full vim package in chroot and configure it
GC> 11ff9f0 Designate release candidate 20170411T2007Z
GC> I suggested doing this in a fully updated local repository:
GC> $git reset --hard 11ff9f0
GC> $HEAD is now at 11ff9f0 Designate release candidate 20170411T2007Z
GC> in order to prepare the release,

 This definitely works, but I'd advise doing "git status" just in case
there are any changes before erasing them and losing them irreversibly with
"git reset --hard". I understand that no changes are supposed to be done in
this working copy, but I just think always checking status before doing
"reset --hard" is a good instinct to have.

GC> and then later
GC> $git pull
GC> to resynchronize with HEAD of master.

 This also works, but requires another connection to the remote server
which is, in principle, unnecessary, and could be replaced with another
"git reset --hard origin/master" (assuming the standard remote and branch

 FWIW I would just do "git checkout 11ff9f0" and then "git checkout master"
to get back. This is less destructive but, again, I realize that ensuring
that there are no local changes (as is the case after "reset --hard") may
be a bonus rather than a problem in this situation.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]