3 ms·

have you ever worked with other people on the same project? or Gerrit? There's really nothing simple, quick or logical about Git when you need to do things lik

have you ever worked with other people on the same project? or Gerrit? There's really nothing simple, quick or logical about Git when you need to do things like: copy some files from another repo into yours while preserving file history copying files within a repo while preserving file history (if you just copy+paste you lose, if you edit the files after moving with git mv, but before comitting the move first, you lose all history) deleting 1 file from all commits in a repo (almost impossible without using an external non-git tool) dealing with a rebase that was pushed that shouldn't have happened I could go on and on with examples of things that should be trivial but aren't.

WorkerBee28474 2y ago
> deleting 1 file from all commits in a repo (almost impossible without using an external non-git tool) That seems like the exact opposite of the purpose of version control.
- anonymoushn 2y ago
  It ends up being a worthwhile thing to do if someone has checked in a large file that shouldn't be in git or whatever
- tverbeure 2y ago
  Somebody accidentally checks in an AWS private key and it gets found out much later.
  - JohnMakin 2y ago
    Then removing it from history doesn’t do anything because you already need to rotate the key
- Smithalicious 2y ago
  The classic example is accidentally committing a binary file or some other large-as-in-filesize garbage -- simply deleting the file preserves it in history, bloating the size of the repo.
JohnMakin 2y ago
> have you ever worked with other people on the same project? or Gerrit? There's really nothing simple, quick or logical about Git when you need to do things like: Yes, I currently manage my team's merge process and review all code that gets merged into our main repository. I tend to only do trunk-based repositories, work mostly in infrastructure, so I imagine my process is a little different than some traditional "dev" ones, but it's largely uncomplicated on my 5 person team. > copy some files from another repo into yours while preserving file history I'm not really sure what this means - I don't often have to do this, can't imagine why I would have to do this. If by "file history" you mean the commits on the file from the other repo? I can't imagine why I'd do that and it sounds like an anti pattern to me, and I avoid doing things like that at all costs, or would just create a git submodule if I really, really had to have that history and file in my repo for whatever reason. > copying files within a repo while preserving file history (if you just copy+paste you lose, if you edit the files after moving with git mv, but before comitting the move first, you lose all history) Really never have felt a need for doing this in any repository I've worked in so I guess no, for similar reasons as my above comment > deleting 1 file from all commits in a repo (almost impossible without using an external non-git tool) Why would you have to do this with any kind of frequency? If I did, and it was sufficiently complicated, I would put it in automation and write it once and call it a day. > dealing with a rebase that was pushed that shouldn't have happened I'm seeing now from other comments what the difference here is, I don't really ever use rebase and never have felt the need to. If I ever worked for a team where I didn't get to decide that, we had tooling that managed that part or wrote it. > I could go on and on with examples of things that should be trivial but aren't. I am a little curious, because some of what you wrote sounds a little bizarre to me, but I guess I'm probably in a much different domain.
Izkata 2y ago
> copying files within a repo while preserving file history (if you just copy+paste you lose, if you edit the files after moving with git mv, but before comitting the move first, you lose all history) This is much closer a description to svn (and probably other systems), and doesn't describe git at all. Git doesn't store file renames. It reconstructs them from the history based on how similar an "add" and a "delete" were in the same commit. There's even args to change the sensitivity and look for line sources in even broader scopes* - which means git can do one thing others can't, show you where lines came from when two or more files were merged. Others can only show you one of the source files, the one that was explicitly renamed. * See "-C" in "git help blame", the broadest scope even looks for the source in other commits.
- g-b-r 2y ago
  Except that it can't, and doesn't, always work
  - bboygravity 2y ago
    Exactly. I have never ever had an OS "cut-paste" operation work in a way that git didn't see as entirely new files that it never saw before. If it did work like that, there would be no reason whatsoever for the "git mv" command to exist.

WorkerBee28474 2y ago

> deleting 1 file from all commits in a repo (almost impossible without using an external non-git tool) That seems like the exact opposite of the purpose of version control.

anonymoushn 2y ago
It ends up being a worthwhile thing to do if someone has checked in a large file that shouldn't be in git or whatever
tverbeure 2y ago
Somebody accidentally checks in an AWS private key and it gets found out much later.
- JohnMakin 2y ago
  Then removing it from history doesn’t do anything because you already need to rotate the key
Smithalicious 2y ago
The classic example is accidentally committing a binary file or some other large-as-in-filesize garbage -- simply deleting the file preserves it in history, bloating the size of the repo.

JohnMakin 2y ago

> have you ever worked with other people on the same project? or Gerrit? There's really nothing simple, quick or logical about Git when you need to do things like: Yes, I currently manage my team's merge process and review all code that gets merged into our main repository. I tend to only do trunk-based repositories, work mostly in infrastructure, so I imagine my process is a little different than some traditional "dev" ones, but it's largely uncomplicated on my 5 person team. > copy some files from another repo into yours while preserving file history I'm not really sure what this means - I don't often have to do this, can't imagine why I would have to do this. If by "file history" you mean the commits on the file from the other repo? I can't imagine why I'd do that and it sounds like an anti pattern to me, and I avoid doing things like that at all costs, or would just create a git submodule if I really, really had to have that history and file in my repo for whatever reason. > copying files within a repo while preserving file history (if you just copy+paste you lose, if you edit the files after moving with git mv, but before comitting the move first, you lose all history) Really never have felt a need for doing this in any repository I've worked in so I guess no, for similar reasons as my above comment > deleting 1 file from all commits in a repo (almost impossible without using an external non-git tool) Why would you have to do this with any kind of frequency? If I did, and it was sufficiently complicated, I would put it in automation and write it once and call it a day. > dealing with a rebase that was pushed that shouldn't have happened I'm seeing now from other comments what the difference here is, I don't really ever use rebase and never have felt the need to. If I ever worked for a team where I didn't get to decide that, we had tooling that managed that part or wrote it. > I could go on and on with examples of things that should be trivial but aren't. I am a little curious, because some of what you wrote sounds a little bizarre to me, but I guess I'm probably in a much different domain.

Izkata 2y ago

> copying files within a repo while preserving file history (if you just copy+paste you lose, if you edit the files after moving with git mv, but before comitting the move first, you lose all history) This is much closer a description to svn (and probably other systems), and doesn't describe git at all. Git doesn't store file renames. It reconstructs them from the history based on how similar an "add" and a "delete" were in the same commit. There's even args to change the sensitivity and look for line sources in even broader scopes* - which means git can do one thing others can't, show you where lines came from when two or more files were merged. Others can only show you one of the source files, the one that was explicitly renamed. * See "-C" in "git help blame", the broadest scope even looks for the source in other commits.

g-b-r 2y ago
Except that it can't, and doesn't, always work
- bboygravity 2y ago
  Exactly. I have never ever had an OS "cut-paste" operation work in a way that git didn't see as entirely new files that it never saw before. If it did work like that, there would be no reason whatsoever for the "git mv" command to exist.