Announcement

Collapse
No announcement yet.

Git 2.23 Brings New Switch & Restore Sub-Commands

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

  • Git 2.23 Brings New Switch & Restore Sub-Commands

    Phoronix: Git 2.23 Brings New Switch & Restore Sub-Commands

    Git 2.23 was released on Friday with more than 500 changes on top of the previous release...

    http://www.phoronix.com/scan.php?pag...-2.23-Released

  • #2
    That's a welcome addition. Baby steps towards sanity
    Now if i could just get to have branch-local modifications it will finally allow hassle-free context switching.

    Comment


    • #3
      Originally posted by attah View Post
      That's a welcome addition. Baby steps towards sanity
      Now if i could just get to have branch-local modifications it will finally allow hassle-free context switching.
      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.

      Comment


      • #4
        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.
        Reading their release...well, around the first 2000 words because I ain't got the time to read a freaking novella about a git update...it's the latter part about breaking checkout into smaller, more maintainable pieces.

        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.

        Comment


        • #5
          Originally posted by attah View Post
          Now if i could just get to have branch-local modifications it will finally allow hassle-free context switching.
          That sounds vague, what do you mean by branch-local modifications? As I read it, that's the whole purpose of branches, that each of them can contain unique modifications.

          Comment


          • #6
            Originally posted by Hi-Angel View Post

            That sounds vague, what do you mean by branch-local modifications? As I read it, that's the whole purpose of branches, that each of them can contain unique modifications.
            A sub-branch. That's how I understood that comment.

            Comment


            • #7
              Originally posted by Hi-Angel View Post

              That sounds vague, what do you mean by branch-local modifications? As I read it, that's the whole purpose of branches, that each of them can contain unique modifications.
              I'm not talking about commits, but about what shows up as modified in "git status". I guess purer gitians, would call it per-branch work-trees or something along those lines, but that's just an implementation, i was trying to talk about the functionality in general. And yes, i'm completely aware about the option to have multiple work trees in separate directories. That is not a solution. Build systems, IDEs and whatnot work with one project and i don't want to have to set up my tools again whenever i switch tasks. Also the fact that i can't have the same branch checked out in the different work-trees just adds insult to injury.

              Related https://git-man-page-generator.lokaltog.net/

              Comment


              • #8
                Originally posted by attah View Post
                I'm not talking about commits, but about what shows up as modified in "git status". I guess purer gitians, would call it per-branch work-trees or something along those lines, but that's just an implementation, i was trying to talk about the functionality in general. And yes, i'm completely aware about the option to have multiple work trees in separate directories. That is not a solution.
                Oh, I see what you mean. I agree, sometimes it's annoying when I have modified files I forgot about, I switch a branch which git happily allows me to do, and then it says that I have a bunch of modifications in my tree.

                Other than that, doing a "wip" commit before switching a branch usually works for me. As a bonus, I can write a title, so the next time I switch back I don't need to look through the code and try to remember what was I working on.

                Originally posted by attah View Post
                Build systems, IDEs and whatnot work with one project and i don't want to have to set up my tools again whenever i switch tasks.
                IDEs usually can work with multiple projects just fine. Build systems though indeed are specific to one directory, but I don't see an issue with that.

                Comment


                • #9
                  Hmm, it seems there's post-checkout hook, but no pre-checkout hook. That's an omission, otherwise the "branch-local" modifications could easily be implemented with hooks.

                  Comment


                  • #10
                    Originally posted by Hi-Angel View Post

                    Oh, I see what you mean. I agree, sometimes it's annoying when I have modified files I forgot about, I switch a branch which git happily allows me to do, and then it says that I have a bunch of modifications in my tree.

                    Other than that, doing a "wip" commit before switching a branch usually works for me. As a bonus, I can write a title, so the next time I switch back I don't need to look through the code and try to remember what was I working on.
                    I often run in to that git won't let me do what i want because there are modified files. Modifications i want to keep in that context, but not bother with right now.
                    Sure, WIP ccommits are a workaround of sorts, but i have found that often enough the branch name is enough information.
                    At some point working around how the software works just becomes unproductive. After all it is mean to improve progress, right?
                    I mean zip files and diffs works after all... just not very well.
                    Any hurdle to "getting on with it", is detrimental to fixing things in general, and doing so separately in particular.

                    Originally posted by Hi-Angel View Post

                    IDEs usually can work with multiple projects just fine. Build systems though indeed are specific to one directory, but I don't see an issue with that.
                    Right, but not multiple projects sharing settings or "tags" cache, or open files. I tend to come across projects that use some environment variables, e.g. to know where they are located. Even switching directories between workspaces is quite annoying, if all i want to do is e.g. "make".

                    Comment

                    Working...
                    X