Gentoo Archives: gentoo-portage-dev

From: Zac Medico <zmedico@g.o>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] [PATCH] egencache --update-changelogs: fix timestamp assumptions (bug 579292)
Date: Fri, 08 Apr 2016 07:29:47
Message-Id: 57075DE4.1060109@gentoo.org
In Reply to: Re: [gentoo-portage-dev] [PATCH] egencache --update-changelogs: fix timestamp assumptions (bug 579292) by Brian Dolbec
1 On 04/07/2016 11:51 PM, Brian Dolbec wrote:
2 > the above looks good, but what about:
3 >
4 >
5 > [19:01] <dwfreed|phone> just use --first-parent
6 > [19:01] <dwfreed|phone> also take into account merge commits
7 > [19:03] <dwfreed|phone> git really complicates ChangeLog generation in general
8 > [19:03] <dwfreed|phone> because your ChangeLog should reflect when these commits became part of master, but you still need to perserve their messages
9 > [19:04] * zmedico is skeptical about the linearizability of the timestamps
10 > [19:04] <dwfreed|phone> if you don't look at merge commits for your timestamps of changes, correct, it is not linear
11 > [19:05] <dwfreed|phone> but if you take a set of commits and determine when they became part of master, it is linear
12 > [19:05] <dol-sen> so: git log --first-parent --format=%ct -1 .
13 > [19:05] <dol-sen> to get the last timestamp of changes to htat pkg
14 > [19:06] <dol-sen> then use that timestamp
15 > [19:06] <dol-sen> lmod = self.grab(['git', self._work_tree, 'log', '--format=%ct', '-1', '.'])
16 > [19:06] <dol-sen> that is the current code
17 > [19:06] <dwfreed|phone> git log -m --first-parent --format=%ct -1 .
18 > [19:06] <dol-sen> so just add the --first-parent option?
19 > [19:07] <dwfreed|phone> you want -m toolmod = self.grab(['git',
20 > self._work_tree, 'log', '--format=%ct', '-1', '.'])
21 >
22 > [19:06] <dwfreed|phone> git log -m --first-parent --format=%ct -1 .
23 > [19:06] <dol-sen> so just add the --first-parent option?
24 > [19:07] <dwfreed|phone> you want -m too
25 >
26 >
27 > Don't we need to add the -m --first-parent ???
28 >
29
30 I don't know enough about how those options matter for git log behavior,
31 but I trust that dwfreed has good reasons to recommend them. Maybe we
32 should add them in a separate patch, possibly with some explanation
33 about how they are useful in this context.
34 --
35 Thanks,
36 Zac

Replies