git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
thread overview below | download mbox.gz: |
* Re: [RFC] dropping support for ancient versions of curl
  @ 2017-04-05 13:04  5%     ` Tom G. Christensen
  0 siblings, 0 replies; 6+ results
From: Tom G. Christensen @ 2017-04-05 13:04 UTC (permalink / raw)
  To: Ævar Arnfjörð Bjarmason
  Cc: Jeff King, Git Mailing List, Jonathan Nieder, Todd Zullinger

On 05/04/17 12:51, Ævar Arnfjörð Bjarmason wrote:
> On Wed, Apr 5, 2017 at 11:33 AM, Tom G. Christensen <tgc@jupiterrise.com> wrote:
> Whoah. So my assumption in
> <CACBZZX78oKU5HuBEqb9qLy7--wcwhC_mW6x7Q+tB4suxohSCsQ@mail.gmail.com>
> that nobody was compiling this & thus not reporting failures was
> false. Rather there's an entire community & distribution mechanism
> around patching git for older EL versions, but the patches aren't
> making it upstream.
>

The community as I know it consists of me and EPEL5 (now dead and archived).
The packages that I build are probably only used by me and the company I 
work for as they are not exactly easy to find via search engines.
EPEL5 supported git 1.8.3.2 but the Fedora git specfile still contains 
all the infrastructure though I cannot know if it actually got used with 
anything later than 1.8.3.2.

I don't know of anyone that actually *needs* to use the latest git on 
RHEL < 5, myself included. I kept the support for RHEL < 5 because I 
could and it was good fun to tinker with.

Also I should say that testresults are good, no problems there except a 
few small nits as revealed in the specfile:
%if %{?el4:1}0
# These tests fail with subversion 1.1.4
export GIT_SKIP_TESTS="t9140.4"
%ifarch x86_64
# These tests fail with subversion 1.1.4 but only on x86_64
export GIT_SKIP_TESTS="$GIT_SKIP_TESTS t9106.7 t9106.8 t9106.9 t9106.10 
t9137.4 t9164.5 t9164.6 t9164.7 t9164.8"
%endif
%endif
%if %{?el3:1}%{?el4:1}0
# not ok 6 - url high-bit escapes
export GIT_SKIP_TESTS="$GIT_SKIP_TESTS t0110.6"
# not ok 32 - ref name 'heads/foo' is invalid
export GIT_SKIP_TESTS="$GIT_SKIP_TESTS t1402.32"
%endif
%if %{?el3:1}0
# t7800 failed 17 among 56 test(s)
export GIT_SKIP_TESTS="$GIT_SKIP_TESTS t7800"
%endif

It's been a little while since I did a build without those exclusions 
but I doubt much has changed.

> $ grep -h -e ^Subject -e ^Date *patch
> Date: Tue, 13 Oct 2009 11:34:11 +0200
> Subject: [PATCH 1/7] Make NO_PERL_MAKEMAKER behave more like
> Date: Fri, 13 Jun 2014 11:02:02 +0200
> Subject: [PATCH 2/7] Install man pages when NO_PERL_MAKEMAKER is used
> Date: Mon, 22 Sep 2014 13:42:50 +0200
> Subject: [PATCH 3/7] Allow svnrdump_sim.py to be used with Python 2.2
> Date: Tue, 8 Mar 2016 09:31:56 +0100
> Subject: [PATCH 4/7] Handle missing HTTP_CONNECTCODE in curl < 7.10.7
> Date: Tue, 23 Aug 2016 10:32:51 +0200
> Subject: [PATCH 5/7] Add support for gnupg < 1.4
> Date: Tue, 23 Aug 2016 18:15:13 +0200
> Subject: [PATCH 6/7] Handle missing CURLINFO_SSL_DATA_{IN,OUT}
> Date: Tue, 23 Aug 2016 18:26:54 +0200
> Subject: [PATCH 7/7] Do not use curl_easy_strerror with curl < 7.12.0

All original work done by me.

> Date: Wed, 2 Feb 2011 21:24:44 -0500
> Subject: [PATCH] Restore vc-git.el for basic compatibility on EL-5
> Date: Mon, 23 Mar 2009 00:03:36 -0400
> Subject: [PATCH] git-cvsimport: Ignore cvsps-2.2b1 Branches: output
>

These two I can't claim credit for. They are lifted verbatim from 
Fedora/EPEL and as the headers reveal they were created by Todd Zullinger.
I won't submit them for inclusion since I am not familiar with nor a 
user of the parts they touch.

>> Patches can be found in the src.rpm, though I can also post them here as
>> patch series, they cover more than just curl.
>>
>> I don't use the el3 and el4 versions much any more and el5 use will also
>> drop of now as I'm busy converting machines from el5 to el7.
>
> It would be great to have them on-list, as far as I can tell they were
> never submitted? Is there some time/administrative reason for why
> you're not submitting them?

Well I recently took the time to clean them up with the intention of 
maybe finally submitting them but I never got that far.

The first one in the series I actually submitted many years ago but it 
was ultimately rejected.

I've submitted a few patches over the years to support older RHEL 
releases and some of them ended up being included.

> Some of these are many years old, it would
> be great to have them on-list for wider review & included so vanilla
> git works on these platforms.
>

I just posted them now. The series was made against the v2.12.2 tag.

-tgc

^ permalink raw reply	[relevance 5%]

* .gitignore sub-dir exclusions not overriding '*'
@ 2014-11-19  3:40  4% Phil Pennock
  0 siblings, 0 replies; 6+ results
From: Phil Pennock @ 2014-11-19  3:40 UTC (permalink / raw)
  To: git

The behaviour below is seen with both git 1.8.3.2 and git 2.1.3; I am
not subscribed to the vger list, please keep me in the CC list.

Use-case: git repo which only holds PGP-encrypted files with a .asc
extension, no matter which sub-directory they're in, or if in the top
directory.

Simple layout; for demo purposes names starting 'incl' should end up
included, those starting 'excl' should end up excluded, but not based on
those prefices: they're success result indicators; so:

    cd wherever
    git init
    mkdir foo
    touch incl.asc excl excl.txt foo/incl.asc foo/excl.txt foo/excl
    $EDITOR .gitignore

Expected to work as .gitignore in top-level of repo:

    *
    !**/*.asc
    !.gitignore

With that, `git status` ignores the contents of foo/ thusly:

    $ git check-ignore -v foo/incl.asc
    .gitignore:1:*	foo/incl.asc

Commenting out the '*' line and removing the '!' from the second, the
**/*.asc clearly matches.  The only way I can make this style work is to
set the first line to '**/*.*' which fails to exclude the plain 'excl'
files (no extension).

It seems that there's some magic around '*' as the entire final path
component of a pattern which causes it to match against the entire
directory, and excludes of the directory can not be overriden by matches
against '*.ext' within the directory, even when they come later in the
same config file at the same precedence.

This does not seem to my reading to match the behaviour described by
`git help gitignore` (checked in both versions of git) and so seems to
me to be a bug, but if it's a failure of my understanding, please help
me to understand where I messed up.

Thanks,
-Phil

^ permalink raw reply	[relevance 4%]

* gitk: file viewer call even for an binary document ?
@ 2013-12-20 19:24  4% Toralf Förster
  0 siblings, 0 replies; 6+ results
From: Toralf Förster @ 2013-12-20 19:24 UTC (permalink / raw)
  To: git@vger.kernel.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

dev-vcs/git-1.8.3.2-r1 at a stable 32 bit Gentoo Linux:

If I right click onto a file in the right pane and choose "Blame parent commit" then even for a binary file (open doc sheet) the file viewer is started - works as designed or a  bug ?


- -- 
MfG/Sincerely
Toralf Förster
pgp finger print:1A37 6F99 4A9D 026F 13E2 4DCF C4EA CDDE 0076 E94E
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlK0mVEACgkQxOrN3gB26U60KQD+M4z5rnOiU7uE8524vHP/hyjz
S586+WIdGFiCz0k0CZIA/jM+bsWaNuyAZk/9vSbflFIv3doiuC/OKnz1MlB1QQp5
=g1Fd
-----END PGP SIGNATURE-----

^ permalink raw reply	[relevance 4%]

* "git checkout foo" is getting confused by folder named "foo"
@ 2013-09-24 21:07  4% Jona Christopher Sahnwaldt
  0 siblings, 0 replies; 6+ results
From: Jona Christopher Sahnwaldt @ 2013-09-24 21:07 UTC (permalink / raw)
  To: git

Hi,

maybe this has already been reported, but I didn't find it in the mail archive.

If I understand correctly, after I clone a repo, I should be able to
switch to branch foo just by running

git checkout foo

This doesn't seem to work if a folder called "foo" exists in the root
of the repo.

I got the same behavior with git 1.8.3.2 on a Mac and git 1.7.9.5 on Linux.

Steps to reproduce:

git clone https://github.com/dbpedia/extraction-framework.git
cd extraction-framework/

First the happy path - there is a remote branch "live-dev", but no
folder "extraction-framework/live-dev":

git checkout live-dev

Response:

Branch live-dev set up to track remote branch live-dev from origin.
Switched to a new branch 'live-dev'

Fine! Now the unhappy path - there is a branch "wiktionary", but also
a folder "extraction-framework/wiktionary":

git checkout wiktionary

Nothing - no response, no changes to working tree. .git/index seems to
be modified though.

Slightly different - cd to some folder, try checkout again:

cd mappings
git checkout wiktionary

Response:

error: pathspec 'wiktionary' did not match any file(s) known to git.


My workaround is that when I switch to a branch for the first time, I
have to call

git checkout -t -b wiktionary --track origin/wiktionary

Response:

Branch wiktionary set up to track remote branch wiktionary from origin.
Switched to a new branch 'wiktionary'

Looks good. After that, I can switch back and forth between branches
just by git checkout wiktionary / git checkout master.


Cheers,
Christopher

^ permalink raw reply	[relevance 4%]

* Git installation on Mac OS X - problem
@ 2013-09-02 20:16  7% Ted Wood
  0 siblings, 0 replies; 6+ results
From: Ted Wood @ 2013-09-02 20:16 UTC (permalink / raw)
  To: git

[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]


I've recently re-installed all of my MacPorts installations due to a third-party application corrupting my installation. Upon attempting to install git-core via MacPorts, it hangs on the "Building" stage, with no disk activity (clang process is active in Terminal). So, I attempted to download the .pkg install from git-scm.com. This Installer says the installation was complete, but Apple's outdated version of git (1.7.3) is still the active binary.

Two observations:
1) The README.txt file says that Git will be installed into /usr/local/bin
2) The installation actually seems to be installed into /usr/bin, according to the installation log, which I have attached. This is the same location as Apple's version of Git.

Of particular interest is the PATH variable setting at the very top of the log file, which makes no reference to /usr/local/bin... only /usr/bin.

        Installer[18576]: Env: PATH=/usr/bin:/bin:/usr/sbin:/sbin

I've rarely experienced problems with installing software in the past. Is this an oversight on the part of the package assembler, or am I missing something?

~Ted


[-- Attachment #2: Git Installer Log 2-Sep-2013.txt --]
[-- Type: text/plain, Size: 8461 bytes --]

Sep  2 13:04:36 topdog Installer[18576]: @(#)PROGRAM:Install  PROJECT:Install-735
Sep  2 13:04:36 topdog Installer[18576]: @(#)PROGRAM:Installer  PROJECT:Installer-617
Sep  2 13:04:36 topdog Installer[18576]: Hardware: MacBookPro3,1 @ 2.20 GHz (x 2), 4096 MB RAM
Sep  2 13:04:36 topdog Installer[18576]: Running OS Build: Mac OS X 10.8.4 (12E55)
Sep  2 13:04:36 topdog Installer[18576]: Env: PATH=/usr/bin:/bin:/usr/sbin:/sbin
Sep  2 13:04:36 topdog Installer[18576]: Env: TMPDIR=/var/folders/h9/d7vc3w7j7jg0lsxsf7bvx6hh0000gn/T/
Sep  2 13:04:36 topdog Installer[18576]: Env: SHELL=/bin/bash
Sep  2 13:04:36 topdog Installer[18576]: Env: HOME=/Users/tedwood
Sep  2 13:04:36 topdog Installer[18576]: Env: USER=tedwood
Sep  2 13:04:36 topdog Installer[18576]: Env: LOGNAME=tedwood
Sep  2 13:04:36 topdog Installer[18576]: Env: SSH_AUTH_SOCK=/tmp/launch-dVtpfg/Listeners
Sep  2 13:04:36 topdog Installer[18576]: Env: Apple_Ubiquity_Message=/tmp/launch-O5o1Ms/Apple_Ubiquity_Message
Sep  2 13:04:36 topdog Installer[18576]: Env: Apple_PubSub_Socket_Render=/tmp/launch-2hUrBG/Render
Sep  2 13:04:36 topdog Installer[18576]: Env: DISPLAY=/tmp/launch-AKzVzY/org.macosforge.xquartz:0
Sep  2 13:04:36 topdog Installer[18576]: Env: COMMAND_MODE=unix2003
Sep  2 13:04:36 topdog Installer[18576]: Env: __CF_USER_TEXT_ENCODING=0x1F5:0:0
Sep  2 13:04:37 topdog Installer[18576]: Git 1.8.3.2  Installation Log
Sep  2 13:04:37 topdog Installer[18576]: Opened from: /Volumes/Git 1.8.3.2 Snow Leopard Intel Universal/git-1.8.3.2-intel-universal-snow-leopard.pkg
Sep  2 13:04:37 topdog Installer[18576]: Product archive /Volumes/Git 1.8.3.2 Snow Leopard Intel Universal/git-1.8.3.2-intel-universal-snow-leopard.pkg trustLevel=100
Sep  2 13:06:23 topdog Installer[18576]: InstallerStatusNotifications plugin loaded
Sep  2 13:06:29 topdog runner[18604]: Administrator authorization granted.
Sep  2 13:06:29 topdog Installer[18576]: ================================================================================
Sep  2 13:06:29 topdog Installer[18576]: User picked Standard Install
Sep  2 13:06:29 topdog Installer[18576]: Choices selected for installation:
Sep  2 13:06:29 topdog Installer[18576]: 	Upgrade: "Git 1.8.3.2"
Sep  2 13:06:29 topdog Installer[18576]: 	Upgrade: "Git"
Sep  2 13:06:29 topdog Installer[18576]: 		git-1.8.3.2-intel-universal-snow-leopard.pkg#git.pkg : GitOSX.Installer.git1832.git.pkg : 1
Sep  2 13:06:29 topdog Installer[18576]: 	Upgrade: "etc"
Sep  2 13:06:29 topdog Installer[18576]: 		git-1.8.3.2-intel-universal-snow-leopard.pkg#etc.pkg : GitOSX.Installer.git1832.etc.pkg : 1
Sep  2 13:06:29 topdog Installer[18576]: ================================================================================
Sep  2 13:06:29 topdog Installer[18576]: It took 0.00 seconds to summarize the package selections.
Sep  2 13:06:29 topdog Installer[18576]: -[IFDInstallController(Private) _buildInstallPlan]: location = file://localhost
Sep  2 13:06:29 topdog Installer[18576]: -[IFDInstallController(Private) _buildInstallPlan]: file://localhost/Volumes/Git%201.8.3.2%20Snow%20Leopard%20Intel%20Universal/git-1.8.3.2-intel-universal-snow-leopard.pkg#git.pkg
Sep  2 13:06:29 topdog Installer[18576]: -[IFDInstallController(Private) _buildInstallPlan]: file://localhost/Volumes/Git%201.8.3.2%20Snow%20Leopard%20Intel%20Universal/git-1.8.3.2-intel-universal-snow-leopard.pkg#etc.pkg
Sep  2 13:06:29 topdog Installer[18576]: Set authorization level to root for session
Sep  2 13:06:29 topdog Installer[18576]: Will use PK session
Sep  2 13:06:29 topdog Installer[18576]: Starting installation:
Sep  2 13:06:29 topdog Installer[18576]: Configuring volume "TopDogHD"
Sep  2 13:06:29 topdog Installer[18576]: Preparing disk for local booted install.
Sep  2 13:06:29 topdog Installer[18576]: Free space on "TopDogHD": 13.19 GB (13192531968 bytes).
Sep  2 13:06:29 topdog Installer[18576]: Create temporary directory "/var/folders/h9/d7vc3w7j7jg0lsxsf7bvx6hh0000gn/T//Install.18576CqNPZq"
Sep  2 13:06:29 topdog Installer[18576]: IFPKInstallElement (2 packages)
Sep  2 13:06:29 topdog Installer[18576]: Using authorization level of root for IFPKInstallElement
Sep  2 13:06:29 topdog installd[18607]: installd: Starting
Sep  2 13:06:29 topdog installd[18607]: installd: uid=0, euid=0
Sep  2 13:06:29 topdog installd[18607]: PackageKit: ----- Begin install -----
Sep  2 13:06:29 topdog installd[18607]: PackageKit: request=PKInstallRequest <2 packages, destination=/>
Sep  2 13:06:29 topdog installd[18607]: PackageKit: packages=(
	    "PKLeopardPackage <file://localhost/Volumes/Git%201.8.3.2%20Snow%20Leopard%20Intel%20Universal/git-1.8.3.2-intel-universal-snow-leopard.pkg#git.pkg>",
	    "PKLeopardPackage <file://localhost/Volumes/Git%201.8.3.2%20Snow%20Leopard%20Intel%20Universal/git-1.8.3.2-intel-universal-snow-leopard.pkg#etc.pkg>"
	)
Sep  2 13:06:29 topdog installd[18607]: PackageKit: Will do receipt-based obsoleting for package identifier GitOSX.Installer.git1832.git.pkg (prefix path=usr/local/git)
Sep  2 13:06:29 topdog installd[18607]: PackageKit: Will do receipt-based obsoleting for package identifier GitOSX.Installer.git1832.etc.pkg (prefix path=etc)
Sep  2 13:06:29 topdog installd[18607]: PackageKit: Extracting file://localhost/Volumes/Git%201.8.3.2%20Snow%20Leopard%20Intel%20Universal/git-1.8.3.2-intel-universal-snow-leopard.pkg#git.pkg (destination=/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/Cleanup At Startup/PKInstallSandboxManager/1.sandbox/Root/usr/local/git, uid=0)
Sep  2 13:06:31 topdog installd[18607]: PackageKit: Extracting file://localhost/Volumes/Git%201.8.3.2%20Snow%20Leopard%20Intel%20Universal/git-1.8.3.2-intel-universal-snow-leopard.pkg#etc.pkg (destination=/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/Cleanup At Startup/PKInstallSandboxManager/1.sandbox/Root/etc, uid=0)
Sep  2 13:06:31 topdog installd[18607]: PackageKit: prevent user idle system sleep
Sep  2 13:06:31 topdog installd[18607]: PackageKit: suspending backupd
Sep  2 13:06:31 topdog installd[18607]: PackageKit: Shoving /var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/Cleanup At Startup/PKInstallSandboxManager/1.sandbox/Root (2 items) to /
Sep  2 13:06:31 topdog install_monitor[18614]: Temporarily excluding: /Applications, /Library, /System, /bin, /private, /sbin, /usr
Sep  2 13:06:31 topdog installd[18607]: PackageKit: Writing receipt for GitOSX.Installer.git1832.git.pkg to /private/var/db/receipts
Sep  2 13:06:31 topdog installd[18607]: PackageKit: Writing receipt for GitOSX.Installer.git1832.etc.pkg to /private/var/db/receipts
Sep  2 13:06:31 topdog installd[18607]: PackageKit: Touched bundle usr/local/git/share/git-gui/lib/Git Gui.app
Sep  2 13:06:31 topdog installd[18607]: Installed "Git 1.8.3.2" ()
Sep  2 13:06:31 topdog install_monitor[18614]: Re-included: /Applications, /Library, /System, /bin, /private, /sbin, /usr
Sep  2 13:06:32 topdog installd[18607]: PackageKit: releasing backupd
Sep  2 13:06:32 topdog installd[18607]: PackageKit: allow user idle system sleep
Sep  2 13:06:32 topdog installd[18607]: PackageKit: ----- End install -----
Sep  2 13:06:32 topdog Installer[18576]: PackageKit: Registered bundle file://localhost/usr/local/git/share/git-gui/lib/Git%20Gui.app/ for uid 501
Sep  2 13:06:32 topdog Installer[18576]: Running install actions
Sep  2 13:06:32 topdog Installer[18576]: Removing temporary directory "/var/folders/h9/d7vc3w7j7jg0lsxsf7bvx6hh0000gn/T//Install.18576CqNPZq"
Sep  2 13:06:32 topdog Installer[18576]: Finalize disk "TopDogHD"
Sep  2 13:06:32 topdog Installer[18576]: Notifying system of updated components
Sep  2 13:06:32 topdog Installer[18576]: 
Sep  2 13:06:32 topdog Installer[18576]: **** Summary Information ****
Sep  2 13:06:32 topdog Installer[18576]:   Operation      Elapsed time
Sep  2 13:06:32 topdog Installer[18576]: -----------------------------
Sep  2 13:06:32 topdog Installer[18576]:        disk      0.02 seconds
Sep  2 13:06:32 topdog Installer[18576]:      script      0.01 seconds
Sep  2 13:06:32 topdog Installer[18576]:        zero      0.03 seconds
Sep  2 13:06:32 topdog Installer[18576]:     install      3.15 seconds
Sep  2 13:06:32 topdog Installer[18576]:     -total-      3.22 seconds
Sep  2 13:06:32 topdog Installer[18576]: 
Sep  2 13:06:32 topdog Installer[18576]: IFDInstallController 2C038770 state = 5
Sep  2 13:06:32 topdog Installer[18576]: Displaying 'Install Succeeded' UI.

^ permalink raw reply	[relevance 7%]

* [ANNOUNCE] Git v1.8.3.2
@ 2013-06-28 22:28  5% Junio C Hamano
  0 siblings, 0 replies; 6+ results
From: Junio C Hamano @ 2013-06-28 22:28 UTC (permalink / raw)
  To: git; +Cc: Linux Kernel

The latest maintenance release Git v1.8.3.2 is now available at the
usual places.  It contains fixes that have already been applied to
the 'master' branch for 1.8.4.

The release tarballs are found at:

    http://code.google.com/p/git-core/downloads/list

and their SHA-1 checksums are:

4a6585dd81a542e7803e5f54a5c85b1c1a5869aa  git-1.8.3.2.tar.gz
adffaa379e1994fc6d6cb6491aed680ad6bb37ad  git-htmldocs-1.8.3.2.tar.gz
5ce8c00fe9e2755c67d29b2f2135fc8c4202fc1f  git-manpages-1.8.3.2.tar.gz

The following public repositories all have a copy of the v1.8.3.2
tag and the maint branch that the tag points at:

  url = https://kernel.googlesource.com/pub/scm/git/git
  url = git://repo.or.cz/alt-git.git
  url = https://code.google.com/p/git-core/
  url = git://git.sourceforge.jp/gitroot/git-core/git.git
  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
  url = https://github.com/gitster/git

Also, http://www.kernel.org/pub/software/scm/git/ has copies of the
release tarballs.

Git v1.8.3.2 Release Notes
==========================

Fixes since v1.8.3.1
--------------------

 * Cloning with "git clone --depth N" while fetch.fsckobjects (or
   transfer.fsckobjects) is set to true did not tell the cut-off
   points of the shallow history to the process that validates the
   objects and the history received, causing the validation to fail.

 * "git checkout foo" DWIMs the intended "upstream" and turns it into
   "git checkout -t -b foo remotes/origin/foo". This codepath has been
   updated to correctly take existing remote definitions into account.

 * "git fetch" into a shallow repository from a repository that does
   not know about the shallow boundary commits (e.g. a different fork
   from the repository the current shallow repository was cloned from)
   did not work correctly.

 * "git subtree" (in contrib/) had one codepath with loose error
   checks to lose data at the remote side.

 * "git log --ancestry-path A...B" did not work as expected, as it did
   not pay attention to the fact that the merge base between A and B
   was the bottom of the range being specified.

 * "git diff -c -p" was not showing a deleted line from a hunk when
   another hunk immediately begins where the earlier one ends.

 * "git merge @{-1}~22" was rewritten to "git merge frotz@{1}~22"
   incorrectly when your previous branch was "frotz" (it should be
   rewritten to "git merge frotz~22" instead).

 * "git commit --allow-empty-message -m ''" should not start an
   editor.

 * "git push --[no-]verify" was not documented.

 * An entry for "file://" scheme in the enumeration of URL types Git
   can take in the HTML documentation was made into a clickable link
   by mistake.

 * zsh prompt script that borrowed from bash prompt script did not
   work due to slight differences in array variable notation between
   these two shells.

 * The bash prompt code (in contrib/) displayed the name of the branch
   being rebased when "rebase -i/-m/-p" modes are in use, but not the
   plain vanilla "rebase".

 * "git push $there HEAD:branch" did not resolve HEAD early enough, so
   it was easy to flip it around while push is still going on and push
   out a branch that the user did not originally intended when the
   command was started.

 * "difftool --dir-diff" did not copy back changes made by the
   end-user in the diff tool backend to the working tree in some
   cases.

^ permalink raw reply	[relevance 5%]

Results 1-6 of 6 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2013-06-28 22:28  5% [ANNOUNCE] Git v1.8.3.2 Junio C Hamano
2013-09-02 20:16  7% Git installation on Mac OS X - problem Ted Wood
2013-09-24 21:07  4% "git checkout foo" is getting confused by folder named "foo" Jona Christopher Sahnwaldt
2013-12-20 19:24  4% gitk: file viewer call even for an binary document ? Toralf Förster
2014-11-19  3:40  4% .gitignore sub-dir exclusions not overriding '*' Phil Pennock
2017-04-04  2:54     [RFC] dropping support for ancient versions of curl Jeff King
2017-04-05  9:33     ` Tom G. Christensen
2017-04-05 10:51       ` Ævar Arnfjörð Bjarmason
2017-04-05 13:04  5%     ` Tom G. Christensen

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).