Q: What happened to "--no-commit" merges?

Hi! Using git version 2.16.4 on OpenSUSE Leap 15.0, it seems that "--no-commit" no longer does what it did before (AFAIR, but I mostly did --no-ff merges in SLES11): Like this (sorry German): > git merge --no-commit local/f-linux-firefox Aktualisiere 520aaae..c11e3da Fast-forward bin/fval.xsl |

Antw: Re: Q: What happened to "--no-commit" merges?

>>> Elijah Newren schrieb am 22.01.2019 um 22:29 in Nachricht : > Hello, > > On Tue, Jan 22, 2019 at 1:05 PM Ulrich Windl > wrote: >> >> Hi! >> >> Using git version 2.16.4 on OpenSUSE Leap 15.0, it seems that "--no-commit" > no >>

Surprising semantics of "git add file"

like "git commit file", meaning "git commit file" should be fixed IMHO. Or are there any reasonable use cased for that? Regards, Ulrich Windl

Antw: Surprising semantics of "git add file"

Actually things are worse: When I tried to fix the comment for the unexpected commit at least using "git commit --amend", more files were committed! >>> Ulrich Windl 05.05.19 22.02 Uhr >>> Hi! Reading the manual, I realized that "it is the way it is (it works

Antw: Re: Surprising semantics of "git add file"

>>> Andreas Schwab schrieb am 05.05.2019 um 22:31 in Nachricht <87o94gbq46@igel.home>: > On Mai 05 2019, "Ulrich Windl" wrote: > >> After that a "git diff ‑‑cached file" just shows the changes added > interactively, but when I "git a

Missing branches after clone

Hi! While wondering why some branches are not being displayed by "git branch" in a cloned repository, I was reading the obvious man pages (man git-branch, man git-remote), but still couldn't find the reason or the solution. Then I found https://stackoverflow.com/questions/10312521/how-to-fetch-

some git confusion (where git's advice didn't help)

Hi! I was fighting with a remote branch being missing: > git branch f-systemd integration master * next > git pull Already up-to-date. > git pull --all Fetching origin Already up-to-date. > git fetch f-gcc-4.8 fatal: 'f-gcc-4.8' does not appear to be a git repository fatal: Could not read fr

Antw: Re: Missing branches after clone

Hi! The confusing part actually is for me: "git clone" does NOT "Clone a repository into a new directory", but "clone the current branch into a new directory" (IMHO). So I was surprised that I couldn't merge branches under the same name in the cloned "repository". Only "git clone --bare" actuall

Re: Antw: Re: Missing branches after clone

>>> Philip Oakley schrieb am 15.05.2019 um 09:34 in Nachricht : > On 14/05/2019 12:49, Ulrich Windl wrote: >> Hi! >> >> The confusing part actually is for me: >> "git clone" does NOT "Clone a repository into a new directory", but "clon

Q: git describe --always --tags .. gives "warning: tag 'tag1' is really 'tag2' here"

Hi! I have a project that changed its name some time ago (from "isredir" to "iredir"), so I added another tag for the same commit ID (What's the command to show the commit IDs for tags, BTW?: "git tag -v" does not. As part of the build process, I run (for example) "git describe --always --tags

Antw: Re: Q: git describe --always --tags .. gives "warning: tag 'tag1' is really 'tag2' here"

>>> Junio C Hamano schrieb am 29.05.2019 um 20:01 in Nachricht : > "Ulrich Windl" writes: > >> So I got the response: >> warning: tag 'isredir‑0.3.0' is really 'iredir‑0.3.0' here >> isredir‑0.3.0‑3‑gaf467c7 > > I suspect th

Merge: "git rm bla": "bla: needs merge", but still removes file "bla"

Hi! I just had "an interesting case" for a merge with conflicts: The merge re-introduced a file that had been renamed (say old one is "bla", and the new one is "foo"). After merging the changes from bla into foo, I added foo, trying to remove bla: > git add foo > git rm bla bla: needs merge rm 'b

blank lines in pre-created merge message

never creates any emüpty lines in the pre-created comment) My Git version is 2.12.3, but the bug is probably quite old... Regards, Ulrich Windl

