[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Revision control
Re: Revision control
Sun, 8 Jun 2008 09:29:00 +0200
Am Samstag 07 Juni 2008 17:47:28 schrieb address@hidden:
> You are missing the point. With git, *it is not necessary* to extend --
> it's all there; git itself already allows doing pretty much anything
Just to make sure I understand you correctly: Do you mean "with the basic
commands of git"?
These naturally are the base for any higher level scripts, just as it is the
case with Mercurial, so you can also archieve everything using them - it just
isn't very convenient to do so.
There are a few things, which aren't yet possible with Mercurial, though. The
ones I know about are:
- Simple rebasing. (You can rebase, but that includes some effort; there isn't
yet a simple script doing it, except using Mercurial queues instead of
- Simple cherry-picking (same here).
- Using an unrelated repository as base for changesets.
And Mercurial has one disadvantage:
- Branches are a bit "heavier" (though I didn't see the effect of that when
working with repositories).
At the moment, I don't see any other weaknesses (I might have forgotten some),
but definite advantages in usability.
> Which isn't surprising at all. git-checkout by default preserves local
> changes; and deleting a file is a change. "git-checkout -f" on the other
> hand would probably do what you want -- and a short look in the man page
> should tell you that.
Should, but didn't.
And looking for the second time didn't either.
And "preserves local changes" is only true, as long as I don't give the
deleted file as argument.
Now, as I look at it the third time, knowing the exact parameter I want to
check, I found it:
--- man ---
-f Proceed even if the index or the working tree differs from HEAD.
This is used to throw away local changes.
--- /man ---
Knowing that git only tracks data, not files, it makes sense to do it that way
(and to express it like that in the man page). But I didn't find it in two
readings of the man page plus searching in google, and nothing in the output
of git checkout told me that 'git checkout -f' might have solved the problem.
If git isn't readily usable for me, then it is quite probable, that it is
unusable for many programmers, including some who might be interested in
contributing to the Hurd.
And every git user will be a newbe at one time, so he will do newbe mistakes
which will in turn lead to a time loss for the project, because someone will
have to undo those mistakes.
> Actually, the command was probably "git-checkout-index -a", which still
> works. It does something slightly different than "git-checkout -f" or
> "git-checkout .": It checks out deleted files, but doesn't overwrite
> modified ones.
That's what I mean with confusing. It's specified, but it isn't clear, at
least to me.
It seems that it does what 'hg up' aka 'hg update' does.
> > If I don't pass any files to, it returns the status of all files.
> Actually, it does a bit more than only printing the status. It just
> happens in this specific situation that it has no other visible
> effect... I suggest reading the man page :-)
I tried quickly finding a solution to a specific problem.
I might have found the solution reading the man page from beginning to end and
doing it again afterwards. But in the end, it was much quicker to just delete
the repo and clone it again, and that doesn't cast a good light on its
> My experience (from what I saw in Xorg) is that people having *serious*
> problems with git usage (i.e. problems that can't be solved by looking
> at the man page(s) for a moment), are generally a result of not
> bothering to understand the basic concepts of git. This is just as
> appropriate as complaining about UNIX usability without understanding
> UNIX concepts...
Why do I _have to_ understand its basic concepts to use it without running
into problems (as opposed to wanting to understand them, because they
UNIX usability is great. I didn't understand most of its basic concepts until
I learned them in my informatics class at university, but I could use it
quite well, because current tools provide a system which (mostly) just works.
Besides: I can use git _now_ (and I mostly understand its concepts, I think),
but it took a good deal of effort to get used to it, and I still stumble at
> I'm not claiming that git is perfect. I'm only saying that learning to
> use git is worth a bit of trouble IMHO. I just can't agree that we
> should always go for the simpler tool, if the more powerful one is
> harder to handle at first...
I don't say, we should always go for the simpler tool (and I also don't think
Mercurial is perfect).
But I think going for the simpler tool is useful, if the more complex tool
doesn't offer significant advantages for the project.
The "power features" in git solve problems which I don't see in the Hurd, as I
don't see them in most other projects.
And in my eyes the potential of Mercurial and git is about the same. What
mostly differs is the order in which their features were (and, I assume, will
For Linux development, where (as I now know) 40% of the sourcefiles are
changed from one version to the next, and where most people who dare touch
the code are longterm kernel hackers, git is the better choice, I think.
Almost half the files have to be touched for the change between two major
versions, so opening a pack should be faster.
In a project like the Hurd, whose development (I assume) will mostly be in its
servers which won't change a lot after they reach a stable state (since its
basic design is more stable, I think), and where every user can write, easily
test and contribute new servers (and only needs to know the proper interfaces
for doing so) Mercurial has an edge, I think.
And then there's one other advantage in Mercurial which is easy to overlook
(and which I overlooked in the beginning), since I got so used to it, I
didn't even realize anymore that I use it: local revision numbers.
While each revision has a unique ID, it also has a local revision number, so I
can just do
$ hg up 23
to get the revision 23 aka (for example) f7f129314465, instead of having to
$ git checkout 5bdc29ebf0c06f43c1165c03273111b5090de3ca
PS: I just found another nice side by side feature comparision, also including
many other VCSs:
PPS: Yes, I think that the VCS system matters for the Hurd, but maybe not in
the proportion in which I invested time in the discussion. In the end their
repositories can easily be converted for other systems.
But I like using Mercurial, for code as well as for text files and many of my
Heißt politisch sein
Ohne es zu merken.
- Arne Babenhauserheide ( http://draketo.de )
-- Weblog: http://blog.draketo.de
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the
history of free software.
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln
-- Mein öffentlicher Schlüssel (PGP/GnuPG):
Description: This is a digitally signed message part.
- Re: Revision control, Arne Babenhauserheide, 2008/06/01
- Re: Revision control, olafBuddenhagen, 2008/06/03
- Re: Revision control, Anatoly A. Kazantsev, 2008/06/03
- Re: Revision control, Arne Babenhauserheide, 2008/06/03
- Re: Revision control, Arne Babenhauserheide, 2008/06/03
- Re: Revision control, olafBuddenhagen, 2008/06/07
- Re: Revision control,
Arne Babenhauserheide <=
- Re: Revision control, olafBuddenhagen, 2008/06/10
- Re: Revision control, Arne Babenhauserheide, 2008/06/11
- Re: Revision control, olafBuddenhagen, 2008/06/17
- Re: Revision control, Arne Babenhauserheide, 2008/06/23
- Re: Revision control, olafBuddenhagen, 2008/06/26
- Re: Revision control, Arne Babenhauserheide, 2008/06/26
- Re: Revision control, olafBuddenhagen, 2008/06/28
- Re: Revision control, Arne Babenhauserheide, 2008/06/28
- Re: Revision control, olafBuddenhagen, 2008/06/29
- Re: Revision control, Arne Babenhauserheide, 2008/06/30