thoughts on setting core.logAllRefUpdates default true for bare repos

[Sitaram Chamarty]

It seems to me an accidental push -f would cause some
trouble on a bare repo, and would usually require a bit of
grubbing around among the unreachable commits looking for
the right one.

What would be the downsides (other than some objects hanging
around far longer, i.e., space issues) of setting the config
variable core.logAllRefUpdates to be default true on bare
repos.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Johannes Schindelin]

Hi,

On Wed, 4 Nov 2009, Sitaram Chamarty wrote:

> It seems to me an accidental push -f would cause some trouble on a bare
> repo, and would usually require a bit of grubbing around among the
> unreachable commits looking for the right one.

In one usage of mine, we have set said config value for exactly that
reason.

> What would be the downsides (other than some objects hanging
> around far longer, i.e., space issues) of setting the config
> variable core.logAllRefUpdates to be default true on bare
> repos.

I did not have time yet to investigate, but it seems that there are
problems with the permissions of shared bare repositories when activating
the reflogs.

With gitweb on a public site, there might be a problem when you pushed
some blob containing trade secrets accidentally, and try to scrub the
repository using "git gc" after a forced push.

That are the only downsides I can think of.

Ciao,
Dscho

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Sitaram Chamarty]

Hi Johannes,

On Wed, Nov 4, 2009 at 6:55 PM, Johannes Schindelin
<[hidden email]> wrote:

> I did not have time yet to investigate, but it seems that there are
> problems with the permissions of shared bare repositories when activating
> the reflogs.

Interesting; I will try and investigate if I can find something.

> With gitweb on a public site, there might be a problem when you pushed
> some blob containing trade secrets accidentally, and try to scrub the
> repository using "git gc" after a forced push.

Agreed.  This config variable is biased to *keep* data if set to true,
and (default) false value is biased not to keep that same data, so
that will always be a conflict.

But if you are able to do "gc" manually on any repo you can also do
"reflog expire" before "gc" can you not?  Please correct me if I'm
wrong.

Regards,

Sitaram
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[demerphq]

2009/11/4 Sitaram Chamarty <[hidden email]>:

> Hi Johannes,
>
> On Wed, Nov 4, 2009 at 6:55 PM, Johannes Schindelin
> <[hidden email]> wrote:
>
>> I did not have time yet to investigate, but it seems that there are
>> problems with the permissions of shared bare repositories when activating
>> the reflogs.
>
> Interesting; I will try and investigate if I can find something.

Assuming you mean via ssh access then if there is we haven't noticed
the problems at $work, and we have had this setup from the first time
somebody did a forced push and broke things, which was like day 3 or
something of our switchover to git from cvs, which is about two years
ago.

IMO it would be nice if the reflog could be set to ONLY record forced
updates. This would make a lot of sense on a bare repo.

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Matthieu Moy-2]

Johannes Schindelin <[hidden email]> writes:

> I did not have time yet to investigate, but it seems that there are
> problems with the permissions of shared bare repositories when activating
> the reflogs.

I can't think of any, and I just tried launching two

while true; do git pull; date > foo.txt ; git add .; git commit -m "xxx"; git push; done

in parallel, with two different users pushing to a --bare --shared
repository, and it did work well. But I may very well have missed
something.

(and actually, if it causes problem, it's an argument in favor of
defaulting to false when core.shared is true, not when core.bare).


Unless I missed something, I think core.logAllRefUpdates should be
enabled for bare repos.

--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Junio C Hamano]

Matthieu Moy <[hidden email]> writes:

> I can't think of any, and I just tried launching two
>
> while true; do git pull; date > foo.txt ; git add .; git commit -m "xxx"; git push; done
>
> in parallel, with two different users pushing to a --bare --shared
> repository, and it did work well. But I may very well have missed
> something.
>
> (and actually, if it causes problem, it's an argument in favor of
> defaulting to false when core.shared is true, not when core.bare).
>
> Unless I missed something, I think core.logAllRefUpdates should be
> enabled for bare repos.

Your experiment justifies "could be enabled safely" and saying "should be"
based on that is a bit too strong and also premature.

The single most common reason why a bare repository is bare is because
nobody regularly logs in to the machine that hosts it and goes there to
access its contents.  As reflog is a local thing, and not exposed to
outside world, enabling it alone would not help a lot to people who do not
have such a direct access to the bare repository, which by definition is
the majority because the reason why the repository is bare to begin with.

Once we add ways to expose information kept in reflog of a bare repository
more effectively and conveniently, the argument could become "should be
enabled now it would be very useful to have one".

I mentioned a possible option to show reflog entry annotations in gitweb.
That was an example of such an addition of "a way to expose".

