On Fri, Mar 6, 2009 at 5:11 PM, John Dlugosz <JDlugosz@xxxxxxxxxxxxxxxx> wrote: > ===Re:=== >> There was patch series adding support --ff=only, but I think it didn't >> made into git... Hmmm... > > I do not think it has much to do with the main point of what John wants > to > do which is to muck with local branch without checking it out, which is > only possible when it happens to fast forward to the new tip of the > corresponding branch obtained from the the remote. > ===end=== > > It occurs to me that maybe my concept is off, if it is being so > difficult. > > Here is what I'm "cooking": > > ======excerpt====== > > To keep apprised of other people's work, including updates to the main > dev branch, start the day with: > > git fetch > > This will update your "remote tracking branches", letting you see what > everyone else is working on, and letting you see the central > repository's dev (as remotes/origin/dev) compared to your own local dev, > so you can see what has been added. > > This does not change your local dev, or any other branches you are > using. As for your own topic branches, you are the only one who changes > them. This is a perfectly safe command and can be performed any time to > update your view of what's happening throughout the team. > You will, in particular, see your local dev where you last left it, and > the current remotes/origin/dev pointing ahead of it. E.g. > > A <== dev > \ > B--C--D <== remotes/origin/dev > > In this example, you see plain "dev" still pointing to A, and > "remotes/origin/dev" pointing to D. So, you can tell that B, C, D were > added. Review the nodes B, C, and D, by reading the comments and seeing > which files were affected, and look deeper if it seems to affect what > you are doing. Finally, issue the command > > ??? > > And this will update your local dev to match the origin. > > ====== > > Basically, instead of mysterious "can't push" messages, the idea is that > people can feel good about 'fetch' as refreshing their view of the > central repo, so gitk can show them how the central dev (and other > branches) differs from their own. If the local "dev" is a topic branch, you'd want to either merge or rebase with the origin's dev branch. Rebasing is probably best if you've not published the branch yet (unless you'd prefer proper merge history on it). If the local "dev" is meant to just track the remote, you really ought to avoid doing anything very involved in it (unless you're planning on merging something into it and pushing the result, that is!). If there's no local changes, then you can just pull with impunity, and let it fast-forward - or use git merge or git rebase if you've already fetched and don't want to spend the few seconds it takes to ask the server if there's anything new :) Finally, if you really, truly, definitely want to blow away the current branch and replace it with another one, you can use git reset --hard. This will throw away (irretrievably) local uncommitted changes, and force the current branch to point to the specified one. Remember, you can undo most things using the reflog if you mess up, including unwanted merges, git reset --hard (committed changes only) etc. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
