* long fsck time
From: Nguyen Thai Ngoc Duy @ 2011-11-02 12:06 UTC (permalink / raw)
To: Git Mailing List
On git.git
$ /usr/bin/time git fsck
333.25user 4.28system 5:37.59elapsed 99%CPU (0avgtext+0avgdata
420080maxresident)k
0inputs+0outputs (0major+726560minor)pagefaults 0swaps
That's really long time, perhaps we should print progress so users
know it's still running?
--
Duy
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Jochen Striepe @ 2011-11-02 11:20 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Junio C Hamano, H. Peter Anvin, git,
James Bottomley, Jeff Garzik, Andrew Morton, linux-ide, LKML
In-Reply-To: <20111102091126.GG18903@elte.hu>
Hi,
On Wed, Nov 02, 2011 at 10:11:26AM +0100, Ingo Molnar wrote:
> If this approach is used then it would be nice to have a .gitconfig
> switch to require trusted pulls by default: to not allow doing
> non-signed or untrusted pulls accidentally, or for Git to warn in a
> visible, hard to miss way if there's a non-signed pull.
>
> This adds social uncertainty (and an element of a silent alarm) to a
> realistic attack: the attacker wouldnt know exactly how the puller
> checks signed pull requests, it's kept private.
But that way you get a false sense of alarm when someone sent a
perfectly trustable pull request, e.g. by signed email.
Another question: If store the actual pgp/gpg signatures in the git tree,
how do you handle signatures by keys which were valid by the time the
signature was made but expired when checking some time afterwards? AFAICT,
gpg will only tell you the key is expired _now_, and will make no statement
regarding the time the actual signature was made.
Thanks,
Jochen.
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Michael J Gruber @ 2011-11-02 10:53 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, git, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <7vwrbjlj5r.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 01.11.2011 20:47:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> But what would be nice is that "git pull" would fetch the tag (based on
>> name) *automatically*, and not actually create a tag in my repository at
>> all. Instead, if would use the tag to check the signature, and - if we
>> do this right - also use the tag contents to populate the merge commit
>> message.
>>
>> In other words, no actual tag would ever be left around as a turd, it
>> would simply be used as an automatic communication channel between the
>> "git push -s" of the submitter and my subsequent "git pull". Neither
>> side would have to do anything special, and the tag would never show
>> up in any relevant tree (it could even be in a totally separate
>> namespace like "refs/pullmarker/<branchname>" or something).
>
> While I like the "an ephemeral tag is used only for hop-to-hop
> communication to carry information to be recorded in the resulting
> history" approach, I see a few downsides.
>
> * The ephemeral tag needs to stay somewhere under refs/ hierarchy of the
> lieutenant's tree until you pick it up, even if they are out of the way
> in refs/pullmarker/$branchname. The next time the same lieutenant makes
> a pull request, either it will be overwritten or multiple versions of
> them refs/pullmarker/$branchname/$serial need to be kept.
If we are interested in commit sigs, the easiest tag-based approach is
to name the sig carrying tag by the commit's sha1. Just like the sig is
tied (in)to a commit in Junio's approach, it would be indexed by it. We
can do that now:
git config --global alias.sign '!f() { c=$(git rev-parse "$1") || exit;
shift; git tag -s $@ sigs/$c $c; }; f'
But a different place rather than refs/tags/sigs/<sha1> will be more
appropriate, so that we don't pollute the tag namespace. (Yes, this is
similar to storing them in notes.) tags have a message etc.
With an appropriate refspec, these sigs can be pushed out automatically
(by the lieutenant).
pull-request as in next will list the expected <sha1> at tip.
git pull needs to learn to (fetch and) use refs/<whatever>/<sha1> to
verify that the tip is signed.
git log --show-signature can do the same tricks as with in-commit sigs.
Some things to decide in this approach:
- Should git-pull (pull sigs and) verify by default?
- Should we worry about overwriting existings sigs? We have union-merge
for notes already, and that would be appropriate for sigs. (Yes, our
tags code does verify multiple concatenated sigs.)
The advantage of tags is that they can be added without rewriting the
commit, of course.
Michael
^ permalink raw reply
* [PATCH] http.c: Use curl_multi_fdset to select on curl fds instead of just sleeping
From: Mika Fischer @ 2011-11-02 10:45 UTC (permalink / raw)
To: git; +Cc: Mika Fischer
Previously, when nothing could be read from the connections curl had
open, git would just sleep unconditionally for 50ms. This patch changes
this behavior and instead obtains the recommended timeout and the actual
file descriptors from curl. This should eliminate time spent sleeping when
data could actually be read/written on the socket.
Signed-off-by: Mika Fischer <mika.fischer@zoopnet.de>
---
http.c | 21 ++++++++++++++++-----
1 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/http.c b/http.c
index a4bc770..12180f3 100644
--- a/http.c
+++ b/http.c
@@ -649,6 +649,7 @@ void run_active_slot(struct active_request_slot *slot)
fd_set excfds;
int max_fd;
struct timeval select_timeout;
+ long int curl_timeout;
int finished = 0;
slot->finished = &finished;
@@ -664,14 +665,24 @@ void run_active_slot(struct active_request_slot *slot)
}
if (slot->in_use && !data_received) {
- max_fd = 0;
+ curl_multi_timeout(curlm, &curl_timeout);
+ if (curl_timeout == 0) {
+ continue;
+ } else if (curl_timeout == -1) {
+ select_timeout.tv_sec = 0;
+ select_timeout.tv_usec = 50000;
+ } else {
+ select_timeout.tv_sec = curl_timeout / 1000;
+ select_timeout.tv_usec = (curl_timeout % 1000) * 1000;
+ }
+
+ max_fd = -1;
FD_ZERO(&readfds);
FD_ZERO(&writefds);
FD_ZERO(&excfds);
- select_timeout.tv_sec = 0;
- select_timeout.tv_usec = 50000;
- select(max_fd, &readfds, &writefds,
- &excfds, &select_timeout);
+ curl_multi_fdset(curlm, &readfds, &writefds, &excfds, &max_fd);
+
+ select(max_fd+1, &readfds, &writefds, &excfds, &select_timeout);
}
}
#else
--
1.7.7.1.489.g1fee
^ permalink raw reply related
* Re: [ANNOUNCE] Git 1.7.8.rc0
From: Michael J Gruber @ 2011-11-02 10:27 UTC (permalink / raw)
To: Stefan Naewe; +Cc: git, Junio C Hamano, Jeff King
In-Reply-To: <loom.20111101T211624-511@post.gmane.org>
[Re-adding cc's]
Stefan Naewe venit, vidit, dixit 01.11.2011 21:18:
> Stefan Naewe <stefan.naewe <at> gmail.com> writes:
>
>> Push with https works, if the URL looks e.g. like this:
>>
>> https://github.com/user/repo.git
>>
>> rather than this
>>
>> https://user <at> github.com/user/repo.git
>>
>> and having a ~/.netrc like this
>>
>> machine github.com login user password YouDontWantToKnow
>>
>> If the URL contains 'user@' I get the 'need ENTER' behaviour.
>>
>
> Another update:
>
> If I revert deba493 the 'need ENTER' is gone and everything works as above.
>
>
> Stefan
>
I can confirm that (and feel partly responsible given the history of of
deba493). For the record: A simple test looks like
SSH_ASKPASS='' git push -n bitbucket
Password for 'bitbucket.org':
which succeeds with a simple ENTER when you have the (log and) PW in
.netrc for that host, and your config says https://user@host.
The workaround is to remove 'user@' from the url in gitconfig, it is not
needed nor used, probably: I haven't checked yet, but that would mean we
can't have two different logins on the same server in .netrc. Can we?
I'll try to have a look later, too.
Michael
^ permalink raw reply
* Re: git sticker svg
From: Michael J Gruber @ 2011-11-02 9:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vy5vykhl3.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 02.11.2011 10:18:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> I do prefer the rotated, vertically stacked +-G though (with + <-> t, -
>> <-> i, G <-> 3/4-circle with arrow). Good thing we don't have to argue
>> about an "official" logo...
>
> It somehow reminds me of the OGC logo fiasco, though.
:)
While looking up "OGC logo fiasco" certainly was fun, I don't think that
our msysgit logo, e.g., is prone to wild fantasies' misinterpretation,
no matter the position, uhm, rotation:
http://code.google.com/p/msysgit/downloads/detail?name=gitlogo.svg
But maybe my fantasy is not wild enough.
Michael
^ permalink raw reply
* Re: Q: "git diff" using tag names
From: Junio C Hamano @ 2011-11-02 9:35 UTC (permalink / raw)
To: Alexey Shumkin; +Cc: Ulrich Windl, git
In-Reply-To: <20111102132945.582707aa@ashu.dyn.rarus.ru>
Alexey Shumkin <alex.crezoff@gmail.com> writes:
>> Also it seems that both syntaxes work:
>> git diff v0.4..v0.5
>> git diff v0.4 v0.5
> honestly, I do not know the difference (at the moment :))
> may be gurus or manual will help to discover it
The latter is the kosher version, as diff is about two "endpoints" and not
about "ranges". The only reason the former is parsed without erroring out
is because too many people are used to type .. between two things without
thinking, learned the notation from "git log", which _is_ about ranges.
^ permalink raw reply
* Re: Q: "git diff" using tag names
From: Frans Klaver @ 2011-11-02 9:34 UTC (permalink / raw)
To: Alexey Shumkin; +Cc: Ulrich Windl, git
In-Reply-To: <20111102132945.582707aa@ashu.dyn.rarus.ru>
On Wed, Nov 2, 2011 at 10:29 AM, Alexey Shumkin <alex.crezoff@gmail.com> wrote:
>> Also it seems that both syntaxes work:
>> git diff v0.4..v0.5
>> git diff v0.4 v0.5
> honestly, I do not know the difference (at the moment :))
> may be gurus or manual will help to discover it
As per the git-diff documentation, these two versions behave equally
-- i.e. no differences.
Comparing branches
$ git diff topic master <1>
$ git diff topic..master <2>
$ git diff topic...master <3>
1. Changes between the tips of the topic and the master branches.
2. Same as above.
3. Changes that occurred on the master branch since when the topic
branch was started off it.
Cheers,
Frans
^ permalink raw reply
* Re: Q: "git diff" using tag names
From: Alexey Shumkin @ 2011-11-02 9:29 UTC (permalink / raw)
To: Ulrich Windl; +Cc: git
In-Reply-To: <4EB0FFCA020000A100007DE2@gwsmtp1.uni-regensburg.de>
> Hello Alexey,
>
> thank you very much for your reply. I felt I did something wrong, but
> couldn't find out what it was. Actually it turned out that I had just
> mistyped one tag name.
>
> Also it seems that both syntaxes work:
> git diff v0.4..v0.5
> git diff v0.4 v0.5
>
> The question is: How does git disambiguate between tag names, commits
> and file names? (All may start with a letter) This seems to work
> automagically, and I was desparately looking for an option like "--"
> to separate revisions from file names. I found "SPECIFYING REVISIONS"
> in git-rev-parse(1), so you don't really have to answer.
Yes, you found right answer. "--" option separates file names from
"commits' names". but it usually necessary when you have branches or
tags named as some of your files.
E.g. you have file "test" and you name branch "test"
so "git log test" will complain that it cannot understand your
intention to see log of what and will fail
$ git log test
fatal: ambiguous argument 'test': both revision and filename
Use '--' to separate filenames from revisions
$ git log -- test
will show log of file test
$ git log test --
will show log of branch test
> Also it seems that both syntaxes work:
> git diff v0.4..v0.5
> git diff v0.4 v0.5
honestly, I do not know the difference (at the moment :))
may be gurus or manual will help to discover it
>
> Regards,
> Ulrich
>
> >>> Alexey Shumkin <Alex.Crezoff@gmail.com> schrieb am 28.10.2011 um
> >>> 14:59 in
> Nachricht <20111028165943.2cc8253d@ashu.dyn.rarus.ru>:
> > Tag is a pointer to a commit (if to say simply)
> >
> > e.g. in my repo
> > $ git show-ref --tags --abbrev=7
> > -->8--
> > 676f194 refs/tags/v2.6.7
> > b23c481 refs/tags/v2.6.8
> > -->8--
> >
> > so
> >
> > $ git diff v2.6.7..v2.6.8
> > is equivalent to
> > $ git diff 676f194..b23c481
> >
> > etc
> > > Hi,
> > >
> > > when using a somewhat older git (of SLES11 SP1 SDK), I could not
> > > find a way to "git diff" between two tag names; I can only diff
> > > between two commit numbers. I can display a changeset using "git
> > > show", but that's not what I wanted. Is it possible to get the
> > > diff I want using older versions, and is such a feature
> > > implemented in the current version? If so, since when?
> > >
> > > As I'm not subscribed to the list, I'd appreciate CC'ed replies.
> > > Thank you.
> > >
> > > Greeting
> > > Ulrich
> > >
> > >
> >
> >
>
>
>
>
^ permalink raw reply
* Re: git sticker svg
From: Junio C Hamano @ 2011-11-02 9:18 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Jeff King, git
In-Reply-To: <4EB1002A.6010602@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> I do prefer the rotated, vertically stacked +-G though (with + <-> t, -
> <-> i, G <-> 3/4-circle with arrow). Good thing we don't have to argue
> about an "official" logo...
It somehow reminds me of the OGC logo fiasco, though.
^ permalink raw reply
* Re: [PATCH] http.c: Use curl_multi_fdset to select on curl fds instead of just sleeping
From: Junio C Hamano @ 2011-11-02 9:17 UTC (permalink / raw)
To: Mika Fischer; +Cc: Daniel Stenberg, git
In-Reply-To: <CAOs=hR+u_MrHK4iNFZj4pLVhZ6-_75YpqN7tqWnSjh+di8Lzxw@mail.gmail.com>
Mika Fischer <mika.fischer@zoopnet.de> writes:
> Since I'm new here, I don't really know what the next steps are for
> the patch, should I just wait? Or send it directly to someone?
Resend to the list for re-evaluation, and then we can take it from there.
Thanks.
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Ingo Molnar @ 2011-11-02 9:11 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, H. Peter Anvin, git, James Bottomley, Jeff Garzik,
Andrew Morton, linux-ide, LKML
In-Reply-To: <CA+55aFyKWLUMQFfaeKJKGFPV_7kfOGjf+pSZ1Y8afzkT4OYQ9Q@mail.gmail.com>
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> And the receiving side would just do the "git pull" and
> automatically just get notified that "Yes, this push has been
> signed by key Xyz Abcdef"
If this approach is used then it would be nice to have a .gitconfig
switch to require trusted pulls by default: to not allow doing
non-signed or untrusted pulls accidentally, or for Git to warn in a
visible, hard to miss way if there's a non-signed pull.
This adds social uncertainty (and an element of a silent alarm) to a
realistic attack: the attacker wouldnt know exactly how the puller
checks signed pull requests, it's kept private.
Thanks,
Ingo
^ permalink raw reply
* [RFC/PATCH] http-push: don't always prompt for password (Was Re: [ANNOUNCE] Git 1.7.8.rc0)
From: Stefan Näwe @ 2011-11-02 8:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git@vger.kernel.org, Jeff King
In-Reply-To: <7vmxcfn23i.fsf@alter.siamese.dyndns.org>
Am 01.11.2011 19:12, schrieb Junio C Hamano:
>
> There are only handful of commits that even remotely touch http related
> codepath between v1.7.7 and v1.7.8-rc0:
>
> * deba493 http_init: accept separate URL parameter
>
> This could change the URL string given to http_auth_init().
>
> * 070b4dd http: use hostname in credential description
>
> This only changes the prompt string; as far as I understand it, the
> condition the password is prompted in the callsites of git_getpass()
> has not changed.
>
> * 6cdf022 remote-curl: Fix warning after HTTP failure
> * be22d92 http: avoid empty error messages for some curl errors
> * 8abc508 http: remove extra newline in error message
> * 8d677ed http: retry authentication failures for all http requests
> * 28d0c10 remote-curl: don't retry auth failures with dumb protocol
>
> These shouldn't affect anything wrt prompting, unless you are somehow
> internally reauthenticating.
>
> Could you try reverting deba493 and retest, and then if the behaviour is
> the same "need ENTER", further revert 070b4dd and retest?
I did a little more testing.
This WIP makes it work for me (i.e. "need ENTER" is gone, works with
and without .netrc, with 'https://host/repo.git' and
'https://user@host...' URL). Needs testing, of course.
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
diff --git a/http.c b/http.c
index a4bc770..008ad72 100644
--- a/http.c
+++ b/http.c
@@ -279,8 +279,6 @@ static CURL *get_curl_handle(void)
curl_easy_setopt(result, CURLOPT_HTTPAUTH, CURLAUTH_ANY);
#endif
- init_curl_http_auth(result);
-
if (ssl_cert != NULL)
curl_easy_setopt(result, CURLOPT_SSLCERT, ssl_cert);
if (has_cert_password())
@@ -846,7 +844,7 @@ static int http_request(const char *url, void *result, int target, int options)
else if (missing_target(&results))
ret = HTTP_MISSING_TARGET;
else if (results.http_code == 401) {
- if (user_name) {
+ if (user_name && user_pass) {
ret = HTTP_NOAUTH;
} else {
/*
@@ -855,7 +853,8 @@ static int http_request(const char *url, void *result, int target, int options)
* but that is non-portable. Using git_getpass() can at least be stubbed
* on other platforms with a different implementation if/when necessary.
*/
- user_name = xstrdup(git_getpass_with_description("Username", description));
+ if (!user_name)
+ user_name = xstrdup(git_getpass_with_description("Username", description));
init_curl_http_auth(slot->curl);
ret = HTTP_REAUTH;
}
---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
Regards,
Stefan
--
----------------------------------------------------------------
/dev/random says: Efficiency takes time! Frugality: who can afford it?
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
^ permalink raw reply related
* Re: git sticker svg
From: Michael J Gruber @ 2011-11-02 8:32 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111101211643.GA12768@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 01.11.2011 22:16:
> If you were at the GSoC mentor summit or the GitTogether last week, you
> may seen Git stickers floating around. I printed 500, thinking there
> would be some leftovers to distribute afterwards. But either git is very
> popular, or somebody decided to re-wallpaper their bedroom, because we
> ran out.
>
> In case anybody wants to make their own git sticker (or whatever), I'm
> providing the SVG that I sent to the printer. I ordered 2"x4" stickers,
> but it's scalable, you should be able to do any size.
>
> Credit where credit is due:
>
> The logo is shamelessly stolen from one Sam Vilain made for GitTogether
> t-shirts in 2008. It's really just the "---/+++" logo done in FreeMono
> with a few pretty colors and outlines. I have no idea who did the
> original "---/+++" logo. It's awesome, but I couldn't find a nice
> scalable version, hence this.
Yeah, git has been G-+ long before G+ ;)
I do prefer the rotated, vertically stacked +-G though (with + <-> t, -
<-> i, G <-> 3/4-circle with arrow). Good thing we don't have to argue
about an "official" logo...
Michael
^ permalink raw reply
* Re: [PATCH] http.c: Use curl_multi_fdset to select on curl fds instead of just sleeping
From: Mika Fischer @ 2011-11-02 8:21 UTC (permalink / raw)
To: Daniel Stenberg; +Cc: git
In-Reply-To: <CAOs=hR+YuF+HP0n0132Ktm3RdeWsnVp0Bgt89LNn+VyT6W0mcw@mail.gmail.com>
>> Calling select() with max_fd+1 (== 0) will then not be appreciated by all
>> implementations of select() so that case should probably also be covered by
>> the 50ms sleep approach...
>
> Actually, the 50ms sleep was also implemented using select(0, ...)
> before the patch. I tried to keep the previous behavior when curl does
> not give us any information.
> I assumed that the select(0, ...) was some portable way to sleep with
> microsecond granularity.
Upon a bit of research, it seems that select(0, ...) is indeed quite
commonly used. So I'd just keep it as it was unless you know of a
problem it causes.
Since I'm new here, I don't really know what the next steps are for
the patch, should I just wait? Or send it directly to someone?
Best,
Mika
^ permalink raw reply
* Antw: Re: Q: "git diff" using tag names
From: Ulrich Windl @ 2011-11-02 7:35 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3aa8l5k1y.fsf@localhost.localdomain>
>>> Jakub Narebski <jnareb@gmail.com> schrieb am 28.10.2011 um 15:21 in Nachricht
<m3aa8l5k1y.fsf@localhost.localdomain>:
> "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> writes:
>
> > When using a somewhat older git (of SLES11 SP1 SDK),
>
> Nb. you can check version of git with "git --version".
Hi!
For the records, it's "1.6.0.2"...
>
> > I could not
> > find a way to "git diff" between two tag names; I can only diff
> > between two commit numbers. I can display a changeset using "git
> > show", but that's not what I wanted.
> >
> > Is it possible to get the diff I want using older versions, and is
> > such a feature implemented in the current version? If so, since
> > when?
>
> From the very beginning in Git you can use tag name where you need
> commit identifier; Git would use commit that tag points to (will
> dereference or peel a tag).
As said before, I was confused by the simplicity: I was looking for an option to specify revisions (as opposed to file names), like "-r" for RCS, but found none. To make things complicated, I had mistyped one tag name without noticing, so I failed to diff, making me think that tag names won't work the way they actually do.
Sorry, and thanks to everybody who helped!
Ulrich
>
> That is not possible in some [censored] version control systems; I am
> looking at you, Subversion!
>
>
> So if you can do
>
> $ git show v0.9
> $ git show v1.0
>
> you can also do
>
> $ git diff v0.9 v1.0
>
> and
>
> $ git log v0.9..v1.0
^ permalink raw reply
* Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC
From: Vincent van Ravesteijn @ 2011-11-02 7:34 UTC (permalink / raw)
To: Pat Thoyts
Cc: Johannes Schindelin, ramsay, msysgit, Karsten Blees, git,
Junio C Hamano, Erik Faye-Lund
In-Reply-To: <CABNJ2G+Km4wob4_uNYQLkQUL61-ohZg5cL2yu7j1cngoL9W7Cw@mail.gmail.com>
Op 2-11-2011 1:48, Pat Thoyts schreef:
> On 1 November 2011 22:32, Vincent van Ravesteijn<vfr@lyx.org> wrote:
>>> Maybe if someone donates Jenkins resources, we could make an automatic
>>> branch in the future that has git.sln in it (similar to the 'html' branch
>>> in git.git).
>>>
>> As long as this means to just run a not so complicated perl script, this
>> Could even be done in a commit hook.
>>
>> Just another question. How does the (msys)git community feel about adding
>> CMake support ? I can probably do that quite easily.
>>
>> Vincent
>>
> -1. We have a make. We don't need two of them.
Make won't offer anything if you want to support MSVC. So, if you want
to support MSVC, there has to be some sort of alternative.
Vincent
^ permalink raw reply
* Antw: Re: Q: "git diff" using tag names
From: Ulrich Windl @ 2011-11-02 7:31 UTC (permalink / raw)
To: Alexey Shumkin; +Cc: git
In-Reply-To: <20111028165943.2cc8253d@ashu.dyn.rarus.ru>
Hello Alexey,
thank you very much for your reply. I felt I did something wrong, but couldn't find out what it was. Actually it turned out that I had just mistyped one tag name.
Also it seems that both syntaxes work:
git diff v0.4..v0.5
git diff v0.4 v0.5
The question is: How does git disambiguate between tag names, commits and file names? (All may start with a letter)
This seems to work automagically, and I was desparately looking for an option like "--" to separate revisions from file names. I found "SPECIFYING REVISIONS" in git-rev-parse(1), so you don't really have to answer.
Regards,
Ulrich
>>> Alexey Shumkin <Alex.Crezoff@gmail.com> schrieb am 28.10.2011 um 14:59 in
Nachricht <20111028165943.2cc8253d@ashu.dyn.rarus.ru>:
> Tag is a pointer to a commit (if to say simply)
>
> e.g. in my repo
> $ git show-ref --tags --abbrev=7
> -->8--
> 676f194 refs/tags/v2.6.7
> b23c481 refs/tags/v2.6.8
> -->8--
>
> so
>
> $ git diff v2.6.7..v2.6.8
> is equivalent to
> $ git diff 676f194..b23c481
>
> etc
> > Hi,
> >
> > when using a somewhat older git (of SLES11 SP1 SDK), I could not find
> > a way to "git diff" between two tag names; I can only diff between
> > two commit numbers. I can display a changeset using "git show", but
> > that's not what I wanted. Is it possible to get the diff I want using
> > older versions, and is such a feature implemented in the current
> > version? If so, since when?
> >
> > As I'm not subscribed to the list, I'd appreciate CC'ed replies.
> > Thank you.
> >
> > Greeting
> > Ulrich
> >
> >
>
>
^ permalink raw reply
* Re: Git is exploding
From: Miles Bader @ 2011-11-02 4:51 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Øyvind A. Holm, git
In-Reply-To: <vpqfwi8tary.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> The recent rise is essentially due to the git-core package renamed to
> git, and people doing updates:
The renaming would obviously explain the extreme initial steepness of
the rise, but it shouldn't have much effect on the absolute values or
the more recent numbers.
[Look at git-core+git, basically it makes the initial part of the
graph fill in a bit, getting rid of the weird kink and making it more
smoothly exponential but doesn't really change the conclusion.]
Probably the main distortion is just the fact that it counts Debian
users ... subversion has a lot of stodgy corporate users etc that are
unlikely to use Debian! :]
--Miles
--
Twice, adv. Once too often.
^ permalink raw reply
* [ANNOUNCE] Git 1.7.7.2
From: Junio C Hamano @ 2011-11-02 1:23 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
The latest maintenance release Git 1.7.7.2 is available.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
be5be63fbab63517fcccf5c876749c61b0019d14 git-1.7.7.2.tar.gz
8f0eb6f1150ea8c6922343aa4c3ee6cf37e8a091 git-htmldocs-1.7.7.2.tar.gz
07e0887315224ac83c61ed60602c345c32a5d658 git-manpages-1.7.7.2.tar.gz
Also the following public repositories all have a copy of the v1.7.7.2
tag and the maint branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git v1.7.7.2 Release Notes
==========================
Fixes since v1.7.7.1
--------------------
* We used to drop error messages from libcurl on certain kinds of
errors.
* Error report from smart HTTP transport, when the connection was
broken in the middle of a transfer, showed a useless message on
a corrupt packet.
* "git fetch --prune" was unsafe when used with refspecs from the
command line.
* The attribute mechanism did not use case insensitive match when
core.ignorecase was set.
* "git bisect" did not notice when it failed to update the working tree
to the next commit to be tested.
* "git config --bool --get-regexp" failed to separate the variable name
and its value "true" when the variable is defined without "= true".
* "git remote rename $a $b" were not careful to match the remote name
against $a (i.e. source side of the remote nickname).
* "git mergetool" did not use its arguments as pathspec, but as a path to
the file that may not even have any conflict.
* "git diff --[num]stat" used to use the number of lines of context
different from the default, potentially giving different results from
"git diff | diffstat" and confusing the users.
* "git pull" and "git rebase" did not work well even when GIT_WORK_TREE is
set correctly with GIT_DIR if the current directory is outside the working
tree.
* "git send-email" did not honor the configured hostname when restarting
the HELO/EHLO exchange after switching TLS on.
* "gitweb" used to produce a non-working link while showing the contents
of a blob, when JavaScript actions are enabled.
----------------------------------------------------------------
Changes since v1.7.7.1 are as follows:
Brandon Casey (4):
attr.c: avoid inappropriate access to strbuf "buf" member
cleanup: use internal memory allocation wrapper functions everywhere
builtin/mv.c: plug miniscule memory leak
attr.c: respect core.ignorecase when matching attribute patterns
Carlos Martín Nieto (6):
Remove 'working copy' from the documentation and C code
fetch: free all the additional refspecs
t5510: add tests for fetch --prune
remote: separate out the remote_find_tracking logic into query_refspecs
fetch: honor the user-provided refspecs when pruning refs
fetch: treat --tags like refs/tags/*:refs/tags/* when pruning
Christian Couder (1):
bisect: fix exiting when checkout failed in bisect_start()
Haitao Li (1):
date.c: Support iso8601 timezone formats
Jakub Narebski (1):
gitweb: Strip non-printable characters from syntax highlighter output
Jeff King (8):
add sha1_array API docs
quote.h: fix bogus comment
refactor argv_array into generic code
quote: provide sq_dequote_to_argv_array
bisect: use argv_array API
checkout: use argv_array API
run_hook: use argv_array API
pull,rebase: handle GIT_WORK_TREE better
Jim Meyering (1):
make the sample pre-commit hook script reject names with newlines, too
Jonathan Nieder (2):
http: remove extra newline in error message
http: avoid empty error messages for some curl errors
Jonathon Mah (1):
mergetool: Use args as pathspec to unmerged files
Junio C Hamano (5):
refactor run_receive_hook()
diff: teach --stat/--numstat to honor -U$num
mergetool: no longer need to save standard input
attr: read core.attributesfile from git_default_core_config
Git 1.7.7.2
Martin von Zweigbergk (4):
remote: write correct fetch spec when renaming remote 'remote'
remote: "rename o foo" should not rename ref "origin/bar"
remote rename: warn when refspec was not updated
remote: only update remote-tracking branch if updating refspec
Matthew Daley (1):
send-email: Honour SMTP domain when using TLS
Michael Haggerty (1):
notes_merge_commit(): do not pass temporary buffer to other function
Michael J Gruber (3):
unpack-trees: print "Aborting" to stderr
git-read-tree.txt: language and typography fixes
git-read-tree.txt: correct sparse-checkout and skip-worktree description
Nguyễn Thái Ngọc Duy (2):
git-read-tree.txt: update sparse checkout examples
Reindent closing bracket using tab instead of spaces
Pat Thoyts (1):
t7511: avoid use of reserved filename on Windows.
Peter Stuge (1):
gitweb: Fix links to lines in blobs when javascript-actions are enabled
Ramsay Allan Jones (1):
t9159-*.sh: skip for mergeinfo test for svn <= 1.4
René Scharfe (1):
read-cache.c: fix index memory allocation
Richard Hartmann (1):
clone: Quote user supplied path in a single quote pair
Shawn O. Pearce (1):
remote-curl: Fix warning after HTTP failure
Stefan Naewe (1):
Documentation/git-update-index: refer to 'ls-files'
Thomas Rast (1):
Documentation: basic configuration of notes.rewriteRef
^ permalink raw reply
* Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC
From: Pat Thoyts @ 2011-11-02 0:48 UTC (permalink / raw)
To: Vincent van Ravesteijn
Cc: Johannes Schindelin, ramsay, msysgit, Karsten Blees, git,
Junio C Hamano, Erik Faye-Lund
In-Reply-To: <CAAH6HY8WfOQQ4g54y7mriq6BKoJCWYsVPrQUTMndqpKdniLAtw@mail.gmail.com>
On 1 November 2011 22:32, Vincent van Ravesteijn <vfr@lyx.org> wrote:
>
>> Maybe if someone donates Jenkins resources, we could make an automatic
>> branch in the future that has git.sln in it (similar to the 'html' branch
>> in git.git).
>>
>
> As long as this means to just run a not so complicated perl script, this
> Could even be done in a commit hook.
>
> Just another question. How does the (msys)git community feel about adding
> CMake support ? I can probably do that quite easily.
>
> Vincent
>
-1. We have a make. We don't need two of them.
^ permalink raw reply
* Re: Re: [PATCHv2] Compile fix for MSVC
From: Vincent van Ravesteijn @ 2011-11-01 23:33 UTC (permalink / raw)
To: Johannes Schindelin
Cc: ramsay, msysgit, Karsten Blees, git, Junio C Hamano,
Erik Faye-Lund
In-Reply-To: <alpine.DEB.1.00.1111011738550.32316@s15462909.onlinehome-server.info>
[-- Attachment #1: Type: text/plain, Size: 1342 bytes --]
>
>
> > > Maybe if someone donates Jenkins resources, we could make an automatic
> > > branch in the future that has git.sln in it (similar to the 'html'
> > > branch in git.git).
> >
> > As long as this means to just run a not so complicated perl script, this
> > Could even be done in a commit hook.
>
> I actually was thinking about something automatic which does not require
> any of the busy msysGit developers to do something manual every once in a
> while.
I thought that a commit hook, was something automatic (iff the busy
developers
do commit something once in a while). I guess I can even set this up very
easily
(given push rights, otherwise it will involve manual labor again).
> > Just another question. How does the (msys)git community feel about
> > adding CMake support ? I can probably do that quite easily.
>
> There was somebody who strongly favored CMake over any other solution but
> was not willing to maintain it in the long run (also, I have to admit that
> I have had quite a few problems with CMake, but maybe I am just pampered
> by projects that Just Compile...)
>
The current way of generating a MSVC project is rather outdated, so the
worst
thing that can happen is that you have a different build system which is not
maintained. At least the CMake people will continue to improve on their
side.
Vincent
[-- Attachment #2: Type: text/html, Size: 2011 bytes --]
^ permalink raw reply
* Re: t5800-*.sh: Intermittent test failures
From: Alex Riesen @ 2011-11-01 23:02 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ramsay Jones, Jeff King, Sverre Rabbelier, GIT Mailing-list,
Jonathan Nieder
In-Reply-To: <7vfwi7lc54.fsf@alter.siamese.dyndns.org>
On Tue, Nov 1, 2011 at 23:18, Junio C Hamano <gitster@pobox.com> wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
>> On Sun, Sep 11, 2011 at 21:14, Ramsay Jones <ramsay@ramsay1.demon.co.uk> wrote:
>>> ... these hangs *are* the failures of which I speak! Yes, the script
>>> doesn't get to declare a failure, but AFAIAC a hanging test (and it
>>> isn't the same test # each time) is a failing test. :-D
>>
>> Was there any outcome of this discussion? I'm asking because I
>> can reproduce this very reliably on a little server here.
>
> I do remember this discussion and recall seeing _no_ outcome.
>
> I did see the hang myself once or twice but did not and do not have a
> reliable reproduction. I have been waiting for somebody to raise the issue
> again ;-).
>
I think I managed to bisect it (between 1.7.6 and 1.7.7):
$ git bisect start v1.7.7 v1.7.6
...
$ git bisect good
a515ebe9f1ac9bc248c12a291dc008570de505ca is the first bad commit
commit a515ebe9f1ac9bc248c12a291dc008570de505ca
Author: Sverre Rabbelier <srabbelier@gmail.com>
Date: Sat Jul 16 15:03:40 2011 +0200
transport-helper: implement marks location as capability
Now that the gitdir location is exported as an environment variable
this can be implemented elegantly without requiring any explicit
flushes nor an ad-hoc exchange of values.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
:100644 100644 1ed7a5651ef5a2320c56856b5a1fe784e178ab23
e9c832bfd3da7db771cc2113027d3e590dc51d59 M git-remote-testgit.py
:100644 100644 0cfc9ae9059ce121b567406d7941b71cd54b961c
74c3122df1835c45a6b621205fb18b4fc89af366 M transport-helper.c
Sadly, I'm going to be able to repeat the test in about 20 hours.
^ permalink raw reply
* Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC
From: Johannes Schindelin @ 2011-11-01 22:51 UTC (permalink / raw)
To: Erik Faye-Lund
Cc: Junio C Hamano, Vincent van Ravesteijn, git, ramsay, msysgit,
Karsten Blees
In-Reply-To: <CABPQNSb07fRUCqPCX7JbfGW_55etZZtPyP=yuCKV9wJeNP-iQw@mail.gmail.com>
Hi kusma,
On Tue, 1 Nov 2011, Erik Faye-Lund wrote:
> On Tue, Nov 1, 2011 at 7:40 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > Maybe if someone donates Jenkins resources, we could make an automatic
> > branch in the future that has git.sln in it (similar to the 'html'
> > branch in git.git).
>
> CloudBees seems to have some kind of a free Jenkins service. Perhaps
> it's sufficient? http://www.cloudbees.com/dev-pricing.cb
Looks quite cool, but keep in mind: they only have Linux build machines.
We'd need to pimp up our cross-platform compiling capabilities; WINE will
most likely not be good enough (we'd only have 2000 minutes per month).
Ciao,
Dscho
^ permalink raw reply
* Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC
From: Johannes Schindelin @ 2011-11-01 22:40 UTC (permalink / raw)
To: Vincent van Ravesteijn
Cc: ramsay, msysgit, Karsten Blees, git, Junio C Hamano,
Erik Faye-Lund
In-Reply-To: <CAAH6HY8WfOQQ4g54y7mriq6BKoJCWYsVPrQUTMndqpKdniLAtw@mail.gmail.com>
Hi,
On Tue, 1 Nov 2011, Vincent van Ravesteijn wrote:
> > Maybe if someone donates Jenkins resources, we could make an automatic
> > branch in the future that has git.sln in it (similar to the 'html'
> > branch in git.git).
>
> As long as this means to just run a not so complicated perl script, this
> Could even be done in a commit hook.
I actually was thinking about something automatic which does not require
any of the busy msysGit developers to do something manual every once in a
while.
> Just another question. How does the (msys)git community feel about
> adding CMake support ? I can probably do that quite easily.
There was somebody who strongly favored CMake over any other solution but
was not willing to maintain it in the long run (also, I have to admit that
I have had quite a few problems with CMake, but maybe I am just pampered
by projects that Just Compile...)
Ciao,
Johannes
^ 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