Git

Let's get real. Apparently git is the best tool for versioning and collaborative work. Well, it is true, unless you collaborate with someone else than just yourself, and just use simplest operations like commits and branches to avoid keeping multiple directories of your projects. Trying to clean up history, rebasing without accidentally losing commits because of wrong submodule bump (yeah, you forgot to also rebase them), accidental file duplication, merging changes unless they are done by you and short and simple (during colaborative work you have to split big changes into multiple dumbed down commits, good luck not ommiting any changes), someone force-pushing the branch, getting lost in stash of changes because you have to edit 4 branches at the same time due to wanting to implementing new things while fighting with CI/CD mechanisms. Most people when they see too much changes just delete the repo and redownload it. Also instead of rebasing people just delete the branch, checkout master, and cherry-picking and checkouting separate files massively. This is so time consuming, but there is less chance for errors. Is there really nothing that can replace git? Or there is some kind of magic tool that wraps often used but difficult to perform tasks?

Git is better than sending over your work directory over some messenger app or usb stick so as far as I'm concerned it truly is the best way to collaborate on code and text heavy projects. But because it's focused on text and lin e breaks that's all you can use it for and for other types of projects hope that you either can use SVN or it allows for enough modularity so everyone can work in their own corner. Or hope the application you're using has some in built versioning for their own proprietary format. Furthermore you really should only use pull (for merging remote changes into your local ones) and push and none of this rebase nonsense since messing with the history is how you fuarrrk things up quickly. Use separate branches for larger multi commit changes so you don't forget anything and resolve merge conflicts on your branches by hand if possible. I've found any visual marge conflict tool causes more trouble than it's worth, "take mine" or "take theirs" always does the wrong thing and going in with a text editor or IDE always was sufficient. You then can delete the working branch if you're done with it. No need to clean up the history unless you upload and change massive binaries at which point Git is not suitable. Never force push or force delete anything unless it's an edge case where you know exactly what you're doing. Cherry picking is a last resort and usually only comes about when you have a bad flow or some weird release branch thing going on. Instead of handling multiple stashes you can just check out the repository multiple times if you have to deal with too many WIP changes you don't wish to commit. It also keeps your build folders in line with your current changes since these are not tracked nor committed. I hope this quick primer was of help and the tl;dr is just keep it simple. Only pull, push and branches and I never had issues (caused by me) that way.

>someone force-pushing the branch protip: have whoever admins your git stuff set up a commit checker that disallows people force pushing to any branch that they didn't create. force pushing should be rare anyway and if you're regularly running into issues with it, something about your workflow is completely fuarrrking dumb. >Trying to clean up history why are you trying to clean it up? the git history is the git history. you don't need to pretty it up or anything. it should reflect whatever was done. >rebasing without accidentally losing commits because of wrong submodule bump (yeah, you forgot to also rebase them) what does this even mean? commits in the parent repository won't be lost because you forgot to add the commit the submodule change (you just add it in a new commit and push), and commits in the submodule won't be lost because you forgot to rebase in it (and do you literally mean `git rebase` because you shouldn't be doing that most of the time anyway) >accidental file duplication how? even if two people are making the same file in two separate branches, you just resolve it when you merge. >merging changes unless they are done by you and short and simple (during colaborative work you have to split big changes into multiple dumbed down commits, good luck not ommiting any changes) no, you don't? put as much soykaf into one commit as makes cohesive sense. in an ideal world, anyone should be able to check out the commit and have all the changes necessary for whatever feature was added or bug was fixed in that commit. what type of commits are you regularly breaking into smaller chunks and why? why does you having a commit with all of your contributions mess up collaborators? >Most people when they see too much changes just delete the repo and redownload it. Those people should be sent to mandatory git training and if they continue this way, fire them. >Also instead of rebasing people just delete the branch, checkout master, and cherry-picking and checkouting separate files massively. that's just disgusting. Can you share more details about you and your coworkers git workflow? All of these problems sound symptomatic of a terrible git workflow and an awful (or absent) branching strategy. >>39115 >Instead of handling multiple stashes you can just check out the repository multiple times if you have to deal with too many WIP changes you don't wish to commit. It also keeps your build folders in line with your current changes since these are not tracked nor committed. disagree. checking out the repository multiple times is messy and unnecessary. it's easy enough to just name the stashes, though that OP is ending up working on 4 different branches at a singular time indicates that something gross is happening with their workflow and/or branching strategy.

>>39114 >Is there really nothing that can replace git? Don't quote me on this but I believe git was created for large code bases. Try mercurial. >Most people when they see too much changes just delete the repo You'd be surprised how many times the committer is also partially responsible for this, as in: Both sides being lazy and uncollaborative.

>>39114 We use svn at my job I like it a lot actually, can get it working with jenkins and CI/CD systems well too There are some missing features but its not that confusing

The other choices would be any of these depending what you need: Mercurial https://www.mercurial-scm.org/ Apache Subversion http://subversion.apache.org/ Fossil http://www.fossil-scm.org/ Bazaar http://bazaar.canonical.com/ (for some reason i cant reach this address, servers down) https://launchpad.net/bzr

>>39114 git would be infinitely more useful if it knew the semantics of the data it was dealing with, so it could make informed decisions and automatically fix merge conflicts

Just merge bro. >editing 4 branches at the same time Just merge every time you switch branches. >instead of rebasing people delete the branch, checkout master, and cherry-picking and checkouting separate files Just merge master bro. I used to care about git history. That was a sign I had too much time on my hands. I look at commits like once a month maybe. The diff on PRs is all you need.

>>39540 You can define custom merge drivers per filetype in your projects' .gitinfo file. That let's you pass the merging off to context aware tools.

>>39547 >gitinfo sorry, made a dumb mistake. You set it up through your .gitattributes and git config.

>>39115 >text heavy You can easily manage binary files with git annex.

>>40753 Sure, but it still doesn't let you deal with .kra or .odt files that multiple people have edited concurrently. Hell, it won't even work correctly on text if there aren't enough linebreaks.

Git is quite good actually. If I were to change anything, it would be to remove rebasing. There are also some UI improvements I should like to make. Namely I would like the work tree and index to be stashed automatically when you run a checkout, then this stash should be attached to the relevant branch/commit and re-applied automatically when you return to it.

rebase users and their obsession with history is pure unadulterated mental illness. just use merge and all of your problems go away.

>>39114 I think Fossil is better but everyone has settled on git because it's the de facto one true version control system and it's good enough. I suggest that you try Emacs + magit because it makes git make sense. This video convinced me to start using it >https://www.youtube.com/watch?v=2-0OwGTt0dI

give mercurial a try, git is overkill for small projects

>>40769 Haven't heard of anyone using http://gameoftrees.org/got.1.html#EXAMPLES but this is also an option for people who want to use Git without the "big system mentality". If didn't use magit this would probably be my tool of choice. (not that am particularly experienced with either.)

>>40768 Github probably plays a big part in this situation. Perhaps if there were similar services for the other vcs, they too would be more popular but, now atleast, git has too many users at this point anyway.

>>39114 I think you should research git some more and apply branch policies for instance before you write it off https://git-scm.com/book/en/v2/Customizing-Git-An-Example-Git-Enforced-Policy