From: Łukasz Lew Date: Wed, 17 Dec 2008 19:57:35 GMT Subject: Re: How to maintain private/secret/confidential branch. Message-ID: In-Reply-To: Well, I am still a beginner in git. I just switched from mercurial. Some inline follows: 2008/12/15 Daniel Barkalow : > On Sun, 14 Dec 2008, Łukasz Lew wrote: > >> Hi Alexander, >> >> On Sun, Dec 14, 2008 at 17:06, Alexander Potashev 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 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*