It also is plausible to teach git-daemon a remote "log" request; similar
to "git fetch" running "upload-pack" on the other end in the bare
repository, a "git log --remote" command may run "upload-log" on the other
end and this service may allow passing the "-g" option when it does so.
That would be another addition of "a way to expose".

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Matthieu Moy-2]

Junio C Hamano <[hidden email]> writes:

> Matthieu Moy <[hidden email]> writes:
>
>> I can't think of any, and I just tried launching two
>>
>> while true; do git pull; date > foo.txt ; git add .; git commit -m "xxx"; git push; done
>>
>> in parallel, with two different users pushing to a --bare --shared
>> repository, and it did work well. But I may very well have missed
>> something.
>>
>> (and actually, if it causes problem, it's an argument in favor of
>> defaulting to false when core.shared is true, not when core.bare).
>>
>> Unless I missed something, I think core.logAllRefUpdates should be
>> enabled for bare repos.
>
> Your experiment justifies "could be enabled safely" and saying "should be"
> based on that is a bit too strong and also premature.

Right, there were no cause/effect relationship between the first part
and the "should".

> As reflog is a local thing, and not exposed to outside world,
> enabling it alone would not help a lot to people who do not have
> such a direct access to the bare repository, which by definition is
> the majority because the reason why the repository is bare to begin
> with.

For sure, it's the majority. But it's not 100% cases either.

And in most cases, even if the user doesn't have access to the repo,
there exists a sysadmin somewhere who has. And the day a user will
send a mail "hey, I've messed up everything, I did a push -f and what
happened?", this sysadmin will appreciate to have a log somewhere.

And another use-case for the reflog is to find know reliable where a
piece of code is comming from. "git blame" tells you who the commiter
said he was, while the reflog says reliably who the push-er was.

So, clearly, the reflog on a bare repo is not usefull for daily use
like it is for non-bare repos (where, really, it's a killer
feature ;-) ). But it doesn't seem useless either, and it doesn't cost
much, so ...

--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Nicolas Sebrecht-3]

The 04/11/09, Sitaram Chamarty wrote:

> But if you are able to do "gc" manually on any repo you can also do
> "reflog expire" before "gc" can you not?  Please correct me if I'm
> wrong.

"If we are able to do 'gc' on any repo"... But a lot of users aren't
able to it because they aren't the admin.

Or did you mean if "non-admin users could" ?

--
Nicolas Sebrecht
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Sverre Rabbelier-2]

Heya,

On Thu, Nov 5, 2009 at 00:52, Nicolas Sebrecht <[hidden email]> wrote:
> Or did you mean if "non-admin users could" ?

We're talking about the case wherein a confidential object is pruned,
regardless of whether it is a non-admin or admin user doing the
pruning, they should be able to 'reflog expire' if they can 'git gc'.

--
Cheers,

Sverre Rabbelier
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Sitaram Chamarty]

On Thu, Nov 5, 2009 at 5:22 AM, Nicolas Sebrecht <[hidden email]> wrote:

> The 04/11/09, Sitaram Chamarty wrote:
>
>> But if you are able to do "gc" manually on any repo you can also do
>> "reflog expire" before "gc" can you not?  Please correct me if I'm
>> wrong.
>
> "If we are able to do 'gc' on any repo"... But a lot of users aren't
> able to it because they aren't the admin.
>
> Or did you mean if "non-admin users could" ?

dscho's original mail said: > With gitweb on a public site, there
might be a problem when you pushed
> some blob containing trade secrets accidentally, and try to scrub the
> repository using "git gc" after a forced push.

That's a manual gc.  If you can do a manual gc, you can do a reflog
expire before the gc, is what I meant.

>
> --
> Nicolas Sebrecht
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Sitaram Chamarty]

On Thu, Nov 5, 2009 at 1:19 AM, Junio C Hamano <[hidden email]> wrote:

> The single most common reason why a bare repository is bare is because
> nobody regularly logs in to the machine that hosts it and goes there to
> access its contents.  As reflog is a local thing, and not exposed to
> outside world, enabling it alone would not help a lot to people who do not
> have such a direct access to the bare repository, which by definition is
> the majority because the reason why the repository is bare to begin with.
>
> Once we add ways to expose information kept in reflog of a bare repository
> more effectively and conveniently, the argument could become "should be
> enabled now it would be very useful to have one".

It doesn't have to be exposed nor we have to wait till such features
(like you mentioned gitweb, remote log, etc) are implemented.

We're talking "disaster recovery", not "daily use" -- after all,
*someone* has access to the machine, and can become "local" to it.

Regards,

Sitaram
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html