Hi Guido and Rob, Guido Günther wrote:
> I tend to agree here. I introduced the change recently since Rob (cc:) > had good arguments for it: > > # However, the committer date does appear to affect things like the > # --since and --until arguments, and if you're trying to import old > # history, I think you might really want both dates to be set to the > # correct historical time. > > # In fact, it looks like that's what some of the conversion tools do > # (judging from the converted upstream guile archive). They set both > # dates. > > I'm o.k. with reverting this change since I thing setting the committer > date to the date the commit to git happened is the right thing to do but > I wanted to get you two in touch exchange arguments I might be missing. > > It's probably best to add two new options: > --author-is-committer > and > --author-date-is-committer-date > so everybody can have this as he wants to (although I hoped this would > not be necessary). Perhaps git should learn an --authored-since option. I think --since uses the committer date because that allows it to be fast (since committer dates are monotonic) and because one is usually interested in when patches were committed, not when they were written. But here we have an exception to that, I suppose. Anyway, if I understand correctly then - when performing a mass import, forging the commit dates would make the result easier to make sense of in the way you describe; - when importing one or two or 10 .dscs by hand, on the other hand, this is an act of history creation that could reasonably get a separate committer date, just like "git cherry-pick" or "git rebase" would do. Does that seem right? I'm trying to get a feel for whether the --author-is-committer part is needed (I hope not). 'night, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
