* 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
* Re: [RFC GSoC 2009: git-submodule for multiple, active developers on active trees]
From: Shawn O. Pearce @ 2009-03-30 15:32 UTC (permalink / raw)
To: P Baker; +Cc: git
In-Reply-To: <526944450903251314o622711b5u3665bac90398d6be@mail.gmail.com>
Hi! As someone who has coded around git submodule by creating "repo"
for Android, I'm certainly interested in git submodule improvements,
so this is a great idea for a GSoC project. I have some comments
below that may help improve your proposal before you submit it.
P Baker <me@retrodict.com> wrote:
> Abstract:
> This project focuses on upgrading git-submodule to manage code
> created in external projects in ways that allow users to safely branch
> and merge that code without loss of data or routine merge conflicts.
> This will incorporate some changes made on the ???pu??? branch, but will
> also include making substantial changes to git-submodule underlying
> code.
...
> As opposed to ???remotes,??? which also incorporate external code into a
> project,
I'm not sure what you mean by that. Typically a "remote" in Git is
thought to be a configuration that says where to download a fork of
this project from. By default you get one remote, called "origin",
which is where you initially cloned your fork from, but you can add
many more, such as other developers you frequently collaborate with.
This is quite different from the problem that submodule tries
to address, as its dealing with forks of of the *same* project.
But a submodule is trying to point to forks of *other* projects,
whose histories are (possibly) unrelated to this project's history.
> The tentative timeline is:
>
> End of May ??? Conclusively finish the public discussion regarding where
> git-submodules needs to go
> Beginning of June ??? Produce final specifications (including method stubs)
> Middle of July ??? Finish active code and test development
> End of July ??? Merge code into production release, fix public submitted bugs
> Middle of August ??? Prepare code for final release and finish
> user-facing documentation
IMHO, this is too vague. *What exactly* are the features you want
to add to git submodule? Break this down by features, not by phases
of coding.
Further, you spend roughly a month writing method stubs.
My experience with such development practices is that you will
get frustrated by not having the code working, get bored with it,
and walk away. Or at best, you'll be able to stub it all out,
but will need to redo most of the stubs because you find later on
while writing the implementation code that you need to pass data
through that you didn't initially anticipate.
Also, we very much prefer Git patches to update the documentation
at the same time that the code changes. Maybe its done in the same
patch, if the code+doc update are relatively small, or maybe its done
in two patches in the same series (code change, then doc update),
but the general guideline is that both code and documentation should
be updated at roughly the same time (e.g. same day for Junio when
he merges the series down to master). This way the documentation
doesn't stray too far from the code its describing.
> A few specific changes that this project will likely include are:
>
> *use .git instead of .gitmodules
> *move objects of submodules into .git/ directory
> *git submodule update --init should initialize nested levels of submodules
> *protect changes in local submodules when doing ???git submodule update???
As I said above, I'd like to see this described in the timeline
better, each of these could be done independently, so you could work
on one item try to get it completed, tested, documented, and merged
into Junio's tree, and then start the next item. At worst at the
end of the summer you'll have a fraction of these done, merged,
and available for users, which is better than trying to do it all
and failing to get none merged.
I'd like to know more about each of these items, and less about
the general reasoning of where you got these feature ideas from.
What exactly are you talking about changing, and why? I don't need
to see detailed code at this stage, but I'd like a better description
of the user-visible changes that each bullet point might cause,
and why you feel this change is better than what we have today.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/2] send-email: refactor and ensure prompting doesn't loop forever
From: Jay Soffian @ 2009-03-30 15:45 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, Junio C Hamano
In-Reply-To: <vpqwsa7gjlh.fsf@bauges.imag.fr>
On Mon, Mar 30, 2009 at 10:40 AM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>> 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.
Okay, well, I figured out how to work the polish. Term::ReadLine is
attempting to use /dev/tty for input/output, which is closed. And
because send-email enables warnings, its attempt to do so emits the
messages you are seeing. Can you confirm that this patch squelches the
warnings?
diff --git a/git-send-email.perl b/git-send-email.perl
index f0405c8..1b17728 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -612,6 +612,8 @@ sub ask {
my $default = $arg{default};
my $resp;
my $i = 0;
+ return undef unless defined fileno($term->IN) and
+ defined fileno($term->OUT);
while ($i++ < 10) {
$resp = $term->readline($prompt);
if (!defined $resp) { # EOF
Thanks,
j.
^ permalink raw reply related
* [PATCH 1/2] graph.c: avoid compile warnings
From: Johannes Schindelin @ 2009-03-30 15:49 UTC (permalink / raw)
To: git, Allan Caffee; +Cc: Jeff King, Nanako Shiraishi
In-Reply-To: <cover.1238428115u.git.johannes.schindelin@gmx.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
I'd actually like to see this and the next patch squashed in.
graph.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/graph.c b/graph.c
index 2929c8b..5e2f224 100644
--- a/graph.c
+++ b/graph.c
@@ -701,8 +701,8 @@ static void graph_output_pre_commit_line(struct git_graph *graph,
for (i = 0; i < graph->num_columns; i++) {
struct column *col = &graph->columns[i];
if (col->commit == graph->commit) {
- seen_this = 1;
struct strbuf tmp = STRBUF_INIT;
+ seen_this = 1;
strbuf_addf(&tmp, "| %*s", graph->expansion_row, "");
strbuf_write_column(sb, col, tmp.buf);
strbuf_release(&tmp);
@@ -921,8 +921,6 @@ 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
--
1.6.2.1.493.g67cf3
^ permalink raw reply related
* [PATCH 2/2] --graph: respect --no-color
From: Johannes Schindelin @ 2009-03-30 15:49 UTC (permalink / raw)
To: git, Allan Caffee; +Cc: Jeff King, Nanako Shiraishi
In-Reply-To: <cover.1238428115u.git.johannes.schindelin@gmx.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
graph.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/graph.c b/graph.c
index 5e2f224..6a8622c 100644
--- a/graph.c
+++ b/graph.c
@@ -5,7 +5,6 @@
#include "diff.h"
#include "revision.h"
-extern int diff_use_color_default;
/* Internal API */
/*
@@ -1253,15 +1252,17 @@ static void strbuf_write_column(struct strbuf *sb, const struct column *c,
* right flag to be checking since --no-color doesn't turn
* this off.
*/
- if (diff_use_color_default)
+ if (c->color)
strbuf_addstr(sb, c->color);
strbuf_addstr(sb, s);
- if (diff_use_color_default)
+ if (c->color)
strbuf_addstr(sb, GIT_COLOR_RESET);
}
static char* get_current_column_color (const struct git_graph* graph)
{
+ if (!DIFF_OPT_TST(&graph->revs->diffopt, COLOR_DIFF))
+ return NULL;
return column_colors[graph->default_column_color];
}
--
1.6.2.1.493.g67cf3
^ permalink raw reply related
* Re: [PATCH 1/2] graph.c: avoid compile warnings
From: Junio C Hamano @ 2009-03-30 15:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Allan Caffee, Jeff King, Nanako Shiraishi
In-Reply-To: <7ee8d1c4ca806ce964356a1fe78efac19d56c29b.1238428115u.git.johannes.schindelin@gmx.de>
Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> I'd actually like to see this and the next patch squashed in.
>
> graph.c | 4 +---
> 1 files changed, 1 insertions(+), 3 deletions(-)
>
> diff --git a/graph.c b/graph.c
> index 2929c8b..5e2f224 100644
> --- a/graph.c
> +++ b/graph.c
> @@ -701,8 +701,8 @@ static void graph_output_pre_commit_line(struct git_graph *graph,
> for (i = 0; i < graph->num_columns; i++) {
> struct column *col = &graph->columns[i];
> if (col->commit == graph->commit) {
> - seen_this = 1;
> struct strbuf tmp = STRBUF_INIT;
> + seen_this = 1;
Which codebase are you working on top of?
> strbuf_addf(&tmp, "| %*s", graph->expansion_row, "");
> strbuf_write_column(sb, col, tmp.buf);
> strbuf_release(&tmp);
> @@ -921,8 +921,6 @@ 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
> --
> 1.6.2.1.493.g67cf3
^ permalink raw reply
* Re: [StGit PATCH] Add the --merged option to goto
From: Catalin Marinas @ 2009-03-30 16:01 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20090326111554.GA19337@diana.vm.bytemark.co.uk>
2009/3/26 Karl Hasselström <kha@treskal.com>:
> On 2009-03-25 10:24:13 +0000, Catalin Marinas wrote:
>
>> BTW, why don't we keep the tree information directly in the Index
>> object? Since this object is modified only via its own interface, it
>> can do all the checks and avoid the managing of temp_index_tree in
>> the Transaction object.
>
> I guess that might be a good idea -- it should be doable without any
> extra overhead for users that don't want it.
I tried but gave up quickly. The IndexAndWorktree class also dirties
the Index with the merge operations, so it is not worth the hassle.
That's the updated patch:
Add the --merged option to goto
This patch adds support for checking which patches were already merged
upstream. This checking is done by trying to reverse-apply the patches
in the index before pushing them onto the stack.
Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
diff --git a/stgit/argparse.py b/stgit/argparse.py
index 85ee6e3..765579c 100644
--- a/stgit/argparse.py
+++ b/stgit/argparse.py
@@ -225,6 +225,10 @@ def keep_option():
short = 'Keep the local changes',
default = config.get('stgit.autokeep') == 'yes')]
+def merged_option():
+ return [opt('-m', '--merged', action = 'store_true',
+ short = 'Check for patches merged upstream')]
+
class CompgenBase(object):
def actions(self, var): return set()
def words(self, var): return set()
diff --git a/stgit/commands/goto.py b/stgit/commands/goto.py
index 66f49df..839b75c 100644
--- a/stgit/commands/goto.py
+++ b/stgit/commands/goto.py
@@ -28,7 +28,7 @@ Push/pop patches to/from the stack until the one
given on the command
line becomes current."""
args = [argparse.other_applied_patches, argparse.unapplied_patches]
-options = argparse.keep_option()
+options = argparse.keep_option() + argparse.merged_option()
directory = common.DirectoryHasRepositoryLib()
@@ -47,8 +47,14 @@ def func(parser, options, args):
assert not trans.pop_patches(lambda pn: pn in to_pop)
elif patch in trans.unapplied:
try:
- for pn in trans.unapplied[:trans.unapplied.index(patch)+1]:
- trans.push_patch(pn, iw, allow_interactive = True)
+ to_push = trans.unapplied[:trans.unapplied.index(patch)+1]
+ if options.merged:
+ merged = set(trans.check_merged(to_push))
+ else:
+ merged = set()
+ for pn in to_push:
+ trans.push_patch(pn, iw, allow_interactive = True,
+ already_merged = pn in merged)
except transaction.TransactionHalted:
pass
elif patch in trans.hidden:
diff --git a/stgit/lib/transaction.py b/stgit/lib/transaction.py
index b146648..4148ff3 100644
--- a/stgit/lib/transaction.py
+++ b/stgit/lib/transaction.py
@@ -297,7 +297,8 @@ class StackTransaction(object):
out.info('Deleted %s%s' % (pn, s))
return popped
- def push_patch(self, pn, iw = None, allow_interactive = False):
+ def push_patch(self, pn, iw = None, allow_interactive = False,
+ already_merged = False):
"""Attempt to push the named patch. If this results in conflicts,
halts the transaction. If index+worktree are given, spill any
conflicts to them."""
@@ -305,11 +306,15 @@ class StackTransaction(object):
cd = orig_cd.set_committer(None)
oldparent = cd.parent
cd = cd.set_parent(self.top)
- base = oldparent.data.tree
- ours = cd.parent.data.tree
- theirs = cd.tree
- tree, self.temp_index_tree = self.temp_index.merge(
- base, ours, theirs, self.temp_index_tree)
+ if already_merged:
+ # the resulting patch is empty
+ tree = cd.parent.data.tree
+ else:
+ base = oldparent.data.tree
+ ours = cd.parent.data.tree
+ theirs = cd.tree
+ tree, self.temp_index_tree = self.temp_index.merge(
+ base, ours, theirs, self.temp_index_tree)
s = ''
merge_conflict = False
if not tree:
@@ -341,7 +346,9 @@ class StackTransaction(object):
else:
comm = None
s = ' (unmodified)'
- if not merge_conflict and cd.is_nochange():
+ if already_merged:
+ s = ' (merged)'
+ elif not merge_conflict and cd.is_nochange():
s = ' (empty)'
out.info('Pushed %s%s' % (pn, s))
def update():
@@ -379,3 +386,25 @@ class StackTransaction(object):
assert set(self.unapplied + self.hidden) == set(unapplied + hidden)
self.unapplied = unapplied
self.hidden = hidden
+
+ def check_merged(self, patches):
+ """Return a subset of patches already merged."""
+ merged = []
+ if self.temp_index_tree != self.stack.head.data.tree:
+ self.temp_index.read_tree(self.stack.head.data.tree)
+ self.temp_index_tree = self.stack.head.data.tree
+ for pn in reversed(patches):
+ # check whether patch changes can be reversed in the current index
+ cd = self.patches[pn].data
+ if cd.is_nochange():
+ continue
+ try:
+ self.temp_index.apply_treediff(cd.tree, cd.parent.data.tree,
+ quiet = True)
+ merged.append(pn)
+ # The self.temp_index was modified by apply_treediff() so
+ # force read_tree() the next time merge() is used.
+ self.temp_index_tree = None
+ except git.MergeException:
+ pass
+ return merged
--
Catalin
^ permalink raw reply related
* Re: [RFC/PATCH] graph API: Added logic for colored edges.
From: Johannes Schindelin @ 2009-03-30 16:04 UTC (permalink / raw)
To: Allan Caffee; +Cc: git, Jeff King, Nanako Shiraishi
In-Reply-To: <20090330141322.GA6221@linux.vnet>
Hi,
On Mon, 30 Mar 2009, Allan Caffee wrote:
> 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>
Nice!
> 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?
The patch I sent you should work...
> diff --git a/graph.c b/graph.c
> index 162a516..2929c8b 100644
> --- a/graph.c
> +++ b/graph.c
> @@ -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);
> +
> +
Please just insert the definitions here, instead of using a forward
declaration.
> @@ -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
I imagine that this is a good start. Whether to make a patch that moves
this into color.[ch] before or after this patch is up to Junio, I guess
(even if I would prefer it to be done before, so that it gets done).
> @@ -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;
> + }
> + }
I imagine that this would be better done using a struct decorate mapping
commits to the color strings.
Also, I'd only call get_current_column_color() if there was no color
assigned to the commit (instead of calling it all the time).
It might not be a performance bottleneck here, but I guess it is better
not to get used to that pattern anyway.
> @@ -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); */
Please remove this line.
> @@ -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);
Maybe it would be better to add functions
const char *column_color(struct column *c)
{
return c->color ? c->color : "";
}
const char *column_color_reset(struct column *c)
{
return c->color ? GIT_COLOR_RESET : "";
}
?
Sorry, I have to stop the review here, ran out of time...
If nobody beats me to it, I will continue here later.
Thanks!
Dscho
^ permalink raw reply
* Re: [PATCH 1/2] send-email: refactor and ensure prompting doesn't loop forever
From: Jay Soffian @ 2009-03-30 16:04 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, Junio C Hamano
In-Reply-To: <76718490903300845x14897599jc73f50a16b21605d@mail.gmail.com>
On Mon, Mar 30, 2009 at 11:45 AM, Jay Soffian <jaysoffian@gmail.com> wrote:
> Okay, well, I figured out how to work the polish. Term::ReadLine is
> attempting to use /dev/tty for input/output, which is closed. And
> because send-email enables warnings, its attempt to do so emits the
> messages you are seeing. Can you confirm that this patch squelches the
> warnings?
Ugh, not that. This:
diff --git a/git-send-email.perl b/git-send-email.perl
index f0405c8..81240ef 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -612,6 +612,9 @@ sub ask {
my $default = $arg{default};
my $resp;
my $i = 0;
+ return defined $default ? $default : undef
+ unless defined $term->IN and defined fileno($term->IN) and
+ defined $term->OUT and defined fileno($term->OUT);
while ($i++ < 10) {
$resp = $term->readline($prompt);
if (!defined $resp) { # EOF
j.
^ permalink raw reply related
* Detached HEAD warning (again)
From: Pieter de Bie @ 2009-03-30 16:09 UTC (permalink / raw)
To: Git Mailing List
Hi all,
I strongly remember there being a discussion about this a few weeks
ago, but I
can't find it. Basically, someone wanted to introduce a warning every
time
someone commits on a detached HEAD. This was shot down because there
already
is a big warning when you detach your HEAD (with which I agree).
However, someone here: http://news.ycombinator.com/item?id=538619
pointed to
an example here: http://book.git-scm.com/5_submodules.html , which
works with
submodules:
$ git submodule update --init
# sub/ is created
$ (cd sub && touch a && git add a && git commit -am "Add new file")
[detached HEAD 8641889] Add new file
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 a
$ git submodule update
$ ls sub/a
ls: sub/a: No such file or directory
Now, it DOES say 'detached HEAD', but I still think this is something
easily
missed and something that can cause a lot of confusion. Perhaps a
warning in
such cases wouldn't hurt?
- Pieter
^ permalink raw reply
* Re: [PATCH 1/2] graph.c: avoid compile warnings
From: Junio C Hamano @ 2009-03-30 16:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Allan Caffee, Jeff King, Nanako Shiraishi
In-Reply-To: <7vd4bzf1e5.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
>> diff --git a/graph.c b/graph.c
>> index 2929c8b..5e2f224 100644
>> --- a/graph.c
>> +++ b/graph.c
>> @@ -701,8 +701,8 @@ static void graph_output_pre_commit_line(struct git_graph *graph,
>> for (i = 0; i < graph->num_columns; i++) {
>> struct column *col = &graph->columns[i];
>> if (col->commit == graph->commit) {
>> - seen_this = 1;
>> struct strbuf tmp = STRBUF_INIT;
>> + seen_this = 1;
>
> Which codebase are you working on top of?
Nevermind. I didn't realize it was "here are to help whipping your series
into shape" meant for Allan.
^ permalink raw reply
* Re: [PATCH] Add diffuse as merge and diff tool
From: Sebastian Pipping @ 2009-03-30 16:41 UTC (permalink / raw)
To: David Aguilar; +Cc: git
In-Reply-To: <20090330045522.GA8308@gmail.com>
David Aguilar wrote:
>> Documentation/git-mergetool.txt | 3 ++-
>> Documentation/merge-config.txt | 7 ++++---
>> contrib/completion/git-completion.bash | 3 ++-
>> contrib/difftool/git-difftool-helper | 12 ++++++++----
>> contrib/difftool/git-difftool.txt | 4 ++--
>> git-gui/lib/mergetool.tcl | 7 +++++++
>> git-mergetool.sh | 15 ++++++++++++---
>> 7 files changed, 37 insertions(+), 14 deletions(-)
>
>
> Hey, thanks for the patch.
> Ouch.. too many places with duplicated information, huh?
Yes.
> I'm in the middle of refactoring git-(diff|merge)tool so that
> there is less duplication of code.
>
> Junio also has a number of difftool-related patches in his
> proposed-updates "pu" branch.
>
> Sebastian, would you mind if I rebased your patch on top of my
> work (once I send it out) so that it makes things easier on
> our kind maintainer? I have a big patch series coming down that
> does away with the redundancies so I think it'd be best if we
> transfered your changes on top of it. Would you mind if I
> rebased your patch and sent it out to the list?
>
> It wouldn't be until much later tonight (or tomorrow) at the
> earliest since I have some unpacking to take care of but if
> that's cool with you just let me know.
>
> You should see the refactoring patches from me shortly...
My patch is your patch, do as you please.
Just take care to keep the order of the files passed
to Diffuse intact, especially with $MERGED second,
as Diffuse sets focus on the second document after startup.
Sebastian
^ permalink raw reply
* Re: [PATCHv2 3/4] Documentation: branch.*.merge can also afect 'git-push'
From: Junio C Hamano @ 2009-03-30 16:47 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <1238407903-28020-4-git-send-email-santi@agolina.net>
Santi Béjar <santi@agolina.net> writes:
> Signed-off-by: Santi Béjar <santi@agolina.net>
> ---
> Documentation/config.txt | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 7ae584f..38ab785 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.
> + branch to merge and can also afect 'git-push' (see push.default).
> 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
I'll take [1/4] and [2/4] with minor rewording, and I think [4/4] is not
necessary (push.default is clear enough---and defaultMode won't make it
any clearer to the first time readers anyway as it is unspecified what
kind of "mode" it is talking about).
I do not understand this [3/4]. I did look at push.default but it is
unclear how this variable is involved.
Perhaps it is because the word "tracking" in the description "push the
current branch to the branch it is tracking" is used without explaination.
I think the author meant to say if your local branch frotz by default
merges changes made to the branch nitfol of the remote repository, "frotz
tracks nitfol", but the use of the word "track" for that meaning appears
nowhere in Documentation/glossary-content.txt
When you have:
[branch "frotz"]
remote = xyzzy
merge = nitfol
[remote "xyzzy"]
url = ...
fetch = refs/heads/*:refs/remotes/xyzzy/*
we can learn from the glossary the following:
* refs/remotes/xyzzy/nitfol is a (remote) tracking branch and is used to
follow changes made on "nitfol" branch in another repository "xyzzy".
* refs/heads/*:refs/remotes/xyzzy/* is a refspec. It shows refs under
refs/heads/ (aka "local branches") of the "xyzzy" repository are copied
to our refs/remotes/xyzzy/ hierarchy.
There is no word defined to describe what "nitfol" is to "frotz". It is
what "frotz" merges from. So perhaps the description of push.default
should say that, instead of using the word "track" in a confusing way to
describe unrelated concept. Saying "merge" might confuse people who want
to use "branch.<name>.rebase", so it might be a good idea to say:
frotz updates with nitfol
To "track" is pretty much about one-way communication. You track the
other guy, but you do not have to (and often you cannot) update the
upstream with what you do. branch.<name>.merge may have been "tracking"
in that sense, but with the push.default set to tracking, suddenly the
communication becomes bidirectional and it is not about tracking anymore.
^ permalink raw reply
* Re: [Q] merging from one (kernel) stable to another?
From: Daniel Barkalow @ 2009-03-30 17:31 UTC (permalink / raw)
To: Brian Foster; +Cc: git mailing list
In-Reply-To: <200903301024.08848.brian.foster@innova-card.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2135 bytes --]
On Mon, 30 Mar 2009, 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.
Why are you going from .26.8 to .27? Based on the -stable policy, there
should be no reason not to skip .26.x between .26 and .27. In fact, it's
not unlikely that merging both .26.8 and .27 will introduce bugs when the
same issue was fixed in different places in the two branches: a narrow
patch to paper over the identified problem in -stable and an intrusive
patch to change some API to make simpler code correct in the mainline.
That is, the correct way of merging changes from -stable with the latest
mainline series is always to take the mainline version, even if the
-stable changes don't conflict at all.
It should actually be ideal to just merge your local changes directly with
the mainline kernel you want to end up using. But you might want to merge
first with earlier mainline kernels in order to get fewer or easier
conflicts per step.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 0/5] Header includes cleanup
From: Nathaniel P Dawson @ 2009-03-30 17:33 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <49D0A3DF.4000203@viscovery.net>
[-- Attachment #1: Type: text/plain, Size: 1556 bytes --]
I'm sorry, I must have misunderstood the task on the janitor
list. Could you explain it a bit better so I would be able to do it
properly?
And as for line wrapping I apologize, emacs on my laptop was
apparently not turning on auto-fill but has been rectified.
Regards,
Nathaniel P Dawson
On Mon, Mar 30, 2009 at 12:50:07PM +0200, Johannes Sixt wrote:
> Please wrap your lines at ca. 75 columns.
>
> Nathaniel P Dawson schrieb:
> > This is just the beginning for this project. I'm slowly cleaning up
> > the header includes one chunk at a time. I hope my patches aren't too
> > messy, I've learned how to better utilize git to make patches and
> > organize my commits logically so I'll submit neater chunks henceforth.
> > You can expect patches from me nightly until I've finished this project.
>
> You have removed includes that are implied by other includes, i.e. if
> foo.h includes bar.h, then you removed #include "bar.h" from *.c if there
> is #include "foo.h".
>
> IMO, this is not a good guiding principle to reduce includes. A better
> principle is to keep #include "bar.h" in a source or header file iff a
> feature that is declared or defined in bar.h is *used* *directly* in that
> source or header file, regardless of whether bar.h is included in foo.h
> that is itself included in that source or header file.
>
> If this latter principle is obeyed, then the build won't break by removing
> the include of foo.h (for the reason that nothing of foo.h is *use*
> *directly* anymore).
>
> -- Hannes
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] git-svn: fix ls-tree usage with dash-prefixed paths
From: Eric Wong @ 2009-03-30 17:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Anton Gyllenberg
In-Reply-To: <7v3acvldc7.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > Junio C Hamano <gitster@pobox.com> wrote:
> >> Eric Wong <normalperson@yhbt.net> writes:
> >>
> >> > To find the blob object name given a tree and pathname, we were
> >> > incorrectly calling "git ls-tree" with a "--" argument followed
> >> > by the pathname of the file we wanted to get.
> >> >
> >> > git ls-tree <TREE> -- --dashed/path/name.c
> >> >
> >> > Unlike many command-line interfaces, the "--" alone does not
> >> > symbolize the end of non-option arguments on the command-line.
> >> >
> >> > ls-tree interprets the "--" as a prefix to match against, thus
> >> > the entire contents of the --dashed/* hierarchy would be
> >> > returned because the "--" matches "--dashed" and every path
> >> > under it.
> >>
> >> The above makes only half a sense to me. In an empty directory:
> >
> > Ah, I think you missed this line:
> >
> > "the entire contents of the --dashed/* hierarchy would be"
>
> Actually, that was what I was trying to demonstrate to be false. Notice
> the empty output from the first ls-tree with only -- and no other pathspec
> on the command line. "--" should not match "--dashed/*" anything (but
> also notice that I said "should" here).
>
> >> $ git init
> >> Initialized empty Git repository in /tmp/empty/.git
> >> $ mkdir -p ./--dashed/path
> >> $ >./--dashed/path/name
> >
> > # Add a second file
> > >./--dashed/path/ame
>
> I think that is an independent bug. Not just "--" but it appears "--d"
> seems to hit it (and this is an ancient bug---even v1.0.0 seems to have
> it).
> I suspect that ls-tree needs a fix, not about "--" but about the pathspec
> filtering. It appears that the part that decides if a subtree is worth
> traversing into uses the correct "is a pathspec pattern match leading path
> components?" semantics (i.e. "--dashed" matches but "--" doesn't), but
> after traversing into subtrees, the part that emits the output uses a
> broken semantics "does the path have any pathspec patter as its prefix?"
> It shouldn't check for "prefix", but for "leading path components", in
> other words, the match must happen at directory boundaries.
>
> And I do not think *this* bug is too late to fix. We should fix it.
>From the ls-tree documentation, I was under the impression that "--"
matching "--dashed" was intended:
When paths are given, show them (note that this isn't really raw
pathnames, but rather a list of patterns to match).
It doesn't make sense to me match like this, either; but I do think it
was intended and it will break things if people depend on the
existing behavior.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 1/2] Add feature release instructions to MaintNotes addendum
From: Raman Gupta @ 2009-03-30 17:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr60fijn5.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]
Junio C Hamano wrote:
> rocketraman@fastmail.fm writes:
>
>> + - The 'maint' branch is updated to the new release.
>> +
>> + $ git branch -f maint master
>
> It appears that you are trying to make this document into a canned set of
> insns for people who want a ready-to-cut-and-paste-without-thinking
> recipe, and I am perfectly fine with such a document, but as I mentioned
> already, "how to maintain git" is not a good place to do so. You seem to
> have taken it as a joke, but I am serious.
I guess the smiley face when you said that threw me off :)
Based on your feedback, I'll withdraw my patch for MaintNotes -- my
intention in patching it was to provide more information for newbies
or people reading it out of curiosity, however you're absolutely right
-- it is not the right place for that type of information.
It does need more info in some of the other areas you mentioned and I
would love to help but I'm not knowledgeable enough to do so and I
fear I'll be more of a hindrance than a help.
Cheers,
Raman
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3528 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] Add feature release instructions to gitworkflows man page
From: Raman Gupta @ 2009-03-30 17:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk567ijlf.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> rocketraman@fastmail.fm writes:
>
>> From: Raman Gupta <raman@rocketraman.com>
>>
>> Based on a mailing list discussion, add a description of the workflow,
>> and associated commands, for creating a feature release.
>
> The same comment applies to the other one, but this commit log message is
> really lacking. If you do not bother to summarize the discussion, place a
> pointer to the list archive, and more importantly, please describe *why*
> this change is desiable.
Ok will do.
> I am not sure rewinding and rebuilding of 'next', or even having 'next',
> is applicable for other projects as a BCP.
Hmmm... The existing gitworkflows man page discusses the 'next' branch
several times. I am simply expanding the document to cover the branch
management associated with the git.git release process as well, which
necessarily includes a discussion of 'next'.
If you wish to remove discussion of 'next' from this document, that is
probably better done in a separate followup change. Though personally
I think its a useful concept for readers to learn about as they are
setting up their own workflows.
> Other parts (except for the "branch -f" bit I've already told you
> about in the other message) looked good.
I'll add some discussion about the branch -f bit -- I hope you agree
that in this document that is distributed with git, some
beginner-level explanation of the difference between the branch -f and
the merge approach is warranted?
Cheers,
Raman
^ permalink raw reply
* Re: [PATCHv2 4/4] Rename push.default to push.mode
From: Jeff King @ 2009-03-30 18:02 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Santi Béjar, git
In-Reply-To: <49D0DB78.2010204@drmicha.warpmail.net>
On Mon, Mar 30, 2009 at 04:47:20PM +0200, Michael J Gruber wrote:
> 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.
The message gmane passes out has the content-transfer-encoding set
properly. Your newsreader should properly un-QP it, or if it has an
option to save it directly (encoding and all), then "git am" will un-QP
it. If you were to "git apply" it directly, that would break, though
(and it is user error). If your newsreader saves the QP text without the
matching header, then that would also break (and your newsreader is
broken).
Just curious how you are seeing the breakage (because I want to make
sure there is no git bug).
-Peff
^ permalink raw reply
* Re: [PATCH] git-svn: fix ls-tree usage with dash-prefixed paths
From: Junio C Hamano @ 2009-03-30 18:05 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Anton Gyllenberg
In-Reply-To: <20090330174151.GA32728@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
>
>> I think that is an independent bug. Not just "--" but it appears "--d"
>> seems to hit it (and this is an ancient bug---even v1.0.0 seems to have
>> it).
>
>> I suspect that ls-tree needs a fix, not about "--" but about the pathspec
>> filtering. It appears that the part that decides if a subtree is worth
>> traversing into uses the correct "is a pathspec pattern match leading path
>> components?" semantics (i.e. "--dashed" matches but "--" doesn't), but
>> after traversing into subtrees, the part that emits the output uses a
>> broken semantics "does the path have any pathspec patter as its prefix?"
>> It shouldn't check for "prefix", but for "leading path components", in
>> other words, the match must happen at directory boundaries.
>>
>> And I do not think *this* bug is too late to fix. We should fix it.
>
> From the ls-tree documentation, I was under the impression that "--"
> matching "--dashed" was intended:
>
> When paths are given, show them (note that this isn't really raw
> pathnames, but rather a list of patterns to match).
>
> It doesn't make sense to me match like this, either; but I do think it
> was intended and it will break things if people depend on the
> existing behavior.
Ok, but then the decision to descend into --dashed should be consistent
with that policy, no? Right now, it appears that giving "--" alone says
"Anything under --dashed can never match that pattern, so I wouldn't
bother recursing into it".
^ permalink raw reply
* Re: [PATCH 2/2] Add feature release instructions to gitworkflows man page
From: Junio C Hamano @ 2009-03-30 18:14 UTC (permalink / raw)
To: Raman Gupta; +Cc: git
In-Reply-To: <49D10875.2060008@fastmail.fm>
Raman Gupta <rocketraman@fastmail.fm> writes:
> Junio C Hamano wrote:
> ...
> If you wish to remove discussion of 'next' from this document, that is
> probably better done in a separate followup change. Though personally
> I think its a useful concept for readers to learn about as they are
> setting up their own workflows.
I do not have a particularly strong feeling about 'next' either way.
As the document states at the top, it lists ingredients from git.git
management and it is left up to the readers to adopt parts that suit their
needs, while not using others. In that spirit, the description of 'next'
as "ahead of master that is supposed to be rock solid" may be a good thing
to keep. It is orthogonal if the project wants to rewind and rebuild
'next' after every feature release---they do not need to (and we didn't do
so for quite some time). One valid choice by readers is to adopt the
concept of 'next' in their project but never rewind and rebuild it, and
you made that clear that it is optional. So I think this part of your
patch is good as-is.
>> Other parts (except for the "branch -f" bit I've already told you
>> about in the other message) looked good.
>
> I'll add some discussion about the branch -f bit -- I hope you agree
> that in this document that is distributed with git, some
> beginner-level explanation of the difference between the branch -f and
> the merge approach is warranted?
Surely and thanks.
^ permalink raw reply
* Re: [Q] merging from one (kernel) stable to another?
From: Uwe Kleine-König @ 2009-03-30 18:23 UTC (permalink / raw)
To: Brian Foster; +Cc: git mailing list
In-Reply-To: <200903301024.08848.brian.foster@innova-card.com>
On Mon, Mar 30, 2009 at 10:24:08AM +0200, 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.
Assuming you have your master on top of .21-stable and want to go to
.26-stable, the following might work better for you:
$ git checkout -b mydot26stable .26-stable
$ git merge -s ours .21-stable
$ git checkout master
$ git merge mydot26stable
Note this is not tested, just came to my mind...
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] git-svn: add a double quiet option to hide git commits
From: Simon Arlott @ 2009-03-30 18:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Wong, git, mdpoole
In-Reply-To: <7vvdprjyrc.fsf@gitster.siamese.dyndns.org>
People may expect/prefer -q to still show git commits,
so this change allows a second -q to hide them.
Signed-off-by: Michael Poole <mdpoole@troilus.org>
Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
---
On 30/03/09 07:44, Junio C Hamano wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>> Simon Arlott <simon@fire.lp0.eu> wrote:
>>> Ideally only errors should be output in this mode so fetch
>>> can be run from cron and normally produce no output. Without
>>> this change it would output a single line on each git commit,
>>> e.g.
>>> r1909 = 32ef87860662526d4a62f903949ed21e0341079e (u2_10_12_branch)
Documentation/git-svn.txt | 3 ++-
git-svn.perl | 9 +++++----
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index cda3389..8163a19 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -385,7 +385,8 @@ config key: svn.authorsfile
-q::
--quiet::
- Make 'git-svn' less verbose.
+ Make 'git-svn' less verbose. Specify a second time to make it
+ even less verbose.
--repack[=<n>]::
--repack-flags=<flags>::
diff --git a/git-svn.perl b/git-svn.perl
index e5c3dfe..d919798 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -68,6 +68,7 @@ my ($_stdin, $_help, $_edit,
$_prefix, $_no_checkout, $_url, $_verbose,
$_git_format, $_commit_url, $_tag);
$Git::SVN::_follow_parent = 1;
+$_q ||= 0;
my %remote_opts = ( 'username=s' => \$Git::SVN::Prompt::_username,
'config-dir=s' => \$Git::SVN::Ra::config_dir,
'no-auth-cache' => \$Git::SVN::Prompt::_no_auth_cache,
@@ -80,7 +81,7 @@ my %fc_opts = ( 'follow-parent|follow!' => \$Git::SVN::_follow_parent,
'useSvnsyncProps' => \$Git::SVN::_use_svnsync_props,
'log-window-size=i' => \$Git::SVN::Ra::_log_window_size,
'no-checkout' => \$_no_checkout,
- 'quiet|q' => \$_q,
+ 'quiet|q+' => \$_q,
'repack-flags|repack-args|repack-opts=s' =>
\$Git::SVN::_repack_flags,
'use-log-author' => \$Git::SVN::_use_log_author,
@@ -2331,13 +2332,13 @@ sub do_git_commit {
$self->{last_rev} = $log_entry->{revision};
$self->{last_commit} = $commit;
- print "r$log_entry->{revision}" unless $::_q;
+ print "r$log_entry->{revision}" unless $::_q > 1;
if (defined $log_entry->{svm_revision}) {
- print " (\@$log_entry->{svm_revision})" unless $::_q;
+ print " (\@$log_entry->{svm_revision})" unless $::_q > 1;
$self->rev_map_set($log_entry->{svm_revision}, $commit,
0, $self->svm_uuid);
}
- print " = $commit ($self->{ref_id})\n" unless $::_q;
+ print " = $commit ($self->{ref_id})\n" unless $::_q > 1;
if (--$_gc_nr == 0) {
$_gc_nr = $_gc_period;
gc();
--
1.6.2
--
Simon Arlott
^ permalink raw reply related
* Re: [PATCH 2/2] Add feature release instructions to gitworkflows man page
From: Raman Gupta @ 2009-03-30 18:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vljqmdgj0.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Raman Gupta <rocketraman@fastmail.fm> writes:
>
>> Junio C Hamano wrote:
>> ...
>> If you wish to remove discussion of 'next' from this document, that is
>> probably better done in a separate followup change. Though personally
>> I think its a useful concept for readers to learn about as they are
>> setting up their own workflows.
>
> I do not have a particularly strong feeling about 'next' either way.
>
> As the document states at the top, it lists ingredients from git.git
> management and it is left up to the readers to adopt parts that suit their
> needs, while not using others. In that spirit, the description of 'next'
> as "ahead of master that is supposed to be rock solid" may be a good thing
> to keep. It is orthogonal if the project wants to rewind and rebuild
> 'next' after every feature release---they do not need to (and we didn't do
> so for quite some time). One valid choice by readers is to adopt the
> concept of 'next' in their project but never rewind and rebuild it, and
> you made that clear that it is optional. So I think this part of your
> patch is good as-is.
It might be useful to add some explanation of why one would want to
rewind and rebuild vs simply continue as is.
I guess the advantage is that the history for next starts out nice and
clean for the next release, without any cruft from repeated merging of
topic branches.
The disadvantage is that one must publish the operation and all forks
must deal with the rebase.
Any other thoughts?
Cheers,
Raman
^ permalink raw reply
* [PATCH] gitk: Mark some strings for translation
From: Michele Ballabio @ 2009-03-30 19:17 UTC (permalink / raw)
To: paulus; +Cc: git
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
gitk | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/gitk b/gitk
index 3835a51..8b61d0d 100755
--- a/gitk
+++ b/gitk
@@ -521,7 +521,7 @@ proc updatecommits {} {
incr viewactive($view)
set viewcomplete($view) 0
reset_pending_select {}
- nowbusy $view "Reading"
+ nowbusy $view [mc "Reading"]
if {$showneartags} {
getallcommits
}
@@ -3766,7 +3766,7 @@ proc editview {} {
set newviewopts($curview,perm) $viewperm($curview)
set newviewopts($curview,cmd) $viewargscmd($curview)
decode_view_opts $curview $viewargs($curview)
- vieweditor $top $curview "Gitk: edit view $viewname($curview)"
+ vieweditor $top $curview "[mc "Gitk: edit view"] $viewname($curview)"
}
proc vieweditor {top n title} {
@@ -10227,7 +10227,7 @@ proc doprefs {} {
proc choose_extdiff {} {
global extdifftool
- set prog [tk_getOpenFile -title "External diff tool" -multiple false]
+ set prog [tk_getOpenFile -title [mc "External diff tool"] -multiple false]
if {$prog ne {}} {
set extdifftool $prog
}
--
1.6.2.22.gc2ac
^ permalink raw reply related
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