Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On Sat, 4 Jul 2015 20:20:23 +0200 Peter Stuge wrote: It's important that the review flow is well-understood and efficient. This is impossible in our case due to the lack of manpower. We already have a lot of bugs, patches, stabilization requests hanging over there for months and even years. Stabilization request will require at least two developers to participate in each commit. This will double manpower required at least. Such approach can kill the whole project. Code review is good at a limited scope, e.g. for non-developers where we have review anyway. And as was already told in this thread, the best is the enemy of the good. In no way we should delay git migration due to possible git review. Best regards, Andrew Savchenko pgpaeQblTgCEP.pgp Description: PGP signature
Re: [gentoo-dev] Re: Git workflow
On 5 July 2015 at 17:03, C Bergström cbergst...@pathscale.com wrote:
Again I don't see it as lying - (you're still working on stuff until
you push.. development isn't done) The ability to do micro or
incremental commits instead of the svn's forced wait approach is the
benefit here.
Generally its better to structure the tree in the order it *should*
happen, not the order it *did* happen.
[intentional sillyness: ] If we were to order the tree in the way it
*did* happen, we'd have to work out when which person thought about
which idea first and what they were looking at when they thought of
that, and re-arrange commits to suit that order. {/instentional
sillyness]
Obviously that would be silly.
Generally however that does suggest, that where it is possible to, and
where it is logical to do so, commit squashing and commit re-ordering
is valueable.
For instance, if you commit something locally, and then you realise
you made a trivial mistake 3 commits later, it is better to create the
fix, and move that fix back to when the commit it pertained to. Nobody
wants to wade through dedicated commits where you fix up your mistakes
in minor syntax errors if you can actually avoid that in the first
place.
This also lends its hand to commit oriented testing, as it allows the
pushed trees to always be pristine, and have clean lines of history
that each commit on a given line can be expected to be used
independently, and be expected to be sane, instead of the commit
walker having to isolate the good commits and the bad commits that get
fixed 3 commits later.
The trick is not to be dogmatic about it, and identify the cases where
different things work out to be best, and use your judgement to work
out which one works best.
Rebases and merges were designed to be used in the same repository for
the most part, the only caveat being that any place you perform a
merge, performing a subsequent rebase of that merge gets tricky.
Merges are also convenient for merge reversals if they prove to be
neccessary, because you can just create HEAD with HEAD~3's tree and
you've reverted the whole merge, instead of having to work our where
the massive rebase line started and ended before it was applied
nuclearly and needing reversion ( somehow ). Granted this use case is
expected to be incredibly rare, but its just a demonstration of how
merge can be a help more than a hinderance in specific cases.
Oh, and as for merge commits and not needing patches ... that's
viable. Git is not really patch oriented. Patches are more a view
of the data than the state of the data.
A clean merge just creates a new tree object by duplicating the tree
of HEAD^ where a child leaf is replaced with child leaves from HEAD^^
in a recursive fashion, and any patch as such would be garbage
simply showing a list of SHA1's with +/- on the front of them which
you couldn't directly use.
You could attempt to format that as a patch, but it would be basically
`git diff HEAD^ HEAD^^` with some special rules ( It really doesn't
map directly to diff, there's 3-way-diff format as well, but ... yeah
).
And non-clean merges are a bit of a dogs breakfast and can be a right
pain in the arse if somebody hits them in a rebase. I've just tried to
avoid those because they're too hard, and prefer to find a way to
resolve them in either HEAD^ or HEAD^^ first before merging to make
sure the merge is clean.
--
Kent
KENTNL - https://metacpan.org/author/KENTNL
[gentoo-dev] Last rites: app-text/deplate, app-text/migemo, dev-utils/travis-yaml
# Manuel Rüger mr...@gentoo.org (5 Jul 2015) # Mask for various issues (missing ruby20 support, test failures) # Removal in 30 days app-text/deplate app-text/migemo dev-utils/travis-yaml signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Git workflow
C Bergström wrote: 3) Ever tried to make a patch of the *actual* merge commit? Can one of the advocates of merge show me the git command to do that? (Sure you can diff between 2 commits, but the merge commit likes to avoid being seen) If there are no conflicts when merging then the merge commit does not contain any changes, so how could there be a patch? Do you actually know the Git data model? I wrote it down the other day. http://peter.stuge.se/git-data-model You deflect the question so nicely. If there is no merge conflict then a rebase would be just fine? You clearly know git very well - much better than I, why not just answer the question? I tried to. My point was that when merge commits don't lead to conflicts on file level (branches touch different files) then the merge commit does not modify anything, so the patch is empty. This is where knowing the data model becomes important to not get angry with Git. When you know what is going on internally it's very easy to deal with all the different cases. If on the other hand you make assumptions about what Git does internally based on previous experience or natural language then it's easy to get frustrated. Now, if there are changes in a file in both branches then this needs to be resolved somehow, manually or automatically. There are two or more sources of changes. A patch expresses the difference between two objects; the before and the after so to say, but it can't really be used to express such a merge resolution, becaue there are two before and one after. You would need multiple patches to do so, one for each merged branch. These you could create by diffing each parent with the merge commit. But why do you need to? and a git pull --rebase before push will be clean and fast (no problems). Q: How do you deal with the two commits from other developers that were pushed while you were rebasing? A: You end up having to spin on the remote repo. That's really clumsy. Pragmatically - the answer to you question is the same as it exists today. You're scared of something which gentoo devs have been dealing with and resolving for years. It's not like CVS/SVN handles this magically better. I'm not scared of spinning, but do you agree that it's really clumsy? A merge commit *is* a much better way to handle this. It's accurate and it makes sense. Arguing without checking makes you look bad. How? I didn't claim to know and clearly not knowing didn't seem important (to me). Not knowing what you're arguing makes you look bad because you can only contribute to the discussion if by chance you are correct, which isn't so likely. It's more likely that your argument wastes time and contributes nothing, if you don't know what you argue. This makes you look bad. I'm just trying to passionately bring this up. I think that's fine, and I welcome every discussion about workflow, but it's only useful when everyone makes the effort to be constructive and well-informed. I can't say I've ever cared to know the date of a commit, but I can say I have cared a lot about knowing which commit came 1st. Rebase, for better or worse, forces something to be 1st and it's clear and easy to see. A rebase, like a cherry-pick, loses the very information you claim to care about; the original parent of the commit. To clarify - I don't (clearly) give a pooh what the original parent was. I care much more about a linear history. The linear history doesn't say what came first however, so you're going against yourself. I rarely can see any value of the at-to-time of original commit compared to the final at-push-time commit (what's rebased). Maybe that's the problem. There is great value in this, because it shows how the commit in question was intended to change the base it starts out with. Rebasing might require modifying the commit so that it applies to the new base, so after a rebase it is impossible to know if a given part of the commit was created before the rebase or as part of the rebase. This has two drawbacks; it makes review more difficult and risks introducing bugs because of incomplete or incorrect rebasing. A rebase, like a cherry-pick, combines these two changes into one, and shouldn't be done too lightly. The value of linear history outweighs the arbitrary point you started from. Linear history looks neat, and as I wrote earlier I really like it too, but I also think that losing the extra information within merge commits is not something to be take too lightly. imho a commit and development is not done until it's ready to be pushed. I agree with that, but I think that's separate from the merge vs. rebase discussion. If I controlled the gentoo git server, I'd I think it's a good thing that you don't, since you seem to still need to study Git in more detail. Peter - I'm ashamed of you - don't be a dick. We can keep this civil without subtle insults. Sorry about that - I
Re: [gentoo-dev] Git workflow
On 07/05/2015 06:10 AM, C Bergström wrote: 5) More about linear commits and history - I need to double check, but I don't think rebase changes the actual commit date (I could be mistaken). You are mistaken, and should have double checked before you argued. Arguing without checking makes you look bad. How? I didn't claim to know and clearly not knowing didn't seem important (to me). I'm not trying to overstate anything. I'm just trying to passionately bring this up. I ***wish*** someone with some guts would actually take charge of this on the gentoo side, have a vote or make some executive decision which is stronger than this wimpy policy we have now. Most of what you brought up wasn't really useful critique, but rather noise based on your personal frustration with git. This thread is not about giving lectures on how git works. We appreciate useful comments on the git workflow. But in order to give useful comments, you have to know and understand the project and how it works internally. There will be a sh*tload of developer, feature and whatnot branches. It is just insane to tell everyone to unconditionally do rebases everywhere. You haven't even commented on a fraction of the resulting problems. So please lets stop this discussion and move on.
[gentoo-dev] Problems updating Qt from 4.8.6 to 4.8.7
Hi there! I'm having trouble updating Qt:4 (dev-qt/qt*-4.8*:4) from 4.8.6 to 4.8.7. Looking at the ebuilds, they require some 4.8.7 versions to be installed already that in turn cannot be installed because other ebuilds require 4.8.6 while not yet upgraded. I am running the latest version of portage. Is there some trick I should know about or am I stuck with Qt 4.8.6 on that box forever? How did you update? Thanks for your help, best, S
Re: [gentoo-dev] Re: Git workflow
On Sun, Jul 05, 2015 at 12:03:29PM +0700, C Bergström wrote: On Sun, Jul 5, 2015 at 11:31 AM, Duncan 1i5t5.dun...@cox.net wrote: C Bergström posted on Sun, 05 Jul 2015 01:17:41 +0700 as excerpted: I super don't like merge workflows. 1) merge commits are confusing at best and normal tools don't display and work with them as you'd always expect git log --graph, as others have mentioned. we are not talking about the same thing. I want to see the diff - not the graph. svn diff -r 1234 git show hash show me the merge commit in diff format So this isn't a good comparison. You are asking for a merge commit in git and a normal commit in svn. Svn can branch but it is so complicated that no one ever does it. If you were similarly to never ever make branches in git its not a huge deal. (There are not *that* many pushes to the tree, if you look at #gentoo-commits there is plenty of time between commits.) While I personally rebase almost all of my stuff, merges are important when taking contributions. A good example would be the main linux kernel tree, if Linus were to merge everything it would be incredibly difficult to figure anything out. -- Jason
Re: [gentoo-dev] Git workflow
Sunday 05 Jul 2015 16:03:27, hasufell wrote : On 07/05/2015 06:10 AM, C Bergström wrote: 5) More about linear commits and history - I need to double check, but I don't think rebase changes the actual commit date (I could be mistaken). You are mistaken, and should have double checked before you argued. Arguing without checking makes you look bad. How? I didn't claim to know and clearly not knowing didn't seem important (to me). I'm not trying to overstate anything. I'm just trying to passionately bring this up. I ***wish*** someone with some guts would actually take charge of this on the gentoo side, have a vote or make some executive decision which is stronger than this wimpy policy we have now. Most of what you brought up wasn't really useful critique, but rather noise based on your personal frustration with git. This thread is not about giving lectures on how git works. We appreciate useful comments on the git workflow. But in order to give useful comments, you have to know and understand the project and how it works internally. There will be a sh*tload of developer, feature and whatnot branches. It is just insane to tell everyone to unconditionally do rebases everywhere. You haven't even commented on a fraction of the resulting problems. So please lets stop this discussion and move on. +1 How about you guys carry on this discussion somewhere else in a place like, I don't know, IRC? #which-git-workflow-fits-best-my-needs
Re: [gentoo-dev] Git workflow
On Sun, Jul 05, 2015 at 04:03:27PM +0200, hasufell wrote: On 07/05/2015 06:10 AM, C Bergström wrote: 5) More about linear commits and history - I need to double check, but I don't think rebase changes the actual commit date (I could be mistaken). You are mistaken, and should have double checked before you argued. Arguing without checking makes you look bad. How? I didn't claim to know and clearly not knowing didn't seem important (to me). I'm not trying to overstate anything. I'm just trying to passionately bring this up. I ***wish*** someone with some guts would actually take charge of this on the gentoo side, have a vote or make some executive decision which is stronger than this wimpy policy we have now. Most of what you brought up wasn't really useful critique, but rather noise based on your personal frustration with git. This thread is not about giving lectures on how git works. We appreciate useful comments on the git workflow. But in order to give useful comments, you have to know and understand the project and how it works internally. There will be a sh*tload of developer, feature and whatnot branches. It is just insane to tell everyone to unconditionally do rebases everywhere. You haven't even commented on a fraction of the resulting problems. So please lets stop this discussion and move on. The only thing you would have to worry about is rebasing your commits if they are already pushed. If you are working on a topic branch to make your changes, which has not been published, just rebase that branch on master, then merge it to master, and no one knows any different. I'm going to start a thread on the signatures, because I have a question about that. William signature.asc Description: Digital signature
Re: [gentoo-dev] Problems updating Qt from 4.8.6 to 4.8.7
On Sun, Jul 5, 2015 at 2:25 PM, Sebastian Pipping sp...@gentoo.org wrote: I really wonder if there is any update path from having dev-qt/qtcore-4.8.6-r2 dev-qt/qtgui-4.8.6-r4 installed before to dev-qt/qtcore-4.8.7 dev-qt/qtgui-4.8.7 Usually this kind of conflict happens when for SOME reason, at least one part of the dev-qt/*:4 collection is not being pulled into the depgraph, like if there's one qt* package which is now orphaned/depcleanable. If even one piece is not pulled into the dep list, it will try to hold all the rest of the pieces back at 4.8.6. Something like this may help, to just force all installed qt4 pieces to upgrade, regardless of whether they are deps of anything: emerge -1av $(qlist -ICS dev-qt/ | grep 4$) Another possibility for a conflict is if you have some package.use entries for dev-qt/ that are too version specific, where the upgraded 4.8.7 version of some component would not meet the USE requirements of some reverse dep. Then it'd lock that one component at 4.8.6 and again it's game-over for the upgrade. Hope this helps, Ben Kohler (iamben @ Freenode)
[gentoo-dev] signatures in git work flow
All, I've been hearing lately that the newest versions of git allow you to sign pushes. Once we have a version of git stable that allows this, can someone fill me in on why we would need to sign commits if we sign pushes? If we have a signature on the push, we know where that came from, so it seems to be overkill to sign the commits as well. Thanks, William signature.asc Description: Digital signature
Re: [gentoo-dev] Re: Git workflow
On Sun, Jul 05, 2015 at 07:17:26PM +0400, Jason Zaman wrote: On Sun, Jul 05, 2015 at 12:03:29PM +0700, C Bergström wrote: On Sun, Jul 5, 2015 at 11:31 AM, Duncan 1i5t5.dun...@cox.net wrote: C Bergström posted on Sun, 05 Jul 2015 01:17:41 +0700 as excerpted: I super don't like merge workflows. 1) merge commits are confusing at best and normal tools don't display and work with them as you'd always expect git log --graph, as others have mentioned. we are not talking about the same thing. I want to see the diff - not the graph. svn diff -r 1234 git show hash show me the merge commit in diff format So this isn't a good comparison. You are asking for a merge commit in git and a normal commit in svn. Svn can branch but it is so complicated that no one ever does it. If you were similarly to never ever make branches in git its not a huge deal. (There are not *that* many pushes to the tree, if you look at #gentoo-commits there is plenty of time between commits.) While I personally rebase almost all of my stuff, merges are important when taking contributions. A good example would be the main linux kernel tree, if Linus were to merge everything it would be incredibly difficult to figure anything out. I'm with Duncan on this. I think I understand what he's asking for... I think he is asking the question, What changed in commit hash. If you use the hash of a merge commit with git show, you get nothing, so the merge commit is useless in terms of following changes. William signature.asc Description: Digital signature
Re: [gentoo-dev] Problems updating Qt from 4.8.6 to 4.8.7
On 05.07.2015 20:44, Alexandre Rostovtsev wrote: What I usually end up doing is listing my installed dev-qt/qt* ebuilds, and updating all of them together explicitly: emerge -1 qtcore:4 qtgui:4 qtsql:4 etc. That's what I tried but it doesn't seem to work with this update. Looking at the dependencies of qtgui dev-qt/qtgui-4.8.6-r4 DEPEND ~dev-qt/qtcore-4.8.6 dev-qt/qtgui-4.8.7 DEPEND ~dev-qt/qtcore-4.8.7 I really wonder if there is any update path from having dev-qt/qtcore-4.8.6-r2 dev-qt/qtgui-4.8.6-r4 installed before to dev-qt/qtcore-4.8.7 dev-qt/qtgui-4.8.7 after. Right now, it looks like I have to use emerge -C .. to un-install them completely, temporary breaking Qt and installing 4.8.7 fresh. I'm still hoping for some way to not needing to do that. Alternatively, just try emerge --update --deep world - it probably should work if you have a consistent, complete and updateable world set. That's where I'm coming from. It doesn't stop complaining because of Qt. Best, Sebastian
Re: [gentoo-dev] Git workflow
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, 05 Jul 2015 21:35:23 +0200 hasufell hasuf...@gentoo.org wrote: https://wiki.gentoo.org/wiki/Gentoo_git_workflow#naming_convention Ah ha! I must have missed that the last time that I read that wiki article. Thanks for the link hasufell. - -- NP-Hardass -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVmYgOAAoJEBzZQR2yrxj7DJYP/0Bj9eyo1zKRewCfV/VheHi4 ECMTkw0aVsYWCAELfTOZnUh8+jxE7GoE61DYy4xAgC2YjxI8dQhCKhpiK+8LUePy 0YNk7W8u4szNcj47V7/D7+DTebK7ARLQKwxTekKMNMMUmw9XU1wudjmdv1EPKS4h kzDDiswz4BFo5Tllb96FTAoh9uD2M1mpj6B0M0y2svxqp/aBDY6hfiDNMdY64QKc nxkK+Nu7cwaJPJoYyTINVqYrz5W5aaVGTL2EwtL37p+VBfP+K5ygSI3kN/Exo0BP KkrUP+4JAu3G+g/GJqSgVJGmNiKcLG+DvsaTlJBKrcRDpuN9lJnMn5SV3HoMF1iM wEScrzdSgoPUsx1v1r+BidQVlRrS7D0T6r/1rWN3mX2F43AvBCztTJn/sEfG6zyf nRVlckMDKwLof5aeSmPqzpLx6XMqcT5cC+ivehZ9WVgZmfyCh01bNJdf+FsnILrS 6BG3ui61CSbR/0aTTTig0pcoB8Fa0WfzSRFRf1JZsxOewU8OFlx2QNyabi9fUd+n SyJqxgE77J8ZaFPcha4oXhUMvda8IaKE3ISjqdw4cIVtLxILLFMXYIPDg+NAp01P dxZNEV81YF0+D5e6ktel1qA/5SlHGJf7iA7oqsqkz9nkBDhNlZ1KYDrDLoBlzTPK XptZ/bIIeZipRxyQILTX =rNhp -END PGP SIGNATURE-
Re: [gentoo-dev] Git workflow
On 07/05/2015 08:57 PM, William Hubbs wrote: On Sun, Jul 05, 2015 at 04:03:27PM +0200, hasufell wrote: On 07/05/2015 06:10 AM, C Bergström wrote: 5) More about linear commits and history - I need to double check, but I don't think rebase changes the actual commit date (I could be mistaken). You are mistaken, and should have double checked before you argued. Arguing without checking makes you look bad. How? I didn't claim to know and clearly not knowing didn't seem important (to me). I'm not trying to overstate anything. I'm just trying to passionately bring this up. I ***wish*** someone with some guts would actually take charge of this on the gentoo side, have a vote or make some executive decision which is stronger than this wimpy policy we have now. Most of what you brought up wasn't really useful critique, but rather noise based on your personal frustration with git. This thread is not about giving lectures on how git works. We appreciate useful comments on the git workflow. But in order to give useful comments, you have to know and understand the project and how it works internally. There will be a sh*tload of developer, feature and whatnot branches. It is just insane to tell everyone to unconditionally do rebases everywhere. You haven't even commented on a fraction of the resulting problems. So please lets stop this discussion and move on. The only thing you would have to worry about is rebasing your commits if they are already pushed. I will repeat it once more: 1. conflict resolution is more difficult with rebases (rebases are still encouraged though in the current git workflow draft, it just seems people haven't read it), it will increase the amount of bad commits. And it can be a lot more work. 2. doesn't work if you want to properly merge user branches (or literally any branch) without losing information (such as development information contained in the branch-structure or user signatures) 3. is totally unrelated to the topic of a clean git history. You can have an unclean git history with rebases and merges and without rebases and without merges. 4. complicates concurrent branches... it will lead to mass-cherry-picking or non-fast-forward pushes (which will be rejected, at least on the master branch) which are both terrible workflows and very prone to error 5. doesn't work particularly well with pull requests since the merged pull request may diverge non-trivially from the branch it comes from (especially if the guy who merges decides to squash commits or whatnot). There are workarounds to that, but they may complicate a PR-workflow without further tooling (such as gerrit). 6. limits developers to a particular workflow type without a good reason (I want a linear history! alone isn't really one). The gentoo git workflow draft already tries to give hints about when to use rebases and when to use merges in order to ensure a clean history. Ofc these hints could be improved. 7. If you want a patch-based DVCS, then git is the wrong choice. Use darcs instead. It does a far better job at that. Rebases are not easy in non-trivial projects. They have some advantages though and that's why the draft recommends to try a rebase first for regular push-conflicts. Ofc, you only know that if you have read it.
Re: [gentoo-dev] Problems updating Qt from 4.8.6 to 4.8.7
On Sun, 2015-07-05 at 20:25 +0200, Sebastian Pipping wrote: Hi there! I'm having trouble updating Qt:4 (dev-qt/qt*-4.8*:4) from 4.8.6 to 4.8.7. Looking at the ebuilds, they require some 4.8.7 versions to be installed already that in turn cannot be installed because other ebuilds require 4.8.6 while not yet upgraded. I am running the latest version of portage. Is there some trick I should know about or am I stuck with Qt 4.8.6 on that box forever? How did you update? What I usually end up doing is listing my installed dev-qt/qt* ebuilds, and updating all of them together explicitly: emerge -1 qtcore:4 qtgui:4 qtsql:4 etc. Alternatively, just try emerge --update --deep world - it probably should work if you have a consistent, complete and updateable world set.
Re: [gentoo-dev] Git workflow
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, 5 Jul 2015 15:00:26 -0400 NP-Hardass np-hard...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On July 5, 2015 2:57:14 PM EDT, William Hubbs willi...@gentoo.org wrote: If you are working on a topic branch to make your changes, which has not been published, just rebase that branch on master, then merge it to master, and no one knows any different. William Speaking of which... Will there be some sort of standard or policy regarding branch names? - -- NP-Hardass I would think that there would be a very small number of branches to the main master tree. Those would be for the large projects like kde, gnome,... They would still do their development work in their overlays, then move them into a branch for final prep and checks, then merge from there into master with one merge commit. Any other small branches could live in developer space if they needed to share them with one or two others. With git it is easy to add other remotes to pull and checkout from. So, no need to clutter up the main git repo with small experimental branches. - -- Brian Dolbec dolsen -BEGIN PGP SIGNATURE- Version: GnuPG v2.1 iQJ8BAEBCgBmBQJVmYP0XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNUQ3Qzc0RTA4MUNDNzBEQjRBNEFBRjVG QkJEMDg3Mjc1ODIwRUQ4AAoJEPu9CHJ1gg7YCYkP/3rQW/tBdwz7Aw+hm3wur85n V8wzEKy5Xaf4oFhoFZPhE/VGFwxp2Bgy+mMjKMgJnlB3Ai6DVLJ50reAxmrcj/x9 juGTqEZRris3FiJ76DhdhCG4/jQMcA1n5Xrh/RoqD0b3OZuBBcT14xEireytNLAc BEmtDUvi51KKLJP5SAHArCXknGP/KLaxbsTqTpBi9apfi7Apg+N1bDLLxRWBKCUD NfVGU8ne1/LIi0GDqfuEOb6s+LkSKr5N1DGbJI6xYoPxt0ZUu/MJPnDSuPocfMT3 RaJlgmcQ4keO9EZZIyud0bFxRMJeW4YkLwACi/Fi+7DaZN2RKqXWRIF2UxDMJkBN UJMcUzOj/hOcKSkrNDpzcgd41XldCEQ3a3Hj/o3PiSerJfPNJHc9+EbzQ5qD4WnY LbTeqWRSdXeWN4lEJlc2hkE1El6cXhO02AgO59LarTjHYvE3AbFcJsRrZs2gKoSf DES3nfHy4NtET/mcctfVdMo/0hHQ9ca/U8AgRoEe4HJIZsKNvGqkvlGm851Zw6QD opE28fgtqzrZBK4CWukcHdpkouuizlFrkdoBGM6fGfixj9dWyCdLXJBSZv4+u6cp HS4AjxzSzq2aUnK0T+rT00Tiuc8x1Hb/TJDjhzSmVUd3UfVIPAWz+Z8TvGnZMLbH id7ovWmGfURvlzVUyBl4 =ePhP -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Git workflow
On Mon, Jul 6, 2015 at 2:15 AM, William Hubbs willi...@gentoo.org wrote: On Sun, Jul 05, 2015 at 07:17:26PM +0400, Jason Zaman wrote: On Sun, Jul 05, 2015 at 12:03:29PM +0700, C Bergström wrote: On Sun, Jul 5, 2015 at 11:31 AM, Duncan 1i5t5.dun...@cox.net wrote: C Bergström posted on Sun, 05 Jul 2015 01:17:41 +0700 as excerpted: I super don't like merge workflows. 1) merge commits are confusing at best and normal tools don't display and work with them as you'd always expect git log --graph, as others have mentioned. we are not talking about the same thing. I want to see the diff - not the graph. svn diff -r 1234 git show hash show me the merge commit in diff format So this isn't a good comparison. You are asking for a merge commit in git and a normal commit in svn. Svn can branch but it is so complicated that no one ever does it. If you were similarly to never ever make branches in git its not a huge deal. (There are not *that* many pushes to the tree, if you look at #gentoo-commits there is plenty of time between commits.) While I personally rebase almost all of my stuff, merges are important when taking contributions. A good example would be the main linux kernel tree, if Linus were to merge everything it would be incredibly difficult to figure anything out. I'm with Duncan on this. I think I understand what he's asking for... I think he is asking the question, What changed in commit hash. If you use the hash of a merge commit with git show, you get nothing, so the merge commit is useless in terms of following changes. That comment was from me (not Duncan) I have responded to every point - 1 by 1, but the passionate people (most polite term I can find) haven't addressed most of the problems or why commit reordering is a particular problem in gentoo's typical case. To avoid the ire of the bystanders - I'm out of this thread and maybe those with more tact and tolerance carry this forward.
Re: [gentoo-dev] Git workflow
On 07/05/2015 09:00 PM, NP-Hardass wrote: On July 5, 2015 2:57:14 PM EDT, William Hubbs willi...@gentoo.org wrote: If you are working on a topic branch to make your changes, which has not been published, just rebase that branch on master, then merge it to master, and no one knows any different. William Speaking of which... Will there be some sort of standard or policy regarding branch names? https://wiki.gentoo.org/wiki/Gentoo_git_workflow#naming_convention
Re: [gentoo-dev] signatures in git work flow
On 07/05/2015 04:01 PM, William Hubbs wrote: All, I've been hearing lately that the newest versions of git allow you to sign pushes. Once we have a version of git stable that allows this, can someone fill me in on why we would need to sign commits if we sign pushes? If we have a signature on the push, we know where that came from, so it seems to be overkill to sign the commits as well. The link Robin posted is a fun read and explains why: http://mikegerwitz.com/papers/git-horror-story
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On Sun, Jul 05, 2015 at 09:05:59AM +0300, Andrew Savchenko wrote: On Sat, 4 Jul 2015 20:20:23 +0200 Peter Stuge wrote: It's important that the review flow is well-understood and efficient. This is impossible in our case due to the lack of manpower. We already have a lot of bugs, patches, stabilization requests hanging over there for months and even years. Stabilization request will require at least two developers to participate in each commit. This will double manpower required at least. Such approach can kill the whole project. Agreed. Forcing all commits from developers to go through a code review from another developer before they hit the tree would potentially kill the entire project. I would strongly veto something like this, because we flat out don't have the manpower to keep up with it. Code review is good at a limited scope, e.g. for non-developers where we have review anyway. Agreed; I could see something like this being beneficial. William signature.asc Description: Digital signature
Re: [gentoo-dev] Git workflow
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On July 5, 2015 2:57:14 PM EDT, William Hubbs willi...@gentoo.org wrote: If you are working on a topic branch to make your changes, which has not been published, just rebase that branch on master, then merge it to master, and no one knows any different. William Speaking of which... Will there be some sort of standard or policy regarding branch names? - -- NP-Hardass -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVmX7KAAoJEBzZQR2yrxj7jJ4P/0DBoOxsAo9PDRXlglylBaPy QX3LbQVKPs6910FGN7HXNFBHvYSAmbV8twrd0LchCDcjVnx8jZcuBymC1uVvEbpu A9dCpZTDnnzoSSn8idWkvd8T1Zi5xmON34czPm4G+FvI+vBeJtYS/2cO80e/JvXa vlpDBW6DKDxhJoBeTzxsdKk5kVFbK0ULSoKl8cx7zp+Q0R498dqDOy07/qJBCDJm BwUZQNkUSHNy2tBz0yu6r9xJB0Utfso462SEkLVluM7dpM4o2N4ADqo24gzybYPC x246bDqPhQ8xNQeL4TiTqv+WkdWcZqSP8saOu5l2njQfuW3bL7QIxhHBPJ21uRMn L4RWpgHm10utnCglp8ZYeVC+CVaa/XS9ZJJEtbD1ftqPSO98yrip/y4j512b0X+h 7awBJk8g1BsZ3Ilwm67R3DqDVAnUBV2hyz84aN7/CzDAgqyh48y7ROSw3i/QkRh4 33c9gol00BGNFL1fc8kj4LdY+D/7WVAG7ysYklf64GVtSCMs2ibIrgfz5myswKgo 2VBQEaAIQTx7wa4mfd3KOL9ry1VQmoRR+vxv9OrExPVp4xU/wTpgkG8mZ1w2TZqv IJf52JOQ1tJzTDWV/9HmtBuGH8QIG7M48V0mJvhEw0sutkYeKxTDMvVkM0+YaGIB Or5Qo4Pi1bRcNOleG5c1 =yOlr -END PGP SIGNATURE-
Re: [gentoo-dev] Problems updating Qt from 4.8.6 to 4.8.7
On Sun, 2015-07-05 at 21:25 +0200, Sebastian Pipping wrote: On 05.07.2015 20:44, Alexandre Rostovtsev wrote: What I usually end up doing is listing my installed dev-qt/qt* ebuilds, and updating all of them together explicitly: emerge -1 qtcore:4 qtgui:4 qtsql:4 etc. That's what I tried but it doesn't seem to work with this update. Looking at the dependencies of qtgui dev-qt/qtgui-4.8.6-r4 DEPEND ~dev-qt/qtcore-4.8.6 dev-qt/qtgui-4.8.7 DEPEND ~dev-qt/qtcore-4.8.7 I don't think that DEPEND would block an update unless --with-bdeps=y
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On Sunday 05 July 2015 13:46:10 William Hubbs wrote: On Sun, Jul 05, 2015 at 09:05:59AM +0300, Andrew Savchenko wrote: On Sat, 4 Jul 2015 20:20:23 +0200 Peter Stuge wrote: It's important that the review flow is well-understood and efficient. This is impossible in our case due to the lack of manpower. We already have a lot of bugs, patches, stabilization requests hanging over there for months and even years. Stabilization request will require at least two developers to participate in each commit. This will double manpower required at least. Such approach can kill the whole project. Agreed. Forcing all commits from developers to go through a code review from another developer before they hit the tree would potentially kill the entire project. I would strongly veto something like this, because we flat out don't have the manpower to keep up with it. ... or you have some pranksters just ok-ing all commits during their morning coffee, independent of content, which would keep things working at the cost of quality ...
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2015-07-05 23:59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2015-07-05 23:59 UTC. Removals: dev-java/excalibur-logger 2015-06-29 12:44:14 monsieurp kde-misc/kcmsystemd 2015-06-29 20:47:30 johu games-misc/gpe-julia2015-07-02 10:53:51 mrueg games-puzzle/gpe-lights 2015-07-02 10:54:53 mrueg gpe-utils/gpe-clock 2015-07-02 10:55:44 mrueg gpe-utils/gpe-edit 2015-07-02 10:55:44 mrueg gpe-utils/gpe-filemanager 2015-07-02 10:55:44 mrueg gpe-utils/gpe-ownerinfo 2015-07-02 10:55:44 mrueg gpe-utils/gpe-plucker 2015-07-02 10:55:44 mrueg gpe-utils/gpe-taskmanager 2015-07-02 10:55:44 mrueg gpe-utils/gpe-what 2015-07-02 10:55:44 mrueg gpe-base/gpe2015-07-02 10:56:33 mrueg gpe-base/gpe-calculator 2015-07-02 10:56:33 mrueg gpe-base/gpe-contacts 2015-07-02 10:56:33 mrueg gpe-base/gpe-dm 2015-07-02 10:56:33 mrueg gpe-base/gpe-gallery2015-07-02 10:56:33 mrueg gpe-base/gpe-icons 2015-07-02 10:56:33 mrueg gpe-base/gpe-login 2015-07-02 10:56:33 mrueg gpe-base/libcontactsdb 2015-07-02 10:56:33 mrueg gpe-base/libdisplaymigration2015-07-02 10:56:33 mrueg gpe-base/libeventdb 2015-07-02 10:56:33 mrueg gpe-base/libgpelaunch 2015-07-02 10:56:33 mrueg gpe-base/libgpepimc 2015-07-02 10:56:34 mrueg gpe-base/libgpevtype2015-07-02 10:56:34 mrueg gpe-base/libgpewidget 2015-07-02 10:56:34 mrueg gpe-base/libgtkstylus 2015-07-02 10:56:34 mrueg gpe-base/libhandoff 2015-07-02 10:56:34 mrueg gpe-base/libmimedir 2015-07-02 10:56:34 mrueg gpe-base/libschedule2015-07-02 10:56:34 mrueg gpe-base/libtododb 2015-07-02 10:56:34 mrueg dev-perl/inline-files 2015-07-04 12:32:39 dilfridge sys-apps/getent 2015-07-04 19:43:48 blueness www-servers/gorg2015-07-05 06:32:17 graaff Additions: net-p2p/classified-ads 2015-06-29 05:39:09 idella4 kde-misc/systemd-kcm2015-06-29 20:43:23 johu net-wireless/horst 2015-07-01 05:44:26 xmw app-portage/grs 2015-07-01 10:42:57 blueness net-libs/nfqueue-bindings 2015-07-01 22:39:58 zmedico dev-python/locustio 2015-07-02 00:54:11 chutzpah dev-python/setuptools_scm 2015-07-03 14:46:29 idella4 dev-lang/coffee-script 2015-07-03 22:11:22 mjo dev-perl/Inline-Files 2015-07-04 12:29:54 dilfridge perl-core/Unicode-Collate 2015-07-04 13:44:16 dilfridge app-misc/ckb2015-07-04 13:58:25 mrueg dev-python/pykka2015-07-04 14:02:56 mrueg dev-python/freezegun2015-07-04 14:06:37 mrueg app-text/itex2mml 2015-07-04 14:56:54 mrueg dev-ruby/itextomml 2015-07-04 15:16:29 mrueg dev-ruby/ritex 2015-07-04 16:05:27 mrueg dev-ruby/websocket-driver 2015-07-04 19:24:27 graaff dev-ruby/poltergeist2015-07-04 19:26:31 graaff dev-ruby/nenv 2015-07-04 20:27:23 mrueg dev-python/pytest-capturelog2015-07-05 09:14:24 mrueg dev-python/pytest-localserver 2015-07-05 09:15:55 mrueg dev-python/vcrpy2015-07-05 10:47:29 mrueg x11-misc/flow-pomodoro 2015-07-05 10:53:06 mrueg dev-libs/injeqt 2015-07-05 20:06:58 reavertm -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: dev-java/excalibur-logger,removed,monsieurp,2015-06-29 12:44:14 kde-misc/kcmsystemd,removed,johu,2015-06-29 20:47:30 games-misc/gpe-julia,removed,mrueg,2015-07-02 10:53:51 games-puzzle/gpe-lights,removed,mrueg,2015-07-02 10:54:53 gpe-utils/gpe-clock,removed,mrueg,2015-07-02 10:55:44 gpe-utils/gpe-edit,removed,mrueg,2015-07-02 10:55:44 gpe-utils/gpe-filemanager,removed,mrueg,2015-07-02 10:55:44 gpe-utils/gpe-ownerinfo,removed,mrueg,2015-07-02 10:55:44 gpe-utils/gpe-plucker,removed,mrueg,2015-07-02 10:55:44 gpe-utils/gpe-taskmanager,removed,mrueg,2015-07-02 10:55:44 gpe-utils/gpe-what,removed,mrueg,2015-07-02 10:55:44 gpe-base/gpe,removed,mrueg,2015-07-02 10:56:33 gpe-base/gpe-calculator,removed,mrueg,2015-07-02 10:56:33 gpe-base/gpe-contacts,removed,mrueg,2015-07-02 10:56:33 gpe-base/gpe-dm,removed,mrueg,2015-07-02 10:56:33 gpe-base/gpe-gallery,removed,mrueg,2015-07-02 10:56:33 gpe-base/gpe-icons,removed,mrueg,2015-07-02 10:56:33 gpe-base/gpe-login,removed,mrueg,2015-07-02 10:56:33 gpe-base/libcontactsdb,removed,mrueg,2015-07-02 10:56:33 gpe-base/libdisplaymigration,removed,mrueg,2015-07-02 10:56:33
Re: [gentoo-dev] Git workflow
On Sun, Jul 5, 2015 at 3:22 PM, Brian Dolbec dol...@gentoo.org wrote: I would think that there would be a very small number of branches to the main master tree. Those would be for the large projects like kde, gnome,... They would still do their development work in their overlays, then move them into a branch for final prep and checks, then merge from there into master with one merge commit. Any other small branches could live in developer space if they needed to share them with one or two others. With git it is easy to add other remotes to pull and checkout from. So, no need to clutter up the main git repo with small experimental branches. ++ No reason to create barriers for devs maintaining branches in the main repo, but in general this should be done when there is a lot of collaboration going on, and not as a replacement for overlays/etc. You can have as many remotes as you want already. I recommend that devs use discretion. -- Rich
Re: [gentoo-dev] signatures in git work flow
On 6 July 2015 at 08:01, William Hubbs willi...@gentoo.org wrote: Once we have a version of git stable that allows this, can someone fill me in on why we would need to sign commits if we sign pushes? If we have a signature on the push, we know where that came from, so it seems to be overkill to sign the commits as well. The TL;DR of why though is basically: It allows a verifiable record of which user set BRANCH/$ID to == $COMMITSHA1. That is all. It doesn't verify the commits themselves, only where they are visible. ( ie: so if there's experimental dangerous stuff in a side branch, a malicious dev can't point master to there and blame the person with the signed commit for breaking the tree ) I noted that even though I can sign pushes now, upon experimentation I found the server couldn't respond to signed pushes. Seems you need to upgrade git on the receiving side *first* to make the feature even an optional thing. ( Github for instance does not support signed pushes yet either ). So we'd have to get it working in an optional state long before we could get it to be mandatory. -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Re: Git workflow
On 6 July 2015 at 07:15, William Hubbs willi...@gentoo.org wrote: If you use the hash of a merge commit with git show, you get nothing, so the merge commit is useless in terms of following changes. git show SHA1 -m -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] signatures in git work flow
On Sun, Jul 5, 2015 at 4:01 PM, William Hubbs willi...@gentoo.org wrote: I've been hearing lately that the newest versions of git allow you to sign pushes. Once we have a version of git stable that allows this, can someone fill me in on why we would need to sign commits if we sign pushes? If we have a signature on the push, we know where that came from, so it seems to be overkill to sign the commits as well. Those push signatures aren't actually exposed to users, and I'm not sure if they're really even a part of the repository, but more like a log item. This is a bit like saying why do we need signed manifests when devs already need an ssh key to commit to cvs? Push signatures are just another form of authentication for pushing. Commit signatures are bound to the specific changes, and follow the code around if it gets branched/merged/etc (but not rebased). Pushing and committing aren't really the same thing in git, though our single-master workflow tends to make them seem interchangeable. That's my general sense of it. All the gpg stuff really exposes the weakness of git being based on sha1 though. I wouldn't think that it would be that hard to change git's hash function, with the caveat that the resulting repositories might not be backwards-compatible. Just change the various headers from blob to blob-sha256 and so on - the compacted file formats might require a tweak and should have a field added for hash type anytime a hash is used. The old commits with signatures/etc would still be valid - they'd continue to be named by their sha1 hashes and references to them would use a blob/tree/parent/etc header instead of a blob-sha256/tree-sha256/parent-sha256 header and so on. For compatibility make the default to stick with sha1 and the old file formats on an old repository unless a setting is set on it, and deprecate the format. -- Rich
Re: [gentoo-dev] Problems updating Qt from 4.8.6 to 4.8.7
On 6 July 2015 at 03:25, Sebastian Pipping sp...@gentoo.org wrote: On 05.07.2015 20:44, Alexandre Rostovtsev wrote: What I usually end up doing is listing my installed dev-qt/qt* ebuilds, and updating all of them together explicitly: emerge -1 qtcore:4 qtgui:4 qtsql:4 etc. That's what I tried but it doesn't seem to work with this update. Looking at the dependencies of qtgui dev-qt/qtgui-4.8.6-r4 DEPEND ~dev-qt/qtcore-4.8.6 dev-qt/qtgui-4.8.7 DEPEND ~dev-qt/qtcore-4.8.7 I really wonder if there is any update path from having dev-qt/qtcore-4.8.6-r2 dev-qt/qtgui-4.8.6-r4 installed before to dev-qt/qtcore-4.8.7 dev-qt/qtgui-4.8.7 after. Right now, it looks like I have to use emerge -C .. to un-install them completely, temporary breaking Qt and installing 4.8.7 fresh. I'm still hoping for some way to not needing to do that. Alternatively, just try emerge --update --deep world - it probably should work if you have a consistent, complete and updateable world set. That's where I'm coming from. It doesn't stop complaining because of Qt. Best, Sebastian See also https://wiki.gentoo.org/wiki/Qt/FAQ#Why_do_I_get_blockers_when_trying_to_emerge_Qt.3F -- Cheers, Ben | yngwin Gentoo developer
