Re: dist-git: Diverging branches can't be fast-forwarded

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Kevin Kofler via devel venit, vidit, dixit 2023-07-21 15:52:23:
> Miroslav Suchý wrote:
> > When I make SPDX statistics I have git checkout of all dist-gits and do
> > git-pull every two week there. This morning I found that two times I got
> > an error:
> > 
> > hint: Diverging branches can't be fast-forwarded, you need to either:
> > hint:
> > hint: git merge --no-ff
> > hint:
> > hint: or:
> > hint:
> > hint: git rebase
> > hint:
> > hint: Disable this message with "git config advice.diverging false"
> > fatal: Not possible to fast-forward, aborting.
> > Could not execute pull: Failed to execute command.
> > 
> > I was under the impression that our dist-git can have only forward
> > commits.
> 
> You should always (from all upstreams, no matter whether they allow force 
> pushes or not) pull with rebase (git pull --rebase). This rebases your 
> local, not yet pushed, changes on top of the upstream changes. Since it does 
> not change the upstream history, only your local unpushed one, it should 
> never require a force-push and hence always be safe. And it works even if 
> the upstream has been force-pushed (which should never happen in Fedora, but 
> can be an issue in other projects).
> 
> A pull with fast-forward only will fail if you have local changes, as you 
> can see above. A pull with merge will create a merge commit. The pull with 
> rebase is the cleanest option.

... and that is why "you should always (from all upstreams ..." is a very
wrong advice to give in this generality.

In fact:

- rewriting your local history automatically (due to the rebase)
  may not at all be what you want (because you may care about it)

- rebasing your changes on top of the latest upstream may not be what
  upstream wants from you (because they may want to base fixes on the
  earliest commit to which they apply, or the commit which introduced a
  regression)

Rebasing your history is not the cleanest option in these case, but the
wrong option.

The best general advice is to fetch, not pull. Then check $ref@{1}..$ref
for the remote $ref you fetched. (merge --no-ff may do as well)

Just look at it this way: Miroslav would not even have noticed something
strange going on had he done a "pull -rebase".

Use the automatic stuff only in those cases where you are sure about the
source or do not care about the target.

Michael
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux