|
Triple Tech posted:More correct answer: don't use SVN if you care about merging after branching. Branch off version snapshots (1.0, 2.0, etc) instead of just creating a tag for that version for backporting bug fixes.
|
#
¿
Aug 25, 2009 00:35
|
|
|
|
| # ¿ Apr 29, 2024 15:58 |
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
Github's permissions model is also sort of garbage, which can be an issue for an even sort of small organization.
|
|
#
¿
Mar 13, 2014 02:22
|
|
|
wolffenstein posted:shell environment variables seem like a decent way to do it if that's an option. This seems to be a common thing to do, but I'd like to point out that it makes it really really easy to accidentally leak sensitive data to third parties. It's common (and not hard to imagine) for error reporting mechanisms to dump the environment along with a stack trace or whatever; if you're putting sensitive poo poo directly in the environment that will go along for the ride. AWS does this and it drives me nuts; the environment variable should be a reference to a file containing the sensitive data, not the data itself.
|
|
#
¿
Apr 18, 2014 04:32
|
|
|
|
| # ¿ Apr 29, 2024 15:58 |
|
|
aerique posted:Then again it avoids regressing the typo back into your software when reverting a big commit and looking stupid to your users. All those users reading comments in your code, yeah
|
|
#
¿
May 8, 2014 20:12
|
|