4 ms·

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 pu

by 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.
pjc50 5y ago
The "intended" way generates a completely spurious merge commit - it doesn't represent a real commit, and rarely do you care about keeping track of merges into a short lived branch which are already tracked on master. Most people want a single source of truth workflow that corresponds to the old total ordering imposed by svn or p4.
- lugged 5y ago
  So use svn?
  - pjmlp 5y ago
    I would, but the option is not mine to make.
- lmm 5y ago
  > The "intended" way generates a completely spurious merge commit - it doesn't represent a real commit, and rarely do you care about keeping track of merges into a short lived branch which are already tracked on master. On the contrary, you want those commits for bisection, which is the main reason to have a VCS history at all. > Most people want a single source of truth workflow that corresponds to the old total ordering imposed by svn or p4. People think they want that, but I've never seen a convincing case for why. Bisect works better if you use merge. Blame works better if you use merge. And if you really want to see the history without merges (why?), it's one flag to do that.

by lugged 5y ago

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.

pjc50 5y ago

The "intended" way generates a completely spurious merge commit - it doesn't represent a real commit, and rarely do you care about keeping track of merges into a short lived branch which are already tracked on master. Most people want a single source of truth workflow that corresponds to the old total ordering imposed by svn or p4.

lugged 5y ago
So use svn?
- pjmlp 5y ago
  I would, but the option is not mine to make.
lmm 5y ago
> The "intended" way generates a completely spurious merge commit - it doesn't represent a real commit, and rarely do you care about keeping track of merges into a short lived branch which are already tracked on master. On the contrary, you want those commits for bisection, which is the main reason to have a VCS history at all. > Most people want a single source of truth workflow that corresponds to the old total ordering imposed by svn or p4. People think they want that, but I've never seen a convincing case for why. Bisect works better if you use merge. Blame works better if you use merge. And if you really want to see the history without merges (why?), it's one flag to do that.