www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Confused about github rebasing

reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
I'm trying to submit a pull request for druntime, but I'm running into a
git problem. This is what I did:

- (I forgot that my master branch is out of date)
- created a new branch for the fix and committed some changes
- switched to master and ran 'git pull'
- now master is ahead of the branch by a number of commits
- switched back to branch
- ran 'git rebase master' to pull in changes from master and apply my
  changes on top of it
- checked that history looks clean
- 'git push -u origin newbranch'
- submit pull request: but now github thinks my branch has a whole bunch
  of commits I didn't make (looks like the commits made by rebase).

So my question is, what did I do wrong, and what's the right way to
pull in the latest changes from upstream without messing up the history?


T

-- 
English is useful because it is a mess. Since English is a mess, it maps
well onto the problem space, which is also a mess, which we call
reality. Similarly, Perl was designed to be a mess, though in the
nicests of all possible ways. -- Larry Wall
Mar 15 2012
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 15-03-2012 20:13, H. S. Teoh wrote:

 I'm trying to submit a pull request for druntime, but I'm running into a
 git problem. This is what I did:

 - (I forgot that my master branch is out of date)
 - created a new branch for the fix and committed some changes
 - switched to master and ran 'git pull'
 - now master is ahead of the branch by a number of commits
 - switched back to branch
 - ran 'git rebase master' to pull in changes from master and apply my
    changes on top of it
 - checked that history looks clean
 - 'git push -u origin newbranch'
 - submit pull request: but now github thinks my branch has a whole bunch
    of commits I didn't make (looks like the commits made by rebase).

 So my question is, what did I do wrong, and what's the right way to
 pull in the latest changes from upstream without messing up the history?


 T


Let's say you're on your branch with your commits. You have a remote 
called dpl, which is upstream. So:

$ git fetch dpl
$ git pull --rebase dpl master
$ git push origin <your branch> -f

Note the -f, since you're overwriting remote history in your repo.

-- 
- Alex
Mar 15 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 15, 2012 at 08:59:57PM +0100, Alex Rønne Petersen wrote:

 On 15-03-2012 20:13, H. S. Teoh wrote:

I'm trying to submit a pull request for druntime, but I'm running into a
git problem. This is what I did:

- (I forgot that my master branch is out of date)
- created a new branch for the fix and committed some changes
- switched to master and ran 'git pull'
- now master is ahead of the branch by a number of commits
- switched back to branch
- ran 'git rebase master' to pull in changes from master and apply my
   changes on top of it
- checked that history looks clean
- 'git push -u origin newbranch'
- submit pull request: but now github thinks my branch has a whole bunch
   of commits I didn't make (looks like the commits made by rebase).

So my question is, what did I do wrong, and what's the right way to
pull in the latest changes from upstream without messing up the history?


T


 
 Let's say you're on your branch with your commits. You have a remote
 called dpl, which is upstream. So:
 
 $ git fetch dpl
 $ git pull --rebase dpl master
 $ git push origin <your branch> -f
 
 Note the -f, since you're overwriting remote history in your repo.


[...]

OK thanks!

Another question. How to I repair my current history, which is all
messed up now? That is, my branch has a whole bunch of commits I didn't
make; how do I clean it up? Or is it easier to start from scratch? :)


T

-- 
If Java had true garbage collection, most programs would delete
themselves upon execution. -- Robert Sewell
Mar 15 2012
next sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 15-03-2012 21:49, H. S. Teoh wrote:

 On Thu, Mar 15, 2012 at 08:59:57PM +0100, Alex Rønne Petersen wrote:

 On 15-03-2012 20:13, H. S. Teoh wrote:

 I'm trying to submit a pull request for druntime, but I'm running into a
 git problem. This is what I did:

 - (I forgot that my master branch is out of date)
 - created a new branch for the fix and committed some changes
 - switched to master and ran 'git pull'
 - now master is ahead of the branch by a number of commits
 - switched back to branch
 - ran 'git rebase master' to pull in changes from master and apply my
    changes on top of it
 - checked that history looks clean
 - 'git push -u origin newbranch'
 - submit pull request: but now github thinks my branch has a whole bunch
    of commits I didn't make (looks like the commits made by rebase).

 So my question is, what did I do wrong, and what's the right way to
 pull in the latest changes from upstream without messing up the history?


 T


 Let's say you're on your branch with your commits. You have a remote
 called dpl, which is upstream. So:

 $ git fetch dpl
 $ git pull --rebase dpl master
 $ git push origin<your branch>  -f

 Note the -f, since you're overwriting remote history in your repo.


 [...]

 OK thanks!

 Another question. How to I repair my current history, which is all
 messed up now? That is, my branch has a whole bunch of commits I didn't
 make; how do I clean it up? Or is it easier to start from scratch? :)


 T


Well, it really depends on how the history looks... How many commits do 
you have? If it's a small number, just branch off upstream and 
cherry-pick each commit.

-- 
- Alex
Mar 15 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 15, 2012 at 09:51:30PM +0100, Alex Rønne Petersen wrote:

 On 15-03-2012 21:49, H. S. Teoh wrote:


[...]

Another question. How to I repair my current history, which is all
messed up now? That is, my branch has a whole bunch of commits I didn't
make; how do I clean it up? Or is it easier to start from scratch? :)


T


 
 Well, it really depends on how the history looks... How many commits
 do you have? If it's a small number, just branch off upstream and
 cherry-pick each commit.


[...]

OK, so I finally figured out how to repair it.

Actually, I discovered that my origin/master branch was also broken
(probably due to running the wrong git command in it in the past),
because it had a bunch of commits from upstream that for some reason had
different hashes (maybe the result of attempting to merge from a messed
up branch?). This is probably why my topic branch was messed up in the
first place, I think.

So I did git reset --hard to clean up the history back to the point
where it first starting diverging, then pulled from upstream/master
(which I confirmed were fast-forward). Then I used `git push -f master`
to clean up the history on github. So that takes care of master.

Then in my topic branch, which had a messed up history:

	(branchpoint)---(fast-forwards from upstream) <-- master
	     \
	      \---(merged)---(merged)---...---(my changes) <-- topic

I did a `git rebase --onto master (my changes)`:

	(branchpoint)---(fast-forwards from upstream) <-- master
	    \                                      \
	     \---(now unreachable commits)          \--(my changes) <-- topic

Then I used git push -f to cleanup the history on github.

So now everything looks OK again. Phew!

I did discover an interesting thing about git though... at one point in
the cleanup process I accidentally reset 1 more commit than I had
intended, and that commit had no other references to it (unreachable).
But luckily I still had its hash available, so `git merge <hash>`
managed to restore it. I guess old unreachable commits are still kept
until you run git gc.

So that's one of the times when you *don't* want to run git gc. :-)


T

-- 
Laissez-faire is a French term commonly interpreted by Conservatives to
mean 'lazy fairy,' which is the belief that if governments are lazy
enough, the Good Fairy will come down from heaven and do all their work
for them.
Mar 15 2012
next sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 15-03-2012 22:37, H. S. Teoh wrote:

 On Thu, Mar 15, 2012 at 09:51:30PM +0100, Alex Rønne Petersen wrote:

 On 15-03-2012 21:49, H. S. Teoh wrote:


 [...]

 Another question. How to I repair my current history, which is all
 messed up now? That is, my branch has a whole bunch of commits I didn't
 make; how do I clean it up? Or is it easier to start from scratch? :)


 T


 Well, it really depends on how the history looks... How many commits
 do you have? If it's a small number, just branch off upstream and
 cherry-pick each commit.


 [...]

 OK, so I finally figured out how to repair it.

 Actually, I discovered that my origin/master branch was also broken
 (probably due to running the wrong git command in it in the past),
 because it had a bunch of commits from upstream that for some reason had
 different hashes (maybe the result of attempting to merge from a messed
 up branch?). This is probably why my topic branch was messed up in the
 first place, I think.

 So I did git reset --hard to clean up the history back to the point
 where it first starting diverging, then pulled from upstream/master
 (which I confirmed were fast-forward). Then I used `git push -f master`
 to clean up the history on github. So that takes care of master.

 Then in my topic branch, which had a messed up history:

 	(branchpoint)---(fast-forwards from upstream)<-- master
 	     \
 	      \---(merged)---(merged)---...---(my changes)<-- topic

 I did a `git rebase --onto master (my changes)`:

 	(branchpoint)---(fast-forwards from upstream)<-- master
 	    \                                      \
 	     \---(now unreachable commits)          \--(my changes)<-- topic

 Then I used git push -f to cleanup the history on github.

 So now everything looks OK again. Phew!

 I did discover an interesting thing about git though... at one point in
 the cleanup process I accidentally reset 1 more commit than I had
 intended, and that commit had no other references to it (unreachable).
 But luckily I still had its hash available, so `git merge<hash>`
 managed to restore it. I guess old unreachable commits are still kept
 until you run git gc.

 So that's one of the times when you *don't* want to run git gc. :-)


 T


See also git reflog. It's a life-saver.

-- 
- Alex
Mar 15 2012
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 15, 2012 at 11:12:26PM +0100, Alex Rønne Petersen wrote:

 On 15-03-2012 22:37, H. S. Teoh wrote:


[...]

I did discover an interesting thing about git though... at one point
in the cleanup process I accidentally reset 1 more commit than I had
intended, and that commit had no other references to it
(unreachable).  But luckily I still had its hash available, so `git
merge<hash>` managed to restore it. I guess old unreachable commits
are still kept until you run git gc.

So that's one of the times when you *don't* want to run git gc. :-)




[...]

 See also git reflog. It's a life-saver.


[...]

Cool! Didn't know about that. Would've needed it if I didn't still have
the hash to the orphaned commit. :) Thanks for the tip.


T

-- 
Democracy: The triumph of popularity over principle. -- C.Bond
Mar 15 2012
prev sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.719.1331847338.4860.digitalmars-d-learn puremagic.com...


 Actually, I discovered that my origin/master branch was also broken
 (probably due to running the wrong git command in it in the past),
 because it had a bunch of commits from upstream that for some reason had
 different hashes (maybe the result of attempting to merge from a messed
 up branch?). This is probably why my topic branch was messed up in the
 first place, I think.

 So I did git reset --hard to clean up the history back to the point
 where it first starting diverging, then pulled from upstream/master
 (which I confirmed were fast-forward). Then I used `git push -f master`
 to clean up the history on github. So that takes care of master.


I used to have this problem all the time - now I have a script which checks 
out master and pulls with -ff-only (in all three repositories) giving me a 
nice big error if I accidentally committed to master.  Although I think I 
just lost it when my hard drive died yesterday...

Get to know rebase -i as well, it can be very useful for untangling history.
Mar 15 2012
next sibling parent reply James Miller <james aatch.net> writes:
On 16 March 2012 16:35, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:

 [...]

 I used to have this problem all the time - now I have a script which
 checks out master and pulls with -ff-only (in all three repositories)
 giving me a nice big error if I accidentally committed to master.
 Although I think I just lost it when my hard drive died yesterday...


 Ahh, thanks for the tip. I'll probably always use -ff-only from now on.
 It's always such a mess to clean up if non-ff commits get merged in by a
 pull. Prevention is better than cure, as they say.



 Get to know rebase -i as well, it can be very useful for untangling
 history.


 [...]

 Yeah I tried that too, but in my case it was easier to just reset HEAD
 back to wherever it diverged from and rerun the pull.


Generally I find that pulls should be rebased, ff-only, and local
merges done with --no-ff. This means that you have merge history in
the tree, which can be useful when trying to do code archaeology, and
pulls are forced to be merged properly, rather than using a merge
commit, avoiding annoying messages in the log.

Git is a strange beast, one moment it is peacful and helpful, the next
it is scary and threatening to eat your files.

Also, git-svn isn't actually that bad...

--
James Miller
Mar 15 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-03-16 04:52, James Miller wrote:

 Also, git-svn isn't actually that bad...


It is. You can't properly use git because you have to make sure it's 
compatible with svn, like linear history. If you don't have a linear 
history you're in big trouble.

-- 
/Jacob Carlborg
Mar 16 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, March 16, 2012 08:52:47 Jacob Carlborg wrote:

 On 2012-03-16 04:52, James Miller wrote:

 Also, git-svn isn't actually that bad...


 
 It is. You can't properly use git because you have to make sure it's
 compatible with svn, like linear history. If you don't have a linear
 history you're in big trouble.


Yeah. I use git-svn at work, because I like it a lot better than using pure
svn, but it's _nowhere_ near as good as pure git. There are just too many
features that you have to be careful with or avoid.

- Jonathan M Davis
Mar 16 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-03-16 09:08, Jonathan M Davis wrote:

 On Friday, March 16, 2012 08:52:47 Jacob Carlborg wrote:

 On 2012-03-16 04:52, James Miller wrote:

 Also, git-svn isn't actually that bad...


 It is. You can't properly use git because you have to make sure it's
 compatible with svn, like linear history. If you don't have a linear
 history you're in big trouble.


 Yeah. I use git-svn at work, because I like it a lot better than using pure
 svn, but it's _nowhere_ near as good as pure git. There are just too many
 features that you have to be careful with or avoid.


Exactly, you need to be very careful and follow a strict workflow to 
avoid breaking svn.

-- 
/Jacob Carlborg
Mar 16 2012
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Mar 16, 2012 at 04:52:35PM +1300, James Miller wrote:
[...]

 Generally I find that pulls should be rebased, ff-only, and local
 merges done with --no-ff. This means that you have merge history in
 the tree, which can be useful when trying to do code archaeology, and
 pulls are forced to be merged properly, rather than using a merge
 commit, avoiding annoying messages in the log.


Why should merges be --no-ff? Doesn't that create a whole bunch of
"spurious" commits in the history?



 Git is a strange beast, one moment it is peacful and helpful, the next
 it is scary and threatening to eat your files.


[...]

The way you worded it made me misread the last phrase as "threatening to
eat your face". :-P


T

-- 
Skill without imagination is craftsmanship and gives us many useful
objects such as wickerwork picnic baskets.  Imagination without skill
gives us modern art. -- Tom Stoppard
Mar 15 2012
prev sibling parent reply Gour <gour atmarama.net> writes:
On Thu, 15 Mar 2012 13:49:14 -0700
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:


 Another question. How to I repair my current history, which is all
 messed up now?=20


By not using DVCS which allows you to rewrite history (hint: check
Fossil). ;)

Otoh, I do not know how much you are 'in love' wiht git, but maybe it
would be possible to use hg-git to collaborate with D  github.


Sincerely,
Gour


--=20
There are principles to regulate attachment and aversion pertaining to=20
the senses and their objects. One should not come under the control of=20
such attachment and aversion, because they are stumbling blocks on the=20
path of self-realization.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Mar 15 2012
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 15-03-2012 21:53, Gour wrote:

 On Thu, 15 Mar 2012 13:49:14 -0700
 "H. S. Teoh"<hsteoh quickfur.ath.cx>  wrote:


 Another question. How to I repair my current history, which is all
 messed up now?


 By not using DVCS which allows you to rewrite history (hint: check
 Fossil). ;)


It's perfectly useful in DVCS. Without it, you'd have a mess of a 
history when you send your changes upstream. That's not really acceptable.


 Otoh, I do not know how much you are 'in love' wiht git, but maybe it
 would be possible to use hg-git to collaborate with D  github.


 Sincerely,
 Gour



-- 
- Alex
Mar 15 2012
parent reply Sean Cavanaugh <WorksOnMyMachine gmail.com> writes:
On 3/15/2012 3:56 PM, Alex Rønne Petersen wrote:

 On 15-03-2012 21:53, Gour wrote:

 On Thu, 15 Mar 2012 13:49:14 -0700
 "H. S. Teoh"<hsteoh quickfur.ath.cx> wrote:


 Another question. How to I repair my current history, which is all
 messed up now?


 By not using DVCS which allows you to rewrite history (hint: check
 Fossil). ;)


 It's perfectly useful in DVCS. Without it, you'd have a mess of a
 history when you send your changes upstream. That's not really acceptable.


Why would you delete history?  Thats pretty much the primary purpose of 
source control.
Mar 15 2012
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, March 15, 2012 16:17:50 Sean Cavanaugh wrote:

 On 3/15/2012 3:56 PM, Alex Rønne Petersen wrote:

 On 15-03-2012 21:53, Gour wrote:

 On Thu, 15 Mar 2012 13:49:14 -0700
 
 "H. S. Teoh"<hsteoh quickfur.ath.cx> wrote:

 Another question. How to I repair my current history, which is all
 messed up now?


 
 By not using DVCS which allows you to rewrite history (hint: check
 Fossil). ;)


 
 It's perfectly useful in DVCS. Without it, you'd have a mess of a
 history when you send your changes upstream. That's not really acceptable.


 
 Why would you delete history? Thats pretty much the primary purpose of
 source control.


There's a difference between the history in the main repository and the history 
in a local branch. It may make a lot of sense to make a lot of small commits 
to your local branch. It's can be easier to manage and rollback small changes 
that way. But it gets to be pretty ugly if the main history has a whole ton of 
small commits. So, it's not all that uncommon to rebase at least sections of 
your local branch's history before merging it into the main repository. You 
don't lose any of the changes. You just don't have as many commits. And once 
it's in the main repository, you never rebase.

- Jonathan M Davis
Mar 15 2012
prev sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 15-03-2012 22:17, Sean Cavanaugh wrote:

 On 3/15/2012 3:56 PM, Alex Rønne Petersen wrote:

 On 15-03-2012 21:53, Gour wrote:

 On Thu, 15 Mar 2012 13:49:14 -0700
 "H. S. Teoh"<hsteoh quickfur.ath.cx> wrote:


 Another question. How to I repair my current history, which is all
 messed up now?


 By not using DVCS which allows you to rewrite history (hint: check
 Fossil). ;)


 It's perfectly useful in DVCS. Without it, you'd have a mess of a
 history when you send your changes upstream. That's not really
 acceptable.


 Why would you delete history? Thats pretty much the primary purpose of
 source control.


I didn't say delete history.

Squashing commits together into one just simplifies the history. It 
makes it easier to review, easier to view in logs, easier to bisect, ...

-- 
- Alex
Mar 15 2012