Jak wybrać strategię scalania dla Git Rebase?


147

git-rebasestrona man wspomina -X<option>mogą być przekazywane git-merge. Kiedy / jak dokładnie?

Chciałbym zmienić bazę, stosując łatki ze strategią rekurencyjną i ich opcją (zastosuj dowolne patyki, zamiast pomijać całe sprzeczne zatwierdzenia). Nie chcę scalać, chcę, aby historia była linearna.

Próbowałem:

git rebase -Xtheirs

i

git rebase -s 'recursive -Xtheirs'

ale git odrzuca -Xw obu przypadkach.


git rebase -Xtheirsdziała w najnowszych wersjach, z wyjątkiem konfliktów drzew, które muszą być rozwiązywane ręcznie. Po rozwiązaniu tych konfliktów musisz biec git rebase -Xtheirs --continue(z -Xpowtórzeniami).


Uwaga: to teraz działa git rebase --interactiverównież z . Zobacz moją [zaktualizowaną odpowiedź poniżej ( stackoverflow.com/a/2945367/6309 ).
VonC,

Odpowiedzi:


229

Możesz tego użyć z Git 1.7.3 lub nowszymi wersjami.

git rebase --strategy-option theirs ${branch} # Long option
git rebase -X theirs ${branch} # Short option

(co jest skrótem git rebase --strategy recursive --strategy-option theirs ${branch}od podanym w dokumentacji )

Z Git v1.7.3 Release Notes:

git rebase --strategy <s>nauczył się opcji --strategy-option/ -X, aby przekazać dodatkowe opcje, które są zrozumiałe dla wybranej strategii łączenia.

Uwaga: „nasze” i „ich” oznaczają przeciwieństwo tego, co robią podczas prostego scalania. Innymi słowy, „ich” faworyzuje zatwierdzenia w bieżącej gałęzi.


6
wyjaśnienie: $ git rebase --strategy recursive -X ich
Gregg Lind

28
Kiedy tego próbuję, znaczenie oursi theirswydaje się być przeciwieństwem tego, czego się spodziewam. Muszę użyć theirsdo faworyzowania mojej obecnej gałęzi.
Craig McQueen

19
@CraigMcQueen, kiedy używasz rebase, twoje niepublikowane (niepublikowane) zatwierdzenia są odkładane na bok, gałąź jest wyrównana ze zdalnym (przewijana do przodu), a twoje zatwierdzenia są odtwarzane na górze twojej gałęzi. . Twoje zatwierdzenia są „ich” zgodnie z operacją scalania, a bieżący (przewijany do przodu) stan lokalnego oddziału to „nasz”. Może wydawać się sprzeczne z intuicją, ale kiedy zdasz sobie sprawę, co się naprawdę dzieje, ma to sens.
patrikbeno

6
@patrikbeno: Cytując Obi-Wana Kenobiego: „Więc to, co ci powiedziałem, było prawdą… z pewnego punktu widzenia”.
Craig McQueen

5
Nie jestem pewien, czy warto dodać, ale przynajmniej w stosunkowo aktualnych wersjach obecność -Ximplikacji -s recursive, więc możesz teraz użyć tylko git rebase ${branch} -X theirs. (źródło git-scm.com/docs/git-rebase#git-rebase--Xltstrategy-optiongt )
Matt Passell,

20

Dotyczy to strategii scalania, które mają własny zestaw opcji

git rebase <branch> -s recursive -X theirs

powinno działać, chociaż ta poprawka wspomina (luty 2010):

Strona podręcznika mówi, że git-rebaseobsługuje strategie łączenia, ale polecenie rebase nie wie o tym -Xi podaje użycie, gdy jest przedstawiane.

Więc jeśli nadal nie działa, jest teraz przedmiotem debaty!
(obsługiwane w ostatnim git)


Aktualizacja z commit db2b3b820e2b28da268cc88adff076b396392dfe (lipiec 2013, git 1.8.4+),

Nie ignoruj ​​opcji scalania w interaktywnym rebase

Strategię scalania i jej opcje można określić w programie git rebase, ale w przypadku -- interactiveich użycia zostały one całkowicie zignorowane.

Podpisał: Arnaud Fontaine

Oznacza to, że -Xstrategia i strategia działają teraz zarówno z interaktywnym rebase, jak i zwykłym rebase.


1
@porneL: Tak myślałem. Stąd mój link do propozycji łatki.
VonC

@porneL: Tak, zauważyłem również ten błąd - spodziewam się jednak, że wkrótce zostanie rozwiązany, czy to w tej poprawce, czy w inny sposób, ponieważ są tam wszystkie podstawowe udogodnienia; muszą tylko dokładnie zdecydować, w jaki sposób będą się komunikować od rebase do scalania.
Cascabel

@porneL: zostało zawarte w git 1.7.3. Jeśli nadal jesteś użytkownikiem 1.7.1, takim jak ja, istnieje proste rozwiązanie, sprawdź moją odpowiedź poniżej
MestreLion

7

Jak powiedział iCrazy , ta funkcja jest dostępna tylko dla git 1.7.3 i nowszych . Tak więc dla biednych dusz (takich jak ja), które wciąż używają 1.7.1, przedstawiam rozwiązanie, które zrobiłem sam:

git-rebase-ich

Jest to bardzo dobrze dopracowany (a przez to długi) skrypt, przeznaczony do użytku produkcyjnego: opcje interfejsu użytkownika, obsługuje wiele plików, sprawdza, czy plik faktycznie zawiera znaczniki konfliktów itp., Ale „rdzeń” można podsumować w 2 liniach:

cp file file.bak
awk '/^<+ HEAD$/,/^=+$/{next} /^>+ /{next} 1' file.bak > file

A oto pełny scenariusz:

#!/bin/bash
#
# git-rebase-theirs - Resolve rebase conflicts by favoring 'theirs' version
#
#    Copyright (C) 2012 Rodrigo Silva (MestreLion) <linux@rodrigosilva.com>
#
#    This program is free software: you can redistribute it and/or modify
#    it under the terms of the GNU General Public License as published by
#    the Free Software Foundation, either version 3 of the License, or
#    (at your option) any later version.
#
#    This program is distributed in the hope that it will be useful,
#    but WITHOUT ANY WARRANTY; without even the implied warranty of
#    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#    GNU General Public License for more details.
#
#    You should have received a copy of the GNU General Public License
#    along with this program. If not see <http://www.gnu.org/licenses/gpl.html>

#Defaults:
verbose=0
backup=1
inplace=0
ext=".bak"

message() { printf "%s\n" "$1" >&2 ; }
skip()    { message "skipping ${2:-$file}${1:+: $1}"; continue ; }
argerr()  { printf "%s: %s\n" "$myname" "${1:-error}" >&2 ; usage 1 ; }
invalid() { argerr "invalid option: $1" ; }
missing() { argerr "missing${1:+ $1} operand." ; }

usage() {
    cat <<- USAGE
    Usage: $myname [options] [--] FILE...
    USAGE
    if [[ "$1" ]] ; then
        cat >&2 <<- USAGE
        Try '$myname --help' for more information.
        USAGE
        exit 1
    fi
    cat <<-USAGE

    Resolve git rebase conflicts in FILE(s) by favoring 'theirs' version

    When using git rebase, conflicts are usually wanted to be resolved
    by favoring the <working branch> version (the branch being rebased,
    'theirs' side in a rebase), instead of the <upstream> version (the
    base branch, 'ours' side)

    But git rebase --strategy -X theirs is only available from git 1.7.3
    For older versions, $myname is the solution.

    It works by discarding all lines between '<<<<<<< HEAD' and '========'
    inclusive, and also the the '>>>>>> commit' marker.

    By default it outputs to stdout, but files can be edited in-place
    using --in-place, which, unlike sed, creates a backup by default.

    Options:
      -h|--help            show this page.
      -v|--verbose         print more details in stderr.

      --in-place[=SUFFIX]  edit files in place, creating a backup with
                           SUFFIX extension. Default if blank is ""$ext"

       --no-backup         disables backup

    Copyright (C) 2012 Rodrigo Silva (MestreLion) <linux@rodrigosilva.com>
    License: GPLv3 or later. See <http://www.gnu.org/licenses/gpl.html>
    USAGE
    exit 0
}
myname="${0##*/}"

# Option handling
files=()
while (( $# )); do
    case "$1" in
    -h|--help     ) usage            ;;
    -v|--verbose  ) verbose=1        ;;
    --no-backup   ) backup=0         ;;
    --in-place    ) inplace=1        ;;
    --in-place=*  ) inplace=1
                    suffix="${1#*=}" ;;
    -*            ) invalid "$1"     ;;
    --            ) shift ; break    ;;
    *             ) files+=( "$1" )  ;;
    esac
    shift
done
files+=( "$@" )

(( "${#files[@]}" )) || missing "FILE"

ext=${suffix:-$ext}

for file in "${files[@]}"; do

    [[ -f "$file" ]] || skip "not a valid file"

    if ((inplace)); then
        outfile=$(tempfile) || skip "could not create temporary file"
        trap 'rm -f -- "$outfile"' EXIT
        cp "$file" "$outfile" || skip
        exec 3>"$outfile"
    else
        exec 3>&1
    fi

    # Do the magic :)
    awk '/^<+ HEAD$/,/^=+$/{next} /^>+ /{next} 1' "$file" >&3

    exec 3>&-

    ((inplace)) || continue

    diff "$file" "$outfile" >/dev/null && skip "no conflict markers found"

    ((backup)) && { cp "$file" "$file$ext" || skip "could not backup" ; }

    cp "$outfile" "$file" || skip "could not edit in-place"

    ((verbose)) && message "resolved ${file}"
done

Dzięki @VonC! Po prostu nie jestem pewien, dlaczego SO nie zakodował skryptu bash kolorem. Taki duży scenariusz jest zawsze brzydki sam w sobie ... ale ogromna masa czarnego tekstu sprawia, że ​​jest jeszcze brzydszy: P
MestreLion Kwietnia

Jest to wyjaśnione na stackoverflow.com/editing-help#syntax-highlighting . Dodałem odpowiedni kod prettify języka przed twoim blokiem kodu. Teraz powinno wyglądać lepiej.
VonC

Dzięki @VonC! Podświetlanie składni SO jest naprawdę kiepskie, ale jest lepsze niż nic. I jesteś niezwykle troskliwy! A będąc THE authorithy git w tak, to może być zainteresowany w kolejnym scenariuszu pomocnika: stackoverflow.com/a/10220276/624066 . To i moje konto na githubie zawiera narzędzia, które mogą Ci się spodobać.
MestreLion

W przypadku wersji 1.7.1 wydaje mi się, że to działa; nie ma potrzeby stosowania powyższego skryptu. git rebase --strategy="recursive --theirs" master
Papadeltasierra

Przepraszam za bycie nowicjuszem w git, ale jak można wykorzystać powyższy skrypt git-rebase-theirs? Czy jest to opcja przekazana w jakiś sposób do git-rebase, czy po prostu skraca czas potrzebny do ręcznego rozwiązywania konfliktów?
Papadeltasierra
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.