Deleting remote branches with git-branch and reflog questions

Deleting remote branches with git-branch and reflog questions

[Andy Parkins]

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
-- 
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com

Re: Deleting remote branches with git-branch and reflog questions

[Andreas Ericsson]

Andy Parkins wrote:
> 
> reflogs
> -------
> 
> Why does the reflog directory .git/logs need to store the refs/ directory?  
> Aren't /all/ the refs under "refs/" these days?
> 

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

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Deleting remote branches with git-branch and reflog questions

[Jakub Narebski]

Andy Parkins wrote:

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

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

> 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.

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

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: Deleting remote branches with git-branch and reflog questions

[Andy Parkins]

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

> > Why does the reflog directory .git/logs need to store the refs/
> > directory? Aren't /all/ the refs under "refs/" these days?
>
> No. HEAD isn't, nor is ORIG_HEAD, and possibly others.

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

-- 
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com

Re: Deleting remote branches with git-branch and reflog questions

[Andy Parkins]

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

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

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

-- 
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com

Re: Deleting remote branches with git-branch and reflog questions

[Johannes Schindelin]

Hi,

On Tue, 23 Jan 2007, Andy Parkins wrote:

> On Tuesday 2007 January 23 13:12, Jakub Narebski wrote:
> 
> > The problem is when you delete branch 'foo', and then create branch
> > 'foo/bar'. You can't have both 'foo' and 'foo/bar' reflog.
> 
> Ah; yes of course.  That is a bit of a deal breaker isn't it?
> 
> On the other hand, why delete it instantly?

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

Re: Deleting remote branches with git-branch and reflog questions

[Andy Parkins]

On Tuesday 2007 January 23 14:59, Johannes Schindelin 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?

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
-- 
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com

Re: Deleting remote branches with git-branch and reflog questions

[Junio C Hamano]

Andy Parkins <andyparkins@gmail.com> writes:

> Aren't /all/ the logged refs under "refs/" these 
> days?

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.

Re: Deleting remote branches with git-branch and reflog questions

[Johannes Schindelin]

Hi,

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

> Andy Parkins <andyparkins@gmail.com> writes:
> 
> > Aren't /all/ the logged refs under "refs/" these 
> > days?
> 
> 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.

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

> 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.

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

Disk space is cheap.

Ciao,
Dscho

Re: Deleting remote branches with git-branch and reflog questions

[Nicolas Pitre]

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

> 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.

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


Nicolas

Re: Deleting remote branches with git-branch and reflog questions

[Johannes Schindelin]

Hi,

On Tue, 23 Jan 2007, Nicolas Pitre wrote:

> On Tue, 23 Jan 2007, Junio C Hamano wrote:
> 
> > 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.
> 
> Didn't we agree already that reflog with detached head was simply 
> insane?

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

Re: Deleting remote branches with git-branch and reflog questions

[Junio C Hamano]

Nicolas Pitre <nico@cam.org> writes:

> On Tue, 23 Jan 2007, Junio C Hamano wrote:
>
>> 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.
>
> Didn't we agree already that reflog with detached head was simply 
> insane?

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).

Re: Deleting remote branches with git-branch and reflog questions

[Nicolas Pitre]

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

> Nicolas Pitre <nico@cam.org> writes:
> 
> > On Tue, 23 Jan 2007, Junio C Hamano wrote:
> >
> >> 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.
> >
> > Didn't we agree already that reflog with detached head was simply 
> > insane?
> 
> 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}

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

Re: Deleting remote branches with git-branch and reflog questions

[Jakub Narebski]

Nicolas Pitre wrote:

> On Tue, 23 Jan 2007, Junio C Hamano wrote:
> 
>> Nicolas Pitre <nico@cam.org> writes:
>> 
>>> On Tue, 23 Jan 2007, Junio C Hamano wrote:
>>>
>>>> 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.
>>>
>>> Didn't we agree already that reflog with detached head was simply 
>>> insane?
>> 
>> 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}
> 
> 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.

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...
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: Deleting remote branches with git-branch and reflog questions

[Nicolas Pitre]

[ please CC me when replying, please ]

On Wed, 24 Jan 2007, Jakub Narebski wrote:

> Nicolas Pitre wrote:
> 
> > On Tue, 23 Jan 2007, Junio C Hamano wrote:
> > 
> >> Nicolas Pitre <nico@cam.org> writes:
> >> 
> >>> On Tue, 23 Jan 2007, Junio C Hamano wrote:
> >>>
> >>>> 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.
> >>>
> >>> Didn't we agree already that reflog with detached head was simply 
> >>> insane?
> >> 
> >> 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}
> > 
> > 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.
> 
> 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 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

Re: Deleting remote branches with git-branch and reflog questions

[Johannes Schindelin]

Hi,

On Tue, 23 Jan 2007, Nicolas Pitre wrote:

> On Tue, 23 Jan 2007, Junio C Hamano wrote:
> 
> > Nicolas Pitre <nico@cam.org> writes:
> > 
> > > On Tue, 23 Jan 2007, Junio C Hamano wrote:
> > >
> > >> 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.
> > >
> > > Didn't we agree already that reflog with detached head was simply 
> > > insane?
> > 
> > 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}
> 
> 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.

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