* Re: git-format-patch should include a checksum
From: Sverre Rabbelier @ 2010-01-27 0:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Juliusz Chroboczek, git
In-Reply-To: <alpine.LFD.2.00.1001261639550.17519@localhost.localdomain>
Heya,
On Wed, Jan 27, 2010 at 01:45, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> That wouldn't work either. People can, should, and do add extra things to
> the message before applying it.
Ah, that's a fair point.
> In short, it might make sense to have some anti-corruption logic, but I
> suspect it needs a lot of thought.
Perhaps it makes sense to make it a separate mode to git am, such that
it only checks that the patch is not corrupted, but does not apply it.
That way it would be possible to download the patch, check that it
arrived unscathed, and then do your usual patch handling. Those who do
not edit patches before applying it would be convenient to set a
configuration option that automatically does it when applying the
patch, either warning about it or aborting (as Juliusz suggested).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Patchdiff
From: Jonathan Nieder @ 2010-01-27 1:09 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git List
In-Reply-To: <fabb9a1e1001261606i4f706387vaf5647436e454fb4@mail.gmail.com>
Hi,
Sverre Rabbelier wrote:
> Do we have anything that allows me to compare two versions of a patch?
> In theory it'd do something like "apply both patches to the their
> merge base, then show the diff between the results".
It’s not git specific, but maybe interdiff [1] could help.
Ciao,
Jonathan
[1] http://cyberelk.net/tim/data/patchutils/stable/
^ permalink raw reply
* Re: git-format-patch should include a checksum
From: Nicolas Pitre @ 2010-01-27 1:13 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Linus Torvalds, Junio C Hamano, Juliusz Chroboczek, git
In-Reply-To: <fabb9a1e1001261650r18e04e3cw2efade6072a426b@mail.gmail.com>
On Wed, 27 Jan 2010, Sverre Rabbelier wrote:
> Heya,
>
> On Wed, Jan 27, 2010 at 01:45, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > That wouldn't work either. People can, should, and do add extra things to
> > the message before applying it.
>
> Ah, that's a fair point.
FWIW, I do manually edit both incoming and outgoing patches from time to
time as well.
> > In short, it might make sense to have some anti-corruption logic, but I
> > suspect it needs a lot of thought.
>
> Perhaps it makes sense to make it a separate mode to git am, such that
> it only checks that the patch is not corrupted, but does not apply it.
> That way it would be possible to download the patch, check that it
> arrived unscathed, and then do your usual patch handling. Those who do
> not edit patches before applying it would be convenient to set a
> configuration option that automatically does it when applying the
> patch, either warning about it or aborting (as Juliusz suggested).
I think what would be even more useful at first is to find out why
corrupted patches still apply.
And yet without any changes in the patch format, it should be possible
to test the validity of a patch whenever the blob for the preimage SHA1
from the index line in the patch header is available locally. Just
applying the patch to that blob and confirming it matches the postimage
SHA1 should cover many cases already.
Nicolas
^ permalink raw reply
* Re: Patchdiff
From: Nicolas Pitre @ 2010-01-27 1:19 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git List
In-Reply-To: <fabb9a1e1001261606i4f706387vaf5647436e454fb4@mail.gmail.com>
On Wed, 27 Jan 2010, Sverre Rabbelier wrote:
> Heya,
>
> Do we have anything that allows me to compare two versions of a patch?
> In theory it'd do something like "apply both patches to the their
> merge base, then show the diff between the results". I don't think we
> have something like that, since there's probably some major caveats
> about conflicts when applying the patches to their merge-base. Or
> perhaps my theory is silly, and there's an easier way to compare two
> patches (other than looking at a diff's diff, which I've never been
> good at).
What about Git's diff -c/--cc ? You'd have to reverse the parenthood
logic though.
Nicolas
^ permalink raw reply
* Re: git-format-patch should include a checksum
From: Junio C Hamano @ 2010-01-27 1:25 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Sverre Rabbelier, Linus Torvalds, Junio C Hamano,
Juliusz Chroboczek, git
In-Reply-To: <alpine.LFD.2.00.1001262006150.1681@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
> FWIW, I do manually edit both incoming and outgoing patches from time to
> time as well.
Me three.
> I think what would be even more useful at first is to find out why
> corrupted patches still apply.
Exactly. That is why I asked that question at the very beginning.
> ... Just
> applying the patch to that blob and confirming it matches the postimage
> SHA1 should cover many cases already.
That would work when you are/have the sole authority (so contributors
won't send patches based on some other trees), you push out often (to keep
the length of the patch queue contributors keep short).
That would make it more likely that others base their work on what you
published, and send patches from their base version all the way (not
skipping "this is what I sent earlier but haven't been accepted nor pushed
out"). Otherwise it will be unlikely that you have the object recorded as
the preimage. Often when I receive follow-up patches from people, some
are based on what was committed by me (possibly with tweaks), and some
others are based on what was seen on the list (lacking the tweaks), yet
some others are based on random other versions. I'll have preimages only
in the first case.
Usually while editing incoming patch text (not log message), you mostly
touch postimage, but when fixing up a diff that was based on a bit stale
version, you need to touch preimage as well. In these cases, the blob
object names recorded in the patch wouldn't be very useful.
^ permalink raw reply
* Re: Patchdiff
From: Junio C Hamano @ 2010-01-27 1:30 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Sverre Rabbelier, Git List
In-Reply-To: <alpine.LFD.2.00.1001262014250.1681@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
>> Do we have anything that allows me to compare two versions of a patch?
>> In theory it'd do something like "apply both patches to the their
>> merge base, then show the diff between the results". I don't think we
>> have something like that, since there's probably some major caveats
>> about conflicts when applying the patches to their merge-base. Or
>> perhaps my theory is silly, and there's an easier way to compare two
>> patches (other than looking at a diff's diff, which I've never been
>> good at).
>
> What about Git's diff -c/--cc ? You'd have to reverse the parenthood
> logic though.
When I did "diff --cc" originally, I thought about its interaction with
reverse (-R), and gave up.
The thing is, "--cc" output needs to show "here is _the_ end result",
together with "and each sides did things in these different ways (shown
with +/- annotations)".
When showing a merge, there is one end result (the merged version), so it
fits the model that is a natural extension of two-way diff. In the "two
patches walked in a bar, modified the same version and produced two
different results" case, the common thing is the preimage, not postimage.
I couldn't come up with a combined output format that visually makes sense
for that mode of operation.
^ permalink raw reply
* Re: git-format-patch should include a checksum
From: Juliusz Chroboczek @ 2010-01-27 1:25 UTC (permalink / raw)
To: git
In-Reply-To: <7vljfkxxj9.fsf@alter.siamese.dyndns.org>
> Do you have an example of such corrupted and incorrectly applied patches?
> What kind of corruption are you talking about?
The commit message getting rewrapped. For some reason, the patch itself
was not corrupted.
Another case is that of the commit message having its non-ASCII
characters corrupted.
> adding a checksum over the entire output and forcing a check upon
> application is really a bad idea, even though, provided if the patch
> is done cleanly, it might be acceptable as an optional feature.
The part I really care about is that git-format-patch should include
a checksum by default.
I'd be quite happy if git-am only warned about a checksum mismatch.
Linus:
> That wouldn't work either. People can, should, and do add extra things to
> the message before applying it.
Shouldn't they remove the checksum line at the same time as they edit
a patch?
Juliusz
^ permalink raw reply
* Re: git-format-patch should include a checksum
From: Junio C Hamano @ 2010-01-27 1:35 UTC (permalink / raw)
To: Juliusz Chroboczek; +Cc: git
In-Reply-To: <7ir5pccp9n.fsf@lanthane.pps.jussieu.fr>
Juliusz Chroboczek <Juliusz.Chroboczek@pps.jussieu.fr> writes:
>> That wouldn't work either. People can, should, and do add extra things to
>> the message before applying it.
>
> Shouldn't they remove the checksum line at the same time as they edit
> a patch?
Why force extra work on people, especially the ones who _receive_ patches,
when they say they _don't_ want to have such a noise by default?
^ permalink raw reply
* Re: Patchdiff
From: Nicolas Pitre @ 2010-01-27 1:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sverre Rabbelier, Git List
In-Reply-To: <7vzl40wcz2.fsf@alter.siamese.dyndns.org>
On Tue, 26 Jan 2010, Junio C Hamano wrote:
> When showing a merge, there is one end result (the merged version), so it
> fits the model that is a natural extension of two-way diff. In the "two
> patches walked in a bar, modified the same version and produced two
> different results" case, the common thing is the preimage, not postimage.
> I couldn't come up with a combined output format that visually makes sense
> for that mode of operation.
Hmmmmmm yeah. I didn't think it through all the way. Too bad.
Nicolas
^ permalink raw reply
* Re: [PATCH] work around an obnoxious bash "safety feature" on OpenBSD
From: Jeff Epler @ 2010-01-27 2:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7veilcxudx.fsf@alter.siamese.dyndns.org>
On Tue, Jan 26, 2010 at 04:29:30PM -0800, Junio C Hamano wrote:
> update_squash_messages () {
> - if test -f "$SQUASH_MSG"; then
> + if test -f "$SQUASH_MSG"
> + then
I don't think this belongs here.
Jeff
^ permalink raw reply
* Re: git-format-patch should include a checksum
From: Junio C Hamano @ 2010-01-27 3:01 UTC (permalink / raw)
To: Juliusz Chroboczek; +Cc: git
In-Reply-To: <7ir5pccp9n.fsf@lanthane.pps.jussieu.fr>
Juliusz Chroboczek <Juliusz.Chroboczek@pps.jussieu.fr> writes:
>> Do you have an example of such corrupted and incorrectly applied patches?
>> What kind of corruption are you talking about?
>
> The commit message getting rewrapped. For some reason, the patch itself
> was not corrupted.
You hopefully check the message (and of course the patch) before applying,
so "automatically reject and require force" wouldn't help you much in this
case. Either you reject and tell the sender to resend, or you reflow it
yourself to save the sender (and yourself) the hassle of round-trip.
And if you choose to do the latter, having to force it would actively
inconvenience you.
> Another case is that of the commit message having its non-ASCII
> characters corrupted.
I've seen this one. It often is that the commit object records UTF-8, but
somehow the MUA didn't mark it as such (or incorrectly marked it as
ISO-8859-1), and mailinfo ended up doing unnecessary conversion. When
this happens, not just the message but also the patch text is affected.
But to use "checksumming" as a solution for this, you need to think about
what you checksum. Output from format-patch is "text/plain;charset=UTF-8"
and requires 8-bit clean transport, but by cutting and pasting that into
MUA you often end up with whatever MIME B/Q-quoting your MUA gives you,
and mailinfo is actively unwraps them, so the right place to add an
optional check _might_ be immediately after we run mailinfo. At that
point, however, the author name and the subject line is in separate
records from the body of the commit log message.
More realistically, the kind of MUA corruption I personally see most often
is "text/plain; format-flowed"; I have a pre-applypatch hook to reject
them altogether, but they tend to corrupt leading whitespaces so badly
that the patch seldome applies. This is not something "checksumming" is
the right tool to solve.
One thing that we _might_ consider doing is to reduce the default length
of the function name we place on the hunk header line. For some reason, I
see they get wrapped in messages I see, even when the proposed commit log
message has overlong lines.
^ permalink raw reply
* Re: [PATCH] work around an obnoxious bash "safety feature" on OpenBSD
From: Junio C Hamano @ 2010-01-27 3:01 UTC (permalink / raw)
To: Jeff Epler; +Cc: Junio C Hamano, git
In-Reply-To: <20100127024148.GA18826@unpythonic.net>
Jeff Epler <jepler@unpythonic.net> writes:
> On Tue, Jan 26, 2010 at 04:29:30PM -0800, Junio C Hamano wrote:
>> update_squash_messages () {
>> - if test -f "$SQUASH_MSG"; then
>> + if test -f "$SQUASH_MSG"
>> + then
>
> I don't think this belongs here.
>
> Jeff
Yeah, it is a general improvement in the vicinity.
^ permalink raw reply
* Re: git status showing phantom modifications
From: Tay Ray Chuan @ 2010-01-27 5:14 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Michael Ludwig, git@vger.kernel.org
In-Reply-To: <59B5C4C4-6E95-4BAA-9351-B88B6309E022@xing.com>
Hi Johannes,
do you happen to have any clue on this?
--
Cheers,
Ray Chuan
On Tue, Jan 26, 2010 at 5:14 PM, Michael Ludwig <michael.ludwig@xing.com> wrote:
> Am 25.01.2010 um 12:43 schrieb Michael Ludwig:
>
>> Reading up about core.fileMode in git-config(1), I think you've pointed
>> me to the solution. I should probably just set it to false. If that doesn't
>> solve the issue, I'll report back.
>
> Back with more info:
>
> git version 1.6.4.2
>
> Before adding any core.filemode setting to ~/.gitconfig or .git/config:
>
> michael@wladimir:/cygdrive/m/REPOS6.TECH.git/comp :-) git config -l
> user.name=Michael Ludwig
> user.email=...
> core.repositoryformatversion=0
> core.filemode=true <= filemode already present
> core.bare=false
> core.logallrefupdates=true
> core.ignorecase=true
> core.autocrlf=false
> svn-remote.svn.ignore-paths=^(some|paths)
> svn-remote.svn.url=svn://localhost
> svn-remote.svn.fetch=:refs/remotes/git-svn
> svn.authorsfile=authors.txt
>
> My git status output after cd to subdir shows many files "modified". But
> they aren't! Edited ~/.gitconfig to include core.filemode = true [sic].
> Here's the diff for the git config output:
>
> --- /home/michael/a 2010-01-25 20:36:53.140625000 +0100
> +++ /home/michael/b 2010-01-25 20:37:01.421875000 +0100
> @@ -4,6 +4,7 @@
> alias.ci=checkin
> alias.co=checkout
> alias.br=branch
> +core.filemode=true
> core.repositoryformatversion=0
> core.filemode=true
> core.bare=false
>
> We're seeing core.filemode appear *twice*. Why that?
>
> michael@wladimir:/cygdrive/m/REPOS6.TECH.git/comp :-) git st
> # On branch master
> nothing to commit (working directory clean)
>
> So it seems adding core.filemode = true has fixed the issue, or at least
> covered the symptoms. Adding core.filemode = false did not cause the
> phantom modifications to disappear. Note that from reading git-config(1),
> I had rather assumed this latter setting to have the desired effect.
>
> And something seems to be wrong here. Why are modifications flagged when
> doing git status from a subdir but not from the topdir?
>
> --
> Michael.Ludwig (#) XING.com
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH v2.1 3/5] Documentation: reset: describe new "--keep" option
From: Christian Couder @ 2010-01-27 5:52 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt,
Stephen Boyd, Andreas Schwab, Daniel Convissor
and give an example to show how it can be used.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-reset.txt | 47 ++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 46 insertions(+), 1 deletions(-)
This is to replace patch "[PATCH v2 3/5]" (in the "reset --keep" series),
which has some grammar/spelling problems.
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 168db08..b9ecd49 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -8,7 +8,7 @@ git-reset - Reset current HEAD to the specified state
SYNOPSIS
--------
[verse]
-'git reset' [--mixed | --soft | --hard | --merge] [-q] [<commit>]
+'git reset' [--mixed | --soft | --hard | --merge | --keep] [-q] [<commit>]
'git reset' [-q] [<commit>] [--] <paths>...
'git reset' --patch [<commit>] [--] [<paths>...]
@@ -52,6 +52,11 @@ OPTIONS
and updates the files that are different between the named commit
and the current commit in the working tree.
+--keep::
+ Resets the index to match the tree recorded by the named commit,
+ but keep changes in the working tree. Aborts if the reset would
+ change files that are already modified in the working tree.
+
-p::
--patch::
Interactively select hunks in the difference between the index
@@ -93,6 +98,7 @@ in the index and in state D in HEAD.
--mixed A D D
--hard D D D
--merge (disallowed)
+ --keep (disallowed)
working index HEAD target working index HEAD
----------------------------------------------------
@@ -100,6 +106,7 @@ in the index and in state D in HEAD.
--mixed A C C
--hard C C C
--merge (disallowed)
+ --keep A C C
working index HEAD target working index HEAD
----------------------------------------------------
@@ -107,6 +114,7 @@ in the index and in state D in HEAD.
--mixed B D D
--hard D D D
--merge D D D
+ --keep (disallowed)
working index HEAD target working index HEAD
----------------------------------------------------
@@ -114,6 +122,7 @@ in the index and in state D in HEAD.
--mixed B C C
--hard C C C
--merge C C C
+ --keep B C C
working index HEAD target working index HEAD
----------------------------------------------------
@@ -121,6 +130,7 @@ in the index and in state D in HEAD.
--mixed B D D
--hard D D D
--merge (disallowed)
+ --keep (disallowed)
working index HEAD target working index HEAD
----------------------------------------------------
@@ -128,6 +138,7 @@ in the index and in state D in HEAD.
--mixed B C C
--hard C C C
--merge B C C
+ --keep B C C
"reset --merge" is meant to be used when resetting out of a conflicted
merge. Any mergy operation guarantees that the work tree file that is
@@ -138,6 +149,14 @@ between the index and the work tree, then it means that we are not
resetting out from a state that a mergy operation left after failing
with a conflict. That is why we disallow --merge option in this case.
+"reset --keep" is meant to be used when removing some of the last
+commits in the current branch while keeping changes in the working
+tree. If there could be conflicts between the changes in the commit we
+want to remove and the changes in the working tree we want to keep,
+the reset is disallowed. That's why it is disallowed if there are both
+changes between the working tree and HEAD, and between HEAD and the
+target.
+
The following tables show what happens when there are unmerged
entries:
@@ -147,6 +166,7 @@ entries:
--mixed X B B
--hard B B B
--merge B B B
+ --keep (disallowed)
working index HEAD target working index HEAD
----------------------------------------------------
@@ -154,6 +174,7 @@ entries:
--mixed X A A
--hard A A A
--merge A A A
+ --keep X A A
X means any state and U means an unmerged index.
@@ -325,6 +346,30 @@ $ git add frotz.c <3>
<2> This commits all other changes in the index.
<3> Adds the file to the index again.
+Keep changes in working tree while discarding some previous commits::
++
+Suppose you are working on something and you commit it, and then you
+continue working a bit more, but now you think that what you have in
+your working tree should be in another branch that has nothing to do
+with what you commited previously. You can start a new branch and
+reset it while keeping the changes in your work tree.
++
+------------
+$ git tag start
+$ git branch branch1
+$ edit
+$ git commit ... <1>
+$ edit
+$ git branch branch2 <2>
+$ git reset --keep start <3>
+------------
++
+<1> This commits your first edits in branch1.
+<2> This creates branch2, but unfortunately it contains the previous
+commit that you don't want in this branch.
+<3> This removes the unwanted previous commit, but this keeps the
+changes in your working tree.
+
Author
------
Written by Junio C Hamano <gitster@pobox.com> and Linus Torvalds <torvalds@osdl.org>
--
1.6.6.1.557.g77031
^ permalink raw reply related
* Re: Patchdiff
From: Bert Wesarg @ 2010-01-27 7:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Sverre Rabbelier, Git List
In-Reply-To: <7vzl40wcz2.fsf@alter.siamese.dyndns.org>
On Wed, Jan 27, 2010 at 02:30, Junio C Hamano <gitster@pobox.com> wrote:
> Nicolas Pitre <nico@fluxnic.net> writes:
>
>>> Do we have anything that allows me to compare two versions of a patch?
>>> In theory it'd do something like "apply both patches to the their
>>> merge base, then show the diff between the results". I don't think we
>>> have something like that, since there's probably some major caveats
>>> about conflicts when applying the patches to their merge-base. Or
>>> perhaps my theory is silly, and there's an easier way to compare two
>>> patches (other than looking at a diff's diff, which I've never been
>>> good at).
>>
>> What about Git's diff -c/--cc ? You'd have to reverse the parenthood
>> logic though.
>
> When I did "diff --cc" originally, I thought about its interaction with
> reverse (-R), and gave up.
Actually, I have done this. My intention is to use this as a new merge
conflict style.
I will send the patch, but not today.
Regards,
Bert
^ permalink raw reply
* Testing if a certain commit is in the current branch
From: Frans Pop @ 2010-01-27 7:19 UTC (permalink / raw)
To: git
I'm currently using the following command for this:
git log --pretty=format:%H | grep -q '^<commit id>"
Problem is that with large repos that can be quite slow.
Is there a faster way to do the test?
TIA,
FJP
^ permalink raw reply
* Re: git status showing phantom modifications
From: Johannes Sixt @ 2010-01-27 7:20 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Michael Ludwig, git@vger.kernel.org
In-Reply-To: <be6fef0d1001262114r137ba8ddi60a3a3468950c5ce@mail.gmail.com>
Please do not top-post, particularly not when you place the meat of the
message after a "-- " marker; There's *no way* to force Thunderbird to
include the text below it in the reply.
Tay Ray Chuan schrieb:
> do you happen to have any clue on this?
Sorry, no. One more thing to try is:
core.ignorecygwinfstricks = false
This turns off some stat() optimizations on Cygwin.
-- Hannes
^ permalink raw reply
* Re: Testing if a certain commit is in the current branch
From: Junio C Hamano @ 2010-01-27 7:24 UTC (permalink / raw)
To: Frans Pop; +Cc: git
In-Reply-To: <201001270819.39819.elendil@planet.nl>
Frans Pop <elendil@planet.nl> writes:
> I'm currently using the following command for this:
> git log --pretty=format:%H | grep -q '^<commit id>"
>
> Problem is that with large repos that can be quite slow.
>
> Is there a faster way to do the test?
test "$(git merge-base HEAD $commit)" = "$(git rev-parse $commit)"
But this is a literal answer that could be a less than optimal solution if
you are having an XY problem.
^ permalink raw reply
* Re: [PATCH] fix portability issues with $ in double quotes
From: Johannes Sixt @ 2010-01-27 7:53 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git, Junio C Hamano
In-Reply-To: <1264547311-25251-1-git-send-email-bebarino@gmail.com>
Stephen Boyd schrieb:
> Using a dollar sign in double quotes isn't portable. Escape them with
> a backslash or replace the double quotes with single quotes.
The instances you changed look good. I didn't check whether you missed
some. Was this some sort of mechanical change?
I must say that a backslash in front of a $ in a sed expression looks very
distracting:
> + git cat-file commit HEAD | sed -e "1,/^\$/d" >actual &&
> + git cat-file commit side@{1} | sed -e "1,/^\$/d" >expect &&
because it is easy to miss that the backslash is taken by the
double-quotes. But since these cases happen in the test suite where the
whole thing is in single-quotes already, I don't think we can do something
about it without making it even more unreadable...
-- Hannes
^ permalink raw reply
* Re: Testing if a certain commit is in the current branch
From: Matthieu Moy @ 2010-01-27 8:26 UTC (permalink / raw)
To: Frans Pop; +Cc: git
In-Reply-To: <201001270819.39819.elendil@planet.nl>
Frans Pop <elendil@planet.nl> writes:
> I'm currently using the following command for this:
> git log --pretty=format:%H | grep -q '^<commit id>"
>
> Problem is that with large repos that can be quite slow.
>
> Is there a faster way to do the test?
Not answering the question exactly, but "git branch --contains <commitid>"
does almost this and a bit more.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: 3 question about how to use Git .
From: honglei junan @ 2010-01-27 8:35 UTC (permalink / raw)
To: git
In-Reply-To: <e78dc7d71001270034k48e1a386p64e01eb8d6d1187a@mail.gmail.com>
hi,i have three questions seem not not appear in GitFaq,yet confuse me much :
*) since I've already commit many patches before telling git my name
and email,should i roll back and recommit all patches to make my name
in repository?
*) i create a new branch ms_port,and then commit several patches like,
commit 1->commit 2->commit 3->commit 4
now i just want to change commit2,without change any others,how could
i do it?since i only change the local repository,i think this should
be allowed.
*) when cloning a git repository,the network is broken down.How could
i went on the clone process when the network being OK ?
since the download speed is very low, i really don't want to remove
all things and download them again.
Many thanks.
^ permalink raw reply
* Re: Testing if a certain commit is in the current branch
From: Frans Pop @ 2010-01-27 8:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viqaorowo.fsf@alter.siamese.dyndns.org>
On Wednesday 27 January 2010, Junio C Hamano wrote:
> Frans Pop <elendil@planet.nl> writes:
> > I'm currently using the following command for this:
> > git log --pretty=format:%H | grep -q "^<commit id>"
> >
> > Problem is that with large repos that can be quite slow.
> >
> > Is there a faster way to do the test?
>
> test "$(git merge-base HEAD $commit)" = "$(git rev-parse $commit)"
Great! If the commit ID is not present that only takes 1 sec versus 11 secs
for my test. (If the commit _is_ present and fairly recent my test can be
faster, but 11 secs delay when it's not present hurts more.)
> But this is a literal answer that could be a less than optimal solution
> if you are having an XY problem.
The use case is a wrapper script for kernel builds in which some variation
are needed (due to changes in the build system) when building older
kernels, e.g. during bisections or when building older stable updates.
So I test for the presence of commits that introduced relevant changes.
Thanks again,
FJP
^ permalink raw reply
* Re: cvs revision number -> git commit name?
From: Junio C Hamano @ 2010-01-27 8:38 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Aaron Crane, Hallvard B Furuseth
In-Reply-To: <201001270043.44614.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> The notes feature is still very new, and there are still outstanding patches
> to be merged, but the basics are there in v1.6.6.
By the way, we should seriously rethink how notes should propagate through
rebases and amends. I've been using this in my post-applypatch hook
lately:
-- >8 -- cut here -- >8 --
#!/bin/sh
GIT_DIR=.git
dotest="$GIT_DIR/rebase-apply"
prec=4 &&
this=$(cat 2>/dev/null "$dotest/next") &&
msgnum=$(printf "%0${prec}d" $this) &&
test -f "$dotest/$msgnum" &&
message_id=$(sed -n '
/^Message-I[Dd]:[ ]*\(<.*>\)[ ]*$/{
s//\1/p
q
}
/^$/q
' "$dotest/$msgnum") &&
test -n "$message_id" &&
GIT_NOTES_REF=refs/notes/amlog \
git notes edit -m "Message-Id: $message_id" HEAD
-- 8< -- upto here -- 8< --
together with this in $HOME/.gitconfig
-- >8 -- cut here -- >8 --
[alias]
lgm = "!sh -c 'GIT_NOTES_REF=refs/notes/amlog git log \"$@\" || :' -"
-- 8< -- upto here -- 8< --
so that I can say:
$ git lgm -1 jh/maint-config-file-prefix
commit 65807ee697a28cb30b8ad38ebb8b84cebd3f255d
Author: Johan Herland <johan@herland.net>
Date: Tue Jan 26 16:02:16 2010 +0100
builtin-config: Fix crash when using "-f <relative path>" from non-root dir
When your current directory is not ...
...
Notes:
Message-Id: <201001261602.16876.johan@herland.net>
A few observations I made myself so far:
- I used to fix minor issues (styles, decl-after-stmt, etc.) using
rebase-i long after running "am" in bulk, but these days I find myself
going back to my "inbox" and fix them in MUA; this is only because I
know these notes do not propagate across rebases and amends---adjusting
the workflow to the tool's limitation is not very good.
- The interface to tell tools to use which notes ref to use should be
able to say "these refs", not just "this ref" i.e. GIT_NOTES_REF=a:b
just like PATH=a:b:c...); I am fairly certain that we would want to
store different kind of information in separate notes trees and
aggregate them, as we gain experience with notes.
- There should be an interface to tell tools to use which notes refs via
command line options; "!alias" does not TAB-complete, and "git lgm"
above doesn't, either. "git log --notes=notes/amlog --notes=notes/other"
would probably be the way to go.
- While reviewing the "inbox", I sometimes wonder if I applied a message
to somewhere already, but there is no obvious way to grep in the notes
tree and get the object name that a note is attached to. Of course I
know I can "git grep -c johan@herland.net notes/amlog" and it will give
me something like:
notes/amlog:65807ee697a28cb30b8ad38ebb8b84cebd3f255d:1
notes/amlog:c789176020d6a008821e01af8b65f28abc138d4b:1
but this won't scale and needs scripting to mechanize, once we start
rebalancing the notes tree with different fan-outs. The end user (me
in this case) is interested in "set of objects that match this grep
criteria", not "the pathnames the notes tree's implementation happens
to use to store notes for them in the hierarchy".
^ permalink raw reply
* Re: Testing if a certain commit is in the current branch
From: Frans Pop @ 2010-01-27 8:47 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqiqaonec1.fsf@bauges.imag.fr>
On Wednesday 27 January 2010, Matthieu Moy wrote:
> Frans Pop <elendil@planet.nl> writes:
> > I'm currently using the following command for this:
> > git log --pretty=format:%H | grep -q "^<commit id>"
> >
> > Problem is that with large repos that can be quite slow.
> >
> > Is there a faster way to do the test?
>
> Not answering the question exactly, but "git branch --contains
> <commitid>" does almost this and a bit more.
Thanks. That would work as:
git branch --contains <commitid> | grep -q "^\*"
It's a lot slower than Junio's solution though (and even slower than my
original solution).
Cheers,
FJP
^ permalink raw reply
* Re: Testing if a certain commit is in the current branch
From: Johannes Schindelin @ 2010-01-27 8:56 UTC (permalink / raw)
To: Frans Pop; +Cc: git
In-Reply-To: <201001270819.39819.elendil@planet.nl>
Hi,
On Wed, 27 Jan 2010, Frans Pop wrote:
> I'm currently using the following command for this:
> git log --pretty=format:%H | grep -q '^<commit id>"
>
> Problem is that with large repos that can be quite slow.
>
> Is there a faster way to do the test?
You are more likely looking for "git branch --contains". But this gives
you _more_ information.
Ciao,
Dscho
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox