ephemeral-branches instead of detached-head?

ephemeral-branches instead of detached-head?

[David Jeske]

Has there ever been any any discussion of creating an ephemeral-branch
name mechanism, instead of using detached HEADs?

By ephemeral, I mean that a branch-name could be created which would
live only so long as it is the only named way to reach a ref or the
ref is in the working directory. Ephemeral branch names would be
local-only and would never be pushed.

For example, if one performed "git checkout 2c29d...", one would not
get a detached head-state, but instead would get an ephemeral branch
name similar to "etmp/2c29d...". If no changes were checked into this
ephemeral branch, it would disappear as soon as it was no longer in
the working directory. If any changes were checked in on this branch,
it would survive until (a) the ref is given a non-ephemeral branch
name, (b) the changes are merged, (c) the ephemeral branch is
deleted/discarded.

I'm asking about (and proposing) this mechanism, because it would
prevent refs from ever being "accidentally lost", such as occurs in
the following scenerios..

1) forgetting to branch a detached head before checkin
2) forgetting a head is detached before moving away from it
3) forgetting about checkins before a submodule update

Also, these "etmp/####" branches would serve as an obvious visible
reminder in the branch list that a change was checked in that should
either be merged, named, or discarded.

Re: ephemeral-branches instead of detached-head?

[Jonathan Nieder]

David Jeske wrote:

>                                  Ephemeral branch names would be
> local-only and would never be pushed.

That's how normal branch names behave (local branch names and remote
branch names live in different namespaces).  How would the proposed
detached HEAD replacement compare to them?  Would the temporary branch
created by checking out a random commit be automatically deleted when
checking out another branch, or would it be garbage-collected at some
point later?

Curious,
Jonathan

Re: ephemeral-branches instead of detached-head?

[Junio C Hamano]

David Jeske <davidj@gmail.com> writes:

> I'm asking about (and proposing) this mechanism, because it would
> prevent refs from ever being "accidentally lost", such as occurs in
> the following scenerios..
>
> 1) forgetting to branch a detached head before checkin
> 2) forgetting a head is detached before moving away from it
> 3) forgetting about checkins before a submodule update

As Jonathan mentioned, your local branch namespace _is_ ephemeral in
the larger picture, and you can and should use your regular branches
as such.

I do not think any of the above will be helped by truly epheral
branch that are not consciously named by the end user.

(1) is not a problem at all by itself with detached HEAD.  You can
commit all you want, and the true problem people perceive that comes
from (1) is (2), as they think they would lose commit that way.  But
the thing is, the commits are not lost---they are recoverable from
the reflog of the HEAD itself.  A truely ephemeral branch that users
do not consciously name would be referred to some random string
(your etmp/4324 below) that is just as discoverable as an entry in
the reflog of the HEAD, so you didn't solve any problem here.

I am not sure what you are trying to improve with (3) but I suspect
it is just the same issue between (1) and (2) in the submodule
working tree.  After running a submodule update in the superproject,
you will get into the detached HEAD state in the submodule, and that
state by itself is not a problem at all, but after committing and
then switching to other branch (or to another commit), the history
leading to the tip commit will not be at the tip of any meaningfully
named branch.  That is different from a commit getting lost, and I
do not see how ephemerally created branches with random names would
help people discover these commits better compared to reflog for the
HEAD.

> Also, these "etmp/####" branches would serve as an obvious visible
> reminder in the branch list that a change was checked in that should
> either be merged, named, or discarded.

Re: ephemeral-branches instead of detached-head?

[David Jeske]

> Would the temporary branch created by checking out a random commit be automatically deleted when checking out another branch, or would it be garbage-collected at some
> point later?


Yes, as I stated in my example, the ephemeral branch created from
checking out a random commit would be automatically deleted anytime
there was another downstream name for the ref (and the ref was no
longer in the working-directory). Another way to think of the proposal
is to allowed detached-HEADs, but automatically create ephemeral
branch-names when checking into a detached head.

On Mon, Aug 12, 2013 at 12:55 AM, Junio C Hamano <gitster@pobox.com> wrote:
> As Jonathan mentioned, your local branch namespace _is_ ephemeral in
> the larger picture, and you can and should use your regular branches
> as such.

This is not the case. To me "ephemeral" means that the branch name
automatically disappears if nothing gets checked into it. The local
branch names definitely do not operate this way.

> (1) is not a problem at all by itself with detached HEAD.  You can
> commit all you want, and the true problem people perceive that comes
> from (1) is (2), as they think they would lose commit that way.

It is not a matter of a commit being destroyed, as I know they are not
destroyed, it is a matter of "losing" as in it being a
pain-in-the-a-s-s to find the darn thing.

The reflog is only really useful for a short time. If you don't notice
until later, it's too late for this to be a reasonable way to find the
missing commit.. and this assumes you noticed at all.

For as long as I've used git, I simplu don't understand why I should
be able to commit something, and have it go "missing" in the branch
namespace without an explicit action on my part.

> A truely ephemeral branch that users do not consciously name would be referred to some random string (your etmp/4324 below) that is just as discoverable as an entry in
> the reflog of the HEAD, so you didn't solve any problem here.

This is simply not true.

The reflog is filled with every reflog action. Any checkout, push,
pull, existing commits, etc. The ephemeral space would *only* contain
dangling refs that were not named, merged, or discarded.

> ...the history leading to the tip commit will not be at the tip of any meaningfully
>
> named branch.  That is different from a commit getting lost, and I
> do not see how ephemerally created branches with random names would
> help people discover these commits better compared to reflog for the
> HEAD.

Is there currently any way to say "hey, git, show me what commits are
dangling that might be lost in the reflog?"

I'm not aware of one. This is the difference. It's making the action
of throwing away a dangling ref more explicit.

Re: ephemeral-branches instead of detached-head?

[David Jeske]

@Junio - to put the issue in the context of your previous comments on
the topic... way back when you made a comment about warnings during
commits to detached heads..

http://git.661346.n2.nabble.com/RFC-Detached-HEAD-reminder-on-commit-td834710.html#a834959

> If we _really_ don't want newbies to shoot themselves in the foot, we
> probably can issue a loud warning when they detach there HEAD.
> Oh, wait,... we already do that.


The reason this rationale doesn't ring true for me, is that it is
*very* common for me to checkout a detached-head and there is nothing
odd or dangerous about it. I do this when using checkout to move
around the history to inspect, build, and test different revisions. As
a result, it's very easy to just start ignoring this (usually
meaningless) message.

The dangerous situation only occurs when something is committed onto a
detached-head, and at this point there is no warning. The "# Not
currently on any branch" message that appears during "git status"
easily blends in with boilerplate text there.

IMO, the current warning during checkout of a detached-head is
misplaced. It should be removed, and instead there should only be a
warning after detached-head commit, since this is the only time there
is a danger of losing something.

With my proposed "ephemeral branch" concept, there is no warning
necessary in either case, since any check-ins left dangling would get
names in the branch space you could see and take a look at. If that
dangling head was temporary and was named or rebased, the ephemeral
branch name would disappear automatically, leaving the expert-user
with no warnings and no annoyance, while the novice user with a simple
tool to help them not lose track of changes they made.

Re: ephemeral-branches instead of detached-head?

[Duy Nguyen]

On Mon, Aug 12, 2013 at 7:14 PM, David Jeske <davidj@gmail.com> wrote:
> IMO, the current warning during checkout of a detached-head is
> misplaced. It should be removed, and instead there should only be a
> warning after detached-head commit, since this is the only time there
> is a danger of losing something.

That would annoy me as I often work on top of detached HEAD on purpose
and only create a branch when I want to save something. If the warning
is to be moved, it should warn at the next checkout.
-- 
Duy

Re: ephemeral-branches instead of detached-head?

[Andreas Schwab]

Duy Nguyen <pclouds@gmail.com> writes:

> That would annoy me as I often work on top of detached HEAD on purpose
> and only create a branch when I want to save something. If the warning
> is to be moved, it should warn at the next checkout.

$ git checkout master
Warning: you are leaving 1 commit behind, not connected to
any of your branches:

  0e3618e a

Switched to branch 'master'

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: ephemeral-branches instead of detached-head?

[Junio C Hamano]

David Jeske <davidj@gmail.com> writes:

> @Junio - to put the issue in the context of your previous comments on
> the topic... way back when you made a comment about warnings during
> commits to detached heads..
>
> http://git.661346.n2.nabble.com/RFC-Detached-HEAD-reminder-on-commit-td834710.html#a834959
>
>> If we _really_ don't want newbies to shoot themselves in the foot, we
>> probably can issue a loud warning when they detach there HEAD.
>> Oh, wait,... we already do that.
>
> The reason this rationale doesn't ring true for me, is that it is
> *very* common for me to checkout a detached-head and there is nothing
> odd or dangerous about it.

You do not have to say that to me _now_ ;-) because after makinng
the above ancient comment others have corrected me, I agreed with
them, and we no longer rely on that "you are detaching, danger
ahead" warning.

With the same line of reasoning, the place where users make commits
on detached HEAD is not where the danger arises, either; the real
danger is where you switch out of the detached HEAD state, and I
think we do give a loud warning there.

Re: ephemeral-branches instead of detached-head?

[Junio C Hamano]

Duy Nguyen <pclouds@gmail.com> writes:

> On Mon, Aug 12, 2013 at 7:14 PM, David Jeske <davidj@gmail.com> wrote:
>> IMO, the current warning during checkout of a detached-head is
>> misplaced. It should be removed, and instead there should only be a
>> warning after detached-head commit, since this is the only time there
>> is a danger of losing something.
>
> That would annoy me as I often work on top of detached HEAD on purpose
> and only create a branch when I want to save something. If the warning
> is to be moved, it should warn at the next checkout.

Don't we already do that?

    Warning: you are leaving N commits behind, not connected to
    any of your branches:

        ... list of commits to be lost ...


    If you want to keep them by creating a new branch, this may be a
    good time
    to do so with:

     git branch new_branch_name xxxxxx

    Switched to branch 'master'

Re: ephemeral-branches instead of detached-head?

[David Jeske]

On Mon, Aug 12, 2013 at 6:23 AM, Duy Nguyen <pclouds@gmail.com> wrote:
> That would annoy me as I often work on top of detached HEAD on purpose
> and only create a branch when I want to save something. If the warning
> is to be moved, it should warn at the next checkout.

Yes, you're absolutely right ...

My point about the current checkout warning is that it's crying wolf,
and nullifying the value of the warning. Most of the time I checkout a
ref, I'm not doing anything dangerous because I'm not going to check
anything in. The warning would be more effective if it warns in as
narrow a situation as possible. You're correct that the clobber is
even more narrow than the checkin.

The warning on clobber would be similar to (but shorter than) the one
which could be removed from checkout..

Clobbered detached HEAD 'cce40d6'!

   git log cce40d6 ^master      # log detached changes vs master
   git branch <name> cc340d6    # name the changes with a branch

Personally, I'd prefer for explicit action to discard a detached head.
It's true that this is an explicit step, but for me it generally takes
a heck of alot less time to explicitly discard than it did to checkout
the detached head, make changes (or apply a patch), and then decide to
throw them away.

My "ephemeral branch" idea was a way to make this explicit discard as
passive and lazy as possible. Basically, never stop you from doing
your work, assume you know what you are doing. If the user
names-the-branch it disappears. If the user merges or rebases the
detached head, it disappears. The only time the "ephemeral branch"
would survive is if the user really clobbered a detached head and then
didn't do anything about it. Even if they missed the warning (in the
middle of a script or automated process), eventually they would see
the ephemeral branch lying around.

Clobbering a detached head with "ephemeral branches" could show no
warning at all, or a warning like:

Clobbered detached HEAD.

   git log cce40d6 ^master           # log detached changes vs master
   git branch -D tmp/cce40d6         # Discard these changes
   git branch tmp/cce40d6 <newname>  # name this branch

Re: ephemeral-branches instead of detached-head?

[David Jeske]

On Mon, Aug 12, 2013 at 10:24 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Don't we already do that?
>
>     Warning: you are leaving N commits behind, not connected to
>     any of your branches:
>
>         ... list of commits to be lost ...

This only shows on checkout... not reset, not submodule-update, nor
any other ways you can clobber a detached head.

Re: ephemeral-branches instead of detached-head?

[Duy Nguyen]

On Mon, Aug 12, 2013 at 3:37 PM, David Jeske <davidj@gmail.com> wrote:
> Is there currently any way to say "hey, git, show me what commits are
> dangling that might be lost in the reflog?"

How do you define dangling commits? When you do "git commit --amend",
the current commit will become dangling (in the sense that it's not
referred by any ref, but the commit exists) and those are just noise
in my opinion.
-- 
Duy

Re: ephemeral-branches instead of detached-head?

[Duy Nguyen]

On Tue, Aug 13, 2013 at 9:44 PM, David Jeske <davidj@gmail.com> wrote:
> On Aug 12, 2013 11:06 PM, "Duy Nguyen" <pclouds@gmail.com> wrote:
>>
>> On Mon, Aug 12, 2013 at 3:37 PM, David Jeske <davidj@gmail.com> wrote:
>> > Is there currently any way to say "hey, git, show me what commits are
>> > dangling that might be lost in the reflog?"
>>
>> How do you define dangling commits?
>
> Any commit which I did not explicitly do something with. (Merge, rebase,
> amend, branch name, discard)
>
> Today every one of those actions is explicit except discard.

So basically everything that is (1) produced by "git commit", (2) not
connected to any ref and (3) not an amend. I think (1) and (3) can be
achieved with "git log -g --grep-reflog commit: HEAD". We only need to
filter out ones that are connected to some ref. Not sure if that can
be done with script though. Maybe add "--dangling" to "git log -g" to
do such filtering?
-- 
Duy

Fwd: ephemeral-branches instead of detached-head?

[David Jeske]

On Aug 12, 2013 11:06 PM, "Duy Nguyen" <pclouds@gmail.com> wrote:

>
> On Mon, Aug 12, 2013 at 3:37 PM, David Jeske <davidj@gmail.com> wrote:
> > Is there currently any way to say "hey, git, show me what commits are
> > dangling that might be lost in the reflog?"
>
> How do you define dangling commits?

Any commit which I did not explicitly do something with. (Merge,
rebase, amend, branch name, discard)

Today every one of those actions is explicit except discard.

> When you do "git commit --amend",
> the current commit will become dangling (in the sense that it's not
> referred by any ref, but the commit exists) and those are just noise
> in my opinion.

This is *exactly* my point.

There is no way to distinguish a commit which was accidentally and
implicitly dangled due to checkout or submodule update on a detached
head, from all those other intentionally dangling refs which were
explicitly handled with merge, rebase, amend.

Ephemeral branches would change only the implicit discard.. Turning it
into a named branch and requiring an explicit discard.

Re: ephemeral-branches instead of detached-head?

[Junio C Hamano]

Duy Nguyen <pclouds@gmail.com> writes:

> On Mon, Aug 12, 2013 at 3:37 PM, David Jeske <davidj@gmail.com> wrote:
>> Is there currently any way to say "hey, git, show me what commits are
>> dangling that might be lost in the reflog?"
>
> How do you define dangling commits? When you do "git commit --amend",
> the current commit will become dangling (in the sense that it's not
> referred by any ref, but the commit exists) and those are just noise
> in my opinion.

"fsck lost-and-found" would be one way.  It would be nice if we had
something like (note: the following will _NOT_ work)

	git log -g HEAD --not --branches

