Every commit you produce should be a valid standalone version of the software. That's what we're doing after all: version control. Of course, you also want it to be easy to add whole files or hunks too, as always going line by line would be insane.Ī good commit means a good version. You want a UI that allows you to easily see the changes in your worktree and add those line by line to the index, if necessary. I don't know that any GUI is going to help junior developers with that. In the end, though, one still needs to understand Git's behavior, to some degree, to be productive and avoid creating situations which take the team's focus away from our goals. Perhaps it's time for me to start looking at the available GUIs again, so that I can make a recommendation for a solid one when someone doesn't want to use the command line. It's often followed by something like: "I ran into a problem with Git, so I just deleted the repository and cloned it again." I have had enough experience of GUIs causing problems, however, to make me nervous when I hear one is being used by a team member. There's nothing that says that a good GUI can't exist, or even be more productive than the CLI in some cases. Ultimately, I don't care what tools people use if they produce quality work and can integrate with the team without creating additional friction. This makes it difficult to help when things go awry, or when someone's having difficulty understanding how to work in the team's established workflow. Adding insult to injury, many of the Git GUIs that I've seen people work with don't use "standard" terminology, or they combine/conflate multiple actions (I'm looking at you, VS Code). As soon as something happens outside of that comfort zone, things go haywire. It has been my experience that the folks that I've worked with who only use Git from the GUI only know the absolute minimal subset of the tool to allow them to get code/changes into the CI system. I'm certainly skeptical of folks that use Git GUIs. You can also use `git replace` to temporarily replace the corrupt object with a placeholder it won't fix the commit history, but it might be useful if the corruption causes commands to fail. , in particular see -strip-blobs-with-ids). You can use a tool such as `git-filter-repo` (docs. Rewrite the history to remove/replace the corrupt object. Or you might be able to work out what the content was (if the corrupt object is a blob, aka file, you might be able to work out the content based on the previous and next versions of that file `git hash-object ` will tell you if it's exactly right, but won't give you any hints if it's slightly wrong). git/objects/, because objects can also be stored in packs). from another repository (you said the object did not appear, but I just want to point out that you should check using `git cat-file -p ` rather than by looking in. If the corruption is in a branch that you don't care about, just delete the branch. To actually fix the corruption, you have a couple of options: Once you find the referring objects, you can use `git cat-file -p ` on them to see their content, and you can repeatedly invoke this function to walk up a directory tree until you get to the enclosing commit. (My only tip is that you can search for multiple targets at once by changing the grep command to `grep -E -q "$target"` and then using `git_find_references "HASH1|HASH2|HASH3"`.) I can't think of a way to make it faster without writing actual code. Note that this function will be very slow on large repositories. (The command is similar to the one posted by but is slightly more sophisticated.) This will output the hashes and types of the objects that refer to the target. If & git cat-file -p "$hash" | grep -F -q "$target" then Git cat-file -batch-check -batch-all-objects -unordered | If || thenĮcho "usage: git_find_references " >&2 return 1 There isn't a simple and fast way to find parent objects, but here is a slow hack: I'd first check whether `git fsck` gives you more information.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |