* Re: [PATCH] fetch: avoid quadratic loop checking for updated submodules
From: Jeff King @ 2011-09-14 18:29 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Junio C Hamano, git
In-Reply-To: <4E70F224.2080401@web.de>
On Wed, Sep 14, 2011 at 08:27:48PM +0200, Jens Lehmann wrote:
> Am 14.09.2011 00:17, schrieb Jeff King:
> > One thing that could make it slightly less expensive (but I wouldn't
> > worry about implementing until it becomes an issue): you do a full diff
> [...]
> I think this would work for the functionality which is implemented right
> now. But with Frederik's gitfile work I hope to enable git to support
> submodules being moved around in the work tree rather soonish. Then we
> would be blind for any changes in the new location. Until it hurts us
> I'd prefer to stay with the correct version, even if it is a bit slower.
Agreed. Let's worry about it if and when it becomes a performance issue.
Thanks for putting up my with my total cluelessness regarding what's
happening in submodules. ;)
-Peff
^ permalink raw reply
* Re: Helping on Git development
From: Junio C Hamano @ 2011-09-14 18:29 UTC (permalink / raw)
To: Andrew Ardill; +Cc: Eduardo D'Avila, git
In-Reply-To: <CAH5451me+MDe34Boak=UDjH9T_WAnO6wxa6pW+JHOoGADoNfkQ@mail.gmail.com>
Andrew Ardill <andrew.ardill@gmail.com> writes:
> On 14 September 2011 13:05, Eduardo D'Avila <erdavila@gmail.com> wrote:
>> Hi,
>>
>> I have being using Git for some time now and I am very satisfied with it.
>> Now I'm considering giving back by helping on its development.
>> Is there any bug listing which I can check if there is some point I can help?
>> Any suggestions on other ways to help are also welcomed. :-)
>
> Hi Eduardo, as stated in the README,
>
> The messages titled "A note from the maintainer", "What's in git.git
> (stable)" and "What's cooking in git.git (topics)" and the discussion
> following them on the mailing list give a good reference for project
> status, development direction and remaining tasks.
>
> Additionally, I think the README should include something like
>
> If you are looking to contribute to the project, a good place to start
> is http://git-blame.blogspot.com/p/note-from-maintainer.html and in
> Documentation/howto/maintain-git.txt
I am moderately averse to hardcoding that URL that is guaranteed not to
survive the maintainer change in our README file. The howto/maintain-git
document mentions the periodical "A note from the maintainer" posting to
the list that has the same text, which is a more appropriate reference.
As to contributing to the project, right now, I think we have enough
people who want to write code and documentation for Git, but what we lack
are bandwidth to (this is not meant to be an exhaustive list):
- review the patches on the list and help perfecting them;
- distilling random wishes from the end user community while winnowing
chaffs that are unrealistic or do not fit well with the grand scheme of
things, to come up with a concrete proposal and a patch series to move
the discussions forward in a productive way;
- "on boarding" new contributors, helping them to become a useful member
of the community, teaching how to write a good bug report and how to
sell a new feature (i.e. "the perfect patch");
- dig list archives to point people at age-old discussions to non-issues
that have long been resolved to squelch noise; and
- remind original submitter, people who were involved in the discussion,
and people who should have been involved but who weren't, of a worthy
but stalled topics from time to time.
The first two need to come from more experienced folks whose judgement I
can trust (iow, not a newbie task). Others are "project secretary" tasks
that can be helped by anybody who is good at tracking things, perhaps
except for the last one that needs a good taste when judging which topic
is worthy of reminders.
^ permalink raw reply
* Re: [PATCH] git-p4: import utf16 file properly
From: Chris Li @ 2011-09-14 18:29 UTC (permalink / raw)
To: Luke Diamand; +Cc: git, Pete Wyckoff, Junio C Hamano
In-Reply-To: <4E705DF8.1040508@diamand.org>
[-- Attachment #1: Type: text/plain, Size: 1175 bytes --]
On Wed, Sep 14, 2011 at 12:55 AM, Luke Diamand <luke@diamand.org> wrote:
> On 13/09/11 22:33, Chris Li wrote:
>> The fix is simple, just ask perforce to print the depot
>> file into a real file. This way perforce will not performe
>> the utf16 to utf8 conversion. Git can import the exact same
>> file as perforce checkout.
>
> Does this change do the right thing with RCS keywords in UTF16 files?
I don't know what is the rules about the RCS keyword in UTF16 files.
I look at the current git-p4, it does not do any keyword replacement in
utf16 files. So this patch did not change that. It should be a separate issue.
The way I see it, this patch is a straight enhancement compare to the
current git-p4 because the current git-p4 *corrupts* the utf16 files.
>
> If p4CmdList() fails, e.g. due to running out of diskspace, will this just
> happily import a truncated/corrupt file?
Good point. I add the error check and attach the new patch.
> (And I could be wrong about this, but does you patch have newline damage? It
> didn't seem to apply for me).
Gmail dmage the white space. I should always use the attachment.
Does the attached patch work for you?
Thanks
Chris
[-- Attachment #2: 0001-git-p4-import-utf16-file-properly.patch --]
[-- Type: text/x-patch, Size: 1846 bytes --]
From 06de9cfdcd89e8bfb6575f40d36fdfcefe1a1985 Mon Sep 17 00:00:00 2001
From: Chris Li <git@chrisli.org>
Date: Tue, 13 Sep 2011 13:57:31 -0700
Subject: [PATCH] git-p4: import utf16 file properly
The current git-p4 does not handle utf16 files properly.
The "p4 print" command, when output to stdout, convert the
utf16 file into utf8. That effectively imported the utf16 file
as utf8 for git. In other words, git-p4 import a different
file compare to file check out by perforce. This breaks my
windows build in the company project.
The fix is simple, just ask perforce to print the depot
file into a real file. This way perforce will not perform
the utf16 to utf8 conversion. Git can import the exact same
file as perforce checkout.
---
contrib/fast-import/git-p4 | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 6b9de9e..c111cad 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1239,6 +1239,14 @@ class P4Sync(Command, P4UserMap):
contents = map(lambda text: re.sub(r'(?i)\$(Id|Header):[^$]*\$',r'$\1$', text), contents)
elif file['type'] in ('text+k', 'ktext', 'kxtext', 'unicode+k', 'binary+k'):
contents = map(lambda text: re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$\n]*\$',r'$\1$', text), contents)
+ elif file['type'] == 'utf16':
+ tmpFile = tempfile.NamedTemporaryFile()
+ cmd = "print -o %s %s"%(tmpFile.name, file['depotFile'])
+ result = p4Cmd(cmd)
+ if "p4ExitCode" in result:
+ die("Problems executing p4 %s"%cmd)
+ contents = [ open(tmpFile.name).read() ]
+ tmpFile.close()
self.gitStream.write("M %s inline %s\n" % (mode, relPath))
--
1.7.6
^ permalink raw reply related
* Re: [PATCH] fetch: avoid quadratic loop checking for updated submodules
From: Jens Lehmann @ 2011-09-14 18:27 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20110913221745.GB24549@sigill.intra.peff.net>
Am 14.09.2011 00:17, schrieb Jeff King:
> One thing that could make it slightly less expensive (but I wouldn't
> worry about implementing until it becomes an issue): you do a full diff
> and collect any changed GITLINK entries, and then compare the paths we
> get with the submodule config. Couldn't you instead do something like
> this:
>
> - let S = set of submodule paths that we care about, from the config
> - start the "git rev-list $new --not $old" traversal, as we do now
> - for each commit
> - diff using a pathspec of S
> - for each changed entry
> - add it to the set of changed submodules
> - remove it from S
> - if S is empty, break
>
> That has two advantages:
>
> 1. We limit the diff by pathspec, which means we can avoid looking at
> irrelevant parts of the tree (we don't do this yet, but hopefully
> we will in the future).
>
> 2. You can break out of the traversal early if you already know you
> have changes in each submodule of interest.
I think this would work for the functionality which is implemented right
now. But with Frederik's gitfile work I hope to enable git to support
submodules being moved around in the work tree rather soonish. Then we
would be blind for any changes in the new location. Until it hurts us
I'd prefer to stay with the correct version, even if it is a bit slower.
> Out of curiosity, what happens if we don't have such a commit? I know
> you said that your policy is never to rewind a submodule's commit that
> has been published in a superproject, and I think that's the only sane
> thing to do. But it's not enforced by git itself, and I wonder how badly
> we break if it does happen (i.e., I'm hoping the answer is "you can't
> diff or checkout superproject revisions that reference the missing bit"
> and not "git log crashes when it gets to that point in history").
No worries, nothing bad happens in that case.
^ permalink raw reply
* Re: [PATCH] fetch: avoid quadratic loop checking for updated submodules
From: Jens Lehmann @ 2011-09-14 18:26 UTC (permalink / raw)
To: git; +Cc: Jens Lehmann, Junio C Hamano, Jeff King, git-dev, Martin Fick
In-Reply-To: <4E6FB05C.6010202@web.de>
Am 13.09.2011 21:34, schrieb Jens Lehmann:
> Am 12.09.2011 22:21, schrieb Junio C Hamano:
>> Jeff King <peff@peff.net> writes:
>>
>>> Instead, this patch structures the code like this:
>>
>> Yup, I agree that's the right way to do the other half of the issue.
>
> Ack from me too! I tested it on the repo with 3k refs and the time went
> down from 142s to 1s (when applied to 3793ac56b4, as later versions of
> master contain my other half which would skip Peff's code).
>
> On current master including my other half this takes 0.90s, while running
> with Peff's code on top of 3793ac56b4 it takes .96s. That is 6 hundreds
> of a second (7%) extra for not having to worry if one must run "git fetch
> --recurse-submodules" or not.
Just for the record: Martin Fick was so kind to run Peff's fix (without my
half) on his 100k refs repo that showed this regression. Here are the results
of some test runs:
1.7.7.rc0.189.gab72a
10m8.133s 9m7.971s 8m16.600s 13m57.821s
8m34.974s 8m41.527s
1.7.7.rc0.189.gab72a --no-recurse-submodules
10m43.833s 7m41.283s 8m17.889s 8m4.549s
8m12.668s 7m59.180s
The fastest runs are 8% apart, which is pretty much the same slowdown as in
the 3k ref repo. Looks like we do have O(n) now :-)
^ permalink raw reply
* Re: [PATCH] contrib: add a credential helper for Mac OS X's keychain
From: Jay Soffian @ 2011-09-14 18:19 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, Jeff King, John Szakmeister, Junio C Hamano
In-Reply-To: <1316023117-84755-1-git-send-email-jaysoffian@gmail.com>
On Wed, Sep 14, 2011 at 1:58 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
> diff --git a/contrib/credential-osxkeychain/git-credential-osxkeychain.c b/contrib/credential-osxkeychain/git-credential-osxkeychain.c
> new file mode 100644
> index 0000000000..64bcc636cb
> --- /dev/null
> +++ b/contrib/credential-osxkeychain/git-credential-osxkeychain.c
>
> [...]
>
> +int find_internet_password(SecProtocolType protocol,
> + char *hostname,
> + char *username)
> +{
> + void *password_buf;
> + UInt32 password_len;
> + OSStatus status;
> + char *password;
> + int free_username;
int free_username = 0;
j.
^ permalink raw reply
* [PATCH] contrib: add a credential helper for Mac OS X's keychain
From: Jay Soffian @ 2011-09-14 17:58 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, Jeff King, John Szakmeister, Junio C Hamano
This credential helper adds, searches, and removes entries from
the Mac OS X keychain via OS X's Security Framework.
Tested with 10.6.8.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
And here's a C version. I cargo-culted the Makefile from
contrib/svn-fe/Makefile. Sadly, linking against git bloats the
binary quite a bit which is dissappointing since this helper
won't be installed as a hard-link. Hmm, maybe it can be if I
dlopen the security framework instead of linking against it.
contrib/credential-osxkeychain/Makefile | 35 ++++
.../git-credential-osxkeychain.c | 205 ++++++++++++++++++++
2 files changed, 240 insertions(+), 0 deletions(-)
create mode 100644 contrib/credential-osxkeychain/Makefile
create mode 100644 contrib/credential-osxkeychain/git-credential-osxkeychain.c
diff --git a/contrib/credential-osxkeychain/Makefile b/contrib/credential-osxkeychain/Makefile
new file mode 100644
index 0000000000..dc6bbbc3f9
--- /dev/null
+++ b/contrib/credential-osxkeychain/Makefile
@@ -0,0 +1,35 @@
+all:: git-credential-osxkeychain
+
+CC = gcc
+RM = rm -f
+CFLAGS = -O2 -Wall -I../.. -DSHA1_HEADER='<openssl/sha.h>'
+GIT_LIBS = ../../libgit.a ../../xdiff/lib.a
+LIBS = $(GIT_LIBS) -lz -liconv -lcrypto -lssl
+
+QUIET_SUBDIR0 = +$(MAKE) -C # space to separate -C and subdir
+QUIET_SUBDIR1 =
+
+ifneq ($(findstring $(MAKEFLAGS),w),w)
+PRINT_DIR = --no-print-directory
+else # "make -w"
+NO_SUBDIR = :
+endif
+
+ifneq ($(findstring $(MAKEFLAGS),s),s)
+ifndef V
+ QUIET_CC = @echo ' ' CC $@;
+ QUIET_LINK = @echo ' ' LINK $@;
+ QUIET_SUBDIR0 = +@subdir=
+ QUIET_SUBDIR1 = ;$(NO_SUBDIR) echo ' ' SUBDIR $$subdir; \
+ $(MAKE) $(PRINT_DIR) -C $$subdir
+endif
+endif
+
+git-credential-osxkeychain: git-credential-osxkeychain.o $(GIT_LIBS)
+ $(QUIET_LINK)$(CC) -o $@ $< $(LIBS) -Wl,-framework -Wl,Security
+
+git-credential-osxkeychain.o: git-credential-osxkeychain.c
+ $(QUIET_CC)$(CC) -c $(CFLAGS) $<
+
+clean:
+ $(RM) git-credential-osxkeychain git-credential-osxkeychain.o
diff --git a/contrib/credential-osxkeychain/git-credential-osxkeychain.c b/contrib/credential-osxkeychain/git-credential-osxkeychain.c
new file mode 100644
index 0000000000..64bcc636cb
--- /dev/null
+++ b/contrib/credential-osxkeychain/git-credential-osxkeychain.c
@@ -0,0 +1,205 @@
+/* Copyright 2011 Jay Soffian. All rights reserved.
+ * FreeBSD License.
+ *
+ * A git credential helper that interfaces with the Mac OS X keychain
+ * via the Security framework.
+ */
+#include <stdlib.h>
+#include <Security/Security.h>
+#include "cache.h"
+#include "credential.h"
+#include "parse-options.h"
+
+void emit_user_pass(char *username, char *password)
+{
+ if (username)
+ printf("username=%s\n", username);
+ if (password)
+ printf("password=%s\n", password);
+}
+
+char *username_from_keychain_item(SecKeychainItemRef item)
+{
+ OSStatus status;
+ SecKeychainAttributeList list;
+ SecKeychainAttribute attr;
+ list.count = 1;
+ list.attr = &attr;
+ attr.tag = kSecAccountItemAttr;
+ char *username;
+
+ status = SecKeychainItemCopyContent(item, NULL, &list, NULL, NULL);
+ if (status != noErr)
+ return NULL;
+ username = xmalloc(attr.length + 1);
+ strncpy(username, attr.data, attr.length);
+ username[attr.length] = '\0';
+ SecKeychainItemFreeContent(&list, NULL);
+ return username;
+}
+
+int find_internet_password(SecProtocolType protocol,
+ char *hostname,
+ char *username)
+{
+ void *password_buf;
+ UInt32 password_len;
+ OSStatus status;
+ char *password;
+ int free_username;
+ SecKeychainItemRef item;
+
+ status = SecKeychainFindInternetPassword(
+ NULL,
+ strlen(hostname), hostname,
+ 0, NULL,
+ username ? strlen(username) : 0, username,
+ 0, NULL,
+ 0,
+ protocol,
+ kSecAuthenticationTypeDefault,
+ &password_len, &password_buf,
+ &item);
+ if (status != noErr)
+ return -1;
+
+ password = xmalloc(password_len + 1);
+ strncpy(password, password_buf, password_len);
+ password[password_len] = '\0';
+ SecKeychainItemFreeContent(NULL, password_buf);
+ if (!username) {
+ username = username_from_keychain_item(item);
+ free_username = 1;
+ }
+ emit_user_pass(username, password);
+ if (free_username)
+ free(username);
+ free(password);
+ return 0;
+}
+
+void delete_internet_password(SecProtocolType protocol,
+ char *hostname,
+ char *username)
+{
+ OSStatus status;
+ SecKeychainItemRef item;
+
+ status = SecKeychainFindInternetPassword(
+ NULL,
+ strlen(hostname), hostname,
+ 0, NULL,
+ username ? strlen(username) : 0, username,
+ 0, NULL,
+ 0,
+ protocol,
+ kSecAuthenticationTypeDefault,
+ 0, NULL,
+ &item);
+ if (status != noErr)
+ return;
+ SecKeychainItemDelete(item);
+}
+
+void add_internet_password(SecProtocolType protocol,
+ char *hostname,
+ char *username,
+ char *password,
+ char *comment)
+{
+ struct strbuf label = STRBUF_INIT;
+ OSStatus status;
+ SecKeychainItemRef item;
+ SecKeychainAttributeList list;
+ SecKeychainAttribute attr;
+ list.count = 1;
+ list.attr = &attr;
+ status = SecKeychainAddInternetPassword(
+ NULL,
+ strlen(hostname), hostname,
+ 0, NULL,
+ strlen(username), username,
+ 0, NULL,
+ 0,
+ protocol,
+ kSecAuthenticationTypeDefault,
+ strlen(password), password,
+ &item);
+ if (status != noErr)
+ return;
+
+ /* set the comment */
+ attr.tag = kSecCommentItemAttr;
+ attr.data = comment;
+ attr.length = strlen(comment);
+ SecKeychainItemModifyContent(item, &list, 0, NULL);
+
+ /* override the label */
+ strbuf_addf(&label, "%s (%s)", hostname, username);
+ attr.tag = kSecLabelItemAttr;
+ attr.data = label.buf;
+ attr.length = label.len;
+ SecKeychainItemModifyContent(item, &list, 0, NULL);
+}
+
+int main(int argc, const char **argv)
+{
+ const char * const usage[] = {
+ "git credential-osxkeychain [options]",
+ NULL
+ };
+ struct credential c = { NULL };
+ int reject = 0;
+ SecProtocolType protocol;
+ char *hostname;
+ struct option options[] = {
+ OPT_BOOLEAN(0, "reject", &reject,
+ "reject a stored credential"),
+ OPT_STRING(0, "username", &c.username, "name",
+ "an existing username"),
+ OPT_STRING(0, "description", &c.description, "desc",
+ "human-readable description of the credential"),
+ OPT_STRING(0, "unique", &c.unique, "token",
+ "a unique context for the credential [REQUIRED]"),
+ OPT_END()
+ };
+ argc = parse_options(argc, argv, NULL, options, usage, 0);
+ if (argc)
+ usage_with_options(usage, options);
+
+ if (!c.unique)
+ die(_("--unique option required"));
+ hostname = strchr(c.unique, ':');
+ if (!hostname)
+ die(_("Invalid token: '%s'"), c.unique);
+ *hostname++ = '\0';
+
+ /* "GitHub for Mac" compatibility */
+ if (!strcmp(hostname, "github.com"))
+ hostname = "github.com/mac";
+
+ if (!strcmp(c.unique, "https")) {
+ protocol = kSecProtocolTypeHTTPS;
+ } else if (!strcmp(c.unique, "http")) {
+ protocol = kSecProtocolTypeHTTP;
+ }
+ else
+ die(_("Unsupported protocol: '%s'"), c.unique);
+
+ /* if this is a rejection delete the existing creds */
+ if (reject) {
+ delete_internet_password(protocol, hostname, c.username);
+ return 0;
+ }
+
+ /* otherwise look for a matching keychain item */
+ if (!find_internet_password(protocol, hostname, c.username))
+ return 0;
+
+ /* no keychain item found, prompt the user and store the result */
+ credential_getpass(&c);
+ add_internet_password(protocol, hostname, c.username, c.password,
+ c.description ? c.description : "default");
+ emit_user_pass(c.username, c.password);
+ return 0;
+}
--
1.7.7.rc1.1.g011e1
^ permalink raw reply related
* Re: Fwd: [Survey] Signed push
From: Junio C Hamano @ 2011-09-14 17:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Michael Haggerty, git
In-Reply-To: <CA+55aFw08zEeWovDPRGCM2f-xCuamJogFzigka4=mfcpJbZpsA@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Now people do "git merge" in scripts etc, so we can't fix it ;-(
Yes you can, by teaching "git merge -e" to open an editor ;-).
In the meantime, "commit --amend" is your friend.
^ permalink raw reply
* Re: Fwd: [Survey] Signed push
From: Junio C Hamano @ 2011-09-14 17:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <CA+55aFy0b+eozmzbKD4RXcJ7e3WCpf7BV1n1qXHOeEwSHZKOXw@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> I think that would probably be a good idea, although I'd actually
> prefer you to be more verbose, and more human-friendly, and actually
> talk about the commit in a readable way. Get rid of the *horrible*
> BRANCH-NOT-VERIFIED message (that actually messes up pull requests if
> mirroring is a bit delayed and throws away more important
> information), and instead just have a blurb afterwards saying
> something human-readable like
>
> Top commit 1f51b001cccf: "Merge branches 'cns3xxx/fixes',
> 'omap/fixes' and 'davinci/fixes' into fixes"
>
> and at *that* point you might have a "UNVERIFIED" notice for people
> to check if they forgot to push.
That UNVERIFIED thing was neither my favorite nor my idea, and I'd happily
rip it out in any second ;-)
>> An alternative that I am considering is to let the requester say this
>> instead:
>>
>> are available in the git repository at:
>> git://git.kernel.org/pub/flobar.git/ 5738c9c21e53356ab5020912116e7f82fd2d428f
>>
>> without adding the extra line.
>
> The extra line in the pull request is cheap - it's not like we need to
> ration them. The above format, in contrast, requires that the person
> doing the *pull* have a recent enough git client, otherwise the merge
> commit message will be just horrible.
In a re-roll patch I've added ";# branch-name" at the end of that line for
people with older git, but existing git wouldn't allow you to fetch anything
but refs so you won't risk getting "just horrible" merge message ;-)
> ... And what if the branch was updated since, so *no* branch name
> matches - does that mean that you'd disallow the pull entirely?
You are right about ambiguities, but when the specified commit does not
match the branch, it was indeed my intention to claim it is a _feature_
that pull fails, as you would be getting something different from what you
thought was promised by the requester with bait-and-switch.
> Also, if we're adding branch information, I'd say that a description
> of the branch is more important than a signature. Right now we lack
> even that.
I do not particularly want to go into that tangent, and I do agree with
your later message in this thread that it may make sense to tie the
publishing (and possibly recording) of the description of the branch to
"push -s"; people simply do not have reason to name throw-away branches.
> It would be lovely if people could annotate their branches with
> descriptions, so that when I pull a "for-linus" branch, if it has a
> description, the description of the branch makes it into the merge
> message.
I'm wondering if this could be something we can share between the push
certificate "Into this repository, I pushed this commit to that branch,
whose pupose is..." and pull request "...so please pull it to merge into
your history." There are three possibile orders of things a lieutenant or
a contributor may want to do after perfecting his tree locally:
(1) Write pull-request, and then "push -s".
(2) "push -s", and then write pull-request.
(3) "push -s" auto-mailing a pull-request.
> I realize that cryptographic signature sound very important right now,
> but in the end, *real* trust comes from people, not from signatures.
> ...
> Technical measures can be subverted, and I think we should also think
> about the social side. Every time somebody mentions a signature, I
> want to also mention "human readability", because I think that matters
> as much, if not more.
I obviously agree 100%, but that is an argument against trusting only
technical measures---right now, we do not have a good technical measure to
validate latest commits not yet contained in any tagged releases.
A piece of e-mail to the kernel list from you that says "I pushed it out
and the tip is this SHA-1", if it is written in good English with a bit of
your usual humor sprinkled in, would in practice be just as good as GPG
for the kernel list regulars who can recognize your style and serve as
that "technical measure" (by the way "What's cooking" does have the tips
of master and next branches for this exact reason).
> Imagine, for example, than when you do a
>
> git push -s ..
>
> git would *require* you to actually write a message about what you are
> pushing.
Yeah, we could go in that direction.
^ permalink raw reply
* Re: [RFC] Questions for "Git User's Survey 2011"
From: Jakub Narebski @ 2011-09-14 17:39 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <CAMP44s2ZSKx3jDZOSX7EM2bYtuUvvEctZYw6R3wNWQEbCeX4Rw@mail.gmail.com>
On Wed, 14 Sep 2011, Felipe Contreras wrote:
> On Sat, Sep 3, 2011 at 6:38 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Sat, 3 Sep 2011, Felipe Contreras wrote:
>>> 2011/7/25 Jakub Narebski <jnareb@gmail.com>:
>>>> I am planning doing annual Git User's Survey, and I'd like to ask for
>>>> feedback.
[...]
>> P.S. If I remember correctly you wanted some question about "staging area"
>> terminology, or something like that. Do you have concrete proposal for
>> question and list of answers?
>>
>> I was thinking about
>>
>> xx. How do you include changes in new commit?
>> (multiple choice, with other)
>>
>> [ ] commit -a
>> [ ] commit <file>
>> [ ] commit -i <file>
>> [ ] git add
>> [ ] git stage
>> [ ] git update-index
>> [ ] incremental add / commit
>> [ ] other, please specify __________________________
>>
>> (it is not in current version of survey, but can be added before it starts
>> for real)... though it is only small subset of "stage" vs "the index"
>> terminology. If you have something better...
>
> I am just looking at this. You should send regular updates to the
> survey, right after the initial batch of feedback, not one day before.
I'm very sorry about that.
My excuse is that I had less time during the summer holidays than
I thought, and there were time when I was not able to work on Git or
Git User's Survey. Additionally the premium account plan, which we have
for free thanks to generosity of Survs.com admins, ends 26 October 2011.
This means that postponing Git User's Survey to gather feedback and
start it later was out of question.
Also somehow I have missed your comments (or not implemented them
immediately because they lacked concrete proposal), and found them
only when sending last call request for feedback, just before starting
survey.
> First of all, "changes in new commit" doesn't sound right, should be
> either "a new commit", or "new commits".
Fixed (to "a new commit"), thanks.
> Second, you should have added what I said:
>
> + stage / partial or interactive commits (e.g. git add -u/-i/-p, git
> diff --cached)
>
> Nowhere in the survey does it as for 'git diff --cached' or anything
> that acts on the stage.
I couldn't come with a good question that would ask about that, and
I didn't want to create too long survey, with too many questions.
> So now we have your question, plus this:
> + interactive commit / per-hunk comitting / partial commit
>
> But that's not good enough.
Right.
> People might think 'git add -u/-i/-p' is not related to a commit.
> Also, we still don't know if people use --cached --keep-index, or any
> of those. If instead of 'git add/stage' you had 'git add/stage
> -u/-i/-p' That would have been better, and no, incremental add /commit
> doesn't really fit, for example, I usually do 'git add -p; git
> commit', so it's not really incremental.
I explicitly asked separately about _incremental_ and _interactive_...
but not in the new question. I'm sorry about that. Hopefully at
least some people will include "partial / interactive" in 'other'.
> I think we should stop beating around the bushes, and ask what we want to ask:
>
> == Do you use the stage/cache/index? ==
Perhaps "Do you use the stage/cache/index explicitly, and how?".
> If you don't want to ask that question directly, or you think people
> might not understand the question, we should be listing all the
> commands that use the stage, and make sure they are handled in the
> survey:
>
> X git diff --cached
> X git grep --cached
> X git rm --cached
> X git stash apply/pop --index
> X git stash (save) --[no-]keep-index
> X git add <tracked_file>
> X git add -p
> X git add -i
> X git add -u
> X git commit -p
> X git commit --interactive (not the same as git commit -i)
If there will be "Git User's Survey 2012", let's add this question
(replacing my "How do you include changes in new commit?").
It is a pity that Git Wiki doesn't work yet; I'd rather put this
proposal in Talk page for GitSurvey2011, or in GitSurvey2012
for next year survey proposal (if there would be one).
> It turns out none of them are explicitly asked in the survey. In order
> to do that, this is the only option I see:
>
> + interactive commits (e.g. git commit -p/--interactive)
> + stage (e.g. git add -p/-i/-u, git add <tracked_file))
> + stage commands (e.g. git * --cached, git stash * --index/--[no-]keep-index)
>
> Or at the very least what I suggested initially:
> + stage / partial or interactive commits (e.g. git add -u/-i/-p, git
> * --cached)
P.S. Would you be interested in running the next survey?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Fwd: [Survey] Signed push
From: Johan Herland @ 2011-09-14 16:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Matthieu Moy, Michael Haggerty, Junio C Hamano
In-Reply-To: <CA+55aFyGRM132OzoJR7wZ8wETvxrFWSmSMjMJnVOKP+6vys-Sw@mail.gmail.com>
On Wednesday 14. September 2011, Linus Torvalds wrote:
> On Wed, Sep 14, 2011 at 4:03 AM, Matthieu Moy
>
> <Matthieu.Moy@grenoble-inp.fr> wrote:
> > Would the notes mechanism be able to annotate ref names instead of
> > commit sha1?
>
> That would be a horrible, horrible notion.
>
> It's quite common to have multiple branches with the same SHA1. It
> might be in the "experimental-development" branch, but it got through
> testing with flying colors and deemed to be stable, so it got
> upgraded to the "for-linus" branch, and there hasn't been any other
> development since. So now both "for-linus" and
> "experimental-development" are the same commit, but they are very
> much not the same branch!
>
> So no, don't confuse branch *contents* with branch *descriptions*.
I don't think the suggestion was about annotating the branch tip as a
way of describing the branch. Rather, you create a _new_ SHA1 that
identifies the branch (e.g. SHA1(branch_name) ), and then annotate
_that_ SHA1. As I said, that _can_ be done with the notes
infrastructure, but - as Ted noted - there might be better solutions to
storing branch descriptions.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [RFC] Questions for "Git User's Survey 2011"
From: Felipe Contreras @ 2011-09-14 16:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <201109031738.11678.jnareb@gmail.com>
On Sat, Sep 3, 2011 at 6:38 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Sat, 3 Sep 2011, Felipe Contreras wrote:
>> 2011/7/25 Jakub Narebski <jnareb@gmail.com>:
>
>> > I am planning doing annual Git User's Survey, and I'd like to ask for
>> > feedback.
>>
>> Do you have an updated version somewhere?
>
> You can preview test version of survey at
>
> https://www.survs.com/survey/VEBXFGJ9B0
>
> Note that all answers in this test channel will be deleted!
>
> Up to date version was sent to git mailing list as
>
> [RFCv2] Questions for "Git User's Survey 2011"
> http://article.gmane.org/gmane.comp.version-control.git/180643
>
> and can be found on Git Wiki:
>
> http://git.wiki.kernel.org/index.php/GitSurvey2011
>
>
> P.S. If I remember correctly you wanted some question about "staging area"
> terminology, or something like that. Do you have concrete proposal for
> question and list of answers?
>
> I was thinking about
>
> xx. How do you include changes in new commit?
> (multiple choice, with other)
>
> [ ] commit -a
> [ ] commit <file>
> [ ] commit -i <file>
> [ ] git add
> [ ] git stage
> [ ] git update-index
> [ ] incremental add / commit
> [ ] other, please specify __________________________
>
> (it is not in current version of survey, but can be added before it starts
> for real)... though it is only small subset of "stage" vs "the index"
> terminology. If you have something better...
I am just looking at this. You should send regular updates to the
survey, right after the initial batch of feedback, not one day before.
First of all, "changes in new commit" doesn't sound right, should be
either "a new commit", or "new commits".
Second, you should have added what I said:
+ stage / partial or interactive commits (e.g. git add -u/-i/-p, git
diff --cached)
Nowhere in the survey does it as for 'git diff --cached' or anything
that acts on the stage.
So now we have your question, plus this:
+ interactive commit / per-hunk comitting / partial commit
But that's not good enough.
People might think 'git add -u/-i/-p' is not related to a commit.
Also, we still don't know if people use --cached --keep-index, or any
of those. If instead of 'git add/stage' you had 'git add/stage
-u/-i/-p' That would have been better, and no, incremental add /commit
doesn't really fit, for example, I usually do 'git add -p; git
commit', so it's not really incremental.
I think we should stop beating around the bushes, and ask what we want to ask:
== Do you use the stage/cache/index? ==
If you don't want to ask that question directly, or you think people
might not understand the question, we should be listing all the
commands that use the stage, and make sure they are handled in the
survey:
X git diff --cached
X git grep --cached
X git rm --cached
X git stash apply/pop --index
X git stash (save) --[no-]keep-index
X git add <tracked_file>
X git add -p
X git add -i
X git add -u
X git commit -p
X git commit --interactive (not the same as git commit -i)
It turns out none of them are explicitly asked in the survey. In order
to do that, this is the only option I see:
+ interactive commits (e.g. git commit -p/--interactive)
+ stage (e.g. git add -p/-i/-u, git add <tracked_file))
+ stage commands (e.g. git * --cached, git stash * --index/--[no-]keep-index)
Or at the very least what I suggested initially:
+ stage / partial or interactive commits (e.g. git add -u/-i/-p, git
* --cached)
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Fwd: [Survey] Signed push
From: Matthieu Moy @ 2011-09-14 15:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Michael Haggerty, Junio C Hamano, git
In-Reply-To: <CA+55aFyGRM132OzoJR7wZ8wETvxrFWSmSMjMJnVOKP+6vys-Sw@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Wed, Sep 14, 2011 at 4:03 AM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>>
>> Would the notes mechanism be able to annotate ref names instead of
>> commit sha1?
>
> That would be a horrible, horrible notion.
>
> It's quite common to have multiple branches with the same SHA1.
That's why my question was about annotating ref _names_, yes. As Johan
Herland pointed out, this would be possible in theory, but not really in
practice.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Fwd: [Survey] Signed push
From: Linus Torvalds @ 2011-09-14 15:27 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Michael Haggerty, Junio C Hamano, git
In-Reply-To: <vpqfwjzxu6i.fsf@bauges.imag.fr>
On Wed, Sep 14, 2011 at 4:03 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
>
> Would the notes mechanism be able to annotate ref names instead of
> commit sha1?
That would be a horrible, horrible notion.
It's quite common to have multiple branches with the same SHA1. It
might be in the "experimental-development" branch, but it got through
testing with flying colors and deemed to be stable, so it got upgraded
to the "for-linus" branch, and there hasn't been any other development
since. So now both "for-linus" and "experimental-development" are the
same commit, but they are very much not the same branch!
So no, don't confuse branch *contents* with branch *descriptions*.
Linus
^ permalink raw reply
* Re: Fwd: [Survey] Signed push
From: Linus Torvalds @ 2011-09-14 15:25 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Junio C Hamano, git
In-Reply-To: <4E7085E6.3060509@alum.mit.edu>
On Wed, Sep 14, 2011 at 3:45 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>
> Instead of "like a branch description", why not implement branch
> descriptions directly?
Mostly because of just human interface issues.
We already have a "repository description", and it's quite commonly
never even filled in. For branches, that would be doubly true, because
a lot of branches are throw-away.
So I think it would work if we made it part of of something like "git
push -s" - because that's when it starts mattering to others.
> I wish that one could annotate a branch (e.g., at creation) and have the
> annotation follow the branch around. This would be a useful place to
> record *why* you created the branch, your plans for it, etc. The
> annotation should be modifiable, because often a branch evolves in
> unforeseen ways during its lifetime. Anybody could read the annotation
> to get a quick idea of what kind of work is in progress.
I wouldn't be against that as a concept, I just think you'd be a small
small minority, and most branches would never get annotated.
But I don't really care deeply how it actually works - my main issue
is that git makes it way too easy to have bad merge messages. I think
part of that is an even simpler idiocy: we never even fire up the
editor by default for a "git merge", but we do for a "git commit".
That was a design mistake, and it means that if you want to actually
add a note to a merge, you have to do extra work. So people don't.
Now people do "git merge" in scripts etc, so we can't fix it ;-(
Linus
^ permalink raw reply
* Re: t0300-credentials: poll failed: invalid argument
From: Jeff King @ 2011-09-14 14:49 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Thomas Rast, Git List
In-Reply-To: <C9FED2AA-15CB-4850-B3DA-F4FC12F06EB4@silverinsanity.com>
On Wed, Sep 14, 2011 at 10:24:01AM -0400, Brian Gernhardt wrote:
> >> --- expect-stderr 2011-09-09 14:12:13.000000000 +0000
> >> +++ stderr 2011-09-09 14:12:13.000000000 +0000
> >> @@ -1,2 +1,3 @@
> >> askpass: Username:
> >> askpass: Password:
> >> +fatal: poll failed: Invalid argument
> >>
> >> for each of the tests 15--19. Is it supposed to be fixed?
> >
> > Ping?
>
> Jeff's patch did fix this for me, but it never appears to have made it
> into git.git. He mentioned something about re-rolling it along with
> some other fixes... *hint, hint*
Yeah, sorry, I wanted to add some more tests for handling multiple
usernames, and then maybe the helper interface was changing, and then...
There's no reason to hold this up, though. I'll repost it later today.
Promise this time. ;)
-Peff
^ permalink raw reply
* Re: t0300-credentials: poll failed: invalid argument
From: Brian Gernhardt @ 2011-09-14 14:24 UTC (permalink / raw)
To: Thomas Rast; +Cc: Jeff King, Git List
In-Reply-To: <201109141015.58333.trast@student.ethz.ch>
On Sep 14, 2011, at 4:15 AM, Thomas Rast wrote:
> Thomas Rast wrote:
>> $ uname -a
>> Darwin mackeller.inf.ethz.ch 11.1.0 Darwin Kernel Version 11.1.0: Tue Jul 26 16:07:11 PDT 2011; root:xnu-1699.22.81~1/RELEASE_X86_64 x86_64
> [...]
>> --- expect-stderr 2011-09-09 14:12:13.000000000 +0000
>> +++ stderr 2011-09-09 14:12:13.000000000 +0000
>> @@ -1,2 +1,3 @@
>> askpass: Username:
>> askpass: Password:
>> +fatal: poll failed: Invalid argument
>>
>> for each of the tests 15--19. Is it supposed to be fixed?
>
> Ping?
Jeff's patch did fix this for me, but it never appears to have made it into git.git. He mentioned something about re-rolling it along with some other fixes... *hint, hint*
~~ Brian
^ permalink raw reply
* Re: [PATCH] contrib: add a credential helper for Mac OS X's keychain
From: Jay Soffian @ 2011-09-14 13:31 UTC (permalink / raw)
To: John Szakmeister; +Cc: git, Junio C Hamano, Jeff King
In-Reply-To: <CAEBDL5UprYM0=SgNQrsY8_aCGf+pxKc1NP0AFjJy8igzt3vDZQ@mail.gmail.com>
On Wed, Sep 14, 2011 at 4:01 AM, John Szakmeister <john@szakmeister.net> wrote:
>> +def add_internet_password(protocol, hostname, username, password):
>> + # We do this over a pipe so that we can provide the password more
>> + # securely than as an argument which would show up in ps output.
>> + # Unfortunately this is possibly less robust since the security man
>> + # page does not document how to quote arguments. Emprically it seems
>> + # that using the double-quote, escaping \ and " works properly.
>
> I'm not sure this comment is correct... it looks like you're passing
> the password on the command line...
>
>> + username = username.replace('\\', '\\\\').replace('"', '\\"')
>> + password = password.replace('\\', '\\\\').replace('"', '\\"')
>> + command = ' '.join([
>> + 'add-internet-password', '-U',
>> + '-r', protocol,
>> + '-s', hostname,
>> + '-a "%s"' % username,
>> + '-w "%s"' % password,
>
> ...right here. :-(
Nope, you snipped out too much context. That command is turned into a
string and then sent to /usr/bin/security on its stdin. It is
absolutely not passed on the command-line.
j.
^ permalink raw reply
* Re: [PATCH] fetch: avoid quadratic loop checking for updated submodules
From: Marc Branchaud @ 2011-09-14 13:20 UTC (permalink / raw)
To: Jeff King; +Cc: Jens Lehmann, Junio C Hamano, git
In-Reply-To: <20110913221745.GB24549@sigill.intra.peff.net>
On 11-09-13 06:17 PM, Jeff King wrote:
>
> And superproject repositories are probably not going
> to have the same number of commits as submodule repositories, so it may
> be less of an issue.
Just a side note: I don't think this is a safe assumption. It's certainly
not the case in our repo, where the submodules are infrequently updated.
M.
^ permalink raw reply
* Re: Fwd: [Survey] Signed push
From: Ted Ts'o @ 2011-09-14 12:56 UTC (permalink / raw)
To: Johan Herland
Cc: git, Matthieu Moy, Michael Haggerty, Linus Torvalds,
Junio C Hamano
In-Reply-To: <201109141428.53163.johanh@opera.com>
On Wed, Sep 14, 2011 at 02:28:52PM +0200, Johan Herland wrote:
> On Wednesday 14. September 2011, Matthieu Moy wrote:
> > Michael Haggerty <mhagger@alum.mit.edu> writes:
> > > I wish that one could annotate a branch (e.g., at creation) and
> > > have the annotation follow the branch around. This would be a
> > > useful place to record *why* you created the branch, your plans
> > > for it, etc. The annotation should be modifiable, because often a
> > > branch evolves in unforeseen ways during its lifetime. Anybody
> > > could read the annotation to get a quick idea of what kind of work
> > > is in progress.
> >
> HOWEVER, "git notes prune" will assume that the SHA1 keys are supposed
> to identify existing git objects, and will delete any note whose SHA1
> key does not identify a reachable git object.
>
> Hence, if you promise to never run "git notes prune" on
> refs/notes/branch-descriptions, you could use that ref to store your
> branch descriptions keyed by the SHA1 of your branch name.
It seems like notes is the wrong place to encode this. If people
really want this, what if there was a convention where there could be
a separate branch head: ref/heads/META
which contained a directory structure like this:
<e-mail>/key # The developer's GPG key
<e-mail>/<tree>/URL # URL of developer's tree named <tree>
<e-mail>/<tree>/description # Descrition of <tree>
<e-mail>/<tree>/branch/<branch-name> # A description of that branch
etc.
Since it's a separate branch head, the contents can be pushed around
and merged very easily, and there's no danger of the information
getting lost via a garbage collection or prune operation.
If there was an association between a local branch and <e-mail>/<tree>
that it was tracking, then either a modified git core or porcelein
command could get the information from the META tree. It would also
make it easy to fetch a developer's GPG key without having to go to
outside GPG key servers, which is a minor benefit (although maybe
that's not worth it).
- Ted
^ permalink raw reply
* Re: Fwd: [Survey] Signed push
From: Johan Herland @ 2011-09-14 12:28 UTC (permalink / raw)
To: git; +Cc: Matthieu Moy, Michael Haggerty, Linus Torvalds, Junio C Hamano
In-Reply-To: <vpqfwjzxu6i.fsf@bauges.imag.fr>
On Wednesday 14. September 2011, Matthieu Moy wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
> > I wish that one could annotate a branch (e.g., at creation) and
> > have the annotation follow the branch around. This would be a
> > useful place to record *why* you created the branch, your plans
> > for it, etc. The annotation should be modifiable, because often a
> > branch evolves in unforeseen ways during its lifetime. Anybody
> > could read the annotation to get a quick idea of what kind of work
> > is in progress.
>
> Would the notes mechanism be able to annotate ref names instead of
> commit sha1?
This has been discussed on the list before, but I'm too lazy to dig up a
reference, so:
The notes mechanism can in principle annotate anything that has a SHA1
sum. The notes tree is really only a key->value mapping using SHA1s as
keys and Git objects (typically blobs) as values.
HOWEVER, "git notes prune" will assume that the SHA1 keys are supposed
to identify existing git objects, and will delete any note whose SHA1
key does not identify a reachable git object.
Hence, if you promise to never run "git notes prune" on
refs/notes/branch-descriptions, you could use that ref to store your
branch descriptions keyed by the SHA1 of your branch name.
The obvious deficiency with this scheme is that if your branch name is
different in some repos, the branch description will be lost in those
repos unless you rewrite the refs/notes/branch-descriptions notes tree
accordingly.
...Johan
--
Johan Herland, <johanh@opera.com>
Core Developer, Opera Software ASA
^ permalink raw reply
* Re: [Survey] Signed push
From: Nguyen Thai Ngoc Duy @ 2011-09-14 11:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vaaa8xufi.fsf@alter.siamese.dyndns.org>
On Wed, Sep 14, 2011 at 2:45 AM, Junio C Hamano <gitster@pobox.com> wrote:
> 1. Improved pull requests.
>
> ...
>
> An alternative that I am considering is to let the requester say this
> instead:
>
> are available in the git repository at:
> git://git.kernel.org/pub/flobar.git/ 5738c9c21e53356ab5020912116e7f82fd2d428f
>
> without adding the extra line.
>
> That is, to allow fetching the history up to an explicitly named commit
> object. This would only involve a change to fetch-pack at the receiving
> end; just match the commit object name given from the command line against
> the ls-remote response and ask upload-pack to give the history leading to
> it. The released versions of Git already will happily oblige, as long as
> the commit object named in the request message still sits at the tip of
> the intended branch.
>
> Do you think it is worthwhile to pursue this alternative?
Stupid question, if we agree to go with signed push, can we also sign
pull requests and verify them when we pull? I suppose most of the
time, pulling can be done automatically by extracting pull url from
the request. This would make pull/push both signed.
BTW, there's a third way (rsync is obsolete) to carry changes away in
human-unreadable way: bundles. Should we also sign the bundles too (I
guess we could just do the same as in signed push).
--
Duy
^ permalink raw reply
* Re: git checkout --orphan skips reflogging
From: Dmitry Ivankov @ 2011-09-14 11:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
In-Reply-To: <7vaaa8vyc8.fsf@alter.siamese.dyndns.org>
On Wed, Sep 14, 2011 at 5:04 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Dmitry Ivankov <divanorama@gmail.com> writes:
>
>> In short, git checkout --orphan doesn't write
>> HEAD_sha1 -> 00000
>> entry to logs/HEAD, while git-comit will write
>> 00000 -> new_orphan_HEAD_sha1
>> entry. And then reflog backward walk will stop on 000 -> entry and
>> won't see earlier history.
>
> Funny. From the point of view of the _current_ branch, it sort of makes
> sense to stop the traversal at that point, but I agree for HEAD reflog
> that records branch switching, the traversal should not stop.
>
> I am not sure if recording 0{40} after --orphan is the right thing to do
> either (for that matter, I do not necessarily think running --orphan is a
> sane thing to do, but that is a separate issue).
In fact, my purpose is more like finding out what branches I were recently
on, most of the time even what branches I've updated recently. So, being
able to see chronologically (by ref modification time) ordered list of refs
may be a better way (than git log -g --decorate).
>> Isn't it also a bug in reflog walking that we rely on each old_sha1
>> being new_sha1 of a previous entry?
>
> I am not all that familiar with the reflog walking (which is admittedly a
> bolted-on hack that injects commits with fake ancestry) code, but I think
> it assumes the old sha1 field on the current entry matches the new sha1
> field on the previous entry, and we could change it to be a bit more
> robust.
>
> The attached patch _may_ (I didn't even compile test it) remove the
> dependency on osha1[] and make the code consistently use nsha1[], but I
> think stopping at the 0{40} is pretty much fundamental in the revision
> walking machinery the reflog walking code is piggy-backing on, and I do
> not think this patch would change that.
The patch compiles fine, and walks past osha1 == 0{40}. Probably osha1
becomes completely hidden from the walking machinery, and since nsha1 is
never 0{40} (for now) whole history is walked.
^ permalink raw reply
* Re: Fwd: [Survey] Signed push
From: Nguyen Thai Ngoc Duy @ 2011-09-14 11:46 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Michael Haggerty, Linus Torvalds, Junio C Hamano, git
In-Reply-To: <vpqfwjzxu6i.fsf@bauges.imag.fr>
On Wed, Sep 14, 2011 at 9:03 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> I wish that one could annotate a branch (e.g., at creation) and have the
>> annotation follow the branch around. This would be a useful place to
>> record *why* you created the branch, your plans for it, etc. The
>> annotation should be modifiable, because often a branch evolves in
>> unforeseen ways during its lifetime. Anybody could read the annotation
>> to get a quick idea of what kind of work is in progress.
>
> Would the notes mechanism be able to annotate ref names instead of
> commit sha1?
Speaking from someone who has few experience with git-notes, no I
don't think current git-notes can do that. But similar mechanism can
be added, targeting ref instead of sha-1. But the question is, is
branch description local or public?
Branch description sounds local to me. I just record a branch's
purpose and status (the latter is more important to me). If it's
local, we just need to extend ref format to store extra text in
addition to SHA-1.
If it's public, perhaps if we have a good way to:
- convert arbitrary text to a ref (maybe just converting spaces to hyphens)
- specify a ref without writing the whole ref name (reminds me of
short sha-1 vs full sha-1)
then we could use branch name as branch description. The default merge
commit messages can be updated to convert back branch name (which is
also the branch description) to human-readable text.
--
Duy
^ permalink raw reply
* Re: Fwd: [Survey] Signed push
From: Matthieu Moy @ 2011-09-14 11:03 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <4E7085E6.3060509@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> I wish that one could annotate a branch (e.g., at creation) and have the
> annotation follow the branch around. This would be a useful place to
> record *why* you created the branch, your plans for it, etc. The
> annotation should be modifiable, because often a branch evolves in
> unforeseen ways during its lifetime. Anybody could read the annotation
> to get a quick idea of what kind of work is in progress.
Would the notes mechanism be able to annotate ref names instead of
commit sha1?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox