• [^] # Re: M'étonnerait que ça arrive dans git.

    Posté par (site web personnel) . En réponse à la dépêche Mercurial 2.1 : Les phases. Évalué à 5.

    Là où le système est perfectible, c'est que git ne te prévient qu'au moment du push. Résultat, tu te retrouves avec un dépôt local en vrac qui ne peut plus faire de push/pull mais qui contient tout de même de nouveau commits. On peut s'en sortir avec un nouveau clone et un peu de cueillette de cerises, mais se serait plus simple si git nous prévenait au moment du rebase.

    Ça se voit que tu n'utilises pas git :)

    git rebase ne change pas un historique mais en crée un autre et fait du nouveau celui de référence. C'est une nuance subtile mais elle a son importance. L'ancien historique existe toujours et est encore référencé sous le nom de "origin/feature" (origin étant le nom de ton dépôt public, ça n'a rien à voir avec le fait que ce soit l'historique d'origin)

    Il est donc possible de retrouver un historique «poussable» avec (au choix):

    • git rebase master feature --onto origin/feature # rebase les commits allant de master à feature sur origin/feature
    • git merge origin/feature

    À ce moment, feature est un commit qui descend de origin/feature. On peut donc le pousser et mettre à jour origin/feature

    Au passage, je ne suis pas sûr que git râle tout le temps quand on veut propager un historique modifié, par exemple si on a fait un rebase interactif ou un de ces trucs d'édition poussée de l'historique. J'ai le souvenir du contraire, mais peut-être que ma mémoire me joue des tours. Ou alors git a amélioré cela ces derniers temps.

    git râlera à chaque fois que tu voudras pousser une série de commits (1) sur un autre (2) alors que les nouveaux (1) ne sont pas des descendants de celui déjà présent (2). Et ce quelque soit la façon dont tu l'ais fait (rebase / rebase -i / commit --amend / filter-branch).

    Matthieu Gautier|irc:starmad