[PATCH] t9402: sed -i is not portable
The command line
sed -i -e s/foo/bar/ filename
works as expected under GNU/Linux:
all foo are replaced by bar in the file filename
sed on other systems like e.g. Mac OS X creates a backup file
called filename-e, because the -i must be followed by a file name.
As the -i is not in POSIX either, avoid it completely
Improve check_end_tree() and check_end_full_tree() to use test_cmp,
and use the between each line.
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
This must be applied on peff/pu
t/t9402-git-cvsserver-refs.sh | 44 ++-
1 file changed, 23 insertions(+), 21 deletions(-)
diff --git a/t/t9402-git-cvsserver-refs.sh b/t/t9402-git-cvsserver-refs.sh
index 858ef0f..5138f14 100755
--- a/t/t9402-git-cvsserver-refs.sh
+++ b/t/t9402-git-cvsserver-refs.sh
@@ -28,27 +28,26 @@ check_file() {
}
check_end_tree() {
-sandbox=$1
-expectCount=$(wc -l $WORKDIR/check.list)
-cvsCount=$(find $sandbox -name CVS -prune -o -type f -print | wc -l)
-test x$cvsCount = x$expectCount
-stat=$?
-echo check_end $sandbox : $stat cvs=$cvsCount expect=$expectCount \
-$WORKDIR/check.log
-return $stat
+sandbox=$1
+wc -l $WORKDIR/check.list expected
+find $sandbox -type f | grep -v /CVS $WORKDIR/check.cvsCount
+wc -l $WORKDIR/check.cvsCount actual
+test_cmp expected actual
+ rm expected actual
+ sort $WORKDIR/check.list expected
+ sort $WORKDIR/check.cvsCount | sed -e s%cvswork/%%
actual
+test_cmp expected actual
+ rm expected actual
}
check_end_full_tree() {
-sandbox=$1
-ver=$2
-expectCount=$(wc -l $WORKDIR/check.list)
-cvsCount=$(find $sandbox -name CVS -prune -o -type f -print | wc -l)
-gitCount=$(git ls-tree -r $2 | wc -l)
-test x$cvsCount = x$expectCount -a x$gitCount = x$expectCount
-stat=$?
-echo check_end $sandbox : $stat cvs=$cvsCount git=$gitCount
expect=$expectCount \
-$WORKDIR/check.log
-return $stat
+sandbox=$1
+sort $WORKDIR/check.list expected
+find $sandbox -name CVS -prune -o -type f -print | sed -e
s%$sandbox/%% | sort act1
+ test_cmp expected act1
+git ls-tree -r $2 | sed -e s/^.*blob [0-9a-fA-F]*[ ]*// | sort
act2
+ test_cmp expected act2
+rm expected act1 act2
}
#
@@ -155,7 +154,8 @@ test_expect_success 'cvs co b1 [cvswork3]' '
test_expect_success 'edit cvswork3 and save diff' '
( cd cvswork3
- sed -i -e s/line1/line1 - data/ adir/afile
+ sed -e s/line1/line1 - data/ adir/afile adir/afileNEW
+ mv -f adir/afileNEW adir/afile
echo afile5 adir/afile5
rm t2
cvs -f add adir/afile5
@@ -168,7 +168,8 @@ test_expect_success 'setup v1.2 on b1' '
git checkout b1
echo new v1.2 t3
rm t2
-sed -i -e s/line3/line3 - more data/ adir/afile
+sed -e s/line3/line3 - more data/ adir/afile adir/afileNEW
+ mv -f adir/afileNEW adir/afile
rm adir/a2file
echo a3file adir/a3file
echo bfile line 3 adir/bdir/bfile
@@ -300,7 +301,8 @@ test_expect_success 'root dir rm file [cvswork2]' '
test_expect_success 'subdir edit/add/rm files [cvswork2' '
( cd cvswork2
- sed -i -e s/line 1/line 1 (v2)/ adir/bdir/bfile
+ sed -e s/line 1/line 1 (v2)/ adir/bdir/bfile adir/bdir/bfileNEW
+ mv -f adir/bdir/bfileNEW adir/bdir/bfile
rm adir/bdir/b2file
cd adir
cvs -f rm bdir/b2file
--
1.7.12
--
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: bare vs non-bare 1.7 then =1.7 ?
When experimenting in order to train some colleagues, I saw that If I clone a repository, I couldn't push to it because it was a non-bare one. Searchin for some explanations, I found this ressource: http://www.bitflop.com/document/111 That's just a precaution (technically it's not necessary, just stops you from doing some dumb things). Suppose the following scenario: * non-bare repository A, with branch 'master' currently checked out. * clone B - somebody's working on branch 'master' (which was forked from A's master) * on A, somebody did some local changes * meanwhile somebody pushes the branch 'master' from B to A * after that, on A, new commit to 'master'. Weird things can happen, eg. the changes coming from B completely reverted by the new commit in A. Unless nobody pushes to the branch currently checked and later somebody doing local changes after that, there shouldn't be any real technical problem. But then, you most likely wont need an worktree anyways. Wait, there *is* an usecase for such things, deploying trees (eg. webapps) some server: * application is developed in git * the final production-system tree is maintained in certian branch * a post-update hook acts on a specific production branch and does something like git checkout --detach treeish cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- 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: Support for a series of patches, i.e. patchset or changeset?
snip yet another idea: you coud always put your patchsets into separate branches, rebase them ontop target branch before merging, and then do an non-ff-merge, which will make the history look like: * merged origin/feature_foo |\ | * first preparation fo feature foo | * part a | * part b |/ * merged origin/bugfix_blah |\ | * fixing bug blah |/ * cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- 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
t9350-fast-export.sh broken on peff/pu under Mac OS X
The short version: echo -n doesn't seem to be portable. The following works for me: (And is this a typo: test_expect_success 'test biridectionality' ') /Torsten diff ../../git.peff/t/t9350-fast-export.sh t9350-fast-export.sh 444,445c444,445 echo -n marks-cur echo -n marks-new --- marks-cur marks-new 464c464 echo -n tmp-marks --- tmp-marks 474c474 echo -n expected --- expected -- 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
Do not add an empty value from config credential.helper
Below is current git message when a local config credential.helper has an empty value. Please skip an empty value. $ git push --force origin master git: 'credential-' is not a git command. See 'git --help'. Did you mean this? credential Total 0 (delta 0), reused 0 (delta 0) To https://u...@github.com/user/myrepo.git + d23aa6a...3405990 master - master (forced update) 0001-credential-do-not-recognize-a-credential-helper-if-c.patch Description: Binary data
overriding/removing inherited credential.helper
In credential.c, line 67: if (!strcmp(key, helper)) string_list_append(c-helpers, value); In global config, I add one credential helper. But I do not want to use any credential helper in a specific repository. Currently there is no way in local config to override and remove inherited credential helper. Of course, I do not want to change global config. Could you suggest a patch? -- 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: Bizarre problem cloning repo from Codeplex
Enrico Weigelt enrico.weig...@vnc.biz writes: Their webserver seems to be configured quite restrictively (eg. cannot access files like 'packed-refs'). Probably it just doesn't exist. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
http-backend GIT_COMMITTER_NAME -EMAIL documentation bug
Documentation says that envvars GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL formed from REMOTE_USER and REMOTE_ADDR, but doesn't mention that they are left alone if they have been set already. Referring to: https://github.com/git/git/blob/master/Documentation/git-http-backend.txt#L178 Source code says that they are set conditionally (referring to this part of the source): https://github.com/git/git/blob/master/http-backend.c#L335 And the (most recent) commit pertaining to this behavior explains the change: https://github.com/git/git/commit/e32a4581bcbf1cf43cd5069a0d19df07542d612a I'm also for the possibility of custom implementations assigning those envvars, so could the documentation be changed to reflect that? -- 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: What's cooking in git.git (Nov 2012, #02; Fri, 9)
kalle olavi niemitalo wrote: Jeff King p...@peff.net writes: Comments welcome from people using unusual editors (e.g., a script that starts an editor in another window then blocks, waiting for the user to finish). I often run a shell in Emacs in X, then start git commit in that shell. $EDITOR is emacsclient --current-frame, which asks the existing Emacs instance to load the file and waits until I press C-x # in Emacs to mark the file done. If I want to abort the commit, it is most intuitive to return to the *Shell* buffer in Emacs and press C-c C-c (comint-interrupt-subjob) to send SIGINT to git from there. (I see that an empty message aborts the commit, and indeed it does, but well, I prefer not to trust such a feature if I can instead just interrupt the thing.) With pf/editor-ignore-sigint, C-c C-c in the *Shell* buffer kills neither git nor the emacsclient started by git. This is not good. SIGQUIT from C-c C-\ (comint-quit-subjob) still works though. when i implemented the change, i wondered if some twisted emacs workflow would be an issue. ;-) and i almost blocked SIGQUIT as well -- the two programs i looked at for precedent (CVS and MH) both block both SIGQUIT and SIGINT when spawning an editor. but since emacs users must have dealt with CVS for a long time before dealing with git, how might they have done so? the existing git behavior is bad for non-emacs users, and git itself provides an abort-the-operation mechanism (i.e., writing an empty message), so i'm not convinced your use case invalidates the new behavior. (though it might spotlight a need for this being prominent in release notes.) paul =- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 40.6 degrees) -- 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-reset man page
On Sat, Nov 10, 2012 at 10:55:13AM +0100, Angelo Borsotti wrote: Hi the man page of git-reset, synopsys, does not allow for an argumentless call, and the description does not tell either what is the meaning of it. This issue was already reported by Bojan Petrović: http://thread.gmane.org/gmane.comp.version-control.git/208505 and fixed in commit d505865be5c7d72abb74318940e8c4c52aa0db5f (doc: git-reset: make mode optional) in master branch. git reset is equivalent to git reset --mixed. Suggested changes: first line of synopsis: gitt reset [-q] [commit] [ [--] pathspec ...] Description: append to the end of the first paragraph: If no pathspecs are specified, all the index entries are reset. I would suggest to change paths with pathspec in all the man page because paths in the glossary are called pathspecs. The paths issue seems to be bigger - path, paths and pathspec are mixed in whole manual: $ cat Documentation/*.txt | grep -o 'path[^]*' | sort | uniq -c | sort -n -r 125 path 17 paths 10 pathspec 2 pathtemplate 2 path-pattern 1 path_to 1 path_from In commands it's even worse: $ cat builtin/*.c | grep -o 'path[^]*' | sort | uniq -c | sort -n -r 14 path 15 paths Note: path is not always used for pathspec. In git-checkout manual in synopsis paths is used, but in description pathspec. Maybe we should just add that paths is an shortcut for pathspec and fix places where paths and pathspec are mixed or path is used as pathspec. Thanks, Krzysiek -- 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: Help requested - trying to build a tool doing whole-tree commits
Unknown unknown@unknown.invalid writes: (Apologies if this arrives twice. I'm on the road, with somewhat flaky email.) Because of my work on reposurgeon, I am sometimes asked to produce git repositories for very old projects that not only are still using CVS but have ancient releases not in the CVS repository, preserved only as tarballs. Perhaps not exactly what you are looking for, but don't we have import-tar somewhere in contrib/fast-import hierarchy (sorry, not on a machine yet, and I cannot give more details). -- 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: What's cooking in git.git (Nov 2012, #02; Fri, 9)
Jeff King p...@peff.net writes: On Fri, Nov 09, 2012 at 12:27:35PM -0800, Junio C Hamano wrote: What we should have arranged was to have https://github.com/git/git (which is not even owned by me, but I asked somebody at GitHub to assign me a write privilege) writable by the interim maintainer, so that normal people would keep pulling from there, while the interim maintainer can choose to publish broken-out branches to his repository. Yes, I have write access to that repository, too, but I intentionally held off from updating it out of a sense of nervousness. I figured if I screwed up anything too badly, people who were clued-in enough to switch to pulling from my repository would be clued-in enough to rebase across any too-horrible mistake I made. ;) That nervousness reminds me of myself when I took over. Before I could ask for a few weeks of practice period, Linus arranged to have folks at k.org to chown the authoritative location to me, declaring no practice period; it's already done and it's all yours. And I made at least one mistake pushing 'master' with one commit rewound too much (corrected by pushing an extra merge). Luckily, the world did not end ;-). I think if we do this again, I will make the same split you do (git/git for integration branches, peff/git as a mirror of my private repo). I am fairly sure I'll have to ask you (or somebody else) again next year around late September. And it is not too late to do so; from the look of your What's cooking, you are doing pretty well ;-). Any fool can merge topics to master. The real test will be how many regressions people report in the next two weeks. :) I agree that the actual merging to 'master' is mechanical with the procedure built around Meta/Reintegrate. Important decisions are made before you merge a topic to 'next' and mark topics as Will merge to 'master'. My comment was about that, and your responses to the list messages. By the way, I did not touch 'maint' at all while you were gone. I don't know what your usual method is for keeping track of maint-worthy topics after they have gone to master. The usual what's cooking workflow keeps track of things going to master, but no more; I'd guess you probably just merge to maint when you delete them from last cycle's graduated to master list. That is done by eyeballing output from Meta/GRADUATED (which spits out something that could be fed to shell, but I do not fully trust its logic, and always eyeball them before I prepare the temporary file to feed Meta/Reintegrate to update 'maint'). -- 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: RFD: fast-import is picky with author names (and maybe it should - but how much so?)
Felipe Contreras venit, vidit, dixit 09.11.2012 15:34: On Fri, Nov 9, 2012 at 10:28 AM, Michael J Gruber g...@drmicha.warpmail.net wrote: Hg seems to store just anything in the author field (committer). The various interfaces that are floating around do some behind-the-back conversion to git format. The more conversions they do, the better they seem to work (no erroring out) but I'm wondering whether it's really a good thing, or whether we should encourage a more diligent approach which requires a user to map non-conforming author names wilfully. So you propose that when somebody does 'git clone hg::hg hg-git' the thing should fail. I hope you don't think it's too unbecoming for me to say that I disagree. There is no need to disagree with a proposal I haven't made. I would disagree with the proposal that I haven't made, too. IMO it should be git fast-import the one that converts these bad authors, not every single tool out there. Maybe throw a warning, but that's all. Or maybe generate a list of bad authors ready to be filled out. That way when a project is doing a real conversion, say, when moving to git, they can run the conversion once and see which authors are bad and not multiple times, each try taking longer than the next. As Jeff pointed out, git-fast-import expects output conforming to a certain standard, and that's not going to change. import is agnostic to where its import stream is coming from. Only the producer of that stream can have additional information about the provenience of the stream's data which may aid (possibly together with user input or choices) in transforming that into something conforming. Michael -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
old folders returning
Issue: I renamed a deprecated folder that i needed the code for, added .old to name. I then pushed to the repository and the original folder and the newly renamed are now in the repository and on my local branch. I renamed 'autoflow' to 'autoflow.old' and worked away ok. But after the push I now have both of the folders with duplicate files. The 'autoflow' folder that has appeared is also from an earlier push this morning 1038 its now 1727 Re-Create: No idea how to as its the first time I've seen this. But the output from the push is: git push origin autoflow Counting objects: 267, done. Delta compression using up to 4 threads. Compressing objects: 100% (132/132), done. Writing objects: 100% (146/146), 140.69 KiB, done. Total 146 (delta 76), reused 1 (delta 0) To g...@github.com:cityindex/labs.cityindex.com.git 8ea3cd9..7e6ff4f autoflow - autoflow Cause: -- The only suggestion I can think of is that the name wasn't cleared after the git add * and then git went looking for an earlier copy. But seems the issue is with the git client as well because of the modified time. If it were pulled then the modified time would've changed, so it must have been taken from an earlier commit on my local branch. System: $ git --version git version 1.7.9.5 $ cat /etc/*release* DISTRIB_ID=Ubuntu DISTRIB_RELEASE=12.04 DISTRIB_CODENAME=precise DISTRIB_DESCRIPTION=Ubuntu 12.04.1 LTS $ uname -a Linux daithi-laptop 3.2.0-32-generic #51-Ubuntu SMP Wed Sep 26 21:33:09 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux -- Any society that would give up a little liberty to gain a little security, will deserve neither and lose both. - Benjamin Franklin -- 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: old folders returning
Hi, In article can4prmavggqn3zm1atde5cadjszzlovpoqasjrzfuvrkrqs...@mail.gmail.com, David Coombeswebe...@gmail.com wrote: The only suggestion I can think of is that the name wasn't cleared after the git add * and then git went looking for an earlier copy. But seems the issue is with the git client as well because of the modified time. If it were pulled then the modified time would've changed, so it must have been taken from an earlier commit on my local branch. Did you git rm the 'old' name of the folder? Andy -- 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: What's cooking in git.git (Oct 2012, #09; Mon, 29)
Jeff King wrote: On Fri, Nov 02, 2012 at 09:33:14PM +, Ramsay Jones wrote: (Linux is my main platform, but I like to keep cygwin working because it has kept me sane on Windows ever since (about) 1995 ...) Stranger in a strange land ;-) I used a different trick around the same time to keep me sane from Windows, but I think it involved dd and /dev/zero... ;-) That's a solution I would have been keen to try, but my employer at the time would not have liked that idea ... This patch fixes the test for me. Great. I was guessing blindly when I wrote it, but having seen the perl bug above, it all makes sense. We should probably wrap it. I'm planning to queue this on top of Chris's patch: Unfortunately, I haven't had time yet to test this patch. (Early this week, I went into hospital for a minor surgical procedure - I have not yet fully recovered). The patch looks good and I don't anticipate any problems. I will hopefully test it soon (I see it's in pu now) and let you know. [snip patch] ATB, Ramsay Jones -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] remote-curl.c: Fix a gcc warning
In particular, gcc complains as follows: CC remote-curl.o remote-curl.c: In function `rpc_service': remote-curl.c:403: warning: 'gzip_size' might be used uninitialized \ in this function The 'gzip_size' variable would not, in fact, be used uninitialized. However, in order to suppress the warning, we simply initialize the variable to zero in it's declaration. Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk --- Hi Jeff, Could you please squash this into commit df126e108 (remote-curl: hoist gzip buffer size to top of post_rpc, 31-10-2012), which is part of your 'jk/maint-http-half-auth-fetch' branch. Thanks! ATB, Ramsay Jones remote-curl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/remote-curl.c b/remote-curl.c index d8b3600..9a8b123 100644 --- a/remote-curl.c +++ b/remote-curl.c @@ -400,7 +400,7 @@ static int post_rpc(struct rpc_state *rpc) struct curl_slist *headers = NULL; int use_gzip = rpc-gzip_request; char *gzip_body = NULL; - size_t gzip_size; + size_t gzip_size = 0; int err, large_request = 0; /* Try to load the entire request, if we can fit it into the -- 1.8.0 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFD: fast-import is picky with author names (and maybe it should - but how much so?)
On Sat, Nov 10, 2012 at 6:28 PM, Michael J Gruber g...@drmicha.warpmail.net wrote: Felipe Contreras venit, vidit, dixit 09.11.2012 15:34: On Fri, Nov 9, 2012 at 10:28 AM, Michael J Gruber g...@drmicha.warpmail.net wrote: Hg seems to store just anything in the author field (committer). The various interfaces that are floating around do some behind-the-back conversion to git format. The more conversions they do, the better they seem to work (no erroring out) but I'm wondering whether it's really a good thing, or whether we should encourage a more diligent approach which requires a user to map non-conforming author names wilfully. So you propose that when somebody does 'git clone hg::hg hg-git' the thing should fail. I hope you don't think it's too unbecoming for me to say that I disagree. There is no need to disagree with a proposal I haven't made. I would disagree with the proposal that I haven't made, too. All right, we shouldn't encourage a more diligent approach which requires a user to map author names then. IMO it should be git fast-import the one that converts these bad authors, not every single tool out there. Maybe throw a warning, but that's all. Or maybe generate a list of bad authors ready to be filled out. That way when a project is doing a real conversion, say, when moving to git, they can run the conversion once and see which authors are bad and not multiple times, each try taking longer than the next. As Jeff pointed out, git-fast-import expects output conforming to a certain standard, and that's not going to change. import is agnostic to where its import stream is coming from. Only the producer of that stream can have additional information about the provenience of the stream's data which may aid (possibly together with user input or choices) in transforming that into something conforming. We already know where the import of those streams come from: mercurial, bazaar, etc. There's absolutely nothing the tools exporting data from those repositories can do, except try to convert all kind of weird names--and many tools do it poorly. So, the options are: a) Leave the name conversion to the export tools, and when they miss some weird corner case, like 'Author email', let the user face the consequences, perhaps after an hour of the process. We know there are sources of data that don't have git-formatted author names, so we know every tool out there must do this checking. In addition to that, let the export tool decide what to do when one of these bad names appear, which in many cases probably means do nothing, so the user would not even see that such a bad name was there, which might not be what they want. b) Do the name conversion in fast-import itself, perhaps optionally, so if a tool missed some weird corner case, the user does not have to face the consequences. The tool writers don't have to worry about this, so we would not have tools out there doing a half-assed job of this. And what happens when such bad names end up being consistent: warning, a scaffold mapping of bad names, etc. One is bad for the users, and the tools writers, only disadvantages, the other is good for the users and the tools writers, only advantages. -- Felipe Contreras -- 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 1/3] git-submodule add: Add -r/--record option
On Thu, Nov 08, 2012 at 11:34:54PM -0800, Junio C Hamano wrote: W. Trevor King wk...@tremily.us writes: By remaining agnostic on the variable usage, this patch makes submodule setup more convenient for all parties. I personally do not think remaining agnostic on the usage is a good thing, at least for any option to commands at the higher level on the stack, such as git submodule. I am afraid that giving an easier way to set up a variable with undefined semantics may make setup more confusing for all parties. One party gives one specific meaning to the field, while another party uses it for something slightly different. I would not object to git config submodule.$name.branch $value, on the other hand. git config can be used to set a piece of data that has specific meaning, but as a low-level tool, it is not _limited_ to variables that have defined meaning. This is what I'm doing now: $ git submodule add -b branch repo path $ git config --file .gitmodules submodule.path.branch branch $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) git pull' With my second patch (Phil's config export), that becomes $ git submodule add -b branch repo path $ git config --file .gitmodules submodule.path.branch branch $ git submodule foreach 'git checkout $submodule_branch git pull' With my first patch, that becomes $ git submodule add -rb branch repo path $ git submodule foreach 'git checkout $submodule_branch git pull' This seems pretty useful to me, but I'm still using submodule.name.branch explicitly as a user, and Git is not interpreting the option directly. Users are free to store whatever they like in that option, and use it however they wish: $ git submodule foreach 'do-crazy-stuff.sh $submodule_branch' If we need a semantic interpretation to justify -r/--record, everyone that's chimed in so far has agreed on the same interpretation. I wouldn't be averse to $ git submodule add -rb branch repo path $ git submodule pull-branch which makes the foreach pull logic internal. However, there has been a reasonable amount of resistance to this workflow in the past, so I thought that a patch series that avoided a semantic interpretation would be more acceptable. If neither an agnostic -r/--record or a semantic pull-branch command are acceptable, I suppose we'll have to drop my first and third patches and only keep the second. Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -- 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: What's cooking in git.git (Nov 2012, #02; Fri, 9)
SZEDER Gábor sze...@ira.uka.de writes: I think it is better to keep the tests simple and maintainable. Maintainable? There is nothing to maintain here ... OTOH, this series has some serious drawbacks. It makes debugging more difficult Are these referring to the same aspect of the series? The concern you described about debuggability matches my impression IIRC back when I took a look at the series, which I would count as a large part of keeping tests maintainable. But you may be referring to something different (sorry, not on my primary machine yet). -- 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] [PATCH] git tag --contains : avoid stack overflow
From: Jean-Jacques Lafay jeanjacques.la...@gmail.com Sent: Saturday,
November 10, 2012 5:36 PM
In large repos, the recursion implementation of contains(commit,
commit_list)
may result in a stack overflow. Replace the recursion with a loop to
fix it.
Signed-off-by: Jean-Jacques Lafay jeanjacques.la...@gmail.com
This is a change to the main git code so it is better to submit it to
the main git list at git@vger.kernel.org (plain text, no HTML, first
post usually has a delay ;-)
It sounds reasonable but others may have opinions and comments.
Have you actually suffered from the stack overflow issue? You only
suggest it as a possibility, rather than a real problem.
Philip
---
builtin/tag.c | 83
--
t/t7004-tag.sh | 21 +++
2 files changed, 78 insertions(+), 26 deletions(-)
diff --git a/builtin/tag.c b/builtin/tag.c
index 9c3e067..4be67dd 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -73,40 +73,71 @@ static int in_commit_list(const struct commit_list
*want, struct commit *c)
return 0;
}
-static int contains_recurse(struct commit *candidate,
- const struct commit_list *want)
-{
- struct commit_list *p;
-
- /* was it previously marked as containing a want commit? */
- if (candidate-object.flags TMP_MARK)
- return 1;
- /* or marked as not possibly containing a want commit? */
- if (candidate-object.flags UNINTERESTING)
- return 0;
- /* or are we it? */
- if (in_commit_list(want, candidate))
- return 1;
+struct commit_list_list {
+ struct commit *item;
+ struct commit_list *next_item;
+ struct commit_list_list *next;
+};
- if (parse_commit(candidate) 0)
- return 0;
+static void mark_path(struct commit_list_list *path, int status)
+{
+ struct commit_list_list *temp;
+ while (path) {
+ path-item-object.flags |= status;
+ temp = path;
+ path = temp-next;
+ free(temp);
+ }
+}
- /* Otherwise recurse and mark ourselves for future traversals. */
- for (p = candidate-parents; p; p = p-next) {
- if (contains_recurse(p-item, want)) {
- candidate-object.flags |= TMP_MARK;
+static int contains(struct commit *candidate,
+ const struct commit_list *want)
+{
+ /* previously implemented with a recursion, but could stack overflow
in large repos */
+ struct commit_list_list *p, *tmp;
+ p = xmalloc(sizeof(struct commit_list_list));
+ p-item = candidate;
+ p-next_item = NULL;
+ p-next = NULL;
+
+ while (p) {
+ candidate = p-item;
+
+ /* is it ok : */
+ /* was it previously marked as containing a want commit? */
+ /* or are we it? */
+ if (candidate-object.flags TMP_MARK || in_commit_list(want,
candidate)) {
+ mark_path(p, TMP_MARK);
return 1;
}
+ /* is it not ok : */
+ /* was it previously marked as not possibly containing a want
commit? */
+ /* do we have parents? */
+ if (candidate-object.flags UNINTERESTING ||
parse_commit(candidate) 0 || !candidate-parents) {
+ candidate-object.flags |= UNINTERESTING;
+ /* then backtrack, marking as UNINTERESTING along the way */
+ while (p !p-next_item) {
+ p-item-object.flags |= UNINTERESTING;
+ tmp = p;
+ p = tmp-next;
+ free(tmp);
+ }
+ if (p) {
+ p-item = p-next_item-item;
+ p-next_item = p-next_item-next;
+ }
+ } else {
+ /* let's check the parents */
+ tmp = xmalloc(sizeof(struct commit_list_list));
+ tmp-item = candidate-parents-item;
+ tmp-next_item = candidate-parents-next;
+ tmp-next = p;
+ p = tmp;
+ }
}
- candidate-object.flags |= UNINTERESTING;
return 0;
}
-static int contains(struct commit *candidate, const struct
commit_list *want)
-{
- return contains_recurse(candidate, want);
-}
-
static void show_tag_lines(const unsigned char *sha1, int lines)
{
int i;
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index 5189446..196ac54 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -1365,4 +1365,25 @@ test_expect_success 'multiple --points-at are
OR-ed together' '
test_cmp expect actual
'
+# what about a deep repo ?
+
+expect
+test_expect_success '--contains works in a deep repo' '
+ i=1
+ while test $i -lt 4
+ do
+ echo commit refs/heads/master
+committer A U Thor aut...@example.com $((10 + $i * 100))
+0200
+data EOF
+commit #$i
+EOF
+ test $i == 1 echo from refs/heads/master^0
+ i=$(($i + 1))
+ done | git fast-import
+ git checkout master
+ git tag far-far-away HEAD^
+ git tag --contains HEAD actual
+ test_cmp expect actual
+'
+
test_done
--
1.8.0.msysgit.0.1.geed93bd.dirty
--
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-reset man page
Krzysztof Mazur krzys...@podlesie.net writes: Maybe we should just add that paths is an shortcut for pathspec and fix places where paths and pathspec are mixed or path is used as pathspec. We should unify uses of paths and path (the former should be path... or something). Some places you need to give exact path (iow, these places you cannot use pathspec), while most other places pathspec (i.e. matching pattern) is accepted. The manual correctly updated will most likely to use both path and pathspec appropriately. -- 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-reset man page
On Sat, Nov 10, 2012 at 12:02:12PM -0800, Junio C Hamano wrote: Krzysztof Mazur krzys...@podlesie.net writes: Maybe we should just add that paths is an shortcut for pathspec and fix places where paths and pathspec are mixed or path is used as pathspec. We should unify uses of paths and path (the former should be path... or something). Currently in most cases paths... is used ;) Some places you need to give exact path (iow, these places you cannot use pathspec), while most other places pathspec (i.e. matching pattern) is accepted. I know, thats why I added a note that path is not always used for pathspec. The manual correctly updated will most likely to use both path and pathspec appropriately. So we should always use path for exact path, and pathspec for pathspecs patterns as defined in gitglossary. I think it's better to avoid paths and always use path... or pathspec Krzysiek -- 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: What's cooking in git.git (Nov 2012, #02; Fri, 9)
Kalle Olavi Niemitalo k...@iki.fi writes: With strace, it looks like CVS sets SIG_IGN as the handler of SIGINT and SIGQUIT only in the parent process after forking, not in the child process that executes the editor. CVS also temporarily blocks signals by calling sigprocmask, but it undoes that before it forks or waits for the child process. This emulates what system(3) does. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] [PATCH] git tag --contains : avoid stack overflow
On 10 November 2012 21:13, Jean-Jacques Lafay jeanjacques.la...@gmail.com wrote: Le samedi 10 novembre 2012 21:00:10 UTC+1, Philip Oakley a écrit : From: Jean-Jacques Lafay jeanjacq...@gmail.com Sent: Saturday, November 10, 2012 5:36 PM In large repos, the recursion implementation of contains(commit, commit_list) may result in a stack overflow. Replace the recursion with a loop to fix it. Signed-off-by: Jean-Jacques Lafay jeanjacq...@gmail.com This is a change to the main git code so it is better to submit it to the main git list at g...@vger.kernel.org (plain text, no HTML, first post usually has a delay ;-) It sounds reasonable but others may have opinions and comments. Have you actually suffered from the stack overflow issue? You only suggest it as a possibility, rather than a real problem. Philip Yes, it actually crashed on me, and since the call is made by GitExtension while browsing the commit history, it was quickly annoying to have windows popping a git.exe stopped working message box at my face every time I clicked on a line of the history ;-) (well, you can sort of work around it by having the file tree or diff tab active) Coincidentally, as I was having a glance at the recent topics, I saw that someone else experienced it. However, I couldn't reproduce it on Linux : where the windows implementations crashes at a ~32000 depth (*not* exactly 32768, mind you), on linux it happily went through 10 commits. I didn't take time to look much further, but maybe on my 64 bit Linux VM, the process can afford to reserve a much bigger address range for the stack of each thread than the 1Mb given to 32 bit processes on windows. Jean-Jacques. I checked this on msysGit - the test causes a crash on Windows when using the 1.8.0 release and recompiling with this patch applied fixes this. As mentioned, its best to have this reviewed upstream too as its likely that windows just has a smaller stack so causes the crash earlier. -- 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: t5801-remote-helpers.sh fails
On Sat, Nov 10, 2012 at 8:20 PM, Torsten Bögershausen tbo...@web.de wrote: On 11/10/2012 08:15 PM, Felipe Contreras wrote: Hi, On Sat, Nov 10, 2012 at 2:48 PM, Torsten Bögershausen tbo...@web.de wrote: on peff/pu t5801 fails, the error is in git-remote-testgit, please see below. That's on my Mac OS X box. I haven't digged further into the test case, but it looks as if [-+]A make NAMEs associative arrays is not supported on this version of bash. /Torsten /Users/tb/projects/git/git.peff/git-remote-testgit: line 64: declare: -A: invalid option declare: usage: declare [-afFirtx] [-p] [name[=value] ...] /Users/tb/projects/git/git.peff/git-remote-testgit: line 66: refs/heads/master: division by 0 (error token is /master) error: fast-export died of signal 13 fatal: Error while running fast-export What is your bash --version? bash --version GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin10.0) Copyright (C) 2007 Free Software Foundation, Inc. I see, that version indeed doesn't have associative arrays. On the other hand, Documentation/CodingGuidelines says: - No shell arrays. Yeah, for shell code I guess, but this is bash code. Could we use perl to have arrays? I think the code in perl would be harder to follow, and this is meant not only as a test, but also as a reference. I'm not exactly sure what we should do here: a) remove the code (would not be so good as a reference) b) enable the code conditionally based on the version of bash (harder to read) c) replace the code without associative arrays (will be much more complicated and ugly) d) add a check for the bash version to the top of the test in t/ I'm leaning towards d), followed by b). If only there was a clean way to do this, so c) would not be so ugly. After investigating different optins this seems to be the best: join -e empty -o '0 1.2 2.2' -a 2 (echo $before) (echo $after) | while read e a b; do test $a == $b continue echo changed $e done But to me seems a bit harder to grasp. Not sure. Cheers. -- Felipe Contreras -- 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: What's cooking in git.git (Nov 2012, #02; Fri, 9)
kalle olavi niemitalo wrote: Paul Fox p...@foxharp.boston.ma.us writes: when i implemented the change, i wondered if some twisted emacs workflow would be an issue. ;-) and i almost blocked SIGQUIT as well -- the two programs i looked at for precedent (CVS and MH) both block both SIGQUIT and SIGINT when spawning an editor. but since emacs users must have dealt with CVS for a long time before dealing with git, how might they have done so? I think I usually ran CVS via vc.el, which prompts for a commit message in Emacs before it runs cvs commit. So CVS did not need to run $EDITOR. I just tried emacsclient with CVS 1.12.13-MirDebian-9, and it behaves somewhat differently from Git with pf/editor-ignore-sigint. When I tell Emacs to send SIGINT to the *Shell* buffer, CVS prompts: cvs commit: warning: editor session failed Log message unchanged or not specified a)bort, c)ontinue, e)dit, !)reuse this message unchanged for remaining dirs Action: (continue) you're sending SIGINT to the cvs commit command, and that causes the editor to die right away? that's surprising. i can replicate your described behavior by setting $VISUAL to a script that just sleeps, and sending SIGTERM to the cvs commit process. but not by sending SIGINT. well, i'm not sure what to say. there's a real problem when using the current code and traditional editors. i thought that the patch in pf/editor-ignore-sigint reflected standard practice, and indeed it accomplishes exactly the right thing with those editors. you've shown a particular work flow involving emacsclient that won't work anymore with the change made, though there are workarounds. perhaps there's something the other editors themselves should be doing differently, but i don't know what that might be. paul and then I can choose to abort. With strace, it looks like CVS sets SIG_IGN as the handler of SIGINT and SIGQUIT only in the parent process after forking, not in the child process that executes the editor. CVS also temporarily blocks signals by calling sigprocmask, but it undoes that before it forks or waits for the child process. =- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 45.5 degrees) -- 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: Reviews on mailing-list
On Sun, Nov 11, 2012 at 12:19 AM, Deniz Türkoglu de...@spotify.com wrote: This is my first mail to the git mailing list. I have been following the list for some time now and I would like to suggest moving the reviews out of the mailing list, for example to a gerrit instance, I believe it would improve the commits and the mailing list. I have a filter on 'PATCH', but I feel I miss some of the discussion, and things that I would be interested in. I have spoken to Shawn Pearce (gerrit project lead, google) and he said he is OK with hosting the gerrit instance. I would like to hear your thoughts on this. Personally I think reviews on the mailing list is far superior than any other review methods. I've even blogged about it and all the reasons[1]. Gerrit is better than bugzilla, but it still requires a web browser, and logging in. I love to be able to just hit 'reply' with my favorite MUA, comment inline, and hit send. Cheers. [1] http://felipec.wordpress.com/2010/01/19/why-bugzilla-sucks-for-handling-patches/ -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-credential-gnome-keyring: Remove die
git-credential-gnome-keyring defines die, but it is unused and
incorrect (it passes a va_list to error, which does not expect one),
so remove it.
Signed-off-by: Matt Kraai kr...@ftbfs.org
---
.../credential/gnome-keyring/git-credential-gnome-keyring.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
index 41f61c5..3eaafba 100644
--- a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
+++ b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
@@ -104,16 +104,6 @@ static inline void error(const char *fmt, ...)
va_end(ap);
}
-static inline void die(const char *fmt, ...)
-{
- va_list ap;
-
- va_start(ap,fmt);
- error(fmt, ap);
- va_end(ap);
- exit(EXIT_FAILURE);
-}
-
static inline void die_errno(int err)
{
error(%s, strerror(err));
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t9350-fast-export.sh broken on peff/pu under Mac OS X
On 11/11/2012 12:11 AM, Felipe Contreras wrote:
On Sat, Nov 10, 2012 at 11:39 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Sat, Nov 10, 2012 at 3:37 PM, Torsten Bögershausen tbo...@web.de wrote:
The short version:
echo -n doesn't seem to be portable.
The following works for me:
Right, I was supposed to change that to:
true marks-cur
Please make it like so:
marks-cur
No command is necessary when creating an empty file or truncating an
existing file to empty, and no SP between redirection and its target.
That hangs on zsh (presumably waiting for stdin).
Unless you set:
NULLCMD=:
early in your test script.
Or, to be extra-safe, you could steal this initialization code from
autoconf:
# Be more Bourne compatible.
if test -n ${ZSH_VERSION+set} (emulate sh) /dev/null 21; then
emulate sh
NULLCMD=:
setopt NO_GLOB_SUBST
# Pre-4.2 versions of Zsh do word splitting on ${1+$@}, which
# is contrary to our usage. Disable this feature.
alias -g '${1+$@}'='$@'
else
case `(set -o) 2/dev/null` in *posix*) set -o posix ;; esac
fi
All of this untested with the real Git testsuite, of course ;-)
Regards, and HTH,
Stefano
--
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: t9350-fast-export.sh broken on peff/pu under Mac OS X
On Sun, Nov 11, 2012 at 1:19 AM, Stefano Lattarini
stefano.lattar...@gmail.com wrote:
On 11/11/2012 12:11 AM, Felipe Contreras wrote:
On Sat, Nov 10, 2012 at 11:39 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Sat, Nov 10, 2012 at 3:37 PM, Torsten Bögershausen tbo...@web.de
wrote:
The short version:
echo -n doesn't seem to be portable.
The following works for me:
Right, I was supposed to change that to:
true marks-cur
Please make it like so:
marks-cur
No command is necessary when creating an empty file or truncating an
existing file to empty, and no SP between redirection and its target.
That hangs on zsh (presumably waiting for stdin).
Unless you set:
NULLCMD=:
early in your test script.
Or, to be extra-safe, you could steal this initialization code from
autoconf:
# Be more Bourne compatible.
if test -n ${ZSH_VERSION+set} (emulate sh) /dev/null 21; then
emulate sh
NULLCMD=:
setopt NO_GLOB_SUBST
# Pre-4.2 versions of Zsh do word splitting on ${1+$@}, which
# is contrary to our usage. Disable this feature.
alias -g '${1+$@}'='$@'
It doesn't seem like zsh listens to that variable in sh mode:
% zsh -c 'emulate sh; NULLCMD=foobar; content'
And it doesn't seem like NO_GLOB_SUBST is needed any more.
I think it doesn't hurt to do 'true marks-cur', but whatever.
Cheers.
--
Felipe Contreras
--
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: Reviews on mailing-list
On Sat, Nov 10, 2012 at 9:40 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Sun, Nov 11, 2012 at 12:19 AM, Deniz Türkoglu de...@spotify.com wrote: This is my first mail to the git mailing list. I have been following the list for some time now and I would like to suggest moving the reviews out of the mailing list, for example to a gerrit instance, I believe it would improve the commits and the mailing list. I have a filter on 'PATCH', but I feel I miss some of the discussion, and things that I would be interested in. I have spoken to Shawn Pearce (gerrit project lead, google) and he said he is OK with hosting the gerrit instance. I would like to hear your thoughts on this. Personally I think reviews on the mailing list is far superior than any other review methods. I've even blogged about it and all the reasons[1]. Gerrit is better than bugzilla, but it still requires a web browser, and logging in. Requiring a web browser is a huge requirement, ham?? How come that can be an impediment to move forward way of this awkward way of reviewing patches through email? Switching to Gerrit would mean everyone would be using the same tool instead of anyone using its own email client (gmail, mutt, thunderbird, whatever...) and having to figure out git format-patch, git send-email (--reply-to where?). There are a lot of issues of having to use email for reviewing patches that I think Gerrit is a superior alternative. And many people are arguing for it! Let's move on... -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Reviews on mailing-list
On Sat, Nov 10, 2012 at 3:40 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Sun, Nov 11, 2012 at 12:19 AM, Deniz Türkoglu de...@spotify.com wrote: This is my first mail to the git mailing list. I have been following the list for some time now and I would like to suggest moving the reviews out of the mailing list, for example to a gerrit instance, I believe it would improve the commits and the mailing list. I have a filter on 'PATCH', but I feel I miss some of the discussion, and things that I would be interested in. I have spoken to Shawn Pearce (gerrit project lead, google) and he said he is OK with hosting the gerrit instance. I would like to hear your thoughts on this. Personally I think reviews on the mailing list is far superior than any other review methods. I've even blogged about it and all the reasons[1]. Gerrit is better than bugzilla, but it still requires a web browser, and logging in. I disagree that the current approach is optimal. Bugzilla is a bug-tracker and is not meant to be used for reviews. I believe in using the right tool for the right job. An e-mail should be concise and to the point, in this case only contain the discussion. This will help it to reach a wider audience and be more useful when people stumble upon it through a google search. cheers, -deniz -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/6] Color skipped tests blue
On Fri, Sep 21, 2012 at 02:13:25AM -0400, Jeff King wrote:
On Wed, Sep 19, 2012 at 09:24:23PM +0100, Adam Spiers wrote:
t/test-lib.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 5293830..78c88c2 100755
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -182,13 +182,13 @@ then
error)
tput bold; tput setaf 1;; # bold red
skip)
- tput bold; tput setaf 2;; # bold green
+ tput setaf 4;;# blue
warn)
tput bold; tput setaf 3;; # bold yellow
pass)
tput setaf 2;;# green
info)
- tput setaf 3;;# brown
+ tput setaf 3;;# yellow/brown
I happened to be running a test script with -v earlier today, and I
noticed that the expecting success... dump of the test contents is
also yellow. By your new rules, shouldn't it be blue?
I think it is matching the info type, which from the discussion should
be blue, no?
It uses the default colour:
say 3 expecting success: $2
where say is defined:
say () {
say_color info $*
}
Many other messages are output in this default colour too, and I never
proposed to change it. The only time in the discussion where blue was
associated with info was in this sentence I wrote in the
commit message for the patch altering the colour of skip messages:
However, it's more informational than cautionary, so instead we
use blue which is a universal color for information signs.
Whilst it could also be applied to info, I don't think it would be a
good idea to have the skip and info colours *both* as bold blue.
It seems to me more important that the skip messages should visually
stand out more than info, since they are rarer and a more notable
level of information than the latter (especially if --verbose is
used). Additionally, yellow is already somewhat overloaded (yellow
for info and bold yellow for warn). Therefore I would suggest
changing info to perhaps bold white or bold cyan. Or skip could
be magenta and info blue. But now we are heading down a slippery
slope; it'll be near impossible to please everyone. Any final
thoughts?
Maybe it is just my terminal. I see it is labeled as brown here, but
it looks very yellow (and I am using the stock xterm colors. According
to:
https://en.wikipedia.org/wiki/ANSI_colors
It looks it really is brown on some platforms.
Yes, it can be.
I'm not sure if it is
worth worrying about. I don't really want to get into configurable
colors just for the test-suite output.
Agreed. There is no indisputably correct combination. However, I
think that, modulo a tweak for the above, we are definitely in the
right ball park. The main thing is that the traffic light colour
scheme is adhered to, and that different types of message are clearly
visually separated, with more important ones standing out more than
less important ones.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] gitweb: git_summary - show $project in title
Gitweb pages are structured by divs of class title with grey background.
The shortlog, and the log page show the project name as the first title.
Page summary only shows an empty grey box above the project details.
This provides an inconstent user experience.
This patch adds the missing project title.
Signed-off-by: Henrich Schuchardt xypron.g...@gmx.de
---
gitweb/gitweb.perl |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 10ed9e5..3e1c452 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6451,7 +6451,7 @@ sub git_summary {
git_header_html();
git_print_page_nav('summary','', $head);
- print div class=\title\nbsp;/div\n;
+ print div class=\title\$project/div\n;
print table class=\projects_list\\n .
tr id=\metadata_desc\tddescription/tdtd .
esc_html($descr) . /td/tr\n;
unless ($omit_owner) {
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Reviews on mailing-list
Thiago Farina tfrans...@gmail.com wrote: Requiring a web browser is a huge requirement, ham?? No, but requiring reviews and discussions typed in the browser is. Pardon terseness, typo and HTML from a tablet. -- 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: What's cooking in git.git (Nov 2012, #02; Fri, 9)
Paul Fox p...@foxharp.boston.ma.us writes: you're sending SIGINT to the cvs commit command, and that causes the editor to die right away? That's right. It is not a quirk of shell-mode in Emacs, because I get the same result with ^C in xterm too. % EDITOR=$HOME/prefix/x86_64-unknown-linux-gnu/bin/emacsclient --current-frame % export EDITOR % cvs commit BUGIT Waiting for Emacs...^Ccvs commit: warning: editor session failed Log message unchanged or not specified a)bort, c)ontinue, e)dit, !)reuse this message unchanged for remaining dirs Action: (continue) a cvs [commit aborted]: aborted by user % While cvs was waiting from emacsclient: % cat /proc/2030/stat 2030 (cvs) S 1849 2030 1849 34816 2030 4202496 598 0 0 0 0 0 0 0 20 0 1 0 94752537 34254848 410 18446744073709551615 140168182550528 140168183348316 140737407935424 140737407931680 140168163193950 0 0 6 20513 0 0 0 17 2 0 0 0 0 0 % grep 'Name\|Pid\|Sig' /proc/2030/status Name: cvs Pid:2030 PPid: 1849 TracerPid: 0 SigQ: 0/28998 SigPnd: SigBlk: SigIgn: 0006 SigCgt: 000180005021 % cat /proc/2031/stat 2031 (emacsclient) S 2030 2030 1849 34816 2030 4202496 155 0 0 0 0 0 0 0 20 0 1 0 94752538 4169728 81 18446744073709551615 4194304 4210620 140735996104016 140735996095456 140664960886018 0 0 0 0 0 0 0 17 1 0 0 0 0 0 % grep 'Name\|Pid\|Sig' /proc/2031/status Name: emacsclient Pid:2031 PPid: 2030 TracerPid: 0 SigQ: 0/28998 SigPnd: SigBlk: SigIgn: SigCgt: % which I interpret to mean both processes were in process group 2030, the cvs process ignored SIGINT and SIGQUIT, the emacsclient process neither ignored nor handled any signals, and neither process blocked any signals (not even SIGCHLD as system(3) would). When ^C in the terminal sent SIGINT to the process group, it terminated the emacsclient process only. If git did the same thing as cvs here, i.e. ignore the signals in the parent process only and check the exit status of the editor, I think that would be OK. -- 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: Reviews on mailing-list
Deniz Türkoglu wrote: I have spoken to Shawn Pearce (gerrit project lead, google) and he said he is OK with hosting the gerrit instance. I would like to hear your thoughts on this. I personally think email is by far the best interface for patches, reviews, and discussions. Git patches are very high-volume, and not everyone can read everything. People should have the flexibility to choose the client they'd like to use to read patches and follow-ups; the freedom to use a scriptable client like Gnus is very important to me. Primarily, I want people to be able to: 1. Choose what to read, by scripting Gnus to score email that they'd likely find relevant. 2. Try out new patches on the list, by assigning one keybinding to git-am a series. 3. Display email the way they like. Many email clients have features to run filters through emails. 4. Read patches/ follow-ups offline, while travelling (on a phone, for instance). The GMail app, for instance, downloads mails for offline viewing. 5. Interact with other lists seamlessly (the kernel list, for instance). Email is a universal interface on which lists can be CC'ed easily. I'm not attacking a specific web interface, but I don't see how any of the following would be possible even with the most advanced web interface. Besides, nobody has made a proper case for using one. Therefore, I'm strongly opposed to the move. Ram -- 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
