* Re: [PATCH v2 28/51] refs.c: rename ref_array -> ref_dir
From: Michael Haggerty @ 2011-12-13 22:13 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Drew Northup, Jakub Narebski, Heiko Voigt,
Johan Herland, Julian Phillips
In-Reply-To: <4EE7A387.3070400@alum.mit.edu>
On 12/13/2011 08:12 PM, Michael Haggerty wrote:
> On 12/13/2011 07:37 AM, Junio C Hamano wrote:
>> Another possibility is to keep the extra_ref interface in refs.c, without
>> any of your changes (i.e. keep it just as a flat list, with the original
>> interface to append to it without any dedup and other fancy features) and
>> also keep the special casing of it in for_each_ref(). AFAIK, that is the
>> only iterator that should care about the extra refs. Thinking about it a
>> bit more, removal of add_extra_ref() API may be unnecessarily complex with
>> no real gain. For example, extra refs added in builtin/clone.c is used by
>> builtin/fetch-pack.c, meaning that the codepath that discovers and
>> remembers these extra history anchor points and the codepath that uses
>> them while walking the history are not localized and we would need some
>> sort of "extra ref API" anyway. I am leaning towards this option.
>
> In a few minutes I will post a series of patches that store extra_refs
> in a linked list separate from the reference caches, and iterates over
> them only from for_each_ref(). I could rebase my ref-api-D changes on
> top of this patch series in such a way that the extra refs are kept in
> non-hierarchical storage. But I leave for vacation on Thursday so it is
> quite likely that I won't be able to get it finished before I return in
> the new year.
I forgot to mention that I think it would be better to separate the
handling of extra refs even more than do the patches
[PATCH 0/6] Handle extra_refs separately from ref_caches
Namely, we should figure out what code wants to set extra refs and or
wants to include extra refs in its iteration over references. The
setters don't have to be changed, but the readers should be. After the
above patch series, the readers call for_each_ref(), which always calls
do_for_each_extra_ref(). The call to do_for_each_extra_ref() should be
taken out of for_each_ref() and called directly by any readers who want
to support extra_refs. Other readers should only call for_each_ref().
(do_for_each_extra_ref(), probably under a different name, would have to
become public.) That way, for_each_ref() could ignore the extra refs
entirely, and other callers of for_each_ref() wouldn't risk getting
extra refs by accident.
Today I spent some time trying to figure out what callers of
for_each_ref() could possible want to deal with extra refs, but I got
lost in the deep call trees and undocumented function declarations. At
the top it is pretty clear that all such code paths start in cmd_clone()
or cmd_receive_pack(). But there are so many calls to the
for_each_ref*() family of functions that I wasn't able to determine
exactly which should allow for extra refs and which shouldn't. (I even
wonder whether extra refs might be used inadvertently in some places
where they aren't wanted, for example in one of the myriad calls to
setup_revisions().) If somebody could put his finger on the
for_each_ref() callers who want to support extra refs, that would be
very helpful.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* [PATCH] Gitweb: Avoid warnings when a repo does not have a valid HEAD
From: Joe Ratterman @ 2011-12-13 22:35 UTC (permalink / raw)
To: git; +Cc: Joe Ratterman
It is possible that the HEAD reference does not point to an existing
branch. When viewing such a repository in gitweb, a message like this
one was sent to the error log:
gitweb.cgi: Use of uninitialized value in string eq at /usr/src/git/gitweb/gitweb.cgi line 5115.
Signed-off-by: Joe Ratterman <jratt0@gmail.com>
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 4f0c3bd..5af06d6 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -5440,7 +5440,7 @@ sub git_heads_body {
for (my $i = $from; $i <= $to; $i++) {
my $entry = $headlist->[$i];
my %ref = %$entry;
- my $curr = $ref{'id'} eq $head;
+ my $curr = $head ? ($ref{'id'} eq $head) : 0;
if ($alternate) {
print "<tr class=\"dark\">\n";
} else {
--
1.7.7.1
^ permalink raw reply related
* [PATCH] Add '-P' as a synonym for '--no-pager' in the git command
From: Joe Ratterman @ 2011-12-13 22:35 UTC (permalink / raw)
To: git; +Cc: Joe Ratterman
In-Reply-To: <1323815706-10560-1-git-send-email-jratt0@gmail.com>
Also, add both -P|--no-pager to the existing -p|--paginate in bash
completion.
Signed-off-by: Joe Ratterman <jratt0@gmail.com>
---
Documentation/git.txt | 3 ++-
contrib/completion/git-completion.bash | 2 +-
git.c | 4 ++--
| 8 ++++++++
4 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index e869032..c7f8445 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git' [--version] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
- [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
+ [-p|--paginate|-P|--no-pager] [--no-replace-objects] [--bare]
[--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
[-c <name>=<value>]
[--help] <command> [<args>]
@@ -329,6 +329,7 @@ help ...`.
configuration options (see the "Configuration Mechanism" section
below).
+-P::
--no-pager::
Do not pipe git output into a pager.
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index cc1bdf9..8b9ea1b 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2640,7 +2640,7 @@ _git ()
case "$i" in
--git-dir=*) __git_dir="${i#--git-dir=}" ;;
--bare) __git_dir="." ;;
- --version|-p|--paginate) ;;
+ --version|-p|--paginate|-P|--no-pager) ;;
--help) command="help"; break ;;
*) command="$i"; break ;;
esac
diff --git a/git.c b/git.c
index 8e34903..baa1613 100644
--- a/git.c
+++ b/git.c
@@ -7,7 +7,7 @@
const char git_usage_string[] =
"git [--version] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]\n"
- " [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]\n"
+ " [-p|--paginate|-P|--no-pager] [--no-replace-objects] [--bare]\n"
" [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]\n"
" [-c name=value] [--help]\n"
" <command> [<args>]";
@@ -103,7 +103,7 @@ static int handle_options(const char ***argv, int *argc, int *envchanged)
exit(0);
} else if (!strcmp(cmd, "-p") || !strcmp(cmd, "--paginate")) {
use_pager = 1;
- } else if (!strcmp(cmd, "--no-pager")) {
+ } else if (!strcmp(cmd, "-P") || !strcmp(cmd, "--no-pager")) {
use_pager = 0;
if (envchanged)
*envchanged = 1;
--git a/t/t7006-pager.sh b/t/t7006-pager.sh
index 320e1d1..783915e 100755
--- a/t/t7006-pager.sh
+++ b/t/t7006-pager.sh
@@ -84,6 +84,14 @@ test_expect_success 'no pager even with --paginate when stdout is a pipe' '
! test -e paginated.out
'
+test_expect_success TTY 'no pager with -P' '
+ rm -f paginated.out ||
+ cleanup_fail &&
+
+ test_terminal git -P log &&
+ ! test -e paginated.out
+'
+
test_expect_success TTY 'no pager with --no-pager' '
rm -f paginated.out ||
cleanup_fail &&
--
1.7.7.1
^ permalink raw reply related
* Re: [RFC/PATCH] add update to branch support for "floating submodules"
From: Marc Branchaud @ 2011-12-13 22:42 UTC (permalink / raw)
To: Jens Lehmann
Cc: Phil Hord, Leif Gruenwoldt, Andreas T.Auer, Junio C Hamano, git
In-Reply-To: <4EE7C15A.3040501@web.de>
On 11-12-13 04:19 PM, Jens Lehmann wrote:
> Am 13.12.2011 16:35, schrieb Marc Branchaud:
>> I'd prefer to have floating be explicitly configured on a per-branch (or
>> per-branch-glob) basis. So in addition to what Jens described yesterday [1]
>> to configure an individual submodule's floating branch, I suggest there also
>> be a new section in the .gitmodules file for configuring the super-repo's
>> floating branches, e.g.
>>
>> [super]
>> floaters = refs/heads/master refs/heads/dev*
>>
>> [submodule "Sub1"]
>> path = foo/bar
>> branch = maint
>> url = ...
>>
>> [submodule "Sub2"]
>> path = other/place
>> url = ...
>
> Hmm, but you can have different .gitmodules files in different branches of
> the superproject, no?
Yes. I'm not sure I see that as a problem though.
> Why not just have the "branch = maint" setting for
> "Sub1" in the master and the dev branches .gitmodules file and drop it in
> the other branches?
Because I think that's an error-prone approach.
If the user creates a topic branch off (an ancestor) of master, git doesn't
know if the user wants floating submodules or not. If this is a bugfix
topic, the user would have to edit .gitmodules to turn off floating. But
that modified .gitmodules is too easily committed to the branch, and once it
gets merged back into master suddenly master loses its "floating" feature.
What's more, less-sophisticated users would be wary of editing an "internal"
file like .gitmodules.
Instead I think it's more intuitive for the repository to define which
branches get floating submodules and which don't, and IMO a list of
names/globs is a good way to do that. The repo's users would need to be
aware of what the magic branch names are, but I think that's easily
communicated in the floating-submodule scenarios I've seen posted. Git could
also help by telling the user, when a branch is created or it's name is
displayed, whether or not it's got floating submodules.
M.
^ permalink raw reply
* Re: Auto update submodules after merge and reset
From: Andreas T.Auer @ 2011-12-13 23:05 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Phil Hord, git
In-Reply-To: <4EE7C733.4010209@web.de>
On 13.12.2011 22:44 Jens Lehmann wrote:
> Am 13.12.2011 10:45, schrieb Andreas T.Auer:
> > On 12.12.2011 23:39 Jens Lehmann wrote:
> >> Am 11.12.2011 22:15, schrieb Andreas T.Auer:
> >>> For example
> >>>
> >>> [submodule "commonlib"] update = heads develop:unstable
> >>> master:stable maint:bugfixes
> >>
> >> Having that configured with "branch=unstable", "branch=stable"
> >> etc. in .gitmodules on the superprojects branches would be
> >> simpler and achieve the same functionality.
> >
> > Yes, this has been my first thought also, but there is also a good
> > point to keep the .gitmodules stable, or you always have to change
> > the file when branches change their names. So when the maint branch
> > of version 1.3 become an archive branch and the new maint is on
> > 1.4, which was the master before then you have to change the
> > .gitmodules on these branches. I.e. .gitmodules of 1.4 have
> > "stable" and must have "bugfixes" now and .gitmodules of 1.3 has
> > "bugfixes" and must remove the floating completely. I'm not sure
> > that this can always be solved with "easy" merging and therefore it
> > is probably not really simpler, when you have to do this for every
> > new release. Or what do you think?
>
> I never rename branches, so I do not concur ;-)
Well, maybe you don't, but Junio does something like that. There is a
maint-1.7.7 where maint has been before and maint jumped to master.
> And I think the .gitmodules file could benefit from a special merge
> driver being aware of the format and some subtleties (like not just
> adding a "branch" setting but rather creating a merge conflict)
> anyways.
If that would work it would be fine, but you would still have to create
a new commit, when maint jumps to master and you need to update the
.gitmodules to be a maint .gitmodules.
> So I'd prefer to keep it simple and just use the .gitmodules we
> already have which can be different in different branches.
I agree that the .gitmodule format would be simpler, but I'd prefer the
.gitmodule to be a little bit more complex, but more stable.
> >>> So whenever a defined branch is checked out in the
> >>> superproject the mapped branch will be checked out in the
> >>> submodule ("new" commit), but if a (e.g. tagged) commit is
> >>> checked out ("old" commit) then the gitlink in the superproject
> >>> is used to check out the referenced commit in the submodule.
> >>
> >> I think checkout should only use the submodule commit recorded in
> >> the superproject and a subsequent "git submodule update" should
> >> be needed to update the submodule to tip. Otherwise you record
> >> SHA-1 but still won't be able to bisect ...
> >
> > bisect would leave the branch and therefore uses the recorded SHA1
> > for the submodule checkout instead of the tip. "follow-the-tip"
> > should only work if the superproject follows the tip.
>
> If you follow a tip there won't be any new SHA-1s recorded during
> that following so you could not do a bisect and expect the submodule
> to be what the developer had when doing the commits, no?
If you never commit something to the superproject, you wouldn't get
SHA1s recorded, that's right. But when you commit something to the
superproject, why shouldn't the current submodule SHA1 be stored?
Floating is about _ignoring_ the recorded SHA1 in _some_ cases, not
about disabling the recording. So you can bisect to the bad superproject
commit. If you suspect a bad submodule commit causing the problem then
you could still bisect the submodule commits between the recorded SHA1s.
^ permalink raw reply
* Re: [PATCH] Revert "http: don't always prompt for password"
From: Jeff King @ 2011-12-13 23:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stefan Naewe, Sebastian Schuberth, Eric, git, msysgit
In-Reply-To: <7v62hkuptt.fsf@alter.siamese.dyndns.org>
On Tue, Dec 13, 2011 at 01:25:18PM -0800, Junio C Hamano wrote:
> > @@ -844,7 +846,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 && user_pass) {
> > + if (user_name) {
> > ret = HTTP_NOAUTH;
> > } else {
> > /*
>
> In the credential series, this is where we declare the given credential is
> to be rejected (if we have both username and password), or ask them to be
> filled by calling credential_fill(), so I think the code in the credential
> series does not need this revert. Right?
Sort of. The point of this conditional is "did we actually send a
credential? If yes, then return HTTP_NOAUTH. Otherwise, ask for the
credential and return HTTP_REAUTH"[1].
Prior to Stefan's patch, if user_name was set, then we sent a credential
(because we always filled in the password if user_name was set). After,
we had to check both (actually, I think checking user_pass would have
been sufficient)).
The situation is the same with credentials, but the variable name is
different. Even though credential_fill will fill in both parts, we may
have set http_auth.username from the URL, but not actually called
credential_fill (and therefore not sent any credentials).
So logically, the revert in the credential series would be:
- if (http_auth.username && http_auth.password)
+ if (http_auth.username)
except that I believe the former is a superset of the latter in both
cases (with or without the credential topic). So leaving it as-is would
be OK. In fact, when reverting Stefan's patch, you could just drop this
hunk entirely, which might be worth it to avoid conflicts with in-flight
topics.
[1] A much saner approach would be to always return HTTP_NOAUTH, and
then let the caller decide to re-ask for credentials and re-try.
But we need the magic curl slot object, which the caller doesn't
have. So doing it that way would have taken some refactoring.
> > @@ -853,8 +855,7 @@ 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.
> > */
> > - if (!user_name)
> > - user_name = xstrdup(git_getpass_with_description("Username", description));
> > + user_name = xstrdup(git_getpass_with_description("Username", description));
> > init_curl_http_auth(slot->curl);
> > ret = HTTP_REAUTH;
> > }
>
> So is this one.
Yeah, this code just goes away, as credential_fill() does the right
thing.
But again, the "if (!user_name)" version post-986bbc08 handles both the
pre-986bbc08 condition (because it will always be NULL then) and the
post-986bbc08 (because we do need to check then). So I believe you could
drop the hunk entirely.
Here's a re-roll of the revert that touches as little as possible. I
believe it's correct from my analysis above, and it does pass the tests.
I also included the flipping of the "expect_failure" test, which I
forgot to put in my original patch.
-- >8 --
Subject: [PATCH] Revert "http: don't always prompt for password"
This is a partial revert of commit 986bbc0842334f0e07731fa37f2a55d2930a5b8c.
The rationale for that commit relied on the fact that asking
for the password up-front was merely an optimization,
because git will notice an HTTP 401 and prompt for the
password. However, that is only true for smart-http, and for
dumb fetching. Dumb push over DAV does not have this
feature; as a result, authenticated push-over-DAV does not
work at all, as it never prompts the user for a password.
This is a partial revert that just restores the "don't ask
for password bits". There were some other related
adjustments in 986bbc08 to handle the fact that the
user_name field might be set even if we didn't send a
credential on the first try. The new logic introduced by
986bbc08 handles both the old case and the new case, so we
can leave them intact. That will prevent unnecessary
conflicts with other in-flight topics that touch this code.
Signed-off-by: Jeff King <peff@peff.net>
---
http.c | 2 ++
t/t5540-http-push.sh | 2 +-
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/http.c b/http.c
index 008ad72..33c63b5 100644
--- a/http.c
+++ b/http.c
@@ -279,6 +279,8 @@ 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())
diff --git a/t/t5540-http-push.sh b/t/t5540-http-push.sh
index 3300227..1eea647 100755
--- a/t/t5540-http-push.sh
+++ b/t/t5540-http-push.sh
@@ -160,7 +160,7 @@ test_expect_success 'PUT and MOVE sends object to URLs with SHA-1 hash suffix' '
test_http_push_nonff "$HTTPD_DOCUMENT_ROOT_PATH"/test_repo.git \
"$ROOT_PATH"/test_repo_clone master
-test_expect_failure 'push to password-protected repository (user in URL)' '
+test_expect_success 'push to password-protected repository (user in URL)' '
test_commit pw-user &&
git push "$HTTPD_URL_USER/auth/dumb/test_repo.git" HEAD &&
git rev-parse --verify HEAD >expect &&
--
1.7.8.17.gfd3524
^ permalink raw reply related
* Re: [PATCH 1/2] t5540: test DAV push with authentication
From: Jeff King @ 2011-12-13 23:16 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: Junio C Hamano, Stefan Naewe, Eric, git, msysgit
In-Reply-To: <CAHGBnuO1CFGacMQb+Md_uGsLu=V9bGDpcFLd9Lb4C5jSN+uUiw@mail.gmail.com>
On Tue, Dec 13, 2011 at 10:28:07PM +0100, Sebastian Schuberth wrote:
> On Tue, Dec 13, 2011 at 21:17, Jeff King <peff@peff.net> wrote:
>
> > We don't currently test this case at all, and instead just
> > test the DAV mechanism over an unauthenticated push. That
> > isn't very realistic, as most people will want to
> > authenticate pushes.
>
> Thanks for adding this, Peff!
You're welcome. Thank you for forwarding the bug report. I would never
have seen it on the msysgit list, and for some reason it seems that
msysgit people are more likely to use DAV.
Having looked a lot at the http code the past month or two, I knew it
was pretty flaky and I was nervous when we added Stefan's patch (and no,
I don't blame Stefan; his patch was completely reasonable, but just
happened to trigger a problem in a seldom-looked-at corner of the code).
But I hadn't looked at http-push at all until yesterday, and it didn't
even occur to me that there was another whole area of code relying in a
very obscure way on the http.c auth code. I'll take a look at some of
the refactoring I've done in http.c (both for the credentials topic as
well as the bundle topic) and see if we can't integrate http-push.c a
little more smoothly.
-Peff
^ permalink raw reply
* Re: [PATCH] Revert "http: don't always prompt for password"
From: Jeff King @ 2011-12-13 23:18 UTC (permalink / raw)
To: Eric Advincula
Cc: Junio C Hamano, Stefan Naewe, Sebastian Schuberth, git, msysgit
In-Reply-To: <CA+e6NDTQNEJB6Y17ow+yuLp2Bc799wsyQdnS8immMDYdCEyCGA@mail.gmail.com>
On Tue, Dec 13, 2011 at 02:22:12PM -0700, Eric Advincula wrote:
> Is there an alternative to using git on windows? I used windows, apache,
> dav for git.
> If there is a better solution please let me know.
I don't know the status of running the smart-http backend on Windows,
but that would be a preferable solution. It's way more efficient, and
the client half of the code is better maintained.
See "git help http-backend" for documentation.
-Peff
^ permalink raw reply
* Re: [PATCH] Revert "http: don't always prompt for password"
From: Jeff King @ 2011-12-13 23:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stefan Naewe, Sebastian Schuberth, Eric, git, msysgit
In-Reply-To: <7vaa6wuqjt.fsf@alter.siamese.dyndns.org>
On Tue, Dec 13, 2011 at 01:09:42PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > Doing (3) is obviously the easiest thing. And given the complexity of
> > the other two solutions, I think it makes sense to revert 986bbc08
> > (i.e., apply this patch), ship a working v1.7.8.1, and then look at
> > doing one of the other two solutions for v1.7.9.
>
> Or just let the "dumb HTTP" die.
>
> I thought push over DAV has long been dead; is anybody using it for real?
For the record, I have no problem whatsoever with letting it die. I just
think we probably shouldn't do it accidentally during a release. ;)
-Peff
^ permalink raw reply
* Re: [PATCH] Revert "http: don't always prompt for password"
From: Jeff King @ 2011-12-13 23:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stefan Naewe, Sebastian Schuberth, Eric, git, msysgit
In-Reply-To: <20111213231909.GD12432@sigill.intra.peff.net>
On Tue, Dec 13, 2011 at 06:19:09PM -0500, Jeff King wrote:
> > Or just let the "dumb HTTP" die.
> >
> > I thought push over DAV has long been dead; is anybody using it for real?
>
> For the record, I have no problem whatsoever with letting it die. I just
> think we probably shouldn't do it accidentally during a release. ;)
BTW, one other solution, rather than reverting Stefan's patch, is to
just re-add the "unconditionally ask for a password" behavior back to
git-http-push, but not to the fetching side. Especially if we hope to
kill off git-http-push soon (after a deprecation period presumably),
then that lets it work in the meantime without hurting the other http
code. And it's really easy to do.
-Peff
^ permalink raw reply
* Re: [PATCH v2 28/51] refs.c: rename ref_array -> ref_dir
From: Junio C Hamano @ 2011-12-13 23:24 UTC (permalink / raw)
To: Michael Haggerty
Cc: git, Jeff King, Drew Northup, Jakub Narebski, Heiko Voigt,
Johan Herland, Julian Phillips
In-Reply-To: <4EE7CDF2.3040408@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
>>> .... For example, extra refs added in builtin/clone.c is used by
>>> builtin/fetch-pack.c, meaning that the codepath that discovers and
>>> remembers these extra history anchor points and the codepath that uses
>>> them while walking the history are not localized and we would need some
>>> sort of "extra ref API" anyway. I am leaning towards this option.
> ...
> Namely, we should figure out what code wants to set extra refs and or
> wants to include extra refs in its iteration over references. The
> setters don't have to be changed, but the readers should be.
You read me correctly. That is exactly what I meant by "extra ref API" in
my earlier response.
> ... But there are so many calls to the
> for_each_ref*() family of functions that I wasn't able to determine
> exactly which should allow for extra refs and which shouldn't.
Only the ones that follow add_extra_ref() in the control flow.
builtin/clone.c adds them in setup_reference() to deal with --reference.
The objects known to be complete in these repositories we borrow from
need to be marked complete on our end (i.e. clone does not have to fetch)
and transport_fetch_refs() that eventually goes to fetch_refs_via_pack()
that calls fetch_pack() uses this information. All three for_each_ref()
calls in builtin/fetch-pack.c are about "what are the objects that we know
are complete?" and needs to pay attention to extra refs.
Having said that, I have a slight suspicion that you might be able to
eliminate this one in clone. setup_reference() adds the reference
repository to the $GIT_DIR/objects/info/alternates, and the fetch logic
already knows to account for the refs in alternate repositories via
insert_alternate_refs() callchain.
builtin/receive-pack.c adds them in add_alternate_refs() to deal with the
repositories listed in $GIT_DIR/objects/info/alternates in the receiving
end of a push. Again, the objects known to be complete in these
repositories we borrow from need to be marked complete on our end, and
write_head_info() in that function sends these extras together with real
refs we have.
^ permalink raw reply
* [PATCH 1/2] set_ref_status_for_push(): use transport-flags abstraction
From: Junio C Hamano @ 2011-12-13 23:26 UTC (permalink / raw)
To: git
It does not make much sense to have separate "int" parameters to
this function with two callsites (why do we need to to begin with?
but that is a separate issue) and having to update them every time
we need to touch it.
Consolidate them into a single "flags" parameter to make it easier
to extend later.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* A preparatory step for the next one
builtin/send-pack.c | 10 ++++++++--
remote.c | 6 ++++--
remote.h | 3 +--
transport.c | 4 +---
4 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/builtin/send-pack.c b/builtin/send-pack.c
index e0b8030..ec107ed 100644
--- a/builtin/send-pack.c
+++ b/builtin/send-pack.c
@@ -404,6 +404,7 @@ int cmd_send_pack(int argc, const char **argv, const char *prefix)
int send_all = 0;
const char *receivepack = "git-receive-pack";
int flags;
+ unsigned transport_flags;
int nonfastforward = 0;
argv++;
@@ -512,8 +513,13 @@ int cmd_send_pack(int argc, const char **argv, const char *prefix)
if (match_push_refs(local_refs, &remote_refs, nr_refspecs, refspecs, flags))
return -1;
- set_ref_status_for_push(remote_refs, args.send_mirror,
- args.force_update);
+ transport_flags = 0;
+ if (args.send_mirror)
+ transport_flags |= TRANSPORT_PUSH_MIRROR;
+ if (args.force_update)
+ transport_flags |= TRANSPORT_PUSH_FORCE;
+
+ set_ref_status_for_push(remote_refs, transport_flags);
ret = send_pack(&args, fd, conn, remote_refs, &extra_have);
diff --git a/remote.c b/remote.c
index 6655bb0..95d7f37 100644
--- a/remote.c
+++ b/remote.c
@@ -7,6 +7,7 @@
#include "dir.h"
#include "tag.h"
#include "string-list.h"
+#include "transport.h"
static struct refspec s_tag_refspec = {
0,
@@ -1223,10 +1224,11 @@ int match_push_refs(struct ref *src, struct ref **dst,
return 0;
}
-void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
- int force_update)
+void set_ref_status_for_push(struct ref *remote_refs, unsigned flags)
{
struct ref *ref;
+ int send_mirror = flags & TRANSPORT_PUSH_MIRROR;
+ int force_update = flags & TRANSPORT_PUSH_FORCE;
for (ref = remote_refs; ref; ref = ref->next) {
if (ref->peer_ref)
diff --git a/remote.h b/remote.h
index b395598..0cf3c07 100644
--- a/remote.h
+++ b/remote.h
@@ -98,8 +98,7 @@ char *apply_refspecs(struct refspec *refspecs, int nr_refspec,
int match_push_refs(struct ref *src, struct ref **dst,
int nr_refspec, const char **refspec, int all);
-void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
- int force_update);
+void set_ref_status_for_push(struct ref *remote_refs, unsigned flags);
/*
* Given a list of the remote refs and the specification of things to
diff --git a/transport.c b/transport.c
index 51814b5..95556da 100644
--- a/transport.c
+++ b/transport.c
@@ -1031,9 +1031,7 @@ int transport_push(struct transport *transport,
return -1;
}
- set_ref_status_for_push(remote_refs,
- flags & TRANSPORT_PUSH_MIRROR,
- flags & TRANSPORT_PUSH_FORCE);
+ set_ref_status_for_push(remote_refs, flags);
if ((flags & TRANSPORT_RECURSE_SUBMODULES_CHECK) && !is_bare_repository()) {
struct ref *ref = remote_refs;
--
1.7.8.249.gb1b73
^ permalink raw reply related
* [PATCH 2/2] push: --ignore-stale option
From: Junio C Hamano @ 2011-12-13 23:35 UTC (permalink / raw)
To: git
If you forked many local branches that are not active from a shared
'origin' repository, it is sometimes convenient to say "I know many of my
branches are stale, so do not push them, but push ones that have my own
work". Using the usual 'matching refs' semantics that is designed for the
workflow to push into your own publishing repository is not suitable for
this purpose as-is, because many of your local branches are likely to have
been made stale by other people pushing into the same shared repository,
triggering 'no fast-forward' errors.
Teach a new "--ignore-stale" option to "git push" which tells it not to
push stale refs (i.e. the commit that would have been pushed without the
option is an ancestor of the commit that is at the destination). With this,
a lazy workflow could be like this:
$ git clone <<origin>>
$ git checkout -b topic1 origin/topic1
$ work work work
$ git push origin :
$ git checkout -b topic2 origin/topic2
$ work work work
$ git push --ignore-stale origin :
and the second push does not have to worry about other people working on
topic1 and updating it in the central repository while you haven't touched
the corresponding local branch at all.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* You may end up having 47 local branches, 7 of them worked on recently
and none of them pushed yet, which requires you to remember which 7 of
them you need to push among 47. The reason you left these 7 unpushed
even though you checked out other branches at least 6 times after
making the last commit on these branches is probably because you wanted
to make sure everything is in good order, delaying the pushout as much
as possible, which by itself is a good discipline.
You however should be testing these 7 before pushing them out anyway,
and the sane way to do so is to check one out, test it, push it, and
iterate that sequence 7 times. If you do so, a workable alternative is
to use the configuration to push the current branch and you do not need
this patch series at all.
Perhaps this series encourages a wrong workflow in that sense. I dunno.
Documentation/git-push.txt | 10 +++++++++-
builtin/push.c | 1 +
builtin/send-pack.c | 7 +++++++
cache.h | 1 +
remote.c | 20 ++++++++++++++++++++
t/t5516-fetch-push.sh | 31 +++++++++++++++++++++++++++++++
transport.c | 6 ++++++
transport.h | 1 +
8 files changed, 76 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index aede488..f2b5ee2 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -11,7 +11,7 @@ SYNOPSIS
[verse]
'git push' [--all | --mirror | --tags] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
[--repo=<repository>] [-f | --force] [-v | --verbose] [-u | --set-upstream]
- [<repository> [<refspec>...]]
+ [--ignore-stale] [<repository> [<refspec>...]]
DESCRIPTION
-----------
@@ -114,6 +114,14 @@ nor in any Push line of the corresponding remotes file---see below).
This flag disables the check. This can cause the
remote repository to lose commits; use it with care.
+--ignore-stale::
+ When the commit that is pushed is known to be an ancestor of the
+ commit that is at the remote ref, exclude it from the push
+ request. This can be used with the "matching" semantics to push
+ out only the branches that have your own work, when you know many
+ of your branches since they were forked from their upstream are
+ untouched and stale.
+
--repo=<repository>::
This option is only relevant if no <repository> argument is
passed in the invocation. In this case, 'git push' derives the
diff --git a/builtin/push.c b/builtin/push.c
index 35cce53..165d2be 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -261,6 +261,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
OPT_BIT('u', "set-upstream", &flags, "set upstream for git pull/status",
TRANSPORT_PUSH_SET_UPSTREAM),
OPT_BOOLEAN(0, "progress", &progress, "force progress reporting"),
+ OPT_BIT(0, "ignore-stale", &flags, "ignore stale refs", TRANSPORT_PUSH_IGNORE_STALE),
OPT_END()
};
diff --git a/builtin/send-pack.c b/builtin/send-pack.c
index ec107ed..0cfc69a 100644
--- a/builtin/send-pack.c
+++ b/builtin/send-pack.c
@@ -196,6 +196,11 @@ static void print_helper_status(struct ref *ref)
msg = "up to date";
break;
+ case REF_STATUS_STALE:
+ res = "ok";
+ msg = "ignored stale";
+ break;
+
case REF_STATUS_REJECT_NONFASTFORWARD:
res = "error";
msg = "non-fast forward";
@@ -282,6 +287,7 @@ int send_pack(struct send_pack_args *args,
switch (ref->status) {
case REF_STATUS_REJECT_NONFASTFORWARD:
case REF_STATUS_UPTODATE:
+ case REF_STATUS_STALE:
continue;
default:
; /* do nothing */
@@ -379,6 +385,7 @@ int send_pack(struct send_pack_args *args,
switch (ref->status) {
case REF_STATUS_NONE:
case REF_STATUS_UPTODATE:
+ case REF_STATUS_STALE:
case REF_STATUS_OK:
break;
default:
diff --git a/cache.h b/cache.h
index 8c98d05..696805d 100644
--- a/cache.h
+++ b/cache.h
@@ -1009,6 +1009,7 @@ struct ref {
REF_STATUS_OK,
REF_STATUS_REJECT_NONFASTFORWARD,
REF_STATUS_REJECT_NODELETE,
+ REF_STATUS_STALE,
REF_STATUS_UPTODATE,
REF_STATUS_REMOTE_REJECT,
REF_STATUS_EXPECTING_REPORT
diff --git a/remote.c b/remote.c
index 95d7f37..9c63426 100644
--- a/remote.c
+++ b/remote.c
@@ -1224,11 +1224,25 @@ int match_push_refs(struct ref *src, struct ref **dst,
return 0;
}
+/*
+ * Do we know if the other side has newer commit than what we are
+ * trying to push (i.e. old_sha1 is descendant of new_sha1)? If so
+ * just ignore the request to push this particular bref under the
+ * "--ignore-stale" option.
+ */
+static int is_stale_push(unsigned char *old_sha1, unsigned char *new_sha1)
+{
+ if (!has_sha1_file(old_sha1) || !has_sha1_file(new_sha1))
+ return 0;
+ return ref_newer(old_sha1, new_sha1);
+}
+
void set_ref_status_for_push(struct ref *remote_refs, unsigned flags)
{
struct ref *ref;
int send_mirror = flags & TRANSPORT_PUSH_MIRROR;
int force_update = flags & TRANSPORT_PUSH_FORCE;
+ int ignore_stale = flags & TRANSPORT_PUSH_IGNORE_STALE;
for (ref = remote_refs; ref; ref = ref->next) {
if (ref->peer_ref)
@@ -1243,6 +1257,12 @@ void set_ref_status_for_push(struct ref *remote_refs, unsigned flags)
continue;
}
+ if (ignore_stale && !ref->deletion &&
+ is_stale_push(ref->old_sha1, ref->new_sha1)) {
+ ref->status = REF_STATUS_STALE;
+ continue;
+ }
+
/* This part determines what can overwrite what.
* The rules are:
*
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index b69cf57..c925640 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -979,4 +979,35 @@ test_expect_success 'push --porcelain --dry-run rejected' '
test_cmp .git/foo .git/bar
'
+test_expect_success 'push --ignore-stale' '
+ mk_empty &&
+ (
+ cd testrepo &&
+ git fetch --update-head-ok .. "refs/heads/*:refs/heads/*" &&
+ git checkout -b next master &&
+ git commit --allow-empty -m "updated next" &&
+ git push . next:master &&
+ git for-each-ref >../snapshot.before
+ ) &&
+ git checkout branch1 &&
+ git commit --allow-empty -m "updated branch1" &&
+ test_must_fail git push testrepo : &&
+ git fetch testrepo "+refs/heads/*:refs/remotes/origin/*" &&
+ git push --ignore-stale testrepo : &&
+ (
+ cd testrepo &&
+ git for-each-ref >../snapshot.after
+ ) &&
+
+ # branch1 must be updated and master must stay the same
+ git for-each-ref refs/heads/branch1 >expect &&
+ grep refs/heads/branch1 snapshot.after >actual &&
+ test_cmp expect actual &&
+
+ grep refs/heads/master snapshot.before >expect &&
+ grep refs/heads/master snapshot.after >actual &&
+ test_cmp expect actual
+
+'
+
test_done
diff --git a/transport.c b/transport.c
index 95556da..d124d70 100644
--- a/transport.c
+++ b/transport.c
@@ -566,6 +566,7 @@ static int push_had_errors(struct ref *ref)
for (; ref; ref = ref->next) {
switch (ref->status) {
case REF_STATUS_NONE:
+ case REF_STATUS_STALE:
case REF_STATUS_UPTODATE:
case REF_STATUS_OK:
break;
@@ -581,6 +582,7 @@ int transport_refs_pushed(struct ref *ref)
for (; ref; ref = ref->next) {
switch(ref->status) {
case REF_STATUS_NONE:
+ case REF_STATUS_STALE:
case REF_STATUS_UPTODATE:
break;
default:
@@ -690,6 +692,10 @@ static int print_one_push_status(struct ref *ref, const char *dest, int count, i
print_ref_status('=', "[up to date]", ref,
ref->peer_ref, NULL, porcelain);
break;
+ case REF_STATUS_STALE:
+ print_ref_status('=', "[stale ignored]", ref,
+ ref->peer_ref, NULL, porcelain);
+ break;
case REF_STATUS_REJECT_NONFASTFORWARD:
print_ref_status('!', "[rejected]", ref, ref->peer_ref,
"non-fast-forward", porcelain);
diff --git a/transport.h b/transport.h
index 059b330..5db8d23 100644
--- a/transport.h
+++ b/transport.h
@@ -102,6 +102,7 @@ struct transport {
#define TRANSPORT_PUSH_PORCELAIN 16
#define TRANSPORT_PUSH_SET_UPSTREAM 32
#define TRANSPORT_RECURSE_SUBMODULES_CHECK 64
+#define TRANSPORT_PUSH_IGNORE_STALE 128
#define TRANSPORT_SUMMARY_WIDTH (2 * DEFAULT_ABBREV + 3)
--
1.7.8.249.gb1b73
^ permalink raw reply related
* Re: [PATCH 2/2] push: --ignore-stale option
From: Andreas Ericsson @ 2011-12-13 23:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vobvct58u.fsf@alter.siamese.dyndns.org>
On 12/14/2011 12:35 AM, Junio C Hamano wrote:
>
> You however should be testing these 7 before pushing them out anyway,
> and the sane way to do so is to check one out, test it, push it, and
> iterate that sequence 7 times. If you do so, a workable alternative is
> to use the configuration to push the current branch and you do not need
> this patch series at all.
>
> Perhaps this series encourages a wrong workflow in that sense. I dunno.
>
I for one really love it and will probably make an alias to use for most of
my repos. With 'maint' branches (with topics) being worked on by one team and
'master' (with topics) being worked on by a different group, but all branches
generally checked out, tracked and touched by everyone sooner or later, I've
come to just ignore the "not fast-forward" error. I've never stopped loathing
it though, since git should just *know* that it doesn't fast-forward because
I haven't done anything and not because I've done something (and maybe
forgotten to push) and someone else has done something different, which would
actually be interesting for me to know.
So big thumbs up and three loud "hurrah"'s for this.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: [PATCH] Revert "http: don't always prompt for password"
From: Jeff King @ 2011-12-14 0:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stefan Naewe, Sebastian Schuberth, Eric, git, msysgit
In-Reply-To: <20111213232053.GE12432@sigill.intra.peff.net>
On Tue, Dec 13, 2011 at 06:20:53PM -0500, Jeff King wrote:
> BTW, one other solution, rather than reverting Stefan's patch, is to
> just re-add the "unconditionally ask for a password" behavior back to
> git-http-push, but not to the fetching side. Especially if we hope to
> kill off git-http-push soon (after a deprecation period presumably),
> then that lets it work in the meantime without hurting the other http
> code. And it's really easy to do.
And here's what that patch looks like.
Thinking on it more, this is probably better for a maint release than
reverting Stefan's patch. It un-breaks http-push, and they are no
differently off than they are with the revert. But it leaves the
enhancement in place for the smart-http code.
-- >8 --
Subject: [PATCH] http-push: enable "proactive auth"
Before commit 986bbc08, git was proactive about asking for
http passwords. It assumed that if you had a username in
your URL, you would also want a password, and asked for it
before making any http requests.
However, this could interfere with the use of .netrc (see
986bbc08 for details). And it was also unnecessary, since
the http fetching code had learned to recognize an HTTP 401
and prompt the user then. Furthermore, the proactive prompt
could interfere with the usage of .netrc (see 986bbc08 for
details).
Unfortunately, the http push-over-DAV code never learned to
recognize HTTP 401, and so was broken by this change. This
patch does a quick fix of re-enabling the "proactive auth"
strategy only for http-push, leaving the dumb http fetch and
smart-http as-is.
Signed-off-by: Jeff King <peff@peff.net>
---
http-fetch.c | 2 +-
http-push.c | 2 +-
http.c | 8 +++++++-
http.h | 3 ++-
remote-curl.c | 2 +-
t/t5540-http-push.sh | 2 +-
6 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/http-fetch.c b/http-fetch.c
index 69299b7..94d47cb 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -67,7 +67,7 @@ int main(int argc, const char **argv)
git_config(git_default_config, NULL);
- http_init(NULL, url);
+ http_init(NULL, url, 0);
walker = get_http_walker(url);
walker->get_tree = get_tree;
walker->get_history = get_history;
diff --git a/http-push.c b/http-push.c
index 5d01be9..70283e6 100644
--- a/http-push.c
+++ b/http-push.c
@@ -1820,7 +1820,7 @@ int main(int argc, char **argv)
memset(remote_dir_exists, -1, 256);
- http_init(NULL, repo->url);
+ http_init(NULL, repo->url, 1);
#ifdef USE_CURL_MULTI
is_running_queue = 0;
diff --git a/http.c b/http.c
index 008ad72..6c90092 100644
--- a/http.c
+++ b/http.c
@@ -43,6 +43,7 @@
static const char *curl_http_proxy;
static const char *curl_cookie_file;
static char *user_name, *user_pass, *description;
+static int http_proactive_auth;
static const char *user_agent;
#if LIBCURL_VERSION_NUM >= 0x071700
@@ -279,6 +280,9 @@ static CURL *get_curl_handle(void)
curl_easy_setopt(result, CURLOPT_HTTPAUTH, CURLAUTH_ANY);
#endif
+ if (http_proactive_auth)
+ init_curl_http_auth(result);
+
if (ssl_cert != NULL)
curl_easy_setopt(result, CURLOPT_SSLCERT, ssl_cert);
if (has_cert_password())
@@ -367,7 +371,7 @@ static void set_from_env(const char **var, const char *envname)
*var = val;
}
-void http_init(struct remote *remote, const char *url)
+void http_init(struct remote *remote, const char *url, int proactive_auth)
{
char *low_speed_limit;
char *low_speed_time;
@@ -378,6 +382,8 @@ void http_init(struct remote *remote, const char *url)
curl_global_init(CURL_GLOBAL_ALL);
+ http_proactive_auth = proactive_auth;
+
if (remote && remote->http_proxy)
curl_http_proxy = xstrdup(remote->http_proxy);
diff --git a/http.h b/http.h
index 3c332a9..51f6ba7 100644
--- a/http.h
+++ b/http.h
@@ -86,7 +86,8 @@ struct buffer {
extern void step_active_slots(void);
#endif
-extern void http_init(struct remote *remote, const char *url);
+extern void http_init(struct remote *remote, const char *url,
+ int proactive_auth);
extern void http_cleanup(void);
extern int data_received;
diff --git a/remote-curl.c b/remote-curl.c
index 0e720ee..0757b19 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -859,7 +859,7 @@ int main(int argc, const char **argv)
url = strbuf_detach(&buf, NULL);
- http_init(remote, url);
+ http_init(remote, url, 0);
do {
if (strbuf_getline(&buf, stdin, '\n') == EOF) {
diff --git a/t/t5540-http-push.sh b/t/t5540-http-push.sh
index 3300227..1eea647 100755
--- a/t/t5540-http-push.sh
+++ b/t/t5540-http-push.sh
@@ -160,7 +160,7 @@ test_expect_success 'PUT and MOVE sends object to URLs with SHA-1 hash suffix' '
test_http_push_nonff "$HTTPD_DOCUMENT_ROOT_PATH"/test_repo.git \
"$ROOT_PATH"/test_repo_clone master
-test_expect_failure 'push to password-protected repository (user in URL)' '
+test_expect_success 'push to password-protected repository (user in URL)' '
test_commit pw-user &&
git push "$HTTPD_URL_USER/auth/dumb/test_repo.git" HEAD &&
git rev-parse --verify HEAD >expect &&
--
1.7.8.17.gfd3524
^ permalink raw reply related
* [REQUEST PULL] git-gui
From: Pat Thoyts @ 2011-12-14 0:05 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano
The following changes since commit 843d6597fbacfae02b8af7d6840992c92d0863f8:
git-gui: incremental goto line in blame view (2011-10-15 23:14:13 +0100)
are available in the git repository at:
git://repo.or.cz/git-gui.git master
for you to fetch changes up to 942e6baa92846e5628752c65a22bc4957d8de4d0:
git-gui 0.16 (2011-12-13 23:44:30 +0000)
----------------------------------------------------------------
Bert Wesarg (14):
git-gui: fix multi selected file operation
git-gui: handle config booleans without value
git-gui: add smart case search mode in searchbar
git-gui: add regexp search mode to the searchbar
git-gui: add search history to searchbar
git-gui: fix unintended line break in message string
git-gui: use "untracked" for files which are not known to git
git-gui: new config to control staging of untracked files
git-gui: fix display of path in browser title
git-gui: use a tristate to control the case mode in the searchbar
git-gui: span widgets over the full file output area in the blame view
git-gui: include the file path in guitools confirmation dialog
git-gui: make config gui.warndetachedcommit a boolean
git-gui: don't warn for detached head when rebasing
Dejan Ribič (1):
git-gui: fix spelling error in sshkey.tcl
Pat Thoyts (12):
git-gui: include the number of untracked files to stage when asking the user
git-gui: theme the search and line-number entry fields on blame screen
git-gui: catch invalid or complete regular expressions and treat as no match.
git-gui: enable the smart case sensitive search only if gui.search.smartcase is true
Merge branch 'bw/searching'
git-gui: set suitable extended window manager hints.
git-gui: support underline style when parsing diff output
git-gui: sort the numeric ansi codes
git-gui: set whitespace warnings appropriate to this project
git-gui: added config gui.gcwarning to disable the gc hint message
git-gui: handle shell script text filters when loading for blame.
git-gui 0.16
Samuel Bronson (1):
git-gui: Set both 16x16 and 32x32 icons on X to pacify Xming.
Tilman Vogel (1):
git-gui: add config value gui.diffopts for passing additional diff options
.gitattributes | 1 +
GIT-VERSION-GEN | 2 +-
git-gui.sh | 56 ++++++++++++++++++++++--
lib/blame.tcl | 29 ++++++------
lib/browser.tcl | 8 +++-
lib/choose_rev.tcl | 1 +
lib/class.tcl | 1 +
lib/commit.tcl | 4 +-
lib/diff.tcl | 5 +-
lib/index.tcl | 24 ++++++++---
lib/line.tcl | 2 +-
lib/option.tcl | 20 ++++++++
lib/search.tcl | 123 ++++++++++++++++++++++++++++++++++++++++++++++-----
lib/sshkey.tcl | 2 +-
lib/themed.tcl | 99 ++++++++++++++++++++++++++++++++++++++++--
lib/tools.tcl | 10 +++-
lib/transport.tcl | 1 +
17 files changed, 339 insertions(+), 49 deletions(-)
^ permalink raw reply
* Re: [PATCH 2/2] Makefile: optionally exclude code that needs Unix sockets
From: Junio C Hamano @ 2011-12-14 0:14 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Jeff King, git
In-Reply-To: <4EE7AEDA.6090509@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> Am 13.12.2011 01:45, schrieb Junio C Hamano:
>> I'll queue a single patch that is a squash between 2/2 and Peff's test
>> updates between "credentials: add "cache" helper" and "strbuf: add
>> strbuf_add*_urlencode" in the series.
>
> Thanks. The resulting series builds fine on Windows and passes/skips the
> new tests in the expected manner.
Thanks. Let's advance the topic forward then.
^ permalink raw reply
* [PATCH] stash: Fix multiple error messages on create if no HEAD
From: Sebastian Morr @ 2011-12-14 0:14 UTC (permalink / raw)
To: git
create_stash() checks whether HEAD is valid via rev-parse. If this is
not the case, both itself as well as rev-parse print an error message.
Make rev-parse quiet.
In no_changes(), diff-index is called, which dies unquietly if there is
no commit. Hide it's stderr.
Signed-off-by: Sebastian Morr <sebastian@morr.cc>
---
This bugged me: In a new, empty repository:
$ git stash
fatal: bad revision 'HEAD'
fatal: bad revision 'HEAD'
fatal: Needed a single revision
You do not have the initial commit yet
With this patch:
$ git stash
You do not have the initial commit yet
With the --quiet option, I wouldn't expect diff-index to print error
messages. But it does so (via revision.c, setup_revisions()). Is this
wanted?
git-stash.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index c766692..07b6511 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -34,7 +34,7 @@ else
fi
no_changes () {
- git diff-index --quiet --cached HEAD --ignore-submodules -- &&
+ git diff-index --quiet --cached HEAD --ignore-submodules -- 2>/dev/null &&
git diff-files --quiet --ignore-submodules &&
(test -z "$untracked" || test -z "$(untracked_files)")
}
@@ -67,7 +67,7 @@ create_stash () {
fi
# state of the base commit
- if b_commit=$(git rev-parse --verify HEAD)
+ if b_commit=$(git rev-parse --quiet --verify HEAD)
then
head=$(git rev-list --oneline -n 1 HEAD --)
else
--
1.7.8.168.gd6118.dirty
^ permalink raw reply related
* Re: [PATCH v2 28/51] refs.c: rename ref_array -> ref_dir
From: Junio C Hamano @ 2011-12-14 0:19 UTC (permalink / raw)
To: Michael Haggerty
Cc: git, Jeff King, Drew Northup, Jakub Narebski, Heiko Voigt,
Johan Herland, Julian Phillips
In-Reply-To: <7vzkewt5qu.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
>> Namely, we should figure out what code wants to set extra refs and or
>> wants to include extra refs in its iteration over references. The
>> setters don't have to be changed, but the readers should be.
>
> You read me correctly. That is exactly what I meant by "extra ref API" in
> my earlier response.
Actually, I do not think it even needs to be the "extra *REF* API". The
only thing that matters is that these commits are considered to be extra
anchor point in the history, in addition to the usual rule of considering
that everything reachable from our refs is complete. The data structure to
hold them does not even have to be a "struct ref". Just an array of object
names (or "struct object *") should suffice.
^ permalink raw reply
* Re: [PATCH] Revert "http: don't always prompt for password"
From: Junio C Hamano @ 2011-12-14 0:33 UTC (permalink / raw)
To: Jeff King; +Cc: Stefan Naewe, Sebastian Schuberth, Eric, git, msysgit
In-Reply-To: <20111214001156.GA21940@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> ... This
> patch does a quick fix of re-enabling the "proactive auth"
> strategy only for http-push, leaving the dumb http fetch and
> smart-http as-is.
Yeah, I somehow like this better. Thanks.
^ permalink raw reply
* Is it "GIT" or "Git" or "git"? Standardize documentation?
From: Sebastian Morr @ 2011-12-14 0:43 UTC (permalink / raw)
To: git
Okay, I'd like to hear opinions on this before creating a patch.
My perception is that "Git" is the name of the software, whereas "git"
is used to refer to the actual command. But "GIT" is all over the
documentation as well, most prominently at the top of README.
Would anyone mind if we replaced all occurrences of "GIT" in the
documentation with "Git"?
I suppose the release notes shouldn't be touched for historical reasons.
Completely unrelated: Why is it "Documentation/RelNotes" and not
something like "documentation/release-notes"? Almost everything else is
spelled either all-lower- or all-uppercase.
Sorry for being such a nazi...
^ permalink raw reply
* Re: Is it "GIT" or "Git" or "git"? Standardize documentation?
From: Andreas Ericsson @ 2011-12-14 1:01 UTC (permalink / raw)
To: Sebastian Morr; +Cc: git
In-Reply-To: <20111214004332.GA8464@thinkpad>
On 12/14/2011 01:43 AM, Sebastian Morr wrote:
> Okay, I'd like to hear opinions on this before creating a patch.
>
> My perception is that "Git" is the name of the software, whereas "git"
> is used to refer to the actual command. But "GIT" is all over the
> documentation as well, most prominently at the top of README.
> Would anyone mind if we replaced all occurrences of "GIT" in the
> documentation with "Git"?
> I suppose the release notes shouldn't be touched for historical reasons.
>
I doubt anyone cares all that much. I for one have absolutely no clue
what you're talking about, but if you think it looks better one way
than the other and care about it enough, just make the patch and send
it in for review. Consensus is never reached before there's code, and
hardly ever after either, but discussing something that *might* happen
and still doesn't affect my daily life feels utterly pointless.
> Completely unrelated: Why is it "Documentation/RelNotes" and not
> something like "documentation/release-notes"? Almost everything else is
> spelled either all-lower- or all-uppercase.
>
For tab-completion and directory listing reasons. Uppercase-D+tab puts
you in the right directory and uppercasing RelNotes makes it easy to
find among its many companions in that directory. It's fairly standard
procedure in the unix world to uppercase or camelcase the more important
documents, and especially when there's more than a small handful of files
in a single directory.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: Is it "GIT" or "Git" or "git"? Standardize documentation?
From: Junio C Hamano @ 2011-12-14 1:02 UTC (permalink / raw)
To: Sebastian Morr; +Cc: git
In-Reply-To: <20111214004332.GA8464@thinkpad>
Sebastian Morr <sebastian@morr.cc> writes:
> Okay, I'd like to hear opinions on this before creating a patch.
>
> My perception is that "Git" is the name of the software, whereas "git"
> is used to refer to the actual command.
And "GIT" is used interchangeably with "Git" whenever the document author
feels like it warrants a bit more visibility than usual in the context.
Think of it as typesetting in a font with small-caps or something ;-).
^ permalink raw reply
* Re: [PATCH] stash: Fix multiple error messages on create if no HEAD
From: Junio C Hamano @ 2011-12-14 1:16 UTC (permalink / raw)
To: Sebastian Morr; +Cc: git
In-Reply-To: <20111214001432.GA2959@thinkpad>
Sebastian Morr <sebastian@morr.cc> writes:
> This bugged me: In a new, empty repository:
>
> $ git stash
> fatal: bad revision 'HEAD'
> fatal: bad revision 'HEAD'
> fatal: Needed a single revision
> You do not have the initial commit yet
>
> With this patch:
>
> $ git stash
> You do not have the initial commit yet
Yeah, that looks tidier.
> With the --quiet option, I wouldn't expect diff-index to print error
> messages.
Even with --quiet, an error is an error.
Asking for a diff with the current HEAD when you do not have one yet _is_
an error and "diff-index" is correct to report the error. The bug
(i.e. "git stash" shows that error message) is in the program that calls
diff-index when the operation does not make sense.
"Hiding error" is not desirable, especially if it is only for giving a
cleaner error message for a narrow corner case that nobody cares
(i.e. running "stash" when you do not have any commit to go back to), with
the side effect that it hides _real_ errors that may help users notice
unusual situation (e.g. corrupted index file).
Probably the right way to fix it is to check if HEAD is a valid commit
before running any command that requires to have a valid HEAD (i.e.
create and save would need one; list, show, etc. would not) and give that
"You do not have the initial commit yet" message, before passing the
control to the implementations of these individual subcommands, without
touching the places you touched in this patch.
> no_changes () {
> - git diff-index --quiet --cached HEAD --ignore-submodules -- &&
> + git diff-index --quiet --cached HEAD --ignore-submodules -- 2>/dev/null &&
> git diff-files --quiet --ignore-submodules &&
> (test -z "$untracked" || test -z "$(untracked_files)")
> }
> @@ -67,7 +67,7 @@ create_stash () {
> fi
>
> # state of the base commit
> - if b_commit=$(git rev-parse --verify HEAD)
> + if b_commit=$(git rev-parse --quiet --verify HEAD)
> then
> head=$(git rev-list --oneline -n 1 HEAD --)
> else
^ permalink raw reply
* What's cooking in git.git (Dec 2011, #04; Tue, 13)
From: Junio C Hamano @ 2011-12-14 1:19 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in
'next'.
Here are the repositories that have my integration branches:
With maint, master, next, pu, todo:
git://git.kernel.org/pub/scm/git/git.git
git://repo.or.cz/alt-git.git
https://code.google.com/p/git-core/
https://github.com/git/git
With only maint and master:
git://git.sourceforge.jp/gitroot/git-core/git.git
git://git-core.git.sourceforge.net/gitroot/git-core/git-core
With all the topics and integration branches:
https://github.com/gitster/git
The preformatted documentation in HTML and man format are found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
--------------------------------------------------
[New Topics]
* jk/maint-fetch-status-table (2011-12-09) 1 commit
(merged to 'next' on 2011-12-09 at 159415e)
+ fetch: create status table using strbuf
Will merge to 'master'.
* ci/stripspace-docs (2011-12-12) 1 commit
(merged to 'next' on 2011-12-13 at 35b2cdf)
+ Update documentation for stripspace
* jk/maint-mv (2011-12-12) 5 commits
(merged to 'next' on 2011-12-13 at 58caedb)
+ mv: be quiet about overwriting
+ mv: improve overwrite warning
+ mv: make non-directory destination error more clear
+ mv: honor --verbose flag
+ docs: mention "-k" for both forms of "git mv"
* jk/maint-snprintf-va-copy (2011-12-12) 1 commit
(merged to 'next' on 2011-12-13 at d37a7e1)
+ compat/snprintf: don't look at va_list twice
* jn/maint-sequencer-fixes (2011-12-12) 7 commits
(merged to 'next' on 2011-12-13 at 5b3950c)
+ revert: stop creating and removing sequencer-old directory
+ Revert "reset: Make reset remove the sequencer state"
+ revert: do not remove state until sequence is finished
+ revert: allow single-pick in the middle of cherry-pick sequence
+ revert: pass around rev-list args in already-parsed form
+ revert: allow cherry-pick --continue to commit before resuming
+ revert: give --continue handling its own function
* mh/ref-api (2011-12-12) 51 commits
- repack_without_ref(): call clear_packed_ref_cache()
- read_packed_refs(): keep track of the directory being worked in
- is_refname_available(): query only possibly-conflicting references
- refs: read loose references lazily
- read_loose_refs(): take a (ref_entry *) as argument
- struct ref_dir: store a reference to the enclosing ref_cache
- sort_ref_dir(): take (ref_entry *) instead of (ref_dir *)
- do_for_each_ref_in_dir*(): take (ref_entry *) instead of (ref_dir *)
- add_entry(): take (ref_entry *) instead of (ref_dir *)
- search_ref_dir(): take (ref_entry *) instead of (ref_dir *)
- find_containing_direntry(): use (ref_entry *) instead of (ref_dir *)
- add_ref(): take (ref_entry *) instead of (ref_dir *)
- read_packed_refs(): take (ref_entry *) instead of (ref_dir *)
- find_ref(): take (ref_entry *) instead of (ref_dir *)
- is_refname_available(): take (ref_entry *) instead of (ref_dir *)
- get_loose_refs(): return (ref_entry *) instead of (ref_dir *)
- get_packed_refs(): return (ref_entry *) instead of (ref_dir *)
- refs: wrap top-level ref_dirs in ref_entries
- get_ref_dir(): keep track of the current ref_dir
- do_for_each_ref(): only iterate over the subtree that was requested
- refs: sort ref_dirs lazily
- sort_ref_dir(): do not sort if already sorted
- refs: store references hierarchically
- refs.c: rename ref_array -> ref_dir
- struct ref_entry: nest the value part in a union
- check_refname_component(): return 0 for zero-length components
- free_ref_entry(): new function
- refs.c: reorder definitions more logically
- is_refname_available(): reimplement using do_for_each_ref_in_array()
- names_conflict(): simplify implementation
- names_conflict(): new function, extracted from is_refname_available()
- repack_without_ref(): reimplement using do_for_each_ref_in_array()
- do_for_each_ref_in_arrays(): new function
- do_for_each_ref_in_array(): new function
- do_for_each_ref(): correctly terminate while processesing extra_refs
- add_ref(): take a (struct ref_entry *) parameter
- create_ref_entry(): extract function from add_ref()
- repack_without_ref(): remove temporary
- resolve_gitlink_ref_recursive(): change to work with struct ref_cache
- Pass a (ref_cache *) to the resolve_gitlink_*() helper functions
- resolve_gitlink_ref(): improve docstring
- get_ref_dir(): change signature
- refs: change signatures of get_packed_refs() and get_loose_refs()
- is_dup_ref(): extract function from sort_ref_array()
- add_ref(): add docstring
- parse_ref_line(): add docstring
- is_refname_available(): remove the "quiet" argument
- clear_ref_array(): rename from free_ref_array()
- refs: rename parameters result -> sha1
- refs: rename "refname" variables
- struct ref_entry: document name member
* nd/resolve-ref (2011-12-13) 3 commits
(merged to 'next' on 2011-12-13 at c7002e9)
+ Rename resolve_ref() to resolve_ref_unsafe()
+ Convert resolve_ref+xstrdup to new resolve_refdup function
+ revert: convert resolve_ref() to read_ref_full()
* tr/grep-threading (2011-12-12) 3 commits
- grep: disable threading in non-worktree case
- grep: enable threading with -p and -W using lazy attribute lookup
- grep: load funcname patterns for -W
Will merge to 'next' after taking another look.
* tr/pty-all (2011-12-12) 3 commits
- t/lib-terminal: test test-terminal's sanity
- test-terminal: set output terminals to raw mode
- test-terminal: give the child an empty stdin TTY
Will merge to 'next' after taking another look.
* jc/push-ignore-stale (2011-12-13) 2 commits
- push: --ignore-stale option
- set_ref_status_for_push(): use transport-flags abstraction
* jk/fetch-no-tail-match-refs (2011-12-13) 4 commits
(merged to 'next' on 2011-12-13 at 805c018)
+ connect.c: drop path_match function
+ fetch-pack: match refs exactly
+ t5500: give fully-qualified refs to fetch-pack
+ drop "match" parameter from get_remote_heads
* jk/maint-push-over-dav (2011-12-13) 2 commits
(merged to 'next' on 2011-12-13 at 45e376c)
+ http-push: enable "proactive auth"
+ t5540: test DAV push with authentication
--------------------------------------------------
[Cooking]
* rr/revert-cherry-pick (2011-12-09) 9 commits
. revert: simplify communicating command-line arguments
. revert: report fine-grained error messages from insn parser
. revert: allow mixed pick and revert instructions
. t3510 (cherry-pick-sequencer): remove malformed sheet 2
. t3510 (cherry-pick-sequencer): use exit status
. revert: simplify getting commit subject in format_todo()
. revert: tolerate extra spaces, tabs in insn sheet
. revert: make commit subjects in insn sheet optional
. revert: free msg in format_todo()
Ejected for now, to give higher priority to jn/maint-sequencer-fixes
topic.
* ew/keepalive (2011-12-05) 1 commit
(merged to 'next' on 2011-12-13 at 1b5d5c4)
+ enable SO_KEEPALIVE for connected TCP sockets
* jc/checkout-m-twoway (2011-12-11) 2 commits
(merged to 'next' on 2011-12-11 at b61057f)
+ Test 'checkout -m -- path'
(merged to 'next' on 2011-12-09 at c946009)
+ checkout -m: no need to insist on having all 3 stages
* tr/cache-tree (2011-12-06) 5 commits
(merged to 'next' on 2011-12-13 at e0da64d)
+ reset: update cache-tree data when appropriate
+ commit: write cache-tree data when writing index anyway
+ Refactor cache_tree_update idiom from commit
+ Test the current state of the cache-tree optimization
+ Add test-scrap-cache-tree
* tr/userdiff-c-returns-pointer (2011-12-06) 1 commit
(merged to 'next' on 2011-12-09 at 0b6a092)
+ userdiff: allow * between cpp funcname words
Will merge to 'master'.
* jc/commit-amend-no-edit (2011-12-08) 5 commits
(merged to 'next' on 2011-12-09 at b9cfa4e)
+ test: commit --amend should honor --no-edit
+ commit: honour --no-edit
+ t7501 (commit): modernize style
+ test: remove a porcelain test that hard-codes commit names
+ test: add missing "&&" after echo command
* jl/submodule-status-failure-report (2011-12-08) 1 commit
(merged to 'next' on 2011-12-09 at 53eb3b3)
+ diff/status: print submodule path when looking for changes fails
Will merge to 'master'.
* ks/tag-cleanup (2011-12-09) 1 commit
(merged to 'next' on 2011-12-09 at cbea045)
+ git-tag: introduce --cleanup option
Will merge to 'master'.
* rr/test-chaining (2011-12-11) 7 commits
(merged to 'next' on 2011-12-13 at b08445e)
+ t3401: use test_commit in setup
+ t3401: modernize style
+ t3040 (subprojects-basic): fix '&&' chaining, modernize style
+ t1510 (worktree): fix '&&' chaining
+ t3030 (merge-recursive): use test_expect_code
+ test: fix '&&' chaining
+ t3200 (branch): fix '&&' chaining
* bc/maint-apply-check-no-patch (2011-12-05) 2 commits
(merged to 'next' on 2011-12-09 at fc780cd)
+ builtin/apply.c: report error on failure to recognize input
+ t/t4131-apply-fake-ancestor.sh: fix broken test
Will merge to 'master'.
* aw/rebase-i-stop-on-failure-to-amend (2011-11-30) 1 commit
(merged to 'next' on 2011-12-09 at a117e83)
+ rebase -i: interrupt rebase when "commit --amend" failed during "reword"
* jc/split-blob (2011-12-01) 6 commits
. WIP (streaming chunked)
- chunked-object: fallback checkout codepaths
- bulk-checkin: support chunked-object encoding
- bulk-checkin: allow the same data to be multiply hashed
- new representation types in the packstream
- varint-in-pack: refactor varint encoding/decoding
(this branch uses jc/stream-to-pack.)
Not ready. At least pack-objects and fsck need to learn the new encoding
for the series to be usable locally, and then index-pack/unpack-objects
needs to learn it to be used remotely.
* jh/fast-import-notes (2011-11-28) 3 commits
(merged to 'next' on 2011-12-09 at 2b01132)
+ fast-import: Fix incorrect fanout level when modifying existing notes refs
+ t9301: Add 2nd testcase exposing bugs in fast-import's notes fanout handling
+ t9301: Fix testcase covering up a bug in fast-import's notes fanout handling
Will merge to 'master'.
* tj/maint-imap-send-remove-unused (2011-11-23) 2 commits
(merged to 'next' on 2011-12-09 at 877cc11)
+ Merge branch 'maint' into tj/imap-send-remove-unused
+ imap-send: Remove unused 'use_namespace' variable
Will merge to 'master'.
* cn/maint-lf-to-crlf-filter (2011-11-28) 1 commit
(merged to 'next' on 2011-12-09 at c374d14)
+ convert: track state in LF-to-CRLF filter
Will merge to 'master'.
* jn/branch-move-to-self (2011-11-28) 2 commits
(merged to 'next' on 2011-12-09 at 7d27260)
+ Allow checkout -B <current-branch> to update the current branch
+ branch: allow a no-op "branch -M <current-branch> HEAD"
Will merge to 'master'.
* jk/credentials (2011-12-12) 24 commits
- contrib: add credential helper for OS X Keychain
- Makefile: OS X has /dev/tty
- Makefile: linux has /dev/tty
- credential: use git_prompt instead of git_getpass
- prompt: use git_terminal_prompt
- add generic terminal prompt function
- refactor git_getpass into generic prompt function
- move git_getpass to its own source file
- imap-send: don't check return value of git_getpass
- imap-send: avoid buffer overflow
(merged to 'next' on 2011-12-12 at 7a6d658)
+ t: add test harness for external credential helpers
+ credentials: add "store" helper
+ strbuf: add strbuf_add*_urlencode
+ Makefile: unix sockets may not available on some platforms
+ credentials: add "cache" helper
+ docs: end-user documentation for the credential subsystem
+ credential: make relevance of http path configurable
+ credential: add credential.*.username
+ credential: apply helper config
+ http: use credential API to get passwords
+ credential: add function for parsing url components
+ introduce credentials API
+ t5550: fix typo
+ test-lib: add test_config_global variant
Looking good. Probably split the later part into its own topic and
merge the parts already in 'next' to 'master' soonish.
* nd/ignore-might-be-precious (2011-11-28) 2 commits
(merged to 'next' on 2011-12-09 at 1a94553)
+ checkout,merge: disallow overwriting ignored files with --no-overwrite-ignore
+ Merge branch 'nd/maint-ignore-exclude' into nd/ignore-might-be-precious
Will merge to 'master'.
* jk/upload-archive-use-start-command (2011-11-21) 1 commit
(merged to 'next' on 2011-12-09 at 88cb83a)
+ upload-archive: use start_command instead of fork
* jk/maint-1.6.2-upload-archive (2011-11-21) 1 commit
+ archive: don't let remote clients get unreachable commits
(this branch is used by jk/maint-upload-archive.)
* jk/maint-upload-archive (2011-11-21) 1 commit
(merged to 'next' on 2011-12-09 at 03deb16)
+ Merge branch 'jk/maint-1.6.2-upload-archive' into jk/maint-upload-archive
(this branch uses jk/maint-1.6.2-upload-archive.)
Will merge to 'master'.
* ab/enable-i18n (2011-12-05) 1 commit
(merged to 'next' on 2011-12-13 at 65af8cd)
+ i18n: add infrastructure for translating Git with gettext
* jc/signed-commit (2011-11-29) 5 commits
- gpg-interface: allow use of a custom GPG binary
- pretty: %G[?GS] placeholders
- test "commit -S" and "log --show-signature"
- log: --show-signature
- commit: teach --gpg-sign option
Not exactly urgent.
* jc/stream-to-pack (2011-12-01) 5 commits
(merged to 'next' on 2011-12-09 at d0fd605)
+ bulk-checkin: replace fast-import based implementation
+ csum-file: introduce sha1file_checkpoint
+ finish_tmp_packfile(): a helper function
+ create_tmp_packfile(): a helper function
+ write_pack_header(): a helper function
(this branch is used by jc/split-blob.)
Teaches "git add" to send large-ish blob data straight to a packfile.
This is a continuation to the "large file support" topic. The codepath to
move data from worktree to repository is made aware of streaming, just
like the checkout codepath that goes the other way, which was done in the
previous "large file support" topic in the 1.7.7 cycle.
* jn/gitweb-side-by-side-diff (2011-10-31) 8 commits
(merged to 'next' on 2011-12-09 at 7662e58)
+ gitweb: Add navigation to select side-by-side diff
+ gitweb: Use href(-replay=>1,...) for formats links in "commitdiff"
+ t9500: Add basic sanity tests for side-by-side diff in gitweb
+ t9500: Add test for handling incomplete lines in diff by gitweb
+ gitweb: Give side-by-side diff extra CSS styling
+ gitweb: Add a feature to show side-by-side diff
+ gitweb: Extract formatting of diff chunk header
+ gitweb: Refactor diff body line classification
Replaces a series from Kato Kazuyoshi on the same topic.
Will merge to 'master'.
^ 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