Hi Wim, my point was that when you do a deny in a pre-receive (exact term i guess) hook in order to enforce things you make the workflow slightly more complicated, because when people have made some commits (incl. merge commits from pulls/remote fetches) in their local git repositories, then those might need to be undone and/or rebased (via git rebase in interactive mode choosing to pick or modify single commits). this way you can comply to the rules the remote end enforces. just enforcing on a local repository is probably much easier and more appropriate in a distributed environment.
however for example at work i run a strict policy, and strict means non-local to me. it just depends on how much control you want to have, at work i happen to be a control-freak, but we develop financial software and real money is moved so being conservative is what is expected. just wanted to share my point here that when you do it "remote" (e.g. pre-receive on the master everyone is pulling from and pushing to), then you kind of have to be prepared for spoiling 1-2 developer evenings on "git-fighting", my whole point, not saying it is never worth it. regards, stepan Am 08.05.2012 um 20:45 schrieb Wim Jongman: > Hi Stepan, > > Thanks but I don't get it. A commit hook is local and a push hook is > remote? Is that what you are saying? > > so you say, if we do a commit (+ reformat) and then a push which is > denied (because of not having pulled and changes pending on master) > the local git repo contains formatted changes which are not in the > workspace. Is that correct? > > > Regards, > > Wim > > On Tue, May 8, 2012 at 5:57 PM, Stepan Rutz <[email protected]> wrote: >> Hi Wim, >> >> with git your commit hook is one thing, but you may need to consider a >> push-hook as well. When you push and things are denied you need to rebase to >> get your commits into a state that the push hook accepts, so thats a good >> thing imho but asking a lot from the programmers, especially those that are >> new to git. Certainly enforcing things on the proclaimed master git server >> (some servers are more equal than other servers, even in dscm environments) >> is the best way to really make sure things (code and/or commit message) come >> in in the expected form. With git (dscm) its just a bit more cumbersome, due >> to the need to rebase "broken" commits. >> >> just my random comments... greetings, stepan >> >> >> >> >> -------- Original-Nachricht -------- >>> Datum: Tue, 8 May 2012 16:28:23 +0200 >>> Von: Wim Jongman <[email protected]> >>> An: Nebula Dev <[email protected]> >>> Betreff: [nebula-dev] git pre-commit hook for code format >> >>> Hi, >>> >>> I use CTRL+F constantly. This gives large code changes when I commit >>> something that was formatted in a different style. I use the default >>> jdt style btw. >>> >>> Is it possible (and desired) to run a pre commit hook that formats our >>> code before it hits the repo? I am looking for opinions and >>> experiences. >>> >>> I found this: >>> >>> http://www.blog.project13.pl/index.php/fun/1076/git-hacking-pre-commit-hook-and-custom-command/ >>> >>> Regards, >>> >>> Wim >>> _______________________________________________ >>> nebula-dev mailing list >>> [email protected] >>> https://dev.eclipse.org/mailman/listinfo/nebula-dev >> >> -- >> Stepan Rutz >> Phone: +49 (0) 178 654 9284 >> Email: [email protected] >> Earth: Brunnenallee 25a, 50226 Frechen, Germany >> >> NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! >> Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a >> _______________________________________________ >> nebula-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/nebula-dev > _______________________________________________ > nebula-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/nebula-dev _______________________________________________ nebula-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/nebula-dev
