Re: [pymvpa] /Developers only/ GIT repository/clones restructuring/migration
On Wed, 25 Aug 2010, Valentin Haenel wrote: > > > > diff M...B > > > I am not sure i understand. M...B shows all commits reachable from M and > > > B, but > > > not from both. > > no -- that should show differences introduced in B on top of M (mention > > number of the dots) > Here is an excerpt from the manpage for git rev-parse: > For two dots: indeed it will show all commits unique to only B, i.e. those > introduced in B, but not yet merged into M. > Is this what you meant? As I have posted about in nipy mailing list recently I wanted http://mail.scipy.org/pipermail/nipy-devel/2010-August/004564.html diff M...B and log (or rev-list) M..B quite counter-intuitive right? ;-) -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] signature.asc Description: Digital signature ___ Pkg-ExpPsy-PyMVPA mailing list Pkg-ExpPsy-PyMVPA@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-exppsy-pymvpa
Re: [pymvpa] /Developers only/ GIT repository/clones restructuring/migration
* Yaroslav Halchenko [100815]: > > On Thu, 12 Aug 2010, Valentin Haenel wrote: > > > diff M...B > > I am not sure i understand. M...B shows all commits reachable from M and B, > > but > > not from both. > no -- that should show differences introduced in B on top of M (mention > number of the dots) Here is an excerpt from the manpage for git rev-parse: This set operation appears so often that there is a shorthand for it. "r1..r2" is equivalent to "^r1 r2". It is the difference of two sets (subtract the set of commits reachable from r1 from the set of commits reachable from r2). A similar notation "r1...r2" is called symmetric difference of r1 and r2 and is defined as "r1 r2 --not $(git-merge-base --all r1 r2)". It is the set of commits that are reachable from either one of r1 or r2 but not from both. So for three dots: if M and B have diverged it will show all commits that are unique to both branches (reachable from either M or B) , but not those common to both branches (not reachable from both). For two dots: indeed it will show all commits unique to only B, i.e. those introduced in B, but not yet merged into M. Is this what you meant? V- ___ Pkg-ExpPsy-PyMVPA mailing list Pkg-ExpPsy-PyMVPA@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-exppsy-pymvpa
Re: [pymvpa] /Developers only/ GIT repository/clones restructuring/migration
On Thu, 12 Aug 2010, Valentin Haenel wrote: > > diff M...B > I am not sure i understand. M...B shows all commits reachable from M and B, > but > not from both. no -- that should show differences introduced in B on top of M (mention number of the dots) > > git merge --no-commit M > > # verifying that no conflicts present > > git reset --hard > Do you mean git merge --no-commit B, i.e. merging B into M, or the other way > round? either way ;-) -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] ___ Pkg-ExpPsy-PyMVPA mailing list Pkg-ExpPsy-PyMVPA@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-exppsy-pymvpa
Re: [pymvpa] /Developers only/ GIT repository/clones restructuring/migration
* Yaroslav Halchenko [100812]: > summary first: indeed rebasing in _tent/* branches within private > clones should be fine in general if we setup the policy that noone > merges _tent/ branches before they get merged into integration > master/'s. Alternatively, continuous merging of master/'s into your > _tent/ branches is fine as well if you promise to provide > human-readable summary of the changes in your _tent/* branch upon pull > request. That sounds like a good policy. Its all mostly clear now. > On Wed, 11 Aug 2010, Valentin Haenel wrote: > > > in general rebases should be avoided as soon as branch is seen publicly, > > Well, that depends. Some projects specify branches that will be rebased > > etc... > > and therefore no one should ever base any work of those branches, but only > > the > > stable ones. We regularly rebase pushed branches in psignifit. I guess it > > also > > depends on the number of devs, the number of users etc.. > yeah -- but what would be the advantage, besides saner development > history with no too many of parallel lines in the DAG? if none -- I > would simply avoid public rebases in general... I think in general it > goes along with Linus's vision on that, e.g. > http://kerneltrap.org/Linux/Git_Management I like my development history as sane as possible and I agree that I may be very pedantic ;P Since i know that no one is basing their work off my branches, i can safely rebase them. Of course i would never rebase master ;p > > Hmm, so you suggest merging from upstream, i.e. merge the master of the > > PyMVPA/PyMVPA.git repo into developer master. I think this is whats called > > criss-cross merging and is discouraged. This is a bit of a tricky subject, > > let > > me try to explain. > > >...< > > PyMVPA/PyMVPA.git developer.git > > M M' B > > | | / > > >...< > > M is the PyMVPA/PyMVPA.git master, M' is the developers version of M, kind > > of > > like a tracking branch, and B is the developer topic branch. The developer > > has > > been writing code in B, and in the meantime some other stuff was merged > > into M. > > A core developer fetches B, tries to merge into M, and encounters a merge > > conflict. Since the core-developer didn't write the code, has limited time, > > etc... he does not wish to fix the conflict, but instead would like to > > delegate > > the job to the developer who wrote the code in the first place. > > > This developer has a number of options, the recommended way of dealing with > > this > > issue is to rebase, rebase B onto M fixing conflicts. > which would be afaik the same conflicts as if he does merge PyMVPA/PyMVPA.git > which is a predecessor of M', right? so is rebasing worth it now? M and M' point to the same commit, i.e. the commit with the same SHA1. The conflicts are the same, of course. I just means that the core-developer gets control over the merge. If i were a core-developer on a project, and someones branch wouldn't merge cleanly, i would ask for a rebase. > > The core-developer may now fast-forward M to B, or alternatively, > > merge B into M using the flag '--no-ff' to force a merge commit, > > including the nice summary of commits if merge.summary = true. (As it > > should for PyMVAP). Of course rebasing allows for linear history, in > > case you fancy that. > and at the end linear history is the only advantage I see in this > case over preliminary merging of M into B, which could be without > additional pain done as many times as possible. Yes, but it introduces merge commits from upstream, something i would avoid, boils down to personal taste, i guess. > another advantage of rebase someone could mention -- easier way to see > all differences introduced by B, BUT I think most of the times, if not > always, it should be the same as > > diff M...B I am not sure i understand. M...B shows all commits reachable from M and B, but not from both. > even if there were subsequent merges of M into B > > > The alternative is to merge M into B, fixing the conflicts. > ha -- I guess I typed my comment above too early. BTW -- we haven't > mentioned possible slight divergence which I've mentioned in my original > email with > " make sure that it merges fine into current HEAD before pushing " > which could be accomplished with > > git merge --no-commit M > # verifying that no conflicts present > git reset --hard Do you mean git merge --no-commit B, i.e. merging B into M, or the other way round? You mean merging from upstream, i.e. pulling changes from PyMVPA/PyMVPA.git into topic branch of developer clone? > > In a distributed > > setup, this requires of course that the developer make a branch reflecting > > the state of M, namely M'. The core developer may then fast-forward his M > > to the > > merge-commit that B now points to. The disadvantage is that the merge > > summary > > contains items from M and not from B, and the commit message isn't that > > m
Re: [pymvpa] /Developers only/ GIT repository/clones restructuring/migration
summary first: indeed rebasing in _tent/* branches within private clones should be fine in general if we setup the policy that noone merges _tent/ branches before they get merged into integration master/'s. Alternatively, continuous merging of master/'s into your _tent/ branches is fine as well if you promise to provide human-readable summary of the changes in your _tent/* branch upon pull request. On Wed, 11 Aug 2010, Valentin Haenel wrote: > implement a soft policy whereby non-core developers, who are in the pkg-exppsy > group are kindly asked not to push to alioth although it would be technically > possible. I think it shouldn't be a problem. :) I thought that is what I described in the original email ;-) > > my question at nipy-devel: > > http://mail.scipy.org/pipermail/nipy-devel/2010-August/004455.html > In fact, unless you add collaborators to the PyMVPA/PyMVPA.git repository > should be > setup like this per default. I.e. only you and Michael are allowed to push > _anything_ to it. I know and that is how it is now > I have no idea if you could mod the hooks from github > repos... yeap -- and that is what was question to nipy-devel about... the main purpose of hooks for that repository would be to avoid human errors of the "core developers" who are still somewhat humans ;) > > > Will you merge the developers masters? > > yes, upon pull request (via github system or just email) > ok. so when you merge my master branch, i can then fast forward the master > branch of my repo to the master branch of the PyMVPA/PyMVPA.git repo, i see > :-) yeap > > in general rebases should be avoided as soon as branch is seen publicly, > Well, that depends. Some projects specify branches that will be rebased etc... > and therefore no one should ever base any work of those branches, but only the > stable ones. We regularly rebase pushed branches in psignifit. I guess it also > depends on the number of devs, the number of users etc.. yeah -- but what would be the advantage, besides saner development history with no too many of parallel lines in the DAG? if none -- I would simply avoid public rebases in general... I think in general it goes along with Linus's vision on that, e.g. http://kerneltrap.org/Linux/Git_Management > > * if branch you want to be merged was not yet pushed online, please > > rebase it against corresponding branch current HEAD, before pushing it > > online > So rebase onto the master of the PyMVPA/PyMVPA.git repository. or maint/0.4 if the branch is a bugfix (or may be even a new feature for god sake) for 0.4 > Hmm, so you suggest merging from upstream, i.e. merge the master of the > PyMVPA/PyMVPA.git repo into developer master. I think this is whats called > criss-cross merging and is discouraged. This is a bit of a tricky subject, let > me try to explain. > >...< > PyMVPA/PyMVPA.git developer.git > M M' B > | | / > >...< > M is the PyMVPA/PyMVPA.git master, M' is the developers version of M, kind of > like a tracking branch, and B is the developer topic branch. The developer has > been writing code in B, and in the meantime some other stuff was merged into > M. > A core developer fetches B, tries to merge into M, and encounters a merge > conflict. Since the core-developer didn't write the code, has limited time, > etc... he does not wish to fix the conflict, but instead would like to > delegate > the job to the developer who wrote the code in the first place. > This developer has a number of options, the recommended way of dealing with > this > issue is to rebase, rebase B onto M fixing conflicts. which would be afaik the same conflicts as if he does merge PyMVPA/PyMVPA.git which is a predecessor of M', right? so is rebasing worth it now? > The core-developer may now fast-forward M to B, or alternatively, > merge B into M using the flag '--no-ff' to force a merge commit, > including the nice summary of commits if merge.summary = true. (As it > should for PyMVAP). Of course rebasing allows for linear history, in > case you fancy that. and at the end linear history is the only advantage I see in this case over preliminary merging of M into B, which could be without additional pain done as many times as possible. another advantage of rebase someone could mention -- easier way to see all differences introduced by B, BUT I think most of the times, if not always, it should be the same as diff M...B even if there were subsequent merges of M into B > The alternative is to merge M into B, fixing the conflicts. ha -- I guess I typed my comment above too early. BTW -- we haven't mentioned possible slight divergence which I've mentioned in my original email with " make sure that it merges fine into current HEAD before pushing " which could be accomplished with git merge --no-commit M # verifying that no conflicts present git reset --hard > In a distributed > setup, this requires of course that the developer make a branch r
Re: [pymvpa] /Developers only/ GIT repository/clones restructuring/migration
* Yaroslav Halchenko [100811]: > > > alioth.debian.org (AKA git.debian.org) Will eventually be ... > > Why don't you remove push access for anyone except the > > core-developers? > I am not sure if we have that much of granularity of control over it > (everyone within pkg-exppsy project has rights atm), besides ACL at > filesystem level which I am not fluent with or adjusting the hook > further... but introduced hook already should forbid most of evil > actions (besides fast-forwarding branches and pushing new tags) so > we should be safe. We even thought to provide custom commit on top of > master which removes everything and adds README describing the migration > -- that would forbid further pushes of code, and provide proper > referencing... but we decided to postpone such radical step for now I know that gitolite apparently provides fine grained control over who is allowed to push to what branch, but i have yet to use it. You could just implement a soft policy whereby non-core developers, who are in the pkg-exppsy group are kindly asked not to push to alioth although it would be technically possible. I think it shouldn't be a problem. :) > > > No _tent branches, nor +tent tags should be pushed in there. Only > > > annotated tags for upstream or distribution releases should end up > > > there > > Again, the same comment as for alioth. > That is trickier one to assure (besides that I already hardcoded in my > .git/config only what gets pushed) since I have not got myself familiar > yet with ways on how to provide hooks on github, please see/answer > my question at nipy-devel: > http://mail.scipy.org/pipermail/nipy-devel/2010-August/004455.html In fact, unless you add collaborators to the PyMVPA/PyMVPA.git repository should be setup like this per default. I.e. only you and Michael are allowed to push _anything_ to it. I have no idea if you could mod the hooks from github repos... But i wouldn't count on it. > > > - master branch -- development/integration branch, intended to be > > > eventually pushed (thus fast-forward only) as master of > > > PyMVPA/PyMVPA repository > > What does this mean exactly? Should the branches in the developers > > repository > > reflect the state of master in the PyMVPA repository? > They should be based on it > > > Can developers use their master to develop stuff in? > yes > > > Will you merge the developers masters? > yes, upon pull request (via github system or just email) ok. so when you merge my master branch, i can then fast forward the master branch of my repo to the master branch of the PyMVPA/PyMVPA.git repo, i see :-) > Also I've forgotten to mention that bugfixes for maintenance versions > should be in _bf/ branches on top of maint/x.y, not sure but it might be > also useful to embed maintenance version into branch name, e.g. > _bf/0.4.5_... ? > > > > - _tent/ (tentative) feature and _bf/ (bugfix) branches which you > > > would like us (or you into your master first) to integrate > > > > - +tent/ unsigned/unannotated tags to point at the locations when > > > your corresponding _tent/ branch got accepted (not necessary if > > > feature is "minimalistic" and not worth memorizing) > > Would you want us to rebase topic branches onto the PyMVPA master, so that > > merges go cleanly? > in general rebases should be avoided as soon as branch is seen publicly, Well, that depends. Some projects specify branches that will be rebased etc... and therefore no one should ever base any work of those branches, but only the stable ones. We regularly rebase pushed branches in psignifit. I guess it also depends on the number of devs, the number of users etc.. > so the flow could be > > * if branch you want to be merged was not yet pushed online, please > rebase it against corresponding branch current HEAD, before pushing it > online So rebase onto the master of the PyMVPA/PyMVPA.git repository. > * if branch was already pushed, please do not bother with rebasing, but > make sure that it merges fine into current HEAD before pushing -- may > be even merge corresponding HEAD before pushing? what would you > advise? Hmm, so you suggest merging from upstream, i.e. merge the master of the PyMVPA/PyMVPA.git repo into developer master. I think this is whats called criss-cross merging and is discouraged. This is a bit of a tricky subject, let me try to explain. we have the following situation. PyMVPA/PyMVPA.git developer.git M M' B | | / | | / | | / M is the PyMVPA/PyMVPA.git master, M' is the developers version of M, kind of like a tracking branch, and B is the developer topic branch. The developer has been writing code in B, and in the meantime some other stuff was merged into M. A core developer fetches B, tries to merge into M, and encounters a merge conflict. Since the core-developer didn't write the code, has limite
Re: [pymvpa] /Developers only/ GIT repository/clones restructuring/migration
Hi Valentin, THANKS bunch for all the feedback! Clarifications (and few follow up questions) are below > > in your own clones at github -- please move them over or remove from > > alioth:: > You neglected to mention that you had already removed them from alioth. ;p oops, sorry: All branches which were already merged into master branch present on github were removed. So you should be safe to proceed with just the master as a starting point. And if you used them locally, you still would have them ;-) so you could push them to your clones's master correspondingly -- everyone should be safe -- we watched your backs ;) > I moved them both to my github clone, so i guess if you still have > '/remotes/alioth/val/*' lying around you can get rid of those with > ' git remote prune alioth'. Assuming of course that your remote for the alioth > repository was indeed called 'alioth'. yes it was ;-) thanks! > > alioth.debian.org (AKA git.debian.org) Will eventually be ... > Why don't you remove push access for anyone except the > core-developers? I am not sure if we have that much of granularity of control over it (everyone within pkg-exppsy project has rights atm), besides ACL at filesystem level which I am not fluent with or adjusting the hook further... but introduced hook already should forbid most of evil actions (besides fast-forwarding branches and pushing new tags) so we should be safe. We even thought to provide custom commit on top of master which removes everything and adds README describing the migration -- that would forbid further pushes of code, and provide proper referencing... but we decided to postpone such radical step for now > > No _tent branches, nor +tent tags should be pushed in there. Only > > annotated tags for upstream or distribution releases should end up > > there > Again, the same comment as for alioth. That is trickier one to assure (besides that I already hardcoded in my .git/config only what gets pushed) since I have not got myself familiar yet with ways on how to provide hooks on github, please see/answer my question at nipy-devel: http://mail.scipy.org/pipermail/nipy-devel/2010-August/004455.html > > - master branch -- development/integration branch, intended to be > > eventually pushed (thus fast-forward only) as master of > > PyMVPA/PyMVPA repository > What does this mean exactly? Should the branches in the developers repository > reflect the state of master in the PyMVPA repository? They should be based on it > Can developers use their master to develop stuff in? yes > Will you merge the developers masters? yes, upon pull request (via github system or just email) Also I've forgotten to mention that bugfixes for maintenance versions should be in _bf/ branches on top of maint/x.y, not sure but it might be also useful to embed maintenance version into branch name, e.g. _bf/0.4.5_... ? > > - _tent/ (tentative) feature and _bf/ (bugfix) branches which you > > would like us (or you into your master first) to integrate > > - +tent/ unsigned/unannotated tags to point at the locations when > > your corresponding _tent/ branch got accepted (not necessary if > > feature is "minimalistic" and not worth memorizing) > Would you want us to rebase topic branches onto the PyMVPA master, so that > merges go cleanly? in general rebases should be avoided as soon as branch is seen publicly, so the flow could be * if branch you want to be merged was not yet pushed online, please rebase it against corresponding branch current HEAD, before pushing it online * if branch was already pushed, please do not bother with rebasing, but make sure that it merges fine into current HEAD before pushing -- may be even merge corresponding HEAD before pushing? what would you advise? > This removes old tags, sure i had those locally and removed them. I didn't see > any that were prefixed with '--' though. good for you then ;-) > > git push :last_website_update > > git push :sg/unittests_passed > But this only applies if i forked on gihub, before the tags were removed. > Since > i only forked today, i do not need to do this. yes -- thank you for clarification! > > fetch -- you will obtain all tags from that remote, and then they would > > propagate to others who would clone you, etc... So, please > But they would only propagate if i push them right? afaics you must push tags > explicitly, or use the '--tags' switch for push. yes yes yes ;) or if you have something like push = refs/tags/* for the corresponding remote in your .git/config > It may also make sense to fetch into a temporary branch to examine the changes > before merging: > git fetch g...@github.com:PyMVPA/PyMVPA.git > $REMOTE_BRANCH:$LOCAL_TEMPORARY > git log $CURRENT_BRANCH..$LOCAL_TEMPORARY > git merge $LOCAL_TEMPORARY COOL -- thanks for sharing, I've not checked before either I could fetch using URL -- good to know! --
Re: [pymvpa] /Developers only/ GIT repository/clones restructuring/migration
Hi, although i have no time to do PyMVPA development, i must admit that git has become one of my major interests, and its always interesting to see how projects use it :-) Naturally i have some questions and comments. * Yaroslav Halchenko [100811]: > Major change > > > you should not push to alioth.debian.org (AKA git.debian.org) your > development branches (e.g. your_name/master) -- they all should reside > in your own clones at github -- please move them over or remove from > alioth:: You neglected to mention that you had already removed them from alioth. ;p > remotes/alioth/val/libsvm+newsl+nodc > remotes/alioth/val/new-sl I moved them both to my github clone, so i guess if you still have '/remotes/alioth/val/*' lying around you can get rid of those with ' git remote prune alioth'. Assuming of course that your remote for the alioth repository was indeed called 'alioth'. > To remove branch (or tag) from alioth (after you pushed it to your > github clone), just do:: > > git push : > > > New workflow > > > We will primarily use github for the development. Therefore: > > alioth.debian.org (AKA git.debian.org) > Will eventually be deprecated. For now it will carry all releases and > associated Debian packaging, since X-Vcs fields in Debian packages > point to this repository. New development will not be pushed into > this repository. All personal branches should migrate off it. > Websites will be updated soon to reflect this Why don't you remove push access for anyone except the core-developers? > http://github.com/PyMVPA/PyMVPA > The main repository -- source for all of your forks on github. > It will contain > > - release and distribution releases tags (signed/annotated) > - maint/* (maintenance) and dist/* (distribution) branches > - master branch -- marginally well tested thus usable (not quite so atm) > development branch > - website/www, website/dev -- only fast-forward branches which would > point to the last location of website updates > > No _tent branches, nor +tent tags should be pushed in there. > Only annotated tags for upstream or distribution releases should end > up there Again, the same comment as for alioth. > http://github.com//PyMVPA > Development environments -- feel free to create your own. Should contain > > - master branch -- development/integration branch, intended to be > eventually pushed (thus fast-forward only) as master of > PyMVPA/PyMVPA repository What does this mean exactly? Should the branches in the developers repository reflect the state of master in the PyMVPA repository? Can developers use their master to develop stuff in? Will you merge the developers masters? > - _tent/ (tentative) feature and _bf/ (bugfix) branches which you > would like us (or you into your master first) to integrate > > - +tent/ unsigned/unannotated tags to point at the locations when > your corresponding _tent/ branch got accepted (not necessary if > feature is "minimalistic" and not worth memorizing) Would you want us to rebase topic branches onto the PyMVPA master, so that merges go cleanly? > Do not forget to remove _tent/ branches from your clones upon > integration, with smth like:: > > git br -d _tent/ > git push origin :_tent/ > > > Course of action > > > # if you relied on /* branches on alioth and haven't yet created > your fork on github, please do so by visiting > http://github.com/PyMVPA/PyMVPA and clicking on "Fork button" > > # we did some cleanup of repositories, so to get your local copies > cleaned up a bit, please do:: > > git fetch --all --prune > git tag | grep -e __ -e last_we -e sg/unittests_passed | xargs git tag -d This removes old tags, sure i had those locally and removed them. I didn't see any that were prefixed with '--' though. >git push :last_website_update >git push :sg/unittests_passed But this only applies if i forked on gihub, before the tags were removed. Since i only forked today, i do not need to do this. > WARNING > === > > As you could guess from manual removal of tags above, tags in git > are somewhat viral. If you add someone's repository as a remote and > fetch -- you will obtain all tags from that remote, and then they would > propagate to others who would clone you, etc... So, please But they would only propagate if i push them right? afaics you must push tags explicitly, or use the '--tags' switch for push. > # follow the conventions above > # do not push to remotes all kinds of useless/temporary tags > > If you want to pull someones' changes into your tree, and do not want to > fetch his tags, you can pull directly using URL and branchnames, smth > like:: > > git pull g...@github.com:PyMVPA/PyMVPA.git master It may also make sense to fetch into a temporary branch to examine the changes before merging:
[pymvpa] /Developers only/ GIT repository/clones restructuring/migration
Dear PyMVPA Developers, We are in the process of migrating from "single GIT repository for everyone" to more distributed flow of development provided by Github. Major change you should not push to alioth.debian.org (AKA git.debian.org) your development branches (e.g. your_name/master) -- they all should reside in your own clones at github -- please move them over or remove from alioth:: remotes/alioth/sg/myflexds remotes/alioth/val/libsvm+newsl+nodc remotes/alioth/val/new-sl To remove branch (or tag) from alioth (after you pushed it to your github clone), just do:: git push : New workflow We will primarily use github for the development. Therefore: alioth.debian.org (AKA git.debian.org) Will eventually be deprecated. For now it will carry all releases and associated Debian packaging, since X-Vcs fields in Debian packages point to this repository. New development will not be pushed into this repository. All personal branches should migrate off it. Websites will be updated soon to reflect this http://github.com/PyMVPA/PyMVPA The main repository -- source for all of your forks on github. It will contain - release and distribution releases tags (signed/annotated) - maint/* (maintenance) and dist/* (distribution) branches - master branch -- marginally well tested thus usable (not quite so atm) development branch - website/www, website/dev -- only fast-forward branches which would point to the last location of website updates No _tent branches, nor +tent tags should be pushed in there. Only annotated tags for upstream or distribution releases should end up there http://github.com//PyMVPA Development environments -- feel free to create your own. Should contain - master branch -- development/integration branch, intended to be eventually pushed (thus fast-forward only) as master of PyMVPA/PyMVPA repository - _tent/ (tentative) feature and _bf/ (bugfix) branches which you would like us (or you into your master first) to integrate - +tent/ unsigned/unannotated tags to point at the locations when your corresponding _tent/ branch got accepted (not necessary if feature is "minimalistic" and not worth memorizing) Do not forget to remove _tent/ branches from your clones upon integration, with smth like:: git br -d _tent/ git push origin :_tent/ Course of action # if you relied on /* branches on alioth and haven't yet created your fork on github, please do so by visiting http://github.com/PyMVPA/PyMVPA and clicking on "Fork button" # we did some cleanup of repositories, so to get your local copies cleaned up a bit, please do:: git fetch --all --prune git tag | grep -e __ -e last_we -e sg/unittests_passed | xargs git tag -d git push :last_website_update git push :sg/unittests_passed WARNING === As you could guess from manual removal of tags above, tags in git are somewhat viral. If you add someone's repository as a remote and fetch -- you will obtain all tags from that remote, and then they would propagate to others who would clone you, etc... So, please # follow the conventions above # do not push to remotes all kinds of useless/temporary tags If you want to pull someones' changes into your tree, and do not want to fetch his tags, you can pull directly using URL and branchnames, smth like:: git pull g...@github.com:PyMVPA/PyMVPA.git master -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] signature.asc Description: Digital signature ___ Pkg-ExpPsy-PyMVPA mailing list Pkg-ExpPsy-PyMVPA@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-exppsy-pymvpa
