Hi!
At $DAYJOB, we have a lot of code flowing from a central repository
to repositories which hold refinitions and ports of the code from the
central repository. Often enough the people working on the porting
repositories find bugs in the code from the central repository, and
want to submit p
On 09/10/2012 11:56 PM, Jeff King wrote:
> On Mon, Sep 10, 2012 at 09:21:12PM +0200, Michael Haggerty wrote:
>
>> I'm renaming this thread so that the bikeshedding can get over ASAP.
>
> Thanks. :)
>
http://tomdoc.org/
Looks much nicer to me than most doxygen I've seen. But ag
Jeff King writes:
> But I would think for that particular use case, you would not want to do
> a per-glob prefix for that, but would rather use a command-line switch.
Yes.
Even though it is not listed as possible future semantics, one thing
that we may want to have before all others is ":(negat
Michael Haggerty writes:
> +`string_list_split`, `string_list_split_in_place`::
> +
> + Split a string into substrings on a delimiter character and
> + append the substrings to a `string_list`. If `maxsplit` is
> + non-negative, then split at most `maxsplit` times. Return the
> +
Michael Haggerty writes:
>> OK. As long as the sort order matches the order string-list
>> internally uses for its bisection search, it won't be a problem,
>> then.
>
> The sorting is crucial but there is no bisection involved. The sorted
> linked-list of references available from the remote an
On 09/10/2012 11:56 PM, Jeff King wrote:
> On Mon, Sep 10, 2012 at 09:21:12PM +0200, Michael Haggerty wrote:
>> My plate is full. If you are able to work on this, it would be awesome.
>> As far as I'm concerned, you are the new literate documentation czar :-)
>
> Lucky me? :)
I was nominating A
On 09/10/2012 11:56 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> diff --git a/string-list.c b/string-list.c
>> index d9810ab..5594b7d 100644
>> --- a/string-list.c
>> +++ b/string-list.c
>> @@ -148,13 +148,23 @@ void print_string_list(const struct string_list *p,
>> const char *text
Michael Haggerty writes:
> diff --git a/string-list.c b/string-list.c
> index 5594b7d..f9051ec 100644
> --- a/string-list.c
> +++ b/string-list.c
> @@ -204,3 +204,52 @@ void unsorted_string_list_delete_item(struct string_list
> *list, int i, int free_
> list->items[i] = list->items[list->n
On 09/09/2012 08:15 PM, Junio C Hamano wrote:
> Jeff King writes:
>
>> On Sun, Sep 09, 2012 at 03:20:18AM -0700, Junio C Hamano wrote:
>>
>>> Michael Haggerty writes:
>>>
This patch series depends on the "Add some string_list-related
functions" series that I just submitted.
>>>
>>> Mak
On Mon, Sep 10, 2012 at 09:21:12PM +0200, Michael Haggerty wrote:
> I'm renaming this thread so that the bikeshedding can get over ASAP.
Thanks. :)
> >>http://tomdoc.org/
> >>
> >> Looks much nicer to me than most doxygen I've seen. But again, it's been
> >> a while, so maybe doxygen is nice
Michael Haggerty writes:
> diff --git a/string-list.c b/string-list.c
> index d9810ab..5594b7d 100644
> --- a/string-list.c
> +++ b/string-list.c
> @@ -148,13 +148,23 @@ void print_string_list(const struct string_list *p,
> const char *text)
> printf("%s:%p\n", p->items[i].string,
On 09/10/2012 10:46 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> Document some bugs in "git fetch-pack":
>>
>> 1. If "git fetch-pack" is called with "--all", "--depth", and an
>> explicit existing non-tag reference to fetch, then it falsely reports
>> that the reference was not found
On Mon, Sep 10, 2012 at 02:38:08PM -0700, Junio C Hamano wrote:
> > Thanks, that helped. I got excited when I saw the "icase" in the
> > comments and thought it might already be implemented. But it looks like
> > it is still to be done. :)
>
> Yeah, some are tongue-in-cheek (e.g. I do not know wh
Jeff King writes:
> On Mon, Sep 10, 2012 at 01:30:03PM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > If the proposal were instead to add a certain type of pathspec that is
>> > case-insensitive[2], that would make much more sense to me. It is not
>> > violating git's case-sensitiv
Signed-off-by: Yacine Belkadi
---
contrib/completion/git-completion.bash |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 222b804..d1f905e 100644
--- a/contrib/completion/git-completion.b
Michael Haggerty writes:
> This patch series depends on the "Add some string_list-related
> functions" series that I just submitted.
>
> This series is a significant rewrite of v2 based on the realization
> that the pair that is passed around in these
> functions is better expressed as a string_
In the demo code blurb, show how to initialize the string_list using
STRING_LIST_INIT_NODUP rather than memset().
Signed-off-by: Michael Haggerty
---
Documentation/technical/api-string-list.txt | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/Documentation/technical/api-stri
Add a function that finds the longest string from a string_list that
is a prefix of a given string.
Signed-off-by: Michael Haggerty
---
Documentation/technical/api-string-list.txt | 8
string-list.c | 20 +++
string-list.h
Add a function that deletes duplicate entries from a sorted
string_list.
Signed-off-by: Michael Haggerty
---
Documentation/technical/api-string-list.txt | 9 +
string-list.c | 17 +
string-list.h | 7 +++
t
On Mon, Sep 10, 2012 at 02:07:02PM -0700, Jeffrey Middleton wrote:
> As you mentioned, parsing "n ... [month]", and even "...n..." (e.g.
> "the 3rd") as the nth day of a month is great, but in this case, I
> think "n ... ago" is a pretty strong sign that that's not the intended
> behavior.
Yeah,
This function allows entries that don't match a specified criterion to
be discarded from a string_list while preserving the order of the
remaining entries.
Signed-off-by: Michael Haggerty
---
Documentation/technical/api-string-list.txt | 11 +++
string-list.c |
Add two new functions, string_list_split() and
string_list_split_in_place(). These split a string into a string_list
on a separator character. The first makes copies of the substrings
(leaving the input string untouched) and the second splits the
original string in place, overwriting the separato
Add a new function that appends a string to a string_list without
copying it. This can be used to pass ownership of an already-copied
string to a string_list that has strdup_strings set.
Signed-off-by: Michael Haggerty
---
Documentation/technical/api-string-list.txt | 17 ++---
stri
Version 2 of a patch series that adds some functions to the
string_list API. This patch series applies to current master. Thanks
for Junio for lots of great feedback.
The patch series "Clean up how fetch_pack() handles the heads list"
v3, which requires some of the new string_list functionality,
Michael Haggerty writes:
> Instead of temporarily storing matched refs to temporary array
> "return_refs", simply append them to newlist as we go. This changes
> the order of references in newlist to strictly sorted if "--all" and
> "--depth" and named references are all specified, but that usag
On Mon, Sep 10, 2012 at 3:57 PM, Junio C Hamano wrote:
> Hrm... They see the contents of the todo file immediately after
> they say "rebase --edit-todo" and the sole reason they said that
> command is because they wanted to edit the todo file. Is it likely
> they need a reminder?
Yes, it's not
As you mentioned, parsing "n ... [month]", and even "...n..." (e.g.
"the 3rd") as the nth day of a month is great, but in this case, I
think "n ... ago" is a pretty strong sign that that's not the intended
behavior.
My first thought was just to make it an error if the string ends in
"ago" but the
Michael Haggerty writes:
> Instead of juggling (sometimes called
> ), pass around the list of references to be sought in
> a single string_list variable called "sought". Future commits will
> make more use of string_list functionality.
>
> Signed-off-by: Michael Haggerty
> ---
The earlier bik
Michael Haggerty writes:
> Document some bugs in "git fetch-pack":
>
> 1. If "git fetch-pack" is called with "--all", "--depth", and an
> explicit existing non-tag reference to fetch, then it falsely reports
> that the reference was not found, even though it was fetched
> correctly.
>
> 2. If "gi
On Mon, Sep 10, 2012 at 01:30:03PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > If the proposal were instead to add a certain type of pathspec that is
> > case-insensitive[2], that would make much more sense to me. It is not
> > violating git's case-sensitivity because it is purely a _
Jeff King writes:
> Hmph. Isn't that what I suggested in my first email? :P
Until I read the current text I did not realize the trailing
paragraph was to apply only to point C (no "--" disambiguates and
throws errors) but somehow thought it was covering both point B
(with "--" you are strict) an
Jeff King writes:
> If the proposal were instead to add a certain type of pathspec that is
> case-insensitive[2], that would make much more sense to me. It is not
> violating git's case-sensitivity because it is purely a _query_ issue.
> And it is a feature you might use whether or not your files
On Thu, Sep 6, 2012 at 9:47 PM, Junio C Hamano wrote:
> "W. Trevor King" writes:
>> On Wed, Sep 05, 2012 at 10:23:54PM -0700, Junio C Hamano wrote:
>>> Really? Would "git log --expand master" be useful?
>>
>> I'm clearly not an expert on this, but isn't that what
>>
>> git show-ref master
>>
>
On Mon, Sep 10, 2012 at 08:27:07PM +0200, Joachim Schmitz wrote:
> > I think it is a mistake to set -std=c89 (or whatever similar option your
> > compiler supports). Like I said, we are not interested in being strictly
> > C89-compliant. We are interested in working on real-world systems.
> >
> >
On Mon, Sep 10, 2012 at 2:28 PM, Johannes Sixt wrote:
> Did you think about what can go wrong? For example, starting with this
> todo sheet:
>
> exec false
> pick 1234567
Ah, that's definitely a problem.
I was going to say we probably just to check the "done" file, same as
the one we do for
Jeff King writes:
> On Mon, Sep 10, 2012 at 01:00:35PM -0700, Junio C Hamano wrote:
>
>> >> And to conclude my bikeshedding for the day: Shouldn't "last" ideally
>> >> be called something like "prev" instead? It's the previously visited
>> >> element, not the last element in the list.
>> >
>> > I
On Mon, Sep 10, 2012 at 12:35:05PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I would argue the opposite; if it is about a specific point, then put it
> > with the point. Otherwise, you are asking the reader to remember back to
> > an earlier point (that they may not even have read;
On Mon, Sep 10, 2012 at 01:00:35PM -0700, Junio C Hamano wrote:
> >> And to conclude my bikeshedding for the day: Shouldn't "last" ideally
> >> be called something like "prev" instead? It's the previously visited
> >> element, not the last element in the list.
> >
> > It is the "last" element visi
Jeff King writes:
> On Mon, Sep 10, 2012 at 03:58:40PM +0200, Erik Faye-Lund wrote:
>
>> >> for (... {
>> >> if (... {
>> >> ...
>> >> }
>> >> last = &p->next;
>> >> }
>> [...]
>> I feel like bikeshedding a bit today!
>>
>> I tend to either prefer either the latte
Andrew Wong writes:
> On Mon, Sep 10, 2012 at 2:46 PM, Jeff King wrote:
>> On Mon, Sep 10, 2012 at 08:36:43PM +0200, Johannes Sixt wrote:
>>
>>> > [1] It does preclude using "--edit" to make a note about a later commit
>>> > while you are in the middle of resolving a conflict or something.
>
People who are not used to working with shell may intellectually
understand how the command line argument is massaged by the shell
but still have a hard time visualizing the difference between
letting the shell expand fileglobs and having Git see the fileglob
to use as a pathspec.
Signed-off-by: J
The paragraph to encourage use of "--" in scripts belongs to the
bullet point that describes the behaviour for a command line without
the explicit "--" disambiguation, not a supporting explanation for
the entire bulletted list.
Signed-off-by: Junio C Hamano
---
Documentation/gitcli.txt | 2 +-
1
Jeff King writes:
> I would argue the opposite; if it is about a specific point, then put it
> with the point. Otherwise, you are asking the reader to remember back to
> an earlier point (that they may not even have read; in reference
> documentation, the point of a list is often to let readers s
On Mon, Sep 10, 2012 at 2:46 PM, Jeff King wrote:
> On Mon, Sep 10, 2012 at 08:36:43PM +0200, Johannes Sixt wrote:
>
>> > [1] It does preclude using "--edit" to make a note about a later commit
>> > while you are in the middle of resolving a conflict or something.
>> > You'd have to do it
I'm renaming this thread so that the bikeshedding can get over ASAP.
On 09/10/2012 07:48 PM, Andreas Ericsson wrote:
> On 09/10/2012 06:33 PM, Jeff King wrote:
>> On Mon, Sep 10, 2012 at 09:24:17AM -0700, Junio C Hamano wrote:
>>> Michael Haggerty writes:
Also, better documentation in header
On Mon, Sep 10, 2012 at 08:36:43PM +0200, Johannes Sixt wrote:
> > [1] It does preclude using "--edit" to make a note about a later commit
> > while you are in the middle of resolving a conflict or something.
> > You'd have to do it at the end. I don't know if anybody actually
> > care
Am 10.09.2012 18:54, schrieb Jeff King:
> On Mon, Sep 10, 2012 at 12:46:45PM -0400, Andrew Wong wrote:
>
>>> Just "edit" may be a bit misleading, as we already have the "edit"
>>> action inside the todolist. I'd call this --edit-list to avoid
>>> ambiguity.
>>
>> I thought that might be a bit conf
Am 10.09.2012 18:14, schrieb Andrew Wong:
> Occasionally, while I'm in the middle of an interactive rebase, I'd change my
> mind about the todo list and want to modify it. This means manually digging
> out the todo file from the rebase directory, and invoking the editor. So I
> thought it might b
> From: Jeff King [mailto:p...@peff.net]
> Sent: Monday, September 10, 2012 7:59 PM
> To: Joachim Schmitz
> Cc: git@vger.kernel.org
> Subject: Re: [PATCH] daemon: restore getpeername(0,...) use
>
> On Mon, Sep 10, 2012 at 07:26:26PM +0200, Joachim Schmitz wrote:
>
> > >>as are non-const array int
On Mon, Sep 10, 2012 at 07:26:26PM +0200, Joachim Schmitz wrote:
> >>as are non-const array intializers, e.g.:
> >>
> >> const char *args[] = { editor, path, NULL };
> >> ^
> >>".../git/editor.c", line 39: error(122): expression must have
On 09/10/2012 06:33 PM, Jeff King wrote:
> On Mon, Sep 10, 2012 at 09:24:17AM -0700, Junio C Hamano wrote:
>
>>> While we're on the subject, it seems to me that documenting APIs like
>>> these in separate files under Documentation/technical rather than in the
>>> header files themselves
>>>
>>> -
and you earned bonus points for the details - thank you very much!
On Mon, Sep 10, 2012 at 10:37 AM, Junio C Hamano wrote:
> Joseph Leong writes:
>
>> Hi Everyone,
>>
>> I'm using Gitweb (Based on Git 1.7.9 on RHEL 5.8).
>>
>> I was poking around and tried a GET Request (REQ) with some SQL
>> s
Joseph Leong writes:
> Hi Everyone,
>
> I'm using Gitweb (Based on Git 1.7.9 on RHEL 5.8).
>
> I was poking around and tried a GET Request (REQ) with some SQL
> statements as a search query and noticed a 500. Can i just confirm
> with anyone here that the error message I'm seeing in the Response
Jeff King wrote:
On Mon, Sep 10, 2012 at 04:38:58PM +0200, Joachim Schmitz wrote:
More importantly, though, is it actually portable? I thought it was
added in C99, and we try to stick to C89 to support older compilers
and systems. My copy of C99 is vague (it says only that the "bool"
macro was
On Mon, Sep 10, 2012 at 10:09:43AM -0700, Junio C Hamano wrote:
> > Does it make sense to join that final paragraph into what is now the
> > third bullet, and then add your new text (the fourth bullet) after?
>
> I am not sure. After re-reading it, I do not think the fileglob
> discussion belong
Joseph Leong writes:
> [RESP]
> 500 - Internal Server Error
> Unmatched ( in regex; marked by <-- HERE in m/( <-- HERE select
> 1234,/ at /var/www/git/gitweb.cgi line 4845.
Gitweb is feeding your input as a perl regex, which is not really clean
but shouldn't really harm either.
I could reproduc
Jeff King writes:
>> When writing a script that is expected to handle random user-input, it is
>> a good practice to make it explicit which arguments are which by placing
>> disambiguating `--` at appropriate places.
>
> Look at the paragraph below your addition. It is typographically outside
OK, thanks. I'll check with the guy who set up the server.
Rob
On 9/10/12 12:26 PM, Matthieu Moy wrote:
Rob Marshall writes:
If I do a 'git repack' it works fine, so are these
messages coming from the remote server?
I guess so, and your remote server has a restricted environment (chroot
or
On Mon, Sep 10, 2012 at 12:46:45PM -0400, Andrew Wong wrote:
> > Just "edit" may be a bit misleading, as we already have the "edit"
> > action inside the todolist. I'd call this --edit-list to avoid
> > ambiguity.
>
> I thought that might be a bit confusing too. "--edit-list" doesn't
> seem infor
On Mon, Sep 10, 2012 at 12:25 PM, Matthieu Moy
wrote:
> Indent with space. Please, use tabs (same below).
Ah, thanks. Good catch.
> Just "edit" may be a bit misleading, as we already have the "edit"
> action inside the todolist. I'd call this --edit-list to avoid
> ambiguity.
I thought that mig
Hi Everyone,
I'm using Gitweb (Based on Git 1.7.9 on RHEL 5.8).
I was poking around and tried a GET Request (REQ) with some SQL
statements as a search query and noticed a 500. Can i just confirm
with anyone here that the error message I'm seeing in the Response
(RESP) is basically saying that the
Am 09.09.2012 23:58, schrieb Marcus Karlsson:
Make git-grep optionally omit the parts of the line before and after the
match.
Signed-off-by: Marcus Karlsson
---
Documentation/git-grep.txt | 8 +++-
builtin/grep.c | 2 ++
grep.c | 7 +--
grep.h
On Mon, Sep 10, 2012 at 09:24:17AM -0700, Junio C Hamano wrote:
> > While we're on the subject, it seems to me that documenting APIs like
> > these in separate files under Documentation/technical rather than in the
> > header files themselves
> >
> > - makes the documentation for a particular func
Adam Spiers writes:
Administrivia. Please never deflect direct responses to you with
"Mail-Followup-To" header. I told my mailer to "follow-up" so that I
could give you advice in response, while adding others in the
discussion to Cc so that they do not have to repeat what I said, but
your "Mail
On Sat, Sep 08, 2012 at 04:10:59PM +0200, Robin Stocker wrote:
> > > Maybe the solution is to detect if the original commit message
> > > ends with a trailer and in that case keep the existing behavior
> > > of not inserting a blank line?
> >
> > Yeah, that sounds like a good change from "this ma
Rob Marshall writes:
> If I do a 'git repack' it works fine, so are these
> messages coming from the remote server?
I guess so, and your remote server has a restricted environment (chroot
or so) with very few commands allowed, which prevents shell-scripts from
executing properly.
--
Matthieu M
Andrew Wong writes:
> This allows users to edit the todo list while they're in the middle of
> an interactive rebase.
I like the idea.
> +edit)
> + git_sequence_editor "$todo" ||
> +die_abort "Could not execute editor"
> +
> + exit
> + ;;
Indent with space. Please, use tabs (same below)
Michael Haggerty writes:
> Another idea: in string-list.h, one could name parameters "sorted_list"
> when they must be sorted as a precondition of the function.
That sounds like a very sensible thing to do.
> But before getting too hung up on finery, the effort might be better
> invested adding
Hi,
Whenever I do a git push origin of a new branch I see:
Auto packing the repository for optimum performance.
/usr/local/libexec/git-core/git-sh-setup: line 241: uname: command not found
/usr/local/libexec/git-core/git-repack: line 56: rm: command not found
/usr/local/libexec/git-core/git-repa
Yann Dirson writes:
> Hm. But then, git rev-parse $(git rev-parse :/Merge}^0 does work, a trivial
> patch would appear to make things better.
That, if done unconditionally, smells like a bad hack that wastes an
extra fork for a corner case that appears only very rarely.
I guess something like
On Fri, Sep 07, 2012 at 01:49:15PM -0700, Junio C Hamano wrote:
> -- >8 --
> gitcli: contrast wildcard given to shell and to git
>
> People who are not used to working with shell may intellectually
> understand how the command line argument is massaged by the shell
> but still have a hard time vi
This allows users to edit the todo list while they're in the middle of
an interactive rebase.
Signed-off-by: Andrew Wong
---
git-rebase--interactive.sh | 6 ++
git-rebase.sh | 14 ++
2 files changed, 20 insertions(+)
diff --git a/git-rebase--interactive.sh b/git-re
Occasionally, while I'm in the middle of an interactive rebase, I'd change my
mind about the todo list and want to modify it. This means manually digging
out the todo file from the rebase directory, and invoking the editor. So I
thought it might be convenient to have an "edit" action that simply
On Sun, Sep 09, 2012 at 12:24:58PM -0700, Junio C Hamano wrote:
> Having said all that, I am not sure if the "fixing" is really the
> right approach to begin with. Contrast these two:
>
> $ git blame MakeFILE
> $ git blame HEAD -- MakeFILE
>
> The latter, regardless of core.ignorecase,
Michael Haggerty writes:
> OK, so the bottom line would be to have two versions of the function.
> One takes a (const char *) and *requires* strdup_strings to be set on
> its input list:
>
> int string_list_split(struct string_list *list, const char *string,
> int delim, int m
On Mon, Sep 10, 2012 at 04:38:58PM +0200, Joachim Schmitz wrote:
> >More importantly, though, is it actually portable? I thought it was
> >added in C99, and we try to stick to C89 to support older compilers
> >and systems. My copy of C99 is vague (it says only that the "bool"
> >macro was added vi
Jeff King wrote:
On Sat, Sep 08, 2012 at 09:20:48PM +0200, Jan Engelhardt wrote:
On Saturday 2012-09-08 20:59, Junio C Hamano wrote:
diff --git a/daemon.c b/daemon.c
index 4602b46..eaf08c2 100644
--- a/daemon.c
+++ b/daemon.c
@@ -1,3 +1,4 @@
+#include
#include "cache.h"
#include "pkt-line.h
On Sat, Sep 08, 2012 at 09:20:48PM +0200, Jan Engelhardt wrote:
> On Saturday 2012-09-08 20:59, Junio C Hamano wrote:
> >> diff --git a/daemon.c b/daemon.c
> >> index 4602b46..eaf08c2 100644
> >> --- a/daemon.c
> >> +++ b/daemon.c
> >> @@ -1,3 +1,4 @@
> >> +#include
> >> #include "cache.h"
> >>
On Mon, Sep 10, 2012 at 03:58:40PM +0200, Erik Faye-Lund wrote:
> >> for (... {
> >> if (... {
> >> ...
> >> }
> >> last = &p->next;
> >> }
> [...]
> I feel like bikeshedding a bit today!
>
> I tend to either prefer either the latter or something like this:
>
> wh
On Sat, Sep 08, 2012 at 09:40:39PM -0700, Junio C Hamano wrote:
> The built-in "binary" attribute macro expands to "-diff -text", so
> that textual diff is not produced, and the contents will not go
> through any CR/LF conversion ever. During a merge, it should also
> choose the "binary" low-leve
On Mon, Sep 10, 2012 at 3:44 PM, Jeff King wrote:
> On Sun, Sep 09, 2012 at 03:44:54PM +0100, David Gould wrote:
>> You want something like:
>>
>> for (... {
>> if (... {
>> ...
>> }
>> last = &p->next;
>> }
>>
>> or (probably clearer, but I haven't read your coding
On Sun, Sep 09, 2012 at 03:44:54PM +0100, David Gould wrote:
> static void clear_child_for_cleanup(pid_t pid)
> {
> struct child_to_clean **last, *p;
>
> last = &children_to_clean;
> for (p = children_to_clean; p; p = p->next) {
> if (p->pid == pid) {
>
Just to close the loop on this thread, it did turn out to be a
permission problem in our case. It was difficult to track down because
it was only a problem on one server in the cluster. Each server had a
system git config file at /usr/local/etc/gitconfig. This was a symlink
pointing to a single com
On Mon, Sep 10, 2012 at 6:09 PM, Adam Spiers wrote:
>> > fprintf(stderr, "%s\n", dir->ignored[i]->name);
>> > - fprintf(stderr, _("Use -f if you really want to add
>> > them.\n"));
>> > + fprintf(stderr, _("Use -f if you really want to add them,
gits...@pobox.com wrote on Sun, 09 Sep 2012 17:35 -0700:
> Pete Wyckoff writes:
>
> > Option "--silent", "--quiet" or "-s" to make prevents
> > echoing of commands as they are executed. However, there
> > are some explicit "echo" commands in the Makefile and in
> > the two GIT-VERSION-GEN script
Looks fine to me. Thanks!
Michael
On 09/09/2012 05:42 PM, Johannes Sixt wrote:
> Only the first half of the test works only on POSIX, the second half
> passes on Windows as well.
>
> A later test "real path removes other extra slashes" looks very similar,
> but it does not make sense to split i
On 09/10/2012 07:47 AM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> ... Consider something like
>>
>> struct string_list *split_file_into_words(FILE *f)
>> {
>> char buf[1024];
>> struct string_list *list = new string list;
>> list->strdup_strings = 1;
>
On Wed, Sep 05, 2012 at 05:25:25PM +0700, Nguyen Thai Ngoc Duy wrote:
> On Wed, Sep 5, 2012 at 12:26 AM, Junio C Hamano wrote:
> > Nguyen Thai Ngoc Duy writes:
> >
> >>> +static void output_exclude(const char *path, struct exclude *exclude)
> >>> +{
> >>> + char *type = exclude->to_exclude
On Tue, Sep 04, 2012 at 08:06:12PM +0700, Nguyen Thai Ngoc Duy wrote:
> On Sun, Sep 2, 2012 at 7:12 AM, Adam Spiers wrote:
> > --- a/builtin/add.c
> > +++ b/builtin/add.c
> > @@ -273,7 +273,7 @@ static int add_files(struct dir_struct *dir, int flags)
> > fprintf(stderr, _(ignore_er
On 09/09/2012 11:54 AM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> [...]
>> diff --git a/Documentation/technical/api-string-list.txt
>> b/Documentation/technical/api-string-list.txt
>> index 9206f8f..291ac4c 100644
>> --- a/Documentation/technical/api-string-list.txt
>> +++ b/Document
On 09/09/2012 11:45 AM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> Signed-off-by: Michael Haggerty
>> ---
>> Documentation/technical/api-string-list.txt | 4
>> string-list.c | 17 +
>> string-list.h |
On 09/09/2012 11:40 AM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> Signed-off-by: Michael Haggerty
>> ---
>> Documentation/technical/api-string-list.txt | 8
>> string-list.c | 17 +
>> string-list.h
Yann Dirson wrote:
On Fri, 07 Sep 2012 15:54:49 +0200
...
BTW, git-rebase.sh seems to be quite inconsistent on the use of $()
vs. ``, not to mention the clear preference stated in
CodingGuidelines.
There are still quite a few more places in *.sh where `cmd`is used instead
of $(cmd):
check-
On Fri, 07 Sep 2012 15:54:49 +0200
Andreas Schwab wrote:
> Yann Dirson writes:
>
> > In 1.7.10.3, "git rebase -i :/Merge" will complain with:
> >
> > fatal: Needed a single revision
> > invalid upstream :/Merge
> >
> > ... whereas "git rev-parse :/Merge" has no problem resolving
> > to a single
94 matches
Mail list logo
