[LRUG] git question

[Chris Mear]

Sounds like what you've missed is git-rebase. This command replays the  
commits from a given branch back on top of the latest head of  
(usually) your master branch.

For instance, say you make a branch off the current master to work on  
your hyperactionpack patch, and do some work on it:

----1----2 master
           \---h1---h2---h3 hyperactionpack

in the meantime, master has moved on a couple of commits:

----1----2----3----4 master
          \---h1---h2---h3 hyperactionpack

if you do

git checkout hyperactionpack
git rebase master

you'll end up with this:

----1----2----3----4-------h1---h2---h3
                    master            hyperactionpack

Then you can create a patch based on the diff master..hyperactionpack  
and it will apply cleanly.

While you're doing the rebase, if it tries to replay a commit that  
doesn't apply cleanly to the latest master, you'll get a chance to fix  
it, just as if you were doing a regular merge.

As an aside, the whole 'pull request' thing is a GitHub-specific  
thing; the Rails team in particular has said that they want patches,  
not pull requests via GitHub, so this approach is probably the best way.

Chris



On 20 Aug 2009, at 11:45, Taryn East wrote:

> I'm having a newbie moment (I'm an svn girl and have only really  
> just started using git) - so I was hoping for a bit of help from the  
> git-gurus out there.
>
> So, what I'm trying to do is to create patches for rails core.
>
> Given I'll be doing a lot of related changes I figured I'd fork  
> rails for myself and make my changes on my fork - then bundle them  
> into patches and resubmit to core.
> The benefit of having my own fork is that it's "up there" and  
> viewable while in progress - and I can get to in anywhere... as  
> opposed to a local branch of rails/rails - which is only available  
> on my own machine.
>
> So I tried that, did some changes, made some commits... then made  
> some patches based on those commits and submitted them... only to  
> find that they simply don't work.
>
> I kept getting "patch does not apply" errors when I tired to run the  
> patch onto the real rails code.
> Now,  during the time I was making my changes, rails had moved on  
> (as it does). I had merged back into my own fork... but it seems  
> that my patches didn't accept that and kept trying to find files  
> (and LOC inside those files) to patch that simply weren't there  
> anymore...
>
> Eventually I gave up and just made a local branch of rails/rails and  
> hand-applied my diffs, creating a patch for each one... but I still  
> think that surely there's a way to do it the "right" way.
>
>
>
> From reading around, I think the way you're "supposed" to do the  
> fork-thing is to make a fork, then branch your fork and make all  
> your individual commits - then bundle these up and commit to the  
> master branch of your fork... then do a pull-request on your fork...  
> which seems like an awful lot of work just to be able to bundle up a  
> patch.
>
> and this "Way Things Should Be Done" isn't very clear unless you  
> read half a dozen tutorials on exactly how you're supposed to use  
> git... or happen to have a git-mentor on hand....and from my svn  
> perspective kind of seems a bit bizarre that you can't work on (and  
> then make working patches from) the git-equivalent of trunk. :P
>
>
> Have I missed something obvious?
>
> Cheers,
> Taryn
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org