* Re: [PATCH] git svn clone -s was not prefixing 'branches/'
From: Eric Wong @ 2009-01-17 10:54 UTC (permalink / raw)
To: Jonathan Lim; +Cc: git
In-Reply-To: <1232050647-2870-1-git-send-email-snowblink@gmail.com>
Jonathan Lim <snowblink@gmail.com> wrote:
> All branches in the subversion repository would appear at the same
> level as trunk. The should now appear with a 'branches/' prefix.
>
> Signed-off-by: Jonathan Lim <snowblink@gmail.com>
This is too ugly for the common existing cases. For the rare case where
this could lead to a namespace conflict[1], it's possible to work around
it by editing .git/config.
I would accept a --tags-prefix= and --branches-prefix= patch to make
this possible w/o having to edit .git/config, but I don't want the
default prefixes changed.
Thanks,
[1] - "/branches/trunk" vs "/trunk", which I've yet to see evidence of...
> ---
> git-svn.perl | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index ad01e18..17d65cb 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -789,7 +789,7 @@ sub cmd_multi_init {
> }
> return unless defined $_branches || defined $_tags;
> my $ra = $url ? Git::SVN::Ra->new($url) : undef;
> - complete_url_ls_init($ra, $_branches, '--branches/-b', $_prefix);
> + complete_url_ls_init($ra, $_branches, '--branches/-b', $_prefix . 'branches/');
> complete_url_ls_init($ra, $_tags, '--tags/-t', $_prefix . 'tags/');
> }
^ permalink raw reply
* Re: Minimum required version of subversion for git-svn?
From: Eric Wong @ 2009-01-17 10:58 UTC (permalink / raw)
To: Tom G. Christensen; +Cc: git@vger.kernel.org
In-Reply-To: <496AF964.1070208@statsbiblioteket.dk>
"Tom G. Christensen" <tgc@statsbiblioteket.dk> wrote:
> Eric Wong wrote:
>> "Tom G. Christensen" <tgc@statsbiblioteket.dk> wrote:
>>> Hello,
>>>
>>> With git 1.6.0.5 I was able to run git-svn with subversion 1.1.4 on
>>> RHEL4/i386 but with 1.6.0.6 and 1.6.1 the testsuite now fails in the new
>>> test t9104.10:
>>
>> ...
>>
>>> With 1.6.1 I also see t9129.10-12 failing with subversion 1.1.4:
>>> * FAIL 10: ISO-8859-1 should match UTF-8 in svn
>>
>> ...
>>
>>> * failed 3 among 12 test(s)
>>> make[2]: Leaving directory `/builddir/build/BUILD/git-1.6.1/t'
>>> make[2]: *** [t9129-git-svn-i18n-commitencoding.sh] Error 1
>>>
>>> I see in git-svn.perl that only SVN::Core 1.1.0 is required. Is it still
>>> the intention that git-svn should work with subversion 1.1.x?
>>>
>>> If you're going to bump the minimum requirement I would ask that you
>>> atleast keep 1.3.x as supported. This is the last release of subversion
>>> where RHEL3 can satisfy the dependencies out of the box and I've
>>> verified that the testsuite will pass with 1.3.2.
>>
>> It's still my intention that SVN 1.1.x is supported; but I haven't had
>> the chance to test those versions in a while.
>>
>> Can you rerun the tests that failed with "sh -x t91..." ?
>>
> I've run the tests from 1.6.1 with -v, sh -x and sh -x + -v and dumped
> the results at http://jupiterrise.com/tmp
>
> You'll find results from one more test (t9106) which I didn't mention
> and which is also giving me problems but only with rhel4/x86_64 and svn
> 1.1.4. It should be noted that this test has never worked for me with
> this config.
Thanks, I'll try to setup an environment that lets me test older
SVN builds over the weekend.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] git svn clone -s was not prefixing 'branches/'
From: Jon Lim @ 2009-01-17 11:39 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20090117105427.GA15801@dcvr.yhbt.net>
Hi,
Maybe this patch doesn't fix the problem I was having. I will attempt
to describe it better here.
I understand that a standard subversion setup is as follows:
trunk
branches
tags
With the -s option, svn clone should expect this.
Using the example subversion repository:
trunk
branches/RB_1.0
branches/RB_2.0
tags/REL_1.0
tags/REL_2.0
Currently, using the -s option you get:
trunk
RB_1.0
RB_2.0
tags/REL_1.0
tags/REL_2.0
I think it makes sense to have:
trunk
branches/RB_1.0
branches/RB_2.0
tags/REL_1.0
tags/REL_2.0
Regards,
Jon
On Sat, Jan 17, 2009 at 10:54, Eric Wong <normalperson@yhbt.net> wrote:
> Jonathan Lim <snowblink@gmail.com> wrote:
>> All branches in the subversion repository would appear at the same
>> level as trunk. The should now appear with a 'branches/' prefix.
>>
>> Signed-off-by: Jonathan Lim <snowblink@gmail.com>
>
> This is too ugly for the common existing cases. For the rare case where
> this could lead to a namespace conflict[1], it's possible to work around
> it by editing .git/config.
>
> I would accept a --tags-prefix= and --branches-prefix= patch to make
> this possible w/o having to edit .git/config, but I don't want the
> default prefixes changed.
>
> Thanks,
>
> [1] - "/branches/trunk" vs "/trunk", which I've yet to see evidence of...
>
>> ---
>> git-svn.perl | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/git-svn.perl b/git-svn.perl
>> index ad01e18..17d65cb 100755
>> --- a/git-svn.perl
>> +++ b/git-svn.perl
>> @@ -789,7 +789,7 @@ sub cmd_multi_init {
>> }
>> return unless defined $_branches || defined $_tags;
>> my $ra = $url ? Git::SVN::Ra->new($url) : undef;
>> - complete_url_ls_init($ra, $_branches, '--branches/-b', $_prefix);
>> + complete_url_ls_init($ra, $_branches, '--branches/-b', $_prefix . 'branches/');
>> complete_url_ls_init($ra, $_tags, '--tags/-t', $_prefix . 'tags/');
>> }
>
--
http://snowblink.co.uk/
^ permalink raw reply
* Re: [PATCH] git svn clone -s was not prefixing 'branches/'
From: Björn Steinbrink @ 2009-01-17 12:07 UTC (permalink / raw)
To: Jon Lim; +Cc: Eric Wong, git
In-Reply-To: <751e526a0901170339m6471ac84tdb032a090d19d7c6@mail.gmail.com>
On 2009.01.17 11:39:28 +0000, Jon Lim wrote:
> Hi,
>
> Maybe this patch doesn't fix the problem I was having. I will attempt
> to describe it better here.
>
> I understand that a standard subversion setup is as follows:
> trunk
> branches
> tags
>
> With the -s option, svn clone should expect this.
>
> Using the example subversion repository:
> trunk
> branches/RB_1.0
> branches/RB_2.0
> tags/REL_1.0
> tags/REL_2.0
>
> Currently, using the -s option you get:
> trunk
> RB_1.0
> RB_2.0
> tags/REL_1.0
> tags/REL_2.0
>
> I think it makes sense to have:
> trunk
> branches/RB_1.0
> branches/RB_2.0
> tags/REL_1.0
> tags/REL_2.0
Why? "trunk" is just a branch like any other branch, too. It's basically
just a svn convention that it's not in branches/ but in its own
"toplevel" directory. Once imported into git, it's just an ordinary
remote tracking branch. It's already pretty well distiguishable from all
the other branches due to its name.
What _does_ make sense is to have a common prefix for all the stuff you
got from svn, using for example --prefix=svn/. That way you get:
svn/trunk
svn/RB_1.0
svn/RB_2.0
svn/tags/REL_1.0
svn/tags/REL_2.0
The important part is that those names aren't ambiguous if you have
local branch heads called, for example:
trunk
RB_1.0
RB_2.0
as the svn/ prefix is part of the shortname for the remote tracking
branches. So "trunk" is the branch head and "svn/trunk" is the remote
tracking branch.
Btw Eric, is there any reason why there's no prefix used by default?
Using the name for the svn-remote as the prefix would make a lot of
sense to me.
Björn
^ permalink raw reply
* Re: [PATCH 2/3] http-push: when sending objects, don't PUT before MOVE
From: Ray Chuan @ 2009-01-17 12:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901170706450.3586@pacific.mpi-cbg.de>
Hi,
On Sat, Jan 17, 2009 at 2:13 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Sat, 17 Jan 2009, Ray Chuan wrote:
>
>> since 753bc911f489748a837ecb5ea4b5216220b24845, the opaquelocktocken
>
> It would be nice to use the form <abbrev-sha1>(<oneline>) instead of a
> non-abbreviated SHA-1 that everybody who is interested has to look up,
> wasting time.
sorry, i was referring to 753bc91 (Remove the requirement
opaquelocktoken uri scheme).
>> URI isn't used, so it doesn't make sense to PUT then MOVE.
>>
>> currently, git PUTs to
>>
>> /repo.git/objects/1a/1a2b..._opaquelocktoken:1234-....
>
> First you say that the opaquelocktoken URI is not used, but here it looks
> like one?
>
>> on some platforms, ':' isn't allowed in filenames so this fails
>> (assuming the server doesn't recognize it as opaquelocktoken scheme).
>> in fact, i don't think this is the correct implementation of the
>> scheme; 'opaquelocktoken: ' should come in front of the path.
>
> It would be nice to make that a fact-backed commit message. IOW there has
> to be some documentation about the subject which you can quote, and which
> would give you a definitive answer to the question if it should be a
> prefix or not.
According to the opaquelocktoken URI scheme in RFC2518
OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension]
if i'm not wrong, then the URI should read
opaquelocktoken:1234-....:/repo.git/objects/1a/1a2b...
rather than (currently):
/repo.git/objects/1a/1a2b..._opaquelocktoken:1234-....
this means either the opaquelocktoken URI scheme wasn't meant to be
implemented, or it is an incorrect implementation.
my belief is of the former, since the URI scheme is meant to represent
the lock token currently held when communicating to the server; in
addition, the lock held doesn't apply to the PUT path; it is
'refs/heads/abranch' rather than 'objects/' that is locked, so it
doesn't make sense to pass the lock token to the server while
accessing 'objects/'.
- Show quoted text -
>> diff --git a/src/git-1.6.1/http-push.c b/src/git-1.6.1/http-push.c
>> index a646a49..838ff6f 100644
>> --- a/src/git-1.6.1/http-push.c
>> +++ b/src/git-1.6.1/http-push.c
>> @@ -31,7 +31,6 @@ enum XML_Status {
>> /* DAV methods */
>> #define DAV_LOCK "LOCK"
>> #define DAV_MKCOL "MKCOL"
>> -#define DAV_MOVE "MOVE"
>> #define DAV_PROPFIND "PROPFIND"
>> #define DAV_PUT "PUT"
>> #define DAV_UNLOCK "UNLOCK"
>> @@ -104,7 +103,6 @@ enum transfer_state {
>> NEED_PUSH,
>> RUN_MKCOL,
>> RUN_PUT,
>> - RUN_MOVE,
>> ABORTED,
>> COMPLETE,
>> };
>> @@ -528,11 +526,6 @@ static void start_put(struct transfer_request *request)
>> posn += 2;
>> *(posn++) = '/';
>> strcpy(posn, hex + 2);
>> - request->dest = xmalloc(strlen(request->url) + 14);
>> - sprintf(request->dest, "Destination: %s", request->url);
>> - posn += 38;
>> - *(posn++) = '_';
>> - strcpy(posn, request->lock->token);
>>
>> slot = get_active_slot();
>> slot->callback_func = process_response;
>
> Color me puzzled again. Why is this code no longer needed? Is this the
> lock you were talking about?
the first two hunks remove MOVE-specific flags and status codes, while
the last hunk removes code that generates the "Destination: <url>"
header needed for a MOVE, which isn't needed by any other DAV
requests.
it isn't related to locks, although the "source" url would contain the
word lock in the current implementation.
for example, currently, a PUT path appended with a opaquelocktoken is
followed by a MOVE request:
PUT /git/test_repo.git/objects/50/b820aea6d3503362343cdc0e699b760c700b2b_opaquelocktoken:6960ad7a-84b0-9b4e-85cc-b9f15652c658
MOVE /git/test_repo.git/objects/50/b820aea6d3503362343cdc0e699b760c700b2b
(actually, it is the request header 'Destination: ' that contains the
destination path, not the request url; i replaced it for demonstrative
purposes.)
>> @@ -705,23 +672,13 @@ static void finish_request(struct
>> transfer_request *request)
>> }
>> } else if (request->state == RUN_PUT) {
>> if (request->curl_result == CURLE_OK) {
>> - start_move(request);
>> - } else {
>> - fprintf(stderr, "PUT %s failed, aborting (%d/%ld)\n",
>> - sha1_to_hex(request->obj->sha1),
>> - request->curl_result, request->http_code);
>> - request->state = ABORTED;
>> - aborted = 1;
>> - }
>
> ... and here comes my first doubt that it would be a good idea to avoid
> "put && move"; what if "put" fails? Then you end up with a corrupt
> repository.
if we take the "put && move" procedure as a guard against failure (as
opposed to "put"), then how does one explain the fact that this
procedure isn't applied when updating a branch file (eg.
refs/heads/mybranch)?
in any case, "put && move" isn't an effective guard after failure
during put. the PUT sends an object/revision to the repository,
however, the repository doesn't yet know that such an object/revision
exists, cos the ref file for the branch to be updated in the remote
repository (eg. refs/heads/mybranch) has yet to be updated; it is
updated only if the PUT was successful.
thus the repository won't be corrupt if a PUT request fails.
> Ciao,
> Dscho
>
>
--
Cheers,
Ray Chuan
^ permalink raw reply
* [RFC] Making format-patch output better when blank line is missing?
From: Adeodato Simó @ 2009-01-17 12:35 UTC (permalink / raw)
To: git
Hello,
I'm using git-format-patch to send commit diff emails, and it was
recently brought to my atention that if a commit message consists
entirely in a paragraph with no blank lines (particluarly, no blank line
after the first line, which is not a summary but just the first line of
the paragraph), git-format-patch will place all the commit message in
the Subject, which is inconvenient to read.
Do you think it would be good to have format-patch do something like
this in this case?:
Subject: [PATCH] This commit introduces a new function bla() that [...]
[...] makes it possible to apply the frobniz operation to objects
that don't bla bla bla bla.
(I realize that, with this, the applying logic would have to learn about
it. Hm.)
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
- I love you, Shirley, I'm not ashamed to say.
- If you love me, then you'll want me to be happy. Even if I'm not with you.
- I don't love you that much.
-- Denny Crane and Shirley Schmidt
^ permalink raw reply
* Re: [PATCH 3/3] Adds a #!bash to the top of bash completions so that editors can recognize, it as a bash script. Also adds a few simple comments above commands that, take arguments. The comments are meant to remind editors of potential, problems that
From: Markus Heidelberg @ 2009-01-17 12:37 UTC (permalink / raw)
To: Jeff King
Cc: Baz, Adeodato Simó, Boyd Stephen Smith Jr., Shawn O. Pearce,
Ted Pavlic, git, Junio C Hamano
In-Reply-To: <20090117014057.GA15331@coredump.intra.peff.net>
Jeff King, 17.01.2009:
> On Fri, Jan 16, 2009 at 03:06:34PM +0000, Baz wrote:
>
> > > At the beginning I tried to fulfil this limit, but often it's not easy.
> > > So should it be adjusted to a slightly higher value in the documentation
> > > or even split into a recommended limit (e.g. 50) and a recommended
> > > absolute maximum (e.g. 76)? Hmm, the split wouldn't make sense, I think.
> >
> > The 50 character limit is for the first line, try "git log
> > --pretty=oneline" and it should be obvious why.
>
> I'm not sure it makes sense to make a workflow recommendation that the
> git project itself does not follow.
I think, it doesn't.
> In practice, is this a problem for people using git.git?
>
> Personally, I find --pretty=oneline unreadable because so much of the
> screen real estate is wasted on random characters that I don't care
> about. I find --pretty=tformat:'%h %s' much nicer
But it doesn't automatically color the SHA1.
> (yes, --abbrev-commit
> works, too, but I find the '...' a pointless waste of space).
And they are annoying for selecting with the mouse doubleclick, at least
Konsole selects the SHA1 including the '...'. Xterm doesn't and I
haven't looked if Konsole can be configured to do so, but without the
'...' it would probably work regardless of the terminal emulator and
its setting.
Markus
^ permalink raw reply
* Re: [PATCH] git-checkout(1) mention fate of extraneous files
From: Markus Heidelberg @ 2009-01-17 12:57 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87k58u4vlq.fsf@jidanni.org>
jidanni@jidanni.org, 17.01.2009:
> Signed-off-by: jidanni <jidanni@jidanni.org>
> ---
> Documentation/git-checkout.txt | 13 +++++++------
> 1 files changed, 7 insertions(+), 6 deletions(-)
> -When <paths> are not given, this command switches branches by
> -updating the index and working tree to reflect the specified
> -branch, <branch>, and updating HEAD to be <branch> or, if
> -specified, <new_branch>. Using -b will cause <new_branch> to
> -be created; in this case you can use the --track or --no-track
> -options, which will be passed to `git branch`.
> +When <paths> are not given, this command switches branches by updating
> +the index and working tree to reflect the specified branch, <branch>,
> +and updating HEAD to be <branch> or, if specified, <new_branch>. (No
> +extraneous files present are deleted, use linkgit:git-clean[1] for a
> +pristine checkout.) Using -b will cause <new_branch> to be created; in
> +this case you can use the --track or --no-track options, which will be
> +passed to `git branch`.
Why do you reformat the whole paragraph? Just inserting your sentence
would give a much nicer diff for easier review, it's no difference for
asciidoc. Indeed to find the change, I just copied the old and new text
into two Vim windows, reformatted and diffed them.
Then you would get this
Documentation/git-checkout.txt | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
Markus
^ permalink raw reply
* Re: [PATCH/RFC v3 0/6] N-th last checked out branch
From: Thomas Rast @ 2009-01-17 13:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano, Johannes Sixt, Johan Herland
In-Reply-To: <alpine.DEB.1.00.0901170646560.3586@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]
Johannes Schindelin wrote:
> On Sat, 17 Jan 2009, Thomas Rast wrote:
> > 9 files changed, 387 insertions(+), 122 deletions(-)
>
> Let's quickly compare that to what Junio sent:
>
> builtin-checkout.c | 10 +++++-
> cache.h | 1 +
> sha1_name.c | 78 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 87 insertions(+), 2 deletions(-)
[...]
> - the '-' handling you seem to want.
Let's be clear that the handling *I* wanted is this big:
builtin-checkout.c | 27 ++++++++++++++++-
In any case, I'll follow up with a version that still traverses the
logs twice and thus doesn't need the first two.
> I really have to ask: why did you not work on top of Junio's patch, just
> adding docs, tests, and checkout -? And then -- maybe -- the
> string_list...
>
> Although I have to admit that I am not _that_ convinced the string_list is
> worth it: reflogs are not evaluated all the time, so it is definitely not
> performance critical.
I take it you have some idea where and how string_list fits into this
topic?
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH/RFC v3bis 1/2] sha1_name: implement @{-N} syntax for N-th last checked out
From: Thomas Rast @ 2009-01-17 13:40 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Schindelin, Johannes Sixt, Johan Herland
In-Reply-To: <200901171438.22504.trast@student.ethz.ch>
Implements a new syntax @{-N} that parses the reflog for the N-th last
interesting 'checkout: moving from $branch to $new' entry and
substitutes $branch. Here, "interesting" is defined as $branch !=
$new. We then substitute the real branch name for the parse.
For example:
git checkout foo
git checkout bar
git checkout master
git checkout master # did not move, so doesn't count
git rev-parse @{-1} # same as bar
git rev-parse @{-2} # same as foo
git rev-parse @{-2}~3 # same as foo~3
Thanks to Junio for much of the code.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/git-rev-parse.txt | 3 +
cache.h | 1 +
sha1_name.c | 99 +++++++++++++++++++++++++++++++++++++-
t/t1505-rev-parse-last.sh | 71 ++++++++++++++++++++++++++++
4 files changed, 171 insertions(+), 3 deletions(-)
create mode 100755 t/t1505-rev-parse-last.sh
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 2921da3..3ccef2f 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -212,6 +212,9 @@ when you run 'git-merge'.
reflog of the current branch. For example, if you are on the
branch 'blabla', then '@\{1\}' means the same as 'blabla@\{1\}'.
+* The special construct '@\{-<n>\}' means the <n>th branch checked out
+ before the current one.
+
* A suffix '{caret}' to a revision parameter means the first parent of
that commit object. '{caret}<n>' means the <n>th parent (i.e.
'rev{caret}'
diff --git a/cache.h b/cache.h
index 8e1af26..0dd9168 100644
--- a/cache.h
+++ b/cache.h
@@ -663,6 +663,7 @@ static inline unsigned int hexval(unsigned char c)
extern const char *resolve_ref(const char *path, unsigned char *sha1, int, int *);
extern int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref);
extern int dwim_log(const char *str, int len, unsigned char *sha1, char **ref);
+extern int interpret_nth_last_branch(const char *str, struct strbuf *);
extern int refname_match(const char *abbrev_name, const char *full_name, const char **rules);
extern const char *ref_rev_parse_rules[];
diff --git a/sha1_name.c b/sha1_name.c
index 159c2ab..9e1538e 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -297,6 +297,8 @@ int dwim_log(const char *str, int len, unsigned char *sha1, char **log)
return logs_found;
}
+static int get_sha1_1(const char *name, int len, unsigned char *sha1);
+
static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
{
static const char *warning = "warning: refname '%.*s' is ambiguous.\n";
@@ -307,7 +309,7 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
if (len == 40 && !get_sha1_hex(str, sha1))
return 0;
- /* basic@{time or number} format to query ref-log */
+ /* basic@{time or number or -number} format to query ref-log */
reflog_len = at = 0;
if (str[len-1] == '}') {
for (at = 0; at < len - 1; at++) {
@@ -324,6 +326,16 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
return -1;
if (!len && reflog_len) {
+ struct strbuf buf = STRBUF_INIT;
+ int ret;
+ /* try the @{-N} syntax for n-th checkout */
+ ret = interpret_nth_last_branch(str+at, &buf);
+ if (ret > 0) {
+ /* substitute this branch name and restart */
+ return get_sha1_1(buf.buf, buf.len, sha1);
+ } else if (ret == 0) {
+ return -1;
+ }
/* allow "@{...}" to mean the current branch reflog */
refs_found = dwim_ref("HEAD", 4, sha1, &real_ref);
} else if (reflog_len)
@@ -379,8 +391,6 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
return 0;
}
-static int get_sha1_1(const char *name, int len, unsigned char *sha1);
-
static int get_parent(const char *name, int len,
unsigned char *result, int idx)
{
@@ -674,6 +684,89 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
return retval;
}
+struct grab_nth_branch_switch_cbdata {
+ int counting;
+ int nth;
+ struct strbuf *buf;
+};
+
+static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
+ const char *email, unsigned long timestamp, int tz,
+ const char *message, void *cb_data)
+{
+ struct grab_nth_branch_switch_cbdata *cb = cb_data;
+ const char *match = NULL, *target = NULL;
+ size_t len;
+
+ if (!prefixcmp(message, "checkout: moving from ")) {
+ match = message + strlen("checkout: moving from ");
+ if ((target = strstr(match, " to ")) != NULL)
+ target += 4;
+ }
+
+ if (!match)
+ return 0;
+
+ len = target - match - 4;
+ if (target[len] == '\n' && !strncmp(match, target, len))
+ return 0;
+
+ if (cb->counting) {
+ cb->nth++;
+ return 0;
+ }
+
+ if (cb->nth-- <= 0) {
+ strbuf_reset(cb->buf);
+ strbuf_add(cb->buf, match, len);
+ return 1;
+ }
+ return 0;
+}
+
+/*
+ * This reads "@{-N}" syntax, finds the name of the Nth previous
+ * branch we were on, and places the name of the branch in the given
+ * buf and returns the number of characters parsed if successful.
+ *
+ * If the input is not of the accepted format, it returns a negative
+ * number to signal an error.
+ *
+ * If the input was ok but there are not N branch switches in the
+ * reflog, it returns 0.
+ */
+int interpret_nth_last_branch(const char *name, struct strbuf *buf)
+{
+ int nth;
+ struct grab_nth_branch_switch_cbdata cb;
+ const char *brace;
+ char *num_end;
+
+ if (name[0] != '@' || name[1] != '{' || name[2] != '-')
+ return -1;
+ brace = strchr(name, '}');
+ if (!brace)
+ return -1;
+ nth = strtol(name+3, &num_end, 10);
+ if (num_end != brace)
+ return -1;
+
+ cb.counting = 1;
+ cb.nth = 0;
+ cb.buf = buf;
+ for_each_reflog_ent("HEAD", grab_nth_branch_switch, &cb);
+
+ if (cb.nth < nth)
+ return 0;
+
+ cb.counting = 0;
+ cb.nth -= nth;
+ cb.buf = buf;
+ for_each_reflog_ent("HEAD", grab_nth_branch_switch, &cb);
+
+ return brace-name+1;
+}
+
/*
* This is like "get_sha1_basic()", except it allows "sha1 expressions",
* notably "xyz^" for "parent of xyz"
diff --git a/t/t1505-rev-parse-last.sh b/t/t1505-rev-parse-last.sh
new file mode 100755
index 0000000..1e49dd2
--- /dev/null
+++ b/t/t1505-rev-parse-last.sh
@@ -0,0 +1,71 @@
+#!/bin/sh
+
+test_description='test @{-N} syntax'
+
+. ./test-lib.sh
+
+
+make_commit () {
+ echo "$1" > "$1" &&
+ git add "$1" &&
+ git commit -m "$1"
+}
+
+
+test_expect_success 'setup' '
+
+ make_commit 1 &&
+ git branch side &&
+ make_commit 2 &&
+ make_commit 3 &&
+ git checkout side &&
+ make_commit 4 &&
+ git merge master &&
+ git checkout master
+
+'
+
+# 1 -- 2 -- 3 master
+# \ \
+# \ \
+# --- 4 --- 5 side
+#
+# and 'side' should be the last branch
+
+git log --graph --all --pretty=oneline --decorate
+
+test_rev_equivalent () {
+
+ git rev-parse "$1" > expect &&
+ git rev-parse "$2" > output &&
+ test_cmp expect output
+
+}
+
+test_expect_success '@{-1} works' '
+ test_rev_equivalent side @{-1}
+'
+
+test_expect_success '@{-1}~2 works' '
+ test_rev_equivalent side~2 @{-1}~2
+'
+
+test_expect_success '@{-1}^2 works' '
+ test_rev_equivalent side^2 @{-1}^2
+'
+
+test_expect_failure '@{-1}@{1} works' '
+ test_rev_equivalent side@{1} @{-1}@{1}
+'
+
+test_expect_success '@{-2} works' '
+ test_rev_equivalent master @{-2}
+'
+
+test_expect_success '@{-3} fails' '
+ test_must_fail git rev-parse @{-3}
+'
+
+test_done
+
+
--
1.6.1.315.g92577
^ permalink raw reply related
* [PATCH/RFC v3bis 2/2] checkout: implement '@{-N}' and '-' special abbreviations
From: Thomas Rast @ 2009-01-17 13:40 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Schindelin, Johannes Sixt, Johan Herland
In-Reply-To: <1232199621-31072-1-git-send-email-trast@student.ethz.ch>
Checks if the branch to be checked out is either '@{-N}' or the
special shorthand '-' for '@{-1}' (i.e. the last checked out branch).
If so, we take it to mean the branch name, not the corresponding SHA,
so that we check out an attached HEAD on that branch.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/git-checkout.txt | 4 +++
builtin-checkout.c | 15 ++++++++++-
t/t2012-checkout-last.sh | 50 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 67 insertions(+), 2 deletions(-)
create mode 100755 t/t2012-checkout-last.sh
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 9cd5151..3bccffa 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -133,6 +133,10 @@ the conflicted merge in the specified paths.
+
When this parameter names a non-branch (but still a valid commit object),
your HEAD becomes 'detached'.
++
+As a special case, the "`@\{-N\}`" syntax for the N-th last branch
+checks out the branch (instead of detaching). You may also specify
+"`-`" which is synonymous with "`@\{-1\}`".
Detached HEAD
diff --git a/builtin-checkout.c b/builtin-checkout.c
index b5dd9c0..b0a101b 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -361,8 +361,16 @@ struct branch_info {
static void setup_branch_path(struct branch_info *branch)
{
struct strbuf buf = STRBUF_INIT;
- strbuf_addstr(&buf, "refs/heads/");
- strbuf_addstr(&buf, branch->name);
+ int ret;
+
+ if ((ret = interpret_nth_last_branch(branch->name, &buf))
+ && ret == strlen(branch->name)) {
+ branch->name = xstrdup(buf.buf);
+ strbuf_splice(&buf, 0, 0, "refs/heads/", 11);
+ } else {
+ strbuf_addstr(&buf, "refs/heads/");
+ strbuf_addstr(&buf, branch->name);
+ }
branch->path = strbuf_detach(&buf, NULL);
}
@@ -671,6 +679,9 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
arg = argv[0];
has_dash_dash = (argc > 1) && !strcmp(argv[1], "--");
+ if (!strcmp(arg, "-"))
+ arg = "@{-1}";
+
if (get_sha1(arg, rev)) {
if (has_dash_dash) /* case (1) */
die("invalid reference: %s", arg);
diff --git a/t/t2012-checkout-last.sh b/t/t2012-checkout-last.sh
new file mode 100755
index 0000000..320f6eb
--- /dev/null
+++ b/t/t2012-checkout-last.sh
@@ -0,0 +1,50 @@
+#!/bin/sh
+
+test_description='checkout can switch to last branch'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ echo hello >world &&
+ git add world &&
+ git commit -m initial &&
+ git branch other &&
+ echo "hello again" >>world &&
+ git add world &&
+ git commit -m second
+'
+
+test_expect_success '"checkout -" does not work initially' '
+ test_must_fail git checkout -
+'
+
+test_expect_success 'first branch switch' '
+ git checkout other
+'
+
+test_expect_success '"checkout -" switches back' '
+ git checkout - &&
+ test "z$(git symbolic-ref HEAD)" = "zrefs/heads/master"
+'
+
+test_expect_success '"checkout -" switches forth' '
+ git checkout - &&
+ test "z$(git symbolic-ref HEAD)" = "zrefs/heads/other"
+'
+
+test_expect_success 'detach HEAD' '
+ git checkout $(git rev-parse HEAD)
+'
+
+test_expect_success '"checkout -" attaches again' '
+ git checkout - &&
+ test "z$(git symbolic-ref HEAD)" = "zrefs/heads/other"
+'
+
+test_expect_success '"checkout -" detaches again' '
+ git checkout - &&
+ test "z$(git rev-parse HEAD)" = "z$(git rev-parse other)" &&
+ test_must_fail git symbolic-ref HEAD
+'
+
+test_done
--
1.6.1.315.g92577
^ permalink raw reply related
* Re: git-difftool
From: Ping Yin @ 2009-01-17 14:17 UTC (permalink / raw)
To: enso; +Cc: git
In-Reply-To: <1232164040173-2171934.post@n2.nabble.com>
On Sat, Jan 17, 2009 at 11:47 AM, enso <a.calhoon@gmail.com> wrote:
>
>
>
> Ping Yin wrote:
>>
>> Thanks. With GIT_PAGER="" it works now.
>>
>
> Personally, I didn't like having to screw around with environment variables
> directly to get vimdiff to work. So I did the following:
>
> 1) Made a simple diff script gitvimdiff.sh:
>
> #!/bin/env sh
> vimdiff "$2" "$5"
>
> 2) git config --global diff.external ~/path/to/gitvimdiff.sh
> 3) git config --global pager.diff ""
>
I am not aware of these configurations, thanks.
What i current do is to use an alias to use vimdiff for diff
^ permalink raw reply
* Possible git bug
From: Damon LaCrosse @ 2009-01-17 13:52 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 66 bytes --]
HiQ,
any chances the attached patch reveals a git bug?
Cheers,
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: git-bug.patch --]
[-- Type: text/x-patch, Size: 596 bytes --]
diff -Nru old/git-bug.sh new/git-bug.sh
--- old/git-bug.sh 1970-01-01 01:00:00.000000000 +0100
+++ new/git-bug.sh 2008-09-16 09:52:18.000000000 +0200
@@ -0,0 +1,24 @@
+#!/bin/bash
+
+mkdir bug
+cd bug
+git init-db
+
+echo one > file1
+git add file1
+echo "Bug Test Example" | git commit --all -F -
+
+git checkout -b branch
+echo two >> file1
+echo "Branch modification" | git commit --all -F -
+
+git checkout master
+git mv file1 file2
+
+echo "Master rename" | git commit --all -F -
+
+echo three >> file2
+
+echo "Master modification" | git commit --all -F -
+
+git merge -s recursive branch
^ permalink raw reply
* [PATCH] interpret_nth_last_branch(): avoid traversing the reflogs twice
From: Johannes Schindelin @ 2009-01-17 15:04 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano, Johannes Sixt, Johan Herland
In-Reply-To: <200901171438.22504.trast@student.ethz.ch>
Instead of traversing them twice, we just build a list of branch switches,
pick the one we're interested in, and free the list again.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Sat, 17 Jan 2009, Thomas Rast wrote:
> Johannes Schindelin wrote:
>
> > I really have to ask: why did you not work on top of Junio's
> > patch, just adding docs, tests, and checkout -? And then -- maybe --
> > the string_list...
Of course, I meant the patch as-is, with Junio as author. But
hey, if he does not care...
> > Although I have to admit that I am not _that_ convinced the
> > string_list is worth it: reflogs are not evaluated all the time, so
> > it is definitely not performance critical.
>
> I take it you have some idea where and how string_list fits into
> this topic?
Indeed.
This patch was generated using --collapse-non-alnums for readability.
Did not really help much.
sha1_name.c | 72 ++++++++++++++++++++++++----------------------------------
1 files changed, 30 insertions(+), 42 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 2bbc5f1..306d04b 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -6,6 +6,7 @@
#include "tree-walk.h"
#include "refs.h"
#include "cache-tree.h"
+#include "string-list.h"
static int find_short_object_filename(int len, const char *name, unsigned char *sha1)
{
@@ -691,43 +692,31 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
return retval;
}
-struct grab_nth_branch_switch_cbdata {
- int counting;
- int nth;
- struct strbuf *buf;
-};
-
-static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
+static int add_one_branch_switch(unsigned char *osha1, unsigned char *nsha1,
const char *email, unsigned long timestamp, int tz,
const char *message, void *cb_data)
{
- struct grab_nth_branch_switch_cbdata *cb = cb_data;
+ struct string_list *list = cb_data;
const char *match = NULL, *target = NULL;
size_t len;
-
- if (!prefixcmp(message, "checkout: moving from ")) {
- match = message + strlen("checkout: moving from ");
- if ((target = strstr(match, " to ")) != NULL)
- target += 4;
- }
-
- if (!match)
+
+ if (prefixcmp(message, "checkout: moving from "))
return 0;
- len = target - match - 4;
- if (target[len] == '\n' && !strncmp(match, target, len))
- return 0;
-
- if (cb->counting) {
- cb->nth++;
- return 0;
- }
-
- if (cb->nth-- <= 0) {
- strbuf_reset(cb->buf);
- strbuf_add(cb->buf, match, len);
- return 1;
- }
+ match = message + strlen("checkout: moving from ");
+
+ /* Is it "moving" from a branch to itself? Then ignore it. */
+ if ((target = strstr(match, " to ")) != NULL) {
+ target += 4;
+ len = target - match - 4;
+ if (target[len] == '\n' && !strncmp(match, target, len))
+ return 0;
+ }
+ else
+ len = strchrnul(match, ' ') - match;
+
+ string_list_append(xstrndup(match, len), list);
+
return 0;
}
@@ -745,7 +734,7 @@ static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
int interpret_nth_last_branch(const char *name, struct strbuf *buf)
{
int nth;
- struct grab_nth_branch_switch_cbdata cb;
+ struct string_list branch_list = { NULL, 0, 0, 0 };
const char *brace;
char *num_end;
@@ -758,18 +747,17 @@ int interpret_nth_last_branch(const char *name, struct strbuf *buf)
if (num_end != brace)
return -1;
- cb.counting = 1;
- cb.nth = 0;
- cb.buf = buf;
- for_each_reflog_ent("HEAD", grab_nth_branch_switch, &cb);
-
- if (cb.nth < nth)
+ for_each_reflog_ent("HEAD", add_one_branch_switch, &branch_list);
+
+ if (branch_list.nr < nth)
return 0;
-
- cb.counting = 0;
- cb.nth -= nth;
- cb.buf = buf;
- for_each_reflog_ent("HEAD", grab_nth_branch_switch, &cb);
+
+ strbuf_reset(buf);
+ strbuf_addstr(buf, branch_list.items[branch_list.nr - nth].string);
+
+ /* force free()ing the items */
+ branch_list.strdup_strings = 1;
+ string_list_clear(&branch_list, 0);
return brace-name+1;
}
--
1.6.1.325.g062d4
^ permalink raw reply related
* [PATCH] http-push: when making directories, have a trailing slash in the path name
From: Johannes Schindelin @ 2009-01-17 15:11 UTC (permalink / raw)
To: Ray Chuan; +Cc: git
In-Reply-To: <be6fef0d0901170028t3b418220wa024880235776037@mail.gmail.com>
The function lock_remote() sends MKCOL requests to make leading
directories; However, if it does not put a forward slash '/' at the end of
the path, the server sends a 301 redirect.
By leaving the '/' in place, we can avoid this additional step.
Incidentally, at least one version of Curl (7.16.3) does not resend
credentials when it follows a 301 redirect, so this commit also fixes
a bug.
Original patch by Tay Ray Chuan <rctay89@gmail.com>.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Sat, 17 Jan 2009, Ray Chuan wrote:
> http-push.c | 20 +++++++++++++++-----
> 1 files changed, 15 insertions(+), 5 deletions(-)
Actually, I had more something like this in mind. Please note
that I am not the best patch writer of the world, and I know it.
However, a few things I do try to follow:
- our commit messages are not really uniform, but they do share a
certain likeliness, e.g. all sentences start with a capital, we
try to use a less personal form than "I", and we avoid
abbreviations like "don't" and write "do not" instead.
- if you can come up with a patch that is shorter, but still clear
in what it does (the commit message might need to help there),
it is preferred: the less lines changed, the less lines for bugs
to hide in.
- this patch includes a test case.
The latter part cannot be stressed enough: my first idea was to
test for 301, but I realized then and there that _my_ Apache does not
care, but always returns a 201.
However, I remember that I had an Apache something like 2 years
ago which cared, and therefore I think this patch should go in.
http-push.c | 5 +++--
t/lib-httpd/apache.conf | 2 ++
t/t5540-http-push.sh | 6 ++++++
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/http-push.c b/http-push.c
index bbe7a8e..9fcccee 100644
--- a/http-push.c
+++ b/http-push.c
@@ -1201,7 +1201,8 @@ static struct remote_lock *lock_remote(const char *path, long timeout)
/* Make sure leading directories exist for the remote ref */
ep = strchr(url + strlen(remote->url) + 1, '/');
while (ep) {
- *ep = 0;
+ char saved_character = ep[1];
+ ep[1] = '\0';
slot = get_active_slot();
slot->results = &results;
curl_easy_setopt(slot->curl, CURLOPT_HTTPGET, 1);
@@ -1223,7 +1224,7 @@ static struct remote_lock *lock_remote(const char *path, long timeout)
free(url);
return NULL;
}
- *ep = '/';
+ ep[1] = saved_character;
ep = strchr(ep + 1, '/');
}
diff --git a/t/lib-httpd/apache.conf b/t/lib-httpd/apache.conf
index 4717c2d..fdb19a5 100644
--- a/t/lib-httpd/apache.conf
+++ b/t/lib-httpd/apache.conf
@@ -1,6 +1,8 @@
ServerName dummy
PidFile httpd.pid
DocumentRoot www
+LogFormat "%h %l %u %t \"%r\" %>s %b" common
+CustomLog access.log common
ErrorLog error.log
<IfDefine SSL>
diff --git a/t/t5540-http-push.sh b/t/t5540-http-push.sh
index da95886..22cfbb6 100755
--- a/t/t5540-http-push.sh
+++ b/t/t5540-http-push.sh
@@ -76,6 +76,12 @@ test_expect_failure 'create and delete remote branch' '
test_must_fail git show-ref --verify refs/remotes/origin/dev
'
+test_expect_success 'MKCOL sends directory names with trailing slashes' '
+
+ ! grep "\"MKCOL.*[^/] HTTP/[^ ]*\"" < "$HTTPD_ROOT_PATH"/access.log
+
+'
+
stop_httpd
test_done
--
1.6.1.325.g062d4
^ permalink raw reply related
* Re: Possible git bug
From: Johannes Schindelin @ 2009-01-17 15:16 UTC (permalink / raw)
To: Damon LaCrosse; +Cc: git
In-Reply-To: <87zlhqca4m.fsf@inbox.ru>
Hi,
On Sat, 17 Jan 2009, Damon LaCrosse wrote:
> any chances the attached patch reveals a git bug?
You mean that it produces a merge conflict when a file was modified in one
branch, and deleted in the other?
Because that's what you did, basically. You did not rename file1 to
file2. You completely changed the contents. I mean, completely.
Ciao,
Dscho
^ permalink raw reply
* Re: 'mail' link on http://repo.or.cz/w/git.git no workee?
From: Johannes Schindelin @ 2009-01-17 15:19 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901161235380.3586@pacific.mpi-cbg.de>
Hi,
On Fri, 16 Jan 2009, Johannes Schindelin wrote:
> The site seems to be down ATM, but it should be
>
> http://search.gmane.org/search.php?group=gmane.comp.version-control.git&query=pasky
FWIW, it is up again.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] Adds a #!bash to the top of bash completions so that editors can recognize, it as a bash script. Also adds a few simple comments above commands that, take arguments. The comments are meant to remind editors of potential, problems that
From: Jeff King @ 2009-01-17 15:21 UTC (permalink / raw)
To: Markus Heidelberg
Cc: Baz, Adeodato Simó, Boyd Stephen Smith Jr., Shawn O. Pearce,
Ted Pavlic, git, Junio C Hamano
In-Reply-To: <200901171337.49938.markus.heidelberg@web.de>
On Sat, Jan 17, 2009 at 01:37:48PM +0100, Markus Heidelberg wrote:
> > Personally, I find --pretty=oneline unreadable because so much of the
> > screen real estate is wasted on random characters that I don't care
> > about. I find --pretty=tformat:'%h %s' much nicer
>
> But it doesn't automatically color the SHA1.
True. I was going to suggest %Cyellow, but for some reason only red,
green, and blue are implemented. How silly. Patch series to follow.
-Peff
^ permalink raw reply
* [PATCH 1/2] color: make it easier for non-config to parse color specs
From: Jeff King @ 2009-01-17 15:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Markus Heidelberg, git
In-Reply-To: <20090117152108.GA24899@coredump.intra.peff.net>
We have very featureful color-parsing routines which are
used for color.diff.* and other options. Let's make it
easier to use those routines from other parts of the code.
This patch adds a color_parse_mem() helper function which
takes a length-bounded string instead of a NUL-terminated
one. While the helper is only a few lines long, it is nice
to abstract this out so that:
- callers don't forget to free() the temporary buffer
- right now, it is implemented in terms of color_parse().
But it would be more efficient to reverse this and
implement color_parse in terms of color_parse_mem.
This also changes the error string for an invalid color not
to mention the word "config", since it is not always
appropriate (and when it is, the context is obvious since
the offending config variable is given).
Finally, while we are in the area, we clean up the parameter
names in the declaration of color_parse; the var and value
parameters were reversed from the actual implementation.
Signed-off-by: Jeff King <peff@peff.net>
---
Just setup for the next patch.
color.c | 9 ++++++++-
color.h | 3 ++-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/color.c b/color.c
index fc0b72a..54a3da1 100644
--- a/color.c
+++ b/color.c
@@ -115,7 +115,7 @@ void color_parse(const char *value, const char *var, char *dst)
*dst = 0;
return;
bad:
- die("bad config value '%s' for variable '%s'", value, var);
+ die("bad color value '%s' for variable '%s'", value, var);
}
int git_config_colorbool(const char *var, const char *value, int stdout_is_tty)
@@ -191,3 +191,10 @@ int color_fprintf_ln(FILE *fp, const char *color, const char *fmt, ...)
va_end(args);
return r;
}
+
+void color_parse_mem(const char *value, int len, const char *var, char *dst)
+{
+ char *tmp = xmemdupz(value, len);
+ color_parse(tmp, var, dst);
+ free(tmp);
+}
diff --git a/color.h b/color.h
index 6cf5c88..7066099 100644
--- a/color.h
+++ b/color.h
@@ -16,7 +16,8 @@ extern int git_use_color_default;
int git_color_default_config(const char *var, const char *value, void *cb);
int git_config_colorbool(const char *var, const char *value, int stdout_is_tty);
-void color_parse(const char *var, const char *value, char *dst);
+void color_parse(const char *value, const char *var, char *dst);
+void color_parse_mem(const char *value, int len, const char *var, char *dst);
int color_fprintf(FILE *fp, const char *color, const char *fmt, ...);
int color_fprintf_ln(FILE *fp, const char *color, const char *fmt, ...);
--
1.6.1.238.g32268.dirty
^ permalink raw reply related
* [PATCH] http-push: fix off-by-path_len
From: Johannes Schindelin @ 2009-01-17 15:36 UTC (permalink / raw)
To: Kirill A. Korinskiy, git, gitster; +Cc: Mike Hommey, Ray Chuan, Nick Hengeveld
When getting the result of remote_ls(), we were advancing the variable
"path" to the relative path inside the repository.
However, then we went on to malloc a bogus amount of memory: we were
subtracting the prefix length _again_, quite possibly getting something
negative, which xmalloc() interprets as really, really much.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Note that the push in t5540 is still broken, as http-push does
not handle packed-refs (when looking what branches are on the
remote side).
It should not even try to access the directory structure under
refs/ to begin with, but read info/refs instead.
However, that is just one example of the ugliness that is
http-push.c; it also seems to be a perfect example of a copy-pasting
hell; just look at the output of "git grep
curl_easy_setopt http-push.c".
There _has_ to be lot of room for improvement.
http-push.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/http-push.c b/http-push.c
index 9fcccee..cb5bf95 100644
--- a/http-push.c
+++ b/http-push.c
@@ -1435,10 +1435,8 @@ static void handle_remote_ls_ctx(struct xml_ctx *ctx, int tag_closed)
}
if (path) {
path += remote->path_len;
+ ls->dentry_name = xstrdup(path);
}
- ls->dentry_name = xmalloc(strlen(path) -
- remote->path_len + 1);
- strcpy(ls->dentry_name, path + remote->path_len);
} else if (!strcmp(ctx->name, DAV_PROPFIND_COLLECTION)) {
ls->dentry_flags |= IS_DIR;
}
@@ -1449,6 +1447,12 @@ static void handle_remote_ls_ctx(struct xml_ctx *ctx, int tag_closed)
}
}
+/*
+ * NEEDSWORK: remote_ls() ignores info/refs on the remote side. But it
+ * should _only_ heed the information from that file, instead of trying to
+ * determine the refs from the remote file system (badly: it does not even
+ * know about packed-refs).
+ */
static void remote_ls(const char *path, int flags,
void (*userFunc)(struct remote_ls_ctx *ls),
void *userData)
--
1.6.1.325.g062d4
^ permalink raw reply related
* Cyellow, was Re: [a way-too-long line]
From: Johannes Schindelin @ 2009-01-17 15:39 UTC (permalink / raw)
To: Jeff King
Cc: Markus Heidelberg, Baz, Adeodato Simó,
Boyd Stephen Smith Jr., Shawn O. Pearce, Ted Pavlic, git,
Junio C Hamano
In-Reply-To: <20090117152108.GA24899@coredump.intra.peff.net>
Hi,
On Sat, 17 Jan 2009, Jeff King wrote:
> True. I was going to suggest %Cyellow, but for some reason only red,
> green, and blue are implemented. How silly. Patch series to follow.
http://repo.or.cz/w/git/dscho.git?a=commitdiff;h=af6ee188b3533e9c8eb665066ed0be32d58be875
Ciao,
Dscho
^ permalink raw reply
* [PATCH 2/2] expand --pretty=format color options
From: Jeff King @ 2009-01-17 15:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Markus Heidelberg, git, René Scharfe
In-Reply-To: <20090117152108.GA24899@coredump.intra.peff.net>
Currently, the only colors available to --pretty=format
users are red, green, and blue. Rather than expand it with a
few new colors, this patch makes the usual config color
syntax available, including more colors, backgrounds, and
attributes.
Because colors are no longer bounded to a single word (e.g.,
%Cred), this uses a more advanced syntax that features a
beginning and end delimiter (but the old syntax still
works). So you can now do:
git log --pretty=tformat:'%C(yellow)%h%C(reset) %s'
to emulate --pretty=oneline, or even
git log --pretty=tformat:'%C(cyan magenta bold)%s%C(reset)'
if you want to relive the awesomeness of 4-color CGA.
Signed-off-by: Jeff King <peff@peff.net>
---
René: I saw you mention an end goal of implementing the other --pretty
formats in terms of --pretty=format:. So maybe this will help just a
little.
Documentation/pretty-formats.txt | 1 +
pretty.c | 12 ++++++++++++
t/t6006-rev-list-format.sh | 9 ++++++++-
3 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 0a8a948..3d87d3e 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -124,6 +124,7 @@ The placeholders are:
- '%Cgreen': switch color to green
- '%Cblue': switch color to blue
- '%Creset': reset color
+- '%C(...)': color specification, as described in color.branch.* config option
- '%m': left, right or boundary mark
- '%n': newline
- '%x00': print a byte from a hex code
diff --git a/pretty.c b/pretty.c
index 343dca5..b1b8620 100644
--- a/pretty.c
+++ b/pretty.c
@@ -6,6 +6,7 @@
#include "string-list.h"
#include "mailmap.h"
#include "log-tree.h"
+#include "color.h"
static char *user_format;
@@ -554,6 +555,17 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
/* these are independent of the commit */
switch (placeholder[0]) {
case 'C':
+ if (placeholder[1] == '(') {
+ const char *end = strchr(placeholder + 2, ')');
+ char color[COLOR_MAXLEN];
+ if (!end)
+ return 0;
+ color_parse_mem(placeholder + 2,
+ end - (placeholder + 2),
+ "--pretty format", color);
+ strbuf_addstr(sb, color);
+ return end - placeholder + 1;
+ }
if (!prefixcmp(placeholder + 1, "red")) {
strbuf_addstr(sb, "\033[31m");
return 4;
diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
index 86bf7e1..59d1f62 100755
--- a/t/t6006-rev-list-format.sh
+++ b/t/t6006-rev-list-format.sh
@@ -14,7 +14,7 @@ touch foo && git add foo && git commit -m "added foo" &&
test_format() {
cat >expect.$1
test_expect_success "format $1" "
-git rev-list --pretty=format:$2 master >output.$1 &&
+git rev-list --pretty=format:'$2' master >output.$1 &&
test_cmp expect.$1 output.$1
"
}
@@ -101,6 +101,13 @@ commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
^[[31mfoo^[[32mbar^[[34mbaz^[[mxyzzy
EOF
+test_format advanced-colors '%C(red yellow bold)foo%C(reset)' <<'EOF'
+commit 131a310eb913d107dd3c09a65d1651175898735d
+^[[1;31;43mfoo^[[m
+commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+^[[1;31;43mfoo^[[m
+EOF
+
cat >commit-msg <<'EOF'
Test printing of complex bodies
--
1.6.1.238.g32268.dirty
^ permalink raw reply related
* Where's Nick?, was Re: [PATCH] http-push: fix off-by-path_len
From: Johannes Schindelin @ 2009-01-17 15:40 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0901171632330.3586@pacific.mpi-cbg.de>
Hi,
Nick's email address seems to be no longer functional. Any idea where
he's hanging about these days?
Ciao,
Dscho
^ permalink raw reply
* Re: Cyellow, was Re: [a way-too-long line]
From: Jeff King @ 2009-01-17 15:40 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Markus Heidelberg, Baz, Adeodato Simó,
Boyd Stephen Smith Jr., Shawn O. Pearce, Ted Pavlic, git,
Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0901171638250.3586@pacific.mpi-cbg.de>
On Sat, Jan 17, 2009 at 04:39:10PM +0100, Johannes Schindelin wrote:
> > True. I was going to suggest %Cyellow, but for some reason only red,
> > green, and blue are implemented. How silly. Patch series to follow.
>
> http://repo.or.cz/w/git/dscho.git?a=commitdiff;h=af6ee188b3533e9c8eb665066ed0be32d58be875
:) Yes, that does work, but please see the series I just posted:
http://article.gmane.org/gmane.comp.version-control.git/106062
which I think is a better solution.
-Peff
^ permalink raw reply
* [PATCH] t5540: clarify that http-push does not handle packed-refs on the remote
From: Johannes Schindelin @ 2009-01-17 15:41 UTC (permalink / raw)
To: git, gitster
In-Reply-To: <alpine.DEB.1.00.0901171632330.3586@pacific.mpi-cbg.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Sat, 17 Jan 2009, Johannes Schindelin wrote:
> Note that the push in t5540 is still broken, as http-push does
> not handle packed-refs (when looking what branches are on the
> remote side).
... and this clarifies the issue.
t/t5540-http-push.sh | 18 +++++++++++++++---
1 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/t/t5540-http-push.sh b/t/t5540-http-push.sh
index 22cfbb6..c236b5e 100755
--- a/t/t5540-http-push.sh
+++ b/t/t5540-http-push.sh
@@ -51,17 +51,29 @@ test_expect_success 'clone remote repository' '
git clone $HTTPD_URL/test_repo.git test_repo_clone
'
-test_expect_failure 'push to remote repository' '
+test_expect_failure 'push to remote repository with packed refs' '
cd "$ROOT_PATH"/test_repo_clone &&
: >path2 &&
git add path2 &&
test_tick &&
git commit -m path2 &&
+ HEAD=$(git rev-parse --verify HEAD) &&
git push &&
- [ -f "$HTTPD_DOCUMENT_ROOT_PATH/test_repo.git/refs/heads/master" ]
+ (cd "$HTTPD_DOCUMENT_ROOT_PATH"/test_repo.git &&
+ test $HEAD = $(git rev-parse --verify HEAD))
'
-test_expect_failure 'create and delete remote branch' '
+test_expect_success ' push to remote repository with unpacked refs' '
+ (cd "$HTTPD_DOCUMENT_ROOT_PATH"/test_repo.git &&
+ rm packed-refs &&
+ git update-ref refs/heads/master \
+ 0c973ae9bd51902a28466f3850b543fa66a6aaf4) &&
+ git push &&
+ (cd "$HTTPD_DOCUMENT_ROOT_PATH"/test_repo.git &&
+ test $HEAD = $(git rev-parse --verify HEAD))
+'
+
+test_expect_success 'create and delete remote branch' '
cd "$ROOT_PATH"/test_repo_clone &&
git checkout -b dev &&
: >path3 &&
--
1.6.1.325.g062d4
^ permalink raw reply related
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