git
Pavel Troller
patrol na sinus.cz
Středa Leden 7 14:10:28 CET 2015
Zdravim,
> On Wed, Jan 07, 2015 at 01:14:28PM +0100, Pavel Troller wrote:
> > ...
> > Aha, ale tam je navic spousta souboru, ktere commitovat nechci (napr. objekt
> > kody jednotlivych modulu, ruzne meziprodukty atd., ktere rozhodne commitovat
> > nechci. A naopak me zmeny jsou i v podrizenych adresarich, ktere commitovat
> > chci. Takze se asi vypisu souboru nevyhnu.
>
> git status
>
> by mel ukazat "untracked files". Soubory ktere do gitu nepatri a jsou
> vysledkem kompilace by mely byt uvedeny v toplevel/.gitignore
> gitignore(5). To by tam uz snad melo byt upstream. Jestli ne, tak si to
> tam pridejte.
Zdravim,
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 :-).
>
> > ALE:
> > Ted davam git status a vidim ty spousty pracovnich souboru, ktere bych mohl
> > add-nout, ale o mem patchnutem configure, ktere uz jsem commitnul, tam neni
> > ani slovo. git diff nevypise nic, otevre prazdny pager. Cili jak nyni vypisu
> > rozdil mezi masterem (skutecnym, na vzdalenem serveru) a svou lokalni
> > branchi, do ktere jsem commitoval ?
>
> 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.
> 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.
> 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.
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 :-).
Pavel
> GIT se hodi na vsechno mozne. Zejmena na verzovani si vlastnich veci
> lokalne. Napriklad v Debianu je balicek etckeeper, ktery vam verzuje
> cele /etc pomoci gitu.
>
> --
> Zito
Další informace o konferenci Hw-list