On Apr 2, 2013, at 10:23 AM, Jeff King <peff@xxxxxxxx> wrote: > On Tue, Apr 02, 2013 at 10:07:01AM -0700, Garrett Cooper wrote: > >> It looks like git branch --set-upstream-to doesn't function with 1.8.1.3 until I run --set-upstream. Is this a known bug? > > No, but I do not think that is exactly what is going on. > >> root@fuji-current:/usr/src # git branch --set-upstream-to origin/pjdfstest-onefs pjdfstest-onefs >> fatal: Not a valid object name: 'origin/pjdfstest-onefs'. > > This is complaining that origin/pjdfstest-onefs does not actually exist > Does it? If the pjdfstest-onefs branch exists on the remote, do you need > to do a "git fetch" to make sure we have a local > refs/remotes/origin/pjdfstest-onefs tracking branch locally? > >> root@fuji-current:/usr/src # git branch --set-upstream origin/pjdfstest-onefs pjdfstest-onefs >> The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to >> Branch origin/pjdfstest-onefs set up to track local branch pjdfstest-onefs. > > This did _not_ create the remote-tracking branch refs/remotes/origin/pjdfstest-onefs. > It created a new local branch called "origin/pjdfstest-onefs" (i.e., > refs/heads/origin/pjdfstest-onefs), whose upstream is another local > branch "pjdfstest-onefs". That "backwards" order to the arguments is why > --set-upstream is deprecated; many people have made the same mistake. > >> root@fuji-current:/usr/src # git branch --set-upstream-to origin/pjdfstest-onefs pjdfstest-onefs >> Branch pjdfstest-onefs set up to track local branch origin/pjdfstest-onefs. > > Note how it says "local branch" here; you are not tracking anything at > the origin. You are tracking a local branch that happens to have > "origin/" in the name. I push the branch to origin/ and then things tend to work, but since I obviously had been doing things wrong what's the correct order of operations for creating a branch and setting the upstream appropriately? Thanks! -Garrett PS I love git as a tool, but I really wish the workflows were simpler or more straightforward, and error messages were clearer. It seems like this would help prevent usage errors like this..-- 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