Re: How to maintain private/secret/confidential branch.

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Dec 18, 2008, 08:03 UTC
Message-ID: <alpine.LNX.1.00.0812180236190.19665@iabervon.org>
In-Reply-To: <c55009e70812171431l7eab33b2x28c5b4360118880b@mail.gmail.com>

On Wed, 17 Dec 2008, Łukasz Lew wrote:

Show 45 quoted lines

> >> > Often, resolve easy conflicts where my mixed-work branch introduced bugs
> >> > that I fixed later and have now adopted the fixed code
> >> >
> >> > Then I repeat until I don't have any more good changes in mixed-work
> >> > (either I have nothing, only debugging cruft, or only stuff I haven't
> >> > gotten to work yet). If there's nothing but cruft, I've fully merged the
> >> > topic, and I delete the branch.
> >> >
> >> > Eventually, I'm satisfied with what I've cleaned up, and I do:
> >> > $ git push origin submit:master
> >> >
> >> > Also, I generally have a bunch of "mixed-work" branches, each containing
> >> > different stuff that isn't ready. I'll periodicly go through all of them
> >> > and rebase onto "submit" or "origin/master" (or, sometimes, give up on
> >> > them and delete them).
> >> >
> >> > (One thing that would be nice to have is a "git apply --interactive" which
> >> > applies the user's choice of hunks, like "git add -i" adds them)
> >>
> >> I totally agree.
> >>
> >> I would appriciate rebase --copy option, which doesn't move, but copy
> >> the changelists like cherry-pick.
> >
> > There's work in progress on a generalization of "rebase -i" that could be
> > seeded with the "cherry-pick" operations instead of the "rebase"
> > operations. I think that's what you'd like.
> 
> I always wanted to have system that would allow me manipulation of
> patches as features.
> I.e: I have one patch for feature X, one for Y, one for debugging X,
> one for debugging Y, etc.
> Then I would just pick some of them, work with them to create new ones.
> 
> The basic operations would be use/unuse patch, combine sequence of
> patches into one (with commit messages of subpatches saved somewhere),
> uncombine patch into sequence of patches.
> Easy way of spliting atomic patch (diff) into several more so I can
> add more commit messages.
> 
> Now this would resemble directory structure, I could copy/move/remove
> patches from/to various bigger packs of patches. Merging would detect
> duplicates of course.
> 
> Git took me for the first time close to this ideal.

Git works from the point of view of a developer producing the ideal development history that doesn;t (necessarily) include false starts, bugs fixed in private, and changes mixed together. Or rather, git allows a developer to make commits again knowing the full outcome of the series.

It also works from the point of view of a maintainer who merges or does not merge the output of developers working in this mode.

It doesn't really quite handle the work of an integrator whose work is to manage a patch queue. I think it needs some additional tools which allow the user do work which consists of operations like "replace this patch/branch with a new version", "suppress this patch/branch", "reorder these patches/branches", and the main thing: "produce a version of my current series with conflict resolutions"

This would actually be really helpful to have explicitly represented, so that people could actually bisect the -mm series to find the operation that Andrew did that caused a problem to enter the series, which would be something like adding a patch that doesn't work with other patches in the series. Note that this is different from bisecting within the failing state of the -mm tree, which finds where the series seen as a difference from mainline, fails; if you know that -mm yesterday works and -mm today fails, the difference might be that a branch merged early in the series was updated to a version incompatible with a branch later in the series that hasn't changed, and you'd want to finger the update rather than the point in the series where kernels start failing.

Show 6 quoted lines

> > On the other hand, remember
> > that you can just make a new branch based on your endpoint and rebase it
> > on your upstream; there's no reason that you can't "unzip" the history
> > past the point where the branch you're modifying was created.
> 
> I never thought about that. It works indeed.

There's a lot you can do when branches are as cheap and flexible as git's branches are.

Show 14 quoted lines

> >> Then we could use rebase -i (with edit) instead of apply.
> >>
> >> PS
> >> Why after edit in rebase -i the change is already commited? I always
> >> have to reset;add -i
> >
> > There's (currently) no equivalent of the index (storing the contents of
> > the commit in progress) for the message (and author info, etc). On the
> > other hand, you can use "git commit --amend" to alter the commit on top
> > (including the files), and you can do "git diff HEAD HEAD^ | git apply" to
> > get reverts into your worktree that you can add (or not add).
> 
> Good idea, thanks.
> BTW is it diff | apply the same as revert --no-commit?

Largely, although you can give the diff/apply pair paths you want to revert, and not revert the whole thing. And the second commit can be anything with the diff/apply pair, not just HEAD^, which is what revert does, so it's a worthwhile generalization to understand.

	-Daniel
*This .sig left intentionally blank*