Re: [RFH] GSoC 2015 application
Johannes Schindelin johannes.schinde...@gmx.de writes: Also drop proper as if scripted Porcelains are second class citizens ;-) If you had to deal with the portability/performance issues of the shell scripts I am frequently faced with, you would not call them first class citizens, either. Perhaps that might be the case. But I am polite enough to refrain from calling that not a problem on 'proper' platforms. I expect the same courtesy from others ;-). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails
On Feb 19, 2015, at 3:35 PM, brian m. carlson sand...@crustytoothpaste.net wrote: On Wed, Feb 18, 2015 at 04:17:46PM +, Dan Langille (dalangil) wrote: I just built from ‘master’, on FreeBSD 9.3: cd ~/src git clone https://github.com/git/git.git cd git gmake Then tried ~/src/git/git clone https://OUR_REPO It cores too, and I see: git-remote-https.core Can you compile with debugging symbols and provide a backtrace? I'm not seeing any such behavior on my end, and I'm not sure whether it's my patch or something else that might be present in master. The problem originally occurred under VMware Fusion and I’m unable to get a backtrace from it. I suspect memory constraints are a factor. There’s only 5GB RAM available to this VM. I have tried in another VM and that succeeds. All good there. It has 40GB RAM. I am going to try this on a third system. At present, we’re just 50/50 on success. — Dan Langille Infrastructure Operations Talos Group Sourcefire, Inc.
Re: [msysGit] Re: [RFH] GSoC 2015 application
Hi Junio, On 2015-02-24 19:25, Junio C Hamano wrote: On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: About the proposal: The idea of this project is to dive into the Git source code and convert, say, git-add--interactive.perl and/or git stash into proper C code, making it a so-called built-in. My advice would be to try converting several small scripts, and avoid targetting a big one add--interactive and stash are relatively complex beasts, perhaps git-pull.sh would be easier to start with. Yeah, I think that is a very good suggestion. Well, git-pull.sh is really small. I did not want to give the impression that the Git project is giving out freebies. But I have no objection to change it if you open that PR. Also drop proper as if scripted Porcelains are second class citizens ;-) If you had to deal with the portability/performance issues of the shell scripts I am frequently faced with, you would not call them first class citizens, either. Ciao, Dscho -- 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
Import git log into a spreadsheet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm trying to import a git log into a spreadsheet. I used a simple - --pretty=format: switch to select the fields I wanted and separate them with commas to generate a CSV file that can be imported. The message body, however, is presenting a problem. The first problem is that it contains newlines itself, which normally signal the start of a new record. It turns out that even when quoting the field, MS Excel still fails to import it properly ( good grief MS ), but openoffice calc does. The second problem is that the body itself may contain quotes. I can't figure out a good way to deal with these quotes. It seems that replacing them with a pair of quotes should make the CSV valid, but how can I replace only those quotes internal to the field without replacing the quotes that actually bracket it? Is it possible to have git log use a NULL terminator between records instead of a new line? Or is there a better way of going about this? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJU7NmpAAoJENRVrw2cjl5RWFEH/Re8o38zp+EqQxrOM7ZfypUy Ebaqf8Sa3dIs57iJINnNNsy6kTyPGCxPphdI5zbN5DVuduYKldZSMIeQ1S3sysRq SPH+E0KL1yxWEv8A0s5CKN/THvPHoUMpl0D7850LBrEmfQzyYNBE4NRBLHSPUL2w pbAaDeQQwmTigwF6J1AYdz3FlZZznVGzR6ST/Tios64G33wePzPOulF8QyXjpQJq R1QNRc9EmMz+FC1X/BwrPMX0e8YeTipjW+X/s6uMUXB6F9cln0VcNR5QOhDO1JDp avbdSwl7nQWRX244cKPfX+eujBgC8RnyrLyz74vSsn1vO8BHtSrLMQ5+1Lbymjo= =MTpF -END PGP SIGNATURE- -- 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] clone: add disassociate alias to dissociate option
Michael Haggerty mhag...@alum.mit.edu writes: On 02/22/2015 07:32 PM, Junio C Hamano wrote: ... Both borrow the objects in order to reduce the network cost, and the difference is that one keeps borrowing while the other one limits the borrowing to strictly the initial phase. The two words, borrow and reference, would not convey that key distinction. ... and that is why I call it a cop-out. ... We are all on the same page. We know the cop-out is suboptimal, we understand why the cop-out is better than --borrow, and we cannot come up with a better name that contrasts with the existing --reference to make it clear how the new thing is different. I'll take that as an invitation to brainstorm :-) --use-objects-from= --copy-objects-from= --precopy-objects-from= --precopy-from= --donor= --object-donor= --steal-from= --steal-objects-from= Of these, I think I like --object-donor the best. Donor (somehow the word reminds me of organ harvesting, yuck)? I didn't think of the word 'copy', but that probably captures the essence the best. reference-to-borrow-and-then-dissociate is an implementation detail, which, as you say, we do not want the users to view this operation as; copying locally instead of over the network is what the user wants to do. By the way, once we have stopped thinking about this feature as --reference and then --dissociate, it becomes obvious that a nice generalization would be to allow *any* repository (including remote ones) to serve as the object donor. As I do not think of a workable approach to implement such a mechanism, I'd refrain from being irresponsible and say Yeah, that's a neat idea, which would make me sound like clueless me too, why doesn't Git do that? crowd. -- 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: Internationalization and yes/no prompts
Pierre-Olivier Vares pierre-olivier.va...@fingerprint.fr writes: /Supprimer //premier_fichier ? [Remove first_file ?]/ Natural answer to this question is 'Oui' [Yes], so I type 'o', rather than 'y'. Once finished, I see no file has been removed (since 'o' has been considered as 'different than yes') Whereas it's not an end-of-the-world thing*, it's annoying as at first sight I didn't understand why it has 'not worked'. I thought of a few possibilities (some easy to implement, others more complex; some are stricter for the user) : - explicitly put y/n in the message. Translaters should be warned to let y/n, This may be suboptimal from the end-user's point of view, but it is the least risky of breaking anything. And it is way better than the status quo. - only allow y and n answers (and variants : yes, no), and reject everything else with a message This is not helpful to the users if it does not say why (O)ui was rejected, which would mean we would be better off saying [Y/n] in the message in the first place. - use as 'n', but echoes a message : 'Answer considered as /no/' Unhelpful without stating why (O)ui was considered as 'no'; same conclusion as above. - accept answers depending on the language used to echo the prompt (y/n for english, o/n for french, j/n for german, ...) This would be the best for languages where translations for Yes and No begin with different letters, but I suspect it might be tricky to implement. -- 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
assistance with git error
Could someone provide me some assistance with troubleshooting the following: remote: Counting objects: 31654, done. error: pack-objects died of signal 99568/19585) error: git upload-pack: git-pack-objects died with error. fatal: git upload-pack: aborting due to possible repository corruption on the remote side. remote: aborting due to possible repository corruption on the remote side. fatal: early EOF fatal: index-pack failed i know next to nothing about git and was asked to resolve this issue. thank you. tom -- 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: assistance with git error
On Tue, Feb 24, 2015 at 08:40:56PM +, Tom wrote: Could someone provide me some assistance with troubleshooting the following: remote: Counting objects: 31654, done. error: pack-objects died of signal 99568/19585) The output is smushed here due to the use of \r for the progress reporting, but the interesting message is: error: pack-objects died of signal 9 which probably overwrote something like: remote: Compressing objects: XXX% (9568/19585) The rest of the messages are just the error propagating through the various programs on the remote and local sides. So something killed pack-objects with signal 9 (SIGKILL). Just a guess, but it may have been killed for using too much memory. Do you have control of the server? Is it running Linux? If so, check your system logs to see if the OOM-killer killed it. If the server is multi-core, setting: git config pack.threads 1 in the repository in question may reduce the peak memory usage. -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
[BUG] diffcore-rename with duplicate tree entries can segfault
I ran across a real-world case where git segfaults on some trees that
have duplicate entries. Those trees are obviously broken, and I'm fine
with us producing whatever output we like on them. But probably we
shouldn't segfault.
Basically what happens is that the rename_dst array maps paths to
diff_filepairs. When we process the results of the rename, if we have
duplicates we may hit that same pathname multiple times, and pull out
the same diff_filepair. So we end up with a diff_queue that has the same
filepair mentioned multiple times. When it comes time to flush and free
that queue, we do a double (or triple) free of the filepair and its
contents, which corrupts the heap.
I managed to reduce it to a simplified test case:
diff --git a/t/t4058-diff-duplicates.sh b/t/t4058-diff-duplicates.sh
new file mode 100755
index 000..9e03490
--- /dev/null
+++ b/t/t4058-diff-duplicates.sh
@@ -0,0 +1,85 @@
+#!/bin/sh
+
+test_description='test tree diff when trees have duplicate entries'
+. ./test-lib.sh
+
+# make_tree_entry mode mode sha1
+#
+# We have to rely on perl here because not all printfs understand
+# hex escapes (only octal), and xxd is not portable.
+make_tree_entry () {
+ printf '%s %s\0' $1 $2
+ perl -e 'print chr(hex($_)) for ($ARGV[0] =~ /../g)' $3
+}
+
+# Like git-mktree, but without all of the pesky sanity checking.
+# Arguments come in groups of three, each group specifying a single
+# tree entry (see make_tree_entry above).
+make_tree () {
+ while test $# -gt 2; do
+ make_tree_entry $1 $2 $3
+ shift; shift; shift
+ done |
+ git hash-object -w -t tree --stdin
+}
+
+# this is kind of a convoluted setup, but matches
+# a real-world case. Each tree contains four entries
+# for the given path, one with one sha1, and three with
+# the other. The first tree has them split across
+# two subtrees (which are themselves duplicate entries in
+# the root tree), and the second has them all in a single subtree.
+test_expect_success 'create trees with duplicate entries' '
+ blob_one=$(echo one | git hash-object -w --stdin)
+ blob_two=$(echo two | git hash-object -w --stdin)
+ inner_one_a=$(make_tree \
+ 100644 inner $blob_one
+ )
+ inner_one_b=$(make_tree \
+ 100644 inner $blob_two \
+ 100644 inner $blob_two \
+ 100644 inner $blob_two
+ )
+ outer_one=$(make_tree \
+ 04 outer $inner_one_a \
+ 04 outer $inner_one_b
+ )
+ inner_two=$(make_tree \
+ 100644 inner $blob_one \
+ 100644 inner $blob_two \
+ 100644 inner $blob_two \
+ 100644 inner $blob_two
+ )
+ outer_two=$(make_tree \
+ 04 outer $inner_two
+ )
+ git tag one $outer_one
+ git tag two $outer_two
+'
+
+test_expect_success 'diff-tree between trees' '
+ {
+ printf :00 100644 $_z40 $blob_two A\touter/inner\n
+ printf :00 100644 $_z40 $blob_two A\touter/inner\n
+ printf :00 100644 $_z40 $blob_two A\touter/inner\n
+ printf :100644 00 $blob_two $_z40 D\touter/inner\n
+ printf :100644 00 $blob_two $_z40 D\touter/inner\n
+ printf :100644 00 $blob_two $_z40 D\touter/inner\n
+ } expect
+ git diff-tree -r --no-abbrev one two actual
+ test_cmp expect actual
+'
+
+test_expect_success 'diff-tree with renames' '
+ {
+ printf :100644 100644 $blob_two $blob_two M\touter/inner\n
+ printf :00 100644 $_z40 $blob_two A\touter/inner\n
+ printf :00 100644 $_z40 $blob_two A\touter/inner\n
+ printf :100644 00 $blob_two $_z40 D\touter/inner\n
+ printf :100644 00 $blob_two $_z40 D\touter/inner\n
+ } expect
+ git diff-tree -M -r --no-abbrev one two actual
+ test_cmp expect actual
+'
+
+test_done
The diff-tree outputs are up for debate. Possibly we should not even be
checking the output at all, and just making sure we don't segfault. The
first one is produced with stock git, and kind-of makes sense (we don't
link up the obviously matching paths in the tree diff because they come
from two different subtrees). Of course with -p it cannot be applied,
but it is at least somewhat informative to the user.
The second one is what is produced by the patch below. It also kind of
makes sense (we link up one pair, but the others are left out of the
rename detection). Though I would have expected the `M` in the first
line to be an `R100`.
My idea for a fix was to make sure we didn't pull the same entry out of
locate_rename_dst multiple times:
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 4e132f1..7030502 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -12,6 +12,7 @@
static struct diff_rename_dst {
Re: Import git log into a spreadsheet
Phillip Susi ps...@ubuntu.com writes: I'm trying to import a git log into a spreadsheet. I used a simple --pretty=format: switch to select the fields I wanted and separate them with commas to generate a CSV file that can be imported. The message body, however, is presenting a problem. The first problem is that it contains newlines itself, which normally signal the start of a new record. It turns out that even when quoting the field, MS Excel still fails to import it properly ( good grief MS ), but openoffice calc does. The second problem is that the body itself may contain quotes. I can't figure out a good way to deal with these quotes. It seems that replacing them with a pair of quotes should make the CSV valid, but how can I replace only those quotes internal to the field without replacing the quotes that actually bracket it? Is it possible to have git log use a NULL terminator between records instead of a new line? Or is there a better way of going about this? I think --pretty=format: (or --format) gives you a way to specify the literal NUL. Also perhaps look at the -z option? -- 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: Copyright on wildmatch.c
On Tue, Feb 24, 2015 at 3:08 PM, Guilherme guibuf...@gmail.com wrote: Hello, I have already posted this to the users mailing list but i guess it's more appropriate to have it here. Related thread about relicensing wildmatch.c for tss http://thread.gmane.org/gmane.comp.version-control.git/259764/focus=259798 -- Forwarded message -- From: Guilherme guibuf...@gmail.com Date: Tue, Feb 24, 2015 at 9:02 AM Subject: Copyright on wildmatch.c To: git-us...@googlegroups.com git-us...@googlegroups.com Hello, I'm trying to implement support for gitignore files in the_silver_searcher (https://github.com/ggreer/the_silver_searcher). It is a source code optimized version of grep. And it is way faster than ack. The problems at hand is that I'd like to use wildmatch.c and some dependencies (hex.c, some portions of compat-util.h) but it seems that git is GPL whereas tss is Apache2 licensed. Is there any possibility to re-license the files above to Apache2 for the TSS project? If not, is there any c library that provides support gitignore patterns? Thank you very much, Bufolo -- 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 -- 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 1/2] clone: add disassociate alias to dissociate option
On 02/22/2015 07:32 PM, Junio C Hamano wrote: Jeff King p...@peff.net writes: I wonder if there is some better word that could become a synonym for --reference --dissociate. Maybe --borrow, but that does not necessarily carry the implication that the relationship ends as soon as the clone is done. You are retracing the exact line of the thinking that led me to a cop-out that is a separate --dissociate. The original idea was to give --borrow /local/repository/path, but that would have made it unclear what the differences between that new option and existing --reference were. Both borrow the objects in order to reduce the network cost, and the difference is that one keeps borrowing while the other one limits the borrowing to strictly the initial phase. The two words, borrow and reference, would not convey that key distinction. Do the reference thing (which is well understood from old days, even before v1.6.0) and then severe the ties was suboptimal but was easy to explain, and that is why I call it a cop-out. What is really happening is that we are reusing objects in order to save bandwidth. Maybe --reuse-from would work? I dunno. I am not extremely happy with any of the suggestions I made,... I dunno, either. We are all on the same page. We know the cop-out is suboptimal, we understand why the cop-out is better than --borrow, and we cannot come up with a better name that contrasts with the existing --reference to make it clear how the new thing is different. I'll take that as an invitation to brainstorm :-) --use-objects-from= --copy-objects-from= --precopy-objects-from= --precopy-from= --donor= --object-donor= --steal-from= --steal-objects-from= Of these, I think I like --object-donor the best. By the way, once we have stopped thinking about this feature as --reference and then --dissociate, it becomes obvious that a nice generalization would be to allow *any* repository (including remote ones) to serve as the object donor. This would allow users to get most of their objects from a nearby repository (e.g., a mirror on the LAN) and then top off from a more distant authoritative repository. In fact, this donor/recipient relationship could be made persistent: before fetching from repository A, always first fetch any objects that repository B has available. OTOH, making the relationship persistent would presumably require us to retain remote-tracking references for repository B even though they are not intrinsically interesting to the user, and would lead to reference namespace conflicts if the user wants a --mirror clone. 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: Question on shallow clones.
On Fri, Feb 20, 2015 at 9:13 PM, Alfred Perlstein bri...@mu.org wrote: Hello, Very sorry if this has been explained before, I have been doing research past few weeks in spare time and have not found a good answer yet on the safety of doing something with git. Basically we have some repos with huge history, namely FreeBSD source and FreeBSD ports. In order to reduce the space in $repo/.git as well as speed up clone time we were thinking of doing a shallow clone of the repo with something like --depth 5000. I am wondering, if we such a thing, basically: # get a shallow mirror of let's say 5000 entries git clone --depth 5000 --mirror our-freebsd.git smaller-freebsd.git # move our current repo to a backup mv our-freebsd.git our-freebsd.git.backup # make shallow repo our primary mv smaller-freebsd.git our-freebsd.git Will we be able to push/pull from our new repo as if nothing happened? Will hashes remain the same? Yes (except the following) and yes if you use git 1.9.0 or later on both client and server sides. The support in 1.9.0 targets this exact use case (among others). - Pushes that require updating $GIT_DIR/shallow (i.e. change the history cut points, perhaps adding more of them) on server are rejected by default, unless you set receive.shallowupdate. Normal pushes should go through fine though. - Because of the shortened history, found merge bases could be less ideal than from a full clone. This may cause some more merge conflicts. Can we in theory later do this: # merge branches from the github remote and push back to our-freebsd.git git clone /url/our-freebsd.git our-freebsd.git cd our-freebsd.git git remote add github https://github.com/freebsd/freebsd.git git fetch github # get from our-freebsd git checkout -b master origin/master # now merge in freebsd changes git merge --no-ff github/master git push origin HEAD Or will this break terribly? I'm not sure which repo is shallow, which is full (or both are shallow?), Regardless, I don't see problems with this. If it breaks, it's a bug. -- 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: Copyright on wildmatch.c
On Tue, Feb 24, 2015 at 4:29 PM, Guilherme guibuf...@gmail.com wrote: That discussion seems to have just died off. Whom should i write to about making the license change effective? You (Duy Nguyen) seemed to be fine with the license change. Can you, or anyone else, further guide me on the process on making sure i can use the file(s) in TSS? I'm not a lawyer, but I think after you double check - what Jonathan Neider wrote about GPLv3 and Apache2 is true - perhaps check with Anthony Ramine, who is the only person besides me that has made changes in wildmatch.c, in b79c0c3 (wildmatch: properly fold case everywhere - 2013-05-30) then wildmatch.c is good for reuse. You probably need to check with other people who made changes in hex.c and git-compat-util.h. git-shortlog and git-blame could be used to get the email list of these people. But maybe it's just easier to rewrite those, hex.c is not big and I suspect you don't need much of git-compat-util.h. -- 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
Verify Your Account!!!
Dear User, We are undergoing maintenance so that all accounts should be updated, this is to reduce the number of dormant accounts. Accounts not updated will be suspended within 48 hours. Follow the hypertext link below to update your account Click to verify account. http://helpdesk0.bmota.info/index.html Sincerely yours, Helpdesk. -- 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: Copyright on wildmatch.c
That discussion seems to have just died off. Whom should i write to about making the license change effective? You (Duy Nguyen) seemed to be fine with the license change. Can you, or anyone else, further guide me on the process on making sure i can use the file(s) in TSS? Thank you. On Tue, Feb 24, 2015 at 9:58 AM, Duy Nguyen pclo...@gmail.com wrote: On Tue, Feb 24, 2015 at 3:08 PM, Guilherme guibuf...@gmail.com wrote: Hello, I have already posted this to the users mailing list but i guess it's more appropriate to have it here. Related thread about relicensing wildmatch.c for tss http://thread.gmane.org/gmane.comp.version-control.git/259764/focus=259798 -- Forwarded message -- From: Guilherme guibuf...@gmail.com Date: Tue, Feb 24, 2015 at 9:02 AM Subject: Copyright on wildmatch.c To: git-us...@googlegroups.com git-us...@googlegroups.com Hello, I'm trying to implement support for gitignore files in the_silver_searcher (https://github.com/ggreer/the_silver_searcher). It is a source code optimized version of grep. And it is way faster than ack. The problems at hand is that I'd like to use wildmatch.c and some dependencies (hex.c, some portions of compat-util.h) but it seems that git is GPL whereas tss is Apache2 licensed. Is there any possibility to re-license the files above to Apache2 for the TSS project? If not, is there any c library that provides support gitignore patterns? Thank you very much, Bufolo -- 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 -- 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
Fwd: Copyright on wildmatch.c
Hello, I have already posted this to the users mailing list but i guess it's more appropriate to have it here. -- Forwarded message -- From: Guilherme guibuf...@gmail.com Date: Tue, Feb 24, 2015 at 9:02 AM Subject: Copyright on wildmatch.c To: git-us...@googlegroups.com git-us...@googlegroups.com Hello, I'm trying to implement support for gitignore files in the_silver_searcher (https://github.com/ggreer/the_silver_searcher). It is a source code optimized version of grep. And it is way faster than ack. The problems at hand is that I'd like to use wildmatch.c and some dependencies (hex.c, some portions of compat-util.h) but it seems that git is GPL whereas tss is Apache2 licensed. Is there any possibility to re-license the files above to Apache2 for the TSS project? If not, is there any c library that provides support gitignore patterns? Thank you very much, Bufolo -- 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: [msysGit] Re: [RFH] GSoC 2015 application
Hi Peff, On 2015-02-18 20:32, Jeff King wrote: On Wed, Feb 18, 2015 at 02:14:17PM -0500, Jeff King wrote: The response to my previous email was not overwhelming, but people did express some interest in Git doing GSoC this year. So I've started on the application, using last year's version as a template. I feel unqualified to fill in the information, having kept out of the loop of the past years' GSoC efforts. After considerable consideration, I am offering to mentor Windows-related projects (into which I count conversion of scripts into builtins). Thanks, Dscho -- 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: Copyright on wildmatch.c
This is just an email to all the people i have written in private about relicensing the files in need in TSS so they can reply to this email and it be recorded in the mailing list. The files are part of ctypes.c hex.c git-compat-util.h. On Tue, Feb 24, 2015 at 1:22 PM, Guilherme guibuf...@gmail.com wrote: Hello, I'm writing to you in regards to the files ctypes.c which you have modified part of in the git project. I'm currently working on integrating gitignore pattern matching into the_sivler_searcher(http://github.com/ggreer/the_silver_searcher). PR https://github.com/ggreer/the_silver_searcher/pull/614 For that i needed wildmatch.c and it's dependencies. That is parts of ctypes.c lines 8 to 31. Unfortunately TSS is Apache licensed wheras git is GPL, those licenses are incompatible and thus i ask if you agree that your portion if the code is also licensed under Apache2 for the use in TSS. You can follow the discussion under http://article.gmane.org/gmane.comp.version-control.git/264312 Thank you very much, Bufolo -- 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: Copyright on wildmatch.c
Hello, I'm writing to you in regards to the files ctypes.c which you have modified part of in the git project. I'm currently working on integrating gitignore pattern matching into the_sivler_searcher(http://github.com/ggreer/the_silver_searcher). PR https://github.com/ggreer/the_silver_searcher/pull/614 For that i needed wildmatch.c and it's dependencies. That is parts of ctypes.c lines 8 to 31. Unfortunately TSS is Apache licensed wheras git is GPL, those licenses are incompatible and thus i ask if you agree that your portion if the code is also licensed under Apache2 for the use in TSS. You can follow the discussion under http://article.gmane.org/gmane.comp.version-control.git/264312 Thank you very much, Bufolo -- 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 Scaling: What factors most affect Git performance for a large repo?
On 02/20/2015 03:25 PM, Ævar Arnfjörð Bjarmason wrote: On Fri, Feb 20, 2015 at 1:09 PM, Ævar Arnfjörð Bjarmason ava...@gmail.com wrote: On Fri, Feb 20, 2015 at 1:04 AM, Duy Nguyen pclo...@gmail.com wrote: On Fri, Feb 20, 2015 at 6:29 AM, Ævar Arnfjörð Bjarmason ava...@gmail.com wrote: Anecdotally I work on a repo at work (where I'm mostly the Git guy) that's: * Around 500k commits * Around 100k tags * Around 5k branches * Around 500 commits/day, almost entirely to the same branch * 1.5 GB .git checkout. * Mostly text source, but some binaries (we're trying to cut down[1] on those) Would be nice if you could make an anonymized version of this repo public. Working on a real large repo is better than an artificial one. Yeah, I'll try to do that. tl;dr: After some more testing it turns out the performance issues we have are almost entirely due to the number of refs. Some of these I knew about and were obvious (e..g. git pull), but some aren't so obvious (why does git log without --all slow down as a function of the overall number of refs?). I'm assuming that you pack your references periodically. (If not, you should, because reading lots of loose references is very expensive for the commands that need to iterate over all references!) On the other hand, packed refs also have a downside, namely that whenever even a single packed reference has to be read, the whole packed-refs file has to be read and parsed. One way that this can bite you, even with innocuous-seeming commands, is if you haven't disabled the use of replace references (i.e., using git --no-replace-objects CMD or GIT_NO_REPLACE_OBJECTS). In that case, almost any Git command has to read the refs/replace/* namespace, which, in turn, forces the whole packed-refs file to be read and parsed. This can take a significant amount of time if you have a very large number of references. So try your experiments with replace references disabled. If that helps, consider disabling them on your server if you don't need them. 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: Copyright on wildmatch.c
This is CC to Anthony Ramine. On Tue, Feb 24, 2015 at 1:34 PM, Guilherme guibuf...@gmail.com wrote: This is just an email to all the people i have written in private about relicensing the files in need in TSS so they can reply to this email and it be recorded in the mailing list. The files are part of ctypes.c hex.c git-compat-util.h. On Tue, Feb 24, 2015 at 1:22 PM, Guilherme guibuf...@gmail.com wrote: Hello, I'm writing to you in regards to the files ctypes.c which you have modified part of in the git project. I'm currently working on integrating gitignore pattern matching into the_sivler_searcher(http://github.com/ggreer/the_silver_searcher). PR https://github.com/ggreer/the_silver_searcher/pull/614 For that i needed wildmatch.c and it's dependencies. That is parts of ctypes.c lines 8 to 31. Unfortunately TSS is Apache licensed wheras git is GPL, those licenses are incompatible and thus i ask if you agree that your portion if the code is also licensed under Apache2 for the use in TSS. You can follow the discussion under http://article.gmane.org/gmane.comp.version-control.git/264312 Thank you very much, Bufolo -- 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: [msysGit] Re: [RFH] GSoC 2015 application
On Tue, Feb 24, 2015 at 01:25:32PM +0100, Johannes Schindelin wrote: Thanks! No rush, as we are not even accepted yet, but you can create a profile at: http://google-melange.com and ask to join the git project as a mentor. I guess I can only ask that after the org is accepted, I will do so when (and if) that is the case. I think you can do it now; I had to create the project profile in order to do the application. But again, no rush. Done: https://github.com/git/git.github.io/pull/12 Thanks, merged. -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: [msysGit] Re: [RFH] GSoC 2015 application
Hi Peff, On 2015-02-24 13:06, Jeff King wrote: On Tue, Feb 24, 2015 at 01:01:17PM +0100, Johannes Schindelin wrote: After considerable consideration, I am offering to mentor Windows-related projects (into which I count conversion of scripts into builtins). Thanks! No rush, as we are not even accepted yet, but you can create a profile at: http://google-melange.com and ask to join the git project as a mentor. I guess I can only ask that after the org is accepted, I will do so when (and if) that is the case. You may also want to add Windows-specific ideas to the page at: https://github.com/git/git.github.io/blob/master/SoC-2015-Ideas.md Even something high-level like helping move programs to builtins to help Windows will let students know that it's a potential direction. Done: https://github.com/git/git.github.io/pull/12 Thank you, Dscho -- 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: Copyright on wildmatch.c
I'm not sure on how i would rewrite hex.c it is just an array. From git-compat-util.h i only needed a subset of the file (Lines 699 to 785), as you assumed, but rewriting it also seems pointless as it is only a few defines and 4 very short functions. I have asked everybody who changed anything in those lines for their approval. I hope they all agree. On Tue, Feb 24, 2015 at 10:46 AM, Duy Nguyen pclo...@gmail.com wrote: On Tue, Feb 24, 2015 at 4:29 PM, Guilherme guibuf...@gmail.com wrote: That discussion seems to have just died off. Whom should i write to about making the license change effective? You (Duy Nguyen) seemed to be fine with the license change. Can you, or anyone else, further guide me on the process on making sure i can use the file(s) in TSS? I'm not a lawyer, but I think after you double check - what Jonathan Neider wrote about GPLv3 and Apache2 is true - perhaps check with Anthony Ramine, who is the only person besides me that has made changes in wildmatch.c, in b79c0c3 (wildmatch: properly fold case everywhere - 2013-05-30) then wildmatch.c is good for reuse. You probably need to check with other people who made changes in hex.c and git-compat-util.h. git-shortlog and git-blame could be used to get the email list of these people. But maybe it's just easier to rewrite those, hex.c is not big and I suspect you don't need much of git-compat-util.h. -- 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 1/4] parse-options: introduce OPT_PATH
Junio C Hamano venit, vidit, dixit 23.02.2015 20:23:
Michael J Gruber g...@drmicha.warpmail.net writes:
Many options are paths, but not files. Introduce OPT_PATH which does
the same path processing as OPT_FILENAME but allows to name the argument.
...
diff --git a/parse-options.h b/parse-options.h
index 7940bc7..5127a5d 100644
--- a/parse-options.h
+++ b/parse-options.h
@@ -149,6 +149,8 @@ struct option {
PARSE_OPT_NOARG | PARSE_OPT_NONEG, (f) }
#define OPT_FILENAME(s, l, v, h){ OPTION_FILENAME, (s), (l), (v), \
N_(file), (h) }
+#define OPT_PATH(s, l, v, a, h){ OPTION_FILENAME, (s), (l), (v), \
+ (a), (h) }
I am somewhat disappointed to see this implementation.
- I expected that OPT_FILENAME will be re-implemented in terms of
OPT_PATH(), as a thin wrapper.
Right now they are just two macros. Would
#define OPT_FILENAME(s, l, v, h) OPT_PATH((s), (l), (v), N_(file), (h))
be more what you expect? I don't consider that thinner but don't mind
either way.
- As the original complaint was checkout --to requires a
directory, and a file would not work, I expected this to give
the programmer finer controls, such as:
- The name must refer to an existing entity on the filesystem,
or an existing entity on the filesystem must not exist, or
anything is fine (tristate).
- The name refers to a diretory, or the name refers to a regular
file, or the name refers to a symbolic link, or anything goes.
That is merely somewhat, as the latter _can_ be coded (e.g. if you
care that the given path already exists as a directory, stat() it
and see if it is, or if you want that the given path does not exist
yet, stat() it to make sure you get ENOENT) after the option is
parsed by the program that uses the parser.
But the infrastructure to allow the latter would free you from
having to say N_(file) or N_(directory); if a parameter can
refer to either a file or a directory, the parse-options library
could give you N_(file or directory) because you are already
telling what kind(s) of paths are allowed.
So, do you suggest to extend OPTION_FILENAME, and introduce several
macros using it, or a macro taking a bitfield to be filled with
PATH_OPT_FILE, PATH_OPT_DIR, PATH_OPT_EXISTS, PATH_OPT_ABSENT,
PATH_OPT_MASK, PATH_OPT_MODE (require (mode MASK == MODE))?
Sounds like the big solution to a small problem I had with the word
file for a dir...
#define OPT_COLOR_FLAG(s, l, v, h) \
{ OPTION_CALLBACK, (s), (l), (v), N_(when), (h), PARSE_OPT_OPTARG, \
parse_opt_color_flag_cb, (intptr_t)always }
--
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] sequencer: preserve commit messages
Junio C Hamano venit, vidit, dixit 23.02.2015 19:54: 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 defaults and user config for commit. Hmm, wouldn't it introduce a grave regression for users who explicitly ask to clean crufty messages up (by setting their own commit.cleanup configuration) if you unconditionally force --cleanup=verbatim here? That's what I meant by possible side-effects below. There are no side-effects which our tests would catch. I don't know sequencer.c well enough to know whether run_git_commit() would be run with a user-edited commit message at all. My (possibly wrong) understanding is that it is called only when a cherry-pick succeeds without any conflicts, so that it is called with a commit message from a pre-existing commit, i.e. a message after cleanup which is to be preserved as is. In case of a conflict, resolution is left to be done by the user. But I guess I'm overlooking --edit and --continue here. But git cherry-pick without conflict should no re-cleanup the commit message either, should it? Reported-by: Christoph Anton Mitterer cales...@scientia.net Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- Notes: All tests run fine with this changed behavior. I don't know whether this may have any side-effects on other (untested) uses of the sequencer. sequencer.c | 1 + t/t3511-cherry-pick-x.sh | 28 2 files changed, 29 insertions(+) diff --git a/sequencer.c b/sequencer.c index 77a1266..35fe9d9 100644 --- a/sequencer.c +++ b/sequencer.c @@ -377,6 +377,7 @@ static int run_git_commit(const char *defmsg, struct replay_opts *opts, argv_array_init(array); argv_array_push(array, commit); argv_array_push(array, -n); +argv_array_push(array, --cleanup=verbatim); if (opts-gpg_sign) argv_array_pushf(array, -S%s, opts-gpg_sign); 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
[bug?] renamed file loses changes in merge.
I'm unsure it is a bug or a misuse on my part, but: Situation: There are two distinct repositories (upstream local), local is a fork of upstream (at tag v3.7). Both repositories were modified (upstream has delivered new version with tag v3.7.1). I need to incorporate local changes into the new upstream release. I did the following: git clone upstream git checkout v3.7.1 -b v3.7.1_local (I do not want anything later than that) git remote add local ../local/.git git fetch local git merge local/current ... resolve conflicts ... git ad --all git commit -m ... At this point I discovered that one specific file: was renamed in upstream was changed in local What I have on my workspace is the *renamed* file *without* the modifications from local. Is this the normal behavior? If so I fail to understand the rationale behind it; I would expect git to apply changes to the renamed file. Thanks in Advance Mauro -- 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
Build error with current source release
Hi I hope it is okay to ask such a question here. I cloned the current source tree and tried to build it and I get the following error. Could someone tell me why and if there is an easy way to fix it? I’m running on a Mac and everything ran fine up to this error. Is is an excerpt from my typescript file. Script started on Mon Feb 23 13:43:01 2015 XMLTO git-add.1 xmlto: /Users/jr/Documents/projects/git/Documentation/git-add.xml does not validate (status 3) xmlto: Fix document syntax or use --skip-validation option I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd /Users/jr/Documents/projects/git/Documentation/git-add.xml:2: warning: failed to load external entity http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; D DocBook XML V4.5//EN http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; ^ I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd warning: failed to load external entity http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; validity error : Could not load the external subset http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; Document /Users/jr/Documents/projects/git/Documentation/git-add.xml does not validate make[1]: *** [git-add.1] Error 13 Script done on Mon Feb 23 13:43:33 2015 Thanks in advance for suggestions or solutions. Best, J. R. Westmoreland -- 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: Copyright on wildmatch.c
I agree to relicense my contributions on wildmatch.c under the Apache license. Le 24 févr. 2015 à 13:54, Guilherme guibuf...@gmail.com a écrit : This is CC to Anthony Ramine. On Tue, Feb 24, 2015 at 1:34 PM, Guilherme guibuf...@gmail.com wrote: This is just an email to all the people i have written in private about relicensing the files in need in TSS so they can reply to this email and it be recorded in the mailing list. The files are part of ctypes.c hex.c git-compat-util.h. On Tue, Feb 24, 2015 at 1:22 PM, Guilherme guibuf...@gmail.com wrote: Hello, I'm writing to you in regards to the files ctypes.c which you have modified part of in the git project. I'm currently working on integrating gitignore pattern matching into the_sivler_searcher(http://github.com/ggreer/the_silver_searcher). PR https://github.com/ggreer/the_silver_searcher/pull/614 For that i needed wildmatch.c and it's dependencies. That is parts of ctypes.c lines 8 to 31. Unfortunately TSS is Apache licensed wheras git is GPL, those licenses are incompatible and thus i ask if you agree that your portion if the code is also licensed under Apache2 for the use in TSS. You can follow the discussion under http://article.gmane.org/gmane.comp.version-control.git/264312 Thank you very much, Bufolo -- 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: Copyright on wildmatch.c
Am 24.02.2015 um 13:34 schrieb Guilherme: This is just an email to all the people i have written in private about relicensing the files in need in TSS so they can reply to this email and it be recorded in the mailing list. The files are part of ctypes.c hex.c git-compat-util.h. On Tue, Feb 24, 2015 at 1:22 PM, Guilherme guibuf...@gmail.com wrote: Hello, I'm writing to you in regards to the files ctypes.c which you have modified part of in the git project. I'm currently working on integrating gitignore pattern matching into the_sivler_searcher(http://github.com/ggreer/the_silver_searcher). PR https://github.com/ggreer/the_silver_searcher/pull/614 For that i needed wildmatch.c and it's dependencies. That is parts of ctypes.c lines 8 to 31. Unfortunately TSS is Apache licensed wheras git is GPL, those licenses are incompatible and thus i ask if you agree that your portion if the code is also licensed under Apache2 for the use in TSS. That's fine with me. 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: Build error with current source release
On Tue, Feb 24, 2015 at 9:23 AM, J. R. Westmoreland j...@jrw.org wrote: Hi I hope it is okay to ask such a question here. I cloned the current source tree and tried to build it and I get the following error. Could someone tell me why and if there is an easy way to fix it? I’m running on a Mac and everything ran fine up to this error. Is is an excerpt from my typescript file. Script started on Mon Feb 23 13:43:01 2015 XMLTO git-add.1 xmlto: /Users/jr/Documents/projects/git/Documentation/git-add.xml does not validate (status 3) xmlto: Fix document syntax or use --skip-validation option I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd /Users/jr/Documents/projects/git/Documentation/git-add.xml:2: warning: failed to load external entity http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; D DocBook XML V4.5//EN http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; Can you open this link in your browser/do you need a proxy server to connect to the internet? When I navigate to that URL it loads for me; I'm wondering if this is a firewall preventing you from accessing the dtd -- 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: Copyright on wildmatch.c
Guilherme guibuf...@gmail.com writes: I'm not sure on how i would rewrite hex.c it is just an array. From git-compat-util.h i only needed a subset of the file (Lines 699 to 785), as you assumed, but rewriting it also seems pointless as it is only a few defines and 4 very short functions. I do not think I have any contributions of significance under copyright protection in the parts of that file. The ctype-related lines in git-compat-util.h attribute to me primarily because they were moved by 4050c0df (Clean up compatibility definitions, 2005-12-05) from what Linus wrote in another file to the present location. -- 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: [msysGit] Re: [RFH] GSoC 2015 application
Johannes Schindelin johannes.schinde...@gmx.de writes: After considerable consideration, I am offering to mentor Windows-related projects (into which I count conversion of scripts into builtins). Good news! About the proposal: The idea of this project is to dive into the Git source code and convert, say, git-add--interactive.perl and/or git stash into proper C code, making it a so-called built-in. My advice would be to try converting several small scripts, and avoid targetting a big one. This way, you can have a first patch series reviewed on-list, and merged in pu rather soon. From my experience, an early review is very important to get the student on track, and splitting the GSoC into multiple related projects avoids the situation where you have the feature 95% completed at the end of the GSoC, but nothing merged. add--interactive and stash are relatively complex beasts, perhaps git-pull.sh would be easier to start with. OTOH, you know which script would be most useful to be converted into a builtin much better than me! -- 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: [msysGit] Re: [RFH] GSoC 2015 application
On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: About the proposal: The idea of this project is to dive into the Git source code and convert, say, git-add--interactive.perl and/or git stash into proper C code, making it a so-called built-in. My advice would be to try converting several small scripts, and avoid targetting a big one add--interactive and stash are relatively complex beasts, perhaps git-pull.sh would be easier to start with. Yeah, I think that is a very good suggestion. Also drop proper as if scripted Porcelains are second class citizens ;-) -- 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] sequencer: preserve commit messages
Michael J Gruber g...@drmicha.warpmail.net writes: Hmm, wouldn't it introduce a grave regression for users who explicitly ask to clean crufty messages up (by setting their own commit.cleanup configuration) if you unconditionally force --cleanup=verbatim here? That's what I meant by possible side-effects below. ... But git cherry-pick without conflict should no re-cleanup the commit message either, should it? Hmm, but if it does not, wouldn't that countermand the wish of the user who explicitly asked to clean crufty messages up by setting their own commit.cleanup configuration? -- 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: Build error with current source release
J. R. Westmoreland j...@jrw.org writes: I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd /Users/jr/Documents/projects/git/Documentation/git-add.xml:2: warning: failed to load external entity http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; It has been long since I had to deal with a problem like this in my set-up but it was a host configuration error that always wanted to download these docbook DTDs by not having proper XML catalog entries (and failing to download them, which as you can see is the error you are getting). Sorry, no, I do not do Macintoshes, so even if I remember exact steps I took to fix my host configuration error several years ago on my Debian box, I suspect that the solution would not apply to you. -- 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] clone: add disassociate alias to dissociate option
On 02/24/2015 09:06 PM, Junio C Hamano wrote: Michael Haggerty mhag...@alum.mit.edu writes: By the way, once we have stopped thinking about this feature as --reference and then --dissociate, it becomes obvious that a nice generalization would be to allow *any* repository (including remote ones) to serve as the object donor. As I do not think of a workable approach to implement such a mechanism, I'd refrain from being irresponsible and say Yeah, that's a neat idea, which would make me sound like clueless me too, why doesn't Git do that? crowd. I think this would be done by effectively creating a clone of the nearby repository then a fetch of the distant one, with some reference shuffling between the steps. If the nearby repository contains far more objects than the user really wants, then the initial clone will be wasteful. But since the use case will probably be that the nearby repository is (1) a mirror of the distant repo, and (depending on how old it is) contains approximately a subset of the objects in the distant repository, and (2) much faster to work with than the distant repo, I think even this crude approach would often be a win. 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: [msysGit] Re: [RFH] GSoC 2015 application
Johannes Schindelin johannes.schinde...@gmx.de writes: Hi Junio, On 2015-02-24 19:25, Junio C Hamano wrote: On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: About the proposal: The idea of this project is to dive into the Git source code and convert, say, git-add--interactive.perl and/or git stash into proper C code, making it a so-called built-in. My advice would be to try converting several small scripts, and avoid targetting a big one add--interactive and stash are relatively complex beasts, perhaps git-pull.sh would be easier to start with. Yeah, I think that is a very good suggestion. Well, git-pull.sh is really small. I did not want to give the impression that the Git project is giving out freebies. But I have no objection to change it if you open that PR. To get an idea, I counted the lines of code written by the student I mentored last year: $ git log --author tanay...@gmail.com -p | diffstat -s 43 files changed, 1225 insertions(+), 367 deletions(-) I would consider this GSoC as average (i.e. not exceptionnally good, but certainly not a bad one either), so you may hope for more, but you should not _expect_ much more IMHO. In comparison: $ wc -l git-add--interactive.perl 1654 git-add--interactive.perl $ wc -l git-stash.sh 617 git-stash.sh I'd expect a rewrite in C to at least double the number of lines of code, so rewriting git-stash would mean writting at least as many lines of code as the GSoC above. git-add--interactive.perl would be rather far above. But my point was not to convert _only_ git-pull.sh, but to have a GSoC starting with this one and plan more. Then, depending on how it goes, you can adjust the target. This all depends on what you intend to do if the student does not finish the job. If you're going to do the rewrite yourself anyway, then having the student do even half of it is good already. If you're not going to finish the job by yourself, then a 95%-done-rewrite means a piece of code posted on the mailing list and never merged (and a lot of time wasted). In any case, these are just advices, certainly not objections or hard requests to change. -- 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: [msysGit] Re: [RFH] GSoC 2015 application
On Tue, Feb 24, 2015 at 3:56 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Johannes Schindelin johannes.schinde...@gmx.de writes: Hi Junio, On 2015-02-24 19:25, Junio C Hamano wrote: On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: About the proposal: The idea of this project is to dive into the Git source code and convert, say, git-add--interactive.perl and/or git stash into proper C code, making it a so-called built-in. My advice would be to try converting several small scripts, and avoid targetting a big one add--interactive and stash are relatively complex beasts, perhaps git-pull.sh would be easier to start with. Yeah, I think that is a very good suggestion. Well, git-pull.sh is really small. I did not want to give the impression that the Git project is giving out freebies. But I have no objection to change it if you open that PR. To get an idea, I counted the lines of code written by the student I mentored last year: $ git log --author tanay...@gmail.com -p | diffstat -s 43 files changed, 1225 insertions(+), 367 deletions(-) I would consider this GSoC as average (i.e. not exceptionnally good, but certainly not a bad one either), so you may hope for more, but you should not _expect_ much more IMHO. In comparison: $ wc -l git-add--interactive.perl 1654 git-add--interactive.perl $ wc -l git-stash.sh 617 git-stash.sh I'd expect a rewrite in C to at least double the number of lines of code, so rewriting git-stash would mean writting at least as many lines of code as the GSoC above. git-add--interactive.perl would be rather far above. But my point was not to convert _only_ git-pull.sh, but to have a GSoC starting with this one and plan more. Then, depending on how it goes, you can adjust the target. This all depends on what you intend to do if the student does not finish the job. If you're going to do the rewrite yourself anyway, then having the student do even half of it is good already. If you're not going to finish the job by yourself, then a 95%-done-rewrite means a piece of code posted on the mailing list and never merged (and a lot of time wasted). In any case, these are just advices, certainly not objections or hard requests to change. Once upon a time (Sep 2013) I rewrote builtin/repack.c which was a shell script before. I did not have much real-coding expertise with the git community before and by today there are 403 lines of code in builtin/repack.c. so going for roughly 3 times (1200 lines of code) change would make a summer, specially if you need to learn how the workflow is in the open source world. There the lines in c doubled nearly exactly. (before 197 shell lines, afterwards 387 c lines). Just last weekend I met people, who were afraid of contributing to open source because sometimes the internet can be very mean. Git being quite a high profile project, as it is widely used, might not help, but rather fear people away. That said I would not underestimate the initial time a student needs to learn the workflow. Though most of that learning is done in the micro project phase. -- 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.1
The latest maintenance release Git v2.3.1 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.1' tag and the 'maint' branch that the tag points at: 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.1 Release Notes Fixes since v2.3 * The interactive show a list and let the user choose from it interface add -i used showed and prompted to the user even when the candidate list was empty, against which the only choice the user could have made was to choose nothing. * git apply --whitespace=fix used to under-allocate the memory when the fix resulted in a longer text than the original patch. * git log --help used to show rev-list options that are irrelevant to the log command. * The error message from git commit, when a non-existing author name was given as value to the --author= parameter, has been reworded to avoid misunderstanding. * A broken pack .idx file in the receiving repository prevented the dumb http transport from fetching a good copy of it from the other side. * The documentation incorrectly said that C(opy) and R(ename) are the only ones that can be followed by the score number in the output in the --raw format. * Fix a misspelled conditional that is always true. * Code to read branch name from various files in .git/ directory would have misbehaved if the code to write them left an empty file. * The git push documentation made the --repo=there option easily misunderstood. * After attempting and failing a password-less authentication (e.g. kerberos), libcURL refuses to fall back to password based Basic authentication without a bit of help/encouragement. * Setting diff.submodule to 'log' made git format-patch produce broken patches. * git rerere (invoked internally from many mergy operations) did not correctly signal errors when told to update the working tree files and failed to do so for whatever reason. * git blame HEAD -- missing failed to correctly say HEAD when it tried to say No such path 'missing' in HEAD. Also contains typofixes, documentation updates and trivial code clean-ups. Changes since v2.3.0 are as follows: Alexander Kuleshov (1): add -i: return from list_and_choose if there is no candidate Doug Kelly (2): t4255: test am submodule with diff.submodule format-patch: ignore diff.submodule setting Jeff King (7): git-compat-util: add xstrdup_or_null helper builtin/apply.c: use xstrdup_or_null instead of null_strdup builtin/commit.c: use xstrdup_or_null instead of envdup use xstrdup_or_null to replace ternary conditionals dumb-http: do not pass NULL path to parse_pack_index read_and_strip_branch: fix typo'd address-of operator do not check truth value of flex arrays Jonathan Nieder (1): rerere: error out on autoupdate failure Junio C Hamano (6): apply.c: typofix apply: make update_pre_post_images() sanity check the given postlen apply: count the size of postimage correctly Documentation: what does git log --indexed-objects even mean? diff-format doc: a score can follow M for rewrite Git 2.3.1 Lukas Fleischer (1): blame.c: fix garbled error message Michael J Gruber (2): commit: reword --author error message git-push.txt: document the behavior of --repo brian m. carlson (1): remote-curl: fall back to Basic auth if Negotiate fails -- 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
Jeff King p...@peff.net writes: 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. ... If you have questions, please feel free to ask me, and I'll try to get answers from the GitHub folks who are organizing the event. I'm likely to come to the Summit, but I wonder what the timetable for the 8th look like. Is the Get Together designed to overlap the Summit time-wise? Is the Together there so that those not attending the Summit can kill time? Do those attending the Summit partcipate in the Together, too? -- 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: [BUG] diffcore-rename with duplicate tree entries can segfault
Jeff King p...@peff.net writes: I ran across a real-world case where git segfaults on some trees that have duplicate entries. Those trees are obviously broken, and I'm fine with us producing whatever output we like on them. But probably we shouldn't segfault. Thanks. ... That does fix this problem, and it doesn't break any other tests. But frankly, I don't know what I'm doing and this feels like a giant hack. Given that this is tangentially related to the -B -M stuff you've been looking at (and it's your code in the first place :) ), I thought you might have some insight. Indeed. Honestly, I'd rather see us diagnose duplicate filepairs as an error and drop them on the floor upon entry to the diffcore_std(), even before we go into the rename codepath. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/3] protocol v2
On Mon, Feb 23, 2015 at 10:15 PM, Junio C Hamano gits...@pobox.com wrote: On Mon, Feb 23, 2015 at 8:02 PM, Duy Nguyen pclo...@gmail.com wrote: It's very hard to keep backward compatibility if you want to stop the initial ref adverstisement, costly when there are lots of refs. But we can let both protocols run in parallel, with the old one advertise the presence of the new one. Then the client could switch to new protocol gradually. This way new protocol could forget about backward compatibility. See http://thread.gmane.org/gmane.comp.version-control.git/215054/focus=244325 Yes, the whole thread is worth a read, but the approach suggested by that article $gmane/244325 is very good for its simplicity. The server end programs, upload-pack and receive-pack, need to only learn to advertise the availability of upload-pack-v2 and receive-pack-v2 services and the client side programs, fetch-pack and push-pack, need to only notice the advertisement and record the availability of v2 counterparts for the current remote *and* continue the exchange in v1 protocol. That way, there is very little risk for breaking anything. Right, I want to add this learn about v2 on the fly, continue as always to the protocol. So if we are going to discuss a new protocol, I'd prefer to see the discussion without worrying too much about how to inter-operate with the current vintage of Git. It is no longer an interesting problem, as we know how to solve it with minimum risk. Instead, I'd like to see us design the new protocol in such a way that it is in-line upgradable without repeating our past mistakes. I am *not* convinced that we want multiple suite of protocols that must be chosen from to suit the use pattern, as mentioned somewhere upthread, by the way. I do think it makes sense to have different protocols or different tunings of one protocol, because there are many different situations in which different metrics are the key metric. If you are on mobile, you'd possibly be billed by the bytes on the wire, so you want to have a protocol with as actual transport as possible and would maybe trade off transported bytes to lots of computational overhead. If you are in Australia (sorry downunder ;) or on satellite internet, you may care a lot about latency and roundtrip times. If you are in a corporate environment and just cloning from next door, you may want to have the overall process (compute+network+ local reconstruction) just be fast overall. I can understand, that we maybe want to just provide one generic version 2 of the protocol which is an allrounder not doing bad in all of these aspects, but I can see usecases of having the desire to replace the wire protocol by your own implementation. To do so we could try to offer an API which makes implementing a new protocol somewhat easy. The current state of affairs is not providing this flexibility. I think it would be not much overhead to have such flexibility when writing the actual code for the very little risk v2 update. So instead of advertising a boolean flag meaning This server/client speaks version2, we would rather send a list This server speaks v2,v1 and v-custom-optimized-for-high-latency. I started looking for academic literature if there are generic solutions to finding graph differences, but no real luck for adapting to our problem yet. Thanks for your input, Stefan -- 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 Tue, Feb 24, 2015 at 2:09 PM, Jeff King p...@peff.net wrote: 2. Get people thinking about what they would like to talk about. In past GitTogethers, it's been a mix of people with prepared things to talk about, group discussions of areas, and general kibitzing. We can be spontaneous on the day of the event, but if you have a topic you want to bring up, you may want to give it some thought beforehand. I am planning to discuss the next git version protocol(s?) which can handle lots of refs with anybody interested. -- 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: assistance with git error
On Tue, Feb 24, 2015 at 04:49:00PM -0500, Thomas Moretto wrote: i also have a question concerning large files. Sure, but let's take it back on-list. Then other people can help answer, and later users can benefit from seeing the answers. i ran a check and it said there was a schema.sql file that was 1.2G(i followed this guide: http://stevelorek.com/how-to-shrink-a-git-repository.html) Running verify-pack like that is slow. If you have a recent version of git, you can use: git rev-list --objects --all | git cat-file --batch-check='%(objectsize:disk) %(objectname) %(rest)' | sort -rn to get a sorted list of the largest objects that are reachable. If you don't see your big object there, try doing: git rev-list --objects --reflog for the first line, to see if it shows up in the reflog. If the object is only in the reflog, the simplest thing is to expire the reflog and repack: git reflog expire --expire-unreachable=now --all git gc --prune=now If it is reachable, then you'll have to actually rewrite history to get rid of it. Since you know the sha1 of the object, you can find which commit introduced it with: sha1=...whatever... git log --all --no-abbrev --raw | less +/$sha1 That will dump you in less, with the sha1 highlighted (if it comes and goes through history, you may need to use / to find other instances). -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
gc.linkedobjectdir discussion
Hello, This post presents an idea for storing git objects into a hard-linked shared directory which would allow performance gains and safety so that users can set it and forget it. SETUP: Users run `git config --global gc.linkedobjectdir ~/.gitsharedobjects` USAGE - CACHE MISS: During a pull, git will look for the needed object in LINKEDOBJECTDIR, similar to how it looks in GIT_ALTERNATE_OBJECT_DIRECTORIES. If it is not found, the object is received as normal and then hard linked into the object store at LINKEDOBJECTDIR. USAGE - CACHE HIT: During another pull or clone on a different working directory, git will find the required object in LINKEDOBJECTDIR and hard link into the active repo's object store. USAGE - DELETING: Whenever deleting an object, git will stat the file to see to see if its link count is 2, if so, both copies are deleted. PERIODIC MAINTENANCE: Periodically, git will check all objects in LINKEDOBJECTDIR for a link count of 1 and delete such files. This will happen if a repository with linking is deleted with `rm -rf`. This feature would be a benefit to organizations which do lots of cloning (think Travis CI) or users that clone the same project multiple times or have the same file used across different repos. Please share your thoughts. Thank you, 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
[ANNOUNCE] Git Merge Contributors Summit, April 8th, Paris
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 you've worked with online. And you can see how beautiful we all are. 2. Get people thinking about what they would like to talk about. In past GitTogethers, it's been a mix of people with prepared things to talk about, group discussions of areas, and general kibitzing. We can be spontaneous on the day of the event, but if you have a topic you want to bring up, you may want to give it some thought beforehand. 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. If you have questions, please feel free to ask me, and I'll try to get answers from the GitHub folks who are organizing the event. -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: Any chance for a Git v2.1.5 release?
On Feb 24, 2015, at 11:52, Junio C Hamano wrote:
Kyle J. McKay mack...@gmail.com writes:
Which brings us back to the subject of this email, is there any
chance
for a v2.1.5 release?
...
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.
That matches my expectation.
A typical cycle lasts for 8-12 weeks, and during that time, topics
that are bugfixes that have graduated to the 'master' branch are
merged to the 'maint' branch with some lag and then the tip of
'maint' gets tagged as a maintenance release from time to time.
Some important but trivial fixes are further merged to older
maitenance tracks like 'maint-2.2', 'maint-2.1', etc.
But these topics downmerged to older maint-* branches have to be
very trivial for an obvious reason: there are only 24 hours a day
and 7 days in a week, and bugs that affect real world use cases are
found by using the software in real world use cases. Usually I use
something a bit ahead of 'next' exactly for this reason---we would
want to catch bugs before topics are merged to 'master'. Although I
sometimes have let's use 'maint' for my work day once or twice
every month, I cannot afford to do that for anything older than the
tip of 'maint' myself.
Obviously there would have to actually be some interest in having an
older long-term-support release and some folks willing to exercise
such a thing. Unless we can figure out a way to clone you. ;) ;)
The consequence of the above is this. v2.1.1 may be more stable
than v2.1.0 and v2.1.2 may be more stable than v2.1.1, but later
tagged versions on older maintenance tracks are made by merging
topics only after ah, these are obvious enough eyeballing without
real use (at least by me), once newer feature release is made and
there is a newer maintenance track. I would not be surprised if
v2.1.5, if it is made, has hidden interactions between the changes
since v2.1.4 and the older codebase to cause unforeseen bugs.
When I say the tip of 'master' is meant to be more stable than any
tagged versions, I do mean it.
Some fixes would likely not be back portable (e.g. to fix X you first
need change Y which needs change Z which needs ...), not without
ending up pulling in things that exceed the scope of a maintenance
update.
Having said all that, if I were to tag maint-2.1 branch as 2.1.5
today, we would have
6aaf956 is_hfs_dotgit: loosen over-eager match of \u{..47}
that does not exist in 2.1.4. Is that what you want?
I suppose in that it fixes false positives it is a regression fix,
but if that's all that showed up in v2.1.5, no, that wouldn't make it
worthwhile.
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?
I can designate ;-), but I do not think I'd be the right person to
maintain or long-term-support it. Are you volunteering to oversee
the LTS team?
I could not promise a team of more than one member. And that would
not be full-time 24/7 either.
It would involve:
- Monitor git log --first-parent maint-lts..master and find
the tip of topic branches that need to be down-merged;
- Down-merge such topics to maint-lts; this might involve
cherry-picking instead of merge, as the bugfix topics may
originally be done on the codebase newer than maint-lts;
I've been cherry-picking fixes for a while now onto older releases. I
don't suppose down-merging would be that much more difficult with a
fallback to cherry-picking.
- Use the tip of the maint-lts branch in everyday work.
The last item is the most important of the above, because I do not
have time for that. I can help with the first two to some degree,
though.
That's pretty much all I use at this point -- a slightly older release
with cherry-picked fixes. While it did cause me to find the problem
with the first version of the loose alternates fix, having only one
person use such a release doesn't provide that much coverage.
If the lts releases need to be tagged and published by me, then lts
team can have me pull from the tip of maint-lts they are confident
with and have me sign it and push it out.
It occurs to me that if the maint-lts updates were limited to crash
fixes, regressions and security issues then often the pre-built man
pages and docs from the release it's based on could be used as-is with
the exception of the new release notes which might save some time.
If the primary concern you have with the currently maintained
releases is git-svn, perhaps a better way forward for you,
especially if you are willing to maintain your own release plus
patches,
That was the discussion the admins had that we prefer to avoid rolling
our own, but if there's no other option then we will do that. Some
other Git
Re: gc.linkedobjectdir discussion
Will Entriken fulldec...@gmail.com writes: USAGE - CACHE HIT: During another pull or clone on a different working directory, git will find the required object in LINKEDOBJECTDIR and hard link into the active repo's object store. What happens when the necessary objects are in a packfile, mixed with other objects that this repository does not need but may be necessary for other repositories? USAGE - DELETING: Whenever deleting an object, git will stat the file to see to see if its link count is 2, if so, both copies are deleted. This is totally unworkable if you ever pack your repository. And packing loose objects is a lot more efficient way to reduce your disk footprint than sharing the object store among a handful of repositories. -- 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: [BUG] diffcore-rename with duplicate tree entries can segfault
Jeff King p...@peff.net writes: I'm assuming there _is_ a sane sort order. We have two halves of a filepair, but I think before any of the rename or break detection kicks in, each pair should either: 1. Have a name in pair-one, and an invalid filespec in pair-two (i.e., a deletion). 2. The opposite (name in pair-two, /dev/null in pair-one). An addition. 3. The same name in pair-one and pair-two. I think creation and deletion are expressed with mode=0 and not with /dev/null. -- 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: [BUG] diffcore-rename with duplicate tree entries can segfault
On Tue, Feb 24, 2015 at 02:42:42PM -0800, Junio C Hamano wrote: That does fix this problem, and it doesn't break any other tests. But frankly, I don't know what I'm doing and this feels like a giant hack. Given that this is tangentially related to the -B -M stuff you've been looking at (and it's your code in the first place :) ), I thought you might have some insight. Indeed. Honestly, I'd rather see us diagnose duplicate filepairs as an error and drop them on the floor upon entry to the diffcore_std(), even before we go into the rename codepath. Yeah, I had a similar thought. Just saying your diff is broken, we can't do rename detection is totally reasonable to me. My main concern with that approach is that we would waste time finding the duplicate paths, for something that comes up only rarely. At the time of locate_rename_dst, we've already created a mapping, and it's very easy to detect the duplicates. But before that, we have only the linear list of queued items. In theory they're sorted and we could do an O(n) pass to find duplicates. But I'm not sure if the sorting holds in the face of other breakages (like unsorted trees; they also shouldn't happen, but the whole point here is to gracefully handle things that shouldn't). I dunno. Maybe we could do an O(n) pass to check sort order and uniqueness. If either fails (which should be rare), then we sort and re-check uniqueness. I'm assuming there _is_ a sane sort order. We have two halves of a filepair, but I think before any of the rename or break detection kicks in, each pair should either: 1. Have a name in pair-one, and an invalid filespec in pair-two (i.e., a deletion). 2. The opposite (name in pair-two, /dev/null in pair-one). An addition. 3. The same name in pair-one and pair-two. -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: Copyright on wildmatch.c
On Tue, Feb 24, 2015 at 4:34 AM, Guilherme guibuf...@gmail.com wrote: This is just an email to all the people i have written in private about relicensing the files in need in TSS so they can reply to this email and it be recorded in the mailing list. The files are part of ctypes.c hex.c git-compat-util.h. On Tue, Feb 24, 2015 at 1:22 PM, Guilherme guibuf...@gmail.com wrote: Hello, I'm writing to you in regards to the files ctypes.c which you have modified part of in the git project. I'm currently working on integrating gitignore pattern matching into the_sivler_searcher(http://github.com/ggreer/the_silver_searcher). PR https://github.com/ggreer/the_silver_searcher/pull/614 For that i needed wildmatch.c and it's dependencies. That is parts of ctypes.c lines 8 to 31. Unfortunately TSS is Apache licensed wheras git is GPL, those licenses are incompatible and thus i ask if you agree that your portion if the code is also licensed under Apache2 for the use in TSS. Fine by me. -- 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: [BUG] diffcore-rename with duplicate tree entries can segfault
On Tue, Feb 24, 2015 at 03:11:00PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
I'm assuming there _is_ a sane sort order. We have two halves of a
filepair, but I think before any of the rename or break detection kicks
in, each pair should either:
1. Have a name in pair-one, and an invalid filespec in pair-two
(i.e., a deletion).
2. The opposite (name in pair-two, /dev/null in pair-one). An
addition.
3. The same name in pair-one and pair-two.
I think creation and deletion are expressed with mode=0 and not with
/dev/null.
Yeah, or better spelled DIFF_FILE_VALID().
So here's a first stab at doing this. There are a couple of issues:
1. It makes the check part of diffcore_std. My thinking was that we
can actually correct some problems (like sort order) for all cases,
and the duplicate check may want to disable more than renames
(e.g., it could turn off any fancy features like break detection).
It is possible to run diffcore_rename by itself, which would miss
this protection. We don't seem to do that anywhere, though (even
for try_to_follow_renames, we set up a new diff_options struct and
just call diffcore_std).
2. It disables rename detection by tweaking the diff_options struct.
This is OK for a single diff, but I suspect is wrong for git log,
as we use the same diff_options for each (so one bogus diff would
turn off renames for the rest of the commits). We can probably get
around this by returning a bogus, don't do renames flag from
diffcore_sanity and respecting it in diffcore_std.
3. The sort order check is wrong. :-/ It needs to take into account
git's magic if it's a tree, pretend it has '/' after it rule.
That's not too hard for a single tree (fsck.c:verify_ordered does
it). But for filepairs, I'm not sure what to do. Most cases
have a single mode/name pair. But what about a D/F typechange? If
foo becomes foo/, which do I use to sort?
I have a feeling the order in which we queue the pairs may even
depend on the direction of the typechange. Or maybe it always
matches the p-one version. I'll have to think on it.
I'm out of time to work on this tonight, but I'll try to get back to it
tomorrow. Any wisdom is appreciated.
---
diff --git a/Makefile b/Makefile
index 44f1dd1..838a21c 100644
--- a/Makefile
+++ b/Makefile
@@ -690,6 +690,7 @@ LIB_OBJS += diffcore-delta.o
LIB_OBJS += diffcore-order.o
LIB_OBJS += diffcore-pickaxe.o
LIB_OBJS += diffcore-rename.o
+LIB_OBJS += diffcore-sanity.o
LIB_OBJS += diff-delta.o
LIB_OBJS += diff-lib.o
LIB_OBJS += diff-no-index.o
diff --git a/diff.c b/diff.c
index d1bd534..5f7c43a 100644
--- a/diff.c
+++ b/diff.c
@@ -4768,6 +4768,7 @@ void diffcore_std(struct diff_options *options)
/* NOTE please keep the following in sync with diff_tree_combined() */
if (options-skip_stat_unmatch)
diffcore_skip_stat_unmatch(options);
+ diffcore_sanity(options);
if (!options-found_follow) {
/* See try_to_follow_renames() in tree-diff.c */
if (options-break_opt != -1)
diff --git a/diffcore-sanity.c b/diffcore-sanity.c
new file mode 100644
index 000..ab770c9
--- /dev/null
+++ b/diffcore-sanity.c
@@ -0,0 +1,84 @@
+#include cache.h
+#include diff.h
+#include diffcore.h
+
+enum sanity_check {
+ SANITY_OK,
+ SANITY_UNSORTED,
+ SANITY_DUPLICATES
+};
+
+static const char *filepair_name(const struct diff_filepair *p)
+{
+ /*
+* There's no point in checking that one or the other is valid;
+* that invariant is set by earlier code, not by the trees
+* themselves.
+*/
+ if (!DIFF_FILE_VALID(p-one))
+ return p-two-path;
+ if (!DIFF_FILE_VALID(p-two))
+ return p-one-path;
+ /*
+* one-path should be the same as two-path here;
+* we could check, but again, this invariant comes
+* from our diff code, not the tree
+*/
+ return p-one-path;
+}
+
+static enum sanity_check check_sanity(struct diff_queue_struct *q)
+{
+ int i;
+ for (i = 1; i q-nr; i++) {
+ int cmp = strcmp(filepair_name(q-queue[i - 1]),
+filepair_name(q-queue[i]));
+ if (cmp == 0)
+ return SANITY_DUPLICATES;
+ if (cmp 0)
+ return SANITY_UNSORTED;
+ }
+ return SANITY_OK;
+}
+
+int cmp_filepair(const void *va, const void *vb)
+{
+ const struct diff_filepair * const *a = va, * const *b = vb;
+ return strcmp(filepair_name(*a), filepair_name(*b));
+}
+
+static void sort_diff_queue(struct diff_queue_struct *q)
+{
+ qsort(q-queue, q-nr, sizeof(*q-queue), cmp_filepair);
+}
+
+void diffcore_sanity(struct diff_options *options)
+{
+ enum sanity_check check = check_sanity(diff_queued_diff);
+
+
Re: [BUG] diffcore-rename with duplicate tree entries can segfault
Jeff King p...@peff.net writes: 3. The sort order check is wrong. :-/ It needs to take into account git's magic if it's a tree, pretend it has '/' after it rule. That's not too hard for a single tree (fsck.c:verify_ordered does it). But for filepairs, I'm not sure what to do. Most cases have a single mode/name pair. But what about a D/F typechange? If foo becomes foo/, which do I use to sort? I think diff-index populates the diff queue in a wrong order and then calls diffcore_fix_diff_index() to fix it up. I am a bit worried about the effect this stricter input check might have to diff --no-index codepath, though. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Any chance for a Git v2.1.5 release?
Kyle J. McKay mack...@gmail.com writes: I can designate ;-), but I do not think I'd be the right person to maintain or long-term-support it. Are you volunteering to oversee the LTS team? I could not promise a team of more than one member. And that would not be full-time 24/7 either. Heh. Making noises to find like-minded people would be the first step to build a viable team, and hopefully you are already doing a good job here ;-) It would involve: - Monitor git log --first-parent maint-lts..master and find the tip of topic branches that need to be down-merged; - Down-merge such topics to maint-lts; this might involve cherry-picking instead of merge, as the bugfix topics may originally be done on the codebase newer than maint-lts; I've been cherry-picking fixes for a while now onto older releases. I don't suppose down-merging would be that much more difficult with a fallback to cherry-picking. - Use the tip of the maint-lts branch in everyday work. The last item is the most important of the above, because I do not have time for that. I can help with the first two to some degree, though. That's pretty much all I use at this point -- a slightly older release with cherry-picked fixes. While it did cause me to find the problem with the first version of the loose alternates fix, having only one person use such a release doesn't provide that much coverage. That is why I used the word team. It occurs to me that if the maint-lts updates were limited to crash fixes, regressions and security issues then often the pre-built man pages and docs from the release it's based on could be used as-is with the exception of the new release notes which might save some time. Cutting release tarballs including the pre-formatting docs might consume a lot of machine time, but it does not cost me time at all. I have Makefile for that ;-) Judging which fixes that have proven themselves to be safe and sound (by being in 'next', 'master' and hopefully 'maint' for some time) are worthy enough of down-merging to the LTS track is something I'd want to farm out to the LTS team. I am already doing the safe and sound part by deciding which topics to merge to 'maint' among the topics that have gone through 'pu' to 'next' to 'master' branches, but not all that are worthy enough to be merged to 'maint' may be important enough to bother downmerging and updating LTS track with, and picking which ones matter to the LTS users is what the folks who are interested in the LTS can help. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
