I'll be hosting a "master class" on using git in conjunction with the Marlin Firmware project. I propose to broadcast starting on Wednesday, April 5 starting at 9:30pm CDT (GMT-5), and will continue for as long as there are useful things to demonstrate.
Please post any questions you would like answered or topics covered.
The stream is at: https://www.youtube.com/watch?v=b-2ngF9e6oI
Will you record it? Cannot attend at that time.
Regards/Saludos,
Ernesto.
Yes, it will be streamed on YouTube, and published immediately afterwards.
Hopfully, you can show more than just a few commits to squash.
And how to open and resolve the conflicts that arise from an attempted squash.
How to reset from that.
Also how to avoid local repo corruption when something doesn't go right.
Cool! Thanks a lot!
On 5 Apr 2017, 10:25 +0800, Scott Lahteine notifications@github.com, wrote:
>
Yes, it will be streamed on YouTube, and published immediately afterwards.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub (https://github.com/MarlinFirmware/Marlin/issues/6246#issuecomment-291721369), or mute the thread (https://github.com/notifications/unsubscribe-auth/AGcPb7lp705lDRPNVMiKcggWDPkRZibdks5rsvuogaJpZM4Mzqry).
@Tannoo All of the above.
@thinkyhead very excited about this! Thanks!!
I think the Git developers should do a 5 minute video explaining why they developed something that is 100% non-intuitive.
The desktop app basic interface simply isn't for managers of projects.
But, you know...
Gnome is better at a gui for linux than git desktop is for git.
Hell, Windows 3.x was a better gui than git desktop.
There's always room for improvement. Shunning it off doesn't make it better.
Just sayin'.
It is early days for that app. I'm sure it could do better. In fact there are other front-ends for git that are more full-featured – "SmartGitHg" for example. But they come with a learning curve for their interface and method of representing the history too.
Once you have a good picture of "what a branch is" it starts to fall into place. One thing I have found is that it's absolutely imperative to have some way to run git rebase -i. (I imagine some UIs just display the commits and let you drag them around, and so on, as an interface.)
But, you know...
Gnome is better at a gui for linux than git desktop is for git.
Hell, Windows 3.x was a better gui than git desktop.
There's always room for improvement. Shunning it off doesn't make it better.
Just sayin'.
From a slightly different perspective... Supposedly Git helps you develop your software and make it everything it can be. How 'bout the Git Developers use their software to make GitHub-DeskTop everything it can be??? And at the top of the list is 'Easy and Obvious to Use'.
Insofar as what it does, it's kind of easy and obvious. It only allows these basic operations:
origin/[default] branchorigin/[current] branch (i.e., Unpublish)No interactive rebase (or rebase at all) is possible, which means you have to use another means, such as the CLI. And of course, for resolving merge or rebase conflicts, you're on your own. But that's the same with all version control systems. A human has to decide what's best.
But that's the same with all version control systems. A human has to decide what's best.
I'm going to watch a good sci-fi movie... But Git has been giving a bunch of us 'Conflicts' when there is nothing even different. I went so far as to delete everything in that area of the file and try to check it in. No Go! It's a conflict. Come On.... And listen... It is philosophically wrong for it to edit my source files and put all kinds of things like <<<<<<<
Yes. I agree. When rebasing (merging commits from upstream), sometimes there are conflicts. Git deskstop will show me what files are conflicting.
Maybe I just missed them when trying to squash, but I didn't see the files it was complaining about.
Some git front-ends exist that will hide the <<<<HEAD, =====, and >>>> comment markers. But generally, we are expected to resolve commits using something which is a text editor at its base, and these markings clearly indicate the positions of the conflicts. It's important to be able to follow the git logic as to why some things are included in these conflict blocks. Sometimes they are not part of the changes, but only part of the context.
In the live-stream I will perform several examples of conflict resolution and explain what's going on at each point.
It is very much a process requiring attention to detail. When we run up against many conflicts that are hard to resolve, that can be annoying. It means we have to look carefully at all of them. Corrections in indentation are the most annoying, because then it's hard to resolve the ordering. In those cases, you need to abort the merge, use a diff tool to decide what the up-to-date code in those blocks should be, and then when you re-do the merge/rebase and hit that conflict again, paste in the block more easily resolved elsewhere.
Of course under some circumstances, the preponderance of conflicts is too many to deal with. In that case it's easier to "start over" and rebuild the changes on the latest code. I will also go over that process in detail.
If anyone is in the mood for a teaser, I made a 56 minute intro video today. Sorry there are clicks and typing noises. (The laptop microphone is sensitive.) I hope to replace this video with shorter videos on the topics covered, plus I hope most topics will be explained well in the live-stream video.
@Roxy-3D <<<<<<<
@thinkyhead - the class notes you're preparing - after I get them all bound up, will they fit on my kitchen table? ;-)
Will you be focusing more on the git command line or the GUI?
If I can suggest a few brief topics
Comparing files between branches or commits with "diff branch1..branch2 -- file.h"
Comparing logs with log branch1..branch2.
Setting up difftool and mergetool
Undo changes with checkout -- * and reset HEAD *
Commit --amend
Push -f
The stream is at: https://www.youtube.com/watch?v=b-2ngF9e6oI
I use TortoiseSVN at work, and I love it!
i know they have released ToirtiseGIT but haven't given it a try yet.... As soon as I get back from Mexico in 2 weeks, I'll give it a try and let you know if it makes life easy :)
i know they have released ToirtiseGIT but haven't given it a try yet.... As soon as I get back from Mexico in 2 weeks, I'll give it a try and let you know if it makes life easy :)
I'm open to suggestions. If you think ToirtiseGIT is better than GitHub-Desktop, I'll switch. GitHub-Desktop is not at all intuitive.
I hope you found the linked videos informative, even though they are a bit scattered. I recently got a newer laptop that probably has a better microphone. And I'm ordering a condenser microphone and headphones so I can do these videos properly and be heard.
Most helpful comment
I think the Git developers should do a 5 minute video explaining why they developed something that is 100% non-intuitive.