* Re: git-rebase skips automatically no more needed commits
From: Junio C Hamano @ 2011-09-07 16:29 UTC (permalink / raw)
To: Francis Moreau; +Cc: Michael J Gruber, git
In-Reply-To: <CAC9WiBi_bkLNJZckq2fr3eb6ie+KVfauE_PyA3GcaW5Ga-isFw@mail.gmail.com>
Francis Moreau <francis.moro@gmail.com> writes:
> If I start the rebase process with : "git rebase -i -p master foo"
> then the filtering is happening. Here 'foo' has been created with
> v2.6.39 tag as start point and contains some patches cherry-picked
> from the upstream.
>
> However if I call git-rebase this way: "git rebase -i -p --onto master
> v2.6.39 foo", then it seems that no filtering is done.
>
> Is that expected ?
Because "rebase --onto A B C" has to be usable when commit A does not have
any ancestry relationship with the history between B and C, I wouldn't be
surprised if the command does not look at commits on the history that lead
to A that _might_ be related to the ones between B and C. It does not know
how far to dig from A and stop, and obviously you do not want to dig down
to the beginning of the history. "rebase A B" on the other hand can safely
stop digging the history back from A down to where the history leading to
B forked (i.e. merge base between A and B).
I do not know if "expected" is the right adjective; understandable---yes,
unsurprised---yes, justifiable--- I dunno.
^ permalink raw reply
* Re: The imporantance of including http credential caching in 1.7.7
From: Michael J Gruber @ 2011-09-07 12:56 UTC (permalink / raw)
To: Kyle Neath; +Cc: git
In-Reply-To: <CAFcyEthzW1AY4uXgpsVxjyWCDXAJ6=GdWGqLFO6Acm1ovJJVaw@mail.gmail.com>
Kyle Neath venit, vidit, dixit 07.09.2011 07:33:
> Earlier today, Scott Chacon alerted me to this email thread:
> http://www.spinics.net/lists/git/msg164192.html (many apologies to the list, I
> am not sure how to properly reference this email or reply to it since I have
> not been subscribed until today).
>
>> * jk/http-auth-keyring (2011-08-03) 13 commits
>> (merged to 'next' on 2011-08-03 at b06e80e)
>> + credentials: add "getpass" helper
>> + credentials: add "store" helper
>> + credentials: add "cache" helper
>> + docs: end-user documentation for the credential subsystem
>> + http: use hostname in credential description
>> + allow the user to configure credential helpers
>> + look for credentials in config before prompting
>> + http: use credential API to get passwords
>> + introduce credentials API
>> + http: retry authentication failures for all http requests
>> + remote-curl: don't retry auth failures with dumb protocol
>> + improve httpd auth tests
>> + url: decode buffers that are not NUL-terminated
>>
>> Looked mostly reasonable except for the limitation that it is not clear
>> how to deal with a site at which a user needs to use different passwords
>> for different repositories. Will keep it in "next" at least for one cycle,
>> until we start hearing real-world success reports on the list.
>>
>> Not urgent; will not be in 1.7.7.
>
> This is very disheartening to hear. Of all the minor changes, bugs, and
> potential features, I believe that http credential caching is the absolute
> most important thing that git core can do to promote adoption. I've believed
> this for more than a year now and I'm incredibly disappointed that it's being
> shelved for yet another release.
>
> Over the past two years as a designer for GitHub, I've answered ~thousands of
> support requests and talked face to face with ~thousands of developers of
> varying git skill levels. Once a month our company does online git training
> for newbies - https://github.com/training/online and I've had many discussions
> about newcomer's struggles with Matthew McCullough and Scott Chacon.
> Previously, I worked at ENTP where I helped polish the very popular "Git for
> Designers" guide http://hoth.entp.com/output/git_for_designers.html based on
> feedback. I was also lead designer for GitHub for Mac - an OSX GUI aimed at
> people less familiar with the command line.
So, it's been a year or more that you've been aware of the importance of
this issue (from your/github's perspective), and we hear about it now,
at the end of the rc phase. I don't know whether jk/http-auth-keyring
has been done on github payroll or during spare time. But as you can
see, all that is missing is real-world success reports, along with the
single-user-multiple-passwords issue which is probably answered best
from the real-world perspective (how common is it, do we even need to
address it now). So, given the importance this has for you and the
company, you sure can help out with what is still left to do, can you?
But note that the credential api is only as good a solution as the
helpers. Do we really want all users to employ credential-store because
it is "much simpler than ssh"? Deploying what we have now and advocating
it as a solution for the ssh-challenged (which will happen whether we,
you or someone else advocates it) could easily mean telling people to
store their credentials unencrypted. The slash-dot story will be "git
security hole", "git stores passwords unencrypted" and so on. And I
don't care as much about the PR as about the users whom we'd be serving
badly.
So, for the ssh-challenged, we really should make sure that secure
helpers are in their hand when the credential api hits a released
version (or revert the insecure store helper). There's a KDE attempt on
the list. Gnome, Win, Mac helpers anyone? Win version of the cache helper?
Michael
^ permalink raw reply
* Re: Issue fetching tags error: unable to find eb03b... ; git fsck shows no problem...
From: James Blackburn @ 2011-09-07 16:30 UTC (permalink / raw)
To: git
In-Reply-To: <CACyv8dcTi0pG_GPvxD1zoTf6iRG81KbaY43FA-pbxYJz2UVJcQ@mail.gmail.com>
I can get the fetch to work, by removing refs/original in the source repo:
bash:jamesb:xl-cbga-20:32942> git fetch --tags old
remote: Counting objects: 35469, done.
remote: Compressing objects: 100% (11562/11562), done.
remote: Total 33792 (delta 18883), reused 30509 (delta 16197)
Receiving objects: 100% (33792/33792), 28.10 MiB | 8.28 MiB/s, done.
Resolving deltas: 100% (18883/18883), completed with 443 local objects.
error: unable to find eb03ba0f40fb2b6a3287036d851d2506e4ea4f8f
fatal: object eb03ba0f40fb2b6a3287036d851d2506e4ea4f8f not found
bash:jamesb:xl-cbga-20:32943> rm -rf ../old_tagsX/.git/refs/original/
bash:jamesb:xl-cbga-20:32944> git fetch --tags old
remote: Counting objects: 1404, done.
remote: Compressing objects: 100% (570/570), done.
remote: Total 1014 (delta 480), reused 659 (delta 233)
Receiving objects: 100% (1014/1014), 1.66 MiB, done.
Resolving deltas: 100% (480/480), completed with 195 local objects.
From ../old_tagsX
* [new tag] 3.2.0-5 -> 3.2.0-5
...
bash:jamesb:xl-cbga-20:32945> git show eb03ba0f40fb2b6a3287036d851d2506e4ea4f8f
commit eb03ba0f40fb2b6a3287036d851d2506e4ea4f8f
Author: (no author) <(no author)@e3bda1c8-b8c7-484d-b8f9-8c0514bc73ff>
Date: Tue Oct 10 09:44:47 2006 +0000
This commit was manufactured by cvs2svn to create tag 'releases/3_2_0-5'.
...
Note that the object was present all along!
(In old_repo I had done: git filter-branch --prune-empty -- --all)
I have a backup of the repo, and this is repeatable for me, is there
an odd interaction between fetch and refs/original?
Cheers,
James
On 7 September 2011 17:14, James Blackburn <jamesblackburn@gmail.com> wrote:
> Hi All,
>
> I've got an error I can't seem to resolve. Fsck reports both my
> repositories are OK, but git fetch --tags tells me it can't find an
> object.
>
> bash:jamesb:xl-cbga-20:32867> git --version
> git version 1.7.6
> bash:jamesb:xl-cbga-20:32864> git remote add old_tags ../old_tags/
> bash:jamesb:xl-cbga-20:32865> git fetch old_tags
> From ../old_tags
> * [new branch] master -> old_tags/master
> ...
> bash:jamesb:xl-cbga-20:32866> git fetch --tags old_tags
> remote: Counting objects: 33613, done.
> remote: Compressing objects: 100% (11778/11778), done.
> remote: Total 33529 (delta 18473), reused 30013 (delta 15779)
> Receiving objects: 100% (33529/33529), 28.59 MiB | 8.06 MiB/s, done.
> Resolving deltas: 100% (18473/18473), completed with 17 local objects.
> error: unable to find eb03ba0f40fb2b6a3287036d851d2506e4ea4f8f
> fatal: object eb03ba0f40fb2b6a3287036d851d2506e4ea4f8f not found
>
> git fsck --full shows no errors in old_tags.
> git show eb03ba0f40fb2b6a3287036d851d2506e4ea4f8f in old_tags seems to work:
>
> commit eb03ba0f40fb2b6a3287036d851d2506e4ea4f8f
> Author: (no author) <(no author)@e3bda1c8-b8c7-484d-b8f9-8c0514bc73ff>
> Date: Tue Oct 10 09:44:47 2006 +0000
>
> This commit was manufactured by cvs2svn to create tag 'releases/3_2_0-5'.
>
> git-svn-id: svn://eng-cbga-2/tools/eclipse/tags/releases/3_2_0-5@39
> e3bda1c8-b8c7-484d-b8f9-8c0514bc73ff
>
> diff --git a/org.eclipse.cdt/org.eclipse.cdt.doc.isv/reference/api/allclasses-frame.html
> b/org.eclipse.cdt/org.eclipse.cdt.doc.isv/reference/api/
> allclasses-frame.html
> ...
>
>
> Any ideas how to resolve this?
>
> Cheers,
> James
>
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.6.2
From: Junio C Hamano @ 2011-09-07 11:22 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git List
In-Reply-To: <CAGdFq_gF8Uz_JTEUfb46kVii=Y0CwzCpOp5H81+HT8y=1PPUTQ@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> That's interesting, how did revert a merge commit?
Does "git revert --help" lack the description?
^ permalink raw reply
* Re: The imporantance of including http credential caching in 1.7.7
From: Junio C Hamano @ 2011-09-07 11:21 UTC (permalink / raw)
To: Kyle Neath; +Cc: git
In-Reply-To: <CAFcyEthzW1AY4uXgpsVxjyWCDXAJ6=GdWGqLFO6Acm1ovJJVaw@mail.gmail.com>
Kyle Neath <kneath@gmail.com> writes:
>> * jk/http-auth-keyring (2011-08-03) 13 commits
>> ...
>>
>> Looked mostly reasonable except for the limitation that it is not clear
>> how to deal with a site at which a user needs to use different passwords
>> for different repositories. Will keep it in "next" at least for one cycle,
>> until we start hearing real-world success reports on the list.
>>
>> Not urgent; will not be in 1.7.7.
>
> This is very disheartening to hear. Of all the minor changes, bugs, and
> potential features, I believe that http credential caching is the absolute
> most important thing that git core can do to promote adoption. I've believed
> this for more than a year now and I'm incredibly disappointed that it's being
> shelved for yet another release.
You are misreading the message utterly wrong that it is not even funny.
If this were a new, insignificant, and obscure feature in a piece of
software with mere 20k users, it may be OK to release a new version with
the feature in an uncooked shape. The feature may turn out to work only in
a very limited scope but not general enough to accomodate other needs you
did not anticipate, and your next version may have to fix it in a backward
incompatible way, forcing existing users to unlearn what the initial
uncooked design and implementation gave them, but by definition such an
insignificant and obscure new feature in a system with a small userbase
wouldn't have been used by too many people by the time you have to fix it,
and the extent of the damage is limited.
Git is not that piece of software with only 20k users, and a lot more
importantly, credential caching API is not a feature in an insignificant
and obscure corner of the user experience. We have to have at least a warm
fuzzy feeling that the API is right from the start so the plug-ins people
write for our initial version and the data its users will accumulate with
it will not go to waste by hastily releasing a version with an uncooked
design and implementation.
"Not urgent" is not "Not important". Quite the contrary, it is important
enough that we cannot afford to be hasty.
See http://thread.gmane.org/gmane.comp.version-control.git/180245 for an
example of how a discussion can be done to help us get closer to the warm
fuzzy feeling of getting the API right in a more mature manner. Don't feel
too bad if you become ashamed of the rant you wrote contrasting with that
exchange. It is a sign that you are learning.
> Then again, perhaps the fact that we spent development time hacking around
> git's limitation is a data point in itself. Git GUI developers are spending
> development time to fill a hole in git core.
Welcome to open source. Do not expect others to scratch every itch of your
niche. Think of it as an opportunity granted to you to make a difference,
not as a roadblock somebody else threw at you because they hate you.
Be thankful, not whiny.
Be good.
Have fun.
^ permalink raw reply
* Issue fetching tags error: unable to find eb03b... ; git fsck shows no problem...
From: James Blackburn @ 2011-09-07 16:14 UTC (permalink / raw)
To: git
Hi All,
I've got an error I can't seem to resolve. Fsck reports both my
repositories are OK, but git fetch --tags tells me it can't find an
object.
bash:jamesb:xl-cbga-20:32867> git --version
git version 1.7.6
bash:jamesb:xl-cbga-20:32864> git remote add old_tags ../old_tags/
bash:jamesb:xl-cbga-20:32865> git fetch old_tags
From ../old_tags
* [new branch] master -> old_tags/master
...
bash:jamesb:xl-cbga-20:32866> git fetch --tags old_tags
remote: Counting objects: 33613, done.
remote: Compressing objects: 100% (11778/11778), done.
remote: Total 33529 (delta 18473), reused 30013 (delta 15779)
Receiving objects: 100% (33529/33529), 28.59 MiB | 8.06 MiB/s, done.
Resolving deltas: 100% (18473/18473), completed with 17 local objects.
error: unable to find eb03ba0f40fb2b6a3287036d851d2506e4ea4f8f
fatal: object eb03ba0f40fb2b6a3287036d851d2506e4ea4f8f not found
git fsck --full shows no errors in old_tags.
git show eb03ba0f40fb2b6a3287036d851d2506e4ea4f8f in old_tags seems to work:
commit eb03ba0f40fb2b6a3287036d851d2506e4ea4f8f
Author: (no author) <(no author)@e3bda1c8-b8c7-484d-b8f9-8c0514bc73ff>
Date: Tue Oct 10 09:44:47 2006 +0000
This commit was manufactured by cvs2svn to create tag 'releases/3_2_0-5'.
git-svn-id: svn://eng-cbga-2/tools/eclipse/tags/releases/3_2_0-5@39
e3bda1c8-b8c7-484d-b8f9-8c0514bc73ff
diff --git a/org.eclipse.cdt/org.eclipse.cdt.doc.isv/reference/api/allclasses-frame.html
b/org.eclipse.cdt/org.eclipse.cdt.doc.isv/reference/api/
allclasses-frame.html
...
Any ideas how to resolve this?
Cheers,
James
^ permalink raw reply
* [RFC/PATCH] core.clientTimeout config for git:// fetches
From: Eric Wong @ 2011-09-07 10:15 UTC (permalink / raw)
To: git
This allows "git fetch" to exit after a preconfigured socket
timeout. This is needed in case an undetected server or network
failure occurs.
The default timeout is 60 seconds.
http:// and rsync:// transports should be supported in future
changes, too.
So far, I've only tested (by hand) with a dummy server setup
using "nc -l $some_port".
---
I run "git fetch" from cron to keep mirrors up-to-date. I've
noticed some cron processes running for hours/days at a time after
network failures. When I straced thoses processes, I saw they were
stuck on read() syscalls to remote machines.
I'm not familiar with this code and hope there's a better way to do
this. Changing wrapper.c like this in this way doesn't feel right,
but neither does sprinkling alarm() calls in various places.
Using a custom GIT_PROXY_COMMAND which implements timeouts on its own
would also work, but I'd like to eventually have a consistent parameter
unified across all remote transports for consistency and ease-of-use.
The default 60s timeout could be too low on some slow servers
with big repos, maybe the default should remain zero (no timeout).
connect.c | 27 +++++++++++++++++++++++++++
wrapper.c | 47 +++++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 72 insertions(+), 2 deletions(-)
diff --git a/connect.c b/connect.c
index ee1d4b4..c1fa1ab 100644
--- a/connect.c
+++ b/connect.c
@@ -320,10 +320,37 @@ static int git_tcp_connect_sock(char *host, int flags)
#endif /* NO_IPV6 */
+static int timeout_setup(const char *var, const char *value, void *cb)
+{
+ int *timeout = cb;
+
+ if (strcmp(var, "core.clienttimeout") == 0)
+ *timeout = git_config_int(var, value);
+
+ return 0;
+}
static void git_tcp_connect(int fd[2], char *host, int flags)
{
int sockfd = git_tcp_connect_sock(host, flags);
+ struct timeval tv;
+ int timeout = 60;
+
+ git_config(timeout_setup, &timeout);
+
+ if (timeout > 0) {
+ socklen_t len = sizeof(struct timeval);
+
+ tv.tv_sec = timeout;
+ tv.tv_usec = 0;
+ if (setsockopt(sockfd, SOL_SOCKET, SO_RCVTIMEO, &tv, len) < 0)
+ die_errno("could not set socket receive timeout");
+
+ tv.tv_sec = timeout;
+ tv.tv_usec = 0;
+ if (setsockopt(sockfd, SOL_SOCKET, SO_SNDTIMEO, &tv, len) < 0)
+ die_errno("could not set socket send timeout");
+ }
fd[0] = sockfd;
fd[1] = dup(sockfd);
diff --git a/wrapper.c b/wrapper.c
index 85f09df..09a31c6 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -109,6 +109,49 @@ void *xcalloc(size_t nmemb, size_t size)
return ret;
}
+static int io_continuable(int fd, int optname)
+{
+ if (errno == EINTR)
+ return 1;
+
+ /*
+ * If fd is a socket, a socket-level timeout could've been
+ * set in git_tcp_connect(). Unfortunately EAGAIN alone
+ * isn't enough to tell us if the timeout is user-specified
+ * or not, so we have to try to figure it out.
+ */
+ if (errno == EAGAIN) {
+ socklen_t len = sizeof(struct timeval);
+ struct timeval tv;
+ int flags;
+
+ /*
+ * Let any non-blocking I/O users through. Currently
+ * git does not explicitly use non-blocking I/O anywhere,
+ * but it could inherit a non-blocking descriptor. We
+ * rely on the fact that (currently) no sockets git itself
+ * creates (and thus may set timeout on) also sets O_NONBLOCK.
+ */
+ flags = fcntl(fd, F_GETFL);
+ if (flags < 0)
+ die_errno("fcntl failed to get file status flags");
+ if (flags & O_NONBLOCK)
+ return 1;
+
+ if (getsockopt(fd, SOL_SOCKET, optname, &tv, &len) < 0) {
+ if (errno == ENOTSOCK)
+ return 1;
+ die_errno("getsockopt failed to get socket option");
+ }
+ if (tv.tv_sec > 0 || tv.tv_usec > 0)
+ die("socket timed out");
+
+ return 1;
+ }
+
+ return 0;
+}
+
/*
* xread() is the same a read(), but it automatically restarts read()
* operations with a recoverable error (EAGAIN and EINTR). xread()
@@ -119,7 +162,7 @@ ssize_t xread(int fd, void *buf, size_t len)
ssize_t nr;
while (1) {
nr = read(fd, buf, len);
- if ((nr < 0) && (errno == EAGAIN || errno == EINTR))
+ if (nr < 0 && io_continuable(fd, SO_RCVTIMEO))
continue;
return nr;
}
@@ -135,7 +178,7 @@ ssize_t xwrite(int fd, const void *buf, size_t len)
ssize_t nr;
while (1) {
nr = write(fd, buf, len);
- if ((nr < 0) && (errno == EAGAIN || errno == EINTR))
+ if (nr < 0 && io_continuable(fd, SO_SNDTIMEO))
continue;
return nr;
}
--
Eric Wong
^ permalink raw reply related
* Git without morning coffee
From: Michael J Gruber @ 2011-09-07 7:48 UTC (permalink / raw)
To: Git Mailing List
Is this my lack of morning coffee, or git's:
git rev-parse origin/next origin/pu
7931f38a2fd882b0f75a4d6f0eb60c3b1b094178
edf014b39ded8ee8a67f2a0cd8d7926b33f3d578
# OK
git checkout origin/next
HEAD is now at 7931f38... Merge branch 'master' into next
# OK
git log --oneline --no-walk ":/Merge branch 'jk/generation-numbers' into pu"
0ac76f9 Merge branch 'jk/generation-numbers' into pu
# Sure it is.
git merge ":/Merge branch 'jk/generation-numbers' into pu"
fatal: ':/Merge branch 'jk/generation-numbers' into pu' does not point
to a commit
# Huh?
git rev-parse ":/Merge branch 'jk/generation-numbers' into pu"
0ac76f96a94a46bce7ec9dcc6c67abcf9d36adac
# It does point to a commit!
git merge $(git rev-parse ":/Merge branch 'jk/generation-numbers' into pu")
error: addinfo_cache failed for path 't/t7810-grep.sh'
Performing inexact rename detection: 100% (91476/91476), done.
error: addinfo_cache failed for path 't/t7810-grep.sh'
error: addinfo_cache failed for path 'gitweb/static/gitweb.js'
error: addinfo_cache failed for path 'gitweb/static/gitweb.css'
## hundreds more
error: addinfo_cache failed for path 't/t7810-grep.sh'
error: addinfo_cache failed for path 'gitweb/static/js/blame_incremental.js'
Auto-merging cache.h
Merge made by the 'recursive' strategy.
Double Huh? Finally, the merge succeeds, despite thy myriad of errors.
I mean, I'm merging a commit from origin/pu to origin/next when the
latter is basically contained in the former (except for some merge
commits). And what are these addinfo_cache errors?
git --version
git version 1.7.7.rc0.328.g9d6c7
which is last week's next with a few additions which I've been carrying
along for weeks. Stumped.
Michael
^ permalink raw reply
* Re: [BUG] git bisect start fails when stale bisect data is left behind
From: Junio C Hamano @ 2011-09-07 10:51 UTC (permalink / raw)
To: Joel Kaasinen; +Cc: Christian Couder, git
In-Reply-To: <CAC6WLetO-KKkHmPHJ64rt6+BMbhUHUtNfxF3GK4obMUAuE9XXQ@mail.gmail.com>
Joel Kaasinen <joel@zenrobotics.com> writes:
> On Tue, Sep 6, 2011 at 19:38, Junio C Hamano <gitster@pobox.com> wrote:
>> I do not necessarily think this is a bug to begin with --- the user had a
>> bad state, and bisect stopped without doing further damage.
>
> Oh, actually my git-bisect man page says:
>
> """
> Bisect reset
> After a bisect session, to clean up the bisection state and return to
> the original HEAD, issue the following command:
>
> $ git bisect reset
>
> By default, this will return your tree to the commit that was checked
> out before git bisect start. (A new git bisect start will also do that,
> as it cleans up the old bisection state.)
> """
>
> The parenthetical sentence seems to imply that a bisect start cleans
> out the old state. The problem is that the cleaning fails when the
> state is bad. (Try e.g. "git bisect start; git bisect start a b" where
> a and b are valid refs.)
>
> It's pretty much the same to me how this gets resolved. I'm fine with
> a more verbose error message from bisect start.
I do not think anybody minds "a more verbose" message. I do mind if the
suggestion the message makes were "wrong". That is what I was questioning.
^ permalink raw reply
* Re: [PATCH v17 1/7] bisect: move argument parsing before state modification.
From: Junio C Hamano @ 2011-09-07 11:29 UTC (permalink / raw)
To: Christian Couder; +Cc: Jon Seymour, git, j6t, jnareb, jrnieder
In-Reply-To: <201109070816.16655.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> If we start bisecting like this:
>
> $ git bisect start HEAD HEAD~20
>
> and then we decide that it was not optimum and we want to start again like
> this:
>
> $ git bisect start HEAD HEAD~6
>
> then issuing the latter command might not work as it did before this patch.
I didn't even know the above was supposed to work. It may have worked, but
I think it was not by design but merely by accident. Besides, wouldn't it
be the same to say "git bisect good" to further limit the suspect range,
instead of giving the second, seemingly nested, "bisect start" that is not
really nesting, which only confuses the users?
Having said that, if you can resurrect the old behaviour without too much
code churn, I wouldn't mind to look at the patch, but I am not sure if it
is worth it.
^ permalink raw reply
* Re: [BUG] git bisect start fails when stale bisect data is left behind
From: Joel Kaasinen @ 2011-09-07 6:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Couder, git
In-Reply-To: <7vehztaan4.fsf@alter.siamese.dyndns.org>
On Tue, Sep 6, 2011 at 19:38, Junio C Hamano <gitster@pobox.com> wrote:
> I do not necessarily think this is a bug to begin with --- the user had a
> bad state, and bisect stopped without doing further damage.
Oh, actually my git-bisect man page says:
"""
Bisect reset
After a bisect session, to clean up the bisection state and return to
the original HEAD, issue the following command:
$ git bisect reset
By default, this will return your tree to the commit that was checked
out before git bisect start. (A new git bisect start will also do that,
as it cleans up the old bisection state.)
"""
The parenthetical sentence seems to imply that a bisect start cleans
out the old state. The problem is that the cleaning fails when the
state is bad. (Try e.g. "git bisect start; git bisect start a b" where
a and b are valid refs.)
It's pretty much the same to me how this gets resolved. I'm fine with
a more verbose error message from bisect start.
–J
^ permalink raw reply
* Re: [PATCH v17 1/7] bisect: move argument parsing before state modification.
From: Christian Couder @ 2011-09-07 6:16 UTC (permalink / raw)
To: Jon Seymour; +Cc: git, gitster, j6t, jnareb, jrnieder
In-Reply-To: <1312459263-16911-2-git-send-email-jon.seymour@gmail.com>
Hi,
On Thursday 04 August 2011 14:00:57 Jon Seymour wrote:
> Currently 'git bisect start' modifies some state prior to checking
> that its arguments are valid.
>
> This change moves argument validation before state modification
> with the effect that state modification does not occur
> unless argument validations succeeds.
This thread:
http://thread.gmane.org/gmane.comp.version-control.git/180733/
made me wonder if we introduced a bug with this patch.
If we start bisecting like this:
$ git bisect start HEAD HEAD~20
and then we decide that it was not optimum and we want to start again like
this:
$ git bisect start HEAD HEAD~6
then issuing the latter command might not work as it did before this patch.
Before this patch the latter command would do a "git checkout $start_head"
before the repeated rev=$(git rev-parse -q --verify "$arg^{commit}") to
convert arguments into sha1. And after this patch the order is reversed.
This means that before this patch "HEAD" in the arguments to "git bisect
start" would refer to $start_head because the "git checkout $start_head"
changes HEAD. After this patch "HEAD" in the arguments to "git bisect start"
would refer to the current HEAD.
For example before this patch, if I issue "git bisect start HEAD HEAD~8" twice
I get:
$ git bisect start HEAD HEAD~8
Bisecting: 15 revisions left to test after this (roughly 4 steps)
[67c116bb26b4ee31889e5ee15d6a9d3b7e972b7b] Merge branch 'jk/pager-with-
external-command'
$ git bisect start HEAD HEAD~8
Previous HEAD position was 67c116b... Merge branch 'jk/pager-with-external-
command'
Switched to branch 'master'
Bisecting: 15 revisions left to test after this (roughly 4 steps)
[67c116bb26b4ee31889e5ee15d6a9d3b7e972b7b] Merge branch 'jk/pager-with-
external-command'
so the same commit to test is checked out.
After this patch I get:
$ git bisect start HEAD HEAD~8
Bisecting: 15 revisions left to test after this (roughly 4 steps)
[67c116bb26b4ee31889e5ee15d6a9d3b7e972b7b] Merge branch 'jk/pager-with-
external-command'
$ git bisect start HEAD HEAD~8
Previous HEAD position was 67c116b... Merge branch 'jk/pager-with-external-
command'
Switched to branch 'master'
Bisecting: 15 revisions left to test after this (roughly 4 steps)
[e5cfcb04e0acc5f3b51e6d69487028315b33e4c9] Merge branch 'mh/attr'
so a different commit is checked out after the second "git bisect start HEAD
HEAD~8".
Best regards,
Christian.
^ permalink raw reply
* [PATCH v2] date.c: Support iso8601 timezone formats
From: Haitao Li @ 2011-09-07 5:46 UTC (permalink / raw)
To: git, Jeff King; +Cc: Haitao Li
In-Reply-To: <1315320996-1997-1-git-send-email-lihaitao@gmail.com>
Timezone designators including additional separator (`:`) are ignored.
Actually zone designators in below formats are all valid according to
ISO8601:2004, section 4.3.2:
[+-]hh, [+-]hhmm, [+-]hh:mm
Steps to reproduce the issue this patch fixes:
$ mkdir /tmp/test
$ cd /tmp/test
$ git init
$ echo 'timezone' > file.txt
$ git add .
$ git update-index
$ git write-tree
3e168d57e1c32a4598af134430384f0587581503
# Commit the tree returned above. Give a date with colon separated
# timezone
$ echo "Test commit" | \
TZ=UTC GIT_AUTHOR_DATE='2011-09-03T12:34:56+08:00' \
git commit-tree 3e168d57e1c32a4598af134430384f0587581503 | \
xargs git show | grep Date
Date: Sat Sep 3 12:34:56 2011 +0000
while the expected result is:
Date: Sat Sep 3 12:34:56 2011 +0800
^---
This patch teaches git recognizing zone designators with hours and
minutes separated by colon, or minutes are empty.
Signed-off-by: Haitao Li <lihaitao@gmail.com>
---
date.c | 32 ++++++++++++++++++++++++++------
t/t0006-date.sh | 5 +++++
2 files changed, 31 insertions(+), 6 deletions(-)
diff --git a/date.c b/date.c
index 896fbb4..f970ea8 100644
--- a/date.c
+++ b/date.c
@@ -556,15 +556,35 @@ static int match_tz(const char *date, int *offp)
int min, hour;
int n = end - date - 1;
- min = offset % 100;
- hour = offset / 100;
+ /*
+ * ISO8601:2004(E) allows time zone designator been separated
+ * by a clone in the extended format
+ */
+ if (*end == ':') {
+ if (isdigit(end[1])) {
+ hour = offset;
+ min = strtoul(end+1, &end, 10);
+ } else {
+ /* Mark as invalid */
+ n = -1;
+ }
+ } else {
+ /* Only hours specified */
+ if (n == 1 || n == 2) {
+ hour = offset;
+ min = 0;
+ } else {
+ hour = offset / 100;
+ min = offset % 100;
+ }
+ }
/*
- * Don't accept any random crap.. At least 3 digits, and
- * a valid minute. We might want to check that the minutes
- * are divisible by 30 or something too.
+ * Don't accept any random crap.. We might want to check that
+ * the minutes are divisible by 15 or something too. (Offset of
+ * Kathmandu, Nepal is UTC+5:45)
*/
- if (min < 60 && n > 2) {
+ if (n > 0 && min < 60 && hour < 25) {
offset = hour*60+min;
if (*date == '-')
offset = -offset;
diff --git a/t/t0006-date.sh b/t/t0006-date.sh
index f87abb5..5235b7a 100755
--- a/t/t0006-date.sh
+++ b/t/t0006-date.sh
@@ -40,6 +40,11 @@ check_parse 2008-02 bad
check_parse 2008-02-14 bad
check_parse '2008-02-14 20:30:45' '2008-02-14 20:30:45 +0000'
check_parse '2008-02-14 20:30:45 -0500' '2008-02-14 20:30:45 -0500'
+check_parse '2008-02-14 20:30:45 -0015' '2008-02-14 20:30:45 -0015'
+check_parse '2008-02-14 20:30:45 -5' '2008-02-14 20:30:45 -0500'
+check_parse '2008-02-14 20:30:45 -05' '2008-02-14 20:30:45 -0500'
+check_parse '2008-02-14 20:30:45 -:30' '2008-02-14 20:30:45 +0000'
+check_parse '2008-02-14 20:30:45 -05:00' '2008-02-14 20:30:45 -0500'
check_parse '2008-02-14 20:30:45' '2008-02-14 20:30:45 -0500' EST5
check_approxidate() {
--
1.7.5.4
^ permalink raw reply related
* The imporantance of including http credential caching in 1.7.7
From: Kyle Neath @ 2011-09-07 5:33 UTC (permalink / raw)
To: git
Earlier today, Scott Chacon alerted me to this email thread:
http://www.spinics.net/lists/git/msg164192.html (many apologies to the list, I
am not sure how to properly reference this email or reply to it since I have
not been subscribed until today).
> * jk/http-auth-keyring (2011-08-03) 13 commits
> (merged to 'next' on 2011-08-03 at b06e80e)
> + credentials: add "getpass" helper
> + credentials: add "store" helper
> + credentials: add "cache" helper
> + docs: end-user documentation for the credential subsystem
> + http: use hostname in credential description
> + allow the user to configure credential helpers
> + look for credentials in config before prompting
> + http: use credential API to get passwords
> + introduce credentials API
> + http: retry authentication failures for all http requests
> + remote-curl: don't retry auth failures with dumb protocol
> + improve httpd auth tests
> + url: decode buffers that are not NUL-terminated
>
> Looked mostly reasonable except for the limitation that it is not clear
> how to deal with a site at which a user needs to use different passwords
> for different repositories. Will keep it in "next" at least for one cycle,
> until we start hearing real-world success reports on the list.
>
> Not urgent; will not be in 1.7.7.
This is very disheartening to hear. Of all the minor changes, bugs, and
potential features, I believe that http credential caching is the absolute
most important thing that git core can do to promote adoption. I've believed
this for more than a year now and I'm incredibly disappointed that it's being
shelved for yet another release.
Over the past two years as a designer for GitHub, I've answered ~thousands of
support requests and talked face to face with ~thousands of developers of
varying git skill levels. Once a month our company does online git training
for newbies - https://github.com/training/online and I've had many discussions
about newcomer's struggles with Matthew McCullough and Scott Chacon.
Previously, I worked at ENTP where I helped polish the very popular "Git for
Designers" guide http://hoth.entp.com/output/git_for_designers.html based on
feedback. I was also lead designer for GitHub for Mac - an OSX GUI aimed at
people less familiar with the command line.
I bring all of this up because I'd like to think I have a good handle on
common problems that git newcomers or people resisting git adoption run into.
I've been deeply involved in spreading git adoption full time for nearly 3
years - it's something that's incredibly important to me professionally and
personally. And the number one problem that *always* comes up is SSH key
complexity.
A lot of these problems surface themselves in people saying it's hard to setup
git on Windows. When I push these people to explain further, it turns out that
the problem is always setting up SSH key authentication on Windows, not
necessarily git.
It's incredibly frustrating that git's biggest roadblock has nothing to do
with version control at all, but rather network authentication. Just as I
believe only *you* can own your availability, I believe git should do it's
best to own authentication.
HTTP credential caching combined with Smart HTTP make git one hell of an
amazing tool for newcomers and experts alike. I like to envision a world in
which git with both these features shipped with the latest OSX install.
Developers, designers, or anyone with an inkling for code would have exactly
two steps to get started with any given git host:
1. Set your git config email / username
2. git clone https://example.com/repository
Contrast this to our current help page for OSX:
http://help.github.com/mac-set-up-git/ or worse yet, our Windows setup page
with all of it's yelling about what kind of SSH keys to setup:
http://help.github.com/win-set-up-git/
Please note that I am not arguing against the merits of SSH keys - for those
developers who understand them, they're fantastic. But the reality is the
great majority of people who interact with version control do not understand
them at all. This results in passwordless SSH keys, confusion, and
frustration.
If another git version comes and goes without http credential caching, I fear
we as a community have purposefully ignored the largest potential for git
adoption currently available. This is important enough for me that I believe
it would be in git's best interest to delay the release of 1.7.7 until this
feature has been patched to the core team's standards.
I'll summarize with a graph of my opinion of where git's potential for
adoption lies:
------------------------------------------------------------------------------
OPPORTUNITY FOR GIT ADOPTION ACCORDING TO KYLE NEATH
Caching of http credentials
|
[=====================================================================||=====]
|
Everything else in the universe
------------------------------------------------------------------------------
With hopes and butterflies,
Kyle Neath
Director of Design at GitHub
^ permalink raw reply
* Re: [BUG] git bisect start fails when stale bisect data is left behind
From: Christian Couder @ 2011-09-07 4:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Couder, Joel Kaasinen, git
In-Reply-To: <7vehztaan4.fsf@alter.siamese.dyndns.org>
On Tuesday 06 September 2011 18:38:55 Junio C Hamano wrote:
> Christian Couder <christian.couder@gmail.com> writes:
> >> How to reproduce:
> >> $ echo foo > .git/BISECT_START
> >> $ git bisect start HEAD HEAD^
> >>
> >> Fails with "fatal: invalid reference:" on git 1.7.6.
> >
> > Yeah, it looks like a very old behavior.
> > I'd suggest a simple improvement in the error message like this:
> >
> > diff --git a/git-bisect.sh b/git-bisect.sh
> > index c21e33c..bd7155b 100755
> > --- a/git-bisect.sh
> > +++ b/git-bisect.sh
> > @@ -67,7 +67,8 @@ bisect_start() {
> >
> > then
> >
> > # Reset to the rev from where we started.
> > start_head=$(cat "$GIT_DIR/BISECT_START")
> >
> > - git checkout "$start_head" -- || exit
> > + git checkout "$start_head" -- ||
> > + die "Could not checkout previous start point
> > '$start_head'. Try 'git bisect reset <branch>' first."
>
> I do not necessarily think this is a bug to begin with --- the user had a
> bad state, and bisect stopped without doing further damage.
Yeah, in fact commit f3a186ffade15f793ea17713a10e10ec4f26ff11 (bisect: improve
error message when branch checkout fails, Sat Apr 4, 2009) already improved
the error message, but probably didn't go far enough.
> The real question is what the sensible suggestion/advice the new message
> should give. It would have to involve bisect reset in the end to get rid
> of the stale bisect state, but wouldn't the user potentially lose some
> other state if s/he blindly followed the die message's suggestion and ran
> "bisect reset"?
When using "git bisect start" with an existing $GIT_DIR/BISECT_START file, the
next thing we do after checking out the previous head from the BISECT_START
file is a call to "bisect_clean_state". So all the previous bisect state is
discarded except the previous head that is in $start_head.
If checking out the previous head fails, that probably means that the previous
head is bad because it has been deleted.
In this case running "git bisect reset <branch>" and then "git bisect start
..." is ok because there is no valuable state lost compared to the situation
where "git bisect start ..." succeeded in the first place.
Of course if checking out the previous head failed because the
$GIT_DIR/BISECT_START file has been corrupted, then it might be better to fix
the content of this file. But anyway if we are able to fix the content of the
file, for example by putting "foobar" in it instead of the truncated "foo" that
made the checkout fail, then running "git bisect reset foobar" and then "git
bisect start ..." would probably do the trick too.
It wouldn't do the trick if the $GIT_DIR/BISECT_START file also needed a
permission change or more free space on the disc or something like that. But
in this case we will get an hopefully meaningful error message when running
"git bisect reset foobar" or "git bisect start ..." and we would not lose
information.
Thanks,
Christian.
^ permalink raw reply
* Re: [BUG] git-svn: --no-metadata related bug
From: Eric Wong @ 2011-09-07 3:39 UTC (permalink / raw)
To: DaveAbrahams; +Cc: git
In-Reply-To: <1315033269582-6756044.post@n2.nabble.com>
DaveAbrahams <dave@boostpro.com> wrote:
> I am reproducing the problem here. Unfortunately I can't share the
> repository with you but I'm willing to try debugging it a bit.
Which version of git/git-svn are you using? (run: "git svn --version")
Can you reproduce it with newer versions? (I can't)
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] date.c: Parse timezone with colon as separator
From: Haitao Li @ 2011-09-07 3:00 UTC (permalink / raw)
To: Jeff King; +Cc: git, gitster
In-Reply-To: <20110906202440.GD14554@sigill.intra.peff.net>
> That seems like a sensible list to support, given that it is part of
> iso8601 (though I was a little surprised after reading your subject
> line, which would probably be better as "support iso8601 timezone
> formats").
I agree this is a better one! ;)
> We should probably have new tests, too. I was going to suggest squashing
> in the ones below, but your patch doesn't seem to work with the first
> one:
>
> diff --git a/t/t0006-date.sh b/t/t0006-date.sh
> index f87abb5..9b326cd 100755
> --- a/t/t0006-date.sh
> +++ b/t/t0006-date.sh
> @@ -40,6 +40,8 @@ check_parse 2008-02 bad
> check_parse 2008-02-14 bad
> check_parse '2008-02-14 20:30:45' '2008-02-14 20:30:45 +0000'
> check_parse '2008-02-14 20:30:45 -0500' '2008-02-14 20:30:45 -0500'
> +check_parse '2008-02-14 20:30:45 -05' '2008-02-14 20:30:45 -0500'
> +check_parse '2008-02-14 20:30:45 -05:00' '2008-02-14 20:30:45 -0500'
> check_parse '2008-02-14 20:30:45' '2008-02-14 20:30:45 -0500' EST5
>
> check_approxidate() {
>
> If I am reading your commit message correctly, that should work, right?
>
Yes, you are right. I will send an updated version to get this right.
Thank you for reviewing and giving suggestions!
/Haitao
^ permalink raw reply
* Re: Linux 3.1-rc5
From: Henrique de Moraes Holschuh @ 2011-09-07 1:37 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Linus Torvalds, Linux Kernel Mailing List, git
In-Reply-To: <4E65307F.5020103@redhat.com>
On Mon, 05 Sep 2011, Mauro Carvalho Chehab wrote:
> It would be great if "git remote update" could also verify the tag
> signature (if present), as most of us just do a "git remote update".
That helps, and it really should be all that matter for a power-end-user
that just wants to build his kernel from a git tree.
However, one can still try to trick someone to base the tree he's going to
use for a future pull request on a tree with a rogue commit, in order to
try to get the rogue commit into mainline through an indirect path, for
example.
Yeah, it is very obvious, and not a real major point of concern around
LKML: we all check the diff, log or shortlog between the tree we're
offering upstream to pull from) and the current upstream tree for any
stray commits after all (if only to avoid embarassing mistakes). And
upstream does his/her own checks before keeping the merged tree, and so
forth.
It's just that the security of the kernel source trees are not a simple
consequence of how git works: the workflow matters. I feel that point
deserves to be stressed every once in a while, however obvious it might
be.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply
* [ANNOUNCE] Git 1.7.6.2
From: Junio C Hamano @ 2011-09-06 23:46 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
I've tagged the latest maintenance release Git 1.7.6.2 but unfortunately
the tarballs are not available at the usual places. The release can be
fetched from any of the following repositories, at the tip of 'maint'
branch.
git://repo.or.cz/alt-git.git
https://github.com/gitster/git
https://code.google.com/p/git-core/
git://git.sourceforge.jp/gitroot/git-core/git.git
git://git-core.git.sourceforge.net/gitroot/git-core/git-core
This is primarily to fix "git push --quiet" breakage in 1.7.6.1.
----------------------------------------------------------------
Changes since v1.7.6.1 are as follows:
Junio C Hamano (3):
whitespace: have SP on both sides of an assignment "="
Revert "Merge branch 'cb/maint-quiet-push' into maint"
Git 1.7.6.2
Pang Yan Han (1):
update-ref: whitespace fix
Thomas Rast (1):
Documentation: clarify effects of -- <path> arguments
^ permalink raw reply
* What's cooking in git.git (Sep 2011, #02; Tue, 6)
From: Junio C Hamano @ 2011-09-06 23:43 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.
Some of the recent patches are fixes to new feature topics already merged
to "master" and are being fast tracked for 1.7.7-rc1, but otherwise
patches for new features and fixes to longstanding issues will stay in
'pu' or 'next' until the 1.7.7 final.
--------------------------------------------------
[Graduated to "master"]
* cb/maint-ls-files-error-report (2011-08-28) 1 commit
(merged to 'next' on 2011-08-30 at b606e19)
+ t3005: do not assume a particular order of stdout and stderr of git-ls-files
* mh/check-ref-format-print-normalize (2011-08-27) 2 commits
(merged to 'next' on 2011-08-30 at e827410)
+ Forbid DEL characters in reference names
+ check-ref-format --print: Normalize refnames that start with slashes
* rc/histogram-diff (2011-08-31) 1 commit
(merged to 'next' on 2011-09-02 at be4d245)
+ xdiff/xprepare: initialise xdlclassifier_t cf in xdl_prepare_env()
--------------------------------------------------
[New Topics]
* cb/common-prefix-unification (2011-09-06) 3 commits
- rename pathspec_prefix() to common_prefix() and move to dir.[ch]
- consolidate pathspec_prefix and common_prefix
- remove prefix argument from pathspec_prefix
* cb/maint-quiet-push (2011-09-05) 4 commits
. t5541: avoid TAP test miscounting
. push: old receive-pack does not understand --quiet
. fix push --quiet via http
. tests for push --quiet
Dropped for rerolling after 1.7.7 cycle.
* cb/send-email-help (2011-09-05) 1 commit
- send-email: add option -h
* jc/fetch-pack-fsck-objects (2011-09-04) 3 commits
- test: fetch/receive with fsckobjects
- transfer.fsckobjects: unify fetch/receive.fsckobjects
- fetch.fsckobjects: verify downloaded objects
* jc/receive-verify (2011-09-02) 3 commits
- receive-pack: check connectivity before concluding "git push"
- check_everything_connected(): libify
- check_everything_connected(): refactor to use an iterator
(this branch uses jc/fetch-verify, jc/fetch-verify and jc/traverse-commit-list.)
* tr/doc-note-rewrite (2011-09-05) 1 commit
- Documentation: "on for all" configuration of notes.rewriteRef
* jc/request-pull-show-head (2011-09-06) 1 commit
- State what commit to expect in request-pull
* jn/maint-http-error-message (2011-09-06) 2 commits
- http: avoid empty error messages for some curl errors
- http: remove extra newline in error message
--------------------------------------------------
[Stalled]
* jk/add-i-hunk-filter (2011-07-27) 5 commits
(merged to 'next' on 2011-08-11 at 8ff9a56)
+ add--interactive: add option to autosplit hunks
+ add--interactive: allow negatation of hunk filters
+ add--interactive: allow hunk filtering on command line
+ add--interactive: factor out regex error handling
+ add--interactive: refactor patch mode argument processing
Needs documentation updates, tests, and integration with the higher level
callers, e.g. "git add -p".
* jh/receive-count-limit (2011-05-23) 10 commits
- receive-pack: Allow server to refuse pushes with too many objects
- pack-objects: Estimate pack size; abort early if pack size limit is exceeded
- send-pack/receive-pack: Allow server to refuse pushing too large packs
- pack-objects: Allow --max-pack-size to be used together with --stdout
- send-pack/receive-pack: Allow server to refuse pushes with too many commits
- pack-objects: Teach new option --max-commit-count, limiting #commits in pack
- receive-pack: Prepare for addition of the new 'limit-*' family of capabilities
- Tighten rules for matching server capabilities in server_supports()
- send-pack: Attempt to retrieve remote status even if pack-objects fails
- Update technical docs to reflect side-band-64k capability in receive-pack
Would need another round to separate per-pack and per-session limits.
* jm/mergetool-pathspec (2011-06-22) 2 commits
- mergetool: Don't assume paths are unmerged
- mergetool: Add tests for filename with whitespace
I think this is a good idea, but it probably needs a re-roll.
Cf. $gmane/176254, 176255, 166256
* jk/generation-numbers (2011-07-14) 7 commits
- limit "contains" traversals based on commit generation
- check commit generation cache validity against grafts
- pretty: support %G to show the generation number of a commit
- commit: add commit_generation function
- add metadata-cache infrastructure
- decorate: allow storing values instead of pointers
- Merge branch 'jk/tag-contains-ab' (early part) into HEAD
The initial "tag --contains" de-pessimization without need for generation
numbers is already in; backburnered.
* sr/transport-helper-fix-rfc (2011-07-19) 2 commits
- t5800: point out that deleting branches does not work
- t5800: document inability to push new branch with old content
* po/cygwin-backslash (2011-08-05) 2 commits
- On Cygwin support both UNIX and DOS style path-names
- git-compat-util: add generic find_last_dir_sep that respects is_dir_sep
I think a further refactoring (no, not my suggestion) was offered?
--------------------------------------------------
[Cooking]
* bk/ancestry-path (2011-08-25) 3 commits
(merged to 'next' on 2011-09-02 at d05ba5d)
+ revision: do not include sibling history in --ancestry-path output
+ revision: keep track of the end-user input from the command line
+ rev-list: Demonstrate breakage with --ancestry-path --all
The topic came up a bit too late in the cycle.
Will cook for a while.
* mg/branch-list (2011-08-28) 5 commits
(merged to 'next' on 2011-09-02 at b818eae)
+ branch: allow pattern arguments
+ branch: introduce --list option
+ git-branch: introduce missing long forms for the options
+ git-tag: introduce long forms for the options
+ t6040: test branch -vv
Not urgent; the topic came up a bit too late in the cycle.
* mm/rebase-i-exec-edit (2011-08-26) 2 commits
(merged to 'next' on 2011-09-02 at e75b1b9)
+ rebase -i: notice and warn if "exec $cmd" modifies the index or the working tree
+ rebase -i: clean error message for --continue after failed exec
Not urgent; the topic came up a bit too late in the cycle.
* jk/default-attr (2011-08-26) 1 commit
- attr: map builtin userdiff drivers to well-known extensions
Not urgent; I fixed up the test breakage just for fun.
* hv/submodule-merge-search (2011-08-26) 4 commits
- submodule: Search for merges only at end of recursive merge
- allow multiple calls to submodule merge search for the same path
- submodule: Demonstrate known breakage during recursive merge
- push: Don't push a repository with unpushed submodules
(this branch uses fg/submodule-auto-push.)
Not urgent; the topic came up a bit too late in the cycle.
The bottom one needs to be replaced with a properly written commit log message.
* mm/mediawiki-as-a-remote (2011-09-01) 2 commits
- git-remote-mediawiki: allow push to set MediaWiki metadata
- Add a remote helper to interact with mediawiki (fetch & push)
Fun.
Not urgent; the topic came up a bit too late in the cycle.
* nd/maint-autofix-tag-in-head (2011-08-26) 3 commits
- Accept tags in HEAD or MERGE_HEAD
- merge: remove global variable head[]
- merge: keep stash[] a local variable
Probably needs a re-roll to aim a bit higher.
Not urgent; will not be in 1.7.7.
* bc/unstash-clean-crufts (2011-08-27) 4 commits
(merged to 'next' on 2011-09-02 at 7bfd66f)
+ git-stash: remove untracked/ignored directories when stashed
+ t/t3905: add missing '&&' linkage
+ git-stash.sh: fix typo in error message
+ t/t3905: use the name 'actual' for test output, swap arguments to test_cmp
Not urgent; the topic came up a bit too late in the cycle.
* da/make-auto-header-dependencies (2011-08-30) 1 commit
(merged to 'next' on 2011-09-02 at e04a4af)
+ Makefile: Improve compiler header dependency check
(this branch uses fk/make-auto-header-dependencies.)
Not urgent; will not be in 1.7.7.
* gb/am-hg-patch (2011-08-29) 1 commit
(merged to 'next' on 2011-09-02 at 3edfe4c)
+ am: preliminary support for hg patches
Not urgent; the topic came up a bit too late in the cycle.
* jc/diff-index-unpack (2011-08-29) 3 commits
(merged to 'next' on 2011-09-02 at 4206bd9)
+ diff-index: pass pathspec down to unpack-trees machinery
+ unpack-trees: allow pruning with pathspec
+ traverse_trees(): allow pruning with pathspec
Will cook for a while.
* jn/remote-helpers-doc (2011-09-01) 3 commits
- (short) documentation for the testgit remote helper
- Documentation/git-remote-helpers: explain how import works with multiple refs
- Documentation/remote-helpers: explain capabilities first
Not urgent.
* nm/grep-object-sha1-lock (2011-08-30) 1 commit
(merged to 'next' on 2011-09-02 at 336f57d)
+ grep: Fix race condition in delta_base_cache
Not urgent; the topic came up a bit too late in the cycle.
* tr/mergetool-valgrind (2011-08-30) 1 commit
(merged to 'next' on 2011-09-02 at f5f2c61)
+ Symlink mergetools scriptlets into valgrind wrappers
Not urgent; the topic came up a bit too late in the cycle.
* fg/submodule-auto-push (2011-08-20) 1 commit
(merged to 'next' on 2011-08-24 at 398e764)
+ push: teach --recurse-submodules the on-demand option
(this branch is used by hv/submodule-merge-search.)
What the topic aims to achieve may make sense, but the implementation
looked somewhat suboptimal.
* jc/fetch-verify (2011-09-01) 3 commits
- fetch: verify we have everything we need before updating our ref
- rev-list --verify-object
- list-objects: pass callback data to show_objects()
(this branch is used by jc/receive-verify and jc/receive-verify; uses jc/traverse-commit-list.)
Make "git fetch" verify what it received a bit more carefully before
updating the refs in the receiving end.
Not urgent; the topic came up a bit too late in the cycle.
* jc/traverse-commit-list (2011-08-22) 3 commits
(merged to 'next' on 2011-08-24 at df50dd7)
+ revision.c: update show_object_with_name() without using malloc()
+ revision.c: add show_object_with_name() helper function
+ rev-list: fix finish_object() call
(this branch is used by jc/fetch-verify and jc/receive-verify.)
Not urgent; will not be in 1.7.7.
* fk/make-auto-header-dependencies (2011-08-18) 1 commit
(merged to 'next' on 2011-08-24 at 3da2c25)
+ Makefile: Use computed header dependencies if the compiler supports it
(this branch is used by da/make-auto-header-dependencies.)
Not urgent; will not be in 1.7.7.
* mh/iterate-refs (2011-08-14) 6 commits
- Retain caches of submodule refs
- Store the submodule name in struct cached_refs
- Allocate cached_refs objects dynamically
- Change the signature of read_packed_refs()
- Access reference caches only through new function get_cached_refs()
- Extract a function clear_cached_refs()
I did not see anything fundamentally wrong with this series, but it was
unclear what the benefit of these changes are. If the series were to read
parts of the ref hierarchy (like refs/heads/) lazily, the story would
have been different, though.
Not urgent; will not be in 1.7.7.
* hv/submodule-update-none (2011-08-11) 2 commits
(merged to 'next' on 2011-08-24 at 5302fc1)
+ add update 'none' flag to disable update of submodule by default
+ submodule: move update configuration variable further up
Not urgent; will not be in 1.7.7.
* jc/lookup-object-hash (2011-08-11) 6 commits
(merged to 'next' on 2011-08-24 at 5825411)
+ object hash: replace linear probing with 4-way cuckoo hashing
+ object hash: we know the table size is a power of two
+ object hash: next_size() helper for readability
+ pack-objects --count-only
+ object.c: remove duplicated code for object hashing
+ object.c: code movement for readability
I do not think there is anything fundamentally wrong with this series, but
the risk of breakage far outweighs observed performance gain in one
particular workload. Will keep it in 'next' at least for one cycle.
Not urgent; will not be in 1.7.7.
* fg/submodule-git-file-git-dir (2011-08-22) 2 commits
(merged to 'next' on 2011-08-23 at 762194e)
+ Move git-dir for submodules
+ rev-parse: add option --resolve-git-dir <path>
I do not think there is anything fundamentally wrong with this series, but
the risk of breakage outweighs any benefit for having this new
feature. Will keep it in 'next' at least for one cycle.
Not urgent; will not be in 1.7.7.
* jk/http-auth-keyring (2011-08-03) 13 commits
(merged to 'next' on 2011-08-03 at b06e80e)
+ credentials: add "getpass" helper
+ credentials: add "store" helper
+ credentials: add "cache" helper
+ docs: end-user documentation for the credential subsystem
+ http: use hostname in credential description
+ allow the user to configure credential helpers
+ look for credentials in config before prompting
+ http: use credential API to get passwords
+ introduce credentials API
+ http: retry authentication failures for all http requests
+ remote-curl: don't retry auth failures with dumb protocol
+ improve httpd auth tests
+ url: decode buffers that are not NUL-terminated
Looked mostly reasonable except for the limitation that it is not clear
how to deal with a site at which a user needs to use different passwords
for different repositories. Will keep it in "next" at least for one cycle,
until we start hearing real-world success reports on the list.
Not urgent; will not be in 1.7.7.
* rr/revert-cherry-pick-continue (2011-08-08) 18 commits
(merged to 'next' on 2011-08-24 at 712c115)
+ revert: Propagate errors upwards from do_pick_commit
+ revert: Introduce --continue to continue the operation
+ revert: Don't implicitly stomp pending sequencer operation
+ revert: Remove sequencer state when no commits are pending
+ reset: Make reset remove the sequencer state
+ revert: Introduce --reset to remove sequencer state
+ revert: Make pick_commits functionally act on a commit list
+ revert: Save command-line options for continuing operation
+ revert: Save data for continuing after conflict resolution
+ revert: Don't create invalid replay_opts in parse_args
+ revert: Separate cmdline parsing from functional code
+ revert: Introduce struct to keep command-line options
+ revert: Eliminate global "commit" variable
+ revert: Rename no_replay to record_origin
+ revert: Don't check lone argument in get_encoding
+ revert: Simplify and inline add_message_to_msg
+ config: Introduce functions to write non-standard file
+ advice: Introduce error_resolve_conflict
Will keep it in 'next' at least for one cycle.
Not urgent; will not be in 1.7.7.
--------------------------------------------------
[Discarded]
* jk/pager-with-alias (2011-08-19) 1 commit
. support pager.* for aliases
^ permalink raw reply
* Re: [PATCHv2 1/2] remote: write correct fetch spec when renaming remote 'remote'
From: Junio C Hamano @ 2011-09-06 22:58 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git, Jeff King
In-Reply-To: <1314924634-12235-1-git-send-email-martin.von.zweigbergk@gmail.com>
Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:
> @@ -659,15 +660,18 @@ static int mv(int argc, const char **argv)
> strbuf_addf(&buf, "remote.%s.fetch", rename.new);
> if (git_config_set_multivar(buf.buf, NULL, NULL, 1))
> return error("Could not remove config section '%s'", buf.buf);
> + strbuf_addf(&old_remote_context, ":refs/remotes/%s/", rename.old);
> for (i = 0; i < oldremote->fetch_refspec_nr; i++) {
> char *ptr;
>
> strbuf_reset(&buf2);
> strbuf_addstr(&buf2, oldremote->fetch_refspec[i]);
> - ptr = strstr(buf2.buf, rename.old);
> + ptr = strstr(buf2.buf, old_remote_context.buf);
> if (ptr)
> - strbuf_splice(&buf2, ptr-buf2.buf, strlen(rename.old),
> - rename.new, strlen(rename.new));
> + strbuf_splice(&buf2,
> + ptr-buf2.buf + strlen(":refs/remotes/"),
> + strlen(rename.old), rename.new,
> + strlen(rename.new));
> if (git_config_set_multivar(buf.buf, buf2.buf, "^$", 0))
> return error("Could not append '%s'", buf.buf);
> }
It is somewhat bothering that we do not say "we didn't do any magic" here
when we did not move the tracking branch specifications, but that is not a
new problem, so I am OK with this change.
I however suspect that you would want to keep the record of what you
changed here, so that the renaming of actual refs done in [PATCH 2/2] is
limited to those that you updated the specifications for, no?
^ permalink raw reply
* Re: [RFC/PATCH git] http: avoid empty error messages for some curl errors
From: Junio C Hamano @ 2011-09-06 22:49 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Tay Ray Chuan
In-Reply-To: <20110905222202.GA32071@elie>
Jonathan Nieder <jrnieder@gmail.com> writes:
> When asked to fetch over SSL without a valid
> /etc/ssl/certs/ca-certificates.crt file, "git fetch" writes
>
> error: while accessing https://github.com/torvalds/linux.git/info/refs
>
> which is a little disconcerting. Better to fall back to
> curl_easy_strerror(result) when the error string is empty, like the
> curl utility does:
>
> error: Problem with the SSL CA cert (path? access rights?) while
> accessing https://github.com/torvalds/linux.git/info/refs
>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> ---
> Hi,
>
> I ran into this error today because this machine has no certs enabled.
> I'm not thrilled with the following patch because the error string
> buffer is not cleared very often so it seems possible for it to be
> not empty but stale at the relevant moment. I would be happier if we
> could rely on libcurl always filling the error buffer on errors.
Will queue both patches; thanks.
^ permalink raw reply
* Re: Tracking database changes.
From: Carlos Martín Nieto @ 2011-09-06 22:18 UTC (permalink / raw)
To: Rodrigo Cortés; +Cc: git
In-Reply-To: <CAFSYZ5RjJYHByTMPu6LiM6awGitt3WqnVrLU34mA9t7O1MVHDQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 339 bytes --]
On Tue, 2011-09-06 at 18:55 -0300, Rodrigo Cortés wrote:
> Is there a way to use git to track database changes?
That question is too generic to receive a useful answer. You could do a
nightly dump of the database contents and commit that file. Whether that
will give you anything useful is a different matter.
Cheers,
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] State what commit to expect in request-pull
From: Shawn Pearce @ 2011-09-06 21:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwrdl749z.fsf@alter.siamese.dyndns.org>
On Tue, Sep 6, 2011 at 14:24, Junio C Hamano <gitster@pobox.com> wrote:
> Interestingly, we did say what commit the requesters based their changes
> on, but did not give the person who performs a fetch & merge to make sure
> he fetched the right branch.
...
> diff --git a/git-request-pull.sh b/git-request-pull.sh
> @@ -71,6 +71,7 @@ git show -s --format='The following changes since commit %H:
>
> are available in the git repository at:' $baserev &&
> echo " $url $branch" &&
> +echo "for you to fetch changes up to $headrev"
> echo &&
Better than what we had before. I was sort of hoping for changing the
pull line slightly to include the SHA-1. E.g. suppose instead the line
was:
echo " $url $headrev"
and git pull passed the $headrev down to git fetch, which then found
any reference that points exactly at $headrev and fetches that. The
branch name is now lost for the merge summary, but could be guessed
from the advertisement similar to how HEAD is guessed. Git pull could
also then validate that the commit its merging in FETCH_HEAD is what
was passed on the command line.
Then verification of the SHA-1 is automatic by Git, and doesn't
require a human. If the pull request was sent by GPG signed email, and
the MUA checked the signature, the puller has pretty reasonable
assurance over the content they are bringing into their repository.
--
Shawn.
^ permalink raw reply
* Tracking database changes.
From: Rodrigo Cortés @ 2011-09-06 21:55 UTC (permalink / raw)
To: git
Is there a way to use git to track database changes?
--
Rodrigo Cortés Carvajal
Ingeniería Eléctrica
Universidad Tecnológica de Chile
^ 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