[plt-dev] pushes & pulls & building

From: Eli Barzilay (eli at barzilay.org)
Date: Tue Apr 27 16:36:01 EDT 2010

On Apr 27, Ryan Culpepper wrote:
> Perhaps it's because we're still working out how to do things, but
> git practice seems to be at war with its data model.

[If the purpose here is to flame, then I'll ignore it.]


> Branches aren't for separate branches of development; we should use
> separate repositories instead.

Branches are for separate branches of development.  Using a separate
repository is encouraging that by allowing you to create any number of
them, even if the branch is meaningless to anyone else.


> Rebasing* seems to be about ignoring git's natural handling of
> merges

Rebasing is for cases where you want to "flatten" the commit history,
it is as "natural to git" as merging is, and a similar kind of work is
needed in both cases.  Since the plt history is, well, "not too
organized", the decision currently depends on what's more convenient.

The problem with rebasing is that you create a new line of commits
from the previous one, so if the the previous line is available
somewhere public (= on an existing clone), then those other clones
will have a different idea where the line for branch X is.  If you
have a private repository with one clone on your machine, this is not
a problem.  If you have a private repository with multiple clones,
then you probably will not want to do this for updates, but you can
later do so when you push the new work to the main repository.


> by making it emulate a really-hard-to-use variant of subversion.

A "variant of subversion" is kind of in the right direction, but re
"really hard to use" -- is adding `--rebase' so hard?


On Apr 27, Robby Findler wrote:
> For some context: I was hoping that gits fanciness would allow me to
> have some kind of intermediary between the public repository and my
> various machines. That is, I imagine something where I can let my
> laptop and my machine at home talk to my machine at work so that
> changes I make can be visible in all three places without having to
> make them public to the whole world.

As I said in the previous message:

  git push fast-machine:path/to/repo master

would push commits from your current repository and branch to the
master branch on a remote one.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!


Posted on the dev mailing list.