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

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

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). ;)

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


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

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

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

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.

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

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

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.

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

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