[Dune] [#981] git support for dunecontrol
flyspray at dune-project.org
Mon Nov 21 15:06:49 CET 2011
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#981 - git support for dunecontrol
User who did this - Jö Fahlke (joe)
FS#429 was a trivial fix. FS#479 was (by Sven):
The support for git-svn in dunecontrol only works for one special use of git
and breaks things in many other use cases. These cases include one-shot
checkouts using git-svn, not being on the master branch and having modified
files that are different in the current branch, being in the middle of an
interactive rebase and many more.
Moreover, local changes in .git/info/exclude are overwritten (without any
backup copy!) and replaced by some arbitrary default.
I think the git-svn support should be dropped. It would be a lot of work to
fix it, and hardly anyone would use it. In my local checkout, I removed the
support a long time ago because it screwed up "dunecontrol update" over and
These concerns were for a different implementation, but lets see how valid
they are with the proposed patch.
1. One-shot checkouts: A one-shot checkout, I believe, is where you convert a
subversion-repository to a git repository, and subsequently make the
git-repository authorative, either as a fork or by replacing the
subversion repository. The problem here is that a one-shot checkout
differs only in purpose from any other git-svn repository. On dunecontrol
update it would try to download changes from svn. In the case of a fork,
it would then try to rebase the "local changes" onto the "upstream
changes", which (failing or not) is not what is desired. This is
undesired, but in git this change to the repository can be undone. In
other cases, the download would either download nothing, or would fail
because the upstream svn repository no longer exists. In any case, no
great harm is done, but having modules in such repositories would prevent
the use of "dunecontrol update" completely.
2. Being on a different branch than master: If the branch is a svn branch as
well, the patch should work flawlessly. If it isn't the branch is rebased
onto the current head of the svn branch (or trunk) it was branched of
from. This may or may not be what you want.
3. Modified files: You're not supposed to rebase with modified and uncommited
files. If you do, git will error out. This is actually reasonable
behaviour, so I see no problem here.
4. Middle of an interactive rebase: This is another repository state where
you shouldn't try to update. I'm not actually sure what git will do if
you try, but I suppose it will error out because you're attemping a rebase
while another rebase is going on.
5. Local changes in .git/info/exclude: The current patch doesn't try to deal
with excludes/ignores, so this isn't a problem.
To remedy the remaining problems, we can introduce a git config option, which
can be set per-repository, like
[ dune ]
update = false # or git, or svn
This can be used to either disable updating on "dunecontrol update", or to
force the plain git or git-svn update methods (instead of autodetecting them).
This way you can force one-shot checkout to have no upstream or to even have a
git upstream. If you create a branch that you don't want to update from svn,
you can (temporarily) mark your repository not to be updated.
We could even introduce a per-branch option (dune-update) so people don't have
to edit their git-options each time they switch branches. But I suppose that
would be the another iteration.
More information can be found at the following URL:
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
More information about the Dune