* Re: [PATCH] ls-remote: a lone "-h" is asking for help
From: Junio C Hamano @ 2011-09-16 19:35 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <CAGdFq_h474OrLzP+CHj_eSdSp53n8x7jz1ORT16dOhvRdQMP+g@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> Should we really have "-h" as a short for anything other than "--help"
> in the first place?
You have been here long enough to know the answer to that question, no?
The answer would be different if you are starting a new project from
scratch and if you are talking about a project with existing userbase.
^ permalink raw reply
* Re: [PATCH] ls-remote: a lone "-h" is asking for help
From: Sverre Rabbelier @ 2011-09-16 19:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vobykfj7g.fsf@alter.siamese.dyndns.org>
Heya,
On Fri, Sep 16, 2011 at 20:14, Junio C Hamano <gitster@pobox.com> wrote:
> It does not give a short-help for the command. Instead because "-h" is a
> synonym for "--heads", it runs "git ls-remote --heads", and because there
> is no remote specified on the command line, we run it against the default
> "origin" remote, hence end up doing the same as
Should we really have "-h" as a short for anything other than "--help"
in the first place?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH v3] request-pull: state what commit to expect
From: Junio C Hamano @ 2011-09-16 19:04 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <7vobynui8a.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> I think that would probably be a good idea, although I'd actually
>> prefer you to be more verbose, and more human-friendly, and actually
>> talk about the commit in a readable way. Get rid of the *horrible*
>> BRANCH-NOT-VERIFIED message...
>>
>> Top commit 1f51b001cccf: "Merge branches 'cns3xxx/fixes',
>> 'omap/fixes' and 'davinci/fixes' into fixes"
>>
>> and at *that* point you might have a "UNVERIFIED" notice for people
>> to check if they forgot to push.
>
> That UNVERIFIED thing was neither my favorite nor my idea, and I'd happily
> rip it out in any second ;-)
So this is the third round.
-- >8 --
The message gives a detailed explanation of the commit the requester based
the changes on, but lacks information that is necessary for the person who
performs a fetch & merge in order to verify that the correct branch was
fetched when responding to the pull request.
Add a few more lines to describe the commit at the tip expected to be
fetched to the same level of detail as the base commit.
Also update the warning message slightly when the script notices that the
commit may not have been pushed.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
A UI wart that we cannot fix without breaking backward compatibility is
that the "end" parameter (which defaults to HEAD and is assigned to $head
variable in the script) the requestor uses from the command line names a
commit (often the name of a local branch), but for the purpose of telling
which ref to pull from the public repository, that is a _wrong_ thing to
give to the recipient.
Because the act of generating a request-pull message and the act of
pushing to the public repository are not linked in any way, the script
does not know _how_ the requestor caused (or intends to cause) the commit
to sit at the tip of which branch. There is no guarantee that a lazy "git
push" that relies on the configured refspec will be (or have been) used,
so even parsing the output from "git push -n --porcelain -v $there" would
not tell the script which branch the commit to be pulled is to be pushed
out to, or if the branch is consistent with the request message.
The use of "git ls-remote" in the script and picking one of the refs that
matches the commit object at random from its output is unsatisfactory, but
that is unfortunately the best this script could do without correcting the
design mistake and redefining what the "end" parameter means.
If we can break the backward compatibility and redefine that the "end"
parameter now means the name of the branch at the public repository, it
would make the operation a lot more robust. We could then:
- $branch is what is given by the end user (it is an error not to give
the "end" parameter);
- run "git ls-remote $url $head" to find $headrev;
- generate the message and shortlog using the information obtained from
$url; and
- get rid of "did you forget to push" message.
We could allow adding yet another argument which names a commit object
locally, and make sure if the $headrev observed by ls-remote does not
match it.
---
git-request-pull.sh | 34 +++++++++++++++++++---------------
t/t5150-request-pull.sh | 6 ++++++
2 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/git-request-pull.sh b/git-request-pull.sh
index afb75e8..438e7eb 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -35,7 +35,7 @@ do
shift
done
-base=$1 url=$2 head=${3-HEAD}
+base=$1 url=$2 head=${3-HEAD} status=0
test -n "$base" && test -n "$url" || usage
baserev=$(git rev-parse --verify "$base"^0) &&
@@ -51,25 +51,29 @@ find_matching_branch="/^$headrev "'refs\/heads\//{
}'
branch=$(git ls-remote "$url" | sed -n -e "$find_matching_branch")
url=$(git ls-remote --get-url "$url")
-if test -z "$branch"
-then
- echo "warn: No branch of $url is at:" >&2
- git log --max-count=1 --pretty='tformat:warn: %h: %s' $headrev >&2
- echo "warn: Are you sure you pushed $head there?" >&2
- echo >&2
- echo >&2
- branch=..BRANCH.NOT.VERIFIED..
- status=1
-fi
git show -s --format='The following changes since commit %H:
%s (%ci)
-are available in the git repository at:' $baserev &&
-echo " $url $branch" &&
-echo &&
+are available in the git repository at:
+' $baserev &&
+echo " $url${branch+ $branch}" &&
+git show -s --format='
+for you to fetch changes up to %H:
+
+ %s (%ci)
+
+----------------------------------------------------------------' $headrev &&
git shortlog ^$baserev $headrev &&
-git diff -M --stat --summary $patch $merge_base..$headrev || exit
+git diff -M --stat --summary $patch $merge_base..$headrev || status=1
+
+if test -z "$branch"
+then
+ echo "warn: No branch of $url is at:" >&2
+ git show -s --format='warn: %h: %s' $headrev >&2
+ echo "warn: Are you sure you pushed '$head' there?" >&2
+ status=1
+fi
exit $status
diff --git a/t/t5150-request-pull.sh b/t/t5150-request-pull.sh
index 9cc0a42..5bd1682 100755
--- a/t/t5150-request-pull.sh
+++ b/t/t5150-request-pull.sh
@@ -193,8 +193,14 @@ test_expect_success 'pull request format' '
SUBJECT (DATE)
are available in the git repository at:
+
URL BRANCH
+ for you to fetch changes up to OBJECT_NAME:
+
+ SUBJECT (DATE)
+
+ ----------------------------------------------------------------
SHORTLOG
DIFFSTAT
--
1.7.7.rc1.3.g559357
^ permalink raw reply related
* Re: [PATCH] gitweb: Strip non-printable characters from syntax highlighter output
From: Jakub Narebski @ 2011-09-16 18:58 UTC (permalink / raw)
To: Junio C Hamano
Cc: Christopher M. Fuhrman, git, Christopher Wilson, Sylvain Rabot
In-Reply-To: <7vwrd8fnxr.fsf@alter.siamese.dyndns.org>
On Fri, 16 Sep 2011, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> Micronit:
>
> > +# Sanitize for use in XHTML + application/xml+xhtm (valid XML 1.0)
> > +sub sanitize {
> > + my $str = shift;
> > +
> > + return undef unless defined $str;
>
> Given that the _whole_ point of this subroutine is to make $str safe for
> printing, wouldn't you want to either (1) die, declaring that feeding an
> undef to this subroutine is a programming error, or (2) return an empty
> string?
Well, that
return undef unless defined $str;
line is copy'n'paste (as is most of sanitize() body) from esc_html().
This line was added in 1df4876 (gitweb: Protect escaping functions against
calling on undef, 2010-02-07) with the following explanation
This is a bit of future-proofing esc_html and friends: when called
with undefined value they would now would return undef... which would
probably mean that error would still occur, but closer to the source
of problem.
This means that we can safely use
esc_html(shift) || "Internal Server Error"
in die_error() instead of
esc_html(shift || "Internal Server Error")
So actually now I see that while this line is good to have in esc_html(),
it is not really necessary in sanitize().
But anyway we don't want to replace undef with an empty string; undef is
(usually) an error, and we want to catch it, not to hide it.
> Given that the input to this function is from the result of feeding $line
> to untabify, which relies on $line being defined, and that $line comes
> from "while (my $line = <$fd>)" (and then chomp $line), it may be Ok for
> this subroutine to make the same assumption as untabify makes.
Right.
Passing undef to sanitize() is usually an error, and we don't want to hide
it. We want for gitweb test to detect it.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 2/2] grep --no-index: don't use git standard exclusions
From: Bert Wesarg @ 2011-09-16 18:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmxe5pp4n.fsf@alter.siamese.dyndns.org>
On Thu, Sep 15, 2011 at 21:44, Junio C Hamano <gitster@pobox.com> wrote:
> Bert Wesarg <bert.wesarg@googlemail.com> writes:
>
>> On Wed, Jul 20, 2011 at 22:57, Junio C Hamano <gitster@pobox.com> wrote:
>>> - Since 3081623 (grep --no-index: allow use of "git grep" outside a git
>>> repository, 2010-01-15) and 59332d1 (Resurrect "git grep --no-index",
>>> 2010-02-06), "grep --no-index" incorrectly paid attention to the
>>> exclude patterns. We shouldn't have, and we'd fix that bug.
>>
>> Fix this bug.
>
> On a busy list like this, it is brutal to withhold the better clues you
> certainly had when you wrote this message that would help people to locate
> the original message you are quoting, and instead forcing everybody to go
> back 5000 messages in the archive to find it. E.g.
>
> http://article.gmane.org/gmane.comp.version-control.git/177548
> http://mid.gmane.org/7vzkk86577.fsf@alter.siamese.dyndns.org
>
> Or perhaps have
>
> References: <7vzkk86577.fsf@alter.siamese.dyndns.org>
>
> in the header.
Sorry for this patch with insufficient references and context. I
realized it too late, and the time was short.
>
> As to the patch, I think this addresses only one fourth of the issue
> identified in that discussion (it is a good starting point, though).
>
I thought to split the bug fixing from the new features. I already
implemented --exclude-standard, including --exclude=<patter>,
--exclude-from=<file> and --exclude-per-directory=<file>. But it's not
ready because of missing tests and documentation. So I just spilled
this bug fix patch out and will now work on the next part.
> With this change, it would now make sense to teach --[no-]exclude-standard
> to "git grep", and "--exclude-standard" is immediately useful when used
> with "--no-index". When we add "git grep --untracked-too" (which lets us
> search in the working tree), people can add "--no-exclude-standard" to the
> command line to say "I want to find the needle even from an ignored file".
Would '--untracked-too' only be a synonym for '--no-index
--exclude-standard', i.e. the current behavior?
Bert
>
> Thanks.
>
^ permalink raw reply
* [PATCH] ls-remote: a lone "-h" is asking for help
From: Junio C Hamano @ 2011-09-16 18:14 UTC (permalink / raw)
To: git
What should happen if you run this command?
$ git ls-remote -h
It does not give a short-help for the command. Instead because "-h" is a
synonym for "--heads", it runs "git ls-remote --heads", and because there
is no remote specified on the command line, we run it against the default
"origin" remote, hence end up doing the same as
$ git ls-remote --heads origin
Fix this counter-intuitive behaviour by special casing a lone "-h" that
does not have anything else on the command line and calling usage().
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/ls-remote.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/builtin/ls-remote.c b/builtin/ls-remote.c
index 1022309..41c88a9 100644
--- a/builtin/ls-remote.c
+++ b/builtin/ls-remote.c
@@ -43,6 +43,9 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix)
struct transport *transport;
const struct ref *ref;
+ if (argc == 2 && !strcmp("-h", argv[1]))
+ usage(ls_remote_usage);
+
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
^ permalink raw reply related
* Re: [PATCH] gitweb: Strip non-printable characters from syntax highlighter output
From: Christopher M. Fuhrman @ 2011-09-16 18:11 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git, Christopher Wilson, Sylvain Rabot
In-Reply-To: <201109161441.58946.jnareb@gmail.com>
Howdy,
On Fri, 16 Sep 2011 at 5:41am, Jakub Narebski wrote:
> The commit message is from Christopher, but I have replaced his solution
> of stripping non-printable characters via col(1) program by having gitweb
> strip characters not allowed in XML.
>
> Christopher, could you check that it fixes your issue?
After applying the patch, I tested it successfully against the following
files:
* linux.git : arch/ia64/kernel/unwind.c
* git.git : t/t3902-quoted.sh
Furthermore, I'm pleased to report that non en_US.UTF8 characters (e.g.,
Chinese hanzi) as found in t3902-quoted.sh are displayed properly when
highlight is enabled.
Tested Web Browsers:
* Safari (5.1 (6534.50)
* Firefox 6.0.2 under Mac OS X Snow Leopard
* Google Chrome 13.0.782.220 under OpenSuSE 11.4
>
> gitweb/gitweb.perl | 14 +++++++++++++-
> 1 files changed, 13 insertions(+), 1 deletions(-)
>
Cheers!
--
Chris Fuhrman
cfuhrman@panix.com
^ permalink raw reply
* Re: zealous git convert determined to set up git server
From: Sitaram Chamarty @ 2011-09-16 17:00 UTC (permalink / raw)
To: Joshua Stoutenburg; +Cc: Jakub Narebski, Git List
In-Reply-To: <CAOZxsTqtW=DD7zFwQLjknJR8g0nnh0WPUPna6_np4bVoGnSntQ@mail.gmail.com>
On Thu, Sep 15, 2011 at 5:08 PM, Joshua Stoutenburg
<jehoshua02@gmail.com> wrote:
> Question 2: It seems gitolite is the popular choice for git user
> management. Any reason why?
Well it *is* pretty darn powerful (I'm the author; allow me some
preening!) but I believe the real reason is that it is the most
*transparent* solution.
The other contendors *all* involve web-based setup/management, and
often include things like wikis, issue tracking, graphical views on
the web, commenting on commits, code review (in case of gerrit), etc.
etc. Gitolite is the only system where the end user (developer) may
not even realise it's installed unless he runs up against an access
restriction.
^ permalink raw reply
* Re: [PATCH] gitweb: Strip non-printable characters from syntax highlighter output
From: Junio C Hamano @ 2011-09-16 16:32 UTC (permalink / raw)
To: Jakub Narebski
Cc: Christopher M. Fuhrman, git, Christopher Wilson, Sylvain Rabot
In-Reply-To: <201109161441.58946.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> The commit message is from Christopher, but I have replaced his solution
> of stripping non-printable characters via col(1) program by having gitweb
> strip characters not allowed in XML.
>
> Christopher, could you check that it fixes your issue?
Thanks.
Micronit:
> +# Sanitize for use in XHTML + application/xml+xhtm (valid XML 1.0)
> +sub sanitize {
> + my $str = shift;
> +
> + return undef unless defined $str;
Given that the _whole_ point of this subroutine is to make $str safe for
printing, wouldn't you want to either (1) die, declaring that feeding an
undef to this subroutine is a programming error, or (2) return an empty
string?
Given that the input to this function is from the result of feeding $line
to untabify, which relies on $line being defined, and that $line comes
from "while (my $line = <$fd>)" (and then chomp $line), it may be Ok for
this subroutine to make the same assumption as untabify makes.
^ permalink raw reply
* Re: Re* [PATCH 4/4] Add documentation for ref namespaces
From: Junio C Hamano @ 2011-09-16 16:20 UTC (permalink / raw)
To: Jamey Sharp
Cc: Ævar Arnfjörð Bjarmason, Shawn O. Pearce,
Johannes Schindelin, Jeff King, Jakub Narebski, git,
Josh Triplett
In-Reply-To: <20110916034051.GH3144@oh.minilop.net>
Jamey Sharp <jamey@minilop.net> writes:
> Assuming that you're happy with this level of detail, and that the
> AsciiDoc syntax is correct (I'm not familiar enough with it), I'm happy
> with the patch you propose---
>
> Reviewed-by: Jamey Sharp <jamey@minilop.net>
Thanks.
^ permalink raw reply
* Re: [PATCH/RFC] bash: add --word-diff option to diff [AND --set-upstream TO push] auto-completion
From: Rodrigo Rosenfeld Rosas @ 2011-09-16 15:56 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Jonathan Nieder, Thomas Rast, git
In-Reply-To: <20110913233712.GE2078@goldbirke>
While on the topic, it would also be interesting to add "--set-upstream"
to "git push" autocompletion. Don't you agree?
Cheers, Rodrigo.
Em 13-09-2011 20:37, SZEDER Gábor escreveu:
> On Wed, Sep 14, 2011 at 01:29:41AM +0200, SZEDER Gábor wrote:
>> Or is it just too late here and I'm missing something
>> obvious?
>>
>> Completing the mode for --word-diff=<TAB> is a good idea, but c'mon,
>> there are plenty of examples ;) Have a look at _git_am(),
>> _git_format_patch(), or _git_init() for something easy, and
>> _git_commit(), _git_log(), or _git_notes() for something fancy.
>>
>> Note that --word-diff= is also valid for log and shortlog, so the same
>> can be done there, too.
>
> Not shortlog, show. It's definitely too late... ;)
>
>
^ permalink raw reply
* Re: [PATCH 2/2] check_expirations: don't copy over same element
From: Jeff King @ 2011-09-16 15:47 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, git, Brian Gernhardt
In-Reply-To: <29010bf6134beb20efca498e7b4f7a9d9bdb21a6.1316173346.git.trast@student.ethz.ch>
On Fri, Sep 16, 2011 at 01:51:35PM +0200, Thomas Rast wrote:
> diff --git a/credential-cache--daemon.c b/credential-cache--daemon.c
> index d6769b1..128c5ce 100644
> --- a/credential-cache--daemon.c
> +++ b/credential-cache--daemon.c
> @@ -77,7 +77,8 @@ static int check_expirations(void)
> free(entries[i].item.unique);
> free(entries[i].item.username);
> free(entries[i].item.password);
> - memcpy(&entries[i], &entries[entries_nr], sizeof(*entries));
> + if (i != entries_nr)
> + memcpy(&entries[i], &entries[entries_nr], sizeof(*entries));
Thanks. I even remember while writing this loop considering the case of
(i == entries_nr), but decided it didn't need special-casing. But I
obviously forgot about memcpy.
Both this and the prior patch are:
Acked-by: Jeff King <peff@peff.net>
-Peff
^ permalink raw reply
* Re: Problem with submodule merge
From: Heiko Voigt @ 2011-09-16 14:57 UTC (permalink / raw)
To: Nicolas Morey-Chaisemartin; +Cc: git
In-Reply-To: <4E734582.6030704@morey-chaisemartin.com>
Hi,
this looks like you have hit a codepath where the submodules object
database is not added to the object database. I am not sure why.
Could you try my patch that moves the merge search into a forked process:
3dcb369b allow multiple calls to submodule merge search for the same path
That should solve the issue as a side effect. Its currently in Junio's
pu branch.
Cheers Heiko
On Fri, Sep 16, 2011 at 02:48:02PM +0200, Nicolas Morey-Chaisemartin wrote:
> Hi,
>
> We have meet an issue few times at work with submodule merge.
> I'm running git 1.7.7-rc1 build from master on FC15 x86_64 but I've seen the issue on other ditro with older (stable) versions
>
> I still haven't figured out exactly when it happends but here are the symptoms:
>
> 1) I commited some updates for a submodule in our integration repo.
> 2) I pulled a remote branch of the integration repo which had an update on the same submodule (but different SHAs)
> 3) When the merge driver try to find a following commit for the submodule, I get some (sometimes many) error messages about refs that point to invalid objects:
>
> [nmorey@sat:SigmaCToolchain (user/nmorey/dev/0.3.0 *%>)]$ git merge origin/prerelease/0.3-0
> error: refs/heads/user/nmorey/master does not point to a valid object!
> error: refs/remotes/origin/dev/cpp does not point to a valid object!
> error: refs/remotes/origin/dev/scuk does not point to a valid object!
> error: refs/remotes/origin/dev/sys_agents does not point to a valid object!
> error: refs/remotes/origin/user/bbodin/cea does not point to a valid object!
> error: refs/remotes/origin/user/borgogoz/master does not point to a valid object!
> warning: Failed to merge submodule db (merge following commits not found)
> Auto-merging db
> CONFLICT (submodule): Merge conflict in db
> Automatic merge failed; fix conflicts and then commit the result.
>
>
> I checked and the object really exists in the submodule but is in a pack.
>
> >From checking the strace, git looks for a the object in db/.git/objects/... whch does not exists
> And from what I could figure it, the issue seems to be coming from find_pack_entry which does not return 1 so git goes looking for loose object
> and cannot find any (as expected).
> This is not a big issue as it just outputs errors about refs and does not block the user but it gets quite scary when there are a few hundreds of them !
>
>
> I kept a tarball of the repo so I can provide more info/logs/trace if needed.
>
> Nicolas
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Problem with submodule merge
From: Nicolas Morey-Chaisemartin @ 2011-09-16 12:48 UTC (permalink / raw)
To: git
Hi,
We have meet an issue few times at work with submodule merge.
I'm running git 1.7.7-rc1 build from master on FC15 x86_64 but I've seen the issue on other ditro with older (stable) versions
I still haven't figured out exactly when it happends but here are the symptoms:
1) I commited some updates for a submodule in our integration repo.
2) I pulled a remote branch of the integration repo which had an update on the same submodule (but different SHAs)
3) When the merge driver try to find a following commit for the submodule, I get some (sometimes many) error messages about refs that point to invalid objects:
[nmorey@sat:SigmaCToolchain (user/nmorey/dev/0.3.0 *%>)]$ git merge origin/prerelease/0.3-0
error: refs/heads/user/nmorey/master does not point to a valid object!
error: refs/remotes/origin/dev/cpp does not point to a valid object!
error: refs/remotes/origin/dev/scuk does not point to a valid object!
error: refs/remotes/origin/dev/sys_agents does not point to a valid object!
error: refs/remotes/origin/user/bbodin/cea does not point to a valid object!
error: refs/remotes/origin/user/borgogoz/master does not point to a valid object!
warning: Failed to merge submodule db (merge following commits not found)
Auto-merging db
CONFLICT (submodule): Merge conflict in db
Automatic merge failed; fix conflicts and then commit the result.
I checked and the object really exists in the submodule but is in a pack.
>From checking the strace, git looks for a the object in db/.git/objects/... whch does not exists
And from what I could figure it, the issue seems to be coming from find_pack_entry which does not return 1 so git goes looking for loose object
and cannot find any (as expected).
This is not a big issue as it just outputs errors about refs and does not block the user but it gets quite scary when there are a few hundreds of them !
I kept a tarball of the repo so I can provide more info/logs/trace if needed.
Nicolas
^ permalink raw reply
* Re: [PATCH/RFC] add lame win32 credential-helper
From: Stephen Bash @ 2011-09-16 12:59 UTC (permalink / raw)
To: kusmabite; +Cc: git, jaysoffian, gitster, Jeff King
In-Reply-To: <CABPQNSZjGzyxJKWRDDWxRj_SLdC1Y_9TxnAMOA+b-Pw3+X-E7w@mail.gmail.com>
----- Original Message -----
> From: "Erik Faye-Lund" <kusmabite@gmail.com>
> To: "Jeff King" <peff@peff.net>
> Cc: git@vger.kernel.org, jaysoffian@gmail.com, gitster@pobox.com
> Sent: Thursday, September 15, 2011 5:48:30 PM
> Subject: Re: [PATCH/RFC] add lame win32 credential-helper
>
> > If it's too hard to adapt it to whatever IPC
> > mechanism would be appropriate on Windows, we can just leave it out
> > on that platform.
> >
> > But the core code in git itself should be pretty straight forward.
>
> I didn't mean that it was impossible to port, just that it didn't compile
> as-is. I haven't looked into fixing up the code so it compiles on Windows
> again myself. And I'm not really planning to; I have little git-time
> these days, and little knowledge of how unix-sockets works...
This may be common knowledge, but from our brief experiment with them last fall, Windows Named Pipes are fairly similar to Unix Domain Sockets (not named FIFOs as one would expect...). We didn't quite get a perfect replacement using preprocessor macros, but I think you can get pretty close (we eventually dumped the idea in favor of straight TCP sockets that behave the same on all our platforms of interest).
HTH,
Stephen
^ permalink raw reply
* [PATCH] gitweb: Strip non-printable characters from syntax highlighter output
From: Jakub Narebski @ 2011-09-16 12:41 UTC (permalink / raw)
To: Junio C Hamano, Christopher M. Fuhrman
Cc: git, Christopher Wilson, Sylvain Rabot
In-Reply-To: <201108270006.19289.jnareb@gmail.com>
The current code, as is, passes control characters, such as form-feed
(^L) to highlight which then passes it through to the browser. User
agents (web browsers) that support 'application/xhtml+xml' usually
require that web pages declared as XHTML and with this mimetype are
well-formed XML. Unescaped control characters cannot appear within a
contents of a valid XML document.
This will cause the browser to display one of the following warnings:
* Safari v5.1 (6534.50) & Google Chrome v13.0.782.112:
This page contains the following errors:
error on line 657 at column 38: PCDATA invalid Char value 12
Below is a rendering of the page up to the first error.
* Mozilla Firefox 3.6.19 & Mozilla Firefox 5.0:
XML Parsing Error: not well-formed
Location:
http://path/to/git/repo/blah/blah
Both errors were generated by gitweb.perl v1.7.3.4 w/ highlight 2.7
using arch/ia64/kernel/unwind.c from the Linux kernel.
When syntax highlighter is not used, control characters are replaced
by esc_html(), but with syntax highlighter they were passed through to
browser (to_utf8() doesn't remove control characters).
Introduce sanitize() subroutine which strips forbidden characters, but
does not perform HTML escaping, and use it in git_blob() to sanitize
syntax highlighter output for XHTML.
Note that excluding "\t" (U+0009), "\n" (U+000A) and "\r" (U+000D) is
not strictly necessary, atleast for currently the only callsite: "\t"
tabs are replaced by spaces by untabify(), "\n" is stripped from each
line before processing it, and replacing "\r" could be considered
improvement.
Originally-by: Christopher M. Fuhrman <cfuhrman@panix.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
The commit message is from Christopher, but I have replaced his solution
of stripping non-printable characters via col(1) program by having gitweb
strip characters not allowed in XML.
Christopher, could you check that it fixes your issue?
gitweb/gitweb.perl | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 70a576a..c28b847 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1517,6 +1517,17 @@ sub esc_path {
return $str;
}
+# Sanitize for use in XHTML + application/xml+xhtm (valid XML 1.0)
+sub sanitize {
+ my $str = shift;
+
+ return undef unless defined $str;
+
+ $str = to_utf8($str);
+ $str =~ s|([[:cntrl:]])|($1 =~ /[\t\n\r]/ ? $1 : quot_cec($1))|eg;
+ return $str;
+}
+
# Make control characters "printable", using character escape codes (CEC)
sub quot_cec {
my $cntrl = shift;
@@ -6484,7 +6495,8 @@ sub git_blob {
$nr++;
$line = untabify($line);
printf qq!<div class="pre"><a id="l%i" href="%s#l%i" class="linenr">%4i</a> %s</div>\n!,
- $nr, esc_attr(href(-replay => 1)), $nr, $nr, $syntax ? to_utf8($line) : esc_html($line, -nbsp=>1);
+ $nr, esc_attr(href(-replay => 1)), $nr, $nr,
+ $syntax ? sanitize($line) : esc_html($line, -nbsp=>1);
}
}
close $fd
--
1.7.6
^ permalink raw reply related
* [PATCH 2/2] check_expirations: don't copy over same element
From: Thomas Rast @ 2011-09-16 11:51 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Brian Gernhardt
In-Reply-To: <a6397f7f28a5adcd34aeac98cca6500e336698aa.1316173346.git.trast@student.ethz.ch>
The credentials expiry loop looks at a credential, and if it's
expired, frees it and memcpy()s the last credential in the now free
place.
This results in a memcpy() with source=destination, which technically
yields undefined behaviour. Instead of turning it into a memmove,
don't copy anything if we deleted the last entry.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Valgrind complained. Sorry for not running it earlier when we were
discussing the poll issue...
credential-cache--daemon.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/credential-cache--daemon.c b/credential-cache--daemon.c
index d6769b1..128c5ce 100644
--- a/credential-cache--daemon.c
+++ b/credential-cache--daemon.c
@@ -77,7 +77,8 @@ static int check_expirations(void)
free(entries[i].item.unique);
free(entries[i].item.username);
free(entries[i].item.password);
- memcpy(&entries[i], &entries[entries_nr], sizeof(*entries));
+ if (i != entries_nr)
+ memcpy(&entries[i], &entries[entries_nr], sizeof(*entries));
/*
* Stick around 30 seconds in case a new credential
* shows up (e.g., because we just removed a failed
--
1.7.7.rc1.366.ge210a6
^ permalink raw reply related
* [PATCH 1/2] t0300: add missing EOF terminator for <<
From: Thomas Rast @ 2011-09-16 11:51 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Brian Gernhardt
In-Reply-To: <20110914191757.GB28267@sigill.intra.peff.net>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
This doesn't really matter on my system, but the shell warns about it.
t/t0300-credentials.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/t/t0300-credentials.sh b/t/t0300-credentials.sh
index 613c3fb..076a109 100755
--- a/t/t0300-credentials.sh
+++ b/t/t0300-credentials.sh
@@ -136,6 +136,7 @@ test_expect_success 'usernames can be preserved' '
password=three
--
verbatim: --username=one
+ EOF
'
test_expect_success 'usernames can be overridden' '
--
1.7.7.rc1.366.ge210a6
^ permalink raw reply related
* Re: New setup, trying to clone . . .
From: Jakub Narebski @ 2011-09-16 8:29 UTC (permalink / raw)
To: Joshua Stoutenburg; +Cc: Git List
In-Reply-To: <CAOZxsToJk45UHGAuno-r=B76+SUg5icbYvUsY5EfgcGv_UkxHg@mail.gmail.com>
Joshua Stoutenburg <jehoshua02@gmail.com> writes:
> I'm following these instructions: http://progit.org/book/ch4-4.html
>
> Everything has gone fine up until about halfway down the page, where it says:
>
> > At this point, the others can clone it down and push changes back up just as easily:
> > $ git clone git@gitserver:/opt/git/project.git
>
> Of course, replacing [git@gitserver:/opt/git/project.git] according to
> my setup, and I change directory to an empty directory apart from the
> original project, then I try the command, I get the following output:
>
> At this point, the others can clone it down and push changes back up
> just as easily:
>
> $ git clone gituser@192.168.1.102:/git/project.git
> Cloning into project...
> Connection closed by 192.168.1.102
> fatal: The remote end hung up unexpectedly
>
> Any ideas what's going on here?
Note that 'gituser@192.168.1.102:/git/project.git' is an SSH URL.
There are two possible issues:
1. The path to repository is incorrect.
If you are on the same machine as server, you can try cloning (or
just 'git ls-remote') with a local path:
git clone /git/project.git
or
git clone file:///git/project.git
2. The SSH setup is not correct: either SSH daemon is not started, or
there is no 'gituser' account, or 'gituser' account doesn't have
access to /git/project.git
You can check first two with
ssh gituser@192.168.1.102 echo Hello
HTH
--
Jakub Narębski
^ permalink raw reply
* New setup, trying to clone . . .
From: Joshua Stoutenburg @ 2011-09-16 6:59 UTC (permalink / raw)
To: Git List
Hey guys,
I'm following these instructions: http://progit.org/book/ch4-4.html
Everything has gone fine up until about halfway down the page, where it says:
> At this point, the others can clone it down and push changes back up just as easily:
> $ git clone git@gitserver:/opt/git/project.git
Of course, replacing [git@gitserver:/opt/git/project.git] according to
my setup, and I change directory to an empty directory apart from the
original project, then I try the command, I get the following output:
At this point, the others can clone it down and push changes back up
just as easily:
$ git clone gituser@192.168.1.102:/git/project.git
Cloning into project...
Connection closed by 192.168.1.102
fatal: The remote end hung up unexpectedly
Any ideas what's going on here?
^ permalink raw reply
* Re: Re* [PATCH 4/4] Add documentation for ref namespaces
From: Jamey Sharp @ 2011-09-16 3:40 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð Bjarmason, Shawn O. Pearce,
Johannes Schindelin, Jeff King, Jakub Narebski, git,
Josh Triplett
In-Reply-To: <7vaaa5pc8q.fsf_-_@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 3202 bytes --]
On Thu, Sep 15, 2011 at 05:22:29PM -0700, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
> > On Tue, Jun 7, 2011 at 20:21, Jamey Sharp <jamey@minilop.net> wrote:
> >
> >> Document the namespace mechanism in a new gitnamespaces(7) page.
> >> Reference it from receive-pack and upload-pack.
> >
> > This breaks the build on older asciidoc versions, the fix is to do
> > what I did in f5008f56d5aba06598e1c6272f4f55b4ee4bb016.
>
> Earlier I sent out a tongue-in-cheek "like this" that had a completely
> bogus SYNOPSIS section that is unusable in a released version of Git,
> hoping that somebody who _care_ more about the feature that the page
> describes would give us a better wording, but unfortunately it never
> happened.
I'm afraid your wit was too subtle for me, as I believed your proposal
was serious and would be applied as-is. I assumed AsciiDoc was going to
magically omit the bogus synopsis, somehow. Perhaps it should detect
when people are making fun of it, and ignore them then?
Your rationale for giving a more specific synopsis is sound, although:
1) git http-backend also supports the environment variable because it's
inherited by the underlying upload-pack and receive-pack; and 2) the
environment variable is an alternative to a general git command-line
option. How much detail do you want in a synopsis?
Assuming that you're happy with this level of detail, and that the
AsciiDoc syntax is correct (I'm not familiar enough with it), I'm happy
with the patch you propose---
Reviewed-by: Jamey Sharp <jamey@minilop.net>
> So here is a more realistic replacement, so that we won't have to suffer
> by complaints from people with older AsciiDoc saying "the release does not
> build". If we were to include this in 1.7.7 final, we now need to make
> sure we won't to have to hear from people with newer AsciiDoc saying "why
> do we have nonsense in SYNOPSIS section", so your help is needed here.
>
> I explicitly avoided saying:
>
> [verse]
> export GIT_NAMESPACE=<namespace>
>
> as nothing other than the selected transports seems to pay attention to
> this environment variable.
>
> -- >8 --
> Subject: [PATCH] Documentation/gitnamespaces.txt: cater to older asciidoc
>
> Older asciidoc (e.g. 8.2.5 on Centos 5.5) is unhappy if a manpage does not
> have a SYNOPSIS section. Show a sample (and a possibly bogus) command line
> of running two commands that pay attention to this environment variable
> with a customized value.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> Documentation/gitnamespaces.txt | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/gitnamespaces.txt b/Documentation/gitnamespaces.txt
> index ed8924e..c6713cf 100644
> --- a/Documentation/gitnamespaces.txt
> +++ b/Documentation/gitnamespaces.txt
> @@ -5,6 +5,13 @@ NAME
> ----
> gitnamespaces - Git namespaces
>
> +SYNOPSIS
> +--------
> +[verse]
> +GIT_NAMESPACE=<namespace> 'git upload-pack'
> +GIT_NAMESPACE=<namespace> 'git receive-pack'
> +
> +
> DESCRIPTION
> -----------
>
> --
> 1.7.7.rc1.3.g559357
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH] mergetool: Use args as pathspec to unmerged files
From: Jonathon Mah @ 2011-09-16 2:12 UTC (permalink / raw)
To: git; +Cc: Dan McGee, David Aguilar, Junio C Hamano
In-Reply-To: <7vsjnysuyl.fsf@alter.siamese.dyndns.org>
Mergetool now treats its path arguments as a pathspec (like other git
subcommands), restricting action to the given files and directories.
Files matching the pathspec are filtered so mergetool only acts on
unmerged paths; previously it would assume each path argument was in an
unresolved state, and get confused when it couldn't check out their
other stages.
Running "git mergetool subdir" will prompt to resolve all conflicted
blobs under subdir.
Signed-off-by: Jonathon Mah <me@JonathonMah.com>
---
With Junio's change, I'm happy with the code in git-mergetool.sh.
I've tried to clarify the commit message since the first submission.
Documentation/git-mergetool.txt | 7 ++--
git-mergetool.sh | 76 ++++++++++++++------------------------
t/t7610-mergetool.sh | 58 ++++++++++++++++++++---------
3 files changed, 72 insertions(+), 69 deletions(-)
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 3470910..2a49de7 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -17,9 +17,10 @@ Use `git mergetool` to run one of several merge utilities to resolve
merge conflicts. It is typically run after 'git merge'.
If one or more <file> parameters are given, the merge tool program will
-be run to resolve differences on each file. If no <file> names are
-specified, 'git mergetool' will run the merge tool program on every file
-with merge conflicts.
+be run to resolve differences on each file (skipping those without
+conflicts). Specifying a directory will include all unresolved files in
+that path. If no <file> names are specified, 'git mergetool' will run
+the merge tool program on every file with merge conflicts.
OPTIONS
-------
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 3c157bc..12a2706 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -342,64 +342,44 @@ merge_keep_temporaries="$(git config --bool mergetool.keepTemporaries || echo fa
last_status=0
rollup_status=0
-rerere=false
-
-files_to_merge() {
- if test "$rerere" = true
- then
- git rerere remaining
- else
- git ls-files -u | sed -e 's/^[^ ]* //' | sort -u
- fi
-}
-
+files=
if test $# -eq 0 ; then
cd_to_toplevel
if test -e "$GIT_DIR/MERGE_RR"
then
- rerere=true
+ files=$(git rerere remaining)
+ else
+ files=$(git ls-files -u | sed -e 's/^[^ ]* //' | sort -u)
fi
+else
+ files=$(git ls-files -u -- "$@" | sed -e 's/^[^ ]* //' | sort -u)
+fi
- files=$(files_to_merge)
- if test -z "$files" ; then
- echo "No files need merging"
- exit 0
- fi
+if test -z "$files" ; then
+ echo "No files need merging"
+ exit 0
+fi
- # Save original stdin
- exec 3<&0
+# Save original stdin
+exec 3<&0
- printf "Merging:\n"
- printf "$files\n"
+printf "Merging:\n"
+printf "$files\n"
- files_to_merge |
- while IFS= read i
- do
- if test $last_status -ne 0; then
- prompt_after_failed_merge <&3 || exit 1
- fi
- printf "\n"
- merge_file "$i" <&3
- last_status=$?
- if test $last_status -ne 0; then
- rollup_status=1
- fi
- done
-else
- while test $# -gt 0; do
- if test $last_status -ne 0; then
- prompt_after_failed_merge || exit 1
- fi
- printf "\n"
- merge_file "$1"
- last_status=$?
- if test $last_status -ne 0; then
- rollup_status=1
- fi
- shift
- done
-fi
+IFS='
+'; for i in $files
+do
+ if test $last_status -ne 0; then
+ prompt_after_failed_merge <&3 || exit 1
+ fi
+ printf "\n"
+ merge_file "$i" <&3
+ last_status=$?
+ if test $last_status -ne 0; then
+ rollup_status=1
+ fi
+done
exit $rollup_status
diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh
index cbc08e3..4aab2a7 100755
--- a/t/t7610-mergetool.sh
+++ b/t/t7610-mergetool.sh
@@ -16,6 +16,7 @@ Testing basic merge tool invocation'
test_expect_success 'setup' '
git config rerere.enabled true &&
echo master >file1 &&
+ echo master spaced >"spaced name" &&
echo master file11 >file11 &&
echo master file12 >file12 &&
echo master file13 >file13 &&
@@ -30,13 +31,14 @@ test_expect_success 'setup' '
git commit -m "Add foo"
) &&
git submodule add git://example.com/submod submod &&
- git add file1 file1[1-4] subdir/file3 .gitmodules submod &&
+ git add file1 "spaced name" file1[1-4] subdir/file3 .gitmodules submod &&
git commit -m "add initial versions" &&
git checkout -b branch1 master &&
git submodule update -N &&
echo branch1 change >file1 &&
echo branch1 newfile >file2 &&
+ echo branch1 spaced >"spaced name" &&
echo branch1 change file11 >file11 &&
echo branch1 change file13 >file13 &&
echo branch1 sub >subdir/file3 &&
@@ -47,7 +49,7 @@ test_expect_success 'setup' '
git commit -m "Add bar on branch1" &&
git checkout -b submod-branch1
) &&
- git add file1 file11 file13 file2 subdir/file3 submod &&
+ git add file1 "spaced name" file11 file13 file2 subdir/file3 submod &&
git rm file12 &&
git commit -m "branch1 changes" &&
@@ -55,6 +57,7 @@ test_expect_success 'setup' '
git submodule update -N &&
echo master updated >file1 &&
echo master new >file2 &&
+ echo master updated spaced >"spaced name" &&
echo master updated file12 >file12 &&
echo master updated file14 >file14 &&
echo master new sub >subdir/file3 &&
@@ -65,7 +68,7 @@ test_expect_success 'setup' '
git commit -m "Add bar on master" &&
git checkout -b submod-master
) &&
- git add file1 file12 file14 file2 subdir/file3 submod &&
+ git add file1 "spaced name" file12 file14 file2 subdir/file3 submod &&
git rm file11 &&
git commit -m "master updates" &&
@@ -78,8 +81,8 @@ test_expect_success 'custom mergetool' '
git checkout -b test1 branch1 &&
git submodule update -N &&
test_must_fail git merge master >/dev/null 2>&1 &&
- ( yes "" | git mergetool file1 >/dev/null 2>&1 ) &&
- ( yes "" | git mergetool file2 >/dev/null 2>&1 ) &&
+ ( yes "" | git mergetool file1 file1 ) &&
+ ( yes "" | git mergetool file2 "spaced name" >/dev/null 2>&1 ) &&
( yes "" | git mergetool subdir/file3 >/dev/null 2>&1 ) &&
( yes "d" | git mergetool file11 >/dev/null 2>&1 ) &&
( yes "d" | git mergetool file12 >/dev/null 2>&1 ) &&
@@ -97,6 +100,7 @@ test_expect_success 'mergetool crlf' '
test_must_fail git merge master >/dev/null 2>&1 &&
( yes "" | git mergetool file1 >/dev/null 2>&1 ) &&
( yes "" | git mergetool file2 >/dev/null 2>&1 ) &&
+ ( yes "" | git mergetool "spaced name" >/dev/null 2>&1 ) &&
( yes "" | git mergetool subdir/file3 >/dev/null 2>&1 ) &&
( yes "d" | git mergetool file11 >/dev/null 2>&1 ) &&
( yes "d" | git mergetool file12 >/dev/null 2>&1 ) &&
@@ -126,7 +130,7 @@ test_expect_success 'mergetool on file in parent dir' '
(
cd subdir &&
( yes "" | git mergetool ../file1 >/dev/null 2>&1 ) &&
- ( yes "" | git mergetool ../file2 >/dev/null 2>&1 ) &&
+ ( yes "" | git mergetool ../file2 ../spaced\ name >/dev/null 2>&1 ) &&
( yes "d" | git mergetool ../file11 >/dev/null 2>&1 ) &&
( yes "d" | git mergetool ../file12 >/dev/null 2>&1 ) &&
( yes "l" | git mergetool ../submod >/dev/null 2>&1 ) &&
@@ -180,6 +184,24 @@ test_expect_success 'mergetool skips resolved paths when rerere is active' '
git reset --hard
'
+test_expect_success 'mergetool takes partial path' '
+ git config rerere.enabled false &&
+ git checkout -b test12 branch1 &&
+ git submodule update -N &&
+ test_must_fail git merge master &&
+
+ #shouldnt need these lines
+ #( yes "d" | git mergetool file11 >/dev/null 2>&1 ) &&
+ #( yes "d" | git mergetool file12 >/dev/null 2>&1 ) &&
+ #( yes "l" | git mergetool submod >/dev/null 2>&1 ) &&
+ #( yes "" | git mergetool file1 file2 >/dev/null 2>&1 ) &&
+
+ ( yes "" | git mergetool subdir ) &&
+
+ test "$(cat subdir/file3)" = "master new sub" &&
+ git reset --hard
+'
+
test_expect_success 'deleted vs modified submodule' '
git checkout -b test6 branch1 &&
git submodule update -N &&
@@ -189,7 +211,7 @@ test_expect_success 'deleted vs modified submodule' '
git checkout -b test6.a test6 &&
test_must_fail git merge master &&
test -n "$(git ls-files -u)" &&
- ( yes "" | git mergetool file1 file2 subdir/file3 >/dev/null 2>&1 ) &&
+ ( yes "" | git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 ) &&
( yes "d" | git mergetool file11 file12 >/dev/null 2>&1 ) &&
( yes "r" | git mergetool submod ) &&
rmdir submod && mv submod-movedaside submod &&
@@ -205,7 +227,7 @@ test_expect_success 'deleted vs modified submodule' '
git submodule update -N &&
test_must_fail git merge master &&
test -n "$(git ls-files -u)" &&
- ( yes "" | git mergetool file1 file2 subdir/file3 >/dev/null 2>&1 ) &&
+ ( yes "" | git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 ) &&
( yes "d" | git mergetool file11 file12 >/dev/null 2>&1 ) &&
( yes "l" | git mergetool submod ) &&
test ! -e submod &&
@@ -218,7 +240,7 @@ test_expect_success 'deleted vs modified submodule' '
git submodule update -N &&
test_must_fail git merge test6 &&
test -n "$(git ls-files -u)" &&
- ( yes "" | git mergetool file1 file2 subdir/file3 >/dev/null 2>&1 ) &&
+ ( yes "" | git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 ) &&
( yes "d" | git mergetool file11 file12 >/dev/null 2>&1 ) &&
( yes "r" | git mergetool submod ) &&
test ! -e submod &&
@@ -233,7 +255,7 @@ test_expect_success 'deleted vs modified submodule' '
git submodule update -N &&
test_must_fail git merge test6 &&
test -n "$(git ls-files -u)" &&
- ( yes "" | git mergetool file1 file2 subdir/file3 >/dev/null 2>&1 ) &&
+ ( yes "" | git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 ) &&
( yes "d" | git mergetool file11 file12 >/dev/null 2>&1 ) &&
( yes "l" | git mergetool submod ) &&
test "$(cat submod/bar)" = "master submodule" &&
@@ -256,7 +278,7 @@ test_expect_success 'file vs modified submodule' '
git checkout -b test7.a branch1 &&
test_must_fail git merge master &&
test -n "$(git ls-files -u)" &&
- ( yes "" | git mergetool file1 file2 subdir/file3 >/dev/null 2>&1 ) &&
+ ( yes "" | git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 ) &&
( yes "d" | git mergetool file11 file12 >/dev/null 2>&1 ) &&
( yes "r" | git mergetool submod ) &&
rmdir submod && mv submod-movedaside submod &&
@@ -271,7 +293,7 @@ test_expect_success 'file vs modified submodule' '
git checkout -b test7.b test7 &&
test_must_fail git merge master &&
test -n "$(git ls-files -u)" &&
- ( yes "" | git mergetool file1 file2 subdir/file3 >/dev/null 2>&1 ) &&
+ ( yes "" | git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 ) &&
( yes "d" | git mergetool file11 file12 >/dev/null 2>&1 ) &&
( yes "l" | git mergetool submod ) &&
git submodule update -N &&
@@ -286,7 +308,7 @@ test_expect_success 'file vs modified submodule' '
git submodule update -N &&
test_must_fail git merge test7 &&
test -n "$(git ls-files -u)" &&
- ( yes "" | git mergetool file1 file2 subdir/file3 >/dev/null 2>&1 ) &&
+ ( yes "" | git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 ) &&
( yes "d" | git mergetool file11 file12 >/dev/null 2>&1 ) &&
( yes "r" | git mergetool submod ) &&
test -d submod.orig &&
@@ -301,7 +323,7 @@ test_expect_success 'file vs modified submodule' '
git submodule update -N &&
test_must_fail git merge test7 &&
test -n "$(git ls-files -u)" &&
- ( yes "" | git mergetool file1 file2 subdir/file3 >/dev/null 2>&1 ) &&
+ ( yes "" | git mergetool file1 file2 spaced\ name subdir/file3 >/dev/null 2>&1 ) &&
( yes "d" | git mergetool file11 file12 >/dev/null 2>&1 ) &&
( yes "l" | git mergetool submod ) &&
test "$(cat submod/bar)" = "master submodule" &&
@@ -388,7 +410,7 @@ test_expect_success 'directory vs modified submodule' '
test "$(cat submod/file16)" = "not a submodule" &&
rm -rf submod.orig &&
- git reset --hard &&
+ git reset --hard >/dev/null 2>&1 &&
test_must_fail git merge master &&
test -n "$(git ls-files -u)" &&
test ! -e submod.orig &&
@@ -400,7 +422,7 @@ test_expect_success 'directory vs modified submodule' '
( cd submod && git clean -f && git reset --hard ) &&
git submodule update -N &&
test "$(cat submod/bar)" = "master submodule" &&
- git reset --hard && rm -rf submod-movedaside &&
+ git reset --hard >/dev/null 2>&1 && rm -rf submod-movedaside &&
git checkout -b test11.c master &&
git submodule update -N &&
@@ -410,7 +432,7 @@ test_expect_success 'directory vs modified submodule' '
git submodule update -N &&
test "$(cat submod/bar)" = "master submodule" &&
- git reset --hard &&
+ git reset --hard >/dev/null 2>&1 &&
git submodule update -N &&
test_must_fail git merge test11 &&
test -n "$(git ls-files -u)" &&
@@ -418,7 +440,7 @@ test_expect_success 'directory vs modified submodule' '
( yes "r" | git mergetool submod ) &&
test "$(cat submod/file16)" = "not a submodule" &&
- git reset --hard master &&
+ git reset --hard master >/dev/null 2>&1 &&
( cd submod && git clean -f && git reset --hard ) &&
git submodule update -N
'
--
1.7.5.4
^ permalink raw reply related
* Re: git-rebase skips automatically no more needed commits
From: Martin von Zweigbergk @ 2011-09-16 1:27 UTC (permalink / raw)
To: Junio C Hamano
Cc: Martin von Zweigbergk, Francis Moreau, Michael J Gruber, git
In-Reply-To: <7vwrdaqxpk.fsf@alter.siamese.dyndns.org>
Hi,
On Wed, 14 Sep 2011, Junio C Hamano wrote:
> What I said is "all 'am' need to use from its input while rebasing is the
> commit object name"; that is very different from "we have only commit
> object name so we must use cherry-pick" or "because we have commit object
> name, we can afford to use cherry-pick".
Right. I didn't mean to suggest that we should use cherry-pick.
> Look for $rebasing in git-am.sh and notice that:
Thanks! I had no idea about these "tricks" in git-am.sh. Now I
understand much better what you meant. So we are currently getting the
metainfo from the commit rather than from the mailbox. With your
patch, we would also get the patch body from the commit. The only
thing remaining after that is the commit log message, correct?
Once all that git-am reads from the mailbox while in $rebasing mode is
the commit name, it would be as small change to teach it to read a
list of commit names instead. Is this what you meant or did you really
mean for format-patch to generate output without patch body? At this
point the name 'am' becomes quite misleading, but maybe that's not
worth worrying about.
Thanks,
Martin
^ permalink raw reply
* Re* [PATCH 4/4] Add documentation for ref namespaces
From: Junio C Hamano @ 2011-09-16 0:22 UTC (permalink / raw)
To: Jamey Sharp
Cc: Ævar Arnfjörð Bjarmason, Shawn O. Pearce,
Johannes Schindelin, Jeff King, Jakub Narebski, git,
Josh Triplett
In-Reply-To: <CACBZZX4bow8vwrwSL5uRJQtAgeg10_K+5ss8u-HvCHOn3+0Tuw@mail.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> On Tue, Jun 7, 2011 at 20:21, Jamey Sharp <jamey@minilop.net> wrote:
>
>> Document the namespace mechanism in a new gitnamespaces(7) page.
>> Reference it from receive-pack and upload-pack.
>
> This breaks the build on older asciidoc versions, the fix is to do
> what I did in f5008f56d5aba06598e1c6272f4f55b4ee4bb016.
Earlier I sent out a tongue-in-cheek "like this" that had a completely
bogus SYNOPSIS section that is unusable in a released version of Git,
hoping that somebody who _care_ more about the feature that the page
describes would give us a better wording, but unfortunately it never
happened.
So here is a more realistic replacement, so that we won't have to suffer
by complaints from people with older AsciiDoc saying "the release does not
build". If we were to include this in 1.7.7 final, we now need to make
sure we won't to have to hear from people with newer AsciiDoc saying "why
do we have nonsense in SYNOPSIS section", so your help is needed here.
I explicitly avoided saying:
[verse]
export GIT_NAMESPACE=<namespace>
as nothing other than the selected transports seems to pay attention to
this environment variable.
-- >8 --
Subject: [PATCH] Documentation/gitnamespaces.txt: cater to older asciidoc
Older asciidoc (e.g. 8.2.5 on Centos 5.5) is unhappy if a manpage does not
have a SYNOPSIS section. Show a sample (and a possibly bogus) command line
of running two commands that pay attention to this environment variable
with a customized value.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/gitnamespaces.txt | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/Documentation/gitnamespaces.txt b/Documentation/gitnamespaces.txt
index ed8924e..c6713cf 100644
--- a/Documentation/gitnamespaces.txt
+++ b/Documentation/gitnamespaces.txt
@@ -5,6 +5,13 @@ NAME
----
gitnamespaces - Git namespaces
+SYNOPSIS
+--------
+[verse]
+GIT_NAMESPACE=<namespace> 'git upload-pack'
+GIT_NAMESPACE=<namespace> 'git receive-pack'
+
+
DESCRIPTION
-----------
--
1.7.7.rc1.3.g559357
^ permalink raw reply related
* Re: [PATCH/RFC] add lame win32 credential-helper
From: Erik Faye-Lund @ 2011-09-15 21:48 UTC (permalink / raw)
To: Jeff King; +Cc: git, jaysoffian, gitster
In-Reply-To: <20110915214026.GA18623@sigill.intra.peff.net>
On Thu, Sep 15, 2011 at 11:40 PM, Jeff King <peff@peff.net> wrote:
> On Thu, Sep 15, 2011 at 10:25:24PM +0200, Erik Faye-Lund wrote:
>
>> Not that it's useful yet, since the core-git code for the
>> credential-helper support doesn't compile on Windows. So
>> it's not fully tested, I've only read the interface
>> documentation and experimented with it from the command
>> line.
>
> Which parts of the credential-helper code don't compile? I wouldn't be
> surprised if the cache helper doesn't work (because it uses unix domain
> sockets for communication).
That's exactly it:
unix-socket.c:12: warning: 'struct sockaddr_un' declared inside parameter list
unix-socket.c:12: warning: its scope is only this definition or declaration, whi
ch is probably not what you want
unix-socket.c: In function 'unix_sockaddr_init':
unix-socket.c:15: error: dereferencing pointer to incomplete type
unix-socket.c:17: error: dereferencing pointer to incomplete type
unix-socket.c:18: error: dereferencing pointer to incomplete type
unix-socket.c:19: error: dereferencing pointer to incomplete type
unix-socket.c: In function 'unix_stream_connect':
unix-socket.c:25: error: storage size of 'sa' isn't known
unix-socket.c: In function 'unix_stream_listen':
unix-socket.c:39: error: storage size of 'sa' isn't known
make: *** [unix-socket.o] Error 1
make: *** Waiting for unfinished jobs....
> If it's too hard to adapt it to whatever IPC
> mechanism would be appropriate on Windows, we can just leave it out on
> that platform.
>
> But the core code in git itself should be pretty straight forward.
I didn't mean that it was impossible to port, just that it didn't compile
as-is. I haven't looked into fixing up the code so it compiles on Windows
again myself. And I'm not really planning to; I have little git-time these
days, and little knowledge of how unix-sockets works...
^ 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