259 Matching Annotations
  1. Last 7 days
    1. Here are the impressive detailed statistics from their repository as of 2015, for which more recent data is challenging to obtain.

      Interesting statistics (mostly inside diagrams) from 2015 on Google's big [[monorepo]] (which is NOT git).

  2. Nov 2021
    1. git ls-files is more than 5 times faster than both fd --no-ignore and find

      git ls-files is the fastest command to find entries in filesystem

    1. The overall flow of Gitflow is: A develop branch is created from main A release branch is created from develop Feature branches are created from develop When a feature is complete it is merged into the develop branch When the release branch is done it is merged into develop and main If an issue in main is detected a hotfix branch is created from main Once the hotfix is complete it is merged to both develop and main

      The overall flow of Gitflow

  3. Oct 2021
    1. Hotfix branches are a lot like release branches and feature branches except they're based on main instead of develop. This is the only branch that should fork directly off of main. As soon as the fix is complete, it should be merged into both main and develop (or the current release branch), and main should be tagged with an updated version number.

      Hotfix branches

    2. Once develop has acquired enough features for a release (or a predetermined release date is approaching), you fork a release branch off of develop. Creating this branch starts the next release cycle, so no new features can be added after this point—only bug fixes, documentation generation, and other release-oriented tasks should go in this branch. Once it's ready to ship, the release branch gets merged into main and tagged with a version number. In addition, it should be merged back into develop, which may have progressed since the release was initiated.

      Release branch

    3. feature branches use develop as their parent branch. When a feature is complete, it gets merged back into develop. Features should never interact directly with main.

      Feature branches should only interact with a develop branch

    4. When using the git-flow extension library, executing git flow init on an existing repo will create the develop branch

      git flow init will create:

      • feature branch
      • release branch
      • hotfix branch
      • support branch
    1. The main condition that needs to be satisfied in order to use OneFlow is that every new production release is based on the previous release. The most difference between One Flow and Git Flow that it not has develop branch.

      Main difference between OneFlow and Git Flow

    2. The most difference between GitLab Flow and GitHub Flow are the environment branches having in GitLab Flow (e.g. staging and production) because there will be a project that isn’t able to deploy to production every time you merge a feature branch

      Main difference between GitLab Flow and GitHub Flow

    3. 4 branching workflows for Git
      1. Git Flow
      2. GitHub Flow
      3. GitLab Flow
      4. One Flow
    4. release-* — release branches support preparation of a new production release. They allow many minor bug to be fixed and preparation of meta-data for a release. May branch off from develop and must merge into master anddevelop.

      release branches

    5. hotfix-* — hotfix branches are necessary to act immediately upon an undesired status of master. May branch off from master and must merge into master anddevelop.

      hotfix branches

    6. feature-* — feature branches are used to develop new features for the upcoming releases. May branch off from develop and must merge into develop.

      feature branches

  4. Sep 2021
  5. Aug 2021
    1. This one implements the behavior of git checkout when running it only against a branch name. So you can use it to switch between branches or commits.

      git switch <branch_name>

    2. When you provide just a branch or commit as an argument for git checkout, then it will change all your files to their state in the corresponding revision, but if you also specify a filename, it will only change the state of that file to match the specified revision.

      git checkout has a 2nd option that most of us skipped

    3. if you are in the develop branch and want to change the test.txt file to be the version from the main branch, you can do it like this

      git chekout main -- test.txt

  6. Jul 2021
    1. rebase is really nothing more than a merge (or a series of merges) that deliberately forgets one of the parents of each merge step.

      What rebase really is

  7. Jun 2021
    1. To try and make things a little bit more secure, Githooks checks if any new hooks were added we haven't run before, or if any of the existing ones have changed
    2. git diff --cached --diff-filter=ACMR --name-only
    1. To address this problem, I offer git undo, part of the git-branchless suite of tools. To my knowledge, this is the most capable undo tool currently available for Git. For example, it can undo bad merges and rebases with ease, and there are even some rare operations that git undo can undo which can’t be undone with git reflog.

      You can use git undo through git-brancheless. There's also GitUp, but only for macOS

    1. From pretty format documentation: '%w([<w>[,<i1>[,<i2>]]])': switch line wrapping, like the -w option of git-shortlog[1]. And from shortlog: -w[<width>[,<indent1>[,<indent2>]]] Linewrap the output by wrapping each line at width. The first line of each entry is indented by indent1 spaces, and the second and subsequent lines are indented by indent2 spaces. width, indent1, and indent2 default to 76, 6 and 9 respectively. If width is 0 (zero) then indent the lines of the output without wrapping them.
    1. There are many projects that does not use the master branch as default. For example, Next.js uses the canary branch, the npm CLI and many more other projects uses stuff like prod, production, dev, develop, release, beta, head.
    2. I'm not sure if there's any cost in terms of contributing either, especially when by design git can have any branch as default, and will not hinder your experience when you use something other than master.

      git is neutral/unbiased/agnostic about default branch name by design

      And that is a good thing

    3. The primary branch in git can have any name by design.
    4. In the context of git, the word "master" is not used in the same way as "master/slave". I've never known about branches referred to as "slaves" or anything similar.
  8. May 2021
    1. Normally, git diff looks for non-printable characters in the files and if it looks like the file is likely to be a binary file, it refuses to show the difference. The rationale for that is binary file diffs are not likely to be human readable and will probably mess up your terminal if displayed. However, you can instruct git diff to always treat files as text using the --text option. You can specify this for one diff command: git diff --text HEAD HEAD^ file.txt You can make Git always use this option by setting up a .gitattributes file that contains: file.txt diff
    1. If you insist on using Git and insist on tracking many large files in version control, you should definitely consider LFS. (Although, if you are a heavy user of large files in version control, I would consider Plastic SCM instead, as they seem to have the most mature solution for large files handling.)

      When the usage of Git LFS makes sense

    2. In Mercurial, use of LFS is a dynamic feature that server/repo operators can choose to enable or disable whenever they want. When the Mercurial server sends file content to a client, presence of external/LFS storage is a flag set on that file revision. Essentially, the flag says the data you are receiving is an LFS record, not the file content itself and the client knows how to resolve that record into content.

      Generally, Merculiar handles LFS slightly better than Git

    3. If you adopt LFS today, you are committing to a) running an LFS server forever b) incurring a history rewrite in the future in order to remove LFS from your repo, or c) ceasing to provide an LFS server and locking out people from using older Git commits.

      Disadvantages of using Git LFS

    1. :/<text>, e.g. :/fix nasty bug A colon, followed by a slash, followed by a text, names a commit whose commit message matches the specified regular expression.

      :/<text> - searching git commits using their text instead of hash, e.g. :/fix nasty bug

    1. git worktree add <path> automatically creates a new branch whose name is the final component of <path>, which is convenient if you plan to work on a new topic. For instance, git worktree add ../hotfix creates new branch hotfix and checks it out at path ../hotfix.

      The simple idea of git-worktree to manage multiple working trees without stashing

    1. Preserving history; we often find ourselves using the git blame tool to discover why a certain change was made.
    2. Preserving commit hashes; we use commit hashes in binary names and our issue tracker; ideally, these references remain intact.
    1. New changes to the old repositories can be imported into the monorepo and merged in. For example, in the above example, say repository one had a branch my_branch which continued to be developed after the migration. To pull those changes in:
    1. [Old commit references] Provide a way for users to use old commit IDs with the new repository (in particular via mapping from old to new hashes with refs/replace/ references).
    2. Let's say that we want to extract a piece of a repository, with the intent on merging just that piece into some other bigger repo.
    1. If you want the project's history to look as though all files have always been in the directory foo/bar, then you need to do a little surgery. Use git filter-branch with the "tree filter" to rewrite the commits so that anywhere foo/bar doesn't exist, it is created and all files are moved to it:
  9. Apr 2021
    1. 🐛 (home, components): Resolve issue with modal collapses 🚚 (home): Move icons folder ✨ (newsletter): Add Newsletter component

      With gitmojis, we can replace the <type> part of a git commit

    2. feat(home, components): Add login modal fix(home, components): Resolve issue with modal collapses chore(home): Move icons folder

      Examples of readable commits in the format:

      <type> [scope]: "Message"

  10. Mar 2021
  11. Feb 2021
    1. The transclusion doesn't automatically change along with it. If transclusions were direct embeds of the original content, we'd end up with link rot on a whole new scale. Every document would be a sad compilation of 404's.

      Thinking about Git repositories, this is how submodules work. you 'freeze' the 'transclusion' to one exact commit and can update if and when needed. Moreover, the contents are stored within the local repository, so they are future-proof.

  12. Jan 2021
    1. master

      Tive problemas ao executar o deploy porque este repo por ser novo já usa o padrao de "main" para o nome da branch principal.

      $ git push heroku main

  13. Dec 2020
    1. Less developer maintenance burden: The existing (Kuma) platform is complex and hard to maintain. Adding new features is very difficult. The update will vastly simplify the platform code — we estimate that we can remove a significant chunk of the existing codebase, meaning easier maintenance and contributions.
    1. Does anyone know how to make npm use a specific fork containing a bug fix while waiting for maintainer to merge a pull request? I was just going to point my package.json to this fork, like this: "svelte-material-ui": "https://github.com/vtpatrickeddy/svelte-material-ui.git#patch-1", but that doesn't work because the repo is a monorepo. And there doesn't appear to be a way to specify a subdirectory inside it, like: "@smui/textfield": "https://github.com/vtpatrickeddy/svelte-material-ui.git/packages/textarea#patch-1",
    1. $ git log --grep "commit message search"

      git blame: searching commit messages themselves with grep

    2. $ git log -S "deleted code" -p

      git blame: way to find deleted piece of code

    3. $ git log -S "some code" -p app/models/user.rb

      git blame: limiting search to a specific folder

    4. $ git log -G "REGEX HERE"

      git blame: searching with a regular expression

    5. Find the entire history of a snippet of code with git log -S Include -p to see the diff as well as the commit messages Include --reverse to see the commit that introduced the code listed first Scope search to specific folders or files by including a path Search with a regular expression using git log -G Search commit messages using git log --grep

      Summary of git blame searching tips

    6. If you include the -p option (short for --patch) you get the full diff alongside the commit messages

      git log -S "method_name" -p <--- get the full dif with commit messages to have more context

    7. Say you want to find the first commit that introduced a particular class, method or snippet of code. You can use the pickaxe combined with the --reverse option to get the commits in reverse-chronological order so the commit where the code first appears is listed at the top

      git log -S "method_name" -p --reverse <--- get commits in reverse-chronological order

    8. git log -S (also known as “the pickaxe”) is how you take things to the next level. It lets you search for all commits that contain a given string:

      git log -S <--- search for commits with a given string

    9. git blame is too coarse: it reports against the whole line. If the most recent change isn’t related to the part of the line you’re interested, you’re out of luck. git blame is too shallow: it only reports a single change; the most recent one. The story of the particular piece of code you’re interested in may have evolved over several commits. git blame is too narrow: it only considers the file you are running blame against. The code you are interested in may also appear in other files, but to get the relevant commits on those you’ll need to run blame several times.

      Disadvantages of git blame command (it's like limiting ourselves to 2D view instead of 3D

  14. Nov 2020
    1. I feel that with all that power that it’s gaining, instead of being a more approachable tool, that it’s actually being a tool that is continuously making people feel frustrated, to the point where I feel that whatever the next version control system is… (And it does not have to be something separate than Git. It should maybe be just a really powerful abstraction built on top of Git.) But I think whatever the next iteration of the people’s version control is… it should be something that is more reflective of how we think about what version control is for us.
    1. master

      une mobilisation parallèle dans le milieu des technologies a eu lieu pour retirer les références à caractère opprimant, mobilisation qui a refait surface avec la poussée du mouvement Black Lives Matter.

      par exemple, une recommandation consiste à nommer «main» ou «primary» la branche principale (au lieu de «master»).

    1. master

      une mobilisation parallèle dans le milieu des technologies a eu lieu pour retirer les références à caractère opprimant, mobilisation qui a refait surface avec la poussée du mouvement Black Lives Matter.

      par exemple, une recommandation consiste à nommer «main» ou «primary» la branche principale (au lieu de «master»).

    1. For example, suppose you want to search for the string "font-size: 52 px;" in your repository: $ git rev-list –all | xargs git grep -F ‘font-size: 52 px;’

      Searching Git repo with grep

    2. $ git show main:README.md Once you execute this command, you can view the content of the file in your terminal.

      You can view the README.md file while being in any branch

    3. Every repository has a .git folder. It is a special hidden folder. $ ls -a . … .git

      Inside the hidden .git folder, you may find:

      1. The current state of HEAD:

      $ cat .git/HEAD ref: refs/heads/master

      1. Potentially a description of your repo:

      $ cat .git/description

    4. To optimize your repository further, you can use Git garbage collection. $ git gc --prune=now --aggressive This command helps when you or your team heavily uses pull or push commands.

      You can optimise your repo not only with .gitignore file, but with Git garbage collection.

      This command is an internal utility that cleans up unreachable or "orphaned" Git objects in your repository

    5. Git, along with some Bash command piping, makes it easy to create a zip archive for your untracked files. $ git ls-files --others --exclude-standard -z |\ xargs -0 tar rvf ~/backup-untracked.zip

      Taking backup of untracked files.

      This command makes an archive (and excludes files listed in .gitignore) with the name backup-untracked.zip

    6. $ git rev-list –count master 32

      Example of counting the number of commits with

      git rev-list --count

    7. Many developers count the number of commits to judge when to increment the build number, for instance, or just to get a feel for how the project is progressing.

      Why to count the number of commits

    8. To avoid similar scenarios, enable Git autocorrection in your Git configuration: $ git config --global help.autocorrect 1

      Applying autocorrection in Git.

      When you type: git stats, instead of suggesting a command, it will run git status automatically

  15. Oct 2020
    1. When you can assume that all the materials you’re using in and with your class are open educational resources, here’s one way to remix the effective practices listed above with OER in order to provide you and your students with opportunities to spend your time and effort on work that makes the world a better place instead of wasting it on disposable assignments.

      As I think of remix, reuse, redistribute and things like git and version control, I also can't help but think that being able to send and receive webmentions in the process of reusing and redistribution with referential links back to the originals will allow the original creator to at least be aware of the changes and their existence to potentially manually add them to the original project. (Manually because they may not (yet) know how to keep their content under source control or allow others to do so and send pull requests.)

    2. Free to accessFree to reuseFree to reviseFree to remixFree to redistributeThe question becomes, then, what is the relationship between these additional capabilities and what we know about effective teaching and learning? How can we extend, revise, and remix our pedagogy based on these additional capabilities?

      I look at this and think immediatly about the Git model of allowing people to not only fork and reuse/redistribute pieces, but what about the ability to do pull requests to take improvements and push them back up the the source so that everyone potentially benefits?

    1. git push origin master explicitly says "push the local branch 'master' to the remote named 'origin'". This does not define a persistent relationship, it just executes a push this one time. Note that the remote branch is assumed to be named "master". git push -u origin master is the same thing, except it first adds a persistent tracking relationship between your local branch "master" and the remote named "origin". As before, it is assumed the remote branch is named "master". If you have done a push with -u already, then the relationship is already defined. In the future, you can simply say git push or git pull, and git will automatically use the defined remote tracking branch without being told explicitly. You can view your tracking relationships with git branch -vv, which will list your local branches along with their current HEAD commit and, if one is set, the remote tracking branch. Here is an example.
  16. Sep 2020
    1. Examining the changes to programs over time is a useful strategy for under-standing the life of the code

      ce que permet notamment le numérique aisément, voire fluidement ou même nativement (avec des logiciels et protocoles comme Git): le versionnement, l'archivage des versions, le marquage volontaire v1, v2 v3.57 comme Kittler…

    1. For a non-monorepo package you can simply point directly to the Github repo. This case is similar, but you want to scope it just to a single package within the repo. For those that make monorepos they don't necessarily need this feature. It's for those that use projects that use monorepos. Telling them to not organize their projects into monorepos doesn't help people who make use of these projects.
    2. If npm installs a git repo, it assumes that the git repo is the package. I don't really know how we could specify a sub-path easily, since all parts of the git url are already used for other things.
    1. This is more a rhetoric question as this seems to be quite hard ;-) There is a long discussion about installing a subfolder of a repository and monorepos in general at the NPM Github issues (yarn misses this feature, too). The thing is that this makes it quite hard to report issues of your project as one can't test the current master easily. Do you recommend a way how to use the latest Github version?
  17. Aug 2020
    1. Would you really forget to push your code if that triggers a rocket launch?

      Git-rocket (VS Code extension).

      Lol :D

    1. Don’t forget to tell Git who you are, add this cell so you don’t have to answer every time you commit during a new session!

      Authenticate yourself with GitHub:

      !git config --global user.email <YOUR EMAIL>
      !git config --global user.name <YOUR NAME>
      
  18. Jul 2020
    1. "that text has been removed from the official version on the Apache site." This itself is also not good. If you post "official" records but then quietly edit them over time, I have no choice but to assume bad faith in all the records I'm shown by you. Why should I believe anything Apache board members claim was "minuted" but which in fact it turns out they might have just edited into their records days, weeks or years later? One of the things I particularly watch for in modern news media (where no physical artefact captures whatever "mistakes" are published as once happened with newspapers) is whether when they inevitably correct a mistake they _acknowledge_ that or they instead just silently change things.
    2. If the reality is you pushed out a release that doesn't even compile, and then you spotted the typo six minutes later, that's fine, that's what the git repo should show. Don't come to me asking if there's a way to change history so that it seems as if it didn't happen that way. How does that help anybody?

      To answer your question:

      How does that help anybody?

      It keeps the history clean.

      Assuming they push up an amended commit minutes after the bad commit, this shouldn't cause too much of a problem. (Depends how many people are working on it and how often they git pull.)

      How does it help anyone to keep 2 separate commits that, semantically, could and should have been just 1? How does it help anyone to have a permanent record of someone's mistake?

      If it can be easily and quickly fixed, I say go for it!

    1. If we do not care about untracked files in the working directory, we can use the --untracked-files=no option to disregard those:
    1. This commit does not belong to any branch on this repository.

      How would I download this commit/changeset with a git client then?? Or is it simply the case that if someone ever deletes the source branch for a merge request and "orphans" those commits, that there is now no longer a way to download it via the usual git fetch methods and the only way now to view these commits is via the web interface?

      Idea: Create a permanent tag for every version of every pull request that gets pushed up. (Which maybe the already do internally to prevent it from being GC'd?)

      https://github.com/ruby/ruby/pull/1758

      Ana06 deleted the Ana06:array-diff branch on Apr 30, 2019

  19. Jun 2020
    1. uses a pre-clone step to seed the project with a recent archive of the repository. This is done for several reasons: It speeds up builds because a 800 MB download only takes seconds, as opposed to a full Git clone.
  20. May 2020
    1. After the initial backup, future backups are differential, both in the files that are transferred and the files that are stored on your behalf.

      I guess git can help with the differential part of the backup, but how exactly does it? In order for it to help with transfer from the subject server, wouldn't it have to keep the git repo on that server? Otherwise wouldn't it have to transfer everything to the remote cloud git repo so that git can do the diff there?

      Makes me wonder if simple rsync wouldn't be more efficient than all this.

    2. the files are then transferred over the to git repository onto the cloud server.
    1. git describe [--tags] describes the current branch in terms of the commits since the most recent [possibly lightweight] tag in this branch's history. Thus, the tag referenced by git describe may NOT reflect the most recently created tag overall.
    1. What I think we're lacking is proper tooling, or at least the knowledge of it. I don't know what most people use to write Git commits, but concepts like interactive staging, rebasing, squashing, and fixup commits are very daunting with Git on the CLI, unless you know really well what you're doing. We should do a better job at learning people how to use tools like Git Tower (to give just one example) to rewrite Git history, and to produce nice Git commits.
  21. Apr 2020
    1. Notebook files, however, are essentially giant JSON documents that contain the base-64 encoding of images and binary data. For a complex notebook, it would be extremely hard for anyone to read through a plaintext diff and draw meaningful conclusions—a lot of it would just be rearranged JSON and unintelligible blocks of base-64.

      Git traces plaintext differences and with notebooks it's a problem

    2. There is no hidden state or arbitrary execution order in a YAML file, and any changes you make to it can easily be tracked by Git

      In comparison to notebooks, YAML is more compatible for Git and in the end might be a better solution for ML

    1. git commit --amend --author="John Doe <john@doe.org>"

      Update the author for a git commit