Thanks for the tip. It should give me a good starting point for what
I'm about to do, since notes seem to be able to add comments for
objects without changing the commit tree (which was one of the things
I was aiming for and quite frankly, one of the parts that worried me
on the implementation side).
However, what I want to implement has a few differences:
a) the flags I'm proposing form a limited set of strings, as I'm
interested in finding which files have a particular flag (I did
mention the idea to add comment as well when adding a certain flag,
but that was something extra, since most of the searching/listing was
around the set of flags of a certain file, not around the comment
itself... I can cook up some more usage and output examples if anyone
thinks it can clear things up). I realize this can be achieved by
using a sound naming convention (and a simple grep for a particular
prefix when listing all notes would handle the search by flag I
mentioned) - unfortunately, some other differences don't seem to be
covered as you'll see below
b) I would like to have all subsequent versions of a file to
inherit the flags/tags of the original file, until specified
otherwise; in the original idea that a 'feature tag' (or 'flag' as I
keep calling them lately - seems a better name that 'feature tag')
remains on the file until someone decides that feature is no longer
implemented in the file (for example, a file implements a certain
technique since version 3 until version 15, when the implementation of
a particular method changed entirely). Unfortunately, what seems to be
a good choice to preserve a state of a file until not needed are
branches, but then I would need to have the same version of the file
on different branches (a file can have multiple flags after all, since
multiple features are usually implemented in a file)
Anyway, I just wanted to point out that the notes you suggested are
not quite what I was looking for, but it should be a good
implementation starting point, so again, lots of thanks.
Catalin Pol
On Thu, Aug 23, 2012 at 6:16 PM, Hilco Wijbenga
<hilco.wijbe...@gmail.com> wrote:
> On 23 August 2012 08:10, Catalin Pol <catalin....@gmail.com> wrote:
>> Hi everyone,
>>
>> This is my first email to this mailing list, so this may be somehow
>> too straight forward... the idea is that I was thinking to develop a
>> new feature in Git (although I'm kind of new to git myself).
>> I wrote a small description of what I intend to do and I figured I
>> could use some pointers (how I can improve it, any possible usage
>> scenarios you can think for it and so on). Details are available at
>> the gist link below or as attachment to this email (I zipped the text
>> file since it was more it is larger than 10k and I didn't want it to
>> get rejected by the email server... although it still might)
>>
>> gist link: https://gist.github.com/3437530
>>
>> I made the gist public, so feel free to edit it directly... or, if you
>> prefer, just email me with any comments. I'm opened to any suggestion,
>> so feel free to send me any kind of comment (maybe I'm trying to
>> implement something that is already in git for example, and since I'm
>> a bit of a newbie in the git world, I didn't notice any way to obtain
>> my desired workflow).
>>
>> Thanks in advance for any feedback,
>
> Have you looked at "git notes"?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
