Re: ephemeral-branches instead of detached-head?
On Wed, Aug 14, 2013 at 4:35 AM, Sitaram Chamarty wrote:
> On 08/14/2013 12:40 PM, Andres Perera wrote:
>> On Wed, Aug 14, 2013 at 2:02 AM, Sitaram Chamarty wrote:
>>> On 08/14/2013 07:14 AM, Junio C Hamano wrote:
Sitaram Chamarty 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 {100..190} > 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 (100)'` | wc
> -bash: /bin/echo: Argument list too long
> 0 0 0
> $ /bin/echo `perl -e 'print "A " x (100)'` | wc
> 1 100 200
>
> 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 :)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ephemeral-branches instead of detached-head?
On 08/14/2013 12:40 PM, Andres Perera wrote:
> On Wed, Aug 14, 2013 at 2:02 AM, Sitaram Chamarty wrote:
>> On 08/14/2013 07:14 AM, Junio C Hamano wrote:
>>> Sitaram Chamarty 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 {100..190} > 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 (100)'` | wc
-bash: /bin/echo: Argument list too long
0 0 0
$ /bin/echo `perl -e 'print "A " x (100)'` | wc
1 100 200
notice that the second one is twice as long in terms of bytes, but it's
not a single argument).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ephemeral-branches instead of detached-head?
On Wed, Aug 14, 2013 at 2:02 AM, Sitaram Chamarty wrote:
> On 08/14/2013 07:14 AM, Junio C Hamano wrote:
>> Sitaram Chamarty 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 {100..190} > 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ephemeral-branches instead of detached-head?
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 {100..190} > 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ephemeral-branches instead of detached-head?
On 08/14/2013 07:14 AM, Junio C Hamano wrote:
> Sitaram Chamarty 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 {100..190} > 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ephemeral-branches instead of detached-head?
Sitaram Chamarty 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ephemeral-branches instead of detached-head?
On 08/13/2013 10:19 PM, Junio C Hamano wrote: > Duy Nguyen writes: > >> On Mon, Aug 12, 2013 at 3:37 PM, David Jeske 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) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ephemeral-branches instead of detached-head?
Duy Nguyen writes: > On Mon, Aug 12, 2013 at 3:37 PM, David Jeske 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". -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ephemeral-branches instead of detached-head?
On Tue, Aug 13, 2013 at 9:44 PM, David Jeske wrote: > On Aug 12, 2013 11:06 PM, "Duy Nguyen" wrote: >> >> On Mon, Aug 12, 2013 at 3:37 PM, David Jeske 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ephemeral-branches instead of detached-head?
On Mon, Aug 12, 2013 at 3:37 PM, David Jeske 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ephemeral-branches instead of detached-head?
On Mon, Aug 12, 2013 at 10:24 AM, Junio C Hamano 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ephemeral-branches instead of detached-head?
On Mon, Aug 12, 2013 at 6:23 AM, Duy Nguyen 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 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 # name this branch -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ephemeral-branches instead of detached-head?
Duy Nguyen writes: > On Mon, Aug 12, 2013 at 7:14 PM, David Jeske 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 xx Switched to branch 'master' -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ephemeral-branches instead of detached-head?
David Jeske 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ephemeral-branches instead of detached-head?
Duy Nguyen 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, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ephemeral-branches instead of detached-head?
On Mon, Aug 12, 2013 at 7:14 PM, David Jeske 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ephemeral-branches instead of detached-head?
@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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ephemeral-branches instead of detached-head?
> 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 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ephemeral-branches instead of detached-head?
David Jeske 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ephemeral-branches instead of detached-head?
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
