Post 9icLj3Pq3N5HtqIsq0 by evilchili@mastodon.social
(DIR) More posts by evilchili@mastodon.social
(DIR) Post #9icDZnzVEYFdoy42Hw by fribbledom@mastodon.social
2019-05-08T23:09:17Z
1 likes, 2 repeats
"git commit -a" is what I call a cowboy-commit, and I still think git should flag and expose commits as such.Not that I mind anyone using it (carefully), but it would make me extra wary when reviewing a commit. It should be the absolute exception, not the standard way of committing things.Do it properly and always review your individual changes once more! Use "git add -p"!You will soon love it and whoever reviews your code will love you for using it!
(DIR) Post #9icDZoGAEbZwedrLG4 by lachs0r@nazrin.moe
2019-05-08T23:11:33Z
0 likes, 0 repeats
@fribbledom And ffs do not use merge commits. Rebase your changes. Stupid GitHub defaults make your commit log unreadable 🤬
(DIR) Post #9icDZoRVYQeXDpAOwK by tomasino@mastodon.sdf.org
2019-05-08T23:15:56Z
0 likes, 0 repeats
@lachs0r @fribbledom you can filter merge commits from your logs
(DIR) Post #9icE7DNBsuke6A4hEm by lachs0r@nazrin.moe
2019-05-08T23:22:05Z
0 likes, 0 repeats
@tomasino @fribbledom That doesn’t make them less messy and doesn’t help when bisecting a regression.
(DIR) Post #9icE8iOU2G2ob6OXfE by palecur@rafting.io
2019-05-08T23:16:27Z
0 likes, 0 repeats
@fribbledom this is literally the only way I commit tho, if there's any errors it's not like you can't fix them with another commit
(DIR) Post #9icE8ien3d5XPg1Z56 by fribbledom@mastodon.social
2019-05-08T23:18:21Z
0 likes, 0 repeats
@palecurThat's fine if it's your own little code base, but as soon as you're working with (even just a small) team, this quickly becomes unmaintainable or -reviewable.
(DIR) Post #9icE8itgAGzw9qzSHw by clarjon1@connected.cat6.network
2019-05-08T23:19:25.781677Z
0 likes, 0 repeats
@fribbledom @palecur I've been using `git add *` -- what's the benefit/difference for using `git add -p`?
(DIR) Post #9icE8jCp16JJ7Dwk7s by fribbledom@mastodon.social
2019-05-08T23:21:40Z
1 likes, 0 repeats
@clarjon1In that case you may as well use "git commit -a" which essentially does "git add *" for you."git add -p" makes you and lets you confirm each individual change hunk before staging it. This also means you can add only some changes within a file and leave other changes for a later commit.@palecur
(DIR) Post #9icFELJqq6kKixTY4u by mansr@society.oftrolls.com
2019-05-08T23:34:37Z
0 likes, 0 repeats
@fribbledom I often use commit -a after making a single small change.
(DIR) Post #9icFHfHV4rGdVJxa0u by fribbledom@mastodon.social
2019-05-08T23:35:13Z
0 likes, 0 repeats
@mansrI guess that falls under "knowing what you're doing and using it carefully". Also, easy enough to review.
(DIR) Post #9icFKR7ACnCMR4RkmW by gabek@mastodon.social
2019-05-08T23:18:00Z
0 likes, 0 repeats
@fribbledom git commit -am “I dunno”
(DIR) Post #9icFKRcMKo9Tzp2fPE by mansr@society.oftrolls.com
2019-05-08T23:35:43Z
0 likes, 0 repeats
@gabek @fribbledom git commit -a -m "fox typo"
(DIR) Post #9icFUdq1kobmnEIVSC by tomasino@mastodon.sdf.org
2019-05-08T23:37:13Z
0 likes, 0 repeats
@lachs0r @fribbledom I've never done that. When and why do you do that? Maybe it's something I should learn
(DIR) Post #9icHODhaDNRbu6PhOi by Rosemary@awoo.space
2019-05-08T23:17:12Z
0 likes, 0 repeats
@fribbledom What does the -a flag do?
(DIR) Post #9icHODzf89uEoAs8Zs by fribbledom@mastodon.social
2019-05-08T23:20:07Z
0 likes, 0 repeats
@RosemaryStages and commits any and all files that have been modified or deleted.
(DIR) Post #9icHOEHk2wMriFKZl2 by Rosemary@awoo.space
2019-05-08T23:20:41Z
0 likes, 0 repeats
@fribbledom I suppose I don't know enough about versioning systems to know what this means. I thought that was default behavior for a commit.
(DIR) Post #9icHOEZ70MGKa7SRpg by clacke@libranet.de
2019-05-08T23:58:43Z
0 likes, 0 repeats
@Rosemary @fribbledom In svn it is. 😀And there you have the extra surprise that it applies to the directory you happen to be in when you commit. Everything there and below gets into the commit, everything above and to the side doesn't. Oh the number of times that bit me.
(DIR) Post #9icLj3Pq3N5HtqIsq0 by evilchili@mastodon.social
2019-05-09T00:28:25Z
0 likes, 0 repeats
@fribbledom -p is great if you have too many unrelated changes in flight at once. Even more powerful is: avoid authoring unrelated changes in parallel. only author single, atomic, logical changes, and resist the urge to start the next 6 changes on the same working branch.
(DIR) Post #9icLj3mAiKwt16kieG by clacke@libranet.de
2019-05-09T00:47:15Z
0 likes, 0 repeats
@evilchili @fribbledom This. git commit -a is absolutely valid when you have six worktrees checked out and aren't mixing things up.
(DIR) Post #9icRutPJgp1Q3j5V0y by 361.xj9@social.sunshinegardens.org
2019-05-09T01:56:42.975443Z
1 likes, 0 repeats
@fribbledom i use rebase -i usually, but i don't see the point in cluttering the commit history with WIP commits. i use git as the "save" program in the workflow. writing to disk is just a temporary buffer. i commit at least 10 times before i'm done working on a thing. then i rebase to create a coherent set of changes. i use -a occasionally if i already have a nice message written up and i notice that i forgot to remove a comment or some other minor adjustment.this is just on feature branches obviously. public history shouldn't be changed because it creates a lot of problems for everyone else using the repo.
(DIR) Post #9icWXURUqFnJk5ldrs by felixthepope@abdl.link
2019-05-09T02:46:22Z
0 likes, 0 repeats
@evilchili @fribbledom I often fail to resist that urge. 😂
(DIR) Post #9icWXUpbOd4owr2tRQ by clacke@libranet.de
2019-05-09T02:48:31Z
0 likes, 0 repeats
@felixthepope @evilchili @fribbledom Sometimes I just hammer away as issues come up as I'm solving some main issue, but then I untangle them before submitting PRs, even to my own project where I wrote 99% of the code.I just create a new branch, cherry-pick things, soft-reset, git add -p the things relevant for that branch, throw away the others, etc.
(DIR) Post #9iccyaG1vf4fJyhsK8 by fribbledom@mastodon.social
2019-05-09T02:49:53Z
1 likes, 0 repeats
@clackeWhen reality gets in the way of your development ethics 😂 @evilchili @felixthepope
(DIR) Post #9icdJjPF6sPtmC6FCC by clacke@libranet.de
2019-05-09T04:04:28Z
0 likes, 0 repeats
@fribbledom As this thread has diverged into talking about git commit --amend, I'll throw in that I do amending so often that I have an alias.amend='commit --amend --no-edit'. Also the other day I discovered git commit --fixup <commitish>, which is pretty great for things you come up with as you hack along, but which belong in an earlier commit. They're easy to spot and move to the right place on the right git rebase -i.
(DIR) Post #9iczpsMLYU8DnpTgrQ by lilo@mastodonten.de
2019-05-09T08:04:34Z
1 likes, 0 repeats
@fribbledom Recently, a colleague warmly recommended the following git alias to me:acp!f() { git add -A && git commit -m "$*" && git push ; };fHe is using it all the time...
(DIR) Post #9id04Ia4rSJXBImHNg by clacke@libranet.de
2019-05-09T08:19:22Z
0 likes, 0 repeats
@lilo @fribbledom As long as you're pushing to a feature branch on your own repo, and make sure to tidy any of the inevitable mistakes, I don't see a big problem with that.
(DIR) Post #9idB3FWzoUdkvf2SXo by ben@mastodon.lubar.me
2019-05-08T23:09:46Z
0 likes, 1 repeats
@fribbledom "git add -i" is also useful but for subtly different kinds of file adding
(DIR) Post #9iem7uQlaC5kOgAasC by ekaitz_zarraga@mastodon.social
2019-05-09T18:39:17Z
1 likes, 0 repeats
@fribbledom I use git diff --staged often to be sure of what I'm doing, also git commit -v is cool because you can see the changes you are committing.:D
(DIR) Post #9iemAL2XcZR3VGzsZs by lilo@mastodonten.de
2019-05-09T08:27:31Z
1 likes, 0 repeats
@clacke Yes, it depends on usage (I copied the alias and use it from time to time, too). Unfortunately his usage is sometimes not so careful and restricted to feature branches...@fribbledom
(DIR) Post #9iemH31syy5hfhtEJM by anne@beach.city
2019-05-09T10:29:01Z
1 likes, 0 repeats
@fribbledomAh see I am coming at this from the other direction. "Oh thank God their changes are in version control at all!" Requesting they be more careful with checkins means they only check code in at all when they are feeling inventive. But this is development where the code only ever needs to run correctly once, so the requirements are different.