From: William S F. <ws...@fu...> - 2012-12-30 17:37:10
|
On 30/12/12 16:48, Alexey Sokolov wrote: > 30.12.2012 21:38, William S Fulton пишет: >> There were some unreachable objects and I should have run >> $ git reflog expire --expire=now --all >> before the 'git gc' and git push to github but it doesn't seem to >> matter - the number of objects reported by 'git fsck' is the same >> after running the above line and what I got back from a github clone: >> $ git clone https://github.com/swig/source-temporary2.git >> >> However, I've given up trying to modify the old empty commit messages >> using 'git rebase -i' to rename empty commits. The interactive rebase >> is rather disappointing as it ends up having to re-resolve merge >> conflicts. I guess we shouldn't be rebasing the subversion commits in >> the future so this is not a big deal. >> > > Changing so old commits with hundreds of forks/merges after that (which > depend on that commit) won't work easily... Just leave it as is. > Yup, probably this is the only solution. I just wonder what will happen if we try to resurrect some of the code in older branches that has not been integrated into trunk... I think a problem for when/if it happens. >> I've used 'git fsck' with all the various options and it checks okay. >> However, 'git fsck --root' reports 4 root nodes, but am not sure if >> this is okay yet. Advice welcome... git is a whole order more complex >> than subversion and somewhat more frustrating to get to grips with. >> > > One of them belongs to a completely separated small branch named > "closed". Not sure what's that, but for me it looks like it can be > harmlessly dropped. See "git log closed". branches/closed is often used for svn repos for getting feature branches that have already been integrated into trunk out of the way by moving them into closed. I found it didn't work very well though as the svn log didn't deal well with the moved/renamed directories. Anyway, I'll delete the branches under closed. I think I'll also delete all the branches except for the ones that have not been integrated into trunk. One thing I don't really get is once a branch has been deleted in git, the history of the branch might be visible without a name but I thought having a name for a branch was useful. Something to get used to. > Other root nodes can't be > dealt with though, because everything else depend on them, as they are > at the very beginning of history... Usually repos have one root commit, > but having more than one doesn't really harm. Thanks. I found these multiple roots broke interactive rebase, but I suppose it only is a problem if you rebase going back far into the history. William |