Kevin Grittner wrote:
What would the normal workflows be to:
rebase the postgresql.git clone and the serializable branch on the
server?
rebase my working copy on my desktop from the serializable branch on
the server?
The way you asked this suggests you've chewed on someone's advanced
workflow and swallowed some wrong bits. Rebase is an operation you do
when you're trying to be picky about what and how you publish your
changes to the world. Let's say you've updated your local branch:
serialized -> commit A -> commit B
Meanwhile, the upstream master has gotten a bunch of new commits made to it:
master -> commit C -> commit D
If you then merge those changes in, you'll have the following history:
synchronized -> commit A -> commit B -> commit C -> commit D
Now, what happens if you want to submit a patch showing your changes?
This isn't really what you want, is it? Ideally, you'd want to see your
changes--A,B--on top of the updated master instead. Basically, throw
these new C,D changes into history behind yours. That's what rebase
allows you to do.
On a normal day, you won't be doing that at all. You'll be merging from
the various sources and pushing to others. Rebasing is something you do
before publishing your changes to the world, or as part of repo history
cleanup. It's not something you have to do all the time.
Also: rebase can allow you to squash A&B into one commit before you
publish them, too, to make the commit log easier to read. Did a bunch
of dumb stuff on your local copy? Squash them into a single, final
version before sharing those with the world. Again, not necessarily a
routine operation you have to do regularly.
You could easily commit happily and usefully share your work without
running rebase once. However, note that once you do push something out,
and people grab it, you've lose the opportunity to do some rebase
cleanup without making life difficult for them--you can't wipe out
commit log history once it's in somebody else's repo or your copy is
going to diverge from theirs, making a future merge messy for one of
you. This is why some people compulsively rebase everything before they
publish. You shouldn't assume you have to do that from day one though.
On this project, if your code gets committed one day, it's not going to
be with the commit history intact anyway, so it really doesn't matter at
the end.
--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
g...@2ndquadrant.com www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
