Daniel Barkalow <barkalow@xxxxxxxxxxxx> writes:
> +'capabilities'::
> + Prints the capabilities of the helper, one per line. These are:
> + - import: the basic import command
> + - marks: import should be done with a saved marks file
> + - find-new-branches: detect new branches
> + - export: the general export command
> + - fork: create a new branch and export to it
> + - anonymous-fork: make commits on a branch without an inherent name
> + - merge: merge branches (of whatever type the system supports)
> +
> + If the helper doesn't support "merge", the default for pull is
> + to rebase instead of merging.
> +
> +'list'::
> + Takes the remote name, and outputs the names of refs. These
> + may be followed, after a single space, by "changed" or
> + "unchanged", indicating whether the foreign repository has
> + changed from the state in the ref. If the helper doesn't know,
> + it doesn't have to provide a value. (In particular, it
> + shouldn't do expensive operations, such as importing the
> + content, to see whether it matches.)
Does this roughly corresponds to get_remote_refs(), with "unchanged"
return turned into the current value of the ref while "changed" returned
as 0{40} in old_sha1 value?
For a vcs backend that lacks find-new-branches capability, when does the
set of refnames returned by this operation change? Can the end user
request an expensive operation to make the list up-to-date? Does the end
user need to?
> +'import'::
> + Takes the remote name and a list of names of refs, and imports
> + whatever it describes, by outputting it in git-fast-import
> + format.
> +
> +'export'::
> + Sends the branch to the foreign system and reimports it in
> + fast-import format.
The above two description is inconsistent; say "git-fast-import" for both.
This seems to follow the model of git-svn in that we treat our history as
throw-away, export the history and give the authority to the other system
by discarding and replacing our history with whatever the other end gives
back to us by re-importing. Because git is more flexible than anything
else, we could afford to do so, but I wonder if it is the right model and
mentality.
One downside is that you end up rebasing the git side by operating this
way, and a topology where multiple developers use one git repository as a
synchronization point and use that git repository to interface with the
foreign system becomes impossible. Instead, these multiple developers
need to treat the foreign system as the central repository, and interface
with it individually.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
