| User | Message |
|
 Posted : Sunday, 17 June 2012, 06:11 | Permalink | Mark Here |
Afr0
  
WW Entries : 3
|
Does anyone here have experience with Git GUI?
I figured out how to use it, and have now moved from Assembla to Git (per suggestion from JL235). Hopefully this will lead to people forking the project and pushing commits back.
The only issue I had was that when I was finished pushing, all files showed up on Github as being pushed by unknown, even though GitGUI asked for my Github username and password!
Link
Does anyone have any idea how I can specify that files are pushed by me in the future? Also, please fork!!
-----
Afr0 Games
Project Dollhouse on Github - Please fork! |
 | |
|
| Posted : Sunday, 17 June 2012, 07:29 | Permalink | Mark Here |
JL235
WW Entries : 7
|
When you push, GitHub can't tell where it's come from. It can only tell if it's allowed based on your ssh key.
So to get your details it looks at the email address provided along side the commit. If this e-mail address matches the one you use on GitHub, then you get your details. If it doesn't, then it won't. So make sure the e-mail address your using matches what you have for your Gravatar.
For example if you look at the commits for my recent project PHP Error, it looks like the commits are coming from two users, but they are actually both me. It's because I have two different e-mail addresses set for when I push from two different machines, but haven't bothered to correct it.
-----
PlayMyCode.com - build and play in your browser, Blog, Twitter. | |
| |
|
| Posted : Sunday, 17 June 2012, 08:02 | Permalink | Mark Here |
Afr0
WW Entries : 3
| |
| Posted : Sunday, 17 June 2012, 08:13 | Permalink | Mark Here |
Afr0
WW Entries : 3
| |
| Posted : Sunday, 17 June 2012, 08:49 | Permalink | Mark Here |
JL235
WW Entries : 7
|
I've not tried Git GUI.
You could try GitHub for Windows (and they have one for the Mac too). It's excellent, and the UI is beautiful.
-----
PlayMyCode.com - build and play in your browser, Blog, Twitter. | |
| |
|
| Posted : Sunday, 17 June 2012, 09:02 | Permalink | Mark Here |
HoboBen
WW Entries : 9
|
I found git became far more sensible with an alias that does "git add -vA && git commit" all in one go.
Dunno how the GUI works though, or why you'd want one.
-----
 github | |
| |
|
| Posted : Monday, 25 June 2012, 02:50 | Permalink | Mark Here |
Cower
|
Late response, but you really ought to just use git from the terminal. Set up a few aliases and you're pretty much set. It's frankly the most flexible way to work with git, plus the ability to manually edit hunks is stupidly useful. It's honestly brilliant for doing fine-grained change tracking.
For reference, this is part of my .gitconfig:
-->
I should point out that "cv" and "ap" are my most-used aliases. After that it's mostly just "st" and "co" for when I'm checking what I haven't already committed and changing branches. I should probably set up an interactive rebase alias too.. maybe "ri".
|edit| Yeah, added "ri". Also expanded flags to their long names just so you can see what they're doing. |edit| | |
| |
|
| Posted : Monday, 25 June 2012, 04:58 | Permalink | Mark Here |
JL235
WW Entries : 7
|
For the day to day cruft, I don't see why you wouldn't use a GUI. Most of the time it's just pulling, committing, and pushing. Ok there are other things too, but you can just reach for the command line when you'd want to use them.
GitHub for Windows is so fluid and pretty; it's not like the many other GUIs for Git, which essentially look like Windows 95 apps.
-----
PlayMyCode.com - build and play in your browser, Blog, Twitter. | |
| |
|
| Posted : Monday, 25 June 2012, 07:08 | Permalink | Mark Here |
Afr0
WW Entries : 3
|
Yeah... I started using Github for Windows and am loving it. If I feel the need to do fine-grained stuff, I'll consider using a terminal.
I got my exams back today and passed, so now I can program all summer with a clean conscience. Next semester I'm doing a minor in CS, which will be interesting.
I actually ended up deleting my first repository because I accidentally commited all the binaries as well, and then when I tried using GitGUI to remove the binaries from the previous commit, everything fucked up.
-----
Afr0 Games
Project Dollhouse on Github - Please fork! | |
| |
|
| Posted : Monday, 25 June 2012, 08:44 | Permalink | Mark Here |
Cower
| |
| Posted : Monday, 25 June 2012, 12:28 | Permalink | Mark Here |
Afr0
WW Entries : 3
|
 you modify a line and only want to stage half of the changes you did to that line.
