* Re: [PATCH 3/5] sequencer: sequencer state is useless without todo
From: Junio C Hamano @ 2011-11-16 7:38 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Jonathan Nieder, Git List
In-Reply-To: <CALkWK0kOrGzjcGNcf2qPahJSgkvCsQwSrEfAA3wj6PqnMzDBVQ@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> I noticed that sha1_to_hex() also operates like this.
A function to externalize our internal representation like sha1_to_hex()
is not such a big problem in practice, as the lifetime of its result is
inherently much shorter.
Anybody sane with a datum that eventually needs to be externalized will
keep it in its internal representation as long as possible, and then call
such an internal-to-external function just before it becomes absolutely
necessary to externalize it (e.g. calling printf(), packet_write(), etc).
This is because the whole point of having an internal representation
(e.g. when our code talks about an object name, we always use "unsigned
char[20]") is so that all of our functions can use that representation to
pass it around. It would be insane to call such a function earlier than
necessary, having to pass external representation around.
On the other hand, resolve_ref() is an interface to canonicalize external
representation into a form suitable to be kept and passed around as its
internal representation. The lifetime of its result fundamentally has to
be a lot longer than that of functions that work in the opposite
direction, e.g. sha1_to_hex().
^ permalink raw reply
* Re: Git 1.7.5 problem with HTTPS
From: Tay Ray Chuan @ 2011-11-16 7:34 UTC (permalink / raw)
To: Dmitry Smirnov; +Cc: Junio C Hamano, Shawn Pearce, git
In-Reply-To: <CACf55T6SRAfdOP1+qQdjeFv13B=G8w+DR-GCSEz=6swFhLJzcw@mail.gmail.com>
On Wed, Nov 16, 2011 at 3:11 PM, Dmitry Smirnov <divis1969@gmail.com> wrote:
> What if problem is caused by curl or TLS lib (libcurl-gnutls?) which
> is used by my git? Is there any to log something from git-remote-https
> ?
You can run git with GIT_CURL_VERBOSE set, like this
GIT_CURL_VERBOSE=1 git ls-remote ...
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: Git, Parrot, Perl6, Rakudo for G4 MAC
From: Jakub Narebski @ 2011-11-16 7:21 UTC (permalink / raw)
To: greggallen; +Cc: Sitaram Chamarty, Hilco Wijbenga, git
In-Reply-To: <CAKjR-Ruj0TEST5OdB4HGh_2Ox2xL9k7bqqnJvx8O0O5T0SziDA@mail.gmail.com>
greggallen@gmail.com wrote:
> Thank you very much for all your help. After a tiny bit of
> consideration, I've decided to sell my G4, for whatever I can get on
> the local Craigslist, and install Linux, or FreeBSD on this &^%^$$&*!!
> Wintel machine.
>
> Copying my several dozen useful Perl and shell scripts, will be much
> easier to accomplish than "GITting" the other stuff to install on a
> PPC MAC. I love programming, but INSTALLING software is boring!
Hmmm... isn't there some pre-compiled Git to be installed on PPC Mac
(Homebrew, git-osx-installer linked from Git Homepage)?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Git 1.7.5 problem with HTTPS
From: Junio C Hamano @ 2011-11-16 7:18 UTC (permalink / raw)
To: Dmitry Smirnov; +Cc: Shawn Pearce, git
In-Reply-To: <CACf55T6SRAfdOP1+qQdjeFv13B=G8w+DR-GCSEz=6swFhLJzcw@mail.gmail.com>
Dmitry Smirnov <divis1969@gmail.com> writes:
> 2011/11/16 Junio C Hamano <gitster@pobox.com>:
>> $ git ls-remote https://git.kernel.org/pub/scm/git/git.git |
>> grep -e HEAD -e master
>
> in my case this command produce no output.
>
> What if problem is caused by curl or TLS lib (libcurl-gnutls?) which
> is used by my git?
Yeah, this is sounding very likely that this is an issue at the SSL/TLS
layer underneath whatever Git speaks.
^ permalink raw reply
* Re: Git 1.7.5 problem with HTTPS
From: Dmitry Smirnov @ 2011-11-16 7:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Pearce, git
In-Reply-To: <7v1ut9uglb.fsf@alter.siamese.dyndns.org>
2011/11/16 Junio C Hamano <gitster@pobox.com>:
> $ git ls-remote https://git.kernel.org/pub/scm/git/git.git |
> grep -e HEAD -e master
in my case this command produce no output.
What if problem is caused by curl or TLS lib (libcurl-gnutls?) which
is used by my git? Is there any to log something from git-remote-https
?
Dmitry
^ permalink raw reply
* Re: Git, Parrot, Perl6, Rakudo for G4 MAC
From: greggallen @ 2011-11-16 7:07 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Jakub Narebski, Hilco Wijbenga, git
In-Reply-To: <CAMK1S_jcThEB=_w=miGBncmTEy8jz6_T-QHv7g-C5s3Hi+X6Lg@mail.gmail.com>
Thank you very much for all your help. After a tiny bit of
consideration, I've decided to sell my G4, for whatever I can get on
the local Craigslist, and install Linux, or FreeBSD on this &^%^$$&*!!
Wintel machine.
Copying my several dozen useful Perl and shell scripts, will be much
easier to accomplish than "GITting" the other stuff to install on a
PPC MAC. I love programming, but INSTALLING software is boring!
Thanks again,
Greg Allen
GreggAllen@gmail.com
On 11/15/11, Sitaram Chamarty <sitaramc@gmail.com> wrote:
> 2011/11/15 Jakub Narebski <jnareb@gmail.com>:
>
>> Git requires Perl version 5.8 at least, so you should not have any
>> problems here.
>
> One day someone [1] reminded me that git does not require perl. Some
> features, like git add -p, require it but git can be built without
> perl.
>
> [1] on irc, while discussing my stated requirements for gitolite
>
--
**********************************************
Descargo de responsabilidad:
(Nulo donde esté prohibido, su kilometraje puede variar, consulte con
su médico, todos los derechos reservados, cualquier retransmisión o
retransmisión de las descripciones y las cuentas de este juego está
prohibida sin el consentimiento expreso por escrito de la Major League
Baseball).
Disclaimer:
(Void where prohibited, your mileage may vary, check with your doctor,
all rights reserved, any rebroadcast or retransmission of the
descriptions and accounts of this game is prohibited without the
expressed written consent of Major League Baseball.)
Haftungsausschluss:
(Void, wo die Leistung kann variieren, fragen Sie Ihren Arzt verboten,
alle Rechte vorbehalten, jegliche Weiterverbreitung oder
Weiterverbreitung von Beschreibungen und Berichte über dieses Spiel
ist ohne ausdrückliche schriftliche Zustimmung der Major League
Baseball verboten.)
Rejettent la Déclaration:
(Nul si interdit, votre kilométrage peut varier, vérifiez auprès de
votre médecin, tous droits réservés, toute rediffusion ou
retransmission des descriptions et des comptes de ce jeu est interdite
sans l'accord écrit de la Major League Baseball).
Negano la Dichiarazione:
(valido dove proibito, le prestazioni possono variare, verificare con
il medico, tutti i diritti riservati, ogni ritrasmissione o
ritrasmissione delle descrizioni e dei conti di questo gioco è vietato
senza il consenso scritto della Major League Baseball.)
^ permalink raw reply
* Re: Git 1.7.5 problem with HTTPS
From: Dmitry Smirnov @ 2011-11-16 7:04 UTC (permalink / raw)
To: git; +Cc: Shawn Pearce
In-Reply-To: <CAJo=hJvdstr39suGMwxNoT+_cKThxsEYHi96eqja7HuHyPmhWA@mail.gmail.com>
2011/11/15 Shawn Pearce <spearce@spearce.org>:
> I would suggest starting over by downloading repo per [1] and using
> that script to start the process.
Cloning of the repo.git repository produces the same error
warning: remote HEAD refers to nonexistent ref, unable to checkout.
That is why I tried to use another repository...
^ permalink raw reply
* Re: [PATCH] revert: prettify fatal messages
From: Jonathan Nieder @ 2011-11-16 6:42 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Junio C Hamano, Git List, Matthieu Moy
In-Reply-To: <CALkWK0m+us0rCx61+SwSsKuO7qK5mbCs0MpoAzB4ja=wBA+Xjw@mail.gmail.com>
Ramkumar Ramachandra wrote:
> To avoid confusion, reverts should always look
> like the following:
>
> Revert [commit message]
>
> This reverts commit [unabbreviated sha1 hex].
Don't forget the description of why it is being reverted. :)
Actually, I think Matthieu's confusion makes a lot of sense. I don't
think it matters very much, but it can sometimes be clearer to say
"cherry-pick/revert: remove spurious period in error message".
Another benefit to moving the juicy part to sequencer.c, I guess.
^ permalink raw reply
* Re: [PATCH 3/7] sequencer: handle single-commit pick as special case
From: Ramkumar Ramachandra @ 2011-11-16 6:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List, Jonathan Nieder
In-Reply-To: <7v62ilujya.fsf@alter.siamese.dyndns.org>
Hi Junio,
Junio C Hamano wrote:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>> [...]
> But we are already in agreement on this point, I think. Didn't I say:
Yes, yes. I was just thinking out loud so it'll help me write a new
commit message. Sorry for the noise.
>> 2. In the case of multi-commit picking, there's an additional layer of
>> decision making: did the conflict occur in the last commit in the
>> range?
>
> Again, it would be the same thing. If the implementation forces that
> decision, that would be a bug, no?
>
> My understanding is that multi-commit form of cherry-pick and revert
> intended to allow two forms of "user done helping and telling the command
> to continue" at any stage, be it the first, in the middle, or the last
> operation in a series:
>
> - User resolves, adds and commits, and then tells the command to
> continue. The command notices that the user has committed, and goes on
> to the next task; or
>
> - User resolves, adds, and then tells the command to continue. The
> command notices that the user has not committed, makes a commit and
> goes on to the next task.
Yep, this is exactly how it'll work after the series :D
Thanks.
-- Ram
^ permalink raw reply
* Re: [PATCH] revert: prettify fatal messages
From: Ramkumar Ramachandra @ 2011-11-16 6:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List, Jonathan Nieder, Matthieu Moy
In-Reply-To: <7vvcqkswpu.fsf@alter.siamese.dyndns.org>
Hi,
Matthieu Moy wrote:
> (I just misread the subject line at first, and understood that this was> a revert of an earlier commit, while this is actually a commit touching> the "revert" part of Git)
Reminds me of an earlier note Jonathan made about the git-revert
commit message format. To avoid confusion, reverts should always look
like the following:
Revert [commit message]
This reverts commit [unabbreviated sha1 hex].
Junio C Hamano wrote:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>> Candidate for 'maint'?
>
> Too minor to matter when 'master' is already at -rc2.
Ah, I haven't been paying much attention to these release cycles. I
suppose we can put this patch in `master` after the release? I wince
everytime I see these ugly fatal messages: it happens shockingly often
while testing :)
Thanks.
-- Ram
^ permalink raw reply
* Re: [PATCH 3/5] sequencer: sequencer state is useless without todo
From: Ramkumar Ramachandra @ 2011-11-16 6:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, Git List
In-Reply-To: <7v7h31wduv.fsf@alter.siamese.dyndns.org>
Hi,
Jonathan Nieder wrote:
> Just use a sane idiom. Which means: as few git_path() values in
> flight at a time as possible.
Makes sense, thanks.
Junio C Hamano wrote:
> Or perhaps http://thread.gmane.org/gmane.comp.version-control.git/184963/focus=185436
I noticed that sha1_to_hex() also operates like this. The
resolve_ref() function is really important, but using the same
technique for these tiny functions is probably an overkill; something
in `Documentation/technical` perhaps?
Thanks.
-- Ram
^ permalink raw reply
* Re: [PATCH 3/4] ll-merge: initialize default_opts const
From: Ramkumar Ramachandra @ 2011-11-16 6:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List, Thomas Rast
In-Reply-To: <7vty65t1qp.fsf@alter.siamese.dyndns.org>
Hi Junio,
Junio C Hamano wrote:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>> [...]
>> diff --git a/ll-merge.c b/ll-merge.c
>> index da59738..205aed3 100644
>> --- a/ll-merge.c
>> +++ b/ll-merge.c
>> @@ -351,7 +351,7 @@ int ll_merge(mmbuffer_t *result_buf,
>> const struct ll_merge_options *opts)
>> {
>> static struct git_attr_check check[2];
>> - static const struct ll_merge_options default_opts;
>> + static const struct ll_merge_options default_opts = {0, 0, 0, 0};
>
> Doesn't "static" tell us that it will be in BSS, initialized to all zero
> by definition?
I'm uncertain about whether the C89 standard says this explicitly- icc
is more pedantic than most mainstream compilers. Feel free to drop
this part if you don't think it adds value.
Thanks.
-- Ram
^ permalink raw reply
* Re: [PATCH] git-show-ref: fix escaping in asciidoc source
From: Michael Haggerty @ 2011-11-16 5:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk471urfy.fsf@alter.siamese.dyndns.org>
On 11/15/2011 08:16 PM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>> Did this one fall through the cracks? I don't see it in your tree.
>
> Yeah, I was wondering if we can have a concise description in what context
> any "^" must be spelled as {caret} and what other context "^" can be
> spelled literally, and possibly which versions of AsciiDoc toolchain have
> this issue [*1*]. Without a clear guideline, people may unknowingly use
> literal "^" to new paragraphs, or perhaps worse yet, spell {caret} that
> end up being shown literally.
>
> Since I didn't find a clear pattern other than that "^" can and should be
> literally given in a literal paragraph (i.e. an indented paragraph or
> inside a listing/literal block that shows program examples), I was meaning
> to ask you if you knew the rules better than I did, and I stopped there,
> forgetting to follow through.
I didn't know anything about asciidoc, and just tried to fix it using a
bit of cargo-cult programming.
Now I just did about an hour of research about asciidoc (but I still
don't feel very enlightened). It seems that asciidoc was interpreting
the caret, paired with one earlier in the paragraph, as markup asking
for the enclosed text to be superscripted [1]. Apparently, single
carets in a paragraph are not treated as markup, which would explain
some apparent inconsistency about when carets need to be quoted. But it
would seem prudent to escape all carets that don't appear in literal blocks.
Constructs like "{caret}" are "simple attribute references". In this
particular case, the attribute that it is referencing is not built into
asciidoc but rather defined in the file Documentation/asciidoc.conf.
Empirically it seems that curly braces need to be escaped if they can be
interpreted to be part of an attribute reference, but not otherwise.
For example, curly braces with nothing inside of them like "{}" don't
necessarily need to be quoted, but it doesn't hurt if they are quoted to
"\{\}".
The backslash escape rules are a bit mysterious to me. Backslash can be
used to escape some special characters. For example, they can be used
to escape leading special quoting characters to avoid the special
effect, like "\_not italic_" [3]. They can also be used to suppress
attribute references, like "\{caret}" [4]. But it doesn't appear
possible to use a backslash to escape another backslash; for example
"\\{carat}" is rendered as "\{carat}". In such cases, the backslash can
be spelled "{backslash}" (which is also defined in asciidoc.conf).
How to quote a monstrosity like the regexp in git-show-ref.txt? We want
it to render as
^(?:<anything>\s)?<refname>(?:\^{})?$
, probably in monospaced font and surrounded by double quotes. asciidoc
supports a bewildering variety of quoting mechanisms [5]. Empirically,
"`^(?:<anything>\s)?<refname>(?:\^{})?$`"
doesn't work (the backticks don't suppress superscripting).
A pedestrian option is
"`{caret}(?:<anything>\s)?<refname>(?:{backslash}{caret}\{\})?$`"
or
"`{caret}(?:<anything>\s)?<refname>(?:{backslash}{caret}{})?$`"
Or the whole blob can be quoted en masse using $$:
"`$$^(?:<anything>\s)?<refname>(?:\^{})?$$$`"
I don't know whether it treats the last dollar signs as "$$ $" or "$
$$", but either way the result looks OK.
I can't believe I spent my whole morning on this :-(
Michael
[1]
http://www.methods.co.nz/asciidoc/userguide.html#_superscripts_and_subscripts
[2]
http://www.methods.co.nz/asciidoc/userguide.html#_simple_attributes_references
[3] http://www.methods.co.nz/asciidoc/userguide.html#X51
[4] http://www.methods.co.nz/asciidoc/userguide.html#_attribute_references
[5] http://www.methods.co.nz/asciidoc/userguide.html#X77
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: odd name-rev behavior?
From: Junio C Hamano @ 2011-11-16 5:41 UTC (permalink / raw)
To: Tim Walberg; +Cc: git
In-Reply-To: <20111116014842.GF27706@comcast.net>
Tim Walberg <twalberg@comcast.net> writes:
> That does indeed seem to work on first try. Not sure it was
> a particularly critical issue - just unexpected.
I didn't think it is particularly critical, either, and that is why I said
it has been like this for eons at least since v1.6.0.
And it turns out that this was pretty much from day one of name-rev at
bd321bc (Add git-name-rev, 2005-10-26).
^ permalink raw reply
* Re: input director not compatible with git right-click
From: Sitaram Chamarty @ 2011-11-16 4:52 UTC (permalink / raw)
To: Carlos Martín Nieto, Sitaram Chamarty, Eric, git
In-Reply-To: <20111115173843.GB5453@centaur.lab.cmartin.tk>
On Tue, Nov 15, 2011 at 11:08 PM, Carlos Martín Nieto <cmn@elego.de> wrote:
> On Tue, Nov 15, 2011 at 09:39:25PM +0530, Sitaram Chamarty wrote:
>> On Mon, Nov 14, 2011 at 8:10 PM, Carlos Martín Nieto <cmn@elego.de> wrote:
>> > On Sun, Nov 13, 2011 at 04:34:26PM +0000, Eric wrote:
>> >> Hi,
>> >>
>> >> New in Git use, I use it do dev on window some administrative script. I use as
>> >> well Input director to share keyboard and mouse on multiple computer.
>> >
>> > Do you mean you're using it on the Windows OS?
>> >
>> >>
>> >> when I right-clicked on an item, it works when input director is disabled. If
>> >
>> > Right-click on what? git doesn't have a graphical interface. If you're
>> > using a graphical front-end to git, you should send them a bug report.
>>
>> git comes with 3 perfectly cromulent graphical programs, and one of
>> them is indispensable.
>
> I guess we have diferent ideas of where "git" ends and other stuff
> starts. gitk, git-gui and what is the last one?
'git gui blame'
^ permalink raw reply
* Re: Git, Parrot, Perl6, Rakudo for G4 MAC
From: Sitaram Chamarty @ 2011-11-16 4:51 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Hilco Wijbenga, Greg, git
In-Reply-To: <m3fwhpmf1f.fsf@localhost.localdomain>
2011/11/15 Jakub Narebski <jnareb@gmail.com>:
> Git requires Perl version 5.8 at least, so you should not have any
> problems here.
One day someone [1] reminded me that git does not require perl. Some
features, like git add -p, require it but git can be built without
perl.
[1] on irc, while discussing my stated requirements for gitolite
^ permalink raw reply
* Re: odd name-rev behavior?
From: Tim Walberg @ 2011-11-16 1:48 UTC (permalink / raw)
To: git, Junio C Hamano
In-Reply-To: <7vlirht1fw.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1809 bytes --]
That does indeed seem to work on first try. Not sure it was
a particularly critical issue - just unexpected. For what I
was using it for it was simple to work around. But thanks
for the quick fix!
tw
On 11/15/2011 15:23 -0800, Junio C Hamano wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>> > Tim Walberg <twalberg@comcast.net> writes:
>> >
>> >> Never noticed this before - is this expected? It doesn't seem to
>> >> match documentation, in any case...
>> >>
>> >> Basically, 'git name-rev --all' lists a lot of lines that are
>> >> marked as "undefined", and most, if not all, of the objects
>> >> represented are trees, not commits... I wouldn't have expected
>> >> name-rev to follow the link from a commit to a tree and try to
>> >> process that result...
>> >
>> > I wouldn't either, but this does not look like a recent breakage. v1.6.0
>> > seems to show the same broken behaviour.
>>
>> And this one-liner should be sufficient (untested).
>>
>> builtin/name-rev.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/builtin/name-rev.c b/builtin/name-rev.c
>> index 7864056..1b37458 100644
>> --- a/builtin/name-rev.c
>> +++ b/builtin/name-rev.c
>> @@ -291,7 +291,7 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix)
>> max = get_max_object_index();
>> for (i = 0; i < max; i++) {
>> struct object *obj = get_indexed_object(i);
>> - if (!obj)
>> + if (!obj || obj->type != OBJ_COMMIT)
>> continue;
>> show_name(obj, NULL,
>> always, allow_undefined, data.name_only);
End of included message
--
+----------------------+
| Tim Walberg |
| 830 Carriage Dr. |
| Algonquin, IL 60102 |
| twalberg@comcast.net |
+----------------------+
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] revert: prettify fatal messages
From: Junio C Hamano @ 2011-11-16 1:05 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List, Jonathan Nieder
In-Reply-To: <1321349492-5653-1-git-send-email-artagnon@gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Candidate for 'maint'?
Too minor to matter when 'master' is already at -rc2.
Thanks.
^ permalink raw reply
* Re: [PATCH 2/2] archive: limit ourselves during remote requests
From: Junio C Hamano @ 2011-11-16 0:03 UTC (permalink / raw)
To: Jeff King; +Cc: Erik Faye-Lund, git
In-Reply-To: <20111115214840.GB20624@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> ... just a very stripped-down version of
> git-archive (i.e., it _only_ calls write_archive). Or it could even be
> spelled "git upload-archive --remote-request". But the point is that
> git-archive never needed to worry about security before. We
> shouldn't be polluting it with security code; we should be bypassing it
> going to write_archive directly.
Quite sensible, and a good approach to reroll the series, I would think.
^ permalink raw reply
* Re: [PATCH 0/2] upload-archive security issues
From: Junio C Hamano @ 2011-11-15 23:40 UTC (permalink / raw)
To: Jeff King; +Cc: Erik Faye-Lund, git
In-Reply-To: <20111115222320.GA28646@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> For the record: I would be fine with c09cd77e simply being reverted
>> for this release, and having a better version applied in the near
>> future. Windows support for upload-archive is not worth the risk of
>> slipping in a remote code execution bug...
>
> I'd be OK with that, too.
Ok, that is easier ;-)
^ permalink raw reply
* Re: hook for rebase --continue
From: Neal Kreitzinger @ 2011-11-15 23:28 UTC (permalink / raw)
To: Matt Graham; +Cc: git
In-Reply-To: <CALts4TQ545L1d1J0EiUjd7x=WBJpjCCv6UsXZOoGQAC29RqC5g@mail.gmail.com>
On 11/7/2011 1:42 PM, Matt Graham wrote:
> Hi, I did some testing and it appears that during a rebase, if I
> resolve a conflict and call git rebase --continue, the pre-commit
> hook doesn't run. This means that if I don't resolve the conflict
> correctly, our check for invalid syntax doesn't get run and creates
> the risk that someone could push code with invalid syntax, not
> realizing that the check didn't run.
>
> Does anyone else share my expectation that the pre-commit hook
> should run during a rebase? Or at least for the first commit
> following a rebase conflict?
>
> If not, is there another hook that is triggered by a rebase that I
> should be using instead?
>
I just noticed there is a post-rewrite hook in the manpage
http://schacon.github.com/git/githooks.html. Maybe this does what you want.
v/r,
neal
^ permalink raw reply
* Re: odd name-rev behavior?
From: Junio C Hamano @ 2011-11-15 23:23 UTC (permalink / raw)
To: git; +Cc: Tim Walberg
In-Reply-To: <7vpqgtt1kb.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Tim Walberg <twalberg@comcast.net> writes:
>
>> Never noticed this before - is this expected? It doesn't seem to
>> match documentation, in any case...
>>
>> Basically, 'git name-rev --all' lists a lot of lines that are
>> marked as "undefined", and most, if not all, of the objects
>> represented are trees, not commits... I wouldn't have expected
>> name-rev to follow the link from a commit to a tree and try to
>> process that result...
>
> I wouldn't either, but this does not look like a recent breakage. v1.6.0
> seems to show the same broken behaviour.
And this one-liner should be sufficient (untested).
builtin/name-rev.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin/name-rev.c b/builtin/name-rev.c
index 7864056..1b37458 100644
--- a/builtin/name-rev.c
+++ b/builtin/name-rev.c
@@ -291,7 +291,7 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix)
max = get_max_object_index();
for (i = 0; i < max; i++) {
struct object *obj = get_indexed_object(i);
- if (!obj)
+ if (!obj || obj->type != OBJ_COMMIT)
continue;
show_name(obj, NULL,
always, allow_undefined, data.name_only);
^ permalink raw reply related
* Re: odd name-rev behavior?
From: Junio C Hamano @ 2011-11-15 23:20 UTC (permalink / raw)
To: Tim Walberg; +Cc: git
In-Reply-To: <20111115211514.GE27706@comcast.net>
Tim Walberg <twalberg@comcast.net> writes:
> Never noticed this before - is this expected? It doesn't seem to
> match documentation, in any case...
>
> Basically, 'git name-rev --all' lists a lot of lines that are
> marked as "undefined", and most, if not all, of the objects
> represented are trees, not commits... I wouldn't have expected
> name-rev to follow the link from a commit to a tree and try to
> process that result...
I wouldn't either, but this does not look like a recent breakage. v1.6.0
seems to show the same broken behaviour.
^ permalink raw reply
* Re: [PATCH 3/4] ll-merge: initialize default_opts const
From: Junio C Hamano @ 2011-11-15 23:17 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List, Thomas Rast
In-Reply-To: <1321376379-31750-4-git-send-email-artagnon@gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
> ---
> ll-merge.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/ll-merge.c b/ll-merge.c
> index da59738..205aed3 100644
> --- a/ll-merge.c
> +++ b/ll-merge.c
> @@ -351,7 +351,7 @@ int ll_merge(mmbuffer_t *result_buf,
> const struct ll_merge_options *opts)
> {
> static struct git_attr_check check[2];
> - static const struct ll_merge_options default_opts;
> + static const struct ll_merge_options default_opts = {0, 0, 0, 0};
Doesn't "static" tell us that it will be in BSS, initialized to all zero
by definition?
^ permalink raw reply
* Re: Git 1.7.5 problem with HTTPS
From: Junio C Hamano @ 2011-11-15 23:10 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Dmitry Smirnov, git
In-Reply-To: <CAJo=hJvdstr39suGMwxNoT+_cKThxsEYHi96eqja7HuHyPmhWA@mail.gmail.com>
Shawn Pearce <spearce@spearce.org> writes:
> On Tue, Nov 15, 2011 at 05:52, Dmitry Smirnov <divis1969@gmail.com> wrote:
>
>> If I use the http URL (http://git.kernel.org/pub/scm/git/git.git) I
>> can clone with no problems.
>
> This may be a problem with the git.kernel.org HTTP server. It is
> probably not a problem with Git itself.
Not likely to be an issue with git.kernel.org either. I am puzzled.
$ git ls-remote https://git.kernel.org/pub/scm/git/git.git |
grep -e HEAD -e master
bc1bbe0c19a6ff39522b4fa3259f34150e308e1f HEAD
bc1bbe0c19a6ff39522b4fa3259f34150e308e1f refs/heads/master
$ rungit v1.7.5.4 ls-remote https://git.kernel.org/pub/scm/git/git.git |
grep -e HEAD -e master
bc1bbe0c19a6ff39522b4fa3259f34150e308e1f HEAD
bc1bbe0c19a6ff39522b4fa3259f34150e308e1f refs/heads/master
The only thing that immediately comes to mind is the rare smart-http
breakage in 1.7.5 but that was plugged in 1.7.5.1, so...
^ 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