Post A09hmadNFwdesrex16 by soft@kawen.space
(DIR) More posts by soft@kawen.space
(DIR) Post #A09b7IxbSjUITK3I2q by soft@kawen.space
2020-10-14T13:24:23.726864Z
0 likes, 0 repeats
why does git suck so much
(DIR) Post #A09b7JJa914JZUKqIq by GNUxeava@fedi.absturztau.be
2020-10-14T13:31:03.859090Z
0 likes, 0 repeats
@soft because you do not tit pullObligatory @absturztaube mention
(DIR) Post #A09b9aGc5VTQj71xke by absturztaube@fedi.absturztau.be
2020-10-14T13:31:28.852099Z
1 likes, 0 repeats
@GNUxeava @soft :peek:
(DIR) Post #A09bL2jYaaUmCU26RE by ily@thighhigh.supply
2020-10-14T13:27:42Z
0 likes, 0 repeats
@soft git gud(git is great)
(DIR) Post #A09bL2yRhEPAwezze4 by soft@kawen.space
2020-10-14T13:31:45.917189Z
1 likes, 0 repeats
@ily If you're working with a lot of other people it's really notIt's easy to get the local and remote copies to diverge, and without any elegant undo/discard things get messy fastAlso branches deleted remotely aren't deleted locally so eventually your local copy will accumulate grunge so you have to periodically delete and re-cloneAnd god forbid someone deletes a remote branch and then makes a new one of the same name
(DIR) Post #A09hYrzbv7mCfOWC1o by duponin@udongein.xyz
2020-10-14T14:43:17.300887Z
0 likes, 0 repeats
@soft still much better than mercurial imo
(DIR) Post #A09hmZO5tGp11BVEYq by ily@thighhigh.supply
2020-10-14T13:33:31Z
0 likes, 0 repeats
@soft these are all good ideas™ tho...it prevents some remote actor from ruining your work.also git fetch --prune
(DIR) Post #A09hmZgWmjZDwM7xIG by soft@kawen.space
2020-10-14T13:38:54.391798Z
0 likes, 0 repeats
@ily Since when was "no undo" a good ideaYou have to set your HEAD backwards, but that leaves you detached, so if you want to commit you have to set upstream and then if the thing you wanted to undo was already pushed you have to push --force which breaks history and causes problems if other people already pulled the commitAnd once all that's done you're still detached and your local branch has diverged a commit, so any attempts to pull changes will try to merge back in the thing you wanted to undoIt's a gigantic mess and the easiest thing is to just delete and reclone which is a terrible solution
(DIR) Post #A09hma15YI0uy7kNLE by soft@kawen.space
2020-10-14T13:43:24.061748Z
0 likes, 0 repeats
@ily You can of course commit --amend but that involves checking out all the changed files from the previous commit to undo things and has the same problems for other people if the commit was already pushed
(DIR) Post #A09hmaMiFtJM3Bre2y by ily@thighhigh.supply
2020-10-14T13:46:23Z
0 likes, 0 repeats
@soft the only reason to undo a commit for me is to remove some private information (e.g. secret keys) uploaded to a public repo.it's still pushed and it'll still be out there. another commit can fix up any other issue.remember, commits are cheap and branches are cheap.
(DIR) Post #A09hmadNFwdesrex16 by soft@kawen.space
2020-10-14T13:50:23.072913Z
0 likes, 0 repeats
@ily "the only reason to undo a commit *for me*"Commits may be cheap but developer time doing reviews is notAtomic commits that do just one correct change with a helpful summary makes review much faster and easierIf someone reviewed your merge, suggested a change, and you made several convoluted commits since, it's hard for the other person to tell what actually changed and reviewing the whole merge again is a waste of time
(DIR) Post #A09hmavo9PNro2HfkW by ily@thighhigh.supply
2020-10-14T13:54:59Z
1 likes, 0 repeats
@soft if you're spending time to do reviews, then you can spend the time to do commit cleanups; that can (and should) be on a separate branch that you are allowed to force push, or via emailed-patches with revisionsyou can also do diffs against a whole branch, not just one commit at a timealso merges can be squashed at the end
(DIR) Post #A09hmbFIyuyomVPF8i by soft@kawen.space
2020-10-14T14:10:20.371781Z
0 likes, 0 repeats
@ily"If you're spending time to do reviews, then you can spend the time to do commit cleanups"My point is cleaning up commits shouldn't be the pants-on-head stupid mess that it is, and it shouldn't take so much time and research and effort to do."that can (and should) be on a separate branch that you are allowed to force push"Yes, everything is on a separate branch I can force push, I assumed that was obvious from my previous comment about force pushing. But if someone else git pulls while I'm working on fixing commits they're in for a bad time."or via emailed patches with revisions"This technique basically circumvents the whole point of git as a collaboration platform, and sadly this often works better than actually using git."you can also do diffs against a whole branch, not just one commit at a time"Like I said, reviewing the whole merge request again is a waste of time if an older version was already reviewed and you just had to make some fixes. It should be easy to review the individual commits made since, with each one being a correct and atomic fix for one comment or problem."also merges can be squashed at the end"That doesn't help the person trying to review your merge request.
(DIR) Post #A09hmbUC5YtDWgN8LY by ily@thighhigh.supply
2020-10-14T14:13:11Z
0 likes, 0 repeats
@soft> circumvents the whole point of git as a collaboration platform, and sadly this often works better than actually using git.maybe you're confuzing git with github?> But if someone else git pulls while I'm working on fixing commits they're in for a bad time.they should be fetching your changes, not pulling them into their own working branch
(DIR) Post #A09hmbwCPRI6vXTUzw by soft@kawen.space
2020-10-14T14:20:55.975435Z
0 likes, 0 repeats
@ily > maybe you're confuzing git with github?No, I'm not. The point of git is having a single remote repository several people can collaborate on at the same time. If the way to make it work is to only have one person use it and send that person diffs then git is hardly involved at all, it's just a different way to generate those diffs.> they should be fetching your changes, not pulling them into their own working branchIf I run git pull on the main branch or my own, I also get updates from other peoples branches. Maybe I'm misunderstanding how it works, but I believe if someone does that and then I break the history to my branch and then they pull again, they'll be prompted to merge their own divergent copy of my branch into remote, even though they aren't working on that branch.
(DIR) Post #A09hmcGPCJSDwCvdUe by ily@thighhigh.supply
2020-10-14T14:33:32Z
0 likes, 0 repeats
@soft > The point of git is having a single remote repository several people can collaborate on at the same time.NO! everyone has their own repository, even if it's a copy. it's a distributed system.> If I run git pull on the main branch or my own, I also get updates from other peoples branches.every person should be set up as a separate remote, so that you can fetch their changes in their own namespace
(DIR) Post #A09hmcYU75uqqHO4fo by duponin@udongein.xyz
2020-10-14T14:45:37.093223Z
0 likes, 0 repeats
@ily@softYou really have to luck at SVN, that probably matches your requirements
(DIR) Post #A09joCq4teIHZXV440 by soft@kawen.space
2020-10-14T14:47:08.779844Z
0 likes, 0 repeats
@duponin Oof, I was hoping to try murcurial and see something better
(DIR) Post #A09joD1QDTMs8io7kG by duponin@udongein.xyz
2020-10-14T15:08:28.003751Z
0 likes, 0 repeats
@soft the problem with mercurial is not only it’s CLI (which is meh to me) but the lack of decent ecosystem aroundalso the way you have to navigate from branches to another, commits to another toooh I forgot that you have to read 2 pages of documentation to figure out that you have to “close” (used term) a branch after you merged itIf you move a file without using hg mv but just mv you will lose the entire history about the filelast but not least frustrating thing is you can’t do add patch and it stages all edits when you do a commitBut often (at least for me) we do edit on many files and don’t want to commit everything:cirno_shrug: