spatny git diff rubrika: Programování: Jiné

2 iarro
položil/-a 20.9.2016
 
upravil/-a 21.9.2016

Ahoj, víte někdo o způsobu jakým by bylo možné upravit výsledek příkazu git diff?

Mám soubor:

function ahoj() 
{
    return 'ahoj';
}
 
function nashledanou() 
{
    return 'na shledanou';
}
 
function sbohem() 
{
    return 'sbohem';
}

a potrebuju odstranit metodu nashledanou() a nahradit ji za metodu dobryden(). Git ale vytvoří diff, ze kterého to vypadá, jako by metoda nashledanou() byla jen přejmenována:

@@ -4,9 +4,9 @@ function ahoj()
     return 'ahoj';
 }
 
-function nashledanou() 
+function dobryden()
 {
-    return 'na shledanou';
+    return 'dobry den';
 }
 
 function sbohem() 

Mým cílem je, aby diff vypadal asi nějak takto:

@@ -4,9 +4,9 @@ function ahoj()
     return 'ahoj';
 }
 
-function nashledanou() 
-{
-    return 'na shledanou';
-}
+function dobryden()
+{
+    return 'dobry den';
+}
 
 function sbohem() 

Zkoušel jsem ručně editovat diff pomocí git add -i. Zkoušel jsem to tak, že jsem si vytvořil patch, ten editoval a pak aplikoval. Zkoušel jsem použít všechny diff strategie (minimal/patience/histogram), ale ani jedno nepomohlo. Git nakonec stejně vytvoří diff jaký jsem popsal výše.

Dá se tenhle problém vůbec v gitu řešit? Dík za odpověď.


Abych to ještě ujasnil, neřeším žádné git workflow. Jde mi o to, jak co nejpřehledněji zapsat, že commit nahradil jednu část textu jiným textem (s tím, že v obou řetezcích jsou opticky stejné řádky).

Komentáře

  • dominios : Ak sa smiem spytat, na co je to potrebne? Ide len o to, aby ten vysledny diff bol lahsie citatelny? Ma ist o nejake vseobecne riesenie ktore bude pouzivane castejsie? 21.9.2016
  • iarro : @domgersak Když to zjednoduším, tak ano, jde mi o lepší čitelnost diffu. S původním diffem se podstatně hůř pracuje, pokud např. potřebuješ integrovat nějaké cizí změny. 21.9.2016
  • skliblatik : 'vypadá, jako by metoda nashledanou() byla jen přejmenována' - a co když byla jen přejmenovaná? Z čeho se to rozhodne? Analýzou změn ve zbytku kódu? A lze to vždy automatizovaně spolehlivě rozhodnout? 21.9.2016
  • iarro : @skliblatik skutečně to tak JENOM vypadá. A já nikde neřekl, že hledám automatizový způsob, klidně si to upravím ručně... Ostatně, zmiňuju to i v otázce. 29.9.2016
  • pracj3am : Editace patche pochopitelně nemůže fungovat, protože git ukládá celé soubory, nikoliv diffy. A jak zobrazit změny mezi soubory po svém, o tom viz `git help difftool`. 30.9.2016
  • Kit : @pracj3am: To je omyl. Git si ukládá diffy, pouze je udržuje pozpátku - jako poslední je uložen kompletní soubor a ke všem předchůdcům jsou diffy. Nejvíc práce tedy má s vydolováním hodně staré verze, protože na nejnovější verzi musí postupně nabalit všechny zpětné patchy. 1.10.2016
  • pracj3am : @Kit Měl jsem na mysli, že při commitu git uloží celé změněné soubory a ne diffy. A to co píšete, není uplně přesné. Ano, git kvůli úspoře místa vytváří packfiles, do kterých balí vždy více objektů (např. tedy souborů) dohromady a komprimuje je ukládáním jen rozdílů (zvládá i binární soubory), viz git help pack-objects. Balení lze vyvolat příkazem git gc (a příležitostně to dělá i automaticky, pokud je gc.auto=1). Nicméně to nemění nic na tom, že při git diff se nejprve zrekonstruují obě verze souboru (pokud jsou tedy v packfile) a teprve pak se na nich dělá diff. 4.10.2016
odkaz Vyřešeno
9 Honza Břešťan
odpověděl/-a 21.9.2016

Vestaveny diff se zameruje na text a binary content, nechape vyznam verzovaneho kodu a neni v jeho silach vsechny jazyky integrovat, jen aby pak zobrazoval hezci vystup. Kdyz je potreba projit zmeny dukladne, je lepsi mit nastaveny externi diff tool. Bud nejaky z podporovanych a nebo vlastni zabaleny do spousteciho skriptu. Tahle SO odpoved popisuje oba pristupy, i ty ostatni stoji za precteni: http://stackoverflow.com/a/949242/1659828

