github.com/btwiuse/jiri@v0.0.0-20191125065820-53353bcfef54/behaviour.md (about)

     1  # Jiri
     2  
     3  [TOC]
     4  
     5  ## Feedback
     6  If you work at Google, please file a bug at [go/file-jiri-bug][file bug], or to request new features use [go/jiri-new-feature][request new feature].
     7  If filing a bug please include output from `jiri [command]`. If you think that jiri did not update projects correctly, please also include outputs of `jiri status` and `jiri project` and if possible `jiri update -v`.
     8  
     9  ## Intended Behavior
    10  
    11  ### update {#intended-jiri-update}
    12  
    13  * Gets latest manifest repository first, then applied below update rules to all local projects.
    14  * Always fetches origin in all the repos except when configured using [`jiri project-config`](#intended-project-config).
    15  * Point the tree name JIRI_HEAD to the manifest selected revision.
    16  * Checkout new repositories at JIRI_HEAD (detached).
    17  * Fast-forward existing repositories to JIRI_HEAD unless further conditions apply (see below).
    18  * If local repo is on a tracked branch, it will fast forward merge to upstream changes. If merge fails, user would be shown a error.
    19  * If project is on un-tracked branch it would be left alone and jiri will show warning.
    20  * It will leave all other local branches as it is.
    21  * If a project is deleted from manifest it  won't be deleted unless command is run with `-gc` flag.
    22  * If a project contains uncommitted changes, jiri will leave it alone and will not fast-forward or merge/rebase the branches.
    23  * Sometimes projects are pinned to particular revision in manifest, in that case if local project is on a local branch, jiri will update them according to above rules and will not throw warnings about those projects.
    24      * Please note that this can leave projects on revisions other than `JIRI_HEAD` which can cause build failures. In that case user can run [`jiri status`](/howdoi.md#use-jiri-status) which will output all the projects which have changes and/or are not on `JIRI_HEAD`. User can manually checkout `JIRI_HEAD` by running `git checkout JIRI_HEAD` from inside the project.
    25  * If user doesn't want jiri to update a project, he/she can use `jiri project-config`.
    26  * Always updates your jiri tool to latest.
    27  
    28  #### checkout snapshot {#intended-checkout-snapshot}
    29  Snaphot file captures current state of all the projects. It can be created using command `jiri snapshot`.
    30  * Snapshot file or a url can be passed to `update` command to checkout snapshot.
    31  * If project has changes, it would **not** be checked-out to snapshot version.
    32  	* else it would be checked out to *DETACHED_HEAD* and snapshot version.
    33  * If `project-config` specifies `ignore` or `noUpdate`, it would be ignored.
    34  * Local branches would **not** be rebased.
    35  
    36  ### project-config {#intended-project-config}
    37  
    38  * If `ignore` is true, jiri will completely ignore this project, ie **no** *fetch*, *update*, *move*, *clean*, *delete* or *rebase*.
    39  * If `noUpdate` is true, jiri will  **not** *fetch*, *update*, *clean* or *rebase* the project.
    40  * For both `ignore` and `noUpdate`, `JIRI_HEAD` is **not** updated for the project.
    41  * If `noRebase` is true, local branches in project **won't be** *updated* or *rebased*.
    42  * This only works with `update` and `project -clean` commands.
    43  
    44  ### project -clean {#intended-project-clean}
    45  
    46  * Puts projects on `JIRI_HEAD`.
    47  * Removes un-tracked files.
    48  * if `-clean-all` flag is used, force deletes all the local branches, even **master**.
    49  
    50  ### upload {#intended-project-upload}
    51  
    52  * Sets topic (default *User-Branch*) for each upload unless `set-topic=false` is used.
    53  * Doesn't rebase the changes before uploading unless `-rebase` is passed.
    54  * Uploads multipart change only when `-multipart` is passed.
    55  
    56  ### patch {#intended-patch}
    57  
    58  * Can patch multipart and single changes.
    59  * If topic is provided patch will try to download whole topic and patch all the affected projects, and will try to create branch derived from topic name.
    60  * If topic is not provided default branch would be *change/{id}/{patch-set}*.
    61  * It will **not** rebase downloaded patch-set unless `-rebase` flag is provided.
    62  
    63  
    64  
    65  
    66  
    67  [file bug]:http://go/file-jiri-bug
    68  [request new feature]: http://go/jiri-new-feature