Re: GSoC 2016: applications open, deadline = Fri, 19/2
On Tue, Feb 23, 2016 at 02:13:34PM +0100, Matthieu Moy wrote: > > So I think a little back and forth is good; almost everybody does > > something a little wrong in their first patch submission. But I'd worry > > about a topic that is going to involve a lot of bikeshedding or subtle > > nuances to finding the correct solution. I certainly think _some_ > > candidates can handle that, but for the ones who cannot, it may > > frustrate all involved. > > Well, starting a microproject and realizing afterwards that it was a > hard one is frustrating. But picking a very easy project and see someone > else do a brillant job on a harder one, and this someone else get > accepted is also frustrating. My "all involved" also included reviewers and list regulars. :) > I don't think this "kill -Wshadow warning" is really too hard. I'd say > it's hard enough to be interesting for students who have a chance to be > selected in the end. Fair enough. If you want to add it, go for it. The worst that can happen is some failed microprojects. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2016: applications open, deadline = Fri, 19/2
Jeff King writes: > On Mon, Feb 22, 2016 at 01:56:52PM -0800, Junio C Hamano wrote: > >> Jeff King writes: >> >> > I agree that there are a lot of different ways to resolve each instance, >> > and it will vary from case to case. I think the original point of a >> > microproject was to do something really easy and not contentious, so >> > that the student could get familiar with all of the other parts of the >> > cycle: writing a commit message, formatting the patch, posting to the >> > list, etc. >> >> I had an impression that Micros are also used as an aptitude test, >> and one important trait we want to see in a potential developer is >> how well s/he interacts with others in such a discussion. So "easy >> and not contentious" might not be a very good criteria. >> >> I dunno. > > I sort-of agree. I think of the microprojects as more of a "fizz-buzz", > where you intentionally keep the technical level very low so that you > can evaluate the other things. I agree with "very low", but I don't think we should eliminate completely the difficulty. During the selection, microprojects can be very efficient in eliminating the really bad candidates (usually, there are quite a few), but once the first selection is done, we still need tools to separate "moderately good" and "really good" candidates. > So I think a little back and forth is good; almost everybody does > something a little wrong in their first patch submission. But I'd worry > about a topic that is going to involve a lot of bikeshedding or subtle > nuances to finding the correct solution. I certainly think _some_ > candidates can handle that, but for the ones who cannot, it may > frustrate all involved. Well, starting a microproject and realizing afterwards that it was a hard one is frustrating. But picking a very easy project and see someone else do a brillant job on a harder one, and this someone else get accepted is also frustrating. I don't think this "kill -Wshadow warning" is really too hard. I'd say it's hard enough to be interesting for students who have a chance to be selected in the end. -- 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: applications open, deadline = Fri, 19/2
On Mon, Feb 22, 2016 at 01:56:52PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > I agree that there are a lot of different ways to resolve each instance, > > and it will vary from case to case. I think the original point of a > > microproject was to do something really easy and not contentious, so > > that the student could get familiar with all of the other parts of the > > cycle: writing a commit message, formatting the patch, posting to the > > list, etc. > > I had an impression that Micros are also used as an aptitude test, > and one important trait we want to see in a potential developer is > how well s/he interacts with others in such a discussion. So "easy > and not contentious" might not be a very good criteria. > > I dunno. I sort-of agree. I think of the microprojects as more of a "fizz-buzz", where you intentionally keep the technical level very low so that you can evaluate the other things. So I think a little back and forth is good; almost everybody does something a little wrong in their first patch submission. But I'd worry about a topic that is going to involve a lot of bikeshedding or subtle nuances to finding the correct solution. I certainly think _some_ candidates can handle that, but for the ones who cannot, it may frustrate all involved. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2016: applications open, deadline = Fri, 19/2
Jeff King writes: > I agree that there are a lot of different ways to resolve each instance, > and it will vary from case to case. I think the original point of a > microproject was to do something really easy and not contentious, so > that the student could get familiar with all of the other parts of the > cycle: writing a commit message, formatting the patch, posting to the > list, etc. I had an impression that Micros are also used as an aptitude test, and one important trait we want to see in a potential developer is how well s/he interacts with others in such a discussion. So "easy and not contentious" might not be a very good criteria. I dunno. > It seems like this has a high chance of frustrating students as they get > embroiled in back-and-forth review. I dunno. Maybe it should be marked > with a star as a "challenge" microproject. :) -- 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: applications open, deadline = Fri, 19/2
On Mon, Feb 22, 2016 at 11:22:48AM +0100, Matthieu Moy wrote: > > Idea for microprojects. If you compile using gcc with -Wshadow, it > > spots local variables that shadow another local or global variables. > > These are usually bad because it makes it's easy to make mistakes when > > changing the code. > > I hade a look an a few instances of the warning, and all of them were > bad (sometimes even suspicious, I wouldn't be surprised if we found real > bugs hunting these down). I looked at a handful, too, and many looked fine (e.g., shadowing an overly-broadly-named global parameter with a function parameter). Not that I'm against squelching them. There's definitely potential for confusion, and I won't be surprised either if there's a real bug lurking in there (which we can't find because of the number of false positives). But... > > _If_ you agree shadow vars are bad and should be exterminated, > > 'master' has 94 warnings spreading over 49 files. A student can pick > > _one_ file and try to fix all warnings in that file. There are many > > possible approaches (rename, combine vars, change scope, even > > restructure/kill global vars..), plenty of room for discussion. > > +1. > > Are there counter-arguments to this? I agree that there are a lot of different ways to resolve each instance, and it will vary from case to case. I think the original point of a microproject was to do something really easy and not contentious, so that the student could get familiar with all of the other parts of the cycle: writing a commit message, formatting the patch, posting to the list, etc. It seems like this has a high chance of frustrating students as they get embroiled in back-and-forth review. I dunno. Maybe it should be marked with a star as a "challenge" microproject. :) -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2016: applications open, deadline = Fri, 19/2
Duy Nguyen writes: > On Sat, Feb 13, 2016 at 6:21 PM, Matthieu Moy > wrote: >> Less urgent, but we need to add more stuff to be credible: >> >> ... >> >> http://git.github.io/SoC-2016-Microprojects/ => I just did s/2015/2016/. >> I think most projects are not valid anymore, and we need new ones. >> >> To all: please contribute to these pages, either by sending patches here >> (CC: me and peff), pushing directly if you have access, or submitting >> pull-requests. The repo is https://github.com/git/git.github.io/. > > Idea for microprojects. If you compile using gcc with -Wshadow, it > spots local variables that shadow another local or global variables. > These are usually bad because it makes it's easy to make mistakes when > changing the code. I hade a look an a few instances of the warning, and all of them were bad (sometimes even suspicious, I wouldn't be surprised if we found real bugs hunting these down). > _If_ you agree shadow vars are bad and should be exterminated, > 'master' has 94 warnings spreading over 49 files. A student can pick > _one_ file and try to fix all warnings in that file. There are many > possible approaches (rename, combine vars, change scope, even > restructure/kill global vars..), plenty of room for discussion. +1. Are there counter-arguments to this? -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2016: applications open, deadline = Fri, 19/2
On Sat, Feb 13, 2016 at 6:21 PM, Matthieu Moy wrote: > Less urgent, but we need to add more stuff to be credible: > > ... > > http://git.github.io/SoC-2016-Microprojects/ => I just did s/2015/2016/. > I think most projects are not valid anymore, and we need new ones. > > To all: please contribute to these pages, either by sending patches here > (CC: me and peff), pushing directly if you have access, or submitting > pull-requests. The repo is https://github.com/git/git.github.io/. Idea for microprojects. If you compile using gcc with -Wshadow, it spots local variables that shadow another local or global variables. These are usually bad because it makes it's easy to make mistakes when changing the code. _If_ you agree shadow vars are bad and should be exterminated, 'master' has 94 warnings spreading over 49 files. A student can pick _one_ file and try to fix all warnings in that file. There are many possible approaches (rename, combine vars, change scope, even restructure/kill global vars..), plenty of room for discussion. -- 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: applications open, deadline = Fri, 19/2
Hi Junio, On Fri, 19 Feb 2016, Junio C Hamano wrote: > The "experimenting" would include mergy operations like "am -3" and > "cherry-pick". "After queuing a topic and trying it in isolation, an > attempt to merge to the baseline results in quite a mess, and I give > up"--there is nothing to salvage. > > And obviously, "stash" is not useful in such a situation. I think this is more a short-coming of "stash" than anything else. Many a times did I wish I could simply quickly stash a failed merge and then come back later. Or not. Just like stashed changes without conflicts allow me to do already. Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2016: applications open, deadline = Fri, 19/2
Lars Schneider writes: > If this mode is enabled then Git shall print a warning message before > running a potentially destructive command. In addition to the warning > Git shall print a command that would reverse the operation if possible. > Most of the information to reverse an operation is already available > via git reflog. However, the task here is to make this information more > easily accessible to Git beginners. > > -- > > Does this go into the direction of "making the powerful tool harder to > misuse"? Not really, if done without a real thinking. The approach risks to make the powerful tool harder to use, not just misuse. -- 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: applications open, deadline = Fri, 19/2
Matthieu Moy writes: >> We have these "powerful" tools for a reason. After making a mess >> experimenting with your working tree files, "reset --hard" is the >> best tool to go back to the known-good state, > > I disagree with that. This reminds me a discussion I had with a student > a few years ago: > > student: how do a clear all changes from my worktree? > me: git reset --hard > > the next day: > > student: OK, now, how do I get my changes back? > me: ...! > > There's almost no situation where reset --hard is the best tool. I obviously have to disagree. After maknig a mess experimenting, when you want to discard all that, "reset --hard" is the best tool--the situation of your student may be quite different but you didn't make it clear what s/he wanted to salvage. In any case, I wasn't asking about "clear all changes for now, to be salvaged later". The "experimenting" would include mergy operations like "am -3" and "cherry-pick". "After queuing a topic and trying it in isolation, an attempt to merge to the baseline results in quite a mess, and I give up"--there is nothing to salvage. And obviously, "stash" is not useful in such a situation. You could use "tar cf ../saved .", though. > Now, another issue with the proposed core.isbeginner is compatibility > with scripts. Yes. > Dangerous commands are often plumbing, and a beginner may > still want to use scripts or other porcelain on top of it. Typically, I > think this rules out "git reset --hard" which is legitimate in scripts. I agree that an "under core.isbeginner, the command will always be refused" change can be written without thinking and it will be useless for anything that has ledigimate uses (like, but not limited to, being used in scripts) [*1*]. But not so fast. If you can figure out when "git reset --hard" is legitimate based *NOT* only on the fact that it is driven by a script, but on what kind of modifications to the working tree contents, the index contents and the refs are about to be made by the command, then "core.isbeginner" can be a permission for the command to spend extra cycles to examine the situation carefully to decide to selectively go ahead, warn and go ahead, or refuse. That of course takes a real thinking. [Footnote] *1* I'd refuse to take a patch to make scripted Porcelains that make legit calls to "powerful" tools export GIT_SCRIPT_IS_RUNNING_YOU environment variable as a workaround for such a kludge. -- 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: applications open, deadline = Fri, 19/2
Lars Schneider writes: > Thanks for your elaborate response. I think I got your point and I > tried to adjust my "beginner mode" proposal accordingly [1]. Now merged as https://github.com/git/git.github.io/commit/6b8b5e19cdb221192dedd70ba3e207636f1cdab1 I've added a warning for students: Note that this project is not technically difficult, it requires a deep understanding of Git: how each command is meant to be used, what are the potential dangers, ... Reaching a solution that effectively protects beginners without harming anyone is much harder than it seems. See for example [this thread](http://thread.gmane.org/gmane.comp.version-control.git/285893/focus=286614) for example potential objections. If chosen, this project should be discussed in depth on the list before and after the student application. I just want to avoid students loosing their time writting silly proposals (once you have seen what the majority of proposals looks like, nothing surprises you anymore ;-) ). -- 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: applications open, deadline = Fri, 19/2
On 02/18, Lars Schneider wrote: > > On 17 Feb 2016, at 19:58, Matthieu Moy wrote: > > > Lars Schneider writes: > > > >> Coincidentally I started working on similar thing already (1) and I have > >> lots of ideas around it. > > > > I guess it's time to start sharing these ideas then ;-). > > > > I think there's a lot to do. If we want to push this idea as a GSoC > > project, we need: > > > > * A rough plan. We can't expect students to read a vague text like > > "let's make Git safer" and write a real proposal out of it. > > > > * A way to start this rough plan incrementally (i.e. first step should > > be easy and mergeable without waiting for next steps). > > > > Feel free to start writting an idea for > > http://git.github.io/SoC-2016-Ideas/. It'd be nice to have a few more > > ideas before Friday. We can polish them later if needed. > > I published my ideas here: > https://github.com/git/git.github.io/pull/125/files Sorry for posting my idea so late, but it took me a while to write this all up, and life has a habit of getting in the way. My idea goes into a different direction than yours. I do like the remote whitelist/blacklist project. Junio pointed out to me off list that this is to complicated for a GSoC project. I kind of agree with that, but I wanted to see how this could be split up, to completely convince myself as well. And indeed, the more I think about it the more risky it seems. Below there are some thoughts on a potential design, in case someone is interested, no code to back any of this up, sorry. Everything proposed below should be hidden behind some configuration variable, potentially one per command (?) - start with git-clean. It's well defined which files are cleaned from a repository when running the command. Add them to a commit on the tip of the current branch. Start a new branch (or use the existing one if applicable) in refs/restore/history, and add a commit including a notes file. The commit message contains the operation that was executed (clean in this case), and the hash of the commit we created which includes the cleaned files. Add a note to the commit, detailing from which command we come from, which files we added (not strictly necessary, as we can infer it from the parent commit). Useful in itself as the user can recover the files manually if needed, and can be sent as separate patch series. Potential problems: Git has no way to track directories. This can be mitigated by keeping the list of directories in the attached note. - add a git recover command. The command looks at This would look like `git recover `, where commit is the hash of the commit we saved before. This works by reading the note attached to the commit, figuring out which command was run before, and restoring the state we were in before. Potential problems: conflicts, but I think this can be solved by simply erroring out, at least in the first iteration. - the next command could be git mv -f, git reset -f and friends. It gets more tricky here, as we'll have to deal with the state of the files in the index. Analogous to git clean, the changes in the working tree are all staged and added to a new commit on the tip of the current branch. The note on this commit needs to contain the necessary data to rebuild the state in the index. The format is more closely specified below. We also need the corresponding changes in the git restore command. Restored files will be written to disk as racily smudged, so the contents are checked by git, as we lost the meta-data anyway. This comes at a slight performance impact, but I think that's okay as we potentially saved the user a lot of time re-doing all the changes. - git branch/tag --force. Store the name and the old location of the branch in refs/restore/history. There are no files lost with this operation, so no additional commits as for git clean or git reset etc. are needed. The format of the commit depends on the exact operation that was forced, for exact format see below. This treatment can't make all operations safe. Any operation that touches the remote is hard to undo as some users already might have fetched the new state of the remote (e.g. git push -f). Others such as git-gc will inevitably delete information from the disk, but changing that There's more, but I don't think just writing up all commands without any code would make any sense. Formats: - commits in refs/restore/history: empty commits with the following commit message format for git-clean and git-reset and friends: $versionnumber\n $command\n $branchname\n $sha1ofreferencedcommit\n empty commits with the following commit message format for git branch and friends $versionnumber\n $command\n (this includes the exact operation that was forced (e.g. move, delete etc.) $branchname\n $sha1ThatWasReferencedByTheBranch\n $overwrittenbranchname\n (this and the sha1 below are only used for --move
Re: GSoC 2016: applications open, deadline = Fri, 19/2
On Fri, Feb 19, 2016 at 2:17 PM, Matthieu Moy wrote: >> with David's multiple ref backend work, we could have a third, >> no-dependency backend. We can use index format to store refs. > > This sounds like an interesting but ambitious project for a GSoC. There > are a lot of new stuff to understand for someone potentially new to > Git's codebase. And it's hard to work incrementally: the result would > hardly be mergeable before being almost finished. On the other hand, the actual amount of code they write is roughly about 1700 lines of refs/lmdb-backend.c. Which I guess can be written in a month once you know what's going on, basically how refs are handled (I think documents have been greatly improved), git object manipulation and optionally index manipulation (if we store in index instead of trees). I think it's manageable. But then I haven't interacted with students for a looong time. > I think it's interesting to offer the idea, but there should be a > warning for the student about the difficulties. Yep. > Would you be willing to (co-)mentor? I can't guarantee I will not disappear for a couple months again like last year. It depends on $DAY_JOB. So maybe co-mentor position, but my other co-mentor should be ready for that situation. -- 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: applications open, deadline = Fri, 19/2
On 18 Feb 2016, at 20:13, Junio C Hamano wrote: > Stefan Beller writes: > >> On Thu, Feb 18, 2016 at 12:41 AM, Lars Schneider >> wrote: Feel free to start writting an idea for http://git.github.io/SoC-2016-Ideas/. It'd be nice to have a few more ideas before Friday. We can polish them later if needed. >>> >>> I published my ideas here: >>> https://github.com/git/git.github.io/pull/125/files >> >> I like the idea of a beginner mode, but on the other hand that looks >> inflexible to me ;) >> (What if I want to use rebase, but not reset --hard?) > > That's simple. You say "cd .. && rm -fr repo && git clone" and > start from scratch ;-). > > This whole "beginner should be limited to a 'safe' subset" is an > unhealthy attitude. > > Deciding what the 'safe' subset is must be done with a lot of > thinking by people who intimately know what implications it has to > ban each feature. I do not think it would be a good fit for a > project to give to a relatively new participant to the Git project. > > For example, I think banning "worktree" feature from newbies may not > be a bad idea, as you can work on a project without using "worktree" > at all, and use of "worktree" would only subject you to bugs that do > not exist when you do not use that feature. The "shallow clone", > "sparse checkout", and "untracked cache" fall into the same category > for exactly the same reason. The "submodule" feature might fall > into the same category for the same reason, but that is not > something you as a project participant can unilaterally decide, as > the project you are working on may have already decided to use the > feature, so it is harder to ban from the beginners. > > But for the rest of really "core" part of Git, I do not think there > is any such command that can be totally banned. > > We have these "powerful" tools for a reason. After making a mess > experimenting with your working tree files, "reset --hard" is the > best tool to go back to the known-good state, and robbing it from > the users is not a sound approach to help them. When "powerful" > becomes "too powerful" is when a "powerful" tool is misused. It is > perhaps done by mistake or perhaps done by copying and pasting a > solution from Interweb for a problem that does not match your > situation without understanding what you are doing. > > What is needed to help beginners is to make the powerful tool harder > to misuse. Of course, that would be a harder task, because you have > to do a real thinking. > > You do not have to do any thinking to say that "a blanket ban that > hides these powerful tools behind the beginner mode" helps > beginners, but I do not think it is solving what really matters. At > the same time, it just adds to the FUD, i.e. some commands are too > powerful for their own good. Thanks for your elaborate response. I think I got your point and I tried to adjust my "beginner mode" proposal accordingly [1]. Here is the relevant change: If this mode is enabled then Git shall print a warning message before running a potentially destructive command. In addition to the warning Git shall print a command that would reverse the operation if possible. Most of the information to reverse an operation is already available via git reflog. However, the task here is to make this information more easily accessible to Git beginners. -- Does this go into the direction of "making the powerful tool harder to misuse"? Thanks, 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: applications open, deadline = Fri, 19/2
Junio C Hamano writes: > Deciding what the 'safe' subset is must be done with a lot of > thinking by people who intimately know what implications it has to > ban each feature. I do not think it would be a good fit for a > project to give to a relatively new participant to the Git project. I have to agree with this: this would actually be very hard to get a nice proposal from a student. Students can be good technically, but we can't expect them to be experienced and giving sound advices to beginners is hard in this situation. > We have these "powerful" tools for a reason. After making a mess > experimenting with your working tree files, "reset --hard" is the > best tool to go back to the known-good state, I disagree with that. This reminds me a discussion I had with a student a few years ago: student: how do a clear all changes from my worktree? me: git reset --hard the next day: student: OK, now, how do I get my changes back? me: ...! There's almost no situation where reset --hard is the best tool. If you just want to discard local changes, then "stash" is much safer (it'll eat a bit of your disk space, but in 99% cases it's not an issue). If you messed up a merge then "merge --abort" is safer. If the goal is to move HEAD, then "reset --keep" is safer. One thing I like about Git is: when a beginner messes up his tree or repo, his Git guru friend can almost always repair it easily (at least, much easier than it was with svn). But there are still a few ways for beginners to shoot themselves in the foot in a way that the guru cannot repair. Now, another issue with the proposed core.isbeginner is compatibility with scripts. Dangerous commands are often plumbing, and a beginner may still want to use scripts or other porcelain on top of it. Typically, I think this rules out "git reset --hard" which is legitimate in scripts. -- 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: applications open, deadline = Fri, 19/2
Duy Nguyen writes: > On Thu, Feb 18, 2016 at 1:58 AM, Matthieu Moy > wrote: >> Feel free to start writting an idea for >> http://git.github.io/SoC-2016-Ideas/. It'd be nice to have a few more >> ideas before Friday. We can polish them later if needed. > > Probably too late now, anyway.. It's still time. I'll post the application very soon (a few hours from now), but the idea list is not included in the application, but linked from it. So we can add something before reviewers follow the link, and obviously we can add more before students start picking them. > with David's multiple ref backend work, we could have a third, > no-dependency backend. We can use index format to store refs. This sounds like an interesting but ambitious project for a GSoC. There are a lot of new stuff to understand for someone potentially new to Git's codebase. And it's hard to work incrementally: the result would hardly be mergeable before being almost finished. I think it's interesting to offer the idea, but there should be a warning for the student about the difficulties. Would you be willing to (co-)mentor? -- 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: applications open, deadline = Fri, 19/2
On Fri, Feb 19, 2016 at 10:20 AM, Junio C Hamano wrote: > Duy Nguyen writes: > >> Probably too late now, anyway.. with David's multiple ref backend >> work, we could have a third, no-dependency backend. We can use index >> format to store refs. Then we can avoid case-sensitivity issue with >> filesystems. > > I'd actually vote for a ref backend that is based on a tree object ;-) > > http://thread.gmane.org/gmane.comp.version-control.git/282677 For reasonably small sets of refs I think index beats trees (remember we have cache-tree, which basically gives us the tree behind the scene), but when you have so many refs, hierarchical storage may be more efficient. Either way it's nice to see a builtin, no dependency backend besides "files". -- 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: applications open, deadline = Fri, 19/2
Duy Nguyen writes: > Probably too late now, anyway.. with David's multiple ref backend > work, we could have a third, no-dependency backend. We can use index > format to store refs. Then we can avoid case-sensitivity issue with > filesystems. I'd actually vote for a ref backend that is based on a tree object ;-) http://thread.gmane.org/gmane.comp.version-control.git/282677 -- 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: applications open, deadline = Fri, 19/2
On Thu, Feb 18, 2016 at 1:58 AM, Matthieu Moy wrote: > Feel free to start writting an idea for > http://git.github.io/SoC-2016-Ideas/. It'd be nice to have a few more > ideas before Friday. We can polish them later if needed. Probably too late now, anyway.. with David's multiple ref backend work, we could have a third, no-dependency backend. We can use index format to store refs. Then we can avoid case-sensitivity issue with filesystems. Split-index could make it relatively cheap for updating refs. Later on, when we can store tree objects in index (*), some (rarely used) refs could be stored as tree objects and we can reduce index file size (and loading cost). This idea is inspired by Shawn's storing refs as tree objects mail, except that I stopped at "wait, if we want to create trees we (usually) have to go through index, why not just stop at index?". (*) In have some WIP in this area, but not ready for public discussion yet. And it's out of scope for GSoC. -- 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: applications open, deadline = Fri, 19/2
Stefan Beller writes: > On Thu, Feb 18, 2016 at 12:41 AM, Lars Schneider > wrote: >>> Feel free to start writting an idea for >>> http://git.github.io/SoC-2016-Ideas/. It'd be nice to have a few more >>> ideas before Friday. We can polish them later if needed. >> >> I published my ideas here: >> https://github.com/git/git.github.io/pull/125/files > > I like the idea of a beginner mode, but on the other hand that looks > inflexible to me ;) > (What if I want to use rebase, but not reset --hard?) That's simple. You say "cd .. && rm -fr repo && git clone" and start from scratch ;-). This whole "beginner should be limited to a 'safe' subset" is an unhealthy attitude. Deciding what the 'safe' subset is must be done with a lot of thinking by people who intimately know what implications it has to ban each feature. I do not think it would be a good fit for a project to give to a relatively new participant to the Git project. For example, I think banning "worktree" feature from newbies may not be a bad idea, as you can work on a project without using "worktree" at all, and use of "worktree" would only subject you to bugs that do not exist when you do not use that feature. The "shallow clone", "sparse checkout", and "untracked cache" fall into the same category for exactly the same reason. The "submodule" feature might fall into the same category for the same reason, but that is not something you as a project participant can unilaterally decide, as the project you are working on may have already decided to use the feature, so it is harder to ban from the beginners. But for the rest of really "core" part of Git, I do not think there is any such command that can be totally banned. We have these "powerful" tools for a reason. After making a mess experimenting with your working tree files, "reset --hard" is the best tool to go back to the known-good state, and robbing it from the users is not a sound approach to help them. When "powerful" becomes "too powerful" is when a "powerful" tool is misused. It is perhaps done by mistake or perhaps done by copying and pasting a solution from Interweb for a problem that does not match your situation without understanding what you are doing. What is needed to help beginners is to make the powerful tool harder to misuse. Of course, that would be a harder task, because you have to do a real thinking. You do not have to do any thinking to say that "a blanket ban that hides these powerful tools behind the beginner mode" helps beginners, but I do not think it is solving what really matters. At the same time, it just adds to the FUD, i.e. some commands are too powerful for their own good. -- 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: applications open, deadline = Fri, 19/2
On Thu, Feb 18, 2016 at 12:41 AM, Lars Schneider wrote: >> Feel free to start writting an idea for >> http://git.github.io/SoC-2016-Ideas/. It'd be nice to have a few more >> ideas before Friday. We can polish them later if needed. > > I published my ideas here: > https://github.com/git/git.github.io/pull/125/files I like the idea of a beginner mode, but on the other hand that looks inflexible to me ;) (What if I want to use rebase, but not reset --hard?) I am confused by the black white mode, did you switch allow and deny in there? > > Do you think that works as start or do we need more detailed, hands-on > instructions? > > Thanks, > 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: applications open, deadline = Fri, 19/2
On Wed, 2016-02-17 at 13:33 -0800, Junio C Hamano wrote: > Jeff King writes: > > > On Wed, Feb 17, 2016 at 09:21:20PM +0100, Matthieu Moy wrote: > > > > > > I am wondering if we heard from libgit2 folks if they want us > > > > to > > > > host them (or they want to participate in GSoC at all). > > > > > > The libgit2 mention is left from previous versions of this page. > > > I left > > > a message on their IRC channel asking to join this thread if > > > people were > > > interested (I don't know the libgit2 community really well, and I > > > didn't > > > find a mailing-list to Cc here). > > > > > > I did not hear anything from them. We should probably remove the > > > mention > > > of libgit2. Or, if anyone receiving this message is interested in > > > having > > > libgit2 participate, or knows anyone who may be, speak now. > > > > I think they do a lot of their communication via GitHub issues. > > I've > > cc'd Carlos, the maintainer, who can ping the rest of the community > > as > > appropriate. > > > > I don't think we did a libgit2 project last year, and included the > > libgit2 references mainly so that we would not drop them with zero > > warning. > > Understandable. I do not mind seeing us hosting them if that is > what they want, but the candidate selection and mentor assignment > between two more-or-less independent projects would not work very > well unless there is _some_ degree of coordination ;-) We still have most of the same things open as for the 2014 list. I'll ask around to see if we have. Last year I wasn't involved in the candidate selection but IIRC we didn't do a project as none of the applications showed the candidates would be capable of doing the project they were applying for. I'll ask around to make sure people would be able to be mentors, but I think that we would still like to put forward a few projects (I can send a PR with the projects that we would still like to see to the 2016 page). Cheers, cmn -- 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: applications open, deadline = Fri, 19/2
On 17 Feb 2016, at 19:58, Matthieu Moy wrote: > Lars Schneider writes: > >> Coincidentally I started working on similar thing already (1) and I have >> lots of ideas around it. > > I guess it's time to start sharing these ideas then ;-). > > I think there's a lot to do. If we want to push this idea as a GSoC > project, we need: > > * A rough plan. We can't expect students to read a vague text like > "let's make Git safer" and write a real proposal out of it. > > * A way to start this rough plan incrementally (i.e. first step should > be easy and mergeable without waiting for next steps). > > Feel free to start writting an idea for > http://git.github.io/SoC-2016-Ideas/. It'd be nice to have a few more > ideas before Friday. We can polish them later if needed. I published my ideas here: https://github.com/git/git.github.io/pull/125/files Do you think that works as start or do we need more detailed, hands-on instructions? Thanks, 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: applications open, deadline = Fri, 19/2
Jeff King writes: > On Wed, Feb 17, 2016 at 09:21:20PM +0100, Matthieu Moy wrote: > >> > I am wondering if we heard from libgit2 folks if they want us to >> > host them (or they want to participate in GSoC at all). >> >> The libgit2 mention is left from previous versions of this page. I left >> a message on their IRC channel asking to join this thread if people were >> interested (I don't know the libgit2 community really well, and I didn't >> find a mailing-list to Cc here). >> >> I did not hear anything from them. We should probably remove the mention >> of libgit2. Or, if anyone receiving this message is interested in having >> libgit2 participate, or knows anyone who may be, speak now. > > I think they do a lot of their communication via GitHub issues. I've > cc'd Carlos, the maintainer, who can ping the rest of the community as > appropriate. > > I don't think we did a libgit2 project last year, and included the > libgit2 references mainly so that we would not drop them with zero > warning. Understandable. I do not mind seeing us hosting them if that is what they want, but the candidate selection and mentor assignment between two more-or-less independent projects would not work very well unless there is _some_ degree of coordination ;-) -- 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: applications open, deadline = Fri, 19/2
On Wed, Feb 17, 2016 at 09:21:20PM +0100, Matthieu Moy wrote: > > I am wondering if we heard from libgit2 folks if they want us to > > host them (or they want to participate in GSoC at all). > > The libgit2 mention is left from previous versions of this page. I left > a message on their IRC channel asking to join this thread if people were > interested (I don't know the libgit2 community really well, and I didn't > find a mailing-list to Cc here). > > I did not hear anything from them. We should probably remove the mention > of libgit2. Or, if anyone receiving this message is interested in having > libgit2 participate, or knows anyone who may be, speak now. I think they do a lot of their communication via GitHub issues. I've cc'd Carlos, the maintainer, who can ping the rest of the community as appropriate. I don't think we did a libgit2 project last year, and included the libgit2 references mainly so that we would not drop them with zero warning. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2016: applications open, deadline = Fri, 19/2
Junio C Hamano writes: > Matthieu Moy writes: > >> Feel free to start writting an idea for >> http://git.github.io/SoC-2016-Ideas/. It'd be nice to have a few more >> ideas before Friday. We can polish them later if needed. > > The top of the page says it is shared between Git and libgit2; > should that be really the case? We later say we only have capacity > for two mentors, but the mentor pool capacity is not shared between > two projects. > > I am wondering if we heard from libgit2 folks if they want us to > host them (or they want to participate in GSoC at all). The libgit2 mention is left from previous versions of this page. I left a message on their IRC channel asking to join this thread if people were interested (I don't know the libgit2 community really well, and I didn't find a mailing-list to Cc here). I did not hear anything from them. We should probably remove the mention of libgit2. Or, if anyone receiving this message is interested in having libgit2 participate, or knows anyone who may be, speak now. -- 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: applications open, deadline = Fri, 19/2
Lars Schneider writes: > Coincidentally I started working on similar thing already (1) and I have > lots of ideas around it. I guess it's time to start sharing these ideas then ;-). I think there's a lot to do. If we want to push this idea as a GSoC project, we need: * A rough plan. We can't expect students to read a vague text like "let's make Git safer" and write a real proposal out of it. * A way to start this rough plan incrementally (i.e. first step should be easy and mergeable without waiting for next steps). Feel free to start writting an idea for http://git.github.io/SoC-2016-Ideas/. It'd be nice to have a few more ideas before Friday. We can polish them later if needed. -- 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: applications open, deadline = Fri, 19/2
Matthieu Moy writes: > Feel free to start writting an idea for > http://git.github.io/SoC-2016-Ideas/. It'd be nice to have a few more > ideas before Friday. We can polish them later if needed. The top of the page says it is shared between Git and libgit2; should that be really the case? We later say we only have capacity for two mentors, but the mentor pool capacity is not shared between two projects. I am wondering if we heard from libgit2 folks if they want us to host them (or they want to participate in GSoC at all). -- 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: applications open, deadline = Fri, 19/2
On 17 Feb 2016, at 18:24, Thomas Gummerer wrote: > On 02/10, Matthieu Moy wrote: >> Work on the application itself, and on the list of ideas. > > One potential idea: > > Make destructive git commands more safe for the user. > > Some commands (e.g. git reset --hard, git clean -f, etc.) can > potentially destroy some of the users work. Store the information > that we are potentially losing somewhere, where it's easily > retrievable by the user. > > This should probably be hidden behind a new config variable > (core.iKnowWhatImDoingButIReallyDont or something better), as it has > the potential to really inflate the repository size (when storing > binary files that should be deleted by git clean for example). > > It happened more than once that I thought I knew what I was doing, but > would have been really glad if git saved me from my mistakes. > > I haven't thought this through much further than just the idea, so it > would be great to hear some opinions on it first. Coincidentally I started working on similar thing already (1) and I have lots of ideas around it. I get endless requests at my $DAYJOB of messed up Git repos where people just pasted stuff from StackOverflow without a deep understanding of what they are doing. If the lists agrees to take this topic for GSoC I would be happy to co-mentor it. Cheers, Lars (1) using Git config hacks > -- > 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: applications open, deadline = Fri, 19/2
On 02/10, Matthieu Moy wrote: > Work on the application itself, and on the list of ideas. One potential idea: Make destructive git commands more safe for the user. Some commands (e.g. git reset --hard, git clean -f, etc.) can potentially destroy some of the users work. Store the information that we are potentially losing somewhere, where it's easily retrievable by the user. This should probably be hidden behind a new config variable (core.iKnowWhatImDoingButIReallyDont or something better), as it has the potential to really inflate the repository size (when storing binary files that should be deleted by git clean for example). It happened more than once that I thought I knew what I was doing, but would have been really glad if git saved me from my mistakes. I haven't thought this through much further than just the idea, so it would be great to hear some opinions on it first. -- 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: applications open, deadline = Fri, 19/2
Hi Johannes, On Wed, Feb 17, 2016 at 2:09 PM, Johannes Schindelin wrote: > >> Then there is also git-bisect.sh with nearly 700 lines, which is also >> not as easy. > > Nothing is easy, but bisect has a much better chance to be finally > converted into a builtin: there is already a bisect--helper builtin, and > all we need to do is to move more parts over, piece by piece. It does not > even have to be a complete rewrite. I don't know which has a better chance to be finally converted, but it's true that for bisect, the bisect--helper builtin could help, and it can be done piece by piece. > I count 22 functions with bisect_start and bisect_replay being the obvious > elephants. Personally, I would recommend starting with bisect_next_check > (which would imply get_terms and bisect_voc, of course). It could even be > a mini project for a prospective student. Not sure it is small enough for a mini project, but sure it is a good choice to start with. Thanks, Christian. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2016: applications open, deadline = Fri, 19/2
Hi Stefan, On Tue, 16 Feb 2016, Stefan Beller wrote: > I'd be interested to co-mentor a sh->C conversion. > > I think the git-rebase*.sh is a good start. > > $ wc -l git-rebase*.sh > 101 git-rebase--am.sh > 1296 git-rebase--interactive.sh > 167 git-rebase--merge.sh > 636 git-rebase.sh > 2200 total > > So start with rebase--am and rebase--merge to have the same amount > of lines as git-pull.sh. I did not look at the code, just judging by > the lines of > code. > > git-rebase.sh with 636 lines of code is quite a lot I would think. As pointed out by Matthieu, starting with `git-rebase.sh` would be the wrong way round. In addition, I would like to point out that turning shell scripts into builtins is not only hard work, it is also very dull. Maybe we can offer GSoC students something more exciting, and *just maybe* they'll stick around longer (I am amazed how active Karthik is, for example). > Then there is also git-bisect.sh with nearly 700 lines, which is also > not as easy. Nothing is easy, but bisect has a much better chance to be finally converted into a builtin: there is already a bisect--helper builtin, and all we need to do is to move more parts over, piece by piece. It does not even have to be a complete rewrite. I count 22 functions with bisect_start and bisect_replay being the obvious elephants. Personally, I would recommend starting with bisect_next_check (which would imply get_terms and bisect_voc, of course). It could even be a mini project for a prospective student. Ciao, Johannes -- 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: applications open, deadline = Fri, 19/2
On Wed, Feb 17, 2016 at 5:34 PM, Matthieu Moy
wrote:
> Stefan Beller writes:
>
>> I'd be interested to co-mentor a sh->C conversion.
>>
>> I think the git-rebase*.sh is a good start.
>>
>> $ wc -l git-rebase*.sh
>> 101 git-rebase--am.sh
>> 1296 git-rebase--interactive.sh
>> 167 git-rebase--merge.sh
>> 636 git-rebase.sh
>> 2200 total
>>
>> So start with rebase--am and rebase--merge to have the same amount
>> of lines as git-pull.sh. I did not look at the code, just judging by
>> the lines of
>> code.
>
> There's a funny exercice there: the git-rebase--$type.sh scripts are not
> called as external helpers, but like this:
>
> run_specific_rebase () {
> if [ "$interactive_rebase" = implied ]; then
> GIT_EDITOR=:
> export GIT_EDITOR
> autosquash=
> fi
> . git-rebase--$type
> # ...
>
> So, turning these scripts into builtins would first require turning this
> ". git-rebase--$type" into an actual command call. But nothing
> unfeasible.
Yeah we can turn those git-rebase--*.sh into separate actual programs,
then we can convert git-rebase.sh to C and other subprograms at a
later time. I started something back in 2013 [1] but never managed to
finish it. Also see the abandoned rewrite effort [2] from git for
windows
[1] https://github.com/pclouds/git/commits/rebase-rewrite
[2] https://github.com/git-for-windows/git/pull/461
--
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: applications open, deadline = Fri, 19/2
Stefan Beller writes:
> I'd be interested to co-mentor a sh->C conversion.
>
> I think the git-rebase*.sh is a good start.
>
> $ wc -l git-rebase*.sh
> 101 git-rebase--am.sh
> 1296 git-rebase--interactive.sh
> 167 git-rebase--merge.sh
> 636 git-rebase.sh
> 2200 total
>
> So start with rebase--am and rebase--merge to have the same amount
> of lines as git-pull.sh. I did not look at the code, just judging by
> the lines of
> code.
There's a funny exercice there: the git-rebase--$type.sh scripts are not
called as external helpers, but like this:
run_specific_rebase () {
if [ "$interactive_rebase" = implied ]; then
GIT_EDITOR=:
export GIT_EDITOR
autosquash=
fi
. git-rebase--$type
# ...
So, turning these scripts into builtins would first require turning this
". git-rebase--$type" into an actual command call. But nothing
unfeasible.
Anyway, I'm not happy with the current shape of the code since
.-including files within a function already caused us several issues (I
fixed a FreeBSD related bug which triggered another one, so the current
code is a fix for a workaround for a FreeBSD issue ...).
I guess git-rebase--interactive.sh would be a lot for a single GSoC
project, but it can remain a shell-script helper called by a builtin.
Can you add more details to the "Convert scripts to builtins" part of
http://git.github.io/SoC-2016-Ideas/ to reflect this? And make it look
attractive for candidates ;-).
Thanks,
--
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: applications open, deadline = Fri, 19/2
On Sat, Feb 13, 2016 at 3:21 AM, Matthieu Moy wrote: > Jeff King writes: > >> On Fri, Feb 12, 2016 at 08:10:34AM +0100, Matthieu Moy wrote: >> >>> So, that makes it 4 possible co-mentors, i.e. 2 potential slots. Not >>> much, but it starts looking like last year ... ;-). >>> >>> Peff, would you be willing to co-admin with me (that would be cool, you >>> are the one with most experience here and you know the SFC stuff for >>> payment)? Are there any other co-admin volunteer? >> >> Yes, I'm willing to co-admin (though I'm also happy to step aside for >> somebody else if they would like to do it). > > Cool! > >> The biggest task there is getting the application together. I went >> through the account creation steps at the site (which is different this >> year), and the application questions are: >> >> - Why does your org want to participate in Google Summer of Code? >> >> - How many potential mentors have agreed to mentor this year? >> >> - How will you keep mentors engaged with their students? >> >> - How will you help your students stay on schedule to complete their >> projects? >> >> - How will you get your students involved in your community during GSoC? >> >> - How will you keep students involved with your community after GSoC? >> >> - Has your org been accepted as a mentoring org in Google Summer of Code >> before? >> >> - Are you part of a foundation/umbrella organization? >> >> - What year was your project started? >> >> I think we can pull most of these answers from previous-year >> applications, but I haven't looked yet. In years past we collaborated >> on the answers via the git.github.io site, and I pasted them in place. > > I started working on it. > > http://git.github.io/SoC-2015-Org-Application/ => the application itself. > Mostly cut-and-paste from last year, but the questions have changed a > bit. There's a "Remarks on the current state of the application" section > at the end for stuff I wasn't sure about. > > This is the urgent part, we won't have an opportunity to modify it after > the deadline. > > > Less urgent, but we need to add more stuff to be credible: > > http://git.github.io/SoC-2016-Ideas/ => Ideas page. I removed the > completed project, and updated some other to reflect the current state > of Git. I think "Convert scripts to builtins" is still feasible this > year, but probably harder (we can't say "start with git-pull.sh" > anymore ...). Johannes: you're still interested I guess? I'd be interested to co-mentor a sh->C conversion. I think the git-rebase*.sh is a good start. $ wc -l git-rebase*.sh 101 git-rebase--am.sh 1296 git-rebase--interactive.sh 167 git-rebase--merge.sh 636 git-rebase.sh 2200 total So start with rebase--am and rebase--merge to have the same amount of lines as git-pull.sh. I did not look at the code, just judging by the lines of code. git-rebase.sh with 636 lines of code is quite a lot I would think. Then there is also git-bisect.sh with nearly 700 lines, which is also not as easy. Thanks, Stefan > > http://git.github.io/SoC-2016-Microprojects/ => I just did s/2015/2016/. > I think most projects are not valid anymore, and we need new ones. > > To all: please contribute to these pages, either by sending patches here > (CC: me and peff), pushing directly if you have access, or submitting > pull-requests. The repo is https://github.com/git/git.github.io/. > > Thanks, > > -- > 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: applications open, deadline = Fri, 19/2
Jeff King writes: > On Fri, Feb 12, 2016 at 08:10:34AM +0100, Matthieu Moy wrote: > >> So, that makes it 4 possible co-mentors, i.e. 2 potential slots. Not >> much, but it starts looking like last year ... ;-). >> >> Peff, would you be willing to co-admin with me (that would be cool, you >> are the one with most experience here and you know the SFC stuff for >> payment)? Are there any other co-admin volunteer? > > Yes, I'm willing to co-admin (though I'm also happy to step aside for > somebody else if they would like to do it). Cool! > The biggest task there is getting the application together. I went > through the account creation steps at the site (which is different this > year), and the application questions are: > > - Why does your org want to participate in Google Summer of Code? > > - How many potential mentors have agreed to mentor this year? > > - How will you keep mentors engaged with their students? > > - How will you help your students stay on schedule to complete their > projects? > > - How will you get your students involved in your community during GSoC? > > - How will you keep students involved with your community after GSoC? > > - Has your org been accepted as a mentoring org in Google Summer of Code > before? > > - Are you part of a foundation/umbrella organization? > > - What year was your project started? > > I think we can pull most of these answers from previous-year > applications, but I haven't looked yet. In years past we collaborated > on the answers via the git.github.io site, and I pasted them in place. I started working on it. http://git.github.io/SoC-2015-Org-Application/ => the application itself. Mostly cut-and-paste from last year, but the questions have changed a bit. There's a "Remarks on the current state of the application" section at the end for stuff I wasn't sure about. This is the urgent part, we won't have an opportunity to modify it after the deadline. Less urgent, but we need to add more stuff to be credible: http://git.github.io/SoC-2016-Ideas/ => Ideas page. I removed the completed project, and updated some other to reflect the current state of Git. I think "Convert scripts to builtins" is still feasible this year, but probably harder (we can't say "start with git-pull.sh" anymore ...). Johannes: you're still interested I guess? http://git.github.io/SoC-2016-Microprojects/ => I just did s/2015/2016/. I think most projects are not valid anymore, and we need new ones. To all: please contribute to these pages, either by sending patches here (CC: me and peff), pushing directly if you have access, or submitting pull-requests. The repo is https://github.com/git/git.github.io/. Thanks, -- 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: applications open, deadline = Fri, 19/2
On Fri, Feb 12, 2016 at 08:04:46AM -0500, Jeff King wrote: > The biggest task there is getting the application together. I went > through the account creation steps at the site (which is different this > year), and the application questions are: > [...] We also need to fill out our profile. Those items are listed below. Matthieu, I listed you as a co-mentor, so I think it will have sent you an email to join the application I started (hopefully you didn't do the exact same thing already... :) ). - Website URL - Tagline - Logo - Primary Open Source License - Organization Category - Technology Tags - Topic Tags - Ideas List - Short Description - Long Description - Application Instructions - Proposal Tags - IRC Channel, Mailing List, or Email The big thing there is the ideas list. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2016: applications open, deadline = Fri, 19/2
On Fri, Feb 12, 2016 at 08:10:34AM +0100, Matthieu Moy wrote: > So, that makes it 4 possible co-mentors, i.e. 2 potential slots. Not > much, but it starts looking like last year ... ;-). > > Peff, would you be willing to co-admin with me (that would be cool, you > are the one with most experience here and you know the SFC stuff for > payment)? Are there any other co-admin volunteer? Yes, I'm willing to co-admin (though I'm also happy to step aside for somebody else if they would like to do it). The biggest task there is getting the application together. I went through the account creation steps at the site (which is different this year), and the application questions are: - Why does your org want to participate in Google Summer of Code? - How many potential mentors have agreed to mentor this year? - How will you keep mentors engaged with their students? - How will you help your students stay on schedule to complete their projects? - How will you get your students involved in your community during GSoC? - How will you keep students involved with your community after GSoC? - Has your org been accepted as a mentoring org in Google Summer of Code before? - Are you part of a foundation/umbrella organization? - What year was your project started? I think we can pull most of these answers from previous-year applications, but I haven't looked yet. In years past we collaborated on the answers via the git.github.io site, and I pasted them in place. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2016: applications open, deadline = Fri, 19/2
Lars Schneider writes: > I don't know what level of Git development knowledge and what amount of time > is necessary but I would be available as junior co-mentor :-) AFAICT, you don't have much experience with Git's codebase itself (if I don't count git-p4 as "Git itself"), but you've already been involved in typical reviewing cycles (just the discussions on Travis-CI were a good example), and that is something at least as important as knowing the codebase well. It's up to you to decide whether you feel experienced enough, but I think you are welcome as a co-mentor! As a mentor, to me, the most important things are: * Give advice on how to interact with the Git community. Students can be shy, and then repeating "you should post more to the mailing-list" can be useful. They sometimes make mistakes, and explaining off-list "there's nothing wrong with what you did, but the custom here is to ..." can help. * Give advice on how to get useful code merged. My usual advice is: "don't be too ambitious", which translates to "git this part done, reviewed and possibly merged, you'll work on the bells and whistles later". * Avoid overloading the list with reviews. Getting your own GSoC tee-shirt and letting the list do the work is unfair ;-). Off-list reviews are good to eliminate straightforwards issues, and then mentors should actively participate to the on-list review. That is probably what takes most time. -- 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: applications open, deadline = Fri, 19/2
On 12 Feb 2016, at 08:10, Matthieu Moy wrote: > Christian Couder writes: > >> Hi, >> >> On Wed, Feb 10, 2016 at 10:31 AM, Matthieu Moy >> wrote: >>> >>> So, the first question is: are there volunteers to be GSoC mentors this >>> year? >> >> I can co-mentor this year too, with you or someone else. >> With you I think it will work out even if you have less time than last year. > > So, that makes it 4 possible co-mentors, i.e. 2 potential slots. Not > much, but it starts looking like last year ... ;-). > > Peff, would you be willing to co-admin with me (that would be cool, you > are the one with most experience here and you know the SFC stuff for > payment)? Are there any other co-admin volunteer? I don't know what level of Git development knowledge and what amount of time is necessary but I would be available as junior co-mentor :-) 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: applications open, deadline = Fri, 19/2
Christian Couder writes: > Hi, > > On Wed, Feb 10, 2016 at 10:31 AM, Matthieu Moy > wrote: >> >> So, the first question is: are there volunteers to be GSoC mentors this >> year? > > I can co-mentor this year too, with you or someone else. > With you I think it will work out even if you have less time than last year. So, that makes it 4 possible co-mentors, i.e. 2 potential slots. Not much, but it starts looking like last year ... ;-). Peff, would you be willing to co-admin with me (that would be cool, you are the one with most experience here and you know the SFC stuff for payment)? Are there any other co-admin volunteer? -- 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: applications open, deadline = Fri, 19/2
Hi, On Wed, Feb 10, 2016 at 10:31 AM, Matthieu Moy wrote: > > So, the first question is: are there volunteers to be GSoC mentors this > year? I can co-mentor this year too, with you or someone else. With you I think it will work out even if you have less time than last year. Best, Christian. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2016: applications open, deadline = Fri, 19/2
On Wed, Feb 10, 2016 at 3:09 AM, Johannes Schindelin wrote: > Hi Matthieu, > > On Wed, 10 Feb 2016, Matthieu Moy wrote: > >> I think participating is a good thing, but it needs mentors, ie. people >> and time. I am people and I have time! ;) > > I am available for mentoring. Stefan, it was really fun to co-mentor with > you, would you be willing to repeat the exercise? Sure thing. > > Ciao, > Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC 2016: applications open, deadline = Fri, 19/2
Hi Matthieu, On Wed, 10 Feb 2016, Matthieu Moy wrote: > I think participating is a good thing, but it needs mentors, ie. people > and time. I am available for mentoring. Stefan, it was really fun to co-mentor with you, would you be willing to repeat the exercise? Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
GSoC 2016: applications open, deadline = Fri, 19/2
Hi, The GSoC (Google Summer of Code) application for mentoring organizations is now open. The deadline is Friday, February 19 at 19:00 UTC. That is: very soon. New website here: https://summerofcode.withgoogle.com/. More info about Git's previous GSoC iterations there: http://git.github.io/SoC-2015-Microprojects/, http://git.github.io/SoC-2015-Org-Application/. I haven't been watching the list very closely the last few weeks, but I didn't see a discussion on whether we shall participate this year, other than "Starting on a microproject for GSoC" (http://thread.gmane.org/gmane.comp.version-control.git/284958). I think participating is a good thing, but it needs mentors, ie. people and time. On my side, I'd be happy to give a hand to GSoC, but unfortunately, I won't have time to properly mentor a student. I can be co-admin, and can help someone to mentor, but only if this someone agrees to do most of the work. Yes, I do realize that this sounds like "we should do it, but someone else should do the work" ;-). So, the first question is: are there volunteers to be GSoC mentors this year? For those who never did it: mentoring means giving advices to the student (partly done during the "microproject" phase in our organization), participating actively in reviews (possibly doing some first review iterations off-list to avoid overloading the list). On overall, the goal is to make sure that some useful code is merged before the end. It's a very enjoyable experience, it can be done with reasonable knowledge of Git's codebase and community (no need to be an old-timer), but it needs time to be done properly (expect to get ~10 iterations of each patch series, and spend hour(s) on each). And you get a nice tee-shirt to show off with your geek friends. If we have enough potential mentors, then the next questions are: who's the admin? Work on the application itself, and on the list of ideas. Cheers, -- 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
