On Wed, 30 Jul 2008 17:18:59 +0200, "Santi Béjar" <sbejar@xxxxxxxxx> wrote: > On Wed, Jul 30, 2008 at 15:58, H.Merijn Brand <h.m.brand@xxxxxxxxx> wrote: > > On Wed, 30 Jul 2008 15:33:34 +0200, Lars Noschinski > > <lars-2008-1@xxxxxxxxxxxxxxxxxxxx> wrote: > > > >> * H.Merijn Brand <h.m.brand@xxxxxxxxx> [08-07-30 13:38]: > >> > >> > I can ask them what version they have, and I can then check if > >> > the complaint was already addressed in an update that was > >> > already released. In SCCS this was easy: they tell me the output > >> > of the what command, I check if the bug was fixed in a newer > >> > version and the answer is present. No such luck in git, as the > >> > stamps are (non-sequitive) SHA id's. As we moved to git, we now > >> > have to update those id's by hand, as the customers are used to > >> > it. (At least we can now use readable date formats) > >> > >> Hm, what about "git-describe --contains $SHA_OF_BUGFIX"? > > > > If you come from a SCCS environment, the developers are used to see the > > version of a single file, not of the id of a fix. One of the reasons we > > moved from SCCS to git, is that we now can commit a group of files as a > > single commit, and later look at the complete picture. > > > > We are not used to working with $SHA's, and IMHO from the end-user pov, > > a $SHA is less user friendly than a release number or a file version. I > > can remember a version, but I cannot remember a SHA. > > > > > The end user only has the application, which is (or at least should be) > > able to spit out its release version. > > As git itself does: > > $ git version > git version 1.6.0.rc1.11.g1ce47 > > I think it is far better to know the version of the entire project, > than the version of a single file. Yes. I agree. We us tags to `mark' the release, but with the repo's of a project (still) scattered around, it is far from ideal. And as to a single file: I mostly know (when I fixed something) in what file I fixed it, so the first thing I do is to check that file against the revision that the customer runs. > > That is all we can go by when we dig back into the history to see where > > we changed things. > > > > One (very) big disadvantage of SCCS is that commits are on a per-file > > basis, and only in a single directory. This drawback still haunts me in > > git, as my first attempts to convert were successful in a single folder > > and git cannot merge folders into a single project. > > > > Say I now have > > > > /work/src/project/.git > > /work/src/project/module_a/.git > > /work/src/project/module_b/.git > > /work/src/project/module_c/.git > > > > Which are all converted repos from SCCS, I'd like to merge the three > > module_# repos into the top level repo. > > You have, basically, two possibilities: > > 1) Add the module_# as submodules: > http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html > http://git.or.cz/gitwiki/GitSubmoduleTutorial > 2) Add the submodules as subtrees (as gitk and git-gui in git.git) > http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html Thanks, I'll start reading ... -- H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/ using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00, 11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ -- 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
