Re: [git-users] Storing extra files for release versions.

2013-01-23 Thread Dale R. Worley
> From: wor...@alum.mit.edu (Dale R. Worley)
> 
> I think you could get a similar effect by doing something like this:
> [...]
> 
> This leaves you with a tagged commit that is not on a branch and
> contains the derived files, whose parent is the commit containing
> exactly the source files.

You may want to have two tags, one tag being a commit on the master
branch that contains only the "source" files, and one tag for a commit
not on master, whose parent is the source commit, and contains the
"derived" files.  Because sometimes you want one set of files and
sometimes you want both sets of files.

Dale

-- 




Re: [git-users] Storing extra files for release versions.

2013-01-23 Thread Dale R. Worley
> From: Rahul Gupta 
> 
> This is probably a hangover from SVN habits but still I would like the Git 
> way doing this.
> 
> Normally using SVN, when I work on a latex file, I store the pdf generated 
> in my Tag folder along with latex file. There is no concept of Tag folder 
> in Git and while I want to store the PDF generated at each release-tag, I 
> do not want them in my project folders or to be tracked at all. What is the 
> best way of achieving this?

I think you could get a similar effect by doing something like this:

1. Create the commit that you want to tag.
2. Rebase onto the commit itself (so the following commit won't change
the master branch), using (I think) "git checkout [hash of HEAD]".
3. Insert the .pdf into the index:  "git add -f [whatever].pdf"
4. Create a new commit that contains the source files along with
whatever.pdf: "git commit".
5. Tag the new commit:  "git tag [tag-name] HEAD"
6. Get the working copy back to the master branch: "git checkout
master"

This leaves you with a tagged commit that is not on a branch and
contains the derived files, whose parent is the commit containing
exactly the source files.

I'm new at this, so those commands may not be quite right...

Dale

-- 




Re: [git-users] Storing extra files for release versions.

2013-01-22 Thread Konstantin Khomoutov
On Tue, Jan 22, 2013 at 10:14:12PM -0800, Rahul Gupta wrote:

> This is probably a hangover from SVN habits but still I would like the Git 
> way doing this.
> 
> Normally using SVN, when I work on a latex file, I store the pdf generated 
> in my Tag folder along with latex file. There is no concept of Tag folder 
> in Git and while I want to store the PDF generated at each release-tag, I 
> do not want them in my project folders or to be tracked at all. What is the 
> best way of achieving this?

Git is able to keep in its database any object at all provided there is
a reference to it so that it's not garbage-collected.  A reference is,
typically, a branch or a tag.

To do that, use something like

$ git tag your-file.pdf $(git hash-object -w your-file.pdf)

The `git hash-object` program calculates the SHA-1 hash over your file,
writes the file to the database ("-w") and prints that SHA-1 name to
stdout.  The `git tag` program accepts a tag name and the SHA-1 name of
an object the tag should reference and creates the tag.

After that, you are able to get the file "out of" your tag by doing

$ git show your-file.pdf >your-file.pdf
or
$ git cat-file blob your-file.pdf >your-file.pdf

-- 




[git-users] Storing extra files for release versions.

2013-01-22 Thread Rahul Gupta
Hi,

This is probably a hangover from SVN habits but still I would like the Git 
way doing this.

Normally using SVN, when I work on a latex file, I store the pdf generated 
in my Tag folder along with latex file. There is no concept of Tag folder 
in Git and while I want to store the PDF generated at each release-tag, I 
do not want them in my project folders or to be tracked at all. What is the 
best way of achieving this?

Cheers,
Rahul

--