On Mon, 8 Aug 2016 21:27:43 -0700
Michael <keybou...@gmail.com> 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

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
* 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.

Reply via email to