On Thu, 6 Nov 2008, Francis Galiegue wrote: > Le Thursday 06 November 2008 04:08:16 Jakub Narebski, vous avez écrit : > Hello, > [...] > > > > > > * 52 CVS modules, fine; but then this can become one and 52 > > > subdirectories in them and still act as separate modules from > > > the build system point of view (which I have implemented, so > > > I can change it); > > > > I think that those CVS modules should become separate repositories, > > perhaps joined together using submodules. This is one of more > > difficult things during conversion. > > > > Note that in Git commits are always whole tree (whole project) > > commits. > > > > Honestly, I'm not fond of this approach. The problem with submodules as far as > I'm concerned is that documentation is "not really there", and (unless the > README of egit is _really_ outdated) that there's no support in egit. > > I know about commits affecting the whole tree, and even branches and tags, and > that's more of an advantage to my eyes, for two reasons: > > * 99+% of queries currently done on the CVS tree (with Bonsai) cover all > modules; only rarely is a single module concerned, and in this case you just > fill in the appropriate field in the search page anyway; Well, the mapping of CVS modules into Git repositories, and perhaps also later binding those Git repositories together using submodules support is IMHO one of more difficult decisions when deciding on migration from CVS to Git. What you would have to ask yourself is which of those CVS modules are independent, for example having independent version numbers (tags) and independent branches. And if commit really affects whole tree... > * creating a branch is one command and that's it. It may also be one command > with submodules, but again, the documentation makes me uncomfortable; with > CVS, well... You get the picture. Submodules are Git repositories of their own. So you have branching there (almost) as easy as otherwise in Git. The only problem is a bit lacking UI for binding those submodules together. > > What's more, I don't think we have the requirement of making specific > per-module tags. Not as far as this has been discussed so far, anyway, and > not as far as the history shows. Well, that is one issue that would help in mapping CVS modules to Git repositories (and submodules). > > > > * second: even though this may be a "non problem", we use Bonsai, > > > which has the ability to see what was commited by whom, given a time > > > interval (from d1 to d2): the base gitweb allows to search by > > > commiter, which is good, but it has no date boundaries: do tools > > > exist for git that can do this? If not, that wouldn't be a big deal, > > > however... > > > > First, there are more web interfaces than gitweb, see > > http://git.or.cz/gitweb/InterfacesFrontendsAndTools > > Yep, I've yet to try those... There are quite a few! > > > Second, you can do this from command line, using combination of commit > > limiting a..b and a...b, or --since=<date> or --after=<date> and > > --before=<date>, commit message searching --author, --committer, and > > --grep, and path limiting "git log -- <pathspec>". > > Well, a Web-based search engine is kind of a requirement. I'm the only one to > do command line... Thanks for the hints, though! You can also use one of GUI; qgit and gitk + git-gui seems to be quite mature and cross-platform. > > Third, it would be not that hard to add more advanced search support > > to gitweb; this is even one of planned features. I think there are two possible ways of doing it: have a kind of "advanced search" form, where one can have fill search terms, like date limit, path limiting etc; or have an option to limit search to current view context (for example current file or current directory). > Which brings back to the subject of submodules, since as I said above, we > generally search on the entire tree, and per-module searches are rare. Hmmm... > > > > * third: also Bonsai-related; Bonsai can link to Bugzilla by > > > matching (wild guess) /\b(?:#?)(\d+)\b/ and transforming this into > > > http://your.bugzilla.fqdn.here/show_bug.cgi?id=$1. Does gitweb have > > > this built-in? (haven't looked yet) Is this planned, or has it been > > > discussed and been considered not worth the hassle? > > > > This is (under name of 'committags') in gitweb TODO; gitweb-xmms2 > > support this IIRC or supported this (for Mantis and not Bugzilla > > though...) > > Interesting... I'll have a look at it. Well, now I have bumped priority of this item in my gitweb TODO list... -- Jakub Narebski Poland -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
