425 Matching Annotations
  1. Last 7 days
  2. Sep 2024
  3. Jul 2024
    1. If the value of the variable is a relative path

      Meaning git config can include relative paths

  4. Jun 2024
  5. May 2024
    1. An alternative approach would be to rebase the "top" of the stack, part-3 on top of dev. We could then reset each of the branches to the "correct" commit in the newly-rebased branch, something like this:
    2. Don't think that I just naturally perfectly segment these commits when creating the feature. I heavily rebase and edit the commits before creating a PR.
  6. Apr 2024
    1. it is a really good idea to check the status before doing an add .

      maybefore, but check mainly AFTER indexing new files !

    1. To recap, I think these are my personal rebase rules I follow:

      Recommendations for doing git rebase (see bullet points below annotation)

    1. However, as we want to do perform the bisection automatically using as criterion ./calc.py 14 0, we run git bisect run ./calc.py 14 0

      git bisect run ./calc.py 14 0 ← example of running git bisect automatically. * If the commit is good, then the command should return 0; * If the commit is bad, then the command should return anything between 1 and 127, inclusive, except 125; * If it is not possible to tell if this commit is good or bad, then it need to be ignored, and the command should return 125.

    2. Git Bisect! It allows us to find the commit that broke something. Given a “good” commit (a commit that is not broken, created before the introduction of the bug), and a “bad” commit (a commit that certainly is broken), Git will perform a binary search until the broken commit is found.

      Git Bisect can be run manually or automatically

    3. What are the tools that comes on your mind when someone say “debug”? Let me guess: a memory leak detector (e.g. Valgrind); a profiler (e.g. GNU gprof); a function that stops your program and gives you a REPL (e.g. Python’s breakpoint and Ruby’s byebug); something that we call a “debugger” (like GDB, or something similar embedded on the IDEs); or even our old friend, the print function. So, in this text I’ll try to convince you to add Git to your debug toolbelt.

      6 differen debugging tools

  7. Mar 2024
  8. Feb 2024
    1. if (!stat(worktree_git_path(wt, "rebase-apply"), &st)) { if (!stat(worktree_git_path(wt, "rebase-apply/applying"), &st)) { state->am_in_progress = 1; if (!stat(worktree_git_path(wt, "rebase-apply/patch"), &st) && !st.st_size) state->am_empty_patch = 1; } else { state->rebase_in_progress = 1; state->branch = get_branch(wt, "rebase-apply/head-name"); state->onto = get_branch(wt, "rebase-apply/onto"); } } else if (!stat(worktree_git_path(wt, "rebase-merge"), &st)) { if (!stat(worktree_git_path(wt, "rebase-merge/interactive"), &st)) state->rebase_interactive_in_progress = 1; else state->rebase_in_progress = 1; state->branch = get_branch(wt, "rebase-merge/head-name"); state->onto = get_branch(wt, "rebase-merge/onto"); } else return 0; return 1;

    1. git remote set-head origin -a

      Resolved the problem I had where I mistakenly deleted this [local tracking branch]?

      ls .git/refs/remotes/origin/HEAD ls: cannot access '.git/refs/remotes/origin/HEAD': No such file or directory

    1. You should never rely on the presence or contents of anything under the .git directory. That's git's territory, not yours or the build system's. Use it's plumbing commands to get access to the information you need, rather than trying to read files directly. Git provides no guarantee about the location or contents of any of those files as far as I'm aware.
    1. The increment-after-release model makes sense for branching too. Suppose you have a mainline development branch, and you create maintenance branches for releases. The moment you create your release branch, your development branch is no longer linked to that release's version number. The development branch contains code that is part of the next release, so the version should reflect that.
    1. git diff 本身只显示尚未暂存的改动,而不是自上次提交以来所做的所有改动。

      比较的是工作目录中当前文件和暂存区域快照之间的差异,若要查看已暂存的将要添加到下次提交里的内容,可以用 git diff --staged 命令

    2. 在工作一段时间后, 它们的状态可能是未修改,已修改或已放入暂存区

      Jetbrains IDE 默认并不会开启暂存区功能,会自动都添加到暂存区

    1. git log --oneline --graph --decorate --all

      show commits of git as a tree

      To show the last 2 commits use this! git log --oneline --graph --decorate --all HEAD~2..HEAD

    2. git config --global alias.tree 'log --oneline --graph --decorate --all'

      configuration to make a shortcut to show commits of git as a tree

  9. Jan 2024
    1. Getting Started git-cliff can generate changelog files from the Git history by utilizing conventional commits as well as regex-powered custom parsers. The changelog template can be customized with a configuration file to match the desired format.

      with emacs

    1. Visual Studio Code has integrated source control management (SCM) and includes Git support out-of-the-box. Many other source control providers are available through extensions on the VS Code Marketplace

      This is an excellent resource for learing about Git integration with VS Code

  10. Dec 2023
  11. Oct 2023
  12. Sep 2023
    1. merge queue prevents semantic merge conflicts by automating the rebase process during merge, and ensuring that the trunk branch stays “green.”

      merge queue - new GitHub feature

    1. Changes not staged for commit

      修改没有舞台去提交/修改没有放到舞台/修改没有放到暂存区

    2. Changes to be committed:

      修改将被提交

    1. git add

      标记资产,需要进行版本控制的内容。

    2. $ git init

      初始化,获得/变成仓库/存储库

  13. Aug 2023
  14. Jul 2023
  15. Jun 2023
    1. Setting the proxy for Git

      git config --global --add http.proxy http://USERNAME:PASSWORD@PROXY_ADDRESS:PROXY_PORT git config --global --add https.proxy http://USERNAME:PASSWORD@PROXY_ADDRESS:PROXY_PORT

    2. Setting the proxy for other tasks

      export HTTPS_PROXY=http://USERNAME:PASSWORD@PROXY_ADDRESS:PROXY_PORT

    1. Instead of manually backtracking what changes each developer made, three-way merge does just that for us! This is because modern version control systems, such as Git, can automatically find what's known as the "nearest common ancestor", aka base revision (or merge-base). It is called "3-way" since it uses three revisions to produce a final merged version.

      3-way merge

    2. Whenever two or more developers make changes to the same file respectively and later try to fuse the versions, merge conflicts will likely occur.

      conflict definition

  16. May 2023
  17. Apr 2023
    1. In recent git versions, git restore is supposed to be a "better" way to revert undesired local changes than the overloaded checkout. Great, that sounds reasonable - a nice simple purpose-built tool for a common operation.
    1. Kilka przykładów z wykorzystujących Conventional Commits:

      Examples of Conventional Commits (see the block below)

    2. Conventional Commits – type

      Conventional Commits types: - feat - fix - docs - chore - refactor - tests - perf - styles - ci - build - revert

    3. Commity o treści refactor, added XXX czy cr fixes, to smutna i nudna rzeczywistość.
  18. Mar 2023
    1. Small Collision Probabilities

      How probable is for some git hash-ids (some chars, not the full length) to collide:

      • for a small project with ~100 commits:

        • 8 digits (32bits): 1/million
        • 7 digits (28bits): 1/54,000
        • 6 digits (24bits): 1/3,400
      • for a big project: with ~10.000 commits:

        • 8 digits: 1/100
        • 7 digits: 1/6
        • 6 digits: ~1

      As confirmed with the vecto repo, with these ipython commands: ```ipython

      !git rev-list --all --count 14042 def collissions(k,N): ...: return 1 - e((-k(k-1)/(2N)))

      collissions(14042, 16**6) 0.9971938358691735 !git rev-list --all | cut -c -6 | sort | uniq -cd 2 5af40d 2 6a6c62 2 914c24 2 d83979 2 e8060f

      collissions(14042, 16**7) 0.3073608000674162 !git rev-list --all | cut -c -7 | sort | uniq -cd 2 e8060f9

      collissions(14042, 16**8) 0.022691464724788335 !git rev-list --all | cut -c -8 | sort | uniq -cd <nothing> ```

    1. So the short answer is to pick rebase or merge based on what you want your history to look like.

      Quick summary of rebase vs merge

    1. ```sparql PREFIX wd: http://www.wikidata.org/entity/ PREFIX gist: https://ontologies.semanticarts.com/gist/ PREFIX dcterms: http://purl.org/dc/terms/

      SELECT DISTINCT ?commitTitle ?commitTime ?filename ?textLine WHERE {

      ?commit a wd:Q20058545 ; # it's a commit gist:hasPart ?part ; dcterms:subject ?commitSubject ; gist:atDateTime ?commitTime .

      ?commitSubject dcterms:title ?commitTitle .

      ?part gist:produces ?contiguousLines .

      ?contiguousLines gist:occursIn ?file ; http://example.com/containedTextContainer ?textContainer .

      ?file gist:name ?filename . ?textContainer ?line ?textLine .

      FILTER(contains(?textLine,"music")) } ```

  19. Feb 2023
    1. In very large code bases, it is likely impossible to make a change to a fundamental API and get it code reviewed by every affected team before merge conflicts force the process to start over again.
    1. Result of lots of searching on net is that pre-checkout hook in git is not implemented yet. The reason can be: There is no practical use. I do have a case It can be achieved by any other means. Please tell me how? Its too difficult to implement. I don't think this is a valid reason
  20. Jan 2023
    1. For ordinary commits, it's trivially obvious what to compare: compare this commit's snapshot to the previous (i.e., parent) commit's snapshot. So that is what git show does (and git log -p too): it runs a git diff from the parent commit, to this commit. Merge commits don't have just one parent commit, though. They have two parents.1 This is what makes them "merge commits" in the first place: the definition of a merge commit is a commit with at least two parents.
  21. Dec 2022
    1. Your changes preserved through git stash are saved in your project’s .git directory, usually, the path is /.git/refs/stash

      Location where git stash saves files

  22. Nov 2022
    1. 自己虽然有梯子,可以正常访问github页面,但是在发现“git clone”命令速度特别慢,有时还经常卡掉。本文通过设置git 代理,解决被墙问题。

      git clone 无法拉取被墙的 repo

    1. It is handy to manually generate the diagram from times to times using the previously created command: npm run db:diagram:generate. Though, getting the diagram to update itself on its own automatically without a developer interaction would ensure that it the diagram is never obsolete. There are several ways of doing this.You could use a pre-commit git hook or even better simply configure your CI/CD pipeline(s) to run the npm script whenever something gets merged into the main branch 🙂
    1. [Solved] Git: LF will be replaced by CRLF the next time Git touches it’ problem solving and thinking

      Trouble shooting git add . issue.

      Setting method one for Windows system working with others:

      git config --global core.autocrlf true

    1. You can then edit files in that repository and commit and push them like this: cd 0a30d52feeb3ff60f7d8636b0bde296b # Edit files here git commit -m "Edited some files" -a git push
    2. But if you want to be able to make local edits and then push them back, you need to use this recipe instead: git clone git@gist.github.com:0a30d52feeb3ff60f7d8636b0bde296b.git You can find this in the "Embed" menu, as the "Clone via SSH" option.
    3. You can clone them anonymously (read-only) just using their URL: git clone https://gist.github.com/simonw/0a30d52feeb3ff60f7d8636b0bde296b
    1. Changing the second line to: foo.txt text !diff would restore the default unset-ness for diff, while: foo.txt text diff will force diff to be set (both will presumably result in a diff, since Git has presumably not previously been detecting foo.txt as binary).

      comments for tag: undefined vs. null: Technically this is undefined (unset, !diff) vs. true (diff), but it's similar enough that don't need a separate tag just for that.

      annotation meta: may need new tag: undefined/unset vs. null/set

  23. Oct 2022
    1. git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main

      Probably would be better to use:

      git remote set-head origin -a

    2. git config --global init.defaultBranch main
    1. git remote set-head origin -aThe above command will query the remote host for the HEAD upstream and it updates that upstream in the local.
    1. But for all of its features, GitHub implements only a subset of git. For instance, GitHub lacks the default merge strategy of git—the fast-forward merge.
  24. Sep 2022
    1. Rename the existing default branch to the new name (main). The argument -m transfers all commit history to the new branch: git branch -m master main
    1. If we ever moved a file to a different location or renamed it, all its previous history is lost in git log, unless we specifically use git log --follow. I think usually, the expected behavior is that we'd like to see the past history too, not "cut off" after the rename or move, so is there a reason why git log doesn't default to using the --follow flag?
    1. Note: Git 2.6+ (Q3 2015) will propose that in command line: see "Why does git log not default to git log --follow?" Note: Git 2.6.0 has been released and includes this feature. Following path changes in the log command can be enabled by setting the log.follow config option to true as in: git config log.follow true
    1. If you want to replace many blobs, trees or commits that are part of a string of commits, you may just want to create a replacement string of commits and then only replace the commit at the tip of the target string of commits with the commit at the tip of the replacement string of commits.
    1. As of Git 1.6.5, the more flexible git replace has been added, which allows you to replace any object with any other object, and tracks the associations via refs which can be pushed and pulled between repos.
    1. The next step is to graft the two branches together, skipping the two commits which renamed the folder. (Otherwise there will be a weird jump where everything is deleted and recreated.)
  25. Aug 2022
    1. A related technique is git submodules, but they come with annoying caveats (for example people who clone your repository won't clone the submodules unless they call git clone --recursive),
    2. git-subtrac (from the author of the earlier git-subtree) seems to solve some of the problems with git submodules.
    3. # Do this the first time: $ git remote add -f -t master --no-tags gitgit https://github.com/git/git.git $ git subtree add --squash --prefix=third_party/git gitgit/master # In future, you can merge in additional changes as follows: $ git subtree pull --squash --prefix=third_party/git gitgit/master # And you can push changes back upstream as follows: $ git subtree push --prefix=third_party/git gitgit/master # Or possibly (not sure what the difference is): $ git subtree push --squash --prefix=third_party/git gitgit/master
  26. Jul 2022
    1. Documentación Git del comando Git restore

    2. git-restore - Restore working tree files

      Aunque dice que restablece working tree files, también restablece el Index (desde HEAD)

    1. GitHub Blog post donde se hace referencia a los nuevos comandos:

      • Git switch
      • Git restore

      Nuevos en la versión 2.23 de Git

    2. Highlights from Git 2.23
    1. Proceso para clonar una sola rama de un repositorio Git remoto
  27. Jun 2022
    1. Git also has a built-in command (maintenance) to optimize a repository’s data, speeding up commands and reducing disk space. This isn’t enabled by default, so we register it with a schedule for daily and hourly routines.

      git maintenance

    1. Remove the commit from step 2. We will merge ignoring the failure. Remove the commit from the other, check it passes with the other commit now on main. Merge the other. We will trigger builds for the main branch of affected repositories to check if everything is in order. Steps 5-8 should happen continuously (e.g. one after another but within a short timespan) so that we don't leave a broken main around. It is important to triage that build process and revert if necessary.

      It is important to not leave a broken main around.

  28. May 2022
    1. git diff-tree -p COMMIT

      command to show code change in given commit

    2. git show COMMIT --compact-summary

      command to show code change in given commit

    3. git diff <root_commit>^!

      command to show code change of one commit: git diff <root_commit>^ git diff <root_commit>^!

    1. You could also start a new email with the contents of this file, by making x-success use the mailto: scheme with something like working-copy://x-callback-url/read/?repo=my%20repo&path=README.md&x-success=mailto%3A%3Fbody%3D If you need to debug your callbacks, setting x-success=mailto%3A%3Fbody%3D

      Holy god in fuck...

    1. A properly formed Git commit subject line should always be able to complete the following sentence:If applied, this commit will your subject line hereFor example:If applied, this commit will refactor subsystem X for readability

      An example how to always aim for imperative commits

    2. Git itself uses the imperative whenever it creates a commit on your behalf.For example, the default message created when using git merge reads:Merge branch 'myfeature'

      Using imperative mood in subject line of git commits

    3. Commit messages with bodies are not so easy to write with the -m option. You’re better off writing the message in a proper text editor.

      I've tested it on Windows, and in PowerShell or Git Bash it is as simple as:

      ```console git commit -m "Subject line<ENTER>

      body line 1 body line 2"<ENTER> ```

      However, it does not work in CMD.exe (pressing [ENTER] will not move to the next line)

    4. Firstly, not every commit requires both a subject and a body. Sometimes a single line is fine, especially when the change is so simple that no further context is necessary.

      Not every commit requires a body part

    5. Summarize changes in around 50 characters or less More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of the commit and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); various tools like `log`, `shortlog` and `rebase` can get confused if you run the two together. Explain the problem that this commit is solving. Focus on why you are making this change as opposed to how (the code explains that). Are there side effects or other unintuitive consequences of this change? Here's the place to explain them. Further paragraphs come after blank lines. - Bullet points are okay, too - Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary here If you use an issue tracker, put references to them at the bottom, like this: Resolves: #123 See also: #456, #789

      Example of a great commit message

    6. Separate subject from body with a blank lineLimit the subject line to 50 charactersCapitalize the subject lineDo not end the subject line with a periodUse the imperative mood in the subject lineWrap the body at 72 charactersUse the body to explain what and why vs. how

      7 rules of great commit messages

    7. What may be a hassle at first soon becomes habit, and eventually a source of pride and productivity for all involved.
    8. Commit messages can do exactly that and as a result, a commit message shows whether a developer is a good collaborator.
    9. A diff will tell you what changed, but only the commit message can properly tell you why.

      Commit messages are important

    10. Look at Spring Boot, or any repository managed by Tim Pope.
  29. Apr 2022
    1. The eagle-eyed among you may notice that there isn't a .git directory in the app-example-2 working tree. Instead, there's a .git file. This file points to the git directory in the original clone, and it means that all your usual git commands work inside the app-example-2 directory, as well as in the original app-example directory.

      The working of git worktree

    2. Anecdotally, I've found IDEs get much less "confused" if you use their built-in support for switching git branches, instead of changing them from the command line and waiting for the IDE to "notice" the changes.
    1. GIT_INDEX_FILE is the path to the index file (non-bare repositories only).

      export GIT_INDEX_FILE=".git/index.linux" if you are working on Linux

      export GIT_INDEX_FILE=".git/index.windows" if you are working on Linux

  30. Mar 2022
    1. Flatpak is built on top of a technology called OSTree, which is influenced by and very similar to the Git version control system. Like Git, OSTree allows versioned data to be tracked and to be distributed between different repositories. However, where Git is designed to track source files, OSTree is designed to track binary files and other large data.
    2. Internally, Flatpak therefore works in a similar way to Git, and many Flatpak concepts are analogous to Git concepts. Like Git, Flatpak uses repositories to store data, and it tracks the differences between versions.
    1. The underlying architecture might be summarized as “git for operating system binaries”.