Re: [PATCH RFC 2/2] builtin/history: print feedback after successful reword

> > So I agree with Pablo's suggestion: printing old/new short hash on
> > success would help visualy confirming something worked.
> 
> I think we have the machinery for this (see --update-refs=print for
> git-replay, for example), but I'm surprised to learn that we don't
> accept --update-refs=print for history.
> 
> In any case, I second the "we should emit something"—I wonder what, though.
> 
> - In the case of rewritten refs, we might like to emit the list of
> rewrites, a bit like a fetch or push will do: "+ $old...$new $ref
> (forced update)" or something
> - For new objects that aren't pointed to… maybe silence is a better
> indicator that "we didn't do what you intended"? Or we could just
> print the new commit objects "$new [unreferenced object]" or something

> > ... But it might be worth to ensure that the commit has any ref we can
> > handle (if --update-refs is set then the commit we edit is ancestor to
> > some branch, if not set then it must be an ancestor of HEAD)
> >
> > What do you think?
> 
> I don't think it's worth restricting the operation (I can imagine a
> use case where someone creates an unpointed-to object and later makes
> the ref, even if that's a bit weird), but
> 
> - we could have a "strict" mode that ensured inputs are pointed to
> - we could warn when only unreferenced objects are rewritten
> 
> ? I see git-history as very "porcelain"/user-focused, so I think it's
> feasible to add output niceties (and optionally a quiet mode to
> suppress the messages).