4 ms·

The one potential effect of this that I'd love over git is being able to check in local changes that I never intend to upstream. E.g. I could have a local chang

The one potential effect of this that I'd love over git is being able to check in local changes that I never intend to upstream. E.g. I could have a local change adding some editor config files, or modifying some compiler flags in the Makefile to suit my local config. With git my typical solution for this is to basically keep rebasing them as uncommitted changes with `git stash`, until I inevitably lose them. Or keep a separate branch, and keep explicitly rebasing (and stay on my toes not to accidentally push the commits).

saagarjha 6y ago
Ooh, yes, I have this problem with Git too. I maintain it mostly by keeping stuff constantly unstaged, but there’s a lot of git tooling that doesn’t respect my working area and dumps things in the wrong place. (And there’s a lot of people who don’t understand the point of staging at all…)
pmeunier 6y ago
This is incredibly useful for a project like Nixpkgs.
didericis 6y ago
Why don’t you add those files to .gitingore?
- kadoban 6y ago
  That only works the way you'd naively expect if the files aren't already tracked. To be explicit: gitignore has no effect at all on already-tracked files. So you end up depending on the upstream correctly foreseeing and working around this problem, or you're sunk. If the give you say a Makefile that's not correctly parameterized for you (doesn't let you adapt to your system via env variables or whatever), there's not a lot of good options unless you fix that yourself and get upstream to accept it.
  - didericis 6y ago
    In the case of a makefile already tracked with parameters incompatible with your system, fixing it to depend on some sort of input seems like something you’d want committed upstream. The fact that that’s the best option practically seems good to me, as I think it’s the best option architecturally. I don’t think it’s great to have a file committed to an upstream repo that is too particular about the machine being used when shared among multiple people. It’s better to make it so you can share it with people on different machines, and put those changes in the repo so others aren’t repeating that same work on their local machines. If you have an unresponsive upstream repo maintainer, that’s a whole problem in and of itself. Seems better to fork it in that kind of a situation rather than have a local bandaid. In the case of editor config files already tracked in the repo, I think it makes sense to remove those from being tracked, add to the gitignore, and push that upstream. Unless dealing with a team that agrees to use the same editor and wants to share settings, having editor settings committed to the repo seems like a mistake that should be corrected upstream. Same thing applies as in previous situation if the upstream maintainer is unresponsive.
hobofan 6y ago
> and stay on my toes not to accidentally push the commits You could just set the upstream of the branch to a remote that will always fail pushing to, which depending on how you usually push should make it very hard to accidentally push something. Always worked well for me.
gnufx 6y ago
With Darcs you might put some tag in the patch name which would be caught by a hook if it was accidentally pushed.

saagarjha 6y ago

Ooh, yes, I have this problem with Git too. I maintain it mostly by keeping stuff constantly unstaged, but there’s a lot of git tooling that doesn’t respect my working area and dumps things in the wrong place. (And there’s a lot of people who don’t understand the point of staging at all…)

pmeunier 6y ago

This is incredibly useful for a project like Nixpkgs.

didericis 6y ago

Why don’t you add those files to .gitingore?

kadoban 6y ago
That only works the way you'd naively expect if the files aren't already tracked. To be explicit: gitignore has no effect at all on already-tracked files. So you end up depending on the upstream correctly foreseeing and working around this problem, or you're sunk. If the give you say a Makefile that's not correctly parameterized for you (doesn't let you adapt to your system via env variables or whatever), there's not a lot of good options unless you fix that yourself and get upstream to accept it.
- didericis 6y ago
  In the case of a makefile already tracked with parameters incompatible with your system, fixing it to depend on some sort of input seems like something you’d want committed upstream. The fact that that’s the best option practically seems good to me, as I think it’s the best option architecturally. I don’t think it’s great to have a file committed to an upstream repo that is too particular about the machine being used when shared among multiple people. It’s better to make it so you can share it with people on different machines, and put those changes in the repo so others aren’t repeating that same work on their local machines. If you have an unresponsive upstream repo maintainer, that’s a whole problem in and of itself. Seems better to fork it in that kind of a situation rather than have a local bandaid. In the case of editor config files already tracked in the repo, I think it makes sense to remove those from being tracked, add to the gitignore, and push that upstream. Unless dealing with a team that agrees to use the same editor and wants to share settings, having editor settings committed to the repo seems like a mistake that should be corrected upstream. Same thing applies as in previous situation if the upstream maintainer is unresponsive.

hobofan 6y ago

> and stay on my toes not to accidentally push the commits You could just set the upstream of the branch to a remote that will always fail pushing to, which depending on how you usually push should make it very hard to accidentally push something. Always worked well for me.

gnufx 6y ago

With Darcs you might put some tag in the patch name which would be caught by a hook if it was accidentally pushed.