Dear Open Hub Users,
We’re excited to announce that we will be moving the Open Hub Forum to
https://community.blackduck.com/s/black-duck-open-hub.
Beginning immediately, users can head over,
register,
get technical help and discuss issue pertinent to the Open Hub. Registered users can also subscribe to Open Hub announcements here.
On May 1, 2020, we will be freezing https://www.openhub.net/forums and users will not be able to create new discussions. If you have any questions and concerns, please email us at
[email protected]
The GIT download of source code history for QGit, git GUI in Qt, failed with the following error:
Step 3 of 3: Counting lines of source code (Failed)
I have checked that qgit repository doesn't use submodules. What happened?
The server that this particular job was running on had some trouble. I've rescheduled the job, and don't expect any more problems.
Thanks,
Robin
Thanks a lot. Downloading source code for QGit succeded. I have also added qgit4 (port to Qt 4 where most of new work occur) repository succesfully.
By the way, at least for Git and Monotone commits are uniquely identified. So if there are two repositories which have some common history, that common part of history can be detected. I think the simplest way is to create common repository, which would have all repositories as alternates, and fetch from all repositories which would update refs (branch and tags information). So for Git we could avoid double counting of commits for more than one enlisted repository.
Hi Jakub,
Yes, we are storing the hashes for all commits and file versions in our database, with the intention that someday we'll be able to do some very interesting things with them... we could potentially bridge development histories between projects, and identify common files between projects.
Unfortunately, these types of things are probably a long ways off for us.
What I wanted to say was that you can do it now for (almost) free with Git, now. You can simply create repository which have all projects repositories as alternates, e.g. git --bare init
, put absolute paths to project repositories in $GIT_DIR/objects/info/alternates, then for each repository do git remote add
, then do git remote update
. As all objects are available via alternates mechanism, fetch (called by git remote update
) would only update refs (branches and tags info). Then you would have to track only this common repository, which would gather all the history, automatically collating it and removing duplicates.
Edit: This of course only reduces the problem of multiple repositories to the problem of multiple branches.
I have not tested this setup personally