10 ms·

Articles like this worry me a lot. Most of this post leaves me thinking, "Why should I be worrying about things like this?" A fair amount of it leaves me at le

Articles like this worry me a lot. Most of this post leaves me thinking, "Why should I be worrying about things like this?" A fair amount of it leaves me at least somewhat boggled; I suspect I'm not alone here. The idea that a user of a DVCS needs to be familiar with issues like these tells me that something is seriously wrong with the design of DVCSs. Remember, a DVCS is a tool we use to track and store data related to a project. The project is what we are interested in: the Python or C++ or LaTeX or whatever. Git, Mercurial, etc. are just there to help us keep track of the real work. Time spent dealing with the intricacies of Git is time not spent on the primary task -- the thing that Git is supposed to help us with. Consider filesystems, which are also tools used to manage stored data. If I'm writing some Python thing, I don't proclaim to everyone that I'm storing my work on a ReiserFS volume, and I'm thrilled by the fact that ReiserFS indexes its metadata using a B+ Tree. I just store my data. I think a well-designed DVCS would be thought of in much the same way. Clearly, current DVCSs aren't. Something is very much amiss, folks.

venomsnake 13y ago
All software has its quirks. And it shows when you move out of the ultra comfort zone. If you want to drill a hole in the wall you need to take into consideration the size of the hole, the power of the drill and what are you drilling in. You cannot abstract them. And then one day someone decides to use your python code not on ReiserFS but on Ext2 that has no journaling and all hell could break loose.
migrantgeek 13y ago
If you're just storing data, your analogy is fine. It breaks down with more advanced usage like integrations which can be very difficult with large teams. I manage a VCS with thousands of developers committing to a large code base. The VC system starts to really matter and you have to understand how it handles things like conflict resolution or things can get out of hand really quickly.
gkoberger 13y ago
Taking your logic a bit further: the final product is what we (should be) interested in. Python or C++ or LaTeX or whatever are just to help us make it. Everything else, whether it be Python or git or C++ or Mecurial or vim or Windows or an ergonomical mouse, is just there to help us make the final product in an easy and quality manner. I don't see a problem with worrying about git any more than I see one with worrying about Python. Change for the sake of change is bad, but change for the sake of an improved workflow is good.
- ggchappell 13y ago
  That's an interesting point. Here are my off-the-top-of-my-head thoughts: I guess the real goal is proper separation of responsibilities. When I cook a meal, I use devices that run on electricity. I want to be able to power them up by plugging them in without thinking much about it. The people who work at my power company need to think about the intricacies of generating and transmitting electricity, but I don't want to. On the other end, the people who eat the food I cook should not have to worry about the use of a stove timer or a rice cooker. Similarly, when I put together a software package, I am functioning as a programmer/software designer. I am interested in the code, how it is structured, and what it is supposed to do. Time spent worrying about storage & version management is generally time spent away from my primary task. Someone needs to worry about that, but, for the most part, I don't think it should be me. The users of the package I write just want to use it. They care that it does what they want. The fact that it is written in Python, developed using agile methods, etc. are irrelevant to them. (But not to me, as a programmer.) And maybe for the users, the software is a tool to help them in their business. The customers of that business probably should not care about the software at all; they just want whatever service the business provides.
  - jlgreco 13y ago
    Even when powering electronics in the home, you have to worry about which sort of power the device needs. Does it need a great big 240V AC outlet, or just the regular 120V AC (using American values...)? Is the device DC powered instead? Does it have it's own wall-wart, or can you use a AC->USB converter? Does it use USB micro or mini? These are things the consumer has to worry about. Of course in practice "worry about" is an exaggeration; this is all pretty elementary stuff and no reasonably intelligent consumer actually loses sleep over it. The matter of what version control to use? The consumer never has to worry about that. That concern is something that only developers (and related professionals) will have to worry about. I don't think it is a big deal. Just pick whatever fits your needs and that you prefer. Should the developer have to know anything about version control? I don't know, should the electrical have to know anything about multimeters, outlet testers, and wire cutters?
