2011-06-23 12:01:42 git URL-update yields double trees
Rob Maris (GERMANY)
Message: 101622
I'm not very sure about what happened after I moved over to the new git repo for linux-kernel after I found that the mirror wasn't live (I mean: git fetch origin delivered no update info). Then I checked out the status on the linux-kernel project homepage, and found about the switchover to git as main repo.
I altered the appropriate url-entry of the config file
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = git://sources.blackfin.uclinux.org/git/linux-kernel
... as is described elsewhere as a valid means to change the git repo URL, and then a git fetch origin was going to load a vast 250 MB. It ended up with a sort of completely parallel tree, which is separate from my own branches that I push to my own server for backup&sharing purposes.
As a consequence, trunk is (still) in the tree was it was before, while remotes/origin/trunk is no longer in common. To be precise: entries trunk are doubled with entries remotes/origin/trunk throughout the history (applies to much other branches, too). I've not succeeded in restoring the original state (=repo before I applied git fetch). Help appreciated.
Meanwhile I found that the SHA's of all the identical commits of the new git repository compared with the old mirror (which is maintained until 20110416) are completely different. This is why the new repository does not "cooperate" with my own local repo where I maintain my own branches.
QuoteReplyEditDelete
2011-06-23 12:07:55 Re: git URL-update yields double trees
Mike Frysinger (UNITED STATES)
Message: 101623
the history was rewritten to remove binary files and clean up the authors. a bunch of the original commits would do things like add *.o or rootfs.img to the tree. i figured this cut over from readonly-backup to main-tree was a good time to execute this step as i had it sitting around on my TODO for a while.
since the history is different, they are two independent trees. if you have local work, rebase it onto the new tree:
git rebase --onto <new refid> <first refid that is for your local work>
if you dont, then throw away your git repo and check out a new one from scratch.
QuoteReplyEditDelete
2011-07-13 05:29:02 Re: git URL-update yields double trees
Rob Maris (GERMANY)
Message: 102392
Mike, I'm still in serious trouble with the rewritten history. Actually the problem is, that I have merges with trunk into my own branches. Thus the situation is just as described at following text section: www.kernel.org...docs...user-manual... .
I ran into this merge-related problem with my "real-world repo" after I have finished simple tests using a small repo with a master tree, own branches and a repo with rewritten master tree (alas: the test was not complete, it lacked a test merge in an "own" branch).
While doing the tests, I have prepared some Q&A regarding this topic at stackoverflow.com/questions/6658195/help-the-history-of-my-remote-host-is-rewritten-how-to-get-my-local-brances-i. I intend to add information there when progress is made in getting my branches onto the rewritten history. Of course, assumptions can be wrong - my git experience is not at an expert level.
QuoteReplyEditDelete
2011-07-13 12:19:28 Re: git URL-update yields double trees
Mike Frysinger (UNITED STATES)
Message: 102394
i dont think the merges are blockers. you can do one of two things:
- rebase your local branch onto the old trunk branch so that all your changes are in line, then use `git rebase --onto <new trunk> <old trunk>` so git will move all your changes onto the new trunk
- use `git format-patch <old trunk>...<your branch>` to get all the patches between the old trunk branch and your branch, then manually apply those to a new branch based on the new trunk branch with `git am -3`
QuoteReplyEditDelete
2011-07-20 10:35:55 Re: git URL-update yields double trees
Rob Maris (GERMANY)
Message: 102547
The format-patch & am sequence looked good, so I tested it. Alas, it repeats the same merge conflicts as I encountered earlier upon merges of my own branch with updated upstream - this makes little sense. The same applies to using the rebase --onto method, or - as suggested above - rebasing the history of my own branches prior to put it onto the rewritten history.
Being coped with a rewritten history while I know that all commits of old and new history point to the same blobs is quite frustrating. In fact, rebase and friends are overkill, because rebase is intended to 'mount' commit chains to other points. Indeed, replaying all commits makes sense, in general - but not here.
A relatively new command (git-replace) pointed out to be the tool of choice, since it allows a sort of cut & paste like cutting in a DNA string and paste the cut part on an identical location elsewhere.
I've documented a sequence of steps on the same stackoverflow page as referenced in my former post above.
In general I'd suggest to split the whole public repository so that (new) users would only clone more recent history and also have the opportunity to fetch the old history upon desire and chain both repos together using replace assignments.
Despite frustrating experience ("never rewrite a published history"), the deeper digging into git makes once more clear that git *is* awesome (compared to other DVCSes), however.
QuoteReplyEditDelete
2011-07-20 11:34:49 Re: git URL-update yields double trees
Mike Frysinger (UNITED STATES)
Message: 102549
if you're going to do it by hand, then `git cherry-pick` would probably help. if you only have a handful of commits, that might be faster anyways.
the public repo has already been split. the /git/readonly-mirrors/linux.git/ is the old one and the /git/linux-kernel/ is the new one. neither has the history of the other.
QuoteReplyEditDelete
2011-07-20 11:49:27 Re: git URL-update yields double trees
Rob Maris (GERMANY)
Message: 102550
Regarding split public history: it's a misunderstanding. I meant split like this (quote): "We are moving from svn to git. Our svn repo is huge, and most of the history is useless. To save space, I would like to do a 50/50 split so that when the repo is cloned, 50% is seen by default, and the historical 50% can be seen by fetching the replacement history."
(from git.661346.n2.nabble.com/git-replace-and-pushing-td5769216.html)
I don't need it, just replied as to clarify things.
QuoteReplyEditDelete
2011-07-20 12:05:12 Re: git URL-update yields double trees
Mike Frysinger (UNITED STATES)
Message: 102551
ah, ok. in that case, i didnt feel like it was necessary to split the history as the git repo is (currently) less than 300MiB. that's a perfectly acceptable size imo.
QuoteReplyEditDelete
2011-07-21 04:24:53 Re: git URL-update yields double trees
Rob Maris (GERMANY)
Message: 102588
Of course, the size is not the problem, but if any history rewrites are still on any todo list, this could be a method to prevent SHA1-breaks in recent history, when old history (e.g. due to invalid email addresses), in short: cut in an appropriate place in the trunk path and set it a new root point via grafts. This does not affect SHA1's of subsequent commits from that point as long as no filter-branch is applied. Anybody interested in full history view could establish this via a git replace assignment at the new root point.
QuoteReplyEditDelete
2011-07-21 08:11:34 Re: git URL-update yields double trees
Mike Frysinger (UNITED STATES)
Message: 102593
since we've transitioned to git as our main repo now, there are no plans to ever rewrite the history. i'm not sure it's necessary as i purged most everything that was a problem in the past that i noticed.