* Re: specify charset for commits
From: Uwe Kleine-König @ 2006-12-22 15:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Alexander Litvinov, git
In-Reply-To: <Pine.LNX.4.63.0612220351520.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Hello Johannes,
Johannes Schindelin wrote:
> The problem is: you cannot easily recognize if it is UTF8 or not,
> programatically. There is a good indicator _against_ UTF8, namely the
> first byte can _only_ be 0xxxxxxx, 110xxxxx, 1110xxxx, 11110xxx. But there
> is no _positive_ sign that it is UTF8. For example, many umlauts and other
> special modifications to letters, stay in the range 0x7f-0xff.
That's not the only indication. Here comes a (Python) function that
checks is string s is correctly UTF-8 encoded:
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
An UTF-8 character is either one byte long with the msb 0 or a sequence
starting with a value between 0xc0 and 0xfd (inclusive) and depending on
that first value up to six further bytes in the range 0x80 to 0xbf.
You could even be more strict by checking for Unicode 3.1 conformance
(i.e. a character has to be encoded in it's shortest form).
Look at utf8(7) for further details. (This manpage is included in the
Debian manpages package.)
Best regards
Uwe
--
Uwe Kleine-König
http://www.google.com/search?q=5+choose+3
^ permalink raw reply
* Re: confusion over the new branch and merge config
From: Nicolas Pitre @ 2006-12-22 15:10 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Andy Parkins, git
In-Reply-To: <8c5c35580612220139x491dc3ecwf3fc60dda2fa379f@mail.gmail.com>
On Fri, 22 Dec 2006, Lars Hjemli wrote:
> On 12/22/06, Andy Parkins <andyparkins@gmail.com> wrote:
> > On Thursday 2006 December 21 22:17, Nicolas Pitre wrote:
> > > $ git branch -r
> > > * master
> > > origin/HEAD
> > > origin/html
> > > origin/maint
> > > origin/man
> > > origin/master
> > > origin/next
> > > origin/pu
> > > origin/todo
> >
> > I'm trying to track down why "master" is being shown in this case";
>
> This looks very much like "git branch -a".
Yes it was. I just pasted the wrong line in my example. Sorry.
Nicolas
^ permalink raw reply
* Re: [PATCH] fix vc git
From: Duncan Mak @ 2006-12-22 15:17 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git
In-Reply-To: <87ac1guj9c.fsf@wine.dyndns.org>
On 12/22/06, Alexandre Julliard <julliard@winehq.org> wrote:
>
> OK, but in that case vc-git-registered needs to return failure, you
> cannot call git-ls-files as it may find the file in the wrong
> directory. I'd suggest something like this:
>
Ah, okay. I agree, that is a better patch.
Would you be committing it soon?
Thanks,
Duncan.
^ permalink raw reply
* Re: confusion over the new branch and merge config
From: Alan Chandler @ 2006-12-22 15:25 UTC (permalink / raw)
To: git; +Cc: Andy Parkins, Junio C Hamano
In-Reply-To: <200612220839.36067.andyparkins@gmail.com>
On Friday 22 December 2006 08:39, Andy Parkins wrote:
> Make it almost inconceivable that a remote branch is being starred,
> or that a local branch is making it into the "-r" output.
>
> Alan: could you show a tree of your .git/refs/heads and your
> .git/refs/remotes for the repository that is displaying this error?
It wasn't my repository I was responding to - it was Nicolas Pitre's
post that listed both remote and local branches - and I then looked at
the man page to see what -r did and saw that it said "only" remote
branches.
--
Alan Chandler
http://www.chandlerfamily.org.uk
^ permalink raw reply
* Re: specify charset for commits
From: Nicolas Pitre @ 2006-12-22 15:31 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Alexander Litvinov, Uwe Kleine-König, git
In-Reply-To: <Pine.LNX.4.63.0612220351520.19693@wbgn013.biozentrum.uni-wuerzburg.de>
On Fri, 22 Dec 2006, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 21 Dec 2006, Junio C Hamano wrote:
>
> > (2) update commit-tree to reject non utf-8 log messages and
> > author/committer names when i18n.commitEncoding is _NOT_
> > set, or set to utf-8.
>
> The problem is: you cannot easily recognize if it is UTF8 or not,
> programatically. There is a good indicator _against_ UTF8, namely the
> first byte can _only_ be 0xxxxxxx, 110xxxxx, 1110xxxx, 11110xxx. But there
> is no _positive_ sign that it is UTF8. For example, many umlauts and other
> special modifications to letters, stay in the range 0x7f-0xff.
Still... that would be a good enough thing to have in the majority of
cases, wouldn't it?
Nicolas
^ permalink raw reply
* Re: [PATCH] Keep "git --git-dir" from causing a bus error.
From: Johannes Schindelin @ 2006-12-22 16:08 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: git
In-Reply-To: <20061222135625.GA26084@179.242.249.10.in-addr.arpa>
Hi,
On Fri, 22 Dec 2006, Brian Gernhardt wrote:
> diff --git a/git.c b/git.c
> index 73cf4d4..2b3c9f9 100644
> --- a/git.c
> +++ b/git.c
> @@ -59,11 +59,14 @@ static int handle_options(const char*** argv, int* argc)
> } else if (!strcmp(cmd, "-p") || !strcmp(cmd, "--paginate")) {
> setup_pager();
> } else if (!strcmp(cmd, "--git-dir")) {
> - if (*argc < 1)
> - return -1;
> - setenv("GIT_DIR", (*argv)[1], 1);
> - (*argv)++;
> - (*argc)--;
> + if (*argc < 2) {
> + fprintf(stderr, "No directory given for --git-dir.\n" );
> + usage(git_usage_string);
Usage already exits, so you do not need this:
> + } else {
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] sha1_name(): accept ':directory/' to get at the cache_tree
From: Alex Riesen @ 2006-12-22 16:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0612221316550.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin, Fri, Dec 22, 2006 13:18:55 +0100:
> > > If the cache tree is not up-to-date, it will be updated first. So, now
> > >
> > > $ git show :Documentation/
> > >
> > > will in effect show what files/directories are in the index' version
> > > of the directory Documentation. The three commands
> > >
> > > $ git show :./
> > > $ git show :.
> > > $ git show :
> > >
> > > are all equivalent and show the index' idea of the root directory.
> >
> > That is a bit unexpected if you're not in the root directory of
> > repository, but in some subdir of the working directory.
> > Why root? Why not the current directory relative to root?
>
> Why root? Because you are not asking for the working directory. Use "ls"
> for that. You are asking for the index. If you git-show a commit, you
> don't expect the output to be restricted by the subdirectory you're in,
> either, right?
Of course I do. You're breaking a very well-known and widely used
idiom here: the "." means current or at least somehow related to the
current directory. Why would you expect "git show :." to show
everything from root on if your current directory is "Documentation"?
Yes, it is a commit which "git show" displays, but the patches/diffs
are restricted by filenames, and that is where the old rules come into
play. And I would actually expect ":/" to filter from the root on, and
":." to mean the current directory.
^ permalink raw reply
* Re: Separating "add path to index" from "update content in index"
From: Carl Worth @ 2006-12-22 16:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Peter Baumann, git
In-Reply-To: <7vfyb87bxg.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 2381 bytes --]
At Thu, 21 Dec 2006 21:10:51 -0800, Junio C Hamano wrote:
> I guess my responding to whatever you said was wasted effort,
> and if you do not like "git add" this time, I should not be
> surprised. That's kind of sad ;-).
I hope I'm not coming across as always just complaining. I do think
the new "git add" thing is an improvement. So if nothing else changes,
I still think git's better than it was before this recent round of
improvements.
> I do not remember who advocated for making "git status" the
> preview of "git commit" to happen. Was that also you? I wonder
> how many people use this form:
>
> git status -v path1 path2...
I was involved in the discussions that led to "status -v", yes. As a
new user I was surprised that "git diff" didn't give a commit preview
and you replied with the "status -v" idea. As things have turned out,
I've never used "status -v".
> Sure, what you want is "git add --no-add newfile", and I can
> understand that mode of operation if you are always going to
> commit with "git commit -a". Maybe we can have a config
> variable that makes "commit -a" and "add --no-add" the default
> for these two commands, and we do not have to change anything
> else.
Yes, you could add the "don't update content" as an option to git-add,
and then all that would be left would be a discussion about which
modes get the default and which require configuration options, (and
those discussions generally don't go anywhere).
But don't you see how odd the command "git add --no-add" looks? What
does it mean to add something without adding it? This is just
reinforcing my position that using "add" to mean "update content"
rather muddles things.
> One minor detail I wonder about is what mode bits would you give
> to that placeholder entry.
You could certainly grab them from the named file if it exists. If the
user is going to "commit -a" it won't matter much, right?
> > I think the best would be:
> >
> > git update-index --all
> >
> > which would still allow room for:
> >
> > git add --all
>
> Wasn't it you who said "all" is ambiguous (all known to git vs
> all in this directory)?
Yes. Having "--all" is ambiguous while "git add" is used for both
adding new paths to the index _and_ updating index content. But if
"git add" were restricted to just adding paths to the index as I am
suggesting, then there's no ambiguity at all.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Separating "add path to index" from "update content in index"
From: Carl Worth @ 2006-12-22 16:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Peter Baumann, git
In-Reply-To: <7vfyb87bxg.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 3105 bytes --]
On Thu, 21 Dec 2006 21:10:51 -0800, Junio C Hamano wrote:
> Running diff with index is what I do almost all the time.
Yes, me too. As I said, months ago I had complained about "git diff"
meaning diff from index. But I was wrong. It really is the right thing
> And it is not just limited to adding the contents of a path that
> happened to be told git for the first time. Adding the contents
> of a path that was known to git also happens only when it is in
> a presentable good state. So running "git diff" and not seeing
> what I added before is a GOOD THING.
Yes. Whenever consciously using the index, being able to stash stuff
there and not see it in "git diff" is definitely a good thing.
After a thread not so long ago, someone told me privately that they
really wished they could see more examples of when using the index is
obviously a net win to the user. He mentioned that the oft-cited
"split commit along file boundaries" isn't compelling since the same
behavior can be achieved with "commit file1 file2".
So here's another example that I was using just yesterday:
I implemented an optimization and started testing it. It had the
performance characteristics I wanted, but also introduced a couple
few regressions noticed by the test suite.
So this code wasn't ready to commit, but I stashed it all into the
index. Then I went through an iterative process of fixing the
little regressions (off-by-one bugs, etc.), using "git diff" to
see _only_ the incremental fix, and then stashing the whole result
into the index again.
Then I only committed once all the regressions were fixed.
Note that in the above scenario, the command I've been proposing
recently, ("update the index with the content of all tracked files"),
would have been quite useful.
Also note that with "git commit --amend" one could get a very similar
result by simply using the HEAD commit as the staging area instead of
the index. (And with reflogs, some might like that even better.)
So yes, "git diff" showing the difference from the index is definitely
the right thing. And it's useful whenever I'm consciously using the
index to stash some content, (as in this example), or when git does
that on my behalf (as in a conflicted merge).
My point is that I'm not always interested in stashing content just
because I want to add a new path to the index. For example, let's say
I sit down with my working tree and I just want to remember what I had
been in the middle of doing. I examine the state of things with "git
diff". It doesn't show me the content of any newly-created files, but
I want to see those as well. So I'd love to be able to easily get the
index into a state where "git diff" shows me that content.
And I'm definitely not ready to stash the content of these new
files---I haven't even looked at them yet---that's what I'd like "git
diff" to help me do at this point.
Anyway, you already said you did understand this mode of operation. So
I won't explain it over and over anymore. I really just wanted to
throw out that index-staging example for people.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: What's in git.git (stable)
From: Randal L. Schwartz @ 2006-12-22 17:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodpw46zj.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> git-pull: refuse default merge without branch.*.merge
Argh. How do I get back the old behavior?
"git-pull origin" doesn't seem to be enough.
You just broke a bunch of automated scripts for me.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: What's in git.git (stable)
From: Randal L. Schwartz @ 2006-12-22 17:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <86k60jsvh8.fsf@blue.stonehenge.com>
>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> git-pull: refuse default merge without branch.*.merge
Randal> Argh. How do I get back the old behavior?
Randal> "git-pull origin" doesn't seem to be enough.
Randal> You just broke a bunch of automated scripts for me.
Ahh, it's "git-pull . origin".
Maybe a bit more warning for non-upward-compatible changes though, please.
Or maybe we should presume everything is non-upward compatible? I didn't
think a naked "git-pull" was that out of the ordinary.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: Separating "add path to index" from "update content in index"
From: Nicolas Pitre @ 2006-12-22 17:28 UTC (permalink / raw)
To: Carl Worth; +Cc: Junio C Hamano, Peter Baumann, git
In-Reply-To: <87bqlvj44w.wl%cworth@cworth.org>
On Fri, 22 Dec 2006, Carl Worth wrote:
> I was involved in the discussions that led to "status -v", yes. As a
> new user I was surprised that "git diff" didn't give a commit preview
> and you replied with the "status -v" idea. As things have turned out,
> I've never used "status -v".
What about my diff -a proposal? Did you miss it?
Nicolas
^ permalink raw reply
* Re: [PATCH] Keep "git --git-dir" from causing a bus error.
From: Brian Gernhardt @ 2006-12-22 17:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612221708070.19693@wbgn013.biozentrum.uni-wuerzburg.de>
On Dec 22, 2006, at 11:08 AM, Johannes Schindelin wrote:
>> + fprintf(stderr, "No directory given for --git-dir.\n" );
>> + usage(git_usage_string);
>
> Usage already exits, so you do not need this:
>
>> + } else {
I suppose not. It came out of a) habit and b) experiments with
things that did not exit.
~~ Brian
^ permalink raw reply
* Re: [PATCH] sha1_name(): accept ':directory/' to get at the cache_tree
From: Jakub Narebski @ 2006-12-22 18:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612221315370.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> On Fri, 22 Dec 2006, Jakub Narebski wrote:
>
>> Junio C Hamano wrote:
>>
>>> (2) What does this do when the index is unmerged?
>>
>> I think it should show "git ls-files --unmerged --abbrev", perhaps...
>
> Nah. I'd rather fail out, saying that because there are unmerged entries,
> there is no valid tree in the index.
Well, 'git diff' on unmerged IIRC does 'git diff -cc', so why not 'git show :'
do 'git ls-files --unmerged --abbrev'...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: What's in git.git (stable)
From: Johannes Schindelin @ 2006-12-22 18:09 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Junio C Hamano, git
In-Reply-To: <86fyb7sv9f.fsf@blue.stonehenge.com>
Hi,
On Fri, 22 Dec 2006, Randal L. Schwartz wrote:
> >>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
>
> >>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
> Junio> git-pull: refuse default merge without branch.*.merge
>
> Randal> Argh. How do I get back the old behavior?
> Randal> "git-pull origin" doesn't seem to be enough.
Maybe "git-pull origin master"?
> Randal> You just broke a bunch of automated scripts for me.
>
> Ahh, it's "git-pull . origin".
This is just a merge, not a real pull (it leaves out the fetch part).
> Maybe a bit more warning for non-upward-compatible changes though,
> please.
It is unfortunate that this change broke your scripts. But I really think
that the new behaviour is much saner: If you have different branches, you
probably do not want to pull the _same_ remote branch into _all_ of them.
So, for each branch (e.g. "xyz") for which you have a preferred upstream
(e.g. remote "linus" with branch "master"), say
$ git repo-config branch.xyz.remote linus
$ git repo-config branch.xyz.merge refs/heads/master
Then,
$ git pull
pulls your preferred upstream. But when you pull from another remote, or
into another branch, without specifying which remote branch you want to
pull, git now refuses to blindly pull branch "master". This should prevent
quite some pilot errors.
Ciao,
Dscho
^ permalink raw reply
* Re: What's in git.git (stable)
From: Randal L. Schwartz @ 2006-12-22 18:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0612221902490.19693@wbgn013.biozentrum.uni-wuerzburg.de>
>>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Ahh, it's "git-pull . origin".
Johannes> This is just a merge, not a real pull (it leaves out the fetch part).
OK, so what does what a naked "git-pull" used to do before, which was
"fetch origin, then pull it into the current branch"?
Johannes> So, for each branch (e.g. "xyz") for which you have a preferred upstream
Johannes> (e.g. remote "linus" with branch "master"), say
Johannes> $ git repo-config branch.xyz.remote linus
Johannes> $ git repo-config branch.xyz.merge refs/heads/master
But that's not upward compatible. The default should be the old behavior,
or we need a better way to notify people that this breaks things.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: What's in git.git (stable)
From: Randal L. Schwartz @ 2006-12-22 18:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <861wmrsstc.fsf@blue.stonehenge.com>
>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
Randal> But that's not upward compatible. The default should be the old behavior,
Randal> or we need a better way to notify people that this breaks things.
Not to mention that the manpage still says:
git pull, git pull origin
Fetch the default head from the repository you cloned from and
merge it into your current branch.
So even if I was *looking* for a change in behavior, it wasn't documented.
Nothing changed in that area in recent history.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: What's in git.git (stable)
From: Junio C Hamano @ 2006-12-22 18:58 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86fyb7sv9f.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
>>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
> Junio> git-pull: refuse default merge without branch.*.merge
>
> Randal> Argh. How do I get back the old behavior?
> Randal> "git-pull origin" doesn't seem to be enough.
>
> Randal> You just broke a bunch of automated scripts for me.
>
> Ahh, it's "git-pull . origin".
>
> Maybe a bit more warning for non-upward-compatible changes though, please.
>
> Or maybe we should presume everything is non-upward compatible? I didn't
> think a naked "git-pull" was that out of the ordinary.
Things are supposed to be upward compatible, but this round
until v1.5.0 some things may not be when it is justifiably an
improvement. For example, we've already made 'separate remote'
not only the default but the only layout 'git clone' produces.
I cannot think of others offhand, but I am reasonably certain
there are others. We need a "incompatible changes" list.
The tradtional "pull always merges the first set of branches"
rule, although I was actually very much in favor of it, was
something that was hated by everybody.
It was said that people had lot of trouble after doing "git pull
origin" without any refspecs ("git pull" without any argument
defaults to 'origin' which is backward compatible, if you do not
have branch.*.remote, so that form has the same issues), when on
a branch other than the 'master' branch. "merges the same first
set of branches no matter which branch you are on" was the rule,
but people did not want to merge the ones they usually merge to
their 'master' but wanted some other branch merged.
"branch.*.merge" can be used to specify this, but if you do not
have need for this "merge different branches depending on which
branch I am on", you do not have to use it. Without
"branch.*.merge" for the current branch, we are still backward
compatible and follow the "first set of branches" rule.
The real trouble is that some people further argued that pulling
without 'branch.*.merge' when you might not want to follow the
"first set of branches" rule might be a newbie mistake and
should be warned and forbidden. The commit that broke you was
an attempt for that behaviour. I think that newbie protection
intent is good, but the execution was obviously not.
What I have on 'master' has a little fixup to use 'first set of
branches' rule when the fetch gets only one branch without
complaining. I am still not happy with that either, and at this
point I am not sure if there is a good compromise that does not
break existing setup while offering the newbie protection.
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.
(2) A slight variant of the above; do the "protection" only
when 'branch.*.merge' is defined for _any_ of the branches,
not just the current branch.
(3) A further variant; do not do the above "protection" if the
current branch is 'master' (this further makes 'master'
special, which some people may hate).
^ permalink raw reply
* Re: specify charset for commits
From: Junio C Hamano @ 2006-12-22 19:01 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Johannes Schindelin, Alexander Litvinov, Uwe Kleine-König,
git
In-Reply-To: <Pine.LNX.4.64.0612221030440.18171@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Fri, 22 Dec 2006, Johannes Schindelin wrote:
>
>> Hi,
>>
>> On Thu, 21 Dec 2006, Junio C Hamano wrote:
>>
>> > (2) update commit-tree to reject non utf-8 log messages and
>> > author/committer names when i18n.commitEncoding is _NOT_
>> > set, or set to utf-8.
>>
>> The problem is: you cannot easily recognize if it is UTF8 or not,
>> programatically. There is a good indicator _against_ UTF8, namely the
>> first byte can _only_ be 0xxxxxxx, 110xxxxx, 1110xxxx, 11110xxx. But there
>> is no _positive_ sign that it is UTF8. For example, many umlauts and other
>> special modifications to letters, stay in the range 0x7f-0xff.
>
> Still... that would be a good enough thing to have in the majority of
> cases, wouldn't it?
I think that would be very sane thing to do.
^ permalink raw reply
* Re: What's in git.git (stable)
From: Johannes Schindelin @ 2006-12-22 19:21 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Junio C Hamano, git
In-Reply-To: <861wmrsstc.fsf@blue.stonehenge.com>
Hi,
On Fri, 22 Dec 2006, Randal L. Schwartz wrote:
> >>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de>
> >>>>> writes:
>
> >> Ahh, it's "git-pull . origin".
>
> Johannes> This is just a merge, not a real pull (it leaves out the fetch
> Johannes> part).
>
> OK, so what does what a naked "git-pull" used to do before, which was
> "fetch origin, then pull it into the current branch"?
$ git repo-config branch.xyz.remote origin
$ git repo-config branch.xyz.merge refs/heads/<whateveryourfirstfetchis>
> Johannes> So, for each branch (e.g. "xyz") for which you have a
> Johannes> preferred upstream (e.g. remote "linus" with branch
> Johannes> "master"), say
>
> Johannes> $ git repo-config branch.xyz.remote linus
> Johannes> $ git repo-config branch.xyz.merge refs/heads/master
>
> But that's not upward compatible. The default should be the old
> behavior, or we need a better way to notify people that this breaks
> things.
AFAIK it is not in maint. Not even in 1.4.4.3. So, you got it with master.
So, TFA should have been in a message "What's in git (stable)".
Alas, the commit a71fb0a1: "git-pull: refuse default merge without
branch.*.merge" was merged _after_ the latest announcement.
HOWEVER, it has been in "What's cooking in git (topics)".
Having said that, we could (at least for some time) print a big red
warning for the specific case of "git pull" meaning "git pull origin
<whateveristhefirstfetchedhead>" that this will GO AWAY SOON.
Of course, you would not see it. Only your script.
BTW I would _never_ allow a script to rely on such a DWIM feature.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] sha1_name(): accept ':directory/' to get at the cache_tree
From: Johannes Schindelin @ 2006-12-22 19:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzm9g7duz.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 21 Dec 2006, Junio C Hamano wrote:
> (2) What does this do when the index is unmerged?
$ git show :
a1: unmerged (f16f906ab60483c100d1241dfc39868de9ec9fcb)
a1: unmerged (cf84443e49e1b366fac938711ddf4be2d4d1d9e9)
a1: unmerged (fd7923529855d0b274795ae3349c5e0438333979)
fatal: ambiguous argument ':': unknown revision or path not in the
working tree. Use '--' to separate paths from revisions
We could be a bit nicer, but I think the first three lines speak for
themselves. This is all stderr BTW.
Ciao,
Dscho
^ permalink raw reply
* [PATCH 2/4] gitweb: optimize git_get_last_activity.
From: Robert Fitzsimons @ 2006-12-22 19:38 UTC (permalink / raw)
To: git; +Cc: Robert Fitzsimons
In-Reply-To: <11668162961084-git-send-email-robfitz@273k.net>
Only return one line of output and we don't need the refname value.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
---
gitweb/gitweb.perl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 80c04b8..01e3a8a 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1139,8 +1139,9 @@ sub git_get_last_activity {
$git_dir = "$projectroot/$path";
open($fd, "-|", git_cmd(), 'for-each-ref',
- '--format=%(refname) %(committer)',
+ '--format=%(committer)',
'--sort=-committerdate',
+ '--count=1',
'refs/heads') or return;
my $most_recent = <$fd>;
close $fd or return;
--
1.4.4.3.gc902c
^ permalink raw reply related
* [PATCH 1/4] gitweb: Add missing show '...' links change.
From: Robert Fitzsimons @ 2006-12-22 19:38 UTC (permalink / raw)
To: git; +Cc: Robert Fitzsimons
In-Reply-To: <20061218224327.GG16029@localhost>
Part of the patch for "gitweb: Show '...' links in "summary" view only
if there are more items" (313ce8cee665447e4476d7e8985b270346a8e5a1) is
missing. Add it back in.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
---
With all the tooing and frowing this part of the original patch got
lost. I'm also resubmiting the original optimizations patches with a
few changes.
Robert
gitweb/gitweb.perl | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index ebbc397..80c04b8 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2983,6 +2983,7 @@ sub git_summary {
if (@forklist) {
git_print_header_div('forks');
git_project_list_body(\@forklist, undef, 0, 15,
+ $#forklist <= 15 ? undef :
$cgi->a({-href => href(action=>"forks")}, "..."),
'noheader');
}
--
1.4.4.3.gc902c
^ permalink raw reply related
* [PATCH 4/4] gitweb: optimize git_summary.
From: Robert Fitzsimons @ 2006-12-22 19:38 UTC (permalink / raw)
To: git; +Cc: Robert Fitzsimons
In-Reply-To: <11668162963240-git-send-email-robfitz@273k.net>
We don't need to call git_get_head_hash at all just pass in "HEAD" and
use the return id field.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
---
gitweb/gitweb.perl | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index d2ddac8..b0e6fdf 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2911,9 +2911,9 @@ sub git_project_index {
sub git_summary {
my $descr = git_get_project_description($project) || "none";
- my $head = git_get_head_hash($project);
- my %co = parse_commit($head);
+ my %co = parse_commit("HEAD");
my %cd = parse_date($co{'committer_epoch'}, $co{'committer_tz'});
+ my $head = $co{'id'};
my $owner = git_get_project_owner($project);
@@ -2960,7 +2960,7 @@ sub git_summary {
# we need to request one more than 16 (0..15) to check if
# those 16 are all
open my $fd, "-|", git_cmd(), "rev-list", "--max-count=17",
- git_get_head_hash($project), "--"
+ $head, "--"
or die_error(undef, "Open git-rev-list failed");
my @revlist = map { chomp; $_ } <$fd>;
close $fd;
--
1.4.4.3.gc902c
^ permalink raw reply related
* [PATCH 1/4] gitweb: Add missing show '...' links change.
From: Robert Fitzsimons @ 2006-12-22 19:38 UTC (permalink / raw)
To: git; +Cc: Robert Fitzsimons
Part of the patch for "gitweb: Show '...' links in "summary" view only
if there are more items" (313ce8cee665447e4476d7e8985b270346a8e5a1) is
missing. Add it back in.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
---
With all the tooing and frowing this part of the original patch got
lost. I'm also resubmiting the original optimizations patches with a
few changes.
Robert
gitweb/gitweb.perl | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index ebbc397..80c04b8 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2983,6 +2983,7 @@ sub git_summary {
if (@forklist) {
git_print_header_div('forks');
git_project_list_body(\@forklist, undef, 0, 15,
+ $#forklist <= 15 ? undef :
$cgi->a({-href => href(action=>"forks")}, "..."),
'noheader');
}
--
1.4.4.3.gc902c
^ permalink raw reply related
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