0

I currently have a PR open on a repo where the maintainer prefers to have all PR's as a single commit. This heavily effects my workflow when making changes on request from the maintainer. I have a desktop and laptop that I use to work from.

This may not be the "right" idea, but I consider my desktop the "homebase" or "original" machine. My laptop is always tracking remote branches that originated from that machine.

Lately, I've been running into this problem where I will make a change (either on my laptop or desktop) and have trouble rebasing the same branch on a different machine. I'm not an expert at git, but I think this has something to do with trying to rebase changes on amended commits. I'll give you an example:

Desktop on a branch with a single commit and an open PR

# Make requested changes
> touch changes.txt
> git add changes.txt
> git commit --amend
> git push -f origin PR_branch

This updates my PR and launches the automated testing scripts. Now, I have a long conference call I have to go to and can still work while listening, so I grab my laptop and navigate to my repo on a branch that is tracking the branch I just pushed to

Laptop on a branch tracking the remote branch with amended commit

> git pull origin PR_branch
From gitlab:user/repo
 * branch                PR_branch -> FETCH_HEAD
CONFLICT (add/add): Merge conflict in changes.txt
Auto-merging changes.txt
Automatic merge failed; fix conflicts and then commit the result.
> git status
On branch PR_branch
Your branch is ahead of 'upstream/devel' by 1 commit.
  (use "git push" to publish your local commits)

You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
    both added:      changes.txt

At this point the only way I've found to resolve this is by doing:

# Still on my laptop
> git checkout --theirs changes.txt
> git add changes.txt
> git commit -m "Fixed merge conflict between desktop and laptop"

Now what I'll do is reset --hard to the previous commit hash which is the amended commit that has the most recent changes from my desktop. My gut feeling is that this is flat out wrong. 

> git reset <previous commit hash> --hard

Now I have the updated changes from my desktop on my laptop and everything seems kosher. I have done this back and forth from my desktop -> laptop -> desktop -> laptop -> desktop (that many times). Is there a more idiomatic way to handle this, am I messing something up in my git history?

dylanjm
  • 2,011
  • 9
  • 21

1 Answers1

0

If you are using plain-old pull (like, the one that merges), sure.. you are shooting yourself in the foot because you are amending revisions that you are keeping on your current branch (the branch you are running the pull operation from because you had already merged revisions that are now gone on the history of the branch where you did the amend). Git can't just guess that you might have removed something from the branch just because you amended and then come up with "hey.... now I can get rid of this revision that I have in my history".

eftshift0
  • 26,375
  • 3
  • 36
  • 60
  • I have tried fetching/rebasing, but I get other odd conflicts that I didn't really want to mess with. – dylanjm Sep 20 '19 at 15:52
  • It's the same thing if you try to rebase... you amended revisions. That's the problem. I'm not against the idea of amending, by the way.... it's a perfectly legit way to do stuff... but it also implies that branches where those revisions that you amend have already been merged will require some aditional work so that you don't see the problem you are facing right now. Git is good.. but it's not a magical wand. – eftshift0 Sep 20 '19 at 15:54
  • I'm just trying to get changes from one machine to the other. Do you have an answer on how to do this? I realize it's not a magical wand, hence the reason for the question. – dylanjm Sep 20 '19 at 15:55
  • Do you do development work on both machines? If on the second part of the problem (when you did the pull) what you would like to say is `all I want at this moment is set this local branch to look exactly like the other branch from the other box`, then a hard reset sounds like what you should do (it has other implications, do not take this advice lightly): `git reset --hard the-other-box/some-branch`. That will set your local branch right where the remote branch is. No merge/rebase/blah/conflict hassle.... again: do not take this advice lightly. Look around for what `git reset --hard` does. – eftshift0 Sep 20 '19 at 15:59
  • I'll look more into it. This may complicate things too, but I am asked to always rebase against the upstream branch I am trying to merge to with the open PR. If my desktop and laptop are not "in sync" in that regard, will this blow up? – dylanjm Sep 20 '19 at 16:04
  • Rebasing is a topic in itself.... your real problem is to make sure that you don't create additional revisions where you don't need them. If you want to _sit_ on top of the new revision that you created when amending on another computer, you don't need to cherry-pick/merge/rebase.... what you need to do it reset on top of that revision.... that is, talking about _your feature branch_. Then, in order to get your changes on top of another branch (like, master), then you might be talking about rebasing. – eftshift0 Sep 20 '19 at 16:09