The copyfile entry in the manifest file copies the contents of the file
but doesn't keep the executable flag. This is inconsistent with repo
tool behaviour, plus is natural to expect that the copy of a executable
file is executable.

Transfer the executable bit when copying the file, aligning the
RepoCommand with repo tool and user expectations.

Change-Id: I01b24f482d5939e01d496f032388b3a5c02a912a
Signed-off-by: Ivan Frade <ifrade@google.com>

When an auto-closeable resources is not opened in try-with-resource,
the warning "should be managed by try-with-resource" is emitted by
Eclipse.

Fix the ones that can be silenced simply by moving the declaration of
the variable into a try-with-resource.

In cases where we explicitly call the close() method, for example in
tests where we are testing specific behavior caused by the close(),
suppress the warning.

Leave the ones that will require more significant refcactoring to fix.
They can be done in separate commits that can be reviewed and tested
in isolation.

Change-Id: I9682cd20fb15167d3c7f9027cecdc82bc50b83c4
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>

Change-Id: I2604c7bca87f005004d6d6c80fa9a39a7a1e3807
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Android wants them to work, and we're only interested in them for bare
repos, so add them just for that.

Make sure to use symlinks instead of just using the copyfile
implementation. Some scripts look up where they're actually located in
order to find related files, so they need the link back to their
project.

Change-Id: I929b69b2505f03036f69e25a55daf93842871f30
Signed-off-by: Dan Willemsen <dwillemsen@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Jeff Gaston <jeffrygaston@google.com>
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>

Since the introduction of generic type parameter inference in Java 7,
it's not necessary to explicitly specify the type of generic parameters.

Enable the warning in Eclipse, and fix all occurrences.

Change-Id: I9158caf1beca5e4980b6240ac401f3868520aad0
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>

Reported-by: David Pursehouse <david.pursehouse@gmail.com>
Change-Id: I9e9b021d335bda4d58b6bcc30f59b81ac5b37724
Signed-off-by: Jonathan Nieder <jrn@google.com>

Change-Id: I2d17115843e453c71febd4a58527effe658b48fd
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Git core learned about the submodule.<name>.shallow option in
.gitmodules files, which is a recommendation to clone a submodule
shallow. A repo manifest may record a clone depth recommendation as
an optional field, which contains more information than a binary
shallow/nonshallow recommendation, so any attempted conversion may be
lossy. In practice the clone depth recommendation is either '1' or doesn't
exist, which is the binary behavior we have in Git core.

Change-Id: I51aa9cb6d1d9660dae6ab6d21ad7bae9bc5325e6
Signed-off-by: Stefan Beller <sbeller@google.com>

Git core learned about attributes in pathspecs:

    pathspec: allow querying for attributes

    The pathspec mechanism is extended via the new
    ":(attr:eol=input)pattern/to/match" syntax to filter paths so that it
    requires paths to not just match the given pattern but also have the
    specified attrs attached for them to be chosen.

(177161a5f7, 2016-05-20)

We intend to use these pathspec attribute patterns for submodule
grouping, similar to the grouping in repo. So the RepoCommand which
translates repo manifest files into submodules should propagate this
information along. This requires writing information to the
.gitattributes file instead of the .gitmodules file. For now we just
overwrite any existing .gitattributes file and do not care about prior
attributes set. If this becomes an issue we need to figure out how to
correctly amend the grouping information to an existing .gitattributes
file.

Change-Id: I0f55b45786b6b8fc3d5be62d7f6aab9ac00ed60e
Signed-off-by: Stefan Beller <sbeller@google.com>

Method parameter names were hiding class members of the same
name.

Change-Id: I182f2715894ac4259b09a371cb4e0eb24f52518a
Signed-off-by: David Pursehouse <david.pursehouse@sonymobile.com>

Similar to nested directories, nested copyfiles won't work with git submodule
either.

Change-Id: Idbe965ec20a682fca0432802858162f8238f05de
Signed-off-by: Yuxuan 'fishy' Wang <fishywang@google.com>

A project's name attribute is required according to repo's
doc/manifest-format.txt:

    <!ELEMENT project (annotation*,
                       project*)>
    <!ATTLIST project name        CDATA #REQUIRED>

Enforcing this in code makes reading easier (in particular making it
clearer that getName() and getPath() can never return null).

Change-Id: I8c7014dd6042183d7fecb2202af5acdc384aa8e4
Signed-off-by: Jonathan Nieder <jrn@google.com>

Change-Id: I3ea25c157b9e11a46a140d2c3ab9373d1596c163
Signed-off-by: Yuxuan 'fishy' Wang <fishywang@google.com>

Change-Id: I74ded6c2c3f5985568cd77bd8799b45017fb1d09
Signed-off-by: Yuxuan 'fishy' Wang <fishywang@google.com>

Commit d3348e introduced few errors in Eclipse.

This commit cleans up the new API:
 - fixes API error in RepoCommand after moving IncludedFileReader type
 - fixes unused imports in RepoCommand & RepoCommandTest
 - fix javadoc errors in ManifestParser & RepoProject
 - makes three (implicitly final) fields in ManifestParser final.

Change-Id: I4185f451d97039d155391f62815bb9d3afe39fa6
Signed-off-by: Andrey Loskutov <loskutov@gmx.de>

The repo xml manifest parser used in RepoCommand could also be useful for
others, so refactor to make it public.

Also this breaks backward compatibility slightly.

Change-Id: I5001bd2fe77541109fe32dbe2597a065e6ad585e
Signed-off-by: Yuxuan 'fishy' Wang <fishywang@google.com>