On Tue, Aug 16, 2005 at 02:09:08PM -0700, Junio C Hamano wrote: > And presumably you have .git/branches/myremotebranch file that > says something like "master.kernel.org:/pub/scm/git/git.git". > Or should the last line of relationships file be spelled just > push:master:ko-master?
Oops, I did intend to add just that to .git/branches/myremotebranch. > > % cat .git/remotes/ko > > push: master:ko-master pu:ko-pu rc:ko-rc > > pull: ko-master:master ko-pu:pu ko-rc:rc > > > > I might argue that this is now a job for a porcelain script or > > something. > > Probably. > > My primary interest in discussing this is to see Porcelain folks > agree on what notation and semantics to use, and probably set an > example by having the minimum base in the barebone Porcelain. This sounds good. > Personally I think there are two kinds of patch-flow: one that > is pretty much static that can easily be described with > something like your relationships notation, and ad-hoc one that > I think should not automatically contaminate the established > static flow your relationships notation nicely describes. The > corporate world may put disproportional stress on the importance > of the former, but my feeling is that ad-hoc patch-flow that is > outside your usual static patch-flow is just as important; see > Documentation/howto/using-topic-branches.txt for why. I don't doubt the utility of these topic branches. In fact, I think it what he's doing with this is great. This is exactly the kind of thing the 'relationships' could help out with. As he creates branches from existing branches, pushes, pulls and merges between them the relationships files would maintain a record of this. Let's say, for example, he made a change on speed-up-spinlocks and merged it to test. Later, a bug is found and he fixes the bug on the speed-up-spinlocks branch. Now, a script could run using the relationships files that could immediately tell that the test branch is behind the speed-up-spinlocks branch and that they should be merged. For someone who has a lot of different things to do this will be valuable. I would leave maintenance of any static work flows up to the porcelains. If a project chose to use some sort of static flow then it can simply populate the relationships files to help drive pushing and pulling if some rogue developer were to use git alone or some other porcelain (thus maintaining compatibility between porcelains). If a porcelain wanted to be very strict about adherance to a static flow then checking the relationships could tell if something 'bad' has been done outside of that porcelain. I hope I'm being clear. Please let me know if something is not clear. Carl -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl Baldwin Systems VLSI Laboratory Hewlett Packard Company MS 88 work: 970 898-1523 3404 E. Harmony Rd. work: [EMAIL PROTECTED] Fort Collins, CO 80525 home: [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
