* Re: SUCCESS -- failed to push
2010-03-01 22:00 ` Bruce Korb
@ 2010-03-01 22:04 ` Bruce Korb
2010-03-02 11:44 ` Erik Faye-Lund
2010-03-02 19:09 ` Jakub Narebski
2 siblings, 0 replies; 10+ messages in thread
From: Bruce Korb @ 2010-03-01 22:04 UTC (permalink / raw)
To: GIT
Bruce Korb wrote:
>> In terms of recovering from your present situation I'd try the
>> following (Disclaimer: maybe you shouldn't try these based solely on
>> my advice. I'm still learning too)
>>
>> git pull
>> <resolve merge issue, 'git mergetool' is your friend>
>> git push
>>
>> I think this will basically sort things out but you may need to hand
>> hold a few things through a merge depending on how different the 2
>> commits are.
>
> I will be trying this procedure momentarily.
There were no resolution issues. "git pull ; git push" was sufficient.
Thank you all for your help! Regards, Bruce
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: failed to push
2010-03-01 22:00 ` Bruce Korb
2010-03-01 22:04 ` SUCCESS -- " Bruce Korb
@ 2010-03-02 11:44 ` Erik Faye-Lund
2010-03-02 19:09 ` Jakub Narebski
2 siblings, 0 replies; 10+ messages in thread
From: Erik Faye-Lund @ 2010-03-02 11:44 UTC (permalink / raw)
To: bkorb; +Cc: Chris Packham, GIT
On Mon, Mar 1, 2010 at 11:00 PM, Bruce Korb <bkorb@gnu.org> wrote:
> Hi,
>
> Thank you-all for your replies.
>
> Chris Packham wrote:
>>>> To ssh://bkorb@autogen.git.sourceforge.net/gitroot/autogen/autogen
>>>> ! [rejected] master -> master (non-fast forward)
>>>> error: failed to push some refs to 'ssh://bkorb@autogen.git.sourceforge.net/gitroot/autogen/autogen'
>
> CF:
>> It tells you right there at the end of the rejected line. The push
>> would have resulted in a non-fast-forward update of the branch.
>
> "non-fast forward" is not very helpful either.
>
How so? "git help glossary" gives you a description of what a
fast-forward is. In my installed copy, it's spelled without a dash,
though. But that's a minor nit, I still found it easily.
>> This basically means that the push you have attempted is not a simple
>> fast forward. This basically means that the commit your work is based
>> on is not present in the remote or that there have been other pushes
>> to the remote and you need to pull them into your repository to handle
>> any merging.
>
> Since the sequence was:
> git commit
> git push
> <more editing>
> git commit --amend
> git push
>
> the neophyte (me) is not going to know that this produces an un-pulled
> delta.
>
"git help commit" gives a warning about this when documenting --amend,
and links to the full description in the rebase-documentation.
>> In a DVCS like git all commits happen locally, the only time commits
>> are sent to the remote repo are when you've pushed so 'git commit
>> --amend' or 'git gui' with the amend box ticked only makes the change
>> locally it won't implicitly figure out that a commit has been pushed
>> out into the ether. One rule of thumb with git (I think it applies to
>> most DVCSes) is not to amend a commit that has been pushed for this
>> very reason.
>
> Then please be kind enough to put a *CAUTION* button next to
> the amend button and have it bring up something that gives you
> a little warning.
That sounds to me like a good idea. Care enough to make a patch.
> GIT *could* have been written in a way that
> causes the remote repo to become synced with my local repo,
> but apparently it was not and there was not adequate warning.
>
That would have caused problems for anyone who cloned. But yes,
git-gui might benefit from a warning here.
>> - or -
>>
>> git push -f
>
> This fails with the same "non-fast forward" rejection message. :(
I've seen this on sourceforge as well, it seems they have some extra
checks (hooks?) to disallow pushing rebased branches. The best thing
would be not to rewrite it. But if you INSIST, what worked for me was
to delete the branch and then re-pushing it. Something like this "git
push remote-name :branch-name && git push remote-name branch-name"
--
Erik "kusma" Faye-Lund
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: failed to push
2010-03-01 22:00 ` Bruce Korb
2010-03-01 22:04 ` SUCCESS -- " Bruce Korb
2010-03-02 11:44 ` Erik Faye-Lund
@ 2010-03-02 19:09 ` Jakub Narebski
2010-03-02 21:36 ` Chris Packham
2 siblings, 1 reply; 10+ messages in thread
From: Jakub Narebski @ 2010-03-02 19:09 UTC (permalink / raw)
To: bkorb; +Cc: Chris Packham, GIT
Bruce Korb <bkorb@gnu.org> writes:
> Chris Packham wrote:
> >>> To ssh://bkorb@autogen.git.sourceforge.net/gitroot/autogen/autogen
> >>> ! [rejected] master -> master (non-fast forward)
> >>> error: failed to push some refs to 'ssh://bkorb@autogen.git.sourceforge.net/gitroot/autogen/autogen'
>
> CF:
> > It tells you right there at the end of the rejected line. The push
> > would have resulted in a non-fast-forward update of the branch.
>
> "non-fast forward" is not very helpful either.
It is part of git jargon, and can be found in gitglossary.
> > This basically means that the push you have attempted is not a simple
> > fast forward. This basically means that the commit your work is based
> > on is not present in the remote or that there have been other pushes
> > to the remote and you need to pull them into your repository to handle
> > any merging.
>
> Since the sequence was:
> git commit
> git push
> <more editing>
> git commit --amend
> git push
>
> the neophyte (me) is not going to know that this produces an un-pulled
> delta.
Well, all of us old gitters know: 1) that you should not change
published (pushed) history, 2) that commits are immutable, and 3) that
amending a commit generates new commit with correction and therefore
changes history.
It is true that git documentation ("Git User's Manual", "Git Community
Book", "Pro Git") can be lacking... unfortunately by the time somebody
is knowledgeable enough to write git documentaions, he/she is usally
used to git way of doing things, and the documentation might not be
newbie-friendly.
> > In a DVCS like git all commits happen locally, the only time commits
> > are sent to the remote repo are when you've pushed so 'git commit
> > --amend' or 'git gui' with the amend box ticked only makes the change
> > locally it won't implicitly figure out that a commit has been pushed
> > out into the ether. One rule of thumb with git (I think it applies to
> > most DVCSes) is not to amend a commit that has been pushed for this
> > very reason.
>
> Then please be kind enough to put a *CAUTION* button next to
> the amend button and have it bring up something that gives you
> a little warning. GIT *could* have been written in a way that
> causes the remote repo to become synced with my local repo,
> but apparently it was not and there was not adequate warning.
What git-gui (and other git interaces) could do is to check if there
is indicator that the part of history you want to change (via amending
a commit, or via [interactive] rebase) is published. On the other
hand you probably would not want for git to access network to check it
before history-rewriting commands...
> > Strictly speaking all commits are immutable, when you
> > amend a commit you actually create a whole new commit and your old one
> > is marked for garbage collection (if nothing else is based off it).
> >
> > In terms of recovering from your present situation I'd try the
> > following (Disclaimer: maybe you shouldn't try these based solely on
> > my advice. I'm still learning too)
> >
> > git pull
> > <resolve merge issue, 'git mergetool' is your friend>
> > git push
> >
> > I think this will basically sort things out but you may need to hand
> > hold a few things through a merge depending on how different the 2
> > commits are.
>
> I will be trying this procedure momentarily. Meanwhile, since I am
> the only person on the planet authorized to commit to the public repo:
>
> > - or -
> >
> > git push -f
>
> This fails with the same "non-fast forward" rejection message. :(
Whether you are able to force pushing non fast-forward changes depends
on configuration on remote side (receive.denyNonFastForwards), and on
the update / pre-receive hooks which can also forbid forcing non
fasf-forward changes.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: failed to push
2010-03-02 19:09 ` Jakub Narebski
@ 2010-03-02 21:36 ` Chris Packham
2010-03-02 23:07 ` [gitbook PATCH] add notes on re-writing history Chris Packham
0 siblings, 1 reply; 10+ messages in thread
From: Chris Packham @ 2010-03-02 21:36 UTC (permalink / raw)
To: GIT; +Cc: bkorb, Jakub Narebski, schacon
On Tue, Mar 2, 2010 at 11:09 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> Well, all of us old gitters know: 1) that you should not change
> published (pushed) history, 2) that commits are immutable, and 3) that
> amending a commit generates new commit with correction and therefore
> changes history.
>
> It is true that git documentation ("Git User's Manual", "Git Community
> Book", "Pro Git") can be lacking... unfortunately by the time somebody
> is knowledgeable enough to write git documentaions, he/she is usally
> used to git way of doing things, and the documentation might not be
> newbie-friendly.
I thought I smelt an easy documentation patch but the current help for
git commit --amend seems to cover it
"You should understand the implications of rewriting history if you
amend a commit that has already been published"
These sections [1],[2] of the git community book could probably do
with a note on the consequences or re-writing history. I'll see if I
can figure out how to submit a change.
[1] http://book.git-scm.com/4_undoing_in_git_-_reset,_checkout_and_revert.html
[2] http://book.git-scm.com/5_modifying_your_history.html
>Bruce Korb <bkorb@gnu.org> writes:
>> Then please be kind enough to put a *CAUTION* button next to
>> the amend button and have it bring up something that gives you
>> a little warning. GIT *could* have been written in a way that
>> causes the remote repo to become synced with my local repo,
>> but apparently it was not and there was not adequate warning.
Shouldn't be too hard to repeat the warning from git help commit. Just
not sure of what the least intrusive way to do it is (plus my tcl-fu
is weak).
^ permalink raw reply [flat|nested] 10+ messages in thread* [gitbook PATCH] add notes on re-writing history
2010-03-02 21:36 ` Chris Packham
@ 2010-03-02 23:07 ` Chris Packham
0 siblings, 0 replies; 10+ messages in thread
From: Chris Packham @ 2010-03-02 23:07 UTC (permalink / raw)
To: schacon; +Cc: git, jnareb, bkorb, Chris Packham
Add a note on the consequences of re-writing a repositories history in
"Undoing in Git - Reset, Checkout and Revert/Fixing a mistake by
modifying a commit" and "Modifying your History".
---
I didn't sucessfully get the ruby gems installed on openSUSE 11.2 (problems
installing ultraviolet) so if someone who does have a working environment could
have a look and maybe do a bit of polishing that would be helpful.
.../0_ Redoing_Git_Reset_and_Revert.markdown | 6 +++++-
.../0_Changing_History.markdown | 20 ++++++++++++++++++--
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/text/21_Redoing_Git_Reset_and_Revert/0_ Redoing_Git_Reset_and_Revert.markdown b/text/21_Redoing_Git_Reset_and_Revert/0_ Redoing_Git_Reset_and_Revert.markdown
index b37245d..8b876f2 100644
--- a/text/21_Redoing_Git_Reset_and_Revert/0_ Redoing_Git_Reset_and_Revert.markdown
+++ b/text/21_Redoing_Git_Reset_and_Revert/0_ Redoing_Git_Reset_and_Revert.markdown
@@ -43,7 +43,11 @@ fundamentally different ways to fix the problem:
never do this if you have already made the history public;
git does not normally expect the "history" of a project to
change, and cannot correctly perform repeated merges from
- a branch that has had its history changed.
+ a branch that has had its history changed. If you do re-write
+ a repositories history anyone else who has cloned the
+ repository will need manually correct the problem on their
+ clone see the "RECOVERING FROM UPSTREAM REBASE" section
+ in linkgit:git-rebase[1].
#### Fixing a mistake with a new commit ####
diff --git a/text/25_Changing_Your_History/0_Changing_History.markdown b/text/25_Changing_Your_History/0_Changing_History.markdown
index b569f46..160c838 100644
--- a/text/25_Changing_Your_History/0_Changing_History.markdown
+++ b/text/25_Changing_Your_History/0_Changing_History.markdown
@@ -1,6 +1,22 @@
## Modifying your History ##
-Interactive rebasing is a good way to modify individual commits.
+There are several ways to re-write the history of a repository. All of
+these can cause problems for commits that have already been pushed to a
+remote repository. If you do re-write a repositories history anyone else
+who has cloned the repository will need manually correct the problem on
+their clone see the "RECOVERING FROM UPSTREAM REBASE" section in
+linkgit:git-rebase[1].
-linkgit:git-filter-branch[1] is a good way to edit commits en masse.
+The simplest method is to use "git commit --amend" to modify the last commit.
+This is useful to correct a commit message, or make a simple update to a
+commit before pushing.
+
+Interactive rebasing is a good way to modify multiple commits. Commits can
+be combined by squashing, changed by editing or removed entirely.
+
+linkgit:git-filter-branch[1] is a good way to edit commits en masse. This is
+useful where a whole component needs to be removed from a project. For
+example removing a subsystem which is licenced under an incompatible
+opensource licence. Or it can be used to alter the commit authorship without
+changing the code.
--
1.7.0.1
^ permalink raw reply related [flat|nested] 10+ messages in thread