Re: keeping remote repo checked out?
- From
Petr Baudis <pasky@suse.cz>
- Date
- Nov 28, 2005, 21:28 UTC
- Message-ID
- <20051128212804.GV22159@pasky.or.cz>
- In-Reply-To
- <7vsltgtvk4.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Mon, Nov 28, 2005 at 08:35:23PM CET, I got a letter where Junio C Hamano <junkio@cox.net> said that...
Show 5 quoted lines
> Both of us are right and talking about the same thing. You are > right that as long as hooks/post-update is done correctly the > one who works on the server should not have to worry. I am > right that the hooks/post-update for that setup needs to be done > very carefully ;-).
Aha, then I misunderstood what you wrote before - sorry. Obviously, you are right. ;-)
Show 7 quoted lines
> Here are the things whoever is doing the hooks/post-update for > this particular setup needs to think about. > > - is it safe to assume that the guy working on the server > working tree never switch branches? otherwise, what to do if > the working tree has different branch checked out when push > called post-update?
I wouldn't do anything. Working copy reflects the HEAD; if you don't update HEAD, you needn't touch the working copy.
Show 5 quoted lines
> - should it allow forced-push that sets HEAD to non descendant > of the current HEAD? In a shared repository setup, > disallowing forced-push is a good discipline. OTOH, if this > is primarily used as an installation mechanism to a remote > hosting site, allowing forced-push may be ok.
I would just leave this on the particular head policy.
> - should it do 'git-checkout', 'git-reset --hard HEAD', or > 'git-pull . branch_to_push_into'? The former two pretty much > assumes no development happens on the server repository and > git push is used primarily as an installation mechanism.
Files should be removed properly, which pretty much excludes the former two, I think.
Show 5 quoted lines
> The latter is to keep a branch, other than "master" that is > always checked out on the server machine, and have people > push into a different branch and merge with it automatically > when a push happens. what would you do when a merge conflict > happens?
This seems weird and overcomplicated, and it seems to mirror that GIT does not want to deal with trees containing local modifications - which is fine, but I don't think you should go over huge hoops in the workflow to adjust to that. Just verify in the pre-update hook that the tree contains no local modifications, and disallow the push otherwise. Cogito can then use own update hooks which will enable it to handle local changes more gracefully (albeit still not ideally).
> On a tangent, the last point brings up an interesting > shared-repo usage pattern. When you have a shared central > repository like CVS, you could arrange things this way:
..snip..
> I am not sure if people would find this useful, though.
It is certainly quite interesting idea. I'm not sure how useful in practice is it either, though. ;-)
-- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ VI has two modes: the one in which it beeps and the one in which it doesn't.