| |
| ▲ | seba_dos1 3 hours ago | parent [-] | | Such as? When you merge a commit in that changed a file that has been already changed since the common ancestor, Git runs a tool of your choice on this file. If the tool fails, it marks the file as needing a merge and doesn't let you commit it until you unmark it to confirm that you have merged it manually. In case of octopus merges, it will just abort early. That's basically its whole behavior when it comes to conflicts. | | |
| ▲ | bulatb 3 hours ago | parent [-] | | Such as moving down a fixup during interactive rebase when it's going to conflict with parents, or I've added more commits mid-rebase, or the rebase started in a tool and now I need to think about the tool's command and understand how many times the rebase point is view is backwards to interpret which is "ours" and which is "theirs" and whether it's the tool, my editor, or my own experience I should ignore because it's going to mislead me. None of that word salad should matter, but it does. Git will ruin everything with glee and there is always an excuse for why that's fine and it's the user's fault. | | |
| ▲ | seba_dos1 3 hours ago | parent | next [-] | | There's nothing "backwards" in "rebase point of view". It's just automated cherry-picking - it's like applying patches, it's as forwards as it gets. People who think it's "backwards" usually just have holes in their mental model of the repository. And yes, I find tools doing what you're asking them to do to be rather fine. In fact, Git makes it easy to notice when you're adding commits mid-rebase, which is something I often do intentionally, as it tells you what the HEAD is (and even shows a detailed state of the in-progress rebase) while authoring the commit message. | | |
| ▲ | bulatb 3 hours ago | parent [-] | | I understand how rebase works and use it many times a day. Thanks for trying to explain but I won't respond further. | | |
| ▲ | seba_dos1 2 hours ago | parent [-] | | These aren't troubles of someone who understands. If anyone else reading this has these kinds of troubles too - don't worry, understanding abstractions takes time and effort, you'll get there eventually (not if you'll keep blaming others though). | | |
| ▲ | bulatb 2 hours ago | parent [-] | | Let me eat the crow of getting drawn back in and cap this conversation with a summary. I think this is important because criticizing Git's UX is always like this. OP: No one should be worried about using Git to do a thing. bulatb: I'm worried it will be unpleasant. seba_dos1: Here is what will happen when you do the thing. bulatb: I know, but doing it will be unpleasant. seba_dos1: You must not understand what's going to happen. bulatb: I do. The process is unpleasant. seba_dos1: You must not understand what's going to happen. | | |
| ▲ | seba_dos1 2 hours ago | parent [-] | | Had you actually read what I wrote, you would rather summarize it as "Git is showing exactly what's going to happen when you attempt to do it, all you have to do to make is pleasant is to not ignore it". Reading things requires unpleasant effort though, I get it. | | |
| ▲ | bulatb an hour ago | parent | next [-] | | I'm sorry (like actually sorry) if I'm getting into counter-condescension here, but, like... > all you have to do to make is pleasant This is an assumption about what I find unpleasant and why. I take it you think "reading information" and "understanding instructions" are some of those things I don't like. Your conclusion that I must not understand is based on that assumption. The assumption is wrong. If you can grant me that, my problem looks different. If you can't or won't, my summary was right. | | |
| ▲ | seba_dos1 7 minutes ago | parent [-] | | If the assumption was wrong, then your first comment was pretty much useless, and the second one didn't help either as it just describes doing things carelessly and without proper understanding. So if that reading of it is wrong, then it was just complaining for complaining's sake and not about Git at all, but rather about what you happen to find scary for some undisclosed reason? |
| |
| ▲ | an hour ago | parent | prev [-] | | [deleted] |
|
|
|
|
| |
| ▲ | skydhash 3 hours ago | parent | prev [-] | | > which is "ours" and which is "theirs" "ours" is always HEAD, usually meaning the state of the working_tree, "theirs" is always the commit that is going to change the working_tree. When merging, you are taking change from another branch (theirs) to create a new commit on the current branch (ours) that ties the two together. When rebasing interactively, you switch to the new base (ours) and replay the changes of the branch (theirs) according to the edit file. Etymology matters. The conceptual model of git is simple, but people only focus on the operations. That's like trying to learn algorithm and data structures and focusing on the words "insert", "remove", "find", without trying to learn "list", "stack", "tree",... first. Instead learn about Git's glossary [0], then how the operations use and modify those concepts. [0] https://git-scm.com/docs/gitglossary |
|
|
|
