thoughts on setting core.logAllRefUpdates default true for bare repos

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.

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

Hi Johannes,

On Wed, Nov 4, 2009 at 6:55 PM, Johannes Schindelin
[off-list ref] 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

2009/11/4 Sitaram Chamarty [off-list ref]:

Hi Johannes,

On Wed, Nov 4, 2009 at 6:55 PM, Johannes Schindelin
[off-list ref] wrote:

quoted

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/"

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

Heya,

On Thu, Nov 5, 2009 at 00:52, Nicolas Sebrecht [off-list ref] 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

On Thu, Nov 5, 2009 at 5:22 AM, Nicolas Sebrecht [off-list ref] wrote:

The 04/11/09, Sitaram Chamarty wrote:

quoted

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