Re: GSoC 2016 Microproject
On 03/01, Sidhant Sharma wrote: > > > If you use PARSE_OPT_HIDDEN, I think you don't need to specify a message. > > Otherwise, the documentation only has value if it contains more than just > > the option name, but that is the hard part if you're not familiar with the > > code. The best place to find documentation is in the history (git blame the > > file and see if the commit message introducing the option enlightens you). > > But that's why I said this didn't have to be part of the microproject: > > writting good doc requires a good understanding of the whole thing ... > I used OPT_HIDDEN_BOOL for all except for reject-thin-pack-for-testing, where > I used PARSE_OPT_HIDDEN. I ran the test locally and also on Travis, and the > all tests passed. How do I proceed now? Now you can send a patch to the mailing list. See Documentation/SubmittingPatches for more details. It usually is helpful to send the patches to yourself first as well, and try to apply them using git am, to avoid mistakes in the patch submission. > > Thanks and regards, > Sidhant Sharma [:tk] > -- > 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 -- Thomas -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2016 Microproject
> If you use PARSE_OPT_HIDDEN, I think you don't need to specify a message. > Otherwise, the documentation only has value if it contains more than just the > option name, but that is the hard part if you're not familiar with the code. > The best place to find documentation is in the history (git blame the file > and see if the commit message introducing the option enlightens you). But > that's why I said this didn't have to be part of the microproject: writting > good doc requires a good understanding of the whole thing ... I used OPT_HIDDEN_BOOL for all except for reject-thin-pack-for-testing, where I used PARSE_OPT_HIDDEN. I ran the test locally and also on Travis, and the all tests passed. How do I proceed now? Thanks and regards, Sidhant Sharma [:tk] -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2016 Microproject
Sidhant Sharmawrites: >>> First, I'm not quite sure what to put in the help message for the >>> options (--quiet, --stateless-rpc, --advertise-refs and >>> --reject-thin-pack-for-testing). >> They are currently undocumented. We sometimes have explicitly >> undocumented options (PARSE_OPT_HIDDEN) when they are used only >> internally to avoid polluting the end-user's UI. >> >> In this case, the command is anyway not meant for end-users so I think >> it would make sense to document them, but not necessarily within the the >> microproject. > So what may I put in the message parameter? I was thinking > perhaps the option itself, without hyphens. Would that be > correct? If you use PARSE_OPT_HIDDEN, I think you don't need to specify a message. Otherwise, the documentation only has value if it contains more than just the option name, but that is the hard part if you're not familiar with the code. The best place to find documentation is in the history (git blame the file and see if the commit message introducing the option enlightens you). But that's why I said this didn't have to be part of the microproject: writting good doc requires a good understanding of the whole thing ... >>> Should I make a patch for this and submit it for discussion on the mailing >>> list? >> >> On this list, it is indeed often more efficient to say "here's what I'm >> done. Any comments?" than "here's what I'm about to do". >> > I'm really sorry, I'm not very familiar with mailing list etiquettes. > I'll keep that in mind :) No problem. It's OK to say what you do beforehand and to ask help. Just don't be surprised when you don't get much feedback on message not starting with [PATCH] ;-). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2016 Microproject
>> First, I'm not quite sure what to put in the help message for the >> options (--quiet, --stateless-rpc, --advertise-refs and >> --reject-thin-pack-for-testing). > They are currently undocumented. We sometimes have explicitly > undocumented options (PARSE_OPT_HIDDEN) when they are used only > internally to avoid polluting the end-user's UI. > > In this case, the command is anyway not meant for end-users so I think > it would make sense to document them, but not necessarily within the the > microproject. So what may I put in the message parameter? I was thinking perhaps the option itself, without hyphens. Would that be correct? > >> Second, regarding the reject-thin-pack-for-testing option, currently >> when the option is entered, `fix_thin` is unset >> (https://github.com/git/git/blob/master/builtin/receive-pack.c#L1736). >> But using `OPT_BOOL(...)` for the same, the variable would instead be >> set when the option is given. I think one solution can be to invert >> `fix_thin` after calling `parse_options`. Am I going right so far? >> Suggestions and corrections welcome. > Or use OPT_SET_INT(..., 0) on a variable initialized to 1. Okay, will do that. >> Should I make a patch for this and submit it for discussion on the mailing >> list? > On this list, it is indeed often more efficient to say "here's what I'm > done. Any comments?" than "here's what I'm about to do". > I'm really sorry, I'm not very familiar with mailing list etiquettes. I'll keep that in mind :) Thanks and regards, Sidhant Sharma [:tk] -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2016 Microproject
Sidhant Sharmawrites: > Hi, >> I didn't see anything going on for this one, but you may want to >> double-check with the ml's archives. >> > I checked the archives and there doesn't seem to be any active work on this. > I made the required changes and ran the test suite. Though all the > tests pass, there still are two queries I have. > First, I'm not quite sure what to put in the help message for the > options (--quiet, --stateless-rpc, --advertise-refs and > --reject-thin-pack-for-testing). They are currently undocumented. We sometimes have explicitly undocumented options (PARSE_OPT_HIDDEN) when they are used only internally to avoid polluting the end-user's UI. In this case, the command is anyway not meant for end-users so I think it would make sense to document them, but not necessarily within the the microproject. > Second, regarding the reject-thin-pack-for-testing option, currently > when the option is entered, `fix_thin` is unset > (https://github.com/git/git/blob/master/builtin/receive-pack.c#L1736). > But using `OPT_BOOL(...)` for the same, the variable would instead be > set when the option is given. I think one solution can be to invert > `fix_thin` after calling `parse_options`. Am I going right so far? > Suggestions and corrections welcome. Or use OPT_SET_INT(..., 0) on a variable initialized to 1. > Should I make a patch for this and submit it for discussion on the mailing > list? On this list, it is indeed often more efficient to say "here's what I'm done. Any comments?" than "here's what I'm about to do". -- 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: GSoC 2016 Microproject
Hi, Should I make a patch for this and submit it for discussion on the mailing list? Regards, Sidhant Sharma [:tk] -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2016 Microproject
Hi, > I didn't see anything going on for this one, but you may want to > double-check with the ml's archives. > I checked the archives and there doesn't seem to be any active work on this. I made the required changes and ran the test suite. Though all the tests pass, there still are two queries I have. First, I'm not quite sure what to put in the help message for the options (--quiet, --stateless-rpc, --advertise-refs and --reject-thin-pack-for-testing). Second, regarding the reject-thin-pack-for-testing option, currently when the option is entered, `fix_thin` is unset (https://github.com/git/git/blob/master/builtin/receive-pack.c#L1736). But using `OPT_BOOL(...)` for the same, the variable would instead be set when the option is given. I think one solution can be to invert `fix_thin` after calling `parse_options`. Am I going right so far? Suggestions and corrections welcome. Regards, Sidhant Sharma [:tk] -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2016 Microproject
Sidhant Sharmawrites: >> There's already work in progress on this project, see the mailing list >> the last few days. >> > > Okay, in that case, I'd like to try is the one titled "Make upload-pack > and receive-pack use the parse-options api". In that, I can take up > the `builtin/receive-pack.c` file. Would that be okay? I didn't see anything going on for this one, but you may want to double-check with the ml's archives. -- 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: GSoC 2016 Microproject
> There's already work in progress on this project, see the mailing list > the last few days. > Okay, in that case, I'd like to try is the one titled "Make upload-pack and receive-pack use the parse-options api". In that, I can take up the `builtin/receive-pack.c` file. Would that be okay? Thanks again. Regards, Sidhant Sharma [:tk] -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2016 Microproject
Sidhant Sharmawrites: > Hi everyone, > > > I'm Sidhant Sharma. I'm looking to participate in GSoC 2016 (and contribute > to Git in general as well). I read up the pages relating to participation > in GSoC and selected the microproject "Add configuration options for some > commonly used command-line options". There's already work in progress on this project, see the mailing list the last few days. -- 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
GSoC 2016 Microproject
Hi everyone, I'm Sidhant Sharma. I'm looking to participate in GSoC 2016 (and contribute to Git in general as well). I read up the pages relating to participation in GSoC and selected the microproject "Add configuration options for some commonly used command-line options". I have some queries regarding this though: 1. I believe the option can be added by a reassignment of the `verbose` variable in `parse_and_validate_options` function inside the `builtin/commit.c`. It can be a logical OR between the `verbose` (which was parsed by the argument parser) and the value obtained by using `git_config_get_bool("command.verbose", _verbose)`. Am I thinking on the right lines? 2. Should I also add an option to override the configuration for verbose? 3. The microproject title suggests there can more such options, so are there more to be added? Thanks in advance. Regards Sidhant Sharma [:tk] -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2016: Microproject
On Mon, Feb 22, 2016 at 4:51 PM, Duy Nguyenwrote: > OK server is up but very likely misconfigured. If you have experience > with http server before (I think this is apache), then you can dig in > t/lib-httpd.sh, study how the server is configured and try to fix it. Thanks Duy. :) All tests passed. I configured apache server to listen to the ports tests were trying to access. Thanks Lars. I tested on Traivs-CI, worked fine. :) Mehul Jain -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2016: Microproject
On Mon, Feb 22, 2016 at 5:30 PM, Mehul Jainwrote: > On Mon, Feb 22, 2016 at 3:50 PM, Duy Nguyen wrote: >> You may have an http server installed but not suitable for these >> tests. Try running one test file alone with -v -i, e.g. >> ./t5539-fetch-http-shallow.sh -v -i and post the output. > > Here's the output :- > > expecting success: > git clone --bare --no-local shallow "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" > && > git clone $HTTPD_URL/smart/repo.git clone && > ( > cd clone && > git fsck && > git log --format=%s origin/master >actual && > cat 7 > 6 > 5 > 4 > 3 > EOF > test_cmp expect actual > ) > > Cloning into bare repository '/home/mj/git/t/trash > directory.t5539-fetch-http-shallow/httpd/www/repo.git'... > remote: Counting objects: 15, done. > remote: Compressing objects: 100% (5/5), done. > remote: Total 15 (delta 0), reused 15 (delta 0) > Receiving objects: 100% (15/15), done. > Checking connectivity... done. > Cloning into 'clone'... > fatal: unable to access 'http://127.0.0.1:5539/smart/repo.git/': The > requested URL returned error: 403 OK server is up but very likely misconfigured. If you have experience with http server before (I think this is apache), then you can dig in t/lib-httpd.sh, study how the server is configured and try to fix it. Alternatively, you can smiply skip http tests by setting environment variable GIT_TEST_HTTPD to false before running the tests. -- 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: GSoC 2016: Microproject
> On 22 Feb 2016, at 11:21, Lars Schneiderwrote: > > >> On 22 Feb 2016, at 11:12, Mehul Jain wrote: >> >> On Mon, Feb 22, 2016 at 12:22 AM, Matthieu Moy >> wrote: >>> The simplest way to get back on track for you is probably to start over >>> with a fresh clone, or (warning: destructive operations): use git clean >>> to remove untracked files. >> >> Hello Matthieu, >> >> I followed your advise and cloned a fresh copy of git source code. >> After compiling it and running the test with " prove --timer --jobs 15 >> ./t[0-9]*.sh" command, I received tests failure. All these tests are >> regarding HTTP protocol being invoked like >> t5539-fetch-http-shallow.sh. >> >> I'm behind a proxy server which blocks all ports except 80 and 443. >> Also my .gitconfig file is properly configured for proxy. Can these >> tests failure be triggered because of proxy server? >> > > Hi Mehul, > > please try this: > https://github.com/git/git.github.io/commit/9754cb22aeacf37fe341c5b3fde88f2a79e0ea24 > Oops.. I am sorry. I should have read your email more closely. t5539 is not yet executed on Travis-CI... But it wouldn't be too hard to add ;-) Cheers, Lars-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2016: Microproject
> On 22 Feb 2016, at 11:12, Mehul Jainwrote: > > On Mon, Feb 22, 2016 at 12:22 AM, Matthieu Moy > wrote: >> The simplest way to get back on track for you is probably to start over >> with a fresh clone, or (warning: destructive operations): use git clean >> to remove untracked files. > > Hello Matthieu, > > I followed your advise and cloned a fresh copy of git source code. > After compiling it and running the test with " prove --timer --jobs 15 > ./t[0-9]*.sh" command, I received tests failure. All these tests are > regarding HTTP protocol being invoked like > t5539-fetch-http-shallow.sh. > > I'm behind a proxy server which blocks all ports except 80 and 443. > Also my .gitconfig file is properly configured for proxy. Can these > tests failure be triggered because of proxy server? > Hi Mehul, please try this: https://github.com/git/git.github.io/commit/9754cb22aeacf37fe341c5b3fde88f2a79e0ea24 Cheers, Lars-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2016: Microproject
On Mon, Feb 22, 2016 at 3:50 PM, Duy Nguyenwrote: > You may have an http server installed but not suitable for these > tests. Try running one test file alone with -v -i, e.g. > ./t5539-fetch-http-shallow.sh -v -i and post the output. Here's the output :- expecting success: git clone --bare --no-local shallow "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" && git clone $HTTPD_URL/smart/repo.git clone && ( cd clone && git fsck && git log --format=%s origin/master >actual && cat actual && #cat
Re: GSoC 2016: Microproject
On Mon, Feb 22, 2016 at 5:12 PM, Mehul Jainwrote: > On Mon, Feb 22, 2016 at 12:22 AM, Matthieu Moy > wrote: >> The simplest way to get back on track for you is probably to start over >> with a fresh clone, or (warning: destructive operations): use git clean >> to remove untracked files. > > Hello Matthieu, > > I followed your advise and cloned a fresh copy of git source code. > After compiling it and running the test with " prove --timer --jobs 15 > ./t[0-9]*.sh" command, I received tests failure. All these tests are > regarding HTTP protocol being invoked like > t5539-fetch-http-shallow.sh. You may have an http server installed but not suitable for these tests. Try running one test file alone with -v -i, e.g. ./t5539-fetch-http-shallow.sh -v -i and post the output. > I'm behind a proxy server which blocks all ports except 80 and 443. > Also my .gitconfig file is properly configured for proxy. Can these > tests failure be triggered because of proxy server? No. HTTP server will be run locally on your machine and serve all the tests. -- 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: GSoC 2016: Microproject
On Mon, Feb 22, 2016 at 12:22 AM, Matthieu Moywrote: > The simplest way to get back on track for you is probably to start over > with a fresh clone, or (warning: destructive operations): use git clean > to remove untracked files. Hello Matthieu, I followed your advise and cloned a fresh copy of git source code. After compiling it and running the test with " prove --timer --jobs 15 ./t[0-9]*.sh" command, I received tests failure. All these tests are regarding HTTP protocol being invoked like t5539-fetch-http-shallow.sh. I'm behind a proxy server which blocks all ports except 80 and 443. Also my .gitconfig file is properly configured for proxy. Can these tests failure be triggered because of proxy server? Thanks, Mehul Jain -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2016: Microproject
Please, don't top-post on this list. Mehul Jainwrites: > Hello, > > I faced the following problem when I tested master branch. Here I have > made no commits to master branch. Are you sure that 1) you have no uncommitted change and 2) you have compiled what you have in your tree? > Is this test failure usual with linux based system or just happened with me. All tests are supposed to pass. You can see the result of the Travis-CI builds there: https://travis-ci.org/git/git/branches -- 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: GSoC 2016: Microproject
On Mon, Feb 22, 2016 at 12:22 AM, Matthieu Moywrote: > Mehul Jain writes: > >> Earlier when I was testing the master branch on my pc, I used "make" >> in \t directory, which lead to failure of test #2, #3 in >> t5539-fetch-http-shallow.sh . >> Afterwards I switched to sudo mode and ran the make command again. > > Never ever do that. Your git source tree should be within your $HOME > directory, and you should never run any command as root that creates > files within your $HOME dir. If you do that, you'll end up having files > belonging to root within other directories, you won't have write > permission on these files. Then, anything can go wrong because any > attempt to write to these files will fail. > > The simplest way to get back on track for you is probably to start over > with a fresh clone, or (warning: destructive operations): use git clean > to remove untracked files. > I think a 'sudo git clean' outta be enough. But the main point to take away is not using 'make' with 'sudo' like you mentioned. -- Regards, Karthik Nayak -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2016: Microproject
Mehul Jainwrites: > Earlier when I was testing the master branch on my pc, I used "make" > in \t directory, which lead to failure of test #2, #3 in > t5539-fetch-http-shallow.sh . > Afterwards I switched to sudo mode and ran the make command again. Never ever do that. Your git source tree should be within your $HOME directory, and you should never run any command as root that creates files within your $HOME dir. If you do that, you'll end up having files belonging to root within other directories, you won't have write permission on these files. Then, anything can go wrong because any attempt to write to these files will fail. The simplest way to get back on track for you is probably to start over with a fresh clone, or (warning: destructive operations): use git clean to remove untracked files. -- 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: GSoC 2016: Microproject
On Sun, Feb 21, 2016 at 10:25 AM, Matthieu Moywrote: > Please, don't top-post on this list. I apologize for top-posting on the list. > Are you sure that 1) you have no uncommitted change and 2) you have > compiled what you have in your tree? 1) Yes, I have no uncommited change in the branch(master). 2) Yes, I compiled before testing. Earlier when I was testing the master branch on my pc, I used "make" in \t directory, which lead to failure of test #2, #3 in t5539-fetch-http-shallow.sh . Afterwards I switched to sudo mode and ran the make command again. This time all test of t5539-fetch-http-shallow.sh passed, but test #32 of file t7300-clean.sh failed. To crosscheck, I ran " sudo sh ./t7300-clean.sh -v --run='1-32' " which gave the following error message - Skipping repository baz/boo Skipping repository foo/ Removing possible_sub1/ Skipping repository repo/ Skipping repository sub2/ Removing to_clean/ File possible_sub1/.git doesn't exist. not ok 32 - should avoid cleaning possible submodules # # rm -fr to_clean possible_sub1 && # mkdir to_clean possible_sub1 && # test_when_finished "rm -rf possible_sub*" && # echo "gitdir: foo" >possible_sub1/.git && # >possible_sub1/hello.world && # chmod 0 possible_sub1/.git && # >to_clean/should_clean.this && # git clean -f -d && # test_path_is_file possible_sub1/.git && # test_path_is_file possible_sub1/hello.world && # test_path_is_missing to_clean # I haven't made any commits/changes in the master branch. Can you please suggest where things are going wrong. Thanks Mehul Jain -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2016: Microproject
On Fri, Feb 19, 2016 at 11:20 PM, Stefan Bellerwrote: > Yes, most likely t/t5521-pull-options.sh or t/t5520-pull.sh would be the right > place as judging from the file name of the tests. I checked out both of the files and made following observations - 1) As I'm going to add an option for "git pull --rebase"; tests should be added for following commands in t/t5521-pull-options.sh a) git pull --rebase --[no-]autostash b) git pull -v --rebase --[no-]autostash c) git pull -q --rebase --[no-]autostash 2) Also test for "pull --rebase --[no-]autostash fails with dirty working tree and rebase.autostash set" should be added to t/t5520-pull.sh. Have I made the right observation? Thanks, Mehul Jain -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2016: Microproject
Hello, I faced the following problem when I tested master branch. Here I have made no commits to master branch. *** t5539-fetch-http-shallow.sh *** ok 1 - setup shallow clone not ok 2 - clone http repository # # git clone --bare --no-local shallow "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" && # git clone $HTTPD_URL/smart/repo.git clone && # ( # cd clone && # git fsck && # git log --format=%s origin/master >actual && # catdone" ../trace # ) # # failed 2 among 3 test(s) 1..3 make[1]: *** [t5539-fetch-http-shallow.sh] Error 1 make[1]: Leaving directory `/home/mj/git/t' make: *** [test] Error 2 Is this test failure usual with linux based system or just happened with me. I'm running Ubuntu 14.04. thanks, Mehul Jain On Fri, Feb 19, 2016 at 11:20 PM, Stefan Beller wrote: > On Fri, Feb 19, 2016 at 9:39 AM, Mehul Jain wrote: >> On Fri, Feb 19, 2016 at 6:33 PM, Matthieu Moy >> wrote: >>> Hi, >>> >>> This is a double-post. You've posted almost the same message under the >>> title "GSoC 2016". Nothing serious, but attention to details is >>> important if you want to give a good image of yourself. >> >> I'm sorry of this kind of behavior. It was due to a misunderstanding by my >> side. >> >>> I don't have all the code in mind, but I think it is. In this situation, >>> you always end up with a variable telling Git what to do (I guess, >>> autostash here), and this variable is set according to the configuration >>> and the command-line. >>> >>> You should be careful about the precedence: command-line should override >>> the configuration. And the default behavior should be used if neither >>> the command-line nor the configuration specified otherwise. >> >> Thanks for the suggestion. >> I've started the work on patch and did the change in the code which >> were necessary for Microproject. I have run the test by using "make", >> and there was no failure of any test. >> I've a doubt regarding tests. Here as "git pull" will now understand >> the argument that "--[no-]autostash" means "rebase.autostash" should >> be set false for current execution of command "git pull --rebase". So >> do I have to write a test for this new option? >> > > Yes, most likely t/t5521-pull-options.sh or t/t5520-pull.sh would be the right > place as judging from the file name of the tests. > > Thanks, > Stefan > >> Mehul Jain >> -- >> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2016: Microproject
On Fri, Feb 19, 2016 at 11:20 PM, Stefan Bellerwrote: > Yes, most likely t/t5521-pull-options.sh or t/t5520-pull.sh would be the right > place as judging from the file name of the tests. Thanks for specifying the files. I think t/t5520-pull.sh line 258 will be the best place to write test for this case. Mehul Jain -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2016: Microproject
On Fri, Feb 19, 2016 at 9:39 AM, Mehul Jainwrote: > On Fri, Feb 19, 2016 at 6:33 PM, Matthieu Moy > wrote: >> Hi, >> >> This is a double-post. You've posted almost the same message under the >> title "GSoC 2016". Nothing serious, but attention to details is >> important if you want to give a good image of yourself. > > I'm sorry of this kind of behavior. It was due to a misunderstanding by my > side. > >> I don't have all the code in mind, but I think it is. In this situation, >> you always end up with a variable telling Git what to do (I guess, >> autostash here), and this variable is set according to the configuration >> and the command-line. >> >> You should be careful about the precedence: command-line should override >> the configuration. And the default behavior should be used if neither >> the command-line nor the configuration specified otherwise. > > Thanks for the suggestion. > I've started the work on patch and did the change in the code which > were necessary for Microproject. I have run the test by using "make", > and there was no failure of any test. > I've a doubt regarding tests. Here as "git pull" will now understand > the argument that "--[no-]autostash" means "rebase.autostash" should > be set false for current execution of command "git pull --rebase". So > do I have to write a test for this new option? > Yes, most likely t/t5521-pull-options.sh or t/t5520-pull.sh would be the right place as judging from the file name of the tests. Thanks, Stefan > Mehul Jain > -- > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2016: Microproject
On Fri, Feb 19, 2016 at 6:33 PM, Matthieu Moywrote: > Hi, > > This is a double-post. You've posted almost the same message under the > title "GSoC 2016". Nothing serious, but attention to details is > important if you want to give a good image of yourself. I'm sorry of this kind of behavior. It was due to a misunderstanding by my side. > I don't have all the code in mind, but I think it is. In this situation, > you always end up with a variable telling Git what to do (I guess, > autostash here), and this variable is set according to the configuration > and the command-line. > > You should be careful about the precedence: command-line should override > the configuration. And the default behavior should be used if neither > the command-line nor the configuration specified otherwise. Thanks for the suggestion. I've started the work on patch and did the change in the code which were necessary for Microproject. I have run the test by using "make", and there was no failure of any test. I've a doubt regarding tests. Here as "git pull" will now understand the argument that "--[no-]autostash" means "rebase.autostash" should be set false for current execution of command "git pull --rebase". So do I have to write a test for this new option? Mehul Jain -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2016: Microproject
Hi, This is a double-post. You've posted almost the same message under the title "GSoC 2016". Nothing serious, but attention to details is important if you want to give a good image of yourself. Mehul Jainwrites: > Hello everyone, > > I'm Mehul Jain. I'm looking for participating in GSoC 2016. Note that we are just submitting our application, but have no guarantee that the Git organization will be accepted for this year's GSoC. > I've started work on a Microproject" Teach git pull --rebase the > --no-autostash" option. While looking at Git's source code I have made > following observation: In the pull.c file > 1. git_config_get_bool( , ) search in the configuration key for the > value of rebase.autostash, if found true then modify autostash's value > to a non-zero number and thus making a stash to encounter the problem > of dirty tree. > 2. Here if in command line a flag "--no-autostash" is given then we > can easily set the value of autostash = 0 and thus killing the process > by die_on_unclean_work_tree(prefix). > Is my observation is right? I don't have all the code in mind, but I think it is. In this situation, you always end up with a variable telling Git what to do (I guess, autostash here), and this variable is set according to the configuration and the command-line. You should be careful about the precedence: command-line should override the configuration. And the default behavior should be used if neither the command-line nor the configuration specified otherwise. To get an example, you can pick any pair (command-line option, config) that work together, find the code implementing it and blame to find the corresponding commit. -- 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
GSoC 2016: Microproject
Hello everyone, I'm Mehul Jain. I'm looking for participating in GSoC 2016. I've started work on a Microproject" Teach git pull --rebase the --no-autostash" option. While looking at Git's source code I have made following observation: In the pull.c file 1. git_config_get_bool( , ) search in the configuration key for the value of rebase.autostash, if found true then modify autostash's value to a non-zero number and thus making a stash to encounter the problem of dirty tree. 2. Here if in command line a flag "--no-autostash" is given then we can easily set the value of autostash = 0 and thus killing the process by die_on_unclean_work_tree(prefix). Is my observation is right? I'm new to open source projects and not much experienced at it. So please correct/comment on any mistake that I made while trying to put my point. I will also appreciate any comment/suggestion/criticism on my observation. Thanks -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html