I got out of this morning's git problem by checking out a complete new
system and merging (my hand).  But now it is must again

100> git push
jpff@csound.git.sourceforge.net's password: 
To ssh://jpff@csound.git.sourceforge.net/gitroot/csound/csound5
 ! [rejected]        ParCS -> ParCS (non-fast-forward)
error: failed to push some refs to 'ssh://jpff@csound.git.sourceforge.net/gitroot/csound/csound5'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again.  See the 'Note about
fast-forwards' section of 'git push --help' for details.

I am rapidly losing confidence in git
==John ffitch

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On 15 April 2011 13:32, John ff  wrote:
> I got out of this morning's git problem by checking out a complete new
> system and merging (my hand).  But now it is must again
>
> 100> git push
> jpff@csound.git.sourceforge.net's password:
> To ssh://jpff@csound.git.sourceforge.net/gitroot/csound/csound5
>  ! [rejected]        ParCS -> ParCS (non-fast-forward)
> error: failed to push some refs to 'ssh://jpff@csound.git.sourceforge.net/gitroot/csound/csound5'
> To prevent you from losing history, non-fast-forward updates were rejected
> Merge the remote changes before pushing again.  See the 'Note about
> fast-forwards' section of 'git push --help' for details.
>

You have local changes that were based on a previous history of the
repository, but the repository has moved on. One option other than a
further merge is to try rebasing your changes onto the current state
of the remote repository:

$ git rebase origin/master

(described here: http://consttype.blogspot.com/2008/10/git-on-rebasing.html)

> I am rapidly losing confidence in git

Because you don't think it's up to the job?

Gareth

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Fri, Apr 15, 2011 at 09:32, John ff  wrote:
> I got out of this morning's git problem by checking out a complete new
> system and merging (my hand).  But now it is must again
>
> 100> git push
> jpff@csound.git.sourceforge.net's password:
> To ssh://jpff@csound.git.sourceforge.net/gitroot/csound/csound5
>  ! [rejected]        ParCS -> ParCS (non-fast-forward)
> error: failed to push some refs to 'ssh://jpff@csound.git.sourceforge.net/gitroot/csound/csound5'
> To prevent you from losing history, non-fast-forward updates were rejected
> Merge the remote changes before pushing again.  See the 'Note about
> fast-forwards' section of 'git push --help' for details.

This means (as Gareth noted) that someone else has committed in
between your checkout and your push. This is similar to when CVS
rejects a commit because it conflicts with a change you just did, but
git prefers to fail earlier, because it doesn't make the assumption
that the merge of both trees will actually result in working code.
That is why you need to merge or rebase explicitly before pushing
again.

>
> I am rapidly losing confidence in git

I hope you regain it. The first steps are hard.



-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/

My problem is that the documentation is not written in my language.  It
seems you are telling me I need top merge; how?  I have not created a
branch so as far as i am concerned it is HEAD.  So far no idea what
rebasing is.  I cannot even find out what the changes are


> This means (as Gareth noted) that someone else has committed in
> between your checkout and your push. This is similar to when CVS
> rejects a commit because it conflicts with a change you just did, but
> git prefers to fail earlier, because it doesn't make the assumption
> that the merge of both trees will actually result in working code.
> That is why you need to merge or rebase explicitly before pushing
> again.
>
>



------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

As far as git is concerned, there is no such thing as a central
repository. Therefore, there is no central HEAD. Every clone/checkout
is a new branch, since git has no way of knowing what is the central
repository. Therefore, your local copy may diverge from the central
repository, and as far as git is concerned, your local copy and the
central repository are two branches that need to be merged, and it
will _not_ do it automatically while pushing, because it does not
assume that a conflict-less merge actually results in a valid state
(CVS does make this assumption).

To see the divergences between your local clone and the upstream
repository, you can:

git fetch # this will update git's knowledge of what is in the central repo
gitk --all

When you want to push, you need to merge what happened on the remote
repo and what you did in your local copy. You can do that with:

git merge origin/master # or origin/ParCS if you where in that branch

Git pull is just a shortcut for git fetch + git merge.



Rebasing is a tricky concept, because it involves rewriting history. I
would not recommend doing that until you are comfortable with how git
works, since rewriting history can result in breakage for other people
following the repository. For more information, you can see [1].


[1] http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html

On Sat, Apr 16, 2011 at 04:46,   wrote:
> My problem is that the documentation is not written in my language.  It
> seems you are telling me I need top merge; how?  I have not created a
> branch so as far as i am concerned it is HEAD.  So far no idea what
> rebasing is.  I cannot even find out what the changes are
>
>
>> This means (as Gareth noted) that someone else has committed in
>> between your checkout and your push. This is similar to when CVS
>> rejects a commit because it conflicts with a change you just did, but
>> git prefers to fail earlier, because it doesn't make the assumption
>> that the merge of both trees will actually result in working code.
>> That is why you need to merge or rebase explicitly before pushing
>> again.
>>
>>
>
>
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists