* Re: Intermittent failures in t9119
From: David D. Kilzer @ 2010-12-31 14:13 UTC (permalink / raw)
To: Eric Wong, Junio C Hamano; +Cc: git
In-Reply-To: <20101209175503.GA16478@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
> > Eric Wong <normalperson@yhbt.net> writes:
> > > Junio C Hamano <gitster@pobox.com> wrote:
> > >> (2) Nobody uses the value from "Text Last Updated" field in practice,
>so
> > >> that bug has been unnoticed so far;
> > >>
> > >> (3) And it is not worth fixing it ;-)
> > >>
> > >> For now, I would suggest fixing the failing test to ignore the "Text
Last
> > >> Updated" field while comparing, and if somebody is inclined to, we would
> > >> update the code to match what "svn info" does.
> > >
> > > Agreed on both points. I consider "git svn log" and "git svn info" to
> > > be reasonable approximations of svn behavior, not exact replicas.
> > > Exactly matching would be extremely difficult given variations between
> > > different svn versions, and also svn requiring network access while
> > > git svn does not.
> >
> > Ok, here is a minimum patch to do that.
>
> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
> Thanks, Acked-by: Eric Wong <normalperson@yhbt.net>
Acked-by: David Kilzer <ddkilzer@kilzer.net>
Thanks!
Dave
^ permalink raw reply
* Re: [PATCH 18/31] rebase: extract merge code to new source file
From: Martin von Zweigbergk @ 2010-12-31 14:05 UTC (permalink / raw)
To: Thomas Rast
Cc: Martin von Zweigbergk, Johannes Sixt, git, Junio C Hamano,
Johannes Schindelin, Christian Couder
In-Reply-To: <201012311323.47102.trast@student.ethz.ch>
On Fri, 31 Dec 2010, Thomas Rast wrote:
> Martin von Zweigbergk wrote:
> > On Wed, 29 Dec 2010, Johannes Sixt wrote:
> > >
> > > Is export -f portable?
> >
> > It seems like it isn't. What is a good way to check?
>
> On my system I have POSIX docs for various commands, coming from the
> 'man-pages-posix' package. Maybe your distribution has those too?
> Then you can simply run 'man 1p export' for the documentation.
> Anything that is documented there should be safe (except on Windows
> maybe).
Thanks. I'm running Debian and I just installed the package from
non-free. Thanks for the hint on the '1p' syntax as well.
/Martin
^ permalink raw reply
* Re: [PATCH] Fix expected values of setup tests on Windows
From: Nguyen Thai Ngoc Duy @ 2010-12-31 13:00 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <201012302205.13728.j6t@kdbg.org>
2010/12/31 Johannes Sixt <j6t@kdbg.org>:
> On Windows, bash stores absolute path names in shell variables in POSIX
> format that begins with a slash, rather than in drive-letter format; such
> a value is converted to the latter format when it is passed to a non-MSYS
> program such as git.
Hmm.. from test-lib.sh:
TEST_DIRECTORY=$(pwd)
test="trash directory.$(basename "$0" .sh)"
TRASH_DIRECTORY="$TEST_DIRECTORY/$test"
I'm just curious how these lines make $TRASH_DIRECTORY in POSIX format, while
here=$(pwd)
in your patch does not. Does bash auto convert value in
TRASH_DIRECTORY="$TE..." line?
--
Duy
^ permalink raw reply
* Re: [PATCH 18/31] rebase: extract merge code to new source file
From: Thomas Rast @ 2010-12-31 12:23 UTC (permalink / raw)
To: Martin von Zweigbergk
Cc: Johannes Sixt, git, Junio C Hamano, Johannes Schindelin,
Christian Couder
In-Reply-To: <alpine.DEB.1.10.1012292315070.7175@debian>
Martin von Zweigbergk wrote:
> On Wed, 29 Dec 2010, Johannes Sixt wrote:
> >
> > Is export -f portable?
>
> It seems like it isn't. What is a good way to check?
On my system I have POSIX docs for various commands, coming from the
'man-pages-posix' package. Maybe your distribution has those too?
Then you can simply run 'man 1p export' for the documentation.
Anything that is documented there should be safe (except on Windows
maybe).
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH 31/31] rebase -i: remove unnecessary state rebase-root
From: Christian Couder @ 2010-12-31 5:41 UTC (permalink / raw)
To: Martin von Zweigbergk
Cc: Thomas Rast, git, Junio C Hamano, Johannes Schindelin,
Johannes Sixt, Christian Couder
In-Reply-To: <alpine.DEB.1.10.1012292325220.7175@debian>
Hi,
On Wed, Dec 29, 2010 at 11:31 PM, Martin von Zweigbergk
<martin.von.zweigbergk@gmail.com> wrote:
> On Tue, 28 Dec 2010, Thomas Rast wrote:
>
>> Martin von Zweigbergk wrote:
>> > @@ -168,11 +168,6 @@ pick_one () {
>> > output git rev-parse --verify $sha1 || die "Invalid commit name: $sha1"
>> > test -d "$REWRITTEN" &&
>> > pick_one_preserving_merges "$@" && return
>> > - if test -n "$rebase_root"
>> > - then
>> > - output git cherry-pick "$@"
>> > - return
>> > - fi
>> > output git cherry-pick $ff "$@"
>> > }
>> [...]
>> > While factoring out the state writing code a few patches back, I went
>> > through each of the pieces of state that was written. I was a bit
>> > hesitant to include this patch since I'm not quite sure why the code
>> > was introduced, but I thought I would include it anyway to hear what
>> > you have to say.
>> >
>> > There used to be bug when using --ff when rebasing a root commit. This
>> > was fixed in 6355e50 (builtin/revert.c: don't dereference a NULL
>> > pointer, 2010-09-27). Could this have been the reason for the check?
>> > Thomas, do you remember?
>>
>> I think this just ended up being such a strange test because of the
>> following hunk in 8e75abf (rebase -i: use new --ff cherry-pick option,
>> 2010-03-06):
>>
>> @@ -232,16 +232,7 @@ pick_one () {
>> output git cherry-pick "$@"
>> return
>> fi
>> - parent_sha1=$(git rev-parse --verify $sha1^) ||
>> - die "Could not get the parent of $sha1"
>> - current_sha1=$(git rev-parse --verify HEAD)
>> - if test -z "$no_ff" && test "$current_sha1" = "$parent_sha1"
>> - then
>> - output git reset --hard $sha1
>> - output warn Fast-forward to $(git rev-parse --short $sha1)
>> - else
>> - output git cherry-pick "$@"
>> - fi
>> + output git cherry-pick $ff "$@"
>> }
>> --
>
> Yes, I saw that one as well, so it would probably have made more sense
> to ask Christian instead (the author of 8e75abf). So do you remember,
> Christian?
Yeah, I must say that I did not try to understand why there was a
special case for $rebase_root above the code I was changing.
Perhaps I should have, and I would probably have sent a patch like yours...
> Anyway, thanks for your input, Thomas. That makes me feel a little
> less worried about this patch.
Yeah I think it's a good one.
Thanks,
Christian.
^ permalink raw reply
* Re: HTTP push not respecting .netrc
From: Tay Ray Chuan @ 2010-12-31 4:03 UTC (permalink / raw)
To: David Borowitz; +Cc: git
In-Reply-To: <AANLkTik84-zRwi+0dGGFoTUrj6Zr3bxO=fE9P_3MuZdZ@mail.gmail.com>
On Thu, Dec 30, 2010 at 2:56 PM, David Borowitz <dave@bwitz.com> wrote:
> I'm trying to push to a smart HTTP remote using the following command line:
> http_proxy=localhost:4242 git push -v http://xxxxx:25989/git/foo
> +refs/heads/*:refs/heads/*
> (The weird proxy and port are not under my control.)
>
> The webserver should return 401 for unauthorized access, and indeed it does:
> error: RPC failed; result=65, HTTP code = 401
> (The rest of the error text from git push is not particularly useful,
> but I'm not worried about that at the moment.)
Could you run the push with the environment variable GIT_CURL_VERBOSE=1?
> [2]
> GET http://xxxxx:25989/git/foo/info/refs?service=git-receive-pack HTTP/1.1
> User-Agent: git/1.7.4.rc0
> Host: xxxxx:25989
> Accept: */*
> Proxy-Connection: Keep-Alive
> Pragma: no-cache
Try having a entry for xxxxx:25989 in your .netrc - that should be
sufficient to demonstrate to you that git+curl reads your .netrc.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: git rebase -i doesn't respect rebase.autosquash
From: Martin von Zweigbergk @ 2010-12-30 18:46 UTC (permalink / raw)
To: Mike Doherty; +Cc: Martin von Zweigbergk, git
In-Reply-To: <4D1D263E.4080600@cs.dal.ca>
On Thu, 30 Dec 2010, Mike Doherty wrote:
> On 10-12-30 01:37 PM, Martin von Zweigbergk wrote:
> > I also have rebase.autosquash enabled and it works for me. Does it
> > autosquash as you expect if you pass '--autosquash' on the command
> > line? Which version of Git are you running?
>
> Yes, it does. I'm using 1.7.0.4
Ok, that explains it. The configuration was introduced in 1.7.3.
Regards,
Martin
^ permalink raw reply
* Re: git rebase -i doesn't respect rebase.autosquash
From: Mike Doherty @ 2010-12-31 0:39 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git
In-Reply-To: <alpine.DEB.1.10.1012301929221.7175@debian>
On 10-12-30 01:37 PM, Martin von Zweigbergk wrote:
> I also have rebase.autosquash enabled and it works for me. Does it
> autosquash as you expect if you pass '--autosquash' on the command
> line? Which version of Git are you running?
Yes, it does. I'm using 1.7.0.4
-Mike
^ permalink raw reply
* Re: git rebase -i doesn't respect rebase.autosquash
From: Martin von Zweigbergk @ 2010-12-30 18:37 UTC (permalink / raw)
To: Mike Doherty; +Cc: git
In-Reply-To: <4D1D1A38.9090305@cs.dal.ca>
On Thu, 30 Dec 2010, Mike Doherty wrote:
> Hello,
>
> In a git repo, I have rebase.autosquash enabled by default (in
> ~/.gitconfig), but whenever I do `git rebase -i`, that setting isn't
> respected. Is this a known bug, or am I misunderstanding what that
> setting is meant to do?
I also have rebase.autosquash enabled and it works for me. Does it
autosquash as you expect if you pass '--autosquash' on the command
line? Which version of Git are you running?
/Martin
^ permalink raw reply
* git rebase -i doesn't respect rebase.autosquash
From: Mike Doherty @ 2010-12-30 23:48 UTC (permalink / raw)
To: git
Hello,
In a git repo, I have rebase.autosquash enabled by default (in
~/.gitconfig), but whenever I do `git rebase -i`, that setting isn't
respected. Is this a known bug, or am I misunderstanding what that
setting is meant to do?
Thanks for your help,
-Mike Doherty
^ permalink raw reply
* Re: rebase parents, or tracking upstream but removing non-distributable bits
From: Jakub Narebski @ 2010-12-30 23:14 UTC (permalink / raw)
To: Alexandre Oliva; +Cc: Jonathan Nieder, git
In-Reply-To: <or4o9uc2ny.fsf@livre.localdomain>
Alexandre Oliva <lxoliva@fsfla.org> writes:
> On Dec 30, 2010, Jonathan Nieder <jrnieder@gmail.com> wrote:
>
> > Alexandre Oliva wrote:
> >> Now, it looks like I might be able to pull from upstream if I maintain
> >> manually a graft file that named each upstream commit as an additional
> >> parent of the corresponding local rebase commit that brought it into my
> >> rewritten tree. Workable, maybe, but this wouldn't help third parties
> >> that used my public repository.
>
> > Have you looked into "git replace"?
>
> As far as I could tell, it solves a complementary problem. IIUC, it
> would enable me to replace objects (say files, trees or commits) in my
> local repository so as to remove objectionable stuff, but when I pushed
> a branch out of it, it would go out with the very stuff I'm not supposed
> to publish. This is because AFAICT replace objects are not sent over
> the wire.
They are not sent by default, but they (refs/replace/*) can be send as
any other ref.
>
> Even if they were, I still don't think it would be appropriate to use
> them, for I'm speaking of really different trees. Publishing a commit
> replacement would, for anyone who had both my public repository and my
> upstream, affect not just the branches I published, but also those in
> upstream, which would be surprising and undesirable.
[...]
I guess what Jonathan had in mind was something like that:
* you have two branches, 'clean' and 'contaminated'
* you want to merge 'contaminated' into 'clean', but you don't
want people to see history of 'contaminated'
* in your private repository you merge 'contaminated' into 'clear'
(with --no-ff, just in case), save merge commit, then rewrite
top commit to be ordinary commit not a merge commit; it would
bring [redacted] changes but not history
* you replace merge-turned-ordinary commit with a proper merge
commit
* you don't distribute replacement refs to public repository
Though I think that better solution would be feature-branch based
workflow. Each feature is developed in seperate feature branch. If
given feature is sutable for 'clean', you merge it into both 'clean'
and in 'contaminated'. If it is not, you merge it only into
'contaminated'.
Hopefully that would help develop workflow for you.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: rebase parents, or tracking upstream but removing non-distributable bits
From: Alexandre Erwin Ittner @ 2010-12-30 22:58 UTC (permalink / raw)
To: git
In-Reply-To: <ord3ojb0yy.fsf@livre.localdomain>
Alexandre Oliva <lxoliva@fsfla.org> wrote
> I need to be able to maintain and publish a modified repository, that
> filters out the unwanted portions, but still be able to pull changes
> from the upstream repository.
Have you tried something with "git filter-branch"? I have never tried
something like this but I think it is possible to automate a process to
(1) pull the changes from the origin into a complete clone, (2) branch
from the HEAD and run "filter-branch" with a customized script to create
a temporary sanitized branch, (3) merge this temporary branch into a
complete sanitized branch, (4) record all the branchpoints, sparing the
next iteration from running through all the history again, and, (5) push
the sanitized branch somewhere.
Of course, this approach creates a complete nightmare with the
integration, testing, and code attribution: it changes the SHA1s,
invalidates signed tags, forces the use of patches instead of pull
requests to the upstream contributions, may taint the validity of the
commit messages and authorship, etc. Publishing edited commits seems a
delicate subject for me -- your "filter-branch" script should mark their
commit messages as such.
Att.
--
Alexandre Erwin Ittner - alexandre@ittner.com.br
OpenPGP pubkey 0x0041A1FB @ http://pgp.mit.edu
^ permalink raw reply
* Re: rebase parents, or tracking upstream but removing non-distributable bits
From: Yann Dirson @ 2010-12-30 22:52 UTC (permalink / raw)
To: Alexandre Oliva, git
In-Reply-To: <ord3ojb0yy.fsf@livre.localdomain>
On Thu, Dec 30, 2010 at 03:54:29PM -0200, Alexandre Oliva wrote:
> Given this problem statement, I started looking for solutions that
> didn't require modifying git.
This is a problem I have come to think a bit about already. Although
I do not have a proper solution either, let's share those ideas.
> I first looked into rewriting history, removing the unwanted bits and
> replaying subsequent changes, but quickly discarded it, for it would
> make my local repository incompatible with upstream both ways: I
> wouldn't be able to pull from it; upstream wouldn't be able to pull to
> it; third parties would run into ugly situations trying to carry patches
> from either one to the other.
>
> Now, it looks like I might be able to pull from upstream if I maintain
> manually a graft file that named each upstream commit as an additional
> parent of the corresponding local rebase commit that brought it into my
> rewritten tree. Workable, maybe, but this wouldn't help third parties
> that used my public repository.
As a side note: I fear grafts won't scale very nicely performance-wise
if you graft every commit.
My use-case was similar to yours, about "how could Debian distribute a
git tree of the kernel ?", but my focus was on distributing
well-defined snapshots, and I ended up with the idea of grafting only
the set of successive revisions that get published - and not
necessarily have a mirror of all upstream revisions in the filtered
tree: such grafts do represent points in history where we would merge
from upstream, and without the grafts the filtered tree would look
like successive imports of well-defined revisions (notably makes it
realistic to adhere to the "all commits have been tested" paradigm).
> Besides, I'm concerned that pushing from the local repository (with the
> graft file) to the public repository would end up publishing the changes
> I'm not supposed to distribute, because they'd be taken as parents of
> the local commits.
Grafts cannot be pushed/pulled. For this, as Jonathan suggests in
another reply, "git replace" looks like a better choice, esp. in that
by default the replacement commits don't get pulled: you need to
explicitely request fetching refs/replace/commits (note: you may need
to handle merges there when needed). OTOH, those replacement commits
would pull the whole upstream history, so they cannot be part of the
filtered repository: it must come from an unfiltered kernel repo, that
may be a real problem if you cannot redistribute some upstream parts.
OTOH, a grafts file can be distributed out-of-band, and would only
pull the problematic contents when put in place, so it might indeed be
more adequate.
> Are there any other ways to support the desired features with git as-is?
> AFAICT, there isn't, so I've been thinking of how to introduce this. I
> suppose the simplest way to accomplish this is to introduce the notion
> of a ???weak parent???: one that is taken into account for purposes of
> checking whether a commit is present in a branch being merged- or
> rebased into, but that is not transmitted over pushes, and that is not
> retained over purges, and not complained about when missing.
That sounds like heavy surgery with too many implications I can think
of.
When it comes to "modifying commit metadata", it rings "git notes" in
my ear - but then, you cannot add/change commit metadata from a note,
maybe that could be a better direction to dig into, so we can add
parents when a specific notes namespace is activated ? But then we
would get back to the problem I mentionned for refs/replace/
> I'm under the impression that this could not just work, but also make
> rebasing in general (especially the hard case) far less problematic, for
> git would be able to relate a rebased commit with an original commit.
I suppose that by "hard case" you mean forking off a branch that gets
rebased later ? Note that "git pull" seems to be able to cope with
this using reflogs already (although I did not test that feature). A
less volatile place than reflogs could again using notes, without a
need for core changes.
> I'm not sure this would enable upstream to easily integrate
> my changes. Or would it?
This problem suggests a more generic one: how to "merge back" most
changes from a branch while still not merging some specific changes ?
It would also help when a maint branch gets some short-term
workarounds that we don't want in the master branch, but the very idea
has a serious flaw: it implies that the "merge back" commit contains
also the commits we don't want (here, the "filtering commits"). So I
guess cherry-pick will be the way here. Anyway, I doubt Linus would
like the idea of merging from such a filtered repo, sending patches is
probably prefered.
Best regards,
--
Yann
^ permalink raw reply
* Re: rebase parents, or tracking upstream but removing non-distributable bits
From: Alexandre Oliva @ 2010-12-30 22:32 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20101230205847.GA29012@burratino>
On Dec 30, 2010, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Alexandre Oliva wrote:
>> Now, it looks like I might be able to pull from upstream if I maintain
>> manually a graft file that named each upstream commit as an additional
>> parent of the corresponding local rebase commit that brought it into my
>> rewritten tree. Workable, maybe, but this wouldn't help third parties
>> that used my public repository.
> Have you looked into "git replace"?
As far as I could tell, it solves a complementary problem. IIUC, it
would enable me to replace objects (say files, trees or commits) in my
local repository so as to remove objectionable stuff, but when I pushed
a branch out of it, it would go out with the very stuff I'm not supposed
to publish. This is because AFAICT replace objects are not sent over
the wire.
Even if they were, I still don't think it would be appropriate to use
them, for I'm speaking of really different trees. Publishing a commit
replacement would, for anyone who had both my public repository and my
upstream, affect not just the branches I published, but also those in
upstream, which would be surprising and undesirable.
Finally, it wouldn't be a complete solution. Consider, for example, an
objectionable file or tree from an early commit, that I replaced with
something I can live with. A later commit that changed that tree, or
any of those files, would AFAICT *silently* override my replacement,
requiring constant monitoring and new replacements for every such
change.
With the rewrite/rebase model I have in mind, changes to modified files
would conflict, prompting an immediate fix, without any risk of
publishing modified versions of unwanted files. (Of course, in my
particular case I'd still have to monitor for newly-introduced
objectionable stuff, but that's to be expected.)
Did I make any mistakes in my analysis of the “replace” feature? It
would be lovely if I could use it, but, in a way, it appears to be the
dual of what I need: I need to fix a problem in what I provide to
others, while replace would fix the problem in what I see myself.
Anyhow, thanks for the pointer, appreciated!
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
^ permalink raw reply
* Re: [PATCH] msvc: Fix compilation error due to missing mktemp() declaration
From: Erik Faye-Lund @ 2010-12-30 21:47 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, GIT Mailing-list
In-Reply-To: <4D1CDE84.7090402@ramsay1.demon.co.uk>
On Thu, Dec 30, 2010 at 8:33 PM, Ramsay Jones
<ramsay@ramsay1.demon.co.uk> wrote:
> Erik Faye-Lund wrote:
>> On Thu, Dec 23, 2010 at 8:05 PM, Ramsay Jones
>> <ramsay@ramsay1.demon.co.uk> wrote:
>>> Commit d1b6e6e (win32: use our own dirent.h, 2010-11-23) removed
>>> the compat/vcbuild/include/dirent.h compatibility header file.
>>> This file, among other things, included the <io.h> system header
>>> file which provides the declaration of the mktemp() function.
>>>
>>> In order to fix the compilation error, we add an include directive
>>> for <io.h> to the compat/vcbuild/include/unistd.h header. (The
>>> MinGW build includes <io.h> from it's <unistd.h> header too.)
>>>
>>> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
>>> ---
>>
>> Thanks. But shouldn't this header be included in mingw.h (or perhaps
>> msvc.h) because of _get_osfhandle and _commit?
>
> Er... no. ;-)
>
> All uses of _get_osfhandle() and _commit() on the msvc build (after this
> patch) are within the scope of an appropriate declaration, so there is
> no *need* to include <io.h> in either mingw.h or msvc.h.
> [I'm confident the same is true of the MinGW build as well, but I didn't
> have time to check before sending this mail...]
>
> I suspect that you already know this and I'm just being dumb in missing
> the import of your question... Perhaps you could clarify your concerns
> regarding this patch?
>
Actually, I suspect that you know exactly what my concern is (based on
the above), and that it's not with your patch.
I have a patch in my MSVC-tree that includes io.h in mingw.h, because
mingw.h already depends on facilities from io.h on MSVC. My point was
simply that this dependency was already present, and as such I think
mingw.h is the appropriate place to include it.
Your patch might remove the warnings (perhaps it was only msvc.c that
depends on io.h, I don't remember), and that's fine. But I think we
should solve the problem in msvc.[ch] instread, as this is the
compatibility-layer that the rest of the system includes.
But it's just an opinion, deal with it as you please. The most
important part is to prevent warnings/errors, how we do it is
secondary.
^ permalink raw reply
* [PATCH 3/4] gitweb: add css class to remote url titles
From: Sylvain Rabot @ 2010-12-30 21:20 UTC (permalink / raw)
To: git; +Cc: Sylvain Rabot
In-Reply-To: <1293744031-17790-1-git-send-email-sylvain@abstraction.fr>
add a new optional parameter to format_repo_url
routine used to add a css class to the url title cell.
Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr>
---
gitweb/gitweb.perl | 17 +++++++++++------
gitweb/static/gitweb.css | 5 +++++
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index eae75ac..350f8b8 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3881,8 +3881,13 @@ sub git_print_header_div {
}
sub format_repo_url {
- my ($name, $url) = @_;
- return "<tr class=\"metadata_url\"><td>$name</td><td>$url</td></tr>\n";
+ my ($name, $url, $class) = @_;
+
+ if (defined $class) {
+ return "<tr class=\"metadata_url\"><td class=\"$class\">$name</td><td>$url</td></tr>\n";
+ } else {
+ return "<tr class=\"metadata_url\"><td>$name</td><td>$url</td></tr>\n";
+ }
}
# Group output by placing it in a DIV element and adding a header.
@@ -5146,13 +5151,13 @@ sub git_remote_block {
if (defined $fetch) {
if ($fetch eq $push) {
- $urls_table .= format_repo_url("URL", $fetch);
+ $urls_table .= format_repo_url("URL", $fetch, 'metadata_remote_fetch_url');
} else {
- $urls_table .= format_repo_url("Fetch URL", $fetch);
- $urls_table .= format_repo_url("Push URL", $push) if defined $push;
+ $urls_table .= format_repo_url("Fetch URL", $fetch, 'metadata_remote_fetch_url');
+ $urls_table .= format_repo_url("Push URL", $push, 'metadata_remote_push_url') if defined $push;
}
} elsif (defined $push) {
- $urls_table .= format_repo_url("Push URL", $push);
+ $urls_table .= format_repo_url("Push URL", $push, 'metadata_remote_push_url');
} else {
$urls_table .= format_repo_url("", "No remote URL");
}
diff --git a/gitweb/static/gitweb.css b/gitweb/static/gitweb.css
index 79d7eeb..631b20d 100644
--- a/gitweb/static/gitweb.css
+++ b/gitweb/static/gitweb.css
@@ -579,6 +579,11 @@ div.remote {
display: inline-block;
}
+.metadata_remote_fetch_url,
+.metadata_remote_push_url {
+ font-weight: bold;
+}
+
/* Style definition generated by highlight 2.4.5, http://www.andre-simon.de/ */
/* Highlighting theme definition: */
--
1.7.3.4.523.g72f0d.dirty
^ permalink raw reply related
* [PATCH 4/4] gitweb: add vim modeline header which describes gitweb coding rule
From: Sylvain Rabot @ 2010-12-30 21:20 UTC (permalink / raw)
To: git; +Cc: Sylvain Rabot
In-Reply-To: <1293744031-17790-1-git-send-email-sylvain@abstraction.fr>
It is useful for people who have their modeline compliant editor(s)
configured to replace tabs by spaces by default.
Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr>
---
gitweb/gitweb.perl | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 350f8b8..cfe86b4 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1,4 +1,5 @@
#!/usr/bin/perl
+# vim: syntax=perl tabstop=4 noexpandtab:
# gitweb - simple web interface to track changes in git repositories
#
--
1.7.3.4.523.g72f0d.dirty
^ permalink raw reply related
* [PATCH 2/4] gitweb: remove unnecessary test when closing file descriptor
From: Sylvain Rabot @ 2010-12-30 21:20 UTC (permalink / raw)
To: git; +Cc: Sylvain Rabot
In-Reply-To: <1293744031-17790-1-git-send-email-sylvain@abstraction.fr>
it happens that closing file descriptor fails whereas
the blob is perfectly readable. According to perlman
the reasons could be:
If the file handle came from a piped open, "close" will additionally
return false if one of the other system calls involved fails, or if the
program exits with non-zero status. (If the only problem was that the
program exited non-zero, $! will be set to 0.) Closing a pipe also waits
for the process executing on the pipe to complete, in case you want to
look at the output of the pipe afterwards, and implicitly puts the exit
status value of that command into $?.
Prematurely closing the read end of a pipe (i.e. before the process writ-
ing to it at the other end has closed it) will result in a SIGPIPE being
delivered to the writer. If the other end can't handle that, be sure to
read all the data before closing the pipe.
In this case we don't mind that close fails.
Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr>
---
gitweb/gitweb.perl | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index ea984b9..eae75ac 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3465,8 +3465,7 @@ sub run_highlighter {
my ($fd, $highlight, $syntax) = @_;
return $fd unless ($highlight && defined $syntax);
- close $fd
- or die_error(404, "Reading blob failed");
+ close $fd;
open $fd, quote_command(git_cmd(), "cat-file", "blob", $hash)." | ".
quote_command($highlight_bin).
" --xhtml --fragment --syntax $syntax |"
--
1.7.3.4.523.g72f0d.dirty
^ permalink raw reply related
* [PATCH 1/4] gitweb: add extensions to highlight feature map
From: Sylvain Rabot @ 2010-12-30 21:20 UTC (permalink / raw)
To: git; +Cc: Sylvain Rabot
In-Reply-To: <1293744031-17790-1-git-send-email-sylvain@abstraction.fr>
added: sql, php5, phps, bash, zsh, ksh, mk, make
Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr>
---
gitweb/gitweb.perl | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 4779618..ea984b9 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -250,13 +250,14 @@ our %highlight_ext = (
# main extensions, defining name of syntax;
# see files in /usr/share/highlight/langDefs/ directory
map { $_ => $_ }
- qw(py c cpp rb java css php sh pl js tex bib xml awk bat ini spec tcl),
+ qw(py c cpp rb java css php sh pl js tex bib xml awk bat ini spec tcl sql make),
# alternate extensions, see /etc/highlight/filetypes.conf
'h' => 'c',
+ map { $_ => 'sh' } qw(bash zsh ksh),
map { $_ => 'cpp' } qw(cxx c++ cc),
- map { $_ => 'php' } qw(php3 php4),
+ map { $_ => 'php' } qw(php3 php4 php5 phps),
map { $_ => 'pl' } qw(perl pm), # perhaps also 'cgi'
- 'mak' => 'make',
+ map { $_ => 'make'} qw(mak mk),
map { $_ => 'xml' } qw(xhtml html htm),
);
--
1.7.3.4.523.g72f0d.dirty
^ permalink raw reply related
* [PATCH 0/4 v4] minor gitweb modifications
From: Sylvain Rabot @ 2010-12-30 21:20 UTC (permalink / raw)
To: git; +Cc: Sylvain Rabot
Here the v4 and hopefully final version of minor modifications done to gitweb.
I added a fourth commit on top of v3 which adds a modeline header.
This serie has been improved regarding the comments of :
- Jakub Narebski <jnareb@gmail.com>
- Jonathan Nieder <jrnieder@gmail.com>
Regards.
Sylvain Rabot (4):
gitweb: add extensions to highlight feature map
gitweb: remove unnecessary test when closing file descriptor
gitweb: add css class to remote url titles
gitweb: add vim modeline header which describes gitweb coding rule
gitweb/gitweb.perl | 28 +++++++++++++++++-----------
gitweb/static/gitweb.css | 5 +++++
2 files changed, 22 insertions(+), 11 deletions(-)
--
1.7.3.4.523.g72f0d.dirty
^ permalink raw reply
* Re: rebase parents, or tracking upstream but removing non-distributable bits
From: Jonathan Nieder @ 2010-12-30 20:58 UTC (permalink / raw)
To: Alexandre Oliva; +Cc: git
In-Reply-To: <ord3ojb0yy.fsf@livre.localdomain>
Alexandre Oliva wrote:
> Now, it looks like I might be able to pull from upstream if I maintain
> manually a graft file that named each upstream commit as an additional
> parent of the corresponding local rebase commit that brought it into my
> rewritten tree. Workable, maybe, but this wouldn't help third parties
> that used my public repository.
Have you looked into "git replace"?
^ permalink raw reply
* [PATCH] lib-git-svn.sh: Move web-server handling code into separate function
From: Ramsay Jones @ 2010-12-30 19:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list
This library file is currently sourced by 57 test files, of which
only four may (optionally) start a web-server in order to access
the svn repo via an http url, rather than a file url.
In addition to isolating the current web-server handling code from
the majority of tests, in a new prepare_httpd function, we also
add some more error checking and reporting code to validate the
apache installation. Only those tests which attempt to start the
web-server, by calling start_httpd, will execute this code.
Note that it is important for start_httpd to return an error
indication, if prepare_httpd fails, so that the failure to use
the web-server, as requested by the user, should not go unnoticed.
(Unless the svnrepo variable is set to an http url at the end of
start_httpd, the remaining tests will use file urls, without
comment.)
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
Hi Junio,
I just noticed that you have already included the "lib-git-svn.sh:
Add check for mis-configured web server variables" patch (from the
rj/maint-test-fixes branch) into the master branch. This was still
in pu last time I looked! (And so the fix-up patch in my last e-mail
is no longer useful - sorry about that)
This patch is on top of master (as of a couple of days ago: 73e7b2e)
and addresses the fault with the above patch.
ATB,
Ramsay Jones
t/lib-git-svn.sh | 38 +++++++++++++++++++++-----------------
1 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/t/lib-git-svn.sh b/t/lib-git-svn.sh
index 6a9d975..199f22c 100644
--- a/t/lib-git-svn.sh
+++ b/t/lib-git-svn.sh
@@ -68,8 +68,7 @@ svn_cmd () {
svn "$orig_svncmd" --config-dir "$svnconf" "$@"
}
-if test -n "$SVN_HTTPD_PORT"
-then
+prepare_httpd () {
for d in \
"$SVN_HTTPD_PATH" \
/usr/sbin/apache2 \
@@ -83,8 +82,8 @@ then
done
if test -z "$SVN_HTTPD_PATH"
then
- skip_all='skipping git svn tests, Apache not found'
- test_done
+ echo >&2 '*** error: Apache not found'
+ return 1
fi
for d in \
"$SVN_HTTPD_MODULE_PATH" \
@@ -99,23 +98,16 @@ then
done
if test -z "$SVN_HTTPD_MODULE_PATH"
then
- skip_all='skipping git svn tests, Apache module dir not found'
- test_done
- fi
-fi
-
-start_httpd () {
- repo_base_path="$1"
- if test -z "$SVN_HTTPD_PORT"
- then
- echo >&2 'SVN_HTTPD_PORT is not defined!'
- return
+ echo >&2 '*** error: Apache module dir not found'
+ return 1
fi
- if test -z "$repo_base_path"
+ if test ! -f "$SVN_HTTPD_MODULE_PATH/mod_dav_svn.so"
then
- repo_base_path=svn
+ echo >&2 '*** error: Apache module "mod_dav_svn" not found'
+ return 1
fi
+ repo_base_path="${1-svn}"
mkdir "$GIT_DIR"/logs
cat > "$GIT_DIR/httpd.conf" <<EOF
@@ -132,12 +124,24 @@ LoadModule dav_svn_module $SVN_HTTPD_MODULE_PATH/mod_dav_svn.so
SVNPath "$rawsvnrepo"
</Location>
EOF
+}
+
+start_httpd () {
+ if test -z "$SVN_HTTPD_PORT"
+ then
+ echo >&2 'SVN_HTTPD_PORT is not defined!'
+ return
+ fi
+
+ prepare_httpd "$1" || return 1
+
"$SVN_HTTPD_PATH" -f "$GIT_DIR"/httpd.conf -k start
svnrepo="http://127.0.0.1:$SVN_HTTPD_PORT/$repo_base_path"
}
stop_httpd () {
test -z "$SVN_HTTPD_PORT" && return
+ test ! -f "$GIT_DIR/httpd.conf" && return
"$SVN_HTTPD_PATH" -f "$GIT_DIR"/httpd.conf -k stop
}
--
1.7.3
^ permalink raw reply related
* Re: [PATCH] msvc: Fix compilation error due to missing mktemp() declaration
From: Ramsay Jones @ 2010-12-30 19:33 UTC (permalink / raw)
To: kusmabite; +Cc: Junio C Hamano, GIT Mailing-list
In-Reply-To: <AANLkTineKS2e8PJs76PLZP4L4APwX2kAiFPg4pz3esae@mail.gmail.com>
Erik Faye-Lund wrote:
> On Thu, Dec 23, 2010 at 8:05 PM, Ramsay Jones
> <ramsay@ramsay1.demon.co.uk> wrote:
>> Commit d1b6e6e (win32: use our own dirent.h, 2010-11-23) removed
>> the compat/vcbuild/include/dirent.h compatibility header file.
>> This file, among other things, included the <io.h> system header
>> file which provides the declaration of the mktemp() function.
>>
>> In order to fix the compilation error, we add an include directive
>> for <io.h> to the compat/vcbuild/include/unistd.h header. (The
>> MinGW build includes <io.h> from it's <unistd.h> header too.)
>>
>> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
>> ---
>
> Thanks. But shouldn't this header be included in mingw.h (or perhaps
> msvc.h) because of _get_osfhandle and _commit?
Er... no. ;-)
All uses of _get_osfhandle() and _commit() on the msvc build (after this
patch) are within the scope of an appropriate declaration, so there is
no *need* to include <io.h> in either mingw.h or msvc.h.
[I'm confident the same is true of the MinGW build as well, but I didn't
have time to check before sending this mail...]
I suspect that you already know this and I'm just being dumb in missing
the import of your question... Perhaps you could clarify your concerns
regarding this patch?
ATB,
Ramsay Jones
^ permalink raw reply
* rebase parents, or tracking upstream but removing non-distributable bits
From: Alexandre Oliva @ 2010-12-30 17:54 UTC (permalink / raw)
To: git
Say the git repository of a project I use (with changes) on another
projet I work on contains portions that I oughtn't distribute. Say,
portions that are illegal, immoral or too risky in my jurisdiction:
patented stuff that lawyers say I should not distribute in anyway,
unauthorized or otherwise copyright-infringing bits, text or pictures
that are offensive or even illegal to publish, i.e., stuff that I must
not be caught distributing and that, ideally, I could arrange to not
even possess.
If you guessed that my primary reason to want this is the non-Free
Software in the Linux git repository, you got it right :-) Anyhow,
regardless of your opinion as to my stance in this matter, I hope you'll
agree that the scenarios above are relevant and desirable. Heck, even a
business that decides to remove all traces from a feature that was
planned for a certain release, but that is pushed back to a later
release, could benefit from this.
Note that simply reverting/removing these bits from the head of a branch
wouldn't be enough: since the repository carries the entire history,
pushing the head of the branch to my public repository would amount to
publishing the bits I must not publish.
I need to be able to maintain and publish a modified repository, that
filters out the unwanted portions, but still be able to pull changes
from the upstream repository. Desirable, but not strictly necessary, is
the possibility of letting upstream pull my improvements, without
bringing in the changes I made to remove the bits I'm not supposed to
distribute.
Given this problem statement, I started looking for solutions that
didn't require modifying git.
I first looked into rewriting history, removing the unwanted bits and
replaying subsequent changes, but quickly discarded it, for it would
make my local repository incompatible with upstream both ways: I
wouldn't be able to pull from it; upstream wouldn't be able to pull to
it; third parties would run into ugly situations trying to carry patches
from either one to the other.
Now, it looks like I might be able to pull from upstream if I maintain
manually a graft file that named each upstream commit as an additional
parent of the corresponding local rebase commit that brought it into my
rewritten tree. Workable, maybe, but this wouldn't help third parties
that used my public repository.
Besides, I'm concerned that pushing from the local repository (with the
graft file) to the public repository would end up publishing the changes
I'm not supposed to distribute, because they'd be taken as parents of
the local commits.
Are there any other ways to support the desired features with git as-is?
AFAICT, there isn't, so I've been thinking of how to introduce this. I
suppose the simplest way to accomplish this is to introduce the notion
of a “weak parent”: one that is taken into account for purposes of
checking whether a commit is present in a branch being merged- or
rebased into, but that is not transmitted over pushes, and that is not
retained over purges, and not complained about when missing.
I'm under the impression that this could not just work, but also make
rebasing in general (especially the hard case) far less problematic, for
git would be able to relate a rebased commit with an original commit.
Now, assuming I'm correct in this assessment, there are two questions
that remain:
- how to represent this?
I thought of changing the commit blob format so as to somehow mark the
weak parents, say, with an additional character on the same line:
parent f00ba5... W
an alternate header:
wparent f00ba5...
or even an additional line:
parent f00ba5...
...
weak f00ba5...
For some backward compatibility, it looks like only the last form would
as much as stand a chance of being properly parsed, if the weak notes
are added at the end of the blob.
Another possibility is to create another kind of object, that named an
original and rebased commit and that, like a tag object, would be
(optionally?) transmitted when the (rebased) commit it named was
transmitted. This could be more interesting, in that it might enable
all traces of a rebase to be eventually removed. A (named?) object that
names multiple such pairs of commits might make even more sense to this
end.
Am I on the right track? Any thoughts, preferences, suggestions,
concerns, recommendations, advice, pointers or gotchas to watch out for
before I start implementing any of these possibilities?
I realize that, although this option could make “git pull --rebase” work
to track upstream in the rebased branch, and would enable me to publish
the repository with the rebased branch without the pieces I shouldn't
distribute, I'm not sure this would enable upstream to easily integrate
my changes. Or would it?
Thanks in advance,
I'm not subscribed, but I'm going to look for replies in the archives.
That said, I'd appreciate if you'd explicitly copy me in any follow ups.
(Mail-Followup-To: set accordingly)
Last but not least: Happy GNU Year! :-)
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
^ permalink raw reply
* Re: custom diff - text file diary entries
From: Santi Béjar @ 2010-12-30 13:47 UTC (permalink / raw)
To: Zenaan Harkness; +Cc: git
In-Reply-To: <AANLkTinAJ=Dzn6u7Xu=dqkzm+tiB2M_nGE2=EzRDnPEa@mail.gmail.com>
On Thu, Dec 30, 2010 at 1:36 PM, Zenaan Harkness <zen@freedbms.net> wrote:
> On Thu, Dec 30, 2010 at 23:22, Andreas Ericsson <ae@op5.se> wrote:
>> On 12/30/2010 12:33 PM, Zenaan Harkness wrote:
>>> Problem:
>>> Separate text file diary entries, committed in separate repos,
>>> cause merge clash when pushed to central repo,
>>> since git thinks the two entries are a single conflicting entry
>>> (since they begin at the same location in the same file).
>>>
>>> What we need is two diary entries automatically detected and inserted
>>> into the one file, one above the other (ordering is not so important).
> ...
>> If you really, really want to use git for this, you could create your
>> own custom merge driver. How to do so is reasonably well documented in
>> examples and man-pages. You'll want to sneak a peak at the attributes
>> page.
>
> "custom merge driver .. attributes page"
Maybe you are interested also in these ChangeLog merge driver for git:
https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools#git-merge-changelog
HTH,
Santi
^ 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