Git has been in the making since 2005, and probably 90% developers use it everyday
What are some pain-points that you face with git everyday or hav...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
off the top of my head?
capitalization
why
git stage -A
not
git stage -a
or another problem....
why doesn't git commit accept a message by default!?!?
why
-m
?!??!Other than this small stuff.... Git is great!
It's bad enough that
-m
is an option at all; why would that ever be a default?This and what @pandademic said can be resolved by creating terminal aliases for specific commands. For example I have git adcom "msg" which is an alias for "git add ." combined with "git commit -m 'msg'"
yes(off-topic: we could also use git aliases) , that's what I do @damjand , but I just feel that it would make everyone's life a little easier not to have more aliases to remember.
The point of aliases is not just to have shortcuts but to also make commands that are so short and custom-tailored that you don't even have to remember them like you do for built-in commands :)
I just feel we don't need to open
$EDITOR
every time we want to commit something.Technically there's nothing wrong with that, but it is a sign that you might be doing something wrong. If you make a commit, you should be spending some time thinking about what you are doing, what you want to write, and what files are affected.
Having an editor open gives you that time. Using
-m
on the other hand only discourages writing proper multiline messages when they are actually needed. When you already wrote a summary and notice you might want to add a few more lines, it's way easier if you already have an editor than if you just wrote the whole thing on the commandline and would have to delete it all then reproduce it in the editor.very true... I didn't think of it like that
I rather like git.
I definitely like git better than the other source control systems I've used: PVCS, MS-Delta, MS-SourceSafe, MS-TFS/TFVC, RCS, CVS, Subversion, Source Depot, and Perforce. (I've not used Mercurial, but from what I've heard about it there is a good chance I'd like Mercurial better than git.)
I'm not a git-guru. I often have to ask git-gurus how to do things. Sometimes those things are what I'd consider easy, but I'm stymied. Sometimes those things are hard, and I've no clue. Regardless, the git-gurus show me how to do these things, both easy, and hard. Kudos to the git-gurus, and their willingness to help the clueless like myself.
I'm sad that the one git graphical interface I've found — which works the way I think — seems to have become abandoned a few years back. Cycligent Git Tool. /sadpanda
On Facebook, one angry south pole elf said this about git...
I understand where he's coming from. I don't share the anger, but I do understand, and I cannot begrudge him his anger.
Looking forward to reading the conversation!
This reminds me of another post I made a few years ago asking folks whether they thought git could/should be superseded, and got some great responses.
Is git the be all and end all of version control?
Ben Halpern ・ Oct 9 '17 ・ 1 min read
Encourage folks to read through that discussion after they've commented here.
its not a thing that i dont like but "rebase --onto" is a little bit tricky and confusy
Lol hadn't even heard about that one, "git merge" for me to be honest as it's safe and simple ...
Git is one of the most brilliant pieces of software, so it doesn't deserve to be criticized haha, but what irks me somewhat is the eternal discussion and confusion about "git merge" vs "git rebase", but even that isn't really the fault of Git.
Agreed that Git is great, but like everything which is adopted by masses needs to be criticised in a healthy manner
So as to improve the experience :)
Well what matters to me isn't that Git is perfect, but that it's "good enough" (make that, very good) - AND, that it is a standard, which almost everyone uses, and for a reason (I mean, who would want to go back to CVS or Subversion?)
You can use the same commands to do very different things. Pretty confusing for beginners.
definitely Also , the wrong order of flags can do something different!
eg:
git commit -am "this is different"
from
git commit -ma "this"
Git seems to be designed to work well with lots of code repositories of different developers, each of them doing their own thing, occasionally going "oh, this thing from repository x of developer y may be useful to me, let me get that".
Instead, git is used, most of the time, with "single source of truth" repositories.
Considering that the software was designed with the Unix philosophy in mind, it can be daunting, to say the least, for a beginner to learn to use Git the way it really is used in the market instead of the way it was designed to be used.
Couple that with some theatrics terminology (staging area and the like), and you may have some new developers screaming and pulling their hairs out.
Interestingly, Linus seems to always make awesome software that is successful in lots of contexts, except the ones that it was intended to. The Linux kernel is an absolute success in all types of devices, except the one that it was originally intended to.
That some developers are emotionally attached to it.
Other professions have figured out how to work on the same files without affecting each other (such as Lawyers), and it doesn't involve writing commands like a hacker from 1998.
And speaking of hackers, be sure not to put any sensitive info in your git:
thehackernews.com/2022/04/github-s...
P.S. I've seen situations where developers didn't understand that they can manage shared access to a resource without exporting it and putting it into git.
The only thing, I don't like about git is I don't have much followers over github !!!lol
github.com/hiteshtbi
You can see by yourself.
I mean, with two repositories, I don't know what you expect 😝
I know what exactly do you mean. But it was only for fun!!
conflicts, i am new yet..