Re: Feature suggestion: git-hist

["H.Merijn Brand" <h.m.brand@xs4all.nl>]

On Wed, 30 Jul 2008 17:18:59 +0200, "Santi Béjar" <sbejar@gmail.com>
wrote:

> On Wed, Jul 30, 2008 at 15:58, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
> > On Wed, 30 Jul 2008 15:33:34 +0200, Lars Noschinski
> > <lars-2008-1@usenet.noschinski.de> wrote:
> >
> >> * H.Merijn Brand <h.m.brand@xs4all.nl> [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/