On 8/9/24 21:58, Mikael Morin wrote:
Hello,
Le 09/08/2024 à 21:40, Thomas Koenig a écrit :
Am 09.08.24 um 21:17 schrieb Dimitar Dimitrov:
I assume you reset your local branch? The branch on the server does not
seem to be affected. I suggest to rebase the remote branch using
another local branch. Example:
# Just in case, see which is your old local branch.
$ git branch
# Create a new local tracking branch
$ git checkout -b fortran_unsigned-20240809
origin/devel/fortran_unsigned
$ git rebase origin/master
$ gitk -n1000
I tried that, with te same result:
warning: skipped previously applied commit a6399bb27b3
hint: use --reapply-cherry-picks to include skipped commits
hint: Disable this message with "git config advice.skippedCherryPicks
false"
Successfully rebased and updated refs/heads/fortran_unsigned-20240809.
$ git status
On branch fortran_unsigned-20240809
Your branch and 'origin/devel/fortran_unsigned' have diverged,
and have 690 and 198 different commits each, respectively.
(use "git pull" to merge the remote branch into yours)
So, it seems I already pushed something dubious previously.
Isn'it the expected outcome?
As soon as you rebase, you have a local branch based on a recent master,
and a remote branch still with the patches applied on an older master.
So they have diverged.
So why do "we" want to use rebase ? Wouldn't it be more "natural" to
merge master into your branch, and work from that ?
I must say that in my professional (i.e., paid) life using git, I always
had to work from a master that was "derived" from a remote repository,
so "the god-given truth", I tend to treat our local branches as
something that had to survive a "git pull <the remote master> && git
merge" (and then fix the conflicts ...).
That said, I didn't have a chance to work on gcc's git, so my experience
might not apply here ...
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
