Re: Tool/Scripts - For maintaining different branches on a repo
On Sat, Jun 21, 2014 at 4:00 AM, brian m. carlson sand...@crustytoothpaste.net wrote: On Thu, Jun 19, 2014 at 04:18:22PM +0530, Jagan Teki wrote: Hi, I have a single repo with different kinds of branches say 4 branches. Developers will send a patches wrt to specific branch. I presume here that you're referring to emailed patches, or patches in independent files, as opposed to just having branches with commits. Let me clear my requirement: I'm using Thunderbird, the tool will pick the patches with _defined_ subject prefix and apply the respective branches as I inputting. Please let me know if you still have any clarity. Is there any opensource tool/script that does applying patches/maintaining the branches in repo w/o manual intervention? If you want something that works with patches specifically, TopGit might do what you want. If what you're looking for is a tool that accepts patches and automatically applies them, I'm not aware of one. It shouldn't be terribly difficult to script, though. If you don't need to deal with patches and can instead deal with git repositories, GitLab and Gitorious offer merge requests, which might make life easier. I have heard that GitLab is less painful to set up. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 thanks! -- Jagan. -- 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] gitk: catch mkdtemp errors
On Wed, Jun 18, 2014 at 07:53:14PM -0700, David Aguilar wrote: 105b5d3fbb1c00bb0aeaf9d3e0fbe26a7b1993fc introduced a dependency on mkdtemp, which is not available on Windows. Use the original temporary directory behavior when mkdtemp fails. This makes the code use mkdtemp when available and gracefully fallback to the existing behavior when it is not available. Helped-by: Junio C Hamano gits...@pobox.com Helped-by: brian m. carlson sand...@crustytoothpaste.net Signed-off-by: David Aguilar dav...@gmail.com Thanks, applied (with slight modification to commit message). Paul. -- 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] gitk: catch mkdtemp errors
On Thu, Jun 26, 2014 at 01:47:36PM -0700, Junio C Hamano wrote: David Aguilar dav...@gmail.com writes: 105b5d3fbb1c00bb0aeaf9d3e0fbe26a7b1993fc introduced a dependency on mkdtemp, which is not available on Windows. Use the original temporary directory behavior when mkdtemp fails. This makes the code use mkdtemp when available and gracefully fallback to the existing behavior when it is not available. Helped-by: Junio C Hamano gits...@pobox.com Helped-by: brian m. carlson sand...@crustytoothpaste.net Signed-off-by: David Aguilar dav...@gmail.com --- In the meantime, I've fetched from you and merged up to your master~2 aka 17f9836c (gitk: Show staged submodules regardless of ignore config, 2014-04-08). I have applied and pushed out this patch, along with one from Max Kirillov, so please do another fetch. Thanks, Paul. -- 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: Is it possible to list unpushed tags without accessing remote?
Junio C Hamano gits...@pobox.com writes: But then in order to learn what tags the remote has, you need to talk to the remote and it won't be complately a local operation anymore, no? Just like for every other remote ref. If you need to know the ultimative truth the only way is to ask the remote. Your local copy is just a cache that may be outdated any time. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- 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] Fix: wrong offset for CET timezone
Robin Rosenberg robin.rosenb...@dewire.com writes: $ TZ=CET date Fre 27 Jun 2014 00:08:05 CEST That only works because CET is a special zone name (POSIX time zones require at least a number to denote the standard offset), similar to Europe/Berlin but without the history. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- 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
[PATCH] stash create: Add --include-untracked and --all option to stash create
From: Kazumasa Shigeta shig...@kanamei.co.jp
The --include-untracked option acts like the normal git stash save
--include-untracked --all but it does not change anything in working directory.
It is inconvenient stash create does not have --include-untracked option
however stash save has --include-untracked option.
It fails when using message that start with dash. It is not compatible with now.
Signed-off-by: Kazumasa Shigeta shig...@kanamei.co.jp
---
Documentation/git-stash.txt | 4 +-
git-stash.sh | 52 +-
t/t3907-stash-create-include-untracked.sh | 286 ++
3 files changed, 336 insertions(+), 6 deletions(-)
create mode 100755 t/t3907-stash-create-include-untracked.sh
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 375213f..7ff9ce6 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -16,7 +16,7 @@ SYNOPSIS
'git stash' [save [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]
[-u|--include-untracked] [-a|--all] [message]]
'git stash' clear
-'git stash' create [message]
+'git stash' create [-u|--include-untracked] [-a|--all] [message]
'git stash' store [-m|--message message] [-q|--quiet] commit
DESCRIPTION
@@ -148,7 +148,7 @@ drop [-q|--quiet] [stash]::
`stash` must be a valid stash log reference of the form
`stash@{revision}`.
-create::
+create [-u|--include-untracked] [-a|--all] [message]::
Create a stash (which is a regular commit object) and return its
object name, without storing it anywhere in the ref namespace.
diff --git a/git-stash.sh b/git-stash.sh
index 4798bcf..d636651 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -57,8 +57,35 @@ clear_stash () {
}
create_stash () {
- stash_msg=$1
- untracked=$2
+stash_msg=
+untracked=
+
+ while test $# != 0
+ do
+ case $1 in
+ -u|--include-untracked)
+ untracked=untracked
+ ;;
+ -a|--all)
+ untracked=all
+ ;;
+ --)
+ shift
+ break
+ ;;
+ -*)
+ option=$1
+ eval_gettextln error: unknown option for 'stash
create': \$option
+ To provide a message, use git stash create -- '\$option'
+ exit 1
+ ;;
+ *)
+ break
+ ;;
+ esac
+ shift
+ done
+ stash_msg=$*
git update-index -q --refresh
if no_changes
@@ -260,8 +287,25 @@ save_stash () {
fi
test -f $GIT_DIR/logs/$ref_stash ||
clear_stash || die $(gettext Cannot initialize stash)
+untracked_opt=
+case $untracked in
+ untracked)
+ untracked_opt=--include-untracked
+ break
+ ;;
+ all)
+ untracked_opt=--all
+ break
+ ;;
+esac
+
+ if test -z $untracked_opt
+ then
+ create_stash -- $stash_msg
+ else
+ create_stash $untracked_opt -- $stash_msg
+ fi
- create_stash $stash_msg $untracked
store_stash -m $stash_msg -q $w_commit ||
die $(gettext Cannot save the current status)
say Saved working directory and index state $stash_msg
@@ -584,7 +628,7 @@ clear)
;;
create)
shift
- create_stash $* echo $w_commit
+ create_stash $@ echo $w_commit
;;
store)
shift
diff --git a/t/t3907-stash-create-include-untracked.sh
b/t/t3907-stash-create-include-untracked.sh
new file mode 100755
index 000..c28ed0f
--- /dev/null
+++ b/t/t3907-stash-create-include-untracked.sh
@@ -0,0 +1,286 @@
+#!/bin/sh
+#
+# File: t3907-stash-create-include-untracked.sh
+# Author: shigeta
+#
+# Created on 2014/05/01, 13:13:15
+
+test_description='Test git stash create --include-untracked and --all'
+
+. ./test-lib.sh
+
+cat .gitignore EOF
+.gitignore
+ignored
+ignored.d/
+EOF
+
+STASH_ID_U=
+STASH_ID__INCLUDE_UNTRACKED=
+STASH_ID_A=
+STASH_ID__ALL=
+
+test_expect_success 'stash create --include-untracked and --all some dirty
working directory' '
+ echo 1 file
+ git add file
+ test_tick
+ git commit -m initial
+ echo 2 file
+ git add file
+ echo 3 file
+ test_tick
+ echo 1 file2
+ echo 1 HEAD
+ mkdir untracked
+ echo untracked untracked/untracked
+ echo ignored ignored
+ mkdir ignored.d
+ echo ignored ignored.d/untracked
+ STASH_ID_U=$(git stash create -u message1 message2 message3)
+ test_tick
+ STASH_ID__INCLUDE_UNTRACKED=$(git stash create
Tackling Git Limitations with Singular Large Line-seperated Plaintext files
Hello, As a software developer I've used git for years and have found it the perfect solution for source control. Lately I have found myself using git in a unique use-case - modifying DNA/RNA sequences and storing them in git, which are essentially software/source code for cells/life. For Bacteria and Viruses the repo's are very small 10mb compress nicely. However on the extreme end of the spectrum a human genome can run in at 50gb or say ~1gb per file/chromosome. Now, this is not the binary problem and it is not the same as storing media inside git - I have reviewed the solutions that exist for the binary problem, such as git-annex, git-media bup. But they don't provide the featureset of git and the data i'm storing is more like plaintext sourcecode with relatively small edits per commit. I have googled and asked in #git which discussion mostly revolved around these tools. The only project that holds interest is a 2009 project, git-bigfiles - however it is abit dated the author is not interested in reviving this project - referring me to git-annex. Unfortunately. With that background; I wanted to discuss the problems with git and how I can contribute to the core project to best solve them. From my understanding the largest problem revolves around git's delta discovery method, holding 2 files in memory at once - is there a reason this could not be adapted to page/chunk the data in a sliding window fashion ? Are there any other issues I need to know about, is anyone else working on making git more capable of handling large source files that I can collaborate with? Thanks for your time, Jarrad -- 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] Fix: wrong offset for CET timezone
- Ursprungligt meddelande - Från: Alan Franzoni mail...@franzoni.eu Till: Robin Rosenberg robin.rosenb...@dewire.com Kopia: git@vger.kernel.org, Alan Franzoni usern...@franzoni.eu, sch...@linux-m68k.org Skickat: fredag, 27 jun 2014 10:24:23 Ämne: Re: [PATCH] Fix: wrong offset for CET timezone On Fri, Jun 27, 2014 at 12:08 AM, Robin Rosenberg robin.rosenb...@dewire.com wrote: 1 hour in winter and 2 in summer, although some standards seem to say that summer time is really called CEST, computers apply DST to CET in summer. $ TZ=UTC date Tor 26 Jun 2014 22:08:01 UTC $ TZ=CET date Fre 27 Jun 2014 00:08:05 CEST Like Andreas pointed out, this seems an implementation detail. CET is still +1, while CEST is +2. I mentioned that myself... If you take a look at the official IANA tzdata: http://www.iana.org/time-zones/repository/releases/tzdata2014e.tar.gz For europe, it's something like std: CET and dst: CEST. The current doc is not correct either; we should write something like either +1 or +2 depending on DST (there seems to be a 2dst as well which gets +3 offset); I knew there gotta be a catch. I don't think glibc is advanced enough to provide two different summer times for the same TZ. Usually the best way of handling timezones is to use the proper location format (e.g. TZ='Europe/Rome') and then letting the system pick the proper offset; we might say something like ' Europe/Rome which is +1 in winter ' in the doc, but I'd say that's nitpicking. Probably is. I think mentioning that CET can be either +1 or +2 is enough. + For example CET (here), which is nominally 1 hour ahead of UTC is encoded + as `+0100`, but when summer savings apply, CET is two hours ahead and encoded + as `+0200`). -- robin -- 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
[PATCH] resolve_gitlink_ref_recursive(): verify format of symbolic refs
When reading a symbolic ref via resolve_gitlink_ref_recursive(), check that the reference name that is pointed at is formatted correctly, using the same check as resolve_ref_unsafe() uses for non-gitlink references. This prevents bogosity like ref: ../../other/file from causing problems. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- Given that symbolic references cannot be transferred via the Git protocol, I do not expect this bug to be exploitable. refs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/refs.c b/refs.c index dc45774..7da8e7d 100644 --- a/refs.c +++ b/refs.c @@ -1273,6 +1273,9 @@ static int resolve_gitlink_ref_recursive(struct ref_cache *refs, while (isspace(*p)) p++; + if (check_refname_format(p, REFNAME_ALLOW_ONELEVEL)) + return -1; + return resolve_gitlink_ref_recursive(refs, p, sha1, recursion+1); } -- 2.0.0 -- 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: [RFC/PATCH] pager.c: replace git_config with git_config_get_string
Karsten Blees karsten.bl...@gmail.com writes: If for some reason a config string is accessed after config_cache_free() (which would be a bug), you won't notice if strings are xstrdup()ed (i.e. git will continue to run with some invalid configuration). This is IMO much worse than failing with segfault. I disagree. In most case, continuing to use the old config value is the right thing. First, config_cache_free() is called whenever _any_ configuration variable is set. So, setting core.foo also invalidates core.bar in the cache, while a user of core.bar could continue working with the old, unchanged value. Then, allowing the invalidation of a config variable at any time raises a lot of tricky cases (if a command uses a configuration variable twice, do we really want to implement and test the behavior for all combination of old/new values for both usages?). More tricky cases usually means more bugs on the user-side ... When the code really want the freshest value, it's cheap to re-query the config cache anyway. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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
[PATCH] submodule.c: use the ARRAY_SIZE macro
Use the ARRAY_SIZE macro to get the number of elements in an array. Signed-off-by: Elia Pinto gitter.spi...@gmail.com --- submodule.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/submodule.c b/submodule.c index b80ecac..48e3b44 100644 --- a/submodule.c +++ b/submodule.c @@ -965,7 +965,7 @@ static int find_first_merges(struct object_array *result, const char *path, sha1_to_hex(a-object.sha1)); init_revisions(revs, NULL); rev_opts.submodule = path; - setup_revisions(sizeof(rev_args)/sizeof(char *)-1, rev_args, revs, rev_opts); + setup_revisions(ARRAY_SIZE(rev_args)-1, rev_args, revs, rev_opts); /* save all revisions from the above list that contain b */ if (prepare_revision_walk(revs)) -- 1.7.10.4 -- 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 3/3] verify-commit: scriptable commit signature verification
Jeff King venit, vidit, dixit 16.06.2014 22:39: On Mon, Jun 16, 2014 at 01:34:20PM -0700, Junio C Hamano wrote: Your middle example above did make me think of one other thing, though. As you noted, we actually have _three_ signature types: 1. signed tags 2. signed commits 3. merges with embedded mergetag headers We already have a tool for (1). Michael is adding a tool for (2). How would one check (3) in a similar way? Hmph, somehow I misread the patch that it was for both 2 3 X-. I was just assuming it handles only (2) without checking further, so I may be wrong. But I do not think it makes sense to conflate (2) and (3). A merge commit may have both, and they are separate signatures. For that matter, is there a way to expose (3) currently, besides via --show-signature? It does not trigger %GG and friends (nor should it). It may make sense to add extra format specifiers for mergetag signatures. Though I do not use them myself, so I am not clear on what the use case is besides a manual, human verification of a particular merge. I'm afraid I'm on a weekly git schedule at best, sorry. Just trying to catch up on this: Admittedly, I simply don't know about 3.. I know only 1. and 2. (and don't remember why they are implemented differently). Are they documented/decribed somewhere? Meanwhile, I'm rebasing on top of the %G related patches by Junio and Jeff and hope to send out a v4 later today. Michael -- 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 3/3] verify-commit: scriptable commit signature verification
Michael J Gruber venit, vidit, dixit 27.06.2014 14:31: Jeff King venit, vidit, dixit 16.06.2014 22:39: On Mon, Jun 16, 2014 at 01:34:20PM -0700, Junio C Hamano wrote: Your middle example above did make me think of one other thing, though. As you noted, we actually have _three_ signature types: 1. signed tags 2. signed commits 3. merges with embedded mergetag headers We already have a tool for (1). Michael is adding a tool for (2). How would one check (3) in a similar way? Hmph, somehow I misread the patch that it was for both 2 3 X-. I was just assuming it handles only (2) without checking further, so I may be wrong. But I do not think it makes sense to conflate (2) and (3). A merge commit may have both, and they are separate signatures. For that matter, is there a way to expose (3) currently, besides via --show-signature? It does not trigger %GG and friends (nor should it). It may make sense to add extra format specifiers for mergetag signatures. Though I do not use them myself, so I am not clear on what the use case is besides a manual, human verification of a particular merge. I'm afraid I'm on a weekly git schedule at best, sorry. Just trying to catch up on this: Admittedly, I simply don't know about 3.. I know only 1. and 2. (and don't remember why they are implemented differently). Are they documented/decribed somewhere? Meanwhile, I'm rebasing on top of the %G related patches by Junio and Jeff and hope to send out a v4 later today. Michael OK, found the two commits which git log -Smergetag outputs, but no tests. A merge commit with embedded signed tag it is, then. The commit could carry it's own commit signature, couldn't it? That would suggest that we use git verify-tag to verify the embedded signed tag of a merge commit and git verify-commit to verify the commit signature. OTOH I would like these basic commands to be as strict as possible, including type-checks. Does that mean having git verify-mergetag which verifies that it is being used on a merge commit with embedded mergetag? (BTW: Is there anything keeping a non-merge commit from having an embedded (merge) tag?) Michael -- 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 3/3] verify-commit: scriptable commit signature verification
Michael J Gruber venit, vidit, dixit 27.06.2014 14:49: Michael J Gruber venit, vidit, dixit 27.06.2014 14:31: Jeff King venit, vidit, dixit 16.06.2014 22:39: On Mon, Jun 16, 2014 at 01:34:20PM -0700, Junio C Hamano wrote: Your middle example above did make me think of one other thing, though. As you noted, we actually have _three_ signature types: 1. signed tags 2. signed commits 3. merges with embedded mergetag headers We already have a tool for (1). Michael is adding a tool for (2). How would one check (3) in a similar way? Hmph, somehow I misread the patch that it was for both 2 3 X-. I was just assuming it handles only (2) without checking further, so I may be wrong. But I do not think it makes sense to conflate (2) and (3). A merge commit may have both, and they are separate signatures. For that matter, is there a way to expose (3) currently, besides via --show-signature? It does not trigger %GG and friends (nor should it). It may make sense to add extra format specifiers for mergetag signatures. Though I do not use them myself, so I am not clear on what the use case is besides a manual, human verification of a particular merge. I'm afraid I'm on a weekly git schedule at best, sorry. Just trying to catch up on this: Admittedly, I simply don't know about 3.. I know only 1. and 2. (and don't remember why they are implemented differently). Are they documented/decribed somewhere? Meanwhile, I'm rebasing on top of the %G related patches by Junio and Jeff and hope to send out a v4 later today. Michael OK, found the two commits which git log -Smergetag outputs, but no tests. A merge commit with embedded signed tag it is, then. The commit could carry it's own commit signature, couldn't it? That would suggest that we use git verify-tag to verify the embedded signed tag of a merge commit and git verify-commit to verify the commit signature. OTOH I would like these basic commands to be as strict as possible, including type-checks. Does that mean having git verify-mergetag which verifies that it is being used on a merge commit with embedded mergetag? (BTW: Is there anything keeping a non-merge commit from having an embedded (merge) tag?) Michael Another observation: git merge -S branch #fix conflict git commit # Merge --continue forgets that the merge was supposed to be signed. One needs to commit -S to sign the merge. Another one: The color for merge tags in log --color is terrible (colored background)... Michael -- 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
[PATCH] log: correctly identify mergetag signature verification status
A wrong '}' made our code record the results of mergetag signature
verification incorrectly.
Fix it.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
This is the color fix...
log-tree.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index 10e6844..fdea358 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -453,9 +453,9 @@ static void show_one_mergetag(struct rev_info *opt,
verify_message, NULL)) {
if (verify_message.len = gpg_message_offset)
strbuf_addstr(verify_message, No
signature\n);
- else
- status = 0;
}
+ else
+ status = 0;
show_sig_lines(opt, status, verify_message.buf);
strbuf_release(verify_message);
--
2.0.1.563.g162087b.dirty
--
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 3/3] verify-commit: scriptable commit signature verification
Michael J Gruber venit, vidit, dixit 27.06.2014 14:49:
Michael J Gruber venit, vidit, dixit 27.06.2014 14:31:
Jeff King venit, vidit, dixit 16.06.2014 22:39:
On Mon, Jun 16, 2014 at 01:34:20PM -0700, Junio C Hamano wrote:
Your middle example above did make me think of one other thing, though.
As you noted, we actually have _three_ signature types:
1. signed tags
2. signed commits
3. merges with embedded mergetag headers
We already have a tool for (1). Michael is adding a tool for (2). How
would one check (3) in a similar way?
Hmph, somehow I misread the patch that it was for both 2 3 X-.
I was just assuming it handles only (2) without checking further, so I
may be wrong. But I do not think it makes sense to conflate (2) and (3).
A merge commit may have both, and they are separate signatures.
For that matter, is there a way to expose (3) currently, besides via
--show-signature? It does not trigger %GG and friends (nor should it).
It may make sense to add extra format specifiers for mergetag
signatures. Though I do not use them myself, so I am not clear on what
the use case is besides a manual, human verification of a particular
merge.
I'm afraid I'm on a weekly git schedule at best, sorry. Just trying to
catch up on this:
Admittedly, I simply don't know about 3.. I know only 1. and 2. (and
don't remember why they are implemented differently).
Are they documented/decribed somewhere?
Meanwhile, I'm rebasing on top of the %G related patches by Junio and
Jeff and hope to send out a v4 later today.
Michael
OK, found the two commits which git log -Smergetag outputs, but no tests.
A merge commit with embedded signed tag it is, then.
The commit could carry it's own commit signature, couldn't it?
That would suggest that we use git verify-tag to verify the embedded
signed tag of a merge commit and git verify-commit to verify the
commit signature.
OTOH I would like these basic commands to be as strict as possible,
including type-checks. Does that mean having git verify-mergetag which
verifies that it is being used on a merge commit with embedded mergetag?
... or an extension ref^{mergetag} to our machinery, defaulting to the
tag object containing the mergetag for the 2nd parent, with an optional
version ref^{mergetag}n?
OTOH, verifying a mergetag involves both looking at the signed tag and
the parent list of the commit. We probably should require signed (merge)
tags on all but the first parent. Oh Can of Worms, oh Can of Worms (Oh
Can'o'Worms to the tune of Oh Canada).
Michael
--
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
[PATCHv4 0/4] verify-commit: verify commit signatures
This is v3 rebased on current next (the %G works by Jeff Junio).
Open questions:
- Should one of git verify-{commit,tag} learn how to verify mergetags?
(Probably no, it differs from both other cases.)
- Should we do this now or go for generic git verify right away?
That depends on whether signed commits need to be verified by scripts now,
or whether mergetags are more important.
For a general command which allows different verification policies,
I'm still wondering whether we may need hooks which receive all
the relevant information in the environment. Otherwise we'll have a ton of
options such as --match-committer-uid, --verify--AllParentsHaveMergeTags,
--verify--All-ParentsAreSignedCommits, --peel-to-commit, --merge-commit-only,
...
I imagine that a generic git verify would provide git verify-{commit,tag}
aliases which call git verify with options that reproduce the current
(suggested)
behavior.
Michael J Gruber (4):
gpg-interface: provide clear helper for struct signature_check
gpg-interface: provide access to the payload
verify-commit: scriptable commit signature verification
t7510: test verify-commit
Documentation/git-verify-commit.txt | 28 +++
Makefile| 1 +
builtin.h | 1 +
builtin/merge.c | 5 +-
builtin/verify-commit.c | 93 +
command-list.txt| 1 +
commit.c| 1 +
git.c | 1 +
gpg-interface.c | 14 ++
gpg-interface.h | 2 +
pretty.c| 3 +-
t/t7510-signed-commit.sh| 20 +++-
12 files changed, 163 insertions(+), 7 deletions(-)
create mode 100644 Documentation/git-verify-commit.txt
create mode 100644 builtin/verify-commit.c
--
2.0.1.563.g162087b.dirty
--
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
[PATCHv4 2/4] gpg-interface: provide access to the payload
In contrast to tag signatures, commit signatures are put into the
header, that is between the other header parts and commit messages.
Provide access to the commit content sans the signature, which is the
payload that is actually signed. Commit signature verification does the
parsing anyways, and callers may wish to act on or display the commit
object sans the signature.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
commit.c| 1 +
gpg-interface.c | 2 ++
gpg-interface.h | 1 +
3 files changed, 4 insertions(+)
diff --git a/commit.c b/commit.c
index fb7897c..acb74b5 100644
--- a/commit.c
+++ b/commit.c
@@ -1270,6 +1270,7 @@ void check_commit_signature(const struct commit* commit,
struct signature_check
gpg_output, gpg_status);
if (status !gpg_output.len)
goto out;
+ sigc-payload = strbuf_detach(payload, NULL);
sigc-gpg_output = strbuf_detach(gpg_output, NULL);
sigc-gpg_status = strbuf_detach(gpg_status, NULL);
parse_gpg_output(sigc);
diff --git a/gpg-interface.c b/gpg-interface.c
index e71b59d..ff07012 100644
--- a/gpg-interface.c
+++ b/gpg-interface.c
@@ -9,10 +9,12 @@ static const char *gpg_program = gpg;
void signature_check_clear(struct signature_check *sigc)
{
+ free(sigc-payload);
free(sigc-gpg_output);
free(sigc-gpg_status);
free(sigc-signer);
free(sigc-key);
+ sigc-payload = NULL;
sigc-gpg_output = NULL;
sigc-gpg_status = NULL;
sigc-signer = NULL;
diff --git a/gpg-interface.h b/gpg-interface.h
index 9f0784a..37c23da 100644
--- a/gpg-interface.h
+++ b/gpg-interface.h
@@ -2,6 +2,7 @@
#define GPG_INTERFACE_H
struct signature_check {
+ char *payload;
char *gpg_output;
char *gpg_status;
char result; /* 0 (not checked),
--
2.0.1.563.g162087b.dirty
--
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
[PATCHv4 3/4] verify-commit: scriptable commit signature verification
Commit signatures can be verified using git show -s --show-signature
or the %G? pretty format and parsing the output, which is well suited
for user inspection, but not for scripting.
Provide a command verify-commit which is analogous to verify-tag: It
returns 0 for good signatures and non-zero otherwise, has the gpg output
on stderr and (optionally) the commit object on stdout, sans the
signature, just like verify-tag does.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
Documentation/git-verify-commit.txt | 28 +++
Makefile| 1 +
builtin.h | 1 +
builtin/verify-commit.c | 93 +
command-list.txt| 1 +
git.c | 1 +
6 files changed, 125 insertions(+)
create mode 100644 Documentation/git-verify-commit.txt
create mode 100644 builtin/verify-commit.c
diff --git a/Documentation/git-verify-commit.txt
b/Documentation/git-verify-commit.txt
new file mode 100644
index 000..9413e28
--- /dev/null
+++ b/Documentation/git-verify-commit.txt
@@ -0,0 +1,28 @@
+git-verify-commit(1)
+
+
+NAME
+
+git-verify-commit - Check the GPG signature of commits
+
+SYNOPSIS
+
+[verse]
+'git verify-commit' commit...
+
+DESCRIPTION
+---
+Validates the gpg signature created by 'git commit -S'.
+
+OPTIONS
+---
+-v::
+--verbose::
+ Print the contents of the commit object before validating it.
+
+commit...::
+ SHA-1 identifiers of Git commit objects.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Makefile b/Makefile
index 07ea105..b92418d 100644
--- a/Makefile
+++ b/Makefile
@@ -999,6 +999,7 @@ BUILTIN_OBJS += builtin/update-ref.o
BUILTIN_OBJS += builtin/update-server-info.o
BUILTIN_OBJS += builtin/upload-archive.o
BUILTIN_OBJS += builtin/var.o
+BUILTIN_OBJS += builtin/verify-commit.o
BUILTIN_OBJS += builtin/verify-pack.o
BUILTIN_OBJS += builtin/verify-tag.o
BUILTIN_OBJS += builtin/write-tree.o
diff --git a/builtin.h b/builtin.h
index c47c110..5d91f31 100644
--- a/builtin.h
+++ b/builtin.h
@@ -128,6 +128,7 @@ extern int cmd_update_server_info(int argc, const char
**argv, const char *prefi
extern int cmd_upload_archive(int argc, const char **argv, const char *prefix);
extern int cmd_upload_archive_writer(int argc, const char **argv, const char
*prefix);
extern int cmd_var(int argc, const char **argv, const char *prefix);
+extern int cmd_verify_commit(int argc, const char **argv, const char *prefix);
extern int cmd_verify_tag(int argc, const char **argv, const char *prefix);
extern int cmd_version(int argc, const char **argv, const char *prefix);
extern int cmd_whatchanged(int argc, const char **argv, const char *prefix);
diff --git a/builtin/verify-commit.c b/builtin/verify-commit.c
new file mode 100644
index 000..b0f8504
--- /dev/null
+++ b/builtin/verify-commit.c
@@ -0,0 +1,93 @@
+/*
+ * Builtin git commit-commit
+ *
+ * Copyright (c) 2014 Michael J Gruber g...@drmicha.warpmail.net
+ *
+ * Based on git-verify-tag
+ */
+#include cache.h
+#include builtin.h
+#include commit.h
+#include run-command.h
+#include signal.h
+#include parse-options.h
+#include gpg-interface.h
+
+static const char * const verify_commit_usage[] = {
+ N_(git verify-commit [-v|--verbose] commit...),
+ NULL
+};
+
+static int run_gpg_verify(const unsigned char *sha1, const char *buf, unsigned
long size, int verbose)
+{
+ struct signature_check signature_check;
+
+ memset(signature_check, 0, sizeof(signature_check));
+
+ check_commit_signature(lookup_commit(sha1), signature_check);
+
+ if (verbose signature_check.payload)
+ fputs(signature_check.payload, stdout);
+
+ if (signature_check.gpg_output)
+ fputs(signature_check.gpg_output, stderr);
+
+ signature_check_clear(signature_check);
+ return signature_check.result != 'G';
+}
+
+static int verify_commit(const char *name, int verbose)
+{
+ enum object_type type;
+ unsigned char sha1[20];
+ char *buf;
+ unsigned long size;
+ int ret;
+
+ if (get_sha1(name, sha1))
+ return error(commit '%s' not found., name);
+
+ buf = read_sha1_file(sha1, type, size);
+ if (!buf)
+ return error(%s: unable to read file., name);
+ if (type != OBJ_COMMIT)
+ return error(%s: cannot verify a non-commit object of type
%s.,
+ name, typename(type));
+
+ ret = run_gpg_verify(sha1, buf, size, verbose);
+
+ free(buf);
+ return ret;
+}
+
+static int git_verify_commit_config(const char *var, const char *value, void
*cb)
+{
+ int status = git_gpg_config(var, value, cb);
+ if (status)
+ return status;
+ return git_default_config(var, value, cb);
+}
+
+int cmd_verify_commit(int argc, const char **argv, const char
[PATCHv4 1/4] gpg-interface: provide clear helper for struct signature_check
The struct has been growing members whose malloced memory needs to be
freed. Do this with one helper function so that no malloced memory shall
be left unfreed.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
builtin/merge.c | 5 +
gpg-interface.c | 12
gpg-interface.h | 1 +
pretty.c| 3 +--
4 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index b49c310..86e9c61 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -1282,10 +1282,7 @@ int cmd_merge(int argc, const char **argv, const char
*prefix)
printf(_(Commit %s has a good GPG signature by
%s\n),
hex, signature_check.signer);
- free(signature_check.gpg_output);
- free(signature_check.gpg_status);
- free(signature_check.signer);
- free(signature_check.key);
+ signature_check_clear(signature_check);
}
}
diff --git a/gpg-interface.c b/gpg-interface.c
index 8b0e874..e71b59d 100644
--- a/gpg-interface.c
+++ b/gpg-interface.c
@@ -7,6 +7,18 @@
static char *configured_signing_key;
static const char *gpg_program = gpg;
+void signature_check_clear(struct signature_check *sigc)
+{
+ free(sigc-gpg_output);
+ free(sigc-gpg_status);
+ free(sigc-signer);
+ free(sigc-key);
+ sigc-gpg_output = NULL;
+ sigc-gpg_status = NULL;
+ sigc-signer = NULL;
+ sigc-key = NULL;
+}
+
void set_signing_key(const char *key)
{
free(configured_signing_key);
diff --git a/gpg-interface.h b/gpg-interface.h
index a85cb5b..9f0784a 100644
--- a/gpg-interface.h
+++ b/gpg-interface.h
@@ -13,6 +13,7 @@ struct signature_check {
char *key;
};
+extern void signature_check_clear(struct signature_check *sigc);
extern int sign_buffer(struct strbuf *buffer, struct strbuf *signature, const
char *signing_key);
extern int verify_signed_buffer(const char *payload, size_t payload_size,
const char *signature, size_t signature_size, struct strbuf *gpg_output, struct
strbuf *gpg_status);
extern int git_gpg_config(const char *, const char *, void *);
diff --git a/pretty.c b/pretty.c
index ce3bbaa..353af81 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1520,8 +1520,7 @@ void format_commit_message(const struct commit *commit,
free(context.commit_encoding);
unuse_commit_buffer(commit, context.message);
- free(context.signature_check.gpg_output);
- free(context.signature_check.signer);
+ signature_check_clear(context.signature_check);
}
static void pp_header(struct pretty_print_context *pp,
--
2.0.1.563.g162087b.dirty
--
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: How to populate index/worktree when recursive merge merges multiple common ancestors?
On Thu, Jun 26, 2014 at 10:50 PM, Christian Halstrick christian.halstr...@gmail.com wrote: Imagine git does a recursive merge between A and B and finds multiple common ancestors X1,X2 for these commits. - Does git try to create an implicit/temporary common ancestor X3 by merging X1 and X2? Yes this is the point of the recursive merge algorithm. When 1 common ancestor is found they are merged. If those again have 1 common ancestor, it proceeds recursively. :) - How should workingtree, index (stage1,2,3) look like if during that merge of common ancestors a conflict occurs? Will I see in stage2 and stage3 really see content of X1 and X2? Its done entirely in memory and never touches the working tree or index. When a conflict exists in the X1-X2 merge the conflict is preserved into the new virtual base. - How is the end user supposed to fix this? Imaging merging X1 and X2 leads to conflicts solved by the end user leading to a implicit common ancestor X3. Then merging A and B with X3 as common base again conflicts occur. They don't. The conflicts are preserved into the virtual ancestor. The user only sees the final conflicts during merging of A and B with virtual X3 as the common ancestor. Ciao Chris -- 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 -- 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: Tackling Git Limitations with Singular Large Line-seperated Plaintext files
On Fri, Jun 27, 2014 at 1:45 AM, Jarrad Hope m...@jarradhope.com wrote: As a software developer I've used git for years and have found it the perfect solution for source control. Lately I have found myself using git in a unique use-case - modifying DNA/RNA sequences and storing them in git, which are essentially software/source code for cells/life. For Bacteria and Viruses the repo's are very small 10mb compress nicely. However on the extreme end of the spectrum a human genome can run in at 50gb or say ~1gb per file/chromosome. Interesting. Unfortunately not everything is used like source code. :) Git does source code well. I don't know enough to judge if DNA/RNA sequence storage is similar enough to source code to benefit from things like `git log -p` showing deltas over time, or if some other algorithm would be more effective. From my understanding the largest problem revolves around git's delta discovery method, holding 2 files in memory at once - is there a reason this could not be adapted to page/chunk the data in a sliding window fashion ? During delta discovery Git holds like 11 files in memory at once. One T is the target file that you are trying to delta compress. The other 10 are in a window and Git compares T to each one of them in turn, selecting the file that produces the smallest delta instruction sequence to recreate T. Because T is compared to 10ish other files (the window size is tuneable), Git needs a full copy of T in memory for the entire compare step. For any single compare, T is scanned through only once. If you were doing a single compare (window size of 1), T could be on disk and paged through sequentially. The files in the window need to be held entirely in memory, along with a matching index. The actual delta compression algorithm is a Rabin-Karp sliding window hash function. Copies can be made from any part of the source file with no regard to ordering. This makes paging/chunking the source file at both compression and decompression time nearly impossible. Git jumps around the source file many times, but it allows for efficient storage for movement of long sequences within a file (e.g. move function foo() later in the file). Maybe if you limited the window to 1 and limited the hash function to avoid backing up in the source file so it could be paged, you can get somewhere. But you mentioned the files are O(1 GiB). Just buy more RAM? Modern workstations have pretty good memory capacity. -- 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
Passing rev-list options in git-filter-branch broken
Hey. When trying to rewrite svn revisions in commit messages to corresponding git commit hashes, I came across the following problem (using git 1.9.1): $ git filter-branch --msg-filter svnrev2git.py -- --date-order --all fatal: options not supported in --stdin mode Could not get the commits This seems to have been caused by 3361a548db. After reverting this commit, using --date-order appears to work again. Regards felix -- 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: [RFC/PATCH] pager.c: replace git_config with git_config_get_string
Am 27.06.2014 13:55, schrieb Matthieu Moy: Karsten Blees karsten.bl...@gmail.com writes: If for some reason a config string is accessed after config_cache_free() (which would be a bug), you won't notice if strings are xstrdup()ed (i.e. git will continue to run with some invalid configuration). This is IMO much worse than failing with segfault. I disagree. In most case, continuing to use the old config value is the right thing. First, config_cache_free() is called whenever _any_ configuration variable is set. This is illogical. An API should do the right thing, and if the right thing is to keep the old values, as you pointed out, then setting a config value shouldn't invalidate the cache (at least not automatically). I can think of only git-clone and git-init that may want to refresh the global config cache, otherwise, config_cache_free() should probably _never_ be called. Least of all as a side effect of git_config_set_multivar_in_file(), which is used to write all kinds of unrelated files that just happen to have config-file format (e.g. '.gitmodules', '.git/sequencer/opts'). So, setting core.foo also invalidates core.bar in the cache, while a user of core.bar could continue working with the old, unchanged value. But a user of an xstrdup()ed copy of core.foo would also continue to work with the old value. So if everyone keeps copies of config strings, invalidating the cache when setting a value has no effect. We could just as well not invalidate the cache and not xstrdup() strings. Perhaps we should see this as an opportunity to get rid of all the memory leaks in current config code (each string value defined in system / global config and overridden locally will currently be leaked with the 'standard' xstrdup() pattern). -- 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 v3 2/3] config: add hashtable for config parsing retrieval
Matthieu Moy matthieu@grenoble-inp.fr writes: Isn't that a bit overkill? Why not just let the caller manage a hashmap directly instead of a config_set? Because I had an experience under my belt of a painful refactoring of the_index which turned out to be not just a single array, I simply suspect that the final data structure to represent a set of config-like things will not be just a single hashmap, hence I do prefer to have one layer of abstraction struct config_set, which would contain a hashmap and possibly more. OK, I guess I overinterpreted what you meant by struct config_set. If it's a thin abstraction layer on top of the hashmap (i.e. essentially contain the hashmap, and possibly a few more metadata), then it definitely makes sense. Yup, and I do not strongly mind the initialization sequence of if you want to overlay from a file, call *_from_file() you outlined; an initialiser that takes a list of file paths to read from was merely an example and not meant to be the sole interface (it is overly rigid to be one). -- 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] gitk: catch mkdtemp errors
Paul Mackerras pau...@samba.org writes: On Thu, Jun 26, 2014 at 01:47:36PM -0700, Junio C Hamano wrote: In the meantime, I've fetched from you and merged up to your master~2 aka 17f9836c (gitk: Show staged submodules regardless of ignore config, 2014-04-08). I have applied and pushed out this patch, along with one from Max Kirillov, so please do another fetch. Thanks, will do. -- 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] stash create: Add --include-untracked and --all option to stash create
shig...@kanamei.co.jp writes:
From: Kazumasa Shigeta shig...@kanamei.co.jp
The --include-untracked option acts like the normal git stash save
--include-untracked --all but it does not change anything in working
directory.
It is inconvenient stash create does not have --include-untracked option
however stash save has --include-untracked option.
Please wrap long lines.
It fails when using message that start with dash. It is not compatible with
now.
I cannot quite parse this. What do you exactly mean by It is not
compatible with now? Do you mean with this patch, we break
backward compatibility and if so in what way?
diff --git a/git-stash.sh b/git-stash.sh
index 4798bcf..d636651 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -57,8 +57,35 @@ clear_stash () {
}
create_stash () {
- stash_msg=$1
- untracked=$2
+stash_msg=
+untracked=
Broken indentation here? We indent with tabs, not runs of spaces.
+ while test $# != 0
+ do
+ case $1 in
+ -u|--include-untracked)
+ untracked=untracked
+ ;;
+ -a|--all)
+ untracked=all
+ ;;
+ --)
+ shift
+ break
+ ;;
+ -*)
+ option=$1
+ eval_gettextln error: unknown option for 'stash
create': \$option
+ To provide a message, use git stash create -- '\$option'
+ exit 1
+ ;;
+ *)
+ break
+ ;;
+ esac
+ shift
+ done
+ stash_msg=$*
git update-index -q --refresh
if no_changes
@@ -260,8 +287,25 @@ save_stash () {
fi
test -f $GIT_DIR/logs/$ref_stash ||
clear_stash || die $(gettext Cannot initialize stash)
+untracked_opt=
+case $untracked in
+ untracked)
+ untracked_opt=--include-untracked
+ break
+ ;;
+ all)
+ untracked_opt=--all
+ break
+ ;;
+esac
+
+ if test -z $untracked_opt
+ then
+ create_stash -- $stash_msg
+ else
+ create_stash $untracked_opt -- $stash_msg
+ fi
- create_stash $stash_msg $untracked
Wouldn't it suffice to do:
create_stash ${untracked_opt:+$untracked_opt} -- $stash_msg
without if/then/else/fi?
diff --git a/t/t3907-stash-create-include-untracked.sh
b/t/t3907-stash-create-include-untracked.sh
new file mode 100755
index 000..c28ed0f
--- /dev/null
+++ b/t/t3907-stash-create-include-untracked.sh
@@ -0,0 +1,286 @@
+#!/bin/sh
+#
+# File: t3907-stash-create-include-untracked.sh
+# Author: shigeta
+#
+# Created on 2014/05/01, 13:13:15
Please discard the above lines. We can see what file it is in, and
git log knows who wrote it when. You are only risking them to
become obsolete and/or irrelevant over time without adding any real
value.
Don't we have existing test script for stash? If we do, shouldn't
this patch be appending test pieces for new mode of operation it
introduces to that existing script instead?
+test_description='Test git stash create --include-untracked and --all'
+
+. ./test-lib.sh
+
+cat .gitignore EOF
+.gitignore
+ignored
+ignored.d/
+EOF
No SP between redirect operator and the filename. Quote EOF if your
here-document does not need any variable interpolation to reduce
mental burden from readers. I.e.
cat .gitignore \EOF
foo
bar
EOF
Also in newer test scripts we try to have as little commands to be
executed outside test_expect_success set-up block as possible. The
general structure of a new test script (if we do need to add one for
this patch, which I doubt) should be along the lines of...
test_description='...'
. ./test-lib.sh
test_expect_success setup '
the first test piece typically does all the set up
cat .gitignore -\EOF
.gitignore
...
EOF
other initialisation necessary
'
test_expect_success 'explain what this second test checks' '
piece specific setup
cat expect -\EOF
expected output comes here
EOF
do the command actual
test_cmp expect actual
'
test_expect_success 'explain what this third test checks' '
...
test_done
--
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: Tackling Git Limitations with Singular Large Line-seperated Plaintext files
Shawn Pearce spea...@spearce.org writes: Git does source code well. I don't know enough to judge if DNA/RNA sequence storage is similar enough to source code to benefit from things like `git log -p` showing deltas over time, or if some other algorithm would be more effective. From my understanding the largest problem revolves around git's delta discovery method, holding 2 files in memory at once - is there a reason this could not be adapted to page/chunk the data in a sliding window fashion ? During delta discovery Git holds like 11 files in memory at once Even though the original question mentioned delta discovery, I think what was being asked is not delta in the Git sense (which your answer is about) but is can we diff two long sequences of text (that happens to consist of only 4-letter alphabet but that is a irrelevant detail) without holding both in-core in their entirety?, which is a more relevant question/desire from the application point of view. Is there a reason this could not be adapted? No, there is no particular reason why this could not. I think that the only reason we only do in-core diff is because adapting to page/chunk hasn't been anybody's high priority list of itches to scratch. -- 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] resolve_gitlink_ref_recursive(): verify format of symbolic refs
Michael Haggerty mhag...@alum.mit.edu writes: When reading a symbolic ref via resolve_gitlink_ref_recursive(), check that the reference name that is pointed at is formatted correctly, using the same check as resolve_ref_unsafe() uses for non-gitlink references. This prevents bogosity like ref: ../../other/file from causing problems. I do agree that a textual symref ref: ../../x/y that is stored in .git/HEAD or in .git/refs/L will step outside .git/ and it is problematic. But if .git/refs/heads/a/b/LINK has ref: ../../x in it, shouldn't we interpret it as referring to the ref at refs/heads/x? Given that symbolic references cannot be transferred via the Git protocol, I do not expect this bug to be exploitable. refs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/refs.c b/refs.c index dc45774..7da8e7d 100644 --- a/refs.c +++ b/refs.c @@ -1273,6 +1273,9 @@ static int resolve_gitlink_ref_recursive(struct ref_cache *refs, while (isspace(*p)) p++; + if (check_refname_format(p, REFNAME_ALLOW_ONELEVEL)) + return -1; + return resolve_gitlink_ref_recursive(refs, p, sha1, recursion+1); } -- 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] resolve_gitlink_ref_recursive(): verify format of symbolic refs
Junio C Hamano gits...@pobox.com writes:
Michael Haggerty mhag...@alum.mit.edu writes:
When reading a symbolic ref via resolve_gitlink_ref_recursive(), check
that the reference name that is pointed at is formatted correctly,
using the same check as resolve_ref_unsafe() uses for non-gitlink
references. This prevents bogosity like
ref: ../../other/file
from causing problems.
I do agree that a textual symref ref: ../../x/y that is stored in
.git/HEAD or in .git/refs/L will step outside .git/ and it is
problematic. But if .git/refs/heads/a/b/LINK has ref: ../../x
in it, shouldn't we interpret it as referring to the ref at
refs/heads/x?
Actually, the textual symrefs have been invented to replace symbolic
links used for .git/HEAD on symlink-incapable filesystems, and we do
even not let the filesystem follow symlinks. The rule we have there
are like so:
/* Follow normalized - ie refs/.. symlinks by hand */
if (S_ISLNK(st.st_mode)) {
len = readlink(path, buffer, sizeof(buffer)-1);
if (len 0) {
if (errno == ENOENT || errno == EINVAL)
/* inconsistent with lstat; retry */
goto stat_ref;
else
return NULL;
}
buffer[len] = 0;
if (starts_with(buffer, refs/)
!check_refname_format(buffer, 0)) {
strcpy(refname_buffer, buffer);
refname = refname_buffer;
if (flag)
*flag |= REF_ISSYMREF;
continue;
}
}
So we should do exactly the same check, I would think, no?
In a typical clone, the .git/refs/remotes/origin/HEAD textual
symref stores ref: refs/remotes/origin/master and it is neither
ref: master nor ref: ./master, so it should be sensible to
insist on must start with 'refs/' and its format valid.
--
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
[PATCH/RFC] config: Add config sets for config parsing retrieval
Add a hash table to cache all key-value pairs read from config files
(repo specific .git/config, user wide ~/.gitconfig and the global
/etc/gitconfig). Add two external functions `git_config_get_string` and
`git_config_get_string_multi` for querying in a non-callback manner from the
hash table.
Add a way to construct custom config sets which contain multiple config
files cached as hashmaps for value retrieval.
---
*NOTE*
Please ignore the commit message and the documentation. This is a WIP. This
patch
implements the user facing API which was discussed thoroughly in discussion
thread[1].
A more polished patch will land next week, this patch is just to give a feel
for what
I inferred from the discussion.
API functions:
1. int git_config_get_value(char *k, char **v): The most generic function,
traverses
the usual config functions for values. (internally uses the the_config_set
struct)
2. int git_configset_get_value_from(const char *key, const char **value,
const char *filename, struct config_set *cs)
For usage of this function, see the example given below.
Most of the extra API functions will be constructed on the top of this patch.
Workflow for custom config_set works like this,
char *value;
struct config_set gm_config = {NULL, 0 ,0};
git_configset_add_file(.gitmodule, gm_config);
/* Add other files similarly */
git_configset_get_value_from(key, value, .gitmodule, gm_config);
/* Work on config values free the set when done */
git_configset_clear(gm_config);
I have tested the workflow and it works fine. :)
Now, about helper functions, if I add new helper functions for get_ family like
git_config_get_string, git_config_get_int and similar, won't the helper
functions
in config.c would become redundant. Is it really necessary to write new
helper functions for the non-callback code, instead of reusing the older ones?
[1]: http://marc.info/?t=14035185021r=1w=2
Cheers,
Tanay Abhra.
Documentation/technical/api-config.txt | 26 +
cache.h| 2 +
config.c | 182 +
3 files changed, 210 insertions(+)
diff --git a/Documentation/technical/api-config.txt
b/Documentation/technical/api-config.txt
index 230b3a0..13f3f40 100644
--- a/Documentation/technical/api-config.txt
+++ b/Documentation/technical/api-config.txt
@@ -77,6 +77,32 @@ To read a specific file in git-config format, use
`git_config_from_file`. This takes the same callback and data parameters
as `git_config`.
+Querying For Specific Variables
+---
+
+For programs wanting to query for specific variables in a non-callback
+manner, the config API provides two functions `git_config_get_string`
+and `git_config_get_string_multi`.They both read values from an internal
+cache generated previously from reading the config files.
+
+`git_config_get_string` takes two parameters,
+
+- a key string in canonical flat form for which the corresponding value
+ with the highest priority (i.e. value in the repo config will be
+ preferred over value in user wide config for the same variable) will
+ be retrieved.
+
+- a pointer to a string which will point to the retrieved value.
+
+`git_config_get_string` returns 0 for success, or -1 for no value found.
+
+`git_config_get_string_multi` returns a `string_list` containing all the
+values for the key passed as parameter, sorted in order of increasing
+priority (Note: NULL values are flagged as 1, check `util` for each
+'string_list_item` for flag value).
+
+See test-config.c for usage examples.
+
Value Parsing Helpers
-
diff --git a/cache.h b/cache.h
index cbe1935..fec0a63 100644
--- a/cache.h
+++ b/cache.h
@@ -1294,6 +1294,8 @@ extern int check_repository_format_version(const char
*var, const char *value, v
extern int git_env_bool(const char *, int);
extern int git_config_system(void);
extern int config_error_nonbool(const char *);
+extern int git_config_get_string(const char *, const char **);
+extern const struct string_list *git_config_get_string_multi(const char *);
#if defined(__GNUC__)
#define config_error_nonbool(s) (config_error_nonbool(s), const_error())
#endif
diff --git a/config.c b/config.c
index a1aef1c..332d92e 100644
--- a/config.c
+++ b/config.c
@@ -9,6 +9,8 @@
#include exec_cmd.h
#include strbuf.h
#include quote.h
+#include hashmap.h
+#include string-list.h
struct config_source {
struct config_source *prev;
@@ -37,6 +39,180 @@ static struct config_source *cf;
static int zlib_compression_seen;
+struct config_hash_entry {
+ struct hashmap_entry ent;
+ char *key;
+ struct string_list value_list;
+};
+
+struct config_set {
+ struct config_set_item *item;
+ unsigned int nr, alloc;
+};
+
+struct config_set_item {
+ struct hashmap config_hash;
+ char *filename;
+ int
Re: Passing rev-list options in git-filter-branch broken
Felix Eckhofer fe...@tribut.de writes: When trying to rewrite svn revisions in commit messages to corresponding git commit hashes, I came across the following problem (using git 1.9.1): $ git filter-branch --msg-filter svnrev2git.py -- --date-order --all fatal: options not supported in --stdin mode Could not get the commits This seems to have been caused by 3361a548db. After reverting this commit, using --date-order appears to work again. Hmph, unfortunate. 3361a548 (Allow git-filter-branch to process large repositories with lots of branches., 2013-09-10) has this change: -rev_args=$(git rev-parse --revs-only $@) +git rev-parse --revs-only $@ ../parse and then later feeds ../parse from the standard input of rev-list. The --revs-only option, because --date-order *is* a rev-list related argument, is emitted by the above rev-parse, along with the tip of refs (which come from --all). But --stdin mode of rev-list is meant to receive *only* revisions, not options. When it gets to the point to accept the list of tips to start traversing from, it is too late to give it an option. Changing the above to something like: git rev-parse --revs-only --no-flags $@ ../parse would be a better workaround that would not break repositories with large number of references, but it obviously will lose --date-order option (why would it be even necessary, though? I suspect that forcing the date-order will make the resulting pack a lot worse by robbing the data stream of locality). -- 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 3/3] verify-commit: scriptable commit signature verification
Michael J Gruber g...@drmicha.warpmail.net writes: A merge commit with embedded signed tag it is, then. The commit could carry it's own commit signature, couldn't it? Yes, an integrator can choose to sign a merge he creates, merging the work by a contributor who gave him a pull-request for a tag signed by the contributor. The resulting commit will embed the contributor's signature to let historians verify the second parent, as well as the integrator's signature to allow verification of the merge result. The integrator does not need to keep the signed tag used as an implementation detail of transferring the signature of the contributor, and in general such a signed tag used only to request pulls is not available to the general public and historians after such a merge is created. As these signatures are part of a commit object, git verify-commit would be the logical place to validate them, if we were to do so. -- 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 3/3] verify-commit: scriptable commit signature verification
Michael J Gruber g...@drmicha.warpmail.net writes:
... or an extension ref^{mergetag} to our machinery, defaulting to the
tag object containing the mergetag for the 2nd parent, with an optional
version ref^{mergetag}n?
One thing you should not forget is that with mergetag, the original
tag object is not even necessary to exist in the repository, and
often the original tag will not be propagated to the general public.
You _could_ extract the necessary information from the commit that
merges a signed tag to recreate the tag, but for what purpose? Your
$commit^{mergetag}n needs to recreate the named tag object but
it is unclear to me how you envision it to be used.
--
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 v2 4/4] diff: mark any file larger than core.bigfilethreshold binary
Am 26.06.2014 19:55, schrieb Junio C Hamano:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Too large files may lead to failure to allocate memory. If it happens
here, it could impact quite a few commands that involve
diff. Moreover, too large files are inefficient to compare anyway (and
most likely non-text), so mark them binary and skip looking at their
content.
...
diff --git a/diff.c b/diff.c
index a489540..7a977aa 100644
--- a/diff.c
+++ b/diff.c
@@ -2185,8 +2185,8 @@ int diff_filespec_is_binary(struct diff_filespec *one)
one-is_binary = one-driver-binary;
else {
if (!one-data DIFF_FILE_VALID(one))
-diff_populate_filespec(one, 0);
-if (one-data)
+diff_populate_filespec(one,
DIFF_POPULATE_IS_BINARY);
+if (one-is_binary == -1 one-data)
one-is_binary = buffer_is_binary(one-data,
one-size);
if (one-is_binary == -1)
The name is misleading and forced me to read it twice before I
realized that this is populating the is-binary bit. It might make
it a bit better if you renamed it to DIFF_POPULATE_IS_BINARY_BIT or
perhaps DIFF_POPULATE_CHECK_BINARY or something. For consistency,
the other bit may want to be also renamed from SIZE_ONLY to either
(1) CHECK_SIZE_ONLY
(2) One bit for CHECK_SIZE, another for NO_CONTENTS, and optionally
make SIZE_ONLY the union of two
I do not have strong preference either way; the latter may be more
logical in that not loading contents and check size are sort of
orthogonal in that you can later choose to check, without loading
contents, only the binary-ness without checking size, but no calles
that passes a non-zero flag to the populate-filespec function will
want to slurp in the contents in practice, so in that sense we could
declare that the NO_CONENTS bit is implied.
But more importantly, would this patch actually help? For one
thing, this wouldn't (and shouldn't) help if the user wants --binary
diff out of us anyway, I suspect, but I wonder what the following
codepath in the builtin_diff() function would do:
...
} else if (!DIFF_OPT_TST(o, TEXT)
( (!textconv_one diff_filespec_is_binary(one)) ||
(!textconv_two diff_filespec_is_binary(two)) )) {
if (fill_mmfile(mf1, one) 0 || fill_mmfile(mf2, two) 0)
die(unable to read files to diff);
/* Quite common confusing case */
if (mf1.size == mf2.size
!memcmp(mf1.ptr, mf2.ptr, mf1.size)) {
if (must_show_header)
fprintf(o-file, %s, header.buf);
goto free_ab_and_return;
}
fprintf(o-file, %s, header.buf);
strbuf_reset(header);
if (DIFF_OPT_TST(o, BINARY))
emit_binary_diff(o-file, mf1, mf2, line_prefix);
else
fprintf(o-file, %sBinary files %s and %s differ\n,
line_prefix, lbl[0], lbl[1]);
o-found_changes = 1;
} else {
...
If we weren't told with --text/-a to force textual output, and
at least one of the sides is marked as binary (and this patch marks
a large blob as binary unless attributes says otherwise), we still
call fill_mmfile() on them to slurp the contents to be compared, no?
And before you get to the DIFF_OPT_TST(o, BINARY), you memcmp(3) to
check if the sides are identical, so...
Good point. So how about an additional change roughly sketched as
@@ -2223,6 +2223,14 @@ struct userdiff_driver *get_textconv(struct
diff_filespec *one)
return userdiff_get_textconv(one-driver);
}
+/* read the files in small chunks into memory and compare them */
+static int filecmp_chunked(struct diff_filespec *one,
+ struct diff_filespec *two)
+{
+ // TODO add implementation
+ return 0;
+}
+
static void builtin_diff(const char *name_a,
const char *name_b,
struct diff_filespec *one,
@@ -2325,19 +2333,26 @@ static void builtin_diff(const char *name_a,
} else if (!DIFF_OPT_TST(o, TEXT)
( (!textconv_one diff_filespec_is_binary(one)) ||
(!textconv_two diff_filespec_is_binary(two)) )) {
- if (fill_mmfile(mf1, one) 0 || fill_mmfile(mf2,two) 0)
- die(unable to read files to diff);
+
+ unsigned long size1 = diff_filespec_size(one);
+ unsigned long size2 = diff_filespec_size(two);
+
+ if (size1 == 0 || size2 == 0)
+ die(unable to retrieve file sizes for diff);
/* Quite common confusing case */
- if
Re: [PATCHv4 0/4] verify-commit: verify commit signatures
Michael J Gruber g...@drmicha.warpmail.net writes:
This is v3 rebased on current next (the %G works by Jeff Junio).
Open questions:
- Should one of git verify-{commit,tag} learn how to verify mergetags?
(Probably no, it differs from both other cases.)
If we were to teach one of them, verify-commit as part of
verifying what is recorded in the commit object, would be the
logical place to do so.
It is OK to implement only verification of signatures on commit
objects themselves, but we would need a plan for handling other
kinds of verifications later, so that we can give a stable output to
scripts.
If we decide to signal successful verification of the signature on
the commit itself one way in this implementation, that should
reliably be the way to do so even if we later add verification of
other aspects on the commit object (e.g. mergetags it carries). If
running verify-commit $commit and checking the zero-ness of its
exit status is the way, that should not change if later versions of
Git learns to verify mergetags as well; even if the given $commit
carries a mergetag that does not verify, as long as the signature in
the commit itself is valid, the script should continue to receive
success from the command.
- Should we do this now or go for generic git verify right away?
I do not think we are ready to do git verify yet. We first need
to design how verify-commit should communicate failure/success
combinations of verification of a commit that has a signature on
itself and a mergetag on one of its parents, and of a commit that
has zero or one signature on itself and two or more mergetags on its
parents. Do we fail unless all of them are found to be valid? Do
we use bits in exit status? Output to the standard output, one line
per signature verified?
--
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: [RFC/PATCH] pager.c: replace git_config with git_config_get_string
Karsten Blees karsten.bl...@gmail.com writes: Am 27.06.2014 13:55, schrieb Matthieu Moy: Karsten Blees karsten.bl...@gmail.com writes: If for some reason a config string is accessed after config_cache_free() (which would be a bug), you won't notice if strings are xstrdup()ed (i.e. git will continue to run with some invalid configuration). This is IMO much worse than failing with segfault. I disagree. In most case, continuing to use the old config value is the right thing. First, config_cache_free() is called whenever _any_ configuration variable is set. This is illogical. An API should do the right thing, and if the right thing is to keep the old values, as you pointed out, then setting a config value shouldn't invalidate the cache (at least not automatically). The reason for which setting any config value invalidates the cache is that it is _much_ simpler to implement. Less complexity, less corner-cases, less bugs. So, setting core.foo also invalidates core.bar in the cache, while a user of core.bar could continue working with the old, unchanged value. But a user of an xstrdup()ed copy of core.foo would also continue to work with the old value. Exactly like the current code does. Has it ever been even close to being a problem? What you're suggesting brings a lot more complexity in the code, and I can't imagine a case where it would have a real benefit. So, why bother? -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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: [PATCHv4 4/4] t7510: test verify-commit
Michael J Gruber g...@drmicha.warpmail.net writes: sed -e s/seventh/7th forged/ raw forged1 git hash-object -w -t commit forged1 forged1.commit + ! git verify-commit $(cat forged1.commit) test_must_fail git verify-commit ... git show --pretty=short --show-signature $(cat forged1.commit) actual1 grep BAD signature from actual1 ! grep Good signature from actual1 @@ -94,6 +110,7 @@ test_expect_success GPG 'detect fudged signature with NUL' ' cat raw forged2 echo Qwik | tr Q \000 forged2 git hash-object -w -t commit forged2 forged2.commit + ! git verify-commit $(cat forged2.commit) test_must_fail git verify-commit ... git show --pretty=short --show-signature $(cat forged2.commit) actual2 grep BAD signature from actual2 ! grep Good signature from actual2 @@ -102,6 +119,7 @@ test_expect_success GPG 'detect fudged signature with NUL' ' test_expect_success GPG 'amending already signed commit' ' git checkout fourth-signed^0 git commit --amend -S --no-edit + git verify-commit HEAD git show -s --show-signature HEAD actual grep Good signature from actual ! grep BAD signature from actual Most of the tests, unlike git show --show-signature tests, do not seem to check the output from the command. Is it because its primary interface to scripts is its exit status [*1*]? [Footnote] *1* Yes is totally an acceptable answer and a justification for not checking the output in many of these tests. -- 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: Tackling Git Limitations with Singular Large Line-seperated Plaintext files
On Fri, Jun 27, 2014 at 10:48 AM, Junio C Hamano gits...@pobox.com wrote: Even though the original question mentioned delta discovery, I think what was being asked is not delta in the Git sense (which your answer is about) but is can we diff two long sequences of text (that happens to consist of only 4-letter alphabet but that is a irrelevant detail) without holding both in-core in their entirety?, which is a more relevant question/desire from the application point of view. .. even there, there's another issue. With enough memory, the diff itself should be fairly reasonable to do, but we do not have any sane *format* for diffing those kinds of things. The regular textual diff is line-based, and is not amenable to comparing two long lines. You'll just get a diff that says the two really long lines are different. The binary diff option should work, but it is a horrible output format, and not very helpful. It contains all the relevant data (copy this chunk from here to here), but it's then shown in a binary encoding that isn't really all that useful if you want to say what are the differences between these two chromosomes. I think it might be possible to just specify a special diff algorithm (git already supports that, obviously), and just introduce a new use binary diffs with a textual representation model. But it also sounds like there might be some actual performance problem with these 1GB file delta-calculations. Which I wouldn't be surprised about at all. Jarrad - is there any public data you could give as an example and for people to play with? Linus -- 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: Tackling Git Limitations with Singular Large Line-seperated Plaintext files
On Fri, Jun 27, 2014 at 12:38 PM, Linus Torvalds torva...@linux-foundation.org wrote: I think it might be possible to just specify a special diff algorithm (git already supports that, obviously), and just introduce a new use binary diffs with a textual representation model. Another model would be to just insert newlines in the data, and use the regular textual diff on that preprocessed format. The problem of *where* to insert the newlines is somewhat interesting, since the stupid approaches (chunk it up in 64-byte lines) don't work with data insertion/deletion (all the lines will now be different just because the data is offset), but there are algorithms that handle that reasonably well, like breaking lines at certain well-defined patterns (the patterns can then be defined either explicitly or algorithmically - like calculating a hash/crc over the last rolling N characters and breaking if the result matches some modulo calculation). Linus -- 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: Tackling Git Limitations with Singular Large Line-seperated Plaintext files
-Original Message- From: Linus Torvalds Sent: Friday, June 27, 2014 15:39 On Fri, Jun 27, 2014 at 10:48 AM, Junio C Hamano gits...@pobox.com wrote: Even though the original question mentioned delta discovery, I think what was being asked is not delta in the Git sense (which your answer is about) but is can we diff two long sequences of text (that happens to consist of only 4-letter alphabet but that is a irrelevant detail) without holding both in-core in their entirety?, which is a more relevant question/desire from the application point of view. .. even there, there's another issue. With enough memory, the diff itself should be fairly reasonable to do, but we do not have any sane *format* for diffing those kinds of things. The regular textual diff is line-based, and is not amenable to comparing two long lines. You'll just get a diff that says the two really long lines are different. The binary diff option should work, but it is a horrible output format, and not very helpful. It contains all the relevant data (copy this chunk from here to here), but it's then shown in a binary encoding that isn't really all that useful if you want to say what are the differences between these two chromosomes. I think it might be possible to just specify a special diff algorithm (git already supports that, obviously), and just introduce a new use binary diffs with a textual representation model. But it also sounds like there might be some actual performance problem with these 1GB file delta-calculations. Which I wouldn't be surprised about at all. Jarrad - is there any public data you could give as an example and for people to play with? Until Jarrad replies see sample here: http://www.genomatix.de/online_help/help/sequence_formats.html The issue will be, if we talk about changes other than same length substitutions (e.g. Down's Syndrome where it has an insertion of code) would require one code per line for the diffs to work nicely. -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: Tackling Git Limitations with Singular Large Line-seperated Plaintext files
On Fri, Jun 27, 2014 at 12:55 PM, Jason Pyeron jpye...@pdinc.us wrote: The issue will be, if we talk about changes other than same length substitutions (e.g. Down's Syndrome where it has an insertion of code) would require one code per line for the diffs to work nicely. Not my area of expertise, but depending on what you are interested in - like protein encoding etc, I really think you don't need to do things character-per-character. You might want to break at interesting sequences (TATA box, and/or known long repeating sequences). So you could basically turn the one long line representation into multiple lines, by just looking for particular known interesting (or known particularly *UN*interesting) patterns, and whenever you see the pattern you create a new line, describing the pattern (TATAAA or run of 128 U), and then continue on the next line. Then you diff those semantically enriched streams instead of the raw data. But it probably depends on what you are looking for and at. Sometimes you might be looking at individual base pairs. And sometimes maybe you want to look at the codons, and consider condons that transcribe to the same amino acid to be the same, and not show up as a difference. So I could well imagine that you might want to have multiple different ways to generate these diffs. No? Linus -- 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: [PATCHv4 4/4] t7510: test verify-commit
On 27. Juni 2014 21:32:30 MESZ, Junio C Hamano gits...@pobox.com wrote: Michael J Gruber g...@drmicha.warpmail.net writes: sed -e s/seventh/7th forged/ raw forged1 git hash-object -w -t commit forged1 forged1.commit +! git verify-commit $(cat forged1.commit) test_must_fail git verify-commit ... git show --pretty=short --show-signature $(cat forged1.commit) actual1 grep BAD signature from actual1 ! grep Good signature from actual1 @@ -94,6 +110,7 @@ test_expect_success GPG 'detect fudged signature with NUL' ' cat raw forged2 echo Qwik | tr Q \000 forged2 git hash-object -w -t commit forged2 forged2.commit +! git verify-commit $(cat forged2.commit) test_must_fail git verify-commit ... Sorry for missing or mis-rebasing these. I meant to cover them all. git show --pretty=short --show-signature $(cat forged2.commit) actual2 grep BAD signature from actual2 ! grep Good signature from actual2 @@ -102,6 +119,7 @@ test_expect_success GPG 'detect fudged signature with NUL' ' test_expect_success GPG 'amending already signed commit' ' git checkout fourth-signed^0 git commit --amend -S --no-edit +git verify-commit HEAD git show -s --show-signature HEAD actual grep Good signature from actual ! grep BAD signature from actual Most of the tests, unlike git show --show-signature tests, do not seem to check the output from the command. Is it because its primary interface to scripts is its exit status [*1*]? [Footnote] *1* Yes is totally an acceptable answer and a justification for not checking the output in many of these tests. Yes, the idea was to check the exit status in all cases (the loopy subtests) and the textual output in a few exemplary ones. I didn't want to bloat the test unnecessarily. Michael -- 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
Trouble merging renamed but identical files - CONFLICT (rename/rename)
There are two identical files from the same original parent, but both were renamed in their own branches. One branch moved the file to a new folder, the other renamed the file in the same folder. Steps to reproduce the issue: git init git fetch https://github.com/pdinc-oss/CipherShed.git git fetch https://github.com/srguglielmo/CipherShed.git git checkout -b test b60070f4d0879e277f44d174a163bbb292325fea git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 CONFLICT (rename/rename): Rename TrueCrypt.sln-src/TrueCrypt.sln in branch HEAD rename TrueCrypt.sln-CipherShed.sln in a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 git reset --hard b60070f4d0879e277f44d174a163bbb292325fea git mv src/TrueCrypt.sln src/CipherShed.sln git commit -m 'renamed to be congruent with a0c84ff' git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 Sill get a CONFLICT (rename/rename): Rename TrueCrypt.sln-src/CipherShed.sln in branch HEAD rename TrueCrypt.sln-CipherShed.sln in a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 I will have many more to come, any suggestions? Repos: https://github.com/srguglielmo/CipherShed/commit/1ca13ed2271d60ba93d40bcc8db17ce d8545f172 https://github.com/pdinc-oss/CipherShed/commit/b60070f4d0879e277f44d174a163bbb29 2325fea -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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/RFC] config: Add config sets for config parsing retrieval
Tanay Abhra tanay...@gmail.com writes: API functions: 1. int git_config_get_value(char *k, char **v): The most generic function, traverses the usual config functions for values. (internally uses the the_config_set struct) This may also want to be accompanied by a set of more type-specific API functions, e.g. long git_config_get_long(char *key); unsigned long git_config_get_ulong(char *key); char *git_config_get_string(char *key); but we would need to know how the error reporting should look like for them. You would also want to add a bit more before we can call the API to be complete. Here are two that comes to my mind: - Multi-valued variables int git_config_get_multi(char *k, char ***v, int *cnt); which may allocate an array of char * and return its address in *v, while returning its length in *cnt. Alternatively, we can report the length of the array as the return value, signalling an error with a negative return value, without having the *cnt argument. - Iterating over keys Existing git_config() function signature can be kept for iterating over keys, I would think, even if we start caching the previous read of the config files from the filesystem. 2. int git_configset_get_value_from(const char *key, const char **value, const char *filename, struct config_set *cs) Having to give filename each and every time I want to know about a single variable does not make any sense to me. I would have expected the API to be more like this: struct config_set *cs = git_configset_init(); char *value; git_configset_from_file(cs, .gitmodule); git_configset_get_value(cs, submodule.kernel.update, value); There will need to be a set of config-set variant of functions that parallel the work on the_config_set variant above, e.g. long git_configset_get_long(struct config_set *, char *); int git_configset_get_multi(struct config_set *, char *, char ***, int *); int git_configset_config(struct config_set *, config_fn_t, void *); The last one is the parallel to the traditional git_config() but it walks over a specific config_set. And once this is done, you wouldn't have any separate implementation of git_config_get_value(). it will be a series of macros: #define git_config_get_value(k, v) \ git_configset_get_value(the_config_set, (k), (v)) just like all the *_cache() API that used to be functions are now implemented as macros built around corresponding *_index() API functions (defined in cache.h). -- 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
Experimental TDB support for GIT REFS
List, One of my ref transaction aims is to make define a stable public API for accessing refs. Once this is done I want to make it possible to replace the current .git/refs/* model with a different type of backend. In my case I want to add support to store all refs and reflogs in a TDB database but once we have a pluggable backend framework for refs, if someone wants to store the refs in a SQL database, that should be fairly trivial too. There are a few series queued before this becomes possible, but is anyone wants to test or play with my git can use TDB database you can find an implementation of this at https://github.com/rsahlberg/git/tree/backend-struct-tdb Most everything works (except submodules) but the code needs more work. It is also VERY LIKELY that the database schema WILL CHANGE so this is only for testing and you will need to blow the repo away and start all over again at some stage. I.e. no production use. To activate TDB support a new flag is added to the init-db and clone commands: git init --tdb-repo-name=RONNIE . This creates a new git repo and sets core.tdb_repo_name in the config. This config variable tells git to dlopen and use libtdb instead of using the files under .git/refs repo-name=RONNIE is a string that identifies the repository and all keys in the database is prefixed with repo-name + '\0' By default this will create the two database refs.tdb and logs.tdb in the repositories .git directory but it is also possible to store the databases somehwere else by adding --tdb-repo-dir=/var/lib/git/ when creating the repo. Since the keys in the database are prefixed with the repo name it is even possible to store all the refs for multiple independent repos in the same database : - First repository $ cd somewhere $ git init-db --tdb-repo-name=MyFirstRepo --tdb-repo-dir=/var/lib/git - Second repository $ cd somewhere else $ git init-db --tdb-repo-name=MySecondRepo --tdb-repo-dir=/var/lib/git This can also be a solutions for platforms lacking case sensitive filesystems where today two refs that only differ in case can not be used. The current prototype will still apply the naming collision rules that the existing files backend has. For example if you have a ref 'm' you can not create another ref 'm/foo'. I left those checks as is in order to not break compatibility between the TDB backend and the current Files backend. Please feel free to test this out. And comment. regards ronnie sahlberg -- 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: Trouble merging renamed but identical files - CONFLICT (rename/rename)
On Fri, Jun 27, 2014 at 4:47 PM, Jason Pyeron jpye...@pdinc.us wrote: There are two identical files from the same original parent, but both were renamed in their own branches. One branch moved the file to a new folder, the other renamed the file in the same folder. You have not stated what you think the issue is. You have only stated the setup. I suppose you want Git to merge without conflict in the end, though, based on your script. Is that right? Steps to reproduce the issue: git init git fetch https://github.com/pdinc-oss/CipherShed.git git fetch https://github.com/srguglielmo/CipherShed.git git checkout -b test b60070f4d0879e277f44d174a163bbb292325fea git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 CONFLICT (rename/rename): Rename TrueCrypt.sln-src/TrueCrypt.sln in branch HEAD rename TrueCrypt.sln-CipherShed.sln in a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 Git seems to be doing the correct thing here. git reset --hard b60070f4d0879e277f44d174a163bbb292325fea git mv src/TrueCrypt.sln src/CipherShed.sln git commit -m 'renamed to be congruent with a0c84ff' git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 Sill get a CONFLICT (rename/rename): Rename TrueCrypt.sln-src/CipherShed.sln in branch HEAD rename TrueCrypt.sln-CipherShed.sln in a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 Git seems to be doing the correct thing here, too. I will have many more to come, any suggestions? Maybe you meant to move the renamed file to the same folder where it exists in the merge target. I do not get a conflict when I do that. git reset --hard b60070f4d0879e277f44d174a163bbb292325fea git mv src/TrueCrypt.sln CipherShed.sln git commit -m 'renamed to be congruent with a0c84ff' git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 No conflict (on that file, anyway). Regards, Phil This message is copyright PD Inc, subject to license 20080407P00. p.s. Maybe you should remove this copyright threat in the future when you are writing to an open source community seeking help. -- 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: Passing rev-list options in git-filter-branch broken
Junio C Hamano gits...@pobox.com writes: Felix Eckhofer fe...@tribut.de writes: This seems to have been caused by 3361a548db. After reverting this commit, using --date-order appears to work again. Hmph, unfortunate. 3361a548 (Allow git-filter-branch to process large repositories with lots of branches., 2013-09-10) has this change: -rev_args=$(git rev-parse --revs-only $@) +git rev-parse --revs-only $@ ../parse and then later feeds ../parse from the standard input of rev-list. The --revs-only option, because --date-order *is* a rev-list related argument, is emitted by the above rev-parse, along with the tip of refs (which come from --all). But --stdin mode of rev-list is meant to receive *only* revisions, not options. When it gets to the point to accept the list of tips to start traversing from, it is too late to give it an option. Changing the above to something like: git rev-parse --revs-only --no-flags $@ ../parse would be a better workaround that would not break repositories with large number of references, but it obviously will lose --date-order option (why would it be even necessary, though? I suspect that forcing the date-order will make the resulting pack a lot worse by robbing the data stream of locality). As the original ../parse file will have mixture of revs (i.e. the object names) and whatever rev-list options (e.g. --date-order) you gave from the command line, here is a band-aid to sift them into two, to be applied on top of 3361a548 (Allow git-filter-branch to process large repositories with lots of branches., 2013-09-10). I wish there was a way to tell rev-parse give us only flags relevant to rev-list, don't include revs in the output, but I do not think there was ever any such option (we can get revs without any flags with --no-flags, though). git-filter-branch.sh | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/git-filter-branch.sh b/git-filter-branch.sh index ca3d539..ed55c01 100755 --- a/git-filter-branch.sh +++ b/git-filter-branch.sh @@ -255,7 +255,9 @@ else remap_to_ancestor=t fi -git rev-parse --revs-only $@ ../parse +git rev-parse --revs-only $@ ../parse.revs.flags +sed -ne '/^[0-9a-f][0-9a-f][0-9a-f]*[0-9a-f]$/p' ../parse.revs.flags ../parse.revs +sed -e '/^[0-9a-f][0-9a-f][0-9a-f]*[0-9a-f]$/d' ../parse.revs.flags ../parse.flags case $filter_subdir in ) @@ -268,7 +270,8 @@ case $filter_subdir in esac git rev-list --reverse --topo-order --default HEAD \ - --parents --simplify-merges --stdin $@ ../parse ../revs || + --parents --simplify-merges --stdin $@ \ + $(cat ../parse.flags) ../parse.revs ../revs || die Could not get the commits commits=$(wc -l ../revs | tr -d ) -- 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: Trouble merging renamed but identical files - CONFLICT (rename/rename)
-Original Message- From: Phil Hord [mailto:phil.h...@gmail.com] Sent: Friday, June 27, 2014 17:46 To: Jason Pyeron Cc: git Subject: Re: Trouble merging renamed but identical files - CONFLICT (rename/rename) On Fri, Jun 27, 2014 at 4:47 PM, Jason Pyeron jpye...@pdinc.us wrote: There are two identical files from the same original parent, but both were renamed in their own branches. One branch moved the file to a new folder, the other renamed the file in the same folder. You have not stated what you think the issue is. You have only stated the setup. Thanks, I could have said it better. I think that git should understand that I have moved a file in path only (the tree object containing the file's entry change, but not the entry it self) and that the branch from which I want to merge back (with common ancestry) has renamed the file in the same path ( the tree object is unchanged, but the entry is) such that the object is re-parented and renamed in that path. How can this be done in git or if it cannot what are the chalenges to patching git for this issue. git cat-file -p b60070f4d0879e277f44d174a163bbb292325fea # tree d8df83fc6714aab1fc1df061fcb03410e1dab1e5 git cat-file -p d8df83fc6714aab1fc1df061fcb03410e1dab1e5 # 04 tree 68bb8a223284e0f5057421217a5965128bf1d51asrc git cat-file -p 68bb8a223284e0f5057421217a5965128bf1d51a # 100644 blob 25c7d3b12bced67046359ba1e7945f82a2640147TrueCrypt.sln git cat-file -p a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 # tree 7f82a6c46f19931c3c40d44dc196cbfab7feaa72 git cat-file -p 7f82a6c46f19931c3c40d44dc196cbfab7feaa72 # 100644 blob 25c7d3b12bced67046359ba1e7945f82a2640147CipherShed.sln I suppose you want Git to merge without conflict in the end, though, based on your script. Is that right? Steps to reproduce the issue: git init git fetch https://github.com/pdinc-oss/CipherShed.git git fetch https://github.com/srguglielmo/CipherShed.git git checkout -b test b60070f4d0879e277f44d174a163bbb292325fea git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 CONFLICT (rename/rename): Rename TrueCrypt.sln-src/TrueCrypt.sln in branch HEAD rename TrueCrypt.sln-CipherShed.sln in a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 Git seems to be doing the correct thing here. git reset --hard b60070f4d0879e277f44d174a163bbb292325fea git mv src/TrueCrypt.sln src/CipherShed.sln git commit -m 'renamed to be congruent with a0c84ff' git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 Sill get a CONFLICT (rename/rename): Rename TrueCrypt.sln-src/CipherShed.sln in branch HEAD rename TrueCrypt.sln-CipherShed.sln in a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 Git seems to be doing the correct thing here, too. I will have many more to come, any suggestions? Maybe you meant to move the renamed file to the same folder where it exists in the merge target. I do not get a conflict when I do that. Are you saying I should git mv src/TrueCrypt.sln CipherShed.sln ? Then it will be in the wrong path as intended. git reset --hard b60070f4d0879e277f44d174a163bbb292325fea git mv src/TrueCrypt.sln CipherShed.sln git commit -m 'renamed to be congruent with a0c84ff' git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 No conflict (on that file, anyway). Agreed, but not the desired end state. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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
[PATCH 3/3] cache-tree: Write index with updated cache-tree after commit
During the commit process, the cache-tree is updated. We need to write
this updated cache-tree so that it's ready for subsequent commands.
Add test code which demonstrates that git commit now writes the cache
tree. Also demonstrate that cache-tree invalidation is correct.
Signed-off-by: David Turner dtur...@twitter.com
---
builtin/commit.c | 6 ++
t/t0090-cache-tree.sh | 50 +++---
2 files changed, 53 insertions(+), 3 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 9cfef6c..6814e87 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -607,6 +607,8 @@ static int prepare_to_commit(const char *index_file, const
char *prefix,
const char *hook_arg2 = NULL;
int clean_message_contents = (cleanup_mode != CLEANUP_NONE);
int old_display_comment_prefix;
+ static struct lock_file index_lock;
+ int index_fd;
/* This checks and barfs if author is badly specified */
determine_author_info(author_ident);
@@ -872,6 +874,10 @@ static int prepare_to_commit(const char *index_file, const
char *prefix,
error(_(Error building trees));
return 0;
}
+ /* After updating the cache-tree, rewrite the index */
+ index_fd = hold_locked_index(index_lock, 0);
+ if (index_fd = 0 write_index(the_index, index_fd) = 0)
+ commit_locked_index(index_lock);
if (run_commit_hook(use_editor, index_file, prepare-commit-msg,
git_path(commit_editmsg), hook_arg1, hook_arg2,
NULL))
diff --git a/t/t0090-cache-tree.sh b/t/t0090-cache-tree.sh
index 5383258..ef012b9 100755
--- a/t/t0090-cache-tree.sh
+++ b/t/t0090-cache-tree.sh
@@ -16,8 +16,31 @@ cmp_cache_tree () {
# We don't bother with actually checking the SHA1:
# test-dump-cache-tree already verifies that all existing data is
# correct.
+generate_expected_cache_tree () {
+ if [ -n $1 ]
+ then
+ local dir=$1/
+ else
+ local dir=$1
+ fi
+ # ls-files might have foo/bar, foo/bar/baz, and foo/bar/quux
+ # We want to count only foo because it's the only direct child
+ local subtrees=$(git ls-files|egrep '/' |cut -d / -f 1|uniq)
+ local subtree_count=$(echo $subtrees|grep -c .)
+ local files_count=$(git ls-files|grep -v /|wc -l)
+ local entries=$(expr $subtree_count + $files_count)
+ printf SHA $dir (%d entries, %d subtrees)\n $entries $subtree_count
+ local subtree
+ for subtree in $subtrees
+ do
+ cd $subtree
+ generate_expected_cache_tree $dir$subtree || return 1
+ cd ..
+ done
+}
+
test_shallow_cache_tree () {
- printf SHA (%d entries, 0 subtrees)\n $(git ls-files|wc -l) expect
+ generate_expected_cache_tree expect
cmp_cache_tree expect
}
@@ -35,7 +58,7 @@ test_no_cache_tree () {
cmp_cache_tree expect
}
-test_expect_failure 'initial commit has cache-tree' '
+test_expect_success 'initial commit has cache-tree' '
test_commit foo
test_shallow_cache_tree
'
@@ -60,15 +83,28 @@ test_expect_success 'git-add in subdir invalidates
cache-tree' '
test_invalid_cache_tree
'
+cat before \EOF
+SHA (3 entries, 2 subtrees)
+SHA dir1/ (1 entries, 0 subtrees)
+SHA dir2/ (1 entries, 0 subtrees)
+EOF
+
+cat expect \EOF
+invalid (2 subtrees)
+invalid dir1/ (0 subtrees)
+SHA dir2/ (1 entries, 0 subtrees)
+EOF
+
test_expect_success 'git-add in subdir does not invalidate sibling cache-tree'
'
git tag no-children
test_when_finished git reset --hard no-children; git read-tree HEAD
mkdir dir1 dir2
test_commit dir1/a
test_commit dir2/b
+ cmp_cache_tree before
echo I changed this file dir1/a
git add dir1/a
- test_invalid_cache_tree dir1/
+ cmp_cache_tree expect
'
test_expect_success 'update-index invalidates cache-tree' '
@@ -95,6 +131,14 @@ test_expect_success 'second commit has cache-tree' '
test_shallow_cache_tree
'
+test_expect_success 'commit in child dir has cache-tree' '
+ mkdir dir
+ dir/child.t
+ git add dir/child.t
+ git commit -m dir/child.t
+ test_shallow_cache_tree
+'
+
test_expect_success 'reset --hard gives cache-tree' '
test-scrap-cache-tree
git reset --hard
--
2.0.0.390.gcb682f8
--
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
[PATCH 2/3] test-dump-cache-tree: Improve output format and exit code
Make test-dump-cache-tree more useful for testing. Do not treat known
invalid trees as errors (and do not produce non-zero exit code),
because we can fall back to the non-cache-tree codepath.
Signed-off-by: David Turner dtur...@twitter.com
---
t/t0090-cache-tree.sh | 28 +---
test-dump-cache-tree.c | 24
2 files changed, 37 insertions(+), 15 deletions(-)
diff --git a/t/t0090-cache-tree.sh b/t/t0090-cache-tree.sh
index 7c60675..5383258 100755
--- a/t/t0090-cache-tree.sh
+++ b/t/t0090-cache-tree.sh
@@ -21,10 +21,13 @@ test_shallow_cache_tree () {
cmp_cache_tree expect
}
+# Test that the cache-tree for a given directory is invalid.
+# If no directory is given, check that the root is invalid
test_invalid_cache_tree () {
- echo invalid (0 subtrees) expect
- printf SHA #(ref) (%d entries, 0 subtrees)\n $(git ls-files|wc -l)
expect
- cmp_cache_tree expect
+ test-dump-cache-tree actual
+ sed -e s/$_x40/SHA/ -e s/[0-9]* subtrees//g actual filtered
+ expect=$(printf invalid $1 ()\n)
+ fgrep $expect filtered
}
test_no_cache_tree () {
@@ -49,6 +52,25 @@ test_expect_success 'git-add invalidates cache-tree' '
test_invalid_cache_tree
'
+test_expect_success 'git-add in subdir invalidates cache-tree' '
+ test_when_finished git reset --hard; git read-tree HEAD
+ mkdir dirx
+ echo I changed this file dirx/foo
+ git add dirx/foo
+ test_invalid_cache_tree
+'
+
+test_expect_success 'git-add in subdir does not invalidate sibling cache-tree'
'
+ git tag no-children
+ test_when_finished git reset --hard no-children; git read-tree HEAD
+ mkdir dir1 dir2
+ test_commit dir1/a
+ test_commit dir2/b
+ echo I changed this file dir1/a
+ git add dir1/a
+ test_invalid_cache_tree dir1/
+'
+
test_expect_success 'update-index invalidates cache-tree' '
test_when_finished git reset --hard; git read-tree HEAD
echo I changed this file foo
diff --git a/test-dump-cache-tree.c b/test-dump-cache-tree.c
index 47eab97..ad42ca1 100644
--- a/test-dump-cache-tree.c
+++ b/test-dump-cache-tree.c
@@ -6,12 +6,12 @@
static void dump_one(struct cache_tree *it, const char *pfx, const char *x)
{
if (it-entry_count 0)
- printf(%-40s %s%s (%d subtrees)\n,
- invalid, x, pfx, it-subtree_nr);
+ printf(%-40s %s (%d subtrees)%s\n,
+ invalid, pfx, it-subtree_nr, x);
else
- printf(%s %s%s (%d entries, %d subtrees)\n,
- sha1_to_hex(it-sha1), x, pfx,
- it-entry_count, it-subtree_nr);
+ printf(%s %s (%d entries, %d subtrees)%s\n,
+ sha1_to_hex(it-sha1), pfx,
+ it-entry_count, it-subtree_nr, x);
}
static int dump_cache_tree(struct cache_tree *it,
@@ -25,19 +25,19 @@ static int dump_cache_tree(struct cache_tree *it,
/* missing in either */
return 0;
- if (it-entry_count 0) {
+ if (it-entry_count 0)
+ /* invalid */
dump_one(it, pfx, );
- dump_one(ref, pfx, #(ref) );
- if (it-subtree_nr != ref-subtree_nr)
- errs = 1;
- }
else {
- dump_one(it, pfx, );
if (hashcmp(it-sha1, ref-sha1) ||
ref-entry_count != it-entry_count ||
ref-subtree_nr != it-subtree_nr) {
- dump_one(ref, pfx, #(ref) );
+ /* claims to be valid but is lying */
+ dump_one(ref, pfx, #(error));
errs = 1;
+ } else {
+ /* is actually valid */
+ dump_one(it, pfx, );
}
}
--
2.0.0.390.gcb682f8
--
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
[PATCH 1/3] cache-tree: Create/update cache-tree on checkout
When git checkout checks out a branch, create or update the
cache-tree so that subsequent operations are faster.
Signed-off-by: David Turner dtur...@twitter.com
---
builtin/checkout.c| 4
cache-tree.c | 22 --
cache-tree.h | 1 +
t/t0090-cache-tree.sh | 15 ++-
4 files changed, 31 insertions(+), 11 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 07cf555..df791e8 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -553,6 +553,10 @@ static int merge_working_tree(const struct checkout_opts
*opts,
}
}
+ if (write_cache_as_tree(NULL, WRITE_TREE_DO_NOT_WRITE, )) {
+ warn(Unable to write cache_tree);
+ }
+
if (write_cache(newfd, active_cache, active_nr) ||
commit_locked_index(lock_file))
die(_(unable to write new index file));
diff --git a/cache-tree.c b/cache-tree.c
index 7fa524a..fb203c6 100644
--- a/cache-tree.c
+++ b/cache-tree.c
@@ -568,17 +568,18 @@ static struct cache_tree *cache_tree_find(struct
cache_tree *it, const char *pat
int write_cache_as_tree(unsigned char *sha1, int flags, const char *prefix)
{
- int entries, was_valid, newfd;
+ int entries, was_valid, newfd = -1;
struct lock_file *lock_file;
- /*
-* We can't free this memory, it becomes part of a linked list
-* parsed atexit()
-*/
- lock_file = xcalloc(1, sizeof(struct lock_file));
-
- newfd = hold_locked_index(lock_file, 1);
+ if (!(flags WRITE_TREE_DO_NOT_WRITE)) {
+ /*
+* We can't free this memory, it becomes part of a linked list
+* parsed atexit()
+*/
+ lock_file = xcalloc(1, sizeof(struct lock_file));
+ newfd = hold_locked_index(lock_file, 1);
+ }
entries = read_cache();
if (entries 0)
return WRITE_TREE_UNREADABLE_INDEX;
@@ -612,9 +613,10 @@ int write_cache_as_tree(unsigned char *sha1, int flags,
const char *prefix)
cache_tree_find(active_cache_tree, prefix);
if (!subtree)
return WRITE_TREE_PREFIX_ERROR;
- hashcpy(sha1, subtree-sha1);
+ if (sha1)
+ hashcpy(sha1, subtree-sha1);
}
- else
+ else if (sha1)
hashcpy(sha1, active_cache_tree-sha1);
if (0 = newfd)
diff --git a/cache-tree.h b/cache-tree.h
index f1923ad..daf6640 100644
--- a/cache-tree.h
+++ b/cache-tree.h
@@ -39,6 +39,7 @@ int update_main_cache_tree(int);
#define WRITE_TREE_IGNORE_CACHE_TREE 2
#define WRITE_TREE_DRY_RUN 4
#define WRITE_TREE_SILENT 8
+#define WRITE_TREE_DO_NOT_WRITE 16
/* error return codes */
#define WRITE_TREE_UNREADABLE_INDEX (-1)
diff --git a/t/t0090-cache-tree.sh b/t/t0090-cache-tree.sh
index 6c33e28..7c60675 100755
--- a/t/t0090-cache-tree.sh
+++ b/t/t0090-cache-tree.sh
@@ -85,9 +85,22 @@ test_expect_success 'reset --hard without index gives
cache-tree' '
test_shallow_cache_tree
'
-test_expect_failure 'checkout gives cache-tree' '
+test_expect_success 'checkout gives cache-tree' '
+ git tag current
git checkout HEAD^
test_shallow_cache_tree
'
+test_expect_success 'checkout -b gives cache-tree' '
+ git checkout current
+ git checkout -b prev HEAD^
+ test_shallow_cache_tree
+'
+
+test_expect_success 'checkout -B gives cache-tree' '
+ git checkout current
+ git checkout -B prev HEAD^
+ test_shallow_cache_tree
+'
+
test_done
--
2.0.0.390.gcb682f8
--
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 3/3] verify-commit: scriptable commit signature verification
On Fri, Jun 27, 2014 at 11:36:47AM -0700, Junio C Hamano wrote: Michael J Gruber g...@drmicha.warpmail.net writes: A merge commit with embedded signed tag it is, then. The commit could carry it's own commit signature, couldn't it? Yes, an integrator can choose to sign a merge he creates, merging the work by a contributor who gave him a pull-request for a tag signed by the contributor. The resulting commit will embed the contributor's signature to let historians verify the second parent, as well as the integrator's signature to allow verification of the merge result. The integrator does not need to keep the signed tag used as an implementation detail of transferring the signature of the contributor, and in general such a signed tag used only to request pulls is not available to the general public and historians after such a merge is created. As these signatures are part of a commit object, git verify-commit would be the logical place to validate them, if we were to do so. We already disagreed on this earlier in the discussion, but I have given it some more thought, and somehow using verify-commit for mergetags still feels wrong to me. Let me see if I can put it into words. First off, I agree that verify-tag is probably not the right place. There _is_ no tag object to verify anymore (the only reason it is a tag at all is that the signature came out of what once was a tag). Let us imagine that we have a verify-commit that verifies commit signatures made by commit -S. If I run verify-commit foo, that implies to me two things: 1. I am verifying the signature over the contents of foo. But the mergetag is _not_ a statement about foo; the person who signed it never saw foo. It is a statement about foo^2 at best, or possibly about the whole history of foo^1..foo^2. 2. I am verifying _only_ the contents of foo. That is, I expect people to use commit -S to cryptographically claim authorship of a commit. Whereas with tags, I think we have typically taken them to mean I have signed the tip of a segment of history, and I am taking responsibility for the final state (e.g., signing release tags). I realize that this claim is somewhat tenuous. It's not something inherent in the crypto, but rather in the social convention of what it means to sign a commit. One could easily say signing a commit is about signing the whole tree state. But I would ask, then: what is the point of signing a commit versus signing a tag? I think that people who wanted commit signatures wanted them to give a stronger guarantee of authorship of individual commits. Git has largely stayed agnostic about what such signatures mean. But if we accept that some projects _are_ going to make that distinction, I think conflating verification of the two within the same command leads to a potential for confusion. So for that reason, I think I'd be in favor of simply treating mergetag signatures as a separate, third entity. Give them their own %G-specifiers, and give them a separate plumbing command. Let projects work out how they want to use them, but do not create any particular affiliation between mergetags and commit signatures (nor between tag signatures and mergetag signatures). -Peff -- 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: Experimental TDB support for GIT REFS
On Fri, Jun 27, 2014 at 2:30 PM, Ronnie Sahlberg sahlb...@google.com wrote: List, One of my ref transaction aims is to make define a stable public API for accessing refs. Once this is done I want to make it possible to replace the current .git/refs/* model with a different type of backend. In my case I want to add support to store all refs and reflogs in a TDB database but once we have a pluggable backend framework for refs, if someone wants to store the refs in a SQL database, that should be fairly trivial too. There are a few series queued before this becomes possible, but is anyone wants to test or play with my git can use TDB database you can find an implementation of this at https://github.com/rsahlberg/git/tree/backend-struct-tdb Interesting! But the link 404s :( -- 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: Trouble merging renamed but identical files - CONFLICT (rename/rename)
-Original Message- From: Jason Pyeron Sent: Friday, June 27, 2014 18:39 -Original Message- From: Phil Hord [mailto:phil.h...@gmail.com] Sent: Friday, June 27, 2014 17:46 To: Jason Pyeron Cc: git Subject: Re: Trouble merging renamed but identical files - CONFLICT (rename/rename) On Fri, Jun 27, 2014 at 4:47 PM, Jason Pyeron jpye...@pdinc.us wrote: There are two identical files from the same original parent, but both were renamed in their own branches. One branch moved the file to a new folder, the other renamed the file in the same folder. You have not stated what you think the issue is. You have only stated the setup. Thanks, I could have said it better. I think that git should understand that I have moved a file in path only (the tree object containing the file's entry change, but not the entry it self) and that the branch from which I want to merge back (with common ancestry) has renamed the file in the same path ( the tree object is unchanged, but the entry is) such that the object is re-parented and renamed in that path. How can this be done in git or if it cannot what are the chalenges to patching git for this issue. git cat-file -p b60070f4d0879e277f44d174a163bbb292325fea # tree d8df83fc6714aab1fc1df061fcb03410e1dab1e5 git cat-file -p d8df83fc6714aab1fc1df061fcb03410e1dab1e5 # 04 tree 68bb8a223284e0f5057421217a5965128bf1d51asrc git cat-file -p 68bb8a223284e0f5057421217a5965128bf1d51a # 100644 blob 25c7d3b12bced67046359ba1e7945f82a2640147TrueCrypt.sln git cat-file -p a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 # tree 7f82a6c46f19931c3c40d44dc196cbfab7feaa72 git cat-file -p 7f82a6c46f19931c3c40d44dc196cbfab7feaa72 # 100644 blob 25c7d3b12bced67046359ba1e7945f82a2640147CipherShed.sln I suppose you want Git to merge without conflict in the end, though, based on your script. Is that right? Steps to reproduce the issue: git init git fetch https://github.com/pdinc-oss/CipherShed.git git fetch https://github.com/srguglielmo/CipherShed.git git checkout -b test b60070f4d0879e277f44d174a163bbb292325fea git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 CONFLICT (rename/rename): Rename TrueCrypt.sln-src/TrueCrypt.sln in branch HEAD rename TrueCrypt.sln-CipherShed.sln in a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 Git seems to be doing the correct thing here. git reset --hard b60070f4d0879e277f44d174a163bbb292325fea git mv src/TrueCrypt.sln src/CipherShed.sln git commit -m 'renamed to be congruent with a0c84ff' git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 Sill get a CONFLICT (rename/rename): Rename TrueCrypt.sln-src/CipherShed.sln in branch HEAD rename TrueCrypt.sln-CipherShed.sln in a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 Git seems to be doing the correct thing here, too. I will have many more to come, any suggestions? Maybe you meant to move the renamed file to the same folder where it exists in the merge target. I do not get a conflict when I do that. Are you saying I should git mv src/TrueCrypt.sln CipherShed.sln ? Then it will be in the wrong path as intended. git reset --hard b60070f4d0879e277f44d174a163bbb292325fea git mv src/TrueCrypt.sln CipherShed.sln git commit -m 'renamed to be congruent with a0c84ff' git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 No conflict (on that file, anyway). Agreed, but not the desired end state. Sorry for the http://pastebin.com/1R68v6jt (changes the merge to 1ca13ed2271d60ba93d40bcc8db17ced8545f172, and manually reconciles the merge), but it was too long to be readable in the email. git blame HEAD -- src/Main/Forms/CipherShed.fbp | cut -c 1-8 | sort -u Gives: ac812aa3 b50a2fb1 git blame b60070f4d0879e277f44d174a163bbb292325fea -- src/Main/Forms/TrueCrypt.fbp | cut -c 1-8 | sort -u Gives: 07b2176f 0eb8b4fa 12c94add a17c95a3 a757b4d4 cac6cd14 d0a9dfa8 d94128a9 e6b1437a f1bb489c If I use cherry pick (vs merge), I can maintain the big history in b60070f, but loose the small history in 1ca13ed [test] / \ / \ [b60070f] [1ca13ed] | | | | [65efd37] | |\| | \ | [d8da778] [39ebb06] How do I maintain all the history including the (line) changes in 1ca13ed? -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- To unsubscribe from this
Re: [PATCH] log: correctly identify mergetag signature verification status
On Fri, Jun 27, 2014 at 03:18:36PM +0200, Michael J Gruber wrote:
A wrong '}' made our code record the results of mergetag signature
verification incorrectly.
Fix it.
I think this is the right thing to do, but we went from:
if (...)
if (...) {
if (...)
...
else
...
}
to:
if (...)
if (...) {
if (...)
...
}
else
...
I think part of the point of the original {} was to make it more clear
which else went with which if. Perhaps we should use more here.
I also find the logic a bit hard to follow in that the outer conditions are:
if (needed_for_goodsig)
if (sig_is_not_good)
...
Perhaps it would be easier to read (and would have made the logic error
you are fixing more obvious) as:
if (extra-len payload_size) {
if (!verify_signed_buffer(...))
status = 0; /* good; all other code paths leave it as -1 */
else if (verify_message.len = gpg_message_offset)
strbuf_addstr(verify_message, No signature\n);
}
That is, for each conditional to check one more thing needed for a good
signature, and then know that all other code paths leave status as -1.
-Peff
--
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: [PATCHv4 0/4] verify-commit: verify commit signatures
On Fri, Jun 27, 2014 at 12:07:35PM -0700, Junio C Hamano wrote: - Should we do this now or go for generic git verify right away? I do not think we are ready to do git verify yet. If there is one thing that this discussion have convinced me of, it is this. :) -Peff -- 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: [PATCHv4 0/4] verify-commit: verify commit signatures
On Fri, Jun 27, 2014 at 04:13:22PM +0200, Michael J Gruber wrote: This is v3 rebased on current next (the %G works by Jeff Junio). Aside from the minor test issues Junio pointed out, I think this version looks OK. For a general command which allows different verification policies, I'm still wondering whether we may need hooks which receive all the relevant information in the environment. Otherwise we'll have a ton of options such as --match-committer-uid, --verify--AllParentsHaveMergeTags, --verify--All-ParentsAreSignedCommits, --peel-to-commit, --merge-commit-only, ... I'd guess these would be project policies that could go in config. But I do not think your series needs to be concerned with that yet. -Peff -- 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: [RFC/PATCH] pager.c: replace git_config with git_config_get_string
Am 27.06.2014 21:19, schrieb Matthieu Moy:
The reason for which setting any config value invalidates the cache is
that it is _much_ simpler to implement. Less complexity, less
corner-cases, less bugs.
I think I see what you mean. E.g. in cmd_clone we have:
write_config(option_config);
git_config(git_default_config, NULL);
...
git_config_set(remote.Foo.url, repo);
...
remote = remote_get(option_origin); /* which does 'git_config(handle_config)'
*/
So if we load the config cache at 'git_config(git_default_config)', then
'remote_get' won't see remote.Foo.url unless we invalidate the cache first.
I still don't like that the invalidation is done in git_config_set, though, as
this is also used to write completely unrelated files. Wouldn't it be better to
have a 'git_config_refresh()' that could be used in place of (or before) current
'git_config(callback)' calls? The initial implementation could just invalidate
the config cache. If there's time and energy to spare, a more advanced version
could first check if any of the involved config files has changed.
The xstrdup() problem could be solved by interning strings (see the
attached patch for a trivial implementation). I.e. allocate each distinct
string only once (and keep it allocated).
So if there are 100 instances of true in the config file, the interned string
pool would contain only one instance (i.e. 5 bytes + hashmap_entry + malloc
overhead, vs. 100 * (5 bytes + malloc overhead) in case of xstrdup()). If the
config cache is cleared, the interned string in the pool would still remain
valid. If the config cache is reloaded, unmodified values would reuse the
existing strings from the pool.
Side note: interning getenv() results would fix the non-POSIX-compliant
getenv()-usage in git [1].
[1] https://groups.google.com/d/msg/msysgit/4cVWWJkN4to/DR8FGTQ09Q0J
8
Subject: [PATCH] hashmap: add string interning API
Interning short strings that are likely to have multiple copies may reduce
memory footprint and speed up string comparisons.
Add a strintern() API that uses a hashmap to manage the pool of interned
strings.
Signed-off-by: Karsten Blees bl...@dcon.de
---
Documentation/technical/api-hashmap.txt | 11 +++
hashmap.c | 34 +
hashmap.h | 4
t/t0011-hashmap.sh | 13 +
test-hashmap.c | 14 ++
5 files changed, 76 insertions(+)
diff --git a/Documentation/technical/api-hashmap.txt
b/Documentation/technical/api-hashmap.txt
index b977ae8..db7c955 100644
--- a/Documentation/technical/api-hashmap.txt
+++ b/Documentation/technical/api-hashmap.txt
@@ -162,6 +162,17 @@ more entries.
`hashmap_iter_first` is a combination of both (i.e. initializes the iterator
and returns the first entry, if any).
+`const char *strintern(const char *string)`::
+
+ Returns the unique, interned version of the specified string, similar
+ to the `String.intern` API in Java and .NET. Interned strings remain
+ valid for the entire lifetime of the process.
++
+Can be used as `[x]strdup()` replacement, except that the interned string must
+not be modified or freed.
++
+Uses a hashmap to store the pool of interned strings.
+
Usage example
-
diff --git a/hashmap.c b/hashmap.c
index d1b8056..03cd8f3 100644
--- a/hashmap.c
+++ b/hashmap.c
@@ -226,3 +226,37 @@ void *hashmap_iter_next(struct hashmap_iter *iter)
current = iter-map-table[iter-tablepos++];
}
}
+
+struct string_pool_entry {
+ struct hashmap_entry ent;
+ char key[FLEX_ARRAY];
+};
+
+static int string_pool_cmp(const struct string_pool_entry *e1,
+ const struct string_pool_entry *e2,
+ const char *key)
+{
+ return strcmp(e1-key, key ? key : e2-key);
+}
+
+const char *strintern(const char *string)
+{
+ static struct hashmap map;
+ struct string_pool_entry key, *e;
+ /* initialize string pool hashmap */
+ if (!map.tablesize)
+ hashmap_init(map, (hashmap_cmp_fn) string_pool_cmp, 0);
+
+ /* lookup interned string in pool */
+ hashmap_entry_init(key, strhash(string));
+ e = hashmap_get(map, key, string);
+ if (!e) {
+ /* not found: create it */
+ int len = strlen(string);
+ e = xmalloc(sizeof(struct string_pool_entry) + len + 1);
+ hashmap_entry_init(e, key.ent.hash);
+ memcpy(e-key, string, len + 1);
+ hashmap_add(map, e);
+ }
+ return e-key;
+}
diff --git a/hashmap.h b/hashmap.h
index a816ad4..b428677 100644
--- a/hashmap.h
+++ b/hashmap.h
@@ -68,4 +68,8 @@ static inline void *hashmap_iter_first(struct hashmap *map,
return hashmap_iter_next(iter);
}
+/* string interning */
+
+extern const char *strintern(const char *string);
+
#endif
[PATCH] Documentation: Mention '--subject-prefix' in git-send-email's manual
This commit adds a mention to the '--subject-prefix' option in git-send-email's documentation. This option is already described in git-format-patch's docs (because it belongs to this command, actually), but it is very useful when you are submitting patches using git-send-email too, for obvious reasons. The text describing the option has been adapted from git-format-patch, in order to be self-contained and not mention other options that are not present in git-send-email's docs (e.g., '--numbered'). Signed-off-by: Sergio Durigan Junior sergi...@sergiodj.net --- Documentation/git-send-email.txt | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt index a60776e..76f531a 100644 --- a/Documentation/git-send-email.txt +++ b/Documentation/git-send-email.txt @@ -110,6 +110,13 @@ is not set, this will be prompted for. Only necessary if --compose is also set. If --compose is not set, this will be prompted for. +--subject-prefix=Subject-Prefix:: + Instead of the standard '[PATCH]' prefix in the subject + line, instead use '[Subject-Prefix]'. This is useful if you + are sending an RFC instead of a patch, or if the patch version + has been bumped (e.g., '[PATCH v2]'). See also + linkgit:git-format-patch[1]. + --to=address:: Specify the primary recipient of the emails generated. Generally, this will be the upstream maintainer of the project involved. Default is the -- 1.9.0 -- 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] resolve_gitlink_ref_recursive(): verify format of symbolic refs
On 06/27/2014 07:59 PM, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Michael Haggerty mhag...@alum.mit.edu writes:
When reading a symbolic ref via resolve_gitlink_ref_recursive(), check
that the reference name that is pointed at is formatted correctly,
using the same check as resolve_ref_unsafe() uses for non-gitlink
references. This prevents bogosity like
ref: ../../other/file
from causing problems.
I do agree that a textual symref ref: ../../x/y that is stored in
.git/HEAD or in .git/refs/L will step outside .git/ and it is
problematic. But if .git/refs/heads/a/b/LINK has ref: ../../x
in it, shouldn't we interpret it as referring to the ref at
refs/heads/x?
I've never seen that usage, nor seen it advocated. Symrefs are not
propagated via the Git protocol, so even if somebody were doing this
privately, it could hardly be a project-wide practice. I can't think of
a practical use for this feature. And it would be mildly annoying to
implement. So my inclination is to forbid it.
Actually, the textual symrefs have been invented to replace symbolic
links used for .git/HEAD on symlink-incapable filesystems, and we do
even not let the filesystem follow symlinks. The rule we have there
are like so:
/* Follow normalized - ie refs/.. symlinks by hand */
if (S_ISLNK(st.st_mode)) {
len = readlink(path, buffer, sizeof(buffer)-1);
if (len 0) {
if (errno == ENOENT || errno == EINVAL)
/* inconsistent with lstat; retry */
goto stat_ref;
else
return NULL;
}
buffer[len] = 0;
if (starts_with(buffer, refs/)
!check_refname_format(buffer, 0)) {
strcpy(refname_buffer, buffer);
refname = refname_buffer;
if (flag)
*flag |= REF_ISSYMREF;
continue;
}
}
So we should do exactly the same check, I would think, no?
I think you overlooked that if the (starts_with()
!check_refname_format()) check fails, execution falls through, ending up
here:
/*
* Anything else, just open it and try to use it as
* a ref
*/
fd = open(path, O_RDONLY);
if (fd 0) {
if (errno == ENOENT)
/* inconsistent with lstat; retry */
goto stat_ref;
else
return NULL;
}
len = read_in_full(fd, buffer, sizeof(buffer)-1);
close(fd);
[...etc...]
This has been the behavior since time immemorial [1].
In fact, another bug (which I probably introduced) is that in the case
of a symlink that points at a non-existent file, this code goes into an
infinite loop due to the if (errno == ENOENT) goto stat_ref in the
code that I quoted. My mistake was forgetting that lstat() is statting
the link whereas open() follows the link, so the success of the former
does not imply that the latter should not ENOENT.
I suggest we fix both problems by making the code behave the way you
*thought* it behaves: symlinks are never followed via the filesystem,
but if the symlink contents have the form of a legitimate refname that
starts with refs/, then we follow it the same way as we would follow a
textual-style symref.
In a typical clone, the .git/refs/remotes/origin/HEAD textual
symref stores ref: refs/remotes/origin/master and it is neither
ref: master nor ref: ./master, so it should be sensible to
insist on must start with 'refs/' and its format valid.
Yes, we don't even have a notation for relative refnames because we
would have no way to distinguish them from absolute refnames except
maybe via some artifice like a ./ prefix.
Michael
[1] Where by time immemorial I mean since before I ever touched refs.c.
--
Michael Haggerty
mhag...@alum.mit.edu
--
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
