* Re: What's in git.git (stable)
From: Junio C Hamano @ 2006-12-22 21:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200612222156.21215.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
> ...
>>>> Possibilities:
>>>>
>>>> (1) Forget about that "protection" business. If you do not
>>>> want mistakes, use 'branch.*.merge' but otherwise we will
>>>> continue to follow the good old "first set of branches"
>>>> rule.
>>>
>>> What about marking default branch to merge explicitely using
>>> "Merge:" in remotes/<repo>, or remote.<name>.merge?
>>
>> Sorry, how is that an improvement over the current branch.*.merge?
>> and how would that help not breaking existing setups?
>
> I meant that in addition to forgetting about "protection" business.
> This would be intermediate improvement over old behavior.
I do not think so. It does not talk about "when on my local
branch X do this", and applies to all pulls from the named
remote. Then longstanding rule of merging the first set of
branches is just fine and as expressive. You see them the first
in the list, and you already know they somehow matter more.
On the other hand, I think Santi's branch.*.merge (done in
commit 5372806a) _was_ a real improvement.
> Perhaps make "protection" business optional, default to on for
> new users?
Now the question is how you would tell "new users".
The possibility (2) is not even good enough, because even old
timers work in a newly cloned repositories.
^ permalink raw reply
* Re: [PATCH 2/2] git-commit-tree: if i18n.commitencoding is utf-8 (default), check it
From: Junio C Hamano @ 2006-12-22 21:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612222204010.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Now, git-commit-tree refuses to commit when i18n.commitencoding is
> either unset, or set to "utf-8", and the commit message does not
> minimally conform to the UTF-8 encoding.
>
> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> ---
>
> Unfortunately, I could not think of a shorter oneline description.
> But my next patch fixes at least the output in shortlog.
I think the rule that you described on the one-line description
makes more sense than "either unset of set to utf-8". In other
words, I'd prefer doing this in a repository that explicitly
asks for it.
I do not want to get burned by too many incompatible changes X-<.
^ permalink raw reply
* Re: [PATCH 1/4] gitweb: Add missing show '...' links change.
From: Junio C Hamano @ 2006-12-22 21:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Robert Fitzsimons, git
In-Reply-To: <emhdru$he9$3@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Robert Fitzsimons wrote:
>
>> I'm also resubmiting the original optimizations patches with a
>> few changes.
>
> Nice series of patches. Ack (FWIW).
Thanks both.
^ permalink raw reply
* Re: [PATCH 1/2] libgit.a: add some UTF-8 handling functions
From: Junio C Hamano @ 2006-12-22 21:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nicolas Pitre, Uwe Kleine-König, git
In-Reply-To: <Pine.LNX.4.63.0612222233150.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> If you do wrapped_text, I think you do not _want_ strlen (the
>> definition to me of strlen is "number of characters in the
>> string"). What you want is a function that returns the number
>> of columns consumed when displayed on monospace terminal.
>
> To me, characters are the symbols occupying one "column" each. Bytes are
> the 8-bit thingies that you usually use to encode the characters.
I cannot tell from your reponse if you are very well aware of
Asian "double-width" characters and your version of strlen()
counts one such character as two, or if you are totally unaware
about the issue and your function returns 1 for a string that
consists of a single such character.
If the former, then the function is not strlen() anymore, and if
the latter, then it is unusable for wrapping purposes.
^ permalink raw reply
* Re: Separating "add path to index" from "update content in index"
From: Carl Worth @ 2006-12-22 21:57 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Peter Baumann, git
In-Reply-To: <Pine.LNX.4.64.0612212337180.18171@xanadu.home>
[-- Attachment #1: Type: text/plain, Size: 7044 bytes --]
On Fri, 22 Dec 2006 00:06:32 -0500 (EST), Nicolas Pitre wrote:
> On Thu, 21 Dec 2006, Carl Worth wrote:
>
> > So, I think what I really want here is a complete separation in the
> > interface between adding a path to the index and updating content into
> > the index.
>
> Strangely enough I think this separation is unnecessary and redundent.
One argument I would make in favor of the separation is that the two
operations are conceptually distinct from the user point-of-view. But
that's really hard to nail down since all users have different points
of view and different conceptual models, (though I think the recent
post about similar file names and accidentally adding a file meant to
be untracked is evidence in favor of this argument).
There's a much less fuzzy, and strictly technical argument that can be
made. Right now, we document "git add" as being useful for two
purposes, ("adding new files" and adding "modified files...to the set
of changes"). These two operations can be described as:
1. Add new path to the index, and update the content
2. Update the content for an existing path
The technical argument for separating the notions of "add path" and
"update content" comes from looking at how to specify path names to
these operations, (and recursive names in particular).
By definition, the first operation, ("add new paths"), must accept
path names from the working tree as it exists in the filesystem.
Since without this operation there's no way to get paths into the
index in the first place. So, any recursive operation for this
operation should traverse the tree of files as they exist in the file
system. This is quite useful in the case of creating a new directory
in a project and wanting to add all of the files in that directory:
git add new-directory
However, the second operation ("update content") need not be defined
in terms of the tree in the filesystem, and is in fact quite useful
when it operates on the tree that exists "within" git. For example, if
I have been hacking on a feature change in a 'source' directory that's
not quite finished yet, and also a new test for that feature in a
'test' directory, (that I do consider ready), then it would be
convenient to be able to stage all the content in that directory be
similarly specifying just the directory name. For example, I'd like to
be able to do:
git update-index test
(which doesn't actually work right now). But doing "git add test"
would be wrong, since it would also add any untracked files, and I
don't want that. This "update content for known files" operation
should recurse on the tree that git knows about, and not the tree of
files in my filesystem.
> > We've long had a command that updates content to the index, and it
> > takes a command-line option (--add) to allow it to first do the
> > necessary path addition as well.
>
> And it is still there.
Yes, update-index still exists. But we're relegating that to
plumbing. What I'm proposing is that we should have a porcelain
command that just does the "update content for known files part" and
that merging this with something that makes files "become known" to
git for the first time is a mistake.
> The problem lies with the git-diff interface then, not git-add.
I don't think so. I'm quite convinced that the fact that "git diff"
shows the difference from the index to the working tree is correct and
can't really be changed. The issue I'm talking about here is that for
"tracked" files git currently provides a way for me to have my edits
of I can
> > I think the best would be:
> >
> > git update-index --all
> >
> > which would still allow room for:
> >
> > git add --all
...
> There is no consistency needed between git-add and git-update-index.
> The first is for users while the second is more suited for scripting
> your own interface.
But it's not actually update-index that I want. I agree that it's a
plumbing thing that users shouldn't use. What I want is two different
pieces of porcelain here, each focusing one one simple task. One to
add the path to the index, and one to update content in the index for
a path that exists.
> > git refresh --add
> > or:
> > git add --refresh
> >
> > would provide the behavior that currently is provided by "git add",
That was actually a bad idea, and I'll retract that part. Neither of
these options should exist. We already have an all-singing,
all-dancing git-update-index that can do anything we want. We really
don't need two new pieces of porcelain that also do everything
update-index does but just have different defaults.
Much better would be for "git add" and "git refresh" to each just
stick to a single task and to do it well, (git has UNIX philosophy,
right?). So "git add" should just add paths to the index, "git
refresh" should just update content for existing paths in the index,
and we don't need a lot of options for either command for users to
have to wade through.
With those simple commands, we could have nice, separate behavior for:
git add some-dir
and:
git refresh some-dir
and if someone wants the existing "add path and update content"
behavior of git add then it should be a simple matter of aliasing to
the combination of "git add" followed by "git refresh".
> I think you are trying to solve the wrong problem, or at least solve a
> problem the wrong way. The problem is that git-diff doesn't give you
> the output you expect because of the index interfering in your work
> flow. And I understand that.
I don't think that's the right characterization. I like that "git
diff" works from the index, and I take advantage of that by
intentionally putting content into the index. The problem is that "git
add" currently forces content into the index even if I consciously do
not want it there yet. I just want a way to tell "git diff", (and
commit -a), to start looking at new files, but without staging the
current content of those files into the index.
> But the best solution is really for git-diff to have a mode where you
> could display a diff between the work tree and the index, _or_ the index
> and HEAD, for each file listed in the index while giving priority to the
> former.
I don't understand what you are proposing here. What would this mode
display? How would it decide?
> With this, for users acustomed to "commit -a", the natural and pretty
> consistent way to see a diff for such a commit before actually
> performing it would bi "diff -a". Isn't it logical?
A new option ("git diff -a") doesn't help much. There's already "git
diff HEAD" and I understand what it does. The problem is having "git
diff" usually work, and then having to remember to do something else
when it doesn't do the right thing.
[Though a command-line option would have one advantage over HEAD which
is that it's easier to document command-line options than a magic
name like HEAD. This "hard to document" bug is something that affects
all of the magic names, (HEAD, ORIG_HEAD, MERGE_HEAD, etc.), and
keeps their functionality quite hidden from new users of git.]
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: specify charset for commits
From: Uwe Kleine-König @ 2006-12-22 22:02 UTC (permalink / raw)
To: Johannes Schindelin, Junio C Hamano, Alexander Litvinov, git
In-Reply-To: <20061222150948.GA6005@cepheus>
Hello,
Uwe Kleine-König wrote:
> def is_utf8_str(s):
> cnt_furtherbytes = 0
> for c in s:
> if cnt_furtherbytes > 0:
> if ord(c) & 0xc0 == 0x80:
> cnt_furtherbytes -= 1
> else:
> return False
> else:
> if ord(c) < 0x80:
> continue
> elif ord(c) < 0xc0:
> return False
> elif ord(c) < 0xe0:
> cnt_furtherbytes = 1
> elif ord(c) < 0xf0:
> cnt_furtherbytes = 2
> elif ord(c) < 0xf8:
> cnt_furtherbytes = 3
> elif ord(c) < 0xfc:
> cnt_furtherbytes = 4
> elif ord(c) < 0xfe:
> cnt_furtherbytes = 5
> else:
> return False
> return True
While I washed the dishes I noticed that the last "return True" should
be "return cnt_furtherbytes == 0". Just before someone else corrects me
... :-)
Best regards
Uwe
--
Uwe Kleine-König
http://www.google.com/search?q=parsec%5E2*Joule%2FNewton+in+tablespoon
^ permalink raw reply
* Re: [PATCH 1/2] libgit.a: add some UTF-8 handling functions
From: Uwe Kleine-König @ 2006-12-22 22:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Nicolas Pitre, git
In-Reply-To: <Pine.LNX.4.63.0612222233150.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Hello Johannes,
Johannes Schindelin wrote:
> On Fri, 22 Dec 2006, Junio C Hamano wrote:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > > This adds utf8_byte_count(), utf8_strlen() and print_wrapped_text().
> > >
> > > The most important is probably utf8_strlen(), which returns the length
> > > of the text, if it is in UTF-8, otherwise -1.
> > >
> > > Note that we do not go the full nine yards: we could also check that
> > > the character is encoded with the minimum amount of bytes, as pointed
> > > out by Uwe Kleine-Koenig.
> > >
> > > The function print_wrapped_text() can be used to wrap text to a certain
> > > line length.
> >
> > If you do wrapped_text, I think you do not _want_ strlen (the
> > definition to me of strlen is "number of characters in the
> > string"). What you want is a function that returns the number
> > of columns consumed when displayed on monospace terminal.
>
> To me, characters are the symbols occupying one "column" each. Bytes are
> the 8-bit thingies that you usually use to encode the characters.
Quoting utf-8(7):
are no longer valid in UTF-8 locales. Firstly, a single byte
does not necessarily correspond any more to a single character.
Secondly, since modern terminal emulators in UTF-8 mode also
support Chinese, Japanese, and Korean double-width characters as
well as non-spacing combining characters, outputting a single
character does not necessarily advance the cursor by one
position as it did in ASCII. Library functions such as
mbsrtowcs(3) and wcswidth(3) should be used today to count
characters and cursor positions.
I'd prefer using a similar naming scheme. To acknowledge Junio,
wcslen(3) (the wide-character equivalent of the strlen() function)
counts the number of (wide-)characters in a string.
Best regards,
Uwe
--
Uwe Kleine-König
http://www.google.com/search?q=e+%5E+%28i+pi%29
^ permalink raw reply
* Re: [PATCH 1/2] libgit.a: add some UTF-8 handling functions
From: Uwe Kleine-König @ 2006-12-22 22:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Nicolas Pitre, git
In-Reply-To: <Pine.LNX.4.63.0612222201200.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Hello,
Johannes Schindelin wrote:
> Note that we do not go the full nine yards: we could also check that
> the character is encoded with the minimum amount of bytes, as pointed
> out by Uwe Kleine-Koenig.
While we're talking about UTF-8 in commit-logs: I'd prefer to have my
name properly written with o-umlaut.
Best regards
Uwe
--
Uwe Kleine-König
http://www.google.com/search?q=0+degree+Celsius+in+kelvin
^ permalink raw reply
* Re: [PATCH 1/2] libgit.a: add some UTF-8 handling functions
From: Johannes Schindelin @ 2006-12-22 22:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Uwe Kleine-König, git
In-Reply-To: <7vpsabwq34.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 22 Dec 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> If you do wrapped_text, I think you do not _want_ strlen (the
> >> definition to me of strlen is "number of characters in the
> >> string"). What you want is a function that returns the number
> >> of columns consumed when displayed on monospace terminal.
> >
> > To me, characters are the symbols occupying one "column" each. Bytes are
> > the 8-bit thingies that you usually use to encode the characters.
>
> I cannot tell from your reponse if you are very well aware of
> Asian "double-width" characters and your version of strlen()
> counts one such character as two, or if you are totally unaware
> about the issue and your function returns 1 for a string that
> consists of a single such character.
>
> If the former, then the function is not strlen() anymore, and if
> the latter, then it is unusable for wrapping purposes.
The latter. Oh, well. Call me a Western idiot.
And scrap that patch.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] git-commit-tree: if i18n.commitencoding is utf-8 (default), check it
From: Johannes Schindelin @ 2006-12-22 22:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7ozwqf5.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 22 Dec 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Now, git-commit-tree refuses to commit when i18n.commitencoding is
> > either unset, or set to "utf-8", and the commit message does not
> > minimally conform to the UTF-8 encoding.
> >
> > Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> > ---
> >
> > Unfortunately, I could not think of a shorter oneline description.
> > But my next patch fixes at least the output in shortlog.
>
> I think the rule that you described on the one-line description
> makes more sense than "either unset of set to utf-8". In other
> words, I'd prefer doing this in a repository that explicitly
> asks for it.
Well, the problem is this line:
environment.c:21:char git_commit_encoding[MAX_ENCODING_LENGTH] = "utf-8";
> I do not want to get burned by too many incompatible changes X-<.
Understandable.
Ciao,
Dscho
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Carl Worth @ 2006-12-22 22:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Francis Moreau, Jay Cliburn, git, Jeff Garzik
In-Reply-To: <Pine.LNX.4.64.0612212009370.3536@woody.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1965 bytes --]
On Thu, 21 Dec 2006 20:13:52 -0800 (PST), Linus Torvalds wrote:
> I do it all the time, I never even use the old-fashioned syntax any more.
> It's much more concise and easy to read, and it has all the nice shortcuts
> (like empty meaning "HEAD", so you can do "git diff ..next" to see the
> diff from HEAD to another branch).
I can understand the advantage of a shortcut like "git diff ..next",
but I still don't understand why it's the comparison of HEAD and next
that's really interesting here. Wouldn't comparing the merge-base to
next be more desirable? For example, if I'm considering whether to
merge in next or not, why should I care to see in the diff all the
irrelevant stuff that's happened on HEAD since next branched off?
But, really, I still don't understand exactly _what_ "diff a..b" even
means. Can you explain it to me?
Presumably the rev-parse magic is happening to the arguments. So does
the diff code just end up seeing the expanded equivalent of "b ^a" and
then just use the ^ to decide which tree to be on the left side or
something?
> It's also useful exactly because of the semantics of things like "...".
And now I'm really confused. If I'm not mistaken, rev-parse will turn
"a...b" into something like "a b ^$(merge-base a b)", right? So does
the diff code now end up seeing three different tree specifiers? What
does it do with that? And how is this useful? (As you said before,
diff is always going to end up acting on only two items, so I don't
see where there could be an interesting distinction from how you
obtain two items from "a..b" compared to "a...b".) But it might be
just that I'm really confused here.
> So "git diff a b" doesn't even look good to me any more, because it's
> literally missing that mental "to" that the ".." adds for me when I read
> it.
OK, that's fine. But can you comment on why you want the comparison
between the tips and not something based on a comparison from the
merge-base to a tip?
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] libgit.a: add some UTF-8 handling functions
From: Junio C Hamano @ 2006-12-22 22:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nicolas Pitre, Uwe Kleine-König, git
In-Reply-To: <Pine.LNX.4.63.0612222319230.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > To me, characters are the symbols occupying one "column" each. Bytes are
>> > the 8-bit thingies that you usually use to encode the characters.
>>
>> I cannot tell from your reponse if you are very well aware of
>> Asian "double-width" characters and your version of strlen()
>> counts one such character as two, or if you are totally unaware
>> about the issue and your function returns 1 for a string that
>> consists of a single such character.
>>
>> If the former, then the function is not strlen() anymore, and if
>> the latter, then it is unusable for wrapping purposes.
>
> The latter. Oh, well. Call me a Western idiot.
>
> And scrap that patch.
Hey, don't give up too quickly. Although the execution of the
initial revision might have been less than desirable, the series
really meant well and was in the right direction. We do that
all the time ;-).
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Linus Torvalds @ 2006-12-22 22:34 UTC (permalink / raw)
To: Carl Worth; +Cc: Francis Moreau, Jay Cliburn, git, Jeff Garzik
In-Reply-To: <877iwjinda.wl%cworth@cworth.org>
On Fri, 22 Dec 2006, Carl Worth wrote:
>
> I can understand the advantage of a shortcut like "git diff ..next",
> but I still don't understand why it's the comparison of HEAD and next
> that's really interesting here.
I can't understand why people complain about this.
YOU DON'T HAVE TO USE IT.
Nobvody forces you. Really. And dammit, if I want to compare HEAD and
next, I compare HEAD and next. You have absolutely no business saying that
you don't understand why I'd want to do it. It's MY LIFE.
> But, really, I still don't understand exactly _what_ "diff a..b" even
> means. Can you explain it to me?
It means exactly the same as "diff a b".
It's that simple.
So now go away. Stop complaining.
Linus
^ permalink raw reply
* Re: [PATCH 1/2] libgit.a: add some UTF-8 handling functions
From: Johannes Schindelin @ 2006-12-22 22:34 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git
In-Reply-To: <20061222221913.GA3071@cepheus>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 791 bytes --]
Dear Mr Zeisberg,
On Fri, 22 Dec 2006, Uwe Kleine-König wrote:
> Johannes Schindelin wrote:
> > Note that we do not go the full nine yards: we could also check that
> > the character is encoded with the minimum amount of bytes, as pointed
> > out by Uwe Kleine-Koenig.
> While we're talking about UTF-8 in commit-logs: I'd prefer to have my
> name properly written with o-umlaut.
I did this because I have no easy way to input UTF-8, and because I am
lazy, and because I did not know how many times this patch has to be
revised.
Apart from that, it seems that the checking of UTF-8 is actually quite
simple, and we could even copy it from
http://www.cl.cam.ac.uk/~mgk25/ucs/utf8_check.c, where the check you
proposed is included.
But I had enough of UTF-8 for a day.
Ciao,
Dscho
^ permalink raw reply
* Re: confusion over the new branch and merge config
From: Jakub Narebski @ 2006-12-22 22:40 UTC (permalink / raw)
To: Nicolas Pitre, Junio Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0612221609430.18171@xanadu.home>
Nicolas Pitre wrote:
>
> Could you at least keep me in CC when replying to me please?
I have Cc-ed you and Junio, but somehow message I send to mailing
list loses the Cc:. Perhaps it is time to change news client (KMail),
or upgrade it...
> On Fri, 22 Dec 2006, Jakub Narebski wrote:
>
>> <opublikowany i wysłany>
>
> ?
Sorry, it is added (in my locale) when both sending reply via mail,
and to newsgroup (and to git mailing list via GMane NNTP news2mail
interface).
>> Perhaps less confusing, but also less powerfull. Current notation
>> allows for pulling _without need for tracking branches_.
>
> Is this really a killer feature worth the confusion?
>
> If you put the repo to pull from on the command line then sure you might
> not want a tracking branch, but if you go to the trouble of adding a
> branch.blah.merge config entry then you certainly don't mind having a
> tracking branch?
I'm not sure. On one hand you have this feature, pulling without tracking
branch (which is nice workflow for one-branch repos at least), on the
other hand the tracking branch tells us the remote, and we can check if
they match.
On another hand, you can have two remotes which are the same repository
(mirrors for example)... although that would be better solved by allowing
multiple url...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Junio C Hamano @ 2006-12-22 22:45 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <877iwjinda.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> On Thu, 21 Dec 2006 20:13:52 -0800 (PST), Linus Torvalds wrote:
>> I do it all the time, I never even use the old-fashioned syntax any more.
>> It's much more concise and easy to read, and it has all the nice shortcuts
>> (like empty meaning "HEAD", so you can do "git diff ..next" to see the
>> diff from HEAD to another branch).
>
> I can understand the advantage of a shortcut like "git diff ..next",
> but I still don't understand why it's the comparison of HEAD and next
> that's really interesting here. Wouldn't comparing the merge-base to
> next be more desirable?
"git diff ...next" should work just as well, I think.
> But, really, I still don't understand exactly _what_ "diff a..b" even
> means. Can you explain it to me?
diff between two points.
> Presumably the rev-parse magic is happening to the arguments. So does
> the diff code just end up seeing the expanded equivalent of "b ^a" and
> then just use the ^ to decide which tree to be on the left side or
> something?
Exactly; diff just reuses the non-magic part of revision
parameter parsing without using the ancestry traversal
machinery (which is the magic part).
>> It's also useful exactly because of the semantics of things like "...".
>
> And now I'm really confused. If I'm not mistaken, rev-parse will turn
> "a...b" into something like "a b ^$(merge-base a b)", right? So does
> the diff code now end up seeing three different tree specifiers? What
> does it do with that?
It knows that rev-parse makes it "b a ^base", and it knows what
the user meant is "base..b".
That's all because we teach them to spell "a...b" when they want
"base..b". Similarly, because we allow them to spell "a..b"
when they mean "between two points, a and b", it handles "b ^a"
as the equivalent to giving two trees separately, as "a b".
> And how is this useful? (As you said before,
> diff is always going to end up acting on only two items, so I don't
> see where there could be an interesting distinction from how you
> obtain two items from "a..b" compared to "a...b".) But it might be
> just that I'm really confused here.
I do not think you are seriously saying that comparing A and
B in this picture is meaningless:
o---o---B
/
---M---o---A
Yes, it is often useful to compare M and B, but that "often" is
limited to the phase of the workflow where you are at A and are
contemplating of merging B. But merging two forked branches is
not the only thing you do.
Comparing two revisions regardless of how they are topologically
related is useful as often. It is only that it may not as
useful while you are trying to merge B into A.
So there are two ways to let you do both, and they need to be
specified differently (.. vs ...) because you need to tell it
to do which one.
^ permalink raw reply
* Re: warning merge message
From: Josef Weidendorfer @ 2006-12-22 22:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Luben Tuikov, git
In-Reply-To: <7vodpvy6sf.fsf@assigned-by-dhcp.cox.net>
On Friday 22 December 2006 22:12, Junio C Hamano wrote:
> People for a long time observed "the first set of branches" rule
> was often a wrong thing to do while on a branch other than
> 'master' (but we do not want to add hardcoded 'master'
> unnecessarily), and I recently screwed up by changing the logic
> in such a way that everything is marked as not-for-merge unless
> branches.*.merge is not set when pulling from the default
> remote,
Ah, yes.
I saw your patch and thought: Wow, that means to fully throw
away the previous behavior, which could upset people ;-)
But then I thought: Hmm... probably on purpose, as this
"the first set of branches" rule really was strange.
> which was completely bogus and bitten Luben.
So I see you actually _wanted_ to keep old behavior
for existing repositories.
In a previous discussion, you talked about switching to
the new behavior (ie. getting rid of this "first set of
branches" rule) when there is at least one branch.*.merge
setting in the config file.
Unfortunately I can not see an easy way to check this with
repo-config, as there is no wildcard support for keys
(Ok, I can do a list of keys and grep).
I think it is better to provide an option
"pull.do-not-follow-the-first-set-of-branches-rule".
And we should make this the default after init-db or clone.
Josef
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Jakub Narebski @ 2006-12-22 23:00 UTC (permalink / raw)
To: git
In-Reply-To: <877iwjinda.wl%cworth@cworth.org>
[Cc: Carl Worth <cworth@cworth.org>, Linus Torvalds <torvalds@osdl.org>
git@vger.kernel.org]
Carl Worth wrote:
> On Thu, 21 Dec 2006 20:13:52 -0800 (PST), Linus Torvalds wrote:
>> I do it all the time, I never even use the old-fashioned syntax any more.
>> It's much more concise and easy to read, and it has all the nice shortcuts
>> (like empty meaning "HEAD", so you can do "git diff ..next" to see the
>> diff from HEAD to another branch).
>
> I can understand the advantage of a shortcut like "git diff ..next",
> but I still don't understand why it's the comparison of HEAD and next
> that's really interesting here. Wouldn't comparing the merge-base to
> next be more desirable? For example, if I'm considering whether to
> merge in next or not, why should I care to see in the diff all the
> irrelevant stuff that's happened on HEAD since next branched off?
>
> But, really, I still don't understand exactly _what_ "diff a..b" even
> means. Can you explain it to me?
For me, it's just a bit of syntactic sugar (I always have in mind that
git-log and friends outputs commit list and use revisions range, while
git-diff and friends needs two (or less) revisions) allowing to
copy'n'paste arguments from "git log a..b" to "git diff a..b"
> Presumably the rev-parse magic is happening to the arguments. So does
> the diff code just end up seeing the expanded equivalent of "b ^a" and
> then just use the ^ to decide which tree to be on the left side or
> something?
And that is just implementation. I don't think anyone uses "git diff b ^a".
>> It's also useful exactly because of the semantics of things like "...".
>
> And now I'm really confused. If I'm not mistaken, rev-parse will turn
> "a...b" into something like "a b ^$(merge-base a b)", right? So does
> the diff code now end up seeing three different tree specifiers? What
> does it do with that? And how is this useful? (As you said before,
> diff is always going to end up acting on only two items, so I don't
> see where there could be an interesting distinction from how you
> obtain two items from "a..b" compared to "a...b".) But it might be
> just that I'm really confused here.
I would have thought that it would be combined diff of a and b against
it's merge base... but it is not.
"git diff a...b" is turned into "git diff a b ^$(git merge-base a b)",
and by a bit of magic (and by a convention) it is turned into
"git diff ^$(merge-base a b) a" (and a...b ceases to be _symmetric_
for git-diff).
I'd like for "git diff --cc a...b" to do 'the right thing' and show
git diff --cc for pretended merge (I'm not sure if with or without
resolving trivial conflicts).
>> So "git diff a b" doesn't even look good to me any more, because it's
>> literally missing that mental "to" that the ".." adds for me when I read
>> it.
>
> OK, that's fine. But can you comment on why you want the comparison
> between the tips and not something based on a comparison from the
> merge-base to a tip?
a..b does not imply merge-base, a...b does.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: warning merge message
From: Junio C Hamano @ 2006-12-22 23:00 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Luben Tuikov, git
In-Reply-To: <200612222349.54363.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> In a previous discussion, you talked about switching to
> the new behavior (ie. getting rid of this "first set of
> branches" rule) when there is at least one branch.*.merge
> setting in the config file.
>
> Unfortunately I can not see an easy way to check this with
> repo-config, as there is no wildcard support for keys
> (Ok, I can do a list of keys and grep).
I think --get-regexp is what you want -- see my "patch for
discussion".
> I think it is better to provide an option
> "pull.do-not-follow-the-first-set-of-branches-rule".
> And we should make this the default after init-db or clone.
Yes, but the problem is that old timers do make new clones.
pull.i-like-the-first-set-of-branches in ~/.gitconfig is the
only thing I can think of but that is too ugly and is already on
the slippery slope of user.expert configuration which I do not
think we want.
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Carl Worth @ 2006-12-22 23:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7iwjwnwh.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 2308 bytes --]
On Fri, 22 Dec 2006 14:45:18 -0800, Junio C Hamano wrote:
> Exactly; diff just reuses the non-magic part of revision
> parameter parsing without using the ancestry traversal
> machinery (which is the magic part).
Thanks, that helps.
> It knows that rev-parse makes it "b a ^base", and it knows what
> the user meant is "base..b".
Ahah! So the "a...b" syntax is how to get at what:
git diff $(git merge-base a b) b
would give. Thanks for explaining, since that was not at all obvious.
> That's all because we teach them to spell "a...b" when they want
> "base..b". Similarly, because we allow them to spell "a..b"
> when they mean "between two points, a and b", it handles "b ^a"
> as the equivalent to giving two trees separately, as "a b".
Where is that teaching happening exactly? Both the "a..b" and "a...b"
forms seem to be entirely missing from the documentation of git
diff. :-)
> I do not think you are seriously saying that comparing A and
> B in this picture is meaningless:
>
> o---o---B
> /
> ---M---o---A
No, I'm certainly not saying that that that comparison is meaningless.
All I was trying to say is that comparing M to B would be meaningful
too, and I hoped that git would provide good syntax for both. If I'm
understanding things correctly now, what exists is:
git diff A B
git diff A..B
Compare A to B
git diff A...B
Compare M to B
So, at the beginning of this thread I wasn't aware that git provided
any short syntax for the "M to B" comparison, (the thread started with
suggestions for adding "git diff $(git merge-base A B) B" to the
hackers guide).
Now, I'm happy to know that git does provide a short syntax for that
useful operation.
My only comment now is that the distinction between ".." and "..." in
git-diff is quite surprising. In fact, in one sense it's exactly
opposite from the distinction of ".." and "..." as used in git log.
For example, given the above graph, "git diff A..B" shows changes due
to all 5 of commits on both branches while "git log -p A..B" shows
only the changes of the 3 commits from M to B.
Meanwhile, "git diff A...B" shows changes due to the 3 commits from M
to B while "git log -p A...B" shows the changes from all 5 of the
commits on both branches.
That's really surprising behavior (to me at least).
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: confusion over the new branch and merge config
From: Junio C Hamano @ 2006-12-22 23:39 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0612221539100.18171@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Thu, 21 Dec 2006, Junio C Hamano wrote:
>
>> Nicolas Pitre <nico@cam.org> writes:
>>
>> > $ git pull origin/next
>> > fatal: The remote end hung up unexpectedly
>> > Cannot get the repository state from git://git.kernel.org/pub/scm/git/git.git/next
>> >
>> > [ WTF? Where that ...pub/scm/git/git.git/next comes from? Hmmm... ]
>>
>> This comes from ancient request by Linus to allow:
>>
>> $ cat .git/remotes/jgarzik
>> URL: master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/
>> $ git pull jgarzik/misc-2.6
>>
>> See http://article.gmane.org/gmane.comp.version-control.git/6181
>> for the full text.
>>
>> Personally I thought this was confusing when I implemented it
>> the first time, and I still find it confusing.
>>
>> I suspect nobody uses it. I am all for removing this "URL
>> prefix shorthand" feature in v1.5.0.
>
> Please do. I'm sure Linus can find a better way now.
Well, "request" was very inprecise word -- I should have said
"suggestion". But I think I agree.
Seconds? Thirds?
-- >8 --
[PATCH] Do not support "partial URL shorthand" anymore.
We used to support specifying the top part of remote URL in
remotes and use that as a short-hand for the URL.
$ cat .git/remotes/jgarzik
URL: git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/
$ git pull jgarzik/misc-2.6
This is confusing when somebody attempts to do this:
$ git pull origin/foo
which is not syntactically correct (unless you have origin/foo.git
repository) and should fail, but it resulted in a mysterious
access to the 'foo' subdirectory of the origin repository.
Which was what it was designed to do, but because this is an
oddball "feature" I suspect nobody uses, let's remove it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-parse-remote.sh | 34 +++++++---------------------------
1 files changed, 7 insertions(+), 27 deletions(-)
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index b163d22..aaef861 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -7,18 +7,7 @@ GIT_DIR=$(git-rev-parse --git-dir 2>/dev/null) || :;
get_data_source () {
case "$1" in
*/*)
- # Not so fast. This could be the partial URL shorthand...
- token=$(expr "z$1" : 'z\([^/]*\)/')
- remainder=$(expr "z$1" : 'z[^/]*/\(.*\)')
- if test "$(git-repo-config --get "remote.$token.url")"
- then
- echo config-partial
- elif test -f "$GIT_DIR/branches/$token"
- then
- echo branches-partial
- else
- echo ''
- fi
+ echo ''
;;
*)
if test "$(git-repo-config --get "remote.$1.url")"
@@ -40,12 +29,7 @@ get_remote_url () {
data_source=$(get_data_source "$1")
case "$data_source" in
'')
- echo "$1" ;;
- config-partial)
- token=$(expr "z$1" : 'z\([^/]*\)/')
- remainder=$(expr "z$1" : 'z[^/]*/\(.*\)')
- url=$(git-repo-config --get "remote.$token.url")
- echo "$url/$remainder"
+ echo "$1"
;;
config)
git-repo-config --get "remote.$1.url"
@@ -54,14 +38,10 @@ get_remote_url () {
sed -ne '/^URL: */{
s///p
q
- }' "$GIT_DIR/remotes/$1" ;;
+ }' "$GIT_DIR/remotes/$1"
+ ;;
branches)
- sed -e 's/#.*//' "$GIT_DIR/branches/$1" ;;
- branches-partial)
- token=$(expr "z$1" : 'z\([^/]*\)/')
- remainder=$(expr "z$1" : 'z[^/]*/\(.*\)')
- url=$(sed -e 's/#.*//' "$GIT_DIR/branches/$token")
- echo "$url/$remainder"
+ sed -e 's/#.*//' "$GIT_DIR/branches/$1"
;;
*)
die "internal error: get-remote-url $1" ;;
@@ -77,7 +57,7 @@ get_default_remote () {
get_remote_default_refs_for_push () {
data_source=$(get_data_source "$1")
case "$data_source" in
- '' | config-partial | branches | branches-partial)
+ '' | branches)
;; # no default push mapping, just send matching refs.
config)
git-repo-config --get-all "remote.$1.push" ;;
@@ -196,7 +176,7 @@ canon_refs_list_for_fetch () {
get_remote_default_refs_for_fetch () {
data_source=$(get_data_source "$1")
case "$data_source" in
- '' | config-partial | branches-partial)
+ '')
echo "HEAD:" ;;
config)
canon_refs_list_for_fetch -d "$1" \
--
1.4.4.3.ge228b
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2006-12-22 23:40 UTC (permalink / raw)
To: git; +Cc: Andy Parkins
In-Reply-To: <200612221111.58071.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> On Friday 2006 December 22 09:37, Junio C Hamano wrote:
>
>> * jc/git-add--interactive (Mon Dec 11 17:09:26 2006 -0800) 2 commits
>> + git-add --interactive: hunk splitting
>> + git-add --interactive
>
> I used this to disentangle a load of changes that I made under pressure and
> turned them into lovely isolated commits. I didn't have any trouble with it,
> and thought it was incredibly useful.
>
> I'd vote for putting it in 1.5 - it's in keeping with the usability theme -
> people love interactive stuff.
Seconds? Thirds? Vetoes?
^ permalink raw reply
* Re: [PATCH 1/2] libgit.a: add some UTF-8 handling functions
From: Johannes Schindelin @ 2006-12-22 23:50 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0612222331581.19693@wbgn013.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 12645 bytes --]
Hi,
On Fri, 22 Dec 2006, Johannes Schindelin wrote:
> Dear Mr Zeisberg,
>
> On Fri, 22 Dec 2006, Uwe Kleine-König wrote:
>
> > Johannes Schindelin wrote:
> > > Note that we do not go the full nine yards: we could also check that
> > > the character is encoded with the minimum amount of bytes, as pointed
> > > out by Uwe Kleine-Koenig.
> > While we're talking about UTF-8 in commit-logs: I'd prefer to have my
> > name properly written with o-umlaut.
>
> I did this because I have no easy way to input UTF-8, and because I am
> lazy, and because I did not know how many times this patch has to be
> revised.
>
> Apart from that, it seems that the checking of UTF-8 is actually quite
> simple, and we could even copy it from
> http://www.cl.cam.ac.uk/~mgk25/ucs/utf8_check.c, where the check you
> proposed is included.
>
> But I had enough of UTF-8 for a day.
Okay, so I lied (this are both patches revised and combined):
--
Makefile | 6 +
builtin-commit-tree.c | 14 ++
utf8.c | 277 +++++++++++++++++++++++++++++++++++++++++++++++++
utf8.h | 8 +
4 files changed, 301 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -234,7 +237,8 @@ LIB_H = \
archive.h blob.h cache.h commit.h csum-file.h delta.h grep.h \
diff.h object.h pack.h pkt-line.h quote.h refs.h list-objects.h sideband.h \
run-command.h strbuf.h tag.h tree.h git-compat-util.h revision.h \
- tree-walk.h log-tree.h dir.h path-list.h unpack-trees.h builtin.h
+ tree-walk.h log-tree.h dir.h path-list.h unpack-trees.h builtin.h \
+ utf8.h
DIFF_OBJS = \
diff.o diff-lib.o diffcore-break.o diffcore-order.o \
@@ -253,7 +257,8 @@ LIB_OBJS = \
revision.o pager.o tree-walk.o xdiff-interface.o \
write_or_die.o trace.o list-objects.o grep.o \
alloc.o merge-file.o path-list.o help.o unpack-trees.o $(DIFF_OBJS) \
- color.o wt-status.o archive-zip.o archive-tar.o shallow.o
+ color.o wt-status.o archive-zip.o archive-tar.o shallow.o \
+ utf8.o
BUILTIN_OBJS = \
builtin-add.o \
diff --git a/builtin-commit-tree.c b/builtin-commit-tree.c
index 856f3cd..ef7cc91 100644
--- a/builtin-commit-tree.c
+++ b/builtin-commit-tree.c
@@ -7,6 +7,7 @@
#include "commit.h"
#include "tree.h"
#include "builtin.h"
+#include "utf8.h"
#define BLOCKING (1ul << 14)
@@ -32,7 +33,7 @@ static void add_buffer(char **bufp, unsigned int *sizep, const char *fmt, ...)
len = vsnprintf(one_line, sizeof(one_line), fmt, args);
va_end(args);
size = *sizep;
- newsize = size + len;
+ newsize = size + len + 1;
alloc = (size + 32767) & ~32767;
buf = *bufp;
if (newsize > alloc) {
@@ -40,7 +41,7 @@ static void add_buffer(char **bufp, unsigned int *sizep, const char *fmt, ...)
buf = xrealloc(buf, alloc);
*bufp = buf;
}
- *sizep = newsize;
+ *sizep = newsize - 1;
memcpy(buf + size, one_line, len);
}
@@ -127,6 +128,15 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
while (fgets(comment, sizeof(comment), stdin) != NULL)
add_buffer(&buffer, &size, "%s", comment);
+ /* And check the encoding */
+ buffer[size] = '\0';
+ if (!strcmp(git_commit_encoding, "utf-8") && !is_utf8(buffer)) {
+ fprintf(stderr, "Commit message does not conform to UTF-8.\n"
+ "Please fix the message,"
+ " or set the config variable i18n.commitencoding.\n");
+ return 1;
+ }
+
if (!write_sha1_file(buffer, size, commit_type, commit_sha1)) {
printf("%s\n", sha1_to_hex(commit_sha1));
return 0;
diff --git a/utf8.c b/utf8.c
new file mode 100644
index 0000000..8daec78
--- /dev/null
+++ b/utf8.c
@@ -0,0 +1,277 @@
+#include "git-compat-util.h"
+#include "utf8.h"
+
+/* This code is originally from http://www.cl.cam.ac.uk/~mgk25/ucs/ */
+
+struct interval {
+ int first;
+ int last;
+};
+
+/* auxiliary function for binary search in interval table */
+static int bisearch(wchar_t ucs, const struct interval *table, int max) {
+ int min = 0;
+ int mid;
+
+ if (ucs < table[0].first || ucs > table[max].last)
+ return 0;
+ while (max >= min) {
+ mid = (min + max) / 2;
+ if (ucs > table[mid].last)
+ min = mid + 1;
+ else if (ucs < table[mid].first)
+ max = mid - 1;
+ else
+ return 1;
+ }
+
+ return 0;
+}
+
+/* The following two functions define the column width of an ISO 10646
+ * character as follows:
+ *
+ * - The null character (U+0000) has a column width of 0.
+ *
+ * - Other C0/C1 control characters and DEL will lead to a return
+ * value of -1.
+ *
+ * - Non-spacing and enclosing combining characters (general
+ * category code Mn or Me in the Unicode database) have a
+ * column width of 0.
+ *
+ * - SOFT HYPHEN (U+00AD) has a column width of 1.
+ *
+ * - Other format characters (general category code Cf in the Unicode
+ * database) and ZERO WIDTH SPACE (U+200B) have a column width of 0.
+ *
+ * - Hangul Jamo medial vowels and final consonants (U+1160-U+11FF)
+ * have a column width of 0.
+ *
+ * - Spacing characters in the East Asian Wide (W) or East Asian
+ * Full-width (F) category as defined in Unicode Technical
+ * Report #11 have a column width of 2.
+ *
+ * - All remaining characters (including all printable
+ * ISO 8859-1 and WGL4 characters, Unicode control characters,
+ * etc.) have a column width of 1.
+ *
+ * This implementation assumes that wchar_t characters are encoded
+ * in ISO 10646.
+ */
+
+static int wcwidth(wchar_t ch)
+{
+ /*
+ * Sorted list of non-overlapping intervals of non-spacing characters,
+ * generated by
+ * "uniset +cat=Me +cat=Mn +cat=Cf -00AD +1160-11FF +200B c".
+ */
+ static const struct interval combining[] = {
+ { 0x0300, 0x0357 }, { 0x035D, 0x036F }, { 0x0483, 0x0486 },
+ { 0x0488, 0x0489 }, { 0x0591, 0x05A1 }, { 0x05A3, 0x05B9 },
+ { 0x05BB, 0x05BD }, { 0x05BF, 0x05BF }, { 0x05C1, 0x05C2 },
+ { 0x05C4, 0x05C4 }, { 0x0600, 0x0603 }, { 0x0610, 0x0615 },
+ { 0x064B, 0x0658 }, { 0x0670, 0x0670 }, { 0x06D6, 0x06E4 },
+ { 0x06E7, 0x06E8 }, { 0x06EA, 0x06ED }, { 0x070F, 0x070F },
+ { 0x0711, 0x0711 }, { 0x0730, 0x074A }, { 0x07A6, 0x07B0 },
+ { 0x0901, 0x0902 }, { 0x093C, 0x093C }, { 0x0941, 0x0948 },
+ { 0x094D, 0x094D }, { 0x0951, 0x0954 }, { 0x0962, 0x0963 },
+ { 0x0981, 0x0981 }, { 0x09BC, 0x09BC }, { 0x09C1, 0x09C4 },
+ { 0x09CD, 0x09CD }, { 0x09E2, 0x09E3 }, { 0x0A01, 0x0A02 },
+ { 0x0A3C, 0x0A3C }, { 0x0A41, 0x0A42 }, { 0x0A47, 0x0A48 },
+ { 0x0A4B, 0x0A4D }, { 0x0A70, 0x0A71 }, { 0x0A81, 0x0A82 },
+ { 0x0ABC, 0x0ABC }, { 0x0AC1, 0x0AC5 }, { 0x0AC7, 0x0AC8 },
+ { 0x0ACD, 0x0ACD }, { 0x0AE2, 0x0AE3 }, { 0x0B01, 0x0B01 },
+ { 0x0B3C, 0x0B3C }, { 0x0B3F, 0x0B3F }, { 0x0B41, 0x0B43 },
+ { 0x0B4D, 0x0B4D }, { 0x0B56, 0x0B56 }, { 0x0B82, 0x0B82 },
+ { 0x0BC0, 0x0BC0 }, { 0x0BCD, 0x0BCD }, { 0x0C3E, 0x0C40 },
+ { 0x0C46, 0x0C48 }, { 0x0C4A, 0x0C4D }, { 0x0C55, 0x0C56 },
+ { 0x0CBC, 0x0CBC }, { 0x0CBF, 0x0CBF }, { 0x0CC6, 0x0CC6 },
+ { 0x0CCC, 0x0CCD }, { 0x0D41, 0x0D43 }, { 0x0D4D, 0x0D4D },
+ { 0x0DCA, 0x0DCA }, { 0x0DD2, 0x0DD4 }, { 0x0DD6, 0x0DD6 },
+ { 0x0E31, 0x0E31 }, { 0x0E34, 0x0E3A }, { 0x0E47, 0x0E4E },
+ { 0x0EB1, 0x0EB1 }, { 0x0EB4, 0x0EB9 }, { 0x0EBB, 0x0EBC },
+ { 0x0EC8, 0x0ECD }, { 0x0F18, 0x0F19 }, { 0x0F35, 0x0F35 },
+ { 0x0F37, 0x0F37 }, { 0x0F39, 0x0F39 }, { 0x0F71, 0x0F7E },
+ { 0x0F80, 0x0F84 }, { 0x0F86, 0x0F87 }, { 0x0F90, 0x0F97 },
+ { 0x0F99, 0x0FBC }, { 0x0FC6, 0x0FC6 }, { 0x102D, 0x1030 },
+ { 0x1032, 0x1032 }, { 0x1036, 0x1037 }, { 0x1039, 0x1039 },
+ { 0x1058, 0x1059 }, { 0x1160, 0x11FF }, { 0x1712, 0x1714 },
+ { 0x1732, 0x1734 }, { 0x1752, 0x1753 }, { 0x1772, 0x1773 },
+ { 0x17B4, 0x17B5 }, { 0x17B7, 0x17BD }, { 0x17C6, 0x17C6 },
+ { 0x17C9, 0x17D3 }, { 0x17DD, 0x17DD }, { 0x180B, 0x180D },
+ { 0x18A9, 0x18A9 }, { 0x1920, 0x1922 }, { 0x1927, 0x1928 },
+ { 0x1932, 0x1932 }, { 0x1939, 0x193B }, { 0x200B, 0x200F },
+ { 0x202A, 0x202E }, { 0x2060, 0x2063 }, { 0x206A, 0x206F },
+ { 0x20D0, 0x20EA }, { 0x302A, 0x302F }, { 0x3099, 0x309A },
+ { 0xFB1E, 0xFB1E }, { 0xFE00, 0xFE0F }, { 0xFE20, 0xFE23 },
+ { 0xFEFF, 0xFEFF }, { 0xFFF9, 0xFFFB }, { 0x1D167, 0x1D169 },
+ { 0x1D173, 0x1D182 }, { 0x1D185, 0x1D18B },
+ { 0x1D1AA, 0x1D1AD }, { 0xE0001, 0xE0001 },
+ { 0xE0020, 0xE007F }, { 0xE0100, 0xE01EF }
+ };
+
+ /* test for 8-bit control characters */
+ if (ch == 0)
+ return 0;
+ if (ch < 32 || (ch >= 0x7f && ch < 0xa0))
+ return -1;
+
+ /* binary search in table of non-spacing characters */
+ if (bisearch(ch, combining, sizeof(combining)
+ / sizeof(struct interval) - 1))
+ return 0;
+
+ /*
+ * If we arrive here, ch is neither a combining nor a C0/C1
+ * control character.
+ */
+
+ return 1 +
+ (ch >= 0x1100 &&
+ /* Hangul Jamo init. consonants */
+ (ch <= 0x115f ||
+ ch == 0x2329 || ch == 0x232a ||
+ /* CJK ... Yi */
+ (ch >= 0x2e80 && ch <= 0xa4cf &&
+ ch != 0x303f) ||
+ /* Hangul Syllables */
+ (ch >= 0xac00 && ch <= 0xd7a3) ||
+ /* CJK Compatibility Ideographs */
+ (ch >= 0xf900 && ch <= 0xfaff) ||
+ /* CJK Compatibility Forms */
+ (ch >= 0xfe30 && ch <= 0xfe6f) ||
+ /* Fullwidth Forms */
+ (ch >= 0xff00 && ch <= 0xff60) ||
+ (ch >= 0xffe0 && ch <= 0xffe6) ||
+ (ch >= 0x20000 && ch <= 0x2fffd) ||
+ (ch >= 0x30000 && ch <= 0x3fffd)));
+}
+
+/*
+ * This function returns the number of columns occupied by the character
+ * pointed to by the variable start. The pointer is updated to point at
+ * the next character. If it was not valid UTF-8, the pointer is set to NULL.
+ */
+int utf8_width(const char **start)
+{
+ unsigned char *s = (unsigned char *)*start;
+ wchar_t ch;
+
+ if (*s < 0x80) {
+ /* 0xxxxxxx */
+ ch = *s;
+ *start += 1;
+ } else if ((s[0] & 0xe0) == 0xc0) {
+ /* 110XXXXx 10xxxxxx */
+ if ((s[1] & 0xc0) != 0x80 ||
+ /* overlong? */
+ (s[0] & 0xfe) == 0xc0)
+ goto invalid;
+ ch = ((s[0] & 0x1f) << 6) | (s[1] & 0x3f);
+ *start += 2;
+ } else if ((s[0] & 0xf0) == 0xe0) {
+ /* 1110XXXX 10Xxxxxx 10xxxxxx */
+ if ((s[1] & 0xc0) != 0x80 ||
+ (s[2] & 0xc0) != 0x80 ||
+ /* overlong? */
+ (s[0] == 0xe0 && (s[1] & 0xe0) == 0x80) ||
+ /* surrogate? */
+ (s[0] == 0xed && (s[1] & 0xe0) == 0xa0) ||
+ /* U+FFFE or U+FFFF? */
+ (s[0] == 0xef && s[1] == 0xbf &&
+ (s[2] & 0xfe) == 0xbe))
+ goto invalid;
+ ch = ((s[0] & 0x0f) << 12) |
+ ((s[1] & 0x3f) << 6) | (s[2] & 0x3f);
+ *start += 3;
+ } else if ((s[0] & 0xf8) == 0xf0) {
+ /* 11110XXX 10XXxxxx 10xxxxxx 10xxxxxx */
+ if ((s[1] & 0xc0) != 0x80 ||
+ (s[2] & 0xc0) != 0x80 ||
+ (s[3] & 0xc0) != 0x80 ||
+ /* overlong? */
+ (s[0] == 0xf0 && (s[1] & 0xf0) == 0x80) ||
+ /* > U+10FFFF? */
+ (s[0] == 0xf4 && s[1] > 0x8f) || s[0] > 0xf4)
+ goto invalid;
+ ch = ((s[0] & 0x07) << 18) | ((s[1] & 0x3f) << 12) |
+ ((s[2] & 0x3f) << 6) | (s[3] & 0x3f);
+ *start += 4;
+ } else {
+invalid:
+ *start = NULL;
+ return 0;
+ }
+
+ return wcwidth(ch);
+}
+
+int is_utf8(const char *text)
+{
+ while (*text) {
+ if (*text == '\n' || *text == '\t' || *text == '\r') {
+ text++;
+ continue;
+ }
+ utf8_width(&text);
+ if (!text)
+ return 0;
+ }
+ return 1;
+}
+
+static void print_spaces(int count)
+{
+ static const char s[] = " ";
+ while (count >= sizeof(s)) {
+ fwrite(s, sizeof(s) - 1, 1, stdout);
+ count -= sizeof(s) - 1;
+ }
+ fwrite(s, count, 1, stdout);
+}
+
+/*
+ * Wrap the text, if necessary. The variable indent is the indent for the
+ * first line, indent2 is the indent for all other lines.
+ */
+void print_wrapped_text(const char *text, int indent, int indent2, int width)
+{
+ int w = indent, assume_utf8 = is_utf8(text);
+ const char *bol = text, *space = NULL;
+
+ for (;;) {
+ char c = *text;
+ if (!c || isspace(c)) {
+ if (w < width || space < 0) {
+ const char *start = bol;
+ if (space)
+ start = space;
+ else
+ print_spaces(indent);
+ fwrite(start, text - start, 1, stdout);
+ if (!c) {
+ putchar('\n');
+ return;
+ } else if (c == '\t')
+ w |= 0x07;
+ space = text;
+ w++;
+ text++;
+ } else {
+ putchar('\n');
+ text = bol = space + 1;
+ space = NULL;
+ w = indent = indent2;
+ }
+ continue;
+ }
+ if (assume_utf8)
+ w += utf8_width(&text);
+ else {
+ w++;
+ text++;
+ }
+ }
+}
diff --git a/utf8.h b/utf8.h
new file mode 100644
index 0000000..a0d7f59
--- /dev/null
+++ b/utf8.h
@@ -0,0 +1,8 @@
+#ifndef GIT_UTF8_H
+#define GIT_UTF8_H
+
+int utf8_width(const char **start);
+int is_utf8(const char *text);
+void print_wrapped_text(const char *text, int indent, int indent2, int len);
+
+#endif
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2006-12-22 23:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Andy Parkins
In-Reply-To: <7vlkkzv6rq.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 22 Dec 2006, Junio C Hamano wrote:
> Andy Parkins <andyparkins@gmail.com> writes:
>
> > On Friday 2006 December 22 09:37, Junio C Hamano wrote:
> >
> >> * jc/git-add--interactive (Mon Dec 11 17:09:26 2006 -0800) 2 commits
> >> + git-add --interactive: hunk splitting
> >> + git-add --interactive
> >
> > I used this to disentangle a load of changes that I made under pressure and
> > turned them into lovely isolated commits. I didn't have any trouble with it,
> > and thought it was incredibly useful.
> >
> > I'd vote for putting it in 1.5 - it's in keeping with the usability theme -
> > people love interactive stuff.
>
> Seconds? Thirds? Vetoes?
Obviously, I like git-hunk-commit better ;-)
Seriously again, I will play with it in the next days.
Ciao,
Dscho
^ permalink raw reply
* Re: warning merge message
From: Josef Weidendorfer @ 2006-12-23 0:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Luben Tuikov, git
In-Reply-To: <7vy7ozv8lz.fsf@assigned-by-dhcp.cox.net>
On Saturday 23 December 2006 00:00, Junio C Hamano wrote:
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
>
> > In a previous discussion, you talked about switching to
> > the new behavior (ie. getting rid of this "first set of
> > branches" rule) when there is at least one branch.*.merge
> > setting in the config file.
> >
> > Unfortunately I can not see an easy way to check this with
> > repo-config, as there is no wildcard support for keys
> > (Ok, I can do a list of keys and grep).
>
> I think --get-regexp is what you want -- see my "patch for
> discussion".
I see. I just read the thread.
The git mailing list is already quite high volume ;-)
Around 150+ new postings a day.
I think I first should browse through any new threads before
answering any mail.
> > I think it is better to provide an option
> > "pull.do-not-follow-the-first-set-of-branches-rule".
> > And we should make this the default after init-db or clone.
>
> Yes, but the problem is that old timers do make new clones.
Yes, they do.
But this is not breaking existing repositories.
If you collect such incompatibilities for the 1.5.0 release
notes and provide the workaround ("remove that pull.do-not ..."
option) to get back the old behavior, it should be fine.
I can imagine that we want to add branch.*.remote/merge lines
with "git checkout -b XXX remotes/YYY". Of course this should
only be done if the pull.do-not is set. Relying on existance
branch.*.merge lines seems fragile for me.
What about putting this option into the config template instead of
setting it in clone?
If somebody always wants the old behavior, he should provide a template
with this option not set.
> pull.i-like-the-first-set-of-branches in ~/.gitconfig is the
> only thing I can think of but that is too ugly and is already on
> the slippery slope of user.expert configuration which I do not
> think we want.
I agree.
Josef
^ 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