Re: [lmi] Did I resolve this git issue correctly?

[Greg Chicares]

On 2016-12-07 14:09, Vadim Zeitlin wrote:
> On Wed, 7 Dec 2016 10:23:49 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Vadim--I didn't notice that you had pushed this changeset:
> GC>   http://lists.nongnu.org/archive/html/lmi-commits/2016-12/msg00008.html
> GC> so of course I hadn't pulled it before committing some changes of my own;
> GC> when I pushed them, I saw:

I just did it again.

/opt/lmi/src/lmi[0]$git push
[REDACTED VALIDATION OF CREDENTIALS]
To git.sv.gnu.org:/srv/git/lmi.git
 ! [rejected]            master -> master (fetch first)
error: failed to push some refs to 'address@hidden:/srv/git/lmi.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Not remembering this prior discussion, I did:

/opt/lmi/src/lmi[1]$git pull
[REDACTED VALIDATION OF CREDENTIALS]
remote: Counting objects: 20, done.
remote: Compressing objects: 100% (9/9), done.
remote: Total 10 (delta 7), reused 1 (delta 1)
Unpacking objects: 100% (10/10), done.
>From git.sv.gnu.org:/srv/git/lmi
   71ec0e0b6..4d4d71c0d  master     -> origin/master
Removing aclocal/ax_cxx_compile_stdcxx.m4

Then, seeing that a merge commit was taking place, I recalled this
prior discussion, and emptied the commit message:

error: Empty commit message.
Not committing merge; use 'git commit' to complete the merge.

Will 'git pull --rebase' work now? Nope:

/opt/lmi/src/lmi[1]$git pull --rebase
error: You have not concluded your merge (MERGE_HEAD exists).
hint: Please, commit your changes before merging.
fatal: Exiting because of unfinished merge.

Next, this seemed like a good idea (was it?)...

/opt/lmi/src/lmi[128]$git merge --abort
/opt/lmi/src/lmi[0]$git status
On branch master
Your branch and 'origin/master' have diverged,
and have 1 and 3 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)
Untracked files:
  (use "git add <file>..." to include in what will be committed)

        .financial.hpp.swp
        .ledger_invariant.cpp.swp
        .ledger_xml_io.cpp.swp

nothing added to commit but untracked files present (use "git add" to track)

Well, I figure that at this point only my local copy is at risk, so...

/opt/lmi/src/lmi[0]$git pull --rebase
[REDACTED VALIDATION OF CREDENTIALS]
First, rewinding head to replay your work on top of it...
Applying: Prevent an MST error

And now it looks pretty good:

/opt/lmi/src/lmi[0]$git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)
Untracked files:
  (use "git add <file>..." to include in what will be committed)

        .financial.hpp.swp
        .ledger_invariant.cpp.swp

[I should have pushed before looking into those IRRs.]

nothing added to commit but untracked files present (use "git add" to track)
/opt/lmi/src/lmi[0]$git log --oneline --graph -8 master
* 1754e1a14 Prevent an MST error
* 4d4d71c0d Restore the use of XML-FO related files in configure build
* 20496df62 Use -std=c++17 flag in configure builds
* 9fabd5ed9 Make it possible to override configure xmlwrapp-config check
* 71ec0e0b6 Configure git log.date to use a consistent timezone
* e3c3d922a Resolve a marked defect [386]
* 568d6a70d Reserve memory all at once before appending to 'cells'
* b31583fe2 Avoid copying cells when pasting into a new census

So should I 'git push' now? Stop me before I destroy something...

> [...] If you'd just like a recipe for
> doing what I consider to be the right thing to do, the next time you fail
> to push something because your local branch is behind master, just do "git
> pull --rebase" instead of "git pull". This will do exactly what you
> expected to happen, i.e. it will "yank your changes", fast-forward your
> local master to the remote master and then "stuff your changes back" (which
> will change their SHA-1s, of course).
I'll try to remember that.