1. 20

    Sad :-( I still think Mercurial far better meets the needs of most people, and that the chief reasons for git’s popularity are that Linus Torvalds wrote it, GitHub, and that Linus Torvalds wrote it.

    That said, I did end up switching from BitBucket/mercurial to GitHub/git a few years ago, simply because it’s the more pragmatical thing to do and I was tired of paying the “mercurial penalty” in missed patches and the like. I wrote a thing about it a few ago: https://arp242.net/git-hg.html

    1. 6

      Why do you think hg is better for most people? I honestly find it vastly more complex to use.

      1. 15

        The hg cli is light years ahead of git in terms of intuitiveness.

        1. 6

          I’d say it’s years behind ;)

          1. 10

            How long have you been using Mercurial? I find most people who dislike Mercurial’s UI, are mainly coming from years of experience with Git. I disliked Mercurial at first as well, but after a few years of forced usage it clicked. Now I appreciate how simple and well composed it is and get frustrated whenever I need to look up some arcane Git flag on StackOverflow.

            In general, I’d say you need several years experience with both Git and Mercurial before you can draw a fair comparison.

            1. 3

              I used mercurial for about 2 years before using git.

              1. 3

                Sorry if my post came across a bit accusatory (not my intent). In that case I guess to each their own :).

              2. 3

                but after a few years of forced usage it clicked.

                I’m pretty sure that git clicked for me in a much shorter timeframe.

                1. 1

                  Me too, but I know many (otherwise perfectly competent engineers) 5-10 years in who still don’t get it and aren’t likely to.

              3. 9

                I’m going to strongly disagree. I’ve used git intensively and I find Mercurial to be a well-designed delight. I’ve run across features that Mercurial supports flawlessly, with a nice UI, and Git requires a hacky filter-branch that takes hours to run and doesn’t even behave correctly.

                IMO, a lot of the badness in projects is down to Git badness. it doesn’t scale and people feel compelled to break things down into tiny sub-projects.

                The only reason Git is winning anything is GitHub’s support of it.

                1. 3

                  The only reason Git is winning anything is GitHub’s support of it.

                  Why then was github ever used in the first place? Kind of a strange proposition.

                  1. 1

                    Network effect of the social network is pretty important.

                    1. 1

                      Why would there ever be a network effect in the first place if git was so bad that github was the only reason to use it. I get that the argument technically holds but it seems very unlikely.

            2. 8

              You find mercurial more complex to use than git? That’s an… unusual view, to say the least. The usual recitation of benefits goes something like this

              • Orthogonal functionality in hg mostly has orthogonal commands (compare git commit, which does a half-dozen essentially unrelated different things).
              • hg has a somewhat more uniform CLI (compare git branch -a, git remote -v, git stash list).
              • hg either lacks or hides a bunch of purportedly-inessential and potentially confusing git functionality (off the top of my head, partial commits aren’t baked into the flow a la git’s index/staging area; and rebasing and history rewriting are hidden behind an extension).

              I personally prefer git, but not because I think it’s easier or simpler; I’m more familiar with it, and I find many of those purportedly-inessential functions to be merely purportedly, not actually, inessential.

              1. 5

                One more thing I like about mercurial that the default set of commands is enough for >90% of people, and that everything else is “hidden” in extensions. This is a very different approach than git’s “kitchen-sink” approach, which gives people 170 commands (vs. Mercurial’s 50, most of which also have much fewer options/switches than git).

                Git very much feels like “bloatware” compared to Mercurial.

                1. 3

                  I used git for many years, and then mercurial (at FB) ever since we switched over. The cli interface for mercurial is definitely more sensible, crecord is delightful, and overall it was fine. But I was never able to build a mental model of how mercurial actually worked. git has a terrible interface, but it’s actually really simple underneath.

                  1. 1

                    I didn’t think that underneath they were different enough to matter much. What differences do you mean? I guess there’s git’s remote tracking stuff. Generally, it seems like they differ in how to refer to and track commits and topological branches, locally and remotely. (IMHO, neither has great mechanisms for all the things I want to do.) Mercurial is slightly more complex with the manifest, git is more complex with the staging area that feels absolutely critical until you don’t have it (by using hg), at which time you wonder why anyone bothers with it. I’m a heavier hg user than git user, but that’s about all I can come up with.

                  2. 2

                    You find mercurial more complex to use than git?

                    I actually found – in a professional shop – mercurial far more complex to use. Now, the fact is that mercurials core – vanilla hg is IMHO absolutely without doubt vastly superior to git. Git keeps trying to make the porcelain less painful (including a release just a bit ago) – but I still think it is ages behind.

                    The problem is – I never used vanilla mercurial in a professional environment. Not once. It was always mercurial++ (we used $X extension and $Y extension and do it like $Z) which meant even if I knew hg, I felt painfully inexperienced because I didn’t know mq, share, attic, collapse, evolve, and more… not to mention both the bigger shops I worked with using mercurial has completely custom workflow extensions. I suspect part of this was just the ease of writing mercurial extensions, and part of it was wanting to fall into a flow they knew (mq, collapse). But, regardless of how we got there, at each place I effectively felt like I had to relearn how to use the version control system entirely.

                    As opposed to git, wherein I can just drop in and work from day one. It might be less clean, it might be more finicky and enable things like history rewriting by default. But at the end of the day, the day I start, I know how to generally function.

                    I am curious how Mercurial would have faired if instead of shipping default extensions you had to turn on – if they had just baked a little more functionality, to try to cover the 80% of what most shops wanted (not needed, I think most could have gotten by with what vanilla mercurial had) – if the shop to shop transition would have been easier.

                    1. 2

                      mq, I think, is responsible for many of the “mercurial is too complicated” complaints people have. Evolve, if it ever stabilized and ships with core hg would really enable some killer capabilities. Sadly for social and technical reasons it’s perpetually in beta.

                    2. 1

                      whoa, no index? Admittedly I didnt really use index as intended for several years, but now its an important part of my workflow.

                      1. 1

                        In Mercurial, commits are so much easier to make and manipulate (split, fold, move), that you don’t miss the index. The index in git is just a limited special cased “commit”.

                        1. 3

                          The index in git is just a limited special cased “commit”.

                          I disagree.

                          The index is a useful way to say “these lines of code are ready to go”. If you are making a big commit, it can be helpful to add changes in logical blocks to the index as you go. Then the diff is not polluted with stuff you know is already fine to commit.

                          You might say, “why not just make those changes their own commits, instead of trying to do one big commit?” That’s a valid question if you are talking about a 200 line commit or similar, but sometimes the “big” commit is only 50 lines. Instead of making a bunch of one line or few line commits, its helpful to “git add” small chunks, then commit at the end.

                          1. 0

                            You can as well amend to a commit instead of adding to the index.

                            1. 3

                              True, but all thats doing is bastardizing the commit process. If you are committing a one line change, just to rebase minutes or hours later, thats not a commit.

                              Rebase to me is for commits that were intended to be commits, but later I decided it would be better to squash or change the history. The index is for changes that are never meant to be a full commit on their own.

                              1. 1

                                Having a distinction between draft and published phases in mercurial I think makes it easier to rewrite WIP work. There’s also a number of UI affordances for it. I don’t miss the index using mercurial. There’s also academic user interface research that shows the index is a big conceptual barrier for new users.

                                1. 1

                                  There’s also academic user interface research that shows the index is a big conceptual barrier for new users.

                                  this isnt really a valid point in my opinion. some concepts are just difficult. if some goal can be achieved in a simpler way i am on board, but I am not a fan of removing useful features because they are hard to understand.

                                  1. 1

                                    But the point is the index is hard to understand and unnecessary.

                                    There’s no need to have a “commit process”. Just commit whatever you want and rewrite/amend it for as long as you want. As long as your commits are drafts, this is fine.

                                    Is the problem the word “commit”? Does it sound too much like commitment?

                                    There’s no need to have two separate ways to record changes, an index, and a commit, each with different degrees of commitments. This is multiplying entities beyond necessity.

                                    1. 1

                                      That’s your opinion. The index is quite useful to me. I’d rather make a proper commit once it’s ready, not hack together a bunch of one line commits after the fact.

                                      1. 2

                                        The index is a commit. Why have two separate ways of storing the same sort of thing?

                                        Also, it’s not my opinion that it’s hard to understand and unnecessary; it’s the result of usability studies:

                                        https://spderosso.github.io/oopsla16.pdf

                                        You’re also not “hacking together” anything after the fact. There’s no more hacking together after the fact whether you use git amend (hypothetically) or git add. Both of those mean, “record additional changes”.

                                        1. 0

                                          It seems you have a fundamental misunderstanding of the difference between add and commit. Commit requires a commit message.

                                          1. 1

                                            This isn’t a useful distinction. You can also create commits with empty commit messages in both git and Mercurial.

                                            With both git and Mercurial you can also amend commit messages after the fact. The index in git could well be implemented as a commit with an empty commit message that you keep amending and you wouldn’t notice the difference at all.

                                            1. 1

                                              you keep amending and you wouldn’t notice the difference at all.

                                              yeah, you would. again it seems that you either dont know git, or havent used it in some time. when you amend a commit, you are prompted to amend the message as well. another facet that doesnt exist with git add, because add doesnt involve a message.

                                              if you wish to contort git internals to suit your agenda thats fine, but git add has perfectly valid use cases.

                                              1. 0

                                                you are prompted to amend the message as well.

                                                This is UI clutter unrelated to the underlying concepts. You can get around that with wrappers and aliases. I spoke of a hypothetical git amend above that could be an alias that avoids prompting for a commit message.

                                                Don’t git users like to say how the UI is incidental? That once you understand the data structures, everything else is easy? The UI seems to have locked you into believing the index is a fundamentally necessary concept, but it’s not. It’s an artifact of the UI.

                                                1. 1

                                                  The UI seems to have locked you into believing the index is a fundamentally necessary concept, but it’s not.

                                                  Nothing has locked me into believing its a necessary concept. Its not necessary. In fact, for about 7 years I didnt use the index in any meaningful way.

                                                  I think what you are missing is that Im not compelled to use it because its the default workflow, I am compelled to use it because its useful. It helps me accomplish work more smoothly than I did previously, when I would just make a bunch of tiny commits because I didnt understand the point of the index, as you still dont.

                                                  The argument could be made to move the index into an option, like somehow make commit only the default workflow. Im not sure what that would look like with Git, but I dont think its a good idea. It would just encourage people to make a bunch of smaller commits with meaningless commit messages.

                                            2. 1

                                              You have a set of things you want to accomplish. With git, you have N+1 concepts/features/tools to work with. With hg, you have N (because you drop the index). That means you have to expand your usage of the remaining N.

                                              Specifically, since you no longer have this extra index concept, you now expand commits to cover the scenarios you need. Normally, you’d make an initial commit and then amend a piece at a time (probably with the interactive curses hunk selector, which is awesome.) If you’re unsure about some pieces, or you have multiple things going on that you’d like to end up in separate commits, you can always make a series of microcommits and then selectively collapse them later. (In practice, it’s even easier than this, because of the absorb extension. But never mind that.)

                                              Yes, those microcommits need commit messages. They don’t need to be good ones, because they’re temporary until you squash them out of existence. I usually use a one word tag to specify which of the separate final commits they belong to. (If you don’t have separate final commits, you may as well amend, in which case no messages are needed.)

                                              …or on the other hand, maybe mercurial ends up with N+1 concepts too, because phases really help in keeping things separate. As I understand it, one reason git users love the index is because it keeps rapidly changing, work in progress stuff separate from mostly set in stone commits. Phases perform the same purpose, but more flexibly, and the concepts are more orthogonal so they compose better. In my opinion.

                    3. 6

                      I never particularly liked git and find it unintuitive, too.

                      I wouldn’t consider myself a git poweruser. But whenever I had to work with alternatives I got the feeling that they’re just inferior versions of git. Yeah, maybe the usage was a bit more intuitive, but all of them seemed to lack things that I’d consider really basic (bisecting - hg has that, but e.g. svn has not - and shallow copying - not avaible in hg - are examples what I often miss).

                      1. 3

                        Mercurial was actually my first DVCS, and like you I ended up switching to git not out of a sense that it was technically better, just more pragmatic. For me, the change is more of a mixed bag, though. It is definitely the case that Mercurial’s UI is worlds better, and revsets in particular are an amazing feature that I sorely miss, but when I made the switch I found that the way git handles branches was much more intuitive to me than Mercurial’s branch/bookmark system, and that the affordances around selectively editing commit histories were very much worth the risk in terms of being able to manage the narrative of a project’s history in a way that makes it more legible to others. Ultimately, I found that git’s advantages outweighed its downsides for my use case, since learning its UI idiosyncrasies was a one-time cost and since managing branches is a much more common occurrence for me than using revsets. That said, I think this is a really unfortunate development.

                        1. 2

                          I occasionally convert people’s git repos to hg for my use. Stubborn like that.

                        1. 17

                          I agree with the author, git concepts are non-orthogonal and subtle. When I think of quality UI software, I don’t think of git.

                          That being said, I would not get rid of the index. The index is the primary reason I use git. I think git add -p is an invaluable tool. If you don’t use it, you’re missing out.

                          1. 13

                            I agree that git is awful to learn, but removing staging seems unnecessary. Even worse, they use funky flags where git uses commands, and they did away with push/pull in favor of publish/???.

                            I’m not impressed. I’ll stick with git and will continue to teach people how to use git instead of some seemingly better shell.

                            1. 3

                              Yeah, it didn’t really feel to me like they changed much fundamentally. They just added some superficial aliases so you don’t have to run as many commands. I’ll write my own aliases when I need them.

                            2. 8

                              I’m perfectly happy using mercurial, which doesn’t have a staging area. Whenever I use git, I get annoyed because it has this extra useless concept. Mercurial has “hg commit -i”, which is analogous to “git add -p”, to commit only a subset of the changes to the working directory.

                              1. 5

                                I’ve always found a lot of utility in being able to stage certain things at once. Sometimes I make large changes without thinking about actual commits until I get to the end of a workstream, and having that all as one commit just seems generally not great, especially when there are atomic components that were tangentially related to the main work at best (like cleaning up a configuration file, or refactoring a particularly hairy section of code).

                                Mainly breaking things up like that seems like the courteous thing to do for your fellow developers, because that way if you’re ripping out a large component and want to do it quickly with reverts, you don’t pull out the secondary changes by accident too. And you can also generally write better, more relevant commit messages too.

                                1. 5

                                  You can do that workflow in mercurial as well using “hg histedit” and “hg commit –amend”.

                                  Having a staging area isn’t related to the workflow and just adds another concept to learn when learning or teaching the tool.

                                  1. 7

                                    You can also do git commit --amend if you want to amend a commit, however you don’t have a tool for implementing a commit queue in hg.

                                    If I have four things I’ve touched and I want to commit them separately, I want to verify that each of these things are in fact separate commits. I do not want to commit four things, and then try to uncommit them, and re-commit them once I’ve figured out what they should look like.

                                    In git, I can add -p the first one, then stash the rest, run my program and verify it works as I expect, then commit just that staged bit (or change it some more). Then I can pop the stash and move on to the next commit.

                                    This concept is useful to me. I can emulate it by creating four separate branches, or by copying my files around, but I find it actually useful to think in terms of the git concept of a stage so that this kind of committing is obvious to me. Tools that generate new intuition to the programmer are like candy to me.

                                    1. 2

                                      Given that I very much use hg with a commit queue, I can’t really agree, though I haven’t tried it much with the base command set (I use evolve).

                                      Still, the way I do something like that is to make my commits, then update to the first commit and test, then update to the next commit (by hash or using the children(.) revset) and test, etc. Then I can land any or all of them with one push. None of that requires evolve, btw, but in practice I will usually find that I’ve mixed up the changes a bit and have to move pieces between them, and that’s much easier to do with evolve and ©histedit.

                                      You’re using the stage+stash as your queue / working area. I’m using the actual dag. When doing so, it’s easy to get mixed up with what is “current work” vs stuff I’m basing the current work on, but hg has phases, which make it easy to distinguish work in progress vs base. (I uses aliases for it, but hg log -r 'not public() and only(.)' gives you a basic patch queue listing.)

                                      1. 1

                                        In git, I can add -p the first one, then stash the rest, run my program and verify it works as I expect, then commit just that staged bit (or change it some more). Then I can pop the stash and move on to the next commit.

                                        I find this the most confusing part of git, fwiw. I can never remember whether stash is going to stash changes that have been added or just changes that have not. Worse, stashing and unstashing seems to change which things have been added, which breaks my mental model of what stash is supposed to do.

                                        1. 4

                                          which breaks my mental model of what stash is supposed to do.

                                          This is a variation on the “X isn’t intuitive”, and it doesn’t really offer any option to me in having a discussion about it.

                                          Can I agree that the user-interface is bad without also agreeing that we need to hide/get-rid-of the index?

                                          I can never remember whether stash is going to stash changes that have been added or just changes that have not. Worse, stashing and unstashing seems to change which things have been added

                                          Read the manual page carefully. The first sentence begins: Use git stash when you want to record the current state of the working directory and the index, but want to go back to a clean working directory and that’s exactly what it does, but you need to understand what the index is.

                                          The thing that I’m referring to is mentioned: If the --keep-index option is used, all changes already added to the index are left intact and that -p implies this.

                                          1. 1

                                            This is a variation on the “X isn’t intuitive”, and it doesn’t really offer any option to me in having a discussion about it.

                                            Ok, I’ll be specific. The man page says: “Remove a single stashed state from the stash list and apply it on top of the current working tree state, i.e., do the inverse operation of git stash save. The working directory must match the index.”

                                            $ git status
                                            # On branch master
                                            # Changes to be committed:
                                            #   (use "git reset HEAD <file>..." to unstage)
                                            #
                                            #       modified:   foo
                                            #
                                            # Changes not staged for commit:
                                            #   (use "git add <file>..." to update what will be committed)
                                            #   (use "git checkout -- <file>..." to discard changes in working directory)
                                            #
                                            #       modified:   bar
                                            #
                                            $ git stash
                                            Saved working directory and index state WIP on master: b12ed82 test
                                            HEAD is now at b12ed82 test
                                            $ git stash apply
                                            # On branch master
                                            # Changes not staged for commit:
                                            #   (use "git add <file>..." to update what will be committed)
                                            #   (use "git checkout -- <file>..." to discard changes in working directory)
                                            #
                                            #       modified:   bar
                                            #       modified:   foo
                                            #
                                            no changes added to commit (use "git add" and/or "git commit -a")
                                            

                                            This is not what the word “inverse” conventionally means; it is extremely confusing to have an operation described as an “inverse” that doesn’t actually invert the thing it is supposedly the inverse of.

                                            Can I agree that the user-interface is bad without also agreeing that we need to hide/get-rid-of the index?

                                            I don’t think so, unless you have a better proposal for how to improve it.

                                            1. 3

                                              it is extremely confusing to have an operation described as an “inverse” that doesn’t actually invert the thing it is supposedly the inverse of.

                                              I don’t see why that means I have to agree that the index is bad.

                                              Can I agree that the user-interface is bad without also agreeing that we need to hide/get-rid-of the index?

                                              I don’t think so, unless you have a better proposal for how to improve it.

                                              “People understand things I don’t, so we need to get rid of them”.

                                              I find that attitude really off-putting.

                                              1. 1

                                                I don’t see why that means I have to agree that the index is bad.

                                                Well, the part that it doesn’t invert is the index. As far as I can see the index causes this problem and removing it would solve the problem.

                                                “People understand things I don’t, so we need to get rid of them”.

                                                That’s not what I’m saying (and I’ll thank you not to put words in my mouth). To agree the user-interface is bad, you must believe a better user-interface is possible (otherwise the idea of “bad” is meaningless). To believe that a better user-interface is possible you must believe that a specific possible alternative user-interface is better. If you don’t believe gitless is better, which possible alternative user-interface do you believe is better?

                                                1. 1

                                                  This is where git stash –keep-index comes in handy. Stash then only would apply to changes to bar.

                                                  1. 1

                                                    Sure, and apparently there’s also a flag to the load to restore changes to the index. But neither of these is the default; fundamentally, stash is clearly confused about whether it’s operating on the index or the working copy or both. If even git’s own commands can’t get staged vs unstaged straight, what hope do us poor users have?

                                                    1. 1

                                                      I won’t argue that git is the most intuitive tool by any means, but it does have the ability to address the needs at the least.

                                                      That said, the git log man page to this day, after 9 years of use still contains things I don’t understand after having read through it numerous times.

                                        2. 1

                                          Both the mq and the shelve extension implement commit queues for hg and they come with hg’s default installation. Commit queues are a power user so it’s fine if this isn’t front and center for a new user yet but they are definitely there.

                                    2. 4

                                      Tools give us power and allow us to be individually more efficient, but they require we learn new skills which can take time and make us struggle which is not something many intermediate programmers are used to.

                                      To paraphrase:

                                      I’m perfectly happy using basic which doesn’t have lambdas or macros. Whenever I use lisp, I get annoyed because it has this extra useless concept. Basic has goto and gosub which is analogous to the use of lambadas and functions that I want to use.

                                      The real issues are whether, having this tool of thought you are more efficient (I am; others say they are) enough to make it worth learning (Others are more convinced than me on this point) or worth fighting inertia (i.e. Git is popular, so it is useful to think in git so that I’m better able to work in git).

                                      As a specific example, I never want to hg commit -i in git – I’ve checked my history and I’ve never typed git commit -p (which works the same way), and I noticed whenever I use git add -p it’s followed by a git stash so I’m pretty certain my goal is to make sure that my single staged commit works in isolation (i.e. if someone just cherry picks this commit, will it work?) This is important because we don’t really have patches in git (which actually solve this problem).

                                      1. 5

                                        I wonder how we can better talk about this conflict. Is the investment of learning worth the trouble in later efficiency? We talk about usability often without putting it into context. Git is worth learning for a developer, because you use it everyday. The banking website that you use once a month should be much more aligned with the concepts that you can be expected to know, even if that makes you ineffective.

                                        1. 1

                                          This is something I often wonder about.

                                          Too many people respond to things they do not understand with an opinion about them: How much they don’t like them. When I see someone do something I cannot do, I want to learn how they do it; If someone can program faster, and their programs are shorter or more correct than mine, I want to know how.

                                          If they say “I use the git index”, then I know I need to learn it. Whatever opinion I might have had goes right out the window at that point.

                                        2. 2

                                          The need is not to have a stage or stash or whatever. As the paper says, there are highlevel goals that developers want to accomplish. The stage and stash are tools that can be used to accomplish those goals, but there are a number of other ways. And you can design systems with more or fewer separate concepts. I prefer systems with fewer concepts that can be used in flexible ways. For that reason, I prefer using the straight dag as much as possible, and figuring out the minimum necessary extensions needed to make the dag handle my goals. The stage feels like a big separate concept to me – not wrong, really, but big and different and I’d rather eliminate it if possible. Similarly, the stash feels like it explodes out the set of possible states unnecessarily. You need some extra states, but I’d rather express them in terms of dag nodes than some completely different thing.

                                          Honestly, I’d like to think of my working directory state as just another node in the dag, one whose hash and exact contents are only determined when necessary. I should be able to use it the same way as any other node in the graph. True, if you go whole hog on immutability, then you need to record a hash for every single keystroke that modifies a file, but I like to think of not having those nodes as an optimization on top of the conceptual dag containing them. And it turns out that you kind of want the same optimization for other nodes – for example, if you rebase a patch stack on top of upstream changes a dozen different times, then all those intermediate nodes (almost length of patch stack x number of rebases of them) are similarly uninteresting, and I would happily discard them even if it means edges in the dag sometimes represent more than one intermediate (garbage collected) node.

                                          1. 1

                                            The need is not to have a stage or stash or whatever.

                                            I certainly don’t have this need, to “not have a stage or stash or whatever” and so I reject the theory that this need exists.

                                            there are highlevel goals that developers want to accomplish

                                            I think this kind of thinking leads to mistakes.

                                            I don’t want to accomplish any of them: I want to show my code to someone, or I want my feature to be on the production system. Everything else is a means to that end, and so I look at how I can do the things that I want. Tools enable that.

                                            I prefer systems with fewer concepts that can be used in flexible ways.

                                            If we say we should prefer hg because it is simpler than git, we are making a mistake. neither “git” nor “hg” are a calculus for version control, but both a set of very messy methods. If you want something mathematically satisfying – the scheme of version control, you should look at patch theory because it may fill that need.

                                            However I have things to do now, and that means I’m looking at the common lisps of the world, not the schemes: I want a robust vocabulary, so I can say what I mean, and get what I want; succinct enough to avoid errors, but I do not want to do version control in brainfuck either.

                                            Both git and hg are robust, but git is more robust. That’s important to me. Can you tell a computer what to do without an index? Sure, but there was a time when programmers used punch cards and paper tape. I certainly don’t want to return to that.

                                            I’d like to think of my working directory state as just another node in the dag,

                                            I’m not interested in this at all.

                                            1. 1

                                              I am not making most of the arguments you are disagreeing with. In fact, we are saying the same thing in your first two quotes. But never mind that.

                                              While to me, hg feels conceptually simpler yet equally powerful to git, that was not my point. (Nor did I say it – where did I mention hg?)

                                              I am saying that a small number of concepts, flexibly applied, results in a better tool than one built from a larger set of nonorthogonal concepts that cover the same space (ie, the space of tasks you actually need to accomplish.)

                                              It is also the case that once you use a tool successfully for long enough, it gets harder to distinguish what you’re doing from how you’re doing it, and alternative ways of accomplishing the same thing appear to be pointless and overcomplicated, because you are evaluating them according to how well they mimic your current tools rather than how well they accomplish the task at hand. Perhaps you are doing that here. Perhaps I am too unfamiliar with the git toolkit to see some large advantages it has.

                                              1. 1

                                                hg feels conceptually simpler yet equally powerful to git, that was not my point. (Nor did I say it – where did I mention hg?)

                                                Given that I very much use hg with a commit queue, I can’t really agree, though I haven’t tried it much with the base command set (I use evolve [a disabled-by-default extension that emulates something that has been in git since the beginning]).

                                                I am saying that a small number of concepts, flexibly applied, results in a better tool than one built from a larger set of nonorthogonal concepts that cover the same space (ie, the space of tasks you actually need to accomplish.)

                                                I’m not going to disagree with that theory, but it’s clearly not sufficient:

                                                Git has a smaller number of concepts than hg: You can tell because things that are evocations of the alien things like the index require extensions in hg to be implemented.

                                                Patch theory represents what might be the smallest possible number of concepts. It is worth some study and makes hg feel quite pointless because where patch theory also highlights something fundamentally wrong with git, hg has the exact same thing wrong.

                                                It is also the case that once you use a tool successfully for long enough, it gets harder to distinguish what you’re doing from how you’re doing it, and alternative ways of accomplishing the same thing appear to be pointless and overcomplicated, because you are evaluating them according to how well they mimic your current tools rather than how well they accomplish the task at hand.

                                                I think this is a silly way to think about things, but history is littered with people who cannot tell the difference between their opinions and reality.

                                        3. 3

                                          I often stage changes at a time, make some more changes, stage those, etc., before finally having something I want to commit. (i.e. I don’t immediately follow git add -p with git commit) Sometimes this process itself is enough to make me change the direction of what I’m doing or decide I don’t want to make a commit at all.

                                          1. 3

                                            I use “hg commit –amend” for that. If I end up deciding not to commit anything at all, “he strip” will delete the WIP commit.

                                            The evolve extension also provides “hg uncommit”, to remove files from a commit.

                                            1. 1

                                              Sounds like we both have something that works for us then!

                                        4. 4

                                          git gui is my prefered way to use git. Gitg/gitk/cola are also invaluable. Github client was good originally, but thry simplified whioe also some how maing it harder for me to use.

                                          1. 2

                                            I think git add -p is an invaluable tool.

                                            And it gets even better with Magit, if you’re an Emacs user