* Re: git-svn of both trunk and tags while having no access to the 'parent' of those
From: Michael J Gruber @ 2009-11-18 15:07 UTC (permalink / raw)
To: Yaroslav Halchenko; +Cc: git, Eric Wong
In-Reply-To: <20091118142332.GC17964@onerussian.com>
Yaroslav Halchenko venit, vidit, dixit 18.11.2009 15:23:
>
> On Wed, 18 Nov 2009, Michael J Gruber wrote:
>>> git svn clone --no-minimize-url --prefix=upstream-svn/ -T trunk -t releases http://domain.com/svnrepo/trunk svnrepo.gitsvn
>> Is the trunk really at svnrepo/trunk/trunk?
> nope... it is just svnrepo/trunk but if I set url to point to parent --
> git svn seeks authentication right away
>
>> I would try both
>> git svn clone --no-minimize-url --prefix=upstream-svn/ -T trunk -t
>> releases http://domain.com/svnrepo/ svnrepo.gitsvn
>
> asks for authentication since there is no public access to
> http://domain.com/svnrepo/
>
>> and also the seemingly equivalent
>
>> git svn clone --no-minimize-url --prefix=upstream-svn/ -T
>> http://domain.com/svnrepo/trunk -t http://domain.com/svnrepo/releases
>> svnrepo.gitsvn
> seems to not work since it wants url as a parameter
>
> Bad URL passed to RA layer: Illegal repository URL svnrepo.gitsvn at /usr/lib/git-core/git-svn line 940
>
>> Also, I assume you can svn list http://domain.com/svnrepo/trunk and
>> http://domain.com/svnrepo/releases ;)
> yeap -- I can list both of those but not their parent.
>
>
OK, so the way it's implemented --no-minimize-url might be half as
useful as it could be. One last try (before asking Eric...) would be
git svn clone --no-minimize-url --prefix=upstream-svn/ -T
http://domain.com/svnrepo/trunk -t http://domain.com/svnrepo/releases
http://domain.com/svnrepo/trunk svnrepo.gitsvn
because that involves accessible URLs only and trunk and branch URLs are
absolute.
[Meanwhile I git the actual URL PMed by Yaroslov.]
So, what happens with the above is that git-svn tries to set the URL
config again from the URL part of an absolute tags argument. I don't
know how absolute URLs (which are documented) for tags etc. could
possibly work if git-svn tries to do that. Eric?
I tried also with two svn sections to circumvent this:
[svn-remote "svn"]
url = http://domain.com:/project/trunk
fetch = :refs/remotes/trunk
[svn-remote "svnr"]
url = http://domain.com:/project/releases
tags = /*:refs/remotes/tags/*
Fetching -Rsvn works fine, but fetching -Rsvnr gives the same
authentication problems. And fetch does not accept --no-minimize-url as
an option. OTOH: If the option is not used it seems to me (from the
source) that not minimizing is the default, which leaves me really
stomped. Eric?? ;)
Michael
^ permalink raw reply
* Re: [PATCHv3] Add branch management for releases to gitworkflows
From: Thomas Rast @ 2009-11-18 14:59 UTC (permalink / raw)
To: Raman Gupta; +Cc: Nanako Shiraishi, git, gitster, skillzero
In-Reply-To: <4B033D8F.1080309@fastmail.fm>
Raman Gupta wrote:
>
> I *am* a native English speaker. Sadly, its the *only* language I
> speak, read, and write. However, additional comments would
> definitely be nice.
Oh, my apologies. I just looked at the names and jumped to
conclusions from there.
> Agree. I reworded the sections to untangle the information
> somewhat. Let me know what you think.
[...]
> * `git merge --ff-only master`
> =====================================
>
[...]
> +If the merge fails because it is not a fast-forward, then it is
> +possible some fixes on 'maint' were missed in the feature release.
> +This will not happen if the content of the branches was verified as
> +described in the previous section.
Yes, I think that is nicer. It's no longer a repetition of what was
said above, but merely points out what could have gone wrong and where
to look for advice. The last sentence sounds a bit like "ha ha we
told you so!" though ;-)
FWIW, you can add my
Acked-by: Thomas Rast <trast@student.ethz.ch>
to the final (squashed) patch.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* git-mailinfo doesn't stop parsing at the end of the header
From: Philip Hofstetter @ 2009-11-18 14:20 UTC (permalink / raw)
To: git
Hello,
today, after working on a topic branch and trying to rebase it on top
of the updated master, the rebase failed, complaining about an invalid
email address.
Some investigating revealed an interesting quirk in git-mailinfo which
seems to be a bit too eager to extract author information: Instead of
just looking at the From:-Line in a mails header (git-rebase seems to
use git-am which in turn uses git-mailinfo), it searches for "from:"
*anywhere* in the mail and uses the last found information as the
source for the author information.
In this case, git-format-patch has generated a file that looks
something like this:
--------------8<---------------
From d28f21ea8ca64681ba7756417799ceea81ad6873 Mon Sep 17 00:00:00 2001
From: Foo Bar <foo@bar.com>
Date: Tue, 17 Nov 2009 15:27:25 +0100
Subject: blah, blah, blah
from:
- this is a
- list for stuff
---
list/of/changed/files | 1 -
list/of/changed/files2 | 1 -
2 files changed, 0 insertions(+), 2 deletions(-)
the actual diff down here
--------------8<---------------
And when you feed this into mailinfo, this is what you get:
pilif@celes ~/git % git mailinfo /dev/null /dev/null < somepatch.patch
Author:
Email:
Subject: blah, blah, blah
Date: Tue, 17 Nov 2009 15:27:25 +0100
pilif@celes ~/git %
and consequently, anything that depends on the correct author being
extracted then fails.
While I know it's rude to have a line beginning with "from:" (and it's
even ruder to have a line beginning with "from "), IMHO the header
ends at the first blank line and I see no reason to extract author
information past the header.
And if this is in fact intended behavior, it should probably not be
permitted to create a commit that later on can't be rebased or applied
using git-am.
I had a look at the source of git-mailinfo to fix it myself, but this
thing does too much for my minimal knowledge in C.
Philip
--
Sensational AG
Giesshübelstrasse 62c, Postfach 1966, 8021 Zürich
Tel. +41 43 544 09 60, Mobile +41 79 341 01 99
info@sensational.ch, http://www.sensational.ch
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2009, #04; Tue, 17)
From: Nguyen Thai Ngoc Duy @ 2009-11-18 14:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7hto46ce.fsf@alter.siamese.dyndns.org>
On 11/18/09, Junio C Hamano <gitster@pobox.com> wrote:
> * nd/sparse (2009-08-20) 19 commits.
> - sparse checkout: inhibit empty worktree
> - Add tests for sparse checkout
> - read-tree: add --no-sparse-checkout to disable sparse checkout support
> - unpack-trees(): ignore worktree check outside checkout area
> - unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
> - unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
> - unpack-trees.c: generalize verify_* functions
> - unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
> - Introduce "sparse checkout"
> - dir.c: export excluded_1() and add_excludes_from_file_1()
> - excluded_1(): support exclude files in index
> - unpack-trees(): carry skip-worktree bit over in merged_entry()
> - Read .gitignore from index if it is skip-worktree
> - Avoid writing to buffer in add_excludes_from_file_1()
> - Teach Git to respect skip-worktree bit (writing part)
> - Teach Git to respect skip-worktree bit (reading part)
> - Introduce "skip-worktree" bit in index, teach Git to get/set this bit
> - Add test-index-version
> - update-index: refactor mark_valid() in preparation for new options
>
> The latest update I didn't look at very closely but I had an impression
> that it was touching very generic codepath that would affect non sparse
> cases, iow the patch looked very scary (the entire series already is).
I wonder if there is any other approach for sparse checkout? I'll see
if I can improve it, but with a series touching unpack logic, diff
core, .gitattributes/.gitignore, it's hard to get it right and
obvious.
--
Duy
^ permalink raw reply
* Re: git-svn of both trunk and tags while having no access to the 'parent' of those
From: Yaroslav Halchenko @ 2009-11-18 14:23 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4B03FD29.3090001@drmicha.warpmail.net>
On Wed, 18 Nov 2009, Michael J Gruber wrote:
> > git svn clone --no-minimize-url --prefix=upstream-svn/ -T trunk -t releases http://domain.com/svnrepo/trunk svnrepo.gitsvn
> Is the trunk really at svnrepo/trunk/trunk?
nope... it is just svnrepo/trunk but if I set url to point to parent --
git svn seeks authentication right away
> I would try both
> git svn clone --no-minimize-url --prefix=upstream-svn/ -T trunk -t
> releases http://domain.com/svnrepo/ svnrepo.gitsvn
asks for authentication since there is no public access to
http://domain.com/svnrepo/
> and also the seemingly equivalent
> git svn clone --no-minimize-url --prefix=upstream-svn/ -T
> http://domain.com/svnrepo/trunk -t http://domain.com/svnrepo/releases
> svnrepo.gitsvn
seems to not work since it wants url as a parameter
Bad URL passed to RA layer: Illegal repository URL svnrepo.gitsvn at /usr/lib/git-core/git-svn line 940
> Also, I assume you can svn list http://domain.com/svnrepo/trunk and
> http://domain.com/svnrepo/releases ;)
yeap -- I can list both of those but not their parent.
--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
^ permalink raw reply
* Re: [PATCH] Give the hunk comment its own color
From: Jeff King @ 2009-11-18 14:23 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Junio C Hamano, git
In-Reply-To: <1258543836-799-1-git-send-email-bert.wesarg@googlemail.com>
On Wed, Nov 18, 2009 at 12:30:36PM +0100, Bert Wesarg wrote:
> Insired by the coloring of quilt.
>
> Introduce a separate color for the hunk comment part, i.e. the current
> function. Whitespace between hunk header and hunk comment is now
> printed as plain.
>
> The current default is magenta. But I'm not settled on this. My
> favorite would be bold yellow.
I don't see any reason not to add this, as it is simply introducing one
extra knob to tweak for people who care. However, after some
experimentation, I found that I don't personally really like it. I ended
up wanting it set to the same color as the hunk header.
I wonder how hard it would be to make it backwards-compatible; that is,
to inherit the color value of the hunk header (be it the original or one
set by the user) unless the func color is set by the user. But maybe
that is over-engineering. It is not like we are breaking scripts, and it
is not that hard for people to see the new behavior and then tweak their
config if they don't like it.
-Peff
PS I almost complained about your default of "magenta" as the same as
the meta color before I remembered that magenta meta is a personal
setting I use. Personally I find the bold meta color to be distractingly
ugly. Blaming it, the default seems to come from Linus, who even in his
commit message (50f575f) seems to indicate that it is somewhat arbitrary
(mostly just dropping the purple from the bold purple).
I'm not sure what is the best way to arrive at a default color for
something like this. Arguing about it really is almost the definition of
bikeshedding. Maybe next year's git survey should contain a special
section on colors, and majority should rule. :)
^ permalink raw reply
* Re: Hey - A Conceptual Simplication....
From: Jonathan del Strother @ 2009-11-18 13:18 UTC (permalink / raw)
To: George Dennie; +Cc: git, torvalds
In-Reply-To: <005a01ca684e$71a1d710$54e58530$@com>
2009/11/18 George Dennie <gdennie@pospeople.com>:
> A Clean checkout command might be...
>
> The Git model does not seem to go far enough conceptually, for some
> unexplainable reason...
>
> In particular, why is Git not treating the entire working tree as the
> versioned document (qualified of course by the .gitignore file).
>
> Instead, Git is treating a manually maintained list of files within the
> working tree as the versioned document, this list being initialized and
> manually amended by the "Git add/rm/mv" commands, etc.
>
> The result is conceptual complexity and rather counter-intuitive behavior.
> For example, adding and renaming files outside of Git is not considered
> editing the version until you subsequently do a "Git Add ." Contrast that
> with editing or deleting files outside of Git. Yet adding and renaming files
> and folders is a significant part of substantive projects, especially in the
> early stages and experimental branches.
>
> Granted, this is not a big deal functionally, but what is being lost is
> conceptual simplicity (and consistency, in my book) and conceptual
> simplicity is a key value point, if not THE key.
>
> Also can we augment checkout to totally CLEAN the working directory prior to
> a restore. If necessary we can augment .gitignore to stipulate those files
> or folders that should be excluded from the cleaning. This suggestion is in
> recognition of the fact that if you are not versioning the file, it is
> typically trash; which becomes the case when the entire working treat is
> treated as the versioned document.
>
> Consequently, I recommend the following new commands:
> "Git commit -x" -- performs a "Git add ." then a "Git commit"
> "Git checkout -x" -- that clean the working tree prior to perform a
> checkout
>
Perhaps try 'git commit -a' and 'git checkout -f' ?
^ permalink raw reply
* Re: git-svn of both trunk and tags while having no access to the 'parent' of those
From: Michael J Gruber @ 2009-11-18 13:56 UTC (permalink / raw)
To: Yaroslav Halchenko; +Cc: git
In-Reply-To: <20091118133205.GB17964@onerussian.com>
Yaroslav Halchenko venit, vidit, dixit 18.11.2009 14:32:
>
> On Wed, 18 Nov 2009, Michael J Gruber wrote:
>
>>> git svn clone --prefix=upstream-svn/ -T trunk -t releases http://domain.com/svnrepo svnrepo.gitsvn
>
>> Your problem description seems to match perfectly with the description
>> of the "--no-minimize-url" option in git svn's man page. I'm sure it's
>> worth a try.
>
> ;-) oh I did I did ;)
> I've used
>
> git svn clone --no-minimize-url --prefix=upstream-svn/ -T trunk -t releases http://domain.com/svnrepo/trunk svnrepo.gitsvn
Is the trunk really at svnrepo/trunk/trunk?
> that initialized repository, went through a lengthy list of
>
> trace: built-in: git 'config' 'svn-remote.svn.tags-maxRev' '...'
>
> with last command reported
>
> trace: built-in: git 'gc' '--auto'
>
> and resulted in nothing being cloned/checked out or even a single ref.
> The only file under .git besides the ones created by git init
>
> ./svn/refs/remotes/upstream-svn/trunk/.rev_map.33fb83da-1015-0410-9b9b-96027f9a4af8
>
> and if I omitted trunk/ from url -- the same story of needed
> authentication
I would try both
git svn clone --no-minimize-url --prefix=upstream-svn/ -T trunk -t
releases http://domain.com/svnrepo/ svnrepo.gitsvn
and also the seemingly equivalent
git svn clone --no-minimize-url --prefix=upstream-svn/ -T
http://domain.com/svnrepo/trunk -t http://domain.com/svnrepo/releases
svnrepo.gitsvn
Also, I assume you can svn list http://domain.com/svnrepo/trunk and
http://domain.com/svnrepo/releases ;)
Michael
^ permalink raw reply
* [PATCH RESEND] Explicitly truncate bswap operand to uint32_t
From: Benjamin Kramer @ 2009-11-18 13:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nicolas Pitre
There are some places in git where a long is passed to htonl/ntohl. llvm
doesn't support matching operands of different bitwidths intentionally.
This patch fixes the build with llvm-gcc (and clang) on x86_64.
Signed-off-by: Benjamin Kramer <benny.kra@googlemail.com>
---
Any comments on this patch?
See also:
* http://llvm.org/bugs/show_bug.cgi?id=3373
* http://lkml.org/lkml/2009/1/23/261
compat/bswap.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/compat/bswap.h b/compat/bswap.h
index 279e0b4..f3b8c44 100644
--- a/compat/bswap.h
+++ b/compat/bswap.h
@@ -24,7 +24,7 @@ static inline uint32_t default_swab32(uint32_t val)
if (__builtin_constant_p(x)) { \
__res = default_swab32(x); \
} else { \
- __asm__("bswap %0" : "=r" (__res) : "0" (x)); \
+ __asm__("bswap %0" : "=r" (__res) : "0" ((uint32_t)(x))); \
} \
__res; })
--
1.6.5.3.149.g9aa3
^ permalink raw reply related
* [PATCH] describe: do not use unannotated tag even if exact match
From: Thomas Rast @ 2009-11-18 13:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
4d23660 (describe: when failing, tell the user about options that
work, 2009-10-28) forgot to update the shortcut path where the code
detected and used a possible exact match. This means that an
unannotated tag on HEAD would be used by 'git describe'.
Guard this code path against the new circumstances, where unannotated
tags can be present in ->util even if we're not actually planning to
use them.
While there, also add some tests for --all.
Reported by 'yashi' on IRC.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
builtin-describe.c | 2 +-
t/t6120-describe.sh | 6 ++++++
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/builtin-describe.c b/builtin-describe.c
index d4efb10..71be2a9 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -200,7 +200,7 @@ static void describe(const char *arg, int last_one)
die("%s is not a valid '%s' object", arg, commit_type);
n = cmit->util;
- if (n) {
+ if (n && (tags || all || n->prio == 2)) {
/*
* Exact match to an existing ref.
*/
diff --git a/t/t6120-describe.sh b/t/t6120-describe.sh
index c050f94..065dead 100755
--- a/t/t6120-describe.sh
+++ b/t/t6120-describe.sh
@@ -92,12 +92,18 @@ check_describe A-* HEAD^
check_describe D-* HEAD^^
check_describe A-* HEAD^^2
check_describe B HEAD^^2^
+check_describe D-* HEAD^^^
check_describe c-* --tags HEAD
check_describe c-* --tags HEAD^
check_describe e-* --tags HEAD^^
check_describe c-* --tags HEAD^^2
check_describe B --tags HEAD^^2^
+check_describe e --tags HEAD^^^
+
+check_describe heads/master --all HEAD
+check_describe tags/c-* --all HEAD^
+check_describe tags/e --all HEAD^^^
check_describe B-0-* --long HEAD^^2^
check_describe A-3-* --long HEAD^^2
--
1.6.5.3.381.gfeb7e
^ permalink raw reply related
* Re: git-svn of both trunk and tags while having no access to the 'parent' of those
From: Yaroslav Halchenko @ 2009-11-18 13:32 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4B03B7D3.8050905@drmicha.warpmail.net>
On Wed, 18 Nov 2009, Michael J Gruber wrote:
> > git svn clone --prefix=upstream-svn/ -T trunk -t releases http://domain.com/svnrepo svnrepo.gitsvn
> Your problem description seems to match perfectly with the description
> of the "--no-minimize-url" option in git svn's man page. I'm sure it's
> worth a try.
;-) oh I did I did ;)
I've used
git svn clone --no-minimize-url --prefix=upstream-svn/ -T trunk -t releases http://domain.com/svnrepo/trunk svnrepo.gitsvn
that initialized repository, went through a lengthy list of
trace: built-in: git 'config' 'svn-remote.svn.tags-maxRev' '...'
with last command reported
trace: built-in: git 'gc' '--auto'
and resulted in nothing being cloned/checked out or even a single ref.
The only file under .git besides the ones created by git init
./svn/refs/remotes/upstream-svn/trunk/.rev_map.33fb83da-1015-0410-9b9b-96027f9a4af8
and if I omitted trunk/ from url -- the same story of needed
authentication
--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
^ permalink raw reply
* Re: Hey - A Conceptual Simplication....
From: Jason Sewall @ 2009-11-18 13:31 UTC (permalink / raw)
To: George Dennie; +Cc: git, torvalds
In-Reply-To: <005a01ca684e$71a1d710$54e58530$@com>
On Wed, Nov 18, 2009 at 7:55 AM, George Dennie <gdennie@pospeople.com> wrote:
>
> In particular, why is Git not treating the entire working tree as the
> versioned document (qualified of course by the .gitignore file).
>
> Instead, Git is treating a manually maintained list of files within the
> working tree as the versioned document, this list being initialized and
> manually amended by the "Git add/rm/mv" commands, etc.
Isn't fastidiously maintaining a .gitignore file to contain everything
you *don't* want in the project more confusing than explicitly
specifying things you *do* want in the project?
> The result is conceptual complexity and rather counter-intuitive behavior.
> For example, adding and renaming files outside of Git is not considered
> editing the version until you subsequently do a "Git Add ." Contrast that
> with editing or deleting files outside of Git. Yet adding and renaming files
> and folders is a significant part of substantive projects, especially in the
> early stages and experimental branches.
>
> Granted, this is not a big deal functionally, but what is being lost is
> conceptual simplicity (and consistency, in my book) and conceptual
> simplicity is a key value point, if not THE key.
In fact, it's a big deal in functionality, but the utility is in being
able to to specify exactly what I want to be part of each commit. One
of git's great features is the ability to specify *exactly* what you
want to be part of each commit, down to the line. This means that each
commit can be extremely fine grained and represent specific bug fixes
and or features.
If you have a bunch of debugging code sitting around in your working
tree after you've tracked down a problem, you don't want to commit all
of those printfs, etc. - you want to commit the fix. This has
ramifications from making diffs of history cleaner to making git
bisect actually useful.
> Also can we augment checkout to totally CLEAN the working directory prior to
> a restore. If necessary we can augment .gitignore to stipulate those files
> or folders that should be excluded from the cleaning. This suggestion is in
> recognition of the fact that if you are not versioning the file, it is
> typically trash; which becomes the case when the entire working treat is
> treated as the versioned document.
This is even worse. It's already pretty easy to trash your working
directory by reflexively typing git checkout -f, and you want to
> Consequently, I recommend the following new commands:
> "Git commit -x" -- performs a "Git add ." then a "Git commit"
> "Git checkout -x" -- that clean the working tree prior to perform a
> checkout
I see that Jan has replied with some loaded guns, *ahem* aliases. Go
ahead and use them, but I recommend you look at the diffs in git.git
or some other repository that takes advantage of making commits as
compact as possible, and learn how to use git add -p.
Jason
^ permalink raw reply
* Re: Hey - A Conceptual Simplication....
From: Thomas Rast @ 2009-11-18 13:30 UTC (permalink / raw)
To: George Dennie; +Cc: git, torvalds
In-Reply-To: <005a01ca684e$71a1d710$54e58530$@com>
George Dennie wrote:
>
> Instead, Git is treating a manually maintained list of files within the
> working tree as the versioned document, this list being initialized and
> manually amended by the "Git add/rm/mv" commands, etc.
This feature is called the "index", and is not merely a list of the
files, but also their content. Please read
http://tomayko.com/writings/the-thing-about-git
for a nice explanation why this is a good and useful thing.
> "Git commit -x" -- performs a "Git add ." then a "Git commit"
> "Git checkout -x" -- that clean the working tree prior to perform a checkout
That would require supernaturally good maintenance of your .gitignore
to avoid adding or (worse) nuking files by accident.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [ANNOUNCE] codeBeamer MR - Easy ACL for Git
From: Intland Software @ 2009-11-18 13:19 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20091118120936.GL17748@machine.or.cz>
Thanks for your comments, Petr.
Petr Baudis wrote:
>> LEARN MORE & DOWNLOAD
>> More details, screenshots and downloads:
>> http://www.intland.com/products/cb-mr/overview.html
>
> Interesting, thank you for the announcement; it would be good to note
> that it's not open-source.
That's right, codeBeamer MR is not open source.
More precisely: parts of the source code are actually open, including
the wiki plugins and the remote clients, for instance. The core source
is closed, because the same core is also used in our commercial offerings, and
our commercial license doesn't (currently) allow publishing the
complete code. We have quite some large customers from the defense space
that would not be happy if we opened everything ;)
We are currently in the midst of rethinking our licensing scheme
in general, to make things more liberal or to set up some kind of a
dual license.
> I think a lot of people wonder now, how does this compare to existing
> solutions; from your announcement I thought it's something like
> Gitosis/Gitolite, but in fact it seems more similar to Gitorious or
> GitHub (if it was publicly available, of course); perhaps it would be
> good idea to present comparison to these on the project homepage.
Good point. More on this later.
---
Intland
^ permalink raw reply
* Re: [PATCH] Makefile: add uninstall target. Fixes elementary good cleaning manners.
From: Matthieu Moy @ 2009-11-18 13:28 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: Tomas Carnecky, git
In-Reply-To: <1258547389.25909.101.camel@heerbeest>
Jan Nieuwenhuizen <janneke-list@xs4all.nl> writes:
> Sorry. Let me retry that. See below.
Please, read Documentation/SubmittingPatches
>>From f260a4dcf0b42088eb1da74aee49f49ac4b0c55b Mon Sep 17 00:00:00 2001
> From: Jan Nieuwenhuizen <janneke@gnu.org>
> Date: Wed, 11 Nov 2009 14:19:00 +0100
> Subject: [PATCH] Makefile: add uninstall target. Fixes elementary good cleaning manners.
>
> * Modified Makefile
> * Modified gitk-git/Makefile
> * Modified perl/Makefile
> * Modified templates/Makefile
Git knows better than you which files are modified by a commit, so
it's counter-productive to rewrite by hand this list in the commit
message. This place is the place to explain _why_ your change is good
(to convince the maintainer to apply it in git.git in particular).
> Makefile | 18 +++++++++++++++++-
> gitk-git/Makefile | 2 ++
> perl/Makefile | 2 +-
> templates/Makefile | 5 +++++
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Hey - A Conceptual Simplication....
From: Jan Krüger @ 2009-11-18 13:25 UTC (permalink / raw)
To: George Dennie; +Cc: git, torvalds
In-Reply-To: <005a01ca684e$71a1d710$54e58530$@com>
Hi,
> The result is conceptual complexity and rather counter-intuitive
> behavior. For example, adding and renaming files outside of Git is
> not considered editing the version until you subsequently do a "Git
> Add ." Contrast that with editing or deleting files outside of Git.
> Yet adding and renaming files and folders is a significant part of
> substantive projects, especially in the early stages and experimental
> branches.
yet even now, people routinely add huge amounts of files they didn't
actually want to add, and then have to expend a huge amount of effort
to get them out of the history again (particularly if that history has
already been published).
What you are describing is a workflow that is even fuller of potential
for wrong turns than the current standard workflow is. If simplicity
leads to a greater potential for errors, how is it a good thing?
This kind of workflow actually involves more work for the user. She now
has to meticulously maintain an accurate list of ignore patterns,
particularly because of this:
> Also can we augment checkout to totally CLEAN the working directory
> prior to a restore. If necessary we can augment .gitignore to
> stipulate those files or folders that should be excluded from the
> cleaning.
So if I forget to add a certain pattern, my file is lost forever? Uhh...
> This suggestion is in recognition of the fact that if you
> are not versioning the file, it is typically trash
Just how typical is that, though? I wouldn't want to be the one to
judge that.
In light of my concerns, I oppose adding your suggestions to the
official CLI of git and I suggest that you create your own commands to
enable this kind of workflow. For example:
git config --global alias.commitx '!git add . && git commit'
git config --global alias.checkoutx '!git clean && git checkout'
Jan
^ permalink raw reply
* Hey - A Conceptual Simplication....
From: George Dennie @ 2009-11-18 12:55 UTC (permalink / raw)
To: git; +Cc: torvalds
A Clean checkout command might be...
The Git model does not seem to go far enough conceptually, for some
unexplainable reason...
In particular, why is Git not treating the entire working tree as the
versioned document (qualified of course by the .gitignore file).
Instead, Git is treating a manually maintained list of files within the
working tree as the versioned document, this list being initialized and
manually amended by the "Git add/rm/mv" commands, etc.
The result is conceptual complexity and rather counter-intuitive behavior.
For example, adding and renaming files outside of Git is not considered
editing the version until you subsequently do a "Git Add ." Contrast that
with editing or deleting files outside of Git. Yet adding and renaming files
and folders is a significant part of substantive projects, especially in the
early stages and experimental branches.
Granted, this is not a big deal functionally, but what is being lost is
conceptual simplicity (and consistency, in my book) and conceptual
simplicity is a key value point, if not THE key.
Also can we augment checkout to totally CLEAN the working directory prior to
a restore. If necessary we can augment .gitignore to stipulate those files
or folders that should be excluded from the cleaning. This suggestion is in
recognition of the fact that if you are not versioning the file, it is
typically trash; which becomes the case when the entire working treat is
treated as the versioned document.
Consequently, I recommend the following new commands:
"Git commit -x" -- performs a "Git add ." then a "Git commit"
"Git checkout -x" -- that clean the working tree prior to perform a
checkout
P.S.
Great your work.
George Dennie, BMath
The Point Of Sale People
www.pospeople.com
BUS: 416-496-2921
FAX: 416-496-9496
^ permalink raw reply
* [PATCH] Makefile: add uninstall target. Fixes elementary good cleaning manners.
From: Jan Nieuwenhuizen @ 2009-11-18 12:29 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: git
In-Reply-To: <48B54636-1825-48B3-BECD-4150A55B013F@dbservice.com>
Op woensdag 11-11-2009 om 15:08 uur [tijdzone +0100], schreef Tomas
Carnecky:
> > Greetings,
> > Jan. -- who just finds out the uninstall target is missing?!?
> > See attached.
>
> Next time please send patches inline, it's easier to review them that
> way.
Sorry. Let me retry that. See below.
Greetings,
Jan.
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl | http://lilypond.org
>From f260a4dcf0b42088eb1da74aee49f49ac4b0c55b Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen <janneke@gnu.org>
Date: Wed, 11 Nov 2009 14:19:00 +0100
Subject: [PATCH] Makefile: add uninstall target. Fixes elementary good cleaning manners.
* Modified Makefile
* Modified gitk-git/Makefile
* Modified perl/Makefile
* Modified templates/Makefile
Signed-off-by: Jan Nieuwenhuizen <janneke@gnu.org>
---
Makefile | 18 +++++++++++++++++-
gitk-git/Makefile | 2 ++
perl/Makefile | 2 +-
templates/Makefile | 5 +++++
4 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 5d5976f..135c3ac 100644
--- a/Makefile
+++ b/Makefile
@@ -1781,7 +1781,23 @@ quick-install-man:
quick-install-html:
$(MAKE) -C Documentation quick-install-html
+bindir_PROGRAMS = git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X git-shell$X git-cvsserver
+uninstall:
+ifndef NO_TCLTK
+ $(MAKE) -C gitk-git uninstall
+ $(MAKE) -C git-gui gitexecdir='$(gitexec_instdir_SQ)' uninstall
+endif
+ifndef NO_PERL
+ $(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' uninstall
+endif
+ $(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' uninstall
+ $(RM) $(ALL_PROGRAMS:%='$(DESTDIR_SQ)$(gitexec_instdir_SQ)'/%)
+ $(RM) $(BUILT_INS:%='$(DESTDIR_SQ)$(gitexec_instdir_SQ)'/%)
+ $(RM) $(OTHER_PROGRAMS:%='$(DESTDIR_SQ)$(gitexec_instdir_SQ)'/%)
+ -rmdir -p '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
+ $(RM) $(bindir_PROGRAMS:%='$(DESTDIR_SQ)$(bindir_SQ)'/%)
+ -rmdir -p '$(DESTDIR_SQ)$(bindir_SQ)'
### Maintainer's dist rules
@@ -1857,7 +1873,7 @@ ifndef NO_TCLTK
endif
$(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-GUI-VARS GIT-BUILD-OPTIONS
-.PHONY: all install clean strip
+.PHONY: all install uninstall clean strip
.PHONY: shell_compatibility_test please_set_SHELL_PATH_to_a_more_modern_shell
.PHONY: .FORCE-GIT-VERSION-FILE TAGS tags cscope .FORCE-GIT-CFLAGS
.PHONY: .FORCE-GIT-BUILD-OPTIONS
diff --git a/gitk-git/Makefile b/gitk-git/Makefile
index e1b6045..d68f19a 100644
--- a/gitk-git/Makefile
+++ b/gitk-git/Makefile
@@ -47,6 +47,8 @@ install:: all
uninstall::
$(foreach p,$(ALL_MSGFILES), $(RM) '$(DESTDIR_SQ)$(msgsdir_SQ)'/$(notdir $p) &&) true
$(RM) '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
+ -rmdir -p '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
+ -rmdir -p '$(DESTDIR_SQ)$(msgsdir_SQ)'
clean::
$(RM) gitk-wish po/*.msg
diff --git a/perl/Makefile b/perl/Makefile
index 4ab21d6..25fc304 100644
--- a/perl/Makefile
+++ b/perl/Makefile
@@ -10,7 +10,7 @@ ifndef V
QUIET = @
endif
-all install instlibdir: $(makfile)
+all install instlibdir uninstall: $(makfile)
$(QUIET)$(MAKE) -f $(makfile) $@
clean:
diff --git a/templates/Makefile b/templates/Makefile
index 408f013..f4048d9 100644
--- a/templates/Makefile
+++ b/templates/Makefile
@@ -51,3 +51,8 @@ install: all
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(template_instdir_SQ)'
(cd blt && $(TAR) cf - .) | \
(cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) xof -)
+
+uninstall:
+ -(cd blt && find . -type f) | (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && xargs $(RM))
+ -(cd blt && find . -mindepth 1 -type d) | (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && xargs rmdir)
+ -rmdir -p '$(DESTDIR_SQ)$(template_instdir_SQ)'
--
1.6.3.3
^ permalink raw reply related
* Re: [ANNOUNCE] codeBeamer MR - Easy ACL for Git
From: Petr Baudis @ 2009-11-18 12:09 UTC (permalink / raw)
To: Intland Software; +Cc: git
In-Reply-To: <4B03B153.1020302@intland.com>
On Wed, Nov 18, 2009 at 09:33:23AM +0100, Intland Software wrote:
> codeBeamer MR is a new tool for teams working with Git, and striving for
> fast repository management and easy access control management.
> Setting up and maintaining ACL on top of Git is not trivial. With this
> web based tool, you can *save a lot of boring and error-prone maintainenace
> work*, and spend your time rather with coding.
>
> FEATURES
> * Starts and close projects and repositories in just seconds
> * Project-, group-, and role-based administration across multiple repositories
> * ACL on directory level
> * SSH authentication
> * Lightweight wiki, issue tracking and project management facilities
> * Web based
> * Remote API
>
> PRICE?
> It is *free* (as in beer). No expiration.
>
> LEARN MORE & DOWNLOAD
> More details, screenshots and downloads:
> http://www.intland.com/products/cb-mr/overview.html
Interesting, thank you for the announcement; it would be good to note
that it's not open-source.
I think a lot of people wonder now, how does this compare to existing
solutions; from your announcement I thought it's something like
Gitosis/Gitolite, but in fact it seems more similar to Gitorious or
GitHub (if it was publicly available, of course); perhaps it would be
good idea to present comparison to these on the project homepage.
--
Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth
^ permalink raw reply
* Re: [PATCH] Give the hunk comment its own color
From: Bert Wesarg @ 2009-11-18 11:57 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Junio C Hamano, git
In-Reply-To: <be6fef0d0911180344ld31237et533cfa8832ea0c6c@mail.gmail.com>
On Wed, Nov 18, 2009 at 12:44, Tay Ray Chuan <rctay89@gmail.com> wrote:
> Hi,
>
> On Wed, Nov 18, 2009 at 7:30 PM, Bert Wesarg <bert.wesarg@googlemail.com> wrote:
>> Insired by the coloring of quilt.
>
> s/Insired/Inspired/?
Sure.
I also forgot to update the test suit.
New patch follows.
Bert
>
> --
> Cheers,
> Ray Chuan
>
^ permalink raw reply
* Re: th/remote-usage
From: Jonathan Nieder @ 2009-11-18 12:05 UTC (permalink / raw)
To: Tim Henigan; +Cc: Junio C Hamano, git
In-Reply-To: <20091118114808.GA13346@progeny.tock>
Hi,
Another thought.
Yesterday, Tim Henigan wrote:
> Do you object to the new #defines for the strings? I added them since we now
> really need to construct the usage string for 2 separate uses:
> (1) When 'git remote -h' is invoked, we need to return the usage
> string showing
> all subcommands.
> (2) When 'git remote <subcommand> -h' is invoked, we need to return the
> usage for just that command.
>
> It doesn't make sense to me to maintain separate strings for the two use cases.
Another option would be to make the strings into static variables.
I vaguely hoped this would help the code size a little, but gcc is
already smart enough to notice the strings are the same on its own.
Actually, this increases the text size by 15 bytes. Apparently,
static arrays have to live at 4-byte aligned addresses in the x86 ABI.
So there is not much to recommend this. I am sending it mostly for
academic interest. It also has the virtue of decreasing the density
of capital letters in the code.
builtin-remote.c | 47 ++++++++++++++++++++++++-----------------------
1 files changed, 24 insertions(+), 23 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index cfd8a36..185ce42 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -7,34 +7,35 @@
#include "run-command.h"
#include "refs.h"
-#define REMOTE_BARE_USAGE "git remote [options]"
-#define REMOTE_ADD_USAGE "git remote add [options] <name> <url>"
-#define REMOTE_RENAME_USAGE "git remote rename <old> <new>"
-#define REMOTE_RM_USAGE "git remote rm <name>"
-#define REMOTE_SETHEAD_USAGE "git remote set-head <name> (-a|-d|<branch>)"
-#define REMOTE_SHOW_USAGE "git remote show [options] <name>"
-#define REMOTE_PRUNE_USAGE "git remote prune [options] <name>"
-#define REMOTE_UPDATE_USAGE "git remote update [options]"
+static const char remote_bare_usage[] = "git remote [options]";
+static const char remote_add_usage[] = "git remote add [options] <name> <url>";
+static const char remote_rename_usage[] = "git remote rename <old> <new>";
+static const char remote_rm_usage[] = "git remote rm <name>";
+static const char remote_sethead_usage[] =
+"git remote set-head <name> (-a|-d|<branch>)";
+static const char remote_show_usage[] = "git remote show [options] <name>";
+static const char remote_prune_usage[] = "git remote prune [options] <name>";
+static const char remote_update_usage[] = "git remote update [options]";
static const char * const builtin_remote_usage[] = {
- REMOTE_BARE_USAGE,
- REMOTE_ADD_USAGE,
- REMOTE_RENAME_USAGE,
- REMOTE_RM_USAGE,
- REMOTE_SETHEAD_USAGE,
- REMOTE_SHOW_USAGE,
- REMOTE_PRUNE_USAGE,
- REMOTE_UPDATE_USAGE,
+ remote_bare_usage,
+ remote_add_usage,
+ remote_rename_usage,
+ remote_rm_usage,
+ remote_sethead_usage,
+ remote_show_usage,
+ remote_prune_usage,
+ remote_update_usage,
NULL
};
-static const char * const builtin_remote_add_usage[] = { REMOTE_ADD_USAGE, NULL };
-static const char * const builtin_remote_rename_usage[] = { REMOTE_RENAME_USAGE, NULL };
-static const char * const builtin_remote_rm_usage[] = { REMOTE_RM_USAGE, NULL };
-static const char * const builtin_remote_sethead_usage[] = { REMOTE_SETHEAD_USAGE, NULL };
-static const char * const builtin_remote_show_usage[] = { REMOTE_SHOW_USAGE, NULL };
-static const char * const builtin_remote_prune_usage[] = { REMOTE_PRUNE_USAGE, NULL };
-static const char * const builtin_remote_update_usage[] = { REMOTE_UPDATE_USAGE, NULL };
+static const char * const builtin_remote_add_usage[] = { remote_add_usage, NULL };
+static const char * const builtin_remote_rename_usage[] = { remote_rename_usage, NULL };
+static const char * const builtin_remote_rm_usage[] = { remote_rm_usage, NULL };
+static const char * const builtin_remote_sethead_usage[] = { remote_sethead_usage, NULL };
+static const char * const builtin_remote_show_usage[] = { remote_show_usage, NULL };
+static const char * const builtin_remote_prune_usage[] = { remote_prune_usage, NULL };
+static const char * const builtin_remote_update_usage[] = { remote_update_usage, NULL };
#define GET_REF_STATES (1<<0)
#define GET_HEAD_NAMES (1<<1)
--
1.6.5.2
^ permalink raw reply related
* Re: [PATCH] Give the hunk comment its own color
From: Tay Ray Chuan @ 2009-11-18 11:44 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Junio C Hamano, git
In-Reply-To: <1258543836-799-1-git-send-email-bert.wesarg@googlemail.com>
Hi,
On Wed, Nov 18, 2009 at 7:30 PM, Bert Wesarg <bert.wesarg@googlemail.com> wrote:
> Insired by the coloring of quilt.
s/Insired/Inspired/?
--
Cheers,
Ray Chuan
^ permalink raw reply
* th/remote-usage
From: Jonathan Nieder @ 2009-11-18 11:48 UTC (permalink / raw)
To: Tim Henigan; +Cc: Junio C Hamano, git
In-Reply-To: <7v7hto46ce.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> [New Topics]
>
> * th/remote-usage (2009-11-16) 1 commit.
> - git remote: Separate usage strings for subcommands
Glancing at pu^2, I had two small nitpicks: [<options>...] is five
characters longer than strictly necessary, and the argument to git
remote set-head is not actually optional.
In other words, would it make sense to squash in something like the
following?
-- %< --
Subject: Tweak 'git remote' usage strings
The set-head argument is not optional. <options>... is five
characters wider than it needs to be.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
builtin-remote.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index ee86810..cfd8a36 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -7,14 +7,14 @@
#include "run-command.h"
#include "refs.h"
-#define REMOTE_BARE_USAGE "git remote [<options>...]"
-#define REMOTE_ADD_USAGE "git remote add [<options>...] <name> <url>"
+#define REMOTE_BARE_USAGE "git remote [options]"
+#define REMOTE_ADD_USAGE "git remote add [options] <name> <url>"
#define REMOTE_RENAME_USAGE "git remote rename <old> <new>"
#define REMOTE_RM_USAGE "git remote rm <name>"
-#define REMOTE_SETHEAD_USAGE "git remote set-head <name> [<options>...]"
-#define REMOTE_SHOW_USAGE "git remote show [<options>...] <name>"
-#define REMOTE_PRUNE_USAGE "git remote prune [<options>...] <name>"
-#define REMOTE_UPDATE_USAGE "git remote update [<options>...]"
+#define REMOTE_SETHEAD_USAGE "git remote set-head <name> (-a|-d|<branch>)"
+#define REMOTE_SHOW_USAGE "git remote show [options] <name>"
+#define REMOTE_PRUNE_USAGE "git remote prune [options] <name>"
+#define REMOTE_UPDATE_USAGE "git remote update [options]"
static const char * const builtin_remote_usage[] = {
REMOTE_BARE_USAGE,
--
1.6.5.2
^ permalink raw reply related
* [PATCH] Give the hunk comment its own color
From: Bert Wesarg @ 2009-11-18 11:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Bert Wesarg
Insired by the coloring of quilt.
Introduce a separate color for the hunk comment part, i.e. the current function.
Whitespace between hunk header and hunk comment is now printed as plain.
The current default is magenta. But I'm not settled on this. My favorite would
be bold yellow.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
Documentation/config.txt | 8 +++---
combine-diff.c | 5 +++-
diff.c | 62 +++++++++++++++++++++++++++++++++++++++++++--
diff.h | 1 +
4 files changed, 68 insertions(+), 8 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index cb73d75..421cd50 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -598,10 +598,10 @@ color.diff.<slot>::
Use customized color for diff colorization. `<slot>` specifies
which part of the patch to use the specified color, and is one
of `plain` (context text), `meta` (metainformation), `frag`
- (hunk header), `old` (removed lines), `new` (added lines),
- `commit` (commit headers), or `whitespace` (highlighting
- whitespace errors). The values of these variables may be specified as
- in color.branch.<slot>.
+ (hunk header), 'func' (function in hunk header), `old` (removed lines),
+ `new` (added lines), `commit` (commit headers), or `whitespace`
+ (highlighting whitespace errors). The values of these variables may be
+ specified as in color.branch.<slot>.
color.grep::
When set to `always`, always highlight matches. When `false` (or
diff --git a/combine-diff.c b/combine-diff.c
index 5b63af1..6162691 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -524,6 +524,7 @@ static void dump_sline(struct sline *sline, unsigned long cnt, int num_parent,
int i;
unsigned long lno = 0;
const char *c_frag = diff_get_color(use_color, DIFF_FRAGINFO);
+ const char *c_func = diff_get_color(use_color, DIFF_FUNCINFO);
const char *c_new = diff_get_color(use_color, DIFF_FILE_NEW);
const char *c_old = diff_get_color(use_color, DIFF_FILE_OLD);
const char *c_plain = diff_get_color(use_color, DIFF_PLAIN);
@@ -588,7 +589,9 @@ static void dump_sline(struct sline *sline, unsigned long cnt, int num_parent,
comment_end = i;
}
if (comment_end)
- putchar(' ');
+ printf("%s%s %s%s", c_reset,
+ c_plain, c_reset,
+ c_func);
for (i = 0; i < comment_end; i++)
putchar(hunk_comment[i]);
}
diff --git a/diff.c b/diff.c
index 0d7f5ea..8a5ed1b 100644
--- a/diff.c
+++ b/diff.c
@@ -39,6 +39,7 @@ static char diff_colors[][COLOR_MAXLEN] = {
GIT_COLOR_GREEN, /* NEW */
GIT_COLOR_YELLOW, /* COMMIT */
GIT_COLOR_BG_RED, /* WHITESPACE */
+ GIT_COLOR_MAGENTA, /* FUNCINFO */
};
static void diff_filespec_load_driver(struct diff_filespec *one);
@@ -60,6 +61,8 @@ static int parse_diff_color_slot(const char *var, int ofs)
return DIFF_COMMIT;
if (!strcasecmp(var+ofs, "whitespace"))
return DIFF_WHITESPACE;
+ if (!strcasecmp(var+ofs, "func"))
+ return DIFF_FUNCINFO;
die("bad config variable '%s'", var);
}
@@ -344,6 +347,61 @@ static void emit_add_line(const char *reset,
}
}
+static void emit_hunk_line(struct emit_callback *ecbdata,
+ const char *line, int len)
+{
+ const char *plain = diff_get_color(ecbdata->color_diff, DIFF_PLAIN);
+ const char *frag = diff_get_color(ecbdata->color_diff, DIFF_FRAGINFO);
+ const char *func = diff_get_color(ecbdata->color_diff, DIFF_FUNCINFO);
+ const char *reset = diff_get_color(ecbdata->color_diff, DIFF_RESET);
+ const char *part_end = NULL;
+ int part_len = 0;
+
+ /* determine length of @ */
+ while (part_len < len && line[part_len] == '@')
+ part_len++;
+
+ /* find end of frag, (Ie. find second @@) */
+ part_end = memmem(line + part_len, len - part_len,
+ line, part_len);
+ if (!part_end)
+ return emit_line(ecbdata->file, frag, reset, line, len);
+ /* go to end of @@ */
+ part_end += part_len;
+ /* calculate total length of frag */
+ part_len = part_end - line;
+ /* emit frag */
+ emit_line(ecbdata->file, frag, reset, line, part_len);
+
+ /* consume hunk header */
+ len -= part_len;
+ line += part_len;
+
+ /* return early */
+ if (!len)
+ return;
+
+ /* determine length of sep space */
+ part_len = 0;
+ while (part_len < len && isspace(line[part_len]))
+ part_len++;
+
+ /* no whitespace sep => print reminder as FRAGINFO */
+ if (!part_len)
+ return emit_line(ecbdata->file, frag, reset, line, len);
+
+ /* print whitespace sep as PLAIN */
+ emit_line(ecbdata->file, plain, reset, part_end, part_len);
+
+ /* consume whitespace sep */
+ len -= part_len;
+ line += part_len;
+
+ /* print reminder as FUNCINFO */
+ if (len)
+ emit_line(ecbdata->file, func, reset, line, len);
+}
+
static struct diff_tempfile *claim_diff_tempfile(void) {
int i;
for (i = 0; i < ARRAY_SIZE(diff_temp); i++)
@@ -781,9 +839,7 @@ static void fn_out_consume(void *priv, char *line, unsigned long len)
diff_words_flush(ecbdata);
len = sane_truncate_line(ecbdata, line, len);
find_lno(line, ecbdata);
- emit_line(ecbdata->file,
- diff_get_color(ecbdata->color_diff, DIFF_FRAGINFO),
- reset, line, len);
+ emit_hunk_line(ecbdata, line, len);
if (line[len-1] != '\n')
putc('\n', ecbdata->file);
return;
diff --git a/diff.h b/diff.h
index 2740421..15fcecd 100644
--- a/diff.h
+++ b/diff.h
@@ -130,6 +130,7 @@ enum color_diff {
DIFF_FILE_NEW = 5,
DIFF_COMMIT = 6,
DIFF_WHITESPACE = 7,
+ DIFF_FUNCINFO = 8,
};
const char *diff_get_color(int diff_use_color, enum color_diff ix);
#define diff_get_color_opt(o, ix) \
--
tg: (785c58e..) bw/func-color (depends on: master)
^ permalink raw reply related
* Re: git-svn of both trunk and tags while having no access to the 'parent' of those
From: Michael J Gruber @ 2009-11-18 9:01 UTC (permalink / raw)
To: Yaroslav Halchenko; +Cc: git
In-Reply-To: <20091117025945.GE17964@onerussian.com>
Yaroslav Halchenko venit, vidit, dixit 17.11.2009 03:59:
> Dear Git People,
>
> I've ran into a situation here:
>
> there is a repository with trunk and releases (analog to tags there)
> available for public, but the rest of directories and their parent is
> not available without authentication... ie I can access
>
> http://domain.com/svnrepo/trunk
> http://domain.com/svnrepo/releases
> but not
> http://domain.com/svnrepo/
>
> Whenever I use git-svn (1.6.5 in Debian):
>
> git svn clone --prefix=upstream-svn/ -T trunk -t releases http://domain.com/svnrepo svnrepo.gitsvn
>
> it asks for authentication... I guess, now I can only clone trunk and
> releases separately? or may be there is some way to avoid the
> problem, ie avoid looking 'into root'?
>
> Thanks in advance!
Your problem description seems to match perfectly with the description
of the "--no-minimize-url" option in git svn's man page. I'm sure it's
worth a try.
Michael
^ 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