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