Bug: git pull --rebase rewinds without applying commits in special workflow.

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

 



Hi,

in our workflow commits can be removed from from the tip of the branch in the
central repo. After this git pull --rebase on the "client" side may "lose"
commits, because the rewinding takes place without an fast-forwarding.


$ git log --oneline master           # example repo with 3 commits
b52b381 c3
faf6bbe c2
2ad3897 c1

$ git push origin master             # let the remote be up-to-date

$ git push origin +master^^:master   # simulate removal on remote

$ git pull --no-rebase               # pull without rebase works fine
Already up-to-date.                  # master points still to c3

$ git pull --rebase --prune          # pull --rebase with pruning also works
Current branch master is up to date. # master points still to c3

$ git pull --rebase # git pull --rebase does part of its job
First, rewinding head to replay your work on top of it...

$ git log --oneline master # commits c2 and c3 are "lost" on master
2ad3897 c1


The actual workflow is that the commits are removed in the post-receive
hook of the central repo and send to an automatic test. After this passes
the commit is sent to svn and the result is then put to the top of the
branch.In case of a failure, the user should still have his commits in
his repo, so he could amend it and send again.
Using -p with git pull is currently the workaround to this.

Regards
Andreas

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]