Project management and issue tracking can be done with for example an org-mode or taskjuggler file in or outside git.
What comes after Git
101–110 of 430 posts
Re: What comes after Git
#102Earlier quoted context omitted.
It sounds like you're just working around the limitations of the tools. Edit: I think it's possible that I misunderstood, given the downvotes. I thought they meant that a dependency should be added in one PR, and then the feature needing that dependency in a separate PR. What I think they actually meant is that if adding a dependency requires upgrades of other dependencies, then upgrade the existing dependencies in o…
Simply separating concerns so that each PR/commit focuses on 1 thing.
But what is the one thing if you're just adding a dependency, where you're only adding it so that you can subsequently add a feature using it in a separate PR? The atomic action is adding the feature which requires the new dependency. Unless I misunderstood what you wrote.
I still agree with the original comment in that diffing technology feels decades behind, and that a lot of what we do as software engineers are working around things the tooling should be doing better on.
Re: What comes after Git
#103The thing is that git is not supposed to be smart when it comes to merging.
https://wincent.com/blog/a-look-back-bram-cohen-vs-linus-tor...
At the end of the article: This is a clearly ambiguous merge and it simply wouldn’t be right for your version control system to try "resolving" it for you.
So the strategy is that if there is any doubt you have to manually fix conflicts. This is by design.
Re: What comes after Git
#104git is like cpp, you have to use a subset: - push - pull - checkout - checkout -b - merge —ff-only - stash - stash pop - reset —hard origin/master - reset —soft $hash - commit -m
> pull
I find that command too dangerous. I only use git fetch and git merge --ff-only.
You forgot git tag
Re: What comes after Git
#105Am I the only one who thinks that Git's UX is fine, and maybe even rather enjoyable? It has taken time to learn, and I am by no means a power user, but its model is now in my brain so, for better or worse, it's how I think and work now too (interactive rebasing for the win, all the time, and lots of shell aliases to shorten things). I do wish I had an easier way to split up a commit that accidentally included several…
> Am I the only one who thinks that Git's UX is fine [...]
No, I think most people that use it are fine with it. But those are usually not the ones you hear :)
Re: What comes after Git
#106My main issue with Git, other than the terrible UX of the CLI, is just how common it is for one to want to rewrite the commit history - an operation for which there's no version control. You better get it right, or otherwise you get to nuke the whole repository.
Big issue is parent commit hash included in the commit hash. You have to rehash all commits following a history change.
I wouldn't call that an issue, more like an indispensable core feature! The fact that git bled the content-addressable hash through to the front of the UI is an underappreciated stroke of genius as far as I'm concerned.
It takes so much of the guess-work out of build tools, CI, etc.
Re: What comes after Git
#107Am I the only one who thinks that Git's UX is fine, and maybe even rather enjoyable? It has taken time to learn, and I am by no means a power user, but its model is now in my brain so, for better or worse, it's how I think and work now too (interactive rebasing for the win, all the time, and lots of shell aliases to shorten things). I do wish I had an easier way to split up a commit that accidentally included several…
Same here. I am totally fine with git as it is. If I weren't I maybe would just try one of the hundreds git plugins / clients to see if it better fits my needs.
Re: What comes after Git
#108My main issue with Git, other than the terrible UX of the CLI, is just how common it is for one to want to rewrite the commit history - an operation for which there's no version control. You better get it right, or otherwise you get to nuke the whole repository.
There absolutely is version control for rewriting commit history, no fancy tools needed. Start another branch at the point where you want to rewrite history; don't switch to it: `git branch original-history-branch`. Now `git rebase` your branch to your heart's content. This branch will have the new, rewritten history. The original-history-branch still has your old history, refers to your old commits and prevents them…
And that original-history-branch is either dropped or lives on happy ever after, polluting a crowded namespace. Or it's the base of some parallel development and then that's merged and you end up with every commit twice in the history. I guess the github model of forks and PRs might help, but that's not git, it's git with an added workaround.
Another approach (which might not be git anymore, but close enough to talk about in git nomenclature) might be some kind of facade layer for the history where you fix wrong comments, bundle up old commits to linear groups and so on. A commit hash would still reference a code state, but the repository state (code and its revised history presentation) would be something like "g123abc as seen by g345fed", usually "g123abc as seen by branch/HEAD", perhaps width some clever defaults like "head of whatever branch has the most recent commit on top of g123abc"
Re: What comes after Git
#109Earlier quoted context omitted.
> And do you seriously not see the need of rebasing? Rebasing isn't actually necessary, and there's a good argument to be made that you should never rebase. Fossil (the version control system used by the sqlite team) doesn't have any rebasing mechanism: https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w... (there are of course also very good arguments in favour of rebasing, but my point is simply that it is…
Of course it isn't necessary. It's just extremely useful. Of course it rewrites history, and I abhor rewriting shared history, but it's extremely useful to be able to rewrite your own private history!
> Of course it isn't necessary.
Well....but you literally said above that there's a need for it. In a somewhat condescending tone. And now it's suddenly obvious that it's not necessary? Okay.
Re: What comes after Git
#110git is like cpp, you have to use a subset: - push - pull - checkout - checkout -b - merge —ff-only - stash - stash pop - reset —hard origin/master - reset —soft $hash - commit -m
> pull I find that command too dangerous. I only use git fetch and git merge --ff-only. You forgot git tag
accurate.