Announcement

Collapse
No announcement yet.

Git 2.23 Brings New Switch & Restore Sub-Commands

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by bug77 View Post

    I don't see these as steps towards sanity. Git is only confusing of you come from a non-DVCS background. I think these are supposed to cater precisely to those people and, maybe, behind the scenes, break up the logic behind checkout into smaller, more maintainable pieces.
    I thought i was just pre-coffee, but i can't follow your argument. Git is confusing in general, but people starting there will have less of an issue than those already having learned some other VCS.

    I keep hearing this argument of being different to "C"VCS:es in particular, but no examples. Care to elaborate? Personally, i cant see why anything outside the separation of commit/push needs to differ substantially. Also you end by that the logic can be separated in the implementation, i find that divisions of responsibilities is as good of an idea there as in the UI... so did you just agree with me?

    Comment


    • #12
      Originally posted by bug77 View Post

      I don't see these as steps towards sanity. Git is only confusing of you come from a non-DVCS background. I think these are supposed to cater precisely to those people and, maybe, behind the scenes, break up the logic behind checkout into smaller, more maintainable pieces.
      These days I really believe most of the people coming to git are coming from a non-DVCS background.

      At work the QE team is using it for making automated test case scenarios. These are bright people, but they have degrees in accounting and psychology and so forth.

      One of my friends works in statistical modeling in a research institute, and they use git everywhere. He and all of his colleagues have PhDs - in mathematics, physics, chemistry, and meteorology, not computer science.

      And there are even fiction writers that have switched to using a git repository for their writing, because DVCS is just as useful for tracking story progressions and even story branching as they are for tracking code.

      git has a long way to go before being genuinely user friendly. Even with the team of experienced developers that I work on, we had to do a ton of training for the transition and people still made big mistakes periodically.

      Comment


      • #13
        Originally posted by Michael_S View Post

        These days I really believe most of the people coming to git are coming from a non-DVCS background.

        At work the QE team is using it for making automated test case scenarios. These are bright people, but they have degrees in accounting and psychology and so forth.

        One of my friends works in statistical modeling in a research institute, and they use git everywhere. He and all of his colleagues have PhDs - in mathematics, physics, chemistry, and meteorology, not computer science.

        And there are even fiction writers that have switched to using a git repository for their writing, because DVCS is just as useful for tracking story progressions and even story branching as they are for tracking code.

        git has a long way to go before being genuinely user friendly. Even with the team of experienced developers that I work on, we had to do a ton of training for the transition and people still made big mistakes periodically.
        Exactly.

        I find it great for tracking changes to /etc, ~/.config, and similar places, when adding new mods to games, save games/save states/etc, writing bids and contracts, tracking anything I write really.

        I love being able to do a git revert when I install a mod that causes issues with other mods in KSP. I have to recommend using git to anyone into modding games, even stuff as simple as config tweaks. Being able to simply revert bad mods, config changes, and save games for the times when I go to pee so the cat uses all my stuff and saves because, of course, it's kitty keyboard nap time, is so helpful it isn't funny. I really wish I'd have thought to use something like git back when I played Morrowind....live and learn.

        I'm in the it really isn't that user friendly camp, but at least it's easy enough to find solutions with search engines.

        Comment


        • #14
          Originally posted by skeevy420 View Post
          All I know is that git checkout -b my_dumb_shit is hardwired in my brain and that it's going to be a real pain in the ass to rewire it to git switch -c my_dumb_shit.
          That's what Bash/Fish aliases are for

          Comment


          • #15
            Originally posted by Vistaus View Post

            That's what Bash/Fish aliases are for
            100% agree, only with Zsh

            Oh-My-Zsh makes using git, and the terminal in general, so freakin nice and convenient.

            Michael I have an unapproved post above. Thanks.

            Comment


            • #16
              Originally posted by skeevy420 View Post

              100% agree, only with Zsh

              Oh-My-Zsh makes using git, and the terminal in general, so freakin nice and convenient.
              Especially so zsh-autosuggestions with "ZSH_AUTOSUGGEST_STRATEGY=(history completion)" and "ZSH_AUTOSUGGEST_USE_ASYNC=t"

              Comment


              • #17
                Originally posted by attah View Post

                I thought i was just pre-coffee, but i can't follow your argument. Git is confusing in general, but people starting there will have less of an issue than those already having learned some other VCS.

                I keep hearing this argument of being different to "C"VCS:es in particular, but no examples. Care to elaborate? Personally, i cant see why anything outside the separation of commit/push needs to differ substantially. Also you end by that the logic can be separated in the implementation, i find that divisions of responsibilities is as good of an idea there as in the UI... so did you just agree with me?
                I would if I understood what you're confused about :P

                Originally posted by Michael_S View Post

                These days I really believe most of the people coming to git are coming from a non-DVCS background.

                At work the QE team is using it for making automated test case scenarios. These are bright people, but they have degrees in accounting and psychology and so forth.

                One of my friends works in statistical modeling in a research institute, and they use git everywhere. He and all of his colleagues have PhDs - in mathematics, physics, chemistry, and meteorology, not computer science.

                And there are even fiction writers that have switched to using a git repository for their writing, because DVCS is just as useful for tracking story progressions and even story branching as they are for tracking code.

                git has a long way to go before being genuinely user friendly. Even with the team of experienced developers that I work on, we had to do a ton of training for the transition and people still made big mistakes periodically.
                Well, I didn't say it doesn't have a steep learning curve, that would be a stupid statement to make. But having a non-DVCS background makes that steep curve even steeper.

                Comment


                • #18
                  Originally posted by bug77 View Post
                  I would if I understood what you're confused about :P
                  Well, i was really after your list of things you had observed people being confused about, but that are obvious once you have seen the DVCS light.

                  Anyway, here are the things I can think of right now:

                  Why there isn't "unstage" or a staging area in the first place for one. (yes tagging things or committing is nice)
                  For example, why diff does not include staging. It is more special than it needs to be.
                  Why i can't stash individual files/chunks without playing the towers of Hanoi.
                  Why pretty much any command for a "basic operation" takes switches to make it behave as one would expect.
                  Why a dirty work tree is keeping me from doing <insert operation here> branch even if the file would not be affected. (or i'd rather keep those changes for whatever context i'm leaving)
                  Merge commits, damned merge commits.

                  I feel i'm forgetting things.. or learning git, not sure which is worse

                  So basically, why do you say a DVCS background makes the curve steeper? I'm not arguing that it doesn't, i'm saying it shouldn't.

                  Comment


                  • #19
                    Originally posted by attah View Post

                    Well, i was really after your list of things you had observed people being confused about, but that are obvious once you have seen the DVCS light.

                    Anyway, here are the things I can think of right now:

                    Why there isn't "unstage" or a staging area in the first place for one. (yes tagging things or committing is nice)
                    For example, why diff does not include staging. It is more special than it needs to be.
                    Why i can't stash individual files/chunks without playing the towers of Hanoi.
                    Why pretty much any command for a "basic operation" takes switches to make it behave as one would expect.
                    Why a dirty work tree is keeping me from doing <insert operation here> branch even if the file would not be affected. (or i'd rather keep those changes for whatever context i'm leaving)
                    Merge commits, damned merge commits.

                    I feel i'm forgetting things.. or learning git, not sure which is worse

                    So basically, why do you say a DVCS background makes the curve steeper? I'm not arguing that it doesn't, i'm saying it shouldn't.
                    Ah.
                    Because they're freaking used to working in the master branch first and foremost. Having used crippled VCSes, people only know how to check out and commit. So when they come to git, they naturally want to do just that, only to discover it takes more steps than they're used to. Many just give up at this point and conclude git is just not worth it. Those that go on, are hot by the things you've mentioned, are unaware you can rebase (have you ever seen devs pulling in changes from master by the way of merge?) or that that clean up their commit history before merging. Plus, they seem to have an acquired aversion to branching.

                    And I'm not going to lie about it, I was bitten by some of the above. But I knew beforehand that git was the better way and I wasn't too proud to admit that when things went wrong, the problem was between the keyboard and the screen.

                    Comment


                    • #20
                      Originally posted by bug77 View Post

                      Ah.
                      Because they're freaking used to working in the master branch first and foremost. Having used crippled VCSes, people only know how to check out and commit. So when they come to git, they naturally want to do just that, only to discover it takes more steps than they're used to. Many just give up at this point and conclude git is just not worth it. Those that go on, are hot by the things you've mentioned, are unaware you can rebase (have you ever seen devs pulling in changes from master by the way of merge?) or that that clean up their commit history before merging. Plus, they seem to have an acquired aversion to branching.

                      And I'm not going to lie about it, I was bitten by some of the above. But I knew beforehand that git was the better way and I wasn't too proud to admit that when things went wrong, the problem was between the keyboard and the screen.
                      And taking more steps with no added value, is not at least a slight issue? After all most things are for master and the left-over branches serve no use.
                      I have yet to see a concrete thing where git being significantly different is an improvement, or due to an improvement instead of just for the heck of it.
                      (again outside the necessary separation of commit and push)

                      Comment

                      Working...
                      X