git mailinfo with patch parser
git mailinfo splits a message into headers, commit message, and patch text, but does not actually parse the patch text. As a result, the patch portion produced by git mailinfo can contain something that looks like a patch, but actually isn't. Is there a way to get the patch data, as parsed by git apply or git am, and dump it back in patch format, without actually applying the patch to a working tree?
Re: git mailinfo with patch parser
* Junio C. Hamano: >> Is there a way to get the patch data, as parsed by git apply or git >> am, and dump it back in patch format, without actually applying the >> patch to a working tree? > > So, "the patch data as used by apply" is what you get from mailinfo. > If it is a patch that applies to what you have in the working tree > and/or the index is something you can/must ask "git apply". IOW, > when "git mailinfo" stored in $GIT_DIR/rebase-apply/patch the > "remainder" of the message, you could > > git apply --check [--index] $GIT_DIR/rebase-apply/patch > > to see if it is an OK patch. If it is, then there is no need to > further "dump it back in patch format"; what you just fed to "apply > --check" is already in the patch format. Yes, but that requires a fully patched up Git repository containing the right blobs. We know from experience that it is easy for humans to misread patches and fail to notice that certain patch hunks are actually ignored by git apply and similar tools. If there was a way to feed the patch through the parser and serialize it back, these discrepancies would be more noticeable, I think. Any data ignored by git apply/git am would be missing from the output.
Re: [PATCH v2] rev-parse: check lookup'ed commit references for NULL
On 05/24/2018 04:04 PM, Todd Zullinger wrote: I added Florian to Cc, in case he wants to provide a preferred address. Sorry, using this address is fine. Thanks, Florian
Produce contents of index with existing directory as cache
Is there a variant of “git checkout-index” which will produce the existing index contents, like “git checkout-index” would do with an empty directory, but can reuse an existing directory tree, to avoid writing all files from scratch? I'm writing some analysis scripts which need to change a checked-out working tree. Right now I'm throwing away the tree after making the changes and create the next tree (which is expected to be quite similar in contents) from scratch, starting with an empty directory. This is quite slow. Thanks, Florian
Re: Produce contents of index with existing directory as cache
On 08/30/2017 04:15 PM, David Lloyd wrote: > git reset --hard ? That doesn't remove unstaged files. Florian
Re: Produce contents of index with existing directory as cache
On 08/30/2017 04:55 PM, David Lloyd wrote: > On Wed, Aug 30, 2017 at 9:18 AM, Florian Weimer wrote: >> On 08/30/2017 04:15 PM, David Lloyd wrote: >>> git reset --hard ? >> >> That doesn't remove unstaged files. > Ah, does it not? Perhaps add a "git clean -d -f" as well. It would have to be “git clean -d -f -f -x” (not the two “-f”) to be on the safe side. I wonder what else I'm missing, though, and if this is completely reliable and has the same effect as removing the tree before “git checkout-index”. Thanks, Florian
Is git am supposed to decode MIME?
The git am documentation talks about “mailboxes”. I suppose these contain messages in Internet Mail syntax. Is git am supposed to decode MIME? I'm asking because I have a message whose body is encoded as quoted-printable, but git am does not parse the patch contained in it. If git am is supposed to deal with this, I'll dig deeper and try to figure out where things go wrong. Thanks, Florian
Special strings in commit messages
I have a commit which looks like this: $ git cat-file commit 4ca76eb7b47724c2444dfea7890fa8db4edd5762 tree c845be47a0653624b1984d0dc1a0b485b527811d parent 9eee98638ef06149e17f94afaa357e3a9e296e69 author Florian Weimer 1507481682 +0200 committer Florian Weimer 1507481682 +0200 19: glibc-fedora-nis-rh188246.patch From baba5d9461d4e8a581ac26fe4412ad783ffc73e7 Mon Sep 17 00:00:00 2001 From: Jakub Jelinek Date: Mon, 1 May 2006 08:02:53 + Subject: [PATCH] Enable SETENT_BATCH_READ nis/nss option by default * Mon May 1 2006 Jakub Jelinek 2.4.90-4 - SETENT_BATCH_READ /etc/default/nss option for speeding up some usages of NIS+ (#188246) This commit causes git rebase to fail, with this error: fatal: could not parse .git/rebase-apply/0008 At this point, .git/rebase-apply/0008 contains this: “ From baba5d9461d4e8a581ac26fe4412ad783ffc73e7 Mon Sep 17 00:00:00 2001 From: Jakub Jelinek Date: Mon, 1 May 2006 08:02:53 + Subject: [PATCH] Enable SETENT_BATCH_READ nis/nss option by default * Mon May 1 2006 Jakub Jelinek 2.4.90-4 - SETENT_BATCH_READ /etc/default/nss option for speeding up some usages of NIS+ (#188246) --- nis/nss | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/nis/nss b/nis/nss index 0ac6774a1ff29f012efaec9c4be1fcc3b83da7e8..d720e719267db5f741b67e7b98e4052e503c4333 100644 ” Followed by the diff. The preceding patch, .git/rebase-apply/0007, is: “ [fweimer@oldenburg glibc-patches]$ cat .git/rebase-apply/0007 From 4ca76eb7b47724c2444dfea7890fa8db4edd5762 Mon Sep 17 00:00:00 2001 From: Florian Weimer Date: Sun, 8 Oct 2017 18:54:42 +0200 Subject: 19: glibc-fedora-nis-rh188246.patch ” Based on strace output, something in git rebase calls git mailsplit, and it probably sees the "\nFrom " string and treats it as a start of a new mail message, and things go downhill from there. I will escape "\nFrom " in commit messages (probably as "\n.From " or maybe "\n>From ", plus escaping for "\n."/"\n>" to make the encoding reversible), but I wonder if there is something else I need to escape while I'm at it. Thanks, Florian
Re: Special strings in commit messages
On 10/08/2017 11:30 PM, Eric Wong wrote:
diff --git a/git-rebase--am.sh b/git-rebase--am.sh
index 6e64d40d6f..14c50782e0 100644
--- a/git-rebase--am.sh
+++ b/git-rebase--am.sh
@@ -53,6 +53,7 @@ else
git format-patch -k --stdout --full-index --cherry-pick --right-only \
--src-prefix=a/ --dst-prefix=b/ --no-renames --no-cover-letter \
+ --pretty=mboxrd \
$git_format_patch_opt \
"$revisions" ${restrict_revision+^$restrict_revision} \
>"$GIT_DIR/rebased-patches"
@@ -83,6 +84,7 @@ else
fi
git am $git_am_opt --rebasing --resolvemsg="$resolvemsg" \
+ --patch-format=mboxrd \
$allow_rerere_autoupdate \
${gpg_sign_opt:+"$gpg_sign_opt"} <"$GIT_DIR/rebased-patches"
ret=$?
My context is slightly different, but I added the mboxrd options
manually to both commands, and it fixes my test case.
I'm still wondering if I have to be on the lookout for similar issues
with different strings.
Thanks,
Florian
Re: Is git am supposed to decode MIME?
On 10/04/2017 11:25 AM, Jeff King wrote:
On Wed, Oct 04, 2017 at 10:44:31AM +0200, Florian Weimer wrote:
The git am documentation talks about “mailboxes”. I suppose these contain
messages in Internet Mail syntax. Is git am supposed to decode MIME?
I'm asking because I have a message whose body is encoded as
quoted-printable, but git am does not parse the patch contained in it.
If git am is supposed to deal with this, I'll dig deeper and try to figure
out where things go wrong.
Yes, it should. I just double-checked with the toy patch patch below,
and it correctly extracted the quoted-printable from the commit message
and patch, as well as in the headers.
It took me a while, but I know think the message is simply corrupted.
It's encoded with quoted-printable, and that looks correct, but it ends
with:
@@ -5137,11 +5114,13 @@ __libc_mallopt (int param_number, int value)
if (__malloc_initialized < 0)
ptmalloc_init ();
__libc_lock_lock (av->mutex);
- /* Ensure initialization/consolidation */
- malloc_consolidate (av);
=20
LIBC_PROBE (memory_mallopt, 2, param_number, value);
=20
+ /* We must consolidate main arena before changing max_fast
+ (see definition of set_max_fast). */
+ malloc_consolidate (av);
+
switch (param_number)
{
case M_MXFAST:=
The “=” masks the final newline, and that doesn't decode into a valid
diff hunk. The file being patched continues after that, so it's not
even the “\ No newline at end of file” case.
So in short, there is no Git bug here, and I just failed to interpret
the “git am” diagnostics correctly:
Applying: Improve malloc initialization sequence
error: corrupt patch at line 342
Patch failed at 0001 Improve malloc initialization sequence
The copy of the patch that failed is found in: .git/rebase-apply/patch
Line 342 refers to the file in .git/rebase-apply/patch, not the original
input, and it took me a while to figure that out.
Thanks,
Florian
Re: Deleting a branch after merging it results in "there may be uncommitted changes"
On 10/05/2017 05:04 AM, Joshua Lamusga wrote: Anyway, I follow a very simple merging model for this one-person project. Recently, I made a new local branch off of develop called feature-printing. After checking out feature-printing, making my changes, and committing changes, I merged it with develop. I then immediately tried to delete feature-printing, which resulted in a prompt asking if I was sure since it might contain uncommitted changes. Though I've seen this problem many times on the internet, I haven't seen it in the context of literally just merging. There are 0 steps between merging and deleting the old branch. What's the exact warning? It seems unlikely that your Git interface would complain about *uncommitted* changes in this context. All of this is done in Visual Studio's GUI for Git. Any ideas? Maybe ask on a Visual Studio forum instead, in case this is something generated by the front end? Florian
Re: fix mktemp (remove mktemp ;)
* Herbert Xu: > Paul Jackson <[EMAIL PROTECTED]> wrote: >> >> Even mktemp(1) can collide, in theory, since there is no practical way >> in shell scripts to hold open and locked the file from the instant of it >> is determined to be a unique name. > > mktemp(1) creates the file before exiting. Other instances of mktemp(1) > cannot successfully create the same file (they all use O_EXCL). > Therefore this race does not exist, even in theory :) /tmp cleaners exist, but the risks are minimal for programs which aren't SUID/SGID. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
