search for: pr1234

...eping the origins dates, so this is a no-go for us. Losing forks connections would strongly affect downstream users as well. This allowed to formulate the following scheme: 1. Migrate Bugzilla to a new repo, say, llvm-bugzilla-import using the internal storage format. 2. Install redirects llvm.org/PR1234 => gh/llvm/llvm-bugzilla-import/issues/1234 3. Wipe existing issues and pull requests 4. Migrate all issues from llvm-bugzilla-import to llvm-project using GH API. Github will take about llvm-bugzilla-import/issues/1234 => llvm-project/issues/5678 redirects The only downside of this approach...

...ify whether we will be able to reset the counter or not > > 4. Migrate all issues from llvm-bugzilla-import to llvm-project using > > GH API. Github will take about llvm-bugzilla-import/issues/1234 => > > llvm-project/issues/5678 redirects > If we're setting a redirect, PR1234 wouldn't hit #5678. We either > guarantee that the IDs will be identical or we'll need a smart > redirect that will know the delta (or 1:1 relationship). Why? If you migrate the issue inside GH, then GH does the necessary redirects on its side. So, we will be taking care about PR1234...

Philip Reames <listmail at philipreames.com> writes: > Let's say I post a patch, and the (warranted) reviewer comment is that > it should be split.  I push a couple new PRs, they get approved, and > landed.  (All as new branches off master.)  Then, I have a stale branch > (say it contains 2 commits) which needs rewritten.  I can of course do > an interactive rebase, and a

...which seems to be working correctly. I ran the following command 5 times, changing the "map to guest" parameter, and typing my password correctly and incorrectly. Here are my results: ----------------------------------------------------------------------- > smbclient '\\BOITEST\PR1234' -U dan_thibadeau -W palo-alto 1) set: map to guest = Never typed correct password result: smbstatus shows "uid" is "pcguest" connection was made, and I got prompt (typed "exit") 2) set: map to guest = Never typed WRONG password res...

On 17 May 2016 at 02:07, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Basically, the high-level status is: > 1. Commits should state when they are fixes. > 2. Bugs should be tracked in a PR. Yup. > None of these is a hard requirement but instead, best practices that we > should remind to the contributors. > For #1, I propose the attached patch for

On 4/21/20 7:00 PM, Tom Stellard via llvm-dev wrote: > On 04/21/2020 03:36 PM, Richard Smith via llvm-dev wrote: >> On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: >> >> +1 to James's take >> >> I'd prefer simplicity of implementation over perfection here.

...optimization to the compiler code - an optimization to the generated code - a refactoring It’s not always easy to distinguish between the first four, and you really want to understand it before cherry-picking in a long living branch. Oh, and PRs are nice, but when the commit message is just “Fix PR1234”, it’s still quite some work to figure out what to do with the commit :-) Fred -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160510/f6965811/attachment.html>

...er, this is about changing how people write commit messages and it's not a trivial matter. We already got used to doing this, unless there's a strong argument against the current model, I don't think we should change it. > I miss the point. > For existing PR we would have: fixes PR1234. > For new PR we would have: fixes PRNew, where PRNew is a keyword that means create a PR and put the actual number in place of PRNew. But that's not all there is to it... The PRNew tag will mean: create a bug, add the text of this commit to it, mark it fixed by this commit, close it. Fir...

> On May 4, 2016, at 4:41 PM, Jim Grosbach <grosbach at apple.com> wrote: > >> >> On May 2, 2016, at 4:03 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi Hans, >> >> Since you are actively doing this kind of things, your feedbacks is particularly valuable. >>