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

Should we allow file identity to be specified by reference to a commit... #14

Closed
ghost opened this issue Sep 26, 2017 · 4 comments
Closed

Comments

@ghost
Copy link

ghost commented Sep 26, 2017

Copied from sarif-standard/sarif-spec-v1#130, created by @lgolding:

... (in a specific repo) rather than by a hash?

This is related to sarif-standard/sarif-spec/#28, but it's about not wanting to have to hash even the few files that are mentioned in the results, whereas sarif-standard/sarif-spec/#28 is about not wanting to have to mention all the files.

@ghost ghost added the discussion-ongoing label Sep 26, 2017
@ghost
Copy link
Author

ghost commented Sep 27, 2017

Notes from TC con call, 2017/09/27:

  • Primary scenario is for accessing the file version and overlaying results on it.
  • Must support "nested" git repos, e.g. submodules
  • Could specify base URI at run level; individual files could specify relative URI, or completely override it.

@DerSaidin
Copy link

When referring to files in repositories, do we want to use an absolute path from the root of the file system?

For example; there are two clones of the same repository, at the same revision, plus a versioned file in each one:
/home/me/myrepo1/.git
/home/me/myrepo1/src/main.c
/home/you/myrepo/.git
/home/you/myrepo/src/main.c

If we run static analysis on each directory, how will we be able to merge the reports?

Do we store the relative path within the repository?
Then we can see "src/main.c" vs "src/main.c"

Do we store absolute paths? How do we see these files are the same?
"/home/me/myrepo1/src/main.c" vs "/home/you/myrepo/src/main.c"

@DerSaidin
Copy link

Something to consider:

* f099d4a - (18 seconds ago) Modified b. - Andrew Browne (HEAD -> master)
|  bbb.txt | 3 +++ 
|  1 file changed, 3 insertions(+)

* b95da14 - (55 seconds ago) Add file b. - Andrew Browne
|  bbb.txt | 1 + 
|  1 file changed, 1 insertion(+)

* b225710 - (2 minutes ago) Add file a. - Andrew Browne
|  a.txt | 1 + 
|  1 file changed, 1 insertion(+)

In these example changesets, a.txt is only changed in the first one.

The a.txt file is identical at all of these revisions.
a.txt @ b225710
a.txt @ b95da14
a.txt @ f099d4a

If we want to refer to this version of the file canonically, we should use the first revision: b225710.

The benefit of doing this is in merging reports. If we had one static analysis run on b95da14, and a second one on f099d4a, the a.txt file (including version information) is already the same in both of them.

@ghost
Copy link
Author

ghost commented Mar 5, 2018

To the extent that this is about specifying an overall commit for the code base, this is tracked in #108. To the extent that you can locate a file at a given commit by means of a URL, that's a matter of setting the URL properly and there's nothing more to do.

@ghost ghost added the resolved-by-design label Mar 5, 2018
@ghost ghost closed this as completed Mar 5, 2018
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant