[plt-dev] pushes & pulls & building

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!