Komentáře

  • Taco : Jestli jsem tazatele dobře pochopil, tak problém není estetika. A druhý problém je v tom, že git nejde ukecat, dát mu nějaký hint nebo tak něco. Prostě git verzuje řádky, smůla no. 21.9.2016
  • Honza Břešťan : Taky nemluvim o estetice ani premlouvani gitu, ale o nastrojich podobnych treba tomuhle https://www.semanticmerge.com/#features. Git muze klidne dal verzovat radky textu, ale diff tool se muze podivat na ten file v sirsim kontextu. 21.9.2016
  • Taco : Jasný. Ale pomůže to při rebasování a mergování? Protože tam git se svým sledováním řádek natropí nejvíce škod. 21.9.2016
  • Honza Břešťan : Pomuze, da se podobne nastavit i externi merge tool 21.9.2016
  • Taco : Tak to je potom bomba. 22.9.2016
  • iarro : Tohle zní fakt moc dobře. Díky za radu. 23.9.2016
  • integer : Externí diff tool a merge tool nastavit jde, ale nepřijde mi to jako dobrá cesta, jak obcházet to, že neumím číst diff (nebo používám nástroj, který mi nevyhovuje). Standardní diffy jsou pak všude jinde a číst cizí diffy bude pořád problém. 26.9.2016
  • Honza Břešťan : Neprijde ti jako dobra cesta pouzit jiny nastroj misto neceho, co ti nevyhovuje? K cemu jinemu by tam byla moznost nastavit externi diff a merge tool? Ja si teda naopak vzdycky rad udelam praci pohodlnejsi, pokud to neohrozi vysledek. Developer experience je dulezita vec. 26.9.2016
  • Kit : Mít v jednom diffu odstranění jedné metody současně s vložením nové metody není zrovna košér. Dobrý programátor takové vylomeniny nedělá a proto mu stači standardní diff. 26.9.2016
  • Honza Břešťan : Dobry programator nepotrebuje verzovani, protoze nedela chyby, ani mu neselhava HW. 26.9.2016
  • Kit : Přeháníš, tohle jsem nikdy nepsal. Kdybych nedělal chyby, nepotřeboval bych testy. Kdybych věřil HW, neverzoval bych na cloudu. 26.9.2016
  • tdvorak : @kit: ty věříš cloudu?! 27.9.2016
  • Kit : @tdvorak: Existuje snad něco spolehlivějšího než cloud? 27.9.2016
  • Taco : @integer: Ale ten problém přeci není v tom, že by to nešlo číst. Jde o to, že ten diff říká něco jiného, než co se stalo; respektive co programátor udělal. 27.9.2016
  • skliblatik : @Taco: Jak to konkrétně myslíš? V ukázce z otázky git říká přesně co se stalo (smazaly/přidaly se řádky). Cílem má být "domyslet" co programátor vlastně chtěl udělat. Tzn. automatizovat to, co obvykle děláme když se snažíme pochopit diff. V tomto případě se podíváme, jestli došlo k prosté záměně "nashledanou" za "dobryden" na volajících místech (což ukazuje na přejmenování) nebo jestli bylo "dobryden" odstraněno z volajících míst a "nashledanou" voláno z úplně jiných míst (což už chce víc promyslet). Otázka je, jestli když automat neuhodne, nebude to ještě víc matoucí. 27.9.2016
  • Taco : @skliblatik: Tobě se nikdy nestalo, že když si rebasoval, tak ti vznikly takové situace, kdy z jedné funkce ti to uřízlo konec a z druhé začátek, ale takovým způsobem, že vznikly dva retardi? 27.9.2016
  • dominios : stat sa to moze, a osobne si myslim, ze je jedno ako realne bude vyzerat ten diff... za x rokov praxe som nayvse potreboval rebase tusim iba raz, vsetko inak riesim klasicky cez merge a pri nom je mensia sanca na taketo problemy 28.9.2016
  • skliblatik : @Taco: Jo, při rebase vznikají občas situace, bez kterých bych se obešel. Ale nejsem si jistý, jestli by nástroj, který "uhodne" co programátor udělal, občas nezatemnil věc ještě víc. @domgersak: I u merge musíš řešit konflikty (pravda u rebase to muže být horší, zvlášť když konfliktní místo upravuješ ve více po sobě jdoucích commitech). Ale rebase není až tak věc aktuální potřeby jako spíš zvoleného workflow. 28.9.2016
  • tomas.fejfar : Taco: Tahle chyba v rebase se mi děla jen pokud jsem měl zapnuté "ignore whitespace changes". Jinak nikdy. domgresak: Fakt jen jednou? To asi pracuješ jen sám, že? 28.9.2016
  • dominios : Nie, pracoval som prevazne v timoch od 3 do 10 developerov. Rebase sme jednoducho potrebovali minimalne, vacsinou staci mergovat. Ale ako pise @skliblatik, je to mozno aj o zvolenom workflow... my sa tomu proste snazime vyhnut. 28.9.2016
  • iarro : @domgersak Jseš štastný člověk, pokud ti stačí jenom merge. Nám ne. Nechceme se potýkat s git merge hell. Pokud to považuješ za problém, tak s tím asi dokážu žít. 29.9.2016
  • iarro : @skliblatik zas a znova, tudíž opakovaně. Nikdo tu přece nechce, aby to rozeznával git automaticky (i když by to bylo super), klidně si to budu rozhodovat sám, chci ale mít tu možnost. Pokud bys tu otázku přečetl celou, tak jsem tam psal, že jsem se ten problém pokoušel řešit pomocí interaktivního 'git add' i pomocí RUČNÍ úpravy patche. 29.9.2016
  • Taco : @tomas.fejfar: "ignore whitespace changes" jsem si kontroloval, ale teď se mi to stalo asi desetkrát. 11.11.2016

Pro zobrazení všech 13 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.