Re: Git drawbacks?

From: Dmitry Potapov <dpotapov@gmail.com>
Date: Nov 10, 2009, 23:43 UTC
Message-ID: <20091110234331.GM27126@dpotapov.dyndns.org>
In-Reply-To: <loom.20091110T154312-665@post.gmane.org>

On Tue, Nov 10, 2009 at 02:54:43PM +0000, Dmitry Smirnov wrote:

Show 12 quoted lines

> 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