Daniel Barkalow [off-list ref] 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.
On Wed, 25 Mar 2009, Junio C Hamano wrote:
Daniel Barkalow [off-list ref] writes:
quoted
+'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?
Yes, with the [1/5] change to make 0{40} tell git to consider it different
but unknown. Also, not giving either of these flags counts as 0{40}, but
we might someday want to have the native side report the difference
between knowing that it changed and not knowing at all.
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?
What I've done for my p4 backend is have an option for whether it should
search for new branches (which is somewhat expensive, at least currently,
because it involves connecting to the server in this step). If the backend
actually lacks the capability, the user has to do something (probably add
them to the config file) to include new branches. In some cases, what the
backend exposes as branches may be something that there isn't a complete
list of; there may be systems that are structured sort of like repo.or.cz,
where the URL is for the whole system, and there are some things on it
that are branches of the project (like various people's git.git
repositories) and some things that are completely unrelated and not
interesting, and there's no machine-readable way to distinguish them.
quoted
+'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.
Not "fast-import" for both, now that other systems have adopted the format
as input?
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.
I think that there is always the requirement that the other system
(whether it's foreign, git through filter-branch, or even a regular remote
git repository) contains a sane, consistant, and normal-looking history.
It's rarely going to be possible to export a history that will import as
the same hash (and incremental imports on top of local history that isn't
what a fresh complete import would contain seems even crazier). I don't
think there's any particular use for using a foreign system to store
history that only makes sense in git.
But, as a general principle, the reason a git developer would push to a
non-git remote repository is because the remote repository is
authoritative. I don't think it makes sense to have an environment where
the authoritative history is in git, but people are sharing it through a
bzr server (even if the bzr server can accurately represent the git
history).
Of course, we may want a different mechanism some day to generalize
git-cvsserver, where the authoritative history is in git, but we're
supporting foreign clients. But that requires very different code from
what I'm working on.
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.
Yeah, this is unfortunate. You can at least import through a shared
system, which is pretty close to how git.git development goes (we pull
from your public repo, make changes locally, and email patches, which you
put in upstream, and we get back commits that are not the same hash we
created locally).
I think it might be possible to do something where the synchronization
point has a list of authoritative commit-swaps, where it can tell the
multiple developers: "commit Y is really the same thing as commit X; they
have the same tree, and their parents Y1..Yn are the same as X1..Xn
(either based on the same criterion applied recursively, or having
identical hashes)". This list of commit-swaps allows the developers to be
comfortable with trivial rebases (in a commit Z with X as a parent, make a
commit Z' with Y replacing X and no other changes, and replace Z with Z'
in refs and other commits). Of course, this depends on being able to get
the foreign system to agree on both complete content and history topology,
but otherwise we kind of have to throw away our history, because the
public history simply can't be like what we've made locally.
-Daniel
*This .sig left intentionally blank*
Daniel Barkalow [off-list ref] writes:
On Wed, 25 Mar 2009, Junio C Hamano wrote:
quoted
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.
...
But, as a general principle, the reason a git developer would push to a
non-git remote repository is because the remote repository is
authoritative. I don't think it makes sense to have an environment
where the authoritative history is in git, but people are sharing it
through a bzr server (even if the bzr server can accurately represent
the git history).
Suppose a project used to use subversion, but it migrated to git (not an
unheard-of scenario these days, I hope). The git repository now is the
authoritative one, all the development happens on this side.
But in order to help:
- people who have established their workflow to follow the project
(e.g. not necessarily contributing anything back, but just doing
regular "svn update");
- people who have leftover local changes from the subversion days; and
- other project infrastracture (e.g. trac) that the project hasn't
managed to interface to the new git repository yet;
the project decides to keep feeding recent updates to the subversion
repository that used to be authoritative, even though it is now declared
read-only (i.e. the only update comes from the git end).
My understanding is that the above scenario would not work if git-vcs-svn
rewrites commits when git exports to svn, and existing git-svn two-way
interface using its "dcommit" may have exactly the same issue.
The reason I brought this up was to involve people who have already faced
this issue with git-svn in the discussion to see if we can avoid it by
doing somethink similar to clever tricks they are using in their git-svn
workflow, if there are some. Perhaps your paragraph below may be one of
those clever tricks, but there may be others.
I think it might be possible to do something where the synchronization
point has a list of authoritative commit-swaps, where it can tell the
multiple developers: "commit Y is really the same thing as commit X; they
have the same tree, and their parents Y1..Yn are the same as X1..Xn
(either based on the same criterion applied recursively, or having
identical hashes)". This list of commit-swaps allows the developers to be
comfortable with trivial rebases (in a commit Z with X as a parent, make a
commit Z' with Y replacing X and no other changes, and replace Z with Z'
in refs and other commits). Of course, this depends on being able to get
the foreign system to agree on both complete content and history topology,
but otherwise we kind of have to throw away our history, because the
public history simply can't be like what we've made locally.
On Wed, 25 Mar 2009, Junio C Hamano wrote:
Suppose a project used to use subversion, but it migrated to git (not an
unheard-of scenario these days, I hope). The git repository now is the
authoritative one, all the development happens on this side.
But in order to help:
- people who have established their workflow to follow the project
(e.g. not necessarily contributing anything back, but just doing
regular "svn update");
- people who have leftover local changes from the subversion days; and
- other project infrastracture (e.g. trac) that the project hasn't
managed to interface to the new git repository yet;
the project decides to keep feeding recent updates to the subversion
repository that used to be authoritative, even though it is now declared
read-only (i.e. the only update comes from the git end).
Actually, this is easy: just configure the git repo to not fetch anything
from the no-longer-authoritative subversion repository. git-vcs-svn would
waste a bunch of time reimporting what it exported, but it wouldn't
actually do anything with it (since it doesn't even have tracking refs to
update). It could, of course, be optimized to avoid reimporting if it
doesn't need to.
My understanding is that the above scenario would not work if git-vcs-svn
rewrites commits when git exports to svn, and existing git-svn two-way
interface using its "dcommit" may have exactly the same issue.
The reason I brought this up was to involve people who have already faced
this issue with git-svn in the discussion to see if we can avoid it by
doing somethink similar to clever tricks they are using in their git-svn
workflow, if there are some. Perhaps your paragraph below may be one of
those clever tricks, but there may be others.
The harder problem is that you can only push history that the remote
system will be able to represent. In the same way that git wants your push
to be a fast-forward, svn wants your push to not contain any merges (and
p4 and svn both want your push to not contain parallel development
pushed to a single branch). Rewriting the history to conform to the
destination's requirements is most of what dcommit does, I believe.
I think that, in this use case, the right thing is to have a config option
for git-vcs-svn to tell it to collapse the problematic commits (or maybe
collapse all commits in a push). That would make the svn history export
like the reflog, which is all linear and simple anyway, and probably
sufficient for the above users of the old repository.
-Daniel
*This .sig left intentionally blank*