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
