Re: unseeking?

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Apr 25, 2005, 17:27 UTC
Message-ID: <Pine.LNX.4.21.0504251236400.30848-100000@iabervon.org>
In-Reply-To: <20050425161854.GE11094@tumblerings.org>

On Mon, 25 Apr 2005, Zack Brown wrote:

Show 24 quoted lines

> Hi,
> 
> Thanks for all the help!
> 
> On Sun, Apr 24, 2005 at 06:10:42PM -0400, Daniel Barkalow wrote:
> > > but I still don't see its significance. What do you get from a fork that
> > > you don't get from a regular old init and pull?
> > 
> > Primarily, the ability to inspect and build the mainline tree. If you want
> > to take a look at what's going on in the mainline without getting it again
> > or messing with your working directory or local commits, you can do that. 
> 
> OK, I think I understand this so far. So, suppose I want to contribute to
> cogito. I would first do a git init on Pasky's cogito tree, to get it on my home
> system. This would be my home base, and whenever I wanted to do some work on the
> current state of his tree, I would fork off another branch.
> 
> So, I want to do this. From inside cogito's root directory, I give the command
> 
> git fork mycogito ../mycogito
> 
> and ../mycogito is created. In this new directory, the .git directory
> contains only symlinks to ../cogito/HEAD, ../cogito/heads, ../cogito/objects,
> ../cogito/remotes, and ../cogito/tags, and an index file.

If you look carefully, ../cogito/.git/heads contains several files, one of which is "mycogito", and the symlink in mycogito/.git/HEAD is to that one, while the one in cogito/.git/HEAD is to a different one. So, while HEAD points to a file in a shared directory, each fork points to a different file.

> Question: when I make changes to mycogito and commit them, is only the index
> file in .git/ altered, or are my changes reflected in the cogito/ directory as
> well? If I do another fork of cogito, will I see mycogito's changes in the new
> fork?

The changes affect only the "mycogito" head, not the original head. On the other hand, the files generated by the commit are accessible from the original directory, so you can diff between your new head and the original or mainline successors of it.

Show 17 quoted lines

> So moving on, I now have this mycogito tree. But I don't do any edits yet. I
> just poke around for awhile, reading files. Finally I realize that there have
> probably been updates to the upstream sources, and I want to pull those in
> before I start my work. So, as I would do in the cogito directory, I give the
> command
> 
> git pull pasky; git pull linus
> 
> this works fine. There are no new updates to be had, and git tells me my tree is
> uptodate.
> 
> so now I start work. I run aspell on the README file, and it catches some
> typos.  I fix them and save the file but don't yet commit it. Now mycogito
> has some changes that I would ultimately like to push up to Pasky.
> 
> Now I'm unclear what comes next. Do I just do a 'git diff' from the mycogito
> directory and post the results to the git list?

Now you commit in your directory. This gives you a new head for mycogito. You can then do "git patch pasky" (or something of the sort, check the help for the details) to get a patch for the your changes. You can also do multiple commits and generate either a single patch or patches corresponding to each commit.

Show 6 quoted lines

> Suppose I want to keep working, changing more stuff in mycogito, but I
> also want to make sure that mycogito tracks the upstream sources.
> 
> git merge pasky; git merge linus
> 
> and give that command to bring the upstream changes into mycogito?

In general, you want to use "merge" when you've got local commits. You also want to commit before doing this, so that you have a known state for your version to revert to if you mess up merging.

	-Daniel
*This .sig left intentionally blank*