Re: fast-forward only policy

On Wed, May 6, 2009 at 1:27 PM, Vincent Untz <vuntz gnome org> wrote:
> Le mercredi 06 mai 2009, à 02:21 +0300, Felipe Contreras a écrit :
>> Debian patches are debian patches, they control them, and they make
>> debian releases. If GNOME decides to remove those commits the
>> distributions will not loose their patches.
> I think this summarize well the whole thing: we do not want to remove
> commits.

I have already explained how you can remove commits from the visible
repositories while keeping them safe in legacy repositories.

If somebody really needs those commits that are not part of any
release (which I seriously doubt) they will still be available.

Marc-André gave me another idea. You are not limited to tags and
branches, you can have any ref you want. For example
"refs/legacy/gedit-0-6", it's not a branch, it's not a tag, but it
will make the commits not disappear and will unclutter cgit and other
visualization tools.

>> If you really want to be safe you can create legacy (hidden) repos in
>> the case someone might need those commits. They will not waste any
>> space because git uses hard links when you clone locally. Then you can
>> delete all the legacy branches in the public (visible) repos while
>> still be confident no commit will be lost.
> If gazillions of branches/tags/whatever is an issue with git, then I'd
> say this is a git bug... I can see it being an issue when doing "git
> checkout <tab>" and I'd very much prefer to have git let me filter the
> branches/tags/whatever that are of interest to me via an option.

Git is perfectly able to handle gazillions of branches, it's sane
human beings the ones that don't.

Filtering branches and tags is a good idea, but sweeping dirt under
the carpet doesn't make it disappear. And you *do have* garbage.

Are you going to argue that this branch is desirable to keep alive for
all eternity?

I doesn't even need to disappear, it can be hidden. What's wrong with that?

Felipe Contreras

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]