Re: pushing changes to a remote branch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux