Re: git-cherry doesn't detect a "copied" commit
Hello Junio, On Sat, Oct 24, 2015 at 12:41 AM, Junio C Hamano <gits...@pobox.com> wrote: > Francis Moreau <francis.m...@gmail.com> writes: > >> I was mislead by the git-cherry manpage somehow which says: >> >> "git-cherry therefore >> detects when commits have been "copied" by means of git-cherry-pick(1), >> >> which is not exactly true. > > Yeah, I agree; the sentence is merely giving a description from > layperson's point of view, and it should have expressed it as such, > e.g. "roughly speaking, you can think of it like so", not sounding > as if it is giving a strictly correct and authoritative statement. > >> Would it make sense to add a "--fuzz" option which would reduce the >> diff context area used to generate the hash ? > > There could be situations where such fuzzing might be useful, but I > do not think this particular use case of yours is one of them. > > I'd imagine that you had two branches A (with "Unkown") and B (with > "Unknown"), and wanted to apply changes in them to your integration > branch (let's call that 'master'). You ask cherry "what commits in > A are missing in my 'master'?" and apply them. Next you ask cherry > "what commits in B are missing in my 'master' now?" and apply them. > > Because "Unkown" and "Unknown" are not considered the "same" patches > (one is most likely an update to the other), you get conflict when > applying the second copy, and that is how you can notice that one of > them is a stale and buggy one. If you haven't made your interim > integration result available to others after processing branch A, > you even have a chance to replace the "Unkown" one you already > applied with the corrected "Unknown" one before continuing. Even if > you choose not to bother and skip the "Unknown" one from branch B, > at least you know that in the end result you have a typo that would > eventually need to be fixed from "Unkown" into "Unknown". > > If you did a fuzzy version and ignored s/Unkown/Unknown/ typofix > between the "same" patches, you can avoid the conflict and all > patches from branch B may apply cleanly and automatically on top of > applying changes from branch A. But depending on the order you > processed A and B, you have a 50% chance of keeping the buggy > version without even realizing. > > So erring on the safe side and judging "Unkown" and "Unknown" are > different changes, inducing one extra conflict you had to look at, > is actively a good thing in this case. > In this case, ie where code modification happens, I agree that we should play in the safe side. But in my case I was more using git-cherry as a tool to help me compare my integration branch and the master one. I'm interested to know which commits have been picked up from upstream and which ones are specific to my branch. And when backporting (cherry-picking) commits from upstream, it's quite frequent that the context is slightly different. I think in this case and not the one you describe, such 'fuzz' option might make sense. Fuzzy match could be reported with a different tag, '~' for example. > One thing that helps to know while learning Git is that we try to > avoid being overly clever and outsmarting human users. Instead, we > err on the safe side to avoid silently doing a wrong thing. > > This is because a tool that automates 100% of cases with 2% chance > of producing wrong result cannot be trusted---you have to manually > inspect all 100% cases it automatically handled to make sure it did > the right thing. We instead automate 98% of simple cases where it > is obvious what the right result is, and ask the human user for help > on the remaining 2%. > > And this design principle is not limited to cherry. The design of > our merge algorithms is the same way, for example. I fully agree with this principle. Thanks -- Francis -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Question about about a trivial merge conflict that git should resolve alone
Hi, I have a simple merge conflict use case: $ mkdir foo $ cd foo/ $ git init $ echo line1 > a $ git add . $ git commit -q -m init $ echo line2 >>a $ git commit -a -q -m "add line2" $ git checkout -b foo HEAD~1 $ git cherry-pick -x master $ echo line3 >>a $ git stage a $ git commit -q -m "add line3" $ git checkout master $ git merge foo $ git diff diff --cc a index c0d0fb4,83db48f..000 --- a/a +++ b/a @@@ -1,2 -1,3 +1,6 @@@ line1 line2 ++<<< HEAD ++=== + line3 ++>>> foo Why does git think there's a conflict here since the "line2" string was added in both branch by the same commit ? Thanks. -- Francis -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-cherry doesn't detect a "copied" commit
On Fri, Oct 23, 2015 at 12:57 PM, Kevin Daudt <m...@ikke.info> wrote:
> On Tue, Oct 20, 2015 at 06:32:12PM +0200, Francis Moreau wrote:
>> Hi,
>>
>> I'm seeing something odd with git-cherry: it doesn't seem to detect
>> that a commit has been cherry-picked from master branch.
>>
>> This happens with the systemd git repository (from github) so it
>> should be fairly simple to reproduce.
>>
>> What I did:
>>
>> $ git --version
>> git version 2.6.0
>> $ git checkout -b foo v210
>> $ git cherry-pick -x 9ea28c55a2488e6cd4a44ac5786f12b71ad5bc9f
>> $ git branch --contains 9ea28c55a2488e6cd4a44ac5786f12b71ad5bc9f
>> master
>> $ git cherry master HEAD
>> + fef60bf34d1b372bea1db2515a8d936386dfc523
>>
>> so git-cherry tells me that the cherry-picked commit has not
>> equivalent in master, which is no the case.
>>
>> What am I missing ?
>>
>
> Let's see:
>
> $ git show | git patch-id
> 50c9f9548e1fd25401ff9540c82c1d5f9723c3d5
> b4c86d2965aaf0736e4ab30be1d1a08931009a08
>
> $ git show 9ea28c55a2488e6cd4a44ac5786f12b71ad5bc9f | git patch-id
> a5cfbb542882bd9cbe192b43026354d1f2741673
> 9ea28c55a2488e6cd4a44ac5786f12b71ad5bc9f
>
> Git patch-id calculates the hash over the diff, and, when gives in this
> case two hashes, first the patch-id and the second the commit hash.
>
> The patch-ids are different, explaining why git cherry does not see them
> as equivalent. If I take a diff of the diff, I notice something:
>
>diff --git a/src/udev/udevadm-settle.c b/src/udev/udevadm-settle.c
> -index 927ea2a..65fc35f 100644
> +index b026155..ea9b078 100644
>--- a/src/udev/udevadm-settle.c
>+++ b/src/udev/udevadm-settle.c
>@@ -41,42 +41,28 @@
> @@ -1094,7 +1094,7 @@
> exit(EXIT_SUCCESS);
>@@ -102,44 +85,13 @@ static int adm_settle(struct udev *udev, int argc,
> char *argv[])
> default:
> - assert_not_reached("Unknown argument");
> + assert_not_reached("Unkown argument");
> }
>+}
>
> If you look at the lines with assert_not_reached, it seems there is a
> difference in the context of both diffs, causing the diffs to be
> different.
>
> Hope this helps, Kevin
Thanks Kevin
I was mislead by the git-cherry manpage somehow which says:
"git-cherry therefore
detects when commits have been "copied" by means of git-cherry-pick(1),
which is not exactly true.
Isn't there a way to get git-cherry less "strict" ?
I mean in this case most of 90% of the diff is the same, only one line
of context is not identical...
Would it make sense to add a "--fuzz" option which would reduce the
diff context area used to generate the hash ?
Thanks.
--
Francis
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-cherry doesn't detect a "copied" commit
Hi, On Tue, Oct 20, 2015 at 6:32 PM, Francis Moreau <francis.m...@gmail.com> wrote: > Hi, > > I'm seeing something odd with git-cherry: it doesn't seem to detect > that a commit has been cherry-picked from master branch. > > This happens with the systemd git repository (from github) so it > should be fairly simple to reproduce. > > What I did: > > $ git --version > git version 2.6.0 > $ git checkout -b foo v210 > $ git cherry-pick -x 9ea28c55a2488e6cd4a44ac5786f12b71ad5bc9f > $ git branch --contains 9ea28c55a2488e6cd4a44ac5786f12b71ad5bc9f > master > $ git cherry master HEAD > + fef60bf34d1b372bea1db2515a8d936386dfc523 > > so git-cherry tells me that the cherry-picked commit has not > equivalent in master, which is no the case. > > What am I missing ? > Could anybody give me a hint even if I'm blind and not seeing my stupid mistake ? Thanks -- Francis -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git-cherry doesn't detect a "copied" commit
Hi, I'm seeing something odd with git-cherry: it doesn't seem to detect that a commit has been cherry-picked from master branch. This happens with the systemd git repository (from github) so it should be fairly simple to reproduce. What I did: $ git --version git version 2.6.0 $ git checkout -b foo v210 $ git cherry-pick -x 9ea28c55a2488e6cd4a44ac5786f12b71ad5bc9f $ git branch --contains 9ea28c55a2488e6cd4a44ac5786f12b71ad5bc9f master $ git cherry master HEAD + fef60bf34d1b372bea1db2515a8d936386dfc523 so git-cherry tells me that the cherry-picked commit has not equivalent in master, which is no the case. What am I missing ? Thanks -- Francis -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
How to handle false-positive with git-cherry ?
Hi, I have several "maintainance" branches which are based on different version of my software, which contains only fixes, imported with 'git cherry-pick'. I use to comparing stable branches to see if one of them is not missing a fix for instance. For that purpose I use "git cherry" of "git log --cherry". But sometimes git reports me some false-positives because one fix in a particular branch has been slighlty modified when cherry-picking it (because the context has slighly changed between 2 versions of my soft). Basically I'd like to force git-cherry to assume that the patch-id of a commit is the same as the one it's been cherry picked from even if the diff is not exactly the same. One way to do this would be forgit-cherry to use the string added by "git-cherry-pick -x": (cherry picked from commit xxx) and to handle the indirection in order to calculate the patch-id. I couldn't find something equivalent of this with git, but maybe I've missed an option... could anybody tell me if something similar already exist ? Thanks. -- Francis -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Possible bug with git-rebase and post-rewrite hook
Hi, I have a suspect case which happens when rebasing a branch. I'm using the post-rewrite hook and during certain circumstance, my hook is called by git-rebase with wrong parameters: old-sha1 argument is not related to new-sha1 one. This actually happens when git-rebase stops and reports: The previous cherry-pick is now empty, possibly due to conflict resolution. If you wish to commit it anyway, use: git commit --allow-empty Otherwise, please use 'git reset' rebase in progress; onto 2889531 You are currently rebasing branch 'foo' on '2889531'. If I decide to skip it by doing 'git rebase --continue' then I get the issue when my hook is run. BTW, I find that the message is not really clear since it tells me to run 'git-reset' in the case I want to ignore this empty commit. I'm not sure that 'git-reset' is really helping in that case (my index is clean) but 'git rebase --continue' would have been more appropriate IMHO. If I do 'git commit --allow-empty' then there's no issue when the hook is run. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible bug with git-rebase and post-rewrite hook
oops, I forgot to say that this happen with git 2.3.1. On 03/05/2015 02:55 PM, Francis Moreau wrote: Hi, I have a suspect case which happens when rebasing a branch. I'm using the post-rewrite hook and during certain circumstance, my hook is called by git-rebase with wrong parameters: old-sha1 argument is not related to new-sha1 one. This actually happens when git-rebase stops and reports: The previous cherry-pick is now empty, possibly due to conflict resolution. If you wish to commit it anyway, use: git commit --allow-empty Otherwise, please use 'git reset' rebase in progress; onto 2889531 You are currently rebasing branch 'foo' on '2889531'. If I decide to skip it by doing 'git rebase --continue' then I get the issue when my hook is run. BTW, I find that the message is not really clear since it tells me to run 'git-reset' in the case I want to ignore this empty commit. I'm not sure that 'git-reset' is really helping in that case (my index is clean) but 'git rebase --continue' would have been more appropriate IMHO. If I do 'git commit --allow-empty' then there's no issue when the hook is run. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-remote.txt: describe behavior without --tags and --no-tags
Hi, On 03/02/2015 02:08 PM, Michael J Gruber wrote: Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- Documentation/git-remote.txt | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt index a77607b..f3f6f0d 100644 --- a/Documentation/git-remote.txt +++ b/Documentation/git-remote.txt @@ -56,7 +56,10 @@ With `--tags` option, `git fetch name` imports every tag from the remote repository. + With `--no-tags` option, `git fetch name` does not import tags from the remote repository. ++ +By default, only tags on fetched branches are imported +(see linkgit:git-fetch[1]). + So the default is neither --no-tags nor --tags ? Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git-remote add: --no-tags/--tags which one is the default option
Hi, git remote add has --no-tags/--tags option, but I can't find in the man page which one is the default. Could anybody tell me the default option ? Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-log --cherry-pick gives different results when using tag or tag^{}
On 01/15/2014 10:49 AM, Jeff King wrote:
[+cc Junio, as the bug blames to him]
On Fri, Jan 10, 2014 at 02:15:40PM +0100, Francis Moreau wrote:
In mykernel repository, I'm having 2 different behaviours with git-log
but I don't understand why:
Doing:
$ git log --oneline --cherry-pick --left-right v3.4.71-1^{}...next
and
$ git log --oneline --cherry-pick --left-right v3.4.71-1...next
give something different (where v3.4.71-1 is a tag).
The command using ^{} looks the one that gives correct result I think.
Yeah, this looks like a bug. Here's a simple reproduction recipe:
Thanks a lot Jeff for your good analyze.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
git-log --cherry-pick gives different results when using tag or tag^{}
Hello,
In mykernel repository, I'm having 2 different behaviours with git-log
but I don't understand why:
Doing:
$ git log --oneline --cherry-pick --left-right v3.4.71-1^{}...next
and
$ git log --oneline --cherry-pick --left-right v3.4.71-1...next
give something different (where v3.4.71-1 is a tag).
The command using ^{} looks the one that gives correct result I think.
Could anybody enlight me ?
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
How to retrieve the rewritten list like the one made by git-rebase
Hello, I'd like to get a similar rewritten list than the one that git-rebase pass to the post-rewrite hook. Is there any ways to do that without using the post-rewrite hook ? Thanks -- Francis -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git describe --contains --abbrev=0 sha1 doesn't work as expected
Hello, Basically doing: git describe --abbrev=0 sha1 gives the closest tag from sha1 I would expect adding --contains option would give the closest tag containing sha1 but it seems that --abbrev=0 has no more effect in that case: $ git describe --tags --contains --abbrev=0 7f285fa78d4b81b8458f05e77fb6b46245121b4e v2.6.35-rc5~14^2~4 Is that expected ? Thanks -- Francis -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question about git log --cherry
On Fri, Sep 27, 2013 at 10:11 AM, John Keeping j...@keeping.me.uk wrote:
On Fri, Sep 27, 2013 at 07:09:03AM +0200, Francis Moreau wrote:
Hi,
On Thu, Sep 26, 2013 at 10:21 PM, John Keeping j...@keeping.me.uk wrote:
On Thu, Sep 26, 2013 at 06:35:57PM +0200, Francis Moreau wrote:
I'm trying to use git log --cherry ... in order to display new, kept
and removed commits between two branches A and B.
So commits which are only in B are considered new and should be marked
with '+'. Commits which are in both branches are marked with '=' but
only commit in branch B are shown. Eventually commits which are in A
but not in B anymore should be marked with '-'.
So far I found this solution:
$ git log --cherry-mark --right-only A...B
$ git log --cherry-pick --left-only A...B
but I have to call twice git-log. This can be annoying since depending
on A and B, calling git-log can take time.
Is there another option that I'm missing which would do the job but
with only one call to git-log ?
Does this do what you want?
git log --cherry-mark --left-right A...B |
sed -e '/^commit / {
y//-+/
}'
Nope because --left-right shows common commits (with '=' mark) that
belong to A *and* B, and I'd like to have only the ones in B.
I think the only way you can address this is to post-process the result,
I don't know any way to remove a left side commit only if it is
patch-identical to a right side commit.
It should be relatively easy to filter out any '=' commits that are in
the output of git rev-list --left-only A...B.
yes that's what I'm doing but I was wondering if that's possible to do
that with only one run of git-log/git-rev-list.
Thanks
--
Francis
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question about git log --cherry
On Fri, Sep 27, 2013 at 11:14 AM, John Keeping j...@keeping.me.uk wrote:
On Fri, Sep 27, 2013 at 10:28:05AM +0200, Francis Moreau wrote:
On Fri, Sep 27, 2013 at 10:11 AM, John Keeping j...@keeping.me.uk wrote:
On Fri, Sep 27, 2013 at 07:09:03AM +0200, Francis Moreau wrote:
Hi,
On Thu, Sep 26, 2013 at 10:21 PM, John Keeping j...@keeping.me.uk wrote:
On Thu, Sep 26, 2013 at 06:35:57PM +0200, Francis Moreau wrote:
I'm trying to use git log --cherry ... in order to display new, kept
and removed commits between two branches A and B.
So commits which are only in B are considered new and should be marked
with '+'. Commits which are in both branches are marked with '=' but
only commit in branch B are shown. Eventually commits which are in A
but not in B anymore should be marked with '-'.
So far I found this solution:
$ git log --cherry-mark --right-only A...B
$ git log --cherry-pick --left-only A...B
but I have to call twice git-log. This can be annoying since depending
on A and B, calling git-log can take time.
Is there another option that I'm missing which would do the job but
with only one call to git-log ?
Does this do what you want?
git log --cherry-mark --left-right A...B |
sed -e '/^commit / {
y//-+/
}'
Nope because --left-right shows common commits (with '=' mark) that
belong to A *and* B, and I'd like to have only the ones in B.
I think the only way you can address this is to post-process the result,
I don't know any way to remove a left side commit only if it is
patch-identical to a right side commit.
It should be relatively easy to filter out any '=' commits that are in
the output of git rev-list --left-only A...B.
yes that's what I'm doing but I was wondering if that's possible to do
that with only one run of git-log/git-rev-list.
I don't think it is. But you only need to use the --cherry-mark option
with one of the runs, so the other one should be very quick - the added
work of calculating patch IDs slows down git log a lot.
That's true, rev-list should be way faster. I think I'll do that.
Thanks.
--
Francis
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
git-log: --cherry-mark option and %m placeholder
Hello, When using --cherry option (which implies --cherry-mark) the mark boundaries are +, -, = when revs are displayed. But if I'm displaying them with --format=format:%m %H, it's still using , , = instead. Is that expected ? Thanks -- Francis -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Question about git log --cherry
Hello, I'm trying to use git log --cherry ... in order to display new, kept and removed commits between two branches A and B. So commits which are only in B are considered new and should be marked with '+'. Commits which are in both branches are marked with '=' but only commit in branch B are shown. Eventually commits which are in A but not in B anymore should be marked with '-'. So far I found this solution: $ git log --cherry-mark --right-only A...B $ git log --cherry-pick --left-only A...B but I have to call twice git-log. This can be annoying since depending on A and B, calling git-log can take time. Is there another option that I'm missing which would do the job but with only one call to git-log ? Thanks -- Francis -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question about git log --cherry
Hi,
On Thu, Sep 26, 2013 at 10:21 PM, John Keeping j...@keeping.me.uk wrote:
On Thu, Sep 26, 2013 at 06:35:57PM +0200, Francis Moreau wrote:
I'm trying to use git log --cherry ... in order to display new, kept
and removed commits between two branches A and B.
So commits which are only in B are considered new and should be marked
with '+'. Commits which are in both branches are marked with '=' but
only commit in branch B are shown. Eventually commits which are in A
but not in B anymore should be marked with '-'.
So far I found this solution:
$ git log --cherry-mark --right-only A...B
$ git log --cherry-pick --left-only A...B
but I have to call twice git-log. This can be annoying since depending
on A and B, calling git-log can take time.
Is there another option that I'm missing which would do the job but
with only one call to git-log ?
Does this do what you want?
git log --cherry-mark --left-right A...B |
sed -e '/^commit / {
y//-+/
}'
Nope because --left-right shows common commits (with '=' mark) that
belong to A *and* B, and I'd like to have only the ones in B.
Thanks
--
Francis
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Save notes state when releasing
On Fri, Sep 20, 2013 at 12:34 PM, Jeff King p...@peff.net wrote: On Fri, Sep 20, 2013 at 07:38:17AM +0200, Francis Moreau wrote: I'm using notes in my project. I'm wondering if it's possible to save the state of the notes when I'm releasing/tagging a new version of my project so I can restore the saved notes state if I checkout back the old release. Therefore I would be able to inspect notes (which may have been removed or modified after the release) as they were when the release happened. The notes are stored as git trees, so you can point a tag ref at a particular state, just as you would with a normal branch. The git tag command expects to create refs under refs/tags, whereas git notes expects to find notes under refs/notes. The simplest thing is to just use git update-ref rather than git tag to create the pointer. Like: $ git update-ref refs/notes/v1.0 refs/notes/commits and then you can always view the v1.0 notes as: $ git --notes=v1.0 log You can even set the notes.displayRef config to always show v1.0 notes when they are available for a commit. Though if they are a subset of the current notes, you would expect to see duplicates. Depending on what you are storing in your notes, you may want to clean out your notes tree after the release. Thank you Jeff, that's what I was needing. -- Francis -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Save notes state when releasing
Hello, I'm using notes in my project. I'm wondering if it's possible to save the state of the notes when I'm releasing/tagging a new version of my project so I can restore the saved notes state if I checkout back the old release. Therefore I would be able to inspect notes (which may have been removed or modified after the release) as they were when the release happened. Thanks -- Francis -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Removing all notes containing a specific string
Hello, I'd like to know if that's possible to parse all notes to detect a special string and if it's the case, remove the note like git-notes remove would do. Thanks -- Francis -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Removing all notes containing a specific string
On Fri, Sep 13, 2013 at 10:12 AM, Johan Herland jo...@herland.net wrote: On Fri, Sep 13, 2013 at 8:51 AM, Francis Moreau francis.m...@gmail.com wrote: Hello, I'd like to know if that's possible to parse all notes to detect a special string and if it's the case, remove the note like git-notes remove would do. Hi, There's no built-in command/option to do this, but the following shell one-liner should do the job: git grep -l $mystring refs/notes/commits | cut -d':' -f2 | tr -d '/' | xargs git notes remove Looks magic to me but does the trick Thanks ! -- Francis -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Transfer notes when rebasing
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Transfer notes when rebasing
On Wed, Sep 4, 2013 at 10:28 AM, Jeff King p...@peff.net wrote:
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:
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.
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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Notes and submodules
Hello, On Mon, Aug 19, 2013 at 3:55 PM, Johan Herland jo...@herland.net wrote: On Mon, Aug 19, 2013 at 10:13 AM, Francis Moreau francis.m...@gmail.com wrote: Hello, Is it possible to keep submodules notes in the super project ? Not easily. I guess it depends on what you want to use the notes for. In order for notes to be generally useful (i.e. show up in logs, surviving a notes prune, etc.) they really must reside in the same repo as the annotated objects [1]. Now, if all your interaction with notes happens through scripts that you control, then I guess it would be possible to hack this in some sort of semi-workable way, but you would still have to make sure never to run git notes prune in the super project. I guess the real question here is: Why would you want to do this? and is there maybe some other way your use case can be accomodated? Well, I'm tracking different foreign git repositories as submodules. Those repositories which tracks different projects are not mine therefore I can't save my own stuff directly in them. I need to annotate some commits in each submodule. One option would be to clone each repository in my own place, but I though it would be simpler if I could store the anntotion in _my_ super project. Thanks for your time. -- Francis -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Notes and submodules
Hello, Is it possible to keep submodules notes in the super project ? Thanks -- Francis -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Splitting a rev list into 2 sets
Hello Thomas,
On Mon, Jun 24, 2013 at 11:59 AM, Thomas Rast tr...@inf.ethz.ch wrote:
Francis Moreau francis.m...@gmail.com writes:
On Thu, Jun 20, 2013 at 3:20 PM, Thomas Rast tr...@inf.ethz.ch wrote:
positive=$(git rev-parse $@ | grep -v '^\^')
negative=$(git rev-parse $@ | grep '^\^')
boundary=$(git rev-list --boundary $positive ^master | sed -n 's/^-//p')
# the intersection is
git rev-list $boundary $negative
I think there's a minor issue here, when boundary is empty. Please
correct me if I'm wrong but I think it can only happen if positive is
simply master or a subset of master. In that case I think the solution
is just make boundary equal to positive:
# the intersection is
git rev-list ${boundary:-$positive} $negative
Now I'm going to see if that solution is faster than the initial one.
Jan jast Krüger pointed out on #git that
git log $(git merge-base --all A B)
is exactly the set of commits reachable from both A and B; so there's
your intersection operator :-)
nice :)
So it would seem that a much simpler approach is
git rev-list $(git merge-base --all master $positive) --not $negative
avoiding the boundary handling and special-case. It relies on the
(weird?) property that $(git merge-base --all A B1 B2 ...) shows the
merge bases of A with a hypothetical merge of B1, B2, ..., which is just
what you need here.
Thank you Thomas, that's exactly what I was asking for :)
--
Francis
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Splitting a rev list into 2 sets
Hi, On Thu, Jun 20, 2013 at 3:47 PM, Ramkumar Ramachandra artag...@gmail.com wrote: Francis Moreau wrote: Basically I have an initial set (or can be several different sets) expressed as a revision specification described by git-rev-list man page. I just want to find the common set of commit which are part of the initial sets *and* is reachable by master. That's just a generic list intersection between [a, b, c] and [d, e, f] no? [a, b, c] is a list you built up somehow, and [d, e, f] comes from $(git rev-list master), right? yes. You could go about determining the revision walk boundaries and combine them to set up a revision walk to splice the master line, but what is the point of that? Well, that seems to me a more elegant solution and I was curious about doing this with git-rev-list only if possible. You'll only be painting yourself into a design-corner (you won't be able to do other kinds of filtering), and going around your head to touch your nose. I think what Thomas proposed is fine. You precisely want list intersection: so write an efficient list intersection in the language of your choice. Why is it a poor man's solution? Sorry my wording was poor. I just meant that it was the obvious solution that I don't find nice. But your implementation was good. If anything, your convoluted rev-list solution will probably be more complicated, slower, and bug-ridden. Slower ? why do you think Thomas' solution is slower than the obvious one ? Thanks -- Francis -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Splitting a rev list into 2 sets
Hello, I'd like to write a script that would parse commits in one of my repo. Ideally this script should accept any revision ranges that git-rev-list would accept. This script should consider commits in master differently than the ones in others branches. To get the commit set which can't be reached by master (ie commits which are specific to branches other than master) I would do: # $@ is the range spec passed to the script git rev-list $@ ^master | check_other_commit But I don't know if it's possible to use a different git-rev-list command to get the rest of the commits, ie the ones that are reachable by the specified range and master. One way to do that is to record the first commit set got by the first rev-list command and check that the ones returned by git rev-list $@ are not in the record. But I'm wondering if someone can see another solution more elegant ? Thanks -- Francis -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Splitting a rev list into 2 sets
On Thu, Jun 20, 2013 at 1:26 PM, Ramkumar Ramachandra artag...@gmail.com wrote: Francis Moreau wrote: To get the commit set which can't be reached by master (ie commits which are specific to branches other than master) I would do: # $@ is the range spec passed to the script git rev-list $@ ^master | check_other_commit But I don't know if it's possible to use a different git-rev-list command to get the rest of the commits, ie the ones that are reachable by the specified range and master. One way to do that is to record the first commit set got by the first rev-list command and check that the ones returned by git rev-list $@ are not in the record. I don't fully understand your query, because almost anything is possible with rev-list: $ git rev-list foo..bar master # reachable from master, bar, not foo What I _suspect_ you're asking is for help when you can't construct this foo..bar master programmatically (or when you cannot express your criterion as arguments to rev-list). You want an initial commit set, and filter it at various points in your program using various criteria, right? Yes, I would like to be sure that I haven't missed some magic syntax for rev-list before going further in my poor man solution :) Basically I have an initial set (or can be several different sets) expressed as a revision specification described by git-rev-list man page. I just want to find the common set of commit which are part of the initial sets *and* is reachable by master. I would write it: git rev-list $@ --and master In that case, I'd suggest something like this: Thanks for the details example. -- Francis -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Splitting a rev list into 2 sets
Hi, On Thu, Jun 20, 2013 at 3:04 PM, Phil Hord phil.h...@gmail.com wrote: On Thu, Jun 20, 2013 at 6:14 AM, Francis Moreau francis.m...@gmail.com wrote: I'd like to write a script that would parse commits in one of my repo. Ideally this script should accept any revision ranges that git-rev-list would accept. This script should consider commits in master differently than the ones in others branches. To get the commit set which can't be reached by master (ie commits which are specific to branches other than master) I would do: # $@ is the range spec passed to the script git rev-list $@ ^master | check_other_commit But I don't know if it's possible to use a different git-rev-list command to get the rest of the commits, ie the ones that are reachable by the specified range and master. One way to do that is to record the first commit set got by the first rev-list command and check that the ones returned by git rev-list $@ are not in the record. But I'm wondering if someone can see another solution more elegant ? I do not know if I would call this elegant, but I think this codification of your One way to do that is at least small and mostly readable: git rev-list $@ |grep -v -f (git rev-list $@ ^master) Yes, thanks. But I wanted to be sure that git-rev-list can't display the intersection of several sets before going forward. -- Francis -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Splitting a rev list into 2 sets
Hi,
On Thu, Jun 20, 2013 at 3:20 PM, Thomas Rast tr...@inf.ethz.ch wrote:
Francis Moreau francis.m...@gmail.com writes:
But I'm wondering if someone can see another solution more elegant ?
I think there's a cute way. Suppose your arguments are of the form
Really nice !
p1 p2 ... --not n1 n2 ...
that is each pX is positive, and each nX is negative. Then as you
observed, building the difference with master is easy: just add it to
the negative args.
I didn't know that git-rev-parse could be used to transform any range
specification into that form (p1 p2 .. -not n1 n2..)
Intersecting with master is harder, because you don't know what parts of
it (if any) are in the range. But the --boundary option can help: these
are the commits where the positive and negative ranges first met, and
prevented the walk from continuing.
So the part of master reachable from p1, p2, etc. is exactly the set of
boundary commits of 'p1 p2 ... ^master'. And on top of that, excluding
the parts reachable from the n's is easy. So you can do:
Really clever.
positive=$(git rev-parse $@ | grep -v '^\^')
negative=$(git rev-parse $@ | grep '^\^')
boundary=$(git rev-list --boundary $positive ^master | sed -n 's/^-//p')
# the intersection is
git rev-list $boundary $negative
I think there's a minor issue here, when boundary is empty. Please
correct me if I'm wrong but I think it can only happen if positive is
simply master or a subset of master. In that case I think the solution
is just make boundary equal to positive:
# the intersection is
git rev-list ${boundary:-$positive} $negative
Now I'm going to see if that solution is faster than the initial one.
Great Thanks
--
Francis
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Adding --ignore-submodules switch to git-describe
Hello, Would it make sense to add the option --ignore-submodules (currently available in git-status) to git-describe when the later is used with --dirty option ? Thanks -- Francis -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-describe fails with --dirty is incompatible with committishes if passing HEAD as argument
On Mon, Nov 19, 2012 at 8:36 PM, Junio C Hamano gits...@pobox.com wrote: Francis Moreau francis.m...@gmail.com writes: Inside the kernel repository, I tried this: $ git describe --dirty --match 'v[0-9]*' --abbrev=4 HEAD fatal: --dirty is incompatible with committishes If 'HEAD' is removed then git-describe works as expected. Is that expected ? I would say so, at least in modern codebase. git describe without any commit object name used to mean describe the HEAD commit using the better known points before the --dirty option was introduced. But --dirty makes it describe the current checkout. For example, output from git describe --dirty v1.8.0-211-gd8b4531-dirty means your working tree contains work-in-progress based on d8b4531, which is 211 commits ahead of the v1.8.0 tag. So conceptually, it should not take any commit, even if it were spelled HEAD. git describe --dirty HEAD^^ would be an utter nonsense for the same reason. Thanks for explaining, that makes sense. -- Francis -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Why does git-commit --template want the template to be modified ?
Hi, On Tue, Oct 30, 2012 at 12:09 PM, Tomas Carnecky tomas.carne...@gmail.com wrote: On Tue, 30 Oct 2012 11:53:08 +0100, Francis Moreau francis.m...@gmail.com wrote: Hi, I'm using git-commit with the --template option. The template I'm given is self sufficient for my purpose but as stated in the documentation, git-commit wants the template to be edited otherwise it aborts the operation. Is it possible to change this ? It seems you want -F instead of --template. Yes, but I want git to still parse the log and sanitize it (remove trailing whitespaces, comments ...) I actually found that -F --edit is what I needed. Thanks both for your answer. -- Francis -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can't understand the behaviour of git-diff --submodule
On Sun, Oct 28, 2012 at 1:02 AM, Jens Lehmann jens.lehm...@web.de wrote: Am 26.10.2012 22:43, schrieb Francis Moreau: On Fri, Oct 26, 2012 at 10:05 PM, Jens Lehmann jens.lehm...@web.de wrote: [...] That is weird, git diff --submodule should show that too. Is there anything unusual about your setup? (The only explanation I can come up with after checking the code is that your submodule has neither a .git directory nor a gitfile or the objects directory in there doesn't contain these commits) Oh now you're asking, I think the submodule has been added by using the --reference option of git-submodule-add. $ cd configs $ cat .git gitdir: ../.git/modules/configs Thanks, I suspect the --reference option makes the difference here, I'll check that as soon as I find some time. Yes that's fairly easy to reproduce: $ mkdir super $ cd super $ git init $ git submodule add --reference ~/tmp/git-submodule/public/a.git ~/tmp/git-submodule/public/a.git a $ git commit -m Initial creation of super project $ cd a $ date a.txt $ git commit -a -m add to a.txt a random change $ cd .. $ git submodule summary * a 2f8803a...a1aa4bf (1): add to a.txt a random change $ git commit -a -m Include a's changes in super project $ git diff --submodule=log HEAD~1 HEAD Submodule a 2f8803a...a1aa4bf (commits not present) Thanks -- Francis -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git submodule summary doesn't return an error when passed a wrong commit/rev
Hi, it seems to me that when passed an unknown rev or a wrong commit/sha1, git-submodule-summary should at least exit with an error status. Even better would be a error output. Test was done with git version 1.7.10.4 from debian wheezy. Thanks -- Francis -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can't understand the behaviour of git-diff --submodule
Hi, Thanks for answering On Fri, Oct 26, 2012 at 9:08 PM, Jens Lehmann jens.lehm...@web.de wrote: Am 26.10.2012 16:07, schrieb Francis Moreau: I'm trying to use the --submodule switch with git-diff but doesnt understand the following behaviour: $ git diff 2c9a257718d1803de720f95766ff256d33accad5 HEAD diff --git a/configs b/configs index 16c6a89..ce12289 16 --- a/configs +++ b/configs @@ -1 +1 @@ -Subproject commit 16c6a89f245f0eed7fb0bce8e027c59fcf1d543e +Subproject commit ce12289c5bfca7b2c423d9f1871c13ad1ba1dc32 but adding the --submodule option gives: $ git diff --submodule=log 2c9a257718d1803de720f95766ff256d33accad5 HEAD Submodule configs 16c6a89...ce12289 (commits not present) Could anybody enlight me ? The output Submodule configs 16c6a89...ce12289 (commits not present) contains same SHA-1s, only in their abbreviated form. That is the same information you get without the --submodule option, but in shorter format: it says the submodule moved from 16c6a89 to ce12289 in the given commit range of the superproject (and the ... part tells us it wasn't a fast-forward). The (commits not present) part indicates that even though git diff would have wanted to show you what happened in the submodule between 16c6a89 and ce12289 by displaying the first line of each commit message, it couldn't because these commit(s) are not present in the submodule repo. If you do a git log --oneline 16c6a89...ce12289 inside the submodule you'll get an unknown revision error for the same reason. Well, no the commits are present in the submodule, that's what I tried to show with the first 'git-diff' command I did in my previous post (without the --submodule switch). And to check again, this is the result of git log: $ cd configs $ git log --oneline 16c6a89...ce12289 ce12289 test 2 [...] Does that make it clearer? Unforunately not really. Thanks. -- Francis -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git submodule summary doesn't return an error when passed a wrong commit/rev
On Fri, Oct 26, 2012 at 9:53 PM, Jens Lehmann jens.lehm...@web.de wrote: Am 26.10.2012 16:03, schrieb Francis Moreau: it seems to me that when passed an unknown rev or a wrong commit/sha1, git-submodule-summary should at least exit with an error status. Even better would be a error output. Test was done with git version 1.7.10.4 from debian wheezy. Thanks for your report, I think you found a real issue. Some quick tests showed some problems with other parameter combinations too. I'll take a deeper look the next days. Glad to help :) -- Francis -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can't understand the behaviour of git-diff --submodule
On Fri, Oct 26, 2012 at 10:05 PM, Jens Lehmann jens.lehm...@web.de wrote: [...] That is weird, git diff --submodule should show that too. Is there anything unusual about your setup? (The only explanation I can come up with after checking the code is that your submodule has neither a .git directory nor a gitfile or the objects directory in there doesn't contain these commits) Oh now you're asking, I think the submodule has been added by using the --reference option of git-submodule-add. $ cd configs $ cat .git gitdir: ../.git/modules/configs Thanks -- Francis -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
