tag:blogger.com,1999:blog-8086052983184217440.comments2022-11-29T11:22:19.101-05:00Paul Stadigpaulhttp://www.blogger.com/profile/14647609048389725132noreply@blogger.comBlogger45125tag:blogger.com,1999:blog-8086052983184217440.post-85103372718291923762017-05-26T07:28:44.868-04:002017-05-26T07:28:44.868-04:00Very interesting! Thanks for sharing those resourc...Very interesting! Thanks for sharing those resources.<br /><br />I figured that I can't be the first to think along these lines.Paul Stadighttps://www.blogger.com/profile/04475151533455732056noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-59571629821173426432017-05-26T07:20:34.062-04:002017-05-26T07:20:34.062-04:00Have you ever looked at Joel Spolsky's "E...Have you ever looked at Joel Spolsky's "Evidence Based Scheduling"? https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/<br /><br />The key feature is using monte carlo methods to statistically combine past estimates and actuals to create a range of possible future outcomes, from which you can say things like we have a 90% chance of finishing by a given date.<br /><br />The #NoEstimates movement does something similar, but also says that the variability in task size is lost in the noise of the variability of estimates anyway, so we might as well assume all tasks are the same size - hence we get a range of possible future outcomes almost as good without even estimating anything.Ianhttps://www.blogger.com/profile/15833033831739364389noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-27377341463354398612016-05-08T08:03:13.774-04:002016-05-08T08:03:13.774-04:00While I agree in general, I will note that some sp...While I agree in general, I will note that some specifics are incorrect. For example, text editors have been around since the previous century. (Not 100 years, yet, but more than a couple decades.)rdmhttps://www.blogger.com/profile/13809495052049903484noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-55887186804048574532016-01-03T21:28:35.727-05:002016-01-03T21:28:35.727-05:00Great ideas
The official rules are too difficult ...Great ideas<br /> The official rules are too difficult for our pre-teen ages to cope with adult strategies. Also puts too much strain on them when the role of the dice isn't going their way.Anonymoushttps://www.blogger.com/profile/00477663217340018345noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-45760939651801954872014-05-07T05:21:31.443-04:002014-05-07T05:21:31.443-04:00The new version of nixos is more usable? I want to...The new version of nixos is more usable? I want to try this distro but I think is more difficult than other package systems.Anonymoushttps://www.blogger.com/profile/05890622437989426805noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-72926182965624263762013-12-30T11:26:10.700-05:002013-12-30T11:26:10.700-05:00iElectric,
Yes! I am a NixOS user, and excited to...iElectric,<br />Yes! I am a NixOS user, and excited to join the community and contribute.<br /><br />The NetworkManager problem I had was glib schemas, so it's good that is getting worked out. I may end up switching to it in the future.<br />Paul Stadighttps://www.blogger.com/profile/04475151533455732056noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-41805335590084300872013-12-30T11:22:20.823-05:002013-12-30T11:22:20.823-05:00Seems you are slowly finding your way into NixOS!
...Seems you are slowly finding your way into NixOS!<br /><br />Few notes:<br /><br />- xmonad recently got options for configuration, see https://github.com/NixOS/nixpkgs/pull/1366<br /><br />- to use NetworkManager see https://nixos.org/wiki/Network_Manager (in unstable, there is a bug in networkmanagerapplet packaging as we are discussing how to handle compiled glib schemas, there is a proposed patch, see https://github.com/NixOS/nixpkgs/pull/1391)<br /><br />- we lack manpower to have all popular desktop managers available, but I'd say that will soon change since the community is growing :-)<br /><br /><br /><br />iElectrichttps://www.blogger.com/profile/18177706290243149760noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-37966617173720648152013-08-12T22:43:50.513-04:002013-08-12T22:43:50.513-04:00A really interesting take! I love this post.
I...A really interesting take! I love this post.<br /><br />I've previously worked in an office, on a distributed team, and as a remote employee. Currently I'm remote, and so is more than half my team.<br />We do have people in an office, but we've made a conscious decision to use the same tools and methods you mention for distributed teams, and use them for remote employees.<br /><br />Eg, the vast majority of our communication both in our team and with other teams, happen over IRC.<br />Sure, some happen in hallways and across desks, but we make a very significant effort to communicate in the same medium.<br /><br />Remote teams definitely can work, there's no reason they shouldn't. But it depends very heavily on having the right type of leadership to recognise how to make it a success and how to develop the proper culture.Anonymoushttps://www.blogger.com/profile/09953733386399584041noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-50156679724223203212013-06-12T13:37:31.334-04:002013-06-12T13:37:31.334-04:00A counter to this article is izs's git-rebase....A counter to this article is izs's <a href="http://blog.izs.me/post/37650663670/git-rebase" rel="nofollow">git-rebase</a>.<br /><br /><i>Rebase is a tool that can be used to arbitrarily edit the commit history. If that sounds universally scary or bad, I’d argue that your understanding of “edit” and “history” are perhaps a bit limited.</i><br /><br /><b>tl;dr:</b> Embrace the difference between draft & published history. Don't edit published history.Johnhttps://www.blogger.com/profile/13442511887203192364noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-67039758537857556902013-01-14T09:53:56.410-05:002013-01-14T09:53:56.410-05:00Thanks for the post. I know it's old, but I st...Thanks for the post. I know it's old, but I still refer back to it from time to time.Jason Rogershttps://www.blogger.com/profile/03512788621802164511noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-16064404527502653242012-12-13T14:57:03.944-05:002012-12-13T14:57:03.944-05:00Great idea, Paul! I was looking for the same thing...Great idea, Paul! I was looking for the same thing for my 5-year-old and used your rules. I added a few ideas of my own, like attacking only from neighboring countries. But the result was the same: after fifteen minutes, he became impatient and left. They're too young, I guess. Still, he was glad we played.MMhttps://www.blogger.com/profile/06390387706426107511noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-89373266589324916282012-02-28T10:04:40.881-05:002012-02-28T10:04:40.881-05:00Excellent post Paul.
I have had misgivings about ...Excellent post Paul.<br /><br />I have had misgivings about rebasing ever since our team began losing commits. It's a way to easily get in trouble, especially if you resolve conflicts on the fly. I had outlined some of these problems in this post:<br />http://blog.codesherpas.com/on_the_path/2010/10/git-rebase-in-anger.html<br /><br />If I were to disagree with anything, I would say that amending a commit that has not been pushed is fine. It's the do-over for a commit that was a mistake (mostly if I ever forget to include some important details in a commit message).<br /><br />Git is currently my preferred version control, but the ability to change repository history worries me. That's why I believe the next great version control utility will be something like git, but without the dangers of rewriting the repository history.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-46858760929152197962011-03-21T06:58:34.274-04:002011-03-21T06:58:34.274-04:00Granted. I was thinking more of the questions lik...Granted. I was thinking more of the questions like, "what is intelligence?" and "what is mind?" but you are correct, "what is common sense?" is also a sticky problem.<br /><br />I also didn't quite say "all" AI researchers have punted, but that "most" do, which is not incompatible with your assertion. :)paulhttps://www.blogger.com/profile/14647609048389725132noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-88698574104421620252011-03-20T01:32:30.271-04:002011-03-20T01:32:30.271-04:00Not all AI researchers have punted on the big ques...Not all AI researchers have punted on the big questions. The project I have in mind is Cyc, which attempts to tackle the common sense problem.Alan Diperthttps://www.blogger.com/profile/15319506900525217811noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-20394662174014474172011-02-17T09:31:01.848-05:002011-02-17T09:31:01.848-05:00Thanks for sharing your thoughts. I appreciate yo...Thanks for sharing your thoughts. I appreciate you sharing Linus' opinion on the subject, but his opinion is not binding.<br /><br />I work daily on a project with 9 other developers where we have lots of topic branches and merges, and they don't "pollute" the repo, or if the do its an issue of personal taste. Preserving the history of particular lines of code is important.<br /><br />There are different opinions on the topic of one large commit vs. lots of small commits. Personally I find it easier to digest commits when the are complete ideas, instead of half-thoughts, so I tend to fall on the side of largeish feature commits (as you do).<br /><br />By the way, it is totally unnecessary to have a single commit per feature if you are doing it only to have an easy way to revert that work. You can do `git rebase -i -p -s subtree SHA` and it will allow you to remove a no fast-forward merge all at once, in other words, you don't have to remove every commit individually.<br /><br />This is one of the benefits of doing merges vs rebasing. If you rebase your work into mine and we've moved on to other changes *then* it is impossibly messy to revert your work later. However, if you do a no fast-forward merge, I can easily come back later and remove your whole branch from the history in one fell swoop, if you're into that sort of thing.paulhttps://www.blogger.com/profile/14647609048389725132noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-36073131697617581032011-02-16T12:27:49.341-05:002011-02-16T12:27:49.341-05:00This sounds to me as more of a Rant than anything....This sounds to me as more of a Rant than anything. Take it from Linus Torvalds himself. he told me to tell you that you are doing it wrong. http://lwn.net/Articles/328438/<br /><br />I think when people rant about rebasing being bad it's because they've never been in a situation of more than 2-3 developers where erroneous merge commits and endless feature branches pollute the repo. I for one (along with Linus) am for the single commit per feature. It's EXTREMELY EASY to revert a single commit. A feature doesn't do what is expected in production? Great yank it out (git revert) keep moving along. Try unwinding a merge. Things get ugly.<br /><br />My $0.02<br /><br />Snuggs<br /><br />Innovative-Studios.comRa'Shaunhttps://www.blogger.com/profile/04907793680556674870noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-44254002144654225792010-12-08T05:37:16.340-05:002010-12-08T05:37:16.340-05:00@chnicola It certainly seems uncontroversial to sa...@chnicola It certainly seems uncontroversial to say "don't rewrite public history", since even my critics agree with that. I did say this in the Epilogue.<br /><br />However, there are things which even when done in private can make things harder for you, and others once you make it public.<br /><br />For instance, rebasing a topic branch on a newer version of master. If there are lots of changes and conflicts, then it is certainly easier on yourself to just merge master in, instead of rebasing. That way you save yourself from the conflict flogging that git gives you for each commit that you are rebasing. Technically you could rebase because its not public, but the argument for merging the new master in is entirely practical and the argument for rebasing on the new master is entirely cosmetic.<br /><br />Second, the last form of lying (retroactive commits), if done without verifying that those commits compile and/or pass tests can cause problems with `git bisect` and conflict resolution when those commits are made public later.paulhttps://www.blogger.com/profile/14647609048389725132noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-84897419612856354442010-12-08T01:50:35.890-05:002010-12-08T01:50:35.890-05:00It is worth really stressing (which I missed in yo...It is worth really stressing (which I missed in your entire post) that lies only matter if you are sharing a repository. If you are working locally these are useful and sensible tools to use and work with.Chris Nicolahttps://www.blogger.com/profile/00427805306827828707noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-60652196702679229522010-12-07T22:04:40.038-05:002010-12-07T22:04:40.038-05:00>It does not undermine anything: you can do a p...>It does not undermine anything: you can do a partial commit (to the index), stash the rest of the changes while keeping the index.<br /><br />>Then run the test suite to make sure that your (staged) commit is OK. Commit and repeat.<br /><br />@sigi uhhhh...I think we agree. The behavior that I said undermined `git bisect` and the ability to verify conflict resolution by compiling and running tests is breaking things into commits *without* running the test suite for each commit.<br /><br />If you are running tests on (or at least trying to compile) each commit, then cherry-pick and bisect are much more useful, and you can trust your conflict resolution a little more than not.paulhttps://www.blogger.com/profile/14647609048389725132noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-79723715098681071642010-12-07T21:31:24.042-05:002010-12-07T21:31:24.042-05:00"I bemoaned choosing to commit individual fil..."I bemoaned choosing to commit individual files out of a bunch of changes because it undermines the ability to compile and test commits, which is useful (essential?)"<br /><br />It does not undermine anything: you can do a partial commit (to the index), stash the rest of the changes while keeping the index.<br /><br />Then run the test suite to make sure that your (staged) commit is OK. Commit and repeat.<br /><br />The same goes when splitting commits after the fact ("lying"). One can always make sure that the test suite completes after every new commit made.<br /><br />Of course this is impractical with a long running test suite, but then in this case so is committing frequently.Sigihttps://www.blogger.com/profile/13560728705152464043noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-29410217327943286152010-12-07T21:24:33.697-05:002010-12-07T21:24:33.697-05:00Some remarks on what eat-a-git said above:
Hunk b...Some remarks on what eat-a-git said above:<br /><br />Hunk based commits are supported by Git. I agree that they are useful for organizing your history. However, one must be disciplined about stashing before every commit ("git stash --keep-index") and running the test suite in order to make sure the partial commits are legit.<br /><br />Otherwise one does break "git bisect", as the article correctly points out.<br /><br />Fully agree on your second point.<br /><br />Very nice article, worth thinking about.Sigihttps://www.blogger.com/profile/13560728705152464043noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-51349903961645084902010-12-07T17:47:39.191-05:002010-12-07T17:47:39.191-05:00@Mahmoud IMO, what one should do instead of rebasi...@Mahmoud IMO, what one should do instead of rebasing is just merge into your topic branch. You resolve all the conflicts at once, instead of having git repeatedly flog you with conflicts for each commit. And git can still easily tell you where commits came from and where they went.<br /><br />@Jlouis I think this is kind what I was getting at with my talk about integration branches at the end.<br /><br />@Douglas I agree, I think I did mention stashes as a way to set aside some changes to go make changes elsewhere.<br /><br />@eat-a-git I don't think I ever said cherry-picking is a lie. Perhaps I implied it? Cherry-picking is useful, and having commits that compile and pass tests make cherry-picking much more pleasant.<br /><br />I did not bemoan squashing because of their mud patch nature. I bemoaned them because they create new commits which destroys cool features of git. I bemoaned choosing to commit individual files out of a bunch of changes because it undermines the ability to compile and test commits, which is useful (essential?) in `git bisect` and in resolving conflicts.<br /><br />And I guess I'm glad to know I have your seal-of-approval. Thanks, dude!paulhttps://www.blogger.com/profile/14647609048389725132noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-51394311474432030292010-12-07T16:32:02.756-05:002010-12-07T16:32:02.756-05:00Point 1:
Cherry-picking to produce commits is not...Point 1:<br /><br />Cherry-picking to produce commits is not lying. It is organization. Darcs lets you do this for each hunk it encounters and it is an incredibly useful feature which allows to make very concise patches rather than balls of mud.<br /><br />Previously you bemoaned balls of mud patches from squashing, but to have work uncommitted and then to choose which files you're committing at one time is not lying.<br /><br />Point 2:<br /><br />Really most of this lying could go away if there was better annotation and organization, allowing you to abstract what happened while still allowing users to dig down into the history.<br /><br />The article is fine otherwise.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-25766135149510194062010-12-07T14:45:49.765-05:002010-12-07T14:45:49.765-05:00Re: retroactive commits: you can use git stash to ...Re: retroactive commits: you can use git stash to hide away bar while you prepare to commit foo. Much safer than committing blindly.Douglashttps://www.blogger.com/profile/08041010789564868324noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-19921614190425895442010-12-07T13:24:30.862-05:002010-12-07T13:24:30.862-05:00The trick is to have rules on certain branches whe...The trick is to have rules on certain branches where the contract is you wont lie.<br /><br />On other branches, personal ones for instance, you can lie to yourself to a certain extent. Blindly rebasing your own branches to "keep them up to date" is bounds for trouble though.Anonymoushttps://www.blogger.com/profile/02990737394952724516noreply@blogger.com