Re: The essential problems of moving from CVS

[Thomas Adam <thomas.adam22%gmail.com@localhost>]

On Sat, Jan 16, 2010 at 08:04:32PM +0000, David Holland wrote:
> On Sat, Jan 16, 2010 at 12:25:30PM +0900, Curt Sampson wrote:
>  > > For me at least it's not so much checkouts that's a problem as not
>  > > being able to selectively update or revert subtrees, particularly in
>  > > pkgsrc.
>  > 
>  > Well, from a git point of view, this simply doesn't make sense.
> 
> When someone needs to be able to do something, and they're told that
> what they want to do doesn't make sense in the model your tool
> provides, the obvious conclusion is that the tool is not suitable.

Or that there's other ways of doing the same thing.  As you're stating, your
concern with branches, is one such approach to this.  And as I have said
continually in other emails, using separate repositories, or submodules is
equally another option.  But just because there might not be as
direct-mapping between what $SOMEONE wants, and the tool providing it,
doesn't mean to say that the tool has to bend; equally $SOMEONE could also.
;)

>  > What you're saying when you do this is that you want only part of a
>  > commit, and parts of other commits. That means you want a modified
>  > working tree. You can generate a patch from a commit and then tweak
>  > it to add or remove only the bits you want, and then you're left
>  > with an appropriately modified working tree, I guess.
> 
> Yes, you can revert a subtree by patching. Then it's a local
> modification and you have to be very sure it doesn't get pushed back
> to the master repository. Which means you have to develop without it
> and then apply it on top of your real changes in a different branch.
> This means, among other things, that you need to commit every time you
> want to test anything. I've done this, it's a big hassle, it involves
> a lot of administrative overhead and if one takes a less involved
> approach it's extremely easy to slip up and accidentally merge and
> push the reversion.

The problem here is that the term "subtree" doesn't exist -- as far as Git
is concerned, it's still being tracked, there's not a lot separate about it.

> What I want is to be able to revert, or maybe just patch, a subtree in
> my working copy and have the SCM tool ignore that subtree (perhaps
> warn or error if it becomes modified) while I work elsewhere. And I
> suspect that I'm not the only person who wants this; with pkgsrc it's
> often necessary to revert one or two broken packages in order to be
> able to build something else that needs immediate updating.

OK -- so there's a few options here:

* The sparse checkout support that's going into Git might help, although I
  yet to look at the extent at which it can be used to do what you're
  describing.

* Again, as I think I mentioned elsewhere, make use of "git stash" to
  separate out your work-concerns as you look doing other things.

> (Updating a subtree is mostly interesting only because updating the
> whole tree is slow. However, that's a legitimate concern.)

Slow?

> The alternative to subtree support appears to be to make each pkgsrc
> package a separate repository, along the lines of the way X got split
> up, but that's a complete non-starter, especially for pkgsrc.

Yeah, well.  I most likely agree with this.

> Sure, you can commit subtrees. But if I commit sh, then commit sail,
> then commit sh again, I need to use branches to avoid having the sail
> commit depend on (and thus become inseparable from without a pile of
> additional hassle) the sh commit. Using branches is fairly cheap, but
> it's not free, it offers a lot of new ways to make mistakes, and it
> makes it harder to keep track of all the half-finished things you have
> in progress at once.

I don't think it will make your life harder.  I understand your concerns
here, it's certainly perceived to be an overhead; this sort of thing
happened a lot with my colleagues at work, but actually they've all said,
having used Git now for two years, that they really appreciate using
branches to manage their work -- as they know exactly what they were doing.

>  > > And another somewhat more tangentially related problem (that topgit
>  > > might also fix) is that you can't really keep local patches, like the
>  > > gross hack I need for the tulip ethernet in my test machine, in the
>  > > same tree that you use for development and commit.
>  > 
>  > Git actually excels at this sort of thing. Say 'master' is the main
>  > branch, and 'local' is the branch that contains your local patches.
>  > Here's the workflow.
>  > 
>  >     1. Switch to master branch and pull. Do any testing (compile or
>  >     whatever) you care to here.
>  > 
>  >     2. Switch to 'local' branch and rebase to master. This brings in all
>  >     of the new changes, and lets you merge your local patches if they
>  >     need merging.
> 
> ...or just merge with the master branch; there's no need for rebase.

Actually, it depends.  Both operations are completely valid, as it only
affects the history for the merged branch; albeit notwithstanding the
caveats with using rebase, but that doesn't apply here.

-- Thomas Adam

-- 
"It was the cruelest game I've ever played and it's played inside my head."
-- "Hush The Warmth", Gorky's Zygotic Mynci.