Hi Jonathan, On Thu, Jan 20, 2011 at 03:06:07AM -0600, Jonathan Nieder wrote: [..snip..] > git assumes each commit has an equal or later timestamp to each of its > parents and uses that assumption to optimize commands like "git log > <foo>..<bar>" and "git name-rev <foo>".[1]
I think we should be safe with the defaults and the --author-is-committer and --author-date-is-committer-date options give folks just enough rope. Cheers and thanks for your explanation, -- Guido > > Ideally "git commit-tree" should warn about non-monotonic timestamps > to prevent trouble but it currently doesn't. Maybe gbp could error > out when forging a commit date as requested would cause a commit to be > older than one of its parents. > > Aside from that detail, an option to enable or disable forging the > commit date sounds good to me. Since the current default is to always > forge the commit date, an option could only diminish the problem. :) > > As for --committer-is-author, sounds harmless enough. If one is very > lucky then two independent imports can get the same commit names that > way. > > Sorry for the ramble. > Jonathan > > [1] So if you try, say: > > git init /tmp/test > cd /tmp/test > for i in 1 2 3 4 5 6 7 8 9 10 > do > git commit --allow-empty -m "commit $i" > done > git branch old > for i in 1 2 3 4 5 6 7 8 9 10 > do > GIT_COMMITTER_DATE="Thu Jan 01 00:00:00 PST 2000" \ > git commit --allow-empty -m "commit $i - B" > done > git branch new > > git log --oneline new..old | wc -l > > then you will get 10 instead of the 0 that probably was expected. > > That same sort of sequence can happen easily using git import-dsc. > > ... hack hack hack ... > # fix up last (unpublished) commit message > git commit --amend > > # some proposed uploads to look over... > git import-dscs --forge-commit-date ../1.dsc ../2.dsc ../3.dsc > > git log master..upstream/master > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
