Re: [lldb-dev] [llvm-dev] GitHub anyone?
With submodules, the current hash of each submodule is recorded in each master commit. If you check out a different master repository commit then you run 'git submodule update' and it checks out the corresponding commit in each submodule. I'm not sure why this isn't automatic with the master repo commit checkout, but in any case it's not difficult. So when you do a git bisect, you just need to make sure there is a 'git submodule update' at the start of your bisect script. It will be fun to get all the correct hashes recorded in the master repo during initial import. But not all that difficult: check out next svn revision; check and push in any submodules with changes in that revision; then commit the master repo for that revision. On Wed, Jun 1, 2016 at 2:06 AM, Robinson, Paul via llvm-dev < llvm-...@lists.llvm.org> wrote: > > > > -Original Message- > > From: mehdi.am...@apple.com [mailto:mehdi.am...@apple.com] > > Sent: Tuesday, May 31, 2016 3:54 PM > > To: Robinson, Paul > > Cc: Bill Kelly; Clang Dev; LLDB Dev; llvm-...@lists.llvm.org > > Subject: Re: [llvm-dev] GitHub anyone? > > > > > > > On May 31, 2016, at 3:38 PM, Robinson, Paul > > wrote: > > > > > > > > > > > >> -Original Message- > > >> From: llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] On Behalf Of > > Mehdi > > >> Amini via llvm-dev > > >> Sent: Tuesday, May 31, 2016 2:38 PM > > >> To: Bill Kelly > > >> Cc: LLVM Dev; Clang Dev; LLDB Dev > > >> Subject: Re: [llvm-dev] GitHub anyone? > > >> > > >> > > >>> On May 31, 2016, at 2:01 PM, Bill Kelly via llvm-dev > >> d...@lists.llvm.org> wrote: > > >>> > > >>> Chris Lattner via llvm-dev wrote: > > Personally, I’m hugely in favor of moving llvm’s source hosting to > > >> github at > > some point, despite the fact that I continue to dislike git as a > tool > > >> and > > consider monotonicly increasing version numbers to be hugely > > >> beneficial. > > >>> > > >>> For whatever it's worth, our projects define a `buildnum` git alias: > > >>> > > >>> alias.buildnum=!sh -c "git rev-list --all | wc -l" > > > > > > Or the cheaper "git rev-list --count --all" if your git is new enough. > > > We do something like this as well. > > > > > >>> > > >>> So from the shell: > > >>> > > >>> $ git buildnum > > >>> 17475 > > >>> > > >>> This number increases monotonically per commit. > > >> > > >> It does not work with branches though (we're not really planning to > > have > > >> branches I believe), > > > > > > You can get a per-branch unique number with this tactic. On our local > > > branches we use "rev-list origin/master.." which is the number of > > commits > > > since branching from master, and that's enough for our local purposes. > > > > > >> but more importantly it won't handle cross-repository > > >> versioning (how do you relate the number this command prints in the > > llvm > > >> repo to the number it'll print in the clang repo?), which I believe is > > >> something important considering our setup. > > > > > > Is it really that important? Or are we just used to the convenience? > > > > I don't know how important it is. How would you bisect without this > > "convenience" for instance? > > (There is nothing like "push date" in git) > > I know that on a single branch, "git bisect" deals with that for you. > I've seen the talk about submodules but I have no clue how that works > or whether git-bisect can operate cleanly in that situation. > --paulr > > > > > -- > > Mehdi > > > > > > > If the Clang build number is a tuple (cfe-number, llvm-number) instead > > > of a single number, how horrible is that really? If you consider what > > > an out-of-tree front end probably does, it's exactly the same thing. > > > > > > (I admit that locally we mush cfe+llvm into a single branch and do the > > > rev-list count to get a single number. But that's more for our own > > > convenience than anything else.) > > > --paulr > > > > > >> > > >> -- > > >> Mehdi > > >> > > >> > > >> > > >>> > > >>> > > >>> Our build scripts make this number available in various #define > forms. > > >>> > > >>> (We use a little extra scripting logic to also determine whether > there > > >>> are currently any unmerged or uncommitted changes, and add an > > annotation > > >>> to the program version in that case, e.g. "9.3.17475 [unmerged]") > > >>> > > >>> > > >>> It's all stupidly simple, but seems to work well enough for us. > > >>> > > >>> > > >>> > > >>> Regards, > > >>> > > >>> Bill > > >>> > > >>> ___ > > >>> LLVM Developers mailing list > > >>> llvm-...@lists.llvm.org > > >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > >> > > >> ___ > > >> LLVM Developers mailing list > > >> llvm-...@lists.llvm.org > > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi
Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?
I'd suggest a workflow like the following: - developer commits locally to a feature/bug dev branch. You can commit work in progress, experiments, have bad commit messages etc - developer commits locally to a feature/bug release branch. Tidy up into a small number of logical commits, nice messages etc. I'd suggest it's good to have at least two commits: 1) a commit adding a test that fails, and is marked as expected to fail, demonstrating the bug or lack of feature. 2) a commit that fixes the bug or adds the feature, and marks the test as expected to pass. - developer rebases to master and tests - developer pushes their feature/bug release branch to their github fork of llvm, issues a pull request - the appropriate maintainer (or or automatic system) causes build and tests to be run on the proposed bug fix. - if the tests work, then do a "git merge --no-ff" to master There's room to discuss the last part. That gives a master history with exactly one commit per feature or bug fix. The details of how it was done are on a different branch that merges back. You might prefer merge --ff-only. This means that the merge can only happen if the new feature has been rebased to the head of master. The commits in the new feature each become a commit in master. In this case you should make very sure that every commit works -- which is defined as no crashes; tests expected to work, work; tests expected to fail, fail. On Mon, Jun 6, 2016 at 8:07 PM, James Y Knight via llvm-dev < llvm-...@lists.llvm.org> wrote: > +1 to that. I would strongly suggest that we continue to commit to master > first, like we've always done in llvm. > > On Jun 6, 2016 11:44 AM, "Joerg Sonnenberger via cfe-dev" < > cfe-...@lists.llvm.org> wrote: > >> On Mon, Jun 06, 2016 at 10:32:45AM -0500, via llvm-dev wrote: >> > My only hesitation with this is that this requires use of cherry-pick, >> > which is not idea. The way most git repositories work is to put >> > everything that should go into a release branch in the release branch >> > *first* and then merge the release branch to master, ensuring that >> > everything going out in a release will make it into the next release. >> > This is how the gitflow workflow works, for example. >> >> The model of "commit to oldest first" is IMO one of the most stupid >> concepts I have ever seen in git "workflows". It is contrary to the way >> software development works and essentially just a bad workaround for >> broken cherry picks. I've seen more than one project starting to use >> this model due to advocacy after deciding to use git, stumble around >> with it for a release or two and then going back to a normal release >> management approach. Even the argument you have presented here does not >> make sense to me. Just because a change has been committed to a release >> branch, doesn't mean it won't get replaced later. >> >> Joerg >> ___ >> cfe-dev mailing list >> cfe-...@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >> > > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
Bug in cmake (or more likely the makefile?), pure and simple. Version numbers aren't strings, and they aren't floating point numbers, they are a series of integers separated by dots. I can't think of a project where interpreting version numbers that way won't work. On Wed, Jun 15, 2016 at 7:21 AM, Cristianno Martins via llvm-dev < llvm-...@lists.llvm.org> wrote: > Hello there, > > First, I would like to say that I don't have any strong opinions on this > matter: as mostly an user of LLVM, my basic concern is for me to be able to > identify which version is the newest and configure it as easily as > possible. That being said, I have a question about LLVM's versioning > strategy: is it possible for other tools (including the ones LLVM depend > on) to become broke or annoyingly buggy just because a bad versioning > scheme was put in place? > > Just to give some context to this question, I've been using OS X for a > while, and I confess I was pretty annoyed when OS X 10.9 was followed by OS > X 10.10. Not at first, no: I didn't realize this would have any impact on > my workspace until I had to compile some code, and CMake kept stopping just > because it recognized that I was using an older version of the OS (emphasis > on *older*). It is funny when you realize that 10.10 should actually be > interpreted as less than 10.9, and CMake was falling for it, which was a > wrong behavior of the tool, I admit, but the weird OS versioning scheme was > the main cause of this issue. Of course this problem can be easily arranged > by setting up some extra environment variables to tell CMake to target OS X > 10.9 instead, but that was a very irritating behavior and only happened > because a bunch of people (from CMake, and, then, from OS X's development > team) thought comparing versions directly shouldn't be a problem. Besides, > every one of these small details end up being some extra steps a new user > need to follow to be able to use a tool, some of which could be easily > avoided. > > I confess I didn't look into this matter after that, and still today, on > OS X 10.11, I'm targeting version 10.9 on all my CMake runs on OS X -- > thus, I don't know if this bug was fixed or not. However, as I'm starting > to see a very similar pattern happening with LLVM on this thread, and I > thought I could contribute with the discussion: did someone check if naming > the next version "3.10" would have any impact on a production system? > > > -- > Cristianno Martins > > > On Tue, Jun 14, 2016 at 10:48 PM, Sean Silva via llvm-dev < > llvm-...@lists.llvm.org> wrote: > >> >> >> On Tue, Jun 14, 2016 at 11:51 AM, Eric Christopher via cfe-dev < >> cfe-...@lists.llvm.org> wrote: >> >>> >>> >>> On Tue, Jun 14, 2016 at 12:43 AM Chandler Carruth via cfe-dev < >>> cfe-...@lists.llvm.org> wrote: >>> On Mon, Jun 13, 2016 at 5:03 PM Hal Finkel via lldb-dev < lldb-dev@lists.llvm.org> wrote: > - Original Message - > > From: "Hans Wennborg via cfe-dev" > > To: "llvm-dev" , "cfe-dev" < > cfe-...@lists.llvm.org>, "LLDB Dev" , > > "openmp-dev (openmp-...@lists.llvm.org)" > > Cc: "r jordans" , "Paul Robinson" < > paul_robin...@playstation.sony.com> > > Sent: Monday, June 13, 2016 6:54:19 PM > > Subject: [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] > Release plan and call for testers) > > > > Breaking this out into a separate thread since it's kind of a > > separate > > issue, and to make sure people see it. > > > > If you have opinions on this, please chime in. I'd like to collect as > > many arguments here as possible to make a good decision. The main > > contestants are 4.0 and 3.10, and I've seen folks being equally > > surprised by both. > > > > Brain-dump so far: > > > > - After LLVM 1.9 came 2.0, and after 2.9 came 3.0; naturally, 4.0 > > comes after 3.9. > > > > - There are special bitcode stability rules [1] concerning major > > version bumps. 2.0 and 3.0 had major IR changes, but since there > > aren't any this time, we should go to 3.10. > > > > - The bitcode stability rules allow for breakage with major versions, > > but it doesn't require it, so 4.0 is fine. > > > > - But maybe we want to save 4.0 for when we do have a significant IR > > change? > > I think that this is the right approach, and we happen to have a > natural forcing function here: opaque pointer types. I think we should > increment the major version number when opaque pointer types are here, as > it will be a major breaking change, and then we'll have a version 4.0. > Until then, unless something else breaking comes up, 3.10 sounds fine to > me. > +1, complete agreement. >>> >>> While I'm not sure opaque pointer types are going to increment versions >>> I'm also in agreement that 3.10 is the right way to go. >>> >> >> +1 >> >> -- Sean Silva >> >> >>> >>>
Re: [lldb-dev] [llvm-dev] [cfe-dev] Sequential ID Git hook
What doesn't scale about tagging every commit? True, every tag creates a small file on disk, but then so does every commit. If you're worried about lots of files in a directory then you can put tags in nested directories by putting one or more /'s in the tag name. So you can hide all the commit tags in, say .git/refs/tags/commits and put release tags in the root tags directory, or another subdirectory. i.e. "git tag commit/23456 HEAD". Things such as shell command autocomplete (e.g. git checkout) deal intelligently with the tags directory structure, so you're not overwhelmed by 1 commit tags when you just want to see the 40 release tags. Also the files are only a short term thing anyway. When a "git gc" or "git pack" happens, tags get added to the compressed pack file just the same as objects do and the .git/refs/tags directory is cleared out. On Mon, Jul 4, 2016 at 11:13 PM, Renato Golin via llvm-dev < llvm-...@lists.llvm.org> wrote: > On 4 July 2016 at 06:01, NAKAMURA Takumi via llvm-dev > wrote: > > "git-describe -t" works also for lw tags. > > But it doesn't work if there are no tags, I just tested on LLVM and I get: > > $ git describe > fatal: No names found, cannot describe anything. > > Should be easy enough to create the tags on each branching point, though. > > "describe" also seems to be available at least since Git 1.9, so it > should be pretty safe. > > And since tagging *every* commit doesn't scale for long ranges, and > anything else will need scripting on the client side, I think we can > get rid *completely* of any server side hook, and let the client side > scripts deal with the output of "git describe". > > Or am I just too optimistic? > > cheers, > --renato > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] Sequential ID Git hook
On Sat, Jul 2, 2016 at 3:18 AM, Tom Honermann via llvm-dev < llvm-...@lists.llvm.org> wrote: > We're using tags in this manner for our internal repos and LLVM/Clang > mirrors and haven't experienced any problems. We're at ~50k tags for > our most used repo, so not quite at hundreds of thousands yet. > > When I look in .git/refs/tags of one of my repos, I do *not* see 50k > files; I see ~400. I'm not sure what causes some to appear here and > others not. > You don't see many tags because tags (both heavy and lightweight) are transferred from the file system into a pack file whenever a "git repack" or "git gc" happens. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
