Re: [git-users] Stacked git?
On Tue, 9 Aug 2016 10:23:00 -0700 Michael wrote: [...] > So, it's basically a set of local changes from the official source > distribution? And tools for managing that? If we tell about one (supposedly the most common) application of patch series then yes. > I am thinking of groups like MacPorts that maintain their port > information as a set of diffs from the official upstream code. Maybe. I have close to zero experience with desktop Apple products. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Stacked git?
On 2016-08-09, at 9:53 AM, Konstantin Khomoutov wrote: > On Mon, 8 Aug 2016 21:27:43 -0700 > Michael wrote: > >> Can someone explain stacked git? >> >> It was referenced in "Git from the bottom up", but I've never used >> Quilt, and neither project really explains what it is for/doing. > > Well, there's certain kind of changes -- relative to some "upstream" -- > you might keep, which are in essense "pending" or are just not going to > be integrated upstream for some reason. > > A good example is software packaging performed by folks who maintain > GNU/Linux-based distributions: when you download a tarball containing > some release of some software package you often want to tweak certain > bits in the source code of confiuration system of that piece of > software before actually building it to produce a package for your OS. > This might amount to relocating certain files or patching some string > resources or artwork etc. Another common case is fixing a bug. > > Such changes are usually maintained as a series of patch files. > Tools like quilt basically maintain a file named, well, "series", > containing the list of names of files containing actual patches in a > textual format -- which is usually "unidiff". > > Quilt and the tools of its ilk is able to start from a pristine state of > the sources and then apply each patch file from the series in turn -- to > produce the modified state ready to be built. Such tools can do more > than that: they are able to de-apply the patches in the reverse order > and "refresh" the patch files -- using the updated state of the source > tree. > > So, before powerful enough VC systems came into existence, patch series > was the strategy everyone was using to maintain a set of local changes > to some upstream target -- possibly changing in time. > > Sure, at some point some clever person noticed that a series of commits > on a branch of a VCS system is able to neatly represent a patch series, > and basically that's what `stgit` does. > > IMO, the closest thing to think of in plain Git sort of matching this > functionality is a local branch which was once forked off some upstream > branch, contains a series of commits and gets rebased from time to time > on top of the updated state of its upstream branch. > > Note that patch series are not going away anytime soon. Say, Debian > makes heavy use of them in its packaging routine (even though it has > VC-relaed tooling to help with this task, such as the `git-buildpackage` > program). The reason for this is two-fold: > * While there exists a certain pressure to standardize on Git as /the/ > VC tool for everything, this won't probably happen in the near to > mid-term. > * Upstreams and casual users should have easy (and automated) access to > the information of what changes the OS applies to the pristine > software releases pulled from their respective upstreams. > Patch series fit this bill rather neatly. So, it's basically a set of local changes from the official source distribution? And tools for managing that? I am thinking of groups like MacPorts that maintain their port information as a set of diffs from the official upstream code. --- Entertaining minecraft videos http://YouTube.com/keybounce -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Stacked git?
On Mon, 8 Aug 2016 21:27:43 -0700 Michael wrote: > Can someone explain stacked git? > > It was referenced in "Git from the bottom up", but I've never used > Quilt, and neither project really explains what it is for/doing. Well, there's certain kind of changes -- relative to some "upstream" -- you might keep, which are in essense "pending" or are just not going to be integrated upstream for some reason. A good example is software packaging performed by folks who maintain GNU/Linux-based distributions: when you download a tarball containing some release of some software package you often want to tweak certain bits in the source code of confiuration system of that piece of software before actually building it to produce a package for your OS. This might amount to relocating certain files or patching some string resources or artwork etc. Another common case is fixing a bug. Such changes are usually maintained as a series of patch files. Tools like quilt basically maintain a file named, well, "series", containing the list of names of files containing actual patches in a textual format -- which is usually "unidiff". Quilt and the tools of its ilk is able to start from a pristine state of the sources and then apply each patch file from the series in turn -- to produce the modified state ready to be built. Such tools can do more than that: they are able to de-apply the patches in the reverse order and "refresh" the patch files -- using the updated state of the source tree. So, before powerful enough VC systems came into existence, patch series was the strategy everyone was using to maintain a set of local changes to some upstream target -- possibly changing in time. Sure, at some point some clever person noticed that a series of commits on a branch of a VCS system is able to neatly represent a patch series, and basically that's what `stgit` does. IMO, the closest thing to think of in plain Git sort of matching this functionality is a local branch which was once forked off some upstream branch, contains a series of commits and gets rebased from time to time on top of the updated state of its upstream branch. Note that patch series are not going away anytime soon. Say, Debian makes heavy use of them in its packaging routine (even though it has VC-relaed tooling to help with this task, such as the `git-buildpackage` program). The reason for this is two-fold: * While there exists a certain pressure to standardize on Git as /the/ VC tool for everything, this won't probably happen in the near to mid-term. * Upstreams and casual users should have easy (and automated) access to the information of what changes the OS applies to the pristine software releases pulled from their respective upstreams. Patch series fit this bill rather neatly. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
