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
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 l
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 --re
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
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 rem
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 "d
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
Junio C Hamano writes:
> David Jeske 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 i
David Jeske 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 whi
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 bec
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 expl
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 y
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 tha
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
an
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 ab
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 dange
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
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 connecte
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.
Tha
@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 s
> 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 aut
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 awa
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
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. Ephemera
24 matches
Mail list logo
