Re: Dumb question about git
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
Re: Dumb question about git
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
Re: Dumb question about git
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
Re: Dumb question about git
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
Re: Dumb question about git
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
Re: Dumb question about git
Unless you have an expectation that other people are already using the old version of your branch, just use 'git push blah -f' to overwrite the old version. It's not a big deal for patches and pull requests, but it would be a disaster if anyone did this to the master branch. "H. S. Teoh" wrote in message news:mailman.271.1330614611.24984.digitalmars-d-le...@puremagic.com... > 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".
Re: Dumb question about git
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
Re: Dumb question about git
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 ^^
Re: Dumb question about git
On Mar 1, 2012 12:15 PM, "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. > > > 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
Re: Dumb question about git
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!"
Re: Dumb question about git
On 01.03.2012 19:11, H. S. Teoh 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 I use the magic pull --rebase master instead of these 3 if I have changes but want to sync with upstream. - 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. That's pretty much all. - Tried to push branch to my fork, but now it complains that I have non-fast-forward changes and rejects the push. I think push --force should do the trick What's the right thing to do here? Looks like I screwed up my branch history. How do I fix it? Thanks! T -- Dmitry Olshansky
Re: Dumb question about git
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" 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". >
