On Thu, 25 Mar 2010, Yang Tse wrote:
With old CVS the curl-commits mailing served a couple of purposes, it was
easy to view which changes were taking place in the repo, and it was very
easy to 'replay' lost commits that had taken place between server backup and
server crash.
With current git configuration curl-commits mails do not include diffs, they
include a link to the repo. If the repo for any reason gets corrupted these
mails serve no purpose. Is if possible to have true diffs included in
curl-commits mails?
Yeah, I really think commit mails should include diffs. I use the mails a lot
to review changes committed by others so I think the current layout is clearly
inferior to what we had before.
But this is the default setup github provides and I think it's better than
nothing, so I've left it like this and I hope and plan to adress this as soon
as I can and have some energy over for it.
Github does provide a way to receive much more info in a custom POST for each
push, but that forces me to have to write some code on my own to make it
really good and I've not yet gotten around to do that. I should also search
around and see if someone else has some useful code already written to enable
diffs in commit mails from github. Anyone knows?
Another thing I miss with git, even without having started to use it, is
that with git, files have no revision Id or number. It may be a git
philosophical thing, no matter what this version control system thinks,
content is provided in files and files have a history and as such a revision
number.
That's something we need to learn to forget. With distributed version control,
there is no such thing as a revision number of a file (at least not in the
sense CVS or subversion provide them). There are ways to pretend that there is
and we can fake up something that somehow resembles a subversion revision
number, but I don't think that's very important.
Having to update revision number by hand is plain nonsense. There are times
when one or many people work with files that come out of a repo and that are
moved to other machines where there is no version control installed.
Ensuring that everyone starts to work with the same initial document becomes
a nightmare.
Why? In our project you'd either start with the same tarball, or you'd start
with the same commit from the same branch.
And don't tell me that everyone in the team must know how to use git because
that won't happen in a million years. Not everyone in the team is a
developer, not all content is source code, and only a fraction of the team
knows what a version control system is.
Are you referring to the revision number inside the files that CVS can keep
there? Yes, that is indeed useful but in reality only a very small fraction of
people ever cared about those and I would assume that most of the people in
that small fraction are among the persons who now know how to use git.
We need to just accept that this is the new way and we need to figure out ways
to work with it.
Switching to git is primarily a help for us who develop curl and libcurl and
less of a concern for the masses who just get and use tarballs. They don't
have to care about git, not even the slightest.
Another thing that shows that git is yet in its infancy is the use of
internal keys as external references. GUID's are fine as primary keys in a
database, but only for internal purposes. Exposing these as the primary way
of identifying elements, no matter if these are code commits, financial
transactions or cake recipes makes little sense, except maybe for debugging
purposes.
git is a developer's tool while it may not be that fancy and "user friendly",
using the hashes as references simplify a lot and make perfect sense to me. I
rather think lots of that is part of git's elegance.
A matter of taste and religion of course.
--
/ daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
