On Thu, 28 Jul 2005, Matthias Urlichs wrote:
> Hi, Johannes Schindelin wrote:
> Since git is better than all of these, we should be able to easily write a
> SVN-like porcelain, so ... ;-)
Sorry, you're correct.
> > IMHO, if you need a central repository, you should also have
> > one central HEAD.
> I disagree. Larger projects have multiple HEADs (stable, oldstable,
> development, ...). I don't like putting those in different repositories,
> you end up with a heap of housekeeping effort to hardlink duplicate
> objects, all of which is going to be wasted when different people run
> "git repack".
Sorry again. I should have been clearer: If you have a larger project
which does have production releases which have to be patched for a while,
and thus need several branches, then there is still a *very good* reason
not to play games with the names of those branches or the tags.
Naming the remote HEAD differently than the local HEAD is just *wrong*
when you want to push back to them. I agree that it is a fine intellectual
challenge to keep juggling a few remote HEADs, and throw in a few local
HEADs, but all that is *complicated*. And complicated things lead to
BTW I am a Jeff, I use git branches extensively in two projects.
The only sane way if you have to have different local and remote HEADs
that I can think of, would be to allow only the current local active HEAD
to be pushed to a certain remote HEAD (preferably identified by a file in
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html