# pushing changes to a remote branch 10 messages from 2007-07-10 to 2007-07-14. Participants: martin f krafft, Jeff King, Brian Gernhardt, Sean Kelley, Jan Hudec, Junio C Hamano. Thread: https://gitlist.dev/t/8964 ## martin f krafft, 2007-07-10 14:36 Subject: pushing changes to a remote branch Message-ID: <20070710143614.GA29681@piper.oerlikon.madduck.net> URL: https://gitlist.dev/e/20070710143614.GA29681%40piper.oerlikon.madduck.net ``` Hi list, I am using git-remote to clone a remote repository and track only a select number of branches: git remote add -f -t vim -t ssh origin git://git.server.org/path/to/repo.git git branch -r origin/ssh origin/vim git merge ... I now merge these into the local repo and decide that I need to make a change to origin/vim. So I figure that it's probably easiest if I just checkout the remote branch, make the change, commit it, push it, return to the master branch, git-remote update and merge, but: git checkout origin/vim Note: moving to "origin/vim" which isn't a local branch echo change > newfile; git add newfile git commit -m'make change' Created commit 64b8b2e: make change 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 newfile If I now checkout master and then return to origin/vim, the commit is gone. If I repeat all this and, instead of returning to master, I push the commit to origin, git suggests success (the push looks normal). However, I then cannot find the commit anymore. It's not available locally, nor in origin/vim, nor in the local master branch or in origin/master. This is curious and I'd love to find out what's going on. Much more, however, I am interested how I am supposed to push commits back to select remote branches. Using git push git://git.server.org/path/to/repo.git \ 7fbb0655:refs/heads/vim does push commit 7fbb0655 to the vim branch in the remote repository, but I should be able to do this using origin/vim, no? How? -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck spamtraps: madduck.bogus@madduck.net "the worst part of being old is remembering when you was young." -- alvin straight (the straight story) ``` ## Jeff King, 2007-07-10 17:34 Subject: Re: pushing changes to a remote branch Message-ID: <20070710173401.GB5032@sigill.intra.peff.net> URL: https://gitlist.dev/e/20070710173401.GB5032%40sigill.intra.peff.net In-Reply-To: <20070710143614.GA29681@piper.oerlikon.madduck.net> ``` On Tue, Jul 10, 2007 at 04:36:14PM +0200, martin f krafft wrote: > git checkout origin/vim > Note: moving to "origin/vim" which isn't a local branch > echo change > newfile; git add newfile > git commit -m'make change' > Created commit 64b8b2e: make change > 1 files changed, 1 insertions(+), 0 deletions(-) > create mode 100644 newfile > > If I now checkout master and then return to origin/vim, the commit > is gone. That's because 'origin/vim' is a tracking branch for the remote; it's where you store the information "here's what the remote 'origin' thinks is in the branch 'vim'." That's why you get the "note" warning above. If you want to make changes, you should make a local branch starting from that point: git-checkout -b vim origin/vim # hack hack hack git-commit -m changes > Much more, however, I am interested how I am supposed to push > commits back to select remote branches. Now when you issue a git-push, you will push _your_ 'vim' branch to the remote's 'vim' branch. Before, you didn't _have_ a vim branch, so nothing was pushed. So the key thing you are missing in all of this is that you shouldn't be doing _anything_ with branches in origin/* (which are, of course, actually refs/remotes/origin/*) except for read-only operations (like diffing against them, merging with them, etc). They are purely for tracking the remote's branches. -Peff ``` ## Brian Gernhardt, 2007-07-10 18:10 Subject: Re: pushing changes to a remote branch Message-ID: <844FC382-DFB3-4762-93C2-6512612136AC@silverinsanity.com> URL: https://gitlist.dev/e/844FC382-DFB3-4762-93C2-6512612136AC%40silverinsanity.com In-Reply-To: <20070710173401.GB5032@sigill.intra.peff.net> ``` On Jul 10, 2007, at 1:34 PM, Jeff King wrote: > On Tue, Jul 10, 2007 at 04:36:14PM +0200, martin f krafft wrote: > >> git checkout origin/vim >> Note: moving to "origin/vim" which isn't a local branch >> echo change > newfile; git add newfile >> git commit -m'make change' >> Created commit 64b8b2e: make change >> 1 files changed, 1 insertions(+), 0 deletions(-) >> create mode 100644 newfile >> >> If I now checkout master and then return to origin/vim, the commit >> is gone. > > That's because 'origin/vim' is a tracking branch for the remote; it's > where you store the information "here's what the remote 'origin' > thinks > is in the branch 'vim'." That's why you get the "note" warning above. > > If you want to make changes, you should make a local branch starting > from that point: > > git-checkout -b vim origin/vim > # hack hack hack > git-commit -m changes Indeed, in master, git outputs a hint to that when you checkout the remote branch. $ git checkout origin/master Note: moving to "origin/master" which isn't a local branch If you want to create a new branch from this checkout, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b HEAD is now at f4855d4... 1 Perhaps git-commit should also also output a warning? "Commit made on detached HEAD. Use "git branch " to save your commit"? That's bad wording, but the idea is there. ~~ Brian ``` ## Jeff King, 2007-07-10 22:04 Subject: Re: pushing changes to a remote branch Message-ID: <20070710220458.GA2295@coredump.intra.peff.net> URL: https://gitlist.dev/e/20070710220458.GA2295%40coredump.intra.peff.net In-Reply-To: <844FC382-DFB3-4762-93C2-6512612136AC@silverinsanity.com> ``` On Tue, Jul 10, 2007 at 02:10:01PM -0400, Brian Gernhardt wrote: > Perhaps git-commit should also also output a warning? "Commit made on > detached HEAD. Use "git branch " to save your commit"? > That's bad wording, but the idea is there. There was much discussion in this area, and the conclusion (and current behavior) is: 1. Notify about the state change to detached HEAD, since some commands will be subtly different. 2. Don't warn about commiting on detached HEAD, since there is nothing technically wrong with it. 3. When moving away from detached HEAD, print the previous HEAD position, so the user knows what might have been lost. See this message (and a bunch of surrounding messages): http://article.gmane.org/gmane.comp.version-control.git/38254 It would be nice if we could allow (3) only when commits weren't being lost, but that would require doing a reachability analysis from all refs, which is expensive. The reflog for HEAD makes those commits recoverable, as well. Personally, I think (2) (commits on detached HEAD) should simply be disallowed, since it is simple enough to 'git checkout -b newbranch' as an override (and I have not personally found a need for commits on detached HEAD, anyway), and it saves the exact newbie error that Martin ran into. But others obviously disagree. -Peff ``` ## Sean Kelley, 2007-07-11 03:44 Subject: Re: pushing changes to a remote branch Message-ID: URL: https://gitlist.dev/e/a2e879e50707102044l864b9dcre5b6fa5893ff4803%40mail.gmail.com In-Reply-To: <844FC382-DFB3-4762-93C2-6512612136AC@silverinsanity.com> ``` Hi, On 7/10/07, Brian Gernhardt wrote: > > On Jul 10, 2007, at 1:34 PM, Jeff King wrote: > > > On Tue, Jul 10, 2007 at 04:36:14PM +0200, martin f krafft wrote: > > > >> git checkout origin/vim > >> Note: moving to "origin/vim" which isn't a local branch > >> echo change > newfile; git add newfile > >> git commit -m'make change' > >> Created commit 64b8b2e: make change > >> 1 files changed, 1 insertions(+), 0 deletions(-) > >> create mode 100644 newfile > >> > >> If I now checkout master and then return to origin/vim, the commit > >> is gone. > > > > That's because 'origin/vim' is a tracking branch for the remote; it's > > where you store the information "here's what the remote 'origin' > > thinks > > is in the branch 'vim'." That's why you get the "note" warning above. > > > > If you want to make changes, you should make a local branch starting > > from that point: > > > > git-checkout -b vim origin/vim > > # hack hack hack > > git-commit -m changes > > Indeed, in master, git outputs a hint to that when you checkout the > remote branch. > > $ git checkout origin/master > Note: moving to "origin/master" which isn't a local branch > If you want to create a new branch from this checkout, you may do so > (now or later) by using -b with the checkout command again. Example: > git checkout -b > HEAD is now at f4855d4... 1 > > Perhaps git-commit should also also output a warning? "Commit made > on detached HEAD. Use "git branch " to save your > commit"? That's bad wording, but the idea is there. If you then do a push from that new_branch_name will it create a new branch on the remote? I am struggling with just being able to add a remote. Create a local branch that maps to the remote. Then committing and pushing changes to the remote - all without creating a new branch on the remote. Sean > > ~~ Brian > - > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ``` ## Jan Hudec, 2007-07-11 19:29 Subject: Re: pushing changes to a remote branch Message-ID: <20070711192959.GB3069@efreet.light.src> URL: https://gitlist.dev/e/20070711192959.GB3069%40efreet.light.src In-Reply-To: <20070710143614.GA29681@piper.oerlikon.madduck.net> ``` On Tue, Jul 10, 2007 at 16:36:14 +0200, martin f krafft wrote: > git checkout origin/vim > Note: moving to "origin/vim" which isn't a local branch There is more to that message, no? However, it only says "Head is now at ", which does not really indicate, that the HEAD has been "detached". This means that it now contains a commit-id rather than name of some branch. Git detaches head whenever you check out, without -b option, anything other than branch (without it's refs/heads prefix). If you than check out a branch, you can't see the commit on any branch anymore. However, you can still access it in reflog, ie. via expressions like HEAD@{1} or HEAD@{1 hour ago}. You should also be able to: git push origin HEAD:vim after the commit, and even (I didn't try it, but documentation seems to claim it should work): git push origin HEAD@{1}:vim if you already changed HEAD more. You can see this "metahistory" of HEAD via: git reflog which is shorthand for git reflog show HEAD -- Jan 'Bulb' Hudec ``` ## Jan Hudec, 2007-07-11 19:31 Subject: Re: pushing changes to a remote branch Message-ID: <20070711193152.GC3069@efreet.light.src> URL: https://gitlist.dev/e/20070711193152.GC3069%40efreet.light.src In-Reply-To: <844FC382-DFB3-4762-93C2-6512612136AC@silverinsanity.com> ``` On Tue, Jul 10, 2007 at 14:10:01 -0400, Brian Gernhardt wrote: > Indeed, in master, git outputs a hint to that when you checkout the remote > branch. > > $ git checkout origin/master > Note: moving to "origin/master" which isn't a local branch > If you want to create a new branch from this checkout, you may do so > (now or later) by using -b with the checkout command again. Example: > git checkout -b > HEAD is now at f4855d4... 1 The problem of this warning is, that it does not actually say anything about detached and that potential commit won't update the ref being checked out. > Perhaps git-commit should also also output a warning? "Commit made on > detached HEAD. Use "git branch " to save your commit"? > That's bad wording, but the idea is there. -- Jan 'Bulb' Hudec ``` ## Jan Hudec, 2007-07-11 19:34 Subject: Re: pushing changes to a remote branch Message-ID: <20070711193444.GD3069@efreet.light.src> URL: https://gitlist.dev/e/20070711193444.GD3069%40efreet.light.src In-Reply-To: ``` On Tue, Jul 10, 2007 at 22:44:58 -0500, Sean Kelley wrote: > If you then do a push from that new_branch_name will it create a new > branch on the remote? I am struggling with just being able to add a > remote. Create a local branch that maps to the remote. Then > committing and pushing changes to the remote - all without creating a > new branch on the remote. git push takes a refspec, which is local-branch:remote-branch. So you can push from local branch of any name to remote branch of any other name. You can also define the relationships in the config, but you'll have to look up what exactly you should specify in the manuals (of git-push and git-config). -- Jan 'Bulb' Hudec ``` ## Junio C Hamano, 2007-07-11 21:26 Subject: Re: pushing changes to a remote branch Message-ID: <7v1wfe4op5.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v1wfe4op5.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20070711193152.GC3069@efreet.light.src> ``` Jan Hudec writes: >> $ git checkout origin/master >> Note: moving to "origin/master" which isn't a local branch >> If you want to create a new branch from this checkout, you may do so >> (now or later) by using -b with the checkout command again. Example: >> git checkout -b >> HEAD is now at f4855d4... 1 > > The problem of this warning is, that it does not actually say anything about > detached and that potential commit won't update the ref being checked out. "Being detached" is a rather geekish synonym to "which isn't a local branch", isn't it? ``` ## Jan Hudec, 2007-07-14 08:38 Subject: Re: pushing changes to a remote branch Message-ID: <20070714083843.GA3678@efreet.light.src> URL: https://gitlist.dev/e/20070714083843.GA3678%40efreet.light.src In-Reply-To: <7v1wfe4op5.fsf@assigned-by-dhcp.cox.net> ``` On Wed, Jul 11, 2007 at 14:26:14 -0700, Junio C Hamano wrote: > Jan Hudec writes: > > >> $ git checkout origin/master > >> Note: moving to "origin/master" which isn't a local branch > >> If you want to create a new branch from this checkout, you may do so > >> (now or later) by using -b with the checkout command again. Example: > >> git checkout -b > >> HEAD is now at f4855d4... 1 > > > > The problem of this warning is, that it does not actually say anything about > > detached and that potential commit won't update the ref being checked out. > > "Being detached" is a rather geekish synonym to "which isn't a > local branch", isn't it? In a sense, no, it is not. "Being detached" is a synonym of "HEAD is not symbolic ref". The current warning does not really convey the information, that the ref being checked out will not be updated. Maybe it could be extended along the lines of following patch. Hm, it will say the same when checking out with commit name, which does not make sense much, though. -->8-- Extend the detached head warning in checkout. The warning when detaching head now explicitely states that ref being checked out will not be updated. --- git-checkout.sh | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/git-checkout.sh b/git-checkout.sh index 17f4392..502b2be 100755 --- a/git-checkout.sh +++ b/git-checkout.sh @@ -178,7 +178,8 @@ then detached="$new" if test -n "$oldbranch" && test -z "$quiet" then - detach_warn="Note: moving to \"$new_name\" which isn't a local branch + detach_warn="Note: moving to \"$new_name\" which isn't a local branch, so it will +_not_ be updated by local commits. If you want to create a new branch from this checkout, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b " -- Jan 'Bulb' Hudec ```