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

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

quoted

quoted

quoted

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.

quoted

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.

quoted

quoted

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*