6 ms·

I do not want to learn git tricks. I just wanna use it as simple as possible. Just let me push my code and be done with git and keep on working. Kudos to all w

I do not want to learn git tricks. I just wanna use it as simple as possible. Just let me push my code and be done with git and keep on working. Kudos to all who love git, for me, it's just a tool I have to use.

schacon 3y ago
I don't totally disagree. I love Git and I find all these things very cool, but I know it's overhead a lot of people don't want. The post is on the blog of the new GUI that I'm trying to build to make the cool things that Git can do much faster and more straightforward, so maybe check it out if the CLI isn't your favorite thing.
- withinboredom 3y ago
  Beyond a junior engineer, I’d expect an engineer to know more than the basics if they’ve been using git for their entire career so far. Git is the power saw for software engineers. You don’t want someone who can’t keep all their fingers and toes anywhere near your code. Not knowing git, when you’ve been interacting with it for years, is a red flag for me. I’m not expecting people to know the difference between rebase and rebase --onto, but they should at least know about the reflog and how to unfuck themselves.
brainzap 3y ago
same
goku12 3y ago
A part of Git's complexity is due to the fact that it was originally meant to be just the plumbing. It was expected that more user-friendly porcelain would be written on top of the git data model. Perhaps that is still the best bet at having a simple and consistent UI. Jujutsu and Got (game of trees) are possible examples.
- dayjaby 3y ago
  That's a bold statement. Any proof or article where Linus states that?
  - goku12 3y ago
    If you mean the plumbing part, I recalled it from memory. I don't have anything from Linus to back this up. But have a look at this from the Pro-Git book [1]: > But because Git was initially a toolkit for a version control system rather than a full user-friendly VCS, it has a number of subcommands that do low-level work and were designed to be chained together UNIX-style or called from scripts. Note that its author (schacon) is also the author of the article and is replying in this discussion thread. I also remember reading somewhere that this design was the reason for the complexity in the porcelain. Will update if I find a reference. [1] https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...
    - schacon 3y ago
      Boy, I can't find this either (but also, the kernel mailing list is _really_ difficult to search). I really remember Linus saying something like "it's not a real SCM, but maybe someone could build one on top of it someday" or something like that, but I cannot figure out how to find that. You _can_ see, though, that in his first README, he refers to what he's building as not a "real SCM": https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23ca2e25604af290#diff-2b7814d3fca2e99e56c51b6ff2aa313ea6e9da6424804240aa8ad891fdfe0900R89-R93 https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23...
      - schacon 3y ago
        So, I found the git-pasky project in the _very_ early days (like a couple days after Linus's first git commits) and iirc, it was an attempt to build an SCM-like thing over the plumbing that Linus was working on: https://marc.info/?l=linux-kernel&m=111315057710062&w=2 https://marc.info/?l=linux-kernel&m=111315057710062&w=2
ourmandave 3y ago
Honestly, get outside of commit and pull and my brain feels dread like regular expressions. Hopefully the incantation is on the Cheat Sheet and I don't make it worse.
- Shacklz 3y ago
  I had the same experience for a long time and then I took a bit of time to have a deeper look behind the curtain and I have to say, once you grasp the data-model of git itself (a branch is a pointer to a commit, a commit is a pointer with metadata to a tree, a tree is...), many of the commands start to make sense all of a sudden, or at the very least "stop looking dangerous". As it's one of those rare tools that's probably meant to stay for quite some time and we interact with quite frequently, it was time well spent for me, and it turns out it's really not as hard as the scary-looking commands imply.
  - saiya-jin 3y ago
    This generic statements can be said about basically any technology (MS MFC anybody? (L)DAP? IBM Websphere studio J2EE abominations?) if you are smart enough / have enough time to dig around. It doesn't help discussion at all (and plenty of folks complain about git all the time), since one can't avoid being branded as lazy/stupid if its not grokking this uber important yet trivial tool like me (TM). But then there is Mercurial, used it decade and a half ago and it contained literally everything good about distributed model I could ever wish for, with maybe 50% of Git's complexity. Yet cargo-culting gonna cargo-cult, if Linus uses it so must we since we are not subpar and the rest be damned. Yes sure its the tool to stay, and eventually can be learned well. But its design is far, very far from the most important software design principle (KISS).
    - Shacklz 3y ago
      > But its design is far, very far from the most important software design principle (KISS) My suggestion was more to look at the underlying data-model, which really isn't that much harder to grasp than what your average undergrad datastructure course teaches. Git really does solve a rather complex problem in a quite elegant way - it just so happens that the packaging around it (the cli) is indeed a bit more controversial. I can only speak for myself but once I started to look at git less like "a tool" and rather from a perspective of datastructure/algorithms etc. (which are inherently agnostic to how they're implemented), it started to make sense to me rather quick (a matter of hours actually, which is nothing compared to the countless of hours I've already wasted trying to find the right cheat-sheet-incantation before).
emmelaich 3y ago
There is detail inherent in the problem and some not. I tend to think we underestimate the inherent problems. So I'm happy for the 'complexity' of git.
koonsolo 3y ago
My feeling is that the git interface is a leaky abstraction. I also don't want to learn git tricks, but unfortunately I learned more about it than I wanted to.
Shacklz 3y ago
I understand your sentiment but git is really not all that hard. And knowing a few things that go beyond bog-standard checkout/commit/push, especially history-rewriting activities, will greatly improve quality of commit-history - which might not be of much use for you but might help other engineers working on your project to make easier sense of what's going on. And on another note, git is probably one of the longer-lasting constants in our industry. Technologies develop and change all the time, but for git, it looks like it's here to stay for a while, and it's probably one of the tools we interact with most in day-to-day dev-work. Might be worth having a bit of a look at :)
- mikro2nd 3y ago
  I'd argue that CVS outlasted git by at least a couple of decades...
  - CRConrad 3y ago
    "Outlasted", in the past tense? We won't know that until git is dead, will we?
- deleted 3y ago
  [deleted]
herpdyderp 3y ago
Totally agree. However, then coworkers who don't understand even the simple git commands mess up their branches (somehow), and... then my git tricks save the day (unfortunately).
beeboobaa 3y ago
I do not want to learn programming. I just wanna use the computer as simple as possible. Let me just tell it what to do and be done with it. Kudos to all who love programming, for me, it's just a tool I have to use.
- Frost1x 3y ago
  Isn’t that where most interest starts? A computer really is a tool. I know for me, it was an unfortunate discovery at the very start of my interest in computing that to do the things I wanted I had to deal with all these tedious bits of programming. Even today I’d like to skip most of the underlying tedious bits although I understand knowledge and willingness to deal with much of those underlying tedious bits are what keep money flowing into my account regularly. That’s about the only saving grace of it. There are so many ideas I’d love to explore but the unfortunate fact is there’s a lot of work to develop or even glue together what one needs to test out, not to mention associated infrastructure costs these days. Even useful prototypes take quite an endeavor.
foofie 3y ago
> do not want to learn git tricks. I just wanna use it as simple as possible. Simplicity is in the eye of the beholder. A single trick can save you a whole lot of work. Take for example interactive rebate which allows you to update your local branches to merge and reorder local commits. If you had to do everything by hand you would certainly have to work a lot more.
globular-toast 3y ago
Why even use git then? `scp code server:code` does what you need. This isn't a rhetorical question.
- deleted 3y ago
  [deleted]
- TrickardRixx 3y ago
  Because all the organizations that pay me to write code host their code centrally on GitHub
  - CRConrad 3y ago
    > GitHub But then it's GitHub you need to know, not git.[1] And doesn't that have a point-and-clicky Web interface, like any "Upload files here!" Web site?[2] [1]: Seems you're being fooled, by organisations that also believe it, that git is GitHub and/or vice versa.) [2]:Sorry, I've had an account there since about forever, but hardly ever (never?) used it.
    - TrickardRixx 3y ago
      This is a complete non-sequitur. Whether I use a point-and-click interface or a CLI has nothing to do with the fact that I have to use a git-based workflow and can't just copy files to the server as a deployment.
deleted 3y ago
[deleted]
pwb25 3y ago
I agree, what more is needed than push and diff and branching, sometimes reset and rebase
samatman 3y ago
It's unfortunate that the weight of ecosystem and tooling (and the 800 point Microsoft-owned GitHub gorilla) has effectively locked the profession into using git. I don't hate it, I'm just keenly aware that a better approach is possible. I wish someone with deep pockets would hook the pijul team up with the money and talent they need to make pijul a full-featured alternative with first-class hosting tools. The way it models change is principled and based on solid theory, and I'm convinced that a markedly better tool than git could be built on that foundation.

schacon 3y ago

I don't totally disagree. I love Git and I find all these things very cool, but I know it's overhead a lot of people don't want. The post is on the blog of the new GUI that I'm trying to build to make the cool things that Git can do much faster and more straightforward, so maybe check it out if the CLI isn't your favorite thing.

withinboredom 3y ago
Beyond a junior engineer, I’d expect an engineer to know more than the basics if they’ve been using git for their entire career so far. Git is the power saw for software engineers. You don’t want someone who can’t keep all their fingers and toes anywhere near your code. Not knowing git, when you’ve been interacting with it for years, is a red flag for me. I’m not expecting people to know the difference between rebase and rebase --onto, but they should at least know about the reflog and how to unfuck themselves.

brainzap 3y ago

same

goku12 3y ago

A part of Git's complexity is due to the fact that it was originally meant to be just the plumbing. It was expected that more user-friendly porcelain would be written on top of the git data model. Perhaps that is still the best bet at having a simple and consistent UI. Jujutsu and Got (game of trees) are possible examples.

dayjaby 3y ago
That's a bold statement. Any proof or article where Linus states that?
- goku12 3y ago
  If you mean the plumbing part, I recalled it from memory. I don't have anything from Linus to back this up. But have a look at this from the Pro-Git book [1]: > But because Git was initially a toolkit for a version control system rather than a full user-friendly VCS, it has a number of subcommands that do low-level work and were designed to be chained together UNIX-style or called from scripts. Note that its author (schacon) is also the author of the article and is replying in this discussion thread. I also remember reading somewhere that this design was the reason for the complexity in the porcelain. Will update if I find a reference. [1] https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...
  - schacon 3y ago
    Boy, I can't find this either (but also, the kernel mailing list is _really_ difficult to search). I really remember Linus saying something like "it's not a real SCM, but maybe someone could build one on top of it someday" or something like that, but I cannot figure out how to find that. You _can_ see, though, that in his first README, he refers to what he's building as not a "real SCM": https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23ca2e25604af290#diff-2b7814d3fca2e99e56c51b6ff2aa313ea6e9da6424804240aa8ad891fdfe0900R89-R93 https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23...
    - schacon 3y ago
      So, I found the git-pasky project in the _very_ early days (like a couple days after Linus's first git commits) and iirc, it was an attempt to build an SCM-like thing over the plumbing that Linus was working on: https://marc.info/?l=linux-kernel&m=111315057710062&w=2 https://marc.info/?l=linux-kernel&m=111315057710062&w=2

ourmandave 3y ago

Honestly, get outside of commit and pull and my brain feels dread like regular expressions. Hopefully the incantation is on the Cheat Sheet and I don't make it worse.

Shacklz 3y ago
I had the same experience for a long time and then I took a bit of time to have a deeper look behind the curtain and I have to say, once you grasp the data-model of git itself (a branch is a pointer to a commit, a commit is a pointer with metadata to a tree, a tree is...), many of the commands start to make sense all of a sudden, or at the very least "stop looking dangerous". As it's one of those rare tools that's probably meant to stay for quite some time and we interact with quite frequently, it was time well spent for me, and it turns out it's really not as hard as the scary-looking commands imply.
- saiya-jin 3y ago
  This generic statements can be said about basically any technology (MS MFC anybody? (L)DAP? IBM Websphere studio J2EE abominations?) if you are smart enough / have enough time to dig around. It doesn't help discussion at all (and plenty of folks complain about git all the time), since one can't avoid being branded as lazy/stupid if its not grokking this uber important yet trivial tool like me (TM). But then there is Mercurial, used it decade and a half ago and it contained literally everything good about distributed model I could ever wish for, with maybe 50% of Git's complexity. Yet cargo-culting gonna cargo-cult, if Linus uses it so must we since we are not subpar and the rest be damned. Yes sure its the tool to stay, and eventually can be learned well. But its design is far, very far from the most important software design principle (KISS).
  - Shacklz 3y ago
    > But its design is far, very far from the most important software design principle (KISS) My suggestion was more to look at the underlying data-model, which really isn't that much harder to grasp than what your average undergrad datastructure course teaches. Git really does solve a rather complex problem in a quite elegant way - it just so happens that the packaging around it (the cli) is indeed a bit more controversial. I can only speak for myself but once I started to look at git less like "a tool" and rather from a perspective of datastructure/algorithms etc. (which are inherently agnostic to how they're implemented), it started to make sense to me rather quick (a matter of hours actually, which is nothing compared to the countless of hours I've already wasted trying to find the right cheat-sheet-incantation before).

emmelaich 3y ago

There is detail inherent in the problem and some not. I tend to think we underestimate the inherent problems. So I'm happy for the 'complexity' of git.

koonsolo 3y ago

My feeling is that the git interface is a leaky abstraction. I also don't want to learn git tricks, but unfortunately I learned more about it than I wanted to.

Shacklz 3y ago

I understand your sentiment but git is really not all that hard. And knowing a few things that go beyond bog-standard checkout/commit/push, especially history-rewriting activities, will greatly improve quality of commit-history - which might not be of much use for you but might help other engineers working on your project to make easier sense of what's going on. And on another note, git is probably one of the longer-lasting constants in our industry. Technologies develop and change all the time, but for git, it looks like it's here to stay for a while, and it's probably one of the tools we interact with most in day-to-day dev-work. Might be worth having a bit of a look at :)

mikro2nd 3y ago
I'd argue that CVS outlasted git by at least a couple of decades...
- CRConrad 3y ago
  "Outlasted", in the past tense? We won't know that until git is dead, will we?
deleted 3y ago
[deleted]

herpdyderp 3y ago

Totally agree. However, then coworkers who don't understand even the simple git commands mess up their branches (somehow), and... then my git tricks save the day (unfortunately).

beeboobaa 3y ago

I do not want to learn programming. I just wanna use the computer as simple as possible. Let me just tell it what to do and be done with it. Kudos to all who love programming, for me, it's just a tool I have to use.

Frost1x 3y ago
Isn’t that where most interest starts? A computer really is a tool. I know for me, it was an unfortunate discovery at the very start of my interest in computing that to do the things I wanted I had to deal with all these tedious bits of programming. Even today I’d like to skip most of the underlying tedious bits although I understand knowledge and willingness to deal with much of those underlying tedious bits are what keep money flowing into my account regularly. That’s about the only saving grace of it. There are so many ideas I’d love to explore but the unfortunate fact is there’s a lot of work to develop or even glue together what one needs to test out, not to mention associated infrastructure costs these days. Even useful prototypes take quite an endeavor.

foofie 3y ago

> do not want to learn git tricks. I just wanna use it as simple as possible. Simplicity is in the eye of the beholder. A single trick can save you a whole lot of work. Take for example interactive rebate which allows you to update your local branches to merge and reorder local commits. If you had to do everything by hand you would certainly have to work a lot more.

globular-toast 3y ago

Why even use git then? `scp code server:code` does what you need. This isn't a rhetorical question.

deleted 3y ago
[deleted]
TrickardRixx 3y ago
Because all the organizations that pay me to write code host their code centrally on GitHub
- CRConrad 3y ago
  > GitHub But then it's GitHub you need to know, not git.[1] And doesn't that have a point-and-clicky Web interface, like any "Upload files here!" Web site?[2] [1]: Seems you're being fooled, by organisations that also believe it, that git is GitHub and/or vice versa.) [2]:Sorry, I've had an account there since about forever, but hardly ever (never?) used it.
  - TrickardRixx 3y ago
    This is a complete non-sequitur. Whether I use a point-and-click interface or a CLI has nothing to do with the fact that I have to use a git-based workflow and can't just copy files to the server as a deployment.

deleted 3y ago

[deleted]

pwb25 3y ago

I agree, what more is needed than push and diff and branching, sometimes reset and rebase

samatman 3y ago

It's unfortunate that the weight of ecosystem and tooling (and the 800 point Microsoft-owned GitHub gorilla) has effectively locked the profession into using git. I don't hate it, I'm just keenly aware that a better approach is possible. I wish someone with deep pockets would hook the pijul team up with the money and talent they need to make pijul a full-featured alternative with first-class hosting tools. The way it models change is principled and based on solid theory, and I'm convinced that a markedly better tool than git could be built on that foundation.