When people say git encourages rewriting history.  Don't listen.  Once you
have pushed your changes to the world they are immutable.  This is because
git uses cryptography internally and changing the history messes everything
up.  If you haven't pushed you can change all of your history and it will
all be fine.  But if someone else (github) has the old hisory bad things
happen.  If you are sure nobody has pulled from github you can use --force
when pushing (I think).  It will work no matter what but you will piss off
people if they have pulled from you.  Please note that this kind of history
modifying is considered bad practice.
On Mar 1, 2012 10:10 AM, "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:

> OK, so I'm new to git, and I ran into this problem:
>
> - I forked druntime on github and made some changes in a branch
> - Pushed the changes to the fork
> - Pulled upstream commits to master
> - Merged master with branch
> - Ran git rebase master, so that my changes appear on top of the latest
>  upstream master.
> - Tried to push branch to my fork, but now it complains that I have
>  non-fast-forward changes and rejects the push.
>
> What's the right thing to do here? Looks like I screwed up my branch history. How do I fix it?
>
> Thanks!
>
>
> T
>
> --
> Real Programmers use "cat > a.out".
>

On Thu, Mar 01, 2012 at 10:22:33AM -0500, Kevin Cox wrote:
> When people say git encourages rewriting history.  Don't listen.  Once you have pushed your changes to the world they are immutable.  This is because git uses cryptography internally and changing the history messes everything up.  If you haven't pushed you can change all of your history and it will all be fine.  But if someone else (github) has the old hisory bad things happen.  If you are sure nobody has pulled from github you can use --force when pushing (I think).  It will work no matter what but you will piss off people if they have pulled from you.  Please note that this kind of history modifying is considered bad practice.
[...]

OK, so what's the right way to do it then? I have some changes in a branch, but master has been updated since, so I want to merge in the latest updates so that the branch changes are compatible with the latest code. If I just pull from master, then my changes get buried underneath the newest changes.

I guess I still don't quite understand how things are supposed to work in situations like this.


T

-- 
Music critic: "That's an imitation fugue!"

On Mar 1, 2012 12:15 PM, "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
>
> On Thu, Mar 01, 2012 at 10:22:33AM -0500, Kevin Cox wrote:
> > When people say git encourages rewriting history.  Don't listen.  Once you have pushed your changes to the world they are immutable.  This is because git uses cryptography internally and changing the history messes everything up.  If you haven't pushed you can change all of your history and it will all be fine.  But if someone else (github) has the old hisory bad things happen.  If you are sure nobody has pulled from github you can use --force when pushing (I think).  It will work no matter what but you will piss off people if they have pulled from you.  Please note that this kind of history modifying is considered bad practice.
> [...]
>
> OK, so what's the right way to do it then? I have some changes in a branch, but master has been updated since, so I want to merge in the latest updates so that the branch changes are compatible with the latest code. If I just pull from master, then my changes get buried underneath the newest changes.
>
> I guess I still don't quite understand how things are supposed to work in situations like this.
>
>
> T
>
> --
> Music critic: "That's an imitation fugue!"

This time I would just --force.  In the future the idea is to only push changes once you are happy with them.

What I would do next time is:
- work
- commit
- work
- commit
- pull
- rebase (make what you have done look pretty)
- push

> OK, so what's the right way to do it then? I have some changes in a
> branch, but master has been updated since, so I want to merge in the
> latest updates so that the branch changes are compatible with the latest
> code.

I use a quite crappy way to rebase my feature branch:
git stash && git checkout master && git pull -v --rebase && git rebase master myworkingbranch

There's probably some redundancy or whatever here, but at least it works ^^

On Thursday, March 01, 2012 09:17:18 H. S. Teoh wrote:
> On Thu, Mar 01, 2012 at 10:22:33AM -0500, Kevin Cox wrote:
> > When people say git encourages rewriting history. Don't listen. Once you have pushed your changes to the world they are immutable. This is because git uses cryptography internally and changing the history messes everything up. If you haven't pushed you can change all of your history and it will all be fine. But if someone else (github) has the old hisory bad things happen. If you are sure nobody has pulled from github you can use --force when pushing (I think). It will work no matter what but you will piss off people if they have pulled from you. Please note that this kind of history modifying is considered bad practice.
> 
> [...]
> 
> OK, so what's the right way to do it then? I have some changes in a branch, but master has been updated since, so I want to merge in the latest updates so that the branch changes are compatible with the latest code. If I just pull from master, then my changes get buried underneath the newest changes.
> 
> I guess I still don't quite understand how things are supposed to work in situations like this.

If you make changes in a branch and want them on top of what's in master, then do

git-rebase master

in _the branch_ and then merge the branch into master. And if you're using github to do pull requests and the like, then don't merge into master all. Simply create the pull request from the branch. That way, master only ever gets updated when the main repository gets updated, and you always have a clean version which matches the main repository.

- Jonathan M Davis

On Thu, 01 Mar 2012 17:16:59 -0500, Jonathan M Davis wrote:
>
> If you make changes in a branch and want them on top of what's in master, then do
> 
> git-rebase master

While "git-rebase" may be available on your system, I think the typical spelling would be

  git rebase master

Graham


> in _the branch_ and then merge the branch into master. And if you're using github to do pull requests and the like, then don't merge into master all. Simply create the pull request from the branch. That way, master only ever gets updated when the main repository gets updated, and you always have a clean version which matches the main repository.
> 
> - Jonathan M Davis

On Friday, March 02, 2012 14:47:00 Graham Fawcett wrote:
> On Thu, 01 Mar 2012 17:16:59 -0500, Jonathan M Davis wrote:
> > If you make changes in a branch and want them on top of what's in master, then do
> > 
> > git-rebase master
> 
> While "git-rebase" may be available on your system, I think the typical spelling would be
> 
> git rebase master

Both should work, and the man page is going to be for git-rebase. Pretty much all of the git commands can be used with or without a -.

- Jonathan M Davis

On Friday, 2 March 2012 at 18:10:56 UTC, Jonathan M Davis wrote:
> Both should work, and the man page is going to be for git-rebase. Pretty much
> all of the git commands can be used with or without a -.

On my system, the dashed commands are not directly accessible, and the man page exclusively uses the non-dashed version except for the page title, where it has to as man page names can't (or at least usually don't), contain spaces.

As far as I know, the dash commands are considered merely an implementation detail now and shouldn't be used directly, but I don't have an official source on hand.

David

On Fri, 02 Mar 2012 20:30:07 +0100, David Nadlinger wrote:

> On Friday, 2 March 2012 at 18:10:56 UTC, Jonathan M Davis wrote:
>> Both should work, and the man page is going to be for git-rebase.
>> Pretty much
>> all of the git commands can be used with or without a -.
> 
> On my system, the dashed commands are not directly accessible, and the man page exclusively uses the non-dashed version except for the page title, where it has to as man page names can't (or at least usually don't), contain spaces.

Yes, same here: git is /usr/bin/git, but git-rebase is /usr/lib/git-core/ git-rebase, which isn't on my $PATH (and probably shouldn't be, as David suggests).

Graham

On 2012-03-02 20:30, David Nadlinger wrote:
> On Friday, 2 March 2012 at 18:10:56 UTC, Jonathan M Davis wrote:
>> Both should work, and the man page is going to be for git-rebase.
>> Pretty much
>> all of the git commands can be used with or without a -.
>
> On my system, the dashed commands are not directly accessible, and the
> man page exclusively uses the non-dashed version except for the page
> title, where it has to as man page names can't (or at least usually
> don't), contain spaces.

Neither on Mac OS X.

> As far as I know, the dash commands are considered merely an
> implementation detail now and shouldn't be used directly, but I don't
> have an official source on hand.
>
> David


-- 
/Jacob Carlborg