> On Oct 13, 2016, at 11:03 AM, Robinson, Paul via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > | 6. How important is cross-project blame, grep, etc.? > <> > I don't understand "cross-project blame" as it works on one file at a time?True, not straightforward blame. My workflow when trying to track the history of some code involves frequently blaming recursively. When I reach a commit that moved the function, I switch file, but continue *from the same commit*. This is only possible in the same repository. Another thing I use daily is finding “when was this added”, using git “pickaxe” (git log S ….). Which again works only inside a repository.> Also, is this question intended to cover bisection? > Thanks, > --paulr > > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Duncan P. N. Exon Smith via llvm-dev > Sent: Wednesday, October 12, 2016 7:07 PM > To: Renato Golin > Cc: LLVM Dev; Tanya Lattner > Subject: Re: [llvm-dev] GitHub Survey? > > > > On 2016-Sep-18, at 09:51, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > Folks, > > > > After feedback from Chris and Mehdi, I have added one long text answer > > to *each* critical questions (impact on productivity), so that people > > can extend their reasoning. > > > > But I have not made them compulsory, so that people that don't know > > much about or don't have any problem don't feel compelled to expand on > > nothing. > > > > https://docs.google.com/forms/d/e/1FAIpQLSc2PBeHW-meULpCOpmbGK1yb2qX8yzcQBtT4nqNF05vSv69WA/viewform <https://docs.google.com/forms/d/e/1FAIpQLSc2PBeHW-meULpCOpmbGK1yb2qX8yzcQBtT4nqNF05vSv69WA/viewform> > > > > The bottom line is, answers with more substance will be taken more > > seriously than those without, but the numbers should also tell us > > something. > > > > For example, if 9/10 of the answers are "we don't care", than the > > other 1/10 will have less weight than if it was 1/2, but still > > important to any decision. > > > > Can we go live with what we have now? > > > > Mehdi, how's the document? Can we get that online so I can change the > > header of the survey? > > Hi Renato, > > Thanks very much for putting this together. > > I think the proposal document is almost finished now. Since I ended up reviewing it pretty thoroughly, I've gained a bit of understanding about the concerns we need input on. > > The survey is a great start, but the final page isn't quite addressing the concerns in the final proposal. I'm not sure it asks the right questions to focus the conversation at the BoF. > > Firstly, I'm concerned that the questions focus on: > - what's good for the individuals responding, instead of what they think is best for the LLVM project; and > - how much pain the transition would cause, instead of what they think the right final state is. > > Secondly, I'm worried about this question: "How does the choice between a single repository with all projects and the use of sub-modules impact your usage of Git?" I'm not sure we'll good signal from this; it's essentially a vote on the two variants, but it doesn't force the respondent to think about the specific issues. I'd rather find a way to ask about the specific concerns raised in the document. > > Thirdly, I'm worried that the follow-ups talk about "preferred" and "non-preferred" instead of "multirepo" and "monorepo". This makes data-mining non-trivial (because the meaning depends on previous answers) and increases the chance of respondent confusion. > > I spent some time today thinking through what set of questions would get us the data we want. > - I've focused on the main concerns about (and benefits of) the two variants. > - I've referred to the multirepo and monorepo by name (consistently) in questions asking about them. This ensures that people know exactly what they're answering. > - I've added specific questions about how people plan to use the multirepo and monorepo, so that we know which tooling is most important (and also to determine how worried we should be about some of the concerns). > - I've moved the "vote"-like question to the end to force respondents to think through the issues first. I've also restricted "the vote" to "the ideal project setup", so we can clearly separate that from "transition pain". (I'm still not sure the vote will have much value, but it doesn't hurt.) > > Here are my suggested questions; feedback welcome: > > ---- > > 1. How do you use LLVM? > // as is > > 2. Which projects do you contribute to / use? > // as is > > 3. Use this field to expand on your usage, if necessary > // as is > > 4. How often do you work on a small LLVM sub-project without using a checkout of LLVM itself? > - Always. > - Most of the time. > - Sometimes. > - Never. > > 5. Please categorize how you interact with upstream. > - I need read/write access, and I have limited disk space. > - I need read/write access, but a 1GB clone doesn't scare me. > - I only need read access. > > 6. How important is cross-project blame, grep, etc.? > - Vital. I already use SVN/monorepo/custom-tooling to accomplish this. > - Extremely. It should be easy enough that everyone does it by default. > - Somewhat. I would use it if it were easy, but it's just nice to have. > - Not at all. Anyone who cares can write their own tooling. > > 7. Single-commit cross-project refactoring designs away a class of build failures and simplifies making API changes. How important is it? > - Vital. I already use SVN/monorepo/custom-tooling to accomplish this. > - Extremely. It should be easy enough that everyone does it by default. > - Somewhat. I would use it if it were easy, but it's just nice to have. > - Not at all. Anyone who cares can write their own tooling. > > 8. The multirepo variant provides read-only umbrella repository to coordinate commits between the split sub-project repositories using Git submodules. Assuming multirepo gets adopted, how do you expect to use the umbrella? > // checkboxes: > + Actively contribute tooling improvements to improve it. > + Integrate it into our downstream fork. > + Use it for upstream contributions. > + Use it as the primary interface development environment. > + Use it for bisection. > > 9. If multirepo is adopted, how do you plan to contribute to upstream? > - Using Git submodules. > - Using the Git repos directly. > - Using the SVN bridges. > - n/a: I don't contribute. > > 10. The monorepo variant provides read/write access to sub-projects via an SVN bridge and git-svn. Contributors will have the option to continue using repositories split on project boundaries. Assuming monorepo gets adopted, how do you plan to contribute? > - I'll use the monorepo as soon as it's possible, even before it's canonical. > - I'll use the monorepo as soon as it's canonical. > - I'll transition to monorepo eventually. > - I'll use the SVN bridge on separated sub-projects forever. > - I'll use a Git mirror (and/or git-svn) on separated sub-projects forever. > - n/a: I don't contribute. > > 11. If monorepo is adopted, how do you plan to integrate it downstream? > - We already use monorepo. > - We'll switch to pulling from monorepo during the transition period. > - We'll switch to pulling from monorepo eventually. > - We'll integrate from the SVN bridge forever. > - We'll integrate from the split sub-project Git mirror forever. > - n/a: There is no downstream. > > 12. The multi/mono hybrid variant merges some sub-projects, but leaves runtimes in separate repositories using the umbrella to tie them together. Is this the best or worst of both worlds? > - This is great. Native cross-project refactoring, without penalizing runtime-only developers. > - Whatever. I'll deal with it. > - This is terrible. All the transition pain of monorepo, without the advantages. > > 13. If multirepo is adopted, how much pain will there be in your transition? > - Nothing consequential. > - A little; but it'll be fine. > - A lot; but it'll get done somehow. > - Too much; I/we may stop contributing to LLVM. > > 14. If monorepo is adopted, how much pain will there be in your transition? > - Nothing consequential. > - A little; but it'll be fine. > - A lot; but it'll get done somehow. > - Too much; I/we may stop contributing to LLVM. > > 15. If we could go back in time and restart the project with today's technologies, which repository scheme would be best for the LLVM project? > - CVS. > - Subversion repository with split sub-projects (<sub-project>/trunk), with git-svn. > - Subversion repository as a single project (trunk/<sub-project>), with git-svn. > - Git: multirepo variant. > - Git: monorepo variant. > - Git: multi/mono hybrid variant. > - Other. > > 16. Other comments. > // Open text field. > > ---- > > Thanks again for your hard work on this! > > Duncan > > P.S. I think there's a bug on in the survey (or maybe my browser). I'm seeing some stray "If responding for a" text at the top. See the PDF I've attached here. > > > > > We only have a month and a bit now... > > > > cheers, > > --renato > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>_______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161013/1218ebb0/attachment.html>
On 13 October 2016 at 19:09, Mehdi Amini <mehdi.amini at apple.com> wrote:> When I reach a commit that moved the function, I switch file, but continue > *from the same commit*. This is only possible in the same repository.Due to their physical separation, I don't think people have been moving code between projects in that manner. If we keep the separation (sub-mods), is it possible to move files between sub-modules? If we do mono-repo, then the problem goes away.> Another thing I use daily is finding “when was this added”, using git > “pickaxe” (git log S ….). Which again works only inside a repository.Uh, that looks nice. Can you share your alias? :) cheers, --renato
> On 2016-Oct-13, at 11:09, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Oct 13, 2016, at 11:03 AM, Robinson, Paul via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> | 6. How important is cross-project blame, grep, etc.? >> >> I don't understand "cross-project blame" as it works on one file at a time? > > True, not straightforward blame. > My workflow when trying to track the history of some code involves frequently blaming recursively. > When I reach a commit that moved the function, I switch file, but continue *from the same commit*. This is only possible in the same repository. > Another thing I use daily is finding “when was this added”, using git “pickaxe” (git log S ….). Which again works only inside a repository.Maybe it makes sense to leave blame out of it, since it would be awkward to explain here? Happy with suggested wording either way (probably at least move "grep" to the front of the list, since that one is obvious).> >> Also, is this question intended to cover bisection?Not exactly, but maybe a little. It's also partially covered by the checkbox in #8. Note that bisection will work pretty similarly between the variants (assuming write-once tooling is in place for the umbrella). Just now I tried to come up with wording specifically for bisection (either in the style of #7, or using checkboxes to sort out which differences matter), but failed to come up with something that (a) we'd get real data from and (b) wasn't already covered by other questions about tooling differences. If you have a suggestion, that would be great.>> Thanks, >> --paulr >> >> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Duncan P. N. Exon Smith via llvm-dev >> Sent: Wednesday, October 12, 2016 7:07 PM >> To: Renato Golin >> Cc: LLVM Dev; Tanya Lattner >> Subject: Re: [llvm-dev] GitHub Survey? >> >> >> > On 2016-Sep-18, at 09:51, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> > >> > Folks, >> > >> > After feedback from Chris and Mehdi, I have added one long text answer >> > to *each* critical questions (impact on productivity), so that people >> > can extend their reasoning. >> > >> > But I have not made them compulsory, so that people that don't know >> > much about or don't have any problem don't feel compelled to expand on >> > nothing. >> > >> > https://docs.google.com/forms/d/e/1FAIpQLSc2PBeHW-meULpCOpmbGK1yb2qX8yzcQBtT4nqNF05vSv69WA/viewform >> > >> > The bottom line is, answers with more substance will be taken more >> > seriously than those without, but the numbers should also tell us >> > something. >> > >> > For example, if 9/10 of the answers are "we don't care", than the >> > other 1/10 will have less weight than if it was 1/2, but still >> > important to any decision. >> > >> > Can we go live with what we have now? >> > >> > Mehdi, how's the document? Can we get that online so I can change the >> > header of the survey? >> >> Hi Renato, >> >> Thanks very much for putting this together. >> >> I think the proposal document is almost finished now. Since I ended up reviewing it pretty thoroughly, I've gained a bit of understanding about the concerns we need input on. >> >> The survey is a great start, but the final page isn't quite addressing the concerns in the final proposal. I'm not sure it asks the right questions to focus the conversation at the BoF. >> >> Firstly, I'm concerned that the questions focus on: >> - what's good for the individuals responding, instead of what they think is best for the LLVM project; and >> - how much pain the transition would cause, instead of what they think the right final state is. >> >> Secondly, I'm worried about this question: "How does the choice between a single repository with all projects and the use of sub-modules impact your usage of Git?" I'm not sure we'll good signal from this; it's essentially a vote on the two variants, but it doesn't force the respondent to think about the specific issues. I'd rather find a way to ask about the specific concerns raised in the document. >> >> Thirdly, I'm worried that the follow-ups talk about "preferred" and "non-preferred" instead of "multirepo" and "monorepo". This makes data-mining non-trivial (because the meaning depends on previous answers) and increases the chance of respondent confusion. >> >> I spent some time today thinking through what set of questions would get us the data we want. >> - I've focused on the main concerns about (and benefits of) the two variants. >> - I've referred to the multirepo and monorepo by name (consistently) in questions asking about them. This ensures that people know exactly what they're answering. >> - I've added specific questions about how people plan to use the multirepo and monorepo, so that we know which tooling is most important (and also to determine how worried we should be about some of the concerns). >> - I've moved the "vote"-like question to the end to force respondents to think through the issues first. I've also restricted "the vote" to "the ideal project setup", so we can clearly separate that from "transition pain". (I'm still not sure the vote will have much value, but it doesn't hurt.) >> >> Here are my suggested questions; feedback welcome: >> >> ---- >> >> 1. How do you use LLVM? >> // as is >> >> 2. Which projects do you contribute to / use? >> // as is >> >> 3. Use this field to expand on your usage, if necessary >> // as is >> >> 4. How often do you work on a small LLVM sub-project without using a checkout of LLVM itself? >> - Always. >> - Most of the time. >> - Sometimes. >> - Never. >> >> 5. Please categorize how you interact with upstream. >> - I need read/write access, and I have limited disk space. >> - I need read/write access, but a 1GB clone doesn't scare me. >> - I only need read access. >> >> 6. How important is cross-project blame, grep, etc.? >> - Vital. I already use SVN/monorepo/custom-tooling to accomplish this. >> - Extremely. It should be easy enough that everyone does it by default. >> - Somewhat. I would use it if it were easy, but it's just nice to have. >> - Not at all. Anyone who cares can write their own tooling. >> >> 7. Single-commit cross-project refactoring designs away a class of build failures and simplifies making API changes. How important is it? >> - Vital. I already use SVN/monorepo/custom-tooling to accomplish this. >> - Extremely. It should be easy enough that everyone does it by default. >> - Somewhat. I would use it if it were easy, but it's just nice to have. >> - Not at all. Anyone who cares can write their own tooling. >> >> 8. The multirepo variant provides read-only umbrella repository to coordinate commits between the split sub-project repositories using Git submodules. Assuming multirepo gets adopted, how do you expect to use the umbrella? >> // checkboxes: >> + Actively contribute tooling improvements to improve it. >> + Integrate it into our downstream fork. >> + Use it for upstream contributions. >> + Use it as the primary interface development environment. >> + Use it for bisection. >> >> 9. If multirepo is adopted, how do you plan to contribute to upstream? >> - Using Git submodules. >> - Using the Git repos directly. >> - Using the SVN bridges. >> - n/a: I don't contribute. >> >> 10. The monorepo variant provides read/write access to sub-projects via an SVN bridge and git-svn. Contributors will have the option to continue using repositories split on project boundaries. Assuming monorepo gets adopted, how do you plan to contribute? >> - I'll use the monorepo as soon as it's possible, even before it's canonical. >> - I'll use the monorepo as soon as it's canonical. >> - I'll transition to monorepo eventually. >> - I'll use the SVN bridge on separated sub-projects forever. >> - I'll use a Git mirror (and/or git-svn) on separated sub-projects forever. >> - n/a: I don't contribute. >> >> 11. If monorepo is adopted, how do you plan to integrate it downstream? >> - We already use monorepo. >> - We'll switch to pulling from monorepo during the transition period. >> - We'll switch to pulling from monorepo eventually. >> - We'll integrate from the SVN bridge forever. >> - We'll integrate from the split sub-project Git mirror forever. >> - n/a: There is no downstream. >> >> 12. The multi/mono hybrid variant merges some sub-projects, but leaves runtimes in separate repositories using the umbrella to tie them together. Is this the best or worst of both worlds? >> - This is great. Native cross-project refactoring, without penalizing runtime-only developers. >> - Whatever. I'll deal with it. >> - This is terrible. All the transition pain of monorepo, without the advantages. >> >> 13. If multirepo is adopted, how much pain will there be in your transition? >> - Nothing consequential. >> - A little; but it'll be fine. >> - A lot; but it'll get done somehow. >> - Too much; I/we may stop contributing to LLVM. >> >> 14. If monorepo is adopted, how much pain will there be in your transition? >> - Nothing consequential. >> - A little; but it'll be fine. >> - A lot; but it'll get done somehow. >> - Too much; I/we may stop contributing to LLVM. >> >> 15. If we could go back in time and restart the project with today's technologies, which repository scheme would be best for the LLVM project? >> - CVS. >> - Subversion repository with split sub-projects (<sub-project>/trunk), with git-svn. >> - Subversion repository as a single project (trunk/<sub-project>), with git-svn. >> - Git: multirepo variant. >> - Git: monorepo variant. >> - Git: multi/mono hybrid variant. >> - Other. >> >> 16. Other comments. >> // Open text field. >> >> ---- >> >> Thanks again for your hard work on this! >> >> Duncan >> >> P.S. I think there's a bug on in the survey (or maybe my browser). I'm seeing some stray "If responding for a" text at the top. See the PDF I've attached here. >> >> > >> > We only have a month and a bit now... >> > >> > cheers, >> > --renato >> > _______________________________________________ >> > LLVM Developers mailing list >> > llvm-dev at lists.llvm.org >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> On Oct 13, 2016, at 11:36 AM, Renato Golin <renato.golin at linaro.org> wrote: > > On 13 October 2016 at 19:09, Mehdi Amini <mehdi.amini at apple.com> wrote: >> When I reach a commit that moved the function, I switch file, but continue >> *from the same commit*. This is only possible in the same repository. > > Due to their physical separation, I don't think people have been > moving code between projects in that manner.Most people are not doing this.> > If we keep the separation (sub-mods), is it possible to move files > between sub-modules?Yes, but not with a single commit, it is “deleting code / file in repo X”, and then “adding code / file in repo Y”. So the git log in repo Y stops at some point, where the commit message says “moving feature F from repo X”. And then you need to close repo X, and use "git log” to find when it was taken out, and resume your blame from here.> > If we do mono-repo, then the problem goes away. > > >> Another thing I use daily is finding “when was this added”, using git >> “pickaxe” (git log S ….). Which again works only inside a repository. > > Uh, that looks nice. Can you share your alias? :)No alias, standard git: git log -S “something” One description I found online (http://jfire.io/blog/2012/03/07/code-archaeology-with-git/ <http://jfire.io/blog/2012/03/07/code-archaeology-with-git/> ) is: "Pickaxes are often useful for archaeological purposes, and git’s pickaxe is no exception. It refers to the -S option to git log. The -S option takes a string parameter and searches the commit history for commits that introduce or remove that string. That’s not quite the same thing as searching for commits whose diff contains the string—the change must actually add or delete that string, not simply include a line on which it appears.” — Mehdi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161013/67b2e75f/attachment.html>