Re: Fetching a specific commit by commit ID
On 06 Dec 2014, at 16:52, brian m. carlson sand...@crustytoothpaste.net wrote: - more interestingly: is there any reason why git fetch should not support fetching by commit id? There are real world use cases where this can be very useful, for instance when references on the remote have been overwritten or deleted. The reason this isn't supported in the general case is because one might want to restrict access to certain branches. For example, an open source project might want to embargo some security fixes that are in the repository. Allowing a user to specify an arbitrary ID would permit someone to circumvent those access controls. Shouldn’t these checks be implemented in the layers above, eg. in gitolite, gitosis, gerrit… ? Having it in git itself makes it impossible in all cases, even for projects/repositories with no ref-specific read restrictions (the vast majority of projects, I would guess). It seems pretty straightforward to support access control in these layers. If a commit id is provided, go through all references of the repository, if one is found that is a child of the given commit, and the user has access to the ref, then it’s ok to fetch the commit. Of course it’s an expensive operation, but it’s is rarely required. -- 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
Fetching a specific commit by commit ID
Hello everyone, I am trying to fetch a commit using a commit ID instead of a reference. According to the documentation of git-fetch, this is not supported, but I found out that this is not entirely true. If the commit is already available in the repository, I get: $ git fetch origin 7365b1a9bd45fbf12b09381d5779b607e232a8cd From repo1 * branch7365b1a9bd45fbf12b09381d5779b607e232a8cd - FETCH_HEAD $ echo $? 0 If the commit is not in the repository (but it is present in the remote of course), I get: $ git fetch origin fc907b94f69b9bd710ba55b5522258b722fefb3b $ echo $? 1 That brings up following questions/remarks: - the documentation of git-fetch is not entirely correct, commit ids are partially supported, not only refs - “git fetch origin fc907” should print an error message on STDERR specifying what the problem is - more interestingly: is there any reason why git fetch should not support fetching by commit id? There are real world use cases where this can be very useful, for instance when references on the remote have been overwritten or deleted. Olivier -- 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] Copy mergetool bc3 as bc4
Beyond compare 4 is out since september 2014. The CLI interface doesn't seem to
have changed compared to the version 3.
Signed-off-by: Olivier Croquette ocroque...@free.fr
---
mergetools/bc4 | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
create mode 100644 mergetools/bc4
diff --git a/mergetools/bc4 b/mergetools/bc4
new file mode 100644
index 000..b6319d2
--- /dev/null
+++ b/mergetools/bc4
@@ -0,0 +1,25 @@
+diff_cmd () {
+ $merge_tool_path $LOCAL $REMOTE
+}
+
+merge_cmd () {
+ touch $BACKUP
+ if $base_present
+ then
+ $merge_tool_path $LOCAL $REMOTE $BASE \
+ -mergeoutput=$MERGED
+ else
+ $merge_tool_path $LOCAL $REMOTE \
+ -mergeoutput=$MERGED
+ fi
+ check_unchanged
+}
+
+translate_merge_tool_path() {
+ if type bcomp /dev/null 2/dev/null
+ then
+ echo bcomp
+ else
+ echo bcompare
+ fi
+}
--
1.7.2.5
--
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] Copy mergetool bc3 as bc4
On 20 Oct 2014, at 19:32, Junio C Hamano gits...@pobox.com wrote: Perhaps something like this, so that existing users can still use bc3 and other people can use bc if it bothers them that they have to say 3 when the backend driver works with both 3 and 4? Thanks for the quick and great feedback. This looks good to me. I used “bc4 just for consistency sake and to preserve backwards compatibility, but introducing “bc” as a generic backend looks indeed as a better approach. It’s even future safe, because it doesn’t prevent introducing bc5 if required later on. Olivier -- 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
