Andy's suggested workflow (pull, commit, push) works, and nicely avoids
spurious merges. But it has the drawback that you dont get to commit until
you're ready to push, which means it gives up one of my favorite features of
git.
Consider this instead:
Hack, commit
Hack, commit
git fetch
git rebase
(Then either "git push", or go back to the top and hack more)
"Fetch" goes and gets all new changes from origin (git.linuxcnc.org) *without*
making any changes to your local branches. Specifically, no automatic merges.
"Rebase" moves your local commits from the old tip of the upstream branch to
the new tip you just fetched. Think of it as detatching your local branch at
the point where it diverged from the upstream, and reattatching it to the new
tip of ipstream. This might have merge conflicts just like a merge, and rebase
lets you fix each conflict as it finds them, in the context of the commit that
has the conflict.
Another git tip is to use gitk in addition to "git log". In John's example, try
"gitk 12323..13434". Gitk shows the same info as git log, but with a nice
graphical ui.
Gitk works especially well when looking at related branches. For example,
after the fetch and before the rebase, you can run "gitk v2.5_branch
origin/v2.5_branch", which means "show me the local and origin 2.5 branches and
all their history", which will make it really clear where your local branch
diverged from origin's, and what will happen when you rebase.
Git is cool :-)
----- Reply message -----
From: "andy pugh" <[email protected]>
Date: Wed, Nov 9, 2011 05:09
Subject: [Emc-developers] [Emc-commit] v2.5_branch: Merge branch 'master' into
v2.5_branch
To: "EMC developers" <[email protected]>
On 9 November 2011 11:59, John Thornton <[email protected]> wrote:
> How do you read the results of git push --dry-run? I don't recall
> exactly when I tried it yesterday it was very terse, something like
> 12323....13434 push from my repository or something.
if you then git log 2323....13434 you see what is going to happen, and
to be absolutely sure you can do
git log -p 2323....13434 which sends an equivalent patch file to stdio.
Any mention of a merge in the git log is probably a bad sign,
indicating that you have made the error that I keep making.
(making a commit, then doing a pull, then pushing, rather than
pulling, commiting, pushing)
--
atp
The idea that there is no such thing as objective truth is, quite simply, wrong.
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
