Git 2.48 Released With Initial Support For The Meson Build System

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • mobadboy
    Senior Member
    • Jul 2024
    • 177

    #11
    Originally posted by uid313 View Post

    Works fine until it doesn't, when you have a detached head, when you need to pick a merge strategy, when you get a merge conflict, when you need to squash commits or rebase.
    skill issue unfortunately. i do these every day and they work fine - great, actually. squashing, git amending, conflict resolution, detached head. i even oopsed my HEAD and recovered it thanks to git reflog.

    git is by far the best version control system for text-based source code. it is not for every single use-case in the world, but it is far better than any alternative today for almost everyone's code.

    Comment

    • Abacus123
      Junior Member
      • Nov 2023
      • 31

      #12
      My organization is still stuck with TFS unfortunately and it's annoying because it only seems to work on windows + visual studio. We've been talking about switching over to git since it's more flexible with the OSes and IDEs it supports but switching all the repositories over looks like a daunting, time consuming task for our relatively small IT department. Anyone else ever had to deal with changing version control systems?

      Comment

      • fez9
        Junior Member
        • Sep 2024
        • 1

        #13
        Originally posted by Abacus123 View Post
        My organization is still stuck with TFS unfortunately and it's annoying because it only seems to work on windows + visual studio. We've been talking about switching over to git since it's more flexible with the OSes and IDEs it supports but switching all the repositories over looks like a daunting, time consuming task for our relatively small IT department. Anyone else ever had to deal with changing version control systems?
        We switched over 100 TFS repos at my old job using git-tfs bridge to bring in all the history of the main branch, worked out pretty good, tough we did it incremental one repo at the time.

        git-tfs worked really good for us so i would look into that if you want to have the existing history in the new git repo, there was also some teams/repos that just archived the old TFS repo and started clean.

        Comment

        • bug77
          Senior Member
          • Dec 2009
          • 6524

          #14
          Originally posted by uid313 View Post

          Works fine until it doesn't, when you have a detached head, when you need to pick a merge strategy, when you get a merge conflict, when you need to squash commits or rebase.
          Imho that's where git works best. As in, any other VCS pretty much falls flat on its face in those situations.
          Merging conflicts, in particular, is an unsolvable issue: oftentimes, when that happens, you have to check with the other committer to determine the proper order. With git, at least you get the ours or ort ours/their options. Helped in at least one situation when I had to merge branches that diverged for months.

          Comment

          • ssokolow
            Senior Member
            • Nov 2013
            • 5114

            #15
            My only issue with Git is that every time I get a merge conflict, I have to re-consult StackOverflow to remind myself which option is which in git gui. They really need to improve that context menu's labelling.

            Comment

            • fintux
              Phoronix Member
              • Nov 2019
              • 53

              #16
              Originally posted by mobadboy View Post

              skill issue unfortunately. i do these every day and they work fine - great, actually. squashing, git amending, conflict resolution, detached head. i even oopsed my HEAD and recovered it thanks to git reflog.

              git is by far the best version control system for text-based source code. it is not for every single use-case in the world, but it is far better than any alternative today for almost everyone's code.
              In my opinion, Git works very well on the technical level. Some things are hard, like tracking where a specific line was removed and tracking over renames etc.

              But my issue is with the user interface. Some things have improved, but there is way too much overloading of commands and the commands don't make sense. The interface lacks intuition, and it still shows it was started as a one-person project without somebody truly focusing on the usability.

              Some things especially in the past were that you stage files with add, but you also add new files with add, and you unstage with reset, but you remove files with rm. And then reset is used for other kind of things, too. Why not have "git add/rm/stage/unstage" to handle each of these separately? And if there is a merge conflict from restoring from the stash, why can I not mark a file as resolved without also staging it? And when I do git stash with staged changes, it kind of does the opposite, also unwanted: it stashes also the staged part, but squashing those together with the unstaged changes. This can lead to loss of work as it is not trivial to separate two set of changes.

              As somebody with ADHD, no matter how careful I try to be, I make mistakes, and those can be a big pain to undo in Git. For example, sometimes it creates a bunch of files in merging something, and if there are conflicts and I want to abort, it leaves those files behind. I usually have a bunch of files that I want to keep, but not add to repo or even .gitignore, so I have to manually delete those left-over files.

              I argue it's not only a skills issue, it is also a user interface design issue. And surely somebody without ADHD will be able to use it better, but you wou be surprised to know of much overrepresented ADHD and other neurominorities are in the set of people who use Git.

              I still prefer git over the other versioning tools I have used, just that with some relatively small changes Git would be a lot easier to use out-of-the-box.

              Comment

              • kpedersen
                Senior Member
                • Jul 2012
                • 2715

                #17
                Originally posted by uid313 View Post

                when you have a detached head, when you need to pick a merge strategy, when you get a merge conflict, when you need to squash commits or rebase.
                Yes, all those features are pretty good and are annoyingly lacking in other VCS.

                Though on the git admin side, I wish there was a slightly better standalone server for small teams (i.e similar to svnserve). I find serving it via httpd using git-http-backend a little fragile and simply using sshd is far too powerful as a transport. git-shell feels like a hack when you still need to prevent tunnelling, allocating ptys, etc. And of course the standalone git daemon offers no authentication. This is where svnserve had a good middle ground and allows us to avoid third party stuff like gitolite, etc.

                I am looking forward to what the OpenBSD guys finalize with got in terms of a server. I think their solution of separating the daemon frontend from the backend might resolve some of the problems I have with ad-hoc git servers via ssh.
                Last edited by kpedersen; 11 January 2025, 07:23 AM.

                Comment

                • anda_skoa
                  Senior Member
                  • Nov 2013
                  • 1212

                  #18
                  Originally posted by fez9 View Post
                  We switched over 100 TFS repos at my old job using git-tfs bridge to bring in all the history of the main branch, worked out pretty good, tough we did it incremental one repo at the time.
                  This is also what the GitHub documentation suggests to do.

                  Microsoft has also documentation for such transitions. After all they had to do it themselves.

                  Comment

                  • archkde
                    Senior Member
                    • May 2019
                    • 693

                    #19
                    Originally posted by uid313 View Post
                    Is anyone of you happy with Git?
                    If you like Mercurial but have to use Git, you may want to check out jj.

                    Comment

                    • Havin_it
                      Junior Member
                      • Mar 2015
                      • 34

                      #20
                      Originally posted by Danny3 View Post

                      I'm not as it refuses to be a full changes tracking system.
                      After all these years and development it still doesn't track empty folders and because of that if you want to sync two folders across the network, unless absolutely each folder has something in it, you will not have a perfect copy on the destination side.
                      Too bad since that rsync, while it doesn't have this problem, it has doesn't use SHA1 checksums and it's still not clear if the checksum algorithm it uses is actually done on the destination too after the items have been written.
                      It isn't. Sending side sends an MD5 sum (of the whole file; entirely separate to the progressive checksumming used in transmission proto) with every changed file, and receiving side uses this to verify the transfer - but not the disk write.

                      A simple way to verify the writes would be to repeat the op (with -c flag) but that's a slow process. Would be better if it had a switch to use those already-provided checksums to verify writes. Maybe that's worth suggesting?

                      Comment

                      Working...
                      X