Ralf Wildenhues <Ralf.Wildenhues@xxxxxx> wrote: > * Shawn O. Pearce wrote on Sat, Oct 20, 2007 at 05:19:17AM CEST: > > Frank Lichtenheld <frank@xxxxxxxxxxxxxx> wrote: > > > On Fri, Oct 19, 2007 at 07:41:34PM +0200, Ralf Wildenhues wrote: > > > > > > > > Is that by design (because there were conflicts) or an omission? > > > > In case of the former, maybe the description of -x should mention this. > > > > > > git commit currently doesn't know that you commit a cherry-pick. The -c > > > only says to use the commit message of the original commit. So this is > > > currently by design. > > > > Ralf, can you submit an updated version of this patch that describes > > the current behavior better, given the "by design" remark above > > from Frank? > > Here it goes. Still makes me wonder whether that is the ideal mode of > operation or not. Thanks. I think you are right that the current behavior of -x *not* including the prior commit SHA-1 in the case of a conflict is wrong. The problem however is that git-commit.sh doesn't get the data necessary to preseve the original author name/email/date/tz unless you use the "-c $id" option. There's some work here to store the necessary information into a file that git-commit.sh could pickup, and then making sure stale versions of those files get cleaned up properly, etc. At least the current behavior is now documented. Maybe someone will be bothered enough by it to try and submit a patch that changes the behavior. -- Shawn. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