asdfaoeu 13y ago
I can see your point but the fundamental problem is that unless you have a simple linear history a DVCS can't possibly know how to merge and apply patches without some heuristics. At best the DVCS can be a tool to assist you. There is of course a lot of simple tasks which DVCS can and do apply near perfectly but I suppose managing a complex project you're at some point going to have to have a basic understanding of how the system works. I've used IBM's RTC which is an excellent GUI VCS tool that I believe internally works similar to git/hg but it attempts to hide how its internals works so on a large merge 500+ changesets and then remerging more commits it refused to push despite saying no incoming changesets. We ended up fixing it by pulling to a different repository based of the branch we were trying to merge from based of advice from support. But I'd prefer a deterministic cli interface over a gui interface anyday.
ams6110 13y ago
Articles like this make me wonder if I'm stupid. 95% of the time all I ever do is commit my work and push/pull, whether I'm using svn, git, or hg. I just hardly ever find myself needing to understand anything more complicated than that. Why does it seem like everyone else has spent thousands of hours understanding esoteric git or hg incantations that I've never encountered the need for.
- jlgreco 13y ago
  Are you working with a large team? I find that tends to be when your "VCS muscles" really start to get exercised.
  - ams6110 13y ago
    I suppose it depends on what you consider large. At the moment my team is 3 who are doing daily work, and a few more that do more intermittent work. I'd consider that to be small. I have in the past worked on larger teams (~15 developers), that project used svn and we never seemed to really run into any issues even though we had branches for mainline dev work, and support branches for each "released" version. I'd get the occasional conflict to resolve but it generally wasn't too bad, and I get those with Git also. I've never worked on a project where dozens or hundreds of remote developers were contributing, but I'd say that outside of a small number of high-profile open-source projects, most people don't. I understand that's what git was built for; maybe that's why all those features just seem like overkill for anything I've never worked on.
    - jlgreco 13y ago
      I guess 'large' is really a function of number of developers and rate and diversity of commits. I've been in a few situations where two or three of us were putting out several changes to the same piece of code rapidly (typically to meet a deadline). Git has proven invaluable in untangling some of the knots we've put ourselves into in those sorts of situations. If commits are coming in slowly, with plenty of notice, and everyone is working on different parts of the codebase, then you probably won't need to do much fancy stuff very often.
natrius 13y ago
Code is read more than it is written. Version control systems provide tools to make it simpler to read code and understand why it was written. Version control systems also define how you branch and merge, which are are hugely important concerns if you're working on a team, and still pretty important if you're working alone. Git handles branches and history management better than Mercurial does for my needs, and it makes a huge difference to me.
- kasey_junk 13y ago
  Just curious, what about Git's branches and history management is better than Mercurials with the appropriate plugins turned on? I've been able to successfully replicate all the Git use cases I can think of in Mercurial even if I think they are bad practices. Conversely, nothing I do makes git's cli anywhere near as good as hg. For me, that is the single biggest glaring problem with Git. I spend a very small minority of my time handling complicated history/branch issues as part of my major workflow and I spend an inordinate amount of time working with the interface to my source control. Git seems optimized for the minority case.
  - steveklabnik 13y ago
    I a not mega familiar with mercurial, but I was under the impression that culturally, rebasing is considered bad. Yes, there is a rebase plug-in, but mercurial users don't generally think it's a good idea to mutate history. Git users tend to branch, make a ton of commits, then clean them up using rebase and then merge and push. hg users tend to... not? I may be _entirely_ off base here. (personally I find git's command line to be fantastic, but I often feel like I'm the only one.)
    - functional_test 13y ago
      Exactly. Although rebasing is convenient, it does involve taking destructive actions on a repository which is ostensibly a tool to make sure your data isn't lost. The feeling in the Mercurial community is that this is potentially dangerous and not necessary. Really, it would be best if there was some way to retain the original commits while rebasing to clean the history. Time for a new DVCS?