Antw: Re: blank lines in pre-created merge message

>>> Johannes Schindelin schrieb am 25.07.2019 um 12:07 in Nachricht : > Hi Ulrich, > > On Wed, 24 Jul 2019, Ulrich Windl wrote: > >> I think I had tried bringing this to your attention before, but I think it > was >> without success. >> The issue may s

Re: Antw: Re: blank lines in pre-created merge message

>>> Johannes Schindelin schrieb am 25.07.2019 um 13:58 in Nachricht : > Hi Ulrich, > > On Thu, 25 Jul 2019, Ulrich Windl wrote: > >> >>> Johannes Schindelin schrieb am 25.07.2019 um >> 12:07 >> in Nachricht : >> > >> > On Wed,

Q: Ignore ./foo, but not script/foo

Hi! I have a (simple) question I could not answer elegantly from the gitignore(5) manual page: A project produces a "foo" binary in the root directory that I want to ignore (So I put "foo" into .gitignore) Unfortunately I found out taht I cannot have a "script/foo" added while "foo" is in .git

Antw: Re: Q: Ignore ./foo, but not script/foo

tually, when read carefully enough, the last item in "PATTERN FORMAT" explains that. Maybe the EXAMPLES could have an example for each item (5 cases) described ;-) Regards, Ulrich > > Best regards, > Sebastian > Am Do., 19. Juli 2018 um 09:45 Uhr schrieb Ulrich Windl >

Antw: Antw:

l be fast-forward type or not. So actually the outcome of --no-commit depends on the conents being merged, not on the command line options. > > Modify the wording to correctly address fast‑forward cases as well, > and suggest using ‑‑no‑ff with ‑‑no‑commit if the point is to ensure > tha

Antw: Re: [PATCH v2] merge-options.txt: correct wording of --no-commit option

nf afterwards); maybe when entering a response is not possible (batch processing) the merge should be aborted due to "--no-commit" not being possible (well actually there would never be a commit, even without that option). The problem is that without prior inspection of the tree you cannot know whether the merge will be fast-forward or not: fast-forward being an optimization (taht is enabled by default) makes life more complicated here. Regards, Ulrich Windl

non-smooth progress indication for git fsck and git gc

Hi! I'd like to point out some minor issue observed while processing some 5-object repository with many binary objects, but most are rather small: Between the two phases of "git fsck" (checking directories and checking objects) there was a break of several seconds where no progress was indi

Antw: Re: non-smooth progress indication for git fsck and git gc

>>> Duy Nguyen schrieb am 16.08.2018 um 17:18 in Nachricht : > On Thu, Aug 16, 2018 at 1:10 PM Ulrich Windl > wrote: >> >> Hi! >> >> I'd like to point out some minor issue observed while processing some > 5-object repository with many binary ob

Antw: Re: non-smooth progress indication for git fsck and git gc

>>> Jeff King schrieb am 16.08.2018 um 22:55 in Nachricht <20180816205556.ga8...@sigill.intra.peff.net>: > On Thu, Aug 16, 2018 at 10:35:53PM +0200, Ævar Arnfjörð Bjarmason wrote: > >> This is all interesting, but I think unrelated to what Ulrich is talking >> about. Quote: >> >> Between the

Re: Antw: Re: non-smooth progress indication for git fsck and git gc

achricht <87woslpg9i@evledraar.gmail.com>: > On Mon, Aug 20 2018, Ulrich Windl wrote: > >>>>> Jeff King schrieb am 16.08.2018 um 22:55 in Nachricht >> <20180816205556.ga8...@sigill.intra.peff.net>: >>> On Thu, Aug 16, 2018 at 10:35:53PM +0200, Æv

Re: Antw: Re: non-smooth progress indication for git fsck and git gc

>>> Jeff King schrieb am 21.08.2018 um 03:07 in Nachricht <20180821010712.ga32...@sigill.intra.peff.net>: > On Mon, Aug 20, 2018 at 10:57:13AM +0200, Ævar Arnfjörð Bjarmason wrote: > [...] > So it really should just be a simple: > > progress = start_delayed_progress("Hashing packfile", 0); >

"show" in git-stash(1)

Hi! Reading the (somewhat older) manual page GIT-STASH(1) for "show" I found: show [] Show the changes recorded in the stash as a diff between the stashed state and its original parent. When no is given, shows the latest one. By default, the command shows

bug deleting "unmerged" branch (2.12.3)

Hi! During a rebase that turned out to be heavier than expected 8-( I decided to keep the old branch by creating a temporary branch name to the commit of the branch to rebase (which was still the old commit ID at that time). When done rebasing, I attached a new name to the new (rebased) branch,

Antw: Re: bug deleting "unmerged" branch (2.12.3)

> Hi Ulrich, > > On Tue, 28 Nov 2017, Ulrich Windl wrote: > >> During a rebase that turned out to be heavier than expected 8-( I >> decided to keep the old branch by creating a temporary branch name to >> the commit of the branch to rebase (which was still the

Antw: Re: bug deleting "unmerged" branch (2.12.3)

> "Ulrich Windl" writes: > >> I think if more than one branches are pointing to the same commit, >> one should be allowed to delete all but the last one without >> warning. Do you agree? > > That comes from a viewpoint that the only purpose "branch

Antw: Re: bug deleting "unmerged" branch (2.12.3)

Hi Philip! I'm unsure what you are asking for... Ulrich >>> "Philip Oakley" 04.12.17 0.30 Uhr >>> From: "Junio C Hamano" > "Philip Oakley" writes: > >> I think it was that currently you are on M, and neither A nor B are >> ancestors (i.e. merged) of M. >> >> As Junio said:- "branch -d" protec

Antw: Re: Re: bug deleting "unmerged" branch (2.12.3)

; with manual pages referring to it. Regards, Ulrich >>> "Philip Oakley" schrieb am 08.12.2017 um 21:26 in Nachricht <582105F8768F4DA6AF4EC82888F0BFBE@PhilipOakley>: > From: "Ulrich Windl" >> Hi Philip! >> >> I'm unsure what you are as

Antw: Re: Terrible bad performance for it blame --date=iso -C -C master --

>>> Samuel Lijin schrieb am 03.05.2017 um 09:12 in Nachricht : > On Mon, May 1, 2017 at 7:59 PM, Junio C Hamano wrote: >> Samuel Lijin writes: >> >>> On Fri, Mar 31, 2017 at 10:52 AM, Junio C Hamano wrote: >>> It might not be a bad idea to teach "blame" not to pay attention to any pat

java diffs show no method context

Hi! This is for git 2.13.6, and it may be an FAQ or frequent feature request. Anyway: I'm new to Java, and writing my first project using Git, I found that "git diff" only reports the class in the diff context, but not the method (as seen for C, for example). I'd wish to have the method where t

Antw: Re: java diffs show no method context

:05 in Nachricht : > Le 25/04/2018 à 14:53, Ulrich Windl a écrit : >> Hi! >> >> This is for git 2.13.6, and it may be an FAQ or frequent feature request. > Anyway: >> I'm new to Java, and writing my first project using Git, I found that "git > diff" onl

Terrible bad performance for it blame --date=iso -C -C master --

Hi! I was running "vc-annotate" in Emacs for a file from a large repository (>4 files, a big percentage being binary, about 10 commits). For the first file the result was presented rather soon, but for a second file the command did not finish even after about 10 minutes! The file in quest

Antw: Re: Terrible bad performance for it blame --date=iso -C -C master --

w to avoid that. Regards, Ulrich >>> Junio C Hamano schrieb am 31.03.2017 um 17:52 in >>> Nachricht : > "Ulrich Windl" writes: > >> I was running "vc-annotate" in Emacs for a file from a large >> repository (>4 files, a big percen

Antw: Re: Terrible bad performance for it blame --date=iso -C

>>> Jakub Narebski schrieb am 03.04.2017 um 17:16 in Nachricht <0ccc5cab-26b7-4b02-b964-452b61e92...@gmail.com>: > W dniu 03.04.2017 o 12:56, SZEDER Gábor pisze: >> Ulrich Windl wrote: > >>> In the other case (for the user bored of waiting seeking for some &

Problems in Default merge message

Hi! I'd like to report an old-time bug in git, regarding the default message visible for a "git merge --no-commit" (at the later commit, of course): * When merging a branch, the first name is put in single quotes, while the second is not. * There is no blank line after the first one * there a

Q: ".git/HEAD" and ".git/refs/heads"

t:shared-863962c". Should I use code like this:? awk '$2 == "refs/heads/shared" { print $1 }' .git/info/refs Of course I'd be most pleased if there was some git builtin to get that (I read the manual without success). Using an older version of Git (git-1.7.12)..

Antw: Re: Q: ".git/HEAD" and ".git/refs/heads"

>>> Matthieu Moy schrieb am 02.04.2014 um 19:54 >>> in Nachricht : > "Ulrich Windl" writes: > >> Hi! >> >> I have a small question: After a "git gc" with last commit being "[shared > 2679648]" I found this: >&g

Extended splitting for "git add --interactive"

AAA or BBB, or into three parts where the empty line is just another junk to accept or refuse. See comment above on why I'd like that. Regards, Ulrich Windl -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org Mor

Antw: Re: Extended splitting for "git add --interactive"

using "edit" to manually split. Iknow that in gerneral such things can't be right, but you can eith reject the new junks or use "edit". I just guessed the feature could save some time on the average. >>> Junio C Hamano schrieb am 26.11.2014 um 19:57 in >>&g

Enhancement Request: "locale" git option

Hi! I'm native German, but German git messages confuse me (yopu'll have to correlate them with the man pages). At the moment git uses the locale settings from the environment, so you can only change git's locale settings by changing the environment (like "LANG= git ..."). OTOH Git has a flexibl

Antw: Re: Enhancement Request: "locale" git option

>>> Torsten Bögershausen schrieb am 04.12.2014 um 09:29 in Nachricht <54801b50.4080...@web.de>: > On 12/04/2014 08:32 AM, Ulrich Windl wrote: >> Hi! >> >> I'm native German, but German git messages confuse me (yopu'll have to > correlate the

Antw: Re: Enhancement Request: "locale" git option

>>> Ralf Thielow schrieb am 04.12.2014 um 20:02 in Nachricht : > Hi Ulrich, > > 2014-12-04 8:32 GMT+01:00 Ulrich Windl : >> Hi! >> >> I'm native German, but German git messages confuse me (yopu'll have to > correlate them with the man pages). A

Antw: Re: Enhancement Request: "locale" git option

>>> Ralf Thielow schrieb am 06.12.2014 um 20:28 in Nachricht : > 2014-12-05 16:45 GMT+01:00 Torsten Bögershausen : >> >> I do not know who was first, and who came later, but >> > chverfolgen> >> >> uses "versioniert

Antw: Re: diff support for the Eiffel language?

a:]_][[:alnum:]_]*)[[:space:]]*$" % cat .git/info/attributes *.e diff=Eiffel --- Regards, Ulrich >>> Johannes Sixt schrieb am 22.10.2012 um 15:35 in Nachricht <50854b90.50...@viscovery.net>: > Am 10/22/2012 15:06, schrieb Ævar Arnfjörð Bjarmason: > > On Mon, Oct 22, 20

diff support for the Eiffel language?

Hi! After a longer pause, I did some programming in Eiffel again, and while doing so, why not use Git? It works! However there's one little thing I noticed with "git diff": The conte4xt lines (staring with "@@") show the current function (in Perl and C), but they show the current "feature claus