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 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 > > >> > > > >> > > > > > > > > >