By 'staging' I'm assuming you mean 'committing'... why would you only commit half the changes you did to a line?
The latter case is far more important to me because I care quite a bit about whether my commit messages are consistent and work regardless of whether you're using a terminal or not.
Why care if you're of the opinion that everyone should be using a terminal in the first place?
-----
Afr0 Games
Project Dollhouse on Github - Please fork! | |
| |
|
| Posted : Monday, 25 June 2012, 13:54 | Permalink | Mark Here |
Afr0
WW Entries : 3
|
Ok so I read up on staging, and it seems like a completely useless feature to me. This blogpost outlines a scenario called the "tangled working copy"-problem for when staging comes in handy.
I've never actually had this problem. Ever!
When I work on a feature, function or what have you, I finish it (and test it) before committing. In the rare case that I don't, I specify in the commit message that I submitted a non-working change so that if you need to avoid experimental code you can revert to the last version.
In the rare case that I fix or change two unrelated issues in the same file, I make sure they both work before committing. And I always summarize what I did in my commit messages.
-----
Afr0 Games
Project Dollhouse on Github - Please fork! | |
| |
|
| Posted : Monday, 25 June 2012, 14:20 | Permalink | Mark Here |
Cower
|
First, you're already using the stage whether you like it or not. Second, if you're making single commits for entire features, you are using git in a way that is not optimal. git operates best if your commits are small, fine-grained changes. It makes locating and undoing specific commits much easier.
The stage itself is useful, and as I mentioned above, you're using it whether you like it or not. If you make any commit at all, congratulations, you've staged changes (not files). If you've ever marked something to go into a commit, congratulations, you've staged changes again.
If you're working with git in an optimal manner, staging a few changes and then going back to work is much better than staging everything when you're done and just saying "I added XYZ" in an enormous, difficult to unravel commit. Small changes, on the other hand, let you very easily see where something went wrong in the changes. Testing doesn't cover everything, nor does static analysis and Valgrind, and things go wrong.
Using your method, it's difficult to figure out where something went wrong and quickly undo it if that's all that needs fixing. Using my method, I really just need to use git-revert on whichever commit(s) introduced a bug or regression and it's done.
Also, though I'm of the opinion that you should use the terminal, I can't force people to use it, I can only tell you what I think. My commits look fine regardless of whether they're in a terminal or GUI because they're formatted according to a consistent standard. Yours probably aren't, and I know Joe's aren't.
Your ignorance of the tools you use isn't a good quality. Try to fix it. | |
| |
|
| Posted : Monday, 25 June 2012, 19:45 | Permalink | Mark Here |
Evil Roy Ferguson
WW Entries : 3
|
I will note that GitHub for Windows actually does indicate when you're formatting your commit messages wrong - it just gives you such a minor visual cue that it's hard to notice unless you're looking for it. When a line of the commit message gets beyond the recommended length, the rest of the characters on that line turn gray instead of black.
Won't fully address the GUI / console disparity, but hopefully knowledge of that will at least make commit messages more palatable to command-line users. | | |
|
| Posted : Monday, 25 June 2012, 21:11 | Permalink | Mark Here |
JL235
WW Entries : 7
|
Heh, I don't think my commit messages are that bad. I've seen a lot worse.
I'd be interested in knowing what Cower thinks is wrong with my commits?
-----
PlayMyCode.com - build and play in your browser, Blog, Twitter. | |
| |
|
| Posted : Tuesday, 26 June 2012, 00:26 | Permalink | Mark Here |
Afr0
WW Entries : 3
|
I will note that GitHub for Windows actually does indicate when you're formatting your commit messages wrong - it just gives you such a minor visual cue that it's hard to notice unless you're looking for it. When a line of the commit message gets beyond the recommended length, the rest of the characters on that line turn gray instead of black.
Thanks for pointing that out, I've actually noticed that before!
Cower, I never said I didn't use staging, just that it seems like a useless feature to me. Also, please tell me if you think that my commits aren't fine grained...
-----
Afr0 Games
Project Dollhouse on Github - Please fork! | |
| |
|
| Posted : Tuesday, 26 June 2012, 02:36 | Permalink | Mark Here |
Cower
| |
Your commits definitely aren't fine-grained. | |
| |
|
| Posted : Tuesday, 26 June 2012, 03:07 | Permalink | Mark Here |
JL235
| |
What are your problems with my commits? | |
| |
|
| Posted : Tuesday, 26 June 2012, 16:00 | Permalink | Mark Here |
Cower
| |
Mainly that they lack explanation and tend to be poorly written. Also, your summary lines are sometimes too long and therefore break both on GitHub and in a terminal. | |
| |
|
| Posted : Wednesday, 27 June 2012, 15:06 | Permalink | Mark Here |
JL235
WW Entries : 7
|
Only one of those commits is cut off for the web and github terminal for me, and only by around 5 or 6 characters.
Tbh I think your just nitpicking.
-----
PlayMyCode.com - build and play in your browser, Blog, Twitter. | |
| |
|
| Posted : Wednesday, 27 June 2012, 15:17 | Permalink | Mark Here |
Afr0
WW Entries : 3
|
Proof and Doubleproof that it is possible to do fine-grained commits with Github for Windows (so long as only one file is committed at a time - otherwise it will automatically stage the entire file).
Admittedly I did manually diffing for this (I copied over the changed function to the target file myself), but I'd rather do that than use a console. In fact, I've been thinking that writing a GUI-diff might not be such a bad idea, but that'd be a distraction...
-----
Afr0 Games
Project Dollhouse on Github - Please fork! | |
| |
|
| Posted : Wednesday, 27 June 2012, 15:38 | Permalink | Mark Here |
JL235
WW Entries : 7
|
That's not the fine grained commits Cower is talking about.
-----
PlayMyCode.com - build and play in your browser, Blog, Twitter. | |
| |
|
| Posted : Thursday, 28 June 2012, 06:17 | Permalink | Mark Here |
Afr0
| |
So what kind of commits is he talking about? | |
| |
|
| Posted : Thursday, 28 June 2012, 16:06 | Permalink | Mark Here |
JL235
WW Entries : 7
|
You have lots of changes in one commit, he is talking about being able to localise changes all the way down to half lines.
Also is it really sensible to be creating a new color of 0,0,0,0 for each row? Make it once.
-----
PlayMyCode.com - build and play in your browser, Blog, Twitter. | |
| |
|
| Posted : Friday, 29 June 2012, 17:33 | Permalink | Mark Here |
Afr0
WW Entries : 3
| |
