Deleting remote branches with git-branch and reflog questions

Hello,

As per subject.

If anything, these are safer to delete than local branches because they will be restored automatically with the next fetch, so why do we require the extra switch for remote branches?

Would it be simpler for the user if the following worked?
$ git branch -a
* master
  origin/master
$ git branch -D origin/master

i.e. that the -r switch was unnecessary in unambiguous cases.

reflogs -------

Why does the reflog directory .git/logs need to store the refs/ directory? Aren't /all/ the refs under "refs/" these days?

Is it right that the reflog for a branch is deleted when the branch is 
deleted?  Doesn't this kill one of the advantages of reflogs?  In particular, 
if I accidentally deleted a branch, I would have no way of getting it back 
because the reflog has been deleted too?  Personally I'd prefer that a reflog 
line was added saying
  XXXXXXXXXXXXXXX 00000000000000 Deleted
Or similar.  After all; it's only disk space.  If the ref was later created 
again, then the log can continue to be added to, but it will have a "Created 
from" in the middle instead of at the end.

Andy

Andy Parkins wrote:

No. HEAD isn't, nor is ORIG_HEAD, and possibly others.

On Tuesday 2007 January 23 13:02, Andreas Ericsson wrote:

They're all special cases aren't they? They are symrefs. I don't think they are reflogged at all (they certainly don't appear in my .git/logs directory.

Perhaps I should rephrase... aren't /all/ the logged refs under "refs/" these days?

Andy

Andy Parkins <andyparkins@gmail.com> writes:

Yes, so what. It's not a big deal, and it's too late to change, isn't it?

Seriously, I think with addition of 'git log --walk-reflogs' and 'git show-branch --reflog', there is less reason for an end user to look at the raw .git/logs/ directory these days. They might not fully expose the information recorded in reflog yet, but I think what they do show is useful and adequate. If some useful information is lacking from their output, we should solve that by enhancing them, not by moving .git/logs/refs up one level to save the end user five keystrokes to allow him to run less head or tail on ".git/logs/heads/master".

And we might want to allow reflogs on detached HEAD someday, although I personally think it goes against what detached HEAD is -- it is of a very temporary nature.

Hi,

On Tue, 23 Jan 2007, Junio C Hamano wrote:

How about introducing the shortcut "-g" for "--walk-reflogs"? It is not yet taken AFAICT.

But so are reflogs. They go away after some time.

Disk space is cheap.

Ciao, Dscho

On Tue, 23 Jan 2007, Junio C Hamano wrote:

Didn't we agree already that reflog with detached head was simply insane?

Nicolas

Hi,

On Tue, 23 Jan 2007, Nicolas Pitre wrote:

Maybe you did. I did not agree on that.

Also I have yet to see a valid reason against tracking HEAD.

(Yes, it is better to think about that first, be restrictive, and if it turns out to make sense, allow that -- rather than allow it, decide that it does not make sense, and then forbid it.)

Ciao, Dscho

Nicolas Pitre <nico@cam.org> writes:

Perhaps, perhaps not.

	$ git checkout v2.6.14
        $ git checkout v2.6.15
        $ git checkout v2.6.16

Ah, which one did I check-out the last time?

	$ git describe HEAD@{1}

I suspect that we could re-implement "git bisect" without using the special "bisect" branch (we would still be using refs/bisect namespace).

On Tue, 23 Jan 2007, Junio C Hamano wrote:

And what does HEAD@{1} means if not detached?

If there is a reflog for HEAD independently of what branch HEAD is attached to then it could make sense. Meaning that if you're on branch "master" and perform a commit, then both reflogs for "master" and "HEAD" are updated at the same time. If you then checkout branch "next" then only the "HEAD" reflog is updated since no changes to any branch did occur but just HEAD changed.

Then moving around and/or committing with a detached head would just update the "HEAD reflog.

Nicolas

Nicolas Pitre wrote:

I think it would be best to maintain mixed approach. When we are on some branch, the HEAD@{1} would mean <current branch>@{1}. When HEAD is detached (is not symlink or symref), HEAD@{1} means it's latest state. Detaching a head creates reflog, de-detaching deletes it...

[ please CC me when replying, please ]

On Wed, 24 Jan 2007, Jakub Narebski wrote:

Please no. I think this is exactly the absolutely worst thing you could have. Better not have any reflog for detached heads at all.

First, if you're not playing with detached heads then you don't care since it makes no difference.

But if you do use a detached head then having HEAD@{n} suddenly change from one universe to another just because you detached or attached HEAD from/to a branch is insane.

Consider HEAD@{1} when you just detached from a branch? According to your suggestion it would point into the void.

And why wouldn't HEAD@{1} refer back to a detached state right after checking out a branch? According to your suggestion the last detached position is now lost. Worse, it will point to a commit which might have nothing to do with the previous operation I performed with my repository which is IMHO against the spirit of a reflog for "HEAD".

Nicolas

Hi,

On Tue, 23 Jan 2007, Nicolas Pitre wrote:

This would also be my idea. I agree with you that mixing approaches like Jakub proposed is insane.

But given the idea of reflogs ("Where was this yesterday"), I think it would make sense to reflog HEAD -- independent on which branch it happens to refer to.

Warning! It _changes_ the behaviour. As of now, "git log --walk-reflogs HEAD" shows the local view of the _branch_ that HEAD points to _currently_. But I think that the current is difficult to explain to new users, whereas the "jumping HEAD" is not.

Ciao, Dscho

Andy Parkins wrote:

HEAD is not under refs/. Although IIRC we don't reflog HEAD, with detached HEAD we could reflog at least detached state.

The problem is when you delete branch 'foo', and then create branch 'foo/bar'. You can't have both 'foo' and 'foo/bar' reflog.

On Tuesday 2007 January 23 13:12, Jakub Narebski wrote:

Ah; yes of course.  That is a bit of a deal breaker isn't it?

On the other hand, why delete it instantly? Since the reflog is currently deleted by git-branch anyway, couldn't the deletion be delayed until the creation of foo/bar? At least then the deletion only hits if it really has to. In most circumstances foo then foo/bar is fairly unlikely.

Andy

Hi,

On Tue, 23 Jan 2007, Andy Parkins wrote:

You mean, kind of like a waste bin? Where you delete stuff, but come back and whine that you did not meant to delete it after all?

:-))

Ciao, Dscho

On Tuesday 2007 January 23 14:59, Johannes Schindelin wrote:

No, no; I'm whining that the reflog was deleted, not the branch. I think that "ref deleted" is just as valid for logging as anything else, and deleting the log makes it impossible to view that operation.

Given how powerful the reflog is; it doesn't seem unreasonable to want to be able to do

$ git branch -D some-branch $ git show some-branch@{2 days ago}

Andy