On Jul 19, 8:29 pm, Roddie Grant <gitl...@myword.co.uk> wrote:
> My recent brush with a forgotten stash has led me to consider again an issue
> which I've never really got a complete answer to - how much information (if
> any) about a project should be kept outside Git.
> IOW do developers keep a note (on paper, spreadsheet, database?) of how
> branches inter-relate, their purpose and so on.
> An example: For a website I'm currently developing, the customer has asked
> me to make what is really a simple cosmetic change. I've done so on a branch
> called "cola_moss". But it could be several days or even weeks before the
> customer approves the change and the cola_moss branch can be merged with
> master. In the meantime, other development work continues on other branches.
> By the time I get back to the cola_moss branch I'll not remember what else
> was happening at the time it was created.
> I've found some very useful stuff on line about workflow, but it's all about
> how to use Git, not how to record the process.
> So do developers generally just use the information obtainable from Git
> itself or do they keep external notes too; and if so, what do they look
> like?

I, presonally, do not (yet) use any specific techniques for this, but
several possibilities of storing some meta-information with Git comes
to mind.

First, is the simple usage of "annotated tags" -- tags which contain
messages attached to them. For instance, having created your
"cola_moss" branch and finalized the changes made on it, you could tag
its tip with an annotated tag and write in the annotation why the
branch was created (what feature(s) does it implement/what bug(s) does
it fix) and so on. When the customer returns back to you with the
results of testing the branch, you could just do `git show that-tag`
and get the idea about what to do next.
You could employ the fact Git stores tags in subdirectories if they
contain slashes, so you could sensibly name such tags, like this, for
$ git tag -a pending/cola_moss
When you have dealt with the branch, you can also remove any tags
pertaining to it.

As a variation, in such a tag you could just record a URL of a ticket
in your project's tracker or of a wiki page describing the situation

Second, it's possible to "graft" a new empty tree onto an existing Git
repository, and by "empty tree" I mean "a tree which shares no history
with the rest of the repository" which differentiates it from "normal"
trees which are created by the means of "forking" existing trees. Such
a tree could be used to store any metadata in any format you like. In
the simplest form this could be just a text file with certain notes.
Creating such a tree looks a bit like voodoo but is in fact nothing
$ git symbolic-ref HEAD refs/heads/meta
$ rm *
$ rm .git/index
$ touch notes.txt
$ git add notes.txt
$ git commit -m "Create new `meta' branch"
$ git branch
* meta

Then, when you need to update any bit meta info about your repository,
you check out that "meta branch", update it, then switch back. In any
aspect, it behaves exactly as any other branch.
[1] contains more background info on such branches.

1. http://madduck.net/blog/2007.07.11:creating-a-git-branch-without-ancestry/

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-us...@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to