Re: Add git-archive [take #2]

From: Junio C Hamano <junkio@cox.net>
Date: Sep 8, 2006, 00:37 UTC
Message-ID: <7v8xkvqjlq.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <450019C3.4030001@innova-card.com>

Franck Bui-Huu <vagabon.xyz@gmail.com> writes:

Show 6 quoted lines

> I'm sending a new version of the patchset which allows 'git-archive'
> and 'git-upload-archive' command. I tried to take into account all
> feedbacks made by Junio and Rene, but there are still some open points.
>
>   1/ Allow 'git-upload-archive' command to enable/disable some
>      formats. This should be done by 'git-upload-archive'.

Perhaps. I was thinking about the way how a site administrator can configure such when upload-archive is spawned via git-daemon (for users coming from ssh and spawn an upload-archive on their own, it's their own process and upload-archive has no business deciding what is allowed and what is forbidden). Not very many clean ways I can think of unfortunately.

>   2/ Can I remove 'git-upload-tar' command ?
>   3/ Should I kill 'git-zip-tree' command ?

We do not deprecate commands that easily. Notice we have kept git-resolve for a long time (we should remove it and by now it should be safe)?

Especially tar-tree --remote and upload-archive talks different protocols, so it is not like not removing it is making your life more difficult. Perhaps after next release (1.4.3 or 1.5? I dunno) in the new development cycle, we would start saying "don't use tar-tree --remote, use archive --fmt=tar --remote", and then the release after that (1.4.4 or 1.5.1? Again I dunno) we might remove it. The same thing for zip-tree, although that one has lived shorter so it might not be missed if we remove it earlier.

In any case, don't make removal of them as part of the series please. Let's make sure this new toy works well first, and then start talking about removing things that have become obsolete.

>   4/ Progress indicator support. Junio wants to mimic upload-pack for
>      that. But it will lead in a lot of duplicated code if we don't
>      try to share code. Can we copy that code anyways and clean up
>      later ?

Refactoring first is always preferred, since "later" tends to come very late (or worse, never) for clean-up tasks than feature enhancements.

>   5/ Should we use "struct tree_desc" based interface for tree parsing
>      ? According to Rene it doesn't worth it as soon as you actually
>      start to do something to the trees

That became a non-issue I agree.  Whichever is easier.