You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
1
(1) |
2
(4) |
3
(2) |
4
|
|
5
(1) |
6
|
7
(1) |
8
(2) |
9
(3) |
10
(1) |
11
(6) |
|
12
|
13
(2) |
14
(4) |
15
(2) |
16
(1) |
17
(1) |
18
(24) |
|
19
(1) |
20
(4) |
21
(1) |
22
|
23
|
24
(5) |
25
(2) |
|
26
(6) |
27
(3) |
28
(5) |
|
|
|
|
|
From: Ivo R. <iv...@iv...> - 2017-02-28 22:45:15
|
2017-02-28 23:13 GMT+01:00 Tom Hughes <to...@co...>: > On 28/02/17 20:56, Ivo Raisr wrote: > >> So we decided to stick with existing (SVN) workflow which translates to >> "rebased branches at the top of the tree". >> Our valgrind.git config will have (after the final migration happens): >> >> [receive] >> denyNonFastforwards = true > > > That doesn't actually prevent people pushing merges though, it just stops > history being rewritten - the push to the remote can only move the remote > forward but the pushed commits can include merges. Good point. So I think it's the time to start gathering config for AdaCore git hooks [1] [2] which is used at sourceware.org. ---------------------------------- [hooks] from-domain = sourceware.org mailinglist = val...@li... # Allow to include debugging output in commit messages. max-rh-line-length = 0 # Forces to rebase changes before pushing to master and release branches. reject-merge-commits = refs/heads/master, refs/heads/VALGRIND_.* commit-url = "https://sourceware.org/git/?p=valgrind.git;h=%(rev)s" # No emails from private user branches. no-emails = /refs/heads/user/.* ---------------------------------- Your thoughts? I. [1] https://github.com/adacore/git-hooks [2] https://sourceware.org/gdb/wiki/GitHooksUsersGuide |
|
From: Tom H. <to...@co...> - 2017-02-28 22:14:03
|
On 28/02/17 20:56, Ivo Raisr wrote: > So we decided to stick with existing (SVN) workflow which translates to > "rebased branches at the top of the tree". > Our valgrind.git config will have (after the final migration happens): > > [receive] > denyNonFastforwards = true That doesn't actually prevent people pushing merges though, it just stops history being rewritten - the push to the remote can only move the remote forward but the pushed commits can include merges. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Ivo R. <iv...@iv...> - 2017-02-28 21:35:44
|
2017-02-28 22:16 GMT+01:00 Christian Borntraeger <bor...@de...>: > The given workflow requires that there is no other push between the pull > and the push. If for some reason somebody else pushes some update after > you have commited, you can recover with a rebase. There is a nice combine > of pull + rebase: > git pull --rebase > and I think we might just want to document that. Definitely yes. Would you mind suggesting something like docs/internals/git-HOWTO.txt, possibly taking into account existing docs/internals/svn-HOWTO.txt. Thank you, I. |
|
From: Christian B. <bor...@de...> - 2017-02-28 21:16:26
|
On 02/28/2017 09:56 PM, Ivo Raisr wrote: [...] > > So we decided to stick with existing (SVN) workflow which translates to > "rebased branches at the top of the tree". Which is a perfectly fine model that makes sense in our project. > Our valgrind.git config will have (after the final migration happens): > > [receive] > denyNonFastforwards = true > > So based on this information, could you suggest different git commands > (with some reasoning) than initially outlined by me? The given workflow requires that there is no other push between the pull and the push. If for some reason somebody else pushes some update after you have commited, you can recover with a rebase. There is a nice combine of pull + rebase: git pull --rebase and I think we might just want to document that. |
|
From: Ivo R. <iv...@iv...> - 2017-02-28 20:56:27
|
2017-02-27 10:02 GMT+01:00 Christian Borntraeger <bor...@de...>:
> For a pull like approach I would suggest to either
> a: do not this step (Linux style git handling)
> b: use git pull --rebase (flat history style)
>
>
>> build + test
>> git commit
>> [git push - if you have write access]
>
> If we give write accesses, then I suggest to use the --rebase variant.
> Not sure what git server is running, but git-o-lite for example allows
> to reject non-fast-forward merges, so that we do not fill the
> history with single patch merge commits.
> Merge commits can be very useful though, if the merge commit contains
> a description of a multititude of patches.
Are you referring here to the git merge model?
We had a discussion with Mark Wielaard previously which git model to use:
----------------------
> > And given the git model we should also
> > decide whether we want a merge model or that we ask people to only push
> > rebased branches at the top of the tree. The merge model is more
> > flexible and more accurately shows the development history if features
> > get developed/integrated in parallel. But having just one straight
> > linear commit history often helps with bisecting and precisely
> > pin-pointing when bugs were introduced. I know sourceware can setup
> > commit/push hooks to make sure one or the other model is followed.
>
> I think the second one reflects what we have been using in SVN.
> Any reason to change that other than that it's more GIT'ish?
I think that is a fine reason and probably works out nicely when
multiple people push to the same repository. The "more GIT'sh" way is
(IMHO) slightly nicer when there is a single person that pushes to a
repo. Merges often represent work others did and show where they started
off and where they integrated their work. But this can (IMHO) get
slightly messy if multiple people push to the same repo.
---------------------
So we decided to stick with existing (SVN) workflow which translates to
"rebased branches at the top of the tree".
Our valgrind.git config will have (after the final migration happens):
[receive]
denyNonFastforwards = true
So based on this information, could you suggest different git commands
(with some reasoning) than initially outlined by me?
I.
|