From: Nick Quaranto <hidden> Date: 2016-06-15 22:46:07
I started this blog just around a month ago on a quest to learn more about
git on a daily basis and to show others how awesome it is. If you have any
suggestions on what content to cover or how things should be done
differently, I would greatly appreciate it. Thanks!
http://gitready.com
--
View this message in context: http://n2.nabble.com/git-ready%3A-daily-git-tips-tp2294642p2294642.html
Sent from the git mailing list archive at Nabble.com.
From: Steven Noonan <hidden> Date: 2016-06-15 22:46:07
On Sun, Feb 8, 2009 at 2:18 PM, Nick Quaranto [off-list ref] wrote:
I started this blog just around a month ago on a quest to learn more about
git on a daily basis and to show others how awesome it is. If you have any
suggestions on what content to cover or how things should be done
differently, I would greatly appreciate it. Thanks!
http://gitready.com
Heh, I've already got this in my RSS reader. It's got some pretty
awesome tips. I've learned more about git on there than pretty much
any other resource.
Keep up the good work. :)
- Steven
From: Nicolas Pitre <hidden> Date: 2016-06-15 22:46:08
On Sun, 8 Feb 2009, Nick Quaranto wrote:
I started this blog just around a month ago on a quest to learn more about
git on a daily basis and to show others how awesome it is. If you have any
suggestions on what content to cover or how things should be done
differently, I would greatly appreciate it. Thanks!
http://gitready.com
Well done.
One topic that IMHO you fail to cover, and which is being neglected
almost everywhere else too, is the reflog.
The reflog is really your safety net when working with git. It records
everything you do. So even if you screw up a rebase, perform the wrong
merge, or any other kind of undesired operation, then you may always go
back to a previous state. Either you use -g with 'git log' to see all
those recorded states, or even 'git reflog' without any argument to get
a condensed list for HEAD.
The <branch>@{<spec>} notation can be used anywhere a ref is normally
required. The special branch "HEAD" shows every state the HEAD pointer
went through, including branch switches. The <branch< part can be left
out to mean "currently checked-out branch".
One thing that I use all the time after a 'git pull' is 'git log @{1}..'
where "@{1}" means the first previous tip of the current branch, so
effectively showing me the log of what the pull brought in my branch.
Nicolas
Well done.
One topic that IMHO you fail to cover, and which is being neglected
almost everywhere else too, is the reflog.
The reflog is really your safety net when working with git. It records
everything you do. So even if you screw up a rebase, perform the wrong
merge, or any other kind of undesired operation, then you may always go
back to a previous state. Either you use -g with 'git log' to see all
those recorded states, or even 'git reflog' without any argument to get
a condensed list for HEAD.
The <branch>@{<spec>} notation can be used anywhere a ref is normally
required. The special branch "HEAD" shows every state the HEAD pointer
went through, including branch switches. The <branch< part can be left
out to mean "currently checked-out branch".
One thing that I use all the time after a 'git pull' is 'git log @{1}..'
where "@{1}" means the first previous tip of the current branch, so
effectively showing me the log of what the pull brought in my branch.
Also, the @{now} notation to get a relative timestamp of the
reflog is invaluable. Seeing reflog lines annotated with
'14 minutes ago' or '17 hours ago' or perhaps '4 days ago',
really helps to focus on the commits you're looking for:
git reflog show @{now}
# (the 'show' is not optional in this syntax)
Well done.
One topic that IMHO you fail to cover, and which is being neglected
almost everywhere else too, is the reflog.
The reflog is really your safety net when working with git. It records
everything you do. So even if you screw up a rebase, perform the wrong
merge, or any other kind of undesired operation, then you may always go
back to a previous state. Either you use -g with 'git log' to see all
those recorded states, or even 'git reflog' without any argument to get
a condensed list for HEAD.
The <branch>@{<spec>} notation can be used anywhere a ref is normally
required. The special branch "HEAD" shows every state the HEAD pointer
went through, including branch switches. The <branch< part can be left
out to mean "currently checked-out branch".
One thing that I use all the time after a 'git pull' is 'git log @{1}..'
where "@{1}" means the first previous tip of the current branch, so
effectively showing me the log of what the pull brought in my branch.
Also, the @{now} notation to get a relative timestamp of the
reflog is invaluable. Seeing reflog lines annotated with
'14 minutes ago' or '17 hours ago' or perhaps '4 days ago',
really helps to focus on the commits you're looking for:
git reflog show @{now}
# (the 'show' is not optional in this syntax)
Yes, I often use "git log -g --date=relative" to get a better
understanding of my recent actions in that particular repository.
Also do not forget to advertise the new @{-<n>} notation for the n-th last
branch you were on (to be part of 1.6.2 AFAIU). This comes in really
handy when you juggle a dozen branches (and happen to commit to the wrong
branch ;-)
Ciao,
Dscho