[git-users] Re: Moving commits from one branch to another (or: My hassles with git-rebase)

2013-01-23 Thread Stefan Schulze
Hi,

just for the records:
John Keeping at g...@vger.kernel.org finally gave me the commands I was 
looking for:

> git rebase --onto svn pushedToSvn master^0
assembles the complete (pushedToSvn..master onto the commits at the 
svn-branch) history detached and
> git checkout -B svn HEAD
moved this to the svn-branch

-- 




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-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

--