On Wed, Jul 30, 2008 at 4:33 PM, Manish <[EMAIL PROTECTED]> 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. _______________________________________________ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home