3 ms·

> You can update during an interactive rebate if you need to, why not? You said your "trick" is to explicitly not update the submodules until you've finished t

> You can update during an interactive rebate if you need to, why not? You said your "trick" is to explicitly not update the submodules until you've finished the rebase? By definition that means you're not updating the submodules during the rebase... > Because the lack of a simple removal command does not warrant the "avoid submodules at all costs" sentiment currently the top voted comment on this thread. It's not just removal, though removal is definitely a big chunk of it. See last paragraph. > No. The world isn't a dichotomy; both things can be true. The world isn't a dichotomy, but you "admit the commands need some polish" and then propose a 4-step workaround for issues you've "not once had"? Did you not encounter issues at some point to lead you to propose workarounds and conclude commands need polishing? > A submodule is just a ref, just like a tag. Init and deinit can be finicky, that's about it. If you fully understood refs, then submodules shouldn't be that difficult to reason about. What, specifically, do you find "painful"? I don't think you understand how annoying it is for submodules not to add/remove/update seamlessly. Maybe you only use submodules for your own personal projects and rarely modify them so you rarely see the effect. But especially in a team project that's evolving constantly and the submodules aren't frozen, and especially in projects where you have to go mess with your own submodules to figure out if to-be-proposed changes to dependencies will actually do what you want, having to constantly go out of your way to make sure everything is committed and synced properly every single time you check out a new commit gets annoying fast. Especially when you don't even know what commits contain submodule changes to begin with.

junon 6y ago
You're assuming a lot about me so I don't really feel like spending time answering in depth. You seem to hold a strong opinion you're not willing to change, and while that's fine, I don't appreciate being told I'm somehow not qualified to have a differing opinion when that is very clearly not the case. > You said your "trick" is to explicitly not update the submodules until you've finished the rebase? By definition that means you're not updating the submodules during the rebase... A "trick", not a rule. If you need to check submodules during an interactive rebase, fine, do it. Nothing is stopping you, and it should work fine. > The world isn't a dichotomy, but you "admit the commands need some polish" and then propose a 4-step workaround for issues you've "not once had"? Did you not encounter issues at some point to lead you to propose workarounds and conclude commands need polishing? For 1 issue, of which I feel could definitely have a better command. You're arguing semantics at this point. I've not had issues where I'm so stuck they're impossible to use or to fix, like so many others here claim they do. > I don't think you understand how annoying it is for submodules not to add/remove/update seamlessly. I don't think you understand how submodules work, at all. > Maybe you only use submodules for your own personal projects and rarely modify them so you rarely see the effect. You assume incorrectly. > But especially in a team project . . . and . . . projects where you have to go mess with your own submodules . . . having to constantly go out of your way to make sure everything is committed and synced . . . single time you check out a new commit You're using submodules incorrectly, then. Learn what worktrees are if you don't. Learn what directory remotes are. Learn how to use multiple remotes, even. None of what you're saying is a result of bad Git design. It's a result of you not knowing how Git works, or how to use it effectively. Git gives you all of the tools to use submodules effectively (e.g. testing changes without commiting, or testing changes directly in a submodule, etc.) Do not patronize me because I RTFM.
- dataflow 6y ago
  Wow. I'm not "assuming" anything about you, I'm going literally off what you wrote ("I'm a stickler for clean histories on my projects" when I asked if you use git non trivially...) and even then I said maybe this is why, and even then its truth or falsehood had absolutely zero bearing on the correctness of my points. And that was literally just 1 thing, not "a lot". For someone trying to be accurate you exaggerate like there's no tomorrow, and that's been part of the very issue from the very beginning of the discussion. Meanwhile the person who's been patronizing me and everybody else this entire time is you. Pretending like you're the only one who understands git and me and the rest of the world doesn't. You both go out of your way to trash my understanding of the entirety of git (not only do I not understand how submodules work but I don't understand remotes either? seriously?) with absolutely zero basis and also get offended that I said maybe you're simply not using git in the same kinds of projects that others do and hence that might be why you're not realizing why the problems are such a big deal to other people you've been looking down on before I even started replying? Your entire thesis is always that nobody but you has read the manuals or understood git, and yet I'm the one with a strong opinion unwilling to change? Really? Yes, obviously I don't understand anything in git and the problem is in fact that nobody understands anything about git except you; it can't be any other way.

junon 6y ago

You're assuming a lot about me so I don't really feel like spending time answering in depth. You seem to hold a strong opinion you're not willing to change, and while that's fine, I don't appreciate being told I'm somehow not qualified to have a differing opinion when that is very clearly not the case. > You said your "trick" is to explicitly not update the submodules until you've finished the rebase? By definition that means you're not updating the submodules during the rebase... A "trick", not a rule. If you need to check submodules during an interactive rebase, fine, do it. Nothing is stopping you, and it should work fine. > The world isn't a dichotomy, but you "admit the commands need some polish" and then propose a 4-step workaround for issues you've "not once had"? Did you not encounter issues at some point to lead you to propose workarounds and conclude commands need polishing? For 1 issue, of which I feel could definitely have a better command. You're arguing semantics at this point. I've not had issues where I'm so stuck they're impossible to use or to fix, like so many others here claim they do. > I don't think you understand how annoying it is for submodules not to add/remove/update seamlessly. I don't think you understand how submodules work, at all. > Maybe you only use submodules for your own personal projects and rarely modify them so you rarely see the effect. You assume incorrectly. > But especially in a team project . . . and . . . projects where you have to go mess with your own submodules . . . having to constantly go out of your way to make sure everything is committed and synced . . . single time you check out a new commit You're using submodules incorrectly, then. Learn what worktrees are if you don't. Learn what directory remotes are. Learn how to use multiple remotes, even. None of what you're saying is a result of bad Git design. It's a result of you not knowing how Git works, or how to use it effectively. Git gives you all of the tools to use submodules effectively (e.g. testing changes without commiting, or testing changes directly in a submodule, etc.) Do not patronize me because I RTFM.

dataflow 6y ago
Wow. I'm not "assuming" anything about you, I'm going literally off what you wrote ("I'm a stickler for clean histories on my projects" when I asked if you use git non trivially...) and even then I said maybe this is why, and even then its truth or falsehood had absolutely zero bearing on the correctness of my points. And that was literally just 1 thing, not "a lot". For someone trying to be accurate you exaggerate like there's no tomorrow, and that's been part of the very issue from the very beginning of the discussion. Meanwhile the person who's been patronizing me and everybody else this entire time is you. Pretending like you're the only one who understands git and me and the rest of the world doesn't. You both go out of your way to trash my understanding of the entirety of git (not only do I not understand how submodules work but I don't understand remotes either? seriously?) with absolutely zero basis and also get offended that I said maybe you're simply not using git in the same kinds of projects that others do and hence that might be why you're not realizing why the problems are such a big deal to other people you've been looking down on before I even started replying? Your entire thesis is always that nobody but you has read the manuals or understood git, and yet I'm the one with a strong opinion unwilling to change? Really? Yes, obviously I don't understand anything in git and the problem is in fact that nobody understands anything about git except you; it can't be any other way.