On Tue, Jun 23, 2009 at 11:50 AM, Assaf Arkin <ar...@intalio.com> wrote:
> On Mon, Jun 22, 2009 at 5:57 PM, Daniel Spiewak <djspie...@gmail.com>wrote:
>
>>
>>
>> With that said, I can see the advantages to your approach as well. What
>> we
>> really need is an SCM that lets us label large blocks of commits. Git is
>> great for pointing to branch tips, but sometimes you want to just afix a
>> name to a slice out of that branch, with a well-defined start and end
>> point. Sort of like a transaction split in a money management program.
>> That would be the best of both worlds, I think.
>
>
> Testing this now in practice. I merged a bunch of changes into master,
> squashed them all and
> removed pointless commit messages and checked to SVN, and merged/rebase the
> branch accordingly (i.e. not squashed just brought up to spec).
>
> So now master just shows what changed, but branch history still shows how
> we got there (warts and all).
>
$ git co master
$ git blame lib/buildr/core/project.rb -L 225,225
3caa2864 (Assaf Arkin 2009-06-23 18:39:20 +0000 225)
project.enhance { project.instance_exec project, &block } if block
$ git log 3caa2864
commit 3caa28648a1a7b10754d9b161fc998560b85affb
Author: Assaf Arkin <as...@apache.org>
Date: Tue Jun 23 18:39:20 2009 +0000
Ruby 1.9.1 compatibility:
- erb_transform works well with binding, not proc
- foo = *args fixed to foo = args.last
....
$ git co ruby1.9
commit 3caa28648a1a7b10754d9b161fc998560b85affb
Author: Assaf Arkin <as...@apache.org>
Date: Tue Jun 23 18:39:20 2009 +0000
Ruby 1.9.1 compatibility:
- erb_transform works well with binding, not proc
- foo = *args fixed to foo = args.last
...
$ git blame lib/buildr/core/project.rb -L 225,225
fe684542 (Assaf Arkin 2009-04-07 13:38:03 -0700 225)
project.enhance { project.instance_exec project, &block } if block
$ git log fe684542
Author: Assaf Arkin <as...@apache.org>
Date: Tue Apr 7 13:38:03 2009 -0700
What we need is instance_exec, new in 1.9 and back-ported by RSpec 1.2.
When we ask master where the change happened it shows the big merge, but the
working branch shows the actual individual commit that introduced the change
(even though it has both commits in its history).
Assaf
>
> To review these changes, which would you rather use:
>
>
> http://github.com/assaf/buildr/commit/3caa28648a1a7b10754d9b161fc998560b85affb
>
> http://github.com/assaf/buildr/commits/ruby1.9?&page=3
>
> Assaf
>
>
>>
>> Anyway, you're the boss, so if you want to make the general policy one of
>> commit squashing, I'm willing to go that way. However, I remain quite in
>> favor of granularity wherever possible.
>>
>> Daniel
>>
>> On Mon, Jun 22, 2009 at 7:31 PM, Assaf Arkin <ar...@intalio.com> wrote:
>>
>> > 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
>> > > > > >> >
>> > > > > >>
>> > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
