Antoine Delaite writes:
> --- a/git-bisect.sh
> +++ b/git-bisect.sh
> @@ -32,6 +32,8 @@ OPTIONS_SPEC=
>
> _x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
> _x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
> +NAME_BAD="bad"
> +NAME_GOOD="good"
I would have written
NAME_NEW=bad
NAME_OLD=good
Karthik Nayak writes:
> On 06/08/2015 10:51 PM, Matthieu Moy wrote:
>> We could introduce ref-filter.h earlier, indeed. To me, the current
>> solution is good enough, but introducing ref-filter.h early and adding
>> function definition there in the same commit as you drop the "static"
>> keyword
The diff and submodule shortlog appended to the commit message template
by 'git commit --verbose' are not stripped when the commit message
contains an indented scissors line.
When cleaning up a commit message with 'git commit --verbose' or
'--cleanup=scissors' the code is careful and triggers only
The diff and submodule shortlog appended to the commit message template
by 'git commit --verbose' are not stripped when the commit message
contains an indented scissors line.
When cleaning up a commit message with 'git commit --verbose' or
'--cleanup=scissors' the code is careful and triggers only
tcsh users who happen to have 'set noclobber' elsewhere in their ~/.tcshrc or
~/.cshrc startup files get a 'File exist' error, and the tcsh completion file
doesn't get generated/updated. Adding a `!` in the redirect works correctly
for both clobber (default) and 'set noclobber' users.
Helped-b
On Mon, Jun 8, 2015 at 11:43 AM, Luke Diamand wrote:
> On 08/06/15 18:18, Junio C Hamano wrote:
>>
>> Lex Spoon writes:
>>
>>> Precisely, Junio, that's what I had in mind. The patch with the two
>>> lines deleted LGTM.
>>
>>
>> Thanks, will do.
>
>
> I don't think we're quite there yet unfortunat
Michael Rappazzo writes:
> Difference between v1 and v2 of this patch:
>
> - Fixed indentation from spaces to match the existing style
> - Changed the prepended sha1 from short (%h) to long (%H)
> - Used bash variable default when the config option is not present
>
> Michael Rappazzo
Junio C Hamano 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.
> >
> > I would have found the series easier to re
Guillaume Pagès writes:
> git status gives more information during rebase -i, about the list of
> command that are done during the rebase. It displays the two last
> commands executed and the two next lines to be executed. It also gives
> hints to find the whole files in .git directory.
> ---
W
> -Original Message-
> From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On
> Behalf Of Konstantin Khomoutov
> Sent: June 8, 2015 12:15 PM
> To: hack...@suddenlink.net
> Cc: git@vger.kernel.org
> Subject: Re: GIT for Microsoft Access projects
>
> On Mon, 8 Jun 2015 9:45:17
Guillaume Pagès writes:
> ---
> wt-status.c | 30 +++---
> 1 file changed, 11 insertions(+), 19 deletions(-)
Hmmm, it obviously does not break anything but it is not obvious why
this is a good change.
Is it that you wanted to have a single instance of "if on a branch,
Michael Rappazzo writes:
> A config option 'rebase.instructionFormat' can override the
> default 'oneline' format of the rebase instruction list.
>
> Since the list is parsed using the left, right or boundary mark plus
> the sha1, they are prepended to the instruction format.
>
> Signed-off-by: M
Antoine Delaite writes:
> When not looking for a regression during a bisect but for a fix or a
> change in another given property, it can be confusing to use 'good'
> and 'bad'.
>
> This patch introduce `git bisect new` and `git bisect old` as an
> alternative to 'bad' and good': the commits whic
Max Kirillov writes:
> User, in theory, can be not the same person who builds, or
> can be not aware that the case needs recoding.
Because you can pretty much say the same for build with iconv
enabled, I think that line of argument is futile. The users do not
have control over platform's iconv
Hi.
On Mon, Jun 08, 2015 at 09:16:16AM -0700, Junio C Hamano wrote:
> Max Kirillov writes:
>> This gives undesirable result that returned data or even
>> data written into repository is incorrect and user is not
>> aware about it.
>
> I do not necessarily agree with that. The user knows what
>
Difference between v1 and v2 of this patch:
- Fixed indentation from spaces to match the existing style
- Changed the prepended sha1 from short (%h) to long (%H)
- Used bash variable default when the config option is not present
Michael Rappazzo (1):
git-rebase--interactive.sh: add
A config option 'rebase.instructionFormat' can override the
default 'oneline' format of the rebase instruction list.
Since the list is parsed using the left, right or boundary mark plus
the sha1, they are prepended to the instruction format.
Signed-off-by: Michael Rappazzo
---
git-rebase--inter
Antoine Delaite writes:
> We create a file BISECT_TERMS in the repository .git to be read during a
> bisection. The fonctions to be changed if we add new terms are quite
> few.
> In git-bisect.sh :
> check_and_set_terms
> bisect_voc
> In bisect.c :
> handle_bad_merge_base
>
> Si
Antoine Delaite writes:
> + *,"$NAME_BAD")
> + die "$(gettext "'git bisect $NAME_BAD' can take only one
> argument.")" ;;
H, doesn't this break i18n the big way?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kern
When not looking for a regression during a bisect but for a fix or a
change in another given property, it can be confusing to use 'good'
and 'bad'.
This patch introduce `git bisect new` and `git bisect old` as an
alternative to 'bad' and good': the commits which have a certain
property must be mar
---
bisect.c| 2 +-
t/t6030-bisect-porcelain.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/bisect.c b/bisect.c
index 10f5e57..de92953 100644
--- a/bisect.c
+++ b/bisect.c
@@ -743,7 +743,7 @@ static void handle_bad_merge_base(void)
fprintf(s
We create a file BISECT_TERMS in the repository .git to be read during a
bisection. The fonctions to be changed if we add new terms are quite
few.
In git-bisect.sh :
check_and_set_terms
bisect_voc
In bisect.c :
handle_bad_merge_base
Signed-off-by: Antoine Delaite
Signed-of
To add new tags like old/new and have keywords less confusing, the
first step is to avoid hardcoding the keywords.
The default mode is still bad/good.
Signed-off-by: Antoine Delaite
Signed-off-by: Louis Stuber
Signed-off-by: Valentin Duperray
Signed-off-by: Franck Jonas
Signed-off-by: Lucien
git checkout can be used to revert changes in the working tree.
Signed-off-by: Torsten Bögershausen
---
My first attempt to improve the documentation
Documentation/git-checkout.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documen
On 06/08/2015 10:51 PM, Matthieu Moy wrote:
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 */
+void ref_array_clear(struct ref_array *array)
Is this a pr
Paul Tan writes:
> Since 7b3b7e3 (am --abort: keep unrelated commits since the last failure
> and warn, 2010-12-21), git-am would refuse to rewind HEAD if commits
> were made since the last git-am failure. This check was implemented in
> safe_to_abort(), which checked to see if HEAD's hash matche
Paul Tan writes:
> When git-am is first run on an unborn branch, no ORIG_HEAD is created.
> As such, any applied commits will remain even after a git am --abort.
I think this answered my question on 4/6; that may indicate that
these two are either done in a wrong order or perhaps should be a
sin
Paul Tan writes:
> Even when a merge conflict occurs with am --3way, the index will be
> modified with the results of any successfully merged files. These
> changes to the index will not be reverted with a
> "git read-tree --reset -u HEAD ORIG_HEAD", as git read-tree will not be
> aware of how th
Paul Tan writes:
> git-mailsplit, which splits mbox patches, will read the patch from stdin
> when the filename is "-" or there are no files listed on the
> command-line.
>
> To be consistent with this behavior, teach the StGit patch parser to
> read from stdin if the filename is "-" or no files
On Mon, Jun 8, 2015 at 10:50 AM, Konrád Lőrinczi wrote:
> I would like to group some files, so I can list group files together,
> list group changes together, filter by group for staging, also order
> by group.
> It seems, there is no such feature in GIT I would need, so I send it
> as suggestion.
Karthik Nayak writes:
> This is a follow up series to the one posted here
> http://thread.gmane.org/gmane.comp.version-control.git/270922
>
> This patch series adds '--ponints-at', '--merged', '--no-merged' and
> '--contain' options to 'ref-filter' and uses these options in
> for-each-ref'.
The
Karthik Nayak writes:
> +#define OPT_CONTAINS(filter, h) \
> + { OPTION_CALLBACK, 0, "contains", (filter), N_("commit"), (h), \
> + PARSE_OPT_LASTARG_DEFAULT, \
> + parse_opt_with_commit, (intptr_t) "HEAD" \
> + }
> +#define OPT_WITH(filter, h) \
> + { OPTION_CALLBACK, 0,
Please use a subject that is shorter and looks more like others on this list.
On Sun, Jun 7, 2015 at 9:54 PM, Ariel Faigon wrote:
>
> Junio,
>
> This is my 1st time doing this, sorry.
> I hope this satisfies the git Sign Off procedure.
The above lines should not be there, otherwise they will be
Karthik Nayak writes:
> +int parse_opt_merge_filter(const struct option *opt, const char *arg, int
> unset)
> +{
> + struct ref_filter *rf = opt->value;
> + unsigned char sha1[20];
> +
> + rf->merge = opt->long_name[0] == 'n'
> + ? REF_FILTER_MERGED_OMIT
> + :
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.
>
> Based-on-patch-by: Jeff King
> Mentored-by: Christian Couder
> Mentored-by: Matthieu Moy
> S
Karthik Nayak writes:
> diff --git a/parse-options-cb.c b/parse-options-cb.c
> index be8c413..a4d294d 100644
> --- a/parse-options-cb.c
> +++ b/parse-options-cb.c
> @@ -4,6 +4,7 @@
> #include "commit.h"
> #include "color.h"
> #include "string-list.h"
> +#include "sha1-array.h"
> ...
> +int pa
On 06/08/2015 11:23 PM, Matthieu Moy wrote:
Karthik Nayak writes:
Add the '--merged' and '--no-merged' options provided by 'ref-filter'.
The '--merged' option lets the user to only list refs merged into the
named commit. The '--no-merged' option lets the user to only list refs
not merged into
On 06/08/2015 11:28 PM, Matthieu Moy wrote:
Karthik Nayak writes:
+int parse_opt_merge_filter(const struct option *opt, const char *arg, int
unset)
+{
+ struct ref_filter *rf = opt->value;
+ unsigned char sha1[20];
+
+ rf->merge = opt->long_name[0] == 'n'
+ ? R
On 06/08/2015 11:30 PM, Matthieu Moy wrote:
Karthik Nayak writes:
In 'tag -l' we have '--points-at' option which lets users
list only tags which point to a particular commit, Implement
s/,/./ ?
this option in 'ref-filter.{c,h}' so that the other commands
s/the//
Noted! thanks
--
Rega
On 06/08/2015 11:21 PM, Matthieu Moy wrote:
Karthik Nayak writes:
+ if(filter->merge_commit) {
space after if.
@@ -938,7 +991,13 @@ void ref_array_clear(struct ref_array *array)
*/
int filter_refs(int (for_each_ref_fn)(each_ref_fn, void *), struct
ref_filter_cbdata *data)
{
-
On 06/08/2015 11:05 PM, Matthieu Moy wrote:
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?
No haven't written tests, this was just
On 06/08/2015 11:01 PM, Matthieu Moy wrote:
Karthik Nayak writes:
+/*
+ * Given a ref (sha1, refname) see if it points to a one of the sha1s
+ * in a sha1_array.
+ */
+static int match_points_at(struct sha1_array *points_at, const unsigned char
*sha1,
+ const char *re
On 06/08/2015 11:45 PM, Junio C Hamano wrote:
Karthik Nayak writes:
+/*
+ * API for filtering a set of refs. The refs are provided and iterated
+ * over using the for_each_ref_fn(). The refs are stored into and filtered
+ * based on the ref_filter_cbdata structure.
+ */
+int filter_refs(int (f
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.
>
> I would have found the series easier to read if this refactoring came
> earlier (and
Based on a cursory review of the git code I get the impression that
GNU diff and git 'diff' do not share any code for the possible diff
algorithms. I'm in particularly curious more about the default "myers"
algorithm. I can take time to do a precise code review of the
algorithms used on both GNU di
On 06/08/2015 11:32 PM, Junio C Hamano wrote:
Karthik Nayak writes:
+ * Given a refname, return 1 if the refname matches with one of the patterns
You can "match refname with pattern". But "refname matches the
pattern" without "with", I think.
I am not a native, though.
+ * while the patt
Karthik Nayak writes:
> +/*
> + * API for filtering a set of refs. The refs are provided and iterated
> + * over using the for_each_ref_fn(). The refs are stored into and filtered
> + * based on the ref_filter_cbdata structure.
> + */
> +int filter_refs(int (for_each_ref_fn)(each_ref_fn, void *),
Karthik Nayak writes:
> On 06/08/2015 10:38 PM, Matthieu Moy wrote:
>> Karthik Nayak writes:
>>
>> > --- a/builtin/for-each-ref.c
>> > +++ b/builtin/for-each-ref.c
>> > @@ -1129,7 +56,7 @@ int cmd_for_each_ref(int argc, const char
>> > **argv, const char *prefix)
>> >
>> > memset(&ref_cbda
Karthik Nayak writes:
> + * Given a refname, return 1 if the refname matches with one of the patterns
You can "match refname with pattern". But "refname matches the
pattern" without "with", I think.
I am not a native, though.
> + * while the pattern is a pathname like 'refs/tags' or 'refs/hea
Karthik Nayak writes:
> In 'tag -l' we have '--points-at' option which lets users
> list only tags which point to a particular commit, Implement
s/,/./ ?
> this option in 'ref-filter.{c,h}' so that the other commands
s/the//
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe
Karthik Nayak writes:
> +int parse_opt_merge_filter(const struct option *opt, const char *arg, int
> unset)
> +{
> + struct ref_filter *rf = opt->value;
> + unsigned char sha1[20];
> +
> + rf->merge = opt->long_name[0] == 'n'
> + ? REF_FILTER_MERGED_OMIT
> + :
Karthik Nayak writes:
> Add the '--merged' and '--no-merged' options provided by 'ref-filter'.
> The '--merged' option lets the user to only list refs merged into the
> named commit. The '--no-merged' option lets the user to only list refs
> not merged into the named commit.
>
> Add documentation
Karthik Nayak writes:
> + if(filter->merge_commit) {
space after if.
> @@ -938,7 +991,13 @@ void ref_array_clear(struct ref_array *array)
> */
> int filter_refs(int (for_each_ref_fn)(each_ref_fn, void *), struct
> ref_filter_cbdata *data)
> {
> - return for_each_ref_fn(ref_filter_h
Michael Haggerty writes:
> Thanks for all the comments. Taking them into consideration, I suggest
> changing the last commit message to
> ...
> Since the only comments were about this one commit message,...
Yeah, this round looked good otherwise. Will amend in-place.
Thanks.
--
To unsubscribe
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.fr/~moy/
--
To unsubscribe from this li
Matthieu Moy writes:
> To me, the series is ready now, and I don't think re-rolling it would be
> a good time investment. Plus, I spent time reviewing this series and
> with my proposal I'd need to review a relatively different one.
Ok, thanks.
--
To unsubscribe from this list: send the line "un
Karthik Nayak writes:
> +/*
> + * Given a ref (sha1, refname) see if it points to a one of the sha1s
> + * in a sha1_array.
> + */
> +static int match_points_at(struct sha1_array *points_at, const unsigned char
> *sha1,
> +const char *refname)
> +{
> + struct object *
Mike Rappazzo writes:
> On Mon, Jun 8, 2015 at 11:28 AM, Junio C Hamano wrote:
>
>> This is optional, but I still wonder why the command line cannot be
>> more like this, though:
>>
>> format=$(git config --get rebase.insnFormat)
>> git log --format="%H ${format-%s}" --reverse --
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 */
> +void ref_array_clear(struct ref_array *array)
Is this a private fu
On 06/08/2015 10:45 PM, Matthieu Moy wrote:
Karthik Nayak writes:
> Version four of this patch can be found here :
> http://www.mail-archive.com/git@vger.kernel.org/msg70280.html
>
> v5 : http://www.mail-archive.com/git@vger.kernel.org/msg70888.html
>
> Changes in v5:
> *Rename functions to
Karthik Nayak writes:
> Version four of this patch can be found here :
> http://www.mail-archive.com/git@vger.kernel.org/msg70280.html
>
> v5 : http://www.mail-archive.com/git@vger.kernel.org/msg70888.html
>
> Changes in v5:
> *Rename functions to better suit the code.
> *implement filter
On Mon, Jun 8, 2015 at 8:48 AM, Paul Tan wrote:
> git-mailsplit, which splits mbox patches, will read the patch from stdin
> when the filename is "-" or there are no files listed on the
> command-line.
>
> To be consistent with this behavior, teach the mercurial patch parser to
> read from stdin i
On 06/08/2015 10:38 PM, Matthieu Moy wrote:
Karthik Nayak writes:
> --- a/builtin/for-each-ref.c
> +++ b/builtin/for-each-ref.c
> @@ -1129,7 +56,7 @@ int cmd_for_each_ref(int argc, const char **argv, const
char *prefix)
>
> memset(&ref_cbdata, 0, sizeof(ref_cbdata));
> ref_cbdata.f
On Mon, Jun 08, 2015 at 09:57:04AM -0700, Stefan Beller wrote:
> On Mon, Jun 8, 2015 at 4:45 AM, Michael Haggerty wrote:
> > This will result in errors being emitted for references that can't be
> > deleted, but that is a good thing.
>
> This sounds a bit like hand-waving to me. "Trust me, I'm a
Karthik Nayak writes:
> --- a/builtin/for-each-ref.c
> +++ b/builtin/for-each-ref.c
> @@ -1129,7 +56,7 @@ int cmd_for_each_ref(int argc, const char **argv, const
> char *prefix)
>
> memset(&ref_cbdata, 0, sizeof(ref_cbdata));
> ref_cbdata.filter.name_patterns = argv;
> - for_ea
Hi Peff,
On 2015-06-08 18:56, Jeff King wrote:
> On Mon, Jun 08, 2015 at 06:00:09PM +0200, Johannes Schindelin wrote:
>
>> >> I like the idea, but I am a bit uncertain whether it would constitute
>> >> "too backwards-incompatible" a change to make this an error. I think
>> >> it could be argued b
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 */
>>> > +void ref_array_clear(struct ref_array *array)
>>>
>>> Is this a private function? If so, then add static. If no
On Sat, Jun 6, 2015 at 4:46 AM, Paul Tan wrote:
> Currently git-am attempts to clean up the index/worktree when skipping or
> aborting, but does not do it very well:
>
> * While it discards conflicted index entries, it does not remove any other
> modifications made to the index due to a previous
On Mon, Jun 8, 2015 at 4:45 AM, Michael Haggerty wrote:
> Add functions to the reference API to
>
> * Delete a bunch of references at once, but *without* failing the
> whole transaction if one of the deletions fails. This functionality
> is used by `git remote remove` and `git remote prune`.
>
On Mon, Jun 8, 2015 at 4:45 AM, Michael Haggerty wrote:
> This will result in errors being emitted for references that can't be
> deleted, but that is a good thing.
This sounds a bit like hand-waving to me. "Trust me, I'm an engineer!".
>
> Signed-off-by: Michael Haggerty
> ---
> builtin/remo
On Mon, Jun 08, 2015 at 06:00:09PM +0200, Johannes Schindelin wrote:
> >> I like the idea, but I am a bit uncertain whether it would constitute
> >> "too backwards-incompatible" a change to make this an error. I think
> >> it could be argued both ways: it *is* an improvement, but it could
> >> als
On Mon, Jun 8, 2015 at 4:45 AM, Michael Haggerty wrote:
> delete_ref() uses a different convention for its old_sha1 parameter
> than, say, ref_transaction_delete(): NULL_SHA1 means not to check the
> old value. Make this fact a little bit clearer in the code by handling
> it in explicit, commented
On Mon, Jun 8, 2015 at 4:45 AM, Michael Haggerty wrote:
> This string is going to have to be re-internationalized anyway because
> of the previous commit. So while we're at it, we might as well convert
> it to lower case as per our usual practice.
Although the previous patch and this are addressi
On Mon, Jun 8, 2015 at 4:45 AM, Michael Haggerty wrote:
> Also
>
> * Add a docstring
>
> * Rename the second parameter to "old_sha1", to be consistent with the
> convention used elsewhere in the refs module
>
> Signed-off-by: Michael Haggerty
> ---
> cache.h | 2 --
> refs.c | 5 +++--
> refs
Nguyễn Thái Ngọc Duy writes:
> Before this change, t7063.17 fails. The actual action though happens at
> t7063.16 where the entry "two" is added back to index after being
> removed in the .13. Here we expect a directory invalidate at .16 and
> none at .17 where untracked cache is refreshed. But
On Mon, Jun 8, 2015 at 4:45 AM, Michael Haggerty wrote:
> Signed-off-by: Michael Haggerty
Found-to-be-Obviously-Correct-by: Stefan Beller ;)
> ---
> builtin/remote.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/builtin/remote.c b/builtin/remote.c
> index f4a6ec9..
Will Palmer writes:
> - * For future extension, ':/!' is reserved. If you want to match a message
> - * beginning with a '!', you have to repeat the exclamation mark.
> + * For negative-matching, prefix the pattern-part with '!-', like: ':/!-WIP'.
> + *
> + * For a literal '!' character at the be
Precisely, Junio, that's what I had in mind. The patch with the two
lines deleted LGTM.
--
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
Quoting Junio C Hamano :
SZEDER Gábor writes:
The diff and submodule shortlog appended to the commit message template
by 'git commit --verbose' are not stripped when the commit message
contains an indented scissors line.
When cleaning up a commit message with 'git commit --verbose' or
'--cl
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, then add static. If not, you probably
>> want to export
Karthik Nayak writes:
> I put these two together as they are trivial changes.
> Either I could reword the commit message or split the commit.
I'd split the commit. Actually, even though it's only a small comment
change, it's not so "trivial" in the sense that one needs a good
understanding of th
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.
>>
>> I would have found the series easier to read
Please, include a version number in the subject. git send-email -v2 does
this for you.
Guillaume Pagès writes:
> +static void show_rebase_information(struct wt_status *s,
> + struct wt_status_state *state,
> + const char *color)
> +
Max Kirillov writes:
> It is an allowed compile-time option to build git without iconv
> support. Resulting build almost always functions correctly, and
> never displays that it is missing anything, but reencode_string_len()
> just never modifies its input.
Correct.
> This gives undesirable res
On Mon, 8 Jun 2015 9:45:17 -0500
wrote:
[...]
> My question is, will GIT work with MS access forms, queries, tables,
> modules, etc?
[...]
Git works with files. So in principle it will work with *files*
containing your MS access stuff.
But Git will consider and treat those files as opaque blob
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.
>
> I would have found the series easier to read if this refactoring came
> earlier
Lex Spoon writes:
> Unless I am reading something wrong, the "new_changes" variable could
> be dropped now. It was needed for the -m version for detecting the
> smallest change number that was returned. Otherwise it looks good to
> me.
Meaning that I should squash this in to 3/3, right?
diff
On Mon, Jun 8, 2015 at 11:28 AM, Junio C Hamano wrote:
> Michael Rappazzo writes:
>
>> A config option 'rebase.instructionFormat' can override the
>> default 'oneline' format of the rebase instruction list.
>>
>> Since the list is parsed using the left, right or boundary mark plus
>> the sha1, th
Hi Michael,
On 2015-06-08 17:09, Michael Haggerty wrote:
> On 06/08/2015 04:27 PM, Johannes Schindelin wrote:
>> On 2015-06-08 08:40, Michael Haggerty wrote:
>>> Previously, if a reflog entry's old or new SHA-1 was not resolvable
>>> to an object, that SHA-1 was silently ignored. Instead, report s
git-mailsplit, which splits mbox patches, will read the patch from stdin
when the filename is "-" or there are no files listed on the
command-line.
To be consistent with this behavior, teach the mercurial patch parser to
read from stdin if the filename is "-" or no files are listed on the
command-
An example of the line in a mercurial patch that specifies the date of
the commit would be:
# Date 1433753301 25200
where the first number is the number of seconds since the unix epoch (in
UTC), and the second number is the offset of the timezone, in second s
west of UTC (negative if the
By default, an StGit patch separates the subject from the commit message
and headers as follows:
$subject
From: $author_name <$author_email>
$message
---
$diffstats
We test git-am's ability to detect such a patch as an StGit patch, and
its ability to be a
A StGit series is a directory containing a "series" file which begins
with the line:
# This series applies on GIT commit X
where X is the commit ID that the patch series applies on. Every
following line names a patch in the directory to be applied.
Test that git-am, when given th
git-mailsplit, which splits mbox patches, will read the patch from stdin
when the filename is "-" or there are no files listed on the
command-line.
To be consistent with this behavior, teach the StGit patch parser to
read from stdin if the filename is "-" or no files are listed on the
command-line
git-am is able to parse StGit and mercurial patches. However, there are no
regression tests in the test suite for these patch formats, and there are some
small bugs as well:
* the mercurial and stgit patch parsers does not support reading from stdin
* the mercurial patch parser parsed the patch d
SZEDER Gábor writes:
> The diff and submodule shortlog appended to the commit message template
> by 'git commit --verbose' are not stripped when the commit message
> contains an indented scissors line.
>
> When cleaning up a commit message with 'git commit --verbose' or
> '--cleanup=scissors' the
Michael Rappazzo writes:
> A config option 'rebase.instructionFormat' can override the
> default 'oneline' format of the rebase instruction list.
>
> Since the list is parsed using the left, right or boundary mark plus
> the sha1, they are prepended to the instruction format.
>
> Signed-off-by: M
On 06/08/2015 08:07 PM, Matthieu Moy wrote:
Karthik Nayak writes:
In 'grab_single_ref()' remove the extra count variable 'cnt' and
use the variable 'grab_cnt' of structure 'grab_ref_cbdata' directly
instead.
Change comment in 'struct ref_sort' to reflect changes in code.
I don't see how the
Dear Thomas,
Unfortunatly for me i cannot send the files, since there are
restrictions, but thanks for your offer.
At the moment also configuring the repo with --shared=all is not
helping, but i could try to reproduce the problem with a fake repo
shared between windows and linux and see if i get
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, then add static. If not, you probably
want to export it in a .h file.
It is in ref-filter.h.
1 - 100 of 157 matches
Mail list logo
