On Tue, Nov 10, 2009 at 02:54:43PM +0000, Dmitry Smirnov wrote:
> Dmitry Potapov <dpotapov <at> gmail.com> writes:
>
> > And then if you really want
> > to have good and clean history, you need more than just a branch. You
> > should be able to amend your previous commits while you work on some
> > feature. With Git, it is trivial, you just run 'git rebase -i' and may
> > edit some previous commits, correct comments, squash fix-ups, etc...
> > How can you model that? By creating another branch and moving patches
> > to it by hands... Well, it is not very productive time spending, and
> > the cost of branch becomes even more prominent.
>
> This is a cool feature, but it contradicts to my understanding of VCS.
Yes, it may *appear* to contradict one of basic axioms of any VCS --
history is immutable, but here is the rule -- you never ever rebase or
change in any other way the public history of the official repository.
So once your commits hit the master branch, you should never try to
change them. This may be enforced through Git hooks.
However, when we speak about history of commits in your private feature
branch then no one cares about how you have arrived to these series of
patches more than in what order you have edited your files. What really
matters is the end result -- our patches are clean and easy to review.
Now, what is 'public' history or what is not. If no one has seen your
commits then it is clearly not public. If your commits are integrated
to the main development branch ('master') then they are clearly public.
However, many Git users have an international branch (often called as
proposed updates or 'pu' for short). The 'pu' branch is regularly
rewound, so no one should based their work on it. It is more for review
and additional testing of things that may not ready yet. When your
branch is merged to 'pu', it considered to be a fair play to re-write
your patches. However, you should do that in the way that will not
cause problems for people who review your changes.
Finally, when you re-write some branch using interactive rebase or
something else. Your old changes do not disappear immediately from your
repository. Git has 'reflog', which keeps _all_ commits in your local
repository for 30 days (or whatever time your choose). So, if you did
something wrong during rebase, you can always go back to the original
version, though you will hardly ever need that feature unless you do
something really stupid...
> BTW, as I undestood it, it is just a feature that can be implemented
> in any VCS (if you have access to its internals).
At least, not so simple. Have you heard about Mercurial? It is another
DVCS, which in many aspects similar to Git, but the underlying backend
is very different. I do not follow it very closely, but for a long time
it did not have 'rebase' and users were advised to use Mercurial Queues
instead, which is patch management system on top of Mercurial. While Git
has its own implementations of patch management systems on top of Git
such as StGit and recently TopGit, I do not think they come even close
when it comes to easy to use in everyday work, especially if you do not
want to be bothered with thinking about patch management.
Much power of Git and its flexibility comes from clean separation of the
underlying storage format and repository history. This makes 'rebase'
almost trivial in Git (unless you have merges in rebased history and you
try to preserve them), while with many other VCSes, those changes will
require significant changes to the underlying storage, which may be
difficult to implement safely and efficiently. The price that Git has to
pay for its flexibility is the need to run the garbage collection to
purge loose objects and compact all objects in one compressed pack...
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html