Re: [git-users] Re: Feature Request - Branch Metadata or Descriptions
On 19.07.22 10:32, Uwe Brauer wrote: Isn't it what you are proposing, what mercurial would call a «named branch»? … and couldn't you just tag the feature branch "feature/FUBAR" before merging, thereby accomplishing much the same thing? -- -- regards -- -- Matthias Urlichs -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/452a8844-2026-175c-7bc0-11dd0b4a8082%40urlichs.de. null OpenPGP_signature Description: OpenPGP digital signature
Re: [git-users] CRLF files on Linux
On 24.01.22 10:53, Konstantin Khomoutov wrote: Yes: setting both core.autocrlf to "false" and core.eol to "crlf" should defeat Git's EOL normalizations. The problem is that I don't want to defeat it. I want to apply it in the other direction. My problem is: the project I'm working on originated on DOS, all text files have been checked in with DOS line endings, and that isn't going to change (i.e. a monster commit that replaces every CRLF with LF, project-wide, isn't in the cards). However, I want to process the files with standard Linux programs and standard editor settings, without seeing a heap of spurioous ^M characters at the end of every second line. I also don't want to accidentally add a file with LF endings to the index. (Yes that can be prevented with hooks, but that's a partial and sub-optimal solution.) -- -- Matthias Urlichs -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/2223af74-3696-7d9b-0275-8652cee74fb0%40urlichs.de. <> OpenPGP_signature Description: OpenPGP digital signature
Re: [git-users] How does Git storing entire files rather than deltas make it superior?
On 02.11.19 16:20, Konstantin Khomoutov wrote: > how does it become > superior to a VCS by storing snapshots rather than deltas? Deltas based on what? As soon as there are merge operations, you either run into ambiguities or the code is forced to prefer one branch over the other. Branches and branch selection and whatnot thus become first-class citizens in that VCS. You don't want that to happen because branches are incidental and don't matter to the user: the state of your repository is not affected by whether you merged A into B or vice versa. Also, one of git's basic tenets is that every file (and directory and commit and …) is identified by the hash of its contents. Thus you can immediately detect if two files (or directories or …) are the same: their hash is identical. This in turn allows you to quickly identify common sub-trees between *any* two commits immediately, without requiring examination of subtrees. Contrast with delta storage where you always need to re-assemble the whole tree as soon as the situation becomes non-trivial. In a complex repository like the Linux kernel, with its thicket of multiple merges, trivial situations are the exception rather than the rule. -- -- Matthias Urlichs -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/5f1df930-a91e-329b-6cfd-d3d82866d9c7%40urlichs.de.
Re: [git-users] Recover partially ignored file deleted by branch checkout?
On 03.11.18 09:40, j...@tcs.ifi.lmu.de wrote: > @Matthias Urlichs: The file had been comitted to the repository > initially. It was only added to .gitignore much later on, when other > users complained. Ah. Sorry, I missed that. You're right – this is a bug. My reasoning for that assessment is that if you check out any commit before the one that added the currently-ignored file and *then* check out the "problem" commit with the old version, you get an error message. However, intermediate checkout steps should not affect the result. Please submit an issue. -- -- Matthias Urlichs -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Recover partially ignored file deleted by branch checkout?
On 02.11.18 18:12, j...@tcs.ifi.lmu.de wrote: > The file is heavily edited, but ignored by commits as expected. Last time I checked (which was half a minute ago), files in .gitignore are only ignored for the purpose of not adding them to the archive. Modifying such a file, editing it, and then "git commit -a"ing the archive will, however, check in your changes. Thus your scenario does not happen. $ git init $ echo a >a $ git add a $ git commit -m Initial $ echo b >b $ echo b >.gitignore $ git add -f .gitignore b $ git commit -m NoB $ echo bla >b $ git commit -a -m foo $ git show commit 1b60a5792732e45c685bcced51b6c754d9833530 (HEAD -> master) Author: Matthias Urlichs Date: Fri Nov 2 20:10:43 2018 +0100 foo diff --git a/b b/b index 6178079..a7f8d9e 100644 --- a/b +++ b/b @@ -1 +1 @@ -b +bla $ -- -- Matthias Urlichs -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
