* Re: ':/<oneline prefix>' notation doesn't support full file syntax
From: Junio C Hamano @ 2008-07-03 8:34 UTC (permalink / raw)
To: Eric Raible; +Cc: git, Johannes.Schindelin
In-Reply-To: <279b37b20807022242q69ad2fcbwb8c11a9d6165272d@mail.gmail.com>
"Eric Raible" <raible@gmail.com> writes:
> % git rev-parse ":/object name":sha1_name.c
> :/object name:sha1_name.c
> fatal: ambiguous argument ':/object name:sha1_name.c': unknown
> revision or path not in the working tree.
> Use '--' to separate paths from revisions
>
> A quick look at int sha1_name.c:get_sha1() shows that it doesn't
> even try to make this work. Is this worth fixing?
Is there anything to fix? In that example, you are looking for a commit
that talks about "object name:sha1_name.c" in the comment.
^ permalink raw reply
* Re: about c8af1de9 (git status uses pager)
From: Johannes Schindelin @ 2008-07-03 12:11 UTC (permalink / raw)
To: Tim Stoakes; +Cc: Junio C Hamano, git
In-Reply-To: <20080703021541.GK18147@mail.rocksoft.com>
Hi,
On Thu, 3 Jul 2008, Tim Stoakes wrote:
> This [changing git status to use the pager automatically] was quite a
> nasty change to sneak on people I think.
Well, I think that a command producing pages and pages of output without
stopping is useless. Therefore, _I_ maintain that it makes tons of sense.
Of course, if you find enough support for a patch reverting it, I might
have to accept the fact that "git status" becomes less useful for me.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH/rfc] gitweb: open files (e.g. indextext.html) in utf8 mode
From: Lea Wiemann @ 2008-07-03 9:39 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Gerrit Pape, git, Junio C Hamano, Recai Oktaş
In-Reply-To: <m3prpwflus.fsf@localhost.localdomain>
Jakub Narebski wrote:
> Second, what is minimal Perl version and Perl configuration (installed
> modules) that support "use open qw(:std :utf8);"?
open is in core (-> corelist), and "qw(:std :utf)" works here with Perl
5.8.8. Perl 5.6 doesn't have it, but gitweb doesn't support Perl 5.6
anyway (e.g. "binmode STDOUT, ':utf8';" doesn't work with Perl 5.6). So
it should be fine compatibility-wise.
-- Lea
^ permalink raw reply
* Re: finding deleted file names
From: Jakub Narebski @ 2008-07-03 9:20 UTC (permalink / raw)
To: geoffrey.russell; +Cc: git
In-Reply-To: <93c3eada0807021701m13b7adddv51537f4cf9d52533@mail.gmail.com>
"Geoff Russell" <geoffrey.russell@gmail.com> writes:
> git diff --diff-filter=D --name-only HEAD@{'7 days ago'}
What did you want to find here?
> finds files deleted during the last 7 days, but if my repository is
> only 6 days old I get a fatal error.
>
> fatal: bad object HEAD@{7 days ago}
First, which version of git do you use? Because with git version 1.5.6.1
I get:
1000:[master!git]$ git diff --diff-filter=D --name-only HEAD@{'10 years ago'}
warning: Log for 'HEAD' only goes back to Fri, 4 Apr 2008 15:28:53 +0200.
Documentation/core-tutorial.txt
[...]
Second, [<ref>]@{<date>} refers to _local_ history of where _branch tip_
pointed in your repository, and is purely local information retrieved from
reflogs (which gets pruned / expired). To refer to (find) commits by
commit creation date, use --since=<date>/--after=<date> or --until=<date>/
/--before=<date>. There was even lately added information to git
documentation about difference bwetween [<ref>]@{<date>} and --before=<date>
and when to use one or the other.
> Is there something that says "since repository creation", ie., go back as far
> as possible, but no further? Is there a symbolic name for the initial commit?
Because git allows joining two repositories into one (either union of
their top directories, or one put into subdirectory in other using so
called 'subtree' merge strategy) there can be more than one "root"
(parentless) commit. In git repository there are 7 root commits, not
counting "disjoint" branches like 'html', 'man' and 'todo' which share
no history and doesn't join with mainline history.
They are: git-p4 (Perforce importer), git-gui, gitweb, gitk, git mail
tools, git,... and something strange (4e00220243).
$ git rev-list --parents --branches --not html man todo | grep -v -e ' '
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)
From: Johannes Schindelin @ 2008-07-03 12:29 UTC (permalink / raw)
To: Edward Z. Yang; +Cc: git, gitster, msysGit, junio
In-Reply-To: <486C425D.8090904@thewritingpot.com>
Hi,
On Wed, 2 Jul 2008, Edward Z. Yang wrote:
> Johannes Sixt wrote:
> > What about installing a wrapper script, plinkssh, that does this:
> > [snip]
>
> Well, the patch is shorter :-)
But you have to do it for every SSH backend that you might want to
support.
And you have to recompile.
> 1. It's been tested, it works. I haven't tried the script yet, so I
> don't know if it works.
Sorry, that argument does not fly. "My patch is better, because I did not
test your patch."
> 2. Git historically doesn't use bash, so the script would have to be
> rewritten in Perl or plain sh or tcl or something.
That is so totally untrue. We have Perl scripts and Shell scripts (for
which we need the bash), and then we have the two GUIs which use Tcl/Tk.
Actually, we only have so few Perl scripts left that it might be possible
to ship a version of Git on Windows without Perl. The only script that
needs to be converted to a builtin is add -i.
The rest of the scripts are shell.
So this argument is totally bogus.
> 3. It's less brittle than the wrapper script if we decide to have Git
> pass more params to OpenSSH.
Granted, should we decide one day to use more elaborate features of
OpenSSH, then we would have to change the script, too.
But most likely, Plink support would be broken by that update _anyway_,
since it does not grok the OpenSSH options directly.
And guess what is easier to fix, a script that rewrites the arguments from
OpenSSH syntax to Plink syntax, or a C program with over 78,000 code
lines that has to be recompiled?
> 4. It's "more native".
Would it not be even more native if we just linked in libssl? Would you
write the patch?
Further, would you like to convert and maintain all people's wrapper
scripts to C code inside Git?
BTW what is the reason why Hannes' mail does not appear to be the mail
you replied to in GMane, but the patch Steffen sent?
Ciao,
Dscho
^ permalink raw reply
* Re: finding deleted file names
From: Jeff King @ 2008-07-03 10:36 UTC (permalink / raw)
To: Geoff Russell; +Cc: Shawn O. Pearce, git
In-Reply-To: <93c3eada0807021701m13b7adddv51537f4cf9d52533@mail.gmail.com>
On Thu, Jul 03, 2008 at 09:31:55AM +0930, Geoff Russell wrote:
> git diff --diff-filter=D --name-only HEAD@{'7 days ago'}
>
> finds files deleted during the last 7 days, but if my repository is
> only 6 days old I get a
> fatal error.
>
> fatal: bad object HEAD@{7 days ago}
This should issue a warning, but use the oldest reflog entry. However,
there is a slight problem with that. See below for details.
Shawn, does this seem sane to you?
-- >8 --
avoid null SHA1 in oldest reflog
When the user specifies a ref by a reflog entry older than
one we have (e.g., "HEAD@{20 years ago"}), we issue a
warning and give them the "from" value of the oldest reflog
entry. That is, we say "we don't know what happened before
this entry, but before this we know we had some particular
SHA1".
However, the oldest reflog entry is often a creation event
such as clone or branch creation. In this case, the entry
claims that the ref went from "00000..." (the null sha1) to
the new value, and the reflog lookup returns the null sha1.
While this is technically correct (the entry tells us that
the ref didn't exist at the specified time) it is not
terribly useful to the end user. What they probably want
instead is "the oldest useful sha1 that this ref ever had".
This patch changes the behavior such that if the oldest
reflog entry would return the null sha1, it instead returns
the first actual value the ref ever had.
We never discovered this problem in the test scripts because
we created "fake" reflogs that had only a specified segment
of history. This patch updates the tests with a creation
event at the beginning of history.
Signed-off-by: Jeff King <peff@peff.net>
---
refs.c | 4 ++++
t/t1400-update-ref.sh | 9 ++++++++-
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/refs.c b/refs.c
index 9e8e858..6c6e9e5 100644
--- a/refs.c
+++ b/refs.c
@@ -1412,6 +1412,10 @@ int read_ref_at(const char *ref, unsigned long at_time, int cnt, unsigned char *
tz = strtoul(tz_c, NULL, 10);
if (get_sha1_hex(logdata, sha1))
die("Log %s is corrupt.", logfile);
+ if (is_null_sha1(sha1)) {
+ if (get_sha1_hex(logdata + 41, sha1))
+ die("Log %s is corrupt.", logfile);
+ }
if (msg)
*msg = ref_msg(logdata, logend);
munmap(log_mapped, mapsz);
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index f387d46..ca99d37 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -155,7 +155,8 @@ rm -f .git/$m .git/logs/$m expect
git update-ref $m $D
cat >.git/logs/$m <<EOF
-$C $A $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150320 -0500
+0000000000000000000000000000000000000000 $C $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150320 -0500
+$C $A $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150350 -0500
$A $B $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150380 -0500
$F $Z $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150680 -0500
$Z $E $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150980 -0500
@@ -186,6 +187,12 @@ test_expect_success \
'Query "master@{May 26 2005 23:32:00}" (exactly history start)' \
'rm -f o e
git rev-parse --verify "master@{May 26 2005 23:32:00}" >o 2>e &&
+ test '"$C"' = $(cat o) &&
+ test "" = "$(cat e)"'
+test_expect_success \
+ 'Query "master@{May 26 2005 23:32:30}" (first non-creation change)' \
+ 'rm -f o e
+ git rev-parse --verify "master@{May 26 2005 23:32:30}" >o 2>e &&
test '"$A"' = $(cat o) &&
test "" = "$(cat e)"'
test_expect_success \
--
1.5.6.1.282.g8aee2.dirty
^ permalink raw reply related
* Re: finding deleted file names
From: Jeff King @ 2008-07-03 10:42 UTC (permalink / raw)
To: Geoff Russell; +Cc: Mikael Magnusson, git
In-Reply-To: <93c3eada0807021945la3e565csc50eed4b14feb9c3@mail.gmail.com>
On Thu, Jul 03, 2008 at 12:15:37PM +0930, Geoff Russell wrote:
> >> Is there something that says "since repository creation", ie., go back as far
> >> as possible, but no further? Is there a symbolic name for the initial commit?
> >
> > There's no symbolic name for it, since there might not be only one initial
> > commit. git.git for example has at least three root commits. You will
> > probably get what you want with $(git rev-list HEAD|tail -1). If your
> > history is very large, $(git rev-list --reverse HEAD|head -1) is slightly
> > faster, but usually not enough to offset typing --reverse :).
>
> Thanks for this, but I'm a little confused.
>
> If I do a "git init", there must be a first commit after this? Isn't
> this the first commit, how
> can there be more than one first commit?
The confusing part is that you two are talking about two slightly
different things. If you define "initial commit" as "the commit which
has no parents" then there can be many (you get a new one anytime you
merge in a project with unrelated history).
However, what Geoff originally mentioned was HEAD{'7 days ago'}, which
actually looks in the reflog. So if you define "initial commit" as "the
first commit value that this ref ever had" then there is only one
(though of course, your reflog will eventually expire, so it won't be
"the oldest value this ref ever had" but rather "the oldest one the
reflog ever remembers it having").
-Peff
^ permalink raw reply
* Question about git-merge-stupid
From: Miklos Vajna @ 2008-07-03 12:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Junio C Hamano, Johannes Schindelin
[-- Attachment #1: Type: text/plain, Size: 1444 bytes --]
Hi,
I'm trying to understand what is the difference between different merge
strategies. git-merge-stupid is something I failed to understand from
the git history/code/documentation, so I'm asking here.
1) From git history:
It seems git-merge-stupid was created by 2276aa6 when Junio renamed
-resolve to -stupid and let -resolve use read-tree. Actually
git show 2276aa6:git-merge-stupid.sh
says -stupid uses read-tree as well.
2) From code:
It seems -stupid is better than -resolve when there are multiple bases.
-resolve just passes all bases to read-tree, while -stupid tries to find
the best one. It does it by counting unmerged entries and the less one
is a better.
Here is what I tried:
A - B - C
X \
\ D - E - F
(Where 'A' adds 'a.c' while the contents 'a', etc.)
$ git reset --hard e
$ git merge -s resolve c
Trying simple merge.
Merge made by resolve.
So it seems resolve does not completely fail if there are multiple
bases, either.
I would like to write a testcase that ensures git-merge-stupid really
picks the best base, but I don't know exactly in what situation can the
number of unmerged entires differ.
3) From documentation:
Actually -stupid is missing from Documentation/merge-strategies.txt. I
plan to send a patch to add it, once I understnad what it does. :-)
Thanks.
[ Writing to Linus as suggested by Dscho, adding Junio to CC as -
according to git log - both strategy created by him. ]
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: ':/<oneline prefix>' notation doesn't support full file syntax
From: Jeff King @ 2008-07-03 10:47 UTC (permalink / raw)
To: Eric Raible; +Cc: git, Johannes.Schindelin
In-Reply-To: <279b37b20807022242q69ad2fcbwb8c11a9d6165272d@mail.gmail.com>
On Wed, Jul 02, 2008 at 10:42:52PM -0700, Eric Raible wrote:
> Although the rev-parse documentation claims that the
> tree-ish:path/to/file syntax works is applicable, this is
> not so when using the :/ "oneline prefix" syntax:
>
> % git rev-parse v1.5.0.1-227-g28a4d94
> 28a4d940443806412effa246ecc7768a21553ec7
> % git rev-parse ":/object name"
> 28a4d940443806412effa246ecc7768a21553ec7
>
> % git rev-parse v1.5.0.1-227-g28a4d94:sha1_name.c
> 0781477a71ac4d76a1b8783868d6649cae7f8507
> % git rev-parse ":/object name":sha1_name.c
> :/object name:sha1_name.c
> fatal: ambiguous argument ':/object name:sha1_name.c': unknown
> revision or path not in the working tree.
> Use '--' to separate paths from revisions
>
> A quick look at int sha1_name.c:get_sha1() shows that it doesn't
> even try to make this work. Is this worth fixing?
> Or at least documenting?
IMHO, :/ should stop eating text at the first ':', and allow '\:' for
a literal colon and '\\' for a literal backslash.
I think nobody has really cared up to this point (and I can't say that I
care that much now, but I wouldn't object to such a patch).
-Peff
^ permalink raw reply
* Re: ':/<oneline prefix>' notation doesn't support full file syntax
From: Johannes Schindelin @ 2008-07-03 12:38 UTC (permalink / raw)
To: Eric Raible; +Cc: Junio C Hamano, git
In-Reply-To: <279b37b20807030150t2e9cbcc8wf099a5872568af8@mail.gmail.com>
Hi,
On Thu, 3 Jul 2008, Eric Raible wrote:
> On Thu, Jul 3, 2008 at 1:34 AM, Junio C Hamano <gitster@pobox.com> wrote:
> > "Eric Raible" <raible@gmail.com> writes:
> >
> > Is there anything to fix? In that example, you are looking for a
> > commit that talks about "object name:sha1_name.c" in the comment.
>
> Yes. What if I'm looking for specific file (i.e. sha1_name.c) in the
> commit described by ":/object name:", just like I can do with
> 28a4d9404:sha1_name.c?
>
> This is not ambiguous if we first consider the entire string as the
> prefix. If that fails we look for a filename after the final ':'.
It is super-expensive, as you have to look through the whole history just
to find that you do not find anything.
And then, it could be that you do find a commit that starts with that
string, but what you really wanted it a file, not a commit.
And then, a file name can contain colons. What to do in that case?
I think your "fix" is not worth it. ":/<oneline>" is to help you find a
commit, and it will only ever find the first commit anyway, so you are
probably better off using
$ git show $(git log --pretty=format:%H:path/to/file.c \
--grep=^<oneline>)
to begin with.
Really, the only reason I ever wrote support for ":/blah" is when someone
less-than-helpful says "In commit 'Bla bla bla' you broke XYZ" and I want
to
$ git show :/Bla
Nowadays, however, I would
$ git log -p --grep=^Bla
so I'd vote to remove the ":/" syntax altogether. We need not even
concern ourselves with scripts using that syntax, since the semantics are
so limited that nobody should use it in scripts anyway.
Ciao,
Dscho
^ permalink raw reply
* Re: RFC: grafts generalised
From: Stephen R. van den Berg @ 2008-07-03 9:37 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Dmitry Potapov, git
In-Reply-To: <486C82F5.6080405@viscovery.net>
Johannes Sixt wrote:
>Stephen R. van den Berg schrieb:
>> Actually, ripple-through changes are rare. In the current project it
>> seems I need exactly one, but it's buried deep in the past (sadly).
>> The reason why I need it, is to make sure that git-bisect will work for
>> any revision in the past (i.e. the tree contained/contains some
>> too-clever-for-their-own-good $Revision$-expansion dependencies)
>But you do know that you don't need to apply the change *now*; you can
>apply it at bisect-time? Unless you expect you or your mere mortal
>coworkers are going to do dozens of bisects into that part of the history,
>I wouldn't change history *like*this*. But of course, I don't understand
>the circumstances enough, so... just my 2 cents.
That is exactly the case, I do expect dozens of bisects.
--
Sincerely,
Stephen R. van den Berg.
This is a day for firm decisions! Or is it?
^ permalink raw reply
* PATCH: allow ':/<oneline prefix>' notation to specify a specific file
From: Eric Raible @ 2008-07-03 8:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes.Schindelin
Although the rev-parse documentation claims that the tree-ish:path/to/file
syntax is applicable to all tree-ish forms this is not so when using the
:/ "oneline prefix" syntax introduced in v1.5.0.1-227-g28a4d94.
This patch allows git show ":/PATCH: allow":sha1_name.c to show the
change to the file changed by this patch.
Signed-off-by: Eric Raible <raible@gmail.com>
---
sha1_name.c | 15 +++++++++++++--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index b0b2167..a1acfcd 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -684,6 +684,7 @@ int get_sha1_with_mode(const char *name, unsigned
char *sha1, unsigned *mode)
int ret, bracket_depth;
int namelen = strlen(name);
const char *cp;
+ char *copy, *colon;
*mode = S_IFINVALID;
ret = get_sha1_1(name, namelen, sha1);
@@ -697,8 +698,18 @@ int get_sha1_with_mode(const char *name, unsigned
char *sha1, unsigned *mode)
int stage = 0;
struct cache_entry *ce;
int pos;
- if (namelen > 2 && name[1] == '/')
- return get_sha1_oneline(name + 2, sha1);
+ if (namelen > 2 && name[1] == '/') {
+ name += 2;
+ colon = strrchr(name, ':');
+ if (!get_sha1_oneline(name, sha1) || !colon)
+ return 0;
+ copy = xstrdup(name);
+ *(colon = strrchr(copy, ':')) = '\0';
+ ret = get_sha1_oneline(copy, sha1) ||
+ get_tree_entry(sha1, colon+1, sha1, mode);
+ free(copy);
+ return ret;
+ }
if (namelen < 3 ||
name[2] != ':' ||
name[1] < '0' || '3' < name[1])
--
1.5.6.1.1356.g3be5f.dirty
^ permalink raw reply related
* Re: Non-inetd git-daemon hangs in syslog(3)/fclose(3) if --syslog --verbose accessing non-repositories
From: Johannes Schindelin @ 2008-07-03 12:45 UTC (permalink / raw)
To: Brian Foster; +Cc: git
In-Reply-To: <200807031400.36315.brian.foster@innova-card.com>
Hi,
On Thu, 3 Jul 2008, Brian Foster wrote:
> I've seen several reports of what seems to be the following
> problem, but no fixes.
>
> [describes that git-daemon -v syslog()s in a signal handler, which is
> unsupported]
I reported this bug earlier, and my workaround was to comment out the
syslog() in the signal handler, but I have no real fix for that, either.
Unfortunately, the wise people on this list did not have an idea either,
at least they did not share it with me.
Ciao,
Dscho
^ permalink raw reply
* Re: bug found (Re: git-fast-export SIGSEGV on solaris + backtrace)
From: Johannes Schindelin @ 2008-07-03 12:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: namsh, git, Pieter de Bie
In-Reply-To: <7vk5g32wve.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 3 Jul 2008, Junio C Hamano wrote:
> What was I smoking when I applied df6a7ff (builtin-fast-export: Add
> importing and exporting of revision marks, 2008-06-11), I have to
> wonder...
FWIW I missed it in my review, too... Well, Junio, it seems we should
avoid smoking together for a while.
Ciao,
Dscho
^ permalink raw reply
* Re: PATCH: allow ':/<oneline prefix>' notation to specify a specific file
From: Johannes Schindelin @ 2008-07-03 12:53 UTC (permalink / raw)
To: Eric Raible; +Cc: Junio C Hamano, git
In-Reply-To: <279b37b20807030152g13492d5dxf21367ab17719993@mail.gmail.com>
Hi,
is there a reason you break the mail thread quite a couple of times? It
makes it really hard to follow when you get 300+ mails a day.
Thankyouverymuch,
Dscho
^ permalink raw reply
* Re: OT: Re: [PATCH 08/15] gitdiffcore(7): fix awkward wording
From: Jonathan Nieder @ 2008-07-03 12:56 UTC (permalink / raw)
To: git; +Cc: Chris Shoemaker
In-Reply-To: <20080703013733.BIF31353@m4500-01.uchicago.edu>
[Junio: sorry for the duplicate message. It occured to me too late
that a clarification might fix some confusion for the rest of the
readers of the list, too.]
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@uchicago.edu> writes:
>
>>> The phrase "diff outputs" sounds awkward to my ear (I think
>>> "output" is meant to be used as a substantive noun.)
>>
>> Ack! that phrase made no sense. If you know what I meant and
>> what it's called, I'd like to know :)
>>
>> Thanks,
>> Jonathan
>
> As a bistander to this exchange, I am confused. Who is acking whose
> comment here?
I wrote:
> Sorry, I meant something to the same effect as "Agh". I should have
> just gone to sleep.
But perhaps more important for my meaning is that by "that phrase" I
meant the phrase "substantive noun". I meant that "output" is a sort
of fluid substance and so is rarely supposed to be plural unless
outputs with different qualities are being discussed, but the phrase
"substantive noun" conveys none of that at all. In fact, I think the
phrase "substantive noun" just means "noun". Hence my dismay at not
making any sense.
Sorry about the confusion.
Jonathan
^ permalink raw reply
* Re: PATCH: allow ':/<oneline prefix>' notation to specify a specific file
From: Johannes Schindelin @ 2008-07-03 12:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Raible, git
In-Reply-To: <7v7ic32ujy.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 3 Jul 2008, Junio C Hamano wrote:
> "Eric Raible" <raible@gmail.com> writes:
>
> > This patch allows git show ":/PATCH: allow":sha1_name.c to show the
> > change to the file changed by this patch.
> > ...
> > @@ -697,8 +698,18 @@ int get_sha1_with_mode(const char *name, unsigned
> > char *sha1, unsigned *mode)
> > int stage = 0;
> > struct cache_entry *ce;
> > int pos;
> > - if (namelen > 2 && name[1] == '/')
> > - return get_sha1_oneline(name + 2, sha1);
> > + if (namelen > 2 && name[1] == '/') {
> > + name += 2;
> > + colon = strrchr(name, ':');
> > + if (!get_sha1_oneline(name, sha1) || !colon)
> > + return 0;
>
> So when you have ":/A:B:C", you first try to look for string "A:B:C", and
> then when it fails try "A:B" and look for path C? I think this fallback
> makes sense, especially because this cannot break existing use for
> positive lookup (it _can_ be called a regression if you are checking to
> see if you have a commit that has A:B:C and you want the lookup to fail if
> there is A:B that happens to have path C, but I do not think we would care
> about that usage).
However, if you specify ambiguous information, you can end up with a
commit when you expect a file.
I do not like the direction this is going; in hindsight, I think
":/<oneline>" was a serious mistake.
As I hinted in another mail, which should have been in the same mail
thread, "log --grep" is so much more powerful and should supersede
":/<oneline>".
Let's grant ":/<oneline>" a quick and painless death.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC/PATCH 1/4] Add git-sequencer shell prototype
From: Jakub Narebski @ 2008-07-03 13:10 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git, Junio C Hamano, Johannes Schindelin
In-Reply-To: <1214879914-17866-2-git-send-email-s-beyer@gmx.net>
Stephan Beyer <s-beyer@gmx.net> writes:
> +# Generate message, patch and author script files
> +make_patch () {
> + parent_sha1=$(git rev-parse --verify "$1"^) ||
> + die "Cannot get patch for $1^"
> + git diff-tree -p "$parent_sha1..$1" >"$PATCH"
First, let's not perpetuate _convenience_ calling convention of "A..B"
of git-diff* family, but use "A B" to set _endpoints_.
Second, with "A B" convention you can fairly easy deal with root
commit, changing the code to the fragment below:
+# Generate message, patch and author script files
+make_patch () {
+ parent_sha1=$(git rev-parse --verify "$1"^) ||
+ echo '--root'
+ git diff-tree -p "$parent_sha1" "$1" >"$PATCH"
BTW. what is best way of checking if given revision is parent-less?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: ':/<oneline prefix>' notation doesn't support full file syntax
From: Eric Raible @ 2008-07-03 8:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes.Schindelin
In-Reply-To: <7vfxqr2won.fsf@gitster.siamese.dyndns.org>
On Thu, Jul 3, 2008 at 1:34 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "Eric Raible" <raible@gmail.com> writes:
>
> Is there anything to fix? In that example, you are looking for a commit
> that talks about "object name:sha1_name.c" in the comment.
Yes. What if I'm looking for specific file (i.e. sha1_name.c) in the commit
described by ":/object name:", just like I can do with 28a4d9404:sha1_name.c?
This is not ambiguous if we first consider the entire string as the prefix.
If that fails we look for a filename after the final ':'.
I'll post a patch in a moment.
- Eric
^ permalink raw reply
* Re: about c8af1de9 (git status uses pager)
From: Wincent Colaiuta @ 2008-07-03 13:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Tim Stoakes, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0807031303080.9925@racer>
El 3/7/2008, a las 14:11, Johannes Schindelin escribió:
> Hi,
>
> On Thu, 3 Jul 2008, Tim Stoakes wrote:
>
>> This [changing git status to use the pager automatically] was quite a
>> nasty change to sneak on people I think.
>
> Well, I think that a command producing pages and pages of output
> without
> stopping is useless. Therefore, _I_ maintain that it makes tons of
> sense.
Ditto. For me, the change was very welcome. Sure, usually the status
output is short, but on those occasions where it isn't (big file
reorganizations etc) I was quite sick of doing the "git status, oops
that output was too long let's try again, git -p status" dance. It was
also incongruous with my very first experiences with Git, where I had
been pleasantly surprised that "git log" automatically invoked the
pager whereas "svn log" just spewed output into my console until ^C.
Cheers,
Wincent
^ permalink raw reply
* Re: Non-inetd git-daemon hangs in syslog(3)/fclose(3) if --syslog --verbose accessing non-repositories
From: Brian Foster @ 2008-07-03 13:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807031343440.9925@racer>
On Thursday 03 July 2008 Johannes Schindelin wrote:
> On Thu, 3 Jul 2008, Brian Foster wrote:
> >[... describes that git-daemon -v syslog()s in a signal handler,
> > which is unsupported ...]
>
> I reported this bug earlier [ ... ]
Ah, yes, I've (now) found the (long!) thread,
about log-rotation (which, as you observe, is
not the problem). Sorry for the duplication.
cheers!
-blf-
--
“How many surrealists does it take to | Brian Foster
change a lightbulb? Three. One calms | somewhere in south of France
the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!
with brightly-coloured machine tools.” | http://www.stopesso.com
^ permalink raw reply
* Re: Non-inetd git-daemon hangs in syslog(3)/fclose(3) if --syslog --verbose accessing non-repositories
From: Johannes Schindelin @ 2008-07-03 14:32 UTC (permalink / raw)
To: Brian Foster; +Cc: git
In-Reply-To: <200807031552.26615.brian.foster@innova-card.com>
Hi,
On Thu, 3 Jul 2008, Brian Foster wrote:
> On Thursday 03 July 2008 Johannes Schindelin wrote:
> > On Thu, 3 Jul 2008, Brian Foster wrote:
> > >[... describes that git-daemon -v syslog()s in a signal handler,
> > > which is unsupported ...]
> >
> > I reported this bug earlier [ ... ]
>
> Ah, yes, I've (now) found the (long!) thread, about log-rotation
> (which, as you observe, is not the problem).
Yeah, sorry, should have mentioned that.
> Sorry for the duplication.
No need to be sorry. It may raise awareness so much that somebody gets a
clever idea how to cope with it.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git daemon: avoid calling syslog() from a signal handler
From: Johannes Schindelin @ 2008-07-03 15:27 UTC (permalink / raw)
To: Brian Foster; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807031531320.9925@racer>
Signal handlers should never call syslog(), as that can raise signals
of its own.
Instead, call the syslog() from the master process.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Thu, 3 Jul 2008, Johannes Schindelin wrote:
> It may raise awareness so much that somebody gets a clever idea
> how to cope with it.
Okay, it might not be clever, but I think this is pretty
straight-forward.
However, this part of the code is tricky, as it can (and will) be
interrupted by signal handlers, so I would appreciate several
careful reviews (but maybe it is not necessary to ask for it,
since I am no longer trusted).
daemon.c | 61 +++++++++++++++++++++++++++++++++++++++++--------------------
1 files changed, 41 insertions(+), 20 deletions(-)
diff --git a/daemon.c b/daemon.c
index 63cd12c..35fd439 100644
--- a/daemon.c
+++ b/daemon.c
@@ -694,23 +694,47 @@ static void kill_some_children(int signo, unsigned start, unsigned stop)
}
}
+static void check_dead_children(void)
+{
+ unsigned spawned, reaped, deleted;
+
+ spawned = children_spawned;
+ reaped = children_reaped;
+ deleted = children_deleted;
+
+ while (deleted < reaped) {
+ pid_t pid = dead_child[deleted % MAX_CHILDREN];
+ const char *dead = pid < 0 ? " (with error)" : "";
+
+ if (pid < 0)
+ pid = -pid;
+
+ /* XXX: Custom logging, since we don't wanna getpid() */
+ if (verbose) {
+ if (log_syslog)
+ syslog(LOG_INFO, "[%d] Disconnected%s",
+ pid, dead);
+ else
+ fprintf(stderr, "[%d] Disconnected%s\n",
+ pid, dead);
+ }
+ remove_child(pid, deleted, spawned);
+ deleted++;
+ }
+ children_deleted = deleted;
+}
+
static void check_max_connections(void)
{
for (;;) {
int active;
- unsigned spawned, reaped, deleted;
+ unsigned spawned, deleted;
+
+ check_dead_children();
spawned = children_spawned;
- reaped = children_reaped;
deleted = children_deleted;
- while (deleted < reaped) {
- pid_t pid = dead_child[deleted % MAX_CHILDREN];
- remove_child(pid, deleted, spawned);
- deleted++;
- }
- children_deleted = deleted;
-
active = spawned - deleted;
if (active <= max_connections)
break;
@@ -760,18 +784,10 @@ static void child_handler(int signo)
if (pid > 0) {
unsigned reaped = children_reaped;
+ if (!WIFEXITED(status) || WEXITSTATUS(status) > 0)
+ pid = -pid;
dead_child[reaped % MAX_CHILDREN] = pid;
children_reaped = reaped + 1;
- /* XXX: Custom logging, since we don't wanna getpid() */
- if (verbose) {
- const char *dead = "";
- if (!WIFEXITED(status) || WEXITSTATUS(status) > 0)
- dead = " (with error)";
- if (log_syslog)
- syslog(LOG_INFO, "[%d] Disconnected%s", pid, dead);
- else
- fprintf(stderr, "[%d] Disconnected%s\n", pid, dead);
- }
continue;
}
break;
@@ -929,7 +945,8 @@ static int service_loop(int socknum, int *socklist)
for (;;) {
int i;
- if (poll(pfd, socknum, -1) < 0) {
+ i = poll(pfd, socknum, 1);
+ if (i < 0) {
if (errno != EINTR) {
error("poll failed, resuming: %s",
strerror(errno));
@@ -937,6 +954,10 @@ static int service_loop(int socknum, int *socklist)
}
continue;
}
+ if (i == 0) {
+ check_dead_children();
+ continue;
+ }
for (i = 0; i < socknum; i++) {
if (pfd[i].revents & POLLIN) {
--
1.5.6.1.376.g6b0fd
^ permalink raw reply related
* [PATCH] git-apply tests need to be portable
From: Don Zickus @ 2008-07-03 16:00 UTC (permalink / raw)
To: git; +Cc: Don Zickus
When I created the tests for my git-apply patch, I accidently used the '-i'
flag for sed. Not all versions of sed handle this flag, so I converted
those instances to output to a temp file and move that temp file back to the
original file.
Thanks to Jim Meyering for noticing this!
---
Junio, I am not sure if you want me to resend the whole patch again or is a
small update like this preferred. I am indifferent either way.
Cheers,
Don
---
t/t4127-apply-same-fn.sh | 33 ++++++++++++++++++++++-----------
1 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/t/t4127-apply-same-fn.sh b/t/t4127-apply-same-fn.sh
index 2a6ed77..2726a29 100755
--- a/t/t4127-apply-same-fn.sh
+++ b/t/t4127-apply-same-fn.sh
@@ -14,10 +14,12 @@ test_expect_success setup '
git commit -m initial
'
test_expect_success 'apply same filename with independent changes' '
- sed -i -e "s/^d/z/" same_fn &&
+ sed -e "s/^d/z/" same_fn > f &&
+ mv f same_fn &&
git diff > patch0 &&
git add same_fn &&
- sed -i -e "s/^i/y/" same_fn &&
+ sed -e "s/^i/y/" same_fn > f &&
+ mv f same_fn &&
git diff >> patch0 &&
cp same_fn same_fn2 &&
git reset --hard &&
@@ -27,10 +29,12 @@ test_expect_success 'apply same filename with independent changes' '
test_expect_success 'apply same filename with overlapping changes' '
git reset --hard
- sed -i -e "s/^d/z/" same_fn &&
+ sed -e "s/^d/z/" same_fn > f &&
+ mv f same_fn &&
git diff > patch0 &&
git add same_fn &&
- sed -i -e "s/^e/y/" same_fn &&
+ sed -e "s/^e/y/" same_fn > f &&
+ mv f same_fn &&
git diff >> patch0 &&
cp same_fn same_fn2 &&
git reset --hard &&
@@ -41,10 +45,12 @@ test_expect_success 'apply same filename with overlapping changes' '
test_expect_success 'apply same new filename after rename' '
git reset --hard
git mv same_fn new_fn
- sed -i -e "s/^d/z/" new_fn &&
+ sed -e "s/^d/z/" new_fn > f &&
+ mv f new_fn &&
git add new_fn &&
git diff -M --cached > patch1 &&
- sed -i -e "s/^e/y/" new_fn &&
+ sed -e "s/^e/y/" new_fn > f &&
+ mv f new_fn &&
git diff >> patch1 &&
cp new_fn new_fn2 &&
git reset --hard &&
@@ -55,11 +61,13 @@ test_expect_success 'apply same new filename after rename' '
test_expect_success 'apply same old filename after rename -- should fail.' '
git reset --hard
git mv same_fn new_fn
- sed -i -e "s/^d/z/" new_fn &&
+ sed -e "s/^d/z/" new_fn > f &&
+ mv f new_fn &&
git add new_fn &&
git diff -M --cached > patch1 &&
git mv new_fn same_fn
- sed -i -e "s/^e/y/" same_fn &&
+ sed -e "s/^e/y/" same_fn > f &&
+ mv f same_fn &&
git diff >> patch1 &&
git reset --hard &&
test_must_fail git apply patch1
@@ -68,15 +76,18 @@ test_expect_success 'apply same old filename after rename -- should fail.' '
test_expect_success 'apply A->B (rename), C->A (rename), A->A -- should pass.' '
git reset --hard
git mv same_fn new_fn
- sed -i -e "s/^d/z/" new_fn &&
+ sed -e "s/^d/z/" new_fn > f &&
+ mv f new_fn &&
git add new_fn &&
git diff -M --cached > patch1 &&
git commit -m "a rename" &&
git mv other_fn same_fn
- sed -i -e "s/^e/y/" same_fn &&
+ sed -e "s/^e/y/" same_fn > f &&
+ mv f same_fn &&
git add same_fn &&
git diff -M --cached >> patch1 &&
- sed -i -e "s/^g/x/" same_fn &&
+ sed -e "s/^g/x/" same_fn > f &&
+ mv f same_fn &&
git diff >> patch1 &&
git reset --hard HEAD^ &&
git apply patch1
--
1.5.6.rc2.48.g13da
^ permalink raw reply related
* Re: [PATCH 0/3] Making remote tracking statistics available to other tools
From: Olivier Marin @ 2008-07-03 16:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ingo Molnar, Bruce Stephens, git
In-Reply-To: <7v3amsg1wx.fsf@gitster.siamese.dyndns.org>
Junio C Hamano a écrit :
> The one I sent out was a bit hacky as the existing implementation inside
> git-checkout was not designed to be cleanly reusable.
>
> Here is a cleaned up series that could be applied.
>
> [PATCH 1/3] Refactor "tracking statistics" code used by "git checkout"
> [PATCH 2/3] git-status: show the remote tracking statistics
> [PATCH 3/3] git-branch -v: show the remote tracking statistics
Sorry, but the third patch does not work for me. FWIU, the problem comes from
the revision walking code that is not reentrant because of the object cache.
IOW, calling stats_tracking_info() more than once does not work: objects
states changed after first call.
I do not understand the code enough yet and I failed to fix it. The only way
I found is by clearing obj_hash (object.c) but this seems the wrong thing to
do.
Ideas?
This test case should trigger the bug:
$ for i in a b c; do echo $i>$i && git add $i && git commit -m $i; done
$ git clone . clone1
$ cd clone1
$ git checkout -b b1 origin/master
$ git reset --hard HEAD~
$ echo d>d && git add d && git commit -m d
$ git checkout -b b2 origin/master
$ git reset --hard HEAD~
$ git merge b1
$ git branch -v
b1 c07015a [ahead 1, behind 1] d
* b2 c07015a d
master 08ca18b c
b1 and b2 are both 1 commit ahead and 1 commit behind.
$ git branch -D b1
$ git branch -v
* b2 c07015a [ahead 1, behind 1] d
master 08ca18b c
deleting b1 show us the side effect.
Olivier.
^ 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