Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explain how to work with subtree #70654

Merged
merged 7 commits into from
Apr 14, 2020
Merged

Explain how to work with subtree #70654

merged 7 commits into from
Apr 14, 2020

Conversation

oli-obk
Copy link
Contributor

@oli-obk oli-obk commented Apr 1, 2020

cc #70651

r? @Centril @RalfJung

This PR just contains the usage documentation, we'll do actual moves in later PRs

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 1, 2020
@Centril
Copy link
Contributor

Centril commented Apr 1, 2020

Waiting with the review and r+ until the conversation re. "should we do this" that you're having with @eddyb has resolved itself. =P

Others should feel free to propose text tweaks though. :)

@oli-obk oli-obk changed the title Explain how to work with subrepos Explain how to work with subtree Apr 1, 2020
@oli-obk
Copy link
Contributor Author

oli-obk commented Apr 1, 2020

see #70655 for a live example of making clippy a subtree

@nikomatsakis
Copy link
Contributor

A question that I didn't see answered: Who is expected to do the "git subtree push/pull"? Are we saying that this is the job of the (e.g.) clippy team, and they're going to do it on some kind of regular schedule?

CONTRIBUTING.md Outdated Show resolved Hide resolved
@RalfJung
Copy link
Member

RalfJung commented Apr 1, 2020

s/subrepo/subtree/

I am confused, did we change the approach or did we just use the wrong term so far?

EDIT: there are just too many discussion going on too fast in concurrent threads right now. Looks like we indeed changed approaches but that was mentioned in one of the 3 other threads, not here, or so.^^

CONTRIBUTING.md Outdated Show resolved Hide resolved
CONTRIBUTING.md Outdated Show resolved Hide resolved
CONTRIBUTING.md Outdated Show resolved Hide resolved
CONTRIBUTING.md Outdated Show resolved Hide resolved
CONTRIBUTING.md Outdated Show resolved Hide resolved
CONTRIBUTING.md Outdated
You always need to specify the `-P` prefix to the subtree directory and the corresponding remote
repository. If you specify the wrong directory or repository
you'll get very fun merges that try to push the wrong directory to the wrong remote repository.
Luckily you can just abort this without any consequences and try again. It is usually fairly obvious
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do you abort?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When pulling, git merge --abort I'd guess? We should test it.

Pushing should always succeed, but if you try to open PR from a malformed branch, it will just look very strange and be unmergeable.

Presumably you can redo it with the right directory specified and the PR will become correct (idk if it overwrites an existing branch though, or maybe it has a -f/--force flag like git push does?).

CONTRIBUTING.md Outdated Show resolved Hide resolved
CONTRIBUTING.md Outdated Show resolved Hide resolved
@Centril
Copy link
Contributor

Centril commented Apr 2, 2020

Reassigning to someone more git-savvy than me. :)

r? @Mark-Simulacrum

@nikomatsakis
Copy link
Contributor

nikomatsakis commented Apr 3, 2020

One final note: I think that this should also go into the rustc-dev-guide. I think it's fine to just land a chapter there that points to CONTRIBUTING.md as the canonical documentation point, though.

modified to move the files from the specified directory to the tool repo root.

Make sure to not pick the `master` branch on the tool repo, so you can open a normal PR to the tool
to merge that subrepo push.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems to me that the important thing is to not have git@github.com:rust-lang/rust-clippy.git as the repository URL, i.e., you should never be pushing into branches there. But which branch you choose in your fork is largely irrelevant (you can push to master if you like).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have my own fork of clippy and miri, should I have?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is better to keep personal feature branches out of the main repo. Not a strong opinion though.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@oli-obk Not to mention that you can only do this because of your powers on those repos, most contributors have to use a fork.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO for repos with many contributors the amount of feature branches in the main repo should be kept as low as possible. Clippy has even an issue, where a contributor complained about the amount of feature branches: rust-lang/rust-clippy#4745

you'll get very fun merges that try to push the wrong directory to the wrong remote repository.
Luckily you can just abort this without any consequences by throwing away either the pulled commits
in rustc or the pushed branch on the remote and try again. It is usually fairly obvious
that this is happening because you suddenly get thousands of commits that want to be synchronized.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Am I correct that subtrees mean that we should no longer need to give particular priority to syncs from clippy upstream? i.e. they're "just normal PRs"? (They would essentially be no different to other PRs being made to that code).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Priority meaning @bors p=1? That definitely should end with the gating.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

jup, all the "time critical" stuff happens on the tool's repo side and not when syncing into rustc. Unless there are bug fixes, but our policy for tool bugfixes and rustc bugfixes willl not have to differ.

@Mark-Simulacrum
Copy link
Member

Mark-Simulacrum commented Apr 4, 2020

