Re: Multi-branch committing in git, revisited

Поиск
Список
Период
Сортировка
От David Christensen
Тема Re: Multi-branch committing in git, revisited
Дата
Msg-id D494B745-AF5E-46FE-88EC-684A62FD60BE@endpoint.com
обсуждение исходный текст
Ответ на Multi-branch committing in git, revisited  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Multi-branch committing in git, revisited  (Bruce Momjian <bruce@momjian.us>)
Re: Multi-branch committing in git, revisited  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> If I commit in master
> before I start working on 9.0, and so on back, then the commits will be
> separated in time by a significant amount, thus destroying any chance of
> having git_topo_order recognize them as related.  So we're back up
> against the problem of git not really understanding the relationships of
> patches in different branches.


Is the issue here the clock time spent between the commits, i.e., the possibility that someone is going to push to the
specificbranches in between or the date/time that the commit itself displays?  Because if it's specifically commit time
that'sat issue, I believe `git cherry-pick` preserves the original commit time from the original commit, which should
makethat a non-issue.  Even if you need to fix up a commit to get the cherry-pick to apply, you can always `git commit
-C<ref-of-cherry-pick>` to preserve the authorship/commit time for the commit in question. 

Regards,

David
--
David Christensen
End Point Corporation
david@endpoint.com






В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Multi-branch committing in git, revisited
Следующее
От: "David E. Wheeler"
Дата:
Сообщение: Re: Multi-branch committing in git, revisited