Thank you. Robby
On Mon, May 10, 2010 at 9:08 PM, Eli Barzilay <e...@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! > _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
