2

Using Rugged, what's the canonical way to perform a fast-forward "merge"?

From here I found one possible lead:

# Move branch forward
# Since there's no fast-forward merge in this lib yet, do it by hand.
br = repo.branch "master"
br.move 'master-old', true if br != nil
repo.create_branch 'master', commit_sha
#br.delete! # No real harm in this hanging around

But I'm curious if there's room for improvement here.

tambre
  • 4,625
  • 4
  • 42
  • 55
Max
  • 4,882
  • 2
  • 29
  • 43
  • After experimenting a little on the command-line, I realize that the APIs in the above example have changed, at least in 0.21. But the overall approach doesn't appear to have changed. – Max Nov 22 '14 at 01:09

1 Answers1

2

There is no need for an operation called "fast-forward merge" libgit2 since a so-called ff-merge is updating the current branch to whatever commit is on the other branch, which does exist.

repo.checkout_tree(other_branch.target)
repo.references.update(repo.head.resolve, other_branch.target_id)

will update the workdir to what the other side has, and then set the current branch to point to whatever the commit at the tip of the branch to "merge", which is what an ff does.

Carlos Martín Nieto
  • 5,207
  • 1
  • 15
  • 16
  • Thanks Carlos, this seems to mostly work. Couple comments: didn't mention this required being on the branch being merged; #references is undocumented; and finally this performs the merge, but also leaves the index in a dirty state (git status shows files staged for committing). – Max Nov 22 '14 at 19:16
  • To clarify, this actually doesn't work for me, as it leaves the index in a weird state. – Max Dec 01 '14 at 18:41
  • @Max I'm experiencing the same issue. I posted essentially the [same question](http://stackoverflow.com/questions/27749418/implementing-pull-with-pygit2) a couple days ago. Did you find a suitable answer besides clearing the index after doing the above? – Michael Boselowitz Jan 05 '15 at 16:33
  • @MichaelBoselowitz You probably need to call `index.write`, per [this](https://github.com/libgit2/rugged/issues/441) open issue. – Max Jan 05 '15 at 23:11
  • @Max thanks for the reply. That indeed helped me with generating a commit (another issue I was having). However, for a ff merge it turned out that you must ```checkout_tree()``` before using ```set_target()```. – Michael Boselowitz Jan 05 '15 at 23:28
  • @MichaelBoselowitz that makes sense...I think that was included in Carlos's example, too, which is why I didn't mention it ;) – Max Jan 05 '15 at 23:29
  • @Max indeed! Silly meatspace error. Stumbled upon this answer after much trial and error. I initially dismissed it because it was what I already had, but out of order! – Michael Boselowitz Jan 05 '15 at 23:36
  • @CarlosMartinNieto that's not exactly what a ff-merge is. I'm going to butcher the terminology here, but it also validates that the your current tree is a subtree of the tree you're fast-forwarding to -- that is, that your target "contains" the current commit and all its ancestors. So it'll actually be moderately more work than what your answer offers to ensure a ff-merge is possible. – Max Jan 20 '15 at 00:44