fritz posted:I never do 'git commit -a' because plenty of times if I have four modified files I want one to go in one commit, two to go in the next, and then I want to "git checkout -- " the fourth, and "-a" seems like a really bad habit to get into. Maybe I'm the horror (especially since we use gerrit and I'll have to squash those commits eventually). No, you're not. You really shouldn't do -a on your commits. You should go through and read each of your modified files and include notes about them in the commit message. You also should be ensuring that you are committing the right files before you do it. I don't know that I've ever typed git commit -am but if I had a More likely I'd tell him to shut the hell up and give him any one of the basic tutorials out there to read over, which is probably what most of you should do if you're using version control in your day to day jobs and this thread is representative of your knowledge. down with slavery fucked around with this message at 22:22 on Feb 20, 2014 |
|
#
?
Feb 20, 2014 22:19
|
|
|
|
| # ? May 11, 2024 15:56 |
|
|
I just review what I'm about to commit before doing so and then use either -a or -p. Or sometimes I review afterward I commit. Fixing a commit that included some changes it shouldn't have is not exactly a big deal.
|
|
#
?
Feb 20, 2014 22:30
|
|
|
Or you just don't review what you're about to commit, because you made the changes and remember them. And it's not like you face some horrible endgame if your commit is slightly more than minimal. Edit: Normally if I want to review changes I just use git diff. Also: Everybody please git config --global merge.conflictstyle diff3
|
|
#
?
Feb 20, 2014 22:33
|
|
|
fritz posted:I never do 'git commit -a' because plenty of times if I have four modified files I want one to go in one commit, two to go in the next, and then I want to "git checkout -- " the fourth, and "-a" seems like a really bad habit to get into. Maybe I'm the horror (especially since we use gerrit and I'll have to squash those commits eventually). Well really the point is that complaining about having to add files manually is silly because pick one: 1: you can just do commit -a 2: doing commit -a might be bad and sometimes you don't actually want to add all the files, and now having to add files manually is a feature
|
|
#
?
Feb 20, 2014 23:33
|
|
|
down with slavery posted:It really is true that like 95% of arguments against git I read are made by people who clearly have never used it in any real capacity. I'll make a musical analogy that I think reflects perfectly the mentality of people who complain about git being the problem instead of their own inability to read about how to use it. I used to be part of a jazz combo, and we'd play standards, many of which had many many changes in them. You have to play the changes, there's no way to get around it, there's no easy way out, and no easier way to play them. You have to learn jazz, and you have to change chords as the music goes along, that's how music works. There was a guy in the group who was a really lovely guitarist, and he said something along the lines of "isn't there just one chord I can play over the whole tune?", to which the group collectively thought "You're a loving retard, stop being lazy and learn the chords like everyone else, there is no simpler way of doing this.". That pretty much is along the same lines of what is being complained about here. Blowing away a repository because you don't know how to fix what you need to in the repo is the same as starting to read a 100 page book and getting 50 pages in, then starting over because you don't know how to pronounce a word at page 50. You do this in the hopes that the next time around you'll get it right. Why not just do yourself a favor and learn the word? It saves you time, and teaches you how to navigate and fix problems you will run into constantly. Blowing away a repo may allow you to continue working temporarily because you ran into a particular problem you couldn't fix once, but let's say you get into a situation where that problem occurs all the time, are you going to waste your time blowing away and recloning for every single change? No one in their right mind would hire someone with that kind of mentality. Megaman fucked around with this message at 23:58 on Feb 20, 2014 |
|
#
?
Feb 20, 2014 23:50
|
|
|
Steve French posted:Well really the point is that complaining about having to add files manually is silly because pick one: I'm not sure if this is a troll or not, but I never use commit -a unless it's something like me renaming a function via the IDE then committing everything immediately, but even then I'll probably just use 'git add .' instead, as I'm in the habit of running git diff --cached before committing, just to be extra sure. Then after committing I'll realize I forgot something and do git commit --amend  Really though, the index should be thought of as a feature, not an obstacle, especially when you're using it to do things like split a commit in two during a rebase.
|
|
#
?
Feb 20, 2014 23:57
|
|
|
Speaking of git commits, never thought I would see one as moving as this: https://github.com/jimweirich/wyriki/commit/d28fac7f18aeacb00d8ad3460a0a5a901617c2d4
|
|
#
?
Feb 21, 2014 00:15
|
|
|
git's arcane command syntax claims its first victim.
|
|
#
?
Feb 21, 2014 00:18
|
|
|
Of all the git subcommands, I never would have predicted anyone would be bothered by "add." Maybe it should have been called "stage" instead? Jim Weirich deserves to be mourned because when he became annoyed with people asking him when Rake would hit 1.0, he made the next release 10.0
|
|
#
?
Feb 21, 2014 01:14
|
|
|
Volmarias posted:I'm not sure if this is a troll or not, but I never use commit -a unless it's something like me renaming a function via the IDE then committing everything immediately, but even then I'll probably just use 'git add .' instead, as I'm in the habit of running git diff --cached before committing, just to be extra sure. Not trolling. I'm not saying that using commit -a is good; I prefer to avoid it as well. I'm just pointing out how illogical it is to be upset about having to manually add files, because either you see the problem with always doing commit -a, and therefore also must see the value in having to add files, or you don't see the problem with using commit -a, in which case you should just use it (and possibly get burned by it and learn a lesson or something). In either case, being upset about having to manually add files is not rational or consistent.
|
|
#
?
Feb 21, 2014 01:25
|
|
|
 I see the git brigade has arrived while I was asleep. I said more then 4 times the problem is that it's usability is terrible because every command is slightly sub-par, and people are still trying to misrepresent me as having said that there is something critically wrong with one command.
|
|
#
?
Feb 21, 2014 01:40
|
|
Sir_Substance posted:
No actually someone even went through and addressed each of your complaints individually. Complaining about -m on git commit isn't going to garner you any support for your totem pole theory or whatever insanity you were on about last night.
|
|
|
#
?
Feb 21, 2014 01:44
|
|
|
Megaman posted:Blowing away a repository because you don't know how to fix what you need to in the repo is the same as starting to read a 100 page book and getting 50 pages in, then starting over because you don't know how to pronounce a word at page 50. It's much more like getting half way through the book and spilling your coffee all over it and saying gently caress it I'm just gonna go get a new copy instead of trying to dry out the pages.
|
|
#
?
Feb 21, 2014 02:04
|
|
|
Ok, to summarize and recap the conversation here: If you dislike git, you're an unemployable retard If you don't dislike git, you're in the git brigade
|
|
#
?
Feb 21, 2014 02:24
|
|
|
Steve French posted:Ok, to summarize and recap the conversation here: You're in  The Git Brigade now, buddy!
|
|
#
?
Feb 21, 2014 02:26
|
|
|
Steve French posted:Ok, to summarize and recap the conversation here: Looks like being in the git brigade is the better option. Hoist the sails, we're off to make a commit.
|
|
#
?
Feb 21, 2014 02:28
|
|
Steve French posted:Ok, to summarize and recap the conversation here: Better summary: If modern version control solutions prevent you from getting work done, you're an unemployable retard If you dislike git, you're probably inexperienced with the tool If you don't dislike git, you're a cool cat with lots of friends
|
|
|
#
?
Feb 21, 2014 02:41
|
|
|
I've been using git daily for work for the past few years and still think it has a lovely unfriendly interface that doesn't deserve being defended.  I actually think it's easier to learn and use git once you accept this as a fact, and stop expecting to be able to use it from a higher level like any other source control system, and just learn it from the bottom up.
|
|
#
?
Feb 21, 2014 05:00
|
|
|
down with slavery posted:Better summary: I dislike git, but use hg so 
|
|
#
?
Feb 21, 2014 05:12
|
|
|
Steve French posted:Ok, to summarize and recap the conversation here: not so! you're highly employable as a TFS consultant.
|
|
#
?
Feb 21, 2014 07:41
|
|
|
"git commit -a" is just a convenience. I use it when I've made really small changes to a project and checked them with "git diff". I don't understand the problems some people in this thread have with it. (And I say this as someone who is happy to see the Git team take some of the criticism on Git's command line interface seriously and them making improvements.)
|
|
#
?
Feb 21, 2014 07:48
|
|
|
The criticism I've seen, which I think is reasonable based on my experience, is the ease with which it can be used to submit changes that aren't really what they say on the tin, because they're missing god knows what line from a neighboring change. I understand that the git fans here, mega-cool rockstars that they are, never do this, but it does happen in the field just the same. e: bah, I got confused and thought we were still talking about explicit add and specifically git add -p. Since I posted, I'll add that a review of the git reset source code shows that there are only two top-level flows. One runs interactive hunk selection and the other is the reset command itself. Regardless of what the docs say, it really is just one command with options, as opposed to branch which does have 8 top-level flows for different modes. Gazpacho fucked around with this message at 08:54 on Feb 21, 2014 |
|
#
?
Feb 21, 2014 08:45
|
|
|
whenever I run a rebase I cp -r the entire repo to another directory so I can experiment without having to tell git "oh please undo this" in whatever incantation is required if I ever make a mistake, because it's actually simpler to do that than use git to do it.
|
|
#
?
Feb 21, 2014 13:13
|
|
|
MononcQc posted:whenever I run a rebase I cp -r the entire repo to another directory so I can experiment without having to tell git "oh please undo this" in whatever incantation is required if I ever make a mistake, because it's actually simpler to do that than use git to do it. It's really not, since you can just reset --hard to your old SHA if you muck up. And, if you don't know what the SHA was, you can use git reflog to see exactly what happened and in what stage your repo was for the last two weeks. By all means tar -czf your repo as a backup if you're experimenting, but you absolutely don't need to do this because of a bad merge or rebase. Please, just find a few hours then sit down with the Pro Git book online and LEARN. Git becomes monumentally awesome when you know how it works and how to use it. Volmarias fucked around with this message at 13:37 on Feb 21, 2014 |
|
#
?
Feb 21, 2014 13:33
|
|
|
All of the commands you have mentioned are longer to remember and more tedious to use than cp -r. For the number of tricky rebases I may be doing (and not just the regular rebase master on a private branch), that's not even worth my time. Hence git has a lovely user interface. It's simpler and faster to work around it to get similar results than to work with it. Edit: if I've needed to do a complex rebase or re-merge of multiple branch say 15 times in the last year, and that running cp -r and rm -rf takes ~10s, it has taken me 1m50 to do that, and then use rebase as usual. That is over 58 minutes I haven't needed to read another git book and then looking up or trying to remember what's the reset command and hash to use. At this pace, I would need roughly 30 years of git usage to make reading the book worth it for this use case alone. I'm usually not too lost in git and won't need to look up references that much for regular operations and slightly more complex stuff. I remember being stumped for a long while when trying to fetch and merge a remote branch with a different name than mine while excluding a few commits, but I think I ended up cherry-picking instead for this v  v
MononcQc fucked around with this message at 13:47 on Feb 21, 2014 |
|
#
?
Feb 21, 2014 13:38
|
|
|
At least use cp -pR. Jesus.
|
|
#
?
Feb 21, 2014 14:03
|
|
|
MononcQc posted:All of the commands you have mentioned are longer to remember and more tedious to use than cp -r. For the number of tricky rebases I may be doing (and not just the regular rebase master on a private branch), that's not even worth my time.  If you can't spend several hours to learn how to use what should be one of your fundamental tools, I shudder to think of the code you write. Seriously, I'm gobsmacked. I don't know what to say if you don't actually want to learn how to get better and you'd rather just whine about how git is so terrible because it's too hard to learn... reset? Do you even know about reset? Hell, do you even know you can do rebase --abort? It's right there on the command line if there's a conflict.
|
|
#
?
Feb 21, 2014 14:16
|
|
|
MononcQc posted:I've been using git daily for work for the past few years and still think it has a lovely unfriendly interface that doesn't deserve being defended. Volmarias posted:
There's a bit in O'Reilly's Git book that says "Linus Torvalds argued on the Git mailing list that you can't grasp and fully appreciate the power of Git without first understanding the purpose of the index." I don't think that's wrong, but it's definitely different from most other version-control systems, and that's going to be weird and confusing to a lot of users, who just want to check files in and out of source control without knowing about anything complicated.
|
|
#
?
Feb 21, 2014 14:34
|
|
|
Yawn. I don't really "get" the index or use it at all. git works fine for me.
|
|
#
?
Feb 21, 2014 15:01
|
|
|
Volmarias posted:
I understand these aspects of git and use them. I make use of rebase --abort when I'm doing a simple rebase that goes wrong, no problem. I've used the reflog a few times to save my rear end before. 99% of the time I'm fine using git and never hit a problem. There are more annoying corners that I do not venture into, or that are always harder to figure out. What I don't want is to spend more hours learning git than I already have. One example I remember is taking three branches, A, B, and C. branch A was to receive half the changes from B, and C, and a new fourth branch D was to receive the other half of B and C starting at the initial point of A. B and C were then to be deleted. The commits to be kept were in no sequential order although they didn't depend on each other, and some of them I wanted to squash together. In less obvious cases like this where you're trying to untangle multiple histories and regroup them, I prefer to take a back up and go at it and see if I can do it with a) rebases, b) interactive rebases c) rebases + cherry picks d) cherry-picks only if there isn't a million commits e) actually research another solution because who knows. Nevermind trying different merge strategies. if I get to e), I'll learn a different thing, but there's a point where I'm halfway through in poo poo (oh, half the branches are okay but now need to be brought back to their initial state) where I just don't feel like undoing the changes I've made to 2-3 branches anymore and going back from the initial repo is just simpler for me. The assumption that not knowing or even just liking all of the git commands in that context makes me a developer who doesn't try to self-improve is ridiculous. I know enough git to get around without an issue most of the time (and I can google for things I don't remember from the top of my head, like the syntax to git force push to a remote having a different branch name than the local one, because why would you do that?), and have better things to do than dig deeper into git. Like I don't know, learning domain-specific stuff relevant to what I'm programming, for example. MononcQc fucked around with this message at 16:16 on Feb 21, 2014 |
|
#
?
Feb 21, 2014 16:14
|
|
|
I use git a lot and I understand most everything about it, to the point that I've sometimes done dumb poo poo to modify files in .git/objects directly, but its UI still loving sucks. I've created a branch called rm too many times. I wish there was a way to check out a file from commit A as a different filename. Right now I do git stash, git checkout sha1 -- filename.c, cp filename.c{,.old}, git checkout HEAD -- filename.c, git stash pop. I wish merges and rebases were a bit better, so that if I interactively got a merge conflict, I could just say "ignore the conflicts, just pick theirs" without having to go around deleting the "<<<<<<<<<<<<"s every single time.
|
|
#
?
Feb 21, 2014 17:02
|
|
|
Suspicious Dish posted:I wish there was a way to check out a file from commit A as a different filename. Right now I do git stash, git checkout sha1 -- filename.c, cp filename.c{,.old}, git checkout HEAD -- filename.c, git stash pop.
|
|
#
?
Feb 21, 2014 17:19
|
|
|
MononcQc posted:All of the commands you have mentioned are longer to remember and more tedious to use than cp -r.
|
|
#
?
Feb 21, 2014 17:22
|
|
|
Suspicious Dish posted:I wish merges and rebases were a bit better, so that if I interactively got a merge conflict, I could just say "ignore the conflicts, just pick theirs" without having to go around deleting the "<<<<<<<<<<<<"s every single time.
|
|
#
?
Feb 21, 2014 17:28
|
|
|
Plorkyeran posted:git show sha1:./filename.c > filename.old Thanks. Though show to me has always been about presenting commits to the user, not for exporting out user-mungeable data. My big issue with the git UI seems to be how they just stuck random features into whatever command line utility seemed appropriate without thinking of a higher-level API. checkout has three different meanings (change HEAD and the working directory to this ref, change HEAD and the working directory to this new branch based on this ref, change the contents of this file to the contents of the file at this ref without changing the working directory). And now show can either mean "show a user-friendly diff for this ref" or "get the raw contents of a file inside this ref". I've often wondered about trying to create a new, better, command-line git UI based on libgit2. None of these command line nuisances are strictly related to the model and user-space filesystem underneath.
|
|
#
?
Feb 21, 2014 17:31
|
|
|
ShoulderDaemon posted:I think my life got a dozen times easier when I just accepted that I never want to deal with textual merge conflicts, and I set a real merge tool in my global config. I personally like diffuse, which makes it easy either examine conflicts one-by-one or to just take one entire side or the other, but I suggest you play with whatever alternatives you can get your hands on and see what you like the best; merge tools seem to be a really personal preference. Sometimes emacs detects that I'm trying to resolve a merge and tries to pop up ediff. The only thing I've gotten out of it so far is that I have to press "q" to get rid of the annoying little popup.
|
|
#
?
Feb 21, 2014 17:31
|
|
|
show is one of the worst commands and it often takes me a few tries to get the right thing. git show sha1 file, git show file, git show -- file, git show sha1:file, and git show sha1:./file are all useful (different) things.
|
|
#
?
Feb 21, 2014 18:10
|
|
|
Suspicious Dish posted:Thanks. Though show to me has always been about presenting commits to the user, not for exporting out user-mungeable data. It's not hard to cherry-pick specific tasks from a general purpose tool and make it seem like some scattershot bullshit. These tools actually do have a single overall purpose, and it just happens that there are a variety of things you can do within that overall umbrella. Determining what that is for these tools is not hard. Quoting from the man pages: git-checkout: "Updates files in the working tree to match the version in the index or the specified tree." Two of the specific examples you gave are just versions of this. "If no paths are given, git checkout will also update HEAD to set the specified branch as the current branch." This makes sense, because if you do this, HEAD is now identical to the specified branch anyway. I'll admit that the presence of -b is a little inconsistent, but the ability to create and checkout a new branch based on a given branch is useful, and this seems as rational a place to put it as any. git-show just shows objects. It happens that refs and files are both objects, and they should be shown in different ways. I'm sure it's possible for the interface to be more easy to use, but I can't help but wonder about the complaints that individual commands do too many things. Is the argument that you shouldn't be able to do all of these things in the first place? Or that there should be even more commands to support doing these things (I don't think more commands would improve the situation). If the argument is just that the tools should be shifted around and functionality grouped together differently and made "more consistent" or whatever, I'd be really interested to see if those of you who find git's command line interface to be so horrid could put your heads together and propose an alternate interface for the same functionality. I'm not just saying "prove it" (though I am, a little), but actually interested to see what people think would be significantly better. If you're all right, and there are big improvements to be made, doing so might actually save a whole lot of people a lot of headaches, right? You don't even have to do the "hard work" of implementing it, just spec the drat thing out. Maybe I'll get really bored and try to implement it.
|
|
#
?
Feb 21, 2014 18:26
|
|
|
Plorkyeran posted:git show sha1:./filename.c > filename.old git cat-file blob sha1:./filename.c >filename.old Plumbing commands!
|
|
#
?
Feb 21, 2014 19:45
|
|
only
|
|
| # ? May 11, 2024 15:56 |
|
|
Let's post a kickstarter to build a decent commandline interface to git on top of libgit2 or w/e 
|
|
#
?
Feb 21, 2014 20:27
|
|
