On Sun, Feb 14, 2010 at 03:16:50AM -0600, Jonathan Nieder wrote:
> I don't understand.
>
> Part of my confusion is that what you are talking about is creating
> history, but gitk is mostly a tool for viewing history. So I am
> trying to imagine what series of commands created the history you are
> talking about and failing.
I think they're mostly created using git cvsimport, which seems
to be doing something else and makes it show up as a merge. I can't
currently show you a cvs repo which has that problem, nor do
I have a copy left of that. I tried to re-import it but it
cvsps seems to have a problem with the repo.
> The setup is presumably as before:
>
> test_commit() {
> : > "$1"
> git add "$1"
> git commit -m "$1"
> git tag "$1"
> }
> git init test-repo
> cd test-repo
> test_commit A
> git checkout -b devel
> for i in E F G H I J; do test_commit "$i"; done
> git checkout -b stable A
> for i in B C D; do test_commit "$i"; done
>
> I am on the stable branch, and I cherry-pick the bug fix F:
>
> git cherry-pick -x F
>
> Next I want to cherry-pick H. Why? H is a bug fix for G, so I guess
> I wanted G as well.
>
> git cherry-pick -x G
> git cherry-pick -x H
So to keep with my example, H was a bugfix for F, so you would:
git cherry-pick -x F
git cherry-pick -x H
But that's clearly not the behaviour I was seeing, and that looks
obvious what the history is. It also does not indicate any "merge".
Kurt
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: http://lists.debian.org/[email protected]