thatthatis 13y ago
A filesystem is a tool we use to track and store data related to a project. A DVCS is a tool we use to track and store data related to a project, collections of that data, changes in that data over time, changes in that data made by others, pointers to certain states, and the relationship of all of those things. What you're really saying is that the filesystem API/UI is simpler than a DVCS API/UI. My argument is that, a filesystem can be reduced to a simpler UI because it does fewer things. We may not have found the simplest possible DVCS API yet, but it by nature is going to have to be more complicated.
army 13y ago
DVCS's solve a hard problem where there isn't a single obvious way of thinking about it. There's no easy solution to managing multiple concurrent streams of development. And everyone has their own different ideas about what's the best way to solve it. I've used tools that are "simpler" than git: subversion for one. My experience has been that this simply means that they don't handle more difficult version control scenarios that do occur in practice. Subversion, in particular, just has a tendency to throw up it's hands and leave you to manually merge changes in any non-trivial merge scenarios.
elwin 13y ago
DVCS is a relatively new technology. We're still figuring out the best ways of designing and using it. To continue your filesystem analogy, filesystems were invented sometime around 1960, but it was over 20 years before everyone settled on Unix-style filesystems, where files are just a sequence of bytes. Eventually, they realized implementing version control or record structures at the filesystem level was unnecessary. DVCS implementations may similarly grow more alike and become simpler.
- dingaling 13y ago
  > Eventually, they realized implementing version control or record structures at the filesystem level was unnecessary. I wouldn't say 'unnecessary'; it's more the case that the quick and dirty Unix and DOS solutions 'won' by deign of being easy for implementers & users. And ever since then we've been hacking-on the features that were lost because of this. Two features we lost: 1. Generational data groups, as on MVS. The OS automatically keeping a history of changes to the 'file' 2. Addressing any file as an RDBMS table, as on OS/400. Amazingly flexible.
  - qznc 13y ago
    1. is addressed by svn,git,etc and 2. is addressed by SQLite,BerkeleyDB,etc. The advantage of the user-space solution is that they are portable across OS boundaries, version management is independent of OS, and more diversity. How is it an advantage to put this stuff into the OS? ("in the OS" probably always means "in the kernel" in this context, not "in system user-space libraries")
hrktb 13y ago
I'm not sure to get the point. If you are relying on a tool to reach your end goal, you should be as familiar as needed for your purpose. I think the more you will rely on the tool, the more you should know it's inner workings. For your filesystem analogy, if your Python app uses the filesystem as a storage layer you should be clear about the features you expect. When a DOS user will come telling you his data is not stored, you'll have to explain you use long filenames with non compatible characters. And perhaps symlinks for your folders, or access control for user management. And suddenly "just store my data" is not good enough, you'll have to care how and with what limitations. For any abstraction you heavily rely on, eventually you'll have to understand where it leaks.
deleted 13y ago
[deleted]
jheriko 13y ago
yeah, as a rule a user shouldn't care about implementation details. to be fair this is mainly possible with git in my experience... but not always. my experience with hg has been positive in that regard
qznc 13y ago
Software development with more than one person is inherently a distributed system. People work on outdated versions and in parallel and conflicts arise. Development requires branching and merging. It is probably impossible to package this complexity into an easy UI. I like git, because it has a simple core model, but the UI could certainly be easier. Mercurials model is not so simple (e.g. multiple types of branches and commits), but the UI is easier. Subversions UI is even easier, but the model is so simple that some things are impossible (the distributed stuff). (can we assume on HN that people have understood "simple != easy"?)
- mrtngslr 13y ago
  There is only one type of commit in Mercurial. Please don't suggest otherwise. The commits form a directed acyclic graph (a DAG) and you expand the graph when you make new commits. Subsets of the graph can be said to belong to the same branch (a named branch, the ones you create with "hg branch"). By default all commits belong to the branch named "default". Any given subset of the commit DAG might have multiple heads (commits with no children), e.g., the subset of the DAG that is the "default" branch might have multiple heads representing multiple features that haven't been merged yet. To help you pick the right head when you update, diff, etc, you can give it a name — you add a bookmark to the head. The bookmark is just like a post-it you stick on your monitor saying "commit e9ade5b11421 is better known as fix-broken-build". It's just an alias for the commit ID, in the same way that a Git branch name is a convenient name for a commit. To be useful, bookmarks move when you make new commits. After 'hg update fix-broken-build', a 'hg commit' will move the "fix-broken-build" bookmark so it points to the newly created commit. This is again very similar to how a Git branch pointer will advance when you run 'git commit'. I hope that helps a bit!
