Well, I am still a beginner in git. I just switched from mercurial.Some inline follows:
2008/12/15 Daniel Barkalow <barkalow@xxxxxxxxxxxx>:> On Sun, 14 Dec 2008, Łukasz Lew wrote:>>> Hi Alexander,>>>> On Sun, Dec 14, 2008 at 17:06, Alexander Potashev <aspotashev@xxxxxxxxx> 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@xxxxxxxxxxxxxxx> 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 copythe changelists like cherry-pick.Then we could use rebase -i (with edit) instead of apply.
PSWhy after edit in rebase -i the change is already commited? I alwayshave to reset;add -i
>> -Daniel> *This .sig left intentionally blank*˙ôčş{.nÇ+?ˇ?Ž??+%?Ë˙ąéÝśĽ?w˙ş{.nÇ+?ˇ ?ßâ?Ř^n?rĄöŚzË?ëh?¨čÚ&ŁűŕzżäzšŢ?ú+?Ę+zfŁ˘ˇh??§~??Űi˙˙ď?ę˙?ęçz_čŽćj:+v?¨ţ)ߣřm
