Re: git-apply: warn/fail on *changed* end of line (eol) *only*?
Igor Djordjevic BugA writes: > In short -- git-apply warns on applying the patch with CRLF line endings > (new), considered whitespace errors, even when previous hunk version > (old) has/had that very same CRLF line endings, too, so nothing actually > changed in this regards. Even worse, it happily applies a patch with LF > line endings (new) without any warning/hint, even though previous (old) > line endings were CRLF, thus effectively (and silently) breaking the > (previous) line endings. Let me see if I understood your problem description correctly. Imagine that the project wants LF line endings, i.e. it considers that a line with CRLF ending has an unwanted "whitespace" at the end. Now, you start from this source file: 1 3 5 and a patch like this comes in: 1 -3 +three 5 You think that "3 " was replaced by "three ", and the claim is "the 'previous' contents already had ending, so the change is not making things worse". But what if the patch was like this? 1 -3 +three +four 5 Do you want to warn on "four " because it does not have any "previous" corresponding line? Extending the thought further, which line do you want to warn and which line do you not want to, if the patch were like this instead? 1 -3 +four +three 5 Extending this thought experiment further, you would realize that fundamentally the concept of "previous contents" has no sensible definition. Incidentally, not realizing "there is no sensible definition of 'previous contents'" is a source of another often seen confusion by new users of Git and any version control systems regarding the "blame" feature. When given the final answer by "blame", they often say "what content did the line have _before_ the commit blame gave me?" As there is no sensible definition of 'previous contents' that corresponds to the line, that question does not in general have a sensible answer.
Re: git-apply: warn/fail on *changed* end of line (eol) *only*?
On 26/12/2016 00:49, Igor Djordjevic BugA wrote: > This is a follow-up of a message posted at git-users Google group[1], > as the topic may actually be better suited for this mailing list > instead. If needed, some elaboration on the context can be found there, > as well as a detailed example describing the motive for the question > itself (or directly here[2], second half of the message). For some reason reference links got excluded, so here they are again: [1] https://groups.google.com/d/msg/git-users/9Os_48yJdn0/j9S_W7h-EAAJ [2] https://groups.google.com/d/msg/git-users/9Os_48yJdn0/5S9Ja1fEEAAJ
git-apply: warn/fail on *changed* end of line (eol) *only*?
Hi to all, This is a follow-up of a message posted at git-users Google group[1], as the topic may actually be better suited for this mailing list instead. If needed, some elaboration on the context can be found there, as well as a detailed example describing the motive for the question itself (or directly here[2], second half of the message). In short -- git-apply warns on applying the patch with CRLF line endings (new), considered whitespace errors, even when previous hunk version (old) has/had that very same CRLF line endings, too, so nothing actually changed in this regards. Even worse, it happily applies a patch with LF line endings (new) without any warning/hint, even though previous (old) line endings were CRLF, thus effectively (and silently) breaking the (previous) line endings. I understand that what should be considered "correct" line endings can be set explicitly (and should be communicated on the project level in the first place), but would it make sense to have an additional git-apply --whitespace option (like "warn-changed" and "error-changed", or something) to warn/fail on *changed* end of line *only*, without any further knowledge needed? So not to have Git need to assume or know which line endings should be considered "correct", nor to think/bother too much with it, but just to warn/fail on actual line ending *change* (in comparison between old and new part/hunk of the patch). This seems more intuitive to me, and much more cross-platform collaboration friendly, at least as an option, as one wouldn`t need to think much about "correct" project/file line endings (which would still be advised, anyway), but would be promptly warned about possibly breaking previous/existing line endings, maybe even with an option to keep those previous ones, or force the new ones... yet as I`m still new around, I accept that I might be missing some bigger picture here :) Thanks, BugA P.S. I`m discussing git-apply and end-of-line handling here in particular as that`s what I`m currently concerned with, and for the sake of simplicity, but might be that whole thing could theoretically be broadened to other Git tools (like git-diff) and whitespace (error) handling in general, too (warn/fail only if actually introduced in new hunk, not previously being present in the old one). -- [1] https://groups.google.com/d/msg/git-users/9Os_48yJdn0/j9S_W7h-EAAJ [2] https://groups.google.com/d/msg/git-users/9Os_48yJdn0/5S9Ja1fEEAAJ
Re: [PATCH v2] log --graph: customize the graph lines with config log.graphColors
Nguyễn Thái Ngọc Duy writes:
> Sounds like the good first step should be something like this instead
> of jumping straight to generating a new color palette automatically.
I like this not merely as a good first step but potentially a good
endgame.
> diff --git a/graph.c b/graph.c
> index d4e8519..9c58fd1 100644
> --- a/graph.c
> +++ b/graph.c
> @@ -79,6 +79,39 @@ static void graph_show_line_prefix(const struct
> diff_options *diffopt)
> static const char **column_colors;
> static unsigned short column_colors_max;
>
> +static void set_column_colors_by_config(void)
> +{
> + static char **colors;
> + static int colors_max, colors_alloc;
I doubt you want these to be static (and allow multiple instances of
the same configuration variable to accumulate). As you defined the
value to be comma-separated colors, users would want the usual "last
one wins" rule to override previous settings, no?
> + char *string = NULL;
> + const char *end, *start;
> +
> + if (git_config_get_string("log.graphcolors", &string)) {
> + graph_set_column_colors(column_colors_ansi,
> + column_colors_ansi_max);
On the other hand, if you do want cumulative semantics, then you'd
need to free the previous set you held in the statics here, I would
think.
> + return;
> + }
> +
> + start = string;
> + end = string + strlen(string);
> + while (start < end) {
> + const char *comma = strchrnul(start, ',');
> + char color[COLOR_MAXLEN];
> +
> + if (!color_parse_mem(start, comma - start, color)) {
> + ALLOC_GROW(colors, colors_max + 1, colors_alloc);
> + colors[colors_max++] = xstrdup(color);
> + } else
> + warning(_("ignore invalid color '%.*s'"),
> + (int)(comma - start), start);
"ignore invalid color"? Who is giving the command to ignore to whom?
> + start = comma + 1;
> + }
> + free(string);
> + ALLOC_GROW(colors, colors_max + 1, colors_alloc);
> + colors[colors_max] = xstrdup(GIT_COLOR_RESET);
> + graph_set_column_colors((const char **)colors, colors_max);
> +}
> +
> void graph_set_column_colors(const char **colors, unsigned short colors_max)
> {
> column_colors = colors;
> @@ -239,8 +272,7 @@ struct git_graph *graph_init(struct rev_info *opt)
> struct git_graph *graph = xmalloc(sizeof(struct git_graph));
>
> if (!column_colors)
> - graph_set_column_colors(column_colors_ansi,
> - column_colors_ansi_max);
> + set_column_colors_by_config();
"by" in the function name somehow sounds funny, at least to me.
[PATCH] gitk: use right colour for remote refs in the "Tags and heads" dialog
Makes it easier to see which refs are local and which refs are remote.
Adds consistency with the remote background colour in the graph display.
Signed-off-by: Paul Wise
---
gitk-git/gitk | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 805a1c703..8d2868148 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -3399,6 +3399,8 @@ set rectmask {
}
image create bitmap reficon-H -background black -foreground lime \
-data $rectdata -maskdata $rectmask
+image create bitmap reficon-R -background black -foreground "#ffddaa" \
+-data $rectdata -maskdata $rectmask
image create bitmap reficon-o -background black -foreground "#ff" \
-data $rectdata -maskdata $rectmask
@@ -9908,6 +9910,7 @@ proc sel_reflist {w x y} {
set n [lindex $ref 0]
switch -- [lindex $ref 1] {
"H" {selbyid $headids($n)}
+ "R" {selbyid $headids($n)}
"T" {selbyid $tagids($n)}
"o" {selbyid $otherrefids($n)}
}
@@ -9937,7 +9940,11 @@ proc refill_reflist {} {
foreach n [array names headids] {
if {[string match $reflistfilter $n]} {
if {[commitinview $headids($n) $curview]} {
- lappend refs [list $n H]
+ if {[string match "remotes/*" $n]} {
+ lappend refs [list $n R]
+ } else {
+ lappend refs [list $n H]
+ }
} else {
interestedin $headids($n) {run refill_reflist}
}
--
2.11.0
git blame while resolving merge conflicts
I often rebase a large open source project and there are merge conflicts where I need to figure out who made the change and when it order to decide as to which change to take. So generally what I do is that I go to both repos and look at the file and do a git blame. Is there a mergetool that will provide this info during conflict resolution. I would like to know who made and this change and when for each version. Right now I am using meld. -- Thanks, Salil "The surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us."
