7 messages, 3 authors, 2016-06-15 · open the first message on its own page
From: Francis Moreau <hidden>
Date: 2016-06-15 22:58:37
Hello, When rebasing a branch which contains commits with notes onto another branch it happens that some commits are already presents in the target branch. In that case git-rebase correctly drops those (already present) commits but it also drops the notes associated with them. Can the notes be transfered somehow in the target branch on the already present commits ? Thanks -- Francis
From: Jeff King <hidden>
Date: 2016-06-15 22:58:37
On Wed, Sep 04, 2013 at 09:51:26AM +0200, Francis Moreau wrote:
When rebasing a branch which contains commits with notes onto another branch it happens that some commits are already presents in the target branch. In that case git-rebase correctly drops those (already present) commits but it also drops the notes associated with them. Can the notes be transfered somehow in the target branch on the already present commits ?
Yes, see the notes.rewriteRef config option to enable this. -Peff
From: John Keeping <hidden>
Date: 2016-06-15 22:58:37
On Wed, Sep 04, 2013 at 03:53:10AM -0400, Jeff King wrote:
On Wed, Sep 04, 2013 at 09:51:26AM +0200, Francis Moreau wrote:quoted
When rebasing a branch which contains commits with notes onto another branch it happens that some commits are already presents in the target branch. In that case git-rebase correctly drops those (already present) commits but it also drops the notes associated with them. Can the notes be transfered somehow in the target branch on the already present commits ?Yes, see the notes.rewriteRef config option to enable this.
Does that actually work for this case? It sounds like Francis has the notes copying correctly when commits are rewritten but the notes are not copied anywhere if the commit becomes empty. I suspect it is difficult to do that in general as there is no clear way to know which commit those notes should be copied to.
From: Francis Moreau <hidden>
Date: 2016-06-15 22:58:37
On Wed, Sep 4, 2013 at 9:59 AM, John Keeping [off-list ref] wrote:
On Wed, Sep 04, 2013 at 03:53:10AM -0400, Jeff King wrote:quoted
On Wed, Sep 04, 2013 at 09:51:26AM +0200, Francis Moreau wrote:quoted
When rebasing a branch which contains commits with notes onto another branch it happens that some commits are already presents in the target branch. In that case git-rebase correctly drops those (already present) commits but it also drops the notes associated with them. Can the notes be transfered somehow in the target branch on the already present commits ?Yes, see the notes.rewriteRef config option to enable this.Does that actually work for this case? It sounds like Francis has the notes copying correctly when commits are rewritten but the notes are not copied anywhere if the commit becomes empty.
I don't think so: $ git config -l ... notes.rewriteref=refs/notes/* $ git notes show note 1 $ git checkout -b target master~1 Switched to a new branch 'target' $ git cherry-pick -x master [target 93740ff] commit 6 (cherry picked from commit 5dc90209d7c0195dd9d671c234c49c903b9e1b10) 1 file changed, 1 insertion(+) $ git rebase target master First, rewinding head to replay your work on top of it... $ git notes show error: No note found for object 93740ff96b37b2ed7aa0a78861c8beb87fdad474. Thanks -- Francis
From: Jeff King <hidden>
Date: 2016-06-15 22:58:37
On Wed, Sep 04, 2013 at 08:59:41AM +0100, John Keeping wrote:
On Wed, Sep 04, 2013 at 03:53:10AM -0400, Jeff King wrote:quoted
On Wed, Sep 04, 2013 at 09:51:26AM +0200, Francis Moreau wrote:quoted
When rebasing a branch which contains commits with notes onto another branch it happens that some commits are already presents in the target branch. In that case git-rebase correctly drops those (already present) commits but it also drops the notes associated with them. Can the notes be transfered somehow in the target branch on the already present commits ?Yes, see the notes.rewriteRef config option to enable this.Does that actually work for this case? It sounds like Francis has the notes copying correctly when commits are rewritten but the notes are not copied anywhere if the commit becomes empty.
Ah, I misunderstood. If we are dropping commits from the rebase because
their counterpart is already applied upstream, then no, there isn't an
automatic way to do this.
If the commits are dropped because a commit with the same patch-id
already exists upstream, you could match them up by patch-id and copy
the notes. Annoyingly, while we have things like "log --cherry-mark" to
show which commits are already present on each side, I do not think
there is a way to correlate them commit for commit. So I think you are
stuck doing something in the shell like:
patch_ids() {
git rev-list "$1" |
git diff-tree --stdin -p |
git patch-id |
sort
}
patch_ids $upstream..HEAD >us
patch_ids HEAD..$upstream >them
join us them |
cut -d' ' -f2-3 |
git notes copy --stdin
However, if the commit is dropped because we find while applying that it
becomes empty, there is not much we can do. It may have been obsoleted
by its counterpart patch that had a different patch-id, or it may even
have been obsoleted by unrelated patches. In the latter case, there is
nothing to copy to. In the former, you would have to trying to match up
the commit messages or similar to guess that the two commits correspond.
-Peff
From: Francis Moreau <hidden>
Date: 2016-06-15 22:58:37
On Wed, Sep 4, 2013 at 10:28 AM, Jeff King [off-list ref] wrote:
On Wed, Sep 04, 2013 at 08:59:41AM +0100, John Keeping wrote:quoted
On Wed, Sep 04, 2013 at 03:53:10AM -0400, Jeff King wrote:quoted
On Wed, Sep 04, 2013 at 09:51:26AM +0200, Francis Moreau wrote:quoted
When rebasing a branch which contains commits with notes onto another branch it happens that some commits are already presents in the target branch. In that case git-rebase correctly drops those (already present) commits but it also drops the notes associated with them. Can the notes be transfered somehow in the target branch on the already present commits ?Yes, see the notes.rewriteRef config option to enable this.Does that actually work for this case? It sounds like Francis has the notes copying correctly when commits are rewritten but the notes are not copied anywhere if the commit becomes empty.Ah, I misunderstood. If we are dropping commits from the rebase because their counterpart is already applied upstream, then no, there isn't an automatic way to do this. If the commits are dropped because a commit with the same patch-id already exists upstream, you could match them up by patch-id and copy the notes. Annoyingly, while we have things like "log --cherry-mark" to show which commits are already present on each side, I do not think there is a way to correlate them commit for commit. So I think you are stuck doing something in the shell like: patch_ids() { git rev-list "$1" | git diff-tree --stdin -p | git patch-id | sort } patch_ids $upstream..HEAD >us patch_ids HEAD..$upstream >them join us them | cut -d' ' -f2-3 | git notes copy --stdin However, if the commit is dropped because we find while applying that it becomes empty, there is not much we can do. It may have been obsoleted by its counterpart patch that had a different patch-id, or it may even have been obsoleted by unrelated patches. In the latter case, there is nothing to copy to. In the former, you would have to trying to match up the commit messages or similar to guess that the two commits correspond.
Can't git-rebase at least handle the case where a patch and its counterpart have the same patch-id ? Also maybe git-rebase should warn when dropping a commit having a note to tell the user that the note is dropped too. -- Francis
From: Jeff King <hidden>
Date: 2016-06-15 22:58:37
On Wed, Sep 04, 2013 at 10:47:22AM +0200, Francis Moreau wrote:
quoted
However, if the commit is dropped because we find while applying that it becomes empty, there is not much we can do. It may have been obsoleted by its counterpart patch that had a different patch-id, or it may even have been obsoleted by unrelated patches. In the latter case, there is nothing to copy to. In the former, you would have to trying to match up the commit messages or similar to guess that the two commits correspond.Can't git-rebase at least handle the case where a patch and its counterpart have the same patch-id ?
Certainly it could. My point was only that it doesn't currently (and it does not even know what the counterpart is, only that there is one).
Also maybe git-rebase should warn when dropping a commit having a note to tell the user that the note is dropped too.
That might end up annoying, depending on what you use notes for. But I think if it were restricted to notes that would be rewritten via notes.rewriteRef, it probably makes sense. Patches welcome. -Peff