Git fork removal?

Git fork removal?

[Daniel Barkalow]

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*

Re: Git fork removal?

[Petr Baudis]

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

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.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: Git fork removal?

[Daniel Barkalow]

On Thu, 28 Apr 2005, Petr Baudis wrote:

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

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.

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

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

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

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*

Re: Git fork removal?

[Petr Baudis]

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...
> > If this breaks your workflow, could you please describe it? Perhaps we
> > could find a good semantics to support both.
> 
> 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.

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.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: Git fork removal?

[Daniel Barkalow]

On Thu, 28 Apr 2005, Petr Baudis wrote:

> 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...
>
> > 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.
> 
> Just do cg-pull barkalow, to get the latest changes from that repository
> (perhaps clone should inherit branches information?).

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.

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

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.

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

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*