4 ms·

No offense, but seems your problems coming your unwillingness to learn git properly. If you would take the time and learn it (reading Pro Git book, learning fro

by Walkman 12y ago

No offense, but seems your problems coming your unwillingness to learn git properly. If you would take the time and learn it (reading Pro Git book, learning from visual tools, which there are a ton, etc) (Again, no offense, just suggestion.) > Huge number, about 148, of commands with many sub-commands that often do non-obvious, even unrelated things. You don't need to know all 148 of them. If you only know 16 (1/9 of them): add, branch, checkout, commit, config, fetch, log, pull, push, rebase, reflog, remote, reset, show, stash, status, You can do pretty complex things already. For day-to-day usage, these are more than enough. > git rebase enables users to rewrite history which subverts what should be the main, if not only, function of a version control system. Git rebase enables very simple workflows, like the GitHub workflow[1], which IMO is quite simple, small overhead workflow, pretty useful and scalable. Git rebase is also for local repo only. In every tutorial and even git command recommends against pushing rebased branches to an already pushed remote repository. If you keep this in mind, it makes sense. > ... to rebase heavily to create a false history presenting themselves as fantasy 10X programmers who don't make mistakes, ... I think the reason is not that they want to hide their mistakes, but to clean the history. Would you rather see typos in a history? IMO it's just cruft, an amend or rebase pretty much just a clean up you can read it more easily, and you don't have to deal meaningless 'Fixed a typo' comments... > There are numerous commands to do similar, overlapping but nonetheless different tasks. If for example you want to back up to earlier versions of code you can do git revert, git reset --hard, git reset --soft, git checkout -- <SHA>, git checkout <SHA> -- all of which do different but overlapping things. git revert is not the same as git reset. git revert creates a new commit on top of the commit you want to revert. git reset move the HEAD. Totally different operations. git reset --hard, --soft, etc does the same thing, just differ how they handle the index and working tree, and once you understand I think it makes sense. > A supposed virtue of git is that it makes it extremely easy to create "branches." This often leads to a proliferation of branches, making locating changes and reconstructing the history of changes extremely difficult. If you stick to a simple workflow and rebase constantly, this is not a problem at all. Not everybody needs git-flow[2]. If you work on the same files with somebody, I think this will always be a problem, no matter what VCS you use, but with git there are a couple of merging strategies which can facilitate the process. > Cryptic hexadecimal SHA for identifying commits instead of sequential numbers for individual files as well as snapshots of the entire project. The SHA1s are for security. A commit's SHA is actually the SHA1 of that snapshot, so if you change any bit of that snapshot manually, git will complain about it[3]. It is basically that nobody can change code unnoticed! > Lack of backward compatibility with RCS-style version control systems like Subversion. I don't really understand what you mean here, but there is the command git svn, which is perfectly compatible with SVN. Recently I converted a whole SVN repository to Git without even losing one commit or message or anything... Also Git supports many more workflows[4], not just centralized. > ... many obvious problems with Git. Of course git is not perfect, but instead of ranting about it, you could learn it in a couple of days and work with it, becase many of us think it's pretty flexible and as simple as you want it to be. Actually, if you learn only two commands: add and commit, you can use Git, nobody stops you doing that if you find the other parts difficult. [1]: https://guides.github.com/introduction/flow/index.html https://guides.github.com/introduction/flow/index.html [2]: http://nvie.com/posts/a-successful-git-branching-model/ http://nvie.com/posts/a-successful-git-branching-model/ [3]: http://youtu.be/4XpnKHJAok8?t=56m20s http://youtu.be/4XpnKHJAok8?t=56m20s [4]: https://www.atlassian.com/git/workflows#!workflow-centralized https://www.atlassian.com/git/workflows#!workflow-centralize...

NumberSix 12y ago
@Walkman I actually have been using Git extensively for 1 1/2 years. I have read the Pro Git book and many other sources cover to cover several times. I use magit with Emacs and gitk extensively. I gave up on the Android repo utility after it repeatedly goofed up the equivalents of git pull --rebase. My complaints about Git are based on direct experience and watching others struggle with it. Yes, I can and have set up Git in a very simple way not unlike an RCS project that avoids most of the issues that I discuss. No rebasing. Minimal use of branches, just a simple approximation of a development/production branch system. Nonetheless there are several problems with Git that still bit me such as the lack of sequential ids for files and the confusing terminology (staging areas, the index, etc.) and documentation. For a better Git: 1. Clean up the documentation and man pages to remove the confusing terminology. Settle on one name for the "index" and so on. 2. Ditch rebasing. 3. Use sequential ids with a suffix of some sort for local changes. e.g. 1.2 on the master, 1.3.repo.branch or something like that for local changes. Keep the SHA, hide the SHA, but give users an easy intuitive way to access the SHA if needed. 1.1 1.2 1.3 \ 1.4 1.4.myrepo.master 1.5 | | / 1.6 1.7 I would guess there is some scheme like this in some other distributed version control system. 4. Simple checkin/checkout commands like RCS Sincerely, Bit by Git
- e40 12y ago
  2. Ditch rebasing. You really are completely clueless. Rebasing is invaluable for use on private branches that no one will ever see but the developer. It allows you to clean up your history before others see it. EDIT: oh, and you can make a hook (like I did from day 1) that disallows non-fast-forward pushes to certain public repos.
chx 12y ago
> Would you rather see typos in a history? Absolutely. Like, normal git log wouldn't show them only the branch merges but if you dig deeper then you'd see them. Or even allow to mark a commit as "superficial" (wikipedia has superficial edits). It is very easy to hide commits but once rebase destroys them it is impossible to see them even if needed. Consider how scientific research works: you write down everything you do, preserve them and publish a book/paper/etc at the end. If it turns out you were not right then it's possible to peek at the notebooks later but if you were, noone ever will care.

by Walkman 12y ago

NumberSix 12y ago

@Walkman I actually have been using Git extensively for 1 1/2 years. I have read the Pro Git book and many other sources cover to cover several times. I use magit with Emacs and gitk extensively. I gave up on the Android repo utility after it repeatedly goofed up the equivalents of git pull --rebase. My complaints about Git are based on direct experience and watching others struggle with it. Yes, I can and have set up Git in a very simple way not unlike an RCS project that avoids most of the issues that I discuss. No rebasing. Minimal use of branches, just a simple approximation of a development/production branch system. Nonetheless there are several problems with Git that still bit me such as the lack of sequential ids for files and the confusing terminology (staging areas, the index, etc.) and documentation. For a better Git: 1. Clean up the documentation and man pages to remove the confusing terminology. Settle on one name for the "index" and so on. 2. Ditch rebasing. 3. Use sequential ids with a suffix of some sort for local changes. e.g. 1.2 on the master, 1.3.repo.branch or something like that for local changes. Keep the SHA, hide the SHA, but give users an easy intuitive way to access the SHA if needed. 1.1 1.2 1.3 \ 1.4 1.4.myrepo.master 1.5 | | / 1.6 1.7 I would guess there is some scheme like this in some other distributed version control system. 4. Simple checkin/checkout commands like RCS Sincerely, Bit by Git

e40 12y ago
2. Ditch rebasing. You really are completely clueless. Rebasing is invaluable for use on private branches that no one will ever see but the developer. It allows you to clean up your history before others see it. EDIT: oh, and you can make a hook (like I did from day 1) that disallows non-fast-forward pushes to certain public repos.

chx 12y ago

> Would you rather see typos in a history? Absolutely. Like, normal git log wouldn't show them only the branch merges but if you dig deeper then you'd see them. Or even allow to mark a commit as "superficial" (wikipedia has superficial edits). It is very easy to hide commits but once rebase destroys them it is impossible to see them even if needed. Consider how scientific research works: you write down everything you do, preserve them and publish a book/paper/etc at the end. If it turns out you were not right then it's possible to peek at the notebooks later but if you were, noone ever will care.