Re: Empty merges per release
On Wednesday 27 April 2011, John Layt wrote: > On Wednesday 27 Apr 2011 19:59:05 Alexander Neundorf wrote: > > I mean, I can help with simple things. > > > > If we agree that the following pages should be gone > > http://techbase.kde.org/Development/Tutorials/Git Done. I.e. I made the page empty (with just a big warning and a link to the centrla git page), changed all links to it to point to the central git page now. I did not really want to delete it, because this would have completely deleted the page including history. Do we really want this ? > > http://techbase.kde.org/Development/Tutorials/Git/Pushing Done. > > http://techbase.kde.org/Development/Tutorials/Git/KdeOnGit Done. > > I can do that. > > Should I use the "Delete" link or something else ? > > Yes, please delete, just check the Further Resources are on the new page. > > Also delete: > > http://techbase.kde.org/Development/Tutorials/Git/BestPractices Done. > http://techbase.kde.org/Development/Tutorials/Git/Intermediate Done. > http://techbase.kde.org/Development/Tutorials/Git/kde-qt Sure ? > http://techbase.kde.org/Development/Tutorials/Git/decoding-git > > > I could merge the one item from > > http://techbase.kde.org/Development/Tutorials/Git/Recipes into > > http://techbase.kde.org/Development/Git/Recipes and remove the former > > one. > > Delete that without copying, the workflow still needs to be decided and > documented, and cherry-picking and branches already have recipes. Not done yet. The page Tutorials/Git/Recipes seems to be a bit more verbose than the paragraph on the other page. > > What about the git-svn page ? I guess this one is ok, or ? > > Keep that and the Basics page for now, I'll harvest them later. > > > I can also add the extra links from the original Tutorials/Git/ page to > > the new starting page, so they don't get lost. > > That would be good, thanks. Done. > > So, if you want me to do that, please let me know. > > > > Other than that, I don't feel qualified to actually edit content there. > > Neither do I, but no-one else was doing it, so me it was :-) So, whoever has a plan of git, please help and write some documentation on using git for KDE ! Alex
Re: Empty merges per release
On Wednesday 27 Apr 2011 19:59:05 Alexander Neundorf wrote: > I mean, I can help with simple things. > > If we agree that the following pages should be gone > http://techbase.kde.org/Development/Tutorials/Git > http://techbase.kde.org/Development/Tutorials/Git/Pushing > http://techbase.kde.org/Development/Tutorials/Git/KdeOnGit > I can do that. > Should I use the "Delete" link or something else ? Yes, please delete, just check the Further Resources are on the new page. Also delete: http://techbase.kde.org/Development/Tutorials/Git/BestPractices http://techbase.kde.org/Development/Tutorials/Git/Intermediate http://techbase.kde.org/Development/Tutorials/Git/kde-qt http://techbase.kde.org/Development/Tutorials/Git/decoding-git > I could merge the one item from > http://techbase.kde.org/Development/Tutorials/Git/Recipes into > http://techbase.kde.org/Development/Git/Recipes and remove the former one. Delete that without copying, the workflow still needs to be decided and documented, and cherry-picking and branches already have recipes. > What about the git-svn page ? I guess this one is ok, or ? Keep that and the Basics page for now, I'll harvest them later. > I can also add the extra links from the original Tutorials/Git/ page to the > new starting page, so they don't get lost. That would be good, thanks. > So, if you want me to do that, please let me know. > > Other than that, I don't feel qualified to actually edit content there. Neither do I, but no-one else was doing it, so me it was :-) John.
Re: Empty merges per release
On Wednesday 27 April 2011, John Layt wrote: > On Wednesday 27 Apr 2011 17:52:32 Alexander Neundorf wrote: > > On Wednesday 27 April 2011, Thiago Macieira wrote: > > > I know we decided to use cherry-picks to bring commits from past > > > versions to master, > > > > Is this what is described here ? > > http://techbase.kde.org/Development/Tutorials/Git/Recipes > > Well, it's a recipe on how to do a cherry-pick, not official policy. I am > supposed to be drafting a revision the SVN commit policy to address such > issues but 1) I've been otherwise busy and 2) every time the issue of > workflow is raised on k-c-d it just gets ignored or goes around in circles. > I'd planned to try raise it again this weekend, we need to get a policy > sorted. > > > Our git docs are still not in good shape: > > Yeap, I've slowly been adding stuff to > http://techbase.kde.org/Development/Git as I learn it, but help from people > who actually understand Git would be welcome. > > > http://techbase.kde.org/Development/Tutorials/Git - remove ? > > http://techbase.kde.org/Development/Tutorials/Git/Pushing - talks about > > gitorious, remove ? > > http://techbase.kde.org/Development/Tutorials/Git/KdeOnGit - same as > > above, remove ? > > http://techbase.kde.org/Development/Tutorials/Git/Intermediate - not much > > there > > http://techbase.kde.org/Development/Tutorials/Git/Recipes vs. > > http://techbase.kde.org/Development/Git/Recipes - what to do with these > > two ? > > http://techbase.kde.org/Development/Tutorials/Git/git-svn - is this still > > valid ? > > http://techbase.kde.org/Development - the git icon is broken > > The Tutorial is seriously outdated, I haven't had time to eitehr revise it > or extract the good bits from it. I'm contemplating just hiding it for now > as it would be seriously misleading to any GSoC students who try follow it. I mean, I can help with simple things. If we agree that the following pages should be gone http://techbase.kde.org/Development/Tutorials/Git http://techbase.kde.org/Development/Tutorials/Git/Pushing http://techbase.kde.org/Development/Tutorials/Git/KdeOnGit I can do that. Should I use the "Delete" link or something else ? I could merge the one item from http://techbase.kde.org/Development/Tutorials/Git/Recipes into http://techbase.kde.org/Development/Git/Recipes and remove the former one. What about the git-svn page ? I guess this one is ok, or ? I can also add the extra links from the original Tutorials/Git/ page to the new starting page, so they don't get lost. So, if you want me to do that, please let me know. Other than that, I don't feel qualified to actually edit content there. Alex
Re: Empty merges per release
On Wednesday 27 Apr 2011 17:52:32 Alexander Neundorf wrote: > On Wednesday 27 April 2011, Thiago Macieira wrote: > > I know we decided to use cherry-picks to bring commits from past versions > > to master, > > Is this what is described here ? > http://techbase.kde.org/Development/Tutorials/Git/Recipes Well, it's a recipe on how to do a cherry-pick, not official policy. I am supposed to be drafting a revision the SVN commit policy to address such issues but 1) I've been otherwise busy and 2) every time the issue of workflow is raised on k-c-d it just gets ignored or goes around in circles. I'd planned to try raise it again this weekend, we need to get a policy sorted. > Our git docs are still not in good shape: Yeap, I've slowly been adding stuff to http://techbase.kde.org/Development/Git as I learn it, but help from people who actually understand Git would be welcome. > http://techbase.kde.org/Development/Tutorials/Git - remove ? > http://techbase.kde.org/Development/Tutorials/Git/Pushing - talks about > gitorious, remove ? > http://techbase.kde.org/Development/Tutorials/Git/KdeOnGit - same as above, > remove ? > http://techbase.kde.org/Development/Tutorials/Git/Intermediate - not much > there > http://techbase.kde.org/Development/Tutorials/Git/Recipes vs. > http://techbase.kde.org/Development/Git/Recipes - what to do with these two > ? > http://techbase.kde.org/Development/Tutorials/Git/git-svn - is this still > valid ? > http://techbase.kde.org/Development - the git icon is broken The Tutorial is seriously outdated, I haven't had time to eitehr revise it or extract the good bits from it. I'm contemplating just hiding it for now as it would be seriously misleading to any GSoC students who try follow it. For now, http://techbase.kde.org/Development/Git should be the start point for anyone. Cheers! John.
Re: Empty merges per release
On Wednesday 27 April 2011, Thiago Macieira wrote: > I know we decided to use cherry-picks to bring commits from past versions > to master, Is this what is described here ? http://techbase.kde.org/Development/Tutorials/Git/Recipes Our git docs are still not in good shape: http://techbase.kde.org/Development/Tutorials/Git - remove ? http://techbase.kde.org/Development/Tutorials/Git/Pushing - talks about gitorious, remove ? http://techbase.kde.org/Development/Tutorials/Git/KdeOnGit - same as above, remove ? http://techbase.kde.org/Development/Tutorials/Git/Intermediate - not much there http://techbase.kde.org/Development/Tutorials/Git/Recipes vs. http://techbase.kde.org/Development/Git/Recipes - what to do with these two ? http://techbase.kde.org/Development/Tutorials/Git/git-svn - is this still valid ? http://techbase.kde.org/Development - the git icon is broken Alex
Re: Empty merges per release
On Wed, Apr 27, 2011 at 12:17:48PM -, Tom Albers wrote: > - Original Message - > > (oh well, who cares, given all that scripty crap in the history) > > I consider our translations very important for KDE. Would be nice if > people -in general- do not consider translations and the contributors > working on that as second class community members. Calling the scripty > commits 'crap' is weird, really. > do i really have to fight this false dichotomy each time? read the kde-scm-interest@ archive.
Re: Empty merges per release
- Original Message - > (oh well, who > cares, > given all that scripty crap in the history) I consider our translations very important for KDE. Would be nice if people -in general- do not consider translations and the contributors working on that as second class community members. Calling the scripty commits 'crap' is weird, really. Best, -- Tom Albers KDE Sysadmin
Re: Empty merges per release
Em Wednesday, 27 de April de 2011, às 12:46:40, Oswald Buddenhagen escreveu: > if you want to make that git feature useful in the kde-ish cherry-pick > regime, tag the stable branch points - if you want to know when a commit > on a stable branch hit master, you need the extra step of following the > "cherry-picked from" message. this could be actually scripted rather > easily. > > > I recommend at least once, after a release, that the tag is merged > > back into master, using strategy "ours" if necessary. > > > > > > great idea ... all cherry-picked commits duplicated (oh well, who cares, > given all that scripty crap in the history), and still the risk of > falsifying the history by claiming that all commits were merged while > they might have not been. A shadow tag might be useful then. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Empty merges per release
On Wed, Apr 27, 2011 at 09:40:08AM +0200, Thiago Macieira wrote: > I know we decided to use cherry-picks to bring commits from past versions to > master, but this has caused that the 4.5 and 4.6 commits are never in the > past > history of master. > which is the state we had with svn. it was considered good enough so far. if you want to make that git feature useful in the kde-ish cherry-pick regime, tag the stable branch points - if you want to know when a commit on a stable branch hit master, you need the extra step of following the "cherry-picked from" message. this could be actually scripted rather easily. > I recommend at least once, after a release, that the tag is merged > back into master, using strategy "ours" if necessary. > great idea ... all cherry-picked commits duplicated (oh well, who cares, given all that scripty crap in the history), and still the risk of falsifying the history by claiming that all commits were merged while they might have not been.
Empty merges per release
I know we decided to use cherry-picks to bring commits from past versions to master, but this has caused that the 4.5 and 4.6 commits are never in the past history of master. I recommend at least once, after a release, that the tag is merged back into master, using strategy "ours" if necessary. This will make master report to be about a few hundred commits past the v4.6.1 tag, instead of 3500 commits past v4.4.85. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
