On Wed, May 13, 2020 at 04:24:54PM -0400, Prarit Bhargava wrote:
> Hey everyone,
>
> I spoke with dzickus about this and he suggested I reach out to the list to
> get
> an idea of how to fix this.
>
> I originally pushed a branch "osnamechange" to gitlab and created merge
> request
> 354. That patch, as discussed in the other thread, caused CKI to fail.
>
> jcline commented in 354 that I had to rebase and make changes to his new
> Sphinx
> documentation. So I did
>
> git fetch --all
> git pull
> git checkout osnamechange
> git reset --hard upstream/os-build
> <made my changes here and created _1_ patch>
> git push -f g...@gitlab.com:prarit/kernel-ark.git osnamechange
>
> which logically made sense to me.
>
> The result of this is that I now have 193 identified patches in the merge
> request. It appears what has happened is that the reset pulled in all of the
> changes from upstream.
I believe GitLab is saying the branch included 193 new commits, which
IIRC was exactly how many commits you were behind os-build, so it's just
indicating what got pulled in from the rebase. If you look at the
commits tab of the merge request you'll see there are actually 0 new
commits compared to os-build.
>
> So I have some questions ;)
>
> 1. What did I do wrong wrt to the kernel-ark workflow?
I think you just lost your commit somehow.
> 2. How do undo what I did ;)?
Whenever I mangle something in git, I find git-reflog invaluable. You
can get back to your original state with:
git checkout osnamechange
git reset --hard 1b1d4554fc1b
>
> Since no one has reviewed the patch, I could just delete the branch and start
> over. I'd rather know what I did wrong so I can avoid doing it in the future.
>
Typically the way I do this is:
git fetch --all
git checkout osnamechange
# drop the -i if you want non-interactive
git rebase -i upstream/os-build
# optionally add -u <your remote name> <branch name> to set upstream
git push -f
Another way to recover from your current situation would be to just
cherry-pick the old commit:
# Assumes osnamechange is still the same as upstream/os-build
git checkout osnamechange
git cherry-pick 1b1d4554fc1b7f76a690fe9255ad75609e9ffe25
# Fix it up as necessary and then:
git add -A
git commit --amend
git push -f
One note generally about Git{Lab,Hub}. Best practice is to not close
merge requests and then create new ones with identical content. It's
much clearer to force push your branch. Closing the merge request
signals that something significant has changed about what your doing and
all prior review/code history is no longer relevant.
- Jeremy
_______________________________________________
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
