Hi Jake & Phillip, On Sat, 20 Jan 2018, Jacob Keller wrote: > On Fri, Jan 19, 2018 at 6:45 AM, Phillip Wood <phillip.wood@xxxxxxxxxxxx> wrote: > > On 18/01/18 15:35, Johannes Schindelin wrote: > >> > >> This patch is part of the effort to reimplement `--preserve-merges` with > >> a substantially improved design, a design that has been developed in the > >> Git for Windows project to maintain the dozens of Windows-specific patch > >> series on top of upstream Git. > >> > >> The previous patch implemented the `label`, `bud` and `reset` commands > >> to label commits and to reset to a labeled commits. This patch adds the > >> `merge` command, with the following syntax: > >> > >> merge <commit> <rev> <oneline> > > > > I'm concerned that this will be confusing for users. All of the other > > rebase commands replay the changes in the commit hash immediately > > following the command name. This command instead uses the first commit > > to specify the message which is different to both 'git merge' and the > > existing rebase commands. I wonder if it would be clearer to have 'merge > > -C <commit> <rev> ...' instead so it's clear which argument specifies > > the message and which the remote head to merge. It would also allow for > > 'merge -c <commit> <rev> ...' in the future for rewording an existing > > merge message and also avoid the slightly odd 'merge - <rev> ...'. Where > > it's creating new merges I'm not sure it's a good idea to encourage > > people to only have oneline commit messages by making it harder to edit > > them, perhaps it could take another argument to mean open the editor or > > not, though as Jake said I guess it's not that common. > > I actually like the idea of re-using commit message options like -C, > -c, and -m, so we could do: > > merge -C <commit> ... to take message from commit That is exactly how the Git garden shears do it. I found it not very readable. That is why I wanted to get away from it in --recreate-merges. > merge -c <commit> ... to take the message from commit and open editor to edit > merge -m "<message>" ... to take the message from the quoted test > merge ... to merge and open commit editor with default message > > This also, I think, allows us to not need to put the oneline on the > end, meaning we wouldn't have to quote the parent commit arguments > since we could use option semantics? The oneline is there primarily to give you, the reader, a clue when reading and editing the todo list. Reusing it for the `merge -` command was only an afterthought. > > One thought that just struck me - if a merge or reset command specifies > > an invalid label is it rescheduled so that it's still in the to-do list > > when the user edits it after rebase stops? It is not rescheduled, because the command already failed, so we know it is bad. You have to go edit the todo list, possibly after copying the faulty command from `git status`' output. > > In the future it might be nice if the label, reset and merge commands > > were validated when the to-do list is parsed so that the user gets > > immediate feedback if they try to create a label that is not a valid > > ref name or that they have a typo in a name given to reset or merge > > rather than the rebase stopping later. There are too many possible errors to make this fool-proof. What if the ref name is valid, but there was no `label` command yet? What if there *has* been a `label` command but it is now stuck in the `done` file (which we do not parse, ever)? What if the user specified two label commands with the same label? It sounds like an exercise in futility to try to catch these things in the parser. And keep in mind that the parser is used - when shortening the commit names - when checking the todo list for accidentally dropped picks - when skipping unnecessary picks - when rearranging fixup!/squash! commands - when adding `exec` commands specified via `-x` I am not sure that I would come out in favor of trying to catch ref name errors during parsing time if I wanted to balance bang vs buck. Ciao, Dscho
