0

We have a long-running feature branch feature/xyz which was branched from master, to add new projects (no changes to pre-existing files).

I thought I would try to do a catch-up using rebase so using the GitKraken client ran "rebase feature/xyz onto master". As far as I can see all this has done is deleted all the files added in my local feature/xyz branch and not added any changes from master; the resultant commit is simply 50 file deletes of all the things added in this feature.

Easy to undo locally but I thought this was a valid catch-up technique instead of a merge. Have I misunderstood rebase and this is expected, or does it indicate something has gone wrong? My local feature/xyz branch does have a remote upstream branch origin/feature/xyz, I am not sure if this is relevant but it rings a bell.

Mr. Boy
  • 60,845
  • 93
  • 320
  • 589
  • I thing that in this post, you will find your answer: https://stackoverflow.com/questions/69828677/pull-rebase-deleted-all-files-of-the-project , that is better answered – haruk1515 Oct 26 '22 at 13:28
  • "the resultant **commit**"; singular commit? As in your long running feature branch with presumably many commits now has only one commit? If yes you're likely stuck at a conflict on rebasing the first commit. You may not be able to see that from inside of the UI (I'm not sure since I haven't used gitkraken), but if you open a command prompt (Git Bash) for example, you may see something saying you're rebasing 1 of 100 commits, or similar, and you need to resolve the conflicts before you can continue the rebase. – TTT Oct 26 '22 at 21:57
  • 1
    Note, my previous comment about being stuck in the rebase wouldn't explain why you don't see any new changes on `main`. Even at the first commit of the rebase you should be starting from `main` so all the changes on `main` should be there, so this is a secondary problem you're having. Maybe though you need to rebase onto `origin/main` instead of your local copy of `main`? If your local copy of `main` hasn't been updated in a while, this would explain it. (Side note, you need to fetch first to update `origin/main`, in case you haven't done that in a while.) – TTT Oct 26 '22 at 22:00
  • What *GitKraken* is doing here, I don't know. A `git rebase` means *copy some set of existing commits to new and improved commits, as if I ran `git cherry-pick` repeatedly; then once the copies are done, move a branch name around so that we find and use the new copies instead of the original commits*. There's a lot of complications you can add here to determine *which* commits get copied and *where the copies go* and so on, but the default is that if you have N commits "on" branch X that aren't already also "on" Y and you rebase X onto Y, you get N copies, except for [continued] – torek Oct 27 '22 at 00:19
  • ... except for any of the N commits that (a) are merge commits or (b) Git can determine were *already copied* to Y, via `git log`'s cherry-pick detection logic, or were deliberately removed from Y as found via the `git merge --fork-point` logic. You can selectively en- and dis-able these exceptions as well. – torek Oct 27 '22 at 00:21
  • As @TTT noted, if GitKraken has started a rebase but "gotten stuck", that *might* show up the way you describe. In Git it shows up a bit differently: the final "move a branch name around" step does not happen until all the copies are successful, and `git status` while you're in the middle of a rebase will tell you that you're not on *any branch at all* at that point and that you're in the middle of a rebase that you need to finish (or abort, if you decide to cancel the idea entirely). – torek Oct 27 '22 at 00:23

0 Answers0