10 ms·

Don’t agree with you about git at all, I find it’s one of the few tools I work with that behaves expectedly and gets out of my way, if you want that workflow of

by jamil7 6y ago

Don’t agree with you about git at all, I find it’s one of the few tools I work with that behaves expectedly and gets out of my way, if you want that workflow of stash, pull and reapply a stash why not make an alias for it?

modeless 6y ago
git config pull.rebase true git config rebase.autoStash true I think these should have been the defaults but they weren't implemented until later and it's hard to change defaults.
- zyberzero 6y ago
  TIL. Thank you for this!
- lordgrenville 6y ago
  Great to know about these. I still think the current default is better: for a new user, it might be scary for your uncommitted changes to "vanish" into a stash.
  - modeless 6y ago
    The stash is popped before the command finishes, so your changes don't appear to vanish. Unless there's a conflict while rebasing a prior commit. Actually I'm not sure if aborting the rebase at that point would pop the autostash, but it should.
    - lordgrenville 6y ago
      Got it. In that case I agree.
- hiyer 6y ago
  Setting rebase to true by default is not a good idea if you push your code to your dev branch regularly (rather than just committing).
  - teraflop 6y ago
    I think that's a bit of an exaggeration; "pull.rebase=true" should be fine as long as you don't have local merge commits that need to be rebased on top of someone else's changes. With ordinary commits, it shouldn't really matter how frequently you (or others) push.
    - Izkata 6y ago
      "git rebase" has --preserve-merges (apparently renamed to --rebase-merges a few years ago) to recreate those local merge commits, maybe it can be set somehow for this as well?
      - jgmarcel 6y ago
        Exactly. That’s the default I use. You can set it via: git config --global pull.rebase merges
recursive 6y ago
The functionality of git is great. Mostly. (I think the whold concept of stage/index/cache is completely unnecessary though) I find the UI to be inconsistent and confusing. Why would I ever want to make a branch without checking it out? It's literally never happened, yet it's the default.
- bacon_waffle 6y ago
  > Why would I ever want to make a branch without checking it out? It's literally never happened, yet it's the default. git checkout -b new-branch I fairly often make a branch as a sort of named undo point, and only check it out if need to undo to that point. Tags could work for that purpose too, but the branch approach seems safer in my usual work situation.
  - mtm7 6y ago
    Wow, I’d never thought of using it like this. Thanks for sharing, I just added something new to my workflow!
    - kubanczyk 6y ago
      It's actually an answer to a standard interview question. I've met it more than once. Funny thing, nowadays it's going to be deprecated in favor of: git switch -c newbranch
      - aprdm 6y ago
        There's an interview question about some behaviour of git that people don't rely on very often? Wow. Asking anything about VCS seems a bit off in general if the person has any experience under their belt developing software...
        deleted 6y ago
        [deleted]
        6y ago
michaelt 6y ago
If you want to change from a git-lover to a git-hater, just join a project that uses submodules.
- hijef 6y ago
  Lol... Don't want to go down that rabbit hole. So many tools have been written to help with submodules. Such a shame. I feel like the only success path for submodules in any project is for anyone working on the project is to understand them completely.
  - deleted 6y ago
    [deleted]
- balladeer 6y ago
  That happened to me few months ago when a new submodule was added that gets updated regularly (old ones are some legacy libs just lying there). I literally had to beg some colleagues to not forget to commit the changed submodule ref to host/main project. None of them even understood why it was needed since "it would anyway be solved by `git submodule update --init --recursive` anyway". Also, of late I have turned to "a lover of git GUI apps" form a full "git in cli is the best evangelist". But that has happened for most other tools as well. I guess I am kind of done with cli.
  - pintxo 6y ago
    Similar here, but without learning the CLI first, I would not be comfortable with the GUIs.
nicbou 6y ago
I've been using git for a decade, and I still have to Google simple tasks. The answers rarely make sense.
- mcswell 6y ago
  My history with git is shorter, but ditto to the web search for simple tasks. Before git, I used svn, and most things there made sense (not everything, I admit).
mcswell 6y ago
git mv foo.bar <SomeNewDirectory>/ It loses all history of foo.bar. I guess if you pull up a version before the mv, you can still see it, but as far as git is concerned, foo.bar in the new location has no relationship to foo.bar in the old location. Many people have complained about this over the years, but it's still that way. Because (they say) Linus likes it that way.
- rovr138 6y ago
  git log --follow

by jamil7 6y ago

modeless 6y ago

git config pull.rebase true git config rebase.autoStash true I think these should have been the defaults but they weren't implemented until later and it's hard to change defaults.

zyberzero 6y ago
TIL. Thank you for this!
lordgrenville 6y ago
Great to know about these. I still think the current default is better: for a new user, it might be scary for your uncommitted changes to "vanish" into a stash.
- modeless 6y ago
  The stash is popped before the command finishes, so your changes don't appear to vanish. Unless there's a conflict while rebasing a prior commit. Actually I'm not sure if aborting the rebase at that point would pop the autostash, but it should.
  - lordgrenville 6y ago
    Got it. In that case I agree.
hiyer 6y ago
Setting rebase to true by default is not a good idea if you push your code to your dev branch regularly (rather than just committing).
- teraflop 6y ago
  I think that's a bit of an exaggeration; "pull.rebase=true" should be fine as long as you don't have local merge commits that need to be rebased on top of someone else's changes. With ordinary commits, it shouldn't really matter how frequently you (or others) push.
  - Izkata 6y ago
    "git rebase" has --preserve-merges (apparently renamed to --rebase-merges a few years ago) to recreate those local merge commits, maybe it can be set somehow for this as well?
    - jgmarcel 6y ago
      Exactly. That’s the default I use. You can set it via: git config --global pull.rebase merges

recursive 6y ago

The functionality of git is great. Mostly. (I think the whold concept of stage/index/cache is completely unnecessary though) I find the UI to be inconsistent and confusing. Why would I ever want to make a branch without checking it out? It's literally never happened, yet it's the default.

bacon_waffle 6y ago
> Why would I ever want to make a branch without checking it out? It's literally never happened, yet it's the default. git checkout -b new-branch I fairly often make a branch as a sort of named undo point, and only check it out if need to undo to that point. Tags could work for that purpose too, but the branch approach seems safer in my usual work situation.
- mtm7 6y ago
  Wow, I’d never thought of using it like this. Thanks for sharing, I just added something new to my workflow!
  - kubanczyk 6y ago
    It's actually an answer to a standard interview question. I've met it more than once. Funny thing, nowadays it's going to be deprecated in favor of: git switch -c newbranch
    - aprdm 6y ago
      There's an interview question about some behaviour of git that people don't rely on very often? Wow. Asking anything about VCS seems a bit off in general if the person has any experience under their belt developing software...
      - deleted 6y ago
        [deleted]
      - 6y ago

michaelt 6y ago

If you want to change from a git-lover to a git-hater, just join a project that uses submodules.

hijef 6y ago
Lol... Don't want to go down that rabbit hole. So many tools have been written to help with submodules. Such a shame. I feel like the only success path for submodules in any project is for anyone working on the project is to understand them completely.
- deleted 6y ago
  [deleted]
balladeer 6y ago
That happened to me few months ago when a new submodule was added that gets updated regularly (old ones are some legacy libs just lying there). I literally had to beg some colleagues to not forget to commit the changed submodule ref to host/main project. None of them even understood why it was needed since "it would anyway be solved by `git submodule update --init --recursive` anyway". Also, of late I have turned to "a lover of git GUI apps" form a full "git in cli is the best evangelist". But that has happened for most other tools as well. I guess I am kind of done with cli.
- pintxo 6y ago
  Similar here, but without learning the CLI first, I would not be comfortable with the GUIs.

nicbou 6y ago

I've been using git for a decade, and I still have to Google simple tasks. The answers rarely make sense.

mcswell 6y ago
My history with git is shorter, but ditto to the web search for simple tasks. Before git, I used svn, and most things there made sense (not everything, I admit).

mcswell 6y ago

git mv foo.bar <SomeNewDirectory>/ It loses all history of foo.bar. I guess if you pull up a version before the mv, you can still see it, but as far as git is concerned, foo.bar in the new location has no relationship to foo.bar in the old location. Many people have complained about this over the years, but it's still that way. Because (they say) Linus likes it that way.

rovr138 6y ago
git log --follow