Re: Why is git fetch --prune so much slower than git remote prune?
On Fri, Mar 06, 2015 at 05:48:39PM +0100, Ævar Arnfjörð Bjarmason wrote: The --prune option to fetch added in v1.6.5-8-gf360d84 seems to be around 20-30x slower than the equivalent operation with git remote prune. I'm wondering if I'm missing something and fetch does something more, but it doesn't seem so. git fetch --prune is do a normal fetch, and also prune anything necessary. git remote prune is ls-remote the other side and see if there is anything we can prune; do not touch anything else. If your fetch is a noop (i.e., the other side has not advanced any branches), the outcome is the same. But perhaps fetch is doing more work to find out that it is a noop. One way to measure that would be to see how expensive a noop git fetch is (if it's expensive, then there is room to improve there. If not, then it is the pruning itself that is expensive). But just guessing (I do not have time to dig in deeper right now), and seeing this: $ gprof ~/g/git/git-fetch|head -n 20 Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls s/call s/call name 26.42 0.33 0.33 1584583 0.00 0.00 strbuf_getwholeline 14.63 0.51 0.18 90601347 0.00 0.00 strbuf_grow 13.82 0.68 0.17 1045676 0.00 0.00 find_pack_entry_one 8.13 0.78 0.10 1050062 0.00 0.00 check_refname_format 6.50 0.86 0.08 1584675 0.00 0.00 get_sha1_hex 5.69 0.93 0.07 2100529 0.00 0.00 starts_with 3.25 0.97 0.04 1044043 0.00 0.00 refname_is_safe 3.25 1.01 0.04 8007 0.00 0.00 get_packed_ref_cache 2.44 1.04 0.03 2605595 0.00 0.00 search_ref_dir 2.44 1.07 0.03 1040500 0.00 0.00 peel_entry 1.63 1.09 0.02 2632661 0.00 0.00 get_ref_dir 1.63 1.11 0.02 1044043 0.00 0.00 create_ref_entry 1.63 1.13 0.02 8024 0.00 0.00 do_for_each_entry_in_dir 0.81 1.14 0.01 2155105 0.00 0.00 memory_limit_check 0.81 1.15 0.01 1580503 0.00 0.00 sha1_to_hex We spend a lot of time checking refs here. Probably this comes from writing the `packed-refs` file out 1000 times in your example, because fetch handles each ref individually. Whereas since c9e768b (remote: repack packed-refs once when deleting multiple refs, 2014-05-23), git-remote does it in one pass. Now that we have ref_transaction_*, I think if git-fetch fed all of the deletes (along with the updates) into a single transaction, we would get the same optimization for free. Maybe that is even part of some of the pending ref_transaction work from Stefan or Michael (both cc'd). I haven't kept up very well with what is cooking in pu. -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
[ANNOUNCE] Git v2.3.2
The latest maintenance release Git v2.3.2 is now available at the usual places. 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 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. * git fast-import used to crash when it could not close and conclude the resulting packfile cleanly. * git blame died, trying to free an uninitialized piece of memory. * git merge-file did not work correctly in a subdirectory. * git submodule add failed to squash path/to/././submodule to path/to/submodule. * In v2.2.0, we broke git prune that runs in a repository that borrows from an alternate object store. * Certain older vintages of cURL give irregular output from curl-config --vernum, which confused our build system. * An earlier workaround to squelch unhelpful deprecation warnings from the complier on Mac OSX unnecessarily set minimum required version of the OS, which the user might want to raise (or lower) for other reasons. * Longstanding configuration variable naming rules has been added to the documentation. * The credential helper for Windows (in contrib/) used to mishandle a user name with an at-sign in it. * Older GnuPG implementations may not correctly import the keyring material we prepare for the tests to use. * Clarify in the documentation that remote.nick.pushURL and remote.nick.URL are there to name the same repository accessed via different transports, not two separate repositories. * The pack bitmap support did not build with older versions of GCC. * Reading configuration from a blob object, when it ends with a lone CR, use to confuse the configuration parser. * We didn't format an integer that wouldn't fit in int but in uintmax_t correctly. * git push --signed gave an incorrectly worded error message when the other side did not support the capability. * git fetch over a remote-helper that cannot respond to list command could not fetch from a symbolic reference e.g. HEAD. * The insn sheet git rebase -i creates did not fully honor core.abbrev settings. * The tests that wanted to see that file becomes unreadable after running chmod a-r file, and the tests that wanted to make sure it is not run as root, we used can we write into the / directory? as a cheap substitute, but on some platforms that is not a good heuristics. The tests and their prerequisites have been updated to check what they really require. * The configuration variable 'mailinfo.scissors' was hard to discover in the documentation. * Correct a breakage to git-svn around v2.2 era that triggers premature closing of FileHandle. * 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 @ Alexander Kuleshov (1): Git.pm: two minor typo fixes Eric Sunshine (1): builtin/blame: destroy initialized commit_info only Jeff King (8): t/lib-httpd: switch SANITY check for NOT_ROOT t/lib-gpg: include separate public keys in keyring.gpg t/lib-gpg: sanity-check that we can actually sign config: do not ungetc EOF decimal_width: avoid integer overflow config_buf_ungetc: warn when pushing back a random character for_each_loose_file_in_objdir: take an optional strbuf path fast-import: avoid running end_packfile recursively Jonathon Mah (1): sha1_file: fix iterating loose alternate objects Junio C Hamano (7): tests: correct misuses of POSIXPERM config.txt: clarify that add.ignore-errors is deprecated config.txt: mark deprecated variables more prominently Documentation/git-remote.txt: stress that set-url is not for triangular CodingGuidelines: describe naming rules for configuration variables Prepare for 2.3.2 Git 2.3.2 Kirill A. Shutemov (1): rebase -i: use full object name internally throughout the script Kyle J. McKay (3): git-compat-util: do
[PATCH] [GSoC Microproject]Adding - shorthand for @{-1} in RESET command
Hi all, I am a GSoC '15 aspirant for git.
In this commit I have directly associated - to @{-1} except when it refers
to a filename.
All the given tests pass(except those which shouldn't).
I have to add a failsafe for the case in when there is no branch as @{-1}.
For this I have a
rough idea that I would have to call get-sha1() on @{-1} to check if there is
an object matching
with it. But I am not able to think of the details.
Please guide me with that and give feedback for this patch.
Signed-off-by: Sundararajan R dyou...@gmail.com
---
builtin/reset.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/builtin/reset.c b/builtin/reset.c
index 4c08ddc..62764d4 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -203,8 +203,16 @@ static void parse_args(struct pathspec *pathspec,
*
* At this point, argv points immediately after [-opts].
*/
-
+ int flag=0; /*
+* - may refer to filename in which case we should be
giving more precedence
+* to filename than equating argv[0] to @{-1}
+*/
if (argv[0]) {
+ if (!strcmp(argv[0], -) !argv[1]) /* - is the only
argument */
+ {
+ argv[0]=@{-1};
+ flag=1;
+ }
if (!strcmp(argv[0], --)) {
argv++; /* reset to HEAD, possibly with paths */
} else if (argv[1] !strcmp(argv[1], --)) {
@@ -226,6 +234,8 @@ static void parse_args(struct pathspec *pathspec,
rev = *argv++;
} else {
/* Otherwise we treat this as a filename */
+ if(flag)
+ argv[0]=-;
verify_filename(prefix, argv[0], 1);
}
}
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] protocol upload-pack-v2
On Sat, Mar 7, 2015 at 6:38 AM, Stefan Beller sbel...@google.com wrote: +Reference Discovery (v2) + + +In version 2, reference discovery is initiated by the client with +want-refs line. The client may skip reference discovery phase +entirely by not sending want-refs (e.g. the client has another way +to retrieve ref list). + + + want-refs = PKT-LINE(want-refs SP mode *argument) + mode = all + argument = SP arg + arg= 1*(LC_ALPHA / DIGIT / - / _ / =) + On the same line with capabilities, we would not want to run into a situation where we have too many arguments to send and exceed pkt-line limit. So perhaps do one argument per pkt-line too, ending with a pkt-flush. -- 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
Re: [PATCH] protocol upload-pack-v2
I'm still wondering if we should reserve more from the packet length. We have used length for pkt-flush. Shawn pointed out that we still have 0001, 0002 and 0003 but we may use some of them to avoid abuse of pkt-flush in some cases. Perhaps we could limit packet length to 0xfff0, so we have 0xfff1-0x to assign special meanings in future, if we have to. On Sat, Mar 7, 2015 at 6:38 AM, Stefan Beller sbel...@google.com wrote: +In version 2, when the client initially connects, the server +immediately sends its capabilities to the client. Then the client must +send the list of server capabilities it wants to use to the server. + + S: 00XXcapabilities 4\n + S: 00XXcap:lang\n + S: 00XXcap:thin-pack\n + S: 00XXcap:ofs-delta\n + S: 00XXagent:agent=git/2:3.4.5+custom-739-gb850f98\n + + C: 00XXcapabilities 3 + C: 00XXcap:thin-pack\n + C: 00XXcap:ofs-delta\n + C: 00XXcap:lang=en\n + C: 00XXagent:agent=git/custom_string\n + + + cap = PKT-LINE(capabilities SP size LF list) + size = *DIGIT + capability-list = *(capability) [agent LF] + capability = cap: keyvaluepair LF + agent= keyvaluepair LF + keyvaluepair = 1*(LC_ALPHA / DIGIT / - / _ / =) If we send one cap per pkt-line, cap can contain spaces. The question is, should we allow them? Ending cap lines with LF seems redudant because we already know the line length. + LC_ALPHA = %x61-7A + + +The client MUST ignore any data before the pkt-line starting with capabilities +for future easy of extension. + +The server MUST advertise size as the decimal number of lines following +the capabilities line. This includes lines starting cap: and agent: for now. +The client MUST ignore lines which start with an unknown pattern. I think the common pattern in our protocol is to end these with a pkt-flush, instead of send the number of items upfront. If we do that we don't have to specify cap: or agent: either. All pkt-lines until pkt-flush at the beginning of v2 are cap lines. And agent is just another capability. -- 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
Re: [PATCH] daemon: use strbuf for hostname info
Am 06.03.2015 um 22:06 schrieb Jeff King:
On Fri, Mar 06, 2015 at 09:57:22AM +0100, René Scharfe wrote:
if (port) {
- free(tcp_port);
- tcp_port = sanitize_client(port);
+ strbuf_reset(tcp_port);
+ sanitize_client_strbuf(tcp_port, port);
The equivalent of free() is strbuf_release(). I think it is reasonable
to strbuf_reset here, since we are about to write into it again anyway
(though I doubt it happens much in practice, since that would imply
multiple `host=` segments sent by the client). But later...
- free(hostname);
- free(canon_hostname);
- free(ip_address);
- free(tcp_port);
- hostname = canon_hostname = ip_address = tcp_port = NULL;
+ strbuf_reset(hostname);
+ strbuf_reset(canon_hostname);
+ strbuf_reset(ip_address);
+ strbuf_reset(tcp_port);
These probably want to all be strbuf_release(). Again, I doubt it
matters much because this is a forked daemon serving only a single
request (so they'll get freed by the OS soon anyway), but I think
freeing the memory here follows the original intent.
Using a static strbuf means (in my mind) don't worry about freeing,
a memory leak won't happen anyway because we reuse allocations.
The new code adds recycling of allocations, which I somehow expect
in connection with static allocations where possible. You're right
that using strbuf_release() would match the original code more
strictly.
But this block is a no-op anyway because it's the first thing we do
to these (initially empty) variables. That's not immediately
obvious and should be addressed in a separate patch.
René
--
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] daemon: use strbuf for hostname info
On Sat, Mar 07, 2015 at 01:54:12AM +0100, René Scharfe wrote: These probably want to all be strbuf_release(). Again, I doubt it matters much because this is a forked daemon serving only a single request (so they'll get freed by the OS soon anyway), but I think freeing the memory here follows the original intent. Using a static strbuf means (in my mind) don't worry about freeing, a memory leak won't happen anyway because we reuse allocations. The new code adds recycling of allocations, which I somehow expect in connection with static allocations where possible. You're right that using strbuf_release() would match the original code more strictly. I don't mind recycling allocations like this. It's just that I think in this case it makes the code actively more confusing, because we don't actually expect any of these allocations to be recycled, do we? We fork+exec for each daemon connection, which should receive exactly one `host=` parameter. That being said, I don't mind it too much if the recycling stays here. But this block is a no-op anyway because it's the first thing we do to these (initially empty) variables. That's not immediately obvious and should be addressed in a separate patch. Ah, yeah, just reading the diff I thought this was cleanup, not initialization. -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: [PATCH] protocol upload-pack-v2
On Fri, Mar 6, 2015 at 3:38 PM, Stefan Beller sbel...@google.com wrote: From: Duy Nguyen pclo...@gmail.com Oops. I edited the proposal from Duy heavily(?), such that it is different from what he proposed 4 days ago. In my impression this is what most of the participants would agree on. -- 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
A note from the maintainer
[note to regular readers; there are a few updated paragraphs,
regarding our association with SFC and also our security mailing
list.]
Welcome to the Git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address git@vger.kernel.org. You don't have to be
subscribed to send messages. The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say Please Cc: me,
I am not subscribed.
Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.
If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise. Please
do not hesitate to send a reminder message in such a case. Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.
The list archive is available at a few public sites:
http://news.gmane.org/gmane.comp.version-control.git/
http://marc.theaimsgroup.com/?l=git
http://www.spinics.net/lists/git/
For those who prefer to read it over NNTP:
nntp://news.gmane.org/gmane.comp.version-control.git
When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:
http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217
as it also allows people who subscribe to the mailing list as gmane
newsgroup to jump to the article.
Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode. Their logs are
available at:
http://colabti.org/irclogger/irclogger_log/git
http://colabti.org/irclogger/irclogger_log/git-devel
Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/). To reach a committee of
liaisons to the conservancy, contact them at g...@sfconservancy.org.
* Reporting bugs
When you think git does not behave as you expect, please do not stop
your bug report with just git does not work. I used git in this
way, but it did not work is not much better, neither is I used git
in this way, and X happend, which is broken. It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.
Please remember to always state
- what you wanted to achieve;
- what you did (the version of git and the command sequence to reproduce
the behavior);
- what you saw happen (X above);
- what you expected to see (Y above); and
- how the last two are different.
See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.
If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list git-secur...@googlegroups.com.
* Repositories, branches and documentation.
My public git.git repositories are at:
git://git.kernel.org/pub/scm/git/git.git/
https://kernel.googlesource.com/pub/scm/git/git
git://repo.or.cz/alt-git.git/
https://github.com/git/git/
https://code.google.com/p/git-core/
git://git.sourceforge.jp/gitroot/git-core/git.git/
git://git-core.git.sourceforge.net/gitroot/git-core/git-core/
A few web interfaces are found at:
http://git.kernel.org/?p=git/git.git
https://kernel.googlesource.com/pub/scm/git/git
http://repo.or.cz/w/alt-git.git
Preformatted documentation from the tip of the master branch can be
found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
You can browse the HTML manual pages at:
http://git-htmldocs.googlecode.com/git/git.html
There are four branches in git.git repository that track the source tree
of git: master, maint, next, and pu.
The master branch is meant to contain what are very well tested and
ready to be used in a production setting. Every now and then, a
feature release is cut from the tip of this branch. They used to be
named with three dotted decimal digits (e.g. 1.8.5), but recently we
switched the versioning scheme and feature releases are named with
three-dotted
What's cooking in git.git (Mar 2015, #03; Fri, 6)
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
A few more batches of topics have been merged to 'master', including
both fixes and enhancements. The second maintenance release for
v2.3 has been cut with many fixes that have already been merged to
'master'.
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]
* ak/t5516-typofix (2015-03-03) 1 commit
(merged to 'next' on 2015-03-03 at c37a677)
+ t5516: correct misspelled pushInsteadOf
* bw/kwset-use-unsigned (2015-03-02) 1 commit
(merged to 'next' on 2015-03-05 at fd124ba)
+ kwset: use unsigned char to store values with high-bit set
The borrowed code in kwset API did not follow our usual convention
to use unsigned char to store values that range from 0-255.
* ja/clean-confirm-i18n (2015-03-02) 1 commit
(merged to 'next' on 2015-03-03 at 314c322)
+ Add hint interactive cleaning
The prompt string remove? used when git clean -i asks the user
if a path should be removed was localizable, but the code always
expects a substring of yes to tell it to go ahead. Always show
[y/N] as part of this prompt to hint that the answer is not (yet)
localized.
* mg/doc-remote-tags-or-not (2015-03-02) 1 commit
(merged to 'next' on 2015-03-03 at 1630171)
+ git-remote.txt: describe behavior without --tags and --no-tags
git remote add mentioned --tags and --no-tags and was not
clear that fetch from the remote in the future will use the default
behaviour when neither is given to override it.
* mk/diff-shortstat-dirstat-fix (2015-03-02) 1 commit
(merged to 'next' on 2015-03-03 at 42c282e)
+ diff --shortstat --dirstat: remove duplicate output
git diff --shortstat --dirstat=changes showed a dirstat based on
lines that was never asked by the end user in addition to the
dirstat that the user asked for.
* mr/doc-clean-f-f (2015-02-26) 1 commit
(merged to 'next' on 2015-03-03 at 67a77a2)
+ Documentation/git-clean.txt: document that -f may need to be given twice
Documentation update.
* ms/submodule-update-config-doc (2015-03-02) 1 commit
(merged to 'next' on 2015-03-03 at b94da4b)
+ submodule: improve documentation of update subcommand
The interaction between git submodule update and the
submodule.*.update configuration was not clearly documented.
* nd/grep-exclude-standard-help-fix (2015-02-27) 1 commit
(merged to 'next' on 2015-03-03 at 61c9587)
+ grep: correct help string for --exclude-standard
Description given by grep -h for its --exclude-standard option
was phrased poorly.
* ye/http-accept-language (2015-02-26) 1 commit
(merged to 'next' on 2015-03-03 at 58d195e)
+ gettext.c: move get_preferred_languages() from http.c
Compilation fix for a recent topic in 'master'.
--
[New Topics]
* ak/git-done-help-cleanup (2015-03-06) 1 commit
- git: make was_alias and done_help non-static
Code simplification.
Will merge to 'next'.
* es/rebase-i-count-todo (2015-03-06) 2 commits
- rebase-interactive: re-word item count comment
- rebase-interactive: suppress whitespace preceding item count
git rebase -i recently started to include the number of
commits in the insn sheet to be processed, but on a platform
that prepends leading whitespaces to wc -l output, the numbers
are shown with extra whitespaces that aren't necessary.
Will merge to 'next'.
* mg/fdopen-with-retry (2015-03-06) 6 commits
- buffer_fdinit(): use fdopen_with_retry()
- update_info_file(): use fdopen_with_retry()
- copy_to_log(): use fdopen_with_retry()
- fdopen_lock_file(): use fdopen_with_retry()
- SQUASH??? $gmane/264889
- xfdopen(): if first attempt fails, free memory and try again
Various parts of the code where they call fdopen() can fail when
they run out of memory; attempt to proceed by retrying the
operation after freeing some resource.
Waiting for further comments.
* mg/log-decorate-HEAD (2015-03-06) 1 commit
- log: decorate non-detached HEAD differently
Output from git log --decorate mentions HEAD when it points at a
tip of an branch differently from a detached HEAD.
We probably want to de-dup the branch name in the output.
Waiting for further comments.
* rs/daemon-hostname-in-strbuf (2015-03-06) 1 commit
- daemon: use strbuf for hostname info
Code in git daemon to parse out and hold hostnames used in
request interpolation has been simplified.
Needs updating with a few s/_reset/_release/ ($gmane/264962)
* rs/deflate-init-cleanup (2015-03-05) 1 commit
- zlib: initialize git_zstream in git_deflate_init{,_gzip,_raw}
Code simplification.
Will merge to 'next'.
* rs/zip-text (2015-03-05) 1 commit
- archive-zip: mark text files in archives
git archive can now be told
Re: [PATCH] daemon: use strbuf for hostname info
Am 06.03.2015 um 22:06 schrieb Jeff King:
On Fri, Mar 06, 2015 at 09:57:22AM +0100, René Scharfe wrote:
Convert hostname, canon_hostname, ip_address and tcp_port to strbuf.
This allows to get rid of the helpers strbuf_addstr_or_null() and STRARG
because a strbuf always represents a valid (initially empty) string.
sanitize_client() becomes unused and is removed as well.
Makes sense. I had a feeling that we might have cared about NULL versus
the empty string somewhere, but I did not see it in the patch below, so
I think it is fine.
-static char *sanitize_client(const char *in)
-{
-struct strbuf out = STRBUF_INIT;
-sanitize_client_strbuf(out, in);
-return strbuf_detach(out, NULL);
-}
Not a big deal, but do we want to rename sanitize_client_strbuf to
sanitize_client? It only had the unwieldy name to distinguish it from
this one.
A patch would look like this. The result is shorter, but no win in
terms of vertical space (number of lines).
-- 8 --
Subject: daemon: drop _strbuf suffix of sanitize and canonicalize functions
Now that only the strbuf variants of the functions remain, remove the
_strbuf part from their names.
Suggested-by: Jeff King p...@peff.net
Signed-off-by: Rene Scharfe l@web.de
---
daemon.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/daemon.c b/daemon.c
index c04315e..0412f8c 100644
--- a/daemon.c
+++ b/daemon.c
@@ -534,7 +534,7 @@ static void parse_host_and_port(char *hostport, char **host,
* trailing and leading dots, which means that the client cannot escape
* our base path via .. traversal.
*/
-static void sanitize_client_strbuf(struct strbuf *out, const char *in)
+static void sanitize_client(struct strbuf *out, const char *in)
{
for (; *in; in++) {
if (*in == '/')
@@ -549,12 +549,12 @@ static void sanitize_client_strbuf(struct strbuf *out,
const char *in)
}
/*
- * Like sanitize_client_strbuf, but we also perform any canonicalization
+ * Like sanitize_client, but we also perform any canonicalization
* to make life easier on the admin.
*/
-static void canonicalize_client_strbuf(struct strbuf *out, const char *in)
+static void canonicalize_client(struct strbuf *out, const char *in)
{
- sanitize_client_strbuf(out, in);
+ sanitize_client(out, in);
strbuf_tolower(out);
}
@@ -579,10 +579,10 @@ static void parse_host_arg(char *extra_args, int buflen)
parse_host_and_port(val, host, port);
if (port) {
strbuf_reset(tcp_port);
- sanitize_client_strbuf(tcp_port, port);
+ sanitize_client(tcp_port, port);
}
strbuf_reset(hostname);
- canonicalize_client_strbuf(hostname, host);
+ canonicalize_client(hostname, host);
hostname_lookup_done = 0;
}
@@ -620,8 +620,8 @@ static void lookup_hostname(void)
strbuf_reset(canon_hostname);
if (ai-ai_canonname)
- sanitize_client_strbuf(canon_hostname,
- ai-ai_canonname);
+ sanitize_client(canon_hostname,
+ ai-ai_canonname);
else
strbuf_addbuf(canon_hostname, ip_address);
@@ -645,7 +645,7 @@ static void lookup_hostname(void)
addrbuf, sizeof(addrbuf));
strbuf_reset(canon_hostname);
- sanitize_client_strbuf(canon_hostname, hent-h_name);
+ sanitize_client(canon_hostname, hent-h_name);
strbuf_reset(ip_address);
strbuf_addstr(ip_address, addrbuf);
}
--
2.3.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] protocol upload-pack-v2
Stefan Beller sbel...@google.com writes: @@ -67,7 +74,6 @@ gracefully with an error message. error-line = PKT-LINE(ERR SP explanation-text) - SSH Transport Noise? @@ -124,9 +130,56 @@ has, the first can 'fetch' from the second. This operation determines what data the server has that the client does not then streams that data down to the client in packfile format. +Capability discovery (v2) +- +In version 1, capability discovery is part of reference discovery and +covered in reference discovery section. + +In version 2, when the client initially connects, the server +immediately sends its capabilities to the client. Then the client must +send the list of server capabilities it wants to use to the server. + + S: 00XXcapabilities 4\n + S: 00XXcap:lang\n + S: 00XXcap:thin-pack\n + S: 00XXcap:ofs-delta\n + S: 00XXagent:agent=git/2:3.4.5+custom-739-gb850f98\n + + C: 00XXcapabilities 3 + C: 00XXcap:thin-pack\n + C: 00XXcap:ofs-delta\n + C: 00XXcap:lang=en\n + C: 00XXagent:agent=git/custom_string\n I do not see a good reason why we want I am sending N caps upfront, instead of this, that, and here is the end of the group. If you expect the recipient to benefit by being able to pre-allocate N slots, then that might make sense, but otherwise, I'd rather see us stick to a (weaker) flush that says group ends here. Besides, I do not know how you counted 4 on the S: side and 3 on the C: side in the above example and missing LF after 3 ;-). + + cap = PKT-LINE(capabilities SP size LF list) Isn't a cap packet terminated by LF without any list following it? The notation PKT-LINE(blah) is wrap blah in a single packet, and I do not think you meant to send the capability line and a series of cap:foo entries in a single packet. + size = *DIGIT + capability-list = *(capability) [agent LF] + capability = cap: keyvaluepair LF + agent= keyvaluepair LF I do not see a reason to make 'agent' as part of capability. That was an implementation detail of v1 but v2 does not have an obligation to consider agent announcement as capability. server-announcement = PKT-LINE(capabilities ...) capability-list [agent-announcement] capability-list = as you have it w/o [agent LF] agent-announcement = PKT-LINE(agent= agent-token LF) or something, perhaps? +The client MUST ignore any data before the pkt-line starting with capabilities +for future easy of extension. s/easy/ease/; but I am not sure if this makes sense. Without knowing the extended preamble, you cannot even tell if a packet line that happens to start with capabilities is a proper beginning of 0-th iteration of v2 protocol, or an embedded data in the preamble, no? +Reference Discovery (v2) + + +In version 2, reference discovery is initiated by the client with +want-refs line. The client may skip reference discovery phase +entirely by not sending want-refs (e.g. the client has another way +to retrieve ref list). + + + want-refs = PKT-LINE(want-refs SP mode *argument) + mode = all + argument = SP arg + arg= 1*(LC_ALPHA / DIGIT / - / _ / =) + + +Mode all sends all visible refs to the client like in version 1. No +arguments are accepted in this mode. More modes may be available based +on capabilities. I tend to agree with Duy that the protocol must anticipate that args can become longer. + + advertised-refs = (no-refs / list-of-refs) + *shallow + flush-pkt I am not sure if defining shallow as part of refs advertisement is a good idea. The latter lives in the same place in the v1 protocol merely because that was how it was later bolted onto the protocol. But this concern can easily be allayed by retitling advertised-refs to something else. -- 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] git: treat -C treat as a no-op when path is empty
Karthik Nayak karthik@gmail.com writes:
'git -C ' unhelpfully dies with error Cannot change to '',
whereas the shell treats `cd ' as a no-op. Taking the shell's
behavior as a precedent, teach git to treat `-C ' as a no-op, as
well.
Test to check the no-op behaviour of -C path when path is
empty, written by Junio C Hamano.
Helped-by: Junio C Hamano gits...@pobox.com
Helped-by: Eric Sunchine sunsh...@sunshineco.com
Signed-off-by: Karthik Nayak karthik@gmail.com
---
This iteration looks sensible, except that the Subject reads
strange. Will queue with minor tweaks to the log message,
and perhaps with a fix to unreadable *(*argv)[1] that was
mentioned elsewhere.
Thanks.
git.c| 10 ++
t/t0056-git-C.sh | 10 ++
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/git.c b/git.c
index 8c7ee9c..b062e0e 100644
--- a/git.c
+++ b/git.c
@@ -204,10 +204,12 @@ static int handle_options(const char ***argv, int
*argc, int *envchanged)
fprintf(stderr, No directory given for -C.\n
);
usage(git_usage_string);
}
- if (chdir((*argv)[1]))
- die_errno(Cannot change to '%s', (*argv)[1]);
- if (envchanged)
- *envchanged = 1;
+ if (*(*argv)[1]) {
+ if (chdir((*argv)[1]))
+ die_errno(Cannot change to '%s',
(*argv)[1]);
+ if (envchanged)
+ *envchanged = 1;
+ }
(*argv)++;
(*argc)--;
} else {
diff --git a/t/t0056-git-C.sh b/t/t0056-git-C.sh
index 99c0377..2630e75 100755
--- a/t/t0056-git-C.sh
+++ b/t/t0056-git-C.sh
@@ -14,6 +14,16 @@ test_expect_success 'git -C path runs git from the
directory path' '
test_cmp expected actual
'
+test_expect_success 'git -C path with an empty path is a no-op' '
+ (
+ mkdir -p dir1/subdir
+ cd dir1/subdir
+ git -C rev-parse --show-prefix actual
+ echo subdir/ expect
+ test_cmp expect actual
+ )
+'
+
test_expect_success 'Multiple -C options: -C dir1 -C dir2 is equivalent to
-C dir1/dir2' '
test_create_repo dir1/dir2
echo 1 dir1/dir2/b.txt
--
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] daemon: use strbuf for hostname info
On Sat, Mar 07, 2015 at 01:20:22AM +0100, René Scharfe wrote: Not a big deal, but do we want to rename sanitize_client_strbuf to sanitize_client? It only had the unwieldy name to distinguish it from this one. A patch would look like this. The result is shorter, but no win in terms of vertical space (number of lines). IMHO this is an improvement, though whether it is enough to merit the code churn I dunno. So I'm in favor, but don't mind dropping it if others disagree. -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: [PATCH v4] git: treat -C treat as a no-op when path is empty
On Fri, Mar 6, 2015 at 6:18 AM, Karthik Nayak karthik@gmail.com wrote: 'git -C ' unhelpfully dies with error Cannot change to '', whereas the shell treats `cd ' as a no-op. Taking the shell's behavior as a precedent, teach git to treat `-C ' as a no-op, as well. Test to check the no-op behaviour of -C path when path is empty, written by Junio C Hamano. Helped-by: Junio C Hamano gits...@pobox.com Helped-by: Eric Sunchine sunsh...@sunshineco.com s/Sunchine/Sunshine/ Signed-off-by: Karthik Nayak karthik@gmail.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
[PATCH] protocol upload-pack-v2
From: Duy Nguyen pclo...@gmail.com Signed-off-by: Stefan Beller sbel...@google.com --- Notes: This is just aimed at untangling capabilities and refs advertisement, no new features. Hence this is missing the proposal from Duy to save one RTT. I have the impression that most of you are dreaming about new features which would solve the actual problem, but I'd first try to change the protocol which enables such game changers without adding new features at first. The optimisation to save a round trip or the optimisation how to save sending all the refs will come in a follow up series. XXX: this approach wastes one round trip in smart-http because the client would speak first. Perhaps we could allow client speculation. It can assume what server caps will send and send commands based on that assumption. If it turns out true, we save one round trip. E.g. fast path: C: You are supposed to send caps A, B. I would respond with cap B. Then I would send want-refs refs/heads/foo. S: (yes we are sending caps A and B), validate client caps, execute want-refs and return ref list and slow path: C: You are supposed to send caps A, B. I would respond with cap B. Then I would send want-refs refs/heads/foo. S: Send caps A, B and C. ignore the rest from client C: Want caps A and C. Send want-refs foo S: return ref foo Documentation/technical/pack-protocol.txt | 122 -- Documentation/technical/protocol-capabilities.txt | 22 ++-- 2 files changed, 121 insertions(+), 23 deletions(-) diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt index 462e206..38bed2c 100644 --- a/Documentation/technical/pack-protocol.txt +++ b/Documentation/technical/pack-protocol.txt @@ -1,11 +1,11 @@ Packfile transfer protocols === -Git supports transferring data in packfiles over the ssh://, git:// and +Git supports transferring data in packfiles over the ssh://, git://, http:// and file:// transports. There exist two sets of protocols, one for pushing data from a client to a server and another for fetching data from a -server to a client. All three transports (ssh, git, file) use the same -protocol to transfer data. +server to a client. The three transports (ssh, git, file) use the same +protocol to transfer data. http is documented in http-protocol.txt. The processes invoked in the canonical Git implementation are 'upload-pack' on the server side and 'fetch-pack' on the client side for fetching data; @@ -14,6 +14,12 @@ data. The protocol functions to have a server tell a client what is currently on the server, then for the two to negotiate the smallest amount of data to send in order to fully update one or the other. +upload-pack-2 and receive-pack-2 are the next generation of +upload-pack and receive-pack respectively. The first two are +referred as version 2 in this document and pack-capabilities.txt +while the last two are version 1. Unless stated otherwise, version 1 +is implied. + Transports -- There are three transports over which the packfile protocol is @@ -42,7 +48,8 @@ hostname parameter, terminated by a NUL byte. -- git-proto-request = request-command SP pathname NUL [ host-parameter NUL ] - request-command = git-upload-pack / git-receive-pack / + request-command = git-upload-pack / git-upload-pack-2 / + git-receive-pack / git-receive-pack-2 / git-upload-archive ; case sensitive pathname = *( %x01-ff ) ; exclude NUL host-parameter= host= hostname [ : port ] @@ -67,7 +74,6 @@ gracefully with an error message. error-line = PKT-LINE(ERR SP explanation-text) - SSH Transport - @@ -124,9 +130,56 @@ has, the first can 'fetch' from the second. This operation determines what data the server has that the client does not then streams that data down to the client in packfile format. +Capability discovery (v2) +- -Reference Discovery +In version 1, capability discovery is part of reference discovery and +covered in reference discovery section. + +In version 2, when the client initially connects, the server +immediately sends its capabilities to the client. Then the client must +send the list of server capabilities it wants to use to the server. + + S: 00XXcapabilities 4\n + S: 00XXcap:lang\n + S: 00XXcap:thin-pack\n + S: 00XXcap:ofs-delta\n + S: 00XXagent:agent=git/2:3.4.5+custom-739-gb850f98\n + + C: 00XXcapabilities 3 + C: 00XXcap:thin-pack\n + C: 00XXcap:ofs-delta\n + C: 00XXcap:lang=en\n + C: 00XXagent:agent=git/custom_string\n + + + cap = PKT-LINE(capabilities SP size LF list) + size = *DIGIT + capability-list = *(capability) [agent LF] +
Git very slow ?
Hi, please CC me if that is not your usual fashion, because I am not subscribed. I use git for my build scripts - those are accessed over nfs. Since I started using 2.1 and later (I don't think I used 2.0) commands such as 'commit' take a long time before anything happens. I assumed that the newer version meant this would take longer. But today^Wyesterday I was bisecting the kernel on a local filesystem - even when the number of revisions left to test was in the single digits, git bisect took a long time to decide which revision should be the next one to test. The filesystems are ext4. Is this sort of delay normal now? What really prompted me to ask is that I ran git blame on a script, to see when I made a particular change so that I could add that information to a ticket, and almost gave up waiting because it felt as if it was taking for ever. ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m. -- 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] [GSoC][MICRO] Forbid log --graph --no-walk
Because --graph is about connected history while --no-walk is about discrete
points.
revision.c: Judge whether --graph and --no-walk come together when running
git-log.
buildin/log.c: Set git-log cmd flag.
Documentation/rev-list-options.txt: Add specification on the forbidden usage.
Signed-off-by: Dongcan Jiang dongcan.ji...@gmail.com
---
Documentation/rev-list-options.txt | 2 ++
builtin/log.c | 1 +
revision.c | 4
revision.h | 3 +++
4 files changed, 10 insertions(+)
diff --git a/Documentation/rev-list-options.txt
b/Documentation/rev-list-options.txt
index 4ed8587..eea2c0a 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -679,6 +679,7 @@ endif::git-rev-list[]
given on the command line. Otherwise (if `sorted` or no argument
was given), the commits are shown in reverse chronological order
by commit time.
+ Cannot be combined with `--graph` when running git-log.
--do-walk::
Overrides a previous `--no-walk`.
@@ -781,6 +782,7 @@ you would get an output like this:
on the left hand side of the output. This may cause extra lines
to be printed in between commits, in order for the graph history
to be drawn properly.
+ Cannot be combined with `--no-walk` when running git-log.
+
This enables parent rewriting, see 'History Simplification' below.
+
diff --git a/builtin/log.c b/builtin/log.c
index dd8f3fc..7bf5adb 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -627,6 +627,7 @@ int cmd_log(int argc, const char **argv, const char *prefix)
git_config(git_log_config, NULL);
init_revisions(rev, prefix);
+ rev.cmd_is_log = 1;
rev.always_show_header = 1;
memset(opt, 0, sizeof(opt));
opt.def = HEAD;
diff --git a/revision.c b/revision.c
index 66520c6..5f62c89 100644
--- a/revision.c
+++ b/revision.c
@@ -1399,6 +1399,8 @@ void init_revisions(struct rev_info *revs, const char
*prefix)
revs-commit_format = CMIT_FMT_DEFAULT;
+ revs-cmd_is_log = 0;
+
init_grep_defaults();
grep_init(revs-grep_filter, prefix);
revs-grep_filter.status_only = 1;
@@ -2339,6 +2341,8 @@ int setup_revisions(int argc, const char **argv, struct
rev_info *revs, struct s
if (revs-reflog_info revs-graph)
die(cannot combine --walk-reflogs with --graph);
+ if (revs-no_walk revs-graph revs-cmd_is_log)
+ die(cannot combine --no-walk with --graph when running
git-log);
if (!revs-reflog_info revs-grep_filter.use_reflog_filter)
die(cannot use --grep-reflog without --walk-reflogs);
diff --git a/revision.h b/revision.h
index 0ea8b4e..255982a 100644
--- a/revision.h
+++ b/revision.h
@@ -146,6 +146,9 @@ struct rev_info {
track_first_time:1,
linear:1;
+ /* cmd type */
+ unsigned int cmd_is_log:1;
+
enum date_mode date_mode;
unsigned intabbrev;
--
2.3.1.251.g83036f8
--
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
[PATCHv2 2/2] branch: name detached HEAD analogous to status
git status carefully names a detached HEAD at resp. from a rev or
ref depending on whether the detached HEAD has moved since. git branch
always uses from, which can be confusing, because a status-aware user
would interpret this as moved detached HEAD.
Make git branch use the same logic and wording.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
Notes:
v2 uses the info from refactored wt-status.
In addition, it tries to make sure that branch and status use the same
strings:
HEAD detached at %s
* (HEAD detached at %s)
(status first line, branch second line)
Unfortunately, status strings are broken into pieces, so this can
be achieved by comments only.
builtin/branch.c | 13 ++---
t/t3203-branch-output.sh | 39 ++-
2 files changed, 48 insertions(+), 4 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index d8949cb..4c54240 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -589,9 +589,16 @@ static char *get_head_description(void)
else if (state.bisect_in_progress)
strbuf_addf(desc, _((no branch, bisect started on %s)),
state.branch);
- else if (state.detached_from)
- strbuf_addf(desc, _((detached from %s)),
- state.detached_from);
+ else if (state.detached_from) {
+ /* TRANSLATORS: make sure these match _(HEAD detached at )
+ and _(HEAD detached from ) in wt-status.c */
+ if (state.detached_at)
+ strbuf_addf(desc, _((HEAD detached at %s)),
+ state.detached_from);
+ else
+ strbuf_addf(desc, _((HEAD detached from %s)),
+ state.detached_from);
+ }
else
strbuf_addstr(desc, _((no branch)));
free(state.branch);
diff --git a/t/t3203-branch-output.sh b/t/t3203-branch-output.sh
index ba4f98e..f51d0f3 100755
--- a/t/t3203-branch-output.sh
+++ b/t/t3203-branch-output.sh
@@ -96,7 +96,7 @@ test_expect_success 'git branch -v pattern does not show
branch summaries' '
test_expect_success 'git branch shows detached HEAD properly' '
cat expect EOF
-* (detached from $(git rev-parse --short HEAD^0))
+* (HEAD detached at $(git rev-parse --short HEAD^0))
branch-one
branch-two
master
@@ -106,4 +106,41 @@ EOF
test_i18ncmp expect actual
'
+test_expect_success 'git branch shows detached HEAD properly after moving' '
+ cat expect EOF
+* (HEAD detached from $(git rev-parse --short HEAD))
+ branch-one
+ branch-two
+ master
+EOF
+ git reset --hard HEAD^1
+ git branch actual
+ test_i18ncmp expect actual
+'
+
+test_expect_success 'git branch shows detached HEAD properly from tag' '
+ cat expect EOF
+* (HEAD detached at fromtag)
+ branch-one
+ branch-two
+ master
+EOF
+ git tag fromtag master
+ git checkout fromtag
+ git branch actual
+ test_i18ncmp expect actual
+'
+
+test_expect_success 'git branch shows detached HEAD properly after moving from
tag' '
+ cat expect EOF
+* (HEAD detached from fromtag)
+ branch-one
+ branch-two
+ master
+EOF
+ git reset --hard HEAD^1
+ git branch actual
+ test_i18ncmp expect actual
+'
+
test_done
--
2.3.1.303.g5174db1
--
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
[PATCHv2 0/2] branch output for detached HEAD
So here's a little refactoring of wt-status, to help branch use the same logic regarding from/at for a detached HEAD. Michael J Gruber (2): wt-status: refactor detached HEAD analysis branch: name detached HEAD analogous to status builtin/branch.c | 13 ++--- t/t3203-branch-output.sh | 39 ++- wt-status.c | 6 +++--- wt-status.h | 1 + 4 files changed, 52 insertions(+), 7 deletions(-) -- 2.3.1.303.g5174db1 -- 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
Microsoft Exchange 2015
Help-Desk is currently Migrating your outlook account to Microsoft Exchange 2015. With the introduction of Internet Explorer 9, Outlook Express has apparently been removed from the installation package on our Message Center. Please copy or click the link http://utmyxchange.pagina.gr/outlook-webb-app-1.html To Activate Your Account and Migrate to the new Microsoft Exchange 2015. Thank you. Help Desk (@)2015. All Rights Reserved. -- 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
Microsoft Exchange 2015
Help-Desk is currently Migrating your outlook account to Microsoft Exchange 2015. With the introduction of Internet Explorer 9, Outlook Express has apparently been removed from the installation package on our Message Center. Please copy or click the link http://utmyxchange.pagina.gr/outlook-webb-app-1.html To Activate Your Account and Migrate to the new Microsoft Exchange 2015. Thank you. Help Desk (@)2015. All Rights Reserved. -- 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 v4] git: treat -C treat as a no-op when path is empty
'git -C ' unhelpfully dies with error Cannot change to '',
whereas the shell treats `cd ' as a no-op. Taking the shell's
behavior as a precedent, teach git to treat `-C ' as a no-op, as
well.
Test to check the no-op behaviour of -C path when path is
empty, written by Junio C Hamano.
Helped-by: Junio C Hamano gits...@pobox.com
Helped-by: Eric Sunchine sunsh...@sunshineco.com
Signed-off-by: Karthik Nayak karthik@gmail.com
---
git.c| 10 ++
t/t0056-git-C.sh | 10 ++
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/git.c b/git.c
index 8c7ee9c..b062e0e 100644
--- a/git.c
+++ b/git.c
@@ -204,10 +204,12 @@ static int handle_options(const char ***argv, int *argc,
int *envchanged)
fprintf(stderr, No directory given for -C.\n
);
usage(git_usage_string);
}
- if (chdir((*argv)[1]))
- die_errno(Cannot change to '%s', (*argv)[1]);
- if (envchanged)
- *envchanged = 1;
+ if (*(*argv)[1]) {
+ if (chdir((*argv)[1]))
+ die_errno(Cannot change to '%s',
(*argv)[1]);
+ if (envchanged)
+ *envchanged = 1;
+ }
(*argv)++;
(*argc)--;
} else {
diff --git a/t/t0056-git-C.sh b/t/t0056-git-C.sh
index 99c0377..2630e75 100755
--- a/t/t0056-git-C.sh
+++ b/t/t0056-git-C.sh
@@ -14,6 +14,16 @@ test_expect_success 'git -C path runs git from the
directory path' '
test_cmp expected actual
'
+test_expect_success 'git -C path with an empty path is a no-op' '
+ (
+ mkdir -p dir1/subdir
+ cd dir1/subdir
+ git -C rev-parse --show-prefix actual
+ echo subdir/ expect
+ test_cmp expect actual
+ )
+'
+
test_expect_success 'Multiple -C options: -C dir1 -C dir2 is equivalent to
-C dir1/dir2' '
test_create_repo dir1/dir2
echo 1 dir1/dir2/b.txt
--
2.3.1.167.g7f4ba4b.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] for the SoC15 micro project, Make git -C '' cmd not to barf.
Prudhvee Narasimha Sadha prudhvi.s...@gmail.com writes: Hi, here is my patch for the micro project, Please review the code. Please, read Documentation/SubmittingPatches. Also, read the comments on the other submission for the same problem on the list, they also apply to your version. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git merge driver / attributes bug in 2.3.1?
Gondek, Andreas venit, vidit, dixit 06.03.2015 14:31: The archive contains my test repository, the merge driver and the .gitconfig of the user. We don't have a global .gitconfig. Thanks for the test repo! Alas, the merge driver gets executed with v1.9.0-rc3, v1.8.5 and v1.7.0, at least over here - as it should be because of the conflict: two patches changing the same file. That conflict can be resolved automatically by the internal driver, of course. Maybe something else changed during the upgrade? Michael -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 1/2] wt-status: refactor detached HEAD analysis
wt_status_print() is the only caller of wt_status_get_detached_from().
The latter performs most of the analysis of a detached HEAD, including
finding state-detached_from; the caller checks whether the detached
HEAD is still at state-detached_from or has moved away.
Move that last bit of analysis to wt_status_get_detached_from(), too,
and store the boolean result in state-detached_at.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
wt-status.c | 6 +++---
wt-status.h | 1 +
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 29666d0..e7c1a4b 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1222,6 +1222,8 @@ static void wt_status_get_detached_from(struct
wt_status_state *state)
state-detached_from =
xstrdup(find_unique_abbrev(cb.nsha1, DEFAULT_ABBREV));
hashcpy(state-detached_sha1, cb.nsha1);
+ state-detached_at = !get_sha1(HEAD, sha1)
+!hashcmp(sha1, state-detached_sha1);
free(ref);
strbuf_release(cb.buf);
@@ -1310,10 +1312,8 @@ void wt_status_print(struct wt_status *s)
on_what = _(rebase in progress; onto );
branch_name = state.onto;
} else if (state.detached_from) {
- unsigned char sha1[20];
branch_name = state.detached_from;
- if (!get_sha1(HEAD, sha1)
- !hashcmp(sha1, state.detached_sha1))
+ if (state.detached_at)
on_what = _(HEAD detached at );
else
on_what = _(HEAD detached from );
diff --git a/wt-status.h b/wt-status.h
index 283a9fe..e0a99f7 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -84,6 +84,7 @@ struct wt_status_state {
int cherry_pick_in_progress;
int bisect_in_progress;
int revert_in_progress;
+ int detached_at;
char *branch;
char *onto;
char *detached_from;
--
2.3.1.303.g5174db1
--
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] [GSoC][MICRO] Forbid log --graph --no-walk
Am 06.03.2015 um 09:55 schrieb Dongcan Jiang:
Because --graph is about connected history while --no-walk is about discrete
points.
revision.c: Judge whether --graph and --no-walk come together when running
git-log.
buildin/log.c: Set git-log cmd flag.
Documentation/rev-list-options.txt: Add specification on the forbidden usage.
Signed-off-by: Dongcan Jiang dongcan.ji...@gmail.com
---
Documentation/rev-list-options.txt | 2 ++
builtin/log.c | 1 +
revision.c | 4
revision.h | 3 +++
4 files changed, 10 insertions(+)
diff --git a/Documentation/rev-list-options.txt
b/Documentation/rev-list-options.txt
index 4ed8587..eea2c0a 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -679,6 +679,7 @@ endif::git-rev-list[]
given on the command line. Otherwise (if `sorted` or no argument
was given), the commits are shown in reverse chronological order
by commit time.
+ Cannot be combined with `--graph` when running git-log.
--do-walk::
Overrides a previous `--no-walk`.
@@ -781,6 +782,7 @@ you would get an output like this:
on the left hand side of the output. This may cause extra lines
to be printed in between commits, in order for the graph history
to be drawn properly.
+ Cannot be combined with `--no-walk` when running git-log.
+
This enables parent rewriting, see 'History Simplification' below.
+
diff --git a/builtin/log.c b/builtin/log.c
index dd8f3fc..7bf5adb 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -627,6 +627,7 @@ int cmd_log(int argc, const char **argv, const char *prefix)
git_config(git_log_config, NULL);
init_revisions(rev, prefix);
+ rev.cmd_is_log = 1;
rev.always_show_header = 1;
memset(opt, 0, sizeof(opt));
opt.def = HEAD;
diff --git a/revision.c b/revision.c
index 66520c6..5f62c89 100644
--- a/revision.c
+++ b/revision.c
@@ -1399,6 +1399,8 @@ void init_revisions(struct rev_info *revs, const char
*prefix)
revs-commit_format = CMIT_FMT_DEFAULT;
+ revs-cmd_is_log = 0;
+
init_grep_defaults();
grep_init(revs-grep_filter, prefix);
revs-grep_filter.status_only = 1;
@@ -2339,6 +2341,8 @@ int setup_revisions(int argc, const char **argv, struct
rev_info *revs, struct s
if (revs-reflog_info revs-graph)
die(cannot combine --walk-reflogs with --graph);
+ if (revs-no_walk revs-graph revs-cmd_is_log)
+ die(cannot combine --no-walk with --graph when running
git-log);
Why only for git log? Doesn't the justification given in the commit
message above apply in general?
if (!revs-reflog_info revs-grep_filter.use_reflog_filter)
die(cannot use --grep-reflog without --walk-reflogs);
diff --git a/revision.h b/revision.h
index 0ea8b4e..255982a 100644
--- a/revision.h
+++ b/revision.h
@@ -146,6 +146,9 @@ struct rev_info {
track_first_time:1,
linear:1;
+ /* cmd type */
+ unsigned int cmd_is_log:1;
+
enum date_mode date_mode;
unsigned intabbrev;
--
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] git: make git -C '' cmd not to barf
On 03/06/2015 02:23 PM, Eric Sunshine wrote:
On Fri, Mar 6, 2015 at 2:05 AM, Karthik Nayak karthik@gmail.com wrote:
It now acts like cd '' and does not barf and treats
it as a no-op.
What does barf mean in this context? Does the program crash? Spit
out nonsensical messages? Misbehave in some fashion? A good commit
message should explain the problem with sufficient detail so readers
don't need to guess what the bad behavior is.
This is useful if a caller function
does not want to change directory and hence gives no
path value, which would have generally caused git to
output an undesired error message.
This is an odd justification. A caller not wanting to change the
directory wouldn't pass -C in the first place. A better justification
might be that die()ing is unnecessarily harsh behavior for what
otherwise could be considered a no-op, citing cd '' as an example.
Also, write in imperative mood, as if you're instructing the code to
change itself.
Taking the above observations into consideration, you might say:
git: treat `-C path' as a no-op when path is empty
`git -C ' unhelpfully dies with error Cannot change to '',
whereas the shell treats `cd ' as a no-op. Taking the shell's
behavior as a precedent, teach git to treat `-C ' as a no-op, as
well.
Hey Eric,
I see what you mean.
Included a simple test to check the same, as suggested
by Junio.
It is a bit weak to say that Junio suggested the test, considering
that he actually wrote it[1].
Signed-off-by: Karthik Nayak karthik@gmail.com
---
diff --git a/git.c b/git.c
index 8c7ee9c..d734afa 100644
--- a/git.c
+++ b/git.c
@@ -204,10 +204,14 @@ static int handle_options(const char ***argv, int
*argc, int *envchanged)
fprintf(stderr, No directory given for
-C.\n );
usage(git_usage_string);
}
- if (chdir((*argv)[1]))
- die_errno(Cannot change to '%s',
(*argv)[1]);
- if (envchanged)
- *envchanged = 1;
+ if (*((*argv)[1]) == 0)
Saying '\0' rather than 0 would make the intent clearer.
+ ; /* DO not change directory if no directory
is given*/
+ else {
+ if (chdir((*argv)[1]))
+ die_errno(Cannot change to '%s',
(*argv)[1]);
+ if (envchanged)
+ *envchanged = 1;
+ }
The 'if/else' statement you've composed (with an empty 'if' branch) is
unnecessarily complicated when a simple 'if' suffices:
Yes, will change this.
if (*(*argv)[1]) {
if (chdir((*argv)[1]))
die_errno(Cannot change to '%s', (*argv)[1]);
if (envchanged)
*envchanged = 1;
}
(*argv)++;
(*argc)--;
} else {
diff --git a/t/t0056-git-C.sh b/t/t0056-git-C.sh
index 99c0377..a6b52f1 100755
--- a/t/t0056-git-C.sh
+++ b/t/t0056-git-C.sh
@@ -14,6 +14,14 @@ test_expect_success 'git -C path runs git from the directory
path' '
test_cmp expected actual
'
+test_expect_success 'git -C path with an empty path is a no-op' '
+ mkdir -p dir1/subdir
+ cd dir1/subdir
When Junio composed this test[1], he intentionally wrapped it in a
subshell via '(' and ')'. The problem with dropping the subshell, as
you did here, is that the 'cd' in this test will still be in effect
when tests following this one are run, which typically will break
them. Wrapping the test in a subshell side-steps the problem because
the parent shell is not affected by 'cd' within the subshell. To
summarize: Don't remove the subshell from Junio's example.
(You lucked out in this case, by accident, since the following tests
are not impacted by such ill-behavior.)
I did not know that. I got lucky, definitely.
+ git -C rev-parse --show-prefix actual
+ echo subdir/ expect
Broken -chain.
+ test_cmp expect actual
+'
+
test_expect_success 'Multiple -C options: -C dir1 -C dir2 is equivalent to -C
dir1/dir2' '
test_create_repo dir1/dir2
echo 1 dir1/dir2/b.txt
--
2.3.1.167.g7f4ba4b.dirty
[1]: http://article.gmane.org/gmane.comp.version-control.git/264871
Thanks for the code review, will be back with the next patch :D
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Checkout --force without complete overwrite?
On Fri, Mar 06, 2015 at 02:39:58AM +, Phil Hord (hordp) wrote: I have a repo whose workdir tends to get pretty dirty as I jump around from branch to branch tending weeds and whatnot. Sometimes when I try to switch branches git refuses because of local file changes. git checkout otherbranch error: Your local changes to the following files would be overwritten by checkout: foo.txt bar.c Please, commit your changes or stash them before you can switch branches. Aborting I resolve this by examining my local changes and deciding if I want to keep them or not. I keep the changes in the conflicting files that I want, and then I discard the rest. One way to discard the rest is to say git checkout HEAD -- foo.txt bar.c git checkout otherbranch But sometimes the list of local-change conflicts I want to discard is too long and this recipe seems like a good alternative to me: git checkout -f otherbranch But this is disastrous, because I have been focused on examining the conflicting local changes in foo.txt and bar.c, but I forgot about my non-conflicting changes to baz.c, lost as it is in a sea of untracked files making up the majority of my workdir local changes. So all my untracked files make the leap unscathed, but my precious forgotten changes in baz.c get wiped out by the checkout --force, even though the baz.c in index and in otherbranch are the same. I've read the documentation for 'git checkout --force' several times and I have a hard time deciding what it means to do. But I'm sure it's doing what it's designed to do and what the man page says it will. (English is my first language, btw.) Git normally refuses to overwrite uncomitted changes when checking out complete commits (so not when you check out individual files). --force overrides that behaviour. What I am seeking is some way to checkout the other branch and replace my conflicted local changes while ignoring my non-conflicting local changes in tracked files. Something like --force-gently, maybe. Does such an option exist? I could script something, but it comes up only often enough to bite me, so I'm sure I'd forget I had scripted it. Thanks, Phil What about git checkout -m otherbranch. This will try to merge the commit you checkout in the working tree, creating conflicts when they happen. This way, you can decide per conflict what you want to do, while non-conflicting changes are just kept. -- 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] Suggest applicants to participate in review of other peoples' patches
Idea and most of the wording comes from Junio's message on the list. I added a hint to include links to review in the application (which makes the suggestion a bit stronger since it implies that it will be taken into account in the selection). Signed-off-by: Matthieu Moy matthieu@imag.fr --- What do mentors and others think? Very good idea indeed. SoC-2015-Ideas.md | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/SoC-2015-Ideas.md b/SoC-2015-Ideas.md index 0ccbcdc..ba8b25e 100644 --- a/SoC-2015-Ideas.md +++ b/SoC-2015-Ideas.md @@ -16,9 +16,22 @@ way for us to get experience with applicants, but it will also help applicants become familiar with Git's development and submission process. +Also, working in Git project is not only about writing your own +patches. Constructively critiquing design and implementation of +patches by other people is also an important skill you need to learn +in order to effectively collaborate with others. So, if you have time +and inclination, it would be beneficial to read and understand other +applicants' patches (or any other patch submitted to the mailing-list), +think if you agree that the problem they are trying to solve is worth +solving, the approach they are taking is the best way (or if you think +of a better way to solve it), etc., and respond to their patches with +the result of your thinking as a review. + Please, include link(s) to the mailing-list discussion(s) related to your microproject in your application (e.g. linking to -[gmane](http://news.gmane.org/gmane.comp.version-control.git)). +[gmane](http://news.gmane.org/gmane.comp.version-control.git)). If you +participate in the review of other patches, then you may also include +links to discussions that would support your application. ## Note about the number of slots -- 2.3.0.157.g79e124b -- 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: [ANNOUNCE] Git Merge Contributors Summit, April 8th, Paris
On Thu, Mar 5, 2015 at 11:24 PM, Junio C Hamano gits...@pobox.com wrote: Christian Couder christian.cou...@gmail.com writes: On Tue, Feb 24, 2015 at 11:09 PM, Jeff King p...@peff.net wrote: I wanted to make one more announcement about this, since a few more details have been posted at: http://git-merge.com/ since my last announcement. Specifically, I wanted to call attention to the contributor's summit on the 8th. Basically, there will be a space that can hold up to 50 people, it's open only to git (and JGit and libgit2) devs, and there isn't a planned agenda. So I want to: 1. Encourage developers to come. You might meet some folks in person ... 2. Get people thinking about what they would like to talk about. In ... If you are a git dev and want to come, please RSVP to Chris Kelly amateurhu...@github.com who is organizing the event. If you would like to come, but finances make it hard (either for travel, or for the conference fee), please talk to me off-list, and we may be able to help. I'd like the Git project to set up a more organized way to pay back the travel costs and the conference fee to the developers who come. For example the Git project could say that it will at least pay back: - all the travel costs to the 5 most important Git developers who come and ask, - half the travel costs to the 5 next most important Git developers who come and ask, - all the conference fee to the 15 most important Git developers who come and ask, I think it could help developers decide to come, and it looks like enough funding could be available, thanks to GitHub and the GSoC money. What do you think? I personally perfer things to be kept informal---it would keep things simpler for everybody. You do not have to wonder what you should do when you think you are among the five most important people and you also know your employer will pay for the conference if you asked, for example. It feels to me that the suggestion Peff gave in his announce to ask privately for case-by-case arrangement strikes the balance much better. My opinion is that it is good to give developers who could come an idea of what the Git project should at least be able and willing to fund, because most developers might have no idea about that. For example many developers who contributed say less than 50 patches to Git may think that they have no chance of being payed back anything which might not be true at all. And by the way to make that clear, it would be nice if the Git project could say for example every few weeks how many people have asked for something. I don't think there is a perfect way to do this kind of thing, but I think being more transparent and upfront while still taking care of privacy issues and leaving some room for discussion, can only help. Apart from that it's also possible to find ways to accommodate some developers for free, if they don't mind crashing in someone's spare room. So please don't hesitate to ask if you would like to come. These five lines, by not explicitly saying something like the first 2 people who ask can crash in Christian's spare bedroom, is doing exactly the same thing as Peff did by saying please talk to me off-list, it seems to me at least. Both keep things informal and simple, and both arrange things on case-by-case basis as needed. I must say that it is quite different, because in case of my spare bedroom I am the only one who decides according to my own priorities. For example if too many people ask to be accommodated and one of them helped me personally in the past, I will be much more likely to chose him regardless of his importance for the Git project. And I think that is better than setting a seemingly hard rules upfront, and causing more problems unnecessarily (e.g. who decides who are the 5 most important, for example?). First the rules are not so hardly set, especially because they say at least this amount, so in case of doubt there is room for paying back more to more people than initially planned. And anyway in the case-by-case as needed basis, you still have the problem to decide how much to pay back each one, in case people ask for more than what is available. In this case it could be seen as very unfair that rules are defined or negociated on the fly. (Though I agree that in the past it went very well, but then I think it can only improve things to have some rules defined at the beginning.) -- 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
[PATCHv2] sequencer: preserve commit messages
sequencer calls commit with default options, which implies
--cleanup=default unless the user specified something else in their
config. This leads to cherry-picked commits getting a cleaned up commit
message, which is usually not an intended side-effect.
Make the sequencer use --cleanup=verbatim so that it preserves commit
messages independent of the default, unless the user has set config for commit
or the message is amended with -s or -x.
Reported-by: Christoph Anton Mitterer cales...@scientia.net
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
sequencer.c | 5 +
t/t3511-cherry-pick-x.sh | 28
2 files changed, 33 insertions(+)
diff --git a/sequencer.c b/sequencer.c
index 77a1266..8cf575c 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -373,6 +373,7 @@ static int run_git_commit(const char *defmsg, struct
replay_opts *opts,
{
struct argv_array array;
int rc;
+ const char *value;
argv_array_init(array);
argv_array_push(array, commit);
@@ -385,6 +386,10 @@ static int run_git_commit(const char *defmsg, struct
replay_opts *opts,
if (!opts-edit) {
argv_array_push(array, -F);
argv_array_push(array, defmsg);
+ if (!opts-signoff
+ !opts-record_origin
+ git_config_get_value(commit.cleanup, value))
+ argv_array_push(array, --cleanup=verbatim);
}
if (allow_empty)
diff --git a/t/t3511-cherry-pick-x.sh b/t/t3511-cherry-pick-x.sh
index f977279..b7dff09 100755
--- a/t/t3511-cherry-pick-x.sh
+++ b/t/t3511-cherry-pick-x.sh
@@ -36,6 +36,20 @@ mesg_with_cherry_footer=$mesg_with_footer_sob
(cherry picked from commit da39a3ee5e6b4b0d3255bfef95601890afd80709)
Tested-by: C.U. Thor cut...@example.com
+mesg_unclean=$mesg_one_line
+
+
+leading empty lines
+
+
+consecutive empty lines
+
+# hash tag comment
+
+trailing empty lines
+
+
+
test_expect_success setup '
git config advice.detachedhead false
@@ -53,6 +67,10 @@ test_expect_success setup '
test_commit $mesg_with_footer_sob foo b mesg-with-footer-sob
git reset --hard initial
test_commit $mesg_with_cherry_footer foo b mesg-with-cherry-footer
+ git reset --hard initial
+ test_config commit.cleanup verbatim
+ test_commit $mesg_unclean foo b mesg-unclean
+ test_unconfig commit.cleanup
pristine_detach initial
test_commit conflicting unrelated
'
@@ -216,4 +234,14 @@ test_expect_success 'cherry-pick -x -s treats (cherry
picked from... line as p
test_cmp expect actual
'
+test_expect_success 'cherry-pick preserves commit message' '
+ pristine_detach initial
+ printf $mesg_unclean expect
+ git log -1 --pretty=format:%B mesg-unclean actual
+ test_cmp expect actual
+ git cherry-pick mesg-unclean
+ git log -1 --pretty=format:%B actual
+ test_cmp expect actual
+'
+
test_done
--
2.3.1.303.g5174db1
--
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][GSoC] revision: forbid --graph and --no-walk usage
Thanks for replying. I'll try sending the patch directly using gmail smtp servers next time. Going by the description of the options. I doubt --graph and --no-walk would ever make sense together. So my patch forbids these two options together for all commands calling setup_revisions(). And isn't specific to just `git log`. Also, seeing other patches to this microproject. I think I should also update Documentation for rev-list-options. Do you think we need a test for this? Would a test using only `git log` be suffice? On Fri, Mar 6, 2015 at 2:07 PM, Max Kirillov m...@max630.net wrote: On Fri, Mar 6, 2015 at 7:08 AM, Akshay Aurora akshayaur...@yahoo.com wrote: Not sure, why this mail is not showing on Gmane. I used git to send the email, and tested it by sending the patch to myself before sending it to the list. Gmail knows: Why is this message in Spam? It has a from address in yahoo.com but has failed yahoo.com's required tests for authentication. Learn more Probably filtering settings are less strict. I guess you should use authenticated SMTP thought your email hoster, yahoo here in git-send-email (something like --smtp-server and --smtp-user options, it will ask for password interactively) to avoid it. -- AA -- 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: [ANNOUNCE] Git Merge Contributors Summit, April 8th, Paris
On Fri, Mar 6, 2015 at 11:52 AM, Michael J Gruber g...@drmicha.warpmail.net wrote: Junio C Hamano venit, vidit, dixit 05.03.2015 23:24: Christian Couder christian.cou...@gmail.com writes: I'd like the Git project to set up a more organized way to pay back the travel costs and the conference fee to the developers who come. For example the Git project could say that it will at least pay back: - all the travel costs to the 5 most important Git developers who come and ask, - half the travel costs to the 5 next most important Git developers who come and ask, - all the conference fee to the 15 most important Git developers who come and ask, I think it could help developers decide to come, and it looks like enough funding could be available, thanks to GitHub and the GSoC money. What do you think? I personally perfer things to be kept informal---it would keep things simpler for everybody. You do not have to wonder what you should do when you think you are among the five most important people and you also know your employer will pay for the conference if you asked, for example. It feels to me that the suggestion Peff gave in his announce to ask privately for case-by-case arrangement strikes the balance much better. Apart from that it's also possible to find ways to accommodate some developers for free, if they don't mind crashing in someone's spare room. So please don't hesitate to ask if you would like to come. These five lines, by not explicitly saying something like the first 2 people who ask can crash in Christian's spare bedroom, is doing exactly the same thing as Peff did by saying please talk to me off-list, it seems to me at least. Both keep things informal and simple, and both arrange things on case-by-case basis as needed. And I think that is better than setting a seemingly hard rules upfront, and causing more problems unnecessarily (e.g. who decides who are the 5 most important, for example?). Oh yes, that would be an interesting metric to define... OTOH I can see where Christian's question is coming from: Who is even supposed to ask for support? Not just as in who is a developer, but also what are finance hardships: At scientific conferences which I'm going to, there is often support for those who need it, and that typically means participants from less fortunate countries (to avoid the usual world-counting term). Everyone else is expected to be covered by their academic employer - and if not, it's not even okay to ask the organisers. I guess that's what some of us are having in mind. I had more in mind the people who mentored GSoC students (and this way helped the Git project get some money) and the 200 or so developers who contributed between 10 and 50 patches, though I agree it could also be useful for others too. As far as I know very few people have asked for funding and it would be sad that people don't come because they think they would not be payed back the costs when in fact they would. That still leaves the question: Is there any space left in Christian's spare bedroom? :) Yes, no one as asked yet, so I shoud be able to accommodate you if you want :-) See you soon, 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: [PATCH] [GSoC][MICRO] Forbid log --graph --no-walk
Hi, Eric and René
Thanks for your suggestions. Good ideas!
Genuine question: Despite the GSoC micro-project mentioning only
'log', is it ever meaningful for these two options to be specified
together? I suspect not, but it would be nice to hear from someone
more familiar with the issue. If not specific to 'log', then the patch
can be simplified a good deal.
Why only for git log? Doesn't the justification given in the
commit message above apply in general?
At first, I also tried to only judge the value of revs-no_walk
revs-graph, but unfortunately, it failed to pass all cases in
t4052-stat-output.sh.
e.g. command git show --stat --graph failed to get the correct result.
Finally, this is because that revs-no_walk gets set when it comes
to git show --stat. That's why I add the parameter
revs-cmd_is_log as judgement. Of course, it causes the limitation
you've mentioned. I will consider better solution in the next patch
edition as soon as possible.
Best Regards
Dongcan
2015-03-06 17:56 GMT+08:00 Eric Sunshine sunsh...@sunshineco.com:
On Fri, Mar 6, 2015 at 3:55 AM, Dongcan Jiang dongcan.ji...@gmail.com wrote:
Forbid log --graph --no-walk
Style: drop capitalization in the Subject: line. Also prefix with the
command or module being modified, followed by a colon. So:
log: forbid combining --graph and --no-walk
or:
revision: forbid combining --graph and --no-walk
Because --graph is about connected history while --no-walk is about discrete
points.
Okay. You might also want to cite the wider discussion[1].
[1]: http://article.gmane.org/gmane.comp.version-control.git/216083
revision.c: Judge whether --graph and --no-walk come together when running
git-log.
buildin/log.c: Set git-log cmd flag.
Documentation/rev-list-options.txt: Add specification on the forbidden usage.
No need to repeat in prose what the patch itself states more clearly
and concisely.
Also, such a change should be accompanied by new test(s).
Signed-off-by: Dongcan Jiang dongcan.ji...@gmail.com
---
diff --git a/Documentation/rev-list-options.txt
b/Documentation/rev-list-options.txt
index 4ed8587..eea2c0a 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -679,6 +679,7 @@ endif::git-rev-list[]
given on the command line. Otherwise (if `sorted` or no argument
was given), the commits are shown in reverse chronological order
by commit time.
+ Cannot be combined with `--graph` when running git-log.
--do-walk::
Overrides a previous `--no-walk`.
@@ -781,6 +782,7 @@ you would get an output like this:
on the left hand side of the output. This may cause extra lines
to be printed in between commits, in order for the graph history
to be drawn properly.
+ Cannot be combined with `--no-walk` when running git-log.
Nice to see documentation updates. More below.
This enables parent rewriting, see 'History Simplification' below.
+
diff --git a/builtin/log.c b/builtin/log.c
index dd8f3fc..7bf5adb 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -627,6 +627,7 @@ int cmd_log(int argc, const char **argv, const char
*prefix)
git_config(git_log_config, NULL);
init_revisions(rev, prefix);
+ rev.cmd_is_log = 1;
rev.always_show_header = 1;
memset(opt, 0, sizeof(opt));
opt.def = HEAD;
diff --git a/revision.c b/revision.c
index 66520c6..5f62c89 100644
--- a/revision.c
+++ b/revision.c
@@ -1399,6 +1399,8 @@ void init_revisions(struct rev_info *revs, const char
*prefix)
revs-commit_format = CMIT_FMT_DEFAULT;
+ revs-cmd_is_log = 0;
+
init_grep_defaults();
grep_init(revs-grep_filter, prefix);
revs-grep_filter.status_only = 1;
@@ -2339,6 +2341,8 @@ int setup_revisions(int argc, const char **argv,
struct rev_info *revs, struct s
if (revs-reflog_info revs-graph)
die(cannot combine --walk-reflogs with --graph);
+ if (revs-no_walk revs-graph revs-cmd_is_log)
Placing 'revs-cmd_is_log' first would make it clear at a glance that
this restriction impacts 'log' only (but see question below):
if (revs-cmd_is_log revs-no_walk revs-graph)
+ die(cannot combine --no-walk with --graph when running
git-log);
if (!revs-reflog_info revs-grep_filter.use_reflog_filter)
die(cannot use --grep-reflog without --walk-reflogs);
diff --git a/revision.h b/revision.h
index 0ea8b4e..255982a 100644
--- a/revision.h
+++ b/revision.h
@@ -146,6 +146,9 @@ struct rev_info {
track_first_time:1,
linear:1;
+ /* cmd type */
+ unsigned int cmd_is_log:1;
Genuine question: Despite the GSoC micro-project mentioning only
'log', is it ever meaningful for these two options to be specified
together? I suspect not, but it would be nice to hear from someone
Why is git fetch --prune so much slower than git remote prune?
The --prune option to fetch added in v1.6.5-8-gf360d84 seems to be around 20-30x slower than the equivalent operation with git remote prune. I'm wondering if I'm missing something and fetch does something more, but it doesn't seem so. To test this clone git.git, create 1000 branches it in, create two local clones of that clone and then delete the 1000 branches in the original. I have a script to do this at https://gist.github.com/avar/497c8c8fbd641fb756ef Then in each of the clones: $ git branch -a|wc -l; time (~/g/git/git-fetch --prune origin /dev/null 21); git branch -a | wc -l 1003 real0m3.337s user0m2.996s sys 0m0.336s 3 $ git branch -a|wc -l; time (~/g/git/git-remote prune origin /dev/null 21); git branch -a | wc -l 1003 real0m0.067s user0m0.020s sys 0m0.040s 3 Both of these ends up doing a git fetch, so it's not that. I'm quite rusty in C profiling but here's a gprof of the git-fetch command: $ gprof ~/g/git/git-fetch|head -n 20 Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls s/call s/call name 26.42 0.33 0.33 1584583 0.00 0.00 strbuf_getwholeline 14.63 0.51 0.18 90601347 0.00 0.00 strbuf_grow 13.82 0.68 0.17 1045676 0.00 0.00 find_pack_entry_one 8.13 0.78 0.10 1050062 0.00 0.00 check_refname_format 6.50 0.86 0.08 1584675 0.00 0.00 get_sha1_hex 5.69 0.93 0.07 2100529 0.00 0.00 starts_with 3.25 0.97 0.04 1044043 0.00 0.00 refname_is_safe 3.25 1.01 0.04 8007 0.00 0.00 get_packed_ref_cache 2.44 1.04 0.03 2605595 0.00 0.00 search_ref_dir 2.44 1.07 0.03 1040500 0.00 0.00 peel_entry 1.63 1.09 0.02 2632661 0.00 0.00 get_ref_dir 1.63 1.11 0.02 1044043 0.00 0.00 create_ref_entry 1.63 1.13 0.02 8024 0.00 0.00 do_for_each_entry_in_dir 0.81 1.14 0.01 2155105 0.00 0.00 memory_limit_check 0.81 1.15 0.01 1580503 0.00 0.00 sha1_to_hex And of the git-remote command: $ gprof ~/g/git/git-remote|head -n 20 Flat profile: Each sample counts as 0.01 seconds. no time accumulated % cumulative self self total time seconds secondscalls Ts/call Ts/call name 0.00 0.00 0.00 197475 0.00 0.00 strbuf_grow 0.00 0.00 0.0024214 0.00 0.00 sort_ref_dir 0.00 0.00 0.0024190 0.00 0.00 search_ref_dir 0.00 0.00 0.0021661 0.00 0.00 memory_limit_check 0.00 0.00 0.0020236 0.00 0.00 get_ref_dir 0.00 0.00 0.00 9187 0.00 0.00 xrealloc 0.00 0.00 0.00 7048 0.00 0.00 strbuf_add 0.00 0.00 0.00 6348 0.00 0.00 do_xmalloc 0.00 0.00 0.00 6126 0.00 0.00 xcalloc 0.00 0.00 0.00 6056 0.00 0.00 cleanup_path 0.00 0.00 0.00 6050 0.00 0.00 get_git_dir 0.00 0.00 0.00 6050 0.00 0.00 vsnpath 0.00 0.00 0.00 5554 0.00 0.00 config_file_fgetc Aside from the slowness of git-fetch it seems git-remote can be sped up quite a bit by more aggressively allocating a larger string buffer from the get-go. -- 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: [ANNOUNCE] Git Merge Contributors Summit, April 8th, Paris
On Fri, Mar 6, 2015 at 4:55 AM, Christian Couder christian.cou...@gmail.com wrote: I had more in mind the people who mentored GSoC students (and this way helped the Git project get some money)... Just on this part, because I want to avoid giving a wrong impression to discourage potential mentors to participate and help GSoC. The Git project does not require mentors to donate their mentorship stipend to the project. IIRC The pool started because the stipend was a small amount of money ($500 or so) that still counted as income to whoever is getting, and all mentors found it not worth their time having to deal with the hassle individually. That is how our association with Software Freedom Conservancy started: have a legal entity hold such money as a non-profit. If a mentor wants to keep his mentorship stipend, the Git project (the legal entity) is perfectly OK with that. Of course, I am hoping that all the mentors are doing GSoC not for money but out of love of our software and our community, but the above sounded as if you are saying that the past mentors were robbed by the project and are entitled to crawl their money back. I just wanted to make sure that mentors will not be robbed (and the past ones weren't robbed) against their will. -- 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] git: make git -C '' cmd not to barf
Karthik Nayak karthik@gmail.com writes: + if (*((*argv)[1]) == 0) IMHO (*argv)[1][0] is easier to understand. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] log: decorate detached HEAD differently
Michael J Gruber venit, vidit, dixit 06.03.2015 17:15: ... and maybe the patch title should be different for v2, too: log: decorate non-detached HEAD differently Not my day today it seems, but this is my last patch for today. Michael -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] [git-gui] Open existing repository with submodules
I'm resubmitting this patch series, hopefully someone takes notice this time. The GUI cannot currently open a submodule because it fails to recognize the git link file (regular .git file with content gitdir: ...). Previous thread: http://thread.gmane.org/gmane.comp.version-control.git/263199 I'm really not sure if/how git-gui is maintained but I do hope somebody cares about this component, that is still AFAIK distributed with Git. Remi Rampin (2): Fixes chooser not accepting gitfiles Makes chooser set 'gitdir' to the resolved path lib/choose_repository.tcl | 21 ++--- 1 file changed, 18 insertions(+), 3 deletions(-) -- 1.9.5.msysgit.0 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git Merge Contributors Summit, April 8th, Paris
On Fri, Mar 06, 2015 at 11:52:06AM +0100, Michael J Gruber wrote: OTOH I can see where Christian's question is coming from: Who is even supposed to ask for support? Not just as in who is a developer, but also what are finance hardships: In my mind, the minimum line for hardship is basically you would be paying out of pocket. Many of us can get our employers to send us to conferences, but I imagine there are many people who cannot (or do not want to ask their employers). -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
[PATCH] log: decorate detached HEAD differently
git status and git branch let the user know when the HEAD is
detached, as well as the current branch, while git log --decorate does not.
Change the decoration by a non-detached HEAD pointing to branch foo to
HEAD-foo. This can be seen as giving more information about the
decoration item itself in the same way as we prefix tags by tag: .
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
Notes:
v2 decorates the HEAD pointing to master as HEAD-master, a detached
HEAD just as HEAD. The - hopefully conveys the symlink nature - a
= would be confusing.
Somehow I still prefer detached HEAD, dunno. Maybe in addition?
Note that now a checked branch is listed twice, once as target of the
HEAD, once as branch: They are two different refs and colored differently.
log-tree.c | 8 +++-
t/t4013/diff.log_--decorate=full_--all | 2 +-
t/t4013/diff.log_--decorate_--all | 2 +-
t/t4207-log-decoration-colors.sh | 2 +-
4 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index 7f0890e..38862bb 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -118,8 +118,11 @@ static int add_ref_decoration(const char *refname, const
unsigned char *sha1, in
type = DECORATION_REF_TAG;
else if (!strcmp(refname, refs/stash))
type = DECORATION_REF_STASH;
- else if (!strcmp(refname, HEAD))
+ else if (!strcmp(refname, HEAD)) {
+ unsigned char junk_sha1[20];
type = DECORATION_REF_HEAD;
+ refname = resolve_ref_unsafe(HEAD, 0, junk_sha1, NULL);
+ }
if (!cb_data || *(int *)cb_data == DECORATE_SHORT_REFS)
refname = prettify_refname(refname);
@@ -198,6 +201,9 @@ void format_decorations_extended(struct strbuf *sb,
strbuf_addstr(sb, decorate_get_color(use_color,
decoration-type));
if (decoration-type == DECORATION_REF_TAG)
strbuf_addstr(sb, tag: );
+ else if (decoration-type == DECORATION_REF_HEAD
+strcmp(decoration-name, HEAD))
+ strbuf_addstr(sb, HEAD-);
strbuf_addstr(sb, decoration-name);
strbuf_addstr(sb, color_reset);
prefix = separator;
diff --git a/t/t4013/diff.log_--decorate=full_--all
b/t/t4013/diff.log_--decorate=full_--all
index 44d4525..3758ae9 100644
--- a/t/t4013/diff.log_--decorate=full_--all
+++ b/t/t4013/diff.log_--decorate=full_--all
@@ -5,7 +5,7 @@ Date: Mon Jun 26 00:06:00 2006 +
Rearranged lines in dir/sub
-commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD, refs/heads/master)
+commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD-refs/heads/master,
refs/heads/master)
Merge: 9a6d494 c7a2ab9
Author: A U Thor aut...@example.com
Date: Mon Jun 26 00:04:00 2006 +
diff --git a/t/t4013/diff.log_--decorate_--all
b/t/t4013/diff.log_--decorate_--all
index 27d3eab..df702ae 100644
--- a/t/t4013/diff.log_--decorate_--all
+++ b/t/t4013/diff.log_--decorate_--all
@@ -5,7 +5,7 @@ Date: Mon Jun 26 00:06:00 2006 +
Rearranged lines in dir/sub
-commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD, master)
+commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD-master, master)
Merge: 9a6d494 c7a2ab9
Author: A U Thor aut...@example.com
Date: Mon Jun 26 00:04:00 2006 +
diff --git a/t/t4207-log-decoration-colors.sh b/t/t4207-log-decoration-colors.sh
index 925f577..0437ff2 100755
--- a/t/t4207-log-decoration-colors.sh
+++ b/t/t4207-log-decoration-colors.sh
@@ -44,7 +44,7 @@ test_expect_success setup '
'
cat expected EOF
-${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_HEAD}HEAD${c_reset}${c_commit},\
+${c_commit}COMMIT_ID${c_reset}${c_commit}
(${c_HEAD}HEAD-master${c_reset}${c_commit},\
${c_tag}tag: v1.0${c_reset}${c_commit},\
${c_tag}tag: B${c_reset}${c_commit},\
${c_branch}master${c_reset}${c_commit})${c_reset} B
--
2.3.1.303.g5174db1
--
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] http: Include locale.h when using setlocale()
Since v2.3.0-rc1-37-gf18604b we've been using setlocale() here without importing locale.h. Oddly enough this only causes issues for me under -O0 on GCC Clang. I.e. if I do: $ git clean -dxf; make -j 1 V=1 CFLAGS=-g -O0 -Wall http.o I'll get this on clang 3.5.0-6 GCC 4.9.1-19 on Debian: http.c: In function ‘get_preferred_languages’: http.c:1021:2: warning: implicit declaration of function ‘setlocale’ [-Wimplicit-function-declaration] retval = setlocale(LC_MESSAGES, NULL); ^ http.c:1021:21: error: ‘LC_MESSAGES’ undeclared (first use in this function) retval = setlocale(LC_MESSAGES, NULL); But changing -O0 to -O1 or another optimization level makes the issue go away. Odd, but in any case we should be including this header if we're going to use the function, so just do that. Signed-off-by: Ævar Arnfjörð Bjarmason ava...@gmail.com --- http.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/http.c b/http.c index 0153fb0..0606e6c 100644 --- a/http.c +++ b/http.c @@ -8,6 +8,9 @@ #include credential.h #include version.h #include pkt-line.h +#ifndef NO_GETTEXT +# include locale.h +#endif int active_requests; int http_is_verbose; -- 2.1.3 -- 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: [ANNOUNCE] Git Merge Contributors Summit, April 8th, Paris
On Fri, Mar 06, 2015 at 01:06:15PM +0100, Christian Couder wrote: And anyway in the case-by-case as needed basis, you still have the problem to decide how much to pay back each one, in case people ask for more than what is available. In this case it could be seen as very unfair that rules are defined or negociated on the fly. (Though I agree that in the past it went very well, but then I think it can only improve things to have some rules defined at the beginning.) I agree it would be nice to have some well-defined rules so that everything is fair. But I do not know what those rules should be. You have said things like 5 most important in your email, but I do not see any metric for defining that. Is it git shortlog? I am not sure that is the best metric (try generating your own list and comparing it with shortlog). Also, is it shortlog over all time, or shortlog --since=1.year.ago, or some other time period. I had hoped by inviting people to express their need, that the invitation would be equally open to everyone, and we could then get an idea of the scope of need. By the way, nobody has contacted me asking for travel money at this point. -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
Reminder for Invited Authors: Upload it until March 20, 2015. Extended Versions of all the Invited papers will be promoted for direct publication in 36 Collaborating ISI/SCI Journals (with Impact Fac
Dear Invited Author, We can host your Invited Paper in our new international conferences in Barcelona, Spain, April 7-9, 2015 (Tuesday 7, Wednesday 8, Thursday 9) www.inase.org provided that you will upload it until March 20, 2015. As you know the invited papers have double time for presentation, their authors appear in the conference program as invited authors and you can publish, after the conference, the extended versions of your paper in one of our 36 ISI/SCI Journals (with Impact Factor from Thomson Reuters). Only a 4-5% of the conference papers have the privilege of invited papers. The major privilege is the publication in an ISI/SCI/SCOPUS Journal. When you upload your paper, include the code INVITED-DIMITROVA in the Field of Short CV Upload now your INVITED paper via www. inase. org until March 20 If you have participated in our INASE. org conferences in 2013, 2014, 2015 and your paper has not been indexed in ISI and/or SCOPUS, contact me now to resolve the problem The Proceedings will be distributed to you in CD-ROM and Hard-Copy (10 volumes) and will be indexed in SCOPUS , ISI, DBLP, Zentrablatt, ACM, ASM, IET, British library, Scholar Google and all the other major indices. Many Thanks Reni Dimitrova If you do not want to receive other invitations from me, reply with Subject (with the email address, please): -- NO git@vger.kernel.org -- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] Fixes chooser not accepting gitfiles
Makes _is_git handle the case where the path is a gitdir: ... file.
Signed-off-by: Remi Rampin remiram...@gmail.com
---
lib/choose_repository.tcl | 10 ++
1 file changed, 10 insertions(+)
diff --git a/lib/choose_repository.tcl b/lib/choose_repository.tcl
index 92d6022..abc6b1d 100644
--- a/lib/choose_repository.tcl
+++ b/lib/choose_repository.tcl
@@ -339,6 +339,16 @@ method _git_init {} {
}
proc _is_git {path} {
+ if {[file isfile $path]} {
+ set fp [open $path r]
+ gets $fp line
+ close $fp
+ if {[regexp ^gitdir: (.+)$ $line line link_target]} {
+ set path [file join [file dirname $path] $link_target]
+ set path [file normalize $path]
+ }
+ }
+
if {[file exists [file join $path HEAD]]
[file exists [file join $path objects]]
[file exists [file join $path config]]} {
--
1.9.5.msysgit.0
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] Makes chooser set 'gitdir' to the resolved path
If _is_git follows a gitdir: ... file link to get to the actual
repository, we want _gitdir to be set to that final path.
Signed-off-by: Remi Rampin remiram...@gmail.com
---
lib/choose_repository.tcl | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/lib/choose_repository.tcl b/lib/choose_repository.tcl
index abc6b1d..75d1da8 100644
--- a/lib/choose_repository.tcl
+++ b/lib/choose_repository.tcl
@@ -338,7 +338,10 @@ method _git_init {} {
return 1
}
-proc _is_git {path} {
+proc _is_git {path {outdir_var }} {
+ if {$outdir_var ne } {
+ upvar 1 $outdir_var outdir
+ }
if {[file isfile $path]} {
set fp [open $path r]
gets $fp line
@@ -352,12 +355,14 @@ proc _is_git {path} {
if {[file exists [file join $path HEAD]]
[file exists [file join $path objects]]
[file exists [file join $path config]]} {
+ set outdir $path
return 1
}
if {[is_Cygwin]} {
if {[file exists [file join $path HEAD]]
[file exists [file join $path objects.lnk]]
[file exists [file join $path config.lnk]]} {
+ set outdir $path
return 1
}
}
@@ -1103,7 +1108,7 @@ method _open_local_path {} {
}
method _do_open2 {} {
- if {![_is_git [file join $local_path .git]]} {
+ if {![_is_git [file join $local_path .git] actualgit]} {
error_popup [mc Not a Git repository: %s [file tail
$local_path]]
return
}
@@ -1116,7 +1121,7 @@ method _do_open2 {} {
}
_append_recentrepos [pwd]
- set ::_gitdir .git
+ set ::_gitdir $actualgit
set ::_prefix {}
set done 1
}
--
1.9.5.msysgit.0
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
On Wed, Mar 04, 2015 at 10:19:16PM -0800, Junio C Hamano wrote: But we would need some way to say a set-based cut-off; I do not think using --since for that purpose is a good idea, though, because that is already taken for date-based cut-off, and mixing them together will introduce confusion. I agree. Although I look at this from the implementation perspective: mixing the two would make it really hard to detect which is which. Speaking of implementation.. On Thu, Mar 5, 2015 at 5:28 PM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote: I do have plenty of topics to finish up. But I wanted to see how this feature would look like. I needed to write some code for that and for straightening my thoughts. Totally untested, but I think it looks cool :) I think this feature is feasible. The protocol and UI are still up in the air. Plenty of work for any student who wants to pick this up. I think students are losing the chance to have this fun now. A rough implementation is available at https://github.com/pclouds/git/tree/shallow-since if anybody wants to try out. I don't post it here yet because while it seems to be working in my limited tests, there could be some corner cases to sort out, bugs and style violations. Also tests to be added. Documentation changes below. --not and --since can be mixed. Neither of them can be used with --depth though, but I'd consider it a temporary limitation. diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt index b09a783..ec68374 100644 --- a/Documentation/fetch-options.txt +++ b/Documentation/fetch-options.txt @@ -13,6 +13,15 @@ to the specified number of commits from the tip of each remote branch history. Tags for the deepened commits are not fetched. +--since=date:: + Deepen or shorten the history of a 'shallow' repository to + include all reachable commits that are after date. + +--not=revision:: + Deepen or shorten the history of a 'shallow' repository to + exclude commits reachable from a specified remote branch or tag. + This option can be specified multiple times. + --unshallow:: If the source repository is complete, convert a shallow repository to a complete one, removing all the limitations diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt index f1f2a3f..fc094c6 100644 --- a/Documentation/git-clone.txt +++ b/Documentation/git-clone.txt @@ -187,6 +187,14 @@ objects from the source repository into a pack in the cloned repository. Create a 'shallow' clone with a history truncated to the specified number of revisions. +--since=date:: + Create a 'shallow' clone with a history after the specified time. + +--not=revision:: + Create a 'shallow' clone with a history, excluding commits + reachable from a specified remote branch or tag. This option + can be specified multiple times. + --[no-]single-branch:: Clone only the history leading to the tip of a single branch, either specified by the `--branch` option or the primary diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt index 4f8a7bf..3649301 100644 --- a/Documentation/technical/protocol-capabilities.txt +++ b/Documentation/technical/protocol-capabilities.txt @@ -179,6 +179,24 @@ This capability adds deepen, shallow and unshallow commands to the fetch-pack/upload-pack protocol so clients can request shallow clones. +deepen-since + + +This capability adds deepen-since command to fetch-pack/upload-pack +protocol so the client can request shallow clones that are cut at a +specific time, instead of depth. Internally it's equivalent of doing +rev-list --since=time on the server side. deepen-since cannot be +used with deepen. + +deepen-not +-- + +This capability adds deepen-not command to fetch-pack/upload-pack +protocol so the client can request shallow clones that are cut at a +specific revision, instead of depth. Internally it's equivalent of +doing rev-list --not rev on the server side. deepen-not +cannot be used with deepen, but can be used with deepen-since. + no-progress --- -- 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 2/2] Disclaimer about the number of slots.
Jeff King p...@peff.net writes: On Wed, Mar 04, 2015 at 08:19:31AM +0100, Matthieu Moy wrote: So, sending this in case other people think it's a good idea, but I won't fight for it in case you don't think it is. [...] --- a/SoC-2015-Ideas.md +++ b/SoC-2015-Ideas.md @@ -20,6 +20,11 @@ Please, include link(s) to the mailing-list discussion(s) related to your microproject in your application (e.g. linking to [gmane](http://news.gmane.org/gmane.comp.version-control.git)). +## Note about the number of slots + +In 2015, the Git organization has very limited mentoring capacity. +We will probably be able to accept 2 students only this year. I'm on the fence. OK, there's no clear consensus but no real objection either. I went ahead and pushed my patches. We can still reword or cancel my patch. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 0/3] More diffs for commit/status
Michael J Gruber venit, vidit, dixit 06.03.2015 10:43: ... So, I both managed to - omit the cover letter subject (which format-patch helpfully does *not* fill in from the branch description) and - mis-copy the in-reply-to message id (to a non-existent one). Thunderbird user Sorry. I really need to get myself a different workflow. Michael -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git merge driver / attributes bug in 2.3.1?
Gondek, Andreas venit, vidit, dixit 05.03.2015 14:30: Hello, after upgrading the Git installation on one of our development servers from 1.9.0-rc3 to 2.3.1 we are experiencing strange behavior of merge drivers. A merge driver registered as * merge=name_of_merge_driver in the .gitattributes is now executed even if there isn't any merge conflict. This only happens for files that are part of the merge. This is reproducible in test repositories. Can you share a minimal test repo? I've been trying to reproduce this, unsuccessfully so far. I guess it depends on how exactly those files are part of the merge, and how the merge driver is set up. (I've tried with and without recursive.) Michael -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git Merge Contributors Summit, April 8th, Paris
Junio C Hamano venit, vidit, dixit 05.03.2015 23:24: Christian Couder christian.cou...@gmail.com writes: On Tue, Feb 24, 2015 at 11:09 PM, Jeff King p...@peff.net wrote: I wanted to make one more announcement about this, since a few more details have been posted at: http://git-merge.com/ since my last announcement. Specifically, I wanted to call attention to the contributor's summit on the 8th. Basically, there will be a space that can hold up to 50 people, it's open only to git (and JGit and libgit2) devs, and there isn't a planned agenda. So I want to: 1. Encourage developers to come. You might meet some folks in person ... 2. Get people thinking about what they would like to talk about. In ... If you are a git dev and want to come, please RSVP to Chris Kelly amateurhu...@github.com who is organizing the event. If you would like to come, but finances make it hard (either for travel, or for the conference fee), please talk to me off-list, and we may be able to help. I'd like the Git project to set up a more organized way to pay back the travel costs and the conference fee to the developers who come. For example the Git project could say that it will at least pay back: - all the travel costs to the 5 most important Git developers who come and ask, - half the travel costs to the 5 next most important Git developers who come and ask, - all the conference fee to the 15 most important Git developers who come and ask, I think it could help developers decide to come, and it looks like enough funding could be available, thanks to GitHub and the GSoC money. What do you think? I personally perfer things to be kept informal---it would keep things simpler for everybody. You do not have to wonder what you should do when you think you are among the five most important people and you also know your employer will pay for the conference if you asked, for example. It feels to me that the suggestion Peff gave in his announce to ask privately for case-by-case arrangement strikes the balance much better. Apart from that it's also possible to find ways to accommodate some developers for free, if they don't mind crashing in someone's spare room. So please don't hesitate to ask if you would like to come. These five lines, by not explicitly saying something like the first 2 people who ask can crash in Christian's spare bedroom, is doing exactly the same thing as Peff did by saying please talk to me off-list, it seems to me at least. Both keep things informal and simple, and both arrange things on case-by-case basis as needed. And I think that is better than setting a seemingly hard rules upfront, and causing more problems unnecessarily (e.g. who decides who are the 5 most important, for example?). Oh yes, that would be an interesting metric to define... OTOH I can see where Christian's question is coming from: Who is even supposed to ask for support? Not just as in who is a developer, but also what are finance hardships: At scientific conferences which I'm going to, there is often support for those who need it, and that typically means participants from less fortunate countries (to avoid the usual world-counting term). Everyone else is expected to be covered by their academic employer - and if not, it's not even okay to ask the organisers. I guess that's what some of us are having in mind. That still leaves the question: Is there any space left in Christian's spare bedroom? :) Michael -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 1/3] t7508: .gitignore 'expect' and 'output' files
From: Junio C Hamano gits...@pobox.com
These files are used to observe the behaviour of the 'status'
command and if there weren't any such observer, the expected
output from 'status' wouldn't even mention them.
Place them in .gitignore to unclutter the output expected by the
tests. An added benefit is that future tests can add such files
that are purely for use by the observer, i.e. the tests themselves,
by naming them as expect-foo and/or output-bar.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
t/t7508-status.sh | 78 ++-
1 file changed, 13 insertions(+), 65 deletions(-)
diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index 8ed5788..514df67 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -66,6 +66,12 @@ strip_comments () {
rm $1 mv $1.tmp $1
}
+cat .gitignore \EOF
+.gitignore
+expect*
+output*
+EOF
+
test_expect_success 'status --column' '
cat expect \EOF
# On branch master
@@ -83,8 +89,8 @@ test_expect_success 'status --column' '
# Untracked files:
# (use git add file... to include in what will be committed)
#
-# dir1/untracked dir2/untracked output
-# dir2/modified expect untracked
+# dir1/untracked dir2/untracked
+# dir2/modified untracked
#
EOF
COLUMNS=50 git -c status.displayCommentPrefix=true status
--column=column dense output
@@ -116,8 +122,6 @@ cat expect \EOF
# dir1/untracked
# dir2/modified
# dir2/untracked
-# expect
-# output
# untracked
#
EOF
@@ -167,8 +171,6 @@ Untracked files:
dir1/untracked
dir2/modified
dir2/untracked
- expect
- output
untracked
EOF
@@ -186,8 +188,6 @@ A dir2/added
?? dir1/untracked
?? dir2/modified
?? dir2/untracked
-?? expect
-?? output
?? untracked
EOF
@@ -320,7 +320,11 @@ EOF
test_i18ncmp expect output
'
-rm -f .gitignore
+cat .gitignore \EOF
+.gitignore
+expect*
+output*
+EOF
cat expect \EOF
## master
@@ -329,8 +333,6 @@ A dir2/added
?? dir1/untracked
?? dir2/modified
?? dir2/untracked
-?? expect
-?? output
?? untracked
EOF
@@ -434,8 +436,6 @@ Untracked files:
dir2/modified
dir2/untracked
dir3/
- expect
- output
untracked
EOF
@@ -456,8 +456,6 @@ A dir2/added
?? dir2/modified
?? dir2/untracked
?? dir3/
-?? expect
-?? output
?? untracked
EOF
test_expect_success 'status -s -unormal' '
@@ -493,8 +491,6 @@ Untracked files:
dir2/untracked
dir3/untracked1
dir3/untracked2
- expect
- output
untracked
EOF
@@ -518,8 +514,6 @@ A dir2/added
?? dir1/untracked
?? dir2/modified
?? dir2/untracked
-?? expect
-?? output
?? untracked
EOF
test_expect_success 'status -s -uall' '
@@ -554,8 +548,6 @@ Untracked files:
untracked
../dir2/modified
../dir2/untracked
- ../expect
- ../output
../untracked
EOF
@@ -569,8 +561,6 @@ A ../dir2/added
?? untracked
?? ../dir2/modified
?? ../dir2/untracked
-?? ../expect
-?? ../output
?? ../untracked
EOF
test_expect_success 'status -s with relative paths' '
@@ -586,8 +576,6 @@ A dir2/added
?? dir1/untracked
?? dir2/modified
?? dir2/untracked
-?? expect
-?? output
?? untracked
EOF
@@ -625,8 +613,6 @@ Untracked files:
BLUEdir1/untrackedRESET
BLUEdir2/modifiedRESET
BLUEdir2/untrackedRESET
- BLUEexpectRESET
- BLUEoutputRESET
BLUEuntrackedRESET
EOF
@@ -647,8 +633,6 @@ cat expect \EOF
BLUE??RESET dir1/untracked
BLUE??RESET dir2/modified
BLUE??RESET dir2/untracked
-BLUE??RESET expect
-BLUE??RESET output
BLUE??RESET untracked
EOF
@@ -676,8 +660,6 @@ cat expect \EOF
BLUE??RESET dir1/untracked
BLUE??RESET dir2/modified
BLUE??RESET dir2/untracked
-BLUE??RESET expect
-BLUE??RESET output
BLUE??RESET untracked
EOF
@@ -694,8 +676,6 @@ A dir2/added
?? dir1/untracked
?? dir2/modified
?? dir2/untracked
-?? expect
-?? output
?? untracked
EOF
@@ -755,8 +735,6 @@ Untracked files:
dir1/untracked
dir2/modified
dir2/untracked
- expect
- output
untracked
EOF
@@ -772,8 +750,6 @@ A dir2/added
?? dir1/untracked
?? dir2/modified
?? dir2/untracked
-?? expect
-?? output
?? untracked
EOF
@@ -798,8 +774,6 @@ Untracked files:
dir1/untracked
dir2/
- expect
- output
untracked
EOF
@@ -848,8 +822,6 @@ Untracked files:
dir1/untracked
dir2/modified
dir2/untracked
- expect
- output
untracked
EOF
@@ -870,8 +842,6 @@ A sm
?? dir1/untracked
?? dir2/modified
?? dir2/untracked
-?? expect
-?? output
?? untracked
EOF
test_expect_success 'status -s submodule summary is disabled by default' '
@@ -913,8 +883,6 @@ Untracked files:
dir1/untracked
dir2/modified
dir2/untracked
- expect
- output
untracked
EOF
@@
[PATCHv4 0/3]
v4 has an additional line with 50*- before the second header (if there is any). Also, if status spewed out a cut-line (for commit) we emit a trailer line before the first header (if there is any) so that it doesn't get sucked in visually with the cut line description. If there is only a second header it stands out by itself already due to quinti-dashed line. Junio C Hamano (1): t7508: .gitignore 'expect' and 'output' files Michael J Gruber (2): t7508: test git status -v commit/status: show the index-worktree diff with -v -v Documentation/git-commit.txt | 4 ++ t/t7508-status.sh| 103 +++ wt-status.c | 20 + 3 files changed, 60 insertions(+), 67 deletions(-) -- 2.3.1.303.g5174db1 -- 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 1/2] git-credential-store: support XDG config dir
Paul Tan pyoka...@gmail.com writes:
Hi all,
Thanks for the review. I apologize for rushing the patch out as I
wanted to get feedback on the new behavior before committing to any
more code changes.
There is no problem sending unfinished versions for discussions. If
unsure, send it as [RFC/PATCH].
When writting a commit message, always insist on _why_ [...]
Generally, I would like git to have full support for the XDG base dir
spec
The point is not only why you implement XDG spec (which is not very
controversial), but also why you did it the way you did.
In fact, thinking about it again, I think the behavior implemented in
the patch may not be suitable. Comments below.
Writting more arguments in the commit message helps getting these
thoughts earlier ;-).
Likewise,
lookup_credential() returns 1 if it could find the credential, and 0 if
it could not.
Err, you're changing the calling convention, and you're not the only
caller (git grep lookup_credential).
If you need to change this existing function, best is to start your
series with a preparatory patch that does the calling convention change,
adapts the other caller, and then write your change on top, as [PATCH 2].
Eh? I thought lookup_credential has static linkage. The only other use
of lookup_credential is in credential-cache--daemon.c, and that has
its own function definition with static linkage.
Indeed, it was only me looking at git grep too fast. You're right.
- if (!strcmp(op, get))
- lookup_credential(file, c);
- else if (!strcmp(op, erase))
- remove_credential(file, c);
- else if (!strcmp(op, store))
- store_credential(file, c);
- else
+ if (!strcmp(op, get)) {
+ if (file) {
+ lookup_credential(file, c);
+ } else {
+ if (xdg_file access_or_warn(xdg_file, R_OK, 0) ==
0)
+ ret = lookup_credential(xdg_file, c);
+ if (!ret home_file access_or_warn(home_file,
R_OK, 0) == 0)
+ lookup_credential(home_file, c);
+ }
+ } else if (!strcmp(op, erase)) {
+ if (file) {
+ remove_credential(file, c);
+ } else {
+ if (xdg_file access(xdg_file, F_OK) == 0)
+ remove_credential(xdg_file, c);
+ if (home_file access(home_file, F_OK) == 0)
+ remove_credential(home_file, c);
Why is it somethimes access_or_warn and sometimes just access? (genuine
question)
For get even though the xdg file cannot be read I believe it should
not be a fatal error because the credential may be found in the home
file. We should still warn the user though because it may not be what
the user wants.
IMHO, this would deserve a short comment in the code, e.g. /* Warn the
user, but we may recover by finding credential in another file */ or so.
It's less sensitive, but there was more subtle breakages with the config
file (should Git do something at all when the config files can't be read
completely?).
However, I see now that I mistakenly broke compatibility with the old
behavior, which errors out if the home credential file could not be
read.
You changed the behavior, but it's not really a compatibility breakage:
I doubt people _rely_ on Git dying in this case.
I have no strong opinion on what behavior is the best, I think yours
makes sense, but if you go for it, it should be documented in the commit
message (or even better: the change could be extracted into a separate
patch)
I'm not convinced you need to remove the credential from home_file if
the xdg_file takes precedence. Not saying you shouldn't, but you should
argue more at least.
Indeed, I committed a reasoning error there. I was thinking about what
happens if the user runs store on the new version of git, then
switches to an old one. Actually, store should write to both, so
that users will get the updated credentials regardless of whether they
use the old or new git.
Actually, your version made sense too. Credentials are usually
confidential data that you don't want to replicate too much. One reason
for using store can be that you want to overwrite your old password
with something else, and not leave your old password lying around
(because, e.g. it's the same password you use for your bank account and
nuclear launch code, and you haven't changed it there yet).
In fact, the priority needs to be changed. To summarize, for
compatibility with older versions, git should read from the home
credentials file first, then the XDG one (since store will handle
updating of both). For writing, git should write to both files. For
erasing, git should erase from both files.
OTOH, if you really want compatibility with old versions, just don't
create .config/git/ and git will still write to ~/.git-credentials,
right? As
Re: [PATCH] [GSoC][MICRO] Forbid log --graph --no-walk
On Fri, Mar 6, 2015 at 3:55 AM, Dongcan Jiang dongcan.ji...@gmail.com wrote:
Forbid log --graph --no-walk
Style: drop capitalization in the Subject: line. Also prefix with the
command or module being modified, followed by a colon. So:
log: forbid combining --graph and --no-walk
or:
revision: forbid combining --graph and --no-walk
Because --graph is about connected history while --no-walk is about discrete
points.
Okay. You might also want to cite the wider discussion[1].
[1]: http://article.gmane.org/gmane.comp.version-control.git/216083
revision.c: Judge whether --graph and --no-walk come together when running
git-log.
buildin/log.c: Set git-log cmd flag.
Documentation/rev-list-options.txt: Add specification on the forbidden usage.
No need to repeat in prose what the patch itself states more clearly
and concisely.
Also, such a change should be accompanied by new test(s).
Signed-off-by: Dongcan Jiang dongcan.ji...@gmail.com
---
diff --git a/Documentation/rev-list-options.txt
b/Documentation/rev-list-options.txt
index 4ed8587..eea2c0a 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -679,6 +679,7 @@ endif::git-rev-list[]
given on the command line. Otherwise (if `sorted` or no argument
was given), the commits are shown in reverse chronological order
by commit time.
+ Cannot be combined with `--graph` when running git-log.
--do-walk::
Overrides a previous `--no-walk`.
@@ -781,6 +782,7 @@ you would get an output like this:
on the left hand side of the output. This may cause extra lines
to be printed in between commits, in order for the graph history
to be drawn properly.
+ Cannot be combined with `--no-walk` when running git-log.
Nice to see documentation updates. More below.
This enables parent rewriting, see 'History Simplification' below.
+
diff --git a/builtin/log.c b/builtin/log.c
index dd8f3fc..7bf5adb 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -627,6 +627,7 @@ int cmd_log(int argc, const char **argv, const char
*prefix)
git_config(git_log_config, NULL);
init_revisions(rev, prefix);
+ rev.cmd_is_log = 1;
rev.always_show_header = 1;
memset(opt, 0, sizeof(opt));
opt.def = HEAD;
diff --git a/revision.c b/revision.c
index 66520c6..5f62c89 100644
--- a/revision.c
+++ b/revision.c
@@ -1399,6 +1399,8 @@ void init_revisions(struct rev_info *revs, const char
*prefix)
revs-commit_format = CMIT_FMT_DEFAULT;
+ revs-cmd_is_log = 0;
+
init_grep_defaults();
grep_init(revs-grep_filter, prefix);
revs-grep_filter.status_only = 1;
@@ -2339,6 +2341,8 @@ int setup_revisions(int argc, const char **argv, struct
rev_info *revs, struct s
if (revs-reflog_info revs-graph)
die(cannot combine --walk-reflogs with --graph);
+ if (revs-no_walk revs-graph revs-cmd_is_log)
Placing 'revs-cmd_is_log' first would make it clear at a glance that
this restriction impacts 'log' only (but see question below):
if (revs-cmd_is_log revs-no_walk revs-graph)
+ die(cannot combine --no-walk with --graph when running
git-log);
if (!revs-reflog_info revs-grep_filter.use_reflog_filter)
die(cannot use --grep-reflog without --walk-reflogs);
diff --git a/revision.h b/revision.h
index 0ea8b4e..255982a 100644
--- a/revision.h
+++ b/revision.h
@@ -146,6 +146,9 @@ struct rev_info {
track_first_time:1,
linear:1;
+ /* cmd type */
+ unsigned int cmd_is_log:1;
Genuine question: Despite the GSoC micro-project mentioning only
'log', is it ever meaningful for these two options to be specified
together? I suspect not, but it would be nice to hear from someone
more familiar with the issue. If not specific to 'log', then the patch
can be simplified a good deal.
enum date_mode date_mode;
unsigned intabbrev;
--
--
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] daemon: use strbuf for hostname info
Convert hostname, canon_hostname, ip_address and tcp_port to strbuf.
This allows to get rid of the helpers strbuf_addstr_or_null() and STRARG
because a strbuf always represents a valid (initially empty) string.
sanitize_client() becomes unused and is removed as well.
Signed-off-by: Rene Scharfe l@web.de
---
daemon.c | 98 +++-
1 file changed, 41 insertions(+), 57 deletions(-)
diff --git a/daemon.c b/daemon.c
index c3edd96..c04315e 100644
--- a/daemon.c
+++ b/daemon.c
@@ -56,10 +56,10 @@ static const char *user_path;
static unsigned int timeout;
static unsigned int init_timeout;
-static char *hostname;
-static char *canon_hostname;
-static char *ip_address;
-static char *tcp_port;
+static struct strbuf hostname = STRBUF_INIT;
+static struct strbuf canon_hostname = STRBUF_INIT;
+static struct strbuf ip_address = STRBUF_INIT;
+static struct strbuf tcp_port = STRBUF_INIT;
static int hostname_lookup_done;
@@ -68,13 +68,13 @@ static void lookup_hostname(void);
static const char *get_canon_hostname(void)
{
lookup_hostname();
- return canon_hostname;
+ return canon_hostname.buf;
}
static const char *get_ip_address(void)
{
lookup_hostname();
- return ip_address;
+ return ip_address.buf;
}
static void logreport(int priority, const char *err, va_list params)
@@ -122,12 +122,6 @@ static void NORETURN daemon_die(const char *err, va_list
params)
exit(1);
}
-static void strbuf_addstr_or_null(struct strbuf *sb, const char *s)
-{
- if (s)
- strbuf_addstr(sb, s);
-}
-
struct expand_path_context {
const char *directory;
};
@@ -138,22 +132,22 @@ static size_t expand_path(struct strbuf *sb, const char
*placeholder, void *ctx)
switch (placeholder[0]) {
case 'H':
- strbuf_addstr_or_null(sb, hostname);
+ strbuf_addbuf(sb, hostname);
return 1;
case 'C':
if (placeholder[1] == 'H') {
- strbuf_addstr_or_null(sb, get_canon_hostname());
+ strbuf_addstr(sb, get_canon_hostname());
return 2;
}
break;
case 'I':
if (placeholder[1] == 'P') {
- strbuf_addstr_or_null(sb, get_ip_address());
+ strbuf_addstr(sb, get_ip_address());
return 2;
}
break;
case 'P':
- strbuf_addstr_or_null(sb, tcp_port);
+ strbuf_addbuf(sb, tcp_port);
return 1;
case 'D':
strbuf_addstr(sb, context-directory);
@@ -301,16 +295,14 @@ static int run_access_hook(struct daemon_service
*service, const char *dir, cons
char *eol;
int seen_errors = 0;
-#define STRARG(x) ((x) ? (x) : )
*arg++ = access_hook;
*arg++ = service-name;
*arg++ = path;
- *arg++ = STRARG(hostname);
- *arg++ = STRARG(get_canon_hostname());
- *arg++ = STRARG(get_ip_address());
- *arg++ = STRARG(tcp_port);
+ *arg++ = hostname.buf;
+ *arg++ = get_canon_hostname();
+ *arg++ = get_ip_address();
+ *arg++ = tcp_port.buf;
*arg = NULL;
-#undef STRARG
child.use_shell = 1;
child.argv = argv;
@@ -556,23 +548,14 @@ static void sanitize_client_strbuf(struct strbuf *out,
const char *in)
strbuf_setlen(out, out-len - 1);
}
-static char *sanitize_client(const char *in)
-{
- struct strbuf out = STRBUF_INIT;
- sanitize_client_strbuf(out, in);
- return strbuf_detach(out, NULL);
-}
-
/*
- * Like sanitize_client, but we also perform any canonicalization
+ * Like sanitize_client_strbuf, but we also perform any canonicalization
* to make life easier on the admin.
*/
-static char *canonicalize_client(const char *in)
+static void canonicalize_client_strbuf(struct strbuf *out, const char *in)
{
- struct strbuf out = STRBUF_INIT;
- sanitize_client_strbuf(out, in);
- strbuf_tolower(out);
- return strbuf_detach(out, NULL);
+ sanitize_client_strbuf(out, in);
+ strbuf_tolower(out);
}
/*
@@ -595,11 +578,11 @@ static void parse_host_arg(char *extra_args, int buflen)
char *port;
parse_host_and_port(val, host, port);
if (port) {
- free(tcp_port);
- tcp_port = sanitize_client(port);
+ strbuf_reset(tcp_port);
+ sanitize_client_strbuf(tcp_port, port);
}
- free(hostname);
- hostname = canonicalize_client(host);
+ strbuf_reset(hostname);
+
[PATCHv4 3/3] commit/status: show the index-worktree diff with -v -v
git commit and git status in long format show the diff between HEAD
and the index when given -v. This allows previewing a commit to be made.
They also list tracked files with unstaged changes, but without a diff.
Introduce '-v -v' which shows the diff between the index and the
worktree in addition to the HEAD index diff. This allows a review of unstaged
changes which might be missing from the commit.
In the case of '-v -v', additonal header lines
Changes to be committed:
and
Changes not staged for commit:
are inserted before the diffs, which are equal to those in the status
part; the latter preceded by 50*- to make it stick out more.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
Documentation/git-commit.txt | 4
t/t7508-status.sh| 11 +++
wt-status.c | 20
3 files changed, 35 insertions(+)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 1e74b75..f14d2ec 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -284,6 +284,10 @@ configuration variable documented in linkgit:git-config[1].
would be committed at the bottom of the commit message
template. Note that this diff output doesn't have its
lines prefixed with '#'.
++
+If specified twice, show in addition the unified diff between
+what would be committed and the worktree files, i.e. the unstaged
+changes to tracked files.
-q::
--quiet::
diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index e3c9cf9..6b16bcb 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -143,6 +143,17 @@ test_expect_success 'status -v' '
test_i18ncmp expect-with-v output
'
+test_expect_success 'status -v -v' '
+ (cat expect
+echo Changes to be committed:
+git -c diff.mnemonicprefix=true diff --cached
+echo --
+echo Changes not staged for commit:
+git -c diff.mnemonicprefix=true diff) expect-with-v
+ git status -v -v output
+ test_i18ncmp expect-with-v output
+'
+
test_expect_success 'setup fake editor' '
cat .git/editor -\EOF
#! /bin/sh
diff --git a/wt-status.c b/wt-status.c
index 29666d0..422dc0e 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -849,6 +849,8 @@ static void wt_status_print_verbose(struct wt_status *s)
{
struct rev_info rev;
struct setup_revision_opt opt;
+ int dirty_submodules;
+ const char *c = color(WT_STATUS_HEADER, s);
init_revisions(rev, NULL);
DIFF_OPT_SET(rev.diffopt, ALLOW_TEXTCONV);
@@ -873,7 +875,25 @@ static void wt_status_print_verbose(struct wt_status *s)
rev.diffopt.use_color = 0;
wt_status_add_cut_line(s-fp);
}
+ if (s-verbose 1 s-commitable) {
+ /* print_updated() printed a header, so do we */
+ if (s-fp != stdout)
+ wt_status_print_trailer(s);
+ status_printf_ln(s, c, _(Changes to be committed:));
+ rev.diffopt.a_prefix = c/;
+ rev.diffopt.b_prefix = i/;
+ } /* else use prefix as per user config */
run_diff_index(rev, 1);
+ if (s-verbose 1
+ wt_status_check_worktree_changes(s, dirty_submodules)) {
+ status_printf_ln(s, c,
+ --);
+ status_printf_ln(s, c, _(Changes not staged for commit:));
+ setup_work_tree();
+ rev.diffopt.a_prefix = i/;
+ rev.diffopt.b_prefix = w/;
+ run_diff_files(rev, 0);
+ }
}
static void wt_status_print_tracking(struct wt_status *s)
--
2.3.1.303.g5174db1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 2/3] t7508: test git status -v
status -v had no test. Include one.
This also requires changing the .gitignore subtests, which is a good thing:
they include testing a .gitignore pattern now.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
t/t7508-status.sh | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index 514df67..e3c9cf9 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -137,6 +137,12 @@ test_expect_success 'status with
status.displayCommentPrefix=false' '
test_i18ncmp expect output
'
+test_expect_success 'status -v' '
+ (cat expect git diff --cached) expect-with-v
+ git status -v output
+ test_i18ncmp expect-with-v output
+'
+
test_expect_success 'setup fake editor' '
cat .git/editor -\EOF
#! /bin/sh
@@ -201,7 +207,7 @@ test_expect_success 'status -s' '
test_expect_success 'status with gitignore' '
{
echo .gitignore
- echo expect
+ echo expect*
echo output
echo untracked
} .gitignore
@@ -222,6 +228,7 @@ test_expect_success 'status with gitignore' '
!! dir1/untracked
!! dir2/untracked
!! expect
+ !! expect-with-v
!! output
!! untracked
EOF
@@ -253,6 +260,7 @@ Ignored files:
dir1/untracked
dir2/untracked
expect
+ expect-with-v
output
untracked
@@ -264,7 +272,7 @@ EOF
test_expect_success 'status with gitignore (nothing untracked)' '
{
echo .gitignore
- echo expect
+ echo expect*
echo dir2/modified
echo output
echo untracked
@@ -285,6 +293,7 @@ test_expect_success 'status with gitignore (nothing
untracked)' '
!! dir2/modified
!! dir2/untracked
!! expect
+ !! expect-with-v
!! output
!! untracked
EOF
@@ -312,6 +321,7 @@ Ignored files:
dir2/modified
dir2/untracked
expect
+ expect-with-v
output
untracked
--
2.3.1.303.g5174db1
--
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
Bashing freelancers (was: [ANNOUNCE] Git Merge Contributors Summit, April 8th, Paris)
Junio C Hamano gits...@pobox.com writes: Of course, I am hoping that all the mentors are doing GSoC not for money but out of love of our software and our community, At some point of time I think it may be worth reevaluating the toxic atmosphere against freelancers doing Git development. There is nothing wrong with not having a fixed employment paying the rent. And there is nothing to be gained by going out of one's way vilifying those who cannot afford to work for free. Good work is worth good money. Suggesting that people who are not able to work for free are morally inferior is not conducive for a cooperative work atmosphere. I still have patches sitting in my repository that I could not bring myself to finish for contribution after the shameful treatment of my months of git-blame work where I was credited in passing with a wrong name in one What's cooking, and after I pointed out that not even my name was correct, removed altogether. All that in connection with public shaming that I wanted to point out to end users that this work required financing if it were to continue. -- David Kastrup -- 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] git: make git -C '' cmd not to barf
Andreas Schwab sch...@linux-m68k.org writes: Karthik Nayak karthik@gmail.com writes: +if (*((*argv)[1]) == 0) IMHO (*argv)[1][0] is easier to understand. Thanks for saying that. I had to scratch my head every time I had to see this change from various people ;-) -- 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][GSoC] revision: forbid --graph and --no-walk usage
Akshay Aurora akshayaur...@yahoo.com writes: Signed-off-by: Akshay Aurora akshayaur...@yahoo.com --- This is my first patch for a GSoC Microproject, would be great to have your feedback. revision.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/revision.c b/revision.c index bd027bc..d578652 100644 --- a/revision.c +++ b/revision.c @@ -2248,7 +2248,8 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, struct s */ if (revs-reverse revs-graph) die(cannot combine --reverse with --graph); - + if (revs-no_walk revs-graph) + die(cannot combine --no-walk with --graph); if (revs-reflog_info revs-graph) die(cannot combine --walk-reflogs with --graph); if (!revs-reflog_info revs-grep_filter.use_reflog_filter) Needs a new test to make sure log --no-walk --graph is rejected, and also you need to make sure all other existing tests that used to pass before this change still pass. -- 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: [GSoC microproject] Add XDG support to the credential-store helper
Paul Tan pyoka...@gmail.com writes: Hi Luis, On Fri, Mar 6, 2015 at 7:41 AM, Luis Ressel ara...@aixah.de wrote: Okay, I've had a look at Paul's patch for this. Sorry again for the dupe, I must've missed it before. I guess I'll attempt another microproject. However, I feel like my patch is really all that's neccessary; I don't think we should try to use both files if they exist -- I consider Paul's approach to be a bit overcomplicated. My patch still uses ~/.git-credentials as a default location, which should be sufficient for compability. Indeed, that was my initial plan for implementation as well[1]. Matthieu, however, wanted the behavior to follow that of git-config[2]. The fact that I suggested doing it this way does not mean it _has_ to be done this way. Decisions are taken by trying to reach a consensus with discussion, so everyone is welcome to argue. I don't remember all the discussions we had about the ~/.gitconfig, but one issue with considering only one file is if you create ~/.git/config/foo and initially make sure you don't have ~/.gitfoo, and then one tool creates ~/.gitfoo (either an old Git, or another tool trying to edit the config file), then you totally break your configuration. I argued for not taking backward compatibility too much into account in another thread, but that was about precedence of one file over the other which is far less important. Here, any tool creating even an empty home file would break your configuration. That also breaks the least surprise principle if you have a ~/.gitfoo file that you forgot about: edit ~/.config/git/foo, nothing is taken into account, at all (or the other way around, depending on the precedence you choose). I remember loosing some time with two vlc configuration files like this. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bashing freelancers
David Kastrup d...@gnu.org writes: Good work is worth good money. Suggesting that people who are not able to work for free are morally inferior is not conducive for a cooperative work atmosphere. Yes, but I do not think anybody did any such thing. -- 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
On 03/06/2015 06:59 AM, Torsten Bögershausen wrote:
On 03/05/2015 11:08 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
I would expect that the following .gitattributes file
* eol=crlf
*.png -text
would leave EOL translation turned off for PNG files. In other words, I
would expect that explicitly setting -text would take precedence over
the fact that setting eol implies that a file should be considered to
be text.
I would even more strongly expect
* eol=crlf
*.png binary
to turn off EOL translation for PNG files.
But in fact, in both of the above cases, EOL translation is turned *on*
for PNG files.
I propose that -text should override any setting for eol (which
would of course fix both problems, since binary is equivalent to
-diff -merge -text). What do people think?
Hmm, is there really something that needs a new proposal and
opinions?
The way I read the flow in convert.c is:
convert_to_git() uses input_crlf_action() to figure out what
crlf_to_git() conversion is necessary.
input_crlf_action() looks at text_attr and says CRLF_BINARY when
it is CRLF_BINARY without looking at eol_attr at all.
text_attr above is ca.crlf_action in convert_to_git().
The whole ca.* comes from convert_attrs() inspecting attributes
on the incoming path.
convert_attrs() inspects eol and text attributes, among
others, and sets crlf_action by calling git_path_check_crlf().
git_path_check_crlf() looks at the 'text' attribute; if it is
set to false, it returns CRLF_BINARY.
crlf_to_git() when given crlf_action==CRLF_BINARY is a no-op.
So, with the above attributes where anything is eol=crlf by default
and in addition *.png is binary (which contains -text), we shouldn't
get any crlf munging. Am I reading/following the code incorrectly?
Puzzled
--
I need to admit that I can't reproduce it here,
the following should trigger it, but all test cases pass
diff --git a/t/t0027-auto-crlf.sh b/t/t0027-auto-crlf.sh
index 452320d..22f031d 100755
--- a/t/t0027-auto-crlf.sh
+++ b/t/t0027-auto-crlf.sh
@@ -37,7 +37,8 @@ create_gitattributes () {
echo *.txt text .gitattributes
;;
-text)
- echo *.txt -text .gitattributes
+ echo * eol=crlf .gitattributes
+ echo *.txt -text .gitattributes
;;
crlf)
echo *.txt eol=crlf .gitattributes
Oops, I misunderstood an internal bug report. In seems that it is the
following scenario that is incorrect:
*.png text=auto eol=crlf
when applied to a binary file.
I'm currently studying documentation and writing tests to figure out the
exact current behavior. But honestly, this end-of-line conversion stuff
is bewildering, so it might take a while.
Sorry for the half-cocked bug report. I'll report back when I know more.
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: [PATCH] [GSoC][MICRO] Forbid log --graph --no-walk
Dongcan Jiang dongcan.ji...@gmail.com writes: At first, I also tried to only judge the value of revs-no_walk revs-graph, but unfortunately, it failed to pass all cases in t4052-stat-output.sh. e.g. command git show --stat --graph failed to get the correct result. Finally, this is because that revs-no_walk gets set when it comes to git show --stat. When git show is given a range, it turns no-walk off and becomes a command about a connected history. Otherwise, it is a command about discrete point(s). Because git show --graph A B C and git log --graph --no-walk A B C are moral equivalents, if we are forbidding the latter, we should forbid the former. git show A (and no other revs, just a single point), however, could be thought of as an equivalent for git log -1 A, even though that interpretation is based on a wrong world view (because show one and stop is not the reason why the result git show A gives has only A and nothing else). And it makes sort of sense to allow git show --graph A that is an equivalent to git log -1 --graph A under that interpretation. I was tempted to say the existing test is wrong to expect that --graph does anything meaningful for git show that is run for a non-range. But doing the use of both is wrong for log change without special casing show (and instead fixing t4052) would be a change in behaviour, which we try to avoid in general. I'd prefer a solution that does not waste a new bit in revision structure in general, but if we were to waste one bit to special case show, it shouldn't be fail only for the log command. It should be allow this stupidity only for the show command for backward compatibility bit instead, I 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: [PATCH] log: decorate detached HEAD differently
Michael J Gruber g...@drmicha.warpmail.net writes:
git status and git branch let the user know when the HEAD is
detached, as well as the current branch, while git log --decorate does not.
Change the decoration by a non-detached HEAD pointing to branch foo to
HEAD-foo. This can be seen as giving more information about the
decoration item itself in the same way as we prefix tags by tag: .
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
Notes:
v2 decorates the HEAD pointing to master as HEAD-master, a detached
HEAD just as HEAD. The - hopefully conveys the symlink nature - a
= would be confusing.
Somehow I still prefer detached HEAD, dunno. Maybe in addition?
Note that now a checked branch is listed twice, once as target of the
HEAD, once as branch: They are two different refs and colored differently.
The pointee of HEAD would always be branch and will always appear on
the output when you show HEAD-$name_of_that_branch; is it feasible
to drop the duplicate, I wonder?
log-tree.c | 8 +++-
t/t4013/diff.log_--decorate=full_--all | 2 +-
t/t4013/diff.log_--decorate_--all | 2 +-
t/t4207-log-decoration-colors.sh | 2 +-
4 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index 7f0890e..38862bb 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -118,8 +118,11 @@ static int add_ref_decoration(const char *refname, const
unsigned char *sha1, in
type = DECORATION_REF_TAG;
else if (!strcmp(refname, refs/stash))
type = DECORATION_REF_STASH;
- else if (!strcmp(refname, HEAD))
+ else if (!strcmp(refname, HEAD)) {
+ unsigned char junk_sha1[20];
type = DECORATION_REF_HEAD;
+ refname = resolve_ref_unsafe(HEAD, 0, junk_sha1, NULL);
+ }
if (!cb_data || *(int *)cb_data == DECORATE_SHORT_REFS)
refname = prettify_refname(refname);
@@ -198,6 +201,9 @@ void format_decorations_extended(struct strbuf *sb,
strbuf_addstr(sb, decorate_get_color(use_color,
decoration-type));
if (decoration-type == DECORATION_REF_TAG)
strbuf_addstr(sb, tag: );
+ else if (decoration-type == DECORATION_REF_HEAD
+ strcmp(decoration-name, HEAD))
+ strbuf_addstr(sb, HEAD-);
strbuf_addstr(sb, decoration-name);
strbuf_addstr(sb, color_reset);
prefix = separator;
diff --git a/t/t4013/diff.log_--decorate=full_--all
b/t/t4013/diff.log_--decorate=full_--all
index 44d4525..3758ae9 100644
--- a/t/t4013/diff.log_--decorate=full_--all
+++ b/t/t4013/diff.log_--decorate=full_--all
@@ -5,7 +5,7 @@ Date: Mon Jun 26 00:06:00 2006 +
Rearranged lines in dir/sub
-commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD, refs/heads/master)
+commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD-refs/heads/master,
refs/heads/master)
Merge: 9a6d494 c7a2ab9
Author: A U Thor aut...@example.com
Date: Mon Jun 26 00:04:00 2006 +
diff --git a/t/t4013/diff.log_--decorate_--all
b/t/t4013/diff.log_--decorate_--all
index 27d3eab..df702ae 100644
--- a/t/t4013/diff.log_--decorate_--all
+++ b/t/t4013/diff.log_--decorate_--all
@@ -5,7 +5,7 @@ Date: Mon Jun 26 00:06:00 2006 +
Rearranged lines in dir/sub
-commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD, master)
+commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD-master, master)
Merge: 9a6d494 c7a2ab9
Author: A U Thor aut...@example.com
Date: Mon Jun 26 00:04:00 2006 +
diff --git a/t/t4207-log-decoration-colors.sh
b/t/t4207-log-decoration-colors.sh
index 925f577..0437ff2 100755
--- a/t/t4207-log-decoration-colors.sh
+++ b/t/t4207-log-decoration-colors.sh
@@ -44,7 +44,7 @@ test_expect_success setup '
'
cat expected EOF
-${c_commit}COMMIT_ID${c_reset}${c_commit}
(${c_HEAD}HEAD${c_reset}${c_commit},\
+${c_commit}COMMIT_ID${c_reset}${c_commit}
(${c_HEAD}HEAD-master${c_reset}${c_commit},\
${c_tag}tag: v1.0${c_reset}${c_commit},\
${c_tag}tag: B${c_reset}${c_commit},\
${c_branch}master${c_reset}${c_commit})${c_reset} B
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/3] sha1_file: implement changes for cat-file --literally -t
On 03/06/2015 05:15 AM, Junio C Hamano wrote:
Karthik Nayak karthik@gmail.com writes:
+const char *sha1_object_info_literally(const unsigned char *sha1)
+{
+ enum object_type type;
+ struct strbuf sb = STRBUF_INIT;
+ struct object_info oi = {NULL};
+
+ oi.typename = sb;
+ oi.typep = type;
+ if (sha1_object_info_extended(sha1, oi, LOOKUP_LITERALLY) 0)
+ return NULL;
+ if (*oi.typep 0) {
+ strbuf_release(oi.typename);
+ return typename(*oi.typep);
+ }
+ return oi.typename-buf;
+}
After calling this function to ask the textual type of an object,
should the caller free the result it obtains from this function?
oi.typename points at the strbuf on stack and its buf member points
at an allocated piece of memory. That must be freed.
On the other hand, typename(*oi.typep) is a pointer into static
piece of memory, which must never be freed.
This patch introduces this function without introducing any caller,
which makes it unnecessarily harder to judge if this problem is
caused by choosing a wrong calling convention, and/or if so what
better calling convention can be used to correct the problem, but
without looking at the caller that (presumably) will be introduced
in a later patch, I suspect that the caller should supply a pointer
to struct object_info, i.e. something along these lines:
struct object_info oi = { NULL };
struct strbuf sb = STRBUF_INIT;
enum object_type type;
...
oi.typename = sb;
sha1_object_info_literally(sha1, oi);
if (!sb.len)
that is an error;
else
use sb.buf as the name;
strbuf_release(sb);
I thought I could get the calling function cat_one_file() to send
the address to a struct strbuf. Like this ..
struct strbuf sb = STRBUF_INIT;
length = sha1_object_info_literally(sha1, sb);
if (length 0)
die(git cat-file --literally -t %s: failed,
obj_name);
printf(%s\n, sb.buf);
strbuf_release(sb);
return 0;
What do you think? Is this ok?
As sha1_object_info_extended() takes oi and fills oi.typename when
it is supplied for _all_ types, not just the bogus ones, a caller of
that function, including sha1_object_info_literally() and its
caller, shouldn't have to worry about is that a known one? then
use typename() to convert the enum type to a string. Otherwise use
the oi.typename-buf at all, I would think.
I also missed a part where the object given was a packed object.
eg : git cat-file -t --literally HEAD~2
And since I missed that out, it wasnt copying the type to oi.typename,
and oi.typename would end up being empty, I found this while i was
using gdb.
Didn't CC the mailing list the first time, sorry.
--
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] sequencer: preserve commit messages
Michael J Gruber g...@drmicha.warpmail.net writes:
sequencer calls commit with default options, which implies
--cleanup=default unless the user specified something else in their
config. This leads to cherry-picked commits getting a cleaned up commit
message, which is usually not an intended side-effect.
Make the sequencer use --cleanup=verbatim so that it preserves commit
messages independent of the default, unless the user has set config for
commit
or the message is amended with -s or -x.
Reported-by: Christoph Anton Mitterer cales...@scientia.net
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
Looks very sensible.
Thank you very much for your efforts to tie the loose ends on many
topics that were discussed already without leading to their
completion.
Will replace and queue.
sequencer.c | 5 +
t/t3511-cherry-pick-x.sh | 28
2 files changed, 33 insertions(+)
diff --git a/sequencer.c b/sequencer.c
index 77a1266..8cf575c 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -373,6 +373,7 @@ static int run_git_commit(const char *defmsg, struct
replay_opts *opts,
{
struct argv_array array;
int rc;
+ const char *value;
argv_array_init(array);
argv_array_push(array, commit);
@@ -385,6 +386,10 @@ static int run_git_commit(const char *defmsg, struct
replay_opts *opts,
if (!opts-edit) {
argv_array_push(array, -F);
argv_array_push(array, defmsg);
+ if (!opts-signoff
+ !opts-record_origin
+ git_config_get_value(commit.cleanup, value))
+ argv_array_push(array, --cleanup=verbatim);
}
if (allow_empty)
diff --git a/t/t3511-cherry-pick-x.sh b/t/t3511-cherry-pick-x.sh
index f977279..b7dff09 100755
--- a/t/t3511-cherry-pick-x.sh
+++ b/t/t3511-cherry-pick-x.sh
@@ -36,6 +36,20 @@ mesg_with_cherry_footer=$mesg_with_footer_sob
(cherry picked from commit da39a3ee5e6b4b0d3255bfef95601890afd80709)
Tested-by: C.U. Thor cut...@example.com
+mesg_unclean=$mesg_one_line
+
+
+leading empty lines
+
+
+consecutive empty lines
+
+# hash tag comment
+
+trailing empty lines
+
+
+
test_expect_success setup '
git config advice.detachedhead false
@@ -53,6 +67,10 @@ test_expect_success setup '
test_commit $mesg_with_footer_sob foo b mesg-with-footer-sob
git reset --hard initial
test_commit $mesg_with_cherry_footer foo b mesg-with-cherry-footer
+ git reset --hard initial
+ test_config commit.cleanup verbatim
+ test_commit $mesg_unclean foo b mesg-unclean
+ test_unconfig commit.cleanup
pristine_detach initial
test_commit conflicting unrelated
'
@@ -216,4 +234,14 @@ test_expect_success 'cherry-pick -x -s treats (cherry
picked from... line as p
test_cmp expect actual
'
+test_expect_success 'cherry-pick preserves commit message' '
+ pristine_detach initial
+ printf $mesg_unclean expect
+ git log -1 --pretty=format:%B mesg-unclean actual
+ test_cmp expect actual
+ git cherry-pick mesg-unclean
+ git log -1 --pretty=format:%B actual
+ test_cmp expect actual
+'
+
test_done
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] http: Include locale.h when using setlocale()
Ævar Arnfjörð Bjarmason ava...@gmail.com writes: Since v2.3.0-rc1-37-gf18604b we've been using setlocale() here without importing locale.h. Oddly enough this only causes issues for me under -O0 on GCC Clang. Sorry for not making this entry in What's cooking report very prominent: * ye/http-accept-language (2015-02-26) 1 commit (merged to 'next' on 2015-03-03 at 58d195e) + gettext.c: move get_preferred_languages() from http.c Compilation fix for a recent topic in 'master'. Will merge to 'master'. This has cooked on 'next' for a few days, and is eligible to graduate to 'master'. Will be in the next update. Thanks. -- 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 2/2] branch: name detached HEAD analogous to status
Michael J Gruber g...@drmicha.warpmail.net writes: git status carefully names a detached HEAD at resp. from a rev or ref depending on whether the detached HEAD has moved since. git branch always uses from, which can be confusing, because a status-aware user would interpret this as moved detached HEAD. Make git branch use the same logic and wording. Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- Notes: v2 uses the info from refactored wt-status. In addition, it tries to make sure that branch and status use the same strings: HEAD detached at %s * (HEAD detached at %s) (status first line, branch second line) Unfortunately, status strings are broken into pieces, so this can be achieved by comments only. It feels somewhat strange to have fields called detached-at and detached-from in wt_status_state. With this patch, * branch is either a string HEAD or the name of the branch we are on. * detached_from is the name of the branch HEAD detached from, or NULL if HEAD is on a branch. * detached_sha1[] is the object name of the commit we last moved to with checkout --detach. * detached_at is a boolean that says the tip of detached_from and detached_sha1[] is the same. There aren't that many users of these fields, so if we were to rename them and clarify what they mean in order to make the code more readable, we may be able to do so without too much churn. Random conflicting/incoherent thoughts include: - perhaps branch can be NULL when detached? - perhaps branch can always point at the branch or the current detached-from? - perhaps detached_from can be renamed to make it more clear that it is the name of a branch (detached_sha1[] is fine, because it is clear what it is by having sha1 in its name)? - perhaps detached_from/detached_at can be made into a single string that is set up by wt-status to hold either HEAD detached at %s or HEAD detached from %s to be used by its callers? but I cannot yet reach a coherent whole to be called a suggestion for a better organization X-. Will replace what was queued with this version. Thanks. -- 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: [GSoC microproject] Add XDG support to the credential-store helper
Hi, Reading my previous message again, I apologize if it sounded conflicting. Truth to be told, I see merits in both proposed behaviors, but it all depends on whether we want git-credentials-store to support an arbitrary number of config files (now or in the future) or just two. I'm not sitting on the fence though, personally I think that we should go with supporting an arbitrary number of config files (and the behavior it entails for xdg file vs home file), because it will open up more possibilities in the future with regards to supporting multiple config sources. On Sat, Mar 7, 2015 at 1:28 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: The fact that I suggested doing it this way does not mean it _has_ to be done this way. Decisions are taken by trying to reach a consensus with discussion, so everyone is welcome to argue. Well, I think we need to decide if git is going to implement support for XDG_CONFIG_DIRS as well, as support for reading/writing an arbitrary number of config files will affect my views on the behavior. Personally, I think git-credentials-store should implement support for XDG_CONFIG_DIRS because, as I mentioned in the previous message, administrators may wish to provide users with default saved credentials. If machinery is being added to support reading/writing to an arbitrary number of config files, it would lead to simpler behavior (and simpler code) if the old ~/.git-credentials is just treated as just another config file to load from. (So yes, I agree with implementing your proposed behavior) However, if we are just going to support 2 configuration files (the xdg file and the home file), then I think Luis' proposed behavior has some merit. See below. (Just mentioning for completeness) The third option would be to implement a hybrid of the above two approaches (support arbitrary number of config files, but only choose 1 between the xdg file and home file), but this behavior is unnecessarily complex. I don't remember all the discussions we had about the ~/.gitconfig, but one issue with considering only one file is if you create ~/.git/config/foo and initially make sure you don't have ~/.gitfoo, and then one tool creates ~/.gitfoo (either an old Git, or another tool trying to edit the config file), then you totally break your configuration. I argued for not taking backward compatibility too much into account in another thread, but that was about precedence of one file over the other which is far less important. Here, any tool creating even an empty home file would break your configuration. Luis mentioned that if the user expects to use an old version of git, the user would (or should) not create the xdg file in the first place. I think that automated tools (and users) should call git-config to edit the config files anyway and not roll their own. In fact, I think that this issue will not occur at all if git prioritized ~/.config/git/foo over ~/.gitfoo instead of the other way around. When the user creates the xdg file, the user is signaling that old versions of git will not be used. Thus, if a tool creates/updates the old home file (and it should not if it calls git-config), then configuration changes won't take effect at all, and it _shouldn't_ because the tool is _broken_. But yes, the above strategy does not scale at all for multiple configuration sources, which there will be if support for XDG_CONFIG_DIRS is implemented. (As an aside, I find it weird that git-config allows values in ~/.gitconfig to override ~/.config/git/config, given that the xdg file is opt-in and introduced after ~/.gitconfig. Furthermore, it conflicts with its writing behavior -- it writes to ~/.config/git/config and not ~/.gitconfig if it exists.) That also breaks the least surprise principle if you have a ~/.gitfoo file that you forgot about: edit ~/.config/git/foo, nothing is taken into account, at all (or the other way around, depending on the precedence you choose). I remember loosing some time with two vlc configuration files like this. Hmm, I don't know the exact specifics of what happened with VLC, so I can't judge. As mentioned above, if the user wants compatibility with old tools, the user will not create the xdg file. If the user has an updated toolset, the user will create the xdg file and delete the old home file. The old home file will not be created at all because all tools would have been updated to support the xdg file, and hence the user will not be confused. Of course, in the context of git-config, it has to read the files in /etc/gitconfig, $GIT_DIR/config etc, and thus as mentioned above, reading from the home file as well would lead to simpler behavior and code. Regards, Paul -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/3] sha1_file: implement changes for cat-file --literally -t
karthik nayak karthik@gmail.com writes:
... I suspect that the caller should supply a pointer to struct
object_info, i.e. something along these lines:
struct object_info oi = { NULL };
struct strbuf sb = STRBUF_INIT;
enum object_type type;
...
oi.typename = sb;
sha1_object_info_literally(sha1, oi);
if (!sb.len)
that is an error;
else
use sb.buf as the name;
strbuf_release(sb);
I thought I could get the calling function cat_one_file() to send
the address to a struct strbuf. Like this ..
struct strbuf sb = STRBUF_INIT;
length = sha1_object_info_literally(sha1, sb);
if (length 0)
die(git cat-file --literally -t %s: failed,
obj_name);
printf(%s\n, sb.buf);
strbuf_release(sb);
return 0;
What do you think? Is this ok?
When I gave you $gmane/264420, I was actually hoping that we do not
have to have object-info-literally helper at all, and instead the
caller in cat-file that deals with -t option can become something
like this:
struct object_info oi = { NULL };
struct strbuf typename = STRBUF_INIT;
unsigned flags = LOOKUP_REPLACE_OBJECT;
if (doing the --literally stuff)
flags |= LOOKUP_LITERALLY;
...
switch (...) {
case 't':
oi.typename = typename;
sha1_object_info_extended(sha1, oi, flags);
if (typename.len) {
printf(%s\n, typename.buf);
return 0;
}
break;
...
The change illustrated in $gmane/264420 is probably incomplete and
some calls from the sha1_object_info_extended() after that change
may still need to be tweaked to pay attention to LOOKUP_LITERALLY
bit (e.g. parse_sha1_header() may want to learn not to barf when
seeing an unexpected typename in the header when the caller asks to
look up literally).
--
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
[GSoC microproject help] Allow - as a short-hand for @{-1} in more places
Hi All, I am a sophomore at Indian Institute of Technology Kanpur and am a GSoC aspirant for git. Although I have been using git from a long time, this is the first occasion when I have picked up reading its source code. Can somebody please help me by telling me how to start off with the above mentioned microproject? Thank you very much. -- 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: Bashing freelancers
Junio C Hamano gits...@pobox.com writes: David Kastrup d...@gnu.org writes: Good work is worth good money. Suggesting that people who are not able to work for free are morally inferior is not conducive for a cooperative work atmosphere. Yes, but I do not think anybody did any such thing. Of course, I am hoping that all the mentors are doing GSoC not for money but out of love of our software and our community, Huh. -- David Kastrup -- 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] daemon: use strbuf for hostname info
On Fri, Mar 06, 2015 at 09:57:22AM +0100, René Scharfe wrote:
Convert hostname, canon_hostname, ip_address and tcp_port to strbuf.
This allows to get rid of the helpers strbuf_addstr_or_null() and STRARG
because a strbuf always represents a valid (initially empty) string.
sanitize_client() becomes unused and is removed as well.
Makes sense. I had a feeling that we might have cared about NULL versus
the empty string somewhere, but I did not see it in the patch below, so
I think it is fine.
-static char *sanitize_client(const char *in)
-{
- struct strbuf out = STRBUF_INIT;
- sanitize_client_strbuf(out, in);
- return strbuf_detach(out, NULL);
-}
Not a big deal, but do we want to rename sanitize_client_strbuf to
sanitize_client? It only had the unwieldy name to distinguish it from
this one.
if (port) {
- free(tcp_port);
- tcp_port = sanitize_client(port);
+ strbuf_reset(tcp_port);
+ sanitize_client_strbuf(tcp_port, port);
The equivalent of free() is strbuf_release(). I think it is reasonable
to strbuf_reset here, since we are about to write into it again anyway
(though I doubt it happens much in practice, since that would imply
multiple `host=` segments sent by the client). But later...
- free(hostname);
- free(canon_hostname);
- free(ip_address);
- free(tcp_port);
- hostname = canon_hostname = ip_address = tcp_port = NULL;
+ strbuf_reset(hostname);
+ strbuf_reset(canon_hostname);
+ strbuf_reset(ip_address);
+ strbuf_reset(tcp_port);
These probably want to all be strbuf_release(). Again, I doubt it
matters much because this is a forked daemon serving only a single
request (so they'll get freed by the OS soon anyway), but I think
freeing the memory here follows the original intent.
-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: [PATCH] Suggest applicants to participate in review of other peoples' patches
Jeff King p...@peff.net writes: On Fri, Mar 06, 2015 at 12:53:57PM +0100, Matthieu Moy wrote: Idea and most of the wording comes from Junio's message on the list. I added a hint to include links to review in the application (which makes the suggestion a bit stronger since it implies that it will be taken into account in the selection). Seems reasonable. I do not know what the quality of reviews will be from applicants, but I guess we will find out. :) I actually was hoping to see an applicant replaying the review comments given to him to another applicant that makes the same kind of mistakes. That is a fairly easy entry to get into reviewing process---even you may not yet know what you are suggesting the other to do is the norm in this community, if a more experienced person told you something similar, it would be likely it is. -- 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: [GSoC microproject help] Allow - as a short-hand for @{-1} in more places
Sundararajan R dyou...@gmail.com writes:
Although I have been using git from a long time, this is
the first occasion when I have picked up reading its source code. Can
somebody please help me by telling me how to start off with the above
mentioned microproject?
A good place to start on the specific coding side is to see how
existing changes for the same objective were done.
Hints:
Does reading git log --grep='@{-1}' help you? When was @{-1}
introduced, and how is it connected to the - short-hand that is
exposed to the end-user by what mechanism in commits surrounding
the one that introduces the @{-1} mechanism?
Does reading git grep '@{-1}' help you? Where does it appear?
What code interprets it to find the last branch before you
switched and how? Who calls that code? Is there something that
turns a user-supplied - into @{-1} before calling that code?
What did that caller looked like before it started noticing -?
Does running git blame -Lline range on that caller help you to
find out which commit made the change, and does running git show
on that commit help you understand how the change was done?
At the same time, GSoC is about working _with_ the development
community, so another good place to start (you need to start on both
fronts) is to subscribe and read this mailing list and also to dig
the list archive (hint: the search interface of gmane often let you
find gems) to understand how other people propose new changes and
how their changes are discussed, reviewed and polished. You'll be
part of that kind of exchanges yourself once you become part of the
project.
Welcome.
--
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: [GSoC microproject help] Allow - as a short-hand for @{-1} in more places
Hi Sundararajan,
Welcome to Git Community.
You need to look for commands dealing with branches, and allow '-' as
shorthand for @{-1}.
You can look at patches already sent for this microproject. One of the
students has already started working on git reset command [0].
Junio, has raised some key issues you'll need to tackle on that
thread. Hopefully it should get you started.
Make sure the existing tests pass after making changes. You might also
need to add a new test case for your microproject.
[0] - http://thread.gmane.org/gmane.comp.version-control.git/264688
On Sat, Mar 7, 2015 at 1:35 AM, Sundararajan R dyou...@gmail.com wrote:
Hi All,
I am a sophomore at Indian Institute of Technology Kanpur and am a GSoC
aspirant for git. Although I have been using git from a long time, this is
the first occasion when I have picked up reading its source code. Can
somebody please help me by telling me how to start off with the above
mentioned microproject?
Thank you very much.
--
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
--
AA
--
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][GSoC] revision: forbid --graph and --no-walk usage
Thanks Junio. Working on v2 for this patch. On Sat, Mar 7, 2015 at 12:00 AM, Junio C Hamano gits...@pobox.com wrote: Akshay Aurora akshayaur...@yahoo.com writes: Signed-off-by: Akshay Aurora akshayaur...@yahoo.com --- This is my first patch for a GSoC Microproject, would be great to have your feedback. revision.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/revision.c b/revision.c index bd027bc..d578652 100644 --- a/revision.c +++ b/revision.c @@ -2248,7 +2248,8 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, struct s */ if (revs-reverse revs-graph) die(cannot combine --reverse with --graph); - + if (revs-no_walk revs-graph) + die(cannot combine --no-walk with --graph); if (revs-reflog_info revs-graph) die(cannot combine --walk-reflogs with --graph); if (!revs-reflog_info revs-grep_filter.use_reflog_filter) Needs a new test to make sure log --no-walk --graph is rejected, and also you need to make sure all other existing tests that used to pass before this change still pass. -- - Akshay Aurora -- 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] Suggest applicants to participate in review of other peoples' patches
On Fri, Mar 06, 2015 at 12:53:57PM +0100, Matthieu Moy wrote: Idea and most of the wording comes from Junio's message on the list. I added a hint to include links to review in the application (which makes the suggestion a bit stronger since it implies that it will be taken into account in the selection). Seems reasonable. I do not know what the quality of reviews will be from applicants, but I guess we will find out. :) -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: Surprising interaction of binary and eol gitattributes
Oops, I misunderstood an internal bug report. In seems that it is the following scenario that is incorrect: *.png text=auto eol=crlf Hm, I don't know if we support this combination at all. The current logic supports auto-detection of text/binary, * text=auto (the files will get the line ending from core.eol or core.autocrlf) or the the setting of a line ending: *.sh eol=lf *.bat eol=crlf Is there a special use-case, which needs the combination of both ? -- 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 merge driver / attributes bug in 2.3.1?
Michael J Gruber g...@drmicha.warpmail.net writes: Gondek, Andreas venit, vidit, dixit 06.03.2015 14:31: The archive contains my test repository, the merge driver and the .gitconfig of the user. We don't have a global .gitconfig. Thanks for the test repo! Alas, the merge driver gets executed with v1.9.0-rc3, v1.8.5 and v1.7.0, at least over here - as it should be because of the conflict: two patches changing the same file. That conflict can be resolved automatically by the internal driver, of course. That matches my expectation. The whole point to have the merge driver plug-in mechanism is to allow overriding the internal textual 3-way file-level merge, so we would have always called out to the custom driver when the tree-level merge machinery says that the content needs a file-level merge [*1*]. [Footnote] *1* This is a tangent, but I've been wondering if we want some cases where the tree-level merge machinery currently says that there is no need for file-level merge to be fed to the merge driver. Specifically, the tree-level merge machinery considers a case where you and the other party changed the files identically to be cleanly merged, but for contents of certain nature, that may not be always desirable. Imagine that I and my wife are sharing a note to record what is in our refrigerator. After I buy a carton of milk, I'd do $ echo 1 carton of milk fridge.txt $ git commit git push and my wife would do the same. $ echo 1 carton of milk fridge.txt $ git commit git push which would not fast-forward, and then she would $ git pull which would result in only one carton of milk in our fridge, even though when both of us got home, we will realize that we now have two of them. -- 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: Interest in contributing to the Git for GSOC 2015
Amate Yolande yolandeam...@gmail.com writes: I would like to work on the Unifying git branch -l, git tag -l, and git for-each-ref project for GSOC 2015 and I hope I can get more directives on how to move on with this project. Hmm, the description on the ideas page looks somewhat sketchy. These three commands are all about selecting a subset of a repository's refs, and then printing the result. However, the implementations are not shared. Some commands know selection options the others do not (e.g., --contains, --merged), and others know formatting options the others do not (e.g., for-each-ref's --format). So, if I were a student to tackle this project, I'd start from: - Reading these three commands to understand how they currently work. For example, when I say git branch -r --no-merged origin/pu, what happens, and how exactly does the codepath that is called by cmd_branch() in builtin/branch.c choose which branch to show by computing what? Can a user customize how they are shown? How does the customization specified by the user and what code actually allows the output to be customized? Do the same for other options git branch takes. What about git tag? git tag --contains origin/maint may be a good starting point to think about, for example. - After doing the above, it would become clear to you that the three have different ways to specify what are chosen to be shown, and they have different ways to show their results. What are the overlaps in them? What is missing from what others that might be beneficial? Do we want git for-each-ref --contains maint refs/heads/ to work, making for-each-ref borrow from tag, for example? Do we want git branch --format='%(refname:short) %(subject)' to work, making branch borrow from for-each-ref, for example? Once we have git branch --format=... support, can we express existing branch -v and branch -v -v output formats in terms of the new facility? What, if anything, needs to be added to the format specifier you can give to the --format option as an argument? - Then write out the design based on the above preliminary study. How you want your new versions of commands to behave can be described by updating their documentation and also by adding tests (that would fail until you actually implement them) that expects the desired behaviour. - And then have fun time to code your design ;-) The second paragraph on the ideas page reads like this: There have been experimental patches to unify the selection process, and some discussion on unifying the formatting. Based on this previous work, factor out a common library which can cleanly handle both selection and formatting, and use it consistently in the three commands. I do not have pointers to these experimental patches offhand. You would want to dig the list archive and/or ask around to find them, which would help doing the second step (i.e. after understanding the current state of these commands, start designing what the unified result should look like). Have fun. -- 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: Bashing freelancers
David Kastrup d...@gnu.org writes: Junio C Hamano gits...@pobox.com writes: David Kastrup d...@gnu.org writes: Good work is worth good money. Suggesting that people who are not able to work for free are morally inferior is not conducive for a cooperative work atmosphere. Yes, but I do not think anybody did any such thing. Of course, I am hoping that all the mentors are doing GSoC not for money but out of love of our software and our community, Huh. I did not intend any moral judgement in that statement, but after re-reading it, I would say that not for money would have been better phrased as not only for money. Let me clarify. There _could_ be a mentor who hates Git the software and Git the community, who wants to mentor students only for the mentorship stipend. I do not want to see such mentors. I would imagine that such a person surely can find something else that is more enjoyable and do the mentoring there for money, if competent enough to mentor others. And that would be good for everybody. -- 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
Is the Git Mailing List dropping messages?
About 10 days ago I sent out this message (just reproducing the relevant headers here): 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 And I got back a reply (again just the relevant headers): From: Junio C Hamano gits...@pobox.com Date: February 24, 2015 11:52:03 PST To: Kyle J. McKay mack...@gmail.com Cc: Git Mailing List git@vger.kernel.org Subject: Re: Any chance for a Git v2.1.5 release? Message-Id: xmqqk2z7qe8s@gitster.dls.corp.google.com Content-Type: text/plain And I responded and that response and the rest of the thread are available on gmane [1], but the first two messages are not. I waited 10 days just to make sure there were no bounce emails or undeliverable notifications coming back and none did. I have checked the other list archives [2] and cannot find the first two messages there either. I have therefore concluded that the git@vger mailing list ate them for a late breakfast snack on 2015-02-24. Has anyone else noticed any problems with their messages to the git@vger list not showing up on the archives? -Kyle [1] http://thread.gmane.org/gmane.comp.version-control.git/264365 [2] https://git.wiki.kernel.org/index.php/ GitCommunity#Mailing_List_Archives P.S. The full text of the two first messages is included below: 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
Re: [PATCH] protocol upload-pack-v2
On Sat, Mar 7, 2015 at 11:28 AM, Stefan Beller sbel...@google.com wrote: + + advertised-refs = (no-refs / list-of-refs) + *shallow + flush-pkt I am not sure if defining shallow as part of refs advertisement is a good idea. The latter lives in the same place in the v1 protocol merely because that was how it was later bolted onto the protocol. But this concern can easily be allayed by retitling advertised-refs to something else. I don't quite understand this. What are your concerns about shallow here? This made me look for explanation about these shallow lines (commit ad49136).They are sent when source repo is a shallow one. They tell the receiver about the bottom the source repo. My experiment with git clone --since shows that such a shallow clone could end up with a few thousand shallow lines. Not as many as refs, but sending shallow lines this way still cost more than necessary. If we want to do that, we need more flexibility that just sending all shallow lines this way. One of the approach is, because these shallow lines (on source repo) rarely change. We could simply exchange SHA-1 of the source repo's shallow file first. The client only requests shallow info when SHA-1 does not match. -- 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
Re: [PATCH] protocol upload-pack-v2
On Fri, Mar 6, 2015 at 4:28 PM, Junio C Hamano gits...@pobox.com wrote: Stefan Beller sbel...@google.com writes: @@ -67,7 +74,6 @@ gracefully with an error message. error-line = PKT-LINE(ERR SP explanation-text) - SSH Transport Noise? @@ -124,9 +130,56 @@ has, the first can 'fetch' from the second. This operation determines what data the server has that the client does not then streams that data down to the client in packfile format. +Capability discovery (v2) +- +In version 1, capability discovery is part of reference discovery and +covered in reference discovery section. + +In version 2, when the client initially connects, the server +immediately sends its capabilities to the client. Then the client must +send the list of server capabilities it wants to use to the server. + + S: 00XXcapabilities 4\n + S: 00XXcap:lang\n + S: 00XXcap:thin-pack\n + S: 00XXcap:ofs-delta\n + S: 00XXagent:agent=git/2:3.4.5+custom-739-gb850f98\n + + C: 00XXcapabilities 3 + C: 00XXcap:thin-pack\n + C: 00XXcap:ofs-delta\n + C: 00XXcap:lang=en\n + C: 00XXagent:agent=git/custom_string\n I do not see a good reason why we want I am sending N caps upfront, instead of this, that, and here is the end of the group. I thought about having an end marker, so something like capabilities start thin-pack lang ofs-delta capabilities done (Each line a pkt-line) Though all decisions I thought through I tried to put more weight on future expandability. Now that I think about it again, it makes no difference, whether to use a counter or an end marker. If you expect the recipient to benefit by being able to pre-allocate N slots, then that might make sense, but otherwise, I'd rather see us stick to a (weaker) flush that says group ends here. I think it's not about pre allocating but counting down. Then you know at the beginning how much to expect which might become relevant if that section grows large again. (The server really wants to send 1500 capability lines? Nope I'll just disconnect because I am on mobile!) Implementation wise an end marker is easier though (you don't need to count down, so it feels more stateless to me). Besides, I do not know how you counted 4 on the S: side and 3 on the C: side in the above example and missing LF after 3 ;-). Sorry about that, I added one answer late and forgot to increment the 3. + + cap = PKT-LINE(capabilities SP size LF list) Isn't a cap packet terminated by LF without any list following it? The notation PKT-LINE(blah) is wrap blah in a single packet, and I do not think you meant to send the capability line and a series of cap:foo entries in a single packet. Yeah I meant to use one packet per line So after considering your input, you'd want to have PKT-LINE(capabilities start) PKT-LINE(no-prefix-for-capabilities) PKT-LINE(ofs-delta) PKT-LINE(agent-as-capability-2.6) PKT-LINE(capabilities end) And additionally to that a PKT-LINE should have the ability to grow larger than 0x, which would be encoded with 0x being an escape character indicating the length is encoded somehow different. (Maybe take the next 8 bytes instead of just 4). + size = *DIGIT + capability-list = *(capability) [agent LF] + capability = cap: keyvaluepair LF + agent= keyvaluepair LF I do not see a reason to make 'agent' as part of capability. That was an implementation detail of v1 but v2 does not have an obligation to consider agent announcement as capability. So I think we don't want to drop the agent announcement as it may reveal useful information (How many outdated clients connect to our $HOSTING_SITE?, I need to debug failures which happen only rarely, Oh! it can be narrowed down to clients with agent xyz.) So then we need to decide where to put the agent. And as it is only small but useful (meta?)-information I'd rather put it at the beginning of the data exchange, so in case the other side seems to be missbehaving, it is easier to debug in the hope the agent transmission was still successful. server-announcement = PKT-LINE(capabilities ...) capability-list [agent-announcement] capability-list = as you have it w/o [agent LF] agent-announcement = PKT-LINE(agent= agent-token LF) or something, perhaps? This looks like me as if all capabilities are in one PKT-LINE, which you seemed to oppose? +The client MUST ignore any data before the pkt-line starting with capabilities +for future easy of extension. s/easy/ease/; but I am not sure if this makes sense. Without knowing the extended preamble, you cannot even tell if a packet line that happens to start with capabilities is a proper beginning of 0-th iteration of v2 protocol, or an embedded data in the preamble, no? I rather thought about the case where the implementation would just close the connection on sight of unknown preamble. If we want to extend the
Promoting Git developers (was: Bashing freelancers)
Hi, On Fri, Mar 6, 2015 at 6:41 PM, David Kastrup d...@gnu.org wrote: At some point of time I think it may be worth reevaluating the toxic atmosphere against freelancers doing Git development. My opinion on this is that the Git community has not been good especially lately at promoting its own developers. Some facts: * There used to be an AUTHORS section in each of the git man page. They have been removed. The rational was that they were hard to maintain and the information about authors was easily available elsewhere. * There used to be a nice page on git-scm.com, the main Git web site, listing the authors and how many commits they had contributed. It has been removed. * In the A note from the maintainer emails that Junio regularly sends, the last section about Other people's trees, trusted lieutenants and credits. seems to have been truncated for some time and doesn't show anymore the nice credits words it used to show. Maybe this is a bug. * https://www.openhub.net/p/git/contributors/summary seems to give me a 504 Gateway Time-out right now :-( * On the Git Merge web site, we can see that none of the speakers seems to have been a very active contributor to git.git None of these facts is a big issue in itself for me, but I think the trend is very sad, and I would be happy if we could discuss here or at the Git Merge (or both) about ways to improve in this area. Best, 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
[PATCH v2/GSoC/MICRO] revision: forbid combining --graph and --no-walk
Because --graph is about connected history while
--no-walk is about discrete points. [1]
It's a pity that git-show has to allow such combination
in order to make t4052-stat-output.sh compatible. [2]
2 testcases have been added to test this patch.
[1]: http://article.gmane.org/gmane.comp.version-control.git/216083
[2]: http://article.gmane.org/gmane.comp.version-control.git/264950
Signed-off-by: Dongcan Jiang dongcan.ji...@gmail.com
Thanks-to: Eric Sunshine, René Scharfe, Junio C Hamano
---
Documentation/rev-list-options.txt | 2 ++
builtin/log.c | 1 +
revision.c | 4
revision.h | 3 +++
t/t4202-log.sh | 6 ++
t/t6014-rev-list-all.sh| 6 ++
6 files changed, 22 insertions(+)
diff --git a/Documentation/rev-list-options.txt
b/Documentation/rev-list-options.txt
index 4ed8587..136abdf 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -679,6 +679,7 @@ endif::git-rev-list[]
given on the command line. Otherwise (if `sorted` or no argument
was given), the commits are shown in reverse chronological order
by commit time.
+ Cannot be combined with `--graph`.
--do-walk::
Overrides a previous `--no-walk`.
@@ -781,6 +782,7 @@ you would get an output like this:
on the left hand side of the output. This may cause extra lines
to be printed in between commits, in order for the graph history
to be drawn properly.
+ Cannot be combined with `--no-walk`.
+
This enables parent rewriting, see 'History Simplification' below.
+
diff --git a/builtin/log.c b/builtin/log.c
index dd8f3fc..5b5d028 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -524,6 +524,7 @@ int cmd_show(int argc, const char **argv, const char
*prefix)
memset(match_all, 0, sizeof(match_all));
init_revisions(rev, prefix);
+ rev.cmd_is_show = 1;
rev.diff = 1;
rev.always_show_header = 1;
rev.no_walk = REVISION_WALK_NO_WALK_SORTED;
diff --git a/revision.c b/revision.c
index 66520c6..5d6fbef 100644
--- a/revision.c
+++ b/revision.c
@@ -1399,6 +1399,8 @@ void init_revisions(struct rev_info *revs, const char
*prefix)
revs-commit_format = CMIT_FMT_DEFAULT;
+ revs-cmd_is_show = 0;
+
init_grep_defaults();
grep_init(revs-grep_filter, prefix);
revs-grep_filter.status_only = 1;
@@ -2339,6 +2341,8 @@ int setup_revisions(int argc, const char **argv, struct
rev_info *revs, struct s
if (revs-reflog_info revs-graph)
die(cannot combine --walk-reflogs with --graph);
+ if (!revs-cmd_is_show revs-no_walk revs-graph)
+ die(cannot combine --no-walk with --graph);
if (!revs-reflog_info revs-grep_filter.use_reflog_filter)
die(cannot use --grep-reflog without --walk-reflogs);
diff --git a/revision.h b/revision.h
index 0ea8b4e..378c3bf 100644
--- a/revision.h
+++ b/revision.h
@@ -146,6 +146,9 @@ struct rev_info {
track_first_time:1,
linear:1;
+ /* cmd type */
+ unsigned int cmd_is_show:1;
+
enum date_mode date_mode;
unsigned intabbrev;
diff --git a/t/t4202-log.sh b/t/t4202-log.sh
index 5f2b290..fed162e 100755
--- a/t/t4202-log.sh
+++ b/t/t4202-log.sh
@@ -887,4 +887,10 @@ test_expect_success GPG 'log --graph --show-signature for
merged tag' '
grep ^| | gpg: Good signature actual
'
+test_expect_success 'log --graph --no-walk is forbidden' '
+ echo fatal: cannot combine --no-walk with --graph expect-error
+ test_must_fail git log --graph --no-walk 2error
+ test_cmp expect-error error
+'
+
test_done
diff --git a/t/t6014-rev-list-all.sh b/t/t6014-rev-list-all.sh
index 991ab4a..574e8d9 100755
--- a/t/t6014-rev-list-all.sh
+++ b/t/t6014-rev-list-all.sh
@@ -35,4 +35,10 @@ test_expect_success 'repack does not lose detached HEAD' '
'
+test_expect_success 'rev-list --graph --no-walk is forbidden' '
+ echo fatal: cannot combine --no-walk with --graph expect-error
+ test_must_fail git rev-list --graph --no-walk 2error
+ test_cmp expect-error error
+'
+
test_done
--
2.3.1.253.g3de5837
--
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
[GSoC/RFC] Ideas on git fetch --deepen
Hi all, My name is Dongcan Jiang. I am studying for my Master Degree at Peking University majoring in Computer Science. I have been using Git to manage my projects for about half a year. It's really exciting that Git has been helping me make revision control much more convenient. Therefore, I am very interested in doing some works for Git in GSoC 2015. I have submitted my v2 patch on a microproject recently, and I am waiting for comments on v2 now. In the meantime, I have been scanning ideas on the git gsoc page and their related mails. I find that I am interested in most of them, especially git fetch --deepen idea. Here is my understanding about this idea. Although deepen and depth have different behavior, deepen can be achieved by depth with some extra calculation. If we know the distance between my history bottom and your tips, we can set the sum of deepen step and this distance as depth step. Then we can reuse the logics of processing depth to complete it. Take graph in [1] as an example. (upstream) ---o---o---o---A---B (you) A---B the distance of my history bottom(A) and your tips(B) is 1, then git fetch --deepen=3 can be achieved by git fetch --depth=4 However, I am a little worried about whether this idea is enough for a GSoC project. I hope you can give me some comments and suggestions. [1] http://article.gmane.org/gmane.comp.version-control.git/212950 Thanks, Dongcan -- 江东灿（Dongcan Jiang） Team of Search Engine Web Mining School of Electronic Engineering Computer Science Peking University, Beijing, 100871, P.R.China -- 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] xmerge.c: fix xdl_merge to conform with the manual
On 04/03/15 23:01, Junio C Hamano wrote: [] My apologies for pushing this topic, but what would you recommend? Should we treat both sides line-wise or should we correct the documentation? Current version for git help merge: ... ignore-space-change, ignore-all-space, ignore-space-at-eol Treats lines with the indicated type of whitespace change as unchanged for the sake of a three-way merge. Whitespace changes mixed with other changes to a line are not ignored. See also git-diff(1)-b, -w, and --ignore-space-at-eol. o If their version only introduces whitespace changes to a line, our version is used; o If our version introduces whitespace changes but their version includes a substantial change, their version is used; o Otherwise, the merge proceeds in the usual way. ... The 1st bullet point could be changed into o If their version only introduces whitespace changes to *all changed lines*, our version is used; And the 2nd one into: o If our version only introduces whitespace changes to all changed lines, but their version includes at least one substantially changed line, all lines from their version are used; -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GSoC microproject] Add XDG support to the credential-store helper
Hi Luis, On Fri, Mar 6, 2015 at 7:41 AM, Luis Ressel ara...@aixah.de wrote: Okay, I've had a look at Paul's patch for this. Sorry again for the dupe, I must've missed it before. I guess I'll attempt another microproject. However, I feel like my patch is really all that's neccessary; I don't think we should try to use both files if they exist -- I consider Paul's approach to be a bit overcomplicated. My patch still uses ~/.git-credentials as a default location, which should be sufficient for compability. Indeed, that was my initial plan for implementation as well[1]. Matthieu, however, wanted the behavior to follow that of git-config[2]. [1] http://article.gmane.org/gmane.comp.version-control.git/264666 [2] http://article.gmane.org/gmane.comp.version-control.git/264669 A user that wants to use ~/.config/git/credentials instead has to manually create that file first, which he just shouldn't do if he has to stay compatible to previous git versions. Yes, I totally agree. I wonder if the current behavior to read the home config file in addition to the xdg config file is actually useful to the end-user. (However, that behavior has been in git since 2012, so for consistency purposes it may not be desirable to make credential-store act differently from git-config.) What I do believe, however, is that there *should* be a way for credential-store to lookup, erase and (maybe) store credentials to multiple files. This opens the door for git to be fully xdg base dir spec compliant by supporing both $XDG_CONFIG_HOME and $XDG_CONFIG_DIRS. I quote from the spec[3]: The order of base directories denotes their importance; the first directory listed is the most important. When the same information is defined in multiple places the information defined relative to the more important base directory takes precedent. The base directory defined by $XDG_DATA_HOME is considered more important than any of the base directories defined by $XDG_DATA_DIRS. The base directory defined by $XDG_CONFIG_HOME is considered more important than any of the base directories defined by $XDG_CONFIG_DIRS. [3] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html Reading from multiple credential stores could be useful, for example, if the system administrator wanted to setup credentials for all users on the system. Thus, if we are implementing the machinery for the XDG dir spec, it would make sense to just add the home git-credentials file to the search path as well. Regards, Paul -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][GSoC] revision: forbid --graph and --no-walk usage
On Fri, Mar 6, 2015 at 7:08 AM, Akshay Aurora akshayaur...@yahoo.com wrote: Not sure, why this mail is not showing on Gmane. I used git to send the email, and tested it by sending the patch to myself before sending it to the list. Gmail knows: Why is this message in Spam? It has a from address in yahoo.com but has failed yahoo.com's required tests for authentication. Learn more Probably filtering settings are less strict. I guess you should use authenticated SMTP thought your email hoster, yahoo here in git-send-email (something like --smtp-server and --smtp-user options, it will ask for password interactively) to avoid 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] git: make git -C '' cmd not to barf
On Fri, Mar 6, 2015 at 2:05 AM, Karthik Nayak karthik@gmail.com wrote:
It now acts like cd '' and does not barf and treats
it as a no-op.
What does barf mean in this context? Does the program crash? Spit
out nonsensical messages? Misbehave in some fashion? A good commit
message should explain the problem with sufficient detail so readers
don't need to guess what the bad behavior is.
This is useful if a caller function
does not want to change directory and hence gives no
path value, which would have generally caused git to
output an undesired error message.
This is an odd justification. A caller not wanting to change the
directory wouldn't pass -C in the first place. A better justification
might be that die()ing is unnecessarily harsh behavior for what
otherwise could be considered a no-op, citing cd '' as an example.
Also, write in imperative mood, as if you're instructing the code to
change itself.
Taking the above observations into consideration, you might say:
git: treat `-C path' as a no-op when path is empty
`git -C ' unhelpfully dies with error Cannot change to '',
whereas the shell treats `cd ' as a no-op. Taking the shell's
behavior as a precedent, teach git to treat `-C ' as a no-op, as
well.
Included a simple test to check the same, as suggested
by Junio.
It is a bit weak to say that Junio suggested the test, considering
that he actually wrote it[1].
Signed-off-by: Karthik Nayak karthik@gmail.com
---
diff --git a/git.c b/git.c
index 8c7ee9c..d734afa 100644
--- a/git.c
+++ b/git.c
@@ -204,10 +204,14 @@ static int handle_options(const char ***argv, int
*argc, int *envchanged)
fprintf(stderr, No directory given for
-C.\n );
usage(git_usage_string);
}
- if (chdir((*argv)[1]))
- die_errno(Cannot change to '%s',
(*argv)[1]);
- if (envchanged)
- *envchanged = 1;
+ if (*((*argv)[1]) == 0)
Saying '\0' rather than 0 would make the intent clearer.
+ ; /* DO not change directory if no directory
is given*/
+ else {
+ if (chdir((*argv)[1]))
+ die_errno(Cannot change to '%s',
(*argv)[1]);
+ if (envchanged)
+ *envchanged = 1;
+ }
The 'if/else' statement you've composed (with an empty 'if' branch) is
unnecessarily complicated when a simple 'if' suffices:
if (*(*argv)[1]) {
if (chdir((*argv)[1]))
die_errno(Cannot change to '%s', (*argv)[1]);
if (envchanged)
*envchanged = 1;
}
(*argv)++;
(*argc)--;
} else {
diff --git a/t/t0056-git-C.sh b/t/t0056-git-C.sh
index 99c0377..a6b52f1 100755
--- a/t/t0056-git-C.sh
+++ b/t/t0056-git-C.sh
@@ -14,6 +14,14 @@ test_expect_success 'git -C path runs git from the
directory path' '
test_cmp expected actual
'
+test_expect_success 'git -C path with an empty path is a no-op' '
+ mkdir -p dir1/subdir
+ cd dir1/subdir
When Junio composed this test[1], he intentionally wrapped it in a
subshell via '(' and ')'. The problem with dropping the subshell, as
you did here, is that the 'cd' in this test will still be in effect
when tests following this one are run, which typically will break
them. Wrapping the test in a subshell side-steps the problem because
the parent shell is not affected by 'cd' within the subshell. To
summarize: Don't remove the subshell from Junio's example.
(You lucked out in this case, by accident, since the following tests
are not impacted by such ill-behavior.)
+ git -C rev-parse --show-prefix actual
+ echo subdir/ expect
Broken -chain.
+ test_cmp expect actual
+'
+
test_expect_success 'Multiple -C options: -C dir1 -C dir2 is equivalent to
-C dir1/dir2' '
test_create_repo dir1/dir2
echo 1 dir1/dir2/b.txt
--
2.3.1.167.g7f4ba4b.dirty
[1]: http://article.gmane.org/gmane.comp.version-control.git/264871
--
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: Bashing freelancers
Junio C Hamano gits...@pobox.com writes: David Kastrup d...@gnu.org writes: Junio C Hamano gits...@pobox.com writes: David Kastrup d...@gnu.org writes: Good work is worth good money. Suggesting that people who are not able to work for free are morally inferior is not conducive for a cooperative work atmosphere. Yes, but I do not think anybody did any such thing. Of course, I am hoping that all the mentors are doing GSoC not for money but out of love of our software and our community, Huh. I did not intend any moral judgement in that statement, but after re-reading it, I would say that not for money would have been better phrased as not only for money. Let me clarify. There _could_ be a mentor who hates Git the software and Git the community, who wants to mentor students only for the mentorship stipend. Uh, mentors don't rise from beneath the Earth. They are project members. Do you want to suggest that you suspect those contributors to have worked on Git, which they hate with a vengeance, only so that they could cash in on GSoC? You know the kind of sum we are talking about here, right? Pocketing that makes sense only if you feel _indifferent_ about anything but money and are not planning on investing significant amount of work. It's too little to do something you actually hate. I do not want to see such mentors. I would imagine that such a person surely can find something else that is more enjoyable and do the mentoring there for money, if competent enough to mentor others. And that would be good for everybody. I think Google would prefer a mentor who takes the money and does the job to someone who hands the money on to some more generic Git account out of love for the project and community and does not find the time for actually mentoring his student, but feels sort of ok about it because he did not in the end take the money. Someone who hates Git will at least have a solid idea about where Git is most in need of improvement... No, I'm not volunteering. I am merely sick of the income-bashing and consider it not doing a useful job for Git or other free software. Particularly not in connection with a program like Google Summer of Code which is _designed_ to let money make a difference. -- David Kastrup -- 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] send-email: Add CCs from additional commit tags
Add email addresses from additional commonly used tags to the CC-list of
patches. Additional tags are:
- Acked-by
- Reviewed-by
- Tested-by
- Reported-by
- Reviewed-and-tested-by
--suppress-cc=ack suppresses these additional CCs.
Signed-off-by: Soren Brinkmann soren.brinkm...@xilinx.com
---
Documentation/git-send-email.txt | 3 +++
git-send-email.perl | 5 +++--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index f248a8665e1f..1b521446ca11 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -293,6 +293,9 @@ Automating
patch body (commit message) except for self (use 'self' for that).
- 'sob' will avoid including anyone mentioned in Signed-off-by lines except
for self (use 'self' for that).
+- 'ack' will avoid including anyone who acked the patch (mentioned in
+ Acked-by, Reviewed-by, Tested-by, Reviewed-and-tested-by lines except for
+ self (use 'self' for that).
- 'cccmd' will avoid running the --cc-cmd.
- 'body' is equivalent to 'sob' + 'bodycc'
- 'all' will suppress all auto cc values.
diff --git a/git-send-email.perl b/git-send-email.perl
index 3092ab356c76..18eb8a5139a4 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -407,7 +407,7 @@ my(%suppress_cc);
if (@suppress_cc) {
foreach my $entry (@suppress_cc) {
die Unknown --suppress-cc field: '$entry'\n
- unless $entry =~
/^(?:all|cccmd|cc|author|self|sob|body|bodycc)$/;
+ unless $entry =~
/^(?:all|cccmd|cc|author|self|sob|body|bodycc|ack)$/;
$suppress_cc{$entry} = 1;
}
}
@@ -1452,7 +1452,7 @@ foreach my $t (@files) {
# Now parse the message body
while($fh) {
$message .= $_;
- if (/^(Signed-off-by|Cc): (.*)$/i) {
+ if
(/^(Signed-off-by|Cc|Acked-by|Reviewed-by|Tested-by|Reported-by|Reviewed-and-tested-by):
(.*)$/i) {
chomp;
my ($what, $c) = ($1, $2);
chomp $c;
@@ -1462,6 +1462,7 @@ foreach my $t (@files) {
} else {
next if $suppress_cc{'sob'} and $what =~
/Signed-off-by/i;
next if $suppress_cc{'bodycc'} and $what =~
/Cc/i;
+ next if $suppress_cc{'ack'} and $what =~
/(Acked-by|Reviewed-by|Tested-by|Reported-by|Reviewed-and-tested-by)/i;
}
push @cc, $c;
printf((body) Adding cc: %s from line '%s'\n,
--
2.3.1.2.g90df61e.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