gcb0 13y ago
Spot on. The whole thread can be summarized as "dev do not get either mercurial not git, complains they want to use git because they have more workflow articles on reddit to copy paste solutions"
smithzvk 13y ago
> Consider filesystems, which are also tools used to manage stored data. If I'm writing some Python thing, I don't proclaim to everyone that I'm storing my work on a ReiserFS volume, and I'm thrilled by the fact that ReiserFS indexes its metadata using a B+ Tree. I just store my data. No, but you do see thousands upon thousands of pages of text written about how to best use a shell to interface with the file system. This is what I think we are dealing with, we are on the cusp of actually having competent tools for the task of this collaborative, everybody works on their own computer but everything needs to be merged together in the end, and still work, thing that we have been doing for years. Give it a few years to settle down and either csh (Hg) or bash (Git) will win out and there will still be odd birds out there using sh (SVN) or zsh (Darcs) (feel free to permute those assignments to your taste).
- xradionut 13y ago
  Only one tool of each category will "win" out? That's a mighty dystopian future.
  - smithzvk 13y ago
    Well, sorry, but as I see it, that is kind of the way of things. The things that coexist/compete share ideas so strongly, due to chasing each other's features, that the things they were before cease to be and they usually, eventually, converge, at least in a functional sense which is all that matters to users. That or one is forced into a minority status. Not really dystopia in either scenario.
    - xradionut 13y ago
      All restaurants are Taco Bell is what you want. :)
asdasf 13y ago
That is primarily a git thing. And the reason is that your main assertion was not true for the primary developer of git. "The project is what we are interested in: the Python or C++ or LaTeX or whatever" was not the case for Linus, messing with VCS and patchsets is precisely what he was interested in, that's basically all he does.
brendoncrawford 13y ago
A skilled painter cares about the origins and chemistry of the minerals and oils used in his/her paints. A skilled guitarist cares about whether the pickups were made with alnico or ceramic magnets. A skilled knife-maker cares about the type of stone used for grinding steel. Tools are important to the craftsman. Plus, some people care about the entire process of building and not just the final product.

venomsnake 13y ago

All software has its quirks. And it shows when you move out of the ultra comfort zone. If you want to drill a hole in the wall you need to take into consideration the size of the hole, the power of the drill and what are you drilling in. You cannot abstract them. And then one day someone decides to use your python code not on ReiserFS but on Ext2 that has no journaling and all hell could break loose.

migrantgeek 13y ago

If you're just storing data, your analogy is fine. It breaks down with more advanced usage like integrations which can be very difficult with large teams. I manage a VCS with thousands of developers committing to a large code base. The VC system starts to really matter and you have to understand how it handles things like conflict resolution or things can get out of hand really quickly.

gkoberger 13y ago

Taking your logic a bit further: the final product is what we (should be) interested in. Python or C++ or LaTeX or whatever are just to help us make it. Everything else, whether it be Python or git or C++ or Mecurial or vim or Windows or an ergonomical mouse, is just there to help us make the final product in an easy and quality manner. I don't see a problem with worrying about git any more than I see one with worrying about Python. Change for the sake of change is bad, but change for the sake of an improved workflow is good.

ggchappell 13y ago
That's an interesting point. Here are my off-the-top-of-my-head thoughts: I guess the real goal is proper separation of responsibilities. When I cook a meal, I use devices that run on electricity. I want to be able to power them up by plugging them in without thinking much about it. The people who work at my power company need to think about the intricacies of generating and transmitting electricity, but I don't want to. On the other end, the people who eat the food I cook should not have to worry about the use of a stove timer or a rice cooker. Similarly, when I put together a software package, I am functioning as a programmer/software designer. I am interested in the code, how it is structured, and what it is supposed to do. Time spent worrying about storage & version management is generally time spent away from my primary task. Someone needs to worry about that, but, for the most part, I don't think it should be me. The users of the package I write just want to use it. They care that it does what they want. The fact that it is written in Python, developed using agile methods, etc. are irrelevant to them. (But not to me, as a programmer.) And maybe for the users, the software is a tool to help them in their business. The customers of that business probably should not care about the software at all; they just want whatever service the business provides.
- jlgreco 13y ago
  Even when powering electronics in the home, you have to worry about which sort of power the device needs. Does it need a great big 240V AC outlet, or just the regular 120V AC (using American values...)? Is the device DC powered instead? Does it have it's own wall-wart, or can you use a AC->USB converter? Does it use USB micro or mini? These are things the consumer has to worry about. Of course in practice "worry about" is an exaggeration; this is all pretty elementary stuff and no reasonably intelligent consumer actually loses sleep over it. The matter of what version control to use? The consumer never has to worry about that. That concern is something that only developers (and related professionals) will have to worry about. I don't think it is a big deal. Just pick whatever fits your needs and that you prefer. Should the developer have to know anything about version control? I don't know, should the electrical have to know anything about multimeters, outlet testers, and wire cutters?

asdfaoeu 13y ago

I can see your point but the fundamental problem is that unless you have a simple linear history a DVCS can't possibly know how to merge and apply patches without some heuristics. At best the DVCS can be a tool to assist you. There is of course a lot of simple tasks which DVCS can and do apply near perfectly but I suppose managing a complex project you're at some point going to have to have a basic understanding of how the system works. I've used IBM's RTC which is an excellent GUI VCS tool that I believe internally works similar to git/hg but it attempts to hide how its internals works so on a large merge 500+ changesets and then remerging more commits it refused to push despite saying no incoming changesets. We ended up fixing it by pulling to a different repository based of the branch we were trying to merge from based of advice from support. But I'd prefer a deterministic cli interface over a gui interface anyday.

ams6110 13y ago

Articles like this make me wonder if I'm stupid. 95% of the time all I ever do is commit my work and push/pull, whether I'm using svn, git, or hg. I just hardly ever find myself needing to understand anything more complicated than that. Why does it seem like everyone else has spent thousands of hours understanding esoteric git or hg incantations that I've never encountered the need for.

jlgreco 13y ago
Are you working with a large team? I find that tends to be when your "VCS muscles" really start to get exercised.
- ams6110 13y ago
  I suppose it depends on what you consider large. At the moment my team is 3 who are doing daily work, and a few more that do more intermittent work. I'd consider that to be small. I have in the past worked on larger teams (~15 developers), that project used svn and we never seemed to really run into any issues even though we had branches for mainline dev work, and support branches for each "released" version. I'd get the occasional conflict to resolve but it generally wasn't too bad, and I get those with Git also. I've never worked on a project where dozens or hundreds of remote developers were contributing, but I'd say that outside of a small number of high-profile open-source projects, most people don't. I understand that's what git was built for; maybe that's why all those features just seem like overkill for anything I've never worked on.
  - jlgreco 13y ago
    I guess 'large' is really a function of number of developers and rate and diversity of commits. I've been in a few situations where two or three of us were putting out several changes to the same piece of code rapidly (typically to meet a deadline). Git has proven invaluable in untangling some of the knots we've put ourselves into in those sorts of situations. If commits are coming in slowly, with plenty of notice, and everyone is working on different parts of the codebase, then you probably won't need to do much fancy stuff very often.

natrius 13y ago

Code is read more than it is written. Version control systems provide tools to make it simpler to read code and understand why it was written. Version control systems also define how you branch and merge, which are are hugely important concerns if you're working on a team, and still pretty important if you're working alone. Git handles branches and history management better than Mercurial does for my needs, and it makes a huge difference to me.

kasey_junk 13y ago
Just curious, what about Git's branches and history management is better than Mercurials with the appropriate plugins turned on? I've been able to successfully replicate all the Git use cases I can think of in Mercurial even if I think they are bad practices. Conversely, nothing I do makes git's cli anywhere near as good as hg. For me, that is the single biggest glaring problem with Git. I spend a very small minority of my time handling complicated history/branch issues as part of my major workflow and I spend an inordinate amount of time working with the interface to my source control. Git seems optimized for the minority case.
- steveklabnik 13y ago
  I a not mega familiar with mercurial, but I was under the impression that culturally, rebasing is considered bad. Yes, there is a rebase plug-in, but mercurial users don't generally think it's a good idea to mutate history. Git users tend to branch, make a ton of commits, then clean them up using rebase and then merge and push. hg users tend to... not? I may be _entirely_ off base here. (personally I find git's command line to be fantastic, but I often feel like I'm the only one.)
  - functional_test 13y ago
    Exactly. Although rebasing is convenient, it does involve taking destructive actions on a repository which is ostensibly a tool to make sure your data isn't lost. The feeling in the Mercurial community is that this is potentially dangerous and not necessary. Really, it would be best if there was some way to retain the original commits while rebasing to clean the history. Time for a new DVCS?

thatthatis 13y ago

A filesystem is a tool we use to track and store data related to a project. A DVCS is a tool we use to track and store data related to a project, collections of that data, changes in that data over time, changes in that data made by others, pointers to certain states, and the relationship of all of those things. What you're really saying is that the filesystem API/UI is simpler than a DVCS API/UI. My argument is that, a filesystem can be reduced to a simpler UI because it does fewer things. We may not have found the simplest possible DVCS API yet, but it by nature is going to have to be more complicated.

army 13y ago

DVCS's solve a hard problem where there isn't a single obvious way of thinking about it. There's no easy solution to managing multiple concurrent streams of development. And everyone has their own different ideas about what's the best way to solve it. I've used tools that are "simpler" than git: subversion for one. My experience has been that this simply means that they don't handle more difficult version control scenarios that do occur in practice. Subversion, in particular, just has a tendency to throw up it's hands and leave you to manually merge changes in any non-trivial merge scenarios.

elwin 13y ago

DVCS is a relatively new technology. We're still figuring out the best ways of designing and using it. To continue your filesystem analogy, filesystems were invented sometime around 1960, but it was over 20 years before everyone settled on Unix-style filesystems, where files are just a sequence of bytes. Eventually, they realized implementing version control or record structures at the filesystem level was unnecessary. DVCS implementations may similarly grow more alike and become simpler.

dingaling 13y ago
> Eventually, they realized implementing version control or record structures at the filesystem level was unnecessary. I wouldn't say 'unnecessary'; it's more the case that the quick and dirty Unix and DOS solutions 'won' by deign of being easy for implementers & users. And ever since then we've been hacking-on the features that were lost because of this. Two features we lost: 1. Generational data groups, as on MVS. The OS automatically keeping a history of changes to the 'file' 2. Addressing any file as an RDBMS table, as on OS/400. Amazingly flexible.
- qznc 13y ago
  1. is addressed by svn,git,etc and 2. is addressed by SQLite,BerkeleyDB,etc. The advantage of the user-space solution is that they are portable across OS boundaries, version management is independent of OS, and more diversity. How is it an advantage to put this stuff into the OS? ("in the OS" probably always means "in the kernel" in this context, not "in system user-space libraries")

hrktb 13y ago

I'm not sure to get the point. If you are relying on a tool to reach your end goal, you should be as familiar as needed for your purpose. I think the more you will rely on the tool, the more you should know it's inner workings. For your filesystem analogy, if your Python app uses the filesystem as a storage layer you should be clear about the features you expect. When a DOS user will come telling you his data is not stored, you'll have to explain you use long filenames with non compatible characters. And perhaps symlinks for your folders, or access control for user management. And suddenly "just store my data" is not good enough, you'll have to care how and with what limitations. For any abstraction you heavily rely on, eventually you'll have to understand where it leaks.

