git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Santi Béjar" <sbejar@gmail.com>
To: "H.Merijn Brand" <h.m.brand@xs4all.nl>
Cc: "Lars Noschinski" <lars-2008-1@usenet.noschinski.de>,
	git@vger.kernel.org
Subject: Re: Feature suggestion: git-hist
Date: Wed, 30 Jul 2008 17:18:59 +0200	[thread overview]
Message-ID: <8aa486160807300818m108920a0pe4a5de47de8d838c@mail.gmail.com> (raw)
In-Reply-To: <20080730155835.71289eee@pc09.procura.nl>

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.

>  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

Santi

  parent reply	other threads:[~2008-07-30 15:20 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-30 11:38 Feature suggestion: git-hist H.Merijn Brand
2008-07-30 12:03 ` Pieter de Bie
2008-07-30 12:14   ` H.Merijn Brand
2008-07-30 13:33 ` Lars Noschinski
2008-07-30 13:58   ` H.Merijn Brand
2008-07-30 14:55     ` Miklos Vajna
2008-07-30 15:03       ` H.Merijn Brand
2008-07-30 15:23         ` Santi Béjar
2008-07-30 15:58           ` Avery Pennarun
2008-07-30 16:34             ` Lars Noschinski
2008-07-30 15:18     ` Santi Béjar [this message]
2008-07-30 15:29       ` H.Merijn Brand
     [not found]     ` <FA2D570A-B2B1-4994-AA6A-9C0C55E69900@silverinsanity.com>
2008-07-30 16:26       ` Merging submodules (was Re: Feature suggestion: git-hist) H.Merijn Brand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8aa486160807300818m108920a0pe4a5de47de8d838c@mail.gmail.com \
    --to=sbejar@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=h.m.brand@xs4all.nl \
    --cc=lars-2008-1@usenet.noschinski.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).