[rspec-devel] rake git:update
dchelimsky at gmail.com
Wed Apr 16 08:30:47 EDT 2008
I don't know how it happened, but somehow all the changes I've
committed to the rspec repo since 4/10 are GONE.
Take a look at http://github.com/dchelimsky/rspec-dev/commit/c59041b3b4b1a1bea8c24f8ca79b88bd9c2043cf.
This commit was on 4/13 with the message "got uber-pre-commit
working." You can see that the rspec repo got updated to commit
Now look at http://github.com/dchelimsky/rspec/commit/f3aeaf1a5f7167148d32adf3001e0fc9db37c138.
WHAT THE FUCK??????????
This really, really, really has me questioning everything about git
and github. Please help me understand why we shouldn't bag the whole
thing right this minute.
On Wed, Apr 16, 2008 at 4:35 AM, Pat Maddox <pergesu at gmail.com> wrote:
> I don't know if any of you guys are using this right now...I made a
> bunch of changes to it tonight, based on some stuff I discovered about
> git, submodules, and the workflow that we (or at least I) use.
> Here's what I think is a pretty natural way to develop...
> make changes to the plugins, commit
> go to superproject, commit submodule changes
> Now to get upstream changes, you can do a couple things. You can't
> just rebase the parent repo and "git submodule update" because that
> will blow away the changes you made. You either have to work with the
> submodules in separate repos and merge them in, or you'd have to
> rebase the submodules individually. I choose the latter because it's
> more natural for me to do this all in the same project. Once you've
> rebased the submodules, you have to commit the submodule refs to the
> I didn't really know all of this when I first wrote the git:update
> task. I thought it was enough to just update the parent and then the
> submodules. That works fine unless you've got changes that need
> rebasing, and then it gets all messed up.
> After playing around with this a bunch I think I came up with a decent
> way to handle that workflow... but I'd really appreciate it if people
> could use it and let me know if there are any problems. Most
> importantly, I'm wondering if this single update command is a viable
> strategy, or if I'm barking up the wrong tree and should look into a
> more traditional "lots of repositories with lots of merging" strategy,
> incurring that overhead.
> Time for bed.
> rspec-devel mailing list
> rspec-devel at rubyforge.org
More information about the rspec-devel