deleted 13y ago

[deleted]

jheriko 13y ago

yeah, as a rule a user shouldn't care about implementation details. to be fair this is mainly possible with git in my experience... but not always. my experience with hg has been positive in that regard

qznc 13y ago

Software development with more than one person is inherently a distributed system. People work on outdated versions and in parallel and conflicts arise. Development requires branching and merging. It is probably impossible to package this complexity into an easy UI. I like git, because it has a simple core model, but the UI could certainly be easier. Mercurials model is not so simple (e.g. multiple types of branches and commits), but the UI is easier. Subversions UI is even easier, but the model is so simple that some things are impossible (the distributed stuff). (can we assume on HN that people have understood "simple != easy"?)

mrtngslr 13y ago
There is only one type of commit in Mercurial. Please don't suggest otherwise. The commits form a directed acyclic graph (a DAG) and you expand the graph when you make new commits. Subsets of the graph can be said to belong to the same branch (a named branch, the ones you create with "hg branch"). By default all commits belong to the branch named "default". Any given subset of the commit DAG might have multiple heads (commits with no children), e.g., the subset of the DAG that is the "default" branch might have multiple heads representing multiple features that haven't been merged yet. To help you pick the right head when you update, diff, etc, you can give it a name — you add a bookmark to the head. The bookmark is just like a post-it you stick on your monitor saying "commit e9ade5b11421 is better known as fix-broken-build". It's just an alias for the commit ID, in the same way that a Git branch name is a convenient name for a commit. To be useful, bookmarks move when you make new commits. After 'hg update fix-broken-build', a 'hg commit' will move the "fix-broken-build" bookmark so it points to the newly created commit. This is again very similar to how a Git branch pointer will advance when you run 'git commit'. I hope that helps a bit!

gcb0 13y ago

Spot on. The whole thread can be summarized as "dev do not get either mercurial not git, complains they want to use git because they have more workflow articles on reddit to copy paste solutions"

smithzvk 13y ago

> Consider filesystems, which are also tools used to manage stored data. If I'm writing some Python thing, I don't proclaim to everyone that I'm storing my work on a ReiserFS volume, and I'm thrilled by the fact that ReiserFS indexes its metadata using a B+ Tree. I just store my data. No, but you do see thousands upon thousands of pages of text written about how to best use a shell to interface with the file system. This is what I think we are dealing with, we are on the cusp of actually having competent tools for the task of this collaborative, everybody works on their own computer but everything needs to be merged together in the end, and still work, thing that we have been doing for years. Give it a few years to settle down and either csh (Hg) or bash (Git) will win out and there will still be odd birds out there using sh (SVN) or zsh (Darcs) (feel free to permute those assignments to your taste).

xradionut 13y ago
Only one tool of each category will "win" out? That's a mighty dystopian future.
- smithzvk 13y ago
  Well, sorry, but as I see it, that is kind of the way of things. The things that coexist/compete share ideas so strongly, due to chasing each other's features, that the things they were before cease to be and they usually, eventually, converge, at least in a functional sense which is all that matters to users. That or one is forced into a minority status. Not really dystopia in either scenario.
  - xradionut 13y ago
    All restaurants are Taco Bell is what you want. :)

asdasf 13y ago

That is primarily a git thing. And the reason is that your main assertion was not true for the primary developer of git. "The project is what we are interested in: the Python or C++ or LaTeX or whatever" was not the case for Linus, messing with VCS and patchsets is precisely what he was interested in, that's basically all he does.

brendoncrawford 13y ago

A skilled painter cares about the origins and chemistry of the minerals and oils used in his/her paints. A skilled guitarist cares about whether the pickups were made with alnico or ceramic magnets. A skilled knife-maker cares about the type of stone used for grinding steel. Tools are important to the craftsman. Plus, some people care about the entire process of building and not just the final product.