I want us to also answer these questions before we proceed here:

  • How should contributors behave with respect to subtrees? For example, if I want to contribute a new lint to clippy, must that happen on the clippy repository? Or can it also happen in rust-lang/rust?

    • I would prefer for the answer to be "no, it must happen on the clippy repository" at least initially, I think, just for ease of review. This would mean that only changes which are related to rustc happen in this repository (e.g., renaming types which affects clippy). However this means that we do not make it as easy for existing rust-lang/rust contributors to work on clippy (they need to learn the clippy repository's build system and quirks). But I think that's a secondary goal and we should start off with "no new work" for clippy and other subtrees on rust-lang/rust.
  • How should tidy and other similar tooling behave? (e.g. should we enforce rustfmt on clippy)

    • Obviously the ideal here is "yes" otherwise changes to files in src/tools/clippy likely have unrelated changes due to rustfmt-on-save and similar, but I can definitely see that being a hard position to accept given the relatively custom nature of rust-lang/rust's tidy. I think the best thing to do is for now not enforce tidy on the files, and continue ignoring the relevant directories in rustfmt.toml. This may change eventually, especially if we start using a non-nightly pinned rustfmt in rust-lang/rust.

@flip1995
Copy link
Member

flip1995 commented Apr 5, 2020

must that happen on the clippy repository?

I think most new lints and features should still be implemented in the Clippy repository. If there was a new lint implemented in the rust repository, and this lint would fail the stricter CI of the Clippy repo, this lint would have to be re-reviewed and maybe modified during a sync.

Also the separation would be clearer: rustups in rust-lang/rust, everything else in the Clippy repo.

How should tidy and other similar tooling behave?

Enforcing rustfmt on Clippy would not be a problem, since we're already doing this. Maybe we would have to adapt our rustfmt.toml to match the one in rust-lang/rust and then reformat once. Does tidy enforce other things, that would concern Clippy, other than rustfmt?

@Mark-Simulacrum
Copy link
Member

Tidy mostly only enforces rustfmt; we do currently pin to a specific nightly which might not be optimal for clippy -- but I think rustfmt at least claims stability (even if that sometimes doesn't hold up in practice, I think). I suspect we'd for now hold off on enforcing rustfmt for the clippy repository (we can land that at a future date), just to avoid bundling too much into the initial rollout. But I suspect we'd fairly quickly want to start doing so, especially as it sounds like at least in the clippy case that should be fairly easy.

@flip1995
Copy link
Member

flip1995 commented Apr 5, 2020

We're currently looking to enhance our dev tooling to behave more like ./x.py rust-lang/rust-clippy#5394. We could also enforce the fixed nightly rustfmt there. But I agree to revisit this later.

@RalfJung
Copy link
Member

RalfJung commented Apr 5, 2020

Also the separation would be clearer: rustups in rust-lang/rust, everything else in the Clippy repo.

From a Miri perspective, I very much like this approach.

@nikomatsakis
Copy link
Contributor

I agree with @Mark-Simulacrum's suggestions, although the "tidy" thing is definitely a drag.

@Mark-Simulacrum
Copy link
Member

I would also echo @nikomatsakis' in saying that I would like to see a link in the rustc-dev-guide pointing at these docs, but that can happen once we land this PR, of course.

Okay, I think we have all of our checkboxes checked here. @oli-obk -- do you know of anything outstanding? If not, let's kick off FCP on the tracking issue (rust-lang/compiler-team#266).

@Mark-Simulacrum Mark-Simulacrum added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 11, 2020
@Mark-Simulacrum
Copy link
Member

Per rust-lang/compiler-team#266 (comment), @bors r+ rollup

Once this lands I can take a look at the actual submodule to subtree PR.

@bors
Copy link
Contributor

bors commented Apr 13, 2020

📌 Commit 7928c45 has been approved by Mark-Simulacrum

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). labels Apr 13, 2020
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 13, 2020
Rollup of 4 pull requests

Successful merges:

 - rust-lang#70654 (Explain how to work with subtree)
 - rust-lang#71092 (Remove some usage of `DUMMY_HIR_ID`)
 - rust-lang#71103 (Add test case for type aliasing `impl Sized`)
 - rust-lang#71109 (allow const generics in const fn)

Failed merges:

r? @ghost
@bors bors merged commit 048c842 into rust-lang:master Apr 14, 2020
bors added a commit to rust-lang-ci/rust that referenced this pull request May 2, 2020
…acrum

Make clippy a git subtree instead of a git submodule

r? @eddyb

cc rust-lang#70651

documentation at rust-lang#70654
Comment on lines +205 to +208
```
git subtree push -P src/tools/clippy git@github.com:your-github-name/rust-clippy sync-from-rust
```

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not working at all on my machine:

git subtree push -P src/tools/clippy git@github.com:matthiaskrgr/rust-clippy2  sync-from-rust

git push using:  git@github.com:matthiaskrgr/rust-clippy2 sync-from-rust
/usr/lib/git-core/git-subtree: line 757: 171266 Done                    eval "$grl"
     171267 Segmentation fault      (core dumped) | while read rev parents; do
    process_split_commit "$rev" "$parents" 0;
done

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

O_o can you run a top in parallel and have a look at your memory consumption?

@oli-obk oli-obk deleted the subrepo_docs branch May 4, 2020 12:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.