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

2008/12/17 Daniel Barkalow [off-list ref]:

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

quoted

Well, I am still a beginner in git. I just switched from mercurial.
Some inline follows:

2008/12/15 Daniel Barkalow [off-list ref]:

quoted

On Sun, 14 Dec 2008, Łukasz Lew wrote:

quoted

Hi Alexander,

On Sun, Dec 14, 2008 at 17:06, Alexander Potashev [off-list ref] wrote:

quoted

Hello, Łukasz!

On 16:38 Sun 14 Dec     , Łukasz Lew wrote:

quoted

Thanks Nick, thats really helpful (and surprisingly simple).
I have a couple more questions:

On Sun, Dec 14, 2008 at 15:55, Nick Andrew [off-list ref] wrote:

quoted

On Sun, Dec 14, 2008 at 02:49:50PM +0100, Łukasz Lew wrote:

quoted

I don't know how to make such a scenario work:
- two repositories: pub, priv
- priv is clone/branch of pub
- there is some constant developement both in pub and priv
- there are regular syncs with pub in priv

Problem:
Occasionally I want to push some changes from priv to pub.
Then after syncing with pub I want to get as few conflicts as possible.

Is it possible to do with git?

Git can do almost anything. One should instead ask "How to do this
with git?" :-)

So I've heard, but not yet experienced it myself. I'm thrilled to try.

quoted

If I understand your problem, you could solve it with git cherry-pick
and rebase. On priv, make a for-public branch from a pub branch. Then
cherry-pick the commits you want from your private branch into the
for-public branch.

That almost works. Can I somehow split existing commits just like in git-add -p?

It's, however, better to make more commits to not experience the need of
commit splitting.

Indeed good advice and best practice, but another best practice is to
not commit not compiling state.

In your private branches, it's actually good practice to commit all sorts
of junk. That way, when you mess up badly while trying to get it to
compile, you won't have lost your work. Of course, that means your commits
are going to need more cleanup before going public.

I started to follow your advise.
Then I rebase -i.
I found out I need more precise commit messages. :)

One useful strategy is to have a second shell and do "git show <hash>" to
figure out what you did in that misc commit.

Indeed!

quoted

quoted

quoted

My common scenario is that I code a big change in priv repository, and
after that I find that some of its parts can and should be moved to
pub.

I usually end up with my private branch containing the public branch, plus
a bunch of commits that introduce: bugs, later fixed; mixed improvements;
and debugging cruft. I want to generate nice commits that are individual
improvements. I generally do:
$ git checkout -b submit origin/master (the first time, to set it up)

$ git checkout submit
$ git diff submit mixed-work
look at it for good changes, find some in file1 and file2
$ git diff submit mixed-work -- file1 file2 | git apply

But with this command we do not preserve objects identity.
I.e: when you merge with mixed-work you have duplicate changes.
Is it ok?

Git is very good about recognizing duplicate changes in 3-way situations.
That is, merging two branches, each of which makes the same change (on a
hunk level) to a common ancestor. It'll identify this as "the branches
agree on a change" rather than "the branches conflict". Also, "rebase"
will try the 3-way merge mechanism, so it will be able to sort this out.

I found that already. And I have to say that I am delighted.
This is absolutely splendid.

The interesting case is when both branches have the same logical change,
but one of them is done better than the other. When you merge these,
you'll have to select the better one by hand in a conflict resolution.

quoted

quoted

Sometimes, clean up bits that aren't ideal
$ git add -i
Add the good parts
$ git checkout . (revert the working tree to the index)
$ make test (did I extract the change correctly?)
$ git commit
Write a good message, sign off, etc
$ git checkout mixed-work
$ git rebase -i submit

... Ah I see, we throw away old commits anyway with rebasing.

Yup. The old commits are there to save us when we make good changes and
undo them before getting to a finished state. Once we reach a finished
state, we intend to throw them away.

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.

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.

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?

The common case for edit, I think, is that things are mostly correct, but
there's a wrong change; with the change already committed, it's easy to
change it to what it should be and "git commit -a --amend".

       -Daniel
*This .sig left intentionally blank*