0

I've got bonobo git server that's supposed to "handle syncing" among at least 2 machines, for now.

It was working fine but lately I've ran into one big problem with it and a related second one with git itself:

  1. I can't simply push from each client into it without getting the faded "non-fast-forward" issue, and though I believe it's an issue with bonobo and bare servers, its creator begs the differ, briefly.

    The following is not a copy paste, but it is the command I use when I get the issue and, as far as I recall, the warning should be very similar to this:

    git push -u "server"
! [rejected]        server/master     -> master  (non-fast-forward)

  2. Today I also can't even fetch from one client into another without getting the "non-fast-forward" freaking issue. Then I tried pushing from it into the server with the mirror option, which is the only one that works for pushing into the server due to issue #1, and pulling from the server on my machine. For my surprise, that worked! But now trying to fetch or pull from the other machine, the issue persists. My problem here is: why?!

    The following is just a copy & paste from Git Extensions:

    git fetch --progress "client" 
Done
From \\\CLIENT\project\git
! [rejected]        master     -> client/master  (non-fast-forward)

    I've actually fixed this using git fetch -f "client", but I still don't know what happened.

Disclaimer: Now I'm already going to git-scm.com to try and learn in details how the hell git works. Maybe I shouldn't even be trying to "fully sync everything" after all...

--

edit: Besides the obvious "not pulling before" issue, I've found two reasons why this could potentially be happening, but none helped fixing in my case: using rebase for editing past commits which are already replicated elsewhere or having same branches under different names, which must happen for the master at very least. This later one makes a lot of sense, except that it works some times and, after some pushes it stops working. Plus, on the fetch side, using fetch -f, it didn't broke any branches. So that wasn't it.

Community
  • 1
  • 1
cregox
  • 17,674
  • 15
  • 85
  • 116

2 Answers2

2

You need either to update client before pushing (git pull, for example) or use forced push (git push --force), but that case commits can be lost on the remote side and trigger non-fast-forward messages on other clients.

Vi.
  • 37,014
  • 18
  • 93
  • 148
-3

As much as I have read resources around as I promised, I'm still far from being 100% confident dealing with every aspect of git. Still, I could finally find solutions for my issues here, and it's been stable for at least 1 month now.

For the 1st issue (non-fast-forward thing) I've found out 3 causes.

I'll mostly copy from bonobo forums:

  1. git commit --ammend

    I use this from time to time and I'm pretty sure if you push a commit then amend it and try to push it again, it will not be accepted. The only way I found around this issue is overwriting the push with the git push --mirror

  2. checkout older commits

    If there's a branch both local and in the server but my local branch is somewhere in the history before the same branch in the server, the push will fail. This has a simple solution: checkout the newest or newer commits than what's been pushed.

  3. conflicts

    As many said, merging. If the same branch (usually the master) is in different places because one machine pushed it to the server without merging first, then the other machine has to pull, merge and then it will be able to push just fine.

This 3rd point is where I think it gets really weird... In a bare repository, from what I understand, merging shouldn't be needed because it would not keep a consistency track of branches or tags, it'd just register where they are. Anyway...

For the 2nd issue it was most likely one of those 3 causes as well.

Community
  • 1
  • 1
cregox
  • 17,674
  • 15
  • 85
  • 116
  • No, bare repos are not meant to "just register where branches are". It's simply a repository without a HEAD, which means no "checked out" branch. It's just to save space if you don't need to work on the repo's data, so it's basically meant as a "server peer". Also, non-fast-forward errors are very quickly and simply [explained on github](https://help.github.com/articles/dealing-with-non-fast-forward-errors) (link found after a quick google search for "git non-fast-forward). Basically, **just pull first**! – cregox Sep 18 '14 at 04:31
  • 4
    You should probably note that `git push --mirror` will delete all the upstream branches that are not on the local machine. In a team setting, that command can be a little more far-reaching than in an individual setting. – Kevin Brown May 01 '17 at 15:17
  • @KevinBrown 5 years ago... perhaps that's what I meant when I said "overwriting", can't recall. but I suppose `push --mirror` is pretty much self explanatory in that sense. what other behavior were you expecting? – cregox May 01 '17 at 15:32
  • Overall, the answer is unclear as to what "overwriting" means. When you `git push --mirror`, the entire local branch chain is mirrored to the git remote, which will remove any instances of those branches on the remote server. If a team is depending upon those branches, this is a really poor solution for the generic git message `can't fast-forward`. Sorry to necromance on your solution. – Kevin Brown May 02 '17 at 04:03
  • well, at least this whole post got more attention now than ever before... :D I guess it's impossible to make it clear now, as this and the other related deleted post (to which I still have access) talk mostly about bugs of an old version of bonobo, and was hoping to find more people with same issues which wasn't possible in their forums (and even here, after all). you didn't answer my question, though @KevinBrown: what other behavior were you expecting? I can't figure it out. are you using bonobo now? is anything else here making any sense to you? – cregox May 03 '17 at 21:35