similar to: Workflow to commit changes using git alone (?)

Hi All, Ok, just for the matter of providing feedback that may be useful for others, I figured out one way to do it based on the setup that I described earlier. It can be something like this git checkout patchbranch # checkout to the patch branch, this is the one containing the differential patch code git checkout -b tmp # checkout to a new tmp branch git reset —soft master

If you want to use your key to authenticate, you need to set your remote URL to the SSH one: git remote set-url --push origin git at github.com:llvm/llvm-project.git You can get the SSH URL by going to https://github.com/llvm/llvm-project/ and clicking on Clone or download to get the appropriate URL ... it should give you the option to Clone with SSH. I've not had a ton of luck with HTTPS

Hi all, I have recently given commit access to LLVM and successfully pushed a test commit from my local master branch. However, I can’t find which is the recommended workflow for committing more serious stuff using git alone. I have read the docs but everything seems to still require svn before bridging to github. I want to use git alone to commit a patch that I got reviewed. I currently have

Hi Hiroshi, Thanks for that. I find “rebase” difficult to use. Maybe I don’t understand it, but it always causes a lot ‘conflicts’ that are very hard to fix according to my experience. I have another question though. LLVM requires that reviewed patches are pushed as a /single/ commit with a standardised message, particularly specifying the Differential Revision url as part of the commit message.

Hi Mehdi, > On 10 Nov 2019, at 20:27, Mehdi AMINI <joker.eph at gmail.com> wrote: > > No: the arcanist command does not suffer from the problem I was raising. > The issue I was referring to is that your reset command will lead to *undoing* changes from master (unrelated to your branch) when you commit in the end (all the changes that are in master but not in

> On 10 Nov 2019, at 07:00, Mehdi AMINI <joker.eph at gmail.com> wrote: > > recipe is not correct in the absolute: the delta from master does not mean it contains exactly what you want, you seem to assume that master didn't evolve between the time "patchbranch" was created. > Hi Mehdi, I’m doing it this way to make sure that master /actually/ contains “exactly

About ftrapping-math: I think we should eliminate ftrapping-math, a boolean option, because it overlaps with ffp-exception-behavior, a 3 valued option. Or we can keep it in the clang driver for compatibility, but it should be rewritten by clang driver into ffp-exception-behavior=ignore and ffp-exception-behavior=strict. There are various fields in llvm and/or clang that maintain Boolean

Yes, you’re probably right about this. I was originally thinking of FENV_ACCESS as a fully strict mode of operation, but what you’re suggesting aligns with what Cameron suggested and even some of my own reasoning on other points. So, let me amend my previous proposal to say: STDC FENV_ACCESS {ON|OFF} Patch in progress. I think ON should force the following: except_behavior { strict }

Hans van Kranenburg writes ("Re: git workflow, redux"): > On 08/23/2018 08:07 PM, Ian Jackson wrote: > > I think git-debrebase is going to be easier for all these things than > > the current approach. > > Ok, let's try it! Thanks a lot for doing the above writeup. Great, thanks. (I hope it's OK that I have snipped most of your responses to the discussion,

I don’t know what you mean by dealing with the merging, I don’t expect any difficulties, you need to elaborate. What I don’t see you addressing here is why this should be more of a problem in the monorepo case (as it was implied in the email I was answering to). Your answer made it sound like you thought the monorepo would solve all downstream problems ("I don't know what you mean… I

> On Jul 29, 2016, at 11:07 AM, Robinson, Paul <paul.robinson at sony.com> wrote: > > > >> -----Original Message----- >> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org <mailto:llvm-dev-bounces at lists.llvm.org>] On Behalf Of Mehdi >> Amini via llvm-dev >> Sent: Friday, July 29, 2016 10:02 AM >> To: David Chisnall >> Cc:

> ... math errno ... I wouldn't recommend to anyone that they should rely on math errno (because I don't trust libraries to correctly support it). My goal here was to incorporate our existing support for it into the rest of what I'm trying to document. My understanding is that for clang this primarily controls whether or not we feel free to substitute intrinsics for recognized

> And if it is, then the "only thing a monorepo gets you" isn't something that you need a monorepo to get. This is an *extremely important* point to understand, so let me try to be really clear about the current state of the world and the state of the world under the two "move to git" proposals. Today, all commits ultimately end up in SVN. Our SVN is a effectively a

By the way, I've been using the existing read-only monorepo [1] for a few days now. The intent is to commit via the script I put together [2], although I haven't committed anything other than a testing commit [3]. All I can say is, *wow* is it nice. I hid everything I don't care about using a sparse checkout [4]. Many of my tools (e.g. ctrl-p [5] [6], ycm [7]) suddenly work better

Thanks for elaborating, Chris. > Case Study 1 - Simple development on a sub-project I explicitly addressed this workflow in my original e-mail. I know it was a while ago, but it sounds like it may be worth a read if you haven't checked it out. In the mail I described how to use sparse checkouts to create a repository structure that functions virtually identically to what you have today.

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Mehdi > Amini via llvm-dev > Sent: Friday, July 29, 2016 10:02 AM > To: David Chisnall > Cc: llvm-dev at lists.llvm.org; Bruce Hoult > Subject: Re: [llvm-dev] [RFC] One or many git repositories? > > > > On Jul 29, 2016, at 2:19 AM, David Chisnall >

IIUC you are mainly wanting to test LLD's PDB generation. Obviously a test suite plugged in under clang/test is not a good fit for that. It could arguably fit into the LLD project, but separating it out as a more end-to-end integration project a-la test-suite seems like a much better idea. Moving debuginfo-tests seems like a way to get a project in place with the right layering and maybe

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of > Justin Lebar via llvm-dev > Sent: Wednesday, July 27, 2016 1:32 PM > To: Chris Bieneman > Cc: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] [RFC] One or many git repositories? > > Thanks for elaborating, Chris. > > > Case Study 1 - Simple development

On Mon, Dec 31, 2012 at 4:56 PM, Renato Golin <rengolin at systemcall.org> wrote: > With git, I normally issue a pull request, but in LLVM, this won't > work. Is there a FAQ/doc/manual on how to do that or what are the best > practices when working with git? Basically, once you are set up with git-svn (see

>> 3. For many (most?) developers, changing to a monolithic git repo is a >> *bigger* workflow change than switching to separate git repos. Many >> people (and at least some downstream infrastructure) use the git >> mirrors exclusively, aside from git-svn for committing. >> >> I believe the idea is to continue to maintain the read-only independent >> git