New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow modification of the gitolite-admin repository from a different location #240

Closed
lschoepps opened this Issue Jul 21, 2014 · 5 comments

Comments

Projects
None yet
4 participants
@lschoepps

lschoepps commented Jul 21, 2014

Hi,
Currently it is not possible to commit into the gitolite-admin repository from a different location than the gitolite_tmp_dir because the plugin won't be able to push the change. It should at least do a pull before any commits, and maybe rebase (if possible) or reset head and try again in case of conflicts.
Do you think it will be possible ?

@n-rodriguez n-rodriguez self-assigned this Jul 21, 2014

@oliverguenther

This comment has been minimized.

Show comment
Hide comment
@oliverguenther

oliverguenther Jul 21, 2014

It shouldn't be too hard to implement that feature for the plugin (either as default or opt-in). The gitolite-rugged gem has an unused method for pulling in changes from the repository, which does the following two steps

  • reset --hard origin/master
  • pull origin/master (implemented as fetch + merge, as rugged does not have a one-line pull)

That functionality should be easy to replicate in grit. From the gitolite gem's perspective, the open question is which protocol should be followed when (e.g., reset+pull before commit). As for rebasing, I'm not sure how that may be employed from rugged, I'd have to look into that.

oliverguenther commented Jul 21, 2014

It shouldn't be too hard to implement that feature for the plugin (either as default or opt-in). The gitolite-rugged gem has an unused method for pulling in changes from the repository, which does the following two steps

  • reset --hard origin/master
  • pull origin/master (implemented as fetch + merge, as rugged does not have a one-line pull)

That functionality should be easy to replicate in grit. From the gitolite gem's perspective, the open question is which protocol should be followed when (e.g., reset+pull before commit). As for rebasing, I'm not sure how that may be employed from rugged, I'd have to look into that.

@lschoepps

This comment has been minimized.

Show comment
Hide comment
@lschoepps

lschoepps Jul 22, 2014

I think that rebasing (or resolving any conflicts) is not necessary, if it reset and pull, then it's fast forward and the only problem is if the repository is modified between a pull and a push. In this case, I think the easiest is to reset + pull and try again.

lschoepps commented Jul 22, 2014

I think that rebasing (or resolving any conflicts) is not necessary, if it reset and pull, then it's fast forward and the only problem is if the repository is modified between a pull and a push. In this case, I think the easiest is to reset + pull and try again.

@n-rodriguez

This comment has been minimized.

Show comment
Hide comment
@n-rodriguez

n-rodriguez Aug 28, 2014

Member

Thanks Oliver for your work (oliverguenther/gitolite-rugged@6642941) I'm gonna look at it in the next days.

Member

n-rodriguez commented Aug 28, 2014

Thanks Oliver for your work (oliverguenther/gitolite-rugged@6642941) I'm gonna look at it in the next days.

@n-rodriguez n-rodriguez changed the title from Allow modification of the gitolite-admin repository to Allow modification of the gitolite-admin repository from a different location Sep 10, 2014

@tomas-korec

This comment has been minimized.

Show comment
Hide comment
@tomas-korec

tomas-korec Oct 24, 2014

If you are still looking for a solution, this worked for me: #299 (comment) (first part of the comment).

tomas-korec commented Oct 24, 2014

If you are still looking for a solution, this worked for me: #299 (comment) (first part of the comment).

@n-rodriguez

This comment has been minimized.

Show comment
Hide comment
@n-rodriguez

n-rodriguez Dec 21, 2014

Member

I close this issue. The work is already done in gitolite-rugged and integrated in the v0.8 branch.
I don't see the point of duplicating efforts to backport a feature. We need to move forward :)

Member

n-rodriguez commented Dec 21, 2014

I close this issue. The work is already done in gitolite-rugged and integrated in the v0.8 branch.
I don't see the point of duplicating efforts to backport a feature. We need to move forward :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment