git

Václav Ovsík vaclav.ovsik na gmail.com
Středa Leden 7 15:19:50 CET 2015


On Wed, Jan 07, 2015 at 02:10:28PM +0100, Pavel Troller wrote:
>   ano, chova se to presne tak. .gitignore existuje, ale je toho tam hrozne
> malo. Na zacatku se pise, ze byl vytvoren pomoci configure, takze jeho
> generovani zrejme neni dokonale. Nemohu tam ale pridat vlastni radky, protoze
> pristi spusteni configure mi ho prepise. A preprogramovavat vsechny ty 
> configure.* veci (.in, .am atd.) se mi nechce :-).

aha, to tam asi teda zabudovali upstream autori projektu.
No v manove strance nahore vidim:

    SYNOPSIS
       $HOME/.config/git/ignore, $GIT_DIR/info/exclude, .gitignore

tak to zkuste vrazit do $GIT_DIR/info/exclude. Sam jsem to tam nikdy
nedaval, ale ten soubor uz tam dokonce existuje:

    zito na bobek:/data/soft/rt/rt$ cat .git/info/exclude
    # git-ls-files --others --exclude-from=.git/info/exclude
    # Lines that start with '#' are comments.
    # For a project mostly in C, the following would be a good set of
    # exclude patterns (uncomment them if you want to use them):
    # *.[oa]
    # *~


...
> > No to co mate commitnuto se uz neukazuje. Ukazuje so pouze rozdil mezi
> > HEAD / index / working files.
> > Posledni commit si zobrazite pres
> >     git show
> >     git show --nameonly
> 
> Jasne. Tam vidim vysledek merge - po commitu jsem totiz dal pull (jeste jsem
> tehdy necetl, ze je lepsi fetch) a merge byl soucasti toho pullu.

Tak jestli bude pracovat primo na vetvi master a bude chtit proste jenom
mergovat, tak asi muzete davat pull. Rovnou pri tom budete resit ty konflikty.

> 
> > apod. Vsechno ma napovedu pres
> >     git show --help
> > zobrazi se man stranka.
> >     git log
> >     git log -p
> 
> git log funguje, vidim tam opravdu celou historii toho projektu, pak moji
> zmenu configure, a pak ten merge.
> 
> > 
> > Commitovat najednou byste mel vzdycky jeden atomicky patch. Tedy veci co
> > k sobe patri a tvori celek, kdy se z jednoho bodu dostavate k druhemu
> > konzistentnimu bodu. Jestli tedy ten modifikovany configure script nebyl
> > jeden patch, tak by bylo nejlepe ten ten commit zahodit
> 
> Tomu rozumim, takto jsem commitoval i v SVN a CVS, chapu. Ta zmena
> configure je skutecne plnohodnotny atomicky patch.

Tak to ok. Nevyhoda toho mergovani je, ze se ta atomicita zrejme postupne
rozbije.

> 
> >     git reset HEAD^
> > tim zahodite posledni commit, ale zustane v indexu. Kdyz se chcete
> > podivat co je v indexu, tak lze
> > 
> >     git diff --cached
> 
> > 
> > Myslim, ze nebudete litovat, kdyz si prectete ten ProGIT.
> 
> Urcite ne, ale to vezme urcity cas. Vypada to, ze ten projekt bude do
> gitu preklopen do konce tohoto tydne a ja uz s nim budu muset umet v teto
> dobe alespon nahrubo zachazet.

Tak cas si to rozhodne vezme. Ja uz si s tim hraju v podstate nekolik let a
porad neco zkoumam a nachazim v dokumentaci :).


> Zatim mne napada posledni dotaz - budu prubezne patchovat a commitovat
> atomicke patche a sem tam fetchovat/mergovat oficialni zmeny. Po nejake
> dobe budu chtit vygenerovat aktualni diff meho lokalniho branche proti
> oficialni master branchi. To jeste porad neumim. git diff mi nikdy nic 
> nevypise.
> 
> Diky a omlouvam se za svoji nechapavost :-).

v pohode

Pokud Vam tedy nevadi postupne rozbiti tech atomickych commitu behem
mergovani, tak ma pak fakt smysl jenom ten souhrnny diff. Kdyz budte mit
vsechno commitnuto, tak rozdil proti upstreamu uvidite napriklad:

    git diff origin..master

Predpokladam, ze vzdaleny branch je take master.

    git branch -a

vypise vsechny branche. origin je asi totez jako origin/master, pokud je
master default v tom origin.
Ty vzdalene repository se daji vypsat:

    git remote
    git remote -v

A muzete jich mit zkonfigurovano vice.

-- 
Zito


Další informace o konferenci Hw-list