* Re: [PATCH] Let git-add--interactive read "git colors" from git-config
From: Jeff King @ 2007-10-23 4:29 UTC (permalink / raw)
To: Dan Zwell
Cc: Shawn O. Pearce, Wincent Colaiuta, Git Mailing List,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld
In-Reply-To: <20071022211958.045895ac@danzwell.com>
On Mon, Oct 22, 2007 at 09:19:58PM -0500, Dan Zwell wrote:
> This patch is againts Shawn Pearce's "pu" branch.
Don't do that. The code in 'pu' is a mess of half-working features. If
your patch is accepted, then it has to be picked apart from those
half-working features that aren't being accepted (which hopefully isn't
hard if nobody has been working in the same area, but can be quite
ugly). Base your work on 'master' if possible, or 'next' if it relies
on features only in next. If it relies on some topic branch that is
_only_ in pu, then mention explicitly which topic.
-Peff
^ permalink raw reply
* Re: What's cooking in git/spearce.git (topics)
From: Shawn O. Pearce @ 2007-10-23 4:27 UTC (permalink / raw)
To: Theodore Tso; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <20071023012140.GC22997@thunk.org>
Theodore Tso <tytso@mit.edu> wrote:
> On Mon, Oct 22, 2007 at 06:15:09PM -0700, Junio C Hamano wrote:
> >
> > Sorry, WI is for "what's in", WC is for "what's cooking". I
> > should remove PU and RB from there.
>
> I assume PU is what you used to build your proposed-update branch?
Actually I found PU of some use:
git branch -f pu next
git checkout pu
./Meta/PU --continue
its a little sluggish to list, but made it pretty easy to pick
topics for merging into pu. git-rerere really makes it easy to
recover conflicts in pu during future rebuilds of pu.
> based off of master, and then merged into next. Or maybe I'm not
> understanding how to make the WC and git-topic.perl script work and
> sing for me perfectly?
The other tidbits I managed to learn by trial and error here was
to make sure I did the following:
- make sure master is fully merged into next
- make sure next is fully merged into pu
- Run "Meta/git-topic.perl --base=master | less"
It wasn't uncommon for me to merge master->next, next->pu, run
git-topic, then reset both next and pu *back* to what I had last
published (remote tracking branches updated during push make this
easy) before moving on with my next and pu updating activities.
Of course take my notes above with a grain of salt; I only worked
this way for a week and it took me a couple of days to come up with
the above. Junio may very well have it streamlined even more.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 2/2] Let git-add--interactive read colors from git-config
From: Jeff King @ 2007-10-23 4:27 UTC (permalink / raw)
To: Dan Zwell
Cc: Shawn O. Pearce, Wincent Colaiuta, Git Mailing List,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld
In-Reply-To: <20071022164048.71a3dceb@danzwell.com>
On Mon, Oct 22, 2007 at 04:40:48PM -0500, Dan Zwell wrote:
> Note: the code to parse git-style color strings to perl-style color
> strings should eventually be added to Git.pm so that other (perl)
> parts of git can be configured to read colors from .gitconfig in
> a nicer way. A git-style string is "ul red black", while perl
> likes strings like "underline red on_black".
Why not do it as part of this patch, then?
> + # Sane (visible) defaults:
> + if (! @git_prompt_color) {
> + @git_prompt_color = ("blue", "bold");
> + }
I think it might be a bit more readable to keep the assignment and
defaults together:
my @git_prompt_color = split /\s+/,
qx(git config --get color.interactive.prompt) || 'blue bold';
Though I wonder why we are splitting here at all, since we just end up
converting the list into a scalar below. And if we just turned that into
a function, we could get a nice:
my $prompt_color = git_color_to_ansicolor(
qx(git config --get color.interactive.prompt) || 'blue bold');
-Peff
^ permalink raw reply
* [PATCH trailing ws fixed] use only the PATH for exec'ing git commands
From: Scott Parish @ 2007-10-23 4:08 UTC (permalink / raw)
Cc: git
In-Reply-To: <20071022190102.GA23714@steel.home>
We need to correctly set up PATH for non-c based git commands. Since we
already do this, we can just use that PATH and execvp, instead of looping
over the paths with execve.
This patch adds a setup_path() function to exec_cmd.c, which sets
the PATH order correctly for our search order. execv_git_cmd() is
stripped down to setting up argv and calling execvp(). git.c's main()
only only needs to call setup_path().
Signed-off-by: Scott R Parish <srp@srparish.net>
---
exec_cmd.c | 121 ++++++++++++++++++++++++++----------------------------------
exec_cmd.h | 1 +
git.c | 43 +++------------------
3 files changed, 60 insertions(+), 105 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index 8b681d0..c228dbf 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -29,85 +29,68 @@ const char *git_exec_path(void)
return builtin_exec_path;
}
+static void add_path(struct strbuf *out, const char *path)
+{
+ if (path && strlen(path)) {
+ if (is_absolute_path(path))
+ strbuf_addstr(out, path);
+ else
+ strbuf_addstr(out, make_absolute_path(path));
+
+ strbuf_addch(out, ':');
+ }
+}
+
+void setup_path(const char *cmd_path)
+{
+ const char *old_path = getenv("PATH");
+ struct strbuf new_path;
+
+ strbuf_init(&new_path, 0);
+
+ add_path(&new_path, argv_exec_path);
+ add_path(&new_path, getenv(EXEC_PATH_ENVIRONMENT));
+ add_path(&new_path, builtin_exec_path);
+ add_path(&new_path, cmd_path);
+
+ if (old_path)
+ strbuf_addstr(&new_path, old_path);
+ else
+ strbuf_addstr(&new_path, "/usr/local/bin:/usr/bin:/bin");
+
+ setenv("PATH", new_path.buf, 1);
+
+ strbuf_release(&new_path);
+}
int execv_git_cmd(const char **argv)
{
- char git_command[PATH_MAX + 1];
- int i;
- const char *paths[] = { argv_exec_path,
- getenv(EXEC_PATH_ENVIRONMENT),
- builtin_exec_path };
-
- for (i = 0; i < ARRAY_SIZE(paths); ++i) {
- size_t len;
- int rc;
- const char *exec_dir = paths[i];
- const char *tmp;
-
- if (!exec_dir || !*exec_dir) continue;
-
- if (*exec_dir != '/') {
- if (!getcwd(git_command, sizeof(git_command))) {
- fprintf(stderr, "git: cannot determine "
- "current directory: %s\n",
- strerror(errno));
- break;
- }
- len = strlen(git_command);
-
- /* Trivial cleanup */
- while (!prefixcmp(exec_dir, "./")) {
- exec_dir += 2;
- while (*exec_dir == '/')
- exec_dir++;
- }
-
- rc = snprintf(git_command + len,
- sizeof(git_command) - len, "/%s",
- exec_dir);
- if (rc < 0 || rc >= sizeof(git_command) - len) {
- fprintf(stderr, "git: command name given "
- "is too long.\n");
- break;
- }
- } else {
- if (strlen(exec_dir) + 1 > sizeof(git_command)) {
- fprintf(stderr, "git: command name given "
- "is too long.\n");
- break;
- }
- strcpy(git_command, exec_dir);
- }
-
- len = strlen(git_command);
- rc = snprintf(git_command + len, sizeof(git_command) - len,
- "/git-%s", argv[0]);
- if (rc < 0 || rc >= sizeof(git_command) - len) {
- fprintf(stderr,
- "git: command name given is too long.\n");
- break;
- }
+ struct strbuf cmd;
+ const char *tmp;
- /* argv[0] must be the git command, but the argv array
- * belongs to the caller, and my be reused in
- * subsequent loop iterations. Save argv[0] and
- * restore it on error.
- */
+ strbuf_init(&cmd, 0);
+ strbuf_addf(&cmd, "git-%s", argv[0]);
- tmp = argv[0];
- argv[0] = git_command;
+ /* argv[0] must be the git command, but the argv array
+ * belongs to the caller, and my be reused in
+ * subsequent loop iterations. Save argv[0] and
+ * restore it on error.
+ */
+ tmp = argv[0];
+ argv[0] = cmd.buf;
- trace_argv_printf(argv, -1, "trace: exec:");
+ trace_argv_printf(argv, -1, "trace: exec:");
- /* execve() can only ever return if it fails */
- execve(git_command, (char **)argv, environ);
+ /* execvp() can only ever return if it fails */
+ execvp(cmd.buf, (char **)argv);
- trace_printf("trace: exec failed: %s\n", strerror(errno));
+ trace_printf("trace: exec failed: %s\n", strerror(errno));
- argv[0] = tmp;
- }
- return -1;
+ argv[0] = tmp;
+ strbuf_release(&cmd);
+
+ return -1;
}
diff --git a/exec_cmd.h b/exec_cmd.h
index da99287..a892355 100644
--- a/exec_cmd.h
+++ b/exec_cmd.h
@@ -3,6 +3,7 @@
extern void git_set_argv_exec_path(const char *exec_path);
extern const char* git_exec_path(void);
+extern void setup_path(const char *);
extern int execv_git_cmd(const char **argv); /* NULL terminated */
extern int execl_git_cmd(const char *cmd, ...);
diff --git a/git.c b/git.c
index f659338..a639e42 100644
--- a/git.c
+++ b/git.c
@@ -6,28 +6,6 @@
const char git_usage_string[] =
"git [--version] [--exec-path[=GIT_EXEC_PATH]] [-p|--paginate|--no-pager] [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE] [--help] COMMAND [ARGS]";
-static void prepend_to_path(const char *dir, int len)
-{
- const char *old_path = getenv("PATH");
- char *path;
- int path_len = len;
-
- if (!old_path)
- old_path = "/usr/local/bin:/usr/bin:/bin";
-
- path_len = len + strlen(old_path) + 1;
-
- path = xmalloc(path_len + 1);
-
- memcpy(path, dir, len);
- path[len] = ':';
- memcpy(path + len + 1, old_path, path_len - len);
-
- setenv("PATH", path, 1);
-
- free(path);
-}
-
static int handle_options(const char*** argv, int* argc, int* envchanged)
{
int handled = 0;
@@ -403,7 +381,7 @@ int main(int argc, const char **argv)
{
const char *cmd = argv[0] ? argv[0] : "git-help";
char *slash = strrchr(cmd, '/');
- const char *exec_path = NULL;
+ const char *cmd_path = NULL;
int done_alias = 0;
/*
@@ -413,10 +391,7 @@ int main(int argc, const char **argv)
*/
if (slash) {
*slash++ = 0;
- if (*cmd == '/')
- exec_path = cmd;
- else
- exec_path = xstrdup(make_absolute_path(cmd));
+ cmd_path = cmd;
cmd = slash;
}
@@ -451,16 +426,12 @@ int main(int argc, const char **argv)
cmd = argv[0];
/*
- * We execute external git command via execv_git_cmd(),
- * which looks at "--exec-path" option, GIT_EXEC_PATH
- * environment, and $(gitexecdir) in Makefile while built,
- * in this order. For scripted commands, we prepend
- * the value of the exec_path variable to the PATH.
+ * We use PATH to find git commands, but we prepend some higher
+ * precidence paths: the "--exec-path" option, the GIT_EXEC_PATH
+ * environment, and the $(gitexecdir) from the Makefile at build
+ * time.
*/
- if (exec_path)
- prepend_to_path(exec_path, strlen(exec_path));
- exec_path = git_exec_path();
- prepend_to_path(exec_path, strlen(exec_path));
+ setup_path(cmd_path);
while (1) {
/* See if it's an internal command */
--
gitgui.0.8.4.11176.gd9205-dirty
^ permalink raw reply related
* Re: What's cooking in git/spearce.git (topics)
From: Shawn O. Pearce @ 2007-10-23 4:05 UTC (permalink / raw)
To: Theodore Tso; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <20071023020044.GA27132@thunk.org>
Theodore Tso <tytso@mit.edu> wrote:
> On Mon, Oct 22, 2007 at 06:29:59PM -0700, Junio C Hamano wrote:
> > Well, the policy is never to commit directly on top of next
> > (iow, only merge other topics and nothing else). Otherwise it
> > becomes hard to allow individual topics graduate to 'master'
> > independently.
>
> I see. So if it's non-trivial enough that you want it to "cook" in
> next for a cycle, you'll create a topic branch for it (based off of
> 'master'), and then force a merge into 'next'?
Yes. Because 'next' always has commits in it that never appear in
'master'. So any topic forked from master must merge into next.
It can't be a fast-forward. No forced merging required.
Of course this isn't true for a new project. That first topic
that forked from master to *create* next will be a fast-forward
as it creates next. But that's no big deal. The second topic will
merge into next, and that first topic can still be merged back into
master without merging next (or the second topic).
I was also doing the same thing Junio already explained to manage
next and pu while he was away. Except I shortcut his:
git checkout pu
git reset --hard next
as:
git branch -f pu next
git checkout pu
as I'm was usually already sitting on next. This saved my poor
little laptop from a second of IO chugging as it slewed around
between the two versions. There were no files to update as it
switched from next to pu, and pu was already setup for merging
the proposed topics. :-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/2] Added basic color support to git add --interactive
From: Jeff King @ 2007-10-23 4:03 UTC (permalink / raw)
To: Dan Zwell
Cc: Shawn O. Pearce, Wincent Colaiuta, Git Mailing List,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld
In-Reply-To: <20071022163244.4af72973@danzwell.com>
On Mon, Oct 22, 2007 at 04:32:44PM -0500, Dan Zwell wrote:
> +my ($use_color, $prompt_color, $header_color, $help_color);
> +my $color_config = qx(git config --get color.interactive);
> +if ($color_config=~/true|always/ || -t STDOUT && $color_config=~/auto/) {
> + $use_color = "true";
> + # Sane (visible) defaults:
> + $prompt_color = "blue bold";
> + $header_color = "bold";
> + $help_color = "red bold";
Bad indentation?
> +sub print_colored {
> + my $color = shift;
> + my @strings = @_;
> +
> + if ($use_color) {
> + print Term::ANSIColor::color($color);
> + print(@strings);
> + print Term::ANSIColor::color("reset");
> + } else {
> + print @strings;
> + }
> +}
This does nothing for embedded newlines in the strings, which means that
you can end up with ${COLOR}text\n${RESET}, which fouls up changed
backgrounds. See commit 50f575fc. Since the strings you are printing are
small, I don't see any problem with making a copy, using a regex to
insert the color coding, and printing that (I think I even posted
example code in a previous thread on this subject).
-Peff
^ permalink raw reply
* Re: [PATCH] Add some fancy colors in the test library when terminal supports it.
From: Christian Couder @ 2007-10-23 4:08 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Shawn O. Pearce, git
In-Reply-To: <20071022081341.GC32763@artemis.corp>
Hi Pierre,
Le lundi 22 octobre 2007, Pierre Habouzit a écrit :
> +
> +say_color () {
> + [ "$nocolor" = 0 ] && [ "$1" != '-1' ] && tput setaf "$1"
> + shift
> + echo "* $*"
> + tput op
> +}
> +
> error () {
> - echo "* error: $*"
> + say_color 9 "* error: $*"
This will print something like "* * error: ..." instead of "* error: ..."
The following should work:
> + say_color 9 "error: $*"
By the way, where do the 9 here and the 10 and the -1 below come from ?
"man 5 terminfo" says that only values form 0 to 7 are portably defined.
Maybe 9 is a bold red and 10 a bold green, or something like that, but it
doesn't seem to work on my konsole.
Anyway, perhaps having:
_red=1
_green=2
and then using "say_color $_red stuff" might be easier to understand and
change if needed.
Thanks for this good idea,
Christian.
^ permalink raw reply
* Re: What's cooking in git/spearce.git (topics)
From: Theodore Tso @ 2007-10-23 2:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Shawn O. Pearce, git
In-Reply-To: <7vtzoi8voo.fsf@gitster.siamese.dyndns.org>
On Mon, Oct 22, 2007 at 06:29:59PM -0700, Junio C Hamano wrote:
> Well, the policy is never to commit directly on top of next
> (iow, only merge other topics and nothing else). Otherwise it
> becomes hard to allow individual topics graduate to 'master'
> independently.
I see. So if it's non-trivial enough that you want it to "cook" in
next for a cycle, you'll create a topic branch for it (based off of
'master'), and then force a merge into 'next'?
- Ted
^ permalink raw reply
* Re: What's cooking in git/spearce.git (topics)
From: Jeff King @ 2007-10-23 3:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Shawn O. Pearce, git
In-Reply-To: <alpine.LFD.0.999.0710221930330.30120@woody.linux-foundation.org>
On Mon, Oct 22, 2007 at 07:32:02PM -0700, Linus Torvalds wrote:
> Your patch is better than what used to be there, but
>
> > - /* Already picked as a destination? */
> > + /* Already picked as a source? */
> > if (!p->src_dst)
> > continue;
>
> the above is wrong, the whole thing should be dropped (we *want* to be
> able to re-use sources).
Oops, you're right. I'm not sure what I was thinking.
> Anyway, the set of fixes I sent out earlier included fixing that stupid
> loop as one of the things.
Looks like you have made some real progress. I'll try to review your
patch tonight, and hopefully make some progress on the inexact case.
-Peff
^ permalink raw reply
* Re: What's cooking in git/spearce.git (topics)
From: Shawn O. Pearce @ 2007-10-23 3:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7du8vv7.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Thanks for keeping the git list running smoothly while I was away.
Funny thing. There's this tool called "git" that makes it really
easy to fork a project, apply patches straight from email, and
republish it for others to read and work on top of. You should
check it out sometime. :-)
> I've pulled the four integration branches from you, and split
> out the topic branches out of next and pu so that I can take a
> look at them individually. I haven't looked at the actual
> changes yet (but I do not have to, as long as I can trust
> capable others), and only skimmed the list messages (about 2200
> of them since I left).
>
> git.git at k.org and alt-git.git at repo.or.cz should be in sync
> with you now. I'll take a look at the recent changes after
> grabbing some sleep ;-)
We're glad to have you back. Or should I say _I'm_ glad to have
you back. Never underestimate a man until you've at least walked
a week in his shoes. :-)
Most of the patches that happened while you were away were merged
or parked into my git/spearce.git work (in large part thanks
to Lars Hjemli's work during the first week you were offline).
So hopefully you can just pickup from "recent history" (e.g. today
forward) and if we missed anything really interesting authors can
repost once you've had a chance to get caught up.
--
Shawn.
^ permalink raw reply
* Re: What's cooking in git/spearce.git (topics)
From: Linus Torvalds @ 2007-10-23 2:32 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, git
In-Reply-To: <20071022071644.GA7290@coredump.intra.peff.net>
Sorry, I missed this while being busy hacking and not reading email ;)
On Mon, 22 Oct 2007, Jeff King wrote:
>
> Patch is below (please just squash with the one from Linus).
Your patch is better than what used to be there, but
> - /* Already picked as a destination? */
> + /* Already picked as a source? */
> if (!p->src_dst)
> continue;
the above is wrong, the whole thing should be dropped (we *want* to be
able to re-use sources).
Anyway, the set of fixes I sent out earlier included fixing that stupid
loop as one of the things.
Linus
^ permalink raw reply
* [PATCH] Let git-add--interactive read "git colors" from git-config
From: Dan Zwell @ 2007-10-23 2:19 UTC (permalink / raw)
To: Dan Zwell
Cc: Shawn O. Pearce, Jeff King, Wincent Colaiuta, Git Mailing List,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld
In-Reply-To: <20071022163244.4af72973@danzwell.com>
Colors are specified in color.interactive.{prompt,header,help}.
They are specified as git color strings as described in the
documentation, then parsed into perl color strings (slightly
different). Ugly but visible defaults are still used.
Signed-off-by: Dan Zwell <dzwell@zwell.net>
---
This patch is againts Shawn Pearce's "pu" branch.
Documentation/config.txt | 17 ++-------
git-add--interactive.perl | 78 +++++++++++++++++++++++++++++++++++++++++---
2 files changed, 76 insertions(+), 19 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 99b3817..d06f55f 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -390,19 +390,10 @@ color.interactive::
color.interactive.<slot>::
Use customized color for `git add --interactive`
- output. `<slot>` may be `prompt`, `header`, or `help`,
- for three distinct types of common output from interactive
- programs. The values may be a space-delimited combination
- of up to three of the following:
-+
-(optional attribute, optional foreground color, and optional background)
-+
-dark, bold, underline, underscore, blink, reverse, concealed,
-black, red, green, yellow, blue, magenta, cyan, white, on_black,
-on_red, on_green, on_yellow, on_blue, on_magenta, on_cyan, on_white
-+
-Note these are not the same colors/attributes that the rest of
-git supports, but are specific to `git-add --interactive`.
+ output. `<slot>` may be `prompt`, `header`, or `help`, for
+ three distinct types of normal output from interactive
+ programs. The values of these variables may be specified as
+ in color.branch.<slot>.
color.pager::
A boolean to enable/disable colored output when the pager is in
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 37be4b0..ca1ca28 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -6,12 +6,78 @@ my ($use_color, $prompt_color, $header_color, $help_color);
my $color_config = qx(git config --get color.interactive);
if ($color_config=~/true|always/ || -t STDOUT && $color_config=~/auto/) {
$use_color = "true";
- chomp( $prompt_color = qx(git config --get color.interactive.prompt) );
- chomp( $header_color = qx(git config --get color.interactive.header) );
- chomp( $help_color = qx(git config --get color.interactive.help) );
- $prompt_color ||= "red bold";
- $header_color ||= "bold";
- $help_color ||= "blue bold";
+ # Grab the 3 main colors in git color string format:
+ my @git_prompt_color =
+ split(/\s+/, qx(git config --get color.interactive.prompt));
+ my @git_header_color =
+ split(/\s+/, qx(git config --get color.interactive.header));
+ my @git_help_color =
+ split(/\s+/, qx(git config --get color.interactive.help));
+
+ # Sane (visible) defaults:
+ if (! @git_prompt_color) {
+ @git_prompt_color = ("blue", "bold");
+ }
+ if (! @git_header_color) {
+ @git_header_color = ("bold");
+ }
+ if (! @git_help_color) {
+ @git_help_color = ("red", "bold");
+ }
+
+ # Parse the git colors into perl colors:
+ my %attrib_mappings = (
+ "bold" => "bold",
+ "ul" => "underline",
+ "blink" => "blink",
+ # not supported:
+ #"dim" => "",
+ "reverse" => "reverse"
+ );
+
+ my @tmp_perl_colors;
+ my $color_list;
+ # Loop over the array of (arrays of) git-style colors
+ foreach $color_list ([@git_prompt_color], [@git_header_color],
+ [@git_help_color]) {
+ my $fg_done;
+ my @perl_attribs;
+ my $word;
+ foreach $word (@{$color_list}) {
+ if ($word =~ /normal/) {
+ $fg_done = "true";
+ }
+ elsif ($word =~ /black|red|green|yellow/ ||
+ $word =~ /blue|magenta|cyan|white/) {
+ # is a color.
+ if ($fg_done) {
+ # this is the background
+ push @perl_attribs, "on_" . $word;
+ }
+ else {
+ # this is foreground
+ $fg_done = "true";
+ push @perl_attribs, $word;
+ }
+ }
+ else {
+ # this is an attribute, not a color.
+ if ($attrib_mappings{$word}) {
+ push(@perl_attribs,
+ $attrib_mappings{$word});
+ }
+ }
+ }
+ if (@perl_attribs) {
+ push @tmp_perl_colors, join(" ", @perl_attribs);
+ }
+ else {
+ #@perl_attribs is empty, need a placeholder
+ push @tmp_perl_colors, "reset";
+ }
+ }
+ ($prompt_color, $header_color, $help_color) =
+ @tmp_perl_colors;
require Term::ANSIColor;
}
--
1.5.3.4.207.gc0ee
^ permalink raw reply related
* Re: [PATCH] resend of git-add--interactive color patch against spearce/pu
From: Dan Zwell @ 2007-10-23 2:11 UTC (permalink / raw)
To: Dan Zwell
Cc: Shawn O. Pearce, Jeff King, Wincent Colaiuta, Git Mailing List,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld
In-Reply-To: <20071022163244.4af72973@danzwell.com>
I apparently missed the e-mail where Shawn Pearce explained where his
repository was. The following patch is my recent change(s), rebased
against that.
Dan
^ permalink raw reply
* [PATCH 1/2] gitweb: Refactor abbreviation-with-title-attribute code.
From: David Symonds @ 2007-10-23 1:31 UTC (permalink / raw)
To: pasky, spearce; +Cc: git, David Symonds
Signed-off-by: David Symonds <dsymonds@gmail.com>
---
gitweb/gitweb.perl | 45 +++++++++++++++++++++------------------------
1 files changed, 21 insertions(+), 24 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index ea84c75..a835bd1 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -842,6 +842,23 @@ sub chop_str {
return "$body$tail";
}
+# takes the same arguments as chop_str, but also wraps a <span> around the
+# result with a title attribute if it does get chopped. Additionally, the
+# string is HTML-escaped.
+sub chop_and_escape_str {
+ my $str = shift;
+ my $len = shift;
+ my $add_len = shift || 10;
+
+ my $chopped = chop_str($str, $len, $add_len);
+ if ($chopped eq $str) {
+ return esc_html($chopped);
+ } else {
+ return qq{<span title="} . esc_html($str) . qq{">} .
+ esc_html($chopped) . qq{</span>};
+ }
+}
+
## ----------------------------------------------------------------------
## functions returning short strings
@@ -3427,12 +3444,7 @@ sub git_shortlog_body {
print "<tr class=\"light\">\n";
}
$alternate ^= 1;
- my $author = chop_str($co{'author_name'}, 10);
- if ($author ne $co{'author_name'}) {
- $author = "<span title=\"" . esc_html($co{'author_name'}) . "\">" . esc_html($author) . "</span>";
- } else {
- $author = esc_html($author);
- }
+ my $author = chop_and_escape_str($co{'author_name'}, 10);
# git_summary() used print "<td><i>$co{'age_string'}</i></td>\n" .
print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
"<td><i>" . $author . "</i></td>\n" .
@@ -3484,12 +3496,7 @@ sub git_history_body {
}
$alternate ^= 1;
# shortlog uses chop_str($co{'author_name'}, 10)
- my $author = chop_str($co{'author_name'}, 15, 3);
- if ($author ne $co{'author_name'}) {
- "<span title=\"" . esc_html($co{'author_name'}) . "\">" . esc_html($author) . "</span>";
- } else {
- $author = esc_html($author);
- }
+ my $author = chop_and_escape_str($co{'author_name'}, 15, 3);
print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
"<td><i>" . $author . "</i></td>\n" .
"<td>";
@@ -3645,12 +3652,7 @@ sub git_search_grep_body {
print "<tr class=\"light\">\n";
}
$alternate ^= 1;
- my $author = chop_str($co{'author_name'}, 15, 5);
- if ($author ne $co{'author_name'}) {
- $author = "<span title=\"" . esc_html($co{'author_name'}) . "\">" . esc_html($author) . "</span>";
- } else {
- $author = esc_html($author);
- }
+ my $author = chop_and_escape_str($co{'author_name'}, 15, 5);
print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
"<td><i>" . $author . "</i></td>\n" .
"<td>" .
@@ -5165,12 +5167,7 @@ sub git_search {
print "<tr class=\"light\">\n";
}
$alternate ^= 1;
- my $author = chop_str($co{'author_name'}, 15, 5);
- if ($author ne $co{'author_name'}) {
- $author = "<span title=\"" . esc_html($co{'author_name'}) . "\">" . esc_html($author) . "</span>";
- } else {
- $author = esc_html($author);
- }
+ my $author = chop_and_escape_str($co{'author_name'}, 15, 5);
print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
"<td><i>" . $author . "</i></td>\n" .
"<td>" .
--
1.5.3.1
^ permalink raw reply related
* [PATCH 2/2] gitweb: Use chop_and_escape_str in more places.
From: David Symonds @ 2007-10-23 1:31 UTC (permalink / raw)
To: pasky, spearce; +Cc: git, David Symonds
In-Reply-To: <1193103083390-git-send-email-dsymonds@gmail.com>
Signed-off-by: David Symonds <dsymonds@gmail.com>
---
gitweb/gitweb.perl | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index a835bd1..1b6c823 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3402,7 +3402,7 @@ sub git_project_list_body {
"<td>" . $cgi->a({-href => href(project=>$pr->{'path'}, action=>"summary"),
-class => "list", -title => $pr->{'descr_long'}},
esc_html($pr->{'descr'})) . "</td>\n" .
- "<td><i>" . esc_html(chop_str($pr->{'owner'}, 15)) . "</i></td>\n";
+ "<td><i>" . chop_and_escape_str($pr->{'owner'}, 15) . "</i></td>\n";
print "<td class=\"". age_class($pr->{'age'}) . "\">" .
(defined $pr->{'age_string'} ? $pr->{'age_string'} : "No commits") . "</td>\n" .
"<td class=\"link\">" .
@@ -3657,7 +3657,7 @@ sub git_search_grep_body {
"<td><i>" . $author . "</i></td>\n" .
"<td>" .
$cgi->a({-href => href(action=>"commit", hash=>$co{'id'}), -class => "list subject"},
- esc_html(chop_str($co{'title'}, 50)) . "<br/>");
+ chop_and_escape_str($co{'title'}, 50) . "<br/>");
my $comment = $co{'comment'};
foreach my $line (@$comment) {
if ($line =~ m/^(.*)($search_regexp)(.*)$/i) {
@@ -5173,7 +5173,7 @@ sub git_search {
"<td>" .
$cgi->a({-href => href(action=>"commit", hash=>$co{'id'}),
-class => "list subject"},
- esc_html(chop_str($co{'title'}, 50)) . "<br/>");
+ chop_and_escape_str($co{'title'}, 50) . "<br/>");
while (my $setref = shift @files) {
my %set = %$setref;
print $cgi->a({-href => href(action=>"blob", hash_base=>$co{'id'},
--
1.5.3.1
^ permalink raw reply related
* Re: What's cooking in git/spearce.git (topics)
From: Junio C Hamano @ 2007-10-23 1:29 UTC (permalink / raw)
To: Theodore Tso; +Cc: Johannes Schindelin, Shawn O. Pearce, git
In-Reply-To: <20071023012140.GC22997@thunk.org>
Theodore Tso <tytso@mit.edu> writes:
> I assume PU is what you used to build your proposed-update branch?
> I'm actually trying to use it, and it is useful, although it hasn't
> been working for me completely perfectly. I've still been trying to
> figure out if the reason why it hasn't been working quite right is due
> to my not understanding how to use it correctly, or whether you don't
> use it these days.
Ah, these days I almost always do:
git checkout pu
git reset --hard next
and then merge the topics that haven't been merged anywhere by
hand, using output from
Meta/git-topic.perl
as the guide.
> One question which I have had about the WC script is that if I
> manually add a commit to the next branch, it ends up showing up in all
> of the topic branches as a commit that was part of that topic branch
> which is in next...
Well, the policy is never to commit directly on top of next
(iow, only merge other topics and nothing else). Otherwise it
becomes hard to allow individual topics graduate to 'master'
independently.
^ permalink raw reply
* Re: What's cooking in git/spearce.git (topics)
From: Junio C Hamano @ 2007-10-23 1:26 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071022063222.GS14735@spearce.org>
Thanks for keeping the git list running smoothly while I was away.
I've pulled the four integration branches from you, and split
out the topic branches out of next and pu so that I can take a
look at them individually. I haven't looked at the actual
changes yet (but I do not have to, as long as I can trust
capable others), and only skimmed the list messages (about 2200
of them since I left).
git.git at k.org and alt-git.git at repo.or.cz should be in sync
with you now. I'll take a look at the recent changes after
grabbing some sleep ;-)
^ permalink raw reply
* Re: What's cooking in git/spearce.git (topics)
From: Theodore Tso @ 2007-10-23 1:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Shawn O. Pearce, git
In-Reply-To: <7v3aw2aaxu.fsf@gitster.siamese.dyndns.org>
On Mon, Oct 22, 2007 at 06:15:09PM -0700, Junio C Hamano wrote:
> >
> > I've recently started trying to use some of the scripts in "todo" to
> > send similar "What's cooking" messages, and started wondering if they
> > were what Junio actually used in production to send his notes. For
> > example, the scripts don't work particularly well if the refs have
> > been packed. So I had to make changes such as these so they would
> > work for me.
>
> Sorry, WI is for "what's in", WC is for "what's cooking". I
> should remove PU and RB from there.
>
I assume PU is what you used to build your proposed-update branch?
I'm actually trying to use it, and it is useful, although it hasn't
been working for me completely perfectly. I've still been trying to
figure out if the reason why it hasn't been working quite right is due
to my not understanding how to use it correctly, or whether you don't
use it these days.
One question which I have had about the WC script is that if I
manually add a commit to the next branch, it ends up showing up in all
of the topic branches as a commit that was part of that topic branch
which is in next. So I can manually edit the output of WC to remove
the spurious commit, or I could make it be a rule that all new commits
either must go against the master branch, or be put in a topic branch
based off of master, and then merged into next. Or maybe I'm not
understanding how to make the WC and git-topic.perl script work and
sing for me perfectly?
- Ted
^ permalink raw reply
* Re: What's cooking in git/spearce.git (topics)
From: Junio C Hamano @ 2007-10-23 1:15 UTC (permalink / raw)
To: Theodore Tso; +Cc: Johannes Schindelin, Shawn O. Pearce, git
In-Reply-To: <20071016195744.GB32132@closure.lan>
Theodore Tso <tytso@mit.edu> writes:
> On Tue, Oct 16, 2007 at 12:16:28PM +0100, Johannes Schindelin wrote:
>>
>> first let me thank you for being the interim maintainer. I know it is
>> much work, and I frankly do not have the time, or nerve, to do it. Out of
>> curiousity: did you use the scripts in "todo" to send these emails?
>
> I've recently started trying to use some of the scripts in "todo" to
> send similar "What's cooking" messages, and started wondering if they
> were what Junio actually used in production to send his notes. For
> example, the scripts don't work particularly well if the refs have
> been packed. So I had to make changes such as these so they would
> work for me.
Sorry, WI is for "what's in", WC is for "what's cooking". I
should remove PU and RB from there.
^ permalink raw reply
* Re: Linear time/space rename logic for *inexact* case
From: Linus Torvalds @ 2007-10-23 0:49 UTC (permalink / raw)
To: Andy C; +Cc: Jeff King, git
In-Reply-To: <596909b30710221647y6a7481c5me41c31bbe1015e3a@mail.gmail.com>
On Mon, 22 Oct 2007, Andy C wrote:
>
> from diffcore-delta.c:
> "
> * Idea here is very simple.
> *
> * Almost all data we are interested in are text, but sometimes we have
> * to deal with binary data. So we cut them into chunks delimited by
> * LF byte, or 64-byte sequence, whichever comes first, and hash them.
> "
>
> What is the similarity metric for binary files? Is it related to the
> number of 64 byte chunks they have in common? How do you know that
> the 64 byte chunks match up? Suppose I have 10k file, and then I
> insert 10 random bytes at positions, 1000, 2000, 3000, etc. How does
> that work?
The 'LF' byte will start a new window, so even with binary files (assuming
some random-enough distribution that you have *some* 'LF' bytes!), you
basically get a synchronization event on each LF.
So the 64-byte hunks "line up" automatically, even for binary files. Maybe
not immediately, but soon enough (ie on average, assuming some reasonably
compressed - ie virtually random - binary format) you should find a LF
roughly every fourth hunk.
There are probably smarter ways to guarantee it even in the absense of
certain bit-patterns, but I bet the "break every 64 bytes or when you see
a LF" thing works well for any reasonable binary file too.
But text files are obviously the most important case. Diffs on binaries
are somewhat hit-and-miss regardless.
Linus
^ permalink raw reply
* Re: gitk patch collection pull request
From: Paul Mackerras @ 2007-10-23 0:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Shawn O. Pearce, git
In-Reply-To: <alpine.LFD.0.999.0710192149020.3794@woody.linux-foundation.org>
Linus Torvalds writes:
> On Sat, 20 Oct 2007, Paul Mackerras wrote:
> >
> > Do you mean that when you have a file limit, the diff window should
> > just show the diffs for those files, not any other files the commit
> > might have modified?
>
> Yes. The same way "git log -p" works by default.
>
> With perhaps a checkbox to toggle the "--full-diff" behaviour.
OK, done. The checkbox is in the Edit/Preferences window. It's
called "Limit diffs to listed paths" and it's on by default.
> > That would be easy enough to implement in gitk.
>
> Well, the "--merged" case is slightly trickier, since git will figure out
> the pathnames on its own (it limits pathnames to the intersection of the
> names you give one the command line *and* the list of unmerged files, ie
> the "filter" becomes "git ls-files -u [pathspec]".
If you use the --merge flag, gitk will do a git ls-files -u at
startup, and use the result as the list of paths (after intersecting
it with the paths on the command line, if you specify paths there).
I pondered whether I needed to re-do the git ls-files -u when you
update the view with File->Update. I decided not to for now, but it
would be possible to add it.
> But goodie. I look forward to it ;)
I just pushed it out to my gitk.git repo (master branch). Enjoy. :)
Paul.
^ permalink raw reply
* Re: [PATCH] Dissociating a repository from its alternates
From: Johannes Schindelin @ 2007-10-23 0:13 UTC (permalink / raw)
To: Michael Hendricks; +Cc: git
In-Reply-To: <20071022233050.GA18430@ginosko.ndrix.org>
Hi,
On Mon, 22 Oct 2007, Michael Hendricks wrote:
> On Mon, Oct 22, 2007 at 08:05:58PM +0100, Johannes Schindelin wrote:
> > On Mon, 22 Oct 2007, Michael Hendricks wrote:
> > > Was such a script ever incorporated into Git?
> >
> > Not that I know of, but "git repack -a && rm
> > .git/objects/info/alternates" should do what you want. You can even
> > make a script of it, add some documentation and a test case, and earn
> > git fame by posting a patch ;-)
>
> With 1.5.3.4, it doesn't appear to work:
>
> $ git clone -s git git2
> Initialized empty Git repository in /Users/michael/src/git2/.git/
>
> $ cd git2
>
> $ git repack -a && rm .git/objects/info/alternates
> Generating pack...
> Done counting 0 objects.
> Nothing new to pack.
>
> $ git status
> # On branch master
> fatal: bad object HEAD
Indeed. Seems that somewhere along the line, repack learnt to imply "-l"
by "-a" or something. Try this instead of "git repack -a":
git rev-parse --all |
git pack-objects --revs .git/objects/pack/pack
(And make sure you read the relevant parts of the documentation to
understand what you're doing ;-)
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] Add color to git-add--interactive diffs (Total different idea to solve the problem)
From: Johannes Schindelin @ 2007-10-22 23:55 UTC (permalink / raw)
To: Peter Baumann
Cc: Tom Tobin, Dan Zwell, Jonathan del Strother, Shawn O. Pearce,
Git Mailing List
In-Reply-To: <20071022204719.GA23348@xp.machine.xx>
Hi,
On Mon, 22 Oct 2007, Peter Baumann wrote:
> Wouldn't it make more sense to implement the diff coloring inside git
> apply so that you could use something like
>
> diff file1 file2|git apply --color
>
> to make the generated diff with colors [1]? It already implements the
> same semantic for generating a diffstat, using
>
> diff file1 file2|git apply --stat
No. In both cases, "git diff" realises that the output is no terminal,
and switches off color generation. (Just try with diff.color=true instead
of =auto.)
Ciao,
Dscho
^ permalink raw reply
* Re: Linear time/space rename logic for *inexact* case
From: Andy C @ 2007-10-22 23:47 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20071022103439.GA16648@coredump.intra.peff.net>
On 10/22/07, Jeff King <peff@peff.net> wrote:
> On Mon, Oct 22, 2007 at 02:40:08AM -0700, Andy C wrote:
> > You can also prune entries which have a long "postings list" (using
> > the term in the IR sense here:
> > http://www.xapian.org/docs/intro_ir.html). This has the nice side
> > effect of getting rid of quadratic behavior, *and* making the
> > algorithm more accurate because it stops considering common lines like
> > "#endif" as contributing to similarity.
>
> Ah, very clever. I think that should have nice behavior most of the
> time, though I wonder about a pathological case where we have many
> files, all very similar to each other, and then have a commit where they
> all start to diverge, but just by a small amount, while getting moved.
> We would end up with an artificially low score between renamed files
> (because we've thrown out all of the commonality) which may lead us to
> believe there was no rename at all.
>
> But it might be worth ignoring that case.
Well I do adjust the file sizes when pruning. In the .py demo code
you can see it at these lines:
for f in filelist:
sizes[f] -= 1
The similarity metric depends on the sizes, so that way it won't get
out of whack if there are a lot of frequently occurring lines.
I did mention that pathological case to Linus. The worst thing is if
you have N adds and N deletes and every single file is identical.
Well the convenient thing is that the pruning handles this gracefully.
*Every* line in both indices will be pruned, and then the similarity
matrix will be completely empty, and no renames will be recorded.
Arguably that is what you want. You don't want N^2 renames. I guess
you could just assign them randomly to each other too for N renames.
> > http://marc.info/?l=git&m=118975452330644&w=2
> > "Of course, 2 minutes for a git-status is still way too slow, so there we
> > might still need a limiter. It also looks like 57% of my time is spent
> > in spanhash_find, and another 29% in diffcore_count_changes."
> >
> > I know there have been a couple fixes since you posted that, but if it
> > was the O(m*n) behavior that was causing your problem, it should still
> > be reproducible. Linus suggested that this is a good data set to try
> > things out with. Is there there a repository I can clone with git
> > commands to run to repro this?
>
> Yes, I still have the problem (the 2 minutes was _after_ we did fixes,
> down from 20 minutes; the latest patch from Linus just covers the "exact
> match" case where two files have identical SHA1s).
>
> It's a 1.2G repo at the end of a slow DSL line, so rather than cloning
> it, here's a way to reproduce a repo with similar properties:
Ah OK thanks. This is a good test case for binary files, and my
Linux 2.4 vs Linux 2.6 test seems reasonable for text files.
> > 3) Compute the similarity metric, which I've defined here as
> > max(c/|left file|, c/|right file|), where c the entry in the matrix
> > for the file pair. Note that the files are treated as *sets* of lines
> > (unordered, unique). The similarity score is a number between 0.0 and
> > 1.0. Other similarity metrics are certainly possible.
>
> We have to handle binary files, too. In the current implementation, we
> consider either lines or "chunks", and similarity is increased by the
> size of the chunk.
Yes, my thing doesn't handle binary files, but I have a variation of
the idea for that too which I'll explain below.
Can you explain what the current implementation does for binary files
in more detail, or point me to some docs? I'm having a hard code
figuring out what the code is doing, even though the comments insist
that it is very simple : )
from diffcore-delta.c:
"
* Idea here is very simple.
*
* Almost all data we are interested in are text, but sometimes we have
* to deal with binary data. So we cut them into chunks delimited by
* LF byte, or 64-byte sequence, whichever comes first, and hash them.
"
What is the similarity metric for binary files? Is it related to the
number of 64 byte chunks they have in common? How do you know that
the 64 byte chunks match up? Suppose I have 10k file, and then I
insert 10 random bytes at positions, 1000, 2000, 3000, etc. How does
that work?
> > * This can be run on all files, not just adds/deletes. If I have a
>
> Great. git has a "look for copies also" flag, but it is usually disabled
> because of the computational cost. If we can get it low enough, it might
> actually become a lot more useful.
Yes, there seem to be quite a few flags that have to do with trading
off features for computational time/memory. I believe this algorithm
could be made fast enough to simplify the user interface a bit. I'm
not yet super familiar with git, but I imagine it's probably hard for
some users to intuit what these thresholds do.
> > If anything about the explanation is unclear, let me know and I will
> > try to clarify it. Playing around with the demo should illuminate
> > what it does. You can run it on data sets of your own. All you need
> > is 2 source trees and the "find" command to produce input to the
> > script (see setup_demo.sh).
>
> I'll try it on my test data, but it sounds like it doesn't really handle
> binary files.
Yes, I think we should try it out for text files first, since that's
probably the more important case. But at the risk of getting a bit
ahead of myself, I think you can do a similar thing for binary files.
This first part isn't my idea; I heard it at a talk by Udi Manber at
Google, but I think it could be combined with my pruning and sparse
similarity matrix thing. And it looks like there are already some of
the same ideas in git, though I'm still deciphering the code (any docs
on this area would help).
Basically his idea is that you take a rolling window of say 64 bytes
and create an inverted index, just like you do for text files. So if
you have a 10,000 byte file, then there are (10,000 - 64) hashes to be
made.
This could be a lot, so you can speed it up by sampling. But you want
to sample in such a way that preserves commonality. That is, you
don't want to sample a given 64-byte sequence in one doc but miss it
in the other one. So then all you do is keep all windows where the
hash code is 0 mod k (and you can adjust k that to achieve the
sampling rate you want). If a given sequence is sampled in *one* doc,
then it's guaranteed to be sampled in *all* docs.
The second point is that you can do this rolling window hashing very
fast with a polynomial hash. You can use the results of the previous
hash to compute the next hash. I think you already have this in
diff-delta.c, but I'm not quite sure. I'm not sure exactly what that
code is used for either (I don't think it is for the rename matching,
because that is done by estimate_similarity and
diffcore_count_changes?).
Once you have these 2 inverted indices of { sampled subset of 64-byte
substrings -> [list of documents] } then you simply do the same thing
as I suggested for text files. The logic is more or less the same.
If 2 files have many 64-byte substrings in common compared to their
sizes, then they are similar. If a given 64-byte sequence (say
0000000000000...000) appears in many docs, then it's not a good
differentiator or indicator of similarity -- so throw it out.
(It occurs to me that it might be useful to do this with a small
window (8 bytes?) and a larger one (>64), and somehow combine the
results. I guess some experimentation is in order, or maybe there is
some theory about that.)
So this is a linear algorithm too. The hashing could have a high
constant factor, but the sampling and polynomial hashing should
basically eliminate that, I believe.
But like I said, it's probably better to concentrate on the text part
before anyone tackles that (at least I will look at the text case
first). I have less experience with this algorithm, but it seems like
it should work just as well, and is quite simple. I think both of
these algorithms are a bit more general and should lead to a net
reduction in lines of code, which is a good thing.
Andy
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Jakub Narebski @ 2007-10-22 23:35 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Johannes Schindelin, Steffen Prohaska, Federico Mena Quintero,
git
In-Reply-To: <471CB443.9070606@op5.se>
On 10/22/07, Andreas Ericsson <ae@op5.se> wrote:
> Johannes Schindelin wrote:
>> On Mon, 22 Oct 2007, Andreas Ericsson wrote:
>>
>>> If I were to suggest any improvements, it'd be to change the semantics of
>>> git-pull to always update the local branches set up to be merged with the
>>> remote tracking branches when they, prior to fetching, pointed to the same
>>> commit, such that when
>>>
>>> $ git show-ref master
>>> d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/heads/master
>>> d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/remotes/origin/master
>>>
>>> refs/heads/master gets set to refs/remotes/origin/master post-fetch.
>>
>> In general, this should fail. Because you are expected to have local
>> changes in the local branches.
>
>
> BS argument. Git knows when I haven't got any changes on my local
> branches, and it can be fairly safely assumed that when I feel like
> making any, I'd like to make them off as fresh a tip as possible unless
> I explicitly tell git otherwise.
[cut]
It would be I think possible to make git behave as you want, although I'd rather
(at least at first) have behaviour described above turned on by some option
or config variable. I guess that it would be not that hard to make script to do
what you ant (and probably it would be best if you tried your idea that way).
There are the following caveats.
1. For each local branch that is to be updated on pull, this branch
must be marked as tracking some branch of some repository. This has to
be explicitely done; for example by creating those branches using
--track option.
2. Git can do a merge with conflicts _only_ if that branch is checked
out. So for all local branches which you want to get updated using
"git pull --update-all <repo>" (or something like that), the merge
with remote branch should be either fast-forward, trivial merge, or
merge without conflicts. "git pull --update-all <repo>" would return
then list of updated branches and list of branches which cannot be
updated.
So... are you going to try to implement that?
--
Jakub Narebski
^ 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