Guido Günther wrote:
> On Wed, Jan 19, 2011 at 09:18:33PM -0600, Rob Browning wrote:
>> For what it's worth, I believe having current committer dates also
>> alters the way gitk sorts its display.
Makes sense. Not too relevant here, but have you tried
"gitk --topo-order"?
> So I think having this as config option seems the only way to go. Do you
> agree with the options propsed?
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]
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
