Git GUI push - Socoder

-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0\|685\|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> On Topic -> Git GUI push
Page : 1 2 Next Prev
Sun, 17 Jun 2012, 07:11
Afr0	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!
Sun, 17 Jun 2012, 08:29
JL235	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.
Sun, 17 Jun 2012, 09:02
Afr0	Yeah, I figured it out. For some reason, Git GUI has an options menu option that is hidden away in the 'Edit...' menu. -=-=- Afr0 Games Project Dollhouse on Github - Please fork!
Sun, 17 Jun 2012, 09:13
Afr0	I have to agree with HoboBen though: Git is annoyingly hard to wrap your head around. But hopefully it's worth it if people fork the project. -=-=- Afr0 Games Project Dollhouse on Github - Please fork!
Sun, 17 Jun 2012, 09:49
JL235	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.
Sun, 17 Jun 2012, 10:02
HoboBen	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. -=-=- blog \| work \| code \| more code
Mon, 25 Jun 2012, 03:50
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: [core] editor = /Users/noel/bin/mate -w excludesfile = /Users/noel/.default_gitignore quotepath = false [alias] ap = add --patch cv = commit --verbose --untracked-files=no ci = commit co = checkout br = branch st = status who = shortlog -s -- df = difftool tree = !open -a SourceTree . ri = rebase --interactive [merge] tool = opendiff [gui] fontdiff = -family Menlo -size 13 -weight normal -slant roman -underline 0 -overstrike 0 recentrepo = /Users/noel/Source/Misc/bmax commitmsgwidth = 72 diffcontext = 2 [difftool "Kaleidoscope"] cmd = ksdiff-wrapper git \"$LOCAL\" \"$REMOTE\" prompt = false [diff] tool = Kaleidoscope [color] branch = auto diff = auto status = auto [color "branch"] current = yellow reverse local = yellow remote = green [color "diff"] meta = yellow bold frag = magenta bold old = red bold new = green bold [color "status"] added = yellow changed = green untracked = cyan --v 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\|
Mon, 25 Jun 2012, 05:58
JL235	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.
Mon, 25 Jun 2012, 08:08
Afr0	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!
Mon, 25 Jun 2012, 09:44
Cower	If you care about creating good commits and good commit messages, you don't use a GUI. First, I edit the hunks I stage. I don't mean selecting specific lines, I mean selecting only parts of specific lines and rejecting other parts. I have yet to see a git GUI that allows this — at best you can find GUI clients that allow you to stage lines, which is mostly pointless if, like me, you modify a line and only want to stage half of the changes you did to that line. Second, I follow Tim Pope's guidelines for commit messages, and that means strict character counts for the first line of the message and all the lines that follow. GUI clients do not make it easy to track these things. 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. If you're using a GUI, chances are you're not doing much to write good commit messages. Chances are your summary line is way longer than it should be. Hell, you may not have a summary line because you don't realize the first line of a git commit message is slightly special. GitHub certainly does not encourage this behavior and in fact will never tell you about it. The only way you'll know about it is if you actually read about commit messages, but you probably didn't do that either because you're using a GUI. Why do it when there's a text box that just lets you write in it and ignore the fact that `git log` will not actually wrap your commit messages? So, if you place any value in other people working with your repositories, you're probably doing them a disservice by not putting enough care into your work. I can pretty much confirm this is true of at least Joe's commits on GitHub (having looked at them). Not everyone works with your pretty/fluid GUI clients, so you're screwing the folks who don't (and when it comes to git, that number is actually pretty high).
Mon, 25 Jun 2012, 13:28
Afr0	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!
Mon, 25 Jun 2012, 14:54
Afr0	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!
Mon, 25 Jun 2012, 15:20
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.
Mon, 25 Jun 2012, 20:45
Evil Roy Ferguso	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.
Mon, 25 Jun 2012, 22:11
JL235	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?
Tue, 26 Jun 2012, 01:26
Afr0	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!
Tue, 26 Jun 2012, 03:36
Cower	Your commits definitely aren't fine-grained.
Tue, 26 Jun 2012, 04:07
JL235	What are your problems with my commits?
Tue, 26 Jun 2012, 17:00
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.
Wed, 27 Jun 2012, 16:06
JL235	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.
Wed, 27 Jun 2012, 16:17
Afr0	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!
Wed, 27 Jun 2012, 16:38
JL235	That's not the fine grained commits Cower is talking about.
Thu, 28 Jun 2012, 07:17
Afr0	So what kind of commits is he talking about?
Thu, 28 Jun 2012, 17:06
JL235	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.
Fri, 29 Jun 2012, 18:33
Afr0	That's a good suggestion, should probably do that! I'm just being lazy, since C# is GCed. -=-=- Afr0 Games Project Dollhouse on Github - Please fork!
Sat, 30 Jun 2012, 10:52
Afr0	By the way, I'm still not sure what is meant by "localizing changes down to half a line" - if I made multiple changes to a file, why not stage then all at once? -=-=- Afr0 Games Project Dollhouse on Github - Please fork!
Page : 1 2 Next Prev