When I sign a git commit, what is my signature actually based on?

I took a look at the function “commit_tree_extended” in the git source code for the file “commit.c” (e.g., in this blob).

Based on reviewing this function, when you sign a commit it seems to be signing a string that contains identifiers for the tree object_id, parent object_id, author, committer, encoding (if not utf-8), commit_extra_header, and the commit message.

git – How can I check the timestamp of a remote commit without cloning the repository?

There is a Git sub-command called ls-remote which allows listing of all the branches and commit hashes of the leaf node/tip of each branch.

How can I also query the timestamp of those commits, or other related information of the commit, without cloning the repo locally? (or, is there no way to do this without cloning the repo)

Dois pontos após usar o git diff –cached

Sempre que uso o comando git diff –cached ele abre dois pontos e sempre que tento sair eu não consigoinserir a descrição da imagem aqui

git – Sobrescribir un repositorio gitlab

Coloqué mi repositorio GitHub /repo1 en una carpeta /all_repos que contiene dos otros y que deve convertirse en el repositorio. Entonces me gustaría sobrescribir el repositorio original con esta nueva architectura. Lamentablemente, todos mis intentos han fracasado. Hasta hoy intenté:

C:UsersantoiPycharmProjectsBass>git status
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
  (commit or discard the untracked or modified content in submodules)
        modified:   scraper (modified content)
        modified:   webapp (modified content, untracked content)

no changes added to commit (use "git add" and/or "git commit -a")

C:UsersantoiPycharmProjectsBass>git add .

C:UsersantoiPycharmProjectsBass>git commit -m "overwriting repo"
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
  (commit or discard the untracked or modified content in submodules)
        modified:   scraper (modified content)
        modified:   webapp (modified content, untracked content)

no changes added to commit (use "git add" and/or "git commit -a")

C:UsersantoiPycharmProjectsBass>git push
warning: redirecting to https://gitlab.top.org/data-science/bass2.git/
Enumerating objects: 22, done.
Counting objects: 100% (22/22), done.
Delta compression using up to 4 threads
Compressing objects: 100% (20/20), done.
Writing objects: 100% (22/22), 5.54 KiB | 149.00 KiB/s, done.
Total 22 (delta 4), reused 0 (delta 0), pack-reused 0
remote:
remote: To create a merge request for master, visit:
remote:   https://gitlab.top.org/data-science/bass2/-/merge_requests/new?merge_request%5Bsource_branch%5D=master
remote:
To https://gitlab.top.org/data-science/bass2
 * (new branch)      master -> master

C:UsersantoiPycharmProjectsBass>

La solicitud de fusión no tiene en cuenta mi deseo de empezar de cero. Entonces intenté con --force:

C:UsersantoiPycharmProjectsBass>git push -f origin main
error: src refspec main does not match any
error: failed to push some refs to 'https://gitlab.ifresearch.org/data-science/bass2'

The "real and effective" GIT CI/CD strategy

I’ve started in this new company a few weeks ago, this is the CTO CI/CD strategy:

current git strategy

Current: Developer team has the repo prod/master and they merge everything into master (no branching strategy).
Once the code is ready in prod/master they’ll ask Infrastructure team to start the deployment process which uses Jenkins.

The Infrastructure team executes a job in Jenkins that performs this actions:

  1. Clone the whole prod/master into build/master (so they don’t mess with the developers)
  2. Execute scripts to build the binary(ies)
  3. Generate a .txt file with the version of the build
  4. Commit and push this changes into build/master (reason: prepare the deployment)
  5. Apply environment specific settings and push, configurations, binaries and code to distro/master

We end up with three repos at the end of the day for each application,
that means, if we have 10 applications we would have 30 repositories

Reasons of the CTO for this:

  1. prod/master: For developers and their code (no branching, only master)
  2. build/master: For Infra team to generate versions (to prepare the deployment)
  3. distro/master: Binaries + code + specific environment configurations (to perform rollbacks, traceability and havebackup)

Cons:

  • Really complex process
  • Unnecesary large data ammounts in repositories and slower processing when performing deployments
  • Only works for FileSystem deployments (Databases are not considered in this sceneario and that kind of changes are manually performed)
  • No instant feedback for developers
  • Complexity when crossed patches/fixes and deployments
  • Developers are involved in the production deployment (quite often, in order to test and apply changes on hot)
  • Most of the deployments are performed directly into production

Pros:

  • There’s backup and posibility to rollback
  • Easy traceability (for rollbacks, not for development)
  • Specific configurations per environment are stored in the repos with the code and binaries

And this is my approach:

approach

  1. Developers create a JIRA ticket, which will be used as tag for the build and to create the branch
  2. Developers will deploy and test in a Q.A/PRE-PROD environment
  3. Once the code works, it will be integrated to master
  4. Once integrated with master, the binary goes to a "binary repo like artifactory or other"

Pros:

  1. Traceability: The code deployed is easy to find through the tag (JIRA-XXX) for an specific build.
  2. Rollback: Taking the binary from the repo (Artifactory)
  3. One Repository per project, it means 10 projects are 10 repos, not 30.
  4. Instant feedback to developers, if the deployment is not sucessful they can change their code
  5. This design contemplates db scripts as hooks
  6. The configurations per environment will be handled with Ansible + GIT, generating templates with placeholders and a backup of each configuration.

Cons:

  • Re-educate developers to work in branches
  • Force developers to integrate code only when it really works
  • Change the CTO mindset only will happen through examples (working on it)
  • We must create new infra (new environments to create deployments and not going to production directly)
  • Lots of hours automating through hooks, rest apis
  • Need to implement new technologies

Pros:

  • Well, many of them.

I’d like to know the opinion of people with expertise on this git strategies.

Regards.

H.

git – How can a developer overcome their fear of merge conflicts?

Extreme Programming is (partly) based on the idea that if things are “hard” or “scary”, we simply aren’t practicing them enough.

That’s the thing: practice makes perfect.

So, the approach that Extreme Programming takes, is that things that are hard should not be pushed back as far as possible to avoid them. Instead, they should be embraced and done as early and as often as possible so they become familiar and lose their “scariness”.

Not only does doing things often make them familiar and gives you practice and experience, so that you get better at solving the problems you encounter, but at the same time, the problems get smaller!

Releasing is scary because after a year, you have forgotten all the steps and scripts and magic folders? Don’t just release once a year, release every week! Not only will it help you remember all the arcane scripts, all the steps, all the magic folders, it will also force you to think very hard about whether all those arcane manual steps are really needed or if they can be either eliminated or automated.

Code review is scary because there is always a mountain of code, and it takes endless hours? Do it continuously while you program (pair programming), that way, there is always only one line of code to review and the review only takes half a second or less.

Merging is scary because there are always huge merge conflicts and it takes hours to resolve them? Merge as often as you can! Again, not only will you get better at merging by doing it more often, but also, the merge conflicts get smaller! If everybody on your team merges 5-10 times a day, how far can your code really diverge in that time frame?

So, let’s say by merging often and gaining practice and experience, you become 3 times better at merging. (It’s probably going to be even more than that.) Also, let’s say that by merging more often, your merge conflicts become 3 times less frequent and 3 times smaller.

That means that merging becomes almost 100 times less scary.

That is the XP approach, at least. It works even if you don’t follow all practices of XP, although of course all the practices are meant to work together and link into each other and reinforce each other.

git – Can’t clone repo from github with correct ssh private key in wsl

I have two enviroment on windows:

  1. msys2
  2. wsl

I use same ssh_key in both env .
They all can connect my remote vps by this key .
But I found only on wsl, I can’t git clone repo:

Cloning into 'MyActions'...
ssh_exchange_identification: Connection closed by remote host
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Try to debug by ssh -vvvT git@github.com in wsl shell :

OpenSSH_7.6p1 Ubuntu-4ubuntu0.4, OpenSSL 1.0.2n  7 Dec 2017
debug1: Reading configuration data /home/ufo/.ssh/config
debug1: /home/ufo/.ssh/config line 1: Applying options for *
debug1: /home/ufo/.ssh/config line 268: Applying options for github.com
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Executing proxy command: exec nc -X 5 -x 172.17.128.1:1920 github.com 22
debug1: permanently_drop_suid: 1000
debug1: identity file /home/ufo/.ssh/id_rsa type 0  #  this line is the problem
debug1: key_load_public: No such file or directory
debug1: identity file /home/ufo/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/ufo/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/ufo/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/ufo/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/ufo/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/ufo/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/ufo/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.4


wsl shows:

debug1: identity file /home/ufo/.ssh/id_rsa type 0

But msys2 can clone repo, it shows:

debug1: identity file /home/ufo/.ssh/id_rsa type 1

I can’t figure it out .

How to prevent shell complete options for git commit-tree?

When I’m completing git commit I would like it add a space at the end so I could enter the desired flags immediately. But, commit-tree is also an option, thus resulting in an annoying situation where I accidentally type: git commit-m 'my message'

How can I make the zsh completion ignore commit-tree?

Controlling and managing separate git repos on Azure DevOps for code security

My company is about to onboard some junior devs for the first time, and we want to limit their access to just the presentation layer. As it stands, everything is in one Git repo. The current plan is to fork the main repo, and modify it such that only presentation layer and the compiled assembles will be left. The new devs can then branch from there. The lead dev can just do the merge himself.

Is there a better and optimal way to approach this?

Get commit list between 2 last tags in git – on windows – without knowing the tags

I am trying to get list of commits between the last Tag and the Tag before it

Answers that I see here ( and that I currently use ) are like this:

git log –pretty=oneline TagA…TagB

But this forces me to know the tag numbers that are not available at this part of the build process

thus sometimes this command fails, stopping the build process

Build machine is a Windows machine, I have seen unix related answers

Any way to achieve that ?