Hello Gaurav, No, it can't. Git hooks that run on the local repository won't necessarily run on the remotes.
What happens here is that developer who ran git-reset will send a ref update to the remote (gitolite); that's what you can log. However, Git by itself is not capable of logging. You will have to implement it in your hooks. Best, Gergely On 22 Feb 2015 07:06, "Gaurav Chhabra" <varuag.chha...@gmail.com> wrote: > Hi Gergely, > > > We use Gitolite only for access control. As you mentioned, it runs as a > common user and each user has its own user id which they use for accessing > Git repositories. > > What i do understand is that we can definitely implement hook (and we do > have one) when a user pushes something to a branch/repo but i'm not sure > whether hooks can also log commands that run before (in my case, 'git > reset') performing pushes. How can we achieve that? > > > Regards, > Gaurav > > > On Sun, Feb 22, 2015 at 3:41 AM, Gergely Polonkai <gerg...@polonkai.eu> > wrote: > >> Logging pushes is a bit tricky, as push such operation doesn't have an >> associated "user" record (ie. pushes don't have authors nor committers). >> >> If your developers use different user accounts for pushing to the >> repository, though, you may implement a git hook that runs after each ref >> update. Note that this is also possible with Gitolite, which uses one SSH >> user, but separates accounts by SSH keys. >> >> Without any further knowledge of your infrastructure, it is hard to >> advise any further. >> >> Best, >> Gergely >> On 21 Feb 2015 10:14, "Gaurav Chhabra" <varuag.chha...@gmail.com> wrote: >> >>> Thanks for the reply Gergely! I am wondering how can we log pushes and >>> whether push logs will contain details about 'git reset'. Can you please >>> help me with the command (not the exact syntax) or some link which i can >>> refer to, to implement logging for pushes? >>> >>> >>> >>> >>> >>> On Sat, Feb 21, 2015 at 2:16 PM, Gergely Polonkai <gerg...@polonkai.eu> >>> wrote: >>> >>>> Hello, >>>> >>>> regarding Q1, if you don't log pushes by any means, I fear this is >>>> impossible. >>>> >>>> To prevent such things, you should disable non-fastforward pushes to >>>> the central repository; this way developers won't be able to change your >>>> branches back to an older state. >>>> >>>> Best, >>>> Gergely >>>> On 21 Feb 2015 02:57, "Gaurav Chhabra" <varuag.chha...@gmail.com> >>>> wrote: >>>> >>>>> I came across a problem recently. One of the developers committed some >>>>> changes in a branch. When he checked the branch log (git checkout >>>>> branch; git log), the commit (say, *abc*) was showing up but when he >>>>> checked the log for a file (git log <file_name>), which was part of >>>>> the given commit (*abc*), the associated commit (*abc*) was not >>>>> showing up; instead, an older commit id (say, *xyz*) was there. >>>>> >>>>> When the issue came to my notice, I tried using git log --follow >>>>> <file_name> to check complete history of a file just to make sure >>>>> whether the file was renamed to its current name. The output of git >>>>> log --follow <file_name> was actually showing the commit id (*abc*) >>>>> that was missing in the output ofgit log <file_name> command. On >>>>> asking developer whether the file was renamed, i came to know that >>>>> *no* renames were done ever for that file. This was confusing and i >>>>> was stuck because i was not able to figure out what happened. Later, it >>>>> turned out that another developer while pushing his code encountered merge >>>>> conflict and instead of resolving it, he simply did a git reset . and >>>>> the HEAD got shifted. >>>>> >>>>> Q.1) Is there any way i could have figured out about the git reset command >>>>> that the other developer executed on his machine? FYI, i have admin access >>>>> to Git. >>>>> >>>>> Q.2) Is there any way we can control such things from happening in >>>>> future? I’m not sure whether this can be controlled using hook because >>>>> this >>>>> is not a ‘push’ command. It's something that's being done just before >>>>> push. >>>>> Please correct me if I’m mistaken. The biggest problem that I see here is >>>>> that every developer has the rights to commit, which I feel is not right. >>>>> I >>>>> feel, even restricting it cannot be foolproof but it can certainly bring >>>>> down such occurrences significantly. Any suggestions? >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Git for human beings" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to git-users+unsubscr...@googlegroups.com. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>> > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
