0

Here is my problem:

  1. I branched off master, naming the branch other_branch.
  2. I worked a long time on my branch, rebasing daily
  3. we tabled the project for a month
  4. somewhere during that time, it appears someone else directly manipulated git history on master. squashed, edited and drop commits.
  5. I try to rebase with master and get tons of conflicts--most of them involving files that are only in my branch. Someone suggested that because the file isn't on master, that of course it's a conflict. I am mystified by that statement.

Worse yet, this is in commit 61 of 147. So fix the conflicts, rebase continue, fix the same conflicts again, rinse and repeat.

I attempt just a merge rather than attempting the rebase and that seemed to work but this morning when I went to do my daily rebase it is broken again or maybe still and I thought I fixed it.

I also tried going through my branch to squash commits but when I got the last merge, I could no longer squash anything. I mean, in this case I couldn't.

Here's my workflow to rebase:

git checkout master
git pull master
git checkout other_branch
git pull other_branch
git rebase master

So I can avoid any further downvotes:

I have googled the heck out of this and found nothing that fixes my issue.

Here are the things I've researched in no particular order:

  • identifying ancestor branch to make sure I branched correctly.
  • git conflicts on files that are being ADDED
  • git conflicts on rebase
  • rebasing across merges
  • change branch ancestor
  • general git interactive rebase to make sure I wasn't screwing THAT up. nope.
  • apply patch of git diff
  • more things...

If there's more info you want, let me know

jaydel
  • 14,389
  • 14
  • 62
  • 98
  • My initial guess would be line ending changes. Do you have an example of such conflicts? Is it everyone of those commits? – Ja Da Jul 18 '23 at 13:25
  • That's a great question. Some of them have zero differences when I open them, but some of them do have conflicts in them. – jaydel Jul 18 '23 at 13:31
  • 1
    The fact that it _doesn't_ exist on `master` is _why_ you have a conflict there... in the commit that is being rebased at the moment there is a change on file X.... but the file is _not_ in the branch you are rebasing onto... what can `git` do? Just assume that it is ok to disregard that change? It would be too gutsy to assume that... so git will stop and ask _you_ to figure out what to do... it might be ok to tell git to delete the file (in which case you are disregarding the change).. but _perhaps_ the change belongs in a different place instead of the missing file for this base branch. – eftshift0 Jul 18 '23 at 13:55
  • so my understanding that once I'm on my branch and do `git rebase master` it just lays my commits over the top of the most recent master? I must be misunderstanding something critical here. I would think new files in my branch would be a trivial merge--it doesn't conflict with anything because it's new. – jaydel Jul 20 '23 at 13:46
  • As things stand, you are probably just throwing away 100 points of rep, because you haven't given anywhere near enough information to make the question answerable. If you don't know the rules for what constitutes a merge conflict, or for what a merge is, or for how a rebase is nothing but a sequence of merges, that's easy enough for you to research and too broad for a meaningful answer here. If you want an answer about _this_ particular situation, we'd need to see some _details_. – matt Jul 20 '23 at 14:26
  • nice downvote. I DID research this. For several days. I found nothing that helps with my situation. Can't believe I've got to say that – jaydel Jul 20 '23 at 14:27
  • Incidentally, checking out master just to pull it before returning to other_branch is quite silly. So the only "code" you've actually shown (something you actually said to Git) is bad code. – matt Jul 20 '23 at 14:27
  • A little more help: how can I make it easier for you to follow. I know the rules of a merge. If the file is on my branch and not master and I'm rebasing MY branch to master, there should be no conflicts. – jaydel Jul 20 '23 at 14:28
  • 1
    How many commits are in your branch and on master? What do `git log --oneline --graph master..mybranch` (only your commits) and `git log --oneline --graph mybranch..master` (only master commits) show? – knittl Jul 20 '23 at 14:32
  • 124 in my branch and 6 in master. And the output looks strange. it's like the output is duplicated. Once with the commit line with a * in front and another w/o it. – jaydel Jul 20 '23 at 14:45
  • 1
    This is not what you asked, but it might be a lot easier to reverse-merge instead of rebase. Sure you'll still have conflicts, maybe, but at least it will all be once-and-done, and the overall effect (as far as the state of the branch goes, and the way a pull request will look) will be the same. – matt Jul 20 '23 at 14:56
  • Okay I'll. look at that. This is what I meant to ask, but probably worded it poorly. – jaydel Jul 20 '23 at 14:58
  • Does your branch _add_ the files causing conflicts, or does it _change_ them? Added files should not cause conflicts. But rebasing a change to a file onto a branch where that file does not exist certainly _should_ produce conflicts. – Josh Klodnicki Jul 25 '23 at 16:26
  • Yes, that's the situation I'm struggling with: in my branch I am adding a file, and during the rebase there's a conflict in that file. – jaydel Jul 26 '23 at 12:36

1 Answers1

2

When you work on a branch starting from another local branch, it is better to not update that other local branch (here master: no git pull master)

That is because you have no idea how the remote master can evolve (as you said: "it appears someone else directly manipulated git history on master. squashed, edited and drop commits.")

When you want to rebase your own local working branch, you need to rebase only your commits, the one created in other_branch.
And you need to rebase it on top of the origin/master: the updated remote tracking branch (your local master remains unchanged, as your original starting point)

From:

...m--m--m--m        origin/master


...m--m--m           master
          \
           o--o--o   other_branch

git fetch
git rebase --onto origin/master master other_branch

To:

              o'--o'--o'   other_branch (rebased)
             /
...m--m--m--m              origin/master


...m--m--m                 master

That way, you are sure to rebase only your commits on top of the updated target branch origin/master.
Once you have done so, you can update your local master branch, in order to have a new starting point for your rebased branch other_branch.

git branch -f master origin/master

              o'--o'--o' other_branch
             /
...m--m--m--m            origin/master, master

And you can go on working from there.

If you update master first, then your rebase will include an untold number of commits, from your other_branch HEAD all the way back to whatever master has been rewritten to.

...m--m--m--m              origin/master, master
    \
     \
      ...m--m--m           Those commits should not be rebased
                \
                 o--o--o   other_branch
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250