pushing changes to a remote branch

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?

On Tue, Jul 10, 2007 at 04:36:14PM +0200, martin f krafft wrote:

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

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

On Jul 10, 2007, at 1:34 PM, Jeff King 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 <new_branch_name>
   HEAD is now at f4855d4... 1

Perhaps git-commit should also also output a warning? "Commit made on detached HEAD. Use "git branch <new_branch_name>" to save your commit"? That's bad wording, but the idea is there.

~~ Brian

On Tue, Jul 10, 2007 at 02:10:01PM -0400, Brian Gernhardt wrote:

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

Hi,

On 7/10/07, Brian Gernhardt <benji@silverinsanity.com> 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.

Sean

On Tue, Jul 10, 2007 at 22:44:58 -0500, Sean Kelley wrote:

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).

On Tue, Jul 10, 2007 at 14:10:01 -0400, Brian Gernhardt wrote:

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.

Jan Hudec <bulb@ucw.cz> writes:

"Being detached" is a rather geekish synonym to "which isn't a local branch", isn't it?

On Wed, Jul 11, 2007 at 14:26:14 -0700, Junio C Hamano wrote:

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(-)

On Tue, Jul 10, 2007 at 16:36:14 +0200, martin f krafft wrote:

There is more to that message, no? However, it only says "Head is now at <commit-id>", 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