On Wed, Sep 16, 2015 at 07:27:12PM +1000, Chris Angelico <ros...@gmail.com>
wrote:
> On Wed, Sep 16, 2015 at 7:20 PM, Oleg Broytman <p...@phdru.name> wrote:
> > Thanks. I think upstream remote-tracking branches in git are rather
> > similar. If one's afraid of rewriting published history she should never
> > rebase before @{u}. Just always using ``git rebase -i @{u}`` should be
> > good enough.
> > The biggest difference here is that git doesn't stop one to rebase
> > beyond @{upstream}.
>
> Incidentally, "git rebase -i" with no argument defaults to rebasing
> everything unpushed, which is exactly what you're talking about. But
> yes, it's perfectly possible to rebase more than that, which I've done
> extremely rarely but sufficiently often to appreciate it. Yes, there
> are consequences. All magic comes with a price. But sometimes those
> consequences are worth accepting.
PEP 103 talks about consequences and price a lot, perhaps too much. :-)
> With git, there are infinite workflows possible - you aren't forced to
> have a concept of "central server" and "clients" the way you would
> with SVN. Mercurial's called a DVCS too, so presumably it's possible
> to operate on a pure-peering model with no central server at all; how
> does that tie in with the inability to alter some commits?
Good question! In git, when you assign an upstream remote-tracking
branch (manually or automatically when cloning an existing repo) you're
essentially declare that remote the public repository on a per-branch
basis.
But certainly there are distributed development scenarios where there
are no upstream remote-tracking branches at all. For example, I develop
SQLObject using two private clones (clean backup repo and dirty working
repo) and three public clones at Gitlab, GutHub and SourceForge. They
are all equal, none of them is the upstream. I don't even have
``origin`` remote - the origin was in Subversion.
> ChrisA
Oleg.
--
Oleg Broytman http://phdru.name/ p...@phdru.name
Programmers don't die, they just GOSUB without RETURN.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
