Keep intermediate git state if --allow-noop was passed

[Kobzol]

If a pull is a no-op, the preparation commit that updates rust-version, along with the (possibly empty) merge commit, is kept if --allow-noop is passed.

CC @RalfJung

Fixes: #26

[RalfJung]

Hm, TBH I don't care for that merge commit. Would it make sense to keep the rust-version update but not have a noop merge?

[Kobzol]

The commit is only created if there are some empty merge commits from upstream, sometimes it's not even created.

I thought that what you suggest would complicate the implementation, but it actually makes it simpler 😆 So I changed it like you proposed.

[Kobzol]

Although, I wonder if it won't be an issue that rust-version will be set to the latest rustc commit, but potentially the empty merge commits from rustc will not be included in the subtree at that point. But I guess it shouldn't be an issue, the empty merge commits will just be added on the next (non-empty) pull.

[RalfJung]

The commit is only created if there are some empty merge commits from upstream, sometimes it's not even created.

Ah, good point.

There's a slight risk the next josh-push will act up because the commit it is based on (which is taken from rust-version) hasn't been fully integrated into the local history yet. But that seems unlikely and we should notice if this ever happens.

[Kobzol]

Alright, let's try it.

[RalfJung]

Pushing changes...
Rerun with `-v` to see executed commands
Error: cannot perform push

Caused by:
    Command `cd "/home/r/src/rust/miri" && "git" "push" "http://localhost:42042/RalfJung/rust.git:rev(75dd959a3a40eb5b4574f8d2e23aa6efbeb33573:prefix=src/tools/miri):/src/tools/miri.git" "HEAD:miri"` failed with exit code Some(1). STDOUT:
    
    STDERR:
    To http://localhost:42042/RalfJung/rust.git:rev(75dd959a3a40eb5b4574f8d2e23aa6efbeb33573:prefix=src/tools/miri):/src/tools/miri.git
     ! [rejected]            HEAD -> miri (non-fast-forward)
    error: failed to push some refs to 'http://localhost:42042/RalfJung/rust.git:rev(75dd959a3a40eb5b4574f8d2e23aa6efbeb33573:prefix=src/tools/miri):/src/tools/miri.git'
    hint: Updates were rejected because a pushed branch tip is behind its remote
    hint: counterpart. If you want to integrate the remote changes, use 'git pull'
    hint: before pushing again.
    hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Yeah I guess it does cause issues.^^

(The fix is to pull again before making a push.)

[Kobzol]

That seems annoying. I'd rather remove the flag if it has such footgun. WDYT about keeping also the potential merge commit?

[RalfJung]

Yeah I think if josh-proxy returned new commits we should just have that merge commit then. We don't need a merge commit if josh-proxy returned the exact same commit that has already been merged before.

[Kobzol]

We don't need a merge commit if josh-proxy returned the exact same commit that has already been merged before.

That's easy, because in that case git doesn't evern create the merge commit.

#30 should fix this.