* Re: [Q] merging from one (kernel) stable to another?
From: Ping Yin @ 2009-03-30 15:20 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Brian Foster, git mailing list
In-Reply-To: <49D09207.9080407@op5.se>
On Mon, Mar 30, 2009 at 5:33 PM, Andreas Ericsson <ae@op5.se> wrote:
> Brian Foster wrote:
>>
>> Whilst this question involves linux(-mips) kernel tree,
>> it's a git(-related?) question, not a kernel question ....
>>
>> We are currently in the process of upgrading our embedded
>> system from kernel 2.6.21(-ish) to at least 2.6.26.8; and
>> later, at some time in the future on to 2.6.3x or something.
>> Going from 2.6.21 to .22 to .23 and so on to .26, then to
>> .26.1 and so on to .26.8 is “easy” in the sense there are
>> very few conflicts with our existing baseline (e.g., just
>> 2 or 3 in 2 or 3 files).
>>
>> .21 --> me --> .22 --> .23 ... --> .26 --> .27 --> master
>> \ \ \ \ \
>> .21-stable .22-stable .23-stable \ .27-stable
>> .26.8
>> \
>> .26-stable
>>
>> But (using 2.6.21-stable and 2.6.22-stable as proxies),
>> tests indicate that going from .26.8 to .27 or anything
>> later will have numerous conflicts (100s? in more than
>> 30 files). Thinking about it, this isn't too surprising
>> since the -stable branches cherry-pick important/benign
>> fixes from later revisions.
>>
>> What's frustrating is that in essentially all “conflict”
>> cases, the resolution is simple: Use the later version.
>
> The trouble is "essentially all", as opposed to "all". Git
> can never know which of the conflicts are which, so it will
> leave it all up to you.
>
> A possibly better approach for you is to "git format-patch"
> your own changes and apply them to a clean 2.6.26.8 tree
> instead of trying to merge 2.6.26.8 into 2.6.21.
Or just (say, always use rebase instead of merge)
git rebase -i 2.6.26.8 --onto 2.6.27
^ permalink raw reply
* [PATCH] Build RPMs locally unless overruled in ~/.rpmmacros
From: Niels Basjes @ 2009-03-30 15:10 UTC (permalink / raw)
To: git; +Cc: Niels Basjes
From: Niels Basjes <niels@basjes.nl>
Signed-off-by: Niels Basjes <niels@basjes.nl>
---
.gitignore | 1 +
Makefile | 8 +++++++-
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/.gitignore b/.gitignore
index 1c57d4c..2f2554b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -173,3 +173,4 @@ configure
tags
TAGS
cscope*
+RPM_BUILDING
diff --git a/Makefile b/Makefile
index 7867eac..ad5a1f7 100644
--- a/Makefile
+++ b/Makefile
@@ -242,7 +242,13 @@ RM = rm -f
TAR = tar
FIND = find
INSTALL = install
-RPMBUILD = rpmbuild
+RPMBUILDOPTS = $(shell if [ "`grep '^%_topdir' $(HOME)/.rpmmacros`" == "" ]; \
+ then \
+ mkdir -p RPM_BUILDING/{BUILD,RPMS,SOURCES,SPECS,SRPMS}; \
+ echo '--define="_topdir `pwd`/RPM_BUILDING"' ; \
+ fi \
+ )
+RPMBUILD = rpmbuild $(RPMBUILDOPTS)
TCL_PATH = tclsh
TCLTK_PATH = wish
PTHREAD_LIBS = -lpthread
--
1.6.1.3
^ permalink raw reply related
* Re: [PATCHv2 4/4] Rename push.default to push.mode
From: Michael J Gruber @ 2009-03-30 14:47 UTC (permalink / raw)
To: Jeff King; +Cc: Santi Béjar, git
In-Reply-To: <20090330134544.GA31827@coredump.intra.peff.net>
Jeff King venit, vidit, dixit 30.03.2009 15:45:
> On Mon, Mar 30, 2009 at 03:06:00PM +0200, Michael J Gruber wrote:
>
>>> I don't see the quoted-printable characters, I see them in utf-8 and 8bit.
>>>
>>> Content-Type: text/plain; charset=utf-8
>>> Content-Transfer-Encoding: 8bit
>>>
>>> Maybe some server in between is recoding it.
>>
>> That's weird. I read through gmane/nntp, but others' posts are fine.
>> Yours have
>>
>> Content-Type: text/plain; charset=utf-8
>> Content-Transfer-Encoding: QUOTED-PRINTABLE
>
> If a subscriber's mailserver does not support the 8BITMIME SMTP
> extension, then vger will (correctly) encode an 8bit message as QP.
> Gmane's mailservers do not seem to support 8BITMIME.
>
> You see it only with Santi's message because most messages are already
> 7bit clean; however, the accent in his name requires git to mark it as
> 8-bit.
Thanks for the explanation! I rechecked, and for sure it also happened
with patches from Tor Arne Vestbø and Nguyễn Thái Ngọc Duy.
Again I feel blessed by my umlautlessness... and challenged by gmane.
About time to ditch it for reading patches also, or at least to be aware
of it when saving patches.
Michael
^ permalink raw reply
* Re: [PATCH 1/2] send-email: refactor and ensure prompting doesn't loop forever
From: Matthieu Moy @ 2009-03-30 14:40 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Junio C Hamano
In-Reply-To: <76718490903300717x5cc5e33ax1cf91471efd242bd@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> On Mon, Mar 30, 2009 at 7:29 AM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
>
> perl send-email ... 2>/dev/null :-)
>
> Seriously though, I am unable to reproduce the messages you are
> getting from Term::ReadLine, and I tried really hard.
Anyway, as I said, the warnings do not harm. They just appear messy in
my log files, but it's really a matter of polishing the UI.
> What does:
>
> $ perl -e 'use Term::ReadLine; print "$Term::ReadLine::VERSION\n"'
$ perl -e 'use Term::ReadLine; print "$Term::ReadLine::VERSION\n"'
1.02
$
That's Debian oldstable (etch), so perhaps newer versions fixed the
problem.
Thanks again,
--
Matthieu
^ permalink raw reply
* Re: [PATCH] Fix bash completion in path with spaces
From: Shawn O. Pearce @ 2009-03-30 14:39 UTC (permalink / raw)
To: Daniel Cheng (aka SDiZ); +Cc: gitster, git
In-Reply-To: <1238412457-29674-1-git-send-email-j16sdiz+freenet@gmail.com>
"Daniel Cheng (aka SDiZ)" <j16sdiz+freenet@gmail.com> wrote:
>
> Signed-off-by: Daniel Cheng (aka SDiZ) <j16sdiz+freenet@gmail.com>
Trivially-acked-by: Shawn O. Pearce <spearce@spearce.org>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 1c6b0e2..e72ce24 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -1103,7 +1103,7 @@ _git_log ()
> local cur="${COMP_WORDS[COMP_CWORD]}"
> local g="$(git rev-parse --git-dir 2>/dev/null)"
> local merge=""
> - if [ -f $g/MERGE_HEAD ]; then
> + if [ -f "$g/MERGE_HEAD" ]; then
> merge="--merge"
> fi
> case "$cur" in
> @@ -1943,7 +1943,7 @@ _gitk ()
> local cur="${COMP_WORDS[COMP_CWORD]}"
> local g="$(__gitdir)"
> local merge=""
> - if [ -f $g/MERGE_HEAD ]; then
> + if [ -f "$g/MERGE_HEAD" ]; then
> merge="--merge"
> fi
> case "$cur" in
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-gui: run post-checkout hook on checkout
From: Shawn O. Pearce @ 2009-03-30 14:34 UTC (permalink / raw)
To: Jens Lehmann; +Cc: git, gitster, peff
In-Reply-To: <49CAB4C1.6070004@web.de>
Jens Lehmann <Jens.Lehmann@web.de> wrote:
> It's been a while since i deeply touched tcl/tk code ... i basically
> adapted the code for calling the post-commit hook here.
Not bad for not having touched tcl/tk in a long time... :-)
> + # -- Run the post-checkout hook.
> + #
> + set fd_ph [githook_read post-checkout $old_hash $new_hash 1]
> + if {$fd_ph ne {}} {
> + upvar #0 pch_error pc_err
I'd rather spell this "global pch_error".
> + set pc_err {}
> + fconfigure $fd_ph -blocking 0 -translation binary -eofchar {}
> + fileevent $fd_ph readable \
> + [list checkout_postcheckout_wait $fd_ph $this]
The callback should be "[cb _postcheckout_wait $fd_ph]". This is
a git-gui macro which returns a handle to invoke a "method" named
"_postcheckout_wait", passing in $this as the first parameter.
> +proc checkout_postcheckout_wait {fd_ph t} {
This should be "method _postcheckout_wait {fd_ph} {" to use the
cb macro above, and have $this automatically carry through.
> + upvar #0 pch_error pch_error
"global pch_error"
> + append pch_error [read $fd_ph]
> + fconfigure $fd_ph -blocking 1
> + if {[eof $fd_ph]} {
> + if {[catch {close $fd_ph}]} {
> + hook_failed_popup post-checkout $pch_error 0
> + }
> + unset pch_error
> + delete_this $t
> + return
> + }
> + fconfigure $fd_ph -blocking 0
Also, I'm wondering about the UI state semantics here. Back on
line 462 (in the preimage) we unlock_index, which means that the
user can start to push buttons again, and then later on around
line 474 you start up the post-checkout hook.
I think we'd want to defer the unlock_index call until after the
hook has terminated, if we are going to run a hook at all. In fact,
we probably need to move that entire block 462-474 (the unlock_index
... delete_this block) to a new method which we invoke if there is
no hook, or after the hook subprocess terminates.
By waiting until after the hook to do the rescan, we also ensure
that the hook has a chance to update the working directory, perhaps
by dirtying a file, and the user seeing the result of that dirtying
immediately.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/2] send-email: refactor and ensure prompting doesn't loop forever
From: Jay Soffian @ 2009-03-30 14:18 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, Junio C Hamano
In-Reply-To: <76718490903300717x5cc5e33ax1cf91471efd242bd@mail.gmail.com>
On Mon, Mar 30, 2009 at 10:17 AM, Jay Soffian <jaysoffian@gmail.com> wrote:
> perl send-email ... 2>/dev/null :-)
Hmfph, perl on the mind. That should of course be "git send-email ...
2>/dev/null" but it was only a half-serious suggestion anyway.
j.
^ permalink raw reply
* Re: [PATCH 1/2] send-email: refactor and ensure prompting doesn't loop forever
From: Jay Soffian @ 2009-03-30 14:17 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, Junio C Hamano
In-Reply-To: <vpqd4bzjlk1.fsf@bauges.imag.fr>
On Mon, Mar 30, 2009 at 7:29 AM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> Minor problem: I still (harmless) get error messages in my log:
>
> print() on closed filehandle FOUT at /usr/share/perl/5.8/Term/ReadLine.pm line 193.
> readline() on closed filehandle FIN at /usr/share/perl/5.8/Term/ReadLine.pm line 395.
> print() on closed filehandle FOUT at /usr/share/perl/5.8/Term/ReadLine.pm line 203.
>
> But I can very well live with them!
perl send-email ... 2>/dev/null :-)
Seriously though, I am unable to reproduce the messages you are
getting from Term::ReadLine, and I tried really hard.
What does:
$ perl -e 'use Term::ReadLine; print "$Term::ReadLine::VERSION\n"'
tell you?
Also, thank you for confirming the fix.
j.
^ permalink raw reply
* Re: [PATCH] git-gui: make "Git GUI Here" Explorer extension more robust
From: Shawn O. Pearce @ 2009-03-30 14:15 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: Johannes Schindelin, msysgit, git
In-Reply-To: <200903300851.43164.markus.heidelberg@web.de>
Markus Heidelberg <markus.heidelberg@web.de> wrote:
>
> But I just noticed, that it will obviously "cd .." forever, if no .git/
> was found. Somehow the root directory has to be catched.
Yup. I'm dropping this patch for now because of this issue, but
I'll look at it again if its addressed in another version. :-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-gui: make "Git GUI Here" Explorer extension more robust
From: Shawn O. Pearce @ 2009-03-30 14:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Markus Heidelberg, msysgit, git
In-Reply-To: <alpine.DEB.1.00.0903301001090.7534@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Mon, 30 Mar 2009, Markus Heidelberg wrote:
> > Johannes Schindelin, 30.03.2009:
> > > And with bare repositories?
> >
> > Git-gui doesn't seem to work with bare repositories, I get
> > "Cannot use funny .git directory: ."
> > when started on the command line.
>
> Oh? I thought there was some discussion recently that was explicitely
> about git gui with bare repositories. But I have to time-share my brain
> these days, so my memory might well show some bit flips.
At best, you can get blame to run on a bare repository, but that's
it. Most of the git-gui UI is designed for viewing the status of
the working tree, or manipulating the index and/or files in that
working tree. There are fairly good reasons why it doesn't work
on a bare repository.
Of course, fetch/push would be fine a bare repository, but I consider
that use case to be not worth the cost it would be in code to make
it possible. We'd have to if out huge blocks of git-gui code,
maybe 80%+ of git-gui.sh, and that script is already hairy enough
(3477 lines).
--
Shawn.
^ permalink raw reply
* [PATCH] Documentation: update graph api example.
From: Allan Caffee @ 2009-03-30 14:13 UTC (permalink / raw)
To: git
As of commit 03300c0 the graph API uses '*' for all nodes including merges.
This updates the example in the documentation to match.
Signed-off-by: Allan Caffee <allan.caffee@gmail.com>
---
Documentation/technical/api-history-graph.txt | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/technical/api-history-graph.txt b/Documentation/technical/api-history-graph.txt
index e955979..d66e61b 100644
--- a/Documentation/technical/api-history-graph.txt
+++ b/Documentation/technical/api-history-graph.txt
@@ -148,22 +148,22 @@ outputting that information, if desired.
------------
*
*
-M
+*
|\
* |
| | *
| \ \
| \ \
-M-. \ \
+*-. \ \
|\ \ \ \
| | * | |
| | | | | *
| | | | | *
-| | | | | M
+| | | | | *
| | | | | |\
| | | | | | *
| * | | | | |
-| | | | | M \
+| | | | | * \
| | | | | |\ |
| | | | * | | |
| | | | * | | |
--
1.5.4.3
^ permalink raw reply related
* [RFC/PATCH] graph API: Added logic for colored edges.
From: Allan Caffee @ 2009-03-30 14:13 UTC (permalink / raw)
To: git; +Cc: Jeff King, Nanako Shiraishi, Johannes Schindelin
In-Reply-To: <20090321175726.GA6677@linux.vnet>
Modified the graph drawing logic to colorize edges based on parent-child
relationships similiarly to gitk.
Signed-off-by: Allan Caffee <allan.caffee@gmail.com>
---
I havn't gotten the chance to do any of the color clean up that's been
discussed on this thread. I'll try to throw something together in a seperate
patch series.
Also this patch isn't respecting the --no-color option which I imagine means
that diff_use_color_default isn't the right variable to be checking. Johannes
mentioned using diff_use_color but the only instance I see is a parameter to
diff_get_color. What am I missing?
~Allan
color.h | 1 +
graph.c | 167 ++++++++++++++++++++++++++++++++++++++++++++++++++++++---------
2 files changed, 144 insertions(+), 24 deletions(-)
diff --git a/color.h b/color.h
index 6846be1..18abeb7 100644
--- a/color.h
+++ b/color.h
@@ -11,6 +11,7 @@
#define GIT_COLOR_GREEN "\033[32m"
#define GIT_COLOR_YELLOW "\033[33m"
#define GIT_COLOR_BLUE "\033[34m"
+#define GIT_COLOR_MAGENTA "\033[35m"
#define GIT_COLOR_CYAN "\033[36m"
#define GIT_COLOR_BG_RED "\033[41m"
diff --git a/graph.c b/graph.c
index 162a516..2929c8b 100644
--- a/graph.c
+++ b/graph.c
@@ -1,9 +1,11 @@
#include "cache.h"
#include "commit.h"
+#include "color.h"
#include "graph.h"
#include "diff.h"
#include "revision.h"
+extern int diff_use_color_default;
/* Internal API */
/*
@@ -72,11 +74,22 @@ struct column {
*/
struct commit *commit;
/*
- * XXX: Once we add support for colors, struct column could also
- * contain the color of its branch line.
+ * The color to (optionally) print this column in.
*/
+ char *color;
};
+static void strbuf_write_column(struct strbuf *sb, const struct column *c,
+ const char *s);
+
+static char* get_current_column_color (const struct git_graph* graph);
+
+/*
+ * Update the default column color and return the new value.
+ */
+static char* get_next_column_color(struct git_graph* graph);
+
+
enum graph_state {
GRAPH_PADDING,
GRAPH_SKIP,
@@ -86,6 +99,24 @@ enum graph_state {
GRAPH_COLLAPSING
};
+/*
+ * The list of available column colors.
+ */
+static char column_colors[][COLOR_MAXLEN] = {
+ GIT_COLOR_RED,
+ GIT_COLOR_GREEN,
+ GIT_COLOR_YELLOW,
+ GIT_COLOR_BLUE,
+ GIT_COLOR_MAGENTA,
+ GIT_COLOR_CYAN,
+ GIT_COLOR_BOLD GIT_COLOR_RED,
+ GIT_COLOR_BOLD GIT_COLOR_GREEN,
+ GIT_COLOR_BOLD GIT_COLOR_YELLOW,
+ GIT_COLOR_BOLD GIT_COLOR_BLUE,
+ GIT_COLOR_BOLD GIT_COLOR_MAGENTA,
+ GIT_COLOR_BOLD GIT_COLOR_CYAN,
+};
+
struct git_graph {
/*
* The commit currently being processed
@@ -185,6 +216,11 @@ struct git_graph {
* temporary array each time we have to output a collapsing line.
*/
int *new_mapping;
+ /*
+ * The current default column color being used. This is
+ * stored as an index into the array column_colors.
+ */
+ short default_column_color;
};
struct git_graph *graph_init(struct rev_info *opt)
@@ -201,6 +237,7 @@ struct git_graph *graph_init(struct rev_info *opt)
graph->num_columns = 0;
graph->num_new_columns = 0;
graph->mapping_size = 0;
+ graph->default_column_color = 0;
/*
* Allocate a reasonably large default number of columns
@@ -317,6 +354,14 @@ static void graph_insert_into_new_columns(struct git_graph *graph,
int *mapping_index)
{
int i;
+ char *color = get_current_column_color(graph);
+
+ for (i = 0; i < graph->num_columns; i++) {
+ if (graph->columns[i].commit == commit) {
+ color = graph->columns[i].color;
+ break;
+ }
+ }
/*
* If the commit is already in the new_columns list, we don't need to
@@ -334,6 +379,8 @@ static void graph_insert_into_new_columns(struct git_graph *graph,
* This commit isn't already in new_columns. Add it.
*/
graph->new_columns[graph->num_new_columns].commit = commit;
+/* fprintf(stderr,"adding the %scommit%s\n", color, GIT_COLOR_RESET); */
+ graph->new_columns[graph->num_new_columns].color = color;
graph->mapping[*mapping_index] = graph->num_new_columns;
*mapping_index += 2;
graph->num_new_columns++;
@@ -445,6 +492,12 @@ static void graph_update_columns(struct git_graph *graph)
for (parent = first_interesting_parent(graph);
parent;
parent = next_interesting_parent(graph, parent)) {
+ /*
+ * If this is a merge increment the current
+ * color.
+ */
+ if (graph->num_parents > 1)
+ get_next_column_color(graph);
graph_insert_into_new_columns(graph,
parent->item,
&mapping_idx);
@@ -596,7 +649,7 @@ static void graph_output_padding_line(struct git_graph *graph,
* Output a padding row, that leaves all branch lines unchanged
*/
for (i = 0; i < graph->num_new_columns; i++) {
- strbuf_addstr(sb, "| ");
+ strbuf_write_column(sb, &graph->new_columns[i], "| ");
}
graph_pad_horizontally(graph, sb);
@@ -649,7 +702,10 @@ static void graph_output_pre_commit_line(struct git_graph *graph,
struct column *col = &graph->columns[i];
if (col->commit == graph->commit) {
seen_this = 1;
- strbuf_addf(sb, "| %*s", graph->expansion_row, "");
+ struct strbuf tmp = STRBUF_INIT;
+ strbuf_addf(&tmp, "| %*s", graph->expansion_row, "");
+ strbuf_write_column(sb, col, tmp.buf);
+ strbuf_release(&tmp);
} else if (seen_this && (graph->expansion_row == 0)) {
/*
* This is the first line of the pre-commit output.
@@ -662,13 +718,13 @@ static void graph_output_pre_commit_line(struct git_graph *graph,
*/
if (graph->prev_state == GRAPH_POST_MERGE &&
graph->prev_commit_index < i)
- strbuf_addstr(sb, "\\ ");
+ strbuf_write_column(sb, col, "\\ ");
else
- strbuf_addstr(sb, "| ");
+ strbuf_write_column(sb, col, "| ");
} else if (seen_this && (graph->expansion_row > 0)) {
- strbuf_addstr(sb, "\\ ");
+ strbuf_write_column(sb, col, "\\ ");
} else {
- strbuf_addstr(sb, "| ");
+ strbuf_write_column(sb, col, "| ");
}
}
@@ -728,6 +784,7 @@ static void graph_output_commit_line(struct git_graph *graph, struct strbuf *sb)
*/
seen_this = 0;
for (i = 0; i <= graph->num_columns; i++) {
+ struct column *col = &graph->columns[i];
struct commit *col_commit;
if (i == graph->num_columns) {
if (seen_this)
@@ -751,7 +808,7 @@ static void graph_output_commit_line(struct git_graph *graph, struct strbuf *sb)
strbuf_addstr(sb, ". ");
}
} else if (seen_this && (graph->num_parents > 2)) {
- strbuf_addstr(sb, "\\ ");
+ strbuf_write_column(sb, col, "\\ ");
} else if (seen_this && (graph->num_parents == 2)) {
/*
* This is a 2-way merge commit.
@@ -768,11 +825,11 @@ static void graph_output_commit_line(struct git_graph *graph, struct strbuf *sb)
*/
if (graph->prev_state == GRAPH_POST_MERGE &&
graph->prev_commit_index < i)
- strbuf_addstr(sb, "\\ ");
+ strbuf_write_column(sb, col, "\\ ");
else
- strbuf_addstr(sb, "| ");
+ strbuf_write_column(sb, col, "| ");
} else {
- strbuf_addstr(sb, "| ");
+ strbuf_write_column(sb, col, "| ");
}
}
@@ -789,6 +846,17 @@ static void graph_output_commit_line(struct git_graph *graph, struct strbuf *sb)
graph_update_state(graph, GRAPH_COLLAPSING);
}
+inline struct column* find_new_column_by_commit(struct git_graph *graph,
+ struct commit *commit)
+{
+ int i;
+ for (i = 0; i < graph->num_new_columns; i++) {
+ if (graph->new_columns[i].commit == commit)
+ return &graph->new_columns[i];
+ }
+ return 0;
+}
+
static void graph_output_post_merge_line(struct git_graph *graph, struct strbuf *sb)
{
int seen_this = 0;
@@ -798,24 +866,43 @@ static void graph_output_post_merge_line(struct git_graph *graph, struct strbuf
* Output the post-merge row
*/
for (i = 0; i <= graph->num_columns; i++) {
+ struct column *col = &graph->columns[i];
struct commit *col_commit;
if (i == graph->num_columns) {
if (seen_this)
break;
col_commit = graph->commit;
} else {
- col_commit = graph->columns[i].commit;
+ col_commit = col->commit;
}
if (col_commit == graph->commit) {
+ /*
+ * Since the current commit is a merge find
+ * the columns for the parent commits in
+ * new_columns and use those to format the
+ * edges.
+ */
+ struct commit_list *parents = NULL;
+ struct column *par_column;
seen_this = 1;
- strbuf_addch(sb, '|');
- for (j = 0; j < graph->num_parents - 1; j++)
- strbuf_addstr(sb, "\\ ");
+ parents = first_interesting_parent(graph);
+ assert(parents);
+ par_column = find_new_column_by_commit(graph,parents->item);
+ assert(par_column);
+
+ strbuf_write_column(sb, par_column, "|");
+ for (j = 0; j < graph->num_parents - 1; j++) {
+ parents = next_interesting_parent(graph, parents);
+ assert(parents);
+ par_column = find_new_column_by_commit(graph,parents->item);
+ assert(par_column);
+ strbuf_write_column(sb, par_column, "\\ ");
+ }
} else if (seen_this) {
- strbuf_addstr(sb, "\\ ");
+ strbuf_write_column(sb, col, "\\ ");
} else {
- strbuf_addstr(sb, "| ");
+ strbuf_write_column(sb, col, "| ");
}
}
@@ -834,6 +921,8 @@ static void graph_output_collapsing_line(struct git_graph *graph, struct strbuf
{
int i;
int *tmp_mapping;
+ static int collapsing_columns[255];
+ int collapsing_seen_so_far = 0;
/*
* Clear out the new_mapping array
@@ -912,9 +1001,11 @@ static void graph_output_collapsing_line(struct git_graph *graph, struct strbuf
if (target < 0)
strbuf_addch(sb, ' ');
else if (target * 2 == i)
- strbuf_addch(sb, '|');
- else
- strbuf_addch(sb, '/');
+ strbuf_write_column(sb, &graph->new_columns[target], "|");
+ else {
+ strbuf_write_column(sb, &graph->new_columns[target], "/");
+
+ }
}
graph_pad_horizontally(graph, sb);
@@ -979,9 +1070,10 @@ static void graph_padding_line(struct git_graph *graph, struct strbuf *sb)
* children that we have already processed.)
*/
for (i = 0; i < graph->num_columns; i++) {
- struct commit *col_commit = graph->columns[i].commit;
+ struct column *col = &graph->columns[i];
+ struct commit *col_commit = col->commit;
if (col_commit == graph->commit) {
- strbuf_addch(sb, '|');
+ strbuf_write_column(sb, col, "|");
if (graph->num_parents < 3)
strbuf_addch(sb, ' ');
@@ -991,7 +1083,7 @@ static void graph_padding_line(struct git_graph *graph, struct strbuf *sb)
strbuf_addch(sb, ' ');
}
} else {
- strbuf_addstr(sb, "| ");
+ strbuf_write_column(sb, col, "| ");
}
}
@@ -1154,3 +1246,30 @@ void graph_show_commit_msg(struct git_graph *graph,
putchar('\n');
}
}
+
+static void strbuf_write_column(struct strbuf *sb, const struct column *c,
+ const char *s)
+{
+ /*
+ * TODO: I get the creeping suspicion that this isn't the
+ * right flag to be checking since --no-color doesn't turn
+ * this off.
+ */
+ if (diff_use_color_default)
+ strbuf_addstr(sb, c->color);
+ strbuf_addstr(sb, s);
+ if (diff_use_color_default)
+ strbuf_addstr(sb, GIT_COLOR_RESET);
+}
+
+static char* get_current_column_color (const struct git_graph* graph)
+{
+ return column_colors[graph->default_column_color];
+}
+
+static char* get_next_column_color(struct git_graph* graph)
+{
+ graph->default_column_color = (graph->default_column_color + 1) %
+ ARRAY_SIZE(column_colors);
+ return (get_current_column_color(graph));
+}
--
1.5.4.3
^ permalink raw reply related
* Re: [PATCH] git-gui: fix deleting from the context menu with empty selection
From: Shawn O. Pearce @ 2009-03-30 14:07 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: git
In-Reply-To: <200903291629.23736.markus.heidelberg@web.de>
Markus Heidelberg <markus.heidelberg@web.de> wrote:
> An "Application Error" was raised when trying to delete text from the
> commit message field when no text was selected.
Thanks.
> diff --git a/git-gui.sh b/git-gui.sh
> index 2f1f305..b3aa732 100755
> --- a/git-gui.sh
> +++ b/git-gui.sh
> @@ -2944,7 +2944,7 @@ $ctxm add command \
> -command {tk_textPaste $ui_comm}
> $ctxm add command \
> -label [mc Delete] \
> - -command {$ui_comm delete sel.first sel.last}
> + -command {catch {$ui_comm delete sel.first sel.last}}
> $ctxm add separator
> $ctxm add command \
> -label [mc "Select All"] \
--
Shawn.
^ permalink raw reply
* Re: [Q] merging from one (kernel) stable to another?
From: Andreas Ericsson @ 2009-03-30 13:52 UTC (permalink / raw)
To: Brian Foster; +Cc: Johannes Sixt, git mailing list
In-Reply-To: <200903301451.33956.brian.foster@innova-card.com>
Brian Foster wrote:
> On Monday 30 March 2009 14:19:11 Andreas Ericsson wrote:
>> Brian Foster wrote:
>
>>> (4) Tag the result `like-this';
>>> (5) Checkout our.21; and
>>> (6) Merge with `like-this'.
>> Merge is not necessary.
>
> <Shrugs/> I'll going to try in both ways (with and without
> merging) to better understand just what the results are like.
If you get the tree into the state you want and simply want to
connect the histories, you can do
git merge -s ours $other_branch
which will record the tree from the current commit as the tree
for the merge-commit (ie, all changes from $other_branch are
thrown away, and the merge always succeeds without conflicts).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: [PATCHv2 4/4] Rename push.default to push.mode
From: Jeff King @ 2009-03-30 13:45 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Santi Béjar, git
In-Reply-To: <49D0C3B8.2050801@drmicha.warpmail.net>
On Mon, Mar 30, 2009 at 03:06:00PM +0200, Michael J Gruber wrote:
> > I don't see the quoted-printable characters, I see them in utf-8 and 8bit.
> >
> > Content-Type: text/plain; charset=utf-8
> > Content-Transfer-Encoding: 8bit
> >
> > Maybe some server in between is recoding it.
>
> That's weird. I read through gmane/nntp, but others' posts are fine.
> Yours have
>
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: QUOTED-PRINTABLE
If a subscriber's mailserver does not support the 8BITMIME SMTP
extension, then vger will (correctly) encode an 8bit message as QP.
Gmane's mailservers do not seem to support 8BITMIME.
You see it only with Santi's message because most messages are already
7bit clean; however, the accent in his name requires git to mark it as
8-bit.
-Peff
^ permalink raw reply
* Re: [PATCHv2 4/4] Rename push.default to push.mode
From: Michael J Gruber @ 2009-03-30 13:06 UTC (permalink / raw)
To: Santi Béjar; +Cc: Michael J Gruber, git
In-Reply-To: <adf1fd3d0903300537i41d4aef3g49ab6bde9343cbc5@mail.gmail.com>
Santi Béjar venit, vidit, dixit 30.03.2009 14:37:
> 2009/3/30 Michael J Gruber <git@drmicha.warpmail.net>:
>> Santi Béjar venit, vidit, dixit 30.03.2009 12:11:
>>> push.default was too generic, and also didn't specify if it was about
>>> remote, refspec, branches, behaviour...
>>
>> I guess we go for US spelling here, so it's "behavior" ;)
>
> Ok.
>
>>> diff --git a/Documentation/config.txt b/Documentation/config.txt
>>> index 38ab785..80bb3a6 100644
>>> --- a/Documentation/config.txt
>>> +++ b/Documentation/config.txt
>>> @@ -480,7 +480,7 @@ branch.<name>.remote::
>>> branch.<name>.merge::
>>> It defines, together with branch.<name>.remote, the upstream branch
>>> for the given branch. It tells 'git-fetch'/'git-pull' which
>>> - branch to merge and can also afect 'git-push' (see push.default).
>>> + branch to merge and can also afect 'git-push' (see push.mode).
>>
>> s/afect/affect/
>>
>
> OK
>
>>
>> Your patches contain quoted-printable characters all over the place.
>
> I don't see the quoted-printable characters, I see them in utf-8 and 8bit.
>
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: 8bit
>
> Maybe some server in between is recoding it.
>
>> Are
>> they not sent with git send-email?
>
> They are send with git send-email and msmtp.
>
> Santi
That's weird. I read through gmane/nntp, but others' posts are fine.
Yours have
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
But as long as Junio gets them unmangled I don't mind.
OK, I checked the raw mail at marc. It's fine. So I guess it's a gmane
thing (or tb)... Sorry I bothered you.
Michael
^ permalink raw reply
* Re: [Q] merging from one (kernel) stable to another?
From: Brian Foster @ 2009-03-30 12:51 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Johannes Sixt, git mailing list
In-Reply-To: <49D0B8BF.2000502@op5.se>
On Monday 30 March 2009 14:19:11 Andreas Ericsson wrote:
> Brian Foster wrote:
> >[ ... ]
> > (1) Create a patch which is all (local) changes
> > (née diffs) from linux-mips.21 to our.21;
>
> This is wrong. Create several git-patches, each containing
> the equivalence of one commit (complete with diff, author
> info and commit message).
Yes, I was being sloppy there. Internally, we use both
`git format-patch' and `git am', but have a bad(?) habit
of referring to a patch series as “a patch”. Apologies
for the confusion. Sorry!
> > (2) Checkout linux-mips.26.8 (e.g.);
> > (3) Apply the patch created in (1), above;
>
> Except it'll be "apply the patches, re-creating history
> as if it had been done with a different base from the
> start".
Yes.
> > (4) Tag the result `like-this';
> > (5) Checkout our.21; and
> > (6) Merge with `like-this'.
>
> Merge is not necessary.
<Shrugs/> I'll going to try in both ways (with and without
merging) to better understand just what the results are like.
> > I admit that now that I write the steps out, it seems
> > to make sense ....? Am I understanding correctly?
>
> Almost. "git help format-patch" and "git help am" will get
> you the rest of the way, I think.
;-) Well, I did say “RTF<a named>M” is useful....!
Many thanks for your patient and very helpful replies.
cheers!
-blf-
--
“How many surrealists does it take to | Brian Foster
change a lightbulb? Three. One calms | somewhere in south of France
the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!
with brightly-coloured machine tools.” | http://www.stopesso.com
^ permalink raw reply
* Re: [PATCH 4/4] Rename push.default to push.style
From: Santi Béjar @ 2009-03-30 12:50 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Finn Arne Gangstad, git
In-Reply-To: <20090330102739.GA5163@sigill.intra.peff.net>
2009/3/30 Jeff King <peff@peff.net>:
> On Mon, Mar 30, 2009 at 11:00:03AM +0200, Santi Béjar wrote:
>
>> >> This configuration variable says what push should do
>> >> when no refspec is given and none are configured, so the word "default"
>> >> should be in there at least. Maybe "defaultref" would have been better?
>>
>> I don't see the point of the word default, a lot of configuration is
>> to set the default value. Git has branch.name.remote, not
>> branch.name.defaultremote, or user.email, not user.defaultemail,...
>
> The usual case is two layers of options: command line and config
> options. Thus "git push <remote>" overrides "branch.*.remote".
>
> But in this case there are actually _three_ layers: command line,
> branch.*.push, and now push.default. I think a name like "push.mode"
> doesn't make clear the fact that it will never be looked at if you have
> "branch.*.push" set up.
>
> I think you have a point that "default" is vague, but "defaultMode"
> would be better than simply "mode".
Thanks, it makes sense. Now I find defaultMode better than 'mode'.
Santi
^ permalink raw reply
* Re: [Q] merging from one (kernel) stable to another?
From: Brian Foster @ 2009-03-30 12:40 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Andreas Ericsson, git mailing list
In-Reply-To: <49D0B8BC.2010405@viscovery.net>
On Monday 30 March 2009 14:19:08 Johannes Sixt wrote:
> Brian Foster schrieb:
>[ ... ]
> > Thanks for the suggestion. I'll have to experiment,
> > but off-the-top-of-my-head, I think I do want a merge,
> > so that it's easier to track the history of individual
> > local changes. Having said that, I'm not entirely sure
> > I follow your suggestions. What I think you mean is:
> >
> > (1) Create a patch which is all (local) changes
> > (née diffs) from linux-mips.21 to our.21;
> > (2) Checkout linux-mips.26.8 (e.g.);
> > (3) Apply the patch created in (1), above;
>
> format-patch creates a patch series. You apply the whole series,
> e.g. with 'git am'. But for this workflow you could also just create
> a single patch and apply it to linux-mips.26.8, just as you wrote.
Point taken. I was being a bit sloppy there; I well know
`git format-patch' (which we use in our internal workflow)
generates a patch series, and that `git am' applies them.
Apologies for the confusion. Sorry!
> The important point is that you forge this tree into the shape that
> you finally want to have in the merge (that you will make later).
> At this point you only have to deal with conflicts and regressions
> that arise from your own changes, which makes your life much easier
> than if you also had to deal with conflicts that are outside your
> own changes.
Gottcha. Thanks for clarifying.
> > (4) Tag the result `like-this';
> > (5) Checkout our.21; and
> > (6) Merge with `like-this'.
>
> No, you merge with linux-mips.26.8. This will again give you a lot
> of conflicts. But you do
>
> (7) git checkout like-this -- .
>
> that is, you overwrite the merge result (that has conflicts) with
> your known-good tree called "like-this". This resolves all conflicts
> in the way that you wanted them.
Ah! Neat. I think I get it (er, git it?) now ....
Many thanks for your patient and very helpful replies!
cheers!
-blf-
--
“How many surrealists does it take to | Brian Foster
change a lightbulb? Three. One calms | somewhere in south of France
the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!
with brightly-coloured machine tools.” | http://www.stopesso.com
^ permalink raw reply
* Re: [PATCHv2 4/4] Rename push.default to push.mode
From: Santi Béjar @ 2009-03-30 12:37 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <49D0A1FE.60300@drmicha.warpmail.net>
2009/3/30 Michael J Gruber <git@drmicha.warpmail.net>:
> Santi Béjar venit, vidit, dixit 30.03.2009 12:11:
>> push.default was too generic, and also didn't specify if it was about
>> remote, refspec, branches, behaviour...
>
> I guess we go for US spelling here, so it's "behavior" ;)
Ok.
>> diff --git a/Documentation/config.txt b/Documentation/config.txt
>> index 38ab785..80bb3a6 100644
>> --- a/Documentation/config.txt
>> +++ b/Documentation/config.txt
>> @@ -480,7 +480,7 @@ branch.<name>.remote::
>> branch.<name>.merge::
>> It defines, together with branch.<name>.remote, the upstream branch
>> for the given branch. It tells 'git-fetch'/'git-pull' which
>> - branch to merge and can also afect 'git-push' (see push.default).
>> + branch to merge and can also afect 'git-push' (see push.mode).
>
> s/afect/affect/
>
OK
>
> Your patches contain quoted-printable characters all over the place.
I don't see the quoted-printable characters, I see them in utf-8 and 8bit.
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Maybe some server in between is recoding it.
> Are
> they not sent with git send-email?
They are send with git send-email and msmtp.
Santi
^ permalink raw reply
* Re: [Q] merging from one (kernel) stable to another?
From: Andreas Ericsson @ 2009-03-30 12:19 UTC (permalink / raw)
To: Brian Foster; +Cc: Johannes Sixt, git mailing list
In-Reply-To: <200903301358.48864.brian.foster@innova-card.com>
Brian Foster wrote:
> On Monday 30 March 2009 12:38:43 Johannes Sixt wrote:
>> Andreas Ericsson schrieb:
>>> A possibly better approach for you is to "git format-patch"
>>> your own changes and apply them to a clean 2.6.26.8 tree
>>> instead of trying to merge 2.6.26.8 into 2.6.21.
> [ I'm going from .21 to .26.8, so I think you've got that reversed? ]
>> After you have successfully done *that*, you know how the resulting
>> tree must look like, and you give it a tag, say "like-this".
>> If you really want to have a merge, then you can just repeat the
>> merge with your original branch, at which time you will get tons
>> of conflicts. Now you just 'git checkout like-this -- .' and you
>> have all your conflicts resolved in the way you need them.
>
> Andreas & Hannes,
>
> Thanks for the suggestion. I'll have to experiment,
> but off-the-top-of-my-head, I think I do want a merge,
> so that it's easier to track the history of individual
> local changes. Having said that, I'm not entirely sure
> I follow your suggestions. What I think you mean is:
>
> (1) Create a patch which is all (local) changes
> (née diffs) from linux-mips.21 to our.21;
This is wrong. Create several git-patches, each containing
the equivalence of one commit (complete with diff, author
info and commit message).
> (2) Checkout linux-mips.26.8 (e.g.);
> (3) Apply the patch created in (1), above;
Except it'll be "apply the patches, re-creating history
as if it had been done with a different base from the
start".
> (4) Tag the result `like-this';
> (5) Checkout our.21; and
> (6) Merge with `like-this'.
>
Merge is not necessary.
> I admit that now that I write the steps out, it seems
> to make sense ....? Am I understanding correctly?
>
Almost. "git help format-patch" and "git help am" will get
you the rest of the way, I think.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: [Q] merging from one (kernel) stable to another?
From: Johannes Sixt @ 2009-03-30 12:19 UTC (permalink / raw)
To: Brian Foster; +Cc: Andreas Ericsson, git mailing list
In-Reply-To: <200903301358.48864.brian.foster@innova-card.com>
Brian Foster schrieb:
> On Monday 30 March 2009 12:38:43 Johannes Sixt wrote:
>> Andreas Ericsson schrieb:
>>> A possibly better approach for you is to "git format-patch"
>>> your own changes and apply them to a clean 2.6.26.8 tree
>>> instead of trying to merge 2.6.26.8 into 2.6.21.
> [ I'm going from .21 to .26.8, so I think you've got that reversed? ]
>> After you have successfully done *that*, you know how the resulting
>> tree must look like, and you give it a tag, say "like-this".
>> If you really want to have a merge, then you can just repeat the
>> merge with your original branch, at which time you will get tons
>> of conflicts. Now you just 'git checkout like-this -- .' and you
>> have all your conflicts resolved in the way you need them.
>
> Andreas & Hannes,
>
> Thanks for the suggestion. I'll have to experiment,
> but off-the-top-of-my-head, I think I do want a merge,
> so that it's easier to track the history of individual
> local changes. Having said that, I'm not entirely sure
> I follow your suggestions. What I think you mean is:
>
> (1) Create a patch which is all (local) changes
> (née diffs) from linux-mips.21 to our.21;
> (2) Checkout linux-mips.26.8 (e.g.);
> (3) Apply the patch created in (1), above;
format-patch creates a patch series. You apply the whole series, e.g. with
'git am'. But for this workflow you could also just create a single patch
and apply it to linux-mips.26.8, just as you wrote.
The important point is that you forge this tree into the shape that you
finally want to have in the merge (that you will make later). At this
point you only have to deal with conflicts and regressions that arise from
your own changes, which makes your life much easier than if you also had
to deal with conflicts that are outside your own changes.
> (4) Tag the result `like-this';
> (5) Checkout our.21; and
> (6) Merge with `like-this'.
No, you merge with linux-mips.26.8. This will again give you a lot of
conflicts. But you do
(7) git checkout like-this -- .
that is, you overwrite the merge result (that has conflicts) with your
known-good tree called "like-this". This resolves all conflicts in the way
that you wanted them.
-- Hannes
^ permalink raw reply
* Re: [Q] merging from one (kernel) stable to another?
From: Brian Foster @ 2009-03-30 11:58 UTC (permalink / raw)
To: Johannes Sixt, Andreas Ericsson; +Cc: git mailing list
In-Reply-To: <49D0A133.80503@viscovery.net>
On Monday 30 March 2009 12:38:43 Johannes Sixt wrote:
> Andreas Ericsson schrieb:
> > A possibly better approach for you is to "git format-patch"
> > your own changes and apply them to a clean 2.6.26.8 tree
> > instead of trying to merge 2.6.26.8 into 2.6.21.
[ I'm going from .21 to .26.8, so I think you've got that reversed? ]
>
> After you have successfully done *that*, you know how the resulting
> tree must look like, and you give it a tag, say "like-this".
> If you really want to have a merge, then you can just repeat the
> merge with your original branch, at which time you will get tons
> of conflicts. Now you just 'git checkout like-this -- .' and you
> have all your conflicts resolved in the way you need them.
Andreas & Hannes,
Thanks for the suggestion. I'll have to experiment,
but off-the-top-of-my-head, I think I do want a merge,
so that it's easier to track the history of individual
local changes. Having said that, I'm not entirely sure
I follow your suggestions. What I think you mean is:
(1) Create a patch which is all (local) changes
(née diffs) from linux-mips.21 to our.21;
(2) Checkout linux-mips.26.8 (e.g.);
(3) Apply the patch created in (1), above;
(4) Tag the result `like-this';
(5) Checkout our.21; and
(6) Merge with `like-this'.
I admit that now that I write the steps out, it seems
to make sense ....? Am I understanding correctly?
Thanks for the suggestions. Other suggestions are also
quite welcome.
cheers!
-blf-
--
“How many surrealists does it take to | Brian Foster
change a lightbulb? Three. One calms | somewhere in south of France
the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!
with brightly-coloured machine tools.” | http://www.stopesso.com
^ permalink raw reply
* [PATCH] [PATCH] git-tag(1): add hint about commit messages
From: Nico -telmich- Schottelius @ 2009-03-30 11:58 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 817 bytes --]
If a tag is not annotated, git tag displays the commit message
instead. Add this hint to the manpage to unhide this secret.
Signed-off-by: Nico Schottelius <nico@ikn.schottelius.org>
---
Documentation/git-tag.txt | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 533d18b..fa73321 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -63,6 +63,7 @@ OPTIONS
are printed when using -l.
The default is not to print any annotation lines.
If no number is given to `-n`, only the first line is printed.
+ If the tag is not annotated, the commit message is displayed instead.
-l <pattern>::
List tags with names that match the given pattern (or all if no pattern is given).
--
1.6.2
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply related
* Re: [PATCHv2 4/4] Rename push.default to push.mode
From: Michael J Gruber @ 2009-03-30 10:42 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <1238407903-28020-5-git-send-email-santi@agolina.net>
Santi Béjar venit, vidit, dixit 30.03.2009 12:11:
> push.default was too generic, and also didn't specify if it was about
> remote, refspec, branches, behaviour...
I guess we go for US spelling here, so it's "behavior" ;)
>
> Signed-off-by: Santi Béjar <santi@agolina.net>
> ---
> Documentation/RelNotes-1.6.3.txt | 2 +-
> Documentation/config.txt | 4 ++--
> builtin-push.c | 16 ++++++++--------
> cache.h | 14 +++++++-------
> config.c | 10 +++++-----
> environment.c | 2 +-
> 6 files changed, 24 insertions(+), 24 deletions(-)
>
> diff --git a/Documentation/RelNotes-1.6.3.txt b/Documentation/RelNotes-1.6.3.txt
> index f0a2e41..67b2b66 100644
> --- a/Documentation/RelNotes-1.6.3.txt
> +++ b/Documentation/RelNotes-1.6.3.txt
> @@ -24,7 +24,7 @@ receive.denyDeleteCurrent in the receiving repository.
>
> When the user does not tell "git push" what to push, it has always
> pushed matching refs. For some people it is unexpected, and a new
> -configuration variable push.default has been introduced to allow
> +configuration variable push.mode has been introduced to allow
> changing a different default behaviour. To advertise the new feature,
Maybe time to change it here, too.
> a big warning is issued if this is not configured and a git push without
> arguments is attempted.
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 38ab785..80bb3a6 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -480,7 +480,7 @@ branch.<name>.remote::
> branch.<name>.merge::
> It defines, together with branch.<name>.remote, the upstream branch
> for the given branch. It tells 'git-fetch'/'git-pull' which
> - branch to merge and can also afect 'git-push' (see push.default).
> + branch to merge and can also afect 'git-push' (see push.mode).
s/afect/affect/
> When in branch <name>, it tells 'git-fetch' the default
> refspec to be marked for merging in FETCH_HEAD. The value is
> handled like the remote part of a refspec, and must match a
> @@ -1215,7 +1215,7 @@ pull.octopus::
> pull.twohead::
> The default merge strategy to use when pulling a single branch.
>
> -push.default::
> +push.mode::
> Defines the action git push should take if no refspec is given
> on the command line, no refspec is configured in the remote, and
> no refspec is implied by any of the options given on the command
> diff --git a/builtin-push.c b/builtin-push.c
> index 2eabcd3..c2c4de1 100644
> --- a/builtin-push.c
> +++ b/builtin-push.c
> @@ -72,7 +72,7 @@ static const char *warn_unconfigured_push_msg[] = {
> "not necessarily be what you want to happen.",
> "",
> "You can specify what action you want to take in this case, and",
> - "avoid seeing this message again, by configuring 'push.default' to:",
> + "avoid seeing this message again, by configuring 'push.mode' to:",
> " 'nothing' : Do not push anything",
> " 'matching' : Push all matching branches (default)",
> " 'tracking' : Push the current branch to whatever it is tracking",
> @@ -89,26 +89,26 @@ static void warn_unconfigured_push(void)
> static void setup_default_push_refspecs(void)
> {
> git_config(git_default_config, NULL);
> - switch (push_default) {
> - case PUSH_DEFAULT_UNSPECIFIED:
> + switch (push_mode) {
> + case PUSH_MODE_UNSPECIFIED:
> warn_unconfigured_push();
> /* fallthrough */
>
> - case PUSH_DEFAULT_MATCHING:
> + case PUSH_MODE_MATCHING:
> add_refspec(":");
> break;
>
> - case PUSH_DEFAULT_TRACKING:
> + case PUSH_MODE_TRACKING:
> setup_push_tracking();
> break;
>
> - case PUSH_DEFAULT_CURRENT:
> + case PUSH_MODE_CURRENT:
> add_refspec("HEAD");
> break;
>
> - case PUSH_DEFAULT_NOTHING:
> + case PUSH_MODE_NOTHING:
> die("You didn't specify any refspecs to push, and "
> - "push.default is \"nothing\".");
> + "push.mode is \"nothing\".");
> break;
> }
> }
> diff --git a/cache.h b/cache.h
> index 641529b..1625965 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -542,17 +542,17 @@ enum rebase_setup_type {
> AUTOREBASE_ALWAYS,
> };
>
> -enum push_default_type {
> - PUSH_DEFAULT_UNSPECIFIED = -1,
> - PUSH_DEFAULT_NOTHING = 0,
> - PUSH_DEFAULT_MATCHING,
> - PUSH_DEFAULT_TRACKING,
> - PUSH_DEFAULT_CURRENT,
> +enum push_mode_type {
> + PUSH_MODE_UNSPECIFIED = -1,
> + PUSH_MODE_NOTHING = 0,
> + PUSH_MODE_MATCHING,
> + PUSH_MODE_TRACKING,
> + PUSH_MODE_CURRENT,
> };
>
> extern enum branch_track git_branch_track;
> extern enum rebase_setup_type autorebase;
> -extern enum push_default_type push_default;
> +extern enum push_mode_type push_mode;
>
> #define GIT_REPO_VERSION 0
> extern int repository_format_version;
> diff --git a/config.c b/config.c
> index b76fe4c..ba02cfb 100644
> --- a/config.c
> +++ b/config.c
> @@ -567,17 +567,17 @@ static int git_default_branch_config(const char *var, const char *value)
>
> static int git_default_push_config(const char *var, const char *value)
> {
> - if (!strcmp(var, "push.default")) {
> + if (!strcmp(var, "push.mode")) {
> if (!value)
> return config_error_nonbool(var);
> else if (!strcmp(value, "nothing"))
> - push_default = PUSH_DEFAULT_NOTHING;
> + push_mode = PUSH_MODE_NOTHING;
> else if (!strcmp(value, "matching"))
> - push_default = PUSH_DEFAULT_MATCHING;
> + push_mode = PUSH_MODE_MATCHING;
> else if (!strcmp(value, "tracking"))
> - push_default = PUSH_DEFAULT_TRACKING;
> + push_mode = PUSH_MODE_TRACKING;
> else if (!strcmp(value, "current"))
> - push_default = PUSH_DEFAULT_CURRENT;
> + push_mode = PUSH_MODE_CURRENT;
> else {
> error("Malformed value for %s: %s", var, value);
> return error("Must be one of nothing, matching, "
> diff --git a/environment.c b/environment.c
> index 4696885..c925ea4 100644
> --- a/environment.c
> +++ b/environment.c
> @@ -42,7 +42,7 @@ enum safe_crlf safe_crlf = SAFE_CRLF_WARN;
> unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;
> enum branch_track git_branch_track = BRANCH_TRACK_REMOTE;
> enum rebase_setup_type autorebase = AUTOREBASE_NEVER;
> -enum push_default_type push_default = PUSH_DEFAULT_UNSPECIFIED;
> +enum push_mode_type push_mode = PUSH_MODE_UNSPECIFIED;
>
> /* Parallel index stat data preload? */
> int core_preload_index = 0;
Your patches contain quoted-printable characters all over the place. Are
they not sent with git send-email?
Michael
^ 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