Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued

Theodore Tso wrote:

Yes. The few topic-branches that require input from several people are distributed this way for peer review and trouble-shooting. It's nifty if they're automatically downloaded, but not so much of an issue that it matters.

No, they're just surprised that what they thought would be automatic isn't, and the curse about it when they put themselves in trouble by forgetting about it. I've done it myself, and I've been using git since may 2005.

It depends. For small bugfixes we sometimes commit directly on the checked out branch. For larger issues we usually create a topic branch and hack away, creating nicely ordered patch-series and such, but those topic branches must be created from the tip of the upstream tracking branch. What Dscho suggested would definitely work, but that would mean I'd have to tell my co-workers to use 'git branch -D', which I'm quite reluctant to do. One solution to that particular problem is ofcourse to hack the delete-command of git-branch to honor remote tracking branches when calculating dependencies, so the local branches can safely be removed when they're done with them.

However, there's still this issue: $ git checkout -b foo origin/pu Branch foo set up to track remote branch refs/remotes/origin/pu. Switched to a new branch "foo"

git checkout will say that every time a branch is created from a tracking branch, unless one tells it --no-track (which people don't learn about unless they're really into git), so it's quite natural that people think git will actually make sure, within reasonable limits, that 'foo' is kept in sync with refs/remotes/origin/pu. That's not the case, however.

So we could either change the message to be: "Branch foo set up to track remote branch refs/remotes/origin/pu, provided you only ever issue git-pull while having branch foo checked out."

Or we could make 'git checkout -b' default to --no-track, perhaps giving annoying messages everytime someone "git-checkout -b"'s a remote tracking branch. Or we could make git-pull keep git checkout's promises.

I'm opting for the latter, since that's the one that makes a piece of machinery do some work for me. I'd happily call the command "git-update-all-local-branches-tracking-remote-tracking-branches" and only ever make it actually do any work if I pass it the option "--I-bask-in-the-glory-of-local-vs-remote-confusion", but I need some sort of solution that a) Doesn't normally present error messages. b) Doesn't involve routinely using "git branch -D" c) Doesn't require more than one or two commands per repo to get the locally checked out copies of the remote tracking branches (the ones git has "set up to track remote branch remotes/x/branch") up to date with their remote counterpart.

Or invent the sensatronic transmission system and get the best of both worlds. Engineering solutions so they fit humans? Good gods, that's a novel idea! ;-)

It's not so much CVS-damaged developers as it's conflicting messages. I'm quite confused about it myself at times, but for me there's nobody to harrass since I was the one vetoing in git as the scm to use for all our corporate needs.