Add more support for folding/ignoring/categorizing changesets from "arc"
Open, NormalPublic


We currently recognize "@generated" in files to mean "this is generated code, fold it at display time", but it would be good to expand this mechanism to allow projects to mark files as generated/unimportant and specify folding upfront.

epriestley triaged this task as Normal priority.Jan 18 2012, 7:40 PM
epriestley added projects: Differential, Arcanist.
epriestley added subscribers: epriestley, davidreuss.
epriestley changed file(s), attached 0: ; detached 0: .Jan 19 2012, 6:13 PM

D1455 is a partial approach. In thinking about that patch, it occurs to me that Diffusion would also benefit from being able to run these rules, so maybe the best place to put it is Phabricator, just pulled out of the hideous mess that is DifferentialChangesetParser so it can access the repository/project objects and have more information available to make decisions.

dmi added a subscriber: dmi.Jan 19 2012, 6:26 PM
btrahan added a project: Differential.

◀ Merged tasks: T2729.

It would be nice to list the generated files in .arcproject, using some syntax similar to .gitignore

See also discussion in {D5826}.

The @generated tag work nicely for generators which you can force this string to appear. But you can't always do that. Here is a typical generated file header generated by Visual Studio Entity Framework:

// <auto-generated>
//     This code was generated from a template.
//     Manual changes to this file may cause unexpected behavior in your application.
//     Manual changes to this file will be overwritten if the code is regenerated.
// </auto-generated>

I can't exclude generated files because they just look like regular sources. It would be nice to add, say, <auto-generated> to the list of keywords to mark a file as generated.

I'm in a similar scenario, t4 templates for codegen in visual studio often have <auto-generated /> somewhere in them. It'd be nice to have this string configurable so we don't need to have comments like this everywhere:

// <auto-generated />
// @generated

just to followup: differential.generated-paths works great.

It'd be nice if this could a be .arcconfig value like differential.generated-marker: [regex to match in files] that defaults to @generated or similar so this could live with the project code.

I have half a diff for this.

eadler added a subscriber: eadler.Jun 12 2015, 5:04 AM
chad changed the visibility from "All Users" to "Public (No Login Required)".Jul 3 2015, 4:35 AM
joshuaspence removed joshuaspence as the assignee of this task.Jul 23 2015, 8:43 AM
dmi removed a subscriber: dmi.Jul 24 2015, 7:34 PM
isfs added a subscriber: isfs.Jul 18 2016, 1:00 AM
J5lx added a subscriber: J5lx.Sep 5 2016, 4:39 PM
eadler added a project: Restricted Project.Sep 15 2016, 6:13 PM
gregprice added a project: Restricted Project.Jan 23 2017, 10:11 PM
gregprice added a subscriber: gregprice.

Having a generated-paths variable in .arcconfig with a similar semantics to the differential.generated-paths server configuration -- something like D11537 a couple of years ago was intended to do -- would be really useful!

A user on our large install asked for help getting some files ignored, where the software that generates them doesn't have a knob to insert extra text like the @generated keyword. We were briefly happy to find D11538 and its reference to an .arcconfig variable, before realizing that that was referring to another abandoned revision. In the end we added a rule to the server differential.generated-paths value, but putting something in .arcconfig would be much cleaner -- it'd be discoverable by non-admins, self-serve for users of any repo to modify, and have a changelog with all the nice review features provided by this code-review system we use :).

Whats the status of this? Also is there any actual documentation for the existing @generated and differential-generated-paths functionality?

See Planning for help on status and timelines.