On Apr 28, Philippe Meunier wrote: > Stevie Strickland wrote: > >It seems easy enough. I believe what you'd want to do is just > > > >1) Clone your local repo to another local repo > > git clone /path/to/local/clone /path/to/new/clone > >2) In the new repo, pull from git:plt > > cd /path/to/new/clone > > git pull git:plt master > >3) Push to git:plt > > git push git:plt master > >4) Throw away the new local repo > > rm -rf /path/to/new/clone > > Doing all this just to commit some change to the main repository > without changing my local repository doesn't fall under my > definition of "easy enough", sorry :-)
[Can we please avoid redundant flames? (Smileys or not.)] * "all this" includes 2 steps for setting a private repository, and 1 step to tear it down. In this description, "just to commit" is basically step #3: "git push git:plt master", which you can repeat with more changes. * This is all needed only if you really want a private repository copy, on the plt server. You could do something similar in a local repository: working on several branches and pushing from them to the master. (And yes, there is that document that Mike asked about, which would include recipes for such things.) * More specifically, this is all stuff that was just impossible to do with svn: either you have a public branch(es) or you don't. Git allows pushes and pulls between random repositories, which means that there is much more flexibility. > > [...] > > > >The changed/additional steps are rebasing so that the commits you're > >adding don't cause spurious three-way merging, > > I don't understand your "spurious three-way merging" comment. > Please explain? Look at the current commit log: * http://git.racket-lang.org/plt/ and look for "Merge branch" commits, * or run `git log' and look for them * or run `git log --graph --oneline' * or run `gitk' * or look at the github graph: http://github.com/plt/racket/network Every time that you do a merge (which people do when they pull changes), git creates a "merge commit" that includes your work and the new tree. These commits are almost all trivial, and what Stevie was talking about a way to "flatten" them. > On a related note, I've looked at a fair amount of git documentation > lately, and I think I understand what a rebase does, but I still > have no clue why anyone would care about doing such a thing rather > than doing a simple merge (and therefore why I should care about > doing a fetch + rebase instead of doing a pull). 1. See above -- many people find it disturbing to have commits that are essentially no-ops; we have a lot of them. (This would be less of an issue with svn, since it allows you to commit to one subdirectory, so no merges would be necessary if there is no other changes to it; but that's all irrelevant since svn doesn't have a proper representation for merge commits.) 2. `git pull' = fetch + merge `git pull --rebase' = fetch + rebase And in addition, some merges are "fast forward" merges, which means that there is no merge commit. (There is http://www.viddler.com/explore/fraserspeirs/videos/6/ which might be a good way to visualize a rebase, and http://www.viddler.com/explore/fraserspeirs/videos/4/ which talks (in too many words) on fast-forwarding.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
