On 24/01/07, Yann Dirson <ydirson@xxxxxxxxxx> wrote:
On Tue, Jan 23, 2007 at 10:03:26PM +0000, Catalin Marinas wrote: > >I'll have to think more about that - I'm not sure I get you point. By > >moving/cloning we keep (or could keep) the patches' history. By > >importing we cannot do that. > > The 'pick' command could be (easily) fixed to preserve the history of > a patch (I'll add this to the todo list). The log commit would have > the picked patch's log as a parent rather than none. Right - "branch --clone" could also use that (or maybe it does already by design). Together with this, "pick --fold" and possibly "sync" (although I never used the latter so I'm not 100% sure how it works) could register a merge, and sometime in the future we could use this information to be able to do some merging. I'm not going to look into this soon, but I have this popping out regularly in my head ;)
'sync' is still experimental. I usually have the same patches on different branches (i.e. a stable kernel branch for customers and a more up-to-date branch for pushing patches upstream). I wanted a way to automatically synchronise the changes made to some patches found in both branches. This command folds the remote patch onto the current one using a three-way merge. If they are identical, the current patch shouldn't change. If they are not identical, it leads to conflicts that have to be manually solved.
> As I said, I'll first like to get a 1.0 out this spring. Yes. Maybe we should get 0.12 out of the door soon, with some more bugs fixed. I'm trying to finish putting out in a decent shape stuff about parent branches, git-fetch use and the other related issues mentionned those last days. Maybe that will be ready before enough bugs are squashed for 0.12, but maybe not :)
Maybe I'll manage to get a new release out in about a week or so. -- Catalin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html