Git fork removal?

I saw that "fork" was removed when going to the cg- scripts, and the replacements don't do the symlinked trees thing. I found the symlinked trees thing vital to my workflow, so I'm going to want to reintroduce them, or something similar. Is there some reason you went to hardlinked object files instead of symlinked directories?

	-Daniel
*This .sig left intentionally blank*

Dear diary, on Thu, Apr 28, 2005 at 03:31:18AM CEST, I got a letter where Daniel Barkalow <barkalow@iabervon.org> told me that...

The user. ;-)

Apparently, too many people were confused by the local/remote branches distinctions, and even I ceased to like it gradually (BTW, Cogito still supports working with them - it just does not offer any interface for manipulation with them). The current scheme is much simpler and I believe more clear.

Also, the forked repositories were not truly independent - people actually got burnt by forking and then removing the original repository.

If this breaks your workflow, could you please describe it? Perhaps we could find a good semantics to support both.

On Thu, 28 Apr 2005, Petr Baudis wrote:

I don't really like having local branches and remote repositories be treated the same. But I like each of them being available concepts separately.

Ah, okay. I'm actually personally using a original repository called "REPOSITORY" without a head or anything, with symlinks to that, so I don't worry about accidentally killing the real thing from some branch. I've really got a storage area per project, plus a set of links and tracking stuff for each fork. I also back up the REPOSITORY on occasion, particularly if I'm about to do something potentially destructive to the database (like git-prune-script or convert-cache). I structure my filesystem like:

  /working
    ... other projects
    /git
      /REPOSITORY (with only .git, non-symlink version)
      /linus
      /pasky
      /barkalow
      /cog-barkalow
      /diff
      ...

The part that I'm worried about is the way I turn a mass of debugging and little local commits into a clean patch series. I've got a working fork "barkalow", which is the result of a bunch of stuff and a dozen commits. It is derived from "linus". I want to split up the changes and make a series of commits, each of which will be a patch to submit.

1) I fork "linus" into "for-linus". I go into "for-linus".

2) I do "git diff this:barkalow > patch". This gives me the complete set
   of changes I want to submit.

3) I cut down the diff to a single logical change by removing all of the
   other hunks.

4) I do "git apply < patch". I do "git commit". I describe the logical
   change.

5) I go back to step 2, unless I'm done.

6) For each of the commits between "linus" and "for-linus", I do 
   "git patch <commit>", and send out the result.

The thing that I think requires the symlinks is step 2, which requires that there be somewhere I can run git and have it able to see a pair of unrelated local heads and the relevant trees.

	-Daniel
*This .sig left intentionally blank*

Dear diary, on Thu, Apr 28, 2005 at 04:47:24AM CEST, I got a letter where Daniel Barkalow <barkalow@iabervon.org> told me that...

Just do cg-pull barkalow, to get the latest changes from that repository (perhaps clone should inherit branches information?).

But if you want Linus to pull from your tree, you generally want it to be clean - that is, you want to manage clean separation (as Pavel Machek describes in his document). That is another advantage of hardlinking - you don't get any unrelated stuff in if you don't explicitly pull it, so you can keep your for-linus branch clean. I'd do cg-diff linus:this in the barkalow branch instead to keep this property.

On Thu, 28 Apr 2005, Petr Baudis wrote:

You can pull from local repositories? I think that having the same concept for remote repositories and for different lines of local development is what confuses users.

I'll be using rpush and he'd have to use http-pull (I don't have rsync set up); both of these only transfer the reachable objects, so cleanliness isn't an issue.

But that doesn't work; when I'm preparing the second patch in the series, I want to compare linus+patch 1 against barkalow, so that I'm looking at what's left to split. That's why I need to have the unrelated heads, not just the linus head and my head based on it. If I go back to linus each time, it's more work making the patches and I don't have an easy way of telling whether I've included the same part twice or missed a part.

	-Daniel
*This .sig left intentionally blank*