git for versioning

Rustom Mody rustompmody at
Wed Jul 30 13:22:51 CEST 2008

On Wed, Jul 30, 2008 at 4:33 PM, Manish <mailtomanish.sharma at> wrote:
>  On Wed, Jul 30, 2008 at 2:43 PM, Rustom Mody wrote:
>  > On Wed, Jul 30, 2008 at 12:47 PM, martin f krafft wrote:
>  >> also sprach Rustom Mody [2008.07.30.0851 +0200]:
>  >>> But how do I work on the base and have it push (yeah, that's not
>  >>> exactly the word) its changes through the (branches for) Albert, Beth
>  >>> and Foo?
>  >>
>  >> You push them to a central location and they fetch&merge from there,
>  >> or they fetch from your repo and merge.
>  >
>  > merge I can understand.
>  > But why push and fetch? Its all on the local machine.
> Martin's response assumes that you have Foo, AlbertFoo, BethFoo and
> CarolFoo in separate repositories.  So you push changes from repo
> containing Foo to some common locations for AFoo, BFoo and CFoo to
> pull or let them pull from the repo containing Foo.  But I think you
> mean to have all of them in the /same/ repo and still be able to
> update ?Foo with changes from file Foo.  I do not think this is
> supported by any in-built mechanism, though It may not be impossible
> to hack together some custom solution tying together diff, patch
> etc. called by post-commit hook.  Ugh.
> What is the use case?

Well the general use case is using git for documents - assume some
text format such as html or latex.
So if using git for documents (rather than source code) is stretching
things in unnatural ways I wont struggle too much.

The specific use case is just as you describe:
I have foo checked in with branches - Albert, Beth and Carol.  When I
want to work on any of these, the corresponding branch is selected and
worked on.

If I want to work on changes in the common part, I check out (a tag
for) the point before the branch (as a detached head??)
Work on that and then what?? Thats my question.

Well I guess one way could be to maintain n+1 branches -- Albert,
Beth, Carol + one for the common and then merge from common to the
others when necessary.

Just wondering if there was some more natural/automatic way.  Looked
through git-rebase and all the tree manipulating examples there but
could not find anything like I wanted.

But then versioning documents is somewhat different from versioning
source code.  In the first case multiple versions may be desired in
the second they are a necessary evil with a single final release being
the goal.

More information about the vcs-home mailing list