* Re: [PATCH 0/7] New sequencer workflow!
From: Ramkumar Ramachandra @ 2011-11-15 8:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List, Jonathan Nieder
In-Reply-To: <7vaa7zmuwt.fsf@alter.siamese.dyndns.org>
Hi Junio,
Thanks for the fantastic review. My lack of foresight is very disturbing.
Junio C Hamano wrote:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>> This series preserves the old workflow:
>> [...]
> Hmm, doesn't "git add && git cherry-pick --continue" (i.e. no "git commit"
> in between) trigger the "commit the resolution first and then go on"?
Ugh, right. I can't possibly preserve the old workflow fully- what I
meant is that users can still "git commit" before continuing (in the
case of a multi-commit operation). It's not so much about preserving
a workflow, as it is about not breaking existing tests.
> Almost. If these are replaced with "git cherry-pick --continue" and "git
> revert --continue" that internally triggers "git sequencer --continue"
> *and* errors out if a wrong command was used to "--continue", it would be
> perfect.
Okay, there are two ways to fix this:
1. If the first instruction in the instruction sheet is a "revert" and
"git cherry-pick --continue" is called or viceversa, error out. The
downside is that there's really no sane way to handle mixed "pick" and
"revert" instructions in the sheet using this approach: parsing the
whole sheet in advance is a total overkill.
2. The key issue is that the sequencer doesn't keep track of which
command was actually executed (argv[0]): fix this by creating a new
'.git/sequencer/cmd' to keep this information.
I think we should pick the latter option. Also, why should "git
<cherry-pick|revert> --continue" invoke "git sequencer --continue"
when it can just call into the corresponding function in the sequencer
library (isn't lib'ification one of the issues we're trying to
address)?
> While I do not mind "sequencer --continue" as a step to get us closer to a
> more pleasant user experience at the implementation level, exposing the
> name "sequencer" or having the user to type "sequencer --continue" is going
> in a very wrong direction at the UI level.
> [...]
> Now, if you rename "cherry-pick --continue" and "revert --continue" to
> "sequencer --continue", what message are you sending to the users? They
> now need to learn that only these two commands are based on something
> called "sequencer", can be resumed with "sequencer --continue", but other
> commands need to be continued with "X --continue".
Thanks for the superb explanation- it's plain as day now. In a
nutshell: it makes little sense to have a grand plan about an
all-encompassing "git sequencer --continue"; even if that is the plan
in the super-long term (although "git continue" is a better idea), it
makes no sense to burden the user now with additional UI
inconsistencies.
I'm still a little confused about what to do with the "git sequencer"
builtin though: how do we prevent users from being confused by it- by
not advertising it?
> The original workflow was "pull; edit && add && commit", and it is very
> unlikely this will change while we are still in Git 1.X series. The
> original single commit variants of "cherry-pick" and "revert" are in the
> same category. We would need to keep supporting "cherry-pick/revert; edit
> && add && commit" as a workflow for a while.
True. I wrote this pretending that only "git <cherry-pick|revert>"
was stuck with this UI inconsistency between one-commit picks and
many-commit picks.
> In the shorter term, a person new to Git, after learning "run command X, X
> gives back control asking for help, help X by editing and adding, and
> telling X to continue" pattern from these commands, will eventually find
> that the commands in single stop-point category (i.e. "pull", "merge" and
> single-commit "cherry-pick" and "revert") inconsistent from others that
> take "--continue" to resume. For this reason, "git cherry-pick --continue"
> that would work even when picking a single commit like this would be
> beneficial:
> [...]
Interesting aside: this final detail is fixed only in the last patch
in the series; that's how deep the problem is.
> In the longer term (now we are talking about Git 2.X version bump), it
> would be ideal if all the "git X --continue" can be consolidated to a
> single "git continue" command (and "git abort" to give up the sequence
> of operations).
>
> Given that bash-completion script can tell in what state the repository
> is, I think this is doable. "git continue" may invoke your implementation
> of "git sequencer --continue" internally when it detects that the state is
> something the "sequencer" machinery knows how to continue, and if it is in
> the middle of conflicted "am -3" or rejected "am", the command may invoke
> "git am --continue" instead.
Makes perfect sense.
Thanks.
-- Ram
^ permalink raw reply
* Re: [PATCH 3/7] sequencer: handle single-commit pick as special case
From: Ramkumar Ramachandra @ 2011-11-15 8:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List, Jonathan Nieder
In-Reply-To: <7vpqgvmwtl.fsf@alter.siamese.dyndns.org>
Hi Junio,
Junio C Hamano writes:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>> [...]
> [...]
> I do not see an inconsistency here, let alone any "glaring" one.
Yeah, my commit message is totally misleading and unclear. Yes, all
the operations make sense to you and me; for a new user who doesn't
understand how Git works, it's completely inconsistent at a very
superficial level, no? The sequence of operations he has to execute
depends on:
1. If he literally specified a single commit or a commit range on the
command-line.
2. In the case of multi-commit picking, there's an additional layer of
decision making: did the conflict occur in the last commit in the
range?
Anyway, I'll rewrite this commit message in the next iteration.
Thanks.
-- Ram
^ permalink raw reply
* Re: [PATCH 1/5] sequencer: factor code out of revert builtin
From: Ramkumar Ramachandra @ 2011-11-15 9:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, Git List
In-Reply-To: <7vvcqnmxeu.fsf@alter.siamese.dyndns.org>
Hi Junio,
Junio C Hamano writes:
> [...]
> With that observation, it would probably make more sense if "foo.c"
> included the headers in the following order:
>
> - git-compat-util.h (or the prominent ones like "cache.h" that is known
> to include it at the beginning);
> - Anything the declarations in "foo.h" depends on;
> - "foo.h" itself; and finally
> - Other headers that "foo.c" implementation needs.
>
> That way, people who want to use "foo.h" can guess what needs to be
> included before using "foo.h" a lot more easily.
That's a good rule-of-thumb. Thanks :)
-- Ram
^ permalink raw reply
* Re: [PATCH 3/5] sequencer: sequencer state is useless without todo
From: Ramkumar Ramachandra @ 2011-11-15 9:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, Git List
In-Reply-To: <7v7h33oifq.fsf@alter.siamese.dyndns.org>
Hi,
Junio C Hamano wrote:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>>>> static int create_seq_dir(void)
>>>> {
>>>> + const char *todo_file = git_path(SEQ_TODO_FILE);
>>>> const char *seq_dir = git_path(SEQ_DIR);
>>>
>>> Scary idiom.
>>
>> What's scary about it?
>
> The next person who copies and pastes this code to other codepaths without
> thinking that the return value of git_path() is ephemeral and may need to
> be saved away depending on what goes between its assignment and its use.
Yeah, git_path() writes to one of the four static buffers in
path.c:get_pathname(). Which brings me to: what should (can) we do
about it? Explicitly xmalloc()'ing and free()'ing a tiny path buffer
is an overkill, so I'm thinking more on the lines of good
documentation. I've been guilty of misusing git_path() blindly in the
past myself.
Thanks.
-- Ram
^ permalink raw reply
* Re: [PATCH 1/5] sequencer: factor code out of revert builtin
From: Miles Bader @ 2011-11-15 9:18 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Junio C Hamano, Jonathan Nieder, Git List
In-Reply-To: <CALkWK0mtmRYyFosQNJixhheUmHpRjWc4A5zPQ6AaBfmw4H4eLQ@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Junio C Hamano writes:
>> [...]
>> With that observation, it would probably make more sense if "foo.c"
>> included the headers in the following order:
>>
>> - Anything the declarations in "foo.h" depends on;
>> - "foo.h" itself; and finally
>> - Other headers that "foo.c" implementation needs.
>>
>> That way, people who want to use "foo.h" can guess what needs to be
>> included before using "foo.h" a lot more easily.
>
> That's a good rule-of-thumb. Thanks :)
Does git not use the common practice of self-contained headers?
-miles
--
Fast, small, soon; pick any 2.
^ permalink raw reply
* [PATCH] revert: prettify fatal messages
From: Ramkumar Ramachandra @ 2011-11-15 9:31 UTC (permalink / raw)
To: Git List; +Cc: Junio C Hamano, Jonathan Nieder
Some of the fatal messages printed by revert and cherry-pick look ugly
like the following:
fatal: Could not open .git/sequencer/todo.: No such file or directory
The culprit here is the die_errno() function that takes a custom error
message string as an argument and appends ": <message from errno>"
before printing it. So, we can fix the problem by not terminating the
string argument to the function with a '.' (period). Fatal messages
look nicer now:
fatal: Could not open .git/sequencer/todo: No such file or directory
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
Candidate for 'maint'?
builtin/revert.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/builtin/revert.c b/builtin/revert.c
index 87df70e..e0319c8 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -331,7 +331,7 @@ static void write_message(struct strbuf *msgbuf, const char *filename)
int msg_fd = hold_lock_file_for_update(&msg_file, filename,
LOCK_DIE_ON_ERROR);
if (write_in_full(msg_fd, msgbuf->buf, msgbuf->len) < 0)
- die_errno(_("Could not write to %s."), filename);
+ die_errno(_("Could not write to %s"), filename);
strbuf_release(msgbuf);
if (commit_lock_file(&msg_file) < 0)
die(_("Error wrapping up %s"), filename);
@@ -767,7 +767,7 @@ static void read_populate_todo(struct commit_list **todo_list,
fd = open(todo_file, O_RDONLY);
if (fd < 0)
- die_errno(_("Could not open %s."), todo_file);
+ die_errno(_("Could not open %s"), todo_file);
if (strbuf_read(&buf, fd, 0) < 0) {
close(fd);
strbuf_release(&buf);
@@ -845,7 +845,7 @@ static int create_seq_dir(void)
if (file_exists(seq_dir))
return error(_("%s already exists."), seq_dir);
else if (mkdir(seq_dir, 0777) < 0)
- die_errno(_("Could not create sequencer directory '%s'."), seq_dir);
+ die_errno(_("Could not create sequencer directory %s"), seq_dir);
return 0;
}
@@ -859,7 +859,7 @@ static void save_head(const char *head)
fd = hold_lock_file_for_update(&head_lock, head_file, LOCK_DIE_ON_ERROR);
strbuf_addf(&buf, "%s\n", head);
if (write_in_full(fd, buf.buf, buf.len) < 0)
- die_errno(_("Could not write to %s."), head_file);
+ die_errno(_("Could not write to %s"), head_file);
if (commit_lock_file(&head_lock) < 0)
die(_("Error wrapping up %s."), head_file);
}
@@ -876,7 +876,7 @@ static void save_todo(struct commit_list *todo_list, struct replay_opts *opts)
die(_("Could not format %s."), todo_file);
if (write_in_full(fd, buf.buf, buf.len) < 0) {
strbuf_release(&buf);
- die_errno(_("Could not write to %s."), todo_file);
+ die_errno(_("Could not write to %s"), todo_file);
}
if (commit_lock_file(&todo_lock) < 0) {
strbuf_release(&buf);
--
1.7.6.351.gb35ac.dirty
^ permalink raw reply related
* Re: [PATCH 1/5] sequencer: factor code out of revert builtin
From: Jonathan Nieder @ 2011-11-15 9:47 UTC (permalink / raw)
To: Miles Bader; +Cc: Ramkumar Ramachandra, Junio C Hamano, Git List
In-Reply-To: <buo4ny5u4k6.fsf@dhlpc061.dev.necel.com>
Miles Bader wrote:
> Does git not use the common practice of self-contained headers?
It usually does, with two exceptions.
Headers do not usually include git-compat-util.h directly, which is a
good thing, since it reminds callers to include git-compat-util.h
before anything else.
Headers might sometimes forget to declare types defined in cache.h,
which would be a mistake. For example, in branch.h we see:
int validate_new_branchname(const char *name, struct strbuf *ref, int force, int attr_only);
Which means the following code does not type-check:
#include "git-compat-util.h"
#include "branch.h"
#include "strbuf.h"
int demo(const char *name, struct strbuf *ref)
{
return validate_new_branchname(name, ref, 0, 0);
}
Reordering the #includes to put strbuf.h before branch.h is a possible
workaround. Adding the missing forward declaration is better:
diff --git i/branch.h w/branch.h
index 1285158d..d5240a20 100644
--- i/branch.h
+++ w/branch.h
@@ -1,6 +1,9 @@
#ifndef BRANCH_H
#define BRANCH_H
+struct strbuf;
+enum branch_track;
+
/* Functions for acting on the information about branches. */
/*
--
^ permalink raw reply related
* Re: [PATCH 3/5] sequencer: sequencer state is useless without todo
From: Jonathan Nieder @ 2011-11-15 9:52 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Junio C Hamano, Git List
In-Reply-To: <CALkWK0nUuzn2_itdACHLQBpUaVv97tFAjNGdVBEhWC7a6Rp75w@mail.gmail.com>
Ramkumar Ramachandra wrote:
> Yeah, git_path() writes to one of the four static buffers in
> path.c:get_pathname(). Which brings me to: what should (can) we do
> about it?
Just use a sane idiom. Which means: as few git_path() values in
flight at a time as possible.
In other words, do not save the git_path() result in a variable, but
pass it directly to whatever computation needs to use it.
^ permalink raw reply
* Re: [PATCH] revert: prettify fatal messages
From: Matthieu Moy @ 2011-11-15 10:04 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List, Junio C Hamano, Jonathan Nieder
In-Reply-To: <1321349492-5653-1-git-send-email-artagnon@gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Some of the fatal messages printed by revert and cherry-pick look ugly
> like the following:
>
> fatal: Could not open .git/sequencer/todo.: No such file or directory
>
> The culprit here is the die_errno() function that takes a custom error
> message string as an argument and appends ": <message from errno>"
> before printing it. So, we can fix the problem by not terminating the
> string argument to the function with a '.' (period). Fatal messages
> look nicer now:
>
> fatal: Could not open .git/sequencer/todo: No such file or directory
Sounds (obviously) good.
(I just misread the subject line at first, and understood that this was
a revert of an earlier commit, while this is actually a commit touching
the "revert" part of Git)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH v4 3/3] upload-archive: use start_command instead of fork
From: Thomas Rast @ 2011-11-15 10:22 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, gitster, j6t, peff, rene.scharfe
In-Reply-To: <1319472131-3968-4-git-send-email-kusmabite@gmail.com>
Erik Faye-Lund wrote:
> The POSIX-function fork is not supported on Windows. Use our
> start_command API instead.
>
> As this is the last call-site that depends on the fork-stub in
> compat/mingw.h, remove that as well.
>
> Add an undocumented flag to git-archive that tells it that the
> action originated from a remote, so features can be disabled.
> Thanks to Jeff King for work on this part.
>
> Remove the NOT_MINGW-prereq for t5000, as git-archive --remote
> now works.
I see valgrind failures bisecting to this commit, like so:
==19125== Syscall param execve(argv[i]) points to unaddressable byte(s)
==19125== at 0x5303CB7: execve (in /lib64/libc-2.11.3.so)
==19125== by 0x53045A5: execvpe (in /lib64/libc-2.11.3.so)
==19125== by 0x4B183C: execv_git_cmd (exec_cmd.c:137)
==19125== by 0x4F305E: start_command (run-command.c:277)
==19125== by 0x47F5C9: cmd_upload_archive (upload-archive.c:98)
==19125== by 0x4051F4: run_builtin (git.c:308)
==19125== by 0x40538F: handle_internal_command (git.c:466)
==19125== by 0x405556: main (git.c:553)
==19125== Address 0x7feffe7d0 is not stack'd, malloc'd or (recently) free'd
when running 'make valgrind' in current master. Let me know if you
need more information.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH v4 3/3] upload-archive: use start_command instead of fork
From: Jeff King @ 2011-11-15 10:28 UTC (permalink / raw)
To: Thomas Rast; +Cc: Erik Faye-Lund, git, gitster, j6t, rene.scharfe
In-Reply-To: <201111151122.48378.trast@student.ethz.ch>
On Tue, Nov 15, 2011 at 11:22:48AM +0100, Thomas Rast wrote:
> > Remove the NOT_MINGW-prereq for t5000, as git-archive --remote
> > now works.
>
> I see valgrind failures bisecting to this commit, like so:
>
> ==19125== Syscall param execve(argv[i]) points to unaddressable byte(s)
> ==19125== at 0x5303CB7: execve (in /lib64/libc-2.11.3.so)
> ==19125== by 0x53045A5: execvpe (in /lib64/libc-2.11.3.so)
> ==19125== by 0x4B183C: execv_git_cmd (exec_cmd.c:137)
> ==19125== by 0x4F305E: start_command (run-command.c:277)
> ==19125== by 0x47F5C9: cmd_upload_archive (upload-archive.c:98)
> ==19125== by 0x4051F4: run_builtin (git.c:308)
> ==19125== by 0x40538F: handle_internal_command (git.c:466)
> ==19125== by 0x405556: main (git.c:553)
> ==19125== Address 0x7feffe7d0 is not stack'd, malloc'd or (recently) free'd
>
> when running 'make valgrind' in current master. Let me know if you
> need more information.
With which test, and on what OS? I couldn't replicate running
t5000 on Linux.
-Peff
^ permalink raw reply
* Git, Parrot, Perl6, Rakudo for G4 MAC
From: Greg @ 2011-11-15 10:36 UTC (permalink / raw)
To: git
Howdy:
Could someone please assist me in locating the resources to "GIT"
this stuff going on a G4 MAC PPC? I
keep getting weird bugs.
Need me to be more explicit? Ok - it says gcc v3.3 isn't compatible, and a
bunch of other sheet!
I'd like to start messing with this while I'm waiting for my Debian
Linux box to be returned. (A friend
borrowed it to do some work:
He installed a horribly virulent bug called WInBlows XP!!!!)
I already have Perl5.10.1 working fine, and performing
numerous marvelous tasks, so I (perhaps
mistakenly) thought it would be an easy addition.
Cheers,
Greg
^ permalink raw reply
* Re: [PATCH v4 3/3] upload-archive: use start_command instead of fork
From: Thomas Rast @ 2011-11-15 12:11 UTC (permalink / raw)
To: Jeff King, Franck Bui-Huu; +Cc: Erik Faye-Lund, git, gitster, j6t, rene.scharfe
In-Reply-To: <20111115102807.GA18649@sigill.intra.peff.net>
Jeff King wrote:
> On Tue, Nov 15, 2011 at 11:22:48AM +0100, Thomas Rast wrote:
> >
> > I see valgrind failures bisecting to this commit, like so:
> >
> > ==19125== Syscall param execve(argv[i]) points to unaddressable byte(s)
> > ==19125== at 0x5303CB7: execve (in /lib64/libc-2.11.3.so)
> > ==19125== by 0x53045A5: execvpe (in /lib64/libc-2.11.3.so)
> > ==19125== by 0x4B183C: execv_git_cmd (exec_cmd.c:137)
> > ==19125== by 0x4F305E: start_command (run-command.c:277)
> > ==19125== by 0x47F5C9: cmd_upload_archive (upload-archive.c:98)
> > ==19125== by 0x4051F4: run_builtin (git.c:308)
> > ==19125== by 0x40538F: handle_internal_command (git.c:466)
> > ==19125== by 0x405556: main (git.c:553)
> > ==19125== Address 0x7feffe7d0 is not stack'd, malloc'd or (recently) free'd
> >
> > when running 'make valgrind' in current master. Let me know if you
> > need more information.
>
> With which test, and on what OS? I couldn't replicate running
> t5000 on Linux.
11, and many others after it, on a pretty vanilla opensuse 11.4 VM I
use almost exclusively for the valgrind runs. I used a pre-3.7 SVN
valgrind build, but 3.6.1 (shipped with opensuse) finds the same.
But after a closer look I think this patch just prodded it enough to
unearth long-existing undefined behaviour: prepare_argv() summarizes
to something like
static void prepare_argv(const char **sent_argv, const char **argv)
{
char *p, buf[4096];
for (p = buf;;) {
len = packet_read_line(0, p, (buf + sizeof buf) - p);
/* ... p always points into buf ... */
sent_argv[sent_argc++] = p;
p += len;
*p++ = 0;
}
sent_argv[sent_argc] = NULL;
}
The code appears to have looked like this ever since the addition of
that file back in 39345a2 (Add git-upload-archive, 2006-09-07). So
the elements of sent_argv have apparently always pointed into the
stack-allocated 'buf'.
(This correlates with the "Address 0x7feffe7d0 is not stack'd", even
though it's pretty clearly an address into the stack.)
A quick band-aid would be to heap-allocate it instead:
diff --git i/builtin/upload-archive.c w/builtin/upload-archive.c
index c57e8bd..6ab50d3 100644
--- i/builtin/upload-archive.c
+++ w/builtin/upload-archive.c
@@ -22,9 +22,10 @@ static const char lostchild[] =
static void prepare_argv(const char **sent_argv, const char **argv)
{
const char *arg_cmd = "argument ";
- char *p, buf[4096];
+ char *p, *buf;
int sent_argc;
int len;
+ buf = xmalloc(4096);
/* put received options in sent_argv[] */
sent_argc = 2;
@@ -32,7 +33,7 @@ static void prepare_argv(const char **sent_argv, const char **argv)
sent_argv[1] = "--remote-request";
for (p = buf;;) {
/* This will die if not enough free space in buf */
- len = packet_read_line(0, p, (buf + sizeof buf) - p);
+ len = packet_read_line(0, p, (buf + 4096) - p);
if (len == 0)
break; /* got a flush */
if (sent_argc > MAX_ARGS - 2)
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply related
* Re: [PATCH] Add built-in diff patterns for MATLAB code
From: Thomas Rast @ 2011-11-15 12:37 UTC (permalink / raw)
To: Gustaf Hendeby; +Cc: Git List, Junio C Hamano
In-Reply-To: <1321191764-11972-1-git-send-email-hendeby@isy.liu.se>
Gustaf Hendeby wrote:
> +PATTERNS("matlab",
> + "^[[:space:]]*((classdef|function)[[:space:]].*)$|^%%[[:space:]].*$",
> + "[a-zA-Z_][a-zA-Z0-9_]*|[-+0-9.e]+|[=~<>]=|\\|\\||&&"),
Shouldn't you, for matlab, ensure that ./ "sticks" as a single word
since it is an operator? At least we used the same logic for the C ||
and && operators, which you copied.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] Add built-in diff patterns for MATLAB code
From: Gustaf Hendeby @ 2011-11-15 12:47 UTC (permalink / raw)
To: Thomas Rast; +Cc: Git List, Junio C Hamano
In-Reply-To: <201111151337.07013.trast@student.ethz.ch>
On Tue, 15 Nov 2011 13:37:06 +0100, Thomas Rast wrote:
> Gustaf Hendeby wrote:
>> +PATTERNS("matlab",
>> +
>> "^[[:space:]]*((classdef|function)[[:space:]].*)$|^%%[[:space:]].*$",
>> + "[a-zA-Z_][a-zA-Z0-9_]*|[-+0-9.e]+|[=~<>]=|\\|\\||&&"),
>
> Shouldn't you, for matlab, ensure that ./ "sticks" as a single word
> since it is an operator? At least we used the same logic for the C
> ||
> and && operators, which you copied.
Good point Thomas, I forgot all about the .-operators. I will add
\.[*/^'] as words, are there any other ones to consider? Thanks for
paying attention!
/Gustaf
^ permalink raw reply
* Re: [PATCH] Add built-in diff patterns for MATLAB code
From: Thomas Rast @ 2011-11-15 13:14 UTC (permalink / raw)
To: Gustaf Hendeby; +Cc: Git List, Junio C Hamano
In-Reply-To: <df238a1919b7c7d05749b4aa637fe2c7@isy.liu.se>
Gustaf Hendeby wrote:
> On Tue, 15 Nov 2011 13:37:06 +0100, Thomas Rast wrote:
> > Gustaf Hendeby wrote:
> >> +PATTERNS("matlab",
> >> +
> >> "^[[:space:]]*((classdef|function)[[:space:]].*)$|^%%[[:space:]].*$",
> >> + "[a-zA-Z_][a-zA-Z0-9_]*|[-+0-9.e]+|[=~<>]=|\\|\\||&&"),
> >
> > Shouldn't you, for matlab, ensure that ./ "sticks" as a single word
> > since it is an operator? At least we used the same logic for the C
> > ||
> > and && operators, which you copied.
>
> Good point Thomas, I forgot all about the .-operators. I will add
> \.[*/^'] as words, are there any other ones to consider? Thanks for
> paying attention!
Uh, I'm afraid it's been years since I did matlab. But
http://www.mathworks.ch/help/techdoc/matlab_prog/f0-40063.html
seems to indicate you forgot '.\'.
Please also update the testcases to whether this splits correctly,
e.g., by changing './' to '/'.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Git 1.7.5 problem with HTTPS
From: Dmitry Smirnov @ 2011-11-15 13:52 UTC (permalink / raw)
To: git
Hi,
I have problems with downloading Android code from android.googlesource.com.
The error says: fatal: branch stable is not signed
I was trying to figure out what happens and finally came to conclusion
that this is a problem of the git.
When I try to clone the git itself using https
(https://git.kernel.org/pub/scm/git/git.git) I'm getting the follwing
error:
warning: remote HEAD refers to nonexistent ref, unable to checkout.
If I use the http URL (http://git.kernel.org/pub/scm/git/git.git) I
can clone with no problems.
I was also considering that the problem is caused by proxy. But when I
tried to clone the same git source from another host via the same
proxy, it works pretty good. The difference is the git version: on the
first host it is 1.7.5.4 (comes with Ubuntu 11.10), on the second -
1.7.0.4
I was trying to collect some tcpdump and it shows the follwoing sequence
15 1.962132 X.X.X.X Y.Y.Y.Y HTTP 204 CONNECT git.kernel.org:443 HTTP/1.1
17 3.687364 Y.Y.Y.Y X.X.X.X HTTP 105 HTTP/1.0 200 Connection established
19 3.764793 X.X.X.X Y.Y.Y.Y TLSv1 208 Client Hello
21 3.815135 X.X.X.X Y.Y.Y.Y TLSv1 215 Ignored Unknown Record
23 4.045326 Y.Y.Y.Y X.X.X.X TLSv1 2239 Server Hello, Certificate,
Server Key Exchange, Server Hello Done
25 4.055059 Y.Y.Y.Y X.X.X.X TLSv1 73 Alert (Level: Fatal, Description:
Protocol Version)
As you can see, session seems terminated with fatal alert. It looks
like client tries to use TLS 1.2 but server accepts only TLS 1.0. But
this is just assumption.
Also, it is no clear what is that Ignored Unknown Record. But it
contains uncripted text: GET
/pub/scm/git/git.git/info/refs?service=git-upload-pack HTTP/1.1
User-Agent: git/1.7.5.4 Host: git.kernel.org Accept: */* Pragma:
no-cache
So, any suggesstions?
Dmitry
^ permalink raw reply
* Re: [PATCH] git-show-ref: fix escaping in asciidoc source
From: Michael Haggerty @ 2011-11-15 14:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1319050336-24717-1-git-send-email-mhagger@alum.mit.edu>
Junio,
Did this one fall through the cracks? I don't see it in your tree.
Michael
On 10/19/2011 08:52 PM, mhagger@alum.mit.edu wrote:
> From: Michael Haggerty <mhagger@alum.mit.edu>
>
> One of the "^" characters was not coming through in the man page.
>
> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
> ---
> Documentation/git-show-ref.txt | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-show-ref.txt b/Documentation/git-show-ref.txt
> index 3c45895..87f358d 100644
> --- a/Documentation/git-show-ref.txt
> +++ b/Documentation/git-show-ref.txt
> @@ -44,7 +44,7 @@ OPTIONS
> -d::
> --dereference::
>
> - Dereference tags into object IDs as well. They will be shown with "^{}"
> + Dereference tags into object IDs as well. They will be shown with "{caret}\{\}"
> appended.
>
> -s::
> @@ -75,7 +75,7 @@ OPTIONS
> Make 'git show-ref' act as a filter that reads refs from stdin of the
> form "^(?:<anything>\s)?<refname>(?:{backslash}{caret}\{\})?$"
> and performs the following actions on each:
> - (1) strip "^{}" at the end of line if any;
> + (1) strip "{caret}\{\}" at the end of line if any;
> (2) ignore if pattern is provided and does not head-match refname;
> (3) warn if refname is not a well-formed refname and skip;
> (4) ignore if refname is a ref that exists in the local repository;
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: Git 1.7.5 problem with HTTPS
From: Shawn Pearce @ 2011-11-15 15:03 UTC (permalink / raw)
To: Dmitry Smirnov; +Cc: git
In-Reply-To: <CACf55T6BGds_D=nbb8G=m+Jwr+bHFruCs-Q0+FOO+WXitXEJ-g@mail.gmail.com>
On Tue, Nov 15, 2011 at 05:52, Dmitry Smirnov <divis1969@gmail.com> wrote:
> I have problems with downloading Android code from android.googlesource.com.
>
> The error says: fatal: branch stable is not signed
>
> I was trying to figure out what happens and finally came to conclusion
> that this is a problem of the git.
Not likely. This is an error printed by the "repo" tool used by
Android. It typically indicates the repo command you are executing is
pointing to a URL that may be a local mirror and contain additional
patches in it that were not signed by me.
I would suggest starting over by downloading repo per [1] and using
that script to start the process.
[1] http://source.android.com/source/downloading.html
> When I try to clone the git itself using https
> (https://git.kernel.org/pub/scm/git/git.git) I'm getting the follwing
> error:
> warning: remote HEAD refers to nonexistent ref, unable to checkout.
>
> If I use the http URL (http://git.kernel.org/pub/scm/git/git.git) I
> can clone with no problems.
This may be a problem with the git.kernel.org HTTP server. It is
probably not a problem with Git itself.
^ permalink raw reply
* Re: [PATCH 0/7] New sequencer workflow!
From: Phil Hord @ 2011-11-15 15:46 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Git List, Junio C Hamano, Jonathan Nieder, Christian Couder
In-Reply-To: <1321181181-23923-1-git-send-email-artagnon@gmail.com>
On Sun, Nov 13, 2011 at 5:46 AM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> $ git revert moo..baz
> ... conflict ...
> $ echo "resolved" >problematicfile
> $ git add problematicfile
> $ git sequencer --continue
>
> In other words, it just doesn't matter how you started what sequencing
> operation: you can always continue a it with "git sequencer
> --continue" and reset it with "git sequencer --reset".
I see that --reset was added to cherry-pick, revert and sequencer
around the same time back in August. Shouldn't it be spelled
"--abort" instead?
This would align better with other commands that do the same thing
(am, merge, notes-merge, rebase) since they all appear to spell it
"--abort". Also, it will make it easier in git 2.x when we begin
using "git continue" and "git abort" rather than "git reset".
Phil
^ permalink raw reply
* Re: input director not compatible with git right-click
From: Sitaram Chamarty @ 2011-11-15 16:09 UTC (permalink / raw)
To: Carlos Martín Nieto, Eric, git
In-Reply-To: <20111114144024.GD10025@beez.lab.cmartin.tk>
On Mon, Nov 14, 2011 at 8:10 PM, Carlos Martín Nieto <cmn@elego.de> wrote:
> On Sun, Nov 13, 2011 at 04:34:26PM +0000, Eric wrote:
>> Hi,
>>
>> New in Git use, I use it do dev on window some administrative script. I use as
>> well Input director to share keyboard and mouse on multiple computer.
>
> Do you mean you're using it on the Windows OS?
>
>>
>> when I right-clicked on an item, it works when input director is disabled. If
>
> Right-click on what? git doesn't have a graphical interface. If you're
> using a graphical front-end to git, you should send them a bug report.
git comes with 3 perfectly cromulent graphical programs, and one of
them is indispensable.
The real reason the original question is not meaningful here is that
-- if he hadn't mentioned "share keyboard and mouse on multiple
computer" most people would have no clue what the heck it was, and
obscure software does... obscure things, so it should be reported to
them. not here.
--
Sitaram
^ permalink raw reply
* Re: [PATCH 0/7] New sequencer workflow!
From: Ramkumar Ramachandra @ 2011-11-15 16:12 UTC (permalink / raw)
To: Phil Hord; +Cc: Git List, Junio C Hamano, Jonathan Nieder, Christian Couder
In-Reply-To: <CABURp0qt+r09Uy_nfLd60pXiMMXgTOUB__XL-N=S7HaJa-oWoA@mail.gmail.com>
Hi Phil,
Phil Hord wrote:
> I see that --reset was added to cherry-pick, revert and sequencer
> around the same time back in August. Shouldn't it be spelled
> "--abort" instead?
"reset" is actually different from "abort": it simply removes the
sequencer state without touching the worktree, index or HEAD. We
decided that this would be a nice low-level command to implement
(since I find myself doing `rm -rf .git/rebase-todo` sometimes).
Sure, "abort" and a lot of other porcelain would be nice- we can
always implement them carefully later :)
Thanks.
-- Ram
^ permalink raw reply
* Re: [PATCH] Fix "is_refname_available(): query only possibly-conflicting references"
From: Michael Haggerty @ 2011-11-15 16:19 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Drew Northup, Jakub Narebski, Heiko Voigt,
Johan Herland, Julian Phillips
In-Reply-To: <7vty65x2zl.fsf@alter.siamese.dyndns.org>
On 11/15/2011 08:24 AM, Junio C Hamano wrote:
> However, I'd rather see us spend effort to make absolutely sure that other
> topics already in next that touch the related codepaths (I think you have
> two such series yourself and I suspect there are other minor fixes that
> may textually conflict) are in good shape and have them graduate early
> after 1.7.8 ships, before queuing a re-roll of the ref-api series, which
> is rather extensive.
If you have a preference for which patch series you would like to
integrate in which order (and especially if you think that there are
gaps that need to be filled), please let me know. It would be a lot
less work to put them in the right order from the start rather than
trying to keep them all synchronized with master and continually reroll
them based on what you have merged so far.
Also, I am working under the assumption that the patch series that are
already in "next" should be left alone; if you have doubts about any of
those patch series (i.e., are thinking of ejecting them from next during
the post-release chaos), please let me know what needs changing.
I'm still getting the hang of this workflow, so suggestions are welcome.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH 3/5] sequencer: sequencer state is useless without todo
From: Junio C Hamano @ 2011-11-15 16:27 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Ramkumar Ramachandra, Git List
In-Reply-To: <20111115095225.GB23139@elie.hsd1.il.comcast.net>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Ramkumar Ramachandra wrote:
>
>> Yeah, git_path() writes to one of the four static buffers in
>> path.c:get_pathname(). Which brings me to: what should (can) we do
>> about it?
>
> Just use a sane idiom. Which means: as few git_path() values in
> flight at a time as possible.
>
> In other words, do not save the git_path() result in a variable, but
> pass it directly to whatever computation needs to use it.
Or perhaps http://thread.gmane.org/gmane.comp.version-control.git/184963/focus=185436
^ permalink raw reply
* [PATCH 0/4] Fix minor warnings reported by icc
From: Ramkumar Ramachandra @ 2011-11-15 16:59 UTC (permalink / raw)
To: Git List; +Cc: Thomas Rast
Hi,
Thomas Rast tried compiling Git with Intel's C compiler (icc) recently
and the results can be found here [1]. Most of them don't amount to
anything, are probably not worth fixing. Here are fixes to a few that
caught my eye.
Thanks.
[1]: https://gist.github.com/1367335
-- Ram
Ramkumar Ramachandra (4):
http: remove unused function hex()
convert: don't mix enum with int
ll-merge: initialize default_opts const
sha1_file: don't mix enum with int
convert.c | 6 +++---
http.c | 8 --------
ll-merge.c | 2 +-
sha1_file.c | 2 +-
4 files changed, 5 insertions(+), 13 deletions(-)
--
1.7.6.351.gb35ac.dirty
^ 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