lter_handler. It seems weird to fill-in an array and then
re-filter it. I think it would make sense to add a few comments, like
/* Simple per-ref filtering */
ret = for_each_ref_fn(ref_filter_handler, data);
/* Filters that need revision walking */
if (data->filter.merge_commit)
...
--
Matthi
Karthik Nayak writes:
> Add the '--points-at' option provided by 'ref-filter'. The
> option lets the user to pick only refs which point to a particular
> commit.
>
> Add Documentation for the same.
... but no test?
--
Matthieu Moy
http://www-verimag.imag.f
this code duplication in the commit
message (or not do code duplication). It might make sense to add a
comment next to match_points_at in tag.c saying stg like "this is
duplicated from ..., will be removed later".
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe fro
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Karthik Nayak writes:
>>
>>> On 06/08/2015 08:23 PM, Matthieu Moy wrote:
>>>> Karthik Nayak writes:
>>>>
>>>> > +/* Free all memory allocated for ref_array */
>>>>
d the
misleading commit message in PATCH 2, the series looks good to me.
(BTW, an easy way to check that each patch is compilable is to run
"git rebase -i --exec make". It would have noticed the issue with
filter_refs() automatically)
--
Matthieu Moy
http://www-verimag.imag.fr/~
lter.name_patterns = argv;
> - for_each_rawref(ref_filter_handler, &ref_cbdata);
> + filter_refs(for_each_rawref, &ref_cbdata);
This seems unrelated from the rest of the patch. And you haven't
introduced filter_refs yet!
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
Karthik Nayak writes:
> On 06/08/2015 08:23 PM, Matthieu Moy wrote:
>> Karthik Nayak writes:
>>
>> > +/* Free all memory allocated for ref_array */
>> > +void ref_array_clear(struct ref_array *array)
>>
>> Is this a private function? If so, the
e needs a good
understanding of the code to check the correctness of your patch.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Remi Lespinet writes:
> Matthieu Moy writes:
>
>> Remi Lespinet writes:
>>
>> > Simplify code by creating a function to transform list of email lists
>> > (comma separated, with aliases ...) into a simple list of valid email
>> > addresses.
>&g
;Next commands to do (%d remaining
> commands):",
> + yet_to_do.nr),
> + yet_to_do.nr);
> + for (i = 0; i < lines_to_show_nr && i < yet_to_do.nr;
> i++) {
> + status_pr
Karthik Nayak writes:
> +/* Free all memory allocated for ref_array */
> +void ref_array_clear(struct ref_array *array)
Is this a private function? If so, then add static. If not, you probably
want to export it in a .h file.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsub
e and keep the member const.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
- REALLOC_ARRAY(cb->grab_array, cnt + 1);
> - cb->grab_array[cnt++] = ref;
> - cb->grab_cnt = cnt;
> + REALLOC_ARRAY(cb->grab_array, cb->grab_cnt + 1);
> + cb->grab_array[cb->grab_cnt++] = ref;
> return 0;
> }
Did you squash the com
x the bug as a positive side effect
of the refactoring). I think it's too late to change this, though.
> I'm not sure about the name of the function...
process_address_list() sounds good to me.
The whole series looks good to me now.
--
Matthieu Moy
http://www-verimag.imag.fr/~
heck if a file exists
> instead of reusing BISECT_TERMS, which would require reading its
> content.
>
> ----
> De: "Christian Couder"
> ...
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To un
this is not a very good change).
Ah, indeed, we're saying the same thing.
>> - echo "old" >>"$GIT_DIR/BISECT_TERMS"
>> + echo "old" >>"$GIT_DIR/BISECT_TERMS" &&
>
st
in case.
With or without this 'rm -fr', the series looks good to me. Thanks.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
is supposed to apply to and we have those blobs
> - available locally.
> + available locally. `--no-3way` can be used to override
> + am.threeWay configuration variable. For more information,
> + see am.threeWay in git-config(1).
... in linkgit:git-config[1].
--
Matthieu
uot;s"));
>
> + free((char*)bisect_bad);
> + free((char*)bisect_good);
Already noted last time I think: these must not be freed as they are
pointing to static strings.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
I'd swap 3/4 and 4/4 so that we see the impact of your code on these new
tests. I won't insist on that though.
Please help reviewers by explaining in the commit message why these
tests are needed (what was not covered properly by existing tests?)
Guillaume Pagès writes:
> +test_expect_success '
; + numlines);
Q_() ?
> + begin = numlines > 1? 0 : 1;
> + for (i = begin; i < 2; i++) {
> + status_printf_ln(s,color," %s",lines[i]);
> + }
> + if (numlines > 2 &
am "1$message1"
Not a Git issue, but a user-error that Git cannot recover.
Your shell is doing the variable expansion before calling git, and
$message1 is considered as a shell variable here. Git does not know that
you used $message1.
Solution:
git commit -am '1$message1'
Remi Galan Alfonso writes:
> Matthieu Moy writes:
>> You're using $1 and $2 only to redirect input and output. I would find
>> it more elegant to write todo_list_to_sha_list as a filter, and do the
>> redirection in the call site (to keep the option of using
>>
de.
+ (use git rebase --edit-todo to view and edit)
All other status hints use double-quotes around commands. I think this
one should, too.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body
ep the option of using
todo_list_to_sha_list in a pipe).
> +check_commits
You're not really checking commits, but rather the todo-list.
> +Use git --config rebase.missingCommitsCheck to change the level of warnings
> (ignore, warn, error).
Long line. Please, wrap the message to <
ere's not much to do when fclose fails actually)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
status_color = color(WT_STATUS_NOBRANCH, s);
> if (state.rebase_in_progress ||
> state.rebase_interactive_in_progress) {
> - on_what = _("rebase in progress; onto ");
> + if (state.rebase_interactive_in_progress)
> + on_what = _("interactive rebase in
> progress; onto ");
> + else
> + on_what = _("rebase in progress; onto
> ");
I wouldn't insist on that, but splitting this one in a separate patch
would make sense to me too. The patch would contain this change, and the
impact on tests.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Remi Lespinet writes:
> +am.threeWay::
> + By default, git-am will fail if the patch does not apply cleanly.
http://article.gmane.org/gmane.comp.version-control.git/270538
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscr
ult behaviour.
I don't think it's a good idea to remove this part. If I look for a way
to make --keep-cr the default, the first place I'd look would be the doc
for --keep-cr, and I'd appreciate a link to am.keepcr.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Karthik Nayak writes:
> Matthieu Moy suggested that I work on the unification of these
> commands let both the implementations stay where the user can select
> the implementation to be used
Just to be clear: my advice is the above with "user" = "caller of the
API"
for "warn") enough, or should I check
> that the commit displayed as removed is the correct one?
Ideally, you would check the list of commits displayed too. If the
commits sha1 are stable, this should be easy to do. If it's too hard to
test, I'd say its not worth the trouble
uot; part. The user may have run "git rebase
--interactive" and not know -i, and normally already knows which command
is executed.
> +test_expect_success 'rebase -i respects
> rebase.missingCommitsCheckLevel=error' '
> + test_config rebase.missingCommitsCheckLev
rop actually drops the lines' '
...
'
?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
command names, and
configuration variables) are typeset in monospace, and if you can use
`backticks around word phrases`, do so.
`--pretty=oneline`
`git rev-list`
`remote.pushDefault`
) so I guess the first is the right way to typeset it.
FYI, the syntax git-am actually existed in the past (b
l be rewritten soon, though.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
hink that it should be in a different patch, changing the
> whole checking system of rebase is not directly linked to the idea of
> the 'drop' command.
Agreed.
Discussions on this list often lead to "Oh, BTW, shall we do XYZ also?",
but you shouldn't take this kind
. I don't have really good proposal in mind, but maybe
rebase.todoListCheckLevel
rebase.missinLinesCheckLevel
?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
Junio C Hamano writes:
> Matthieu Moy writes:
>
>>> @@ -1,1 +1,2 @@
>>> +5
>>> 10
>>> @@ -1,3 +2,3 @@
>>> 10
>>> +15
>>> -20
>>> 30
>>
>> With this one, I get:
>>
>> $ git apply <
a1" command.
So, IMHO, why not do this check, but I'm not sure it will actually help
much.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
iled: pre.txt:3
error: pre.txt: patch does not apply
$ patch < p2.diff
patching file pre.txt
$ cat pre.txt
-1
0
5
10
15
30
40
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
#1 succeeded at 2 with fuzz 1 (offset 1 line).
It's different from the other case:
Remi LESPINET writes:
> @@ -1,1 +1,2 @@
> +5
> 10
> @@ -1,3 +2,3 @@
> 10
> +15
> -20
> 30
With this one, I get:
$ git apply < p2.diff
error: patch failed: pre.txt:1
er
my sign-off. The rule which
applies by default for students is "don't distribute your code"
(symmetrical to "don't use other students code"), which obviously does
not apply for this project: I do allow them to contribute their code!
--
Matthieu Moy
http://www-verimag
mple.com" \
> + --cc="c...@example.com, Cc 1 " \
> + --cc="Cc 2 " \
> + --bcc="b...@example.com, b...@example.com" \
> + 0001-add-master.patch | replace_variable_fields \
> + >actual-list &&
You may drop the spa
Karthik Nayak writes:
> On 06/01/2015 02:16 AM, Matthieu Moy wrote:
>> Karthik Nayak writes:
>>
>> > That is kind of a problem, If I need to swap those commits also, I'd
>> > have to add the part where ref-filter is added to the Makefile with
>>
could
think and discuss the naming by looking just at the summary, and then
check that you did it correctly (easy).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kerne
Then, the next patch can be just code movement.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
tch_refname may not carry all the semantics of the function,
which matches a prefix up to the end of string, or up to a / (but you
can't just be a prefix stopping in the middle of a word). To me, the
"_as_path" helped understanding the overall behavior of the function.
--
Matthi
g ", Bar" with something a bit more
> realistic that people use in real life, e.g. ", Esq." or ", PhD"
> (e.g. "Jane Doe, Esq.")
Why not, but it's also not uncommon to see "Last, First", like
"Moy, Matthieu" .
--
Matthieu
to push tags only with this?
fetch and push are a bit different: it's almost never a bad idea to run
fetch (I see remote-tracking as a kind of cache, and fetch is the way to
refresh this cache), but pushing too much can be harmful. Not a strong
objection, but I'm not sure that this change
if it was a good thing.
Perhaps a justification is that annotated tags are clearly meant to be
public while lightweight tags can also be used as private bookmarks.
In any case, the fact that it's been this way and documented this way
since 2013 makes it a bit hard to change now.
--
Matthieu Mo
ng that and provide commands to do this (e.g. "git
rebase --edit-todo" instead of asking the user to do $EDITOR
.git/rebase-merge/git-rebase-todo), but the ones you show seem OK to me.
There's already at least one instance of this when a rebase fails:
Patch failed at 0001 foo
T
/git-multimail/git-multimail/pulse/monthly
[3] https://github.com/git-multimail/git-multimail/pull/90
[4] https://github.com/git-multimail/git-multimail/pull/52
Cheers,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe
d form (-bbranch) and unsticked (-b
branch). This is the convention with most Unix commands (try "grep -e
foo" Vs "grep -efoo").
It gets more confusing for "git -amend" Vs "git --amend", which got a
special-case to avoid confusion (strictly speak
option like --tags-also that would push
tags _in addition_ to what would normally be pushed. --follow-tags does
more or less this, though, but only for annotated tags pointing at a ref
being pushed.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line &q
Karthik Nayak writes:
> On 05/29/2015 01:56 AM, Matthieu Moy wrote:
>> Karthik Nayak writes:
>>
>>> Rename 'refinfo' to 'ref_array_item' and intoduce 'ref_filter_cbdata'
>>
>> The fact that you need to use "and" to
to avoid having to review the
code movement & refactoring again when we move to the next patches).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ing is not just about having a look and seeing if there's
something stupid. Reviewers are actually taking a lot of time to see if
the patch does not introduce new bugs, or looking for better ways to do
the same thing. Be nice with them!
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
the commit message, and I had to fight a
bit to understand what it does with "we're extracting helper functions"
in mind. It would have been much easier to review in a separate patch
entitled "for-each-ref: simplify code" for example.
But I agree that your version is simpler
e --skip" to skip this patch)
(use "git rebase --abort" to check out the original branch)
I like the output of "git status" to be concise. OTOH, there are tons of
information in .git/rebase-merge/ that could be displayed to the user.
--
Matthieu Moy
http://ww
adding support for them would not hurt, lack of these
> are OK, as long as we do not have configuration variables to tweak
> their defaults.
I wouldn't worry about these issues, as the port to C will make them
disappear anyway.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsub
sualizes the commit graph in
> a visually pleasing manner, where I can select one or more commits and
> drop them onto a commit in the graph, and then it goes and magically
> cherry-picks-and-drops them.
You need to argue a bit more to convince my students to schedule this
for the end of the
ady taken for "show me the diff together
with status".
(I'm also dreaming of a "git status --tutor" that would show detailed
explanations with pointers to the documentation & all for each section
of "status". Useless for non-beginners, but could be a nice way to t
n't pass
arguments to the helper, but why not have this in case we need it later.
No need to resend now, you'll send a new version when you have something
to build on top (or if someone has more important remarks).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsu
e it to the shell
On my side, that wouldn't be twice a week, but I often do the same
mistake. I find your idea for a solution conceptually ugly but
practically very convenient ;-), so I'd be in favor of doing it.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this
and most people would appreciate a brief explanation of
what "git rebase --status" is before knowing how you're starting the
work.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to ma
essage even when there's no rebase
in progress. And reviewers may get confused.
I'd have written stg like
printf("git rebase --status is not yet implemented");
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsub
-e "s/^\(X-Mailer:\).*/\1 X-MAILER-STRING/" \
> + $patches | replace_variable_fields \
I wouldn't insist on that, but this change would be better done in a
separate, preparatory patch (that would be PATCH 1/2, and the actual
code would be PATCH 2/2).
Karthik Nayak writes:
> On 05/26/2015 09:19 PM, Matthieu Moy wrote:
>> Seconded. Some reasons/guide to split:
>>
>> * Split trivial and non-trivial stuff. I can quickly review a
>>"rename-only" patch even if it's a bit long (essentially, I&#x
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> I find it weird to write
>>
>> noop
>
> True, but then it can be spelled
>
> #
I do find it weird too. "#" means "comment", which means "do as if it
was not there" to m
Mercurial. Perhaps we should
ask on the mercurial ml how happy they are with the name.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ccurence. Accidentally dropped commits are another story: it's rather
easy to cut-and-forget-to-paste, and the consequence currently is silent
data loss ...
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git"
and basic helper functions (constructors,
mutators, destructors).
It will take time and may appear to be counter-productive at first, but
you'll get used to it, and you'll end up being actually more productive
this way (well, maybe not "you" but the set "you + reviewers&quo
only filtering, but who says it has to stay that way?
(With which I do agree)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
"argv_array" in argv-array.h and "sha1_array" in
> "sha1-array.h".
I'd drop the "filter" part and make it ref_array then. There's no reason
we could not use it it places other than filter.
But we also have string_list which is an array underneath,
tg like:
struct ref_filter_data /* Probably not the best name */ {
struct ref_list list;
struct ref_filter filter;
};
struct ref_list {
int count, alloc;
struct ref_filter_item **items;
const char **name_patterns;
};
struct ref_filter {
const char **n
> Where do I find the Amazon SES account for submitGit, to register
> my email with?
>
> Also can I change the email in the process or change it before?
I was confused at the same point, but at the top of the screen showing
this message, there was a link to do this registration. I was just n
/2 predates PATCH 1/2 and the second is
In-Reply-To: the first.
* I was about to suggest that you post a comment on the GitHub pull
request when sending the email, but it is already the case, with a
link to Gmane. Very very cool.
* Did I mention how awesome the application is already? '
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> The 'exec' command is sending the current commit to stopped-sha, which is
>> supposed to contain the original commit (before rebase). As a result, if
>> an 'exec' command fails, the next 'git r
The 'exec' command is sending the current commit to stopped-sha, which is
supposed to contain the original commit (before rebase). As a result, if
an 'exec' command fails, the next 'git rebase --continue' will send the
current commit as to the post-rewrite hook.
The test currently fails with :
-
Usually, when 'git rebase' stops before completing the rebase, it is to
give the user an opportunity to edit a commit (e.g. with the 'edit'
command). In such cases, 'git rebase' leaves the sha1 of the commit being
rewritten in "$state_dir"/stopped-sha, and subsequent 'git rebase
--continue' will ca
store list of refs (full_list_of_refs and
filtered_list_of_refs) and another to describe what you're doing with it
(description_of_filter).
The name ref_filter implies to me that it contains the description of
the filter, but looking at the code it doesn't seem to be the case.
--
Matthie
Eric Sunshine writes:
>> +test_expect_failure 'git rebase -i (exec)' '
>> + git reset --hard D &&
>> + clear_hook_input &&
>> + FAKE_LINES="edit 1 exec_false 2" git rebase -i B
>
> Broken &&-ch
led the
post-rewrite hook.
Fix the behavior to leave no stopped-sha file in case of failed exec
command, and teach 'git rebase --continue' to skip record_in_rewritten if
no stopped-sha file is found.
Signed-off-by: Matthieu Moy
---
I'm afraid I'm the one to blame for the bug :
Matthieu Moy (2):
rebase -i: demonstrate incorrect behavior of post-rewrite hook with
exec
rebase -i: fix post-rewrite hook with failed exec command
git-rebase--interactive.sh | 10 +-
t/t5407-post-rewrite-hook.sh | 17 +
2 files changed, 22 insertions(+), 5
c0b598b70cbeb594258a917e3f6fab
488028e9fac0b598b70cbeb594258a917e3f6fab
babc8a4c7470895886fc129f1a015c486d05a351
8edffcc4e69a4e696a1d4bab047df450caf99507
Signed-off-by: Matthieu Moy
---
t/t5407-post-rewrite-hook.sh | 17 +
1 file changed, 17 insertions(+)
diff --git a/t/t5407-post-rewrite-hook.sh b/t/t5
very vague. Be more precise, say how it will be involved
in sorting & formatting.
> +/* ref_filter will hold data pertaining to a list of refs. */
This is the answer to the "what?" question, which is not very hard to
infer from the code. That's not anwsering "what f
b49223c64c6f914944287a7d049cf4d26
Removing the last digit:
$ git show 280c12ab49223c64c6f914944287a7d049cf4d2
fatal: ambiguous argument '280c12ab49223c64c6f914944287a7d049cf4d2': unknown
revision or path not in the working tree.
Use '--' to separate paths from revisions
; for non existing objects.
I did the same, but the error message is different if you provide an abreviated
sha1 or a full 40-chars sha1.
Any full sha1 I tried gave the same error message.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscr
7a7d049cf4dd0 is not an object in
your repository. The good news it: I don't think you have a corrupt
repository. What makes you think you have an object with identifier
280c12ab49223c64c6f914944287a7d049cf4dd0?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list:
case, you should add in the commit message that there's no
actual changs, and perhaps which renames were done. This makes the
review straightforward.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
karthik nayak writes:
> There is also Junio's Blog where he keeps a list of things to be done
>
> http://git-blame.blogspot.de/p/leftover-bits.html
I'd add this: https://git.wiki.kernel.org/index.php/SmallProjectsIdeas
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
pull and git-am builtins", mentored by
Johannes Schindelin and Stefan Beller.
Regards,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at ht
ver the past 12 months.
That is the point indeed. Michael does not use git-multimail himself,
and does not find time to work on it. I'm joining the effort, but
currently have no time either. But eventually I'll go through the list
of pending pull-requests, and we'll actually get new c
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Junio C Hamano writes:
>>
>>> Was that obtained from the upstream project (i.e. you) and match
>>> your 1.0.2 tag?
>>
>> Yes. Isn't that what the text above says?
>
> Well, the patc
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Junio C Hamano writes:
>>
>>>> --- a/contrib/hooks/multimail/README.Git
>>>> +++ b/contrib/hooks/multimail/README.Git
>>>> @@ -3,13 +3,13 @@ section of the Git project as a convenienc
quot; subdirectory from
>> +on 2015-04-27 and consists of the "git-multimail" subdirectory from
>> revision
>>
>> -1b32653bafc4f902535b9fc1cd9cae911325b870
>> +8c3aaafa873bf10de8dddf1d202c449b3eff3b42 refs/tags/1.0.2
>
> Huh, really?
What's the
oks/multimail/README.Git | 6 +++---
> 2 files changed, 25 insertions(+), 24 deletions(-)
Acked-by: Matthieu Moy
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.ke
ttached file is empty ;-). Actually, as much as
possible, avoid sending attachments but prefer inline patches.
You'll need a bit of reading to send a proper patch:
https://github.com/git/git/blob/master/Documentation/SubmittingPatches
--
Matthieu Moy
http://www-verimag.imag.fr/~moy
roblem is unrelated from Git: your webserver looks at files
on disk, not at the Git repository (i.e. whether your changes are staged
in the index, commited, or totally outside Git does not change the
result). My guess would be that you have two clones of the same project.
--
Matthieu Moy
http://
Scott Meyer writes:
> When I use my browser to bring up the site the change is not visible.
Which site are you talking about?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a mess
901 - 1000 of 2167 matches
Mail list logo
