|
ExcessBLarg! posted:The whole point of running "git checkout ." is to discard non-staged changes. That's not a side effect, it's the only thing the command does. That's like complaining that "rm *" should warn before removing files. "git checkout branch/commit" updates the index to branch/commit for all files (and HEAD), and preserves local changes. "git checkout branch/commit $path" updates the index to branch/commit for $path files, and discards local changes. It's not saying 'rm' should warn about every use, it's saying that 'cd' and 'rm' should be different commands.
|
#
¿
Mar 1, 2014 21:15
|
|
|
|
| # ¿ May 4, 2024 00:29 |
|
|
ToxicFrog posted:For that, the natural thing to do would be to use the 'theirs' merge strategy (-s theirs, not to be confused with the 'theirs' merge option -X theirs) -- but it was removed several versions ago for some reason. The git devs recommend using git reset instead, but that'll throw away the history you want to keep. But if you want to do it anyway, how about this for a workaround: code:
|
|
#
¿
Mar 12, 2014 22:36
|
|
|
ExcessBLarg! posted:As I understand modern Windows has support for symlinks, although making use of them with git requires effort.
|
|
#
¿
Apr 21, 2014 13:04
|
|
|
HardDisk posted:I'm looking for a specific git tutorial where the author tries to illustrate git operations with actual files and folders. For example, each commit, the author copied the entire repository to a new folder, where then he explains that it is unsustainable and started copying only the changes and so on. That sounds like a weird way to start, since at a logical level git works with full snapshots and not changesets. Then it deduplicates entire files, and sometimes compresses them together, but that gives a significantly different output from copying changes as changes. Dylan16807 fucked around with this message at 19:33 on Aug 9, 2015 |
|
#
¿
Aug 9, 2015 19:30
|
|
|
Are https://xxxxxx@bitbucket.org/zzzzz/yyyyyyy.git and origin the same place? Why are you passing a full url to push?
|
|
#
¿
Mar 3, 2016 22:10
|
|
|
Arcsech posted:Yeah, you can get the original back, which is great. But my original point was that if you don't know what you're doing (see: team that has never used any form of version control), unfucking a bad rebase is not the easiest thing ever, and even if you do know what you're doing, the commands are kind of arcane. Better to just use a simpler tool that won't let them shoot themselves in the foot (as easily), given the state of the team in question. Though it's comforting to know that worst-case you can unfuck things without any commands at all. Open the reflog in a text editor, find the ID from before you broke it, copy into branch file.
|
|
#
¿
Aug 19, 2016 06:03
|
|
|
New Yorp New Yorp posted:In vanilla Git? No. Are you using a service that hosts repos? If not, start, they all allow that.
|
|
#
¿
Oct 23, 2018 19:59
|
|
|
~1, ~2, ~3 mean parent, grandparent, great-grandparent, etc. But commits can have more than one parent, like when you're merging. ~ always picks the first parent. ^1, ^2, ^3 mean first parent of this commit, second parent of this commit, third parent of this commit, etc. So they are only the same when the number is exactly 1. And if you omit the number then it assumes 1.
|
|
#
¿
Jun 10, 2019 05:32
|
|
|
Chrome is slowly rolling out a feature that lets you embed text in a link, and the browser will automatically scroll to that text and highlight it. So your problem might be solved soon, if other browsers adopt it.
|
|
#
¿
Dec 15, 2019 10:39
|
|
|
|
| # ¿ May 4, 2024 00:29 |
|
|
I want to directly note here that git can also push and pull to a shared directory.
|
|
#
¿
Oct 13, 2023 07:29
|
|