pushing changes to a remote branch

pushing changes to a remote branch

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 1898 bytes --]

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)

[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: pushing changes to a remote branch

[Jeff King]

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

Re: pushing changes to a remote branch

[Brian Gernhardt]

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

Re: pushing changes to a remote branch

[Jeff King]

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 <new_branch_name>" 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

Re: pushing changes to a remote branch

[Sean Kelley]

Hi,

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


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
>

Re: pushing changes to a remote branch

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 725 bytes --]

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 <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: pushing changes to a remote branch

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 880 bytes --]

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 <new_branch_name>
>   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 <new_branch_name>" to save your commit"?  
> That's bad wording, but the idea is there.

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: pushing changes to a remote branch

[Junio C Hamano]

Jan Hudec <bulb@ucw.cz> 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 <new_branch_name>
>>   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?

Re: pushing changes to a remote branch

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 1977 bytes --]

On Wed, Jul 11, 2007 at 14:26:14 -0700, Junio C Hamano wrote:
> Jan Hudec <bulb@ucw.cz> 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 <new_branch_name>
> >>   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 <new_branch_name>"

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: pushing changes to a remote branch

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 1085 bytes --]

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

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]