On Mon, Jun 22, 2009 at 5:21 PM, Daniel Spiewak <djspie...@gmail.com> wrote:
> I did strongly consider that. Unfortunately, if I had squashed all of the > commits, that would have meant losing the granularity of the history. Or > at > least, preventing it from ever existing under ASF control. One of the huge > advantages of Git (at least in my eyes) is the ability to "go offline" and > work on something experimental and breaking before coming back and pushing > the changes into the upstream repository *without* turning it all into "one > big commit". IMHO, this is also a big part of why Git branch merging is so > awesome. I often squash distinct Git commits into one before merging with master, for a very simple reason: reading unsquashed commits is as helpful as standing behind my shoulder watching me type/erase/fix/retype the code. I want my commit messages to show what the new feature is, not the details of how it came to be. Assaf > > > I know it's a *lot* of commits (50, to be exact), but I think the added > control and more informative history is worth it. > > Daniel > > On Mon, Jun 22, 2009 at 7:07 PM, Assaf Arkin <ar...@intalio.com> wrote: > > > On Mon, Jun 22, 2009 at 5:00 PM, Daniel Spiewak <djspie...@gmail.com> > > wrote: > > > > > Alrighty, in we go! Those of you on the commits list, prepare for a > > minor > > > flood... > > > > > > you can always git rebase -i apache/master and squash like there's no > > tomorrow > > > > > > > > > > > > Daniel > > > > > > On Sun, Jun 21, 2009 at 10:48 PM, Daniel Spiewak <djspie...@gmail.com > > > >wrote: > > > > > > > Any other thoughts on this? Without a dissenting opinion, I'm just > > going > > > > to filibuster my changes in regardless of potential controversy. :-) > > > > > > > > Daniel > > > > > > > > > > > > On Sat, Jun 20, 2009 at 3:26 PM, Alex Boisvert <boisv...@intalio.com > > > >wrote: > > > > > > > >> +1 on getting it into trunk... it's a good way to get people using > > it. > > > >> > > > >> My preference is still a local_task per project. > > > >> > > > >> Re: testing, have you considered capturing stdin/stdout, feeding > > > commands > > > >> to > > > >> the interpreters and checking the results? > > > >> > > > >> alex > > > >> > > > >> > > > >> On Sat, Jun 20, 2009 at 8:41 AM, Daniel Spiewak < > djspie...@gmail.com> > > > >> wrote: > > > >> > > > >> > I would like to move that my long-standing branch > > `interactive-shell` > > > >> and > > > >> > its support branch `jruby-system` (both available from git:// > > > >> > github.com/djspiewak/buildr.git) be rebased onto trunk/ and > merged > > > into > > > >> > the > > > >> > mainline Buildr SVN. I have been dogfooding this feature for > about > > > six > > > >> > months now and have found it invaluable on many occasions. I > > decided > > > >> > against just "going ahead" with the merge without discussion since > > > there > > > >> > was > > > >> > some controversy the last time we talked about this particular > > > feature. > > > >> > Specifically, Assaf was of the opinion that the `shell` task > should > > > open > > > >> a > > > >> > shell which is global to the entire project structure, whereas I > > > wanted > > > >> to > > > >> > make `shell` a local_task (as it is implemented in my branch). > > > >> > > > > >> > There is also a rather ugly hack that I had to add to get around a > > > >> > restriction in JRuby. Specifically, I overwrote Rake's > FileUtils.sh > > > >> > method. This doesn't seem to have caused any ill effects, even > > though > > > >> I'm > > > >> > technically stubbing part of the API (exitstatus and pid). The > only > > > >> > problem > > > >> > I'm having here is it seems to have broken shell launch (but not > > > >> anything > > > >> > else) under MRI. Considering the fact that my hack only applies > > when > > > >> > running under JRuby, I'm not sure how this could be. If someone > > more > > > >> > knowledgable in the dark arts of Rake could take a look, I would > > > greatly > > > >> > appreciate it (just run `buildr shell` in a Scala project under > > MRI). > > > >> > > > > >> > The main glaring omission from this contribution is specs. I > can't > > > for > > > >> the > > > >> > life of me figure out how to spec something like this, so I've > > settled > > > >> for > > > >> > just manually testing the heck out of it. A poor substitute, but > > it's > > > >> all > > > >> > I've got. If someone has any better ideas, I'm definitely open. > > > >> > > > > >> > Anyway, there has been some interest from the community in this > > > >> particular > > > >> > feature, and given its usefulness in my own development, I think > > that > > > >> it's > > > >> > worthy of inclusion in trunk/. Any thoughts? > > > >> > > > > >> > Daniel > > > >> > > > > >> > > > > > > > > > > > > > >
