[rspec-devel] rake git:update
bryansray at gmail.com
Wed Apr 16 10:08:20 EDT 2008
On Apr 16, 2008, at 7:30 AM, David Chelimsky wrote:
> 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
I'm no git expert by any means, but I don't see that it was created
under that ID?
> Now look at http://github.com/dchelimsky/rspec/commit/f3aeaf1a5f7167148d32adf3001e0fc9db37c138
> WHAT THE FUCK??????????
Perhaps someone's repo has this commit from an earlier pull down?
Not to doubt you David, but are you sure that commit was made to the
rspec repo? I'm not entirely sure I'd believe that a commit just
"disappeared." Don't take that the wrong way, buddy.
> 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
>> 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
>> 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
>> 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"
>> incurring that overhead.
>> Time for bed.
>> rspec-devel mailing list
>> rspec-devel at rubyforge.org
> rspec-devel mailing list
> rspec-devel at rubyforge.org
More information about the rspec-devel