6 ms·

Yes. Especially git init --submodule --recursive Or is it git submodule --init --recursive? God I hate this UX so much I usually have a ./fetch-subrepos.sh

• handrous 5y ago
  > And if I push without first pulling, must it always punish me with a merge commit? Can't I say "oh shit I don't want to do this, go back and git pull"? This is a source of probably 50% of my "ah, fuck, time to undo..." moments with git, these days. I hate that shit. Muscle-memory gets ahead of me and I commit on a shared remote branch, which would be fine given our workflow except that I didn't pull first. What a pain in the ass.
  • lamontcg 5y ago
    I guess I have `git pull --rebase` as muscle memory. I would guess there's an easy way to make git do this automatically for you via config so you never forget, but I just never, ever `git pull` Or: > git config --global alias.up '!git fetch && git rebase --autostash FETCH_HEAD' From: https://github.com/JKrag/git-up https://github.com/JKrag/git-up
    • deleted 5y ago
      [deleted]
    • rjmunro 5y ago
      git config --global pull.rebase true You probably also want: git config --global rebase.autostash true
    • deleted 5y ago
      [deleted]
  • funkymike 5y ago
    I have this in my .gitconfig so the pull will fail rather than merge. [pull] ff = only If it does fail I can decide whether to merge or rebase.
  • Nullabillity 5y ago
    For the sake of your coworkers (and your future self), please don't lie just to make your history look pretty.
    • DangitBobby 5y ago
      I try to make each commit a snapshot of a working repository (compileable or runnable or testable, whatever is the heuristic for working) where the difference between each snapshot can be explained by the commit message. Ideally they are isolated to a single logical "unit" of change (fix, refactor, add, remove). The goal here being to minimize the amount of confusion and work for anyone traveling up and down the tree. I often have to rewrite my local history to make this happen, because the actual changes that I make can happen in a somewhat arbitrary order. How has local history revision bitten you?
      • lmm 5y ago
        Rebasing leads to either having long stretches of non-compiling commits in history or giant non-bisectable commits. E.g. you added a method call on your feature branch, that method was renamed in master while you were working on your feature. If you merge then your commits still compile and I can use automated `git bisect` the way it's intended. If you rebase then your commits don't compile and I can't bisect through commits on your feature branch. If you squash then your whole feature development becomes a single monster commit and I can't bisect through it. I agree with having as many commits as possible be compilable, but that's not the sole criterion, because there's a tension between that and having granular history: if you squash the whole history of the repo into a single commit then that means 100% of commits are compilable, but it's still a bad move. Conversely, a non-compiling commit in between two compiling commits is not a big problem (you just make sure your git bisect script skips non-compiling commits) - what really matters is keeping the diff between two successive compiling commits as small as possible. IME the best way to achieve that is never rewriting history.
        • DangitBobby 5y ago
          That's a very good point with rebasing. Thanks for explaining.
• ItsMonkk 5y ago
  It is for this reason that I have changed my workflow to always stash first, then pull, then pop the stash and do the merges locally, then push.
  • deleted 5y ago
    [deleted]
  • lanstin 5y ago
    And always diff before stash because sometimes it's just random shit I wasn't serious about, so I'll re-checkout that file and then stash the rest.
• lugged 5y ago
  Git init inits a git repo. Git submodule runs commands on submodules. What is hard about this UX? And it's not punishing you, its doing what you asked, to pull into a non matching head, how does it know you're not using git in the intended and distributed way? Btw, just quit the editor without saving, it aborts.
  • klyrs 5y ago
    [misunderstanding removed]
    • chakspak 5y ago
      You can also quit the CLI editor, e.g. vim.
    • chriswarbo 5y ago
      Git invokes an editor, for writing commit messages, etc. (it looks in the VISUAL and EDITOR env vars). That could be a GUI text editor, or something running in the CLI (personally, I use emacsclient to open a new buffer in an existing Emacs window) What they're saying is: if you quit that editor without saving the commit message, git will abort.
    • handrous 5y ago
      I think they mean the commit message editor, which git will use to open a temp file to save the message to if you don't specify a message in-line with the "-m" flag when committing, including when a merge commit is initiated by a "pull". This happens on the CLI, it's just usually (though doesn't have to be!) a command line editor that it opens. I think vim's a common default. AFAIK whatever's opened does need to block the CLI, so you can't use a command that opens a GUI editor then returns immediately or git will interpret that as your having closed the file without saving, but otherwise any editor should work, CLI or GUI, and can be assigned in your git config.
    • smichel17 5y ago
      In a thread about common sources of confusion, I think it would be more helpful to leave the misunderstanding so others might learn from it. Ie, edit to add "this is a misunderstanding" to the top, not replace it entirely.
• urxvtcd 5y ago
  > And if I push without first pulling I think I know git well, but you got me confused. I've never heard of pushes causing merges. Surely you are talking about pulls, right?
  • MereInterest 5y ago
    Maybe somebody who has a habit of using --force when pushing. A major downside of rebase-centric workflows is that it teaches you to ignore the safety rails when pushing, or when deleting branches.
    • Zarel 5y ago
      `--force-with-lease` would fix this problem (it needs an alias). Also, `--force` wouldn't cause a merge commit; it would overwrite the remote changes. The only theory that makes sense is that this person doesn't know how to `pull --rebase`, but the order of `push` vs `pull` wouldn't change the presence of merge commits, so I'm still confused.
      • MereInterest 5y ago
        Ooh, --force-with-lease looks like a nice feature, especially for updating github PRs that aren't yet merged. I still wouldn't want to use it where anybody else has a copy of the changes, since that's where you need a merge commit to avoid breaking somebody else's repo, but that gives me a safer option than a blind --force.
        • urxvtcd 5y ago
          Just remember that --force-with-lease only protects you from overriding commits you have not yet fetched.
      • jtbayly 5y ago
        I don’t know git well, but I often run into the problem being discussed. If I pull from origin before making my changes, I don’t have to merge, obviously. But correct me if I’m wrong: I think that if I don’t pull first, but my changes don’t conflict with any part of what was done by the previous commit(s) I missed, I’ll still have to merge if I touched a file they touched. This is a common scenario for me. Correct some typos in comments for example, and I get forced to figure out how to merge using vim, which I don’t know how to use at all (being a nano user). I’m sure I could and should switch to at least using nano by default, but I don’t know how merging really works, either. What I really want to do is undo my commit, pull, and redo my commit. Then I don’t have to figure out git merge.
• jacobmischka 5y ago
  I usually use `git pull -r` to rebase upstream changes