On 08/14/2013 07:14 AM, Junio C Hamano wrote:
Sitaram Chamarty sitar...@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,
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
On Wed, Aug 14, 2013 at 2:02 AM, Sitaram Chamarty sitar...@gmail.com wrote:
On 08/14/2013 07:14 AM, Junio C Hamano wrote:
Sitaram Chamarty sitar...@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
On 08/14/2013 12:40 PM, Andres Perera wrote:
On Wed, Aug 14, 2013 at 2:02 AM, Sitaram Chamarty sitar...@gmail.com wrote:
On 08/14/2013 07:14 AM, Junio C Hamano wrote:
Sitaram Chamarty sitar...@gmail.com writes:
# all reflog entries that are not on a branch, tag, or remote
d1 = !gitk
On Wed, Aug 14, 2013 at 4:35 AM, Sitaram Chamarty sitar...@gmail.com wrote:
On 08/14/2013 12:40 PM, Andres Perera wrote:
On Wed, Aug 14, 2013 at 2:02 AM, Sitaram Chamarty sitar...@gmail.com wrote:
On 08/14/2013 07:14 AM, Junio C Hamano wrote:
Sitaram Chamarty sitar...@gmail.com writes:
#
On Mon, Aug 12, 2013 at 3:37 PM, David Jeske dav...@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
On Tue, Aug 13, 2013 at 9:44 PM, David Jeske dav...@gmail.com wrote:
On Aug 12, 2013 11:06 PM, Duy Nguyen pclo...@gmail.com wrote:
On Mon, Aug 12, 2013 at 3:37 PM, David Jeske dav...@gmail.com wrote:
Is there currently any way to say hey, git, show me what commits are
dangling that might be
On Aug 12, 2013 11:06 PM, Duy Nguyen pclo...@gmail.com wrote:
On Mon, Aug 12, 2013 at 3:37 PM, David Jeske dav...@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
Duy Nguyen pclo...@gmail.com writes:
On Mon, Aug 12, 2013 at 3:37 PM, David Jeske dav...@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
David Jeske dav...@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
Junio C Hamano gits...@pobox.com writes:
David Jeske dav...@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.
On 08/13/2013 10:19 PM, Junio C Hamano wrote:
Duy Nguyen pclo...@gmail.com writes:
On Mon, Aug 12, 2013 at 3:37 PM, David Jeske dav...@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
Sitaram Chamarty sitar...@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
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.
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
David Jeske dav...@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
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
@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
On Mon, Aug 12, 2013 at 7:14 PM, David Jeske dav...@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
Duy Nguyen pclo...@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
David Jeske dav...@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..
Duy Nguyen pclo...@gmail.com writes:
On Mon, Aug 12, 2013 at 7:14 PM, David Jeske dav...@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
On Mon, Aug 12, 2013 at 6:23 AM, Duy Nguyen pclo...@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
On Mon, Aug 12, 2013 at 10:24 AM, Junio C Hamano gits...@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
24 matches
Mail list logo
