On Mon, 2007-09-10 at 12:44 -0700, Junio C Hamano wrote: Hi, Junio, Thanks for the patch review! > I briefly looked at the patch text and they look Ok-ish, but one > message per patch is the standard procedure around here. For a > set of good example patches, see recent "strbuf" series from > Pierre Habouzit. It is almost perfect except for the two-space > indent on the first line of each paragraph he adds. Ah, cool --- I'll see how that patch series was done. > Thanks for noticing the omission of these in the OPTIONS list. > The body text of the DESCRIPTION part has the correct version, > so does the OPTIONS list in git-checkout (the crucial difference > is that branching off of another local branch does not make > much sense making it tracked). You are right; I didn't really notice that in the git-checkout docs. I'll submit another patch so that the git-branch docs have mostly the same text for that part of OPTIONS. > I am not so sure it "tracking" should be considered the norm. > While I would agree up to "This branch is not set up to track > any other branches." part, I would probably insert "please name > which branch you want to merge on the command line. If you want > to almost always want to merge with the same branch, then" > before suggesting to set up tracking. Hmmm, I guess it depends on people's particular workflows, but I do believe auto-tracking should be the default for remote branches. Here's my scenario: you clone a remote repository which has various interesting branches. You want to base your work off one of those branches, not the remote's master. So you do git checkout -b mybranch origin/theirbranch You want to "git pull" periodically to get the upstream changes easily, but then you'll be surprised when a default "git pull" doesn't actually do anything :) What's an effective use of "git pull <url>", say, with different URLs every time? If you were a maintainer getting changes from various contributors, I guess you'd create branches for each one, then pull individually into each of those branches, and merge them into your master branch one by one. Or maybe not --- I'm not very sure what the right workflow is here. > Please do not do this; you are fixing up your own mess in a > patch that has not been applied. Instead, fix the original > patch so that it does not introduce trailing whitespaces in the > first place. Ah, sure - I just concatenated all that "git format-patch" happened to spit :) Actually, what's the preferred way to generate a patch for submission once you've been working on something (making mistakes, committing over them, etc.)? Sorry for the n00b questions; I really like what Git has to offer, but I'm just making up my workflow as I go :) Federico - 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
