* Re: [PATCH 4/5] Full rework of quote_c_style and write_name_quoted.
From: Junio C Hamano @ 2007-09-19 8:28 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <20070918224122.2B55D344AB3@madism.org>
Pierre Habouzit <madcoder@debian.org> writes:
> ...
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> ---
> builtin-apply.c | 83 +++++--------
> builtin-blame.c | 3 +-
> builtin-check-attr.c | 2 +-
> builtin-checkout-index.c | 4 +-
> builtin-ls-files.c | 13 +--
> builtin-ls-tree.c | 6 +-
> combine-diff.c | 16 +--
> diff.c | 303 +++++++++++++++++-----------------------------
> quote.c | 198 +++++++++++++++++-------------
> quote.h | 8 +-
> 10 files changed, 268 insertions(+), 368 deletions(-)
> ...
> diff --git a/builtin-apply.c b/builtin-apply.c
> index cffbe52..0328863 100644
> --- a/builtin-apply.c
> +++ b/builtin-apply.c
> @@ -1378,61 +1377,50 @@ static const char minuses[]= "--------------------------------------------------
>
> static void show_stats(struct patch *patch)
> {
> - const char *prefix = "";
> - char *name = patch->new_name;
> - char *qname = NULL;
> - int len, max, add, del, total;
> -
> - if (!name)
> - name = patch->old_name;
> + struct strbuf qname;
> + char *cp = patch->new_name ? patch->new_name : patch->old_name;
> + int max, add, del;
>
> - if (0 < (len = quote_c_style(name, NULL, NULL, 0))) {
> - qname = xmalloc(len + 1);
> - quote_c_style(name, qname, NULL, 0);
> - name = qname;
> - }
> + strbuf_init(&qname, 0);
> + quote_c_style(cp, &qname, NULL, 0);
>
> /*
> * "scale" the filename
> */
> - len = strlen(name);
> max = max_len;
> if (max > 50)
> max = 50;
> - if (len > max) {
> - char *slash;
> - prefix = "...";
> - max -= 3;
> - name += len - max;
> - slash = strchr(name, '/');
> - if (slash)
> - name = slash;
> +
> + if (qname.len > max) {
> + cp = strchr(qname.buf + qname.len + 3 - max, '/');
> + if (cp)
> + cp = qname.buf + qname.len + 3 - max;
> + strbuf_splice(&qname, 0, cp - qname.buf, "...", 3);
> + }
At this point, you have max that is larger by 3 than what old
code had. That would make the next two printf() you added as
expected. This affects scaling of add/delete code. Is this
intentional? I _think_ the change is correct (there is no
reason that name display being cliped should affect the length
of the bar graph), but that should have been documented as a
separate bugfix in the commit log.
> diff --git a/quote.c b/quote.c
> index 67c6527..a8a755a 100644
> --- a/quote.c
> +++ b/quote.c
> @@ -114,83 +114,142 @@ char *sq_dequote(char *arg)
> }
> }
>
> +/* 1 means: quote as octal
> + * 0 means: quote as octal if (quote_path_fully)
> + * -1 means: never quote
> + * c: quote as "\\c"
> + */
> +#define X8(x) x, x, x, x, x, x, x, x
> +#define X16(x) X8(x), X8(x)
> +static signed char const sq_lookup[256] = {
> + /* 0 1 2 3 4 5 6 7 */
> + /* 0x00 */ 1, 1, 1, 1, 1, 1, 'a', 1,
Isn't BEL == 0x07, not 0x06?
> + /* 0x08 */ 'b', 't', 'n', 'v', 'f', 'r', 1, 1,
> + /* 0x10 */ X16(1),
> + /* 0x20 */ -1, -1, '"', -1, -1, -1, -1, -1,
> + /* 0x28 */ X16(-1), X16(-1), X16(-1),
> + /* 0x58 */ -1, -1, -1, -1,'\\', -1, -1, -1,
> + /* 0x60 */ X16(-1), X16(-1),
Shouldn't you quote DEL == 0177 here?
> + /* 0x80 */ /* set to 0 */
> +};
> +
> +static inline int sq_must_quote(char c) {
> + return sq_lookup[(unsigned char)c] + quote_path_fully > 0;
> +}
> +
> +/* returns the longest prefix not needing a quote up to maxlen if positive.
> + This stops at the first \0 because it's marked as a character needing an
> + escape */
> +static size_t next_quote_pos(const char *s, ssize_t maxlen)
> +{
> + size_t len;
> + if (maxlen < 0) {
> + for (len = 0; !sq_must_quote(s[len]); len++);
> + } else {
> + for (len = 0; len < maxlen && !sq_must_quote(s[len]); len++);
> + }
> + return len;
> +}
> +
> /*
> * C-style name quoting.
> *
> - * Does one of three things:
> - *
> * (1) if outbuf and outfp are both NULL, inspect the input name and
> * counts the number of bytes that are needed to hold c_style
> * quoted version of name, counting the double quotes around
> * it but not terminating NUL, and returns it. However, if name
> * does not need c_style quoting, it returns 0.
> *
You need to update this comment; you do not have outbuf nor
outfp anymore, you have something else.
^ permalink raw reply
* Re: [PATCH 4/5] Full rework of quote_c_style and write_name_quoted.
From: Junio C Hamano @ 2007-09-19 8:31 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86r6kv2h64.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> writes:
> Pierre Habouzit <madcoder@debian.org> writes:
>
>> On Wed, Sep 19, 2007 at 08:08:02AM +0000, Andreas Ericsson wrote:
>>> Then perhaps a separate patch for this would have been prudent? I'm not
>>> against the change per se and I understand the reasoning behind it, but
>>> it seems to go against Documentation/SubmittingPatches (submit one change
>>> at a time).
>>
>> Yes, the thing is, I wrote it in one piece, and had a _very_ hard time
>> splitting it. The aggregated patches had almost no chunks, and editing
>> diffs by hand isn't what I like to do :)
>
> Use Emacs for it. After loading the patch in a file, type
>
> Esc x diff-mode RET
>
> If you now move to a place in the middle of a hunk and type C-c C-s,
> the hunk is split at that point into two hunks. C-c C-k kills the
> current hunk. C-x C-s saves the file, C-x C-c exits Emacs.
>
> In that manner throwing selected material out of a patch is rather
> straightforward, even when it is in the middle of a hunk.
Be careful when you edit format-patch output. It seems that
diff-mode tends to mistake the trailing "signature separator" at
the end as if it is a removal of a line from the preimage, and
editing the last hunk ends up miscalculating the number of lines
in it. It might have been fixed in the latest version but I was
burned by it number of times.
^ permalink raw reply
* Re: [PATCH] Simplify strbuf uses in archive-tar.c using the proper functions.
From: Pierre Habouzit @ 2007-09-19 8:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8x73qdtr.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1624 bytes --]
On Wed, Sep 19, 2007 at 08:06:24AM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
> > + strbuf_grow(&path, MAX(PATH_MAX, baselen + filenamelen + 1));
>
> Where are you getting the MAX() macro from? On my Linux box
> it appears that <sys/params.h> happens to define it but I do not
> think that is something we can rely upon portably.
indeed.
> Moreover, isn't this allocation wrong? I thought "grow" was
> about "we want this much more in addition to the existing
> length", not "reserve at least this much", and this "path" is a
> static that will keep the buffer and length from the previous
> invocation.
I'm a nitwit, the strbuf_reset() should be done _before_ the grow
indeed.
> > + strbuf_reset(&path);
> > + strbuf_add(&path, base, baselen);
> > + strbuf_add(&path, filename, filenamelen);
> > if (S_ISDIR(mode) || S_ISGITLINK(mode)) {
> > - strbuf_append_string(&path, "/");
> > + strbuf_addch(&path, '/');
> > buffer = NULL;
> > size = 0;
> > } else {
>
> Having said that, I suspect that the preallocation does not
> really matter in practice. How about doing something like:
>
> strbuf_reset(&path);
> strbuf_grow(&path, PATH_MAX);
> strbuf_add(&path, base, baselen);
> strbuf_add(&path, filename, filenamelen);
yeah, I was about to propose the same, I'll add a patch in my current
series to fix that this way.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 4/5] Full rework of quote_c_style and write_name_quoted.
From: David Kastrup @ 2007-09-19 8:38 UTC (permalink / raw)
To: git
In-Reply-To: <7vwsunoy3d.fsf@gitster.siamese.dyndns.org>
[Also posted to the list via gmane, so reply there if appropriate]
Junio C Hamano <gitster@pobox.com> writes:
> David Kastrup <dak@gnu.org> writes:
>>
>> Esc x diff-mode RET
>
> Be careful when you edit format-patch output. It seems that
> diff-mode tends to mistake the trailing "signature separator" at
> the end as if it is a removal of a line from the preimage, and
> editing the last hunk ends up miscalculating the number of lines
> in it. It might have been fixed in the latest version but I was
> burned by it number of times.
Would you be able to prepare an example and submit it using
M-x report-emacs-bug RET (probably using an attachment)?
Emacs 22.2 is likely to come out in a few months mainly as a bug fix,
incremental change and maintenance release to 22.1, and this would be
very much the kind of bug that warrants getting fixed, in particular
since it appears likely that Emacs 22.2 will come with git support in
VC.
If there is a good test case known to fail in your Emacs version, it
would be quite easy to verify that it is or gets fixed in 22.2
Thanks,
--
David Kastrup
^ permalink raw reply
* Re: [PATCH 4/5] Full rework of quote_c_style and write_name_quoted.
From: Pierre Habouzit @ 2007-09-19 8:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wcvqcsg.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2375 bytes --]
On Wed, Sep 19, 2007 at 08:28:47AM +0000, Junio C Hamano wrote:
> At this point, you have max that is larger by 3 than what old
> code had. That would make the next two printf() you added as
> expected. This affects scaling of add/delete code. Is this
> intentional? I _think_ the change is correct (there is no
> reason that name display being cliped should affect the length
> of the bar graph), but that should have been documented as a
> separate bugfix in the commit log.
Indeed, in fact I didn't noticed that difference, I'll document that.
>
> > diff --git a/quote.c b/quote.c
> > index 67c6527..a8a755a 100644
> > --- a/quote.c
> > +++ b/quote.c
> > @@ -114,83 +114,142 @@ char *sq_dequote(char *arg)
> > }
> > }
> >
> > +/* 1 means: quote as octal
> > + * 0 means: quote as octal if (quote_path_fully)
> > + * -1 means: never quote
> > + * c: quote as "\\c"
> > + */
> > +#define X8(x) x, x, x, x, x, x, x, x
> > +#define X16(x) X8(x), X8(x)
> > +static signed char const sq_lookup[256] = {
> > + /* 0 1 2 3 4 5 6 7 */
> > + /* 0x00 */ 1, 1, 1, 1, 1, 1, 'a', 1,
>
> Isn't BEL == 0x07, not 0x06?
indeed.
> > + /* 0x08 */ 'b', 't', 'n', 'v', 'f', 'r', 1, 1,
> > + /* 0x10 */ X16(1),
> > + /* 0x20 */ -1, -1, '"', -1, -1, -1, -1, -1,
> > + /* 0x28 */ X16(-1), X16(-1), X16(-1),
> > + /* 0x58 */ -1, -1, -1, -1,'\\', -1, -1, -1,
> > + /* 0x60 */ X16(-1), X16(-1),
>
> Shouldn't you quote DEL == 0177 here?
indeed again.
> > /*
> > * C-style name quoting.
> > *
> > - * Does one of three things:
> > - *
> > * (1) if outbuf and outfp are both NULL, inspect the input name and
> > * counts the number of bytes that are needed to hold c_style
> > * quoted version of name, counting the double quotes around
> > * it but not terminating NUL, and returns it. However, if name
> > * does not need c_style quoting, it returns 0.
> > *
>
> You need to update this comment; you do not have outbuf nor
> outfp anymore, you have something else.
heh, well outfp is still here, but I'll fix the part about outbuf.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Mention that 'push .. master' is in explicit form master:refs/heads/master
From: Jari Aalto @ 2007-09-19 10:37 UTC (permalink / raw)
To: git
In-Reply-To: <7vfy1bvgn1.fsf@gitster.siamese.dyndns.org>
* Tue 2007-09-18 Junio C Hamano <gitster AT pobox.com>
* Message-Id: 7vfy1bvgn1.fsf AT gitster.siamese.dyndns.org
>> Find a ref that matches `master` in the source repository
>> (most likely, it would find `refs/heads/master`), and update
>> the same ref (e.g. `refs/heads/master`) in `origin` repository
>> - with it.
>> + with it. The following would be exactly same command:
>> +
>> + git push origin master:refs/heads/master
>
> They _might_ be exactly the same.
>
> The reason people often explicitly write
>
> $ git push $URL refs/heads/master:refs/heads/master
>
> in their insns for newbies is because this form would not be
> affected by the random factors at $URL repository (or your
> repository) and will consistently get the same result.
>
> $ git push $URL foo
>
> may push branch head 'foo' or tag 'foo' depending on which one
> you have locally. Having both is not encouraged, but spelling
> the insn out explicitly as refs/heads/foo makes it clear the
> command is talking about the branch even when there is a tag
> with the same name.
Thank you, kindly broaden the current documentation to include this
explanation.
Jari
--
Welcome to FOSS revolution: we fix and modify until it shines
^ permalink raw reply
* Side-by-side diff and patch visualization
From: Wincent Colaiuta @ 2007-09-19 11:40 UTC (permalink / raw)
To: Git Mailing List
Does anybody know of any tools for doing side-by-side visualizations
of diffs and patches which work well with Git?
By side-by-side I mean something like what's shown in this screen shot:
<http://wincent.com/images/side-by-side-diff.png>
For simple diffs there is little advantage here over a raw textual
diff, but as patch complexity and size increase the side-by-side diff
can sometimes prove itself to be more useful:
- totally flexible notion of context (you can scroll as far as you
want in either direction)
- this flexibility comes with the same rapid movement between changes
(ie. up/down cursor keys to jump between hunks no matter how far
apart they are)
- for complex diffs, truly comprehending the nature of the changes
may be easier in a side-by-side format
- as icing on cake, the implementation in the screenshot highlights
the removed/added portions within each line
Now, that screenshot is actually of Apple's FileMerge app on Mac OS X
and it would be fairly straightforward to write a dump wrapper script
that either just interpreted the output of git-diff, or could be used
in conjunction with GIT_EXTERNAL_DIFF, to feed files into opendiff
two at a time, but that wouldn't allow you to easily visualize diffs
which touch many paths.
So, can anyone recommend a tool which can do this kind of side-by-
side visualization and plays nicely with Git? Experience with
opendiff and git-mergetool has spoilt me here. For most cases I would
continue to use vanilla git-diff (or gitk), but when I see a change
that I'd like to visualize side-by-side I'd like to be able to use
this alternative diff viewer (or can gitk already do side-by-side
diffs and I just haven't seen how to turn them on?). Bonus points if
I could not only view existing commits, but proposed commits too (ie.
the ability to feed in a patch and see a side-by-side visualization
of what the diff would look like if applied).
If nothing exists I will look at quickly hacking something together
(most likely something that just reads the output of git-diff), but
it will be just that, a quick hack.
Cheers,
Wincent
^ permalink raw reply
* Initial push to remote repository
From: Thomas Glanzmann @ 2007-09-19 11:35 UTC (permalink / raw)
To: GIT
Hello,
I used to publish my local work on a machine with all my git
repositories using the following commands:
# Publish a local created repository to a remote repository.
ssh 131.188.30.102 git --git-dir=/home/cip/adm/sithglan/work/repositories/private/astro.git init-db
git remote add origin 131.188.30.102:/home/cip/adm/sithglan/work/repositories/private/astro.git
git push origin master:master
echo >> .git/config <<EOF
[branch "master"]
remote = origin
merge = refs/heads/master
EOF
git pull
But since my last update of git it doesn't seem to work that way anymore. Is
there another way to do what I like to using the git way?
(ad027088pc) [~] mkdir test_initial_push
(ad027088pc) [~] cd !$
(ad027088pc) [~/test_initial_push] touch a
(ad027088pc) [~/test_initial_push] git init
Initialized empty Git repository in .git/
(ad027088pc) [~/test_initial_push] git add a
(ad027088pc) [~/test_initial_push] git commit -m "whatever" a
Created initial commit 0d408ed: whatever
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 a
(reverse-i-search)`':
(ad027088pc) [~/test_initial_push] ssh 131.188.30.102 git --git-dir=/home/cip/adm/sithglan/work/repositories/private/test_initial_push.git init-db
Initialized empty Git repository in /home/cip/adm/sithglan/work/repositories/private/test_initial_push.git/
(ad027088pc) [~/test_initial_push] git remote add origin 131.188.30.102:/home/cip/adm/sithglan/work/repositories/private/test_initial_push.git/
You have new mail in /home/adglth0/Maildir
(ad027088pc) [~/test_initial_push] git push origin master:master
error: dst refspec master does not match any existing ref on the remote and does not start with refs/.
fatal: The remote end hung up unexpectedly
error: failed to push to '131.188.30.102:/home/cip/adm/sithglan/work/repositories/private/test_initial_push.git/'
(ad027088pc) [~/test_initial_push] git version
git version 1.5.3.1
(ad027088pc) [~/test_initial_push] ssh 131.188.30.102 git version
git version 1.5.2.1
Thomas
^ permalink raw reply
* Re: Side-by-side diff and patch visualization
From: Jeff King @ 2007-09-19 12:09 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Git Mailing List
In-Reply-To: <A92611E8-1035-46A6-AFEF-9C8A6F93AFB1@wincent.com>
On Wed, Sep 19, 2007 at 01:40:17PM +0200, Wincent Colaiuta wrote:
> Does anybody know of any tools for doing side-by-side visualizations of
> diffs and patches which work well with Git?
Have you tried kompare?
git-diff HEAD~5 | kompare -
-Peff
^ permalink raw reply
* Re: Initial push to remote repository
From: Peter Baumann @ 2007-09-19 12:25 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: GIT
In-Reply-To: <20070919113557.GA24674@cip.informatik.uni-erlangen.de>
On Wed, Sep 19, 2007 at 01:35:57PM +0200, Thomas Glanzmann wrote:
> Hello,
> I used to publish my local work on a machine with all my git
> repositories using the following commands:
>
> # Publish a local created repository to a remote repository.
> ssh 131.188.30.102 git --git-dir=/home/cip/adm/sithglan/work/repositories/private/astro.git init-db
> git remote add origin 131.188.30.102:/home/cip/adm/sithglan/work/repositories/private/astro.git
> git push origin master:master
> echo >> .git/config <<EOF
> [branch "master"]
> remote = origin
> merge = refs/heads/master
> EOF
> git pull
>
> But since my last update of git it doesn't seem to work that way anymore. Is
> there another way to do what I like to using the git way?
>
> (ad027088pc) [~] mkdir test_initial_push
> (ad027088pc) [~] cd !$
> (ad027088pc) [~/test_initial_push] touch a
> (ad027088pc) [~/test_initial_push] git init
> Initialized empty Git repository in .git/
> (ad027088pc) [~/test_initial_push] git add a
> (ad027088pc) [~/test_initial_push] git commit -m "whatever" a
> Created initial commit 0d408ed: whatever
> 0 files changed, 0 insertions(+), 0 deletions(-)
> create mode 100644 a
> (reverse-i-search)`':
> (ad027088pc) [~/test_initial_push] ssh 131.188.30.102 git --git-dir=/home/cip/adm/sithglan/work/repositories/private/test_initial_push.git init-db
> Initialized empty Git repository in /home/cip/adm/sithglan/work/repositories/private/test_initial_push.git/
> (ad027088pc) [~/test_initial_push] git remote add origin 131.188.30.102:/home/cip/adm/sithglan/work/repositories/private/test_initial_push.git/
> You have new mail in /home/adglth0/Maildir
> (ad027088pc) [~/test_initial_push] git push origin master:master
> error: dst refspec master does not match any existing ref on the remote and does not start with refs/.
> fatal: The remote end hung up unexpectedly
> error: failed to push to '131.188.30.102:/home/cip/adm/sithglan/work/repositories/private/test_initial_push.git/'
Try to give it the full ref name and it should work, e.g.
git push origin refs/heads/master:refs/heads/master
-siprbaum
^ permalink raw reply
* Re: Initial push to remote repository
From: Thomas Glanzmann @ 2007-09-19 12:27 UTC (permalink / raw)
To: Peter Baumann; +Cc: GIT
In-Reply-To: <20070919122558.GA4777@xp.machine.xx>
Hello Peter,
> Try to give it the full ref name and it should work, e.g.
> git push origin refs/heads/master:refs/heads/master
I owe you a beer or two.
(ad027088pc) [~/work/raid_ueberwachung] git push origin refs/heads/master:refs/heads/master
updating 'refs/heads/master'
from 0000000000000000000000000000000000000000
to aca655af03443ef8b4adea269b50471894686b14
Also local refs/remotes/origin/master
Generating pack...
Done counting 18 objects.
Deltifying 18 objects...
100% (18/18) done
Writing 18 objects...
100% (18/18) done
Total 18 (delta 6), reused 0 (delta 0)
refs/heads/master: 0000000000000000000000000000000000000000 -> aca655af03443ef8b4adea269b50471894686b14
Thomas
^ permalink raw reply
* Re: Side-by-side diff and patch visualization
From: Wincent Colaiuta @ 2007-09-19 12:36 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
In-Reply-To: <20070919120956.GA20715@coredump.intra.peff.net>
El 19/9/2007, a las 14:09, Jeff King escribió:
> On Wed, Sep 19, 2007 at 01:40:17PM +0200, Wincent Colaiuta wrote:
>
>> Does anybody know of any tools for doing side-by-side
>> visualizations of
>> diffs and patches which work well with Git?
>
> Have you tried kompare?
>
> git-diff HEAD~5 | kompare -
>
> -Peff
Ah, didn't know about that one. From the look of it that is exactly
the kind of extremely simple viewer that I was wanting.
Cheers,
Wincent
^ permalink raw reply
* Re: Side-by-side diff and patch visualization
From: David Kastrup @ 2007-09-19 12:23 UTC (permalink / raw)
To: git
In-Reply-To: <A92611E8-1035-46A6-AFEF-9C8A6F93AFB1@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> Does anybody know of any tools for doing side-by-side visualizations
> of diffs and patches which work well with Git?
>
> So, can anyone recommend a tool which can do this kind of side-by-
> side visualization and plays nicely with Git?
I use M-x ediff-revision RET in Emacs for this. There is also M-x
smerge-ediff RET for resolving a file with merge conflict markers, and
M-x ediff-merge-revisions-with-ancestor RET.
The side-by-side layout is chosen by typing | into the control window
for the merge.
Looking at a patch in respect of two versions can be done with M-x
ediff-patch-file RET.
--
David Kastrup
^ permalink raw reply
* Re: [PATCH 1/5] strbuf API additions and enhancements.
From: Edgar Toernig @ 2007-09-19 12:46 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Junio C Hamano, Shawn O. Pearce, git
In-Reply-To: <20070918224119.17650344AB3@madism.org>
Pierre Habouzit wrote:
>
> +void strbuf_addvf(struct strbuf *sb, const char *fmt, va_list ap)
> +{
> + int len;
> +
> + len = vsnprintf(sb->buf + sb->len, sb->alloc - sb->len, fmt, ap);
> + if (len < 0) {
> + len = 0;
> + }
> + if (len > strbuf_avail(sb)) {
> + strbuf_grow(sb, len);
> + len = vsnprintf(sb->buf + sb->len, sb->alloc - sb->len, fmt, ap);
> + if (len > strbuf_avail(sb)) {
> + die("this should not happen, your snprintf is broken");
> + }
> + }
> + strbuf_setlen(sb, sb->len + len);
> +}
The second vsnprintf won't work as the first one consumed all args
from va_list ap. You need to va_copy the ap. But iirc va_copy poses
compatibility issues. Unless va_copy is made available somehow,
I would suggest to let the caller know that the buffer was too small
(but isn't any more) and it has to call the function again:
int strbuf_addvf(struct strbuf *sb, const char *fmt, va_list ap)
{
int len;
len = vsnprintf(sb->buf + sb->len, sb->alloc - sb->len, fmt, ap);
if (len < 0)
return 0;
if (len > strbuf_avail(sb)) {
strbuf_grow(sb, len);
return -1;
}
strbuf_setlen(sb, sb->len + len);
return 0;
}
The caller:
do {
va_start(ap, fmt);
again = strbuf_addvf(sb, fmt, ap);
va_end(ap);
} while (again);
va_copy would be nicer though...
Ciao, ET.
^ permalink raw reply
* Re: Side-by-side diff and patch visualization
From: Andy Parkins @ 2007-09-19 13:08 UTC (permalink / raw)
To: git; +Cc: Jeff King, Wincent Colaiuta
In-Reply-To: <20070919120956.GA20715@coredump.intra.peff.net>
On Wednesday 2007 September 19, Jeff King wrote:
> Have you tried kompare?
>
> git-diff HEAD~5 | kompare -
You can also throw in the "--unified" switch to see the whole file, rather
than just the bits that have changed (if that's what you like).
git-diff --unified=9999999 HEAD~5 | kompare -
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [PATCH 2/5] Refactor struct transport_ops inlined into struct transport
From: Johannes Schindelin @ 2007-09-19 13:11 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20070919044931.GB17107@spearce.org>
Hi,
On Wed, 19 Sep 2007, Shawn O. Pearce wrote:
> diff --git a/transport.c b/transport.c
> index cc76e3f..d8458dc 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -44,8 +44,6 @@ static int disconnect_walker(struct transport *transport)
> return 0;
> }
>
> -static const struct transport_ops rsync_transport;
> -
> static int curl_transport_push(struct transport *transport, int refspec_nr, const char **refspec, int flags) {
> const char **argv;
> int argc;
> @@ -431,18 +406,31 @@ struct transport *transport_get(struct remote *remote, const char *url)
> ret->url = url;
>
> if (!prefixcmp(url, "rsync://")) {
> - ret->ops = &rsync_transport;
> + /* not supported; don't populate any ops */
> +
That is sneaky. What are the reasons to remove rsync support? I know it
is deprecated, but I'd still like to have it, especially for initial
clones on small-RAMed machines.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/5] strbuf API additions and enhancements.
From: Pierre Habouzit @ 2007-09-19 13:36 UTC (permalink / raw)
To: Edgar Toernig; +Cc: Junio C Hamano, Shawn O. Pearce, git
In-Reply-To: <20070919144604.7deca4f7.froese@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 1603 bytes --]
On Wed, Sep 19, 2007 at 12:46:04PM +0000, Edgar Toernig wrote:
> Pierre Habouzit wrote:
> >
> > +void strbuf_addvf(struct strbuf *sb, const char *fmt, va_list ap)
> > +{
> > + int len;
> > +
> > + len = vsnprintf(sb->buf + sb->len, sb->alloc - sb->len, fmt, ap);
> > + if (len < 0) {
> > + len = 0;
> > + }
> > + if (len > strbuf_avail(sb)) {
> > + strbuf_grow(sb, len);
> > + len = vsnprintf(sb->buf + sb->len, sb->alloc - sb->len, fmt, ap);
> > + if (len > strbuf_avail(sb)) {
> > + die("this should not happen, your snprintf is broken");
> > + }
> > + }
> > + strbuf_setlen(sb, sb->len + len);
> > +}
>
> The second vsnprintf won't work as the first one consumed all args
> from va_list ap. You need to va_copy the ap. But iirc va_copy poses
> compatibility issues. Unless va_copy is made available somehow,
> I would suggest to let the caller know that the buffer was too small
> (but isn't any more) and it has to call the function again:
That's what I thought, and then nfvasprintf in trace.c suffers from
the same issue, as I copied the code from there.
> do {
> va_start(ap, fmt);
> again = strbuf_addvf(sb, fmt, ap);
> va_end(ap);
> } while (again);
in fact doing it twice is enough but either way I don't like to impose
that to the caller :/ I mean it's totally stupid to have to do that on a
strbuf. of course we could provide a macro doing that ...
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Repository backups
From: Jason Sewall @ 2007-09-19 15:14 UTC (permalink / raw)
To: git
I'd like to build a modest safety net for my various git repositories
in case of catastrophic failure. Currently, everything is backed up on
machines in the same building. I'm not expecting the Computer Science
building to get hit by terrorists and we're in a seismically stable
place, but there *is* construction nearby...
Anyway, my university offers a "mass storage" tape-based service that
is supposedly very safe. We are encouraged to give them single big
files for backups.
The temptation to just make bundles of all branch heads is great but
probably not what I really want - things like reflogs don't get handed
off with those, if I understand correctly.
Is there any argument against just making a tar of a bare clone of the
repo? Any other ideas? I'm reluctant to actually clone into the tape
(SAM-FS, which I know nothing about) because of the number of files it
would create and the lack of git tools on the machines with access to
this machine.
Thanks,
Jason
^ permalink raw reply
* Re: Repository backups
From: Johannes Schindelin @ 2007-09-19 15:27 UTC (permalink / raw)
To: Jason Sewall; +Cc: git
In-Reply-To: <31e9dd080709190814t6ef8b725w8a8320685e70578b@mail.gmail.com>
Hi,
On Wed, 19 Sep 2007, Jason Sewall wrote:
> I'd like to build a modest safety net for my various git repositories
> in case of catastrophic failure. Currently, everything is backed up on
> machines in the same building. I'm not expecting the Computer Science
> building to get hit by terrorists and we're in a seismically stable
> place, but there *is* construction nearby...
>
> Anyway, my university offers a "mass storage" tape-based service that
> is supposedly very safe. We are encouraged to give them single big
> files for backups.
>
> The temptation to just make bundles of all branch heads is great but
> probably not what I really want - things like reflogs don't get handed
> off with those, if I understand correctly.
>
> Is there any argument against just making a tar of a bare clone of the
> repo?
If you make a bare clone, you lose reflogs, too.
So I would backup the complete .git/ directory instead.
Hth,
Dscho
^ permalink raw reply
* Re: State of Perforce importing.
From: David Brown @ 2007-09-19 17:12 UTC (permalink / raw)
To: Simon Hausmann; +Cc: Git
In-Reply-To: <200709190819.12188.simon@lst.de>
On Wed, Sep 19, 2007 at 08:19:11AM +0200, Simon Hausmann wrote:
>> An additional problem:
>>
>> - git-p4 doesn't preserve the execute permission bit from Perforce.
>
>Hmm, can you paste the output of
>
> p4 fstat //path/in/depot/to/file/that/is/imported/incorrectly
>
>? I'm interested in the type of the file that p4 reports.
headType kxtext
so the problem is that the git-p4 is only looking for an 'x' at the start.
According to 'p4 help filetypes', we need to use execute for any of:
cxtext, kxtext, uxbinary, and the others that start with 'x'.
I think it would be sufficient to check the first or second character for
an 'x'. I'll make a change and give it a try later today.
David
^ permalink raw reply
* [PATCH] User Manual: add a chapter for submodules
From: Miklos Vajna @ 2007-09-19 17:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0709181405120.6203@juice.ott.cti.com>
Signed-off-by: Michael Smith <msmith@cbnco.com>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Tue, Sep 18, 2007 at 02:12:17PM -0400, Michael Smith <msmith@cbnco.com> wrote:
> On Tue, 18 Sep 2007, Miklos Vajna wrote:
>
> > Michael, i think the wiki version is better as my example does not
> > contain any extra to the wiki version. is it ok if i would send a patch
> > to include your work in the official docs?
>
> Thanks, that would be great.
here it is. this version is a bit shorter than the wiki one, but i think it
does not contain less useful info
Documentation/user-manual.txt | 175 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 175 insertions(+), 0 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index ecb2bf9..ce0cf38 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -3155,6 +3155,181 @@ a tree which you are in the process of working on.
If you blow the index away entirely, you generally haven't lost any
information as long as you have the name of the tree that it described.
+[[submodules]]
+Submodules
+==========
+
+This tutorial explains how to create and publish a repository with submodules
+using the gitlink:git-submodule[1] command.
+
+Submodules maintain their own identity; the submodule support just stores the
+submodule repository location and commit ID, so other developers who clone the
+superproject can easily clone all the submodules at the same revision.
+
+To see how submodule support works, create (for example) four example
+repository that can be used later as a submodule:
+
+-------------------------------------------------
+$ mkdir ~/git
+$ cd ~/git
+$ for i in a b c d
+do
+ mkdir $i
+ cd $i
+ git init
+ echo "module $i" > $i.txt
+ git add $i.txt
+ git commit -m "Initial commit, submodule $mod"
+ cd ..
+done
+-------------------------------------------------
+
+Now create the superproject and add all the submodules:
+
+-------------------------------------------------
+$ mkdir super
+$ cd super
+$ git init
+$ echo hi > super.txt
+$ git add super.txt
+$ git commit -m "Initial commit of empty superproject"
+$ for i in a b c d
+do
+ git submodule add ~/git/$i
+done
+-------------------------------------------------
+
+See what files `git submodule` created:
+
+-------------------------------------------------
+$ ls -a
+. .. .git .gitmodules a b c d super.txt
+-------------------------------------------------
+
+The `git submodule add` command does a couple of things:
+
+- It clones the submodule under the current directory and by default checks out
+ the master branch.
+- It adds the submodule's clone path to the `.gitmodules` file and adds this
+ file to the index, ready to be committed.
+- It adds the submodule's current commit ID to the index, ready to be
+ committed.
+
+Commit the superproject:
+
+-------------------------------------------------
+$ git commit -m "Add submodules a, b, c, d."
+-------------------------------------------------
+
+Now clone the superproject:
+
+-------------------------------------------------
+$ cd ..
+$ git clone super cloned
+$ cd cloned
+-------------------------------------------------
+
+The submodule directories are there, but they're empty:
+
+-------------------------------------------------
+$ ls -a a
+. ..
+$ git submodule status
+-d266b9873ad50488163457f025db7cdd9683d88b a
+-e81d457da15309b4fef4249aba9b50187999670d b
+-c1536a972b9affea0f16e0680ba87332dc059146 c
+-d96249ff5d57de5de093e6baff9e0aafa5276a74 d
+-------------------------------------------------
+
+Pulling down the submodules is a two-step process. First run `git submodule
+init` to add the submodule repository URLs to `.git/config`:
+
+-------------------------------------------------
+$ git submodule init
+-------------------------------------------------
+
+Now use `git submodule update` to clone the repositories and check out the
+commits specified in the superproject:
+
+-------------------------------------------------
+$ git submodule update
+$ cd a
+$ ls -a
+. .. .git a.txt
+-------------------------------------------------
+
+One major difference between `git submodule update` and `git submodule add` is
+that `git submodule update` checks out a specific commit, rather than the tip
+of a branch. It's like checking out a tag: the head is detached, so you're not
+working on a branch.
+
+-------------------------------------------------
+$ git branch
+* (no branch)
+ master
+-------------------------------------------------
+
+If you want to make a change within a submodule, you should first check out a
+branch, make your changes, publish the change within the submodule, and then
+update the superproject to reference the new commit:
+
+-------------------------------------------------
+$ git branch
+* (no branch)
+ master
+$ git checkout master
+$ echo "adding a line again" >> a.txt
+$ git commit -a -m "Updated the submodule from within the superproject."
+$ git push
+$ cd ..
+$ git add a
+$ git commit -m "Updated submodule a."
+$ git push
+-------------------------------------------------
+
+NOTE: This means that you have to run `git submodule update` after `git pull`
+if you want to update the subprojects, too.
+
+Problems with submodules
+------------------------
+
+Always publish the submodule change before publishing the change to the
+superproject that references it. If you forget to publish the submodule change,
+others won't be able to clone the repository:
+
+-------------------------------------------------
+$ echo i added another line to this file >> a.txt
+$ git commit -a -m "doing it wrong this time"
+$ cd ..
+$ git add a
+$ git commit -m "Updated submodule a again."
+$ git push
+$ cd ~/git/cloned
+$ git pull
+$ git submodule update
+error: pathspec '261dfac35cb99d380eb966e102c1197139f7fa24' did not match any file(s) known to git.
+Did you forget to 'git add'?
+Unable to checkout '261dfac35cb99d380eb966e102c1197139f7fa24' in submodule path 'a'
+-------------------------------------------------
+
+It's not safe to run `git submodule update` if you've made changes within a
+submodule. They will be silently overwritten:
+
+-------------------------------------------------
+$ cat a.txt
+module a
+$ echo line added from private2 >> a.txt
+$ git commit -a -m "line added inside private2"
+$ cd ..
+$ git submodule update
+Submodule path 'a': checked out 'd266b9873ad50488163457f025db7cdd9683d88b'
+$ cd a
+$ cat a.txt
+module a
+-------------------------------------------------
+
+NOTE: The changes are still visible in the submodule's reflog.
+
[[low-level-operations]]
Low-level git operations
========================
--
1.5.3.1.1.g1e61-dirty
^ permalink raw reply related
* Re: State of Perforce importing.
From: Reece Dunn @ 2007-09-19 18:23 UTC (permalink / raw)
To: Simon Hausmann, Git
In-Reply-To: <20070919171243.GA23902@old.davidb.org>
On 19/09/2007, David Brown <git@davidb.org> wrote:
> On Wed, Sep 19, 2007 at 08:19:11AM +0200, Simon Hausmann wrote:
>
> >> An additional problem:
> >>
> >> - git-p4 doesn't preserve the execute permission bit from Perforce.
> >
> >Hmm, can you paste the output of
> >
> > p4 fstat //path/in/depot/to/file/that/is/imported/incorrectly
> >
> >? I'm interested in the type of the file that p4 reports.
>
> headType kxtext
>
> so the problem is that the git-p4 is only looking for an 'x' at the start.
> According to 'p4 help filetypes', we need to use execute for any of:
>
> cxtext, kxtext, uxbinary, and the others that start with 'x'.
>
> I think it would be sufficient to check the first or second character for
> an 'x'. I'll make a change and give it a try later today.
These are the old file types. If you read the output of `p4 help
filetypes`, the new way of specifying this is with file type
modifiers. Therefore, you also have things like text+x.
- Reece
^ permalink raw reply
* Re: State of Perforce importing.
From: David Brown @ 2007-09-19 18:25 UTC (permalink / raw)
To: Reece Dunn; +Cc: Simon Hausmann, Git
In-Reply-To: <3f4fd2640709191123j64b53878vc96d785c13c3bca2@mail.gmail.com>
On Wed, Sep 19, 2007 at 07:23:41PM +0100, Reece Dunn wrote:
>> I think it would be sufficient to check the first or second character for
>> an 'x'. I'll make a change and give it a try later today.
>
>These are the old file types. If you read the output of `p4 help
>filetypes`, the new way of specifying this is with file type
>modifiers. Therefore, you also have things like text+x.
So my patch I just sent may not be sufficient. Thing is, we set the file
type as 'text+x' and it comes back as xtext, so I'm not sure if P4 ever
gives out text+x or if that is just available as a new way of specifying
them.
David
^ permalink raw reply
* Re: [EGIT PATCH] Change to simplified icon.
From: Robin Rosenberg @ 2007-09-19 18:19 UTC (permalink / raw)
To: Ben Konrath; +Cc: git
In-Reply-To: <20070918222416.GB11990@toast.toronto.redhat.com>
onsdag 19 september 2007 skrev Ben Konrath:
> Hi Robin,
>
> Here's a patch that changes the icon to something that is a little more
> aesthetically pleasing than the one I iniitially submitted. Feel free to
> use the one you like best.
The icon looks very similar to the one in GitWeb. The simplified is, without,
making a bitwise compare, is seems identical to the Git icon. Is that
appropriate? What do the author of that icon, and other Git developers, think?
The plugin. after all, does steal ideas and repository format from Git,
but is in fact a completely separate implementation.
I'll leave this one in my patch tree for now. The Egit icon contest is stil open to all.
-- robin
^ permalink raw reply
* Re: [EGIT PATCH] Remove src dir and entry in build.properties.
From: Robin Rosenberg @ 2007-09-19 18:28 UTC (permalink / raw)
To: Ben Konrath; +Cc: git
In-Reply-To: <20070918222057.GA11990@toast.toronto.redhat.com>
onsdag 19 september 2007 skrev Ben Konrath:
> Hi Robin,
>
> This is just a small clean up patch for the branding plugin.
>
> CHeers, Ben
>
> Signed-off-by: Ben Konrath <bkonrath@redhat.com>
> ---
> org.spearce.egit/build.properties | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
Now why didn't I see that? Thanks.
-- robin
^ 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