[plt-dev] Re: [plt] Push #20178: master branch updated
Thank you.
Robby
On Mon, May 10, 2010 at 9:08 PM, Eli Barzilay <eli at barzilay.org> wrote:
> On May 10, Robby Findler wrote:
>> I've tried to read your file, but it got pretty complicated and full
>> of what seemed to be not so useful details, so I gave up (twice
>> now).
>
> Well, FWIW, I tried my best to make it useful, but probably the need
> to have accurate descriptions made it more accurate. Also, the reason
> it took so much time is that I actually had to learn about all of the
> little details, because I really wanted it to be practical and kind-of
> complete. (You can see the results of that on the git list...)
>
>
>> I do plan to read the whole thing, but can you perhaps provide some
>> more of a hint that's tailored to this situation?
>
> I tried to write an executive summary, but it got long enough to
> justify an executive^2 summary:
>
> * Setup: git config --global alias.up "pull --ff-only --stat --all"
> * Update before pushing with: git up
> * When it tells you that it failed, use: git rebase origin
> -- or if you have more substantial work: git merge origin
> * Push out as usual: git push
>
> and if you always push out single commits, you can make it easier
> with:
>
> * Setup: git config --global alias.up "pull --rebase --stat --all"
> * Update before pushing with: git up
> * Push out the rebased result with: git push
>
> And here is the executive^1 summary:
>
> * Run this:
>
> git config --global alias.up "pull --ff-only --stat --all"
>
> this gives you a new "git up" command that is the same as running
> "git pull ..."
>
> - the `--stat' flag will give you a quick by-file summary of the
> changes that you pulled
> - the `--all' flag will make it pull all branches (which is more
> relevant if you have your own repository with branches)
> - the `--ff-only' flag tells it to abort if it can't trivially
> advance your history to the point where the remote repo is at.
>
> * The last one is the important point here: if you have local commits,
> it will not just blindly do a merge (which is the default, and the
> reason for those merges) -- instead, it will stop with:
>
> fatal: Not possible to fast-forward, aborting.
>
> At this point you could inspect the history of your commits and the
> ones you pulled -- I describe in the text a few ways to do this
> (look for that error message). But usually you'll know where things
> stand -- my guess is that most people are still in the svn-mindset
> of pushing commits out quickly, so in most case you'll know that you
> have a single commit. Also, since we're usually working on
> different things, you'll know that a merge will be trivial.
>
> * As a result, in most cases you'll just run "git rebase origin" now,
> to rebase your commit, then ship it out.
>
> * And finally, since this is the common use pattern at this point, you
> could just replace the `--ff-only' flag in the alias with
> `--rebase', and this will make your `git up' command rebase your
> work.
>
> --
> ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
> http://barzilay.org/ Maze is Life!
>