to say "walk the reflog of HEAD, but exclude anything that can be
reached from the tips of branches".

Re: Fwd: ephemeral-branches instead of detached-head?

[Junio C Hamano]

David Jeske <davidj@gmail.com> writes:

>> When you do "git commit --amend",
>> the current commit will become dangling (in the sense that it's not
>> referred by any ref, but the commit exists) and those are just noise
>> in my opinion.
>
> This is *exactly* my point.
>
> There is no way to distinguish a commit which was accidentally and
> implicitly dangled due to checkout or submodule update on a detached
> head, from all those other intentionally dangling refs which were
> explicitly handled with merge, rebase, amend.

I do not follow.  Just like "commit --amend", checking out another
branch to leave a detached HEAD _is_ an explicit way to discard what
you started experimenting behind, declaring it useless.  Otherwise
you would have saved it to some named branch.

This of course assumes that, as you said in one of your earlier
messages, the user knows what he is doing, though.

Re: Fwd: ephemeral-branches instead of detached-head?

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> David Jeske <davidj@gmail.com> writes:
>
>>> When you do "git commit --amend",
>>> the current commit will become dangling (in the sense that it's not
>>> referred by any ref, but the commit exists) and those are just noise
>>> in my opinion.
>>
>> This is *exactly* my point.
>>
>> There is no way to distinguish a commit which was accidentally and
>> implicitly dangled due to checkout or submodule update on a detached
>> head, from all those other intentionally dangling refs which were
>> explicitly handled with merge, rebase, amend.
>
> I do not follow.  Just like "commit --amend", checking out another
> branch to leave a detached HEAD _is_ an explicit way to discard what
> you started experimenting behind, declaring it useless.  Otherwise
> you would have saved it to some named branch.
>
> This of course assumes that, as you said in one of your earlier
> messages, the user knows what he is doing, though.

By the way, by the above I do not mean "checking out a named branch
should not be protected".  I am saying "treating commits lost by
running 'commit --amend' differently does not make sense to me".

Re: ephemeral-branches instead of detached-head?

[Sitaram Chamarty]

On 08/13/2013 10:19 PM, Junio C Hamano wrote:
> Duy Nguyen <pclouds@gmail.com> writes:
> 
>> On Mon, Aug 12, 2013 at 3:37 PM, David Jeske <davidj@gmail.com> wrote:
>>> Is there currently any way to say "hey, git, show me what commits are
>>> dangling that might be lost in the reflog?"
>>
>> How do you define dangling commits? When you do "git commit --amend",
>> the current commit will become dangling (in the sense that it's not
>> referred by any ref, but the commit exists) and those are just noise
>> in my opinion.
> 
> "fsck lost-and-found" would be one way.  It would be nice if we had
> something like (note: the following will _NOT_ work)
> 
> 	git log -g HEAD --not --branches
> 
> to say "walk the reflog of HEAD, but exclude anything that can be
> reached from the tips of branches".

I've been using the following 3 aliases for some time now, to find
various dangling stuff.  The middle one (d1) seems to do approximately
what you want, but will probably fail on repos with lots of activity
when the command line length limit is (b)reached.

    # all stashed entries (since they don't chain)
    sk = !gitk --date-order $(git stash list | cut -d: -f1) --not --branches --tags --remotes
    # all reflog entries that are not on a branch, tag, or remote
    d1 = !gitk --date-order $(git log -g --pretty=%H) --not --branches --tags --remotes
    # all dangling commits not on a branch, tag, or remote
    d2 = !gitk --date-order $(git fsck | grep "dangling.commit" | cut -f3 -d' ') --not --branches --tags --remotes

(Apologies if something like this was already said; I was not following
the discussion closely enough to notice)

Re: ephemeral-branches instead of detached-head?

[Junio C Hamano]

Sitaram Chamarty <sitaramc@gmail.com> writes:

>     # all reflog entries that are not on a branch, tag, or remote
>     d1 = !gitk --date-order $(git log -g --pretty=%H) --not --branches --tags --remotes
>     # all dangling commits not on a branch, tag, or remote
>     d2 = !gitk --date-order $(git fsck | grep "dangling.commit" | cut -f3 -d' ') --not --branches --tags --remotes
>
> (Apologies if something like this was already said; I was not following
> the discussion closely enough to notice)

Yup.

A potential problem is that the output from "log -g --pretty=%H" or
"fsck | grep dangling" may turn out to be humongous.  Other than
that, they correctly compute what you want.

Re: ephemeral-branches instead of detached-head?

[Sitaram Chamarty]

On 08/14/2013 07:14 AM, Junio C Hamano wrote:
> Sitaram Chamarty <sitaramc@gmail.com> writes:
> 
>>     # all reflog entries that are not on a branch, tag, or remote
>>     d1 = !gitk --date-order $(git log -g --pretty=%H) --not --branches --tags --remotes
>>     # all dangling commits not on a branch, tag, or remote
>>     d2 = !gitk --date-order $(git fsck | grep "dangling.commit" | cut -f3 -d' ') --not --branches --tags --remotes
>>
>> (Apologies if something like this was already said; I was not following
>> the discussion closely enough to notice)
> 
> Yup.
> 
> A potential problem is that the output from "log -g --pretty=%H" or
> "fsck | grep dangling" may turn out to be humongous.  Other than
> that, they correctly compute what you want.

I thought I mentioned that but I can't find my email now so maybe I
didn't.

In practice though, I find that, bash at least seems happy to take
command lines as long as 7+ million characters long, so with the default
reflog expire times, that should work out to 10,000 commits *per day*.
[Tested with: echo {1000000..1900000}  > junk; echo `cat junk` | wc]

Incidentally, am I the only one who thinks the default values for
gc.reflogexpire (90 days) and gc.reflogexpireunreachable (30) should be
reversed?

In terms of recovering potentially lost commits at least, it seems it
would make more sense that something that is UNreachable have a longer
expiry, whereas stuff that's reachable... that's only a quick "gitk"
browse away.

Design question: is the primary purpose of the reflog "what was I doing
X days ago" or is it "I need some code from a commit that got rebased
out [or whatever] X days ago"?

I have always only used the reflog for the latter.

Re: ephemeral-branches instead of detached-head?

[Jeff King]

On Wed, Aug 14, 2013 at 12:02:24PM +0530, Sitaram Chamarty wrote:

> >>     # all reflog entries that are not on a branch, tag, or remote
> >>     d1 = !gitk --date-order $(git log -g --pretty=%H) --not --branches --tags --remotes
> [...]
>
> > A potential problem is that the output from "log -g --pretty=%H" or
> > "fsck | grep dangling" may turn out to be humongous.  Other than
> > that, they correctly compute what you want.
> 
> I thought I mentioned that but I can't find my email now so maybe I
> didn't.
> 
> In practice though, I find that, bash at least seems happy to take
> command lines as long as 7+ million characters long, so with the default
> reflog expire times, that should work out to 10,000 commits *per day*.
> [Tested with: echo {1000000..1900000}  > junk; echo `cat junk` | wc]

You can also do:

  git log -g --pretty=%H |
  git log --stdin --not --branches --tags --remotes

to avoid any argv limitations.

-Peff

Re: ephemeral-branches instead of detached-head?

[Andres Perera]

On Wed, Aug 14, 2013 at 2:02 AM, Sitaram Chamarty <sitaramc@gmail.com> wrote:
> On 08/14/2013 07:14 AM, Junio C Hamano wrote:
>> Sitaram Chamarty <sitaramc@gmail.com> writes:
>>
>>>     # all reflog entries that are not on a branch, tag, or remote
>>>     d1 = !gitk --date-order $(git log -g --pretty=%H) --not --branches --tags --remotes
>>>     # all dangling commits not on a branch, tag, or remote
>>>     d2 = !gitk --date-order $(git fsck | grep "dangling.commit" | cut -f3 -d' ') --not --branches --tags --remotes
>>>
>>> (Apologies if something like this was already said; I was not following
>>> the discussion closely enough to notice)
>>
>> Yup.
>>
>> A potential problem is that the output from "log -g --pretty=%H" or
>> "fsck | grep dangling" may turn out to be humongous.  Other than
>> that, they correctly compute what you want.
>
> I thought I mentioned that but I can't find my email now so maybe I
> didn't.
>
> In practice though, I find that, bash at least seems happy to take
> command lines as long as 7+ million characters long, so with the default
> reflog expire times, that should work out to 10,000 commits *per day*.
> [Tested with: echo {1000000..1900000}  > junk; echo `cat junk` | wc]

echo is a builtin in bash, as is the case with other shell implementations

builtins may have different limit's than exec()'s ARG_MAX

$ getconf ARG_MAX
262144
$ perl -e 'print "A" x (262144 * 2)' | wc -c
  524288
$ perl -e 'print "A" x (262144 * 2)' | sh -c 'read v; echo "$v"' | wc -c
  524289
$ perl -e 'print "A" x (262144 * 2)' | sh -c 'read v; /bin/echo "$v"' | wc -c
sh: /bin/echo: Argument list too long
       0

builtin's argument buffer limit tends to be aligned with the
implementation's lexer buffer limit

Re: ephemeral-branches instead of detached-head?

[Sitaram Chamarty]

On 08/14/2013 12:40 PM, Andres Perera wrote:
> On Wed, Aug 14, 2013 at 2:02 AM, Sitaram Chamarty <sitaramc@gmail.com> wrote:
>> On 08/14/2013 07:14 AM, Junio C Hamano wrote:
>>> Sitaram Chamarty <sitaramc@gmail.com> writes:
>>>
>>>>     # all reflog entries that are not on a branch, tag, or remote
>>>>     d1 = !gitk --date-order $(git log -g --pretty=%H) --not --branches --tags --remotes
>>>>     # all dangling commits not on a branch, tag, or remote
>>>>     d2 = !gitk --date-order $(git fsck | grep "dangling.commit" | cut -f3 -d' ') --not --branches --tags --remotes
>>>>
>>>> (Apologies if something like this was already said; I was not following
>>>> the discussion closely enough to notice)
>>>
>>> Yup.
>>>
>>> A potential problem is that the output from "log -g --pretty=%H" or
>>> "fsck | grep dangling" may turn out to be humongous.  Other than
>>> that, they correctly compute what you want.
>>
>> I thought I mentioned that but I can't find my email now so maybe I
>> didn't.
>>
>> In practice though, I find that, bash at least seems happy to take
>> command lines as long as 7+ million characters long, so with the default
>> reflog expire times, that should work out to 10,000 commits *per day*.
>> [Tested with: echo {1000000..1900000}  > junk; echo `cat junk` | wc]
> 
> echo is a builtin in bash, as is the case with other shell implementations
> 
> builtins may have different limit's than exec()'s ARG_MAX
> 
> $ getconf ARG_MAX
> 262144
> $ perl -e 'print "A" x (262144 * 2)' | wc -c
>   524288
> $ perl -e 'print "A" x (262144 * 2)' | sh -c 'read v; echo "$v"' | wc -c
>   524289
> $ perl -e 'print "A" x (262144 * 2)' | sh -c 'read v; /bin/echo "$v"' | wc -c
> sh: /bin/echo: Argument list too long
>        0
> 
> builtin's argument buffer limit tends to be aligned with the
> implementation's lexer buffer limit

Aah; good catch -- I did not know this.  Thanks!

My systems show 2621440 on CentOS 6 and 2097152 on Fedora 19, so --
dividing by 8 (abbrev SHA + space) then by 90, that's still 2900 commits
*per day* to run past this limit though!

(side note: making a single argument that long seems to have a much
lower limit than having multiple arguments:

    $ /bin/echo `perl -e 'print "A" x (1000000)'` | wc
    -bash: /bin/echo: Argument list too long
          0       0       0
    $ /bin/echo `perl -e 'print "A " x (1000000)'` | wc
          1 1000000 2000000

notice that the second one is twice as long in terms of bytes, but it's
not a single argument).

Re: ephemeral-branches instead of detached-head?

[Andres Perera]

On Wed, Aug 14, 2013 at 4:35 AM, Sitaram Chamarty <sitaramc@gmail.com> wrote:
> On 08/14/2013 12:40 PM, Andres Perera wrote:
>> On Wed, Aug 14, 2013 at 2:02 AM, Sitaram Chamarty <sitaramc@gmail.com> wrote:
>>> On 08/14/2013 07:14 AM, Junio C Hamano wrote:
>>>> Sitaram Chamarty <sitaramc@gmail.com> writes:
>>>>
>>>>>     # all reflog entries that are not on a branch, tag, or remote
>>>>>     d1 = !gitk --date-order $(git log -g --pretty=%H) --not --branches --tags --remotes
>>>>>     # all dangling commits not on a branch, tag, or remote
>>>>>     d2 = !gitk --date-order $(git fsck | grep "dangling.commit" | cut -f3 -d' ') --not --branches --tags --remotes
>>>>>
>>>>> (Apologies if something like this was already said; I was not following
>>>>> the discussion closely enough to notice)
>>>>
>>>> Yup.
>>>>
>>>> A potential problem is that the output from "log -g --pretty=%H" or
>>>> "fsck | grep dangling" may turn out to be humongous.  Other than
>>>> that, they correctly compute what you want.
>>>
>>> I thought I mentioned that but I can't find my email now so maybe I
>>> didn't.
>>>
>>> In practice though, I find that, bash at least seems happy to take
>>> command lines as long as 7+ million characters long, so with the default
>>> reflog expire times, that should work out to 10,000 commits *per day*.
>>> [Tested with: echo {1000000..1900000}  > junk; echo `cat junk` | wc]
>>
>> echo is a builtin in bash, as is the case with other shell implementations
>>
>> builtins may have different limit's than exec()'s ARG_MAX
>>
>> $ getconf ARG_MAX
>> 262144
>> $ perl -e 'print "A" x (262144 * 2)' | wc -c
>>   524288
>> $ perl -e 'print "A" x (262144 * 2)' | sh -c 'read v; echo "$v"' | wc -c
>>   524289
>> $ perl -e 'print "A" x (262144 * 2)' | sh -c 'read v; /bin/echo "$v"' | wc -c
>> sh: /bin/echo: Argument list too long
>>        0
>>
>> builtin's argument buffer limit tends to be aligned with the
>> implementation's lexer buffer limit
>
> Aah; good catch -- I did not know this.  Thanks!
>
> My systems show 2621440 on CentOS 6 and 2097152 on Fedora 19, so --
> dividing by 8 (abbrev SHA + space) then by 90, that's still 2900 commits
> *per day* to run past this limit though!

ARG_MAX may also include the process environment, which needs to be
copied over to the new vm

the limit may also include the argv pointer sizes

those calculations based on SHA string length are just approximates

>
> (side note: making a single argument that long seems to have a much
> lower limit than having multiple arguments:
>
>     $ /bin/echo `perl -e 'print "A" x (1000000)'` | wc
>     -bash: /bin/echo: Argument list too long
>           0       0       0
>     $ /bin/echo `perl -e 'print "A " x (1000000)'` | wc
>           1 1000000 2000000
>
> notice that the second one is twice as long in terms of bytes, but it's
> not a single argument).

the behaviour is different in OpenBSD-amd64:

perl -e 'print "A " x ((262144/2)-5)' | env -i sh -c 'unset PATH; read
v; /bin/echo $v' | wc -c

a bigger size and i get E2BIG. if i pass the env or let PATH get
exported, again, i need to reduce the multiplier

apparently Linux is doing copyin() for each argument. that seems
excessive to me :)