William Clifford writes:
> I will see about actually reading
> in additional lines and raising an error, but it occurs to me that if
> I can read in the additional lines, I could also insert them as
> comments, and then it should be as safe as any of the other comments
> inserted in the rebase to
Thanks! I've set it up just this way and it seems to work fine.
It turns out the formatted string is processed by the shell `read`
later on, which happens to ignore everything after the first line, so
it seems like it should be safe. But doing something explicit about it
seems like a good idea in
Junio C Hamano writes:
> William Clifford writes:
>
>> A couple of examples:
>>
>> - `git config sequence.format "%<(12,trunc)%ae %s"`
>> - `git config sequence.format "%s <%aN %aE>"`
>> - `git config sequence.format "%s%n%%n%b"`
>> ... I'm unsure what would happen if I tried to rebase with the
William Clifford writes:
> A couple of examples:
>
> - `git config sequence.format "%<(12,trunc)%ae %s"`
> - `git config sequence.format "%s <%aN %aE>"`
> - `git config sequence.format "%s%n%%n%b"`
> ... I'm unsure what would happen if I tried to rebase with the
> third style unedited or uncommen
I'm sorry if this shows up twice. I messed up the first time.
I was recently in a situation of rebasing a topic branch with many
commits by several colleagues and I thought it would be useful if I
could see the author of the commit in the commit table in the rebase
todo file. I wanted try to squas
5 matches
Mail list logo
