git vs patchset?

Fórumok

Ma kezdtem el foglalkozni a gittel. Volt doksiolvasás, meg homokozó, a koncepció megvan. A következőt szeretném: elkezdem követni a 2.6.32.y ágat, amihez hozzáveszek 1-2 olyan patchet, ami a 2.6-os ágba bekerült, de a .32.y-ba még nem, plusz én is szeretnék belemódosítani néha. Ez eddig oké, na de mi van akkor, ha úgy gondolom, átállok a 2.6.33.y-ra?

Ugyebár az a baj, hogy a 2.6.32.y-ba gregkh cherry-pickelget dolgokat a 2.6-os ágból (mint ahogy azt egyébként én is tenném). A cherry-pick commitokról még nem tudok sokat, de azt igen, hogy ezek nem ugyanazok a commitok (csak a tartalmum ugyanaz), ezért másik ágra váltáskor problémám lehet belőle. Ugyan gregkh a commitlogokban rendesen vezeti, hogy melyik upstream commitot vette át, de ez mégsem az igazi.

Tehát valami olyat szeretnék, hogy legyen egy saját patchsetem. Ha van valami új feature egy új ágban, azt beteszem a patchsetbe, és a nekem aktuális, régebbi kernelre tudom backportolni. Ha elég stabilnak érzek egy új kernel verziót, akkor módosítom a patchsetet, hogy arra is applikálható legyen, és így tudok az új verzióra átállni. Mivel nem vagyok kernel hacker, a patchsetben szinte csak olyan dolgok vannak, amik már az új kernel verzióban is megvannak (hiszen az oda vezető útból válogattam ki magamnak patcheket), ezért a patchsetből gyakorlatilag csak törölni kell ilyenkor. Ezt szeretném tehát gittel. Tudom, igazából elosztott branchkezelésre és összetartozó historykra van kitalálva, nem cherry-pickelgetésre, úgyhogy még a végén lehet, hogy textfájlnál maradok...

Hozzászólások

Esetleg nezd meg a quilt-et. Ez ugyan nem gites cucc, fajl alapu patchkezelo, de hasznos lehet...
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.