191–200 of 269 posts
Oh its from Google? Eh. Pass. It will either be killed in 5 years, or be pitted against Git in an attempt to take over the community.
I wish these well-intentioned Googlers realise what they are doing.
Oh its from Google? Eh. Pass. It will either be killed in 5 years, or be pitted against Git in an attempt to take over the community.
Earlier quoted context omitted.
So in your workflow you never "git commit -a"? So you have to always manually mark what you stage. Which is probably more work than always manually removing the changes you don't want to commit. The ability to rewrite older commits easily in jj also looks like it would help with this usecase if you get it wrong once. Concretely I think you would do is: Instead of staging part of your changes and then committing as in…
> So in your workflow you never "git commit -a"? I like seeing what I'm about to commit, so I always do `git commit -p` or `git add -i`. Most people where I work do the same, so I don't think this workflow is uncommon.
I'll then go back through, tidy and add all my changes.
Earlier quoted context omitted.
gitignores are usually committed (they're treated like a normal file), so yes, in this context that would delete it from everyone. There's .git/info/exclude, but that has some kinda large surprises if it excludes a tracked file and I don't recommend anyone use it unless they know what to look for and can always remember what they've excluded.
I have a $HOME/.gitignore that I use for this. (You can configure git to use that globally.) It's not a panacea, and I think other commenters are right that you should instead endeavor to organize things so that the project's own gitignore results in a sane workflow. But I think having permanently unstaged changes is worse.
Git will fight you if you ignore .config files which are actually used.
Has anyone tried both this and Sapling? https://engineering.fb.com/2022/11/15/open-source/sapling-so... Both of these are on my TODO lists but haven't had time to try them yet.
In my opinion:
- Sapling is much more mature/full-featured at this point. - Jujutsu improves source control workflows in a more principled way. - Jujutsu currently supports colocation with a Git repo, while Sapling requires that the Git repo be kept separately.
Earlier quoted context omitted.
Why do you want such big files in a git repo?
How about why not? The only reason it's not done is because git doesn't support it.
"working copy is automatically committed" seems like a good idea at first glance, but there are many situations where this is not a good idea: - when new artefact files are added and you have not yet added them to .gitignore, they'll be automatically committed - when you have added ignored files in one branch and switch to another branch, the files will still be in your working copy but not listed in your .gitignore…
> staging only some files and comitting is much easier than splitting a commit after the fact Re this point, how is it any different? "Staging" the files is essentially the same as splitting the commit, anyways — it's just that the newly-split contents go into a "staging area" vs a commit. Do you mean that the tooling to accomplish this is not good?
Earlier quoted context omitted.
> staging only some files and comitting is much easier than splitting a commit after the fact Re this point, how is it any different? "Staging" the files is essentially the same as splitting the commit, anyways — it's just that the newly-split contents go into a "staging area" vs a commit. Do you mean that the tooling to accomplish this is not good?
Staging is additive, while splitting is subtractive