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

Re: Modification of Nettoe

Thanks, guys!

As a small developer, most important thing I find beneficial here is email as identifier (in case hypothetical developer doesn't care about releasing email publicly). I also find it interesting and fascinating that git takes less space and possibly creates less traffic -- speed and size are important to me and I'll take a peek at git because of that.

I'll just make a few comments from POV: "I'm an SVN user, and it serves my needs" -- solely for purposes of healthy discussion, of course :-)

However, honestly, I rarely need to take a look at full history (in fact, almost never). Occasionally I need svn blame, and at work we have different branches for different publishers of our games, so sometimes we need to merge trunk into branches (yes, opposite of the regular way of doing things, but that's what we need to do). 

Paragraph where I speak about "committing  every 30 minutes or less" obviously didn't quite turn out the way I intended it, and I apologize. Even I'm not sure what I wanted to write exactly :-)
I believe I referred to the fact that for my smaller projects I usually don't need a history of how a patch was created. If several people work at the same time on same code, projects are still small enough: one person's work can be isolated and easily tracked through multiple commits on one shared repo, without a need for creating patch from a local repository.

About offline commits: I usually don't commit without internet connection, or I keep a locally created repository (with a local svnserve). It's really rare that I am developing on a machine at times when I can't access the internet. From my experience, either a local repository is used (at work, or for small local projects) -- or I can be on the net while working.

About privilegeless commits: I do agree with advantage of commit-challenged users being able to use local commits. Still, it is an advantage only for larger projects; on smaller projects, it's easy to simply give write privileges to the large contributor who would have a need for history and multiple reverts.

About submitting patches via email: Hm, I really don't see a problem with:
svn diff > mypatch.diff
mpack -s "Subject" -c application/octet-stream mypatch.diff destmail@somewhere.com
Not that I need it -- on the project that I manage, potential submitters are more versed in using forums than anything else, so we suggest that patches are submitted on our forum.

About multiple backups: Redundancy is neat :-)

And to finish by once again commenting on size of local copy:
Git's local copy being smaller does sound suspicious to me. Don't you need at least 1) history, 2) latest committed copy, 3) current working copy? You definitely need 2 and 3 in order to produce diffs. SVN stores 2 in ".svn" folders aongside of the working copy. Some logic tells me that adding the history (before head) into the whole deal must increase the total size. Does Git have some special mechanism it uses when creating patches that avoids storing full copies of latest committed copy?

Thanks guys, hope noone minds that this discussion went a bit offtopic. It surely is helping me understand what Git has and how it works. 

On Mon, Nov 30, 2009 at 11:18, Paul Wise <pabs@debian.org> wrote:
2009/11/30 Ansgar Burchardt <ansgar@43-1.org>:

> Git makes it easy to submit patches by email.  This is also convenient
> when having no commit rights.  In the history credit is also given to
> the person providing the patch (the committer is shown as well).

Another nice related aspect is that git uses (globally unique) Name
<foo@example.com> for authorship information instead of locally-unique
account names.

> Every object (file, commit) in Git is secured with a cryptographic hash,
> tags can be signed using PGP.  This makes a compromise of the repository
> much harder.

Unfortunately git currently uses SHA1, which is on the way out now:


(/me still needs to create a new GPG key that doesn't use SHA1)

To UNSUBSCRIBE, email to debian-devel-games-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Ivan Vučica

Reply to: