Hi, On Fri, Jun 20, 2008 at 12:00:42PM +0200, Arne Babenhauserheide wrote: > Am Freitag 20 Juni 2008 02:22:45 schrieb [EMAIL PROTECTED]:
> > Every project has a different workflow -- both small and large. Git > > is nice because it serves *all* kinds of workflows; it is extremely > > flexible in this way. Again, that's what I like about it... > > I already wrote about the three things (i remembered at that time) in > which Mercurial is weaker than Git: - 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 branches) - Simple > cherry-picking (same here). - Using an unrelated repository as base > for changesets. These are differences in specific features. While I guess that Git is pretty complete in this regard, it's not really what I'm talking about. What I mean is that every project and every individual has a somewhat different workflow; and that there are always situations where you have to do something unusual. Most software is designed with specific workflows in mind, and if they don't exactly cover your needs, you have to adopt your workflow, kludge around it, or modify the software. Git is exceptional in that with the very direct, unabstracted interface, there are no restrictions what you can do -- untypical workflows and actions are often as easily done, or only sligtly harder, than the standard ones. I said at the beginning of this discussion that I doubt any other system offers this kind of directness and flexibility, and you haven't convinced me in the course of it that Mercurial does. In fact, you haven't really tried. Rather, you are trying to convince me that this doesn't matter. But that's hopeless -- you won't succeed here; I can assure you of that. I may not be able to argue this very well (I'm generally not very well at arguing my points, as others here can confirm); but it is nevertheless a very deeply held belief -- I am absolutely sure that this kind of flexibility *does* matter very much. > And the workflow of having local branches and rebasing them can be > archieved with mercurial queues. That's about the same workflow, but a > different way of realizing it. So it introduces an additional concept to achieve the same effect? Sounds like something that actually complicates the interface and sacrifices flexibility... > And Gits more complex basic interface is specialized for big projects > like Linux. I fail to see anything specialized in Git's interface, for big projects or otherwise. > Just look at the things which take the least amount of time/typing > compared to Mercurial. > > > # I only want to commit blah.c and foo.py in their current state. > git add blah.c foo.py > git commit -m "blah and foo shine now" > -> commit can also be done later. > > hg commit -m "blah and foo shine now" blah.c foo.py > -> not much more efficient, but the files can't be selected incrementally. I guess you are aware that it can be done the same way in Git?... Anyways, I don't quite understand what you are getting at. How is this related to large projects? > # I want to commit all changes (which are only blah.c and foo.py). > git commit -a -m "blah and foo shine now" > > hg commit -m "blah and foo shine now" > -> Somewhat more efficient (one parameter less to type (or forget)) Yes, Git exposes the index -- this is one of the concepts one needs to understand to use Git properly. And one of the reasons why Git is so powerful: Rather than using some hidden state magic during certain operations (merge, rebase etc.), everything is explicit and transparent. > # I want to see all changes in my working tree > git checkout . What do you mean by "seeing changes"? If you mean just seeing what has changed, "git-status" would be the right command. If you want to integrate changes that happened on the branch in the mean time into your working tree, "git-checkout -m" is probably the right command. (Didn't have the need to do this so far... With a distributed system, the more natural workflow usually is to merge or rebase only after committing -- though I can see situations where it will be different. As I said, flexibility is important...) > # And now the same using the provided shorthands in Mercurial, saving much > typing. If the "efficiency" of Mercurial's interface is manifested mostly in saving a few characters here and there, I'm deeply unimpressed. > # And going back to a specific revision in your local tree > git checkout d3d7b2f9088b90f21d2dd92869078e7ad3a1724a > > hg up 35 Or "git-checkout d3d7b2f". Admittedly, this is still more cryptic than "35", but I don't think it matters much -- you have to explicitely look up the ID in either case... > Due to that optimization (track mostly your part, squash changes, > ...), Git requires people to learn a completely new set of commands No idea what you mean :-( > That doesn't mean, it doesn't allow certain workflows, it only means, > that it favors some and makes others slightly less efficient. > > The same is true for Mercurial, just with a different focus and with a > command set which people who know CVS and SVN can understand with > ease. Indeed, Git's UI makes a clean cut for the most part. The result is that aside from a few glitches, it is actually remarkably logical and consistent (once you ctake the trouble to learn it properly) in a way that nothing trying to resemble CVS can ever be -- CVS is already inconsistent in itself, and trying to preserve the interface in a distributed system can't really work very well IMHO. As much as I generally insist on the importance of keeping familiar interfaces (like keeping UNIX interfaces in the Hurd), this only makes sense, if people can actually use them without relearning much. But that's not the case when switching from CVS to a distributed system -- here you *always* have to relearn. Using similar commands will only create the *impression* that no relearning is necessary -- and that way probably do more harm than good. > Did you try out Mercurial now? No, didn't need it so far. As much as I'd like to know it to be able to have a better founded discussion, this is not really reason enough to learn it :-) -antrik-
