On Wed, Jul 25, 2007 at 02:35:16PM +0800, Steven Grimm wrote: > Do you mix your public and private commits on the private branch, then > cherry-pick some of them over to the public branch before running > dcommit? Or do you have some other workflow? Yes, what you describe is what I usually do. > That was actually my first suggestion to him, but he pointed out (and I > had to agree) that that would mean he's always just one mistake away > from publishing his local changes. All it takes is getting interrupted > for a moment and mistakenly thinking he already switched to the public > branch. He wants some less human-error-prone way to tell the system that > a particular change and/or a particular file is not intended for > publication, and for the system to just honor that without further human > intervention. If I wanted to be argumentative, you're still only one step from disaster with stgit. In order to build, you'd have to keep your local changes applied. If you forgot to pop them before a dcommit, they would be published. > Actually, one could argue that the above isn't a git-svn issue at all. > You could reasonably want the same thing from git-push too (and even > from pull, though that'd be trickier.) I guess it'd take the form of > marking a commit as local-only, and having the system automatically > rebase all the local-only commits on top of the public ones. > > Maybe a wrapper than maintains a pair of underlying git branches for > each user-visible branch would work. If you have a branch "foo" with > some public and some private changes (private ones in lower case here): > > A---B---C---D---e---f---g foo > ^ foo-public > > Now if you commit a new private revision, it's like normal: > > A---B---C---D---e---f---g---h foo > ^ foo-public > > But if you commit a new public revision, we do something like > > git commit > git checkout foo-public > git cherry-pick foo > git checkout foo > git rebase foo-public > > to get > > A---B---C---D---H---e---f---g foo > ^ foo-public > > Then, when it comes time to do the push / dcommit, we always switch to > the foo-public branch first. We push / dcommit, then checkout foo and > rebase it on foo-public again (since svn dcommit will leave foo-public > pointing at a different revision.) > > This seems like it should work in the context of git-svn with its > mostly-linear history. Not sure if it'd fall flat on its face in the > presence of lots of branching and merging. > > I also suspect I've more or less just described StGIT and this would be > a big waste of time to reinvent from scratch. This actually sounds fairly useful, as it's mostly the automation of my existing workflow. Let me know if you follow up on this. -- -Steven Walter <stevenrwalter@xxxxxxxxx> "A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects." -Robert Heinlein - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
