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

Re: Format 3.0 (git)



]] Steve Langasek 

| > Given I maintain my packages in git, it's quite clear that the preferred
| > form for modification of my packages is through git and not debian
| > source packages.  That we don't have a good way of distributing the
| > source of packages is a fault I think we should address.
| 
| I am sympathetic to the problems caused by the interactions between quilt
| and VCS-hosted packages, but I object strongly to this attempt to cast git
| repositories as "the preferred form for modification" of a work.  Under the
| GPL, this is tantamount to claiming that it's *illegal* to distribute a
| tarball of the work without the git history!

Yes, I think it might well be.

| git is a container, not a "preferred form for modification".  It's a
| container with some nice added features, like access to the full history,
| but the history of the work is not part of "the work".  This is evident from
| a simple question:  is access to this history a benefit because it allows
| you to modify the history?

No, it's primarily because it gives me richer metadata for the current
state of the project, using git blame, git log and so on.

Having access to the history is similar to having sensible file names
rather than naming all the files in a project a.c, b.c, c.c, d.c and so
on.  Having useless names does make hacking on the source harder, but it
does not prevent it completely.  There are other obfuscation techniques
one could apply as well, and at some point, the source would be so
obfuscated or lacking so much metadata we would no longer consider it
the source.

The main point here might not be the git repository but «the files
including their history» and a fast-export of the repository would be as
acceptable as the git repository itself.

| When submitting changes upstream or planning to maintain the code in the
| long-term, access to the VCS is invaluable.  But neither of those things is
| equivalent to modification of a work, and modifying the work does not
| require access to a VCS.  I'm pretty sure anyone who can modify the code in
| a git repository can also modify it without a git repository.

Can?  Yes, I suppose so.  That does not make it the preferred way,
though.

| > I don't put much weight on the «it should be simple to hack on packages
| > and VCSes make it hard» argument.  IME, there are many more people who
| > know how to drive git than there are people who know how to usefully
| > hack on Debian packages.
| 
| There are more people who know how to drive svn than there are people who
| know how to drive git.  Let's make svn repositories the preferred source
| format. :-P

That is a strawman if I ever saw one. :-)

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


Reply to: