Git talk at Pycon2015

[Kent Tenney]

Well done.
1/2 hour, shows when and how to use some scarier git commands
https://www.youtube.com/watch?v=4EOZvow1mk4

[Edward K. Ream]

​Thanks.  There are several commands I've never used.

Just to be clear, the upsetting thing about the recent reversion of Terry's code was due solely to the fact that the reversion was not obvious from the diffs in SourceTree.  Not sure whether that is a SourceTree problem or a git problem.

In other words, I knew there was a problem, but that was because I knew I had just screwed up.  Afaik, there was no other way to know that the reversion happened, so it might have lasted indefinitely.

Sure, it's almost impossible to really lose data with git, but that does no good unless you know that you have to recreate the data.  And how are you supposed to know that if the diffs don't show the reversion?

EKR

[Terry Brown]

On Thu, 30 Apr 2015 07:09:22 -0500
"Edward K. Ream" <edre...@gmail.com> wrote:

> On Wed, Apr 29, 2015 at 11:24 AM, Kent Tenney <kte...@gmail.com>
> wrote:
>
> > Well done.
> > 1/2 hour, shows when and how to use some scarier git commands
> > https://www.youtube.com/watch?v=4EOZvow1mk4
> >
>
> ​Thanks. There are several commands I've never used.
>
> Just to be clear, the upsetting thing about the recent reversion of
> Terry's code was due solely to the fact that the reversion was not
> obvious from the diffs in SourceTree. Not sure whether that is a
> SourceTree problem or a git problem.

It's git rather than SourceTree, although it might be you rather than
git ;-)

We started from 37dd5677 and both edited leoEditCommands.py, your
changes committed in 294b358 and mine in 7d21d1a. 24906c45 is where
you merged these, apparently keeping only your changes - I guess the
issue is why didn't that cause enough alarm from git etc. to catch the
problem.

For the diff, well, there's not really any parent child pair in which
your removal of my changes /could/ be seen.

B
/ \
->-A *--D-->
\ /
C

A,B,C,D are commits, * is the merge process that happened before D

if B is your 294b358 and C my 7d21d1a, my diffs only exist between A
and C, not B and D or A and D. Whatever happened happened in *

Cheers -Terry

[Edward K. Ream]

On Thu, Apr 30, 2015 at 9:48 AM, 'Terry Brown' via leo-editor <leo-e...@googlegroups.com> wrote:

​> ​

I guess the​

​ ​

issue is why didn't

​[the merge, reverting changes] cause enough alarm from git etc. to catch the​

​ ​

problem.

​> ​

For the diff, well, there's not really any parent child pair in which

​ ​

your removal of my changes /could/ be seen.

​Yes, I thought that would be the case. 

Now suppose I hadn't been aware of any problem.  Would you have been able to see your code reverted when you did a git pull?

EKR

[Edward K. Ream]

On Wed, Apr 29, 2015 at 11:24 AM, Kent Tenney <kte...@gmail.com> wrote:

​A great video.  I think git reset --hard would have been a good idea after mistakenly discarding Terry's commit.  I could have re-committed my work, pulled Terry's work and all would have been well.

A related question.  This all came about because I wanted to discard one of the conflicting .json files.  What is the best way to resolve the conflict?

EKR

[Terry Brown]

On Thu, 30 Apr 2015 09:58:10 -0500

"Edward K. Ream" <edre...@gmail.com> wrote:

> Now suppose I hadn't been aware of any problem. Would you have been
> able to see your code reverted when you did a git pull?

I don't remember git making a fuss, but there has been some noise from
git recently, I just don't remember the details, so maybe it did?

I only use git from the command line, with gitk / meld for looking at
diffs sometimes.

Cheers -Terry

[Terry Brown]

On Thu, 30 Apr 2015 10:01:04 -0500

"Edward K. Ream" <edre...@gmail.com> wrote:

So the conflict would have been marked up like:

{
<<<<<<<<<<<< HEAD
"asctime": "Thu Apr 30 06:52:34 CDT 2015",
"timestamp": "20150430065234"
============
"asctime": "Thu Apr 30 06:52:34 CDT 2015",
"timestamp": "20150430065234"
>>>>>>>>>>>> 838fd2a45
}

or something.

In the general case of handling a merge conflict you should edit the
file manually and select pieces, then use `git add <filename>` to
indicate the working copy is the copy with resolved conflicts.

Or using meld, `git mergetool`
(http://blog.wuwon.id.au/2010/09/painless-merge-conflict-resolution-in.html)

In the case of commit_timestamp.json, where it really doesn't matter
that much, you can just do

git checkout --theirs leo/core/commit_timestamp.json
(https://rtcamp.com/tutorials/git/git-resolve-merge-conflicts/)

Cheers -Terry

[Edward K. Ream]

On Wed, Apr 29, 2015 at 11:24 AM, Kent Tenney <kte...@gmail.com> wrote:

​This video is encouraging me to use git from the console.  ​

​Gui-based git clients seem a little limited.  Fine for beginners, but at least SourceTree does not seem to encourage the full range of commands.

EKR

[Edward K. Ream]

​​

On Thu, Apr 30, 2015 at 10:23 AM, 'Terry Brown' via leo-editor <leo-e...@googlegroups.com> wrote:

In the general case of handling a merge conflict you should edit the
file manually and select pieces, then use `git add <filename>` to
indicate the working copy is the copy with resolved conflicts.

​[snip]

 

​

git checkout --theirs leo/core/commit_timestamp.json
(https://rtcamp.com/tutorials/git/git-resolve-merge-conflicts/)

​Thanks!

I just realized that file completion does work, both on Linux and Windows.  On Linux, I must use the forward slash character as the directory separator as usual. On Windows, I must use the forward slash character when using the git bash shell (recommended) or the back slash when using a regular Windows shell.

So this is good.  It's becoming easier to use the terminal.

As another tip, the following will open the global config file (~/.gitconfig) using the editor in effect::

    git config --global -e

This is a good way to test the editor setting. On Windows, ~/.gitconfig specifies the editor as::

    editor = c:/bin/scite.bat

where scite.bat is:

    "C:/Program Files (x86)/SciTE/scite.exe" %*

Again, this batch file *must* use forward slashes if it is used by git.

The only drawback to using the git bash shell is that Windows .bat files aren't recognized.  Sigh.

I am going on about this because using the git console may encourage me to do more development work on Linux.

EKR