Re: unseeking?

From: Zack Brown <zbrown@tumblerings.org>
Date: Apr 24, 2005, 21:38 UTC
Message-ID: <20050424213841.GD11094@tumblerings.org>
In-Reply-To: <Pine.LNX.4.21.0504241418190.30848-100000@iabervon.org>

On Sun, Apr 24, 2005 at 02:47:30PM -0400, Daniel Barkalow wrote:

Show 7 quoted lines

> On Sun, 24 Apr 2005, Zack Brown wrote:
> > 4) In normal work-flow, when would forks be created, as opposed to other ways
> > of getting a tree?
> 
> I have a tree that I want to modify, but I want to keep the original, and
> I may want to update the original from an upstream source (and then sync
> my work with it).

So why not just do 'git init URL' to get the upstream sources, make your edits, do 'git pull' to track the upstream sources every once in awhile, and do 'git diff' when you're ready to send your changes to the upstream maintainer.

I think I've understood your explanation of what's actually happening, 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?

Be well, Zack

Show 48 quoted lines

> I start with the original:
> 
>   cd original
>   git init URL
>   git addremote remote-source URL
>   git track remote-source
> 
> I make my own working directory:
> 
>   git fork my-changes ../my-changes
>   cd ../my-changes
> 
> Then I do my changes, and commit whenever I feel like I've gotten
> somewhere (or when I think I'm about to mess something up and might want
> to undo changes). Periodically, I check on the mainline:
> 
>   cd ../original
>   git pull
> 
> I also merge changes from the mainline:
> 
>   cd ../my-changes
>   git merge remote-source
> 
> When I'm done, I make a patch for my work:
> 
>   cd ../my-changes
>   git patch remote-source
> 
> I generally then fork the original again, split the patch, apply each
> section in the new fork, committing after each one, generate patches for
> each of these commits, and send those out. Then I discard my old branch
> and continue from the new one. If, at some point, all of the changes I
> want to keep have been put into the mainline, I discard all my branches
> and fork again from the mainline.
> 
> (My personal style is to discard the history of how the changes got made
> in favor of the history of how the changes got into the mainline, since I
> don't really need to keep all of my debugged mistakes that nobody else
> saw.)
> 
> 	-Daniel
> *This .sig left intentionally blank*
> 
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Zack Brown