Re: Feature suggestion: git-hist

On Wed, 30 Jul 2008 17:18:59 +0200, "Santi Béjar" [off-list ref]
wrote:

On Wed, Jul 30, 2008 at 15:58, H.Merijn Brand [off-list ref] wrote:

quoted

On Wed, 30 Jul 2008 15:33:34 +0200, Lars Noschinski
[off-list ref] wrote:

quoted

* H.Merijn Brand [off-list ref] [08-07-30 13:38]:

quoted

    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.

quoted

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.

quoted

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/