Re: [PATCH v2 00/10] Use a structure for object IDs.
On 03/08/2015 12:23 AM, brian m. carlson wrote: This is a patch series to convert some of the relevant uses of unsigned char [20] to struct object_id. The goal of this series to improve type-checking in the codebase and to make it easier to move to a different hash function if the project decides to do that. This series does not convert all of the codebase, but only parts. I've dropped some of the patches from earlier (which no longer apply) and added others. Certain parts of the code have to be converted before others to keep the patch sizes small, maintainable, and bisectable, so functions and structures that are used across the codebase (e.g. struct object) will be converted later. Conversion has been done in a somewhat haphazard manner by converting modules with leaf functions and less commonly used structs first. Since part of the goal is to ease a move to a different hash function if the project decides to do that, I've adopted Michael Haggerty's suggestion of using variables named oid, naming the structure member sha1, and using GIT_SHA1_RAWSZ and GIT_SHA1_HEXSZ as the constants. I've been holding on to this series for a long time in hopes of converting more of the code before submitting, but realized that this deprived others of the ability to use the new structure and required me to rebase extremely frequently. [...] I've added CC to several people who commented on v1. I think this is a really interesting project and I hope that it works out. In my opinion, the biggest risk (aside from the sheer amount of work required) is the issue that was brought up on the mailing list when you submitted v1 [1]: Converting an arbitrary (unsigned char *) to a (struct object_id *) is not allowed, because the alignment requirements of the latter might be stricter than those of the former. This means that if, for example, we are reading some data from disk or from the network, and we expect the 20 bytes starting with byte number 17 to be a SHA-1 in binary format, we used to be able to do unsigned char *sha1 = buf + 17; and use sha1 like any other SHA-1, without the need for any copying. But we can't do the analogous struct object_id *oid = (struct object_id *)(buf + 17); because the alignment is not necessarily correct. So in a pure struct object_id world, I think we would be forced to change such code to struct object_id oid; hashcpy(oid.sha1, buf + 17); This uses additional memory and introduces copying overhead. Also, the lifetime of oid might exceed the scope of a function, so oid might have to be allocated on the heap and later freed. This adds more computational overhead, more memory overhead, and more programming effort to get it all right. So as much as I like the idea of wrapping SHA-1s in objects, I think it would be a good idea to first make sure that we can all agree on a plan for dealing with situations like this. I can think of the following possibilities: 1. Maybe code that needs to handle SHA-1s with screwy alignment does not exist, or maybe it does the copying anyway. I haven't actually checked. 2. Maybe somebody can prove that struct object_id *oid = (struct object_id *)(buf + 17); somehow *is* allowed by the C standard, or at least that it is sufficiently portable for our purposes. 3. We accept the additional runtime costs and development effort for the extra copies. To accept this approach, we would need some idea of which areas of the code will be affected, and some estimate of how much additional memory it would cost. 4. We continue to support working with SHA-1s declared to be (unsigned char *) in some performance-critical code, even as we migrate most other code to using SHA-1s embedded within a (struct object_id). This will cost some duplication of code. To accept this approach, we would need an idea of *how much* code duplication would be needed. E.g., how many functions will need both (unsigned char *) versions and (struct object_id *) versions? 5. We only make the change opportunistically. Whenever we find a function that needs to work with non-struct-aligned SHA-1s, we leave the function as-is rather than converting it or creating a second version that works with object_id objects. This approach would leave the codebase somewhat schizophrenic. I'm not trying to dissuade you from this project, but I think that for your project to have a chance of success, we need an answer to this question. So let's confront it now rather than after you have invested lots more time and/or gotten patches merged. Michael [1] http://thread.gmane.org/gmane.comp.version-control.git/248054 -- 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
Re: Promoting Git developers
Jeff King p...@peff.net writes: Or something along those lines. The wording and indentation of the message could probably use tweaking. And there is a bash-ism in the script. :) OK, I've updated the Announce script on the 'todo' branch. The announcement for 2.3.2 I sent out earlier as $gmane/264975 would have looked like this. -- 8 -- To: git@vger.kernel.org Cc: Linux Kernel linux-ker...@vger.kernel.org Bcc: l...@lwn.net Subject: [ANNOUNCE] Git v2.3.2 The latest maintenance release Git v2.3.2 is now available at the usual places. It comprises of 41 non-merge commits since v2.3.1, contributed by 19 people, 5 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories all have a copy of the 'v2.3.2' tag and the 'maint' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git New contributors who made this release possible are as follows. Welcome to the Git development community! Aleksander Boruch-Gruszecki, Aleksey Vasenev, Patrick Steinhardt, Ryuichi Kokubo, and Tom G. Christensen. Returning contributors who helped this release are as follows. Thanks for your continued support. Alexander Kuleshov, Eric Sunshine, Jeff King, Jonathon Mah, Junio C Hamano, Kirill A. Shutemov, Kyle J. McKay, Matthieu Moy, Mike Hommey, Ramsay Allan Jones, René Scharfe, Stefan Beller, Torsten Bögershausen, and Дилян Палаузов. Git v2.3.2 Release Notes Fixes since v2.3.1 -- * update-index --refresh used to leak when an entry cannot be refreshed for whatever reason. ... * Even though we officially haven't dropped Perl 5.8 support, the Getopt::Long package that came with it does not support --no- prefix to negate a boolean option; manually add support to help people with older Getopt::Long package. Also contains typofixes, documentation updates and trivial code clean-ups. Changes since v2.3.1 are as follows: Aleksander Boruch-Gruszecki (1): merge-file: correctly open files when in a subdir Aleksey Vasenev (1): wincred: fix get credential if username has @ ... Дилян Палаузов (1): do not include the same header twice -- 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: Surprising interaction of binary and eol gitattributes
Johannes Sixt j...@kdbg.org writes: I would say former. You find out what attributes apply to a path and then consider the collective effect of these attributes that survived. So the second No it is not text which is overruled by the oops, no that is text later should not get in the picture, I would say. As binary is not just -text and turns other things off, those other things will be off after these three. Is that how attribute lookup works? I.e., given a path, all attributes are collected? Isn't it more like: Here we are interested in the eol attribute of this file named a.foo. And the lookup would find the first line that says eol=crlf. Elsewhere, we are interested in the binary attribute of the file named a.foo, and lookup would find the second line that sets the binary attribute. And again elsewhere, we ask for the text attribute, and we find the last line that sets the text property. Am I totally off track? In the codepath in question, we say we are interested in text and eol attributes, grab the values (set/unset/set-to-value/unspecified) for these two for the path we are interested in from all the applicable gitattributes file and then act on the result. -- 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] *config.txt: stick to camelCase naming convention
On Wed, Mar 11, 2015 at 07:20:18PM +0700, Nguyễn Thái Ngọc Duy wrote: This should improve readability. Compare thislongname and thisLongName. The following keys are left in unchanged. We can decide what to do with them later. - am.keepcr - core.autocrlf .safecrlf .trustctime - diff.dirstat .noprefix - gitcvs.usecrlfattr - gui.blamehistoryctx .trustmtime - pull.twohead - receive.autogc - sendemail.signedoffbycc .smtpsslcertpath .suppresscc Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- diff --git a/Documentation/config.txt b/Documentation/config.txt index 1530255..54ae0f6 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -237,7 +237,7 @@ The default is false, except linkgit:git-clone[1] or linkgit:git-init[1] will probe and set core.ignorecase true if appropriate when the repository is created. -core.precomposeunicode:: +core.precomposeUnicode:: There are numerous places in config.txt where a config variable is mentioned in the description blurbs as well, so camel-casing it at just the point of definition makes for an incomplete conversion. This option is only used by Mac OS implementation of Git. When core.precomposeunicode=true, Git reverts the unicode decomposition Here is one such instance of the variable mentioned inline in a blurb. These converted variables are also mentioned in a number of other documentation files. Below is a more thorough conversion, covering all instances. You may want to split it up for easier review. --- 8 --- From: =?UTF-8?q?Nguy=E1=BB=85n=20Th=C3=A1i=20Ng=E1=BB=8Dc=20Duy?= pclo...@gmail.com Subject: [PATCH] *config.txt: stick to camelCase naming convention This should improve readability. Compare thislongname and thisLongName. The following keys are left in unchanged. We can decide what to do with them later. - am.keepcr - core.autocrlf .safecrlf .trustctime - diff.dirstat .noprefix - gitcvs.usecrlfattr - gui.blamehistoryctx .trustmtime - pull.twohead - receive.autogc - sendemail.signedoffbycc .smtpsslcertpath .suppresscc Helped-by: Eric Sunshine sunsh...@sunshineco.com Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com Signed-off-by: Eric Sunshine sunsh...@sunshineco.com --- Documentation/CodingGuidelines | 2 +- Documentation/blame-options.txt| 2 +- Documentation/config.txt | 242 ++--- Documentation/diff-config.txt | 10 +- Documentation/diff-options.txt | 4 +- Documentation/fetch-options.txt| 2 +- Documentation/git-add.txt | 4 +- Documentation/git-apply.txt| 2 +- Documentation/git-branch.txt | 6 +- Documentation/git-check-ignore.txt | 2 +- Documentation/git-checkout.txt | 4 +- Documentation/git-commit-tree.txt | 2 +- Documentation/git-commit.txt | 2 +- Documentation/git-config.txt | 2 +- Documentation/git-cvsserver.txt| 22 ++-- Documentation/git-fetch.txt| 2 +- Documentation/git-format-patch.txt | 4 +- Documentation/git-gc.txt | 12 +- Documentation/git-init.txt | 2 +- Documentation/git-instaweb.txt | 2 +- Documentation/git-log.txt | 2 +- Documentation/git-merge.txt| 4 +- Documentation/git-pull.txt | 2 +- Documentation/git-rebase.txt | 6 +- Documentation/git-receive-pack.txt | 2 +- Documentation/git-repack.txt | 4 +- Documentation/git-rerere.txt | 2 +- Documentation/git-send-email.txt | 50 Documentation/git-status.txt | 4 +- Documentation/git-tag.txt | 2 +- Documentation/git.txt | 2 +- Documentation/gitattributes.txt| 2 +- Documentation/gitcredentials.txt | 2 +- Documentation/gitignore.txt| 4 +- Documentation/gitweb.conf.txt | 2 +- Documentation/merge-config.txt | 2 +- Documentation/user-manual.txt | 2 +- 37 files changed, 212 insertions(+), 212 deletions(-) diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index 7636199..376d5ec 100644 --- a/Documentation/CodingGuidelines +++ b/Documentation/CodingGuidelines @@ -526,7 +526,7 @@ Writing Documentation: `backticks around word phrases`, do so. `--pretty=oneline` `git rev-list` - `remote.pushdefault` + `remote.pushDefault` Word phrases enclosed in `backtick characters` are rendered literally and will not be further expanded. The use of `backticks` to achieve the diff --git a/Documentation/blame-options.txt b/Documentation/blame-options.txt index 0cebc4f..b299b59 100644 --- a/Documentation/blame-options.txt +++ b/Documentation/blame-options.txt @@ -4,7 +4,7 @@ --root:: Do not treat root commits as boundaries. This can also be - controlled via the `blame.showroot` config option. + controlled via the `blame.showRoot` config option. --show-stats:: Include additional statistics at the end of blame
Re: Promoting Git developers
Christian Couder christian.cou...@gmail.com writes: On Tue, Mar 10, 2015 at 6:23 PM, Junio C Hamano gits...@pobox.com wrote: I would suspect that those who agree with you would appreciate if you or somebody volunteered to act as our CKDO (chief kudos distribution officer). I do not think I have enough time to do that well. One good place to start might be to scan the list and summarize something like the following on weekly or monthly basis, as these are not something you can get by pointing people to git shortlog output. - Those who gave helpful review comments, how about going this way illustration patches, etc. Bonus points to those who helped onboarding newcomers. - Those who asked pertinent questions on common pain points, and those who answered them helpfully. Ok, I can start something about this two points every week or every few week. It would be best if I could get help from at least one person as I think it is a lot of work. No kidding; even though it may no longer be an impossibly large task as in the infrationary epoch reported in the Git Traffic, this forum is still a high traffic place. I also appreciate very much that you are willing to improve the release notes by adding a summary with people's names. Just in case you misunderstood, I do not think it is a good idea to add names to release notes and I will not do so. I was and am planning add the list of contributors at the end of the e-mail when the release notes is sent out, i.e. in the Announce message that is sent to the list (and CC'ed to lwn.net). -- 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: Surprising interaction of binary and eol gitattributes
Junio C Hamano gits...@pobox.com writes: Johannes Sixt j...@kdbg.org writes: Isn't it more like: Here we are interested in the eol attribute of this file named a.foo. And the lookup would find the first line that says eol=crlf. Elsewhere, we are interested in the binary attribute of the file named a.foo, and lookup would find the second line that sets the binary attribute. And again elsewhere, we ask for the text attribute, and we find the last line that sets the text property. Am I totally off track? In the codepath in question, we say we are interested in text and eol attributes, grab the values (set/unset/set-to-value/unspecified) for these two for the path we are interested in from all the applicable gitattributes file and then act on the result. Technically the above is only a half-answer; I know you are intelligent enough to derive the other untold half from it, but for the benefit of those reading from sidelines The calling convention to (1) prepare the list of attributes you are interested in upfront and then (2) to ask the set of attributes that apply among that set for a path is designed to force programmers avoid doing attribute lookups (which is rather expensive) at random places in their code. But in the end, this let us implement the functionality as you alluded to in the quote paragraph. If a proposed change wants to make 'text=auto' stronger in the sense that we decide if we pay attention to 'eol' only after checking if the contents look non-text, it can do so, just like setting '-text' to the current code makes settings of 'eol' irrelevant. -- 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 v4] rev-list: refuse --first-parent combined with --bisect
Kevin Daudt m...@ikke.info writes: On Tue, Mar 10, 2015 at 04:12:18PM -0700, Junio C Hamano wrote: What does such a command line _mean_? It tells us this: Define a set by having the bad ref as a positive end, and having all the good refs as negative (uninteresting) boundary. That is a way to show commits that are reachable from the bad one and excluding the ones that are reachable from any of the known-good commits. The area of the graph in the current bisection that contains suspect commits. Now, what does it mean to pull only the first-parent chain starting from the bad one in such a set in the first place? What does the resulting set of commits mean? In that case it will leave out any merged in branches. Needs a bit more thinking (hint: branches merged into *what*?). I recalled reading something about this. Searching found me the GSoC idea: When your project is strictly new features are merged into trunk, never the other way around, it is handy to be able to first find a merge on the trunk that merged a topic to point fingers at when a bug appears, instead of having to drill down to the individual commit on the faulty side branch. So there is definitely a use case for --bisect --first-parent, which would show you those commits that would be part of the bisection. Step back and think why git bisect --first-parent is sometimes desired in the first place. It is because in the regular bisection, you will almost always end up on a commit that is _not_ on the first-parent chain and asked to check that commit at a random place on a side branch in the first place. And you mark such a commit as bad. The thing is, traversing from that bad commit that is almost always is on a side branch, following the first-parent chain, will not be a useful history that leaves out any merged in branches. When git bisect --first-parent feature gets implemented, do not use --first-parent with --bisect limitation has to be lifted anyway, but until then, not allowing --first-parent --bisect for rev-list but allowing it for log does not buy our users much. The output does not give us a nice show me which merges on the trunk may have caused the breakage to be examined with the remainder of this bisect session. So, yes, there is a use case for log --bisect --first-parent, once there is a working bisect --first-parent, but not until then, the command is not useful, I would think. -- 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: Surprising interaction of binary and eol gitattributes
Am 10.03.2015 um 23:54 schrieb Junio C Hamano: Michael Haggerty mhag...@alum.mit.edu writes: Well, that's true, but the eol attribute can regain its effect if binary is followed by text or text=auto. So I guess the simplest question is as follows. Suppose I have the following .gitattributes: a.foo eol=crlf a.foo binary a.foo text It is obvious in this case that a.foo should be treated as a text file. Should it be processed with eol=crlf, or should the intervening binary imply -eol? I would say former. You find out what attributes apply to a path and then consider the collective effect of these attributes that survived. So the second No it is not text which is overruled by the oops, no that is text later should not get in the picture, I would say. As binary is not just -text and turns other things off, those other things will be off after these three. Is that how attribute lookup works? I.e., given a path, all attributes are collected? Isn't it more like: Here we are interested in the eol attribute of this file named a.foo. And the lookup would find the first line that says eol=crlf. Elsewhere, we are interested in the binary attribute of the file named a.foo, and lookup would find the second line that sets the binary attribute. And again elsewhere, we ask for the text attribute, and we find the last line that sets the text property. Am I totally off track? -- Hannes -- 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] remote-curl: fall back to Basic auth if Negotiate fails
On Wed, Mar 11, 2015 at 07:33:05PM +, Dan Langille (dalangil) wrote: On Mar 10, 2015, at 6:29 PM, brian m. carlson sand...@crustytoothpaste.net wrote: Does it work with a ticket if you specify a username, as in the following URL? https://b...@git.crustytoothpaste.net/git/bmc/homedir.git Yes, that does work. Our project is 98% of the way there now. I looked at both libcurl and git environment variables to see if there was a way to specify the user without putting it in the URL. I didn’t see one. My next step is the git configuration, either server or client. Do you know if I should stop looking now because it’s not there? You might try looking at git config --help. It looks like there's a credential.username option that might do what you want. -- 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 signature.asc Description: Digital signature
Re: [PATCH v4] rev-list: refuse --first-parent combined with --bisect
On Tue, Mar 10, 2015 at 04:12:18PM -0700, Junio C Hamano wrote: Kevin Daudt m...@ikke.info writes: git log --bisect seems to do something different then git rev-list --bisect From git-log(1): Pretend as if the bad bisection ref refs/bisect/bad was listed and as if it was followed by --not and the good bisection refs refs/bisect/good-* on the command line. This seems to just add addition refs to the log command, which seems unrelated to what rev-list --bisect does. So I don't see why git log --bisect --first-parent should be prohibited (unless this combination doesn't make sense on itself). Well, but think if your unless holds true or not yourself first and then say I do not think this combination doesn't make sense, if you truly mean I don't see why ... should be prohibited. What does such a command line _mean_? It tells us this: Define a set by having the bad ref as a positive end, and having all the good refs as negative (uninteresting) boundary. That is a way to show commits that are reachable from the bad one and excluding the ones that are reachable from any of the known-good commits. The area of the graph in the current bisection that contains suspect commits. Now, what does it mean to pull only the first-parent chain starting from the bad one in such a set in the first place? What does the resulting set of commits mean? In that case it will leave out any merged in branches. I recalled reading something about this. Searching found me the GSoC idea: When your project is strictly new features are merged into trunk, never the other way around, it is handy to be able to first find a merge on the trunk that merged a topic to point fingers at when a bug appears, instead of having to drill down to the individual commit on the faulty side branch. So there is definitely a use case for --bisect --first-parent, which would show you those commits that would be part of the bisection. -- 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: git commit --amend safety check?
Peter Krefting pe...@softwolves.pp.se writes: For commit --amend, I would say it would refuse to amend if the commit you are trying to amend 1. was not authored by yourself (and --reset-author was not given), or 2. is reachable (or is the tip?) from an upstream branch. I agree that 2. is a safe check without too much risk to trigger a false positive (and the tip of origin/master is reachable from origin/master, so we do not have to single out is the tip). On the other hand, 1. may be good in training wheel mode, but once you start allowing amends and rebases, I do not see why it should be considered possibly bad as long as check 2. says it is OK to rewrite. At least (1) would have saved myself from mistakes that take time and effort to clean up (I have used Git for eight years or so already, and I *still* do that kind of mistake every now and then). Isn't your friend reflog helping you to clean things up? The difference between the state before you started amending and the current state is what you did since then, 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: Surprising interaction of binary and eol gitattributes
Torsten Bögershausen tbo...@web.de writes: On 03/10/2015 11:54 PM, Junio C Hamano wrote: Michael Haggerty mhag...@alum.mit.edu writes: Well, that's true, but the eol attribute can regain its effect if binary is followed by text or text=auto. So I guess the simplest question is as follows. Suppose I have the following .gitattributes: a.foo eol=crlf a.foo binary a.foo text As binary is not just -text and turns other things off, those other things will be off after these three. Not sure if I follow: Whenever you specify -text, the eol doesn't matter, or what do I miss ? Something unrelated to the main theme of this topic ;-). I was just saying that saying a.foo text is not a way to take your earlier mistake of saying a.foo binary back, if that binary was placed on the path by mistake or an over-eager globbing. The 'text' attribute will be reset, but -diff you placed on the path by saying binary is still there after these three attribute lines and running git diff a.foo would sill show the effect from it. -- 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
What's cooking in git.git (Mar 2015, #04; Wed, 11)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. It is becoming clear that the upcoming release will be a usual incremental improvements and not an earth shattering one. Let's decide to name it 2.4, move the top-level RelNotes down to its usual place in Documentation/RelNotes and make it a symbolic link. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [Graduated to master] * jk/diffcore-rename-duplicate (2015-02-27) 2 commits (merged to 'next' on 2015-03-03 at 1d5a2d2) + diffcore-rename: avoid processing duplicate destinations + diffcore-rename: split locate_rename_dst into two functions A corrupt input to git diff -M can cause us to segfault. * mh/expire-updateref-fixes (2015-03-05) 9 commits (merged to 'next' on 2015-03-05 at 1caf9a6) + reflog_expire(): never update a reference to null_sha1 + reflog_expire(): ignore --updateref for symbolic references + reflog: improve and update documentation + struct ref_lock: delete the force_write member + lock_ref_sha1_basic(): do not set force_write for missing references + write_ref_sha1(): move write elision test to callers + write_ref_sha1(): remove check for lock == NULL + Merge branch 'sb/atomic-push' into mh/ref-trans-value-check + Merge branch 'mh/reflog-expire' into mh/ref-trans-value-check Various issues around reflog expire, e.g. using --updateref when expiring a reflog for a symbolic reference, have been corrected and/or made saner. -- [New Topics] * kn/git-cd-to-empty (2015-03-06) 1 commit - git: treat git -C 'path' as a no-op when path is empty git -C '' subcmd refused to work in the current directory, unlike cd '' which silently behaves as a no-op. Will merge to 'next'. * dj/log-graph-with-no-walk (2015-03-10) 1 commit - revision: forbid combining --graph and --no-walk git log --graph --no-walk A B... is a otcnflicting request that asks nonsense; no-walk tells us show discrete points in the history, while graph asks to draw connections between these discrete points. Forbid the combination. Will replace with the version that does not special case git show that implies --no-walk unless it is given a range. * km/bsd-shells (2015-03-10) 5 commits - t5528: do not fail with FreeBSD shell - help.c: use SHELL_PATH instead of hard-coded /bin/sh - git-compat-util.h: move SHELL_PATH default into header - git-instaweb: use @SHELL_PATH@ instead of /bin/sh - git-instaweb: allow running in a working tree subdirectory Portability fixes and workarounds for shell scripts have been added to help BSD-derived systems. Will merge to 'next'. * km/bsd-sysctl (2015-03-10) 2 commits - thread-utils.c: detect CPU count on older BSD-like systems - configure: support HAVE_BSD_SYSCTL option We now detect number of CPUs on older BSD-derived systems. Will merge to 'next'. * km/imap-send-libcurl-options (2015-03-10) 1 commit - imap-send: use cURL automatically when NO_OPENSSL defined git imap-send learned to optionally talk with an IMAP server via libcURL; because there is no other option when Git is built with NO_OPENSSL option, use that codepath by default under such configuration. Will merge to 'next'. * mg/doc-status-color-slot (2015-03-10) 1 commit - config,completion: add color.status.unmerged Documentation fixes. Will merge to 'next'. * mg/verify-commit (2015-03-10) 1 commit - t7510: do not fail when gpg warns about insecure memory Workarounds for certain build of GPG that triggered false breakage in a test.. Will merge to 'next'. * rs/use-isxdigit (2015-03-10) 1 commit - use isxdigit() for checking if a character is a hexadecimal digit Code cleanup. Will merge to 'next'. * sb/leaks (2015-03-10) 3 commits - builtin/help.c: fix memory leak - bundle.c: fix memory leak - connect.c: do not leak conn after showing diagnosis Code cleanup. Will merge to 'next'. -- [Stalled] * jk/push-config (2015-02-17) 4 commits - [NEEDSACK] push: allow --follow-tags to be set by config push.followTags - cmd_push: pass flags pointer to config callback - cmd_push: set atomic bit directly - git_push_config: drop cargo-culted wt_status pointer Waiting for Ack and/or update for the tip one from Dave Olszewski ($gmane/263880, $gmane/263991). * nd/untracked-cache (2015-02-09) 24 commits - git-status.txt: advertisement for untracked cache - untracked cache: guard and disable on system changes - mingw32: add uname() - t7063: tests for untracked cache - update-index: test the system before enabling untracked cache - update-index: manually enable or disable untracked cache - status: enable untracked cache - untracked-cache:
[PATCH] git-completion: add stashes for gitk
Auto complete stashed modifications for gitk. This makes them easier to
discover and faster to view.
Signed-off-by: Sveinung Kvilhaugsvik sveinun...@users.sourceforge.net
---
contrib/completion/git-completion.bash | 2 ++
1 file changed, 2 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index c21190d..3a23abb 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2644,6 +2644,8 @@ __gitk_main ()
;;
esac
__git_complete_revlist
+ __gitcomp_nl_append $(git --git-dir=$(__gitdir) stash list \
+ | sed -n -e 's/:.*//p')
}
if [[ -n ${ZSH_VERSION-} ]]; then
--
2.1.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 v2 01/10] Define a structure for object IDs.
On Tue, Mar 10, 2015 at 07:38:42PM -0700, Kyle J. McKay wrote:
GIT_SHA1_HEXSZ will always be exactly 2 * GIT_SHA1_RAWSZ, right? In
fact, if it's not things will almost certainly break, yes?
Does it make more sense then to reflect this requirement by using:
#define GIT_SHA1_HEXSZ (2 * GIT_SHA1_RAWSZ)
instead?
Yes. I'll make that change in the next version.
I don't see anything wrong with this. However, in part 02/10 the
utility functions all use oid in their names, so I'm thinking that
it may make more sense to just go with:
struct object_id {
unsigned char oid[GIT_SHA1_RAWSZ];
};
to match?
Michael Haggerty recommended that I call the structure element sha1
instead of oid in case we want to turn this into a union if we decide to
go the additional hash route.
I think it can also improve readability if we use oid only for the
instances of the struct itself, especially since it makes it more
obvious what code has been converted already.
--
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
signature.asc
Description: Digital signature
Re: Promoting Git developers
On 12 March 2015 at 08:28, Junio C Hamano gits...@pobox.com wrote: OK, I've updated the Announce script on the 'todo' branch. The announcement for 2.3.2 I sent out earlier as $gmane/264975 would have looked like this. I think the changes are excellent, and think they add a lot of value regardless of any other measures that might be introduced, such as Git Traffic. At the least it gives long time lurkers, and people who skim the list, an easy way to put 'names to code', and it promotes the very people who should be promoted. Thanks to everyone involved in making this happen. Regards, Andrew Ardill -- 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 04/10] archive.c: convert to use struct object_id
On Wed, Mar 11, 2015 at 03:20:08PM +0100, Michael Haggerty wrote:
On 03/08/2015 12:23 AM, brian m. carlson wrote:
struct directory {
struct directory *up;
- unsigned char sha1[20];
+ unsigned char sha1[GIT_SHA1_RAWSZ];
This is a local struct, and I think it is only a three-line change to
change the sha1 member to
struct object_id oid;
Though perhaps you are delaying that change for some concrete reason.
No, I just overlooked it. I'll fix that in the re-roll.
--
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
signature.asc
Description: Digital signature
Re: [PATCH v2 01/10] Define a structure for object IDs.
brian m. carlson sand...@crustytoothpaste.net writes:
Michael Haggerty recommended that I call the structure element sha1
instead of oid in case we want to turn this into a union if we decide to
go the additional hash route.
I'd advise against it.
As I wrote in $gmane/265337 in response to Michael:
4. We continue to support working with SHA-1s declared to be (unsigned
char *) in some performance-critical code, even as we migrate most other
code to using SHA-1s embedded within a (struct object_id). This will
cost some duplication of code. To accept this approach, we would need an
idea of *how much* code duplication would be needed. E.g., how many
functions will need both (unsigned char *) versions and (struct
object_id *) versions?
...
I do not know what kind of code duplication you are worried about,
though. If a callee needs unsigned char *, the caller that has a
struct object_id *o should pass o-hash to the callee.
And that would break the abstraction effort if you start calling the
field with a name that is specific to the underlying hash function.
The caller has to change o-sha1 to o-sha256 instead of keeping
that as o-oid and letting the callee handle the implementation
details when calling
if (!hashcmp(o1-oid, o2-oid))
; /* they are the same */
else
; /* they are different */
The only folks that need to _know_ what hash function is used or
how long the field is are the ones that have raw bytes of the hash
obtained from files (e.g. from the index) and they would do
something like this to implement a function that checks the file
records an object name that is expected by the caller:
void check_oid(int fd, struct object_id *expected)
{
unsigned char object_name[GIT_HASH_RAWSZ];
...
read(fd, object_name, GIT_HASH_RAWSZ);
if (hashcmp(object_name, expected-oid))
die(object name mismatch???);
}
or when they do know they are using a specific function, do:
void compute_object_name(struct object_id *id,
unsignd char*data,
size_t len)
{
git_SHA_CTX c;
unsigned char *sha1 = (id-oid);
/* if we are paranoid... */
assert(sizeof(id-oid) = 20);
...
git_SHA1_Init(c);
git_SHA1_Update(c, data, len);
...
git_SHA1_Final(sha1, c);
}
Even the latter would not be helped if the field to store the hash
were named id-sha1 very much, I would think.
--
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 v3 1/4] git-credential-store: support multiple credential files
Previously, git-credential-store only supported storing credentials in a
single file: ~/.git-credentials. In order to support the XDG base
directory specification[1], git-credential-store needs to be able to
lookup and erase credentials from multiple files, as well as to pick the
appropriate file to write to so that the credentials can be found on
subsequent lookups.
[1] http://standards.freedesktop.org/basedir-spec/basedir-spec-0.7.html
Note that some credential storage files may not be owned, readable or
writable by the user, as they may be system-wide files that are meant to
apply to every user.
Instead of a single file path, lookup_credential(), remove_credential()
and store_credential() now take a precedence-ordered string_list of
file paths. lookup_credential() expects both user-specific and
system-wide credential files to be provided to support the use case of
system administrators setting default credentials for users.
remove_credential() and store_credential() expect only the user-specific
credential files to be provided as usually the only config files that
users are allowed to edit are their own user-specific ones.
lookup_credential() will read these (user-specific and system-wide) file
paths in order until it finds the 1st matching credential and print it.
As some files may be private and thus unreadable, any file which cannot
be read will be ignored silently.
remove_credential() will erase credentials from all (user-specific)
files in the list. This is because if credentials are only erased from
the file with the highest precedence, a matching credential may still be
found in a file further down the list. (Note that due to the lockfile
code, this requires the directory to be writable, which should be so for
user-specific config files)
store_credential() will write the credentials to the first existing
(user-specific) file in the list. If none of the files in the list
exist, store_credential() will write to the filename specified by
default_fn, thus creating it. For backwards compatibility, default_fn
should be ~/.git-credentials.
Helped-by: Matthieu Moy matthieu@grenoble-inp.fr
Helped-by: Junio C Hamano gits...@pobox.com
Helped-by: Jeff King p...@peff.net
Signed-off-by: Paul Tan pyoka...@gmail.com
---
Previous version can be found at [1].
[1] http://thread.gmane.org/gmane.comp.version-control.git/265042/focus=265038
The changes are as follows:
* store_credential(), instead of taking an index to the string_list for the
default filename, takes a filename string instead as it leads to a more
flexible API.
credential-store.c | 78 +-
1 file changed, 53 insertions(+), 25 deletions(-)
diff --git a/credential-store.c b/credential-store.c
index 925d3f4..803bed2 100644
--- a/credential-store.c
+++ b/credential-store.c
@@ -6,7 +6,7 @@
static struct lock_file credential_lock;
-static void parse_credential_file(const char *fn,
+static int parse_credential_file(const char *fn,
struct credential *c,
void (*match_cb)(struct credential *),
void (*other_cb)(struct strbuf *))
@@ -14,18 +14,20 @@ static void parse_credential_file(const char *fn,
FILE *fh;
struct strbuf line = STRBUF_INIT;
struct credential entry = CREDENTIAL_INIT;
+ int found_credential = 0;
fh = fopen(fn, r);
if (!fh) {
- if (errno != ENOENT)
+ if (errno != ENOENT errno != EACCES)
die_errno(unable to open %s, fn);
- return;
+ return found_credential;
}
while (strbuf_getline(line, fh, '\n') != EOF) {
credential_from_url(entry, line.buf);
if (entry.username entry.password
credential_match(c, entry)) {
+ found_credential = 1;
if (match_cb) {
match_cb(entry);
break;
@@ -38,6 +40,7 @@ static void parse_credential_file(const char *fn,
credential_clear(entry);
strbuf_release(line);
fclose(fh);
+ return found_credential;
}
static void print_entry(struct credential *c)
@@ -64,21 +67,10 @@ static void rewrite_credential_file(const char *fn, struct
credential *c,
die_errno(unable to commit credential store);
}
-static void store_credential(const char *fn, struct credential *c)
+static void store_credential_file(const char *fn, struct credential *c)
{
struct strbuf buf = STRBUF_INIT;
- /*
-* Sanity check that what we are storing is actually sensible.
-* In particular, we can't make a URL without a protocol field.
-* Without either a host or pathname (depending on the scheme),
-* we have no primary key. And without a username and password,
-* we are not actually
[PATCH v3 4/4] t0302: test credential-store support for XDG_CONFIG_HOME
t0302 now tests git-credential-store's support for the XDG user-specific configuration file $XDG_CONFIG_HOME/git/credentials. Specifically: * Ensure that the XDG file is strictly opt-in. It should not be created by git at all times if it does not exist. * On the flip side, if the XDG file exists, ~/.git-credentials should not be created at all times. * If both the XDG file and ~/.git-credentials exists, then both files should be used for credential lookups. However, credentials should only be written to ~/.git-credentials. * Credentials must be erased from both files. * $XDG_CONFIG_HOME can be a custom directory set by the user as per the XDG base directory specification. Test that git-credential-store respects that, but defaults to ~/.config/git/credentials if it does not exist or is empty. Helped-by: Matthieu Moy matthieu@grenoble-inp.fr Helped-by: Junio C Hamano gits...@pobox.com Signed-off-by: Paul Tan pyoka...@gmail.com --- The previous version can be found at [1]. [1] http://thread.gmane.org/gmane.comp.version-control.git/265042/focus=265041 The changes are as follows: * Corrected code style violations: All tests are now separated by newlines. * After $XDG_CONFIG_HOME is set to $HOME/xdg, use $XDG_CONFIG_HOME directly for all paths instead of $HOME/xdg. Thanks Matthieu for the code review. t/t0302-credential-store.sh | 107 1 file changed, 107 insertions(+) diff --git a/t/t0302-credential-store.sh b/t/t0302-credential-store.sh index f61b40c..34752ea 100755 --- a/t/t0302-credential-store.sh +++ b/t/t0302-credential-store.sh @@ -6,4 +6,111 @@ test_description='credential-store tests' helper_test store +test_expect_success '~/.git-credentials is written to when xdg credentials file does not exist' ' + test -s $HOME/.git-credentials +' + +test_expect_success 'xdg credentials file will not be created if it does not exist' ' + test_path_is_missing $HOME/.config/git/credentials +' + +test_expect_success 'create $XDG_CONFIG_HOME/git/credentials file' ' + test_might_fail rm $HOME/.git-credentials + mkdir -p $HOME/.config/git + $HOME/.config/git/credentials +' + +helper_test store + +test_expect_success 'xdg credentials file will be written to if it exists' ' + test -s $HOME/.config/git/credentials +' + +test_expect_success '~/.git-credentials will not be created if xdg credentials file exists' ' + test_path_is_missing $HOME/.git-credentials +' + +test_expect_success 'set up custom XDG_CONFIG_HOME credential file' ' + XDG_CONFIG_HOME=$HOME/xdg export XDG_CONFIG_HOME + mkdir -p $XDG_CONFIG_HOME/git + $XDG_CONFIG_HOME/git/credentials + $HOME/.config/git/credentials +' + +helper_test store + +test_expect_success 'custom XDG_CONFIG_HOME credentials file will be written to if it exists' ' + test_when_finished unset XDG_CONFIG_HOME + test -s $XDG_CONFIG_HOME/git/credentials +' + +test_expect_success '~/.config/git/credentials file will not be written to if a custom XDG_CONFIG_HOME is set' ' + test_must_be_empty $HOME/.config/git/credentials +' + +test_expect_success '~/.git-credentials will not be created if xdg credentials file exists' ' + test_path_is_missing $HOME/.git-credentials +' + +test_expect_success 'get: return credentials from home file if matches are found in both home and xdg files' ' + mkdir -p $HOME/.config/git + echo https://xdg-user:xdg-p...@example.com; $HOME/.config/git/credentials + echo https://home-user:home-p...@example.com; $HOME/.git-credentials + check fill store -\EOF + protocol=https + host=example.com + -- + protocol=https + host=example.com + username=home-user + password=home-pass + -- + EOF +' + +test_expect_success 'get: return credentials from xdg file if the home files do not have them' ' + mkdir -p $HOME/.config/git + $HOME/.git-credentials + echo https://home-user:home-p...@example.com; $HOME/.config/git/credentials + check fill store -\EOF + protocol=https + host=example.com + -- + protocol=https + host=example.com + username=home-user + password=home-pass + -- + EOF +' + +test_expect_success 'get: return credentials from home file if xdg files are unreadable' ' + mkdir -p $HOME/.config/git + echo https://xdg-user:xdg-p...@example.com; $HOME/.config/git/credentials + echo https://home-user:home-p...@example.com; $HOME/.git-credentials + chmod -r $HOME/.config/git/credentials + check fill store -\EOF + protocol=https + host=example.com + -- + protocol=https + host=example.com + username=home-user + password=home-pass + -- + EOF +' + +test_expect_success 'erase: erase matching credentials from both xdg and home files' ' + mkdir -p
[PATCH v3 0/4] git-credential-store: XDG user-specific config file support
The previous patch series can be found at [1].
[1] http://thread.gmane.org/gmane.comp.version-control.git/265042
The changes for git-credential-store: support multiple credential files are
as follows:
* store_credential(), instead of taking an index to the string_list for the
default filename, takes a filename string instead as it leads to a more
flexible API.
The changes for t0302: test credential-store support for XDG_CONFIG_HOME are
as follows:
* Corrected code style violations: All tests are now separated by newlines.
* After $XDG_CONFIG_HOME is set to $HOME/xdg, use $XDG_CONFIG_HOME directly
for all paths instead of $HOME/xdg.
Thanks Matthieu for the code review.
The diff between the previous patch series is as follows:
diff --git a/credential-store.c b/credential-store.c
index 7b22a3a..b00f80f 100644
--- a/credential-store.c
+++ b/credential-store.c
@@ -88,7 +88,7 @@ static void store_credential_file(const char *fn, struct
credential *c)
}
static void store_credential(const struct string_list *fns, struct credential
*c,
-unsigned int default_index)
+const char *default_fn)
{
struct string_list_item *fn;
@@ -107,8 +107,9 @@ static void store_credential(const struct string_list *fns,
struct credential *c
store_credential_file(fn-string, c);
return;
}
- /* Write credential to the filename at default_index, creating it */
- store_credential_file(fns-items[default_index].string, c);
+ /* Write credential to default_fn, thus creating it */
+ if (default_fn)
+ store_credential_file(default_fn, c);
}
static void remove_credential(const struct string_list *fns, struct credential
*c)
@@ -182,7 +183,7 @@ int main(int argc, char **argv)
else if (!strcmp(op, erase))
remove_credential(fns, c);
else if (!strcmp(op, store))
- store_credential(fns, c, 0);
+ store_credential(fns, c, fns.items[0].string);
else
; /* Ignore unknown operation. */
diff --git a/t/t0302-credential-store.sh b/t/t0302-credential-store.sh
index 7fe832d..34752ea 100755
--- a/t/t0302-credential-store.sh
+++ b/t/t0302-credential-store.sh
@@ -5,41 +5,53 @@ test_description='credential-store tests'
. $TEST_DIRECTORY/lib-credential.sh
helper_test store
+
test_expect_success '~/.git-credentials is written to when xdg credentials
file does not exist' '
test -s $HOME/.git-credentials
'
+
test_expect_success 'xdg credentials file will not be created if it does not
exist' '
test_path_is_missing $HOME/.config/git/credentials
'
+
test_expect_success 'create $XDG_CONFIG_HOME/git/credentials file' '
test_might_fail rm $HOME/.git-credentials
mkdir -p $HOME/.config/git
$HOME/.config/git/credentials
'
+
helper_test store
+
test_expect_success 'xdg credentials file will be written to if it exists' '
test -s $HOME/.config/git/credentials
'
+
test_expect_success '~/.git-credentials will not be created if xdg credentials
file exists' '
test_path_is_missing $HOME/.git-credentials
'
+
test_expect_success 'set up custom XDG_CONFIG_HOME credential file' '
XDG_CONFIG_HOME=$HOME/xdg export XDG_CONFIG_HOME
- mkdir -p $HOME/xdg/git
- $HOME/xdg/git/credentials
+ mkdir -p $XDG_CONFIG_HOME/git
+ $XDG_CONFIG_HOME/git/credentials
$HOME/.config/git/credentials
'
+
helper_test store
+
test_expect_success 'custom XDG_CONFIG_HOME credentials file will be written
to if it exists' '
- unset XDG_CONFIG_HOME
- test -s $HOME/xdg/git/credentials
+ test_when_finished unset XDG_CONFIG_HOME
+ test -s $XDG_CONFIG_HOME/git/credentials
'
+
test_expect_success '~/.config/git/credentials file will not be written to if
a custom XDG_CONFIG_HOME is set' '
test_must_be_empty $HOME/.config/git/credentials
'
+
test_expect_success '~/.git-credentials will not be created if xdg credentials
file exists' '
test_path_is_missing $HOME/.git-credentials
'
+
test_expect_success 'get: return credentials from home file if matches are
found in both home and xdg files' '
mkdir -p $HOME/.config/git
echo https://xdg-user:xdg-p...@example.com;
$HOME/.config/git/credentials
@@ -55,6 +67,7 @@ test_expect_success 'get: return credentials from home file
if matches are found
--
EOF
'
+
test_expect_success 'get: return credentials from xdg file if the home files
do not have them' '
mkdir -p $HOME/.config/git
$HOME/.git-credentials
@@ -70,6 +83,7 @@ test_expect_success 'get: return credentials from xdg file if
the home files do
--
EOF
'
+
test_expect_success 'get: return credentials from home file if xdg files are
unreadable' '
mkdir -p $HOME/.config/git
echo
[PATCH v3 3/4] docs/git-credential-store: document XDG file and precedence
git-credential-store now supports an additional default credential file at $XDG_CONFIG_HOME/git/credentials. However, ~/.git-credentials takes precedence over it for backwards compatibility. To make the precedence ordering explicit, add a new section FILES that lists out the credential file paths in their order of precedence, and explains how the ordering affects the lookup, storage and erase operations. Also update documentation for --store to briefly explain the operations on multiple files if the --store option is not provided. Signed-off-by: Paul Tan pyoka...@gmail.com --- Documentation/git-credential-store.txt | 37 -- 1 file changed, 35 insertions(+), 2 deletions(-) diff --git a/Documentation/git-credential-store.txt b/Documentation/git-credential-store.txt index bc97071..451c4fa 100644 --- a/Documentation/git-credential-store.txt +++ b/Documentation/git-credential-store.txt @@ -31,10 +31,43 @@ OPTIONS --file=path:: - Use `path` to store credentials. The file will have its + Use `path` to lookup and store credentials. The file will have its filesystem permissions set to prevent other users on the system from reading it, but will not be encrypted or otherwise - protected. Defaults to `~/.git-credentials`. + protected. If not specified, credentials will be searched for from + `~/.git-credentials` and `$XDG_CONFIG_HOME/git/credentials`, and + credentials will be written to `~/.git-credentials` if it exists, or + `$XDG_CONFIG_HOME/git/credentials` if it exists and the former does + not. See also FILES. + +[[FILES]] +FILES +- + +If not set explicitly with '--file', there are two files where +git-credential-store will search for credentials in order of precedence: + +~/.git-credentials:: + User-specific credentials file. + +$XDG_CONFIG_HOME/git/credentials:: + Second user-specific credentials file. If '$XDG_CONFIG_HOME' is not set + or empty, `$HOME/.config/git/credentials` will be used. Any credentials + stored in this file will not be used if `~/.git-credentials` has a + matching credential as well. It is a good idea not to create this file + if you sometimes use older versions of Git, as support for this file + was added fairly recently. + + +For credential lookups, the files are read in the order given above, with the +first matching credential found taking precedence over credentials found in +files further down the list. + +Credential storage will per default write to the first existing file in the +list. If none of these files exist, `~/.git-credentials` will be created and +written to. + +When erasing credentials, matching credentials will be erased from all files. EXAMPLES -- 2.1.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
[PATCH v3 2/4] git-credential-store: support XDG_CONFIG_HOME
Add $XDG_CONFIG_HOME/git/credentials to the default credential search
path of git-credential-store. This allows git-credential-store to
support user-specific configuration files in accordance with the XDG
base directory specification[1].
[1] http://standards.freedesktop.org/basedir-spec/basedir-spec-0.7.html
~/.git-credentials has a higher precedence than
$XDG_CONFIG_HOME/git/credentials when looking up credentials. This
means that if any duplicate matching credentials are found in the xdg
file (due to ~/.git-credentials being updated by old versions of git or
outdated tools), they will not be used at all. This is to give the user
some leeway in switching to old versions of git while keeping the xdg
directory. This is consistent with the behavior of git-config.
However, the higher precedence of ~/.git-credentials means that as long
as ~/.git-credentials exist, all credentials will be written to the
~/.git-credentials file even if the user has an xdg file as having a
~/.git-credentials file indicates that the user wants to preserve
backwards-compatibility. This is also consistent with the behavior of
git-config.
Since the xdg file will not be used unless it actually exists, to
prevent the situation where some credentials are present in the xdg file
while some are present in the home file, users are recommended to not
create the xdg file if they require compatibility with old versions of
git or outdated tools. Note, though, that erase can be used to
explicitly erase matching credentials from all files.
Helped-by: Matthieu Moy matthieu@grenoble-inp.fr
Helped-by: Junio C Hamano gits...@pobox.com
Helped-by: Jeff King p...@peff.net
Signed-off-by: Paul Tan pyoka...@gmail.com
---
credential-store.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/credential-store.c b/credential-store.c
index 803bed2..b00f80f 100644
--- a/credential-store.c
+++ b/credential-store.c
@@ -163,11 +163,16 @@ int main(int argc, char **argv)
usage_with_options(usage, options);
op = argv[0];
- if (!file)
- file = expand_user_path(~/.git-credentials);
- if (file)
+ if (file) {
string_list_append_nodup(fns, file);
- else
+ } else {
+ if ((file = expand_user_path(~/.git-credentials)))
+ string_list_append_nodup(fns, file);
+ home_config_paths(NULL, file, credentials);
+ if (file)
+ string_list_append_nodup(fns, file);
+ }
+ if (!fns.nr)
die(unable to set up default path; use --file);
if (credential_read(c, stdin) 0)
--
2.1.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: [PATCHv2 0/2] log decorations for HEAD
Junio C Hamano venit, vidit, dixit 10.03.2015 18:06: Michael J Gruber g...@drmicha.warpmail.net writes: So it didn't take too long to convince me after all :) Here comes Junio's version, preceded by a cleanup of the color setting and resetting for decorations. Junio C Hamano (1): log: decorate HEAD with branch name Michael J Gruber (1): log-tree: properly reset colors log-tree.c| 76 ++- t/t4013/diff.log_--decorate_--all | 2 +- t/t4207-log-decoration-colors.sh | 16 - 3 files changed, 77 insertions(+), 17 deletions(-) Hmph, is the do not leak commit color one the same as 5ee87585 (log --decorate: do not leak commit color into the next item, 2015-03-04) aka $gmane/264788 [*1*] or is there something I missed? Uh, I missed that one. The commit msg confuses me somewhat (color.diff vs color.decorate), but the patch to log-tree.c is the same, and so I assume the patch to t4207 is the same, too. 2/2 from here should go on top of 7/7 from there, accordingly. [References] *1* http://thread.gmane.org/gmane.comp.version-control.git/264063/focus=264788 -- 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: git commit --amend safety check?
On Tue, Mar 10, 2015 at 10:11 PM, Junio C Hamano gits...@pobox.com wrote:
Shawn Pearce spea...@spearce.org writes:
We keep seeing reports of Gerrit Code Review users who incorrectly do
something like:
git clone URL foo
cd foo
git commit --amend -m My first change! -a
git push URL HEAD:refs/for/master
Step #3 is where they get into trouble. They just amended the
published tip commit and pushed it back to the server. That is... lets
just say not good.
Hg is known to be more user friendly. One way its user friendly is it
by default refuses to let you amend a change set that the client has
reasonable assertion to believe was already published through a remote
repository.
Well, it is not Git that is less user friendly, but Gerrit is the
problem. More specifically, the last line:
git push URL HEAD:refs/for/master
is what catches this non-fast-forward in usual workflow with Git.
OK, replace that Gerrit-specific push syntax with:
git send-email
:)
Even in mailing list based workflows we ask Git users to use git
commit to make their new commit and git commit --amend to polish it
up. New users are often confused and cargo-culting their Git usage
because they cannot be bothered to actually learn the tools they are
using; they are too busy learning all of the other tools they need,
like their programming language or the latest jQuery plugin.
Wouldn't the real problem that the refs/for/master magic accepts
anything, even a non-fast-forward?
I see your argument. But this was a conscious design choice.
It is already untenable to ask users sending you patches on git ML to
first fetch and rebase *their* working tree against your latest master
before they run git send-email. The async nature of when you publish
your tree vs. when they prepared their commit makes it likely that at
least some of the patches you receive were based on a different tip
than what you most recently published.
On very fast moving development repositories that have hundreds of
developers working against them during the bulk of the working day the
tip can be advancing more rapidly than users have the patience to run:
while ! ( git pull --rebase git push origin HEAD:refs/for/master ); do
echo Retrying ...
done
Having said that, disabling --amend and forcing to use --force or
something when it is clear that the user is attempting something
unusual is a good idea. But I am not sure what the definition of
unusual should be. In a non-Gerrit central repository workflow, the
rule might be HEAD must not be reachable from @{upstream}
(otherwise you are rewriting what you got from elsewhere), or it may
be HEAD must not be reachable from @{publish}'s remote tracking
branch, or perhaps both, as these two could be different in
triangular workflow.
But I am not sure what the sensible rules are when the user prepares
the commit, planning to push it to a ref like refs/for/master that
does not have a counterpart on our side.
True.
Another way users get into a bind is they pull someone else's branch
(so they can build on top of her work), then `git commit --amend -a`
by mistake instead of making a new commit. Now they mixed their work
with her last commit. Then they push this.
Currently Gerrit Code Review accepts that as an intentional squash to
further polish her proposed change. And why not? I can take a patch
proposed by Peff from the mailing list, `commit --amend` additional
polishing, and resend with attribution^Wblame to Peff.
Perhaps Gerrit Code Review should reject this by default unless the
user has some sort of Yes I know what I am doing bit toggled on her
user account.
That only mildly helps the poor newbie who has no idea how to
unstick their Git repository. Most users just rm -rf the directory,
reclone, and start over from scratch, meanwhile complaining that Git
lost hours of their work.
Nevermind that one could probably get out of such a jam with something like:
git diff HEAD@{1}..HEAD P
git reset --hard HEAD@{1}
git apply --index P ; rm P
If only they knew how to use their tools. :(
--
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: Promoting Git developers
On Wed, Mar 11, 2015 at 12:31 AM, Jeff King p...@peff.net wrote: On Tue, Mar 10, 2015 at 07:36:34PM -0700, Junio C Hamano wrote: Or if that would make the release notes too cumbersome to review, what about using systemd's method? systemd's release notes include a contributions from section at the very end that lists everyone with a patch included in the release. I can add shortlog --no-merges -s -n v2.3.0..v2.4.0 at the end of the e-mail when the release notes is sent out. That might be a good enough balance between the usefulness of the release notes to its customers and giving credits to individuals in a way a bit more visible than if you are interested, run shortlog yourself [*4*]. I somehow thought you already did this, but it looks like you just do shortlog (without the -ns) for the maint release announcement. That is because (a) it is scripted in Meta/Announce, and (b) I strip it out for feature releases, as the plain shortlog output with full feature list is usually ends up being just too long for the announce message. Perhaps I'll add shortlog -s | pr -3 or something at the end for both maintenance track and feature releases. Names only, unordered and hopefully not overly long. -- 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: git commit --amend safety check?
On Tue, Mar 10, 2015 at 11:18:45PM -0700, Junio C Hamano wrote: One thing we already do is to give an extra Author: line in the comment when the user edits the log message, so that it is clear that what is being edited is not their own work but hers. We obviously can add the extra warning, when the is_ancestor() thing triggers, to say YOU ARE REWRITING PUBLISHED HISTORY in blinking red bold letters there. But the symptom indicates that they are not reading these warning comment. Maybe they would if the warnings were a big paragraph *before* the commit message (but brains are easily trained to recognize patterns and skip them, so that would need to be done for very specific warnings, not for everything that's printed in a git commit editor). Mike -- 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: git commit --amend safety check?
On Tue, Mar 10, 2015 at 11:00 PM, Shawn Pearce spea...@spearce.org wrote:
OK, replace that Gerrit-specific push syntax with:
git send-email
:)
Heh don't be too defensive; I was merely pulling your leg.
... But I am not sure what the definition of
unusual should be. In a non-Gerrit central repository workflow, the
rule might be HEAD must not be reachable from @{upstream}
(otherwise you are rewriting what you got from elsewhere), or it may
be HEAD must not be reachable from @{publish}'s remote tracking
branch, or perhaps both, as these two could be different in
triangular workflow.
But I am not sure what the sensible rules are when the user prepares
the commit, planning to push it to a ref like refs/for/master that
does not have a counterpart on our side.
True.
With a more concrete example, I'd imagine you have something like
this to wok on branch master
[remote origin]
url = ...
pushurl = ...
fetch = +refs/heads/*:refs/remotes/origin/*
push = refs/heads/*:refs/for/*
[branch master]
merge = refs/heads/master
Even though we cannot prevent the user from rewriting what _he_
already pushed out to refs/for/master (as we do not have the record
of what the last thing we pushed there and its history via a reflog),
we could at least detect when he attempts to rewrite what he
obtained directly from the upstream by noticing where origin/master
is. If HEAD is _at_ that commit, or its ancestor, then he is trying to
rewrite what he got from elsewhere.
It would catch your original commit --amend -m 'my first' scenario.
Run is_ancestor(HEAD, @{upstream}) we can notice. That may be
better than nothing, but I do not offhand know if that is sufficient.
Another way users get into a bind is they pull someone else's branch
(so they can build on top of her work), then `git commit --amend -a`
by mistake instead of making a new commit.
One thing we already do is to give an extra Author: line in the
comment when the user edits the log message, so that it is clear
that what is being edited is not their own work but hers. We obviously
can add the extra warning, when the is_ancestor() thing triggers, to
say YOU ARE REWRITING PUBLISHED HISTORY in blinking red
bold letters there.
But the symptom indicates that they are not reading these warning
comment. Perhaps it is necessary to introduce a training wheel mode
where you cannot use --amend and -m options from the command
line until you ask nicely to override it?
--
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 4/4] t0302: test credential-store support for XDG_CONFIG_HOME
On Wed, Mar 11, 2015 at 2:49 AM, Paul Tan pyoka...@gmail.com wrote: t0302 now tests git-credential-store's support for the XDG user-specific configuration file $XDG_CONFIG_HOME/git/credentials. Specifically: * Ensure that the XDG file is strictly opt-in. It should not be created by git at all times if it does not exist. * On the flip side, if the XDG file exists, ~/.git-credentials should not be created at all times. * If both the XDG file and ~/.git-credentials exists, then both files should be used for credential lookups. However, credentials should only be written to ~/.git-credentials. Regarding the final sentence: I don't see a test corresponding to the restriction that only ~/.git-credentials will be modified if both files exist. Am I missing something? More below. * Credentials must be erased from both files. * $XDG_CONFIG_HOME can be a custom directory set by the user as per the XDG base directory specification. Test that git-credential-store respects that, but defaults to ~/.config/git/credentials if it does not exist or is empty. Helped-by: Matthieu Moy matthieu@grenoble-inp.fr Helped-by: Junio C Hamano gits...@pobox.com Signed-off-by: Paul Tan pyoka...@gmail.com --- diff --git a/t/t0302-credential-store.sh b/t/t0302-credential-store.sh index f61b40c..34752ea 100755 --- a/t/t0302-credential-store.sh +++ b/t/t0302-credential-store.sh @@ -6,4 +6,111 @@ test_description='credential-store tests' helper_test store +test_expect_success '~/.git-credentials is written to when xdg credentials file does not exist' ' + test -s $HOME/.git-credentials +' + +test_expect_success 'xdg credentials file will not be created if it does not exist' ' + test_path_is_missing $HOME/.config/git/credentials Since these two tests are complementary, each checking a facet of the same behavioral rule, it seems like they ought to be combined. For people reading the tests, having them separate implies incorrectly that they are unrelated, making it difficult to understand the overall picture of how the pieces relate to one another. In prose, you would describe the behavior as: When XDG credentials does not exist, write only to ~/.git-credentials; do not create XDG credentials. It's one thought; easy to read and understand. The test should reflect the same intent: test_expect_success '...' ' test -s $HOME/.git-credentials test_path_is_missing $HOME/.config/git/credentials ' The same observation applies to several other tests below. +' + +test_expect_success 'create $XDG_CONFIG_HOME/git/credentials file' ' + test_might_fail rm $HOME/.git-credentials Can this just be rm -f $HOME/.git-credentials instead? + mkdir -p $HOME/.config/git + $HOME/.config/git/credentials +' + +helper_test store + +test_expect_success 'xdg credentials file will be written to if it exists' ' + test -s $HOME/.config/git/credentials +' + +test_expect_success '~/.git-credentials will not be created if xdg credentials file exists' ' + test_path_is_missing $HOME/.git-credentials Ditto: It seems like these two tests should be combined. +' + +test_expect_success 'set up custom XDG_CONFIG_HOME credential file' ' + XDG_CONFIG_HOME=$HOME/xdg export XDG_CONFIG_HOME + mkdir -p $XDG_CONFIG_HOME/git + $XDG_CONFIG_HOME/git/credentials + $HOME/.config/git/credentials +' + +helper_test store + +test_expect_success 'custom XDG_CONFIG_HOME credentials file will be written to if it exists' ' + test_when_finished unset XDG_CONFIG_HOME + test -s $XDG_CONFIG_HOME/git/credentials +' It feels wrong to set global state (XDG_CONFIG_HOME) in one test and then clear it later in another test, and it's not obvious to the casual reader that global state is being modified. An alternative would be to set XDG_CONFIG_HOME outside of the first test to which it applies, clear it after the final test. In reality, however, it only needs to be defined for the helper_test store invocation, so it also could be highly localized: XDG_CONFIG_HOME=$HOME/xdg export XDG_CONFIG_HOME helper_test store unset XDG_CONFIG_HOME A final alternative would be to wrap the block of tests needing XDG_CONFIG_HOME within a subshell and set the variable only within the subshell. Then, there's no need to unset it, and it's clear to the reader that only the tests within the subshell are affected by it. + +test_expect_success '~/.config/git/credentials file will not be written to if a custom XDG_CONFIG_HOME is set' ' + test_must_be_empty $HOME/.config/git/credentials +' + +test_expect_success '~/.git-credentials will not be created if xdg credentials file exists' ' + test_path_is_missing $HOME/.git-credentials For clarity, the three above tests probably ought to be combined. +' + +test_expect_success 'get: return credentials from home file if matches are
Re: [PATCH v3 3/4] docs/git-credential-store: document XDG file and precedence
On Wed, Mar 11, 2015 at 2:49 AM, Paul Tan pyoka...@gmail.com wrote: git-credential-store now supports an additional default credential file at $XDG_CONFIG_HOME/git/credentials. However, ~/.git-credentials takes precedence over it for backwards compatibility. To make the precedence ordering explicit, add a new section FILES that lists out the credential file paths in their order of precedence, and explains how the ordering affects the lookup, storage and erase operations. Also update documentation for --store to briefly explain the operations on multiple files if the --store option is not provided. Signed-off-by: Paul Tan pyoka...@gmail.com --- diff --git a/Documentation/git-credential-store.txt b/Documentation/git-credential-store.txt index bc97071..451c4fa 100644 --- a/Documentation/git-credential-store.txt +++ b/Documentation/git-credential-store.txt @@ -31,10 +31,43 @@ OPTIONS +[[FILES]] +FILES +- + +If not set explicitly with '--file', there are two files where +git-credential-store will search for credentials in order of precedence: + +~/.git-credentials:: + User-specific credentials file. + +$XDG_CONFIG_HOME/git/credentials:: + Second user-specific credentials file. If '$XDG_CONFIG_HOME' is not set + or empty, `$HOME/.config/git/credentials` will be used. Any credentials + stored in this file will not be used if `~/.git-credentials` has a + matching credential as well. It is a good idea not to create this file + if you sometimes use older versions of Git, as support for this file + was added fairly recently. The final sentence won't age well: fairly recently is too nebulous. It may be sufficient merely to advise the reader to avoid this file if she also uses an older version of Git which doesn't support XDG for credentials. Other than this minor point, the patch series seems well prepared and quite nicely done. Thanks. +For credential lookups, the files are read in the order given above, with the +first matching credential found taking precedence over credentials found in +files further down the list. + +Credential storage will per default write to the first existing file in the +list. If none of these files exist, `~/.git-credentials` will be created and +written to. + +When erasing credentials, matching credentials will be erased from all files. EXAMPLES -- 2.1.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: Promoting Git developers
On Wed, Mar 11, 2015 at 12:38:21AM -0700, Junio C Hamano wrote:
I can add shortlog --no-merges -s -n v2.3.0..v2.4.0 at the end of
the e-mail when the release notes is sent out. That might be a good
enough balance between the usefulness of the release notes to its
customers and giving credits to individuals in a way a bit more
visible than if you are interested, run shortlog yourself [*4*].
I somehow thought you already did this, but it looks like you just do
shortlog (without the -ns) for the maint release announcement.
That is because (a) it is scripted in Meta/Announce, and (b) I strip it
out for feature releases, as the plain shortlog output with full feature
list is usually ends up being just too long for the announce message.
Yeah, I figured the length was the reason.
Perhaps I'll add shortlog -s | pr -3 or something at the end for both
maintenance track and feature releases. Names only, unordered and
hopefully not overly long.
Yes, I was thinking something along those lines. Maybe:
# example
old=v2.2.0
new=v2.3.0
# like shortlog -s, but we do not even care about the numbers
shortlog () {
git log --format=%aN $@ | sort -u
}
compact () {
perl -lne 'push @x, $_; END { print join(, , @x) }' |
fold -s
}
count () {
shortlog $old..$new | wc -l
}
newbies () {
comm -23 (shortlog $old..$new) (shortlog $old) | compact
}
oldtimers () {
comm -12 (shortlog $old..$new) (shortlog $old) | compact
}
cat EOF
Git $new was developed with commits from $(count) people. Thanks very
much to our returning developers:
$(oldtimers)
and welcome to new contributors in this release:
$(newbies)
EOF
Or something along those lines. The wording and indentation of the
message could probably use tweaking. And there is a bash-ism in the
script. :)
-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: git commit --amend safety check?
Junio C Hamano: Having said that, disabling --amend and forcing to use --force or something when it is clear that the user is attempting something unusual is a good idea. But I am not sure what the definition of unusual should be. For commit --amend, I would say it would refuse to amend if the commit you are trying to amend 1. was not authored by yourself (and --reset-author was not given), or 2. is reachable (or is the tip?) from an upstream branch. Of course, you should be able to do the amend commit, but then you would need to say something like git commit --amend --force to indicate that you really want to do that. At least (1) would have saved myself from mistakes that take time and effort to clean up (I have used Git for eight years or so already, and I *still* do that kind of mistake every now and then). -- \\// Peter - http://www.softwolves.pp.se/ -- 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] config.txt: stick to CamelCase naming convention
On Tue, Mar 10, 2015 at 9:11 PM, Torsten Bögershausen tbo...@web.de wrote: On 10.03.15 11:39, Nguyễn Thái Ngọc Duy wrote: Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- .. while I'm looking at config.txt. I think this is the preferred naming convention for config keys. I think the default is unix-like lowercase, this is what Git itself produces. (core.ignorecase, core.filemode, core.precomposeunicode) You made me look back in history. Nobody actually mentioned about filemode vs fileMode. And config.txt is a mixed bag. But I think fileMode is better for reading. -- Duy -- 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 v2] *config.txt: stick to camelCase naming convention
This should improve readability. Compare thislongname and thisLongName. The following keys are left in unchanged. We can decide what to do with them later. - am.keepcr - core.autocrlf .safecrlf .trustctime - diff.dirstat .noprefix - gitcvs.usecrlfattr - gui.blamehistoryctx .trustmtime - pull.twohead - receive.autogc - sendemail.signedoffbycc .smtpsslcertpath .suppresscc Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- Documentation/config.txt | 190 - Documentation/diff-config.txt | 8 +- Documentation/merge-config.txt | 2 +- 3 files changed, 100 insertions(+), 100 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 1530255..54ae0f6 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -225,7 +225,7 @@ See linkgit:git-update-index[1]. + The default is true (when core.filemode is not specified in the config file). -core.ignorecase:: +core.ignoreCase:: If true, this option enables various workarounds to enable Git to work better on filesystems that are not case sensitive, like FAT. For example, if a directory listing finds @@ -237,7 +237,7 @@ The default is false, except linkgit:git-clone[1] or linkgit:git-init[1] will probe and set core.ignorecase true if appropriate when the repository is created. -core.precomposeunicode:: +core.precomposeUnicode:: This option is only used by Mac OS implementation of Git. When core.precomposeunicode=true, Git reverts the unicode decomposition of filenames done by Mac OS. This is useful when sharing a repository @@ -264,13 +264,13 @@ core.trustctime:: crawlers and some backup systems). See linkgit:git-update-index[1]. True by default. -core.checkstat:: +core.checkStat:: Determines which stat fields to match between the index and work tree. The user can set this to 'default' or 'minimal'. Default (or explicitly 'default'), is to check all fields, including the sub-second part of mtime and ctime. -core.quotepath:: +core.quotePath:: The commands that output paths (e.g. 'ls-files', 'diff'), when not given the `-z` option, will quote unusual characters in the pathname by enclosing the @@ -476,7 +476,7 @@ core.compression:: If set, this provides a default to other compression variables, such as 'core.loosecompression' and 'pack.compression'. -core.loosecompression:: +core.looseCompression:: An integer -1..9, indicating the compression level for objects that are not in a pack file. -1 is the zlib default. 0 means no compression, and 1..9 are various speed/size tradeoffs, 9 being @@ -537,7 +537,7 @@ be delta compressed, but larger binary media files won't be. + Common unit suffixes of 'k', 'm', or 'g' are supported. -core.excludesfile:: +core.excludesFile:: In addition to '.gitignore' (per-directory) and '.git/info/exclude', Git looks into this file for patterns of files which are not meant to be tracked. `~/` is expanded @@ -546,7 +546,7 @@ core.excludesfile:: If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/ignore is used instead. See linkgit:gitignore[5]. -core.askpass:: +core.askPass:: Some commands (e.g. svn and http interfaces) that interactively ask for a password can be told to use an external program given via the value of this variable. Can be overridden by the 'GIT_ASKPASS' @@ -555,7 +555,7 @@ core.askpass:: prompt. The external program shall be given a suitable prompt as command-line argument and write the password on its STDOUT. -core.attributesfile:: +core.attributesFile:: In addition to '.gitattributes' (per-directory) and '.git/info/attributes', Git looks into this file for attributes (see linkgit:gitattributes[5]). Path expansions are made the same @@ -569,7 +569,7 @@ core.editor:: variable when it is set, and the environment variable `GIT_EDITOR` is not set. See linkgit:git-var[1]. -core.commentchar:: +core.commentChar:: Commands such as `commit` and `tag` that lets you edit messages consider a line that begins with this character commented, and removes them after the editor returns @@ -638,7 +638,7 @@ core.whitespace:: is relevant for `indent-with-non-tab` and when Git fixes `tab-in-indent` errors. The default tab width is 8. Allowed values are 1 to 63. -core.fsyncobjectfiles:: +core.fsyncObjectFiles:: This boolean will enable 'fsync()' when writing object files. + This is a total waste of time and effort on a filesystem that orders @@ -646,7 +646,7 @@ data writes properly, but can be useful for filesystems that do not use journalling (traditional UNIX filesystems) or that only journal metadata and not file contents (OS X's HFS+, or Linux ext3 with data=writeback).
Re: [PATCH v2 02/10] Define utility functions for object IDs.
On 03/08/2015 12:23 AM, brian m. carlson wrote:
There are several utility functions (hashcmp and friends) that are used
for comparing object IDs (SHA-1 values). Using these functions, which
take pointers to unsigned char, with struct object_id requires tiresome
access to the sha1 member, which bloats code and violates the desired
encapsulation. Provide wrappers around these functions for struct
object_id for neater, more maintainable code. Use the new constants to
avoid the hard-coded 20s and 40s throughout the original functions.
These functions simply call the underlying pointer-to-unsigned-char
versions to ensure that any performance improvements will be passed
through to the new functions.
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
I'm not very excited about having to put the #include in the middle of
cache.h. The alternative, of course, is to move enum object_type up,
which I can do if necessary. Another alternative is to simply move the
struct object_id definitions to cache.h instead of object.h, which might
be cleaner.
I'm interested in hearing opinions about the best way to go forward.
cache.h | 37 +
hex.c | 16 +---
2 files changed, 46 insertions(+), 7 deletions(-)
diff --git a/cache.h b/cache.h
index 761c570..f9addcc 100644
--- a/cache.h
+++ b/cache.h
[...]
@@ -724,20 +729,42 @@ static inline int hashcmp(const unsigned char *sha1,
const unsigned char *sha2)
return 0;
}
+static inline int oidcmp(const struct object_id *o1, const struct object_id
*o2)
+{
+ return hashcmp(o1-sha1, o2-sha1);
+}
+
Maybe rename o1 - oid1 and o2 - oid2 just to make things blindingly
obvious?
[...]
Michael
--
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
Re: [JFF] - and @{-1} on various programs
Junio C Hamano venit, vidit, dixit 10.03.2015 21:20:
JFF stands for just for fun.
This is not meant to give out a model answer and is known to be
incomplete, but I was wondering if it would be a better direction to
allow - as a stand-in for @{-1} everywhere we allow a branch
name, losing workarounds at the surface level we have for checkout,
merge and revert.
The first three paths are to remove the surface workarounds that
become unnecessary. The one in sha1_name.c is the central change.
The change in revision.c is to allow a single - to be recognized
as a potential revision name (without this change, what begins with
- is either an option or an unknown option).
So you could do things like git reset - $path but also things like
git log - after switching out of a branch.
What does not work are what needs further tweaking in revision.c
parser. git checkout master git checkout next git log -..
should show what next has on top of master but I didn't touch the
range notation so it does not work, for example.
builtin/checkout.c | 3 ---
builtin/merge.c| 3 +--
builtin/revert.c | 2 --
revision.c | 2 +-
sha1_name.c| 57
+-
5 files changed, 37 insertions(+), 30 deletions(-)
Like it :)
It removes the special casing and makes a shorthand available
systematically. I'd say it's useful even without extending it to ranges.
Michae
--
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: Any chance for a Git v2.1.5 release?
The first two messages in this thread were dropped by the vger mailing list for some unknown reason. In an attempt to make the mailing list archives of this thread complete, the original two messages in this thread are included below. -Kyle BEGIN FIRST MESSAGE From: Kyle J. McKay mack...@gmail.com Date: February 24, 2015 09:16:05 PST To: Junio C Hamano gits...@pobox.com Cc: Git Mailing List git@vger.kernel.org Subject: Any chance for a Git v2.1.5 release? Message-Id: c5211e53-8905-41c9-9d28-26d7bb51e...@gmail.com Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes As you know, I help out with repo.or.cz. Recently the admins have been discussing upgrading the version of Git we use in order to support newer features such as pack bitmaps. While we do use a slightly customized gitweb, we have always stuck to an official Git release for everything else. Repo.or.cz provides fetch (git, http, https, ssh), browsing (gitweb) and push (ssh, https). Additionally, created repositories can be mirrors (no push allowed) of other repositories (including svn via git- svn). Email notification of ref changes (along with diffs) can also be requested. We are finding that in order to upgrade Git at this point we would need to build a custom Git with cherry picked fixes for various issues that have come up or they would likely be triggered by one of the services repo.or.cz provides. In addition, as there are numerous reports of an unresolved issue with git-svn starting with v2.2.0 upgrading to v2.2.0 or later presents a problem since we have several mirrors that rely on git-svn. Which brings us back to the subject of this email, is there any chance for a v2.1.5 release? After reviewing a few release dates: 2011-06-26T12:41:26-07:00 v1.7.6 2012-02-05T23:51:07-08:00 v1.7.6.6 2013-11-27T12:14:52-08:00 v1.8.5 2014-02-13T13:42:01-08:00 v1.8.5.5 2014-02-14T11:36:11-08:00 v1.9.0 2014-05-30T10:15:10-07:00 v1.9.4 2014-05-28T11:04:29-07:00 v2.0.0 2014-07-30T14:20:01-07:00 v2.0.4 2014-08-15T15:09:28-07:00 v2.1.0 2014-10-29T10:48:57-07:00 v2.1.3 2014-11-26T13:18:43-08:00 v2.2.0 2015-01-12T14:06:20-08:00 v2.2.2 2015-02-05T13:24:05-08:00 v2.3.0 (I have omitted the dates of the 5 security releases on 2014-12-17 as that seems like an extraordinary event unlikely to be repeated.) It appears that the average support lifespan of a Git release from initial release date through last released maintenance update is approximately 2-3 months with the 1.7.6 release being an exception at a little over 7 months. If a v2.1.5 release is out of the question, would it be possible to periodically designate certain Git releases as long term support releases? Meaning that they would receive maintenance updates (e.g. fixes for invalid memory accesses/crashes, regressions or security issues) for an extended period of time, say at least 6 months? Here's the analysis that led to this request: Goal 1: add support for symref=HEAD:refs/... capability Goal 2: add support for pack bitmaps Nice to have: The CVE-2014-9390 fix, but repo.or.cz does not create any working trees so it's not mandatory. Goal 1: symref=HEAD:refs/... requires at least Git 1.8.4.3. However, repo.or.cz runs git-daemon with read-only access to the repositories and since Git 1.8.4.2 shallow clones require write access. This was corrected in v2.0.0. So at least v2.0.0 would be needed for symref=HEAD:refs/ Goal 2: Pack bitmap support was added in v2.0.0, but it's probably not a good idea to run without 21134714 (pack-objects: turn off bitmaps when we split packs) just in case which requires at least v2.1.3. Nice to have: If at least v2.1.3 is required, then we might as well use v2.1.4 since the primary change from v2.1.3 to v2.1.4 is the addition of the CVE-2014-9390 fix. What about a later release, v2.2.0 or later? git-svn is reported to suffer from occasional .git/ Git_svn_hash_XX: Bad file descriptor errors since v2.2.0 making that a non-starter. No fix is currently available in the Git repository. Since 660c889e (sha1_file: add for_each iterators for loose and packed objects) loose objects in alternates directories may not be found when pruning. This affects v2.2.0 and later. A fix is currently in master. This is an absolute must have for repo.or.cz as alternates are used to implement repository forks. Since d38379e (make update-server-info more robust), affecting v2.2.x, the files used by non-smart HTTP clients could have the wrong permissions. This might preclude them from being updated correctly on repo.or.cz. It would require research to see if repo.or.cz is affected. The fix for this d91175b2 (update-server-info: create info/ * with mode 0666) was released in v2.3.0. So why not v2.1.4 then? There's an XDL_FAST_HASH performance regression that affects v1.7.11 and later [1]. But that can be turned
Rip and transfer Blu-ray films to Galaxy Note Pro 12.2
Rip and transfer Blu-ray films to Galaxy Note Pro 12.2 Want to put Blu-ray onto Galaxy Note Pro 12.2 for watching on the go, but don't know what to do? Get the solution below to rip Blu-ray to Note Pro native video. I have some Blu-ray discs like Amour and Ernest amp; Clementine from the local library in Knokke-Heist. What can I do to make copies of these Blu-ray movies for downloading onto my Galaxy Note Pro 12.2? Then I can watch them when I have the time for or I can take them while traveling for watching on the go. Still stick with your Galaxy Note Pro 12.2 for Blu-ray enjoyment? Through hours'searching online, I got know that Galaxy Note Pro 12.2 will not recognize Blu-ray without having to do something. The best way is to convert my Blu-ray to Galaxy Note Pro 12.2 friendly MP4 http://samsung-galaxy-video-converter.blogspot.com/2013/12/galaxy-note-recommend-format.html with a Blu-ray ripping tool I guess. Well, Pavtube BDMagic http://www.multipelife.com/bdmagic is the tool I've been used for nearly one year. It should be the app helping me finish the Blu-ray ripping task. With this top Blu-ray to Galaxy Note Pro Converter, I can perfectly convert massive Blu-ray/DVD data as well as ISO/IFO files into common videos that Galaxy Note Pro can deal with. (I choose Pavtube since other products were not able to provide greater resolution for my new Samsung Galaxy Note Pro 12.2.) Plus, with the Blu-ray ripper, I can also backup Blu-ray, DVD movies to your hard drive with the original structures. * Read Top 5 Reasons to choose Pavtube BDMagic http://media-playback.jimdo.com/2014/06/24/top-5-reasons-to-choose-bdmagic/ If you are on Mac, turn to BDMagic for Mac http://www.multipelife.com/bdmagic-mac . Don't hesitate to get it now and follow the easy steps below to make your Blu-rays playable anywhere on Galaxy Note Pro 12.2. How to rip Blu-ray movies to Galaxy Note Pro 12.2 playback format Step 1: Run the best Blu-ray to Galaxy Note Pro Converter and click Blu-ray disc icon to load your Blu-ray movie files. http://open-mobile-share.com/wp-content/uploads/2014/06/blu-ray-to-galaxy-note.png Step 2: Click Format bar, here I recommend Samsung gt;gt; Samsung Galaxy Note(*.mp4) as target format for your Galaxy Note Pro 12.2 with the best video amp; audio settings. http://open-mobile-share.com/wp-content/uploads/2014/06/galaxy-note-format.png Tip: By clicking the Settings button, you can modify the video/audio parameters like 1920*1080 (Full HD 1080P video resolution), which can help you get the ripped Blu-ray movies with high quality. http://open-mobile-share.com/wp-content/uploads/2014/06/galaxy-note-settings.png Step 3: Select subtitle and audio track language you like from the Subtitle and Audio options. If you like, you can also check Only show forced subtitles to make it possible for playback HD videos with forced subtitles on your Galaxy Note Pro 12.2. Step 4: Hit the Convert button to start converting Blu-ray movies to Galaxy Note Pro video. After a short conversion, you will get the ripped Blu-ray files. And then you could transfer http://mediaconverting.blogspot.com/2013/10/transfer-music-video-file-to-galaxy-note-3.html Blu-ray movies to Samsung Galaxy Note Pro 12.2 and find the videos for HD playback. More related: Get SD/HD video onto Galaxy Note Pro 12.2 http://bestvideosolution.blogspot.com/2014/05/watch-the-hobbit-movie-on-galaxy-note-pro.html Get Rid of the DRM on Disney Digital Copy to play on Galaxy Note Pro http://samsung-galaxy-video-converter.blogspot.com/2014/12/transfer-digital-copy-to-galaxy-note-pro.html Best solution to enable DVD VOB files to play on Galaxy Note Pro 12.2 http://formatplayable.jimdo.com/2014/03/10/enjoy-dvd-vob-on-galaxy-note-pro-12-2/ Put and Play Blu-ray ISO movies on Samsung Galaxy Note Pro 12.2 http://media-playback.jimdo.com/2014/03/11/convert-blu-ray-iso-to-galaxy-note-pro-12-2/ Put 1080p or 720p HD Videos to Samsung Galaxy Note Edge http://www.multipelife.com/put-1080p-720p-video-to-galaxy-note-edge.html Play Blu-ray amp; DVD Movies on Samsung Galaxy Note Edge http://www.multipelife.com/play-blu-ray-dvd-on-galaxy-note-edge.html Source: http://techmovieshare.blogspot.com/2014/11/put-blu-ray-to-galaxy-note-pro.html http://techmovieshare.blogspot.com/2014/11/put-blu-ray-to-galaxy-note-pro.html -- View this message in context: http://git.661346.n2.nabble.com/Rip-and-transfer-Blu-ray-films-to-Galaxy-Note-Pro-12-2-tp7626933.html Sent from the git mailing list archive at Nabble.com. -- 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 08/10] commit: convert parts to struct object_id
On 03/08/2015 12:24 AM, brian m. carlson wrote:
Convert struct commit_graft and necessary local parts of commit.c.
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
commit.c | 32
commit.h | 4 ++--
log-tree.c| 2 +-
send-pack.c | 2 +-
shallow.c | 8
upload-pack.c | 2 +-
6 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/commit.c b/commit.c
index a8c7577..89c207e 100644
--- a/commit.c
+++ b/commit.c
@@ -55,12 +55,12 @@ struct commit *lookup_commit(const unsigned char *sha1)
struct commit *lookup_commit_reference_by_name(const char *name)
{
- unsigned char sha1[20];
+ struct object_id oid;
struct commit *commit;
- if (get_sha1_committish(name, sha1))
+ if (get_sha1_committish(name, oid.sha1))
return NULL;
- commit = lookup_commit_reference(sha1);
+ commit = lookup_commit_reference(oid.sha1);
if (parse_commit(commit))
return NULL;
return commit;
@@ -99,7 +99,7 @@ static int commit_graft_alloc, commit_graft_nr;
static const unsigned char *commit_graft_sha1_access(size_t index, void
*table)
{
struct commit_graft **commit_graft_table = table;
- return commit_graft_table[index]-sha1;
+ return commit_graft_table[index]-oid.sha1;
}
static int commit_graft_pos(const unsigned char *sha1)
@@ -110,7 +110,7 @@ static int commit_graft_pos(const unsigned char *sha1)
int register_commit_graft(struct commit_graft *graft, int ignore_dups)
{
- int pos = commit_graft_pos(graft-sha1);
+ int pos = commit_graft_pos(graft-oid.sha1);
if (0 = pos) {
if (ignore_dups)
@@ -148,12 +148,12 @@ struct commit_graft *read_graft_line(char *buf, int len)
i = (len + 1) / 41 - 1;
graft = xmalloc(sizeof(*graft) + 20 * i);
graft-nr_parent = i;
- if (get_sha1_hex(buf, graft-sha1))
+ if (get_oid_hex(buf, graft-oid))
goto bad_graft_data;
for (i = 40; i len; i += 41) {
if (buf[i] != ' ')
goto bad_graft_data;
- if (get_sha1_hex(buf + i + 1, graft-parent[i/41]))
+ if (get_sha1_hex(buf + i + 1, graft-parent[i/41].sha1))
goto bad_graft_data;
}
There are a bunch of constants in this function related to
GIT_SHA1_RAWSZ and GIT_SHA1_HEXSZ.
return graft;
@@ -302,7 +302,7 @@ int parse_commit_buffer(struct commit *item, const void
*buffer, unsigned long s
{
const char *tail = buffer;
const char *bufptr = buffer;
- unsigned char parent[20];
+ struct object_id parent;
struct commit_list **pptr;
struct commit_graft *graft;
@@ -312,10 +312,10 @@ int parse_commit_buffer(struct commit *item, const void
*buffer, unsigned long s
tail += size;
if (tail = bufptr + 46 || memcmp(bufptr, tree , 5) || bufptr[45] !=
'\n')
return error(bogus commit object %s,
sha1_to_hex(item-object.sha1));
- if (get_sha1_hex(bufptr + 5, parent) 0)
+ if (get_sha1_hex(bufptr + 5, parent.sha1) 0)
return error(bad tree pointer in commit %s,
sha1_to_hex(item-object.sha1));
- item-tree = lookup_tree(parent);
+ item-tree = lookup_tree(parent.sha1);
bufptr += 46; /* tree + hex sha1 + \n */
pptr = item-parents;
Here, too; e.g.,
* 45 - GIT_SHA1_HEXSZ + 5
* 46 - GIT_SHA1_HEXSZ + 5 + 1
and below,
* 47 - GIT_SHA1_HEXSZ + 7
* 48 - GIT_SHA1_HEXSZ + 7 + 1
@@ -324,7 +324,7 @@ int parse_commit_buffer(struct commit *item, const void
*buffer, unsigned long s
struct commit *new_parent;
if (tail = bufptr + 48 ||
- get_sha1_hex(bufptr + 7, parent) ||
+ get_sha1_hex(bufptr + 7, parent.sha1) ||
bufptr[47] != '\n')
return error(bad parents in commit %s,
sha1_to_hex(item-object.sha1));
bufptr += 48;
@@ -334,7 +334,7 @@ int parse_commit_buffer(struct commit *item, const void
*buffer, unsigned long s
*/
if (graft (graft-nr_parent 0 || grafts_replace_parents))
continue;
- new_parent = lookup_commit(parent);
+ new_parent = lookup_commit(parent.sha1);
if (new_parent)
pptr = commit_list_insert(new_parent, pptr)-next;
}
@@ -342,7 +342,7 @@ int parse_commit_buffer(struct commit *item, const void
*buffer, unsigned long s
int i;
struct commit *new_parent;
for (i = 0; i graft-nr_parent; i++) {
- new_parent = lookup_commit(graft-parent[i]);
+ new_parent = lookup_commit(graft-parent[i].sha1);
if (!new_parent)
continue;
Re: Promoting Git developers
On Tue, Mar 10, 2015 at 07:36:34PM -0700, Junio C Hamano wrote: Or if that would make the release notes too cumbersome to review, what about using systemd's method? systemd's release notes include a contributions from section at the very end that lists everyone with a patch included in the release. I can add shortlog --no-merges -s -n v2.3.0..v2.4.0 at the end of the e-mail when the release notes is sent out. That might be a good enough balance between the usefulness of the release notes to its customers and giving credits to individuals in a way a bit more visible than if you are interested, run shortlog yourself [*4*]. I somehow thought you already did this, but it looks like you just do shortlog (without the -ns) for the maint release announcement. This does seem like a very simple thing we could to promote visibility of contributors, and one would that would not require any ongoing effort once it is initially scripted. It may even be a nice place to specifically call out contributors who are new in this release. I spent many years as a type C contributor, and I remember how nice it was to see my name mentioned occasionally as a useful person. -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: git commit --amend safety check?
On Tue, Mar 10, 2015 at 11:18:45PM -0700, Junio C Hamano wrote:
Even though we cannot prevent the user from rewriting what _he_
already pushed out to refs/for/master (as we do not have the record
of what the last thing we pushed there and its history via a reflog),
we could at least detect when he attempts to rewrite what he
obtained directly from the upstream by noticing where origin/master
is. If HEAD is _at_ that commit, or its ancestor, then he is trying to
rewrite what he got from elsewhere.
It would catch your original commit --amend -m 'my first' scenario.
Run is_ancestor(HEAD, @{upstream}) we can notice. That may be
better than nothing, but I do not offhand know if that is sufficient.
I think rebase basically suffers the same problem, too. Perhaps it
happens less there because we choose @{upstream} as the default fork
point. But rewriting commits is a potential problem any time they are
referenced somewhere else. For example, if you do this:
git checkout -b topic origin/master
... commit commit commit ...
git checkout -b subtopic
... commit commit commit ...
git checkout topic
git rebase ;# or git pull --rebase
you are left with doppelganger commits in subtopic, which you probably
want to handle by rebasing it (with --fork-point).
I kind of wonder if the check should just be is the commit you are
rewriting mentioned in _any_ ref except the current HEAD?.
In theory we could even give advice based on the command and the ref we
find that contains the commit (e.g., if it's another local branch,
suggest rebasing that branch. If it's in @{upstream}, suggest commit
without --amend if that was the command given). But I'm not at all
confident that we could cover all cases thoroughly enough to do more
good than harm.
Another way users get into a bind is they pull someone else's branch
(so they can build on top of her work), then `git commit --amend -a`
by mistake instead of making a new commit.
One thing we already do is to give an extra Author: line in the
comment when the user edits the log message, so that it is clear
that what is being edited is not their own work but hers. We obviously
can add the extra warning, when the is_ancestor() thing triggers, to
say YOU ARE REWRITING PUBLISHED HISTORY in blinking red
bold letters there.
But the symptom indicates that they are not reading these warning
comment. Perhaps it is necessary to introduce a training wheel mode
where you cannot use --amend and -m options from the command
line until you ask nicely to override it?
It's entirely possible to me that the Author line is too subtle, and a
bigger warning might do the trick.
At the very least printing a warning that can be suppressed with
advice.* would match our usual technique for dealing with possible
mistakes like this (as opposed to blocking the action entirely). And we
can always bump the severity of the warning (or introduce blocking) if
it doesn't have an effect.
I dunno. It feels like such a warning would probably trigger as a false
positive way too often and get in people's way. But then, I am not
exactly the target audience for the warning, so my perspective is a bit
skewed. I do think it has a reasonable chance of irritating old-timers,
even with an escape hatch. Were you thinking that training-wheel mode
would have to be turned on explicitly?
-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: Promoting Git developers
On Tue, Mar 10, 2015 at 6:23 PM, Junio C Hamano gits...@pobox.com wrote: Christian Couder christian.cou...@gmail.com writes: I don't want to write again about each of these points now. I am more interested in discussing a good strategy to try to revert the sad trend of Git developers being promoted less and less, because I think that it is really very important. I would suspect that those who agree with you would appreciate if you or somebody volunteered to act as our CKDO (chief kudos distribution officer). I do not think I have enough time to do that well. One good place to start might be to scan the list and summarize something like the following on weekly or monthly basis, as these are not something you can get by pointing people to git shortlog output. - Those who gave helpful review comments, how about going this way illustration patches, etc. Bonus points to those who helped onboarding newcomers. - Those who asked pertinent questions on common pain points, and those who answered them helpfully. Ok, I can start something about this two points every week or every few week. It would be best if I could get help from at least one person as I think it is a lot of work. We can perhaps use the Git Developer Site at https://github.com/git/git.github.io to edit a new page collaboratively that would be published on http://git.github.io/ and after that send an email to the mailing list. If you are more ambitious, the source of the kudos may want to cover activities outside of this mailing list (e.g. giving talks and tutorials at conferences, etc.). First I don't know if we should really give kudos (or badges) or have something more like the former Git Traffic you talk about in another email (or perhaps both). And then I expect that if people give talks or tutorials at conferences or publish a blog post or have other news they want to share, they could edit the web page themselves on GitHub (or fork it and send a pull request if they don't have the rights). I also appreciate very much that you are willing to improve the release notes by adding a summary with people's names. It would be nice if we could also have somewhere on a web page at least a good listing of the authors and how many commits they had contributed (since the beginning and maybe also during the last year). We could also add other listings made using the Helped-by and Reviewed-by trailers. I don't think we should rely on an external web site like OpenHub (which is still giving me a 504 Gateway Time-out on the contributor page) or even the (broken) contributor graph on GitHub for that. If Scott and Peff don't want it on git-scm.com then it is of course better on git.github.io than nowhere. Thanks, Christian. -- 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: Promoting Git developers
Duy Nguyen pclo...@gmail.com writes: On Wed, Mar 11, 2015 at 11:16 AM, Junio C Hamano gits...@pobox.com wrote: Duy Nguyen pclo...@gmail.com writes: ... We may want to acknowledge review efforts as well, by grepping Helped-by:, Reviewed-by:... Agreed. Something along the lines of $ git shortlog --no-merges -s -n -t Helped-by -t Reviewed-by v2.3.0.. A quick grep/uniq/sort gives this 1512 Acked-by 537 Reviewed-by 389 Reported-by 317 Helped-by 147 Tested-by 143 Suggested-by 97 Noticed-by 78 Improved-by 49 Thanks-to 40 Mentored-by 23 Requested-by 21 Acked-By 20 Inspired-by 18 Based-on-patch-by 9 Explained-by 9 Contributions-by It looks like people are quite creative. I think all these *-by (so -t supports wildcards) and Thanks-to: could be also considered as contribution. I'd first suggest to employ icase to unify *-By and *-by. Perhaps we would want a recommended list somewhere in SubmittingPatches to discourage people from getting too creative? Acked and Reviewed would be part of the normal review process. Reported, Requested, Noticed, Suggested, Inspired, and Based-on-patch-by are about where the motivation to make the change came from. They try to express modes of communication and degree of involvement of the named person in the process of germinating an idea, and the nature of the change (is it a bug or is it an improvement?), but I wonder if we can standardize these into just a few (or just one) by shedding the various nuances. If the difference these various phrases try to convey is so important, it probably deserves to be in the log message proper (e.g. instead of Inspired-by, say In his blog at $URL, ... expressed frustration in doing ...; this will solve that issue in such and such way in the log, and use the standard trailer that designates where the idea came from). People named by these trailers are the ones that connect us to end users by noticing and relaying their pain points, and by working with us to improve Git. We would want to credit them no less than we do an author of a casual here is a typofix in a comment patch. And everything else above looks Helped-by to me. Again, the different phrases try to convey what kind of help in polishing the change was, but if that is worth expressing, it probably belongs to the log message itself (e.g. instead of Explained-by, say The above explanation was given by ... in $gmane/1369525 in the log message and use Helped-by). -- 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: Promoting Git developers
Jeff King p...@peff.net writes: I spent many years as a type C contributor, and I remember how nice it was to see my name mentioned occasionally as a useful person. I guess that everybody is different ;-) After throwing a small patch at ROCKbox (git.rockbox.org) back when they were still hosted on Subversion, I felt somewhat ashamed to see my name appear in their CREDITS file because the change I made was so insignificant. In such a flat list like that, you cannot tell who made significant contributions over time and who are just a casual drive-by contributor like me, unless you know the community and who are important in the community. -- 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: Promoting Git developers
On Wed, Mar 11, 2015 at 11:16 AM, Junio C Hamano gits...@pobox.com wrote: Duy Nguyen pclo...@gmail.com writes: ... We may want to acknowledge review efforts as well, by grepping Helped-by:, Reviewed-by:... Agreed. Something along the lines of $ git shortlog --no-merges -s -n -t Helped-by -t Reviewed-by v2.3.0.. A quick grep/uniq/sort gives this 1512 Acked-by 537 Reviewed-by 389 Reported-by 317 Helped-by 147 Tested-by 143 Suggested-by 97 Noticed-by 78 Improved-by 49 Thanks-to 40 Mentored-by 23 Requested-by 21 Acked-By 20 Inspired-by 18 Based-on-patch-by 9 Explained-by 9 Contributions-by It looks like people are quite creative. I think all these *-by (so -t supports wildcards) and Thanks-to: could be also considered as contribution. -- Duy -- 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
