On Tue, Jun 23, 2009 at 1:18 PM, Daniel Spiewak <djspie...@gmail.com> wrote:
> Well, I did some research, and it seems that the bulk of the Git community
> agrees with you. Thinking about it more, this really wouldn't be an issue
> if we were using Git for the upstream source. The problem really originates
> in the fact that SVN doesn't track merges natively.
>
> Next question: rebase -i or merge --squash? The Gnome developer's guide to
> git-svn says to use merge, but you do get a lot more control with rebase.
> Question: did Git auto-generate that gigantic commit message, or did you
> have to do it yourself?
I used rebase -i because I wanted to edit the commit message for
readability. Specifically ordering items together so they make more sense
and deleting progress commits like "groovy specs now passing". I didn't add
anything new beyond what was already in the commit log.
Assaf
>
>
> Daniel
>
>
> On Jun 23, 2009, at 3:08 PM, Assaf Arkin <ar...@intalio.com> wrote:
>
> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
