Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need help on fixing branches in my fork after git cleanup #3174

Closed
HHHartmann opened this issue Jun 21, 2020 · 5 comments
Closed

Need help on fixing branches in my fork after git cleanup #3174

HHHartmann opened this issue Jun 21, 2020 · 5 comments

Comments

@HHHartmann
Copy link
Member

I need some help on how to fix my branches after the git repository has been cleaned up.

I managed to update my clean local dev branch with

git checkout dev
git rebase upstream/dev
git rebase --skip
git push --force

But this does not work well for branches with own commits that have conflicts.

@nwf
Copy link
Member

nwf commented Jun 22, 2020

You might try interactive rebasing (git rebase -i upstream/dev): you can preemptively drop commits that git has failed to detect as duplicates, and you can commit --amend real conflicts "in situ" as you work your way up the stack. This is almost always what I use for PR development, speaking of: I commit -p -m 'fixup foo' and then later go rebase -i those fixup commits back into place, replacing pick with f (or fixup).

Alternatively, if your branch has only a few commits on it beyond the old dev head, with a clean working state (i.e., everything checked in or stashed), you could instead try something like

git checkout foobar
git reset --hard upstream/dev  # Replace the current state with upstream/dev
git cherry-pick @{1}^3..@{1}   # Cherry-pick the top 3 commits from the old branch head, which is the 1st entry in this branch's reflog

or (instead of the bulk cherry-pick like that), you could manually (with git log) grab the list of commits you want to preserve, hard reset the branch, and then cherry-pick each commit individually.

@marcelstoer
Copy link
Member

marcelstoer commented Jun 22, 2020

An (maybe brutal) alternative to @nwf's idiomatic Git suggestions (thanks!) is to resort to creating and then applying a patch. That normally works well - if you can live with loosing the history of the commits not yet merged upstream. You won't loose the changes but their history. It's similar to cherry-picking in that respect.

@nwf
Copy link
Member

nwf commented Jun 22, 2020

FWIW, I believe the old dev head prior to rebasing was 862420b; likely your clone still has this commit referenced (via the reflog of origin/dev, but the salient point is that the garbage collector has not yet shed it), and so you can run things like git diff 862420b6 or git diff HEAD..862420b6 (to ignore uncommitted changes) to make those patches.

@TerryE
Copy link
Collaborator

TerryE commented Jun 22, 2020

Or even git diff 862420b6~..862420b6. I mist admit that I dislike the lack of control of rebasing. I never work in dev but rather dev-something. When I want to rebase I just del the dev branch and refetch the latest from nodemcu and create a new branch off of dev and check this out. I can then checkout individual files where I am replacing by just doing git checkout dev-something -- path/file or using diff to git diff newdev.. dev-something -- path/pattern then reviewing the diff file and applying it as a patch. A bit slower, but at least I have total control over the rebase.

@HHHartmann HHHartmann pinned this issue Jun 28, 2020
@HHHartmann
Copy link
Member Author

Thanks guys for your help.
I pinned this issue so other developers can find it easily. We can unpin it at a later state but I think it makes sense at the moment.

@HHHartmann HHHartmann mentioned this issue Jul 5, 2020
4 tasks
@TerryE TerryE unpinned this issue Jul 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants