* Re: Bug! Git merge also fails with a wrong error message
From: Jeff King @ 2012-01-13 17:50 UTC (permalink / raw)
To: Yves Goergen; +Cc: git
In-Reply-To: <loom.20120113T181805-423@post.gmane.org>
On Fri, Jan 13, 2012 at 05:37:38PM +0000, Yves Goergen wrote:
> After asking several people who didn't believe me,
> after all I could pass all checks to ensure that
> the file in question really is tracked, despite the error
> message telling it is not. (The file has a history, it is
> part of the branch,
> git status behaves as expected when I rename it, and so on.)
Whether a file in the working tree is tracked or not does not have to do
with the history, but rather with whether it is mentioned in the index.
Does the file appear in "git ls-files"?
It sounds like you are perhaps making changes in the working tree and
index, and then trying to checkout/merge on top of that. In that case
"git status" would report the file as renamed, but it's possible the
file is still in the working tree. From git's perspective the file is no
longer tracked, but the operations you are requesting would overwrite
the new contents (and git is being safe by refusing to do so).
Generally you don't want to merge with uncommitted changes like this.
You would want to commit them and then do your merge.
But even if you do commit, the question still remains: if you have
committed the removal of this file, then why is it still there? Is
something else creating it after you have deleted it?
-Peff
^ permalink raw reply
* Re: Bug! Git merge also fails with a wrong error message
From: Carlos Martín Nieto @ 2012-01-13 17:56 UTC (permalink / raw)
To: Yves Goergen; +Cc: git
In-Reply-To: <loom.20120113T181805-423@post.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2790 bytes --]
On Fri, Jan 13, 2012 at 05:37:38PM +0000, Yves Goergen wrote:
> I have updates to this issue.
You still haven't told us what version of (msys)git you're using nor
have you provided a transcript of your session or found a minimal
reproducible example.
Gmane is a mailing list viewer and there /only/ is the real maling
list. The e-mail you provided for yourself looks bogus, but if it
isn't, you'll notice we communicate via e-mail.
>
> After asking several people who didn't believe me,
> after all I could pass all checks to ensure that
> the file in question really is tracked, despite the error
> message telling it is not. (The file has a history, it is
> part of the branch,
> git status behaves as expected when I rename it, and so on.)
>
> I had found a workaround hack to access my
> data again: I have cloned the repo
> into another directory, then switched to
> the branch in there (it actually
> worked) and used BeyondCompare to manually(!)
> switch my original repo and
> working directory by copying some (not all) files
> in .git and all differences in
> the working directory.
>
> That worked fine at first, I could commit to that branch.
>
> Today I wanted to merge that branch into master again.
> Switching to master was
> fine, but merging from the form-refactoring branch
> now fails for the very same
> "reason":
>
> -----
> git.exe merge --no-commit form-refactoring
>
> error: The following untracked working tree files
> would be overwritten by merge:
> Form1.Designer.cs
> Please move or remove them before you can merge.
> Aborting
> -----
>
> Again, that file is NOT untracked. Git just fails
> processing its own data. I
> cannot move that file because it is part of the
> other branch and must be merged now.
>
> Am I now supposed to checkout both branches and
> do the merge somehow on my own?
>
> Maybe it's not a good idea to use branching and
> then rename, create and delete
> files on that branch, as switching and merging
> fail completely afterwards. And
> in the end, maybe Git isn't all that good and
> some of the alternatives with real
> file tracking should be preferred.
>
> I, for one, have lost a great amount of trust
> in Git in the last two days.
>
> (Sorry for the formatting mess, but the stupid Gmane
> post editor forced me to do that or it wouldn't
> accept my message... Don't you have a real mailing
> list, if there's no web forum??)
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Carlos Martín Nieto | http://cmartin.tk
"¿Cómo voy a decir bobadas si soy mudo?" -- CACHAI
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Bug? Git checkout fails with a wrong error message
From: Yves Goergen @ 2012-01-13 17:46 UTC (permalink / raw)
To: Holger Hellmuth; +Cc: git
In-Reply-To: <4F1028AD.9080701@ira.uka.de>
On 13.01.2012 13:50 CE(S)T, Holger Hellmuth wrote:
> Important information missing: What version of git are you using? Should
> the version number begin with 1.6 or even lower you will get the advice
> to update your version to something non-ancient. Lots of bug-fixes
> happened in-between.
The first bug happened with msysGit 1.7.6 and 1.7.8, the second one
(reported now) with 1.7.8. That update didn't change a thing.
> I assume .cs is a C source file for visual studio, not a generated file,
> right ?
.cs is C# code and .Designer.cs files are used internally by the Visual
Studio designer. They're not supposed to be edited by the programmer and
contain lots of stuff that changes all the time. So they are generated
and presented in a different way.
> git does not record renames like cvs/svn do. It operates on snapshots
> and infers renames through comparisions. So if the next commit has a
> file missing and the same or similar file contents under some different
> path, it reports it as a rename. You can try -M with git log or git diff
> so that git expends more effort to detect renames+edits. Or you could
> avoid doing renames and edits of the same file in the same commit.
I renamed the file and created a new one with the same name. Is it so
simple to crash the Git repository?
>> -----
>> git.exe checkout form-refactoring
>>
>> Aborting
>> error: The following untracked working tree files would be overwritten by
>> checkout:
>> Form1.Designer.cs
>> Please move or remove them before you can switch branches.
>> -----
>
> You didn't mention that filename before (please assume people not
> accustomed to the ways of Visual Studio 2010). Is that another file you
> renamed and created new in the form-refactoring branch?
Form1.cs, Form1.Designer.cs and Form1.resx all belong together and are
renamed atomically. If I rename "Form1" in the project, actually these 3
files are renamed on disk.
> What does git diff -- Form1.Designer.cs' say?
Nothing.
> What does 'git diff form-refactoring -- Form1.Designer.cs' say?
All lines deleted.
Will this message also appear on the mailing list where I posted my
first message with Gmane? (That's the only thing I've found on the
official Git website.)
--
Yves Goergen "LonelyPixel" <nospam.list@unclassified.de>
Visit my web laboratory at http://beta.unclassified.de
^ permalink raw reply
* Re: Bug! Git merge also fails with a wrong error message
From: Yves Goergen @ 2012-01-13 18:49 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120113175040.GC9373@sigill.intra.peff.net>
On 13.01.2012 18:50 CE(S)T, Jeff King wrote:
> Whether a file in the working tree is tracked or not does not have to do
> with the history, but rather with whether it is mentioned in the index.
I'm not using the index. In fact I don't even know how that what I have
read about it can be useful.
> Does the file appear in "git ls-files"?
Yes, it's in the list along with all other files.
> It sounds like you are perhaps making changes in the working tree and
> index, and then trying to checkout/merge on top of that. In that case
> "git status" would report the file as renamed, but it's possible the
> file is still in the working tree. From git's perspective the file is no
> longer tracked, but the operations you are requesting would overwrite
> the new contents (and git is being safe by refusing to do so).
Here's the git status output:
# On branch master
nothing to commit (working directory clean)
I have switched to master and the very next action was trying the merge.
There's no change in the working directory, and nothing uncommitted.
--
Yves Goergen "LonelyPixel" <nospam.list@unclassified.de>
Visit my web laboratory at http://beta.unclassified.de
^ permalink raw reply
* Re: Bug! Git merge also fails with a wrong error message
From: Jeff King @ 2012-01-13 18:54 UTC (permalink / raw)
To: Yves Goergen; +Cc: git
In-Reply-To: <4F107CAD.1020103@unclassified.de>
On Fri, Jan 13, 2012 at 07:49:17PM +0100, Yves Goergen wrote:
> On 13.01.2012 18:50 CE(S)T, Jeff King wrote:
> > Whether a file in the working tree is tracked or not does not have to do
> > with the history, but rather with whether it is mentioned in the index.
>
> I'm not using the index. In fact I don't even know how that what I have
> read about it can be useful.
Whether you realize it or not, git is using the index to store state.
When you "git add", "git rm", or "git mv", it is updating the index.
> > Does the file appear in "git ls-files"?
>
> Yes, it's in the list along with all other files.
Then it should be considered tracked, and there's a bug.
I notice that in your first mail, you mentioned a problem with
"checkout", and in the second one, a problem with "merge". Do you still
have the repo around with the "checkout" problem? If so, is the file
also in your "git ls-files" output in that repo?
It is much more likely to me that there is a bug in the merge than in
regular checkout (because merge has many complex corner cases
surrounding the 3-way merge, whereas checkout is simply moving from one
state to another). I'd like to make sure we're not seeing two different
problems.
> Here's the git status output:
> # On branch master
> nothing to commit (working directory clean)
>
> I have switched to master and the very next action was trying the merge.
> There's no change in the working directory, and nothing uncommitted.
Which version of git are you using? There were many bugs fixed around
this area of merge around the v1.7.7 timeframe.
-Peff
^ permalink raw reply
* mySysGit
From: Srinivas Rao @ 2012-01-12 23:56 UTC (permalink / raw)
To: msysgit@googlegroups.com; +Cc: git@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 345 bytes --]
Hello,
When I try to connect to an ubuntu box which I am trying to setup as a git server, and then try to ssh through from my local machine, I see the following error. I have already generated the keys and setup the public key on the server.
ssh: connect to host 10.192.27.131 port 22: Bad file number
any ideas ?
Thanks much,
Sri
[-- Attachment #2: Type: text/html, Size: 2311 bytes --]
^ permalink raw reply
* Re: Bug! Git merge also fails with a wrong error message
From: Yves Goergen @ 2012-01-13 18:59 UTC (permalink / raw)
To: Carlos Martín Nieto, Yves Goergen, git
In-Reply-To: <20120113175617.GE2850@centaur.lab.cmartin.tk>
On 13.01.2012 18:56 CE(S)T, Carlos Martín Nieto wrote:
> You still haven't told us what version of (msys)git you're using nor
> have you provided a transcript of your session or found a minimal
> reproducible example.
In case one of my other mails didn't arrive, the Git version is 1.7.8.
There is no session transcript because I use TortoiseGit and I'm not
going to add a screencast here.
> Gmane is a mailing list viewer and there /only/ is the real maling
> list. The e-mail you provided for yourself looks bogus, but if it
> isn't, you'll notice we communicate via e-mail.
Well, I am very confused. Starting from git-scm.com, the only support
site is a mailing list, and the hyperlink on that word sends me to Gmane
which says I am in a newsgroup called "gmane.comp.version-control.git".
Since I don't have access to the news system, I need to use the Gmane
website. I don't know exactly what it is. I know mailing lists, but that
doesn't look like one at all. There's not even a subscription page or
address. For users of the modern web who are not familiar with 70s nntp
technology and cannot use a mailing list by merely knowing its address,
this is very support-unfriendly. I almost would have considered that the
official Git website doesn't want to offer any support at all. In that
case I would likely have searched for an alternative and switched right
away. Assuming I could have extracted the remainders of my source code
from the broken Git repository.
So am I now subscribed to that "git@vger.kernel.org" mailing list and do
my posts show up there? I have no idea what's going on, neither in my
repository, nor in this mailing list. Confusing and intransparent.
--
Yves Goergen "LonelyPixel" <nospam.list@unclassified.de>
Visit my web laboratory at http://beta.unclassified.de
^ permalink raw reply
* Re: Bug! Git merge also fails with a wrong error message
From: Yves Goergen @ 2012-01-13 19:05 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120113185436.GA13522@sigill.intra.peff.net>
On 13.01.2012 19:54 CE(S)T, Jeff King wrote:
> Whether you realize it or not, git is using the index to store state.
> When you "git add", "git rm", or "git mv", it is updating the index.
I'm using TortoiseGit most of the time and that doesn't expose the
concept of an "index". I edit files as usual, then select "commit" and
get the commit dialogue. In there I enter the commit message and select
all files to commit. I can add new files right there. There is no
two-step procedure.
> I notice that in your first mail, you mentioned a problem with
> "checkout", and in the second one, a problem with "merge". Do you still
> have the repo around with the "checkout" problem? If so, is the file
> also in your "git ls-files" output in that repo?
Yes, I have made a backup of the repo right after the initial problem
arose. And the git ls-files output is the same regarding that file.
> Which version of git are you using? There were many bugs fixed around
> this area of merge around the v1.7.7 timeframe.
msysGit 1.7.8 on Windows XP SP3. It's a "preview" but since Git is so
old now and there's been nothing but "previews", I consider msysGit's
meaning of the word "preview" as "stable".
--
Yves Goergen "LonelyPixel" <nospam.list@unclassified.de>
Visit my web laboratory at http://beta.unclassified.de
^ permalink raw reply
* Re: [PATCH] merge: Make merge strategy message follow the diffstat
From: Junio C Hamano @ 2012-01-13 19:12 UTC (permalink / raw)
To: Paul Gortmaker
Cc: Linus Torvalds, Mark Brown, Liam Girdwood, linux-kernel,
Git Mailing List
In-Reply-To: <20120111184026.GA23952@windriver.com>
Paul Gortmaker <paul.gortmaker@windriver.com> writes:
> By moving the message after the diffstat, there is a better chance that
> people will be aware they've done a pointless merge commit.
>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
I think the goal of the change may be worthy, but a few points:
- What does "automsg" mean? Is "auto" in contrast to "manual"? Even
better, wouldn't it be far simpler to just use
if (msg && verbosity >= 0)
printf("%s\n", msg);
and get rid of this mysteriously named variable altogether?
- Wouldn't it make more sense to move "No merge message -- not updating
HEAD" also to the end?
- After applying this patch, does the tests still pass?
Thanks.
^ permalink raw reply
* Re: [PATCH 1/2] gitweb: Fix file links in "grep" search
From: Junio C Hamano @ 2012-01-13 19:18 UTC (permalink / raw)
To: Thomas Perl; +Cc: Jakub Narebski, git
In-Reply-To: <CA+uOhx7QwRQJzyYBCkmVDBRCMt0i_ZqS=sfTG0VmNiVv2dVoww@mail.gmail.com>
Thomas Perl <th.perl@gmail.com> writes:
> As far as I'm concerned, the patch can be applied and fixes the bug.
Thanks.
^ permalink raw reply
* Re: [PATCH] merge: Make merge strategy message follow the diffstat
From: Nguyen Thai Ngoc Duy @ 2012-01-13 19:27 UTC (permalink / raw)
To: Junio C Hamano
Cc: Paul Gortmaker, Linus Torvalds, Mark Brown, Liam Girdwood,
linux-kernel, Git Mailing List
In-Reply-To: <7vaa5rzaax.fsf_-_@alter.siamese.dyndns.org>
On Sat, Jan 14, 2012 at 2:12 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Paul Gortmaker <paul.gortmaker@windriver.com> writes:
>
>> By moving the message after the diffstat, there is a better chance that
>> people will be aware they've done a pointless merge commit.
>>
>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>
> I think the goal of the change may be worthy
Still, diffstat from a fetch/pull is sometimes too verbose. It'd be
better if we have something that fit in one screen (dirstat or maybe
just a first few lines from diffstat then ellipsis) then refer users
to "git diff --stat HEAD@{1}" for more detail stat.
--
Duy
^ permalink raw reply
* Re: Bug? Git checkout fails with a wrong error message
From: Holger Hellmuth @ 2012-01-13 19:28 UTC (permalink / raw)
To: Yves Goergen; +Cc: git, Jeff King, Carlos Martín Nieto
In-Reply-To: <4F106DDF.4040408@unclassified.de>
Added Peff and Carlos to the CC so they see this part of the thread too.
On 13.01.2012 18:46, Yves Goergen wrote:
> On 13.01.2012 13:50 CE(S)T, Holger Hellmuth wrote:
>> Important information missing: What version of git are you using? Should
>> the version number begin with 1.6 or even lower you will get the advice
>> to update your version to something non-ancient. Lots of bug-fixes
>> happened in-between.
>
> The first bug happened with msysGit 1.7.6 and 1.7.8, the second one
> (reported now) with 1.7.8. That update didn't change a thing.
>
>> I assume .cs is a C source file for visual studio, not a generated file,
>> right ?
>
> .cs is C# code and .Designer.cs files are used internally by the Visual
> Studio designer. They're not supposed to be edited by the programmer and
> contain lots of stuff that changes all the time. So they are generated
> and presented in a different way.
Is it possible that Visual Studio changes them while you are comitting?
>> git does not record renames like cvs/svn do. It operates on snapshots
>> and infers renames through comparisions. So if the next commit has a
>> file missing and the same or similar file contents under some different
>> path, it reports it as a rename. You can try -M with git log or git diff
>> so that git expends more effort to detect renames+edits. Or you could
>> avoid doing renames and edits of the same file in the same commit.
>
> I renamed the file and created a new one with the same name. Is it so
> simple to crash the Git repository?
Who said anything about crash? git simply doesn't care whether a change
is because of a rename. It isn't special or different to any change you
can make to a file
>>> -----
>>> git.exe checkout form-refactoring
>>>
>>> Aborting
>>> error: The following untracked working tree files would be overwritten by
>>> checkout:
>>> Form1.Designer.cs
>>> Please move or remove them before you can switch branches.
>>> -----
>>
>> You didn't mention that filename before (please assume people not
>> accustomed to the ways of Visual Studio 2010). Is that another file you
>> renamed and created new in the form-refactoring branch?
>
> Form1.cs, Form1.Designer.cs and Form1.resx all belong together and are
> renamed atomically. If I rename "Form1" in the project, actually these 3
> files are renamed on disk.
As an aside, if .Designer.cs is generated automatically from Form1.cs it
shouldn't be tracked at all. Maybe tortoise git has a global gitignore
with a line "*.Designer.cs" in it to account for that fact. Maybe this
lead to the error message?
>> What does git diff -- Form1.Designer.cs' say?
>
> Nothing.
>
>> What does 'git diff form-refactoring -- Form1.Designer.cs' say?
>
> All lines deleted.
Really all lines? That would indicate that you don't have a file
Form1.Designer.cs (or an empty one) in your working directory in branch
master. In case there is no file (as seen by git) the output of diff
should compare with /dev/null aka the void aka <I don't know how this
prints on the windows side>. Also notice the line "deleted file mode ..."
> git diff master -- zumf
diff --git a/zumf b/zumf
deleted file mode 100644
index 925eccd..0000000
--- a/zumf
+++ /dev/null
@@ -1 +0,0 @@
Or did you just mean "all the shown lines in the diff were fronted by a
minus sign"? Which would just indicate that the file in form-refactoring
is a superset of the one in master.
(As you can see, actual reproduction of command line output is very
helpful to avoid ambiguity and can give further hints)
^ permalink raw reply related
* Re: Bug! Git merge also fails with a wrong error message
From: Jakub Narebski @ 2012-01-13 19:34 UTC (permalink / raw)
To: Yves Goergen; +Cc: Carlos Martín Nieto, git
In-Reply-To: <4F107F16.30009@unclassified.de>
Yves Goergen <nospam.list@unclassified.de> writes:
> On 13.01.2012 18:56 CE(S)T, Carlos Martín Nieto wrote:
> > Gmane is a mailing list viewer and there /only/ is the real maling
> > list. The e-mail you provided for yourself looks bogus, but if it
> > isn't, you'll notice we communicate via e-mail.
>
> Well, I am very confused. Starting from git-scm.com, the only support
> site is a mailing list, and the hyperlink on that word sends me to Gmane
> which says I am in a newsgroup called "gmane.comp.version-control.git".
Note however that the _text_ of the hyperlink is
git@vger.kernel.org mailing list
> Since I don't have access to the news system, I need to use the Gmane
> website. I don't know exactly what it is.
GMane is an e-mail to news gateway, and a mailing list archive. It
exposes mailing list as a newsgroup, so it can be read and written to
via newsreader (via Usenet).
Perhaps better solution would be to use mailto:git@vger.kernel.org
link, and add a sentence about archives / alternative interfaces.
> I know mailing lists, but that
> doesn't look like one at all. There's not even a subscription page or
> address.
git@vger.kernel.org is a public non-subscribe mailing list; you don't
need to subscribe to post requests there. Note that it is a custom on
this mailing list to always include all participants in given
(sub)thread directly in Cc, so you should get responses to your emails
even if you are not subscribed.
[...]
> So am I now subscribed to that "git@vger.kernel.org" mailing list and do
> my posts show up there? I have no idea what's going on, neither in my
> repository, nor in this mailing list. Confusing and non-transparent.
If you send email to git@vger.kernel.org, it would also appear on
GMane.
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH] merge: Make merge strategy message follow the diffstat
From: Linus Torvalds @ 2012-01-13 19:49 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Junio C Hamano, Paul Gortmaker, Mark Brown, Liam Girdwood,
linux-kernel, Git Mailing List
In-Reply-To: <CACsJy8BmFgssTAh=1U7JgBsGG-tSaWXQzZeODND3icXY3QUxug@mail.gmail.com>
On Fri, Jan 13, 2012 at 11:27 AM, Nguyen Thai Ngoc Duy
<pclouds@gmail.com> wrote:
>
> Still, diffstat from a fetch/pull is sometimes too verbose. It'd be
> better if we have something that fit in one screen (dirstat or maybe
> just a first few lines from diffstat then ellipsis) then refer users
> to "git diff --stat HEAD@{1}" for more detail stat.
Yeah, I've wanted that. Show the beginning, the end, and the summary
line of the diffstat would be lovely.
It would be lovely in "git commit" too. Not just
Modified: filename
but a diffstat that shows now many lines.
And what I've *really* wanted is to actually see the diff itself if it
is small. So some kind of "dynamic summary": for one-liners (or
ten-liners), show the whole diff. For medium-sized changes, show the
whole diffstat. And for really big changes, show an outline and the
"768 files changed, 179851 lines added, 7630 lines removed" stats.
IOW, whatever fits in, say, 50 lines or less.
That would be absolutely lovely if somebody were to do it.
Linus
^ permalink raw reply
* Re: [PATCH v2 2/2] git-show-ref doc: typeset regexp in fixed width font
From: Junio C Hamano @ 2012-01-13 19:51 UTC (permalink / raw)
To: mhagger; +Cc: git, Thomas Rast
In-Reply-To: <1326472756-15227-3-git-send-email-mhagger@alum.mit.edu>
mhagger@alum.mit.edu writes:
> From: Michael Haggerty <mhagger@alum.mit.edu>
>
>
> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
> ---
> Optional; I think it looks better.
I agree it looks better, too, as long as everybody's copy of AsciiDoc
groks it. I see "`<something>`" in many places in the other pages, so this
should be safe.
Thanks for resending. Will queue.
^ permalink raw reply
* Re: [PATCH v4 00/10] nd/clone-detached
From: Junio C Hamano @ 2012-01-13 19:52 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1326439322-15648-1-git-send-email-pclouds@gmail.com>
Thanks, replaced (and updated comment strings read much better).
There were some conlicts I had to resolve while merging this to 'pu'.
I would appreciate it if you can eyeball it to make sure I didn't make
silly mistakes there.
Thanks.
^ permalink raw reply
* [ANNOUNCE] Git 1.7.9.rc1
From: Junio C Hamano @ 2012-01-13 19:55 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
A release candidate Git 1.7.9.rc1 is available for testing.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
b97f10508f16b4117499cdfc4df9b19c725027d5 git-1.7.9.rc1.tar.gz
3064fc295a46440a91ca3f5fa622f5f1d40d3ba4 git-htmldocs-1.7.9.rc1.tar.gz
332e12061823d8def0fb823fa7798093bbe41279 git-manpages-1.7.9.rc1.tar.gz
Also the following public repositories all have a copy of the v1.7.9.rc1
tag and the master branch that the tag points at:
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
Git v1.7.9 Release Notes (draft)
========================
Updates since v1.7.8
--------------------
* gitk updates accumulated since early 2011.
* git-gui updated to 0.16.0.
* git-p4 (in contrib/) updates.
* Git uses gettext to translate its most common interface messages
into the user's language if translations are available and the
locale is appropriately set. Distributors can drop in new PO files
in po/ to add new translations.
* The code to handle username/password for HTTP transaction used in
"git push" & "git fetch" learned to talk "credential API" to
external programs to cache or store them, to allow integration with
platform native keychain mechanisms.
* The prompted input in the terminal use our own getpass() replacement
when possible. HTTP transactions used to ask username without echoing
back what was typed, but with this change you will see it as you type.
* The internal of "revert/cherry-pick" has been tweaked to prepare
building more generic "sequencer" on top of the implementation that
drives them.
* "git rev-parse FETCH_HEAD" after "git fetch" without specifying
what to fetch from the command line will now show the commit that
would be merged if the command were "git pull".
* "git add" learned to stream large files directly into a packfile
instead of writing them into individual loose object files.
* "git checkout -B <current branch> <elsewhere>" is a more intuitive
way to spell "git reset --keep <elsewhere>".
* "git checkout" and "git merge" learned "--no-overwrite-ignore" option
to tell Git that untracked and ignored files are not expendable.
* "git commit --amend" learned "--no-edit" option to say that the
user is amending the tree being recorded, without updating the
commit log message.
* "git commit" and "git reset" re-learned the optimization to prime
the cache-tree information in the index, which makes it faster to
write a tree object out after the index entries are updated.
* "git commit" detects and rejects an attempt to stuff NUL byte in
the commit log message.
* "git commit" learned "-S" to GPG-sign the commit; this can be shown
with the "--show-signature" option to "git log".
* fsck and prune are relatively lengthy operations that still go
silent while making the end-user wait. They learned to give progress
output like other slow operations.
* The set of built-in function-header patterns for various languages
knows MATLAB.
* "git log --format='<format>'" learned new %g[nNeE] specifiers to
show information from the reflog entries when warlking the reflog
(i.e. with "-g").
* "git pull" can be used to fetch and merge an annotated/signed tag,
instead of the tip of a topic branch. The GPG signature from the
signed tag is recorded in the resulting merge commit for later
auditing.
* "git log" learned "--show-signature" option to show the signed tag
that was merged that is embedded in the merge commit. It also can
show the signature made on the commit with "git commit -S".
* "git branch --edit-description" can be used to add descriptive text
to explain what a topic branch is about.
* "git fmt-merge-msg" learned to take the branch description into
account when preparing a merge summary that "git merge" records
when merging a local branch.
* "git request-pull" has been updated to convey more information
useful for integrators to decide if a topic is worth merging and
what is pulled is indeed what the requestor asked to pull,
including:
- the tip of the branch being requested to be merged;
- the branch description describing what the topic is about;
- the contents of the annotated tag, when requesting to pull a tag.
* "git pull" learned to notice 'pull.rebase' configuration variable,
which serves as a global fallback for setting 'branch.<name>.rebase'
configuration variable per branch.
* "git tag" learned "--cleanup" option to control how the whitespaces
and empty lines in tag message are cleaned up.
* "gitweb" learned to show side-by-side diff.
Also contains minor documentation updates and code clean-ups.
Fixes since v1.7.8
------------------
Unless otherwise noted, all the fixes since v1.7.8 in the maintenance
releases are contained in this release (see release notes to them for
details).
----------------------------------------------------------------
Changes since v1.7.9-rc0 are as follows:
Ben Walton (1):
Use perl instead of sed for t8006-blame-textconv test
Carlos Martín Nieto (1):
archive: re-allow HEAD:Documentation on a remote invocation
Clemens Buchacher (1):
credentials: unable to connect to cache daemon
Jeff King (5):
send-email: multiedit is a boolean config option
attr: don't confuse prefixes with leading directories
attr: drop misguided defensive coding
attr: fix leak in free_attr_elem
thin-pack: try harder to use preferred base objects as base
Junio C Hamano (11):
attr.c: make bootstrap_attr_stack() leave early
attr.c: clarify the logic to pop attr_stack
Documentation: rerere's rr-cache auto-creation and rerere.enabled
Prepare for 1.7.6.6
Prepare for 1.7.7.6
Prepare for 1.7.8.4
request-pull: use the real fork point when preparing the message
Update draft release notes to 1.7.6.6
Update draft release notes to 1.7.7.6
Update draft release notes to 1.7.8.4
Git 1.7.9-rc1
Matthieu Moy (1):
gitweb: accept trailing "/" in $project_list
Michael Haggerty (3):
receive-pack: move more work into write_head_info()
show_ref(): remove unused "flag" and "cb_data" arguments
write_head_info(): handle "extra refs" locally
Nguyễn Thái Ngọc Duy (1):
t2203: fix wrong commit command
Sebastian Schuberth (2):
t9200: On MSYS, do not pass Windows-style paths to CVS
git-cvsexportcommit: Fix calling Perl's rel2abs() on MSYS
Thomas Rast (1):
mailinfo documentation: accurately describe non -k case
^ permalink raw reply
* Commit changes to remote repository
From: ruperty @ 2012-01-13 20:29 UTC (permalink / raw)
To: git
Being new to git I am probably not doing things correctly so pointers in the
right direction would be useful.
What I want to do make changes on my laptop and commit them to a remote
repository. Here is what I have done,
1. Created a repository on my remote linux host, in a folder of cource code,
by,
git init
git add *
git commit
2. On my laptop I did a git clone pointing by ssh to the remote repo which
downloaded all the files to my local system.
3. I changed a file locally and did a commit.
4. I then wanted to update the remote repo with my change, which I did with
a git push, but that didn't work, getting this error,
remote: error: refusing to update checked out branch:
refs/heads/master^[[K
remote: error: By default, updating the current branch in a non-bare
repository^[[K.......
What am I doing wrong?
I was following the tutorial at
http://book.git-scm.com/3_distributed_workflows.html
I did search for this issue in this list but didn't understand the
responses.
Rupert
--
View this message in context: http://git.661346.n2.nabble.com/Commit-changes-to-remote-repository-tp7185551p7185551.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [RFC][PATCH v2] git on Mac OS and precomposed unicode
From: Torsten Bögershausen @ 2012-01-13 21:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, tb
In-Reply-To: <7vd3asejrr.fsf@alter.siamese.dyndns.org>
On 01/09/2012 08:52 PM, Junio C Hamano wrote:
[snip]
>probe_utf8_pathname_composition(path, len);
Done
[snip]
>and implementation of the function body in compat/darwin.c (Didn't I see a
>comment on the name of this file, by the way? What was the conclusion of
> the discussion?).
I renamed the compat/darwin.[ch] into compat/precomposed_utf8.[ch]
>> +{
>> + int i = 0;
>> + int first_arg = 0; /* convert everything */
>> + const char *oldarg;
>> + char *newarg;
>> + iconv_t ic_precompose;
>> +
>> + git_config(precomposed_unicode_config, NULL);
>
> Hmmmmm. Is it safe to call git_config() this early in the program? Have
> we determined if we are in a git managed repository and where its $GIT_DIR
> is?
>
According to my understanding, yes:
git_config is called with the custom function precomposed_unicode_config():
git_config(precomposed_unicode_config, NULL);
where
precomposed_unicode_config()
fishes for the config variable "core.precomposedunicode" and puts the
result into
int precomposed_unicode_config.
After that, when precomposed_unicode_config==0, argv_precomposed() will
return.
I'll send the V3 RFC/PATCH
/Torsten
^ permalink raw reply
* [RFC][PATCH v3] git on Mac OS and precomposed unicode
From: tb @ 2012-01-13 21:53 UTC (permalink / raw)
To: gitster, git; +Cc: tboegi
Changes since V2:
- renamed compat/darwin.[ch] into compat/precomposed_utf8.[ch]
- builtin/init-db.c: use probe_utf8_pathname_composition()
- fix in reencode_string_iconv(): Don't call iconv_close()
- Allways convert all arguments, no special handling for "git commit"
Changes since last version:
- Improved testcase t/t3910-mac-os-precompose.sh:
test "git commit -- pathspec" (Thanks Junio)
- Improved the converting of argv[] for "git commit"
===============
Purpose:
This patch is a suggestion to work around the unpleasenties
when Mac OS is decomposing unicode filenames.
The suggested change:
a) is only used under Mac OS
b) can be switched off by a configuration variable
c) is optimized to handle ASCII only filename
d) will improve the interwork between Mac OS, Linux and Windows*
via git push/pull, using USB sticks (technically speaking VFAT)
or mounted network shares using samba.
* (Not all Windows versions support UTF-8 yet:
Msysgit needs the unicode branch, cygwin supports UTF-8 since 1.7)
Runtime configuration:
A new confguration variable is added: "core.precomposedunicode"
This variable is only used on Mac OS.
If set to false, git behaves exactly as older versions of git.
When a new git version is installed and there is a repository
where the configuration "core.precomposedunicode" is not present,
the new git is backward compatible.
When core.precomposedunicode=true, all filenames are stored in precomposed
unicode in the index (technically speaking precomposed UTF-8).
Even when readdir() under Mac OS returns filenames as decomposed.
Implementation:
Two files are added to the "compat" directory, darwin.h and darwin.c.
They implement basically 4 new functions:
precomposed_utf8_opendir(), precomposed_utf8_readdir(),
precomposed_utf8_closedir() argv_precompose()
Compile time configuration:
A new compiler option PRECOMPOSED_UNICODE is introduced in the Makefile,
so that the patch can be switched off completely at compile time.
No decomposed file names in a git repository:
In order to prevent that ever a file name in decomposed unicode is entering
the index, a "brute force" attempt is taken:
all arguments into git (technically argv[1]..argv[n]) are converted into
precomposed unicode.
This is done in git.c by calling argv_precompose().
This function is actually a #define, and it is only defined under Mac OS.
Nothing is converted on any other OS.
Implementation details:
The main work is done in precomposed_utf8_readdir() and argv_precompose().
The conversion into precomposed unicode is done by using iconv,
where decomposed is denoted by "UTF-8-MAC" and precomposed is "UTF-8".
When already precomposed unicode is precomposed, the string is returned
unchanged.
Thread save:
Since there is no need for argv_precompose()to be thread-save, one iconv
instance is created at the beginning and kept for all conversions.
Even readdir() is not thread-save, so that precomposed_utf8_opendir() will call
iconv_open() once and keep the instance for all calls of precomposed_utf8_readdir()
until precomposed_utf8_close() is called.
Auto sensing:
When creating a new git repository with "git init" or "git clone", the
"core.precomposedunicode" will be set automatically to "true" or "false".
Typically core.precomposedunicode is "true" on HFS and VFAT.
It is even true for file systems mounted via SAMBA onto a Linux box,
and "false" for drives mounted via NFS onto a Linux box.
New test case:
The new t3910-mac-os-precompose.sh is added to check if a filename
can be reached either in precomposed or decomposed unicode (NFC or NFD).
Torsten Bögershausen (1):
git on Mac OS and precomposed unicode
Documentation/config.txt | 9 ++
Makefile | 3 +
builtin/init-db.c | 2 +
compat/precomposed_utf8.c | 213 ++++++++++++++++++++++++++++++++++++++++++
compat/precomposed_utf8.h | 39 ++++++++
git-compat-util.h | 9 ++
git.c | 1 +
t/t0050-filesystem.sh | 1 +
t/t3910-mac-os-precompose.sh | 117 +++++++++++++++++++++++
9 files changed, 394 insertions(+), 0 deletions(-)
create mode 100644 compat/precomposed_utf8.c
create mode 100644 compat/precomposed_utf8.h
create mode 100755 t/t3910-mac-os-precompose.sh
--
1.7.8.rc0.43.gb49a8
^ permalink raw reply
* [RFC][PATCH v3] git on Mac OS and precomposed unicode
From: tb @ 2012-01-13 21:53 UTC (permalink / raw)
To: gitster, git; +Cc: tboegi
Allow git on Mac OS to store file names in the index in precomposed unicode,
while the file system used decomposed unicode.
When a file called "LATIN CAPITAL LETTER A WITH DIAERESIS"
(in utf-8 encoded as 0xc3 0x84) is created,
the filesystem converts "precomposed unicode" into "decomposed unicode",
which means that readdir() will return 0x41 0xcc 0x88.
When true, git reverts the unicode decomposition of filenames.
This is useful when pulling/pushing from repositories containing utf-8
encoded filenames using precomposed utf-8 (like Linux).
This feature is automatically switched on when "git init" is run,
and the file system is doing UTF-8 decompostion.
(Which has been observed on HFS+, SMBFS and VFAT, but not on NFS)
It can be switched off by setting core.macosforcenfc=false
It is implemented by re-defining the readdir() functions.
File names are converted into precomposed UTF-8.
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
Documentation/config.txt | 9 ++
Makefile | 3 +
builtin/init-db.c | 2 +
compat/precomposed_utf8.c | 213 ++++++++++++++++++++++++++++++++++++++++++
compat/precomposed_utf8.h | 39 ++++++++
git-compat-util.h | 9 ++
git.c | 1 +
t/t0050-filesystem.sh | 1 +
t/t3910-mac-os-precompose.sh | 117 +++++++++++++++++++++++
9 files changed, 394 insertions(+), 0 deletions(-)
create mode 100644 compat/precomposed_utf8.c
create mode 100644 compat/precomposed_utf8.h
create mode 100755 t/t3910-mac-os-precompose.sh
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 2959390..01b9465 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -175,6 +175,15 @@ The default is false, except linkgit:git-clone[1] or linkgit:git-init[1]
will probe and set core.ignorecase true if appropriate when the repository
is created.
+core.precomposedunicode::
+ This option is only used by Mac OS implementation of git.
+ When core.precomposedunicode=true,
+ git reverts the unicode decomposition of filenames done by Mac OS.
+ This is useful when pulling/pushing from repositories containing utf-8
+ encoded filenames using precomposed unicode (like Linux).
+ When false, file names are handled fully transparent by git.
+ If in doubt, set core.precomposedunicode=false.
+
core.trustctime::
If false, the ctime differences between the index and the
working tree are ignored; useful when the inode change time
diff --git a/Makefile b/Makefile
index b21d2f1..a912b45 100644
--- a/Makefile
+++ b/Makefile
@@ -519,6 +519,7 @@ LIB_H += compat/bswap.h
LIB_H += compat/cygwin.h
LIB_H += compat/mingw.h
LIB_H += compat/obstack.h
+LIB_H += compat/precomposed_utf8.h
LIB_H += compat/win32/pthread.h
LIB_H += compat/win32/syslog.h
LIB_H += compat/win32/poll.h
@@ -884,6 +885,8 @@ ifeq ($(uname_S),Darwin)
endif
NO_MEMMEM = YesPlease
USE_ST_TIMESPEC = YesPlease
+ COMPAT_OBJS += compat/precomposed_utf8.o
+ BASIC_CFLAGS += -DPRECOMPOSED_UNICODE
endif
ifeq ($(uname_S),SunOS)
NEEDS_SOCKET = YesPlease
diff --git a/builtin/init-db.c b/builtin/init-db.c
index 0dacb8b..06953df 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -290,6 +290,8 @@ static int create_default_files(const char *template_path)
strcpy(path + len, "CoNfIg");
if (!access(path, F_OK))
git_config_set("core.ignorecase", "true");
+
+ probe_utf8_pathname_composition(path, len);
}
return reinit;
diff --git a/compat/precomposed_utf8.c b/compat/precomposed_utf8.c
new file mode 100644
index 0000000..46d35af
--- /dev/null
+++ b/compat/precomposed_utf8.c
@@ -0,0 +1,213 @@
+#define __PRECOMPOSED_UNICODE_C__
+
+#include <stdlib.h>
+#include <string.h>
+#include <stdio.h>
+#include <stdint.h>
+
+#include "../cache.h"
+#include "../utf8.h"
+
+#include "precomposed_utf8.h"
+
+static int mac_os_precomposed_unicode;
+const static char *repo_encoding = "UTF-8";
+const static char *path_encoding = "UTF-8-MAC";
+
+
+/* Code borrowed from utf8.c */
+#if defined(OLD_ICONV) || (defined(__sun__) && !defined(_XPG6))
+ typedef const char * iconv_ibp;
+#else
+ typedef char * iconv_ibp;
+#endif
+
+static char *reencode_string_iconv(const char *in, size_t insz, iconv_t conv)
+{
+ size_t outsz, outalloc;
+ char *out, *outpos;
+ iconv_ibp cp;
+
+ outsz = insz;
+ outalloc = outsz + 1; /* for terminating NUL */
+ out = xmalloc(outalloc);
+ outpos = out;
+ cp = (iconv_ibp)in;
+
+ while (1) {
+ size_t cnt = iconv(conv, &cp, &insz, &outpos, &outsz);
+
+ if (cnt == -1) {
+ size_t sofar;
+ if (errno != E2BIG) {
+ free(out);
+ return NULL;
+ }
+ /* insz has remaining number of bytes.
+ * since we started outsz the same as insz,
+ * it is likely that insz is not enough for
+ * converting the rest.
+ */
+ sofar = outpos - out;
+ outalloc = sofar + insz * 2 + 32;
+ out = xrealloc(out, outalloc);
+ outpos = out + sofar;
+ outsz = outalloc - sofar - 1;
+ }
+ else {
+ *outpos = '\0';
+ break;
+ }
+ }
+ return out;
+}
+
+static size_t has_utf8(const char *s, size_t maxlen, size_t *strlen_c)
+{
+ const uint8_t *utf8p = (const uint8_t*) s;
+ size_t strlen_chars = 0;
+ size_t ret = 0;
+
+ if ((!utf8p) || (!*utf8p))
+ return 0;
+
+ while((*utf8p) && maxlen) {
+ if (*utf8p & 0x80)
+ ret++;
+ strlen_chars++;
+ utf8p++;
+ maxlen--;
+ }
+ if (strlen_c)
+ *strlen_c = strlen_chars;
+
+ return ret;
+}
+
+
+void probe_utf8_pathname_composition(char *path, int len)
+{
+ const static char *auml_nfc = "\xc3\xa4";
+ const static char *auml_nfd = "\x61\xcc\x88";
+ int output_fd;
+ path[len] = 0;
+ strcpy(path + len, auml_nfc);
+ output_fd = open(path, O_CREAT|O_EXCL|O_RDWR, 0600);
+ if (output_fd >=0) {
+ close(output_fd);
+ path[len] = 0;
+ strcpy(path + len, auml_nfd);
+ if (0 == access(path, R_OK))
+ git_config_set("core.precomposedunicode", "true");
+ else
+ git_config_set("core.precomposedunicode", "false");
+ path[len] = 0;
+ strcpy(path + len, auml_nfc);
+ unlink(path);
+ }
+}
+
+
+static int precomposed_unicode_config(const char *var, const char *value, void *cb)
+{
+ if (!strcasecmp(var, "core.precomposedunicode")) {
+ mac_os_precomposed_unicode = git_config_bool(var, value);
+ return 0;
+ }
+ return 1;
+}
+
+void argv_precompose(int argc, const char **argv)
+{
+ int i = 0;
+ const char *oldarg;
+ char *newarg;
+ iconv_t ic_precompose;
+
+ git_config(precomposed_unicode_config, NULL);
+ if (!mac_os_precomposed_unicode)
+ return;
+
+ ic_precompose = iconv_open(repo_encoding, path_encoding);
+ if (ic_precompose == (iconv_t) -1)
+ return;
+
+ while (i < argc) {
+ size_t namelen;
+ oldarg = argv[i];
+ if (has_utf8(oldarg, (size_t)-1, &namelen)) {
+ newarg = reencode_string_iconv(oldarg, namelen, ic_precompose);
+ if (newarg)
+ argv[i] = newarg;
+ }
+ i++;
+ }
+ iconv_close(ic_precompose);
+}
+
+
+PRECOMPOSED_UTF_DIR * precomposed_utf8_opendir(const char *dirname)
+{
+ PRECOMPOSED_UTF_DIR *precomposed_utf8_dir;
+ precomposed_utf8_dir = malloc(sizeof(PRECOMPOSED_UTF_DIR));
+ if (!precomposed_utf8_dir)
+ return NULL;
+
+ precomposed_utf8_dir->dirp = opendir(dirname);
+ if (!precomposed_utf8_dir->dirp) {
+ free(precomposed_utf8_dir);
+ return NULL;
+ }
+ precomposed_utf8_dir->ic_precompose = iconv_open(repo_encoding, path_encoding);
+ if (precomposed_utf8_dir->ic_precompose == (iconv_t) -1) {
+ closedir(precomposed_utf8_dir->dirp);
+ free(precomposed_utf8_dir);
+ return NULL;
+ }
+
+ return precomposed_utf8_dir;
+}
+
+struct dirent * precomposed_utf8_readdir(PRECOMPOSED_UTF_DIR *precomposed_utf8_dirp)
+{
+ struct dirent *res;
+ size_t namelen = 0;
+
+ res = readdir(precomposed_utf8_dirp->dirp);
+ if (!res || !mac_os_precomposed_unicode || !has_utf8(res->d_name, (size_t)-1, &namelen))
+ return res;
+ else {
+ int olderrno = errno;
+ size_t outsz = sizeof(precomposed_utf8_dirp->dirent_nfc.d_name) - 1; /* one for \0 */
+ char *outpos = precomposed_utf8_dirp->dirent_nfc.d_name;
+ iconv_ibp cp;
+ size_t cnt;
+ size_t insz = namelen;
+ cp = (iconv_ibp)res->d_name;
+
+ /* Copy all data except the name */
+ memcpy(&precomposed_utf8_dirp->dirent_nfc, res,
+ sizeof(precomposed_utf8_dirp->dirent_nfc)-sizeof(precomposed_utf8_dirp->dirent_nfc.d_name));
+ errno = 0;
+
+ cnt = iconv(precomposed_utf8_dirp->ic_precompose, &cp, &insz, &outpos, &outsz);
+ if (cnt < sizeof(precomposed_utf8_dirp->dirent_nfc.d_name) -1) {
+ *outpos = 0;
+ errno = olderrno;
+ return &precomposed_utf8_dirp->dirent_nfc;
+ }
+ errno = olderrno;
+ return res;
+ }
+}
+
+
+int precomposed_utf8_closedir(PRECOMPOSED_UTF_DIR *precomposed_utf8_dirp)
+{
+ int ret_value;
+ ret_value = closedir(precomposed_utf8_dirp->dirp);
+ if (precomposed_utf8_dirp->ic_precompose != (iconv_t)-1)
+ iconv_close(precomposed_utf8_dirp->ic_precompose);
+ free(precomposed_utf8_dirp);
+ return ret_value;
+}
diff --git a/compat/precomposed_utf8.h b/compat/precomposed_utf8.h
new file mode 100644
index 0000000..3eca7b9
--- /dev/null
+++ b/compat/precomposed_utf8.h
@@ -0,0 +1,39 @@
+#ifndef __PRECOMPOSED_UNICODE_H__
+#if defined (PRECOMPOSED_UNICODE)
+#include <sys/stat.h>
+#include <sys/types.h>
+#include <dirent.h>
+#include <iconv.h>
+
+
+typedef struct {
+ iconv_t ic_precompose;
+ DIR *dirp;
+ struct dirent dirent_nfc;
+} PRECOMPOSED_UTF_DIR;
+
+char *str_precompose(const char *in, iconv_t ic_precompose);
+void argv_precompose(int argc, const char **argv);
+void probe_utf8_pathname_composition(char *, int);
+
+PRECOMPOSED_UTF_DIR *precomposed_utf8_opendir(const char *dirname);
+struct dirent *precomposed_utf8_readdir(PRECOMPOSED_UTF_DIR *dirp);
+int precomposed_utf8_closedir(PRECOMPOSED_UTF_DIR *dirp);
+
+#ifndef __PRECOMPOSED_UNICODE_C__
+
+#define opendir(n) precomposed_utf8_opendir(n)
+#define readdir(d) precomposed_utf8_readdir(d)
+#define closedir(d) precomposed_utf8_closedir(d)
+#define DIR PRECOMPOSED_UTF_DIR
+#endif /* __PRECOMPOSED_UNICODE_C__ */
+
+#else
+
+#define str_precompose(in,i_nfd2nfc) (NULL)
+#define argv_precompose(c,v)
+#define probe_utf8_pathname_composition(a,b)
+#endif /* PRECOMPOSED_UNICODE */
+
+#define __PRECOMPOSED_UNICODE_H__
+#endif /* __PRECOMPOSED_UNICODE_H__ */
diff --git a/git-compat-util.h b/git-compat-util.h
index 230e198..708b178 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -90,6 +90,15 @@
#include <windows.h>
#endif
+#if defined (PRECOMPOSED_UNICODE)
+#include "compat/precomposed_utf8.h"
+#else
+#define str_precompose(in,i_nfd2nfc) (NULL)
+#define argv_precompose(c,v)
+#define probe_utf8_pathname_composition(a,b)
+
+#endif
+
#include <unistd.h>
#include <stdio.h>
#include <sys/stat.h>
diff --git a/git.c b/git.c
index 8e34903..6b2ffb7 100644
--- a/git.c
+++ b/git.c
@@ -298,6 +298,7 @@ static int run_builtin(struct cmd_struct *p, int argc, const char **argv)
startup_info->have_repository) /* get_git_dir() may set up repo, avoid that */
trace_repo_setup(prefix);
}
+ argv_precompose(argc, argv);
commit_pager_choice();
if (!help && p->option & NEED_WORK_TREE)
diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh
index 1542cf6..befe39e 100755
--- a/t/t0050-filesystem.sh
+++ b/t/t0050-filesystem.sh
@@ -126,6 +126,7 @@ test_expect_success "setup unicode normalization tests" '
test_create_repo unicode &&
cd unicode &&
+ git config core.precomposedunicode false &&
touch "$aumlcdiar" &&
git add "$aumlcdiar" &&
git commit -m initial &&
diff --git a/t/t3910-mac-os-precompose.sh b/t/t3910-mac-os-precompose.sh
new file mode 100755
index 0000000..439e266
--- /dev/null
+++ b/t/t3910-mac-os-precompose.sh
@@ -0,0 +1,117 @@
+#!/bin/sh
+#
+# Copyright (c) 2012 Torsten Bögershausen
+#
+
+test_description='utf-8 decomposed (nfd) converted to precomposed (nfc)'
+
+. ./test-lib.sh
+
+Adiarnfc=`printf '\303\204'`
+Odiarnfc=`printf '\303\226'`
+Adiarnfd=`printf 'A\314\210'`
+Odiarnfd=`printf 'O\314\210'`
+
+mkdir junk &&
+>junk/"$Adiarnfc" &&
+case "$(cd junk && echo *)" in
+ "$Adiarnfd")
+ test_nfd=1
+ ;;
+ *) ;;
+esac
+rm -rf junk
+
+if test "$test_nfd"
+then
+ test_expect_success "detect if nfd needed" '
+ precomposedunicode=`git config --bool core.precomposedunicode` &&
+ test "$precomposedunicode" = true
+ '
+ test_expect_success "setup" '
+ >x &&
+ git add x &&
+ git commit -m "1st commit" &&
+ git rm x &&
+ git commit -m "rm x"
+ '
+ test_expect_success "setup case mac" '
+ git checkout -b mac_os
+ '
+ # This will test nfd2nfc in readdir()
+ test_expect_success "add file Adiarnfc" '
+ echo f.Adiarnfc >f.$Adiarnfc &&
+ git add f.$Adiarnfc &&
+ git commit -m "add f.$Adiarnfc"
+ '
+ # This will test nfd2nfc in git stage()
+ test_expect_success "stage file d.Adiarnfd/f.Adiarnfd" '
+ mkdir d.$Adiarnfd &&
+ echo d.$Adiarnfd/f.$Adiarnfd >d.$Adiarnfd/f.$Adiarnfd &&
+ git stage d.$Adiarnfd/f.$Adiarnfd &&
+ git commit -m "add d.$Adiarnfd/f.$Adiarnfd"
+ '
+ test_expect_success "add link Adiarnfc" '
+ ln -s d.$Adiarnfd/f.$Adiarnfd l.$Adiarnfc &&
+ git add l.$Adiarnfc &&
+ git commit -m "add l.Adiarnfc"
+ '
+ # This will test git log
+ test_expect_success "git log f.Adiar" '
+ git log f.$Adiarnfc > f.Adiarnfc.log &&
+ git log f.$Adiarnfd > f.Adiarnfd.log &&
+ test -s f.Adiarnfc.log &&
+ test -s f.Adiarnfd.log &&
+ test_cmp f.Adiarnfc.log f.Adiarnfd.log &&
+ rm f.Adiarnfc.log f.Adiarnfd.log
+ '
+ # This will test git ls-files
+ test_expect_success "git lsfiles f.Adiar" '
+ git ls-files f.$Adiarnfc > f.Adiarnfc.log &&
+ git ls-files f.$Adiarnfd > f.Adiarnfd.log &&
+ test -s f.Adiarnfc.log &&
+ test -s f.Adiarnfd.log &&
+ test_cmp f.Adiarnfc.log f.Adiarnfd.log &&
+ rm f.Adiarnfc.log f.Adiarnfd.log
+ '
+ # This will test git mv
+ test_expect_success "git mv" '
+ git mv f.$Adiarnfd f.$Odiarnfc &&
+ git mv d.$Adiarnfd d.$Odiarnfc &&
+ git mv l.$Adiarnfd l.$Odiarnfc &&
+ git commit -m "mv Adiarnfd Odiarnfc"
+ '
+ # Files can be checked out as nfc
+ # And the link has been corrected from nfd to nfc
+ test_expect_success "git checkout nfc" '
+ rm f.$Odiarnfc &&
+ git checkout f.$Odiarnfc
+ '
+ # Make it possible to checkout files with their NFD names
+ test_expect_success "git checkout file nfd" '
+ rm -f f.* &&
+ git checkout f.$Odiarnfd
+ '
+ # Make it possible to checkout links with their NFD names
+ test_expect_success "git checkout link nfd" '
+ rm l.* &&
+ git checkout l.$Odiarnfd
+ '
+ test_expect_success "setup case mac2" '
+ git checkout master &&
+ git reset --hard &&
+ git checkout -b mac_os_2
+ '
+ # This will test nfd2nfc in git commit
+ test_expect_success "commit file d2.Adiarnfd/f.Adiarnfd" '
+ mkdir d2.$Adiarnfd &&
+ echo d2.$Adiarnfd/f.$Adiarnfd >d2.$Adiarnfd/f.$Adiarnfd &&
+ git add d2.$Adiarnfd/f.$Adiarnfd &&
+ git commit -m "add d2.$Adiarnfd/f.$Adiarnfd" -- d2.$Adiarnfd/f.$Adiarnfd
+ '
+else
+ say "Skipping nfc/nfd tests"
+fi
+ #git commit -m "add d2.$Adiarnfd/f.$Adiarnfd" -- d2.$Adiarnfd/f.$Adiarnfd
+
+test_done
--
1.7.8.rc0.43.gb49a8
^ permalink raw reply related
* Re: [RFC][PATCH v3] git on Mac OS and precomposed unicode
From: Jonathan Nieder @ 2012-01-13 22:56 UTC (permalink / raw)
To: tb; +Cc: gitster, git
In-Reply-To: <201201132253.00799.tboegi@web.de>
Hi,
tb wrote:
> Purpose:
[...]
> Runtime configuration:
[...]
> Implementation:
[...]
> Compile time configuration:
[...]
> Implementation details:
[....]
> Thread safety:
[...]
> Auto sensing:
[...]
> New test case:
This information, to the extent that it is useful at all, belongs in
the commit log. That is, the commit message should concisely say
everything a person would want to know when reading a patch, whether
reading it to review it for inclusion, to make sure it still works
when making a related change, to consider whether it is safe to
upgrade to a version including the change, to understand what is
happening when a bug is tracked down to be caused by that commit, or
for some other reason.
So please do not use a cover letter that separates this information
when sending a single patch.
> Changes since [...]
This kind of information that does not belong in the commit message
can go after the "---" in the same message as the patch.
I haven't read the patch yet, except to glance at it and see some
nitpicks I can mention later (e.g., source files should not #include
anything else before git-compat-util.h or cache.h), and the approach
seems likely to be sane; I'm mentioning this to help you present the
information in a way that can save myself and other reviewers some
trouble for the next round.
Thanks much for your work, and hope that helps.
Regards,
Jonathan
^ permalink raw reply
* Sending patches with KMail (Re: [PATCH] git-blame.el: Fix compilation warnings.)
From: Jonathan Nieder @ 2012-01-13 23:31 UTC (permalink / raw)
To: Rüdiger Sonderfeld
Cc: git, davidk, Sergei Organov, Kevin Ryde, Michele Ballabio
In-Reply-To: <2304907.sEfEeC6Eon@descartes>
Hi,
Rüdiger Sonderfeld wrote:
> On Thursday 12 January 2012 10:26:41 Jonathan Nieder wrote:
>> These lines should be left out [*].
>
> Sorry, I wasn't sure whether to remove them or not. I followed the description
> in git-format-patch(1) on how to send patches with kmail. I'll remove them in
> the future. Thanks for the advice.
Oh, thanks for the pointer. How about something like this?
The hints at [1] might also be useful, in case you would like to try
and consider improving the manpage to document them if they work.
-- >8 --
Subject: Documentation/format-patch: mention removal of in-body headers for KMail
The opening "From " line and following lines in "git format-patch"
From 13c41b41b832d41680ccd33a2422ef8217965566 Mon Sep 17 00:00:00 2001
From: Jonathan Nieder <jrnieder@gmail.com>
Date: Fri, 13 Jan 2012 17:22:41 -0600
are for your mailer and should be omitted except for fields that
differ from the mail header when reading your patch into an email
body. Otherwise "git am" thinks these lines are part of the commit
message when trying to reproduce the resulting patch from an mbox
automatically. Add a reminder in this direction to the KMail recipe.
Suggested-by: Rüdiger Sonderfeld <ruediger@c-plusplus.de>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
[1] http://thread.gmane.org/gmane.comp.version-control.git/171580/focus=171720
Documentation/git-format-patch.txt | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 6ea9be77..5e1d6d2c 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -462,8 +462,10 @@ This should help you to submit patches inline using KMail.
4. Use Message -> Insert file... and insert the patch.
-5. Back in the compose window: add whatever other text you wish to the
- message, complete the addressing and subject fields, and press send.
+5. Back in the compose window: remove the "`From $SHA1 $magic_timestamp`"
+ marker and unwanted in-body headers, add whatever other text you wish
+ to the message, complete the addressing and subject fields, and
+ press send.
EXAMPLES
--
1.7.8.3
^ permalink raw reply related
* Re: Sending patches with KMail (Re: [PATCH] git-blame.el: Fix compilation warnings.)
From: Junio C Hamano @ 2012-01-14 0:59 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Rüdiger Sonderfeld, git, davidk, Sergei Organov, Kevin Ryde,
Michele Ballabio
In-Reply-To: <20120113233158.GD7343@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> The hints at [1] might also be useful, in case you would like to try
> and consider improving the manpage to document them if they work.
Don't you need similar updates to sections for other MUAs and procedures?
I suspect that the reason why you added the new text there is because you
know KMail users are very lazy bunch, and once they see a "KMail"
subsection, they will skip everything outside the subsection. Thunderbird
users would also be lazy---after choosing one of the three approaches
presented, they will skip anything outside the subsubsection. So I can
understand that we would need something in these individual subsections,
but the advice does not logically belong there.
Perhaps rephrasing the early part of the Discussion section, with an
illustration that is designed to be more visible, would be a better
approach?
For example, we could take your log message and stuff it there:
The opening "From " line and following lines in "git format-patch" are
for your mailer and should be omitted except for fields that differ from
the mail header when reading your patch into an email body. For example,
the output of your format-patch may begin like this:
From 13c41b41b832d41680ccd33a2422ef8217965566 Mon Sep 17 00:00:00 2001
From: Jonathan Nieder <jrnieder@gmail.com>
Date: Fri, 13 Jan 2012 17:22:41 -0600
Subject: Documentation/format-patch: mention removal of in-body headers
The opening "From " line and following lines in ...
The part you should send in the body of your e-mail message begins at the
first blank line. The "From $SHA1 $magic_timestamp" line and other header
lines are there to make it look like a mbox, and if you send it in e-mail,
they will become redundant.
You can leave "From:" and/or "Subject:" lines in, if they are
different from the e-mail you will be sending out (e.g. you are
forwarding a patch written by somebody else, as a follow up to an
ongoing discussion and do not want the subject of your e-mail message
to help threading). E.g. your message _may_ begin like this:
From: Jonathan Nieder <jrnieder@gmail.com>
Subject: Documentation/format-patch: mention removal of in-body headers
The opening "From " line and following lines in ...
when you are not Jonathan, and you are sending it as a response to
an existing discussion thread.
Or something like that?
^ permalink raw reply
* Re: SVN -> Git *but* with special changes
From: Abscissa @ 2012-01-14 3:43 UTC (permalink / raw)
To: git
In-Reply-To: <1326405138283-7181897.post@n2.nabble.com>
Someone on a different message board noticed that it seemed like it was
trying to strip and already-stripped path in git-svn.perl, so I went in
there, changed the "die" to "print", and after a "make && sudo make install"
it seems to work fine now. Probably not the proper way to fix it, but it
seems to work for me.
It does now fail to delete directories once they actually *are* deleted in
the SVN repo, which is kinda sloppy, but it doesn't hurt anything, so I can
live with that.
--
View this message in context: http://git.661346.n2.nabble.com/SVN-Git-but-with-special-changes-tp6840904p7186699.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox