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

["Łukasz Lew" <lukasz.lew@gmail.com>]

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

2008/12/15 Daniel Barkalow <barkalow@iabervon.org>:
> On Sun, 14 Dec 2008, Łukasz Lew wrote:
>
>> Hi Alexander,
>>
>> On Sun, Dec 14, 2008 at 17:06, Alexander Potashev <aspotashev@gmail.com> wrote:
>> > Hello, Łukasz!
>> >
>> > On 16:38 Sun 14 Dec     , Łukasz Lew wrote:
>> >> Thanks Nick, thats really helpful (and surprisingly simple).
>> >> I have a couple more questions:
>> >>
>> >> On Sun, Dec 14, 2008 at 15:55, Nick Andrew <nick@nick-andrew.net> wrote:
>> >> > On Sun, Dec 14, 2008 at 02:49:50PM +0100, Łukasz Lew wrote:
>> >> >> 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.
>> >>
>> >> >
>> >> > 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. :)

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

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

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

>
>        -Daniel
> *This .sig left intentionally blank*