Re: "remote end hung up unexpectedly"

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

 



On 11/12/2007, at 5:54 PM, Andreas Ericsson wrote:
I'm bringing this back on the list. It's very uncharitable of you to not
do so yourself,

My humble apologies - I just hit reply. I've previously only encountered
majordomo configurations where the reply goes to the list (including
when I operated majordomo for ten years), so I made a mistake.

Not really. You can do "git rebase --onto origin/master master". However, since you merged origin/master earlier, a rebase will only tell you that
you're up-to-date.
I don't think that anything I've done has affected the remote repository.

It hasn't. The only way you can update the remote repository, short of
editing it manually, is to use "git push". That's not strictly true, but
for the sake of this argument, it will suffice.

Thanks, that's good confirmation.

Most of the instructions and manpages I've read show how to do things
to local repositories and push changes back. Here's what I most recently tried, perhaps you can see where I went wrong. I've changed the project
name for PROJECT, and the branch name with BRANCH
git clone git+ssh://cjheath@xxxxxxxxxx/srv/git/PROJECT.git
cd PROJECT
git checkout --track -b BRANCH origin/BRANCH
git rebase origin/master
At this point the local branch seems to have the content I want, so I tried
to push the changes back in:

You mean, "at this point BRANCH seems to have the content I want"?

No, I mean that the recent changes have been pulled from origin/master
and my tree looks like what I want the remote origin/BRANCH to look like. Though if I pushed, I don't know that its revision history would necessarily
be in the preferred order.

git push
Which replied:
error: remote 'refs/heads/BRANCH' is not a strict subset of local ref 'refs/heads/BRANCH'. maybe you are not up-to-date and need to pull first? error: failed to push to 'git+ssh://cjheath@xxxxxxxxxx/srv/git/ PROJECT.git'

Yes. What you did caused history to be rewritten. Push is fast- forward[1] only by default, to prevent published history from being modified, so when you moved one line of development onto another you effectively changed its
ancestry.

Ok, I think I follow that. I can see I need to spend more time reading the
man pages.  Thanks for your help...

Clifford Heath.

If you do

git checkout BRANCH
git reset --hard origin/BRANCH
git merge origin/master
git push

you will achieve the desired end-result. If you really, really want a linear
history, you can do

git push -f origin BRANCH

but beware that this will cause errors for everyone fetching from you, and for yourself if you fetch into multiple local clones of the same remote.

I suggest you sit down and really read through the git rebase man- page to understand what it does and the precautions one must take when rewriting
history like that.


[1]fast-forward:
   A fast-forward is a special type of merge where you have a
   revision and you are "merging" another branch's changes that
   happen to be a descendant of what you have. In such cases,
   you do not make a new merge commit but instead just update
   to his revision. This will happen frequently on a tracking
   of a remote repository.

--
Andreas Ericsson                   andreas.ericsson@xxxxxx
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

-
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