* Re: [PATCH 0/3] Document and refuse rebase -s ours
From: Thomas Rast @ 2009-11-15 21:13 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Nicolas Sebrecht, Baz, Peter Krefting, Johannes Schindelin,
Björn Steinbrink
In-Reply-To: <7veinzfqj9.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
>
> I'd rewrite [3/3] in the following way to keep it easier to maintain the
> blacklist, like this.
>
> case "$1" in
> - ours)
> + ours | theirs | octopus | subtree)
I agree with the rewrite; it's easier to maintain, even though it's
now in a quite strange place.
However, I think the example you gave is misleading: 'subtree' is a
useful strategy if you want to rebase across a subtree merge boundary,
isn't it?
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCH RFC] git remote: Separate usage strings for subcommands
From: Tim Henigan @ 2009-11-15 21:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
When the usage string for a subcommand must be printed,
only print the information relevant to that command.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
---
This patch is based on:
http://article.gmane.org/gmane.comp.version-control.git/132953
All usage strings are still only located at the top of file. However,
separate usage
string arrays have been created for each subcommand.
Does this look like a sane way to structure the code?
If anyone else should be added to the CC list, please let me know.
builtin-remote.c | 57 +++++++++++++++++++++++++++++++++--------------------
1 files changed, 35 insertions(+), 22 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index 0777dd7..ec65a4b 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -7,18 +7,35 @@
#include "run-command.h"
#include "refs.h"
+#define REMOTE_BARE_USAGE "git remote [-v | --verbose]"
+#define REMOTE_ADD_USAGE "git remote add [-t <branch>] [-m <master>]
[-f] [--mirror] <name> <url>"
+#define REMOTE_RENAME_USAGE "git remote rename <old> <new>"
+#define REMOTE_RM_USAGE "git remote rm <name>"
+#define REMOTE_SETHEAD_USAGE "git remote set-head <name> [-a | -d | <branch>]"
+#define REMOTE_SHOW_USAGE "git remote show [-n] <name>"
+#define REMOTE_PRUNE_USAGE "git remote prune [-n | --dry-run] <name>"
+#define REMOTE_UPDATE_USAGE "git remote [-v | --verbose] update [-p |
--prune] [group]"
+
static const char * const builtin_remote_usage[] = {
- "git remote [-v | --verbose]",
- "git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>",
- "git remote rename <old> <new>",
- "git remote rm <name>",
- "git remote set-head <name> [-a | -d | <branch>]",
- "git remote show [-n] <name>",
- "git remote prune [-n | --dry-run] <name>",
- "git remote [-v | --verbose] update [-p | --prune] [group]",
+ REMOTE_BARE_USAGE,
+ REMOTE_ADD_USAGE,
+ REMOTE_RENAME_USAGE,
+ REMOTE_RM_USAGE,
+ REMOTE_SETHEAD_USAGE,
+ REMOTE_SHOW_USAGE,
+ REMOTE_PRUNE_USAGE,
+ REMOTE_UPDATE_USAGE,
NULL
};
+static const char * const builtin_remote_add_usage[] = {
REMOTE_ADD_USAGE, NULL };
+static const char * const builtin_remote_rename_usage[] = {
REMOTE_RENAME_USAGE, NULL };
+static const char * const builtin_remote_rm_usage[] = {
REMOTE_RM_USAGE, NULL };
+static const char * const builtin_remote_sethead_usage[] = {
REMOTE_SETHEAD_USAGE, NULL };
+static const char * const builtin_remote_show_usage[] = {
REMOTE_SHOW_USAGE, NULL };
+static const char * const builtin_remote_prune_usage[] = {
REMOTE_PRUNE_USAGE, NULL };
+static const char * const builtin_remote_update_usage[] = {
REMOTE_UPDATE_USAGE, NULL };
+
#define GET_REF_STATES (1<<0)
#define GET_HEAD_NAMES (1<<1)
#define GET_PUSH_REF_STATES (1<<2)
@@ -70,7 +87,6 @@ static int add(int argc, const char **argv)
int i;
struct option options[] = {
- OPT_GROUP("add specific options"),
OPT_BOOLEAN('f', "fetch", &fetch, "fetch the remote branches"),
OPT_CALLBACK('t', "track", &track, "branch",
"branch(es) to track", opt_parse_track),
@@ -79,11 +95,11 @@ static int add(int argc, const char **argv)
OPT_END()
};
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_add_usage,
0);
if (argc < 2)
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_add_usage, options);
name = argv[0];
url = argv[1];
@@ -540,7 +556,7 @@ static int mv(int argc, const char **argv)
int i;
if (argc != 3)
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_rename_usage, options);
rename.old = argv[1];
rename.new = argv[2];
@@ -681,7 +697,7 @@ static int rm(int argc, const char **argv)
int i, result;
if (argc != 2)
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_rm_usage, options);
remote = remote_get(argv[1]);
if (!remote)
@@ -984,7 +1000,7 @@ static int show(int argc, const char **argv)
struct string_list info_list = { NULL, 0, 0, 0 };
struct show_info info;
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_show_usage,
0);
if (argc < 1)
@@ -1088,7 +1104,7 @@ static int set_head(int argc, const char **argv)
"delete refs/remotes/<name>/HEAD"),
OPT_END()
};
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_sethead_usage,
0);
if (argc)
strbuf_addf(&buf, "refs/remotes/%s/HEAD", argv[0]);
@@ -1114,7 +1130,7 @@ static int set_head(int argc, const char **argv)
if (delete_ref(buf.buf, NULL, REF_NODEREF))
result |= error("Could not delete %s", buf.buf);
} else
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_sethead_usage, options);
if (head_name) {
unsigned char sha1[20];
@@ -1138,16 +1154,15 @@ static int prune(int argc, const char **argv)
{
int dry_run = 0, result = 0;
struct option options[] = {
- OPT_GROUP("prune specific options"),
OPT__DRY_RUN(&dry_run),
OPT_END()
};
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_prune_usage,
0);
if (argc < 1)
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_prune_usage, options);
for (; argc; argc--, argv++)
result |= prune_remote(*argv, dry_run);
@@ -1228,13 +1243,12 @@ static int update(int argc, const char **argv)
struct string_list list = { NULL, 0, 0, 0 };
static const char *default_argv[] = { NULL, "default", NULL };
struct option options[] = {
- OPT_GROUP("update specific options"),
OPT_BOOLEAN('p', "prune", &prune,
"prune remotes after fetching"),
OPT_END()
};
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_update_usage,
PARSE_OPT_KEEP_ARGV0);
if (argc < 2) {
argc = 2;
@@ -1334,7 +1348,6 @@ static int show_all(void)
int cmd_remote(int argc, const char **argv, const char *prefix)
{
struct option options[] = {
- OPT__VERBOSE(&verbose),
OPT_END()
};
int result;
--
1.6.5.2.185.gb7fba.dirty
^ permalink raw reply related
* Re: [RFC] format-patch: Ensure that author and commit time are not lost
From: Björn Gustavsson @ 2009-11-15 22:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzl6nfqkx.fsf@alter.siamese.dyndns.org>
2009/11/15 Junio C Hamano <gitster@pobox.com>:
> I think you are addressing a very valid issue, but I suspect that you are
> doing so at a wrong place in the "patch mail-out" workflow.
[...]
> This new function is not about "Is the _sender_ the same as the author?",
> but is about "Is the person who is running format-patch the same as the
> author?". There is a big difference.
Yes, I kind of suspected that my solution would not
be general enough to suit all users and workflows.
Thanks for the feedback.
/Björn
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2009, #03; Sun, 15)
From: Daniel Barkalow @ 2009-11-15 22:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtywwm6i4.fsf@alter.siamese.dyndns.org>
On Sun, 15 Nov 2009, Junio C Hamano wrote:
> * sr/vcs-helper (2009-11-06) 12 commits
> - Add Python support library for remote helpers
> - Basic build infrastructure for Python scripts
> - Allow helpers to request the path to the .git directory
> - Allow helpers to report in "list" command that the ref is unchanged
> - Allow helper to map private ref names into normal names
> - Add support for "import" helper command
> - Allow specifying the remote helper in the url
> - Add a config option for remotes to specify a foreign vcs
> - Allow fetch to modify refs
> - Use a function to determine whether a remote is valid
> - Allow programs to not depend on remotes having urls
> - Fix memory leak in helper method for disconnect
>
> Re-rolled series that contains Daniel's and Johan's.
> Any comments? Is everybody happy?
My initial cleanup for "Allow helper to map private ref names into normal
names" was wrong (and the original was supposed to be RFC, and isn't
signed-off); I identified the bug he reported in it, but haven't gotten
positive test results from him yet, and the series obviously needs a
proper version rolled in before it goes into next.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2009, #03; Sun, 15)
From: Sverre Rabbelier @ 2009-11-15 23:32 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LNX.2.00.0911151711170.14365@iabervon.org>
Heya,
On Sun, Nov 15, 2009 at 23:26, Daniel Barkalow <barkalow@iabervon.org> wrote:
> My initial cleanup for "Allow helper to map private ref names into normal
> names" was wrong (and the original was supposed to be RFC, and isn't
> signed-off); I identified the bug he reported in it, but haven't gotten
> positive test results from him yet, and the series obviously needs a
> proper version rolled in before it goes into next.
Sorry, I tested, got primary positive results, then wanted to test
something else and instead of:
~/code$ rm -rf test
I did:
~/code$ rm -rf git
I hate it when my fingers don't listen. Anyway, I ^C-ed and managed to
save my worktree, but most of my git/.git was gone already. I'll get
back to you tomorrow with more results since the time I was going to
spend on running it through valgrind was wasted trying to recover my
git repo :P.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2009, #03; Sun, 15)
From: Peter Weseloh @ 2009-11-15 23:40 UTC (permalink / raw)
To: git
In-Reply-To: <7vtywwm6i4.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster <at> pobox.com> writes:
> * nd/sparse (2009-08-20) 19 commits.
>
> The latest update I didn't look at very closely but I had an impression
> that it was touching very generic codepath that would affect non sparse
> cases, iow the patch looked very scary (the entire series already is).
Hi,
I'm new here so first of all thanks a lot for such a great tool!
Does that mean this feature will not make it into 'master' any time soon?
I'm currently trying to convince my managment to switch from CVS to git.
What causes some trouble is that we have quite some files (> 40k) in various
(>300) CVS modules and splitting them into sub-repos seams somewhat difficult.
git has no problem even with that many files but commands that stat the
working copy (e.g. 'git status') take quite long on our filers
(it's either a problem with the filers or with nfs or both, I don't know yet).
Having the ability to do sparse checkouts only of the repo sounds like a
way out.
Annother question: What's the timeline for 1.7.0? I couldn't find anything
about it neither here nor in the wiki.
Thanks,
Peter
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2009, #03; Sun, 15)
From: Junio C Hamano @ 2009-11-16 0:11 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LNX.2.00.0911151711170.14365@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> My initial cleanup for "Allow helper to map private ref names into normal
> names" was wrong (and the original was supposed to be RFC, and isn't
> signed-off); I identified the bug he reported in it, but haven't gotten
> positive test results from him yet, and the series obviously needs a
> proper version rolled in before it goes into next.
Thanks; will wait for a re-roll.
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2009, #03; Sun, 15)
From: James Pickens @ 2009-11-16 0:13 UTC (permalink / raw)
To: Peter Weseloh; +Cc: git
In-Reply-To: <loom.20091116T003914-635@post.gmane.org>
On Sun, Nov 15, 2009 at 4:40 PM, Peter Weseloh <Peter.Weseloh@gmail.com> wrote:
> I'm currently trying to convince my managment to switch from CVS to git.
> What causes some trouble is that we have quite some files (> 40k) in various
> (>300) CVS modules and splitting them into sub-repos seams somewhat difficult.
> git has no problem even with that many files but commands that stat the
> working copy (e.g. 'git status') take quite long on our filers
> (it's either a problem with the filers or with nfs or both, I don't know yet).
> Having the ability to do sparse checkouts only of the repo sounds like a
> way out.
Make sure you have set core.preloadindex to true. It makes life on NFS much
more tolerable.
James
^ permalink raw reply
* Re: .gitignore polution
From: Sverre Rabbelier @ 2009-11-16 0:22 UTC (permalink / raw)
To: Jeff King; +Cc: Git List
In-Reply-To: <20091115094352.GA21477@coredump.intra.peff.net>
Heya,
On Sun, Nov 15, 2009 at 10:43, Jeff King <peff@peff.net> wrote:
> The other option is to mark them for ignore outside of the
> branch-specific ignore:
>
> git ls-files -o --exclude-standard >>.git/info/exclude
Ah, that would work, thanks! :)
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2009, #03; Sun, 15)
From: Junio C Hamano @ 2009-11-16 0:26 UTC (permalink / raw)
To: Peter Weseloh; +Cc: git
In-Reply-To: <loom.20091116T003914-635@post.gmane.org>
Peter Weseloh <Peter.Weseloh@gmail.com> writes:
> Does that mean this feature will not make it into 'master' any time soon?
It does not mean anything about this _feature_, but it does mean this
particular _implementation_ is not likely to.
> Having the ability to do sparse checkouts only of the repo sounds like a
> way out.
There is a big difference between (a) a feature is desirable and (b) a
particular implementation of that feature does things right.
The change in the topic is very intrusive and I am hesitant to merge it
into even 'next'. Before considering inclusion to 'next', it does not
matter that much if a topic realizes the feature as it advertises, but it
does matter a lot if it breaks things for people who do not need the
feature. While 'pu' has carried this topic for quite a long time, we
haven't heard much success report from folks like you with the need for
the feature if this implementation worked well for them without breaking
things.
I am not convinced that it won't regress fundamental things for the common
codepaths when "sparse" is not used, and the latest update patch posted to
the list (I do not think I picked it up) seemed very likely to regress
things for the normal codepath.
> Another question: What's the timeline for 1.7.0? I couldn't find anything
> about it neither here nor in the wiki.
When it is ready. But it is likely that there won't be 1.6.7.
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2009, #03; Sun, 15)
From: Daniel Barkalow @ 2009-11-16 0:30 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, git
In-Reply-To: <fabb9a1e0911151532w1ad81a0bi8b13ca59d13cdd79@mail.gmail.com>
On Mon, 16 Nov 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Sun, Nov 15, 2009 at 23:26, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > My initial cleanup for "Allow helper to map private ref names into normal
> > names" was wrong (and the original was supposed to be RFC, and isn't
> > signed-off); I identified the bug he reported in it, but haven't gotten
> > positive test results from him yet, and the series obviously needs a
> > proper version rolled in before it goes into next.
>
> Sorry, I tested, got primary positive results, then wanted to test
> something else and instead of:
> ~/code$ rm -rf test
>
> I did:
> ~/code$ rm -rf git
>
> I hate it when my fingers don't listen. Anyway, I ^C-ed and managed to
> save my worktree, but most of my git/.git was gone already. I'll get
> back to you tomorrow with more results since the time I was going to
> spend on running it through valgrind was wasted trying to recover my
> git repo :P.
Ouch. I remember one day when I got some old code all cleaned up for my
initial commit, and was about to type "cvs import", but decided I should
get rid of the editor cruft first. So I typed "rm *~", but missed one key.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 1/2] git-svn: add (failing) test for SVN 1.5+ merge with intervening commit
From: Toby Allsopp @ 2009-11-16 1:15 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Sam Vilain
In-Reply-To: <20091114214031.GA3732@dcvr.yhbt.net>
[Dropped Junio from CC]
On Sun, Nov 15 2009, Eric Wong wrote:
> Hi Toby,
>
> Thanks for this series, acked and squashed into a single commit to avoid
> unnecessary bisection failures at git://git.bogomips.org/git-svn
Great, thanks. I have no objection to being squashed, but I'm not sure
what you mean by bisection failures. Does a test_expect_failure cause
problems for bisection? It appears to be fairly common to introduce a
failing test case and later fix it, e.g. ce06461 then 751c597. I'd just
like to understand any potential problems with what I did.
Cheers,
Toby.
^ permalink raw reply
* Re: [PATCH 1/2] git-svn: add (failing) test for SVN 1.5+ merge with intervening commit
From: Eric Wong @ 2009-11-16 1:30 UTC (permalink / raw)
To: Toby Allsopp; +Cc: git, Sam Vilain
In-Reply-To: <87k4xrb785.fsf@navakl084.mitacad.com>
Toby Allsopp <Toby.Allsopp@navman.co.nz> wrote:
> [Dropped Junio from CC]
>
> On Sun, Nov 15 2009, Eric Wong wrote:
>
> > Hi Toby,
> >
> > Thanks for this series, acked and squashed into a single commit to avoid
> > unnecessary bisection failures at git://git.bogomips.org/git-svn
>
> Great, thanks. I have no objection to being squashed, but I'm not sure
> what you mean by bisection failures. Does a test_expect_failure cause
> problems for bisection? It appears to be fairly common to introduce a
> failing test case and later fix it, e.g. ce06461 then 751c597. I'd just
> like to understand any potential problems with what I did.
Oops. I didn't even notice you had test_expect_failure there :x
I'll just leave it as is incase somebody has already pulled from me
(other, unrelated patches coming in a few)
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 1/2] http-backend: Fix access beyond end of string.
From: Shawn O. Pearce @ 2009-11-16 1:36 UTC (permalink / raw)
To: Tarmigan Casebolt, Junio C Hamano; +Cc: git
In-Reply-To: <1258233058-2348-1-git-send-email-tarmigan+git@gmail.com>
Tarmigan Casebolt <tarmigan+git@gmail.com> wrote:
> diff --git a/http-backend.c b/http-backend.c
> index f8ea9d7..ab9433d 100644
> --- a/http-backend.c
> +++ b/http-backend.c
> @@ -634,7 +634,7 @@ int main(int argc, char **argv)
> cmd = c;
> cmd_arg = xmalloc(n);
> strncpy(cmd_arg, dir + out[0].rm_so + 1, n);
> - cmd_arg[n] = '\0';
> + cmd_arg[n-1] = '\0';
> dir[out[0].rm_so] = 0;
> break;
Shouldn't this instead be:
diff --git a/http-backend.c b/http-backend.c
index 9021266..16ec635 100644
--- a/http-backend.c
+++ b/http-backend.c
@@ -626,7 +626,7 @@ int main(int argc, char **argv)
}
cmd = c;
- cmd_arg = xmalloc(n);
+ cmd_arg = xmalloc(n + 1);
strncpy(cmd_arg, dir + out[0].rm_so + 1, n);
cmd_arg[n] = '\0';
dir[out[0].rm_so] = 0;
The cmd_arg string was simply allocated too small. Your fix is
terminating the string one character too short which would cause
get_loose_object and get_pack_file to break.
--
Shawn.
^ permalink raw reply related
* Re: [PATCH 2/2] http-backend: Let gcc check the format of more printf-type functions.
From: Shawn O. Pearce @ 2009-11-16 1:39 UTC (permalink / raw)
To: Tarmigan Casebolt; +Cc: git
In-Reply-To: <1258233058-2348-2-git-send-email-tarmigan+git@gmail.com>
Tarmigan Casebolt <tarmigan+git@gmail.com> wrote:
> We already have these checks in many printf-type functions that have
> prototypes which are in header files. Add these same checks to
> static functions in http-backend.c
>
> Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
> ---
>
> Shawn, please consider this patch in addition to the one that you posted
> that actually fixes the bug. With this patch, gcc will warn about that bug.
Yup, it would have caught it, thanks.
Acked-by: Shawn O. Pearce <spearce@spearce.org>
--
Shawn.
^ permalink raw reply
* Re: [PATCH v2] Speed up bash completion loading
From: Shawn O. Pearce @ 2009-11-16 1:55 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Stephen Boyd, Kirill Smelkov, Sverre Rabbelier,
git
In-Reply-To: <20091115102912.GA4100@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> wrote:
> Since git is not used in each and every interactive xterm, it
> seems best to load completion support with cold caches and then
> load each needed thing lazily. This has most of the speed
> advantage of pre-generating everything at build time, without the
> complication of figuring out at build time what commands will be
> available at run time.
>
> Suggested-by: Kirill Smelkov <kirr@mns.spb.ru>
> Cc: Shawn O. Pearce <spearce@spearce.org>
Acked-By: Shawn O. Pearce <spearce@spearce.org>
--
Shawn.
^ permalink raw reply
* [PATCH] gitk: Use git-difftool for external diffs
From: David Aguilar @ 2009-11-16 3:12 UTC (permalink / raw)
To: paulus; +Cc: peff, sam, git, David Aguilar
This teaches gitk about git-difftool. A benefit of this change is
that gitk's external diff now works with read-only repositories.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
The diffstat alone makes me happy.
gitk | 83 ++++--------------------------------------------------------------
1 files changed, 5 insertions(+), 78 deletions(-)
diff --git a/gitk b/gitk
index db5ec54..881ef95 100755
--- a/gitk
+++ b/gitk
@@ -2520,7 +2520,7 @@ proc savestuff {w} {
global viewname viewfiles viewargs viewargscmd viewperm nextviewnum
global cmitmode wrapcomment datetimeformat limitdiffs
global colors uicolor bgcolor fgcolor diffcolors diffcontext selectbgcolor
- global autoselect extdifftool perfile_attrs markbgcolor
+ global autoselect perfile_attrs markbgcolor
global hideremotes
if {$stuffsaved} return
@@ -2554,7 +2554,6 @@ proc savestuff {w} {
puts $f [list set markbgcolor $markbgcolor]
puts $f [list set diffcontext $diffcontext]
puts $f [list set selectbgcolor $selectbgcolor]
- puts $f [list set extdifftool $extdifftool]
puts $f [list set perfile_attrs $perfile_attrs]
puts $f "set geometry(main) [wm geometry .]"
@@ -3204,31 +3203,10 @@ proc save_file_from_commit {filename output what} {
return $output
}
-proc external_diff_get_one_file {diffid filename diffdir} {
- global nullid nullid2 nullfile
- global gitdir
-
- if {$diffid == $nullid} {
- set difffile [file join [file dirname $gitdir] $filename]
- if {[file exists $difffile]} {
- return $difffile
- }
- return $nullfile
- }
- if {$diffid == $nullid2} {
- set difffile [file join $diffdir "\[index\] [file tail $filename]"]
- return [save_file_from_commit :$filename $difffile index]
- }
- set difffile [file join $diffdir "\[$diffid\] [file tail $filename]"]
- return [save_file_from_commit $diffid:$filename $difffile \
- "revision $diffid"]
-}
-
proc external_diff {} {
global nullid nullid2
global flist_menu_file
global diffids
- global extdifftool
if {[llength $diffids] == 1} {
# no reference commit given
@@ -3249,23 +3227,9 @@ proc external_diff {} {
set diffidto [lindex $diffids 1]
}
- # make sure that several diffs wont collide
- set diffdir [gitknewtmpdir]
- if {$diffdir eq {}} return
-
- # gather files to diff
- set difffromfile [external_diff_get_one_file $diffidfrom $flist_menu_file $diffdir]
- set difftofile [external_diff_get_one_file $diffidto $flist_menu_file $diffdir]
-
- if {$difffromfile ne {} && $difftofile ne {}} {
- set cmd [list [shellsplit $extdifftool] $difffromfile $difftofile]
- if {[catch {set fl [open |$cmd r]} err]} {
- file delete -force $diffdir
- error_popup "$extdifftool: [mc "command failed:"] $err"
- } else {
- fconfigure $fl -blocking 0
- filerun $fl [list delete_at_eof $fl $diffdir]
- }
+ set cmd {git difftool --no-prompt $diffidfrom $diffidto -- $flist_menu_file}
+ if {[catch {eval exec $cmd &} err]} {
+ error_popup "[mc "git difftool: command failed:"] $err"
}
}
@@ -3557,19 +3521,6 @@ proc read_line_source {fd inst} {
return 0
}
-# delete $dir when we see eof on $f (presumably because the child has exited)
-proc delete_at_eof {f dir} {
- while {[gets $f line] >= 0} {}
- if {[eof $f]} {
- if {[catch {close $f} err]} {
- error_popup "[mc "External diff viewer failed:"] $err"
- }
- file delete -force $dir
- return 0
- }
- return 1
-}
-
# Functions for adding and removing shell-type quoting
proc shellquote {str} {
@@ -10446,7 +10397,7 @@ proc doprefs {} {
global maxwidth maxgraphpct
global oldprefs prefstop showneartags showlocalchanges
global uicolor bgcolor fgcolor ctext diffcolors selectbgcolor markbgcolor
- global tabstop limitdiffs autoselect extdifftool perfile_attrs
+ global tabstop limitdiffs autoselect perfile_attrs
global hideremotes
set top .gitkprefs
@@ -10498,15 +10449,6 @@ proc doprefs {} {
-font optionfont -variable perfile_attrs
grid x $top.lattr -sticky w
- entry $top.extdifft -textvariable extdifftool
- frame $top.extdifff
- label $top.extdifff.l -text [mc "External diff tool" ] -font optionfont \
- -padx 10
- button $top.extdifff.b -text [mc "Choose..."] -font optionfont \
- -command choose_extdiff
- pack $top.extdifff.l $top.extdifff.b -side left
- grid x $top.extdifff $top.extdifft -sticky w
-
label $top.cdisp -text [mc "Colors: press to choose"]
grid $top.cdisp - -sticky w -pady 10
label $top.ui -padx 40 -relief sunk -background $uicolor
@@ -10566,15 +10508,6 @@ proc doprefs {} {
bind $top <Visibility> "focus $top.buts.ok"
}
-proc choose_extdiff {} {
- global extdifftool
-
- set prog [tk_getOpenFile -title [mc "External diff tool"] -multiple false]
- if {$prog ne {}} {
- set extdifftool $prog
- }
-}
-
proc choosecolor {v vi w x cmd} {
global $v
@@ -11100,12 +11033,6 @@ set datetimeformat "%Y-%m-%d %H:%M:%S"
set autoselect 1
set perfile_attrs 0
-if {[tk windowingsystem] eq "aqua"} {
- set extdifftool "opendiff"
-} else {
- set extdifftool "meld"
-}
-
set colors {green red blue magenta darkgrey brown orange}
set uicolor grey85
set bgcolor white
--
1.6.5.2.180.gc5b3e
^ permalink raw reply related
* Re: Preserving empty directories when doing a git-svn clone/rebase
From: Eric Wong @ 2009-11-16 3:32 UTC (permalink / raw)
To: Steven J. Murdoch; +Cc: git
In-Reply-To: <20091115020605.GE15966@cl.cam.ac.uk>
"Steven J. Murdoch" <git+Steven.Murdoch@cl.cam.ac.uk> wrote:
> When git-svn clones a Subversion repository, any empty directories
> appear to be silently dropped (tested using git version 1.6.5.2 on Mac
> OS X Snow Leopard). This causes problems for using git with software
> projects which depend on Subversion's ability to track empty
> directories. I was recently caught out by this, and it was difficult
> to debug what had gone wrong.
>
> Would it be possible to change git-svn to handle this case? Since git
> doesn't have the ability to track empty directories, probably the
> simplest thing to do would be to automatically add a file (e.g.
> .gitignore) to any empty directories. In theory this could cause
> problems, but I would think the chances of this are far lower than
> with the current behaviour.
Hi Steven,
The problem is that some git-svn using folks have started using
.gitignore to create empty directories on their own. Dealing with
conflicts like this is very problematic because we have to know
if the .gitignore file is supposed to be committed up to SVN or
not (it can be quite expensive to check).
Attempting to deal with mismatching the information stored in the git
index and SVN nearly made my head explode when I tried to implement
svn:externals support via git submodules. Fortunately I stopped in
time, but the mental scars still remain.
> I think this feature would help projects in which some contributors
> are transitioning to git. It would especially be useful to novice
> users of git, who are not aware of the potential problems with having
> empty directories.
>
> I see there was a discussion in 2006:
> http://kerneltrap.org/mailarchive/git/2006/11/29/231586
>
> However, since then I haven't seen any updates. The rationale behind
> the original request still seems applicable today:
>
> "I think there are many potential git users out there who are
> currently svn users. And git-svn is a really nice way to get started,
> but this sort of stumbling block could really turn people off. For
> example, it made me look pretty dumb when I carelessly complained to
> my colleague about his code not working and then it turns out to be
> because my super-advanced scm tool "messed things up"."
> (git-svn and empty directories in svn (was: [PATCH 1.2/2 (fixed)]
> git-svn: fix output reporting from the delta fetcher))
Shortly afterwards, git svn started logging unhandled information into
unhandled.log files. I hoped that somebody would write a parser for
those log files to be able to recreate useful information from them.
Since I'm lazy, forgetful and absent-minded, I never got around to it
until now.
Let me know how it works and if the "git svn mkdirs" command name makes
sense. Thanks for reminding me :)
>From 023675791988373beab921ad3ada115b2c224edf Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Sun, 15 Nov 2009 18:57:16 -0800
Subject: [PATCH] git svn: attempt to create empty dirs on clone+rebase
Attempt to parse unhandled.log files for empty_dir statements
and make a best effort attempt to recreate empty directories
on fresh clones and rebase.
This cannot affect "normal" git commands like "checkout" or
"reset", so users switching between branches in a single working
directory should use the new "git svn mkdirs" command after
switching branches.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Documentation/git-svn.txt | 7 +++
git-svn.perl | 45 ++++++++++++++++
t/t9115-git-svn-dcommit-funky-renames.sh | 4 +-
t/t9146-git-svn-empty-dirs.sh | 85 ++++++++++++++++++++++++++++++
4 files changed, 139 insertions(+), 2 deletions(-)
create mode 100755 t/t9146-git-svn-empty-dirs.sh
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 1812890..db00ed4 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -320,6 +320,13 @@ Any other arguments are passed directly to 'git log'
directories. The output is suitable for appending to
the $GIT_DIR/info/exclude file.
+'mkdirs'::
+ Attempts to recreate empty directories that core git cannot track
+ based on information in $GIT_DIR/svn/<refname>/unhandled.log files.
+ Empty directories are automatically recreated when using
+ "git svn clone" and "git svn rebase", so "mkdirs" is intended
+ for use after commands like "git checkout" or "git reset".
+
'commit-diff'::
Commits the diff of two tree-ish arguments from the
command-line. This command does not rely on being inside an `git svn
diff --git a/git-svn.perl b/git-svn.perl
index ea922ac..ab0a8dd 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -168,6 +168,9 @@ my %cmd = (
'Create a .gitignore per svn:ignore',
{ 'revision|r=i' => \$_revision
} ],
+ 'mkdirs' => [ \&cmd_mkdirs ,
+ "recreate empty directories after a checkout",
+ { 'revision|r=i' => \$_revision } ],
'propget' => [ \&cmd_propget,
'Print the value of a property on a file or directory',
{ 'revision|r=i' => \$_revision } ],
@@ -769,6 +772,7 @@ sub cmd_rebase {
$_fetch_all ? $gs->fetch_all : $gs->fetch;
}
command_noisy(rebase_cmd(), $gs->refname);
+ $gs->mkemptydirs;
}
sub cmd_show_ignore {
@@ -830,6 +834,12 @@ sub cmd_create_ignore {
});
}
+sub cmd_mkdirs {
+ my ($url, $rev, $uuid, $gs) = working_head_info('HEAD');
+ $gs ||= Git::SVN->new;
+ $gs->mkemptydirs($_revision);
+}
+
sub canonicalize_path {
my ($path) = @_;
my $dot_slash_added = 0;
@@ -1196,6 +1206,7 @@ sub post_fetch_checkout {
command_noisy(qw/read-tree -m -u -v HEAD HEAD/);
print STDERR "Checked out HEAD:\n ",
$gs->full_url, " r", $gs->last_rev, "\n";
+ $gs->mkemptydirs($gs->last_rev);
}
sub complete_svn_url {
@@ -2724,6 +2735,34 @@ sub do_fetch {
$self->make_log_entry($rev, \@parents, $ed);
}
+sub mkemptydirs {
+ my ($self, $r) = @_;
+ my %empty_dirs = ();
+
+ open my $fh, '<', "$self->{dir}/unhandled.log" or return;
+ binmode $fh or croak "binmode: $!";
+ while (<$fh>) {
+ if (defined $r && /^r(\d+)$/) {
+ last if $1 > $r;
+ } elsif (/^ \+empty_dir: (.+)$/) {
+ $empty_dirs{$1} = 1;
+ } elsif (/^ \-empty_dir: (.+)$/) {
+ delete $empty_dirs{$1};
+ }
+ }
+ close $fh;
+ foreach my $d (sort keys %empty_dirs) {
+ $d = uri_decode($d);
+ next if -d $d;
+ if (-e _) {
+ warn "$d exists but is not a directory\n";
+ } else {
+ print "creating empty directory: $d\n";
+ mkpath([$d]);
+ }
+ }
+}
+
sub get_untracked {
my ($self, $ed) = @_;
my @out;
@@ -3556,6 +3595,12 @@ sub uri_encode {
$f
}
+sub uri_decode {
+ my ($f) = @_;
+ $f =~ s#%([0-9a-fA-F]{2})#chr(hex($1))#eg;
+ $f
+}
+
sub remove_username {
$_[0] =~ s{^([^:]*://)[^@]+@}{$1};
}
diff --git a/t/t9115-git-svn-dcommit-funky-renames.sh b/t/t9115-git-svn-dcommit-funky-renames.sh
index 9be7aef..767799e 100755
--- a/t/t9115-git-svn-dcommit-funky-renames.sh
+++ b/t/t9115-git-svn-dcommit-funky-renames.sh
@@ -19,7 +19,7 @@ test_expect_success 'init and fetch repository' '
'
test_expect_success 'create file in existing ugly and empty dir' '
- mkdir "#{bad_directory_name}" &&
+ mkdir -p "#{bad_directory_name}" &&
echo hi > "#{bad_directory_name}/ foo" &&
git update-index --add "#{bad_directory_name}/ foo" &&
git commit -m "new file in ugly parent" &&
@@ -37,7 +37,7 @@ test_expect_success 'rename pretty file' '
git update-index --add pretty &&
git commit -m "pretty :x" &&
git svn dcommit &&
- mkdir regular_dir_name &&
+ mkdir -p regular_dir_name &&
git mv pretty regular_dir_name/pretty &&
git commit -m "moved pretty file" &&
git svn dcommit
diff --git a/t/t9146-git-svn-empty-dirs.sh b/t/t9146-git-svn-empty-dirs.sh
new file mode 100755
index 0000000..5948544
--- /dev/null
+++ b/t/t9146-git-svn-empty-dirs.sh
@@ -0,0 +1,85 @@
+#!/bin/sh
+#
+# Copyright (c) 2009 Eric Wong
+
+test_description='git svn creates empty directories'
+. ./lib-git-svn.sh
+
+test_expect_success 'initialize repo' '
+ for i in a b c d d/e d/e/f "weird file name"
+ do
+ svn_cmd mkdir -m "mkdir $i" "$svnrepo"/"$i"
+ done
+'
+
+test_expect_success 'clone' 'git svn clone "$svnrepo" cloned'
+
+test_expect_success 'empty directories exist' '
+ (
+ cd cloned &&
+ for i in a b c d d/e d/e/f "weird file name"
+ do
+ if ! test -d "$i"
+ then
+ echo >&2 "$i does not exist"
+ exit 1
+ fi
+ done
+ )
+'
+
+test_expect_success 'more emptiness' '
+ svn_cmd mkdir -m "bang bang" "$svnrepo"/"! !"
+'
+
+test_expect_success 'git svn rebase creates empty directory' '
+ ( cd cloned && git svn rebase )
+ test -d cloned/"! !"
+'
+
+test_expect_success 'git svn mkdirs recreates empty directories' '
+ (
+ cd cloned &&
+ rm -r * &&
+ git svn mkdirs &&
+ for i in a b c d d/e d/e/f "weird file name" "! !"
+ do
+ if ! test -d "$i"
+ then
+ echo >&2 "$i does not exist"
+ exit 1
+ fi
+ done
+ )
+'
+
+test_expect_success 'git svn mkdirs -r works' '
+ (
+ cd cloned &&
+ rm -r * &&
+ git svn mkdirs -r7 &&
+ for i in a b c d d/e d/e/f "weird file name"
+ do
+ if ! test -d "$i"
+ then
+ echo >&2 "$i does not exist"
+ exit 1
+ fi
+ done
+
+ if test -d "! !"
+ then
+ echo >&2 "$i should not exist"
+ exit 1
+ fi
+
+ git svn mkdirs -r8 &&
+ if ! test -d "! !"
+ then
+ echo >&2 "$i not exist"
+ exit 1
+ fi
+ )
+'
+
+test_done
--
Eric Wong
^ permalink raw reply related
* Re: [PATCH 1/2] http-backend: Fix access beyond end of string.
From: Jeff King @ 2009-11-16 4:55 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Tarmigan Casebolt, Junio C Hamano, git
In-Reply-To: <20091116013654.GX11919@spearce.org>
On Sun, Nov 15, 2009 at 05:36:54PM -0800, Shawn O. Pearce wrote:
> Tarmigan Casebolt <tarmigan+git@gmail.com> wrote:
> > diff --git a/http-backend.c b/http-backend.c
> > index f8ea9d7..ab9433d 100644
> > --- a/http-backend.c
> > +++ b/http-backend.c
> > @@ -634,7 +634,7 @@ int main(int argc, char **argv)
> > cmd = c;
> > cmd_arg = xmalloc(n);
> > strncpy(cmd_arg, dir + out[0].rm_so + 1, n);
> > - cmd_arg[n] = '\0';
> > + cmd_arg[n-1] = '\0';
> > dir[out[0].rm_so] = 0;
> > break;
>
> Shouldn't this instead be:
>
> diff --git a/http-backend.c b/http-backend.c
> index 9021266..16ec635 100644
> --- a/http-backend.c
> +++ b/http-backend.c
> @@ -626,7 +626,7 @@ int main(int argc, char **argv)
> }
>
> cmd = c;
> - cmd_arg = xmalloc(n);
> + cmd_arg = xmalloc(n + 1);
> strncpy(cmd_arg, dir + out[0].rm_so + 1, n);
> cmd_arg[n] = '\0';
> dir[out[0].rm_so] = 0;
>
> The cmd_arg string was simply allocated too small. Your fix is
> terminating the string one character too short which would cause
> get_loose_object and get_pack_file to break.
Actually, from my reading, I think his fix is right, because you trim
the first character during the strncpy (using "out[0].rm_so + 1"). But
it's not clear when you create 'n' that you are dropping that character.
IOW, you are doing:
/* string + '\0' - '/' */
size_t n = out[0].rm_eo - (out[0].rm_so + 1) + 1;
which ends up the same as your n, but means that the NUL goes at
cmd_arg[n-1]. But I didn't actually run it, so if his fix is breaking
things, then both Tarmigan and I are counting wrong. ;)
-Peff
^ permalink raw reply
* Re: [RFC] format-patch: Ensure that author and commit time are not lost
From: Jeff King @ 2009-11-16 5:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Björn Gustavsson, git
In-Reply-To: <7vzl6nfqkx.fsf@alter.siamese.dyndns.org>
On Sun, Nov 15, 2009 at 01:03:42PM -0800, Junio C Hamano wrote:
> I would expect the right solution would be to give send-email an ability
> to either (1) use "Sender:" to record the operator of the MUA while
> keeping "From: " taken from the payload, or (2) duplicate "From: " as an
> in-body header when it sends out.
I agree that send-email is the "right" place for this functionality in
the git toolchain. And indeed, it already does (2):
$ sed -ne '/$author ne $sender/,+1p' git-send-email.perl
if (defined $author and $author ne $sender) {
$message = "From: $author\n\n$message";
That being said, like you, I usually pull the patches directly from
format-patch into my MUA, and I fix up the headers manually. I suspect
there are many others who do the same thing. And each of us has to
either handle this case manually, or write our own munging code
ourselves for our particular setup.
So in that sense, even though format-patch is not the right place, it
may be useful for it to give tool support to people who do not use the
"format-patch to send-email" workflow. In other words, I would be
happy if my short glue shell-script became:
git format-patch --stdout --sender-is-me "$@" >mbox &&
mutt -f mbox
and this just handled the case properly, without me having to parse the
From header of each message and munge the messages in my script.
The arguments against it are:
1. It is polluting format-patch with MUA cruft.
2. --sender-is-me (besides being a terrible name) may not be
expressive enough. You might want --sender=... depending on the
setup of the calling script.
Honestly, though, I send few enough patches made by other people that I
have never found it to be a huge burden. This would be a minor
convenience to have.
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] http-backend: Fix access beyond end of string.
From: Junio C Hamano @ 2009-11-16 6:12 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, Tarmigan Casebolt, Junio C Hamano, git
In-Reply-To: <20091116045532.GC14664@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Nov 15, 2009 at 05:36:54PM -0800, Shawn O. Pearce wrote:
> ...
>> Shouldn't this instead be:
>>
>> diff --git a/http-backend.c b/http-backend.c
>> index 9021266..16ec635 100644
>> --- a/http-backend.c
>> +++ b/http-backend.c
>> @@ -626,7 +626,7 @@ int main(int argc, char **argv)
>> }
>>
>> cmd = c;
>> - cmd_arg = xmalloc(n);
>> + cmd_arg = xmalloc(n + 1);
>> strncpy(cmd_arg, dir + out[0].rm_so + 1, n);
>> cmd_arg[n] = '\0';
>> dir[out[0].rm_so] = 0;
>>
>> The cmd_arg string was simply allocated too small. Your fix is
>> terminating the string one character too short which would cause
>> get_loose_object and get_pack_file to break.
>
> Actually, from my reading, I think his fix is right, because you trim
> the first character during the strncpy (using "out[0].rm_so + 1").
Your regexps all start with leading "/", and rm_so+1 points at the
character after the slash; the intention being that you would copy
the rest of the matched sequence without the leading "/".
So allocating n = rm_eo - rm_so is Ok. It counts the space for
terminating NUL. But copying "up to n bytes" using strncpy(), only to NUL
terminate immediately later, is dubious. You would want to copy only n-1
bytes. I.e.
n = out[0].rm_eo - out[0].rm_so; /* allocation */
... validate and fail invalid method ...
cmd_arg = xmalloc(n);
memcpy(cmd_arg, dir + out[0].rm_so + 1, n-1);
cmd_arg[n-1] = '\0';
^ permalink raw reply
* Re: git am and CRLF files
From: Stefan Naewe @ 2009-11-16 7:33 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <4AFD2A8F.7000806@atlas-elektronik.com>
On 11/13/2009 10:44 AM, Stefan Naewe wrote:
> Hi there.
> I have:
>
> $ git version
> git version 1.6.5.1.1367.gcd48
>
> $ git config --get core.autocrlf
> false
>
> A repository with some UNIX (LF) and some Windows (CRLF) files.
> (and no: I will not change the files. My editors handle CRLF and LF correctly)
>
> My problem:
>
> 'git am' can't handle changes in CRLF files because the patch
> gets converted (by git mailsplit) to contain only LF.
>
> Which is wrong IMHO.
>
> git-am on my msysgit version looks like this (lines: 214++)
>
> <---------->
> split_patches () {
> case "$patch_format" in
> mbox)
> case "$rebasing" in
> '')
> keep_cr= ;;
> ?*)
> keep_cr=--keep-cr ;;
> esac
> git mailsplit -d"$prec" -o"$dotest" -b $keep_cr -- "$@" > "$dotest/last" ||
> clean_abort
> ;;
> <---------->
>
> The '--keep-cr' flags is passed to git mailsplit when git am is in 'rebasing' mode.
> By looking through git-am I found that I can pass "--rebasing" to git am to get my
> patch applied correctly.
> But why is git am behaving that way ?
>
> Puzzled,
>
> Stefan
Does anyone have any comment on this ?
Regards,
Stefan
--
----------------------------------------------------------------
/dev/random says: Microsoft Windows... a virus with mouse support.
^ permalink raw reply
* how to make gitk to use specified history information
From: Liu Yubao @ 2009-11-16 7:51 UTC (permalink / raw)
To: git
Hi,
I want to obtain an outline of history information, for example:
a - b - c - d - h -i -j
\ /
e- f - g
I simplify the graph like this:
a - c - d - j
\ /
g
That's to say, I skip all commits that
* have only one parent, and
* have only one child, and
* its child has only one parent
I checked `git help rev-list` but didn't find this feature, so I
write a little script[1] to parse output of `git rev-list --parents
--full-history --sparse --all` and get the simplified history:
j d
d c g
c a
g a
Now how can I make gitk to show this simpilified history? I have tried
GraphViz but the history information is still so large that GraphViz
crashes.
[1] http://jff.googlecode.com/svn/trunk/utils/git-branch-graph.pl
Best regards,
Liu Yubao
^ permalink raw reply
* Re: how to make gitk to use specified history information
From: Eric Raible @ 2009-11-16 8:08 UTC (permalink / raw)
To: git
In-Reply-To: <4B01049A.5090402@gmail.com>
Liu Yubao <yubao.liu <at> gmail.com> writes:
> I want to obtain an outline of history information, for example:
>
> a - b - c - d - h -i -j
> \ /
> e- f - g
>
> I simplify the graph like this:
>
> a - c - d - j
> \ /
> g
"gitk --simplify-by-decoration"?
- Eric
^ permalink raw reply
* Re: [PATCH] Re: Clarify documentation on the "ours" merge strategy.
From: Peter Krefting @ 2009-11-16 8:20 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nanako Shiraishi, Thomas Rast, Nicolas Sebrecht, Baz,
Git Mailing List, Johannes.Schindelin, B.Steinbrink
In-Reply-To: <7vk4xsqhkv.fsf@alter.siamese.dyndns.org>
Junio C Hamano:
> Even though I still think -Xours/-Xtheirs are nonsense options in the
> context of source code management, I suspect that they might be exactly
> what Peter needs in this situation.
Yes, it sounds like it would. That is not something I would use for source
code management, but it would fit this, and some other use-cases I have,
quite nicely.
I tend to use Git not only for source code management, but also for document
synchronisation across machines which may, or may not, be connected to a
network at any given time. Git is very nice for that sort of work.
> ; otherwise Peter's web site is seriously broken from the security point
> of view and no SCM can fix that),
Indeed. If it that was the case, I deserve whatever problems I get :-)
--
\\// Peter - http://www.softwolves.pp.se/
^ 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