autosquash | GitHub Action to update PRs | Continous Integration library

Quoting the doc :

--autosquash
--no-autosquash

When the commit log message begins with "squash! …​" (or "fixup! …​"), and there is already a commit in the todo list that matches the same ..., automatically modify the todo list of rebase -i so that the commit marked for squashing comes right after the commit to be modified, and change the action of the moved commit from pick to squash (or fixup).

[emphasis mine : ]
A commit matches the ... if the commit subject matches, or if the ... refers to the commit’s hash.

As a fall-back, partial matches of the commit subject work, too. The recommended way to create fixup/squash commits is by using the --fixup/--squash options of git-commit[1].

note that "commit subject" means "the first line of the commit message" -- not "the complete commit mesage".

In the past, git pull is doing git fetch and git merge.

This is still the default.

So it always have merge commit.

This, however, is not the case: git merge with no options defaults to doing a fast-forward operation instead of a merge, whenever this is possible. A fast-forward operation is not a merge (even though Git refers to it as a "fast-forward merge") so it does not produce a merge commit.

You get a merge commit when:

• you force git merge to make one, using --no-ff; or
• a fast-forward is not possible (in which case --no-ff, if you set it, is redundant).

This is all quite configurable, though.

But now I saw our team members, use 'git pull' when they have commits. And won't have merge commit, because the commit time is later than the branch's last commit.

The word because here is misplaced. The time stamps on any given commit are quite independent of whether Git uses a merge commit. There is no cause-and-effect relationship here. Merging uses the commit graph, not any date-and-time-stamps on commits; the date-and-time-stamps are irrelevant to the graph structure.¹

I have check the git config --list and it has rebase.autosquash=true

That affects git rebase: it makes a plain git rebase -i act as though you ran git rebase --autosquash -i. See the git config documentation and search for rebase.autoSquash.

To make git pull act as if you had run git pull --rebase, there are multiple configuration options:

• branch.name.rebase can be set to anything that evaluates to boolean true;
• pull.rebase can be set to anything that evaluates to boolean true.

In addition, setting branch.autoSetupRebase directs branch-name-creating operations to set branch.name.rebase to true. Again, see the configuration documentation for details, as this is highly configurable.

¹For instance, we can have a series of commits C-D-E where the date and time stamp of commit C is in the 1970s, before Git even existed; the date and time stamp of commit D is set far in the future; and the date and time stamp of commit E is "right now". This is not normal and strongly suggests that the date-stamps were faked. But since Git does not depend on them,² it's harmless.

²Some features in Git speed up use of the commit graph by making assumptions about increasing date stamps. To make this work correctly, some recent Git work now computes a "corrected commit timestamp" internally. For an ordinary commit, the corrected commit timestamp of child C of parent P is max(C.date, P.date+1), more or less. For a root commit we simply use the date stamp as-is and for a multi-parent commit we find max(P.date ∀ P ∈ parents) and add 1 and use that as the other input to our outer max function.

follow this page fatal: unable to access curl-ca-bundle.crt · Issue #4836 · desktop/desktop

1. I found curl-ca-bundle.crt at C:\Program Files (x86)\Git\bin\curl-ca-bundle.crt
2. copy it to C:\program files (x86)\microsoft visual studio\2019\community\common7\ide\commonextensions\microsoft\teamfoundation\team explorer\Git\mingw32\bin\curl-ca-bundle.crt
3. try to push in vs2019 and it's work.

This actually has already been answered. I asked a little early before my due diligence with the google. So I'll put in my answer below.

Using the eval function will work. But this is not best practice. For best practice I'm using a shell function.

In my case I have a lot of duplicate configurations that shorthands some of the typing so it's not as verbose. In this case I've further opted for an associative array of configurations considering each configuration will have a unique key.

You've misconfigured your .gitattributes file. The attribute is eol=lf, not eol=LF. This option is case sensitive, like most Git options, and by specifying LF this attribute is left unset. Since it's unset and your version of Git is configured with core.autocrlf=true, your files are checked out as CRLF.

If you fix that, things should work correctly.

What you've run into here is basically an edge case in merges. You just have to fix these manually. You might wonder why I'm talking about merges, when you're not running git merge. For that, see the long answer below.

What git rebase does is to copy (some) commits. When using the interactive rebase, git rebase -i, you can fiddle with the copying process. When using --autosquash, Git itself fiddles with the copying process. This fiddling can lead to the problem you encountered. Even without any fiddling, you can still get conflicts. Let's explore this.

We need to start with a brief overview of commits. Each commit:

• has a unique number: a hash ID, formed by running a cryptographic checksum over the full content of the commit;
• contains both a snapshot of all files (as an internal tree object holding the meat of the commit) and some metadata, or information about the commit itself: your name and email address, for instance, and the hash ID of the commit's parent or parents.

The parent commit hash ID(s) inside each commit form commits into backwards-looking chains. For instance, if we represent a simple linear chain of commits using single uppercase letters to stand in for hash IDs, we get a drawing like this:

You may try the following steps:

1. Delete folder (you can back up this folder in case you need to restore it): C:\Program Files (x86)\Microsoft Visual Studio\2019\xxx\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\Git

2. Make sure that there is no version of Git installed on your system. Uninstall them in Control Panel / Uninstall a program once you have Git .

3. Download the latest version of Git and install it.

4. Run this command in your Git shell to disable the revocation check:

   $ git config --global http.schannelCheckRevoke false

   Note:

   From this link:

   We do not recommend setting this config value for normal Git usage. This is intended to be an "escape hatch" for situations where the network administrator has restricted the normal usage of SChannel APIs on Windows that Git is trying to use.

Be sure to use the -i option with --autosquash. New versions of Git might not require it, but older ones will (and it doesn't hurt).

As to your comment: rebase is complicated.

In particular, git rebase is a front end that parses options and other arguments and then invokes one of several different rebase implementations:

• git-rebase--am is the original rebase, dating back to well before even the oldest current Git versions still in use (1.7-era). It uses git format-patch and git am and is the least capable (but fastest) rebase.

• git-rebase--interactive is the standard backend for all interactive rebases up until Git version 2.13. It uses git cherry-pick.

• git-rebase--merge is a variant of non-interactive rebase that uses cherry-pick. This is the form of rebase you get with git rebase -m, git rebase -s strategy, or git rebase -X eXtended-argument, unless you add an explicit -i as well, in which case you get the interactive back end.

• git-rebase--preserve-merges is a special purpose back end split off in Git version 2.19.0. It implements the old style git rebase -p. (The new git rebase -r requires the new sequencer-based rebase mentioned below.)

• Starting with Git 2.13 and progressing further through Git 2.19 (when the preserve-merges back end was split off), the interactive rebase backend has grown more capable (and been written less in shell script and more in C), and now uses Git's sequencer code, which previously mainly implemented git cherry-pick and git revert.

• As of Git 2.20, git-rebase--interactive no longer exists at all (but git rebase -i still does an interactive rebase). As of Git 2.23, git-rebase--am no longer exists as a separate back-end script (but this style of rebase still exists, it's just handled more directly).

• As of Git 2.26, git rebase no longer uses the am style machinery by default. (This might mean you don't need a separate -i option, but my own Git installations are not this new so I have not tested it.)

The --autosquash option requires the use of the interactive back end machinery, and requires that Git generate the list of commits that might be applied so that the code can check for fixup! and squash! commit subjects. Use of the interactive machinery in particular disables the "already up to date" check.