* Re: [RFC PATCH 0/6] Second round of committag series
From: Jakub Narebski @ 2009-11-20 23:24 UTC (permalink / raw)
To: Marcel M. Cary; +Cc: git, Petr Baudis, Giuseppe Bilotta, Francis Galiegue
In-Reply-To: <1258525350-5528-1-git-send-email-marcel@oak.homeunix.org>
On Wed, 18 Nov 2009, Marcel M. Cary wrote:
> Thanks for the feedback. I've added four more patches to the end of
> the series and updated the first two. My replies are below.
>
> On Mon, 22 Jun 2009, Jakub Narebski wrote:
> > On Fri, 19 June 2009, Marcel M. Cary wrote:
Thanks for working on this. I'll try to reply soon.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] gitk: Use git-difftool for external diffs
From: Markus Heidelberg @ 2009-11-20 23:33 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Paul Mackerras, peff, sam, git
In-Reply-To: <20091120185522.GC56351@gmail.com>
David Aguilar, 2009-11-20:
> The argument in favor of difftool is one of user
> expectations. From a user's POV it ~seems~ desirable for
> gitk to honor difftool configurations.
In general I absolutely like the idea. There are however problems you
can encounter.
I use vimdiff for git-difftool and gvimdiff for gitk. When testing gitk
with your patch, I wondered where the editor is, because nothing popped
up. I then found vim on the terminal from where I started gitk. Even
worse: when started with "gitk &", the vim process runs somewhere in the
background and gitk freezes.
To overcome this problem maybe we need a second config variable like
diff.guitool.
Markus
^ permalink raw reply
* [PATCH v5] git remote: Separate usage strings for subcommands
From: Tim Henigan @ 2009-11-20 23:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nanako Shiraishi, jrnieder
When the usage string for a subcommand must be printed,
only print the information relevant to that command.
This commit also removes the complete options list from
the first line of the subcommand usage string. Instead,
individual options are documented in the detailed
description following the general usage line.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
---
This patch is based on:
http://article.gmane.org/gmane.comp.version-control.git/132953
After some misunderstanding on my part, this version of the patch
should be correct. The following snippet [1] explains the intent:
> Junio C Hamano wrote:
>> Tim Henigan <tim.henigan@gmail.com> writes:
>>
>> Using the 'add' subcommand as an example, the desired output is:
>>
>> Output of 'git remote -h':
>> "git remote [-v | --verbose]"
>> "git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>"
>> etc.
>>
>> Output of 'git remote add -h':
>> "git remote add [<options>...] <name> <url>"
>> followed by the detailed description given by 'parse_options()'.
>>
>> Text in 'man git-remote':
>> "git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>"
>> with the options explained in detail later in the file.
>>
>> Thanks for your patience,
>
> I think the above looks good;
[1]: http://thread.gmane.org/gmane.comp.version-control.git/133209/focus=133243
Documentation/git-remote.txt | 7 ++--
builtin-remote.c | 66 ++++++++++++++++++++++++++++++-----------
2 files changed, 52 insertions(+), 21 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 82a3d29..c272c92 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -13,10 +13,10 @@ SYNOPSIS
'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 set-head' <name> (-a | -d | <branch>)
+'git remote' [-v | --verbose] 'show' [-n] <name>
'git remote prune' [-n | --dry-run] <name>
-'git remote update' [-p | --prune] [group | remote]...
+'git remote' [-v | --verbose] 'update' [-p | --prune] [group | remote]...
DESCRIPTION
-----------
@@ -30,6 +30,7 @@ OPTIONS
-v::
--verbose::
Be a little more verbose and show remote url after name.
+ NOTE: This must be placed between `remote` and `subcommand`.
COMMANDS
diff --git a/builtin-remote.c b/builtin-remote.c
index 0777dd7..4f4cba4 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -12,13 +12,48 @@ static const char * const builtin_remote_usage[] = {
"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 set-head <name> (-a | -d | <branch>)",
+ "git remote [-v | --verbose] show [-n] <name>",
"git remote prune [-n | --dry-run] <name>",
"git remote [-v | --verbose] update [-p | --prune] [group]",
NULL
};
+static const char * const builtin_remote_add_usage[] = {
+ "git remote add [<options>] <name> <url>",
+ NULL
+};
+
+static const char * const builtin_remote_rename_usage[] = {
+ "git remote rename <old> <new>",
+ NULL
+};
+
+static const char * const builtin_remote_rm_usage[] = {
+ "git remote rm <name>",
+ NULL
+};
+
+static const char * const builtin_remote_sethead_usage[] = {
+ "git remote set-head <name> (-a | -d | <branch>])",
+ NULL
+};
+
+static const char * const builtin_remote_show_usage[] = {
+ "git remote show [<options>] <name>",
+ NULL
+};
+
+static const char * const builtin_remote_prune_usage[] = {
+ "git remote prune [<options>] <name>",
+ NULL
+};
+
+static const char * const builtin_remote_update_usage[] = {
+ "git remote update [<options>] [<group> | <remote>]...",
+ NULL
+};
+
#define GET_REF_STATES (1<<0)
#define GET_HEAD_NAMES (1<<1)
#define GET_PUSH_REF_STATES (1<<2)
@@ -70,7 +105,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 +113,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 +574,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 +715,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)
@@ -976,7 +1010,6 @@ static int show(int argc, const char **argv)
{
int no_query = 0, result = 0, query_flag = 0;
struct option options[] = {
- OPT_GROUP("show specific options"),
OPT_BOOLEAN('n', NULL, &no_query, "do not query remotes"),
OPT_END()
};
@@ -984,7 +1017,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)
@@ -1081,14 +1114,13 @@ static int set_head(int argc, const char **argv)
char *head_name = NULL;
struct option options[] = {
- OPT_GROUP("set-head specific options"),
OPT_BOOLEAN('a', "auto", &opt_a,
"set refs/remotes/<name>/HEAD according to remote"),
OPT_BOOLEAN('d', "delete", &opt_d,
"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 +1146,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 +1170,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 +1259,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 +1364,7 @@ static int show_all(void)
int cmd_remote(int argc, const char **argv, const char *prefix)
{
struct option options[] = {
- OPT__VERBOSE(&verbose),
+ OPT_BOOLEAN('v', "verbose", &verbose, "be verbose; must be placed before a subcommand"),
OPT_END()
};
int result;
--
1.6.5.2.186.g3ccc3
^ permalink raw reply related
* Re: [PATCH 0/2] jn/gitweb-blame fixes
From: Jakub Narebski @ 2009-11-21 0:32 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git
In-Reply-To: <4B06157B.10203@gmail.com>
On Fri, 20 Nov 2009, Stephen Boyd wrote:
> Stephen Boyd wrote:
> > Jakub Narebski wrote:
> > >
> > > Thanks for working on this. Also it is nice to have incremental blame
> > > tested for another browser, beside Mozilla 1.17.2 and Konqueror 3.5.3
> >
> > For those following along, Opera-10.10 has been tested and works.
>
> Ok. I tried using the version of incremental blame that's in next
> (e206d62 gitweb: Colorize 'blame_incremental' view during processing,
> 2009-09-01) on IE8 with no success. The page loads and the file is shown
> with line numbers, but the progress is stuck at 0% (with the
> showing too).
>
> I then tried with my two patches applied on top of e206d62 on IE8 and
> still no success. The page loads and the file is show with the line
> numbers but still stuck at 0%, but the is gone at least.
>
> Do you have access to IE8 to confirm?
I have tested gitweb with both of your patches applied, serving gitweb
as CGI script using Apache 2.0.54 on Linux, and viewing from separate
computer on MS Windows XP, with the following results:
* For the following browsers blame_incremental view on gitweb/gitweb.perl
file produces correct output, but for progress info which instead of
( 1%) -> ( 29%) -> (100%) looks more like ( 1%) -> (29%) -> (100%)
+ Firefox 3.5.5 (rv:1.9.1.5 Gecko/20091102)
+ Opera 10.01
+ Google Chrome 3.0.195.33
* Testing it with IE8 (Internet Explorer 8.0.6001.18702) page loading stops
at 0%, at the very beginning on startBlame() function
IE8 shows that it finds the following errors:
* "firstChild is null or not an object"
line: 565, char:4
a_sha1.firstChild.data = commit.sha1.substr(0, 8);
It might be caused by the fact that firstChild for this case should be
text node containing of pure whitespace:
<a href=""> </a>
Perhaps IE8 simplifies it in "compatability view" mode
* "Unspecified error" (twice)
line: 777, char:2
if (xhr.readyState === 3 && xhr.status !== 200) {
return;
}
I don't know what might be the source of error here; I suspect that the
error position mentioned by IE8 is bogus.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [ANNOUNCE] tig-0.15
From: Jonas Fonseca @ 2009-11-21 2:29 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20091120162543.GB3919@debian.b2j>
On Fri, Nov 20, 2009 at 11:25, bill lam <cbill.lam@gmail.com> wrote:
> On Fri, 20 Nov 2009, Jonas Fonseca wrote:
>> install-release-doc-man:
>> for doc in $(MANDOC); do \
>> git checkout origin/release $$doc; \
>> done
>> $(MAKE) install-doc-man
>
> Thanks it works. Could you also commit this to git?
Done, but using git-checkout-index ...
--
Jonas Fonseca
^ permalink raw reply
* Re: [ANNOUNCE] tig-0.15
From: bill lam @ 2009-11-21 3:58 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <2c6b72b30911201829i52ffa022qff827bdf317ad447@mail.gmail.com>
On Fri, 20 Nov 2009, Jonas Fonseca wrote:
> On Fri, Nov 20, 2009 at 11:25, bill lam <cbill.lam@gmail.com> wrote:
> > On Fri, 20 Nov 2009, Jonas Fonseca wrote:
> >> install-release-doc-man:
> >> for doc in $(MANDOC); do \
> >> git checkout origin/release $$doc; \
> >> done
> >> $(MAKE) install-doc-man
> >
> > Thanks it works. Could you also commit this to git?
>
> Done, but using git-checkout-index ...
the line
git read-tree release
raised error perhaps I didn't checkout a branch for it, replacing it
with
git read-tree origin/relase
or
git read-tree remotes/origin/relase
seems working.
Another question, while it can open a file with editor in tree-view, I
cannot find in tigmanual how to directly save a file. Any idea?
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: [ANNOUNCE] tig-0.15
From: bill lam @ 2009-11-21 4:10 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <2c6b72b30911201829i52ffa022qff827bdf317ad447@mail.gmail.com>
Sorry, typo 's/relase/release/'
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: Default history simplification
From: Junio C Hamano @ 2009-11-21 6:37 UTC (permalink / raw)
To: Jan Krüger; +Cc: Tommy Wang, git
In-Reply-To: <20091120095537.1909f6b6@perceptron>
Jan Krüger <jk@jk.gs> writes:
> Tommy Wang <subscription@august8.net> wrote:
>> [...] I would love to simply use the rev-list built-in to
>> do my work for me; but I fear that I may have much too many path
>> limiters than the linux command-line can handle (which if I'm correct,
>> can only take so many arguments).
>
> On my system, "only so many arguments" means about two megabytes worth
> of command line.
Good point.
The command line limitation, even if it is very small, shouldn't be a
problem if Tommy is interested in recreating exactly what rev-list does.
If his tool that drives rev-list or log from the command line cannot work
because his request overflows the command line, the same request will
overflow the command line for rev-list or log, so they wouldn't work
either.
For a more serious answer, see the other thread ;-).
^ permalink raw reply
* Help creating script that mass-pulls Git(Hub) repos
From: Tony Maserati @ 2009-11-21 10:25 UTC (permalink / raw)
To: git
Hi,
I got a bunch of repos I've cloned off GitHub and I'm looking for the
best way to keep them all up to date.
I got a working zsh script, but it lacks some stuff. For instance I
think it'd be neat if it could output the difference between the
commit dates as oppose to those long hashes. And if it could initiate
the pull only when necessary. Other ideas are welcome.
Does anybody have any suggestions to how I might complete or otherwise
improve the below scripts? Thanks in advance.
Here's the working version:
abletony84$ cat pull_all.sh
#!/usr/bin/env zsh
for folder in $PWD/**/.git(:h); do
cd $folder
git pull
done
-
This script lacks a proper if clause, and shows hashes instead of dates:
abletony84$ cat pull_all2.sh
#!/usr/bin/env zsh
for folder in $PWD/**/.git(:h); do
cd $folder
if this repo needs an update; then # git ls-remote has been suggested
old=$(git rev-parse HEAD)
git pull >& /dev/null
new=$(git rev-parse HEAD)
echo "$folder: $old -> $new"
else
echo "$folder: nothing to do"
fi
done
-
A slightly different approach, even more incomplete than the previous:
abletony84$ cat pull_all3.sh
#!/usr/bin/env zsh
for folder in $PWD/**/.git(:h); do
cd $folder
if repo still exists at github; then
git fetch >& /dev/null
if a merge is needed; then
git merge >& /dev/null
echo "$folder: date_of_last_current_commit -> date_of_last_new_comit"
else
echo "$folder: nothing to do"
fi
fi
done
-
Thanks again!
Tony
^ permalink raw reply
* Re: [ANNOUNCE] codeBeamer MR - Easy ACL for Git
From: Sitaram Chamarty @ 2009-11-21 13:12 UTC (permalink / raw)
To: Petr Baudis; +Cc: Intland Software, git
In-Reply-To: <20091120074702.GW12890@machine.or.cz>
On Fri, Nov 20, 2009 at 1:17 PM, Petr Baudis <pasky@suse.cz> wrote:
> I brought Gitosis/Gitolite up because I got the impression that MR was
> marketed primarily as a Git ACL tool, the other things being sort of
> mirror; maybe my impession was wrong, but I still think the comparison
> in ACL capabilities is useful.
Sorry; didn't mean to imply you were wrong about that...
But the bulk of MR is probably the web based stuff, wiki, issues etc.,
which means gitolite is way on the other side of the spectrum, so it
felt like any comparision is moot, and used the code/binary sizes to
highlight that.
But you said just the ACL capabilities... set me thinking...
Intland: do you have a page that describes your role based ACL stuff a
little more? I have a feeling that, modulo it all being in one text
file, gitolite can probably come close :-)
>> You should stick to gitorious, github, and -- here's a new
>> one for you -- indefero.
>
> Hmm, I didn't even know about this one, thanks for the pointer. Looks
> like this suddenly is a very popular area. High competition is good!
Oh yeah, and indefero is actually looking pretty good -- I know some
guys at $DAYJOB looking at it very seriously.
> (BTW, if you don't care about wikis and issue tracking, but you do care
> about simplicity and light-weightness, you should best stick to Girocco!
> ;-)
:-) yes it is nice, but again, at $DAYJOB access control (even to
view projects) is a big deal. A very big deal, actually...!
^ permalink raw reply
* Re: [ANNOUNCE] tig-0.15
From: Jonas Fonseca @ 2009-11-21 13:59 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20091121035858.GC3919@debian.b2j>
On Fri, Nov 20, 2009 at 22:58, bill lam <cbill.lam@gmail.com> wrote:
> On Fri, 20 Nov 2009, Jonas Fonseca wrote:
>> On Fri, Nov 20, 2009 at 11:25, bill lam <cbill.lam@gmail.com> wrote:
>> > On Fri, 20 Nov 2009, Jonas Fonseca wrote:
>> >> install-release-doc-man:
>> >> for doc in $(MANDOC); do \
>> >> git checkout origin/release $$doc; \
>> >> done
>> >> $(MAKE) install-doc-man
>> >
>> > Thanks it works. Could you also commit this to git?
>>
>> Done, but using git-checkout-index ...
> the line
> git read-tree release
> raised error perhaps I didn't checkout a branch for it, replacing it
> with
> git read-tree origin/relase
> or
> git read-tree remotes/origin/relase
>
> seems working.
Ah, stupid me.
> Another question, while it can open a file with editor in tree-view, I
> cannot find in tigmanual how to directly save a file. Any idea?
There is no such action/keybinding. I guess it should be easy to
extend the current functionality to query for a file name and save to
that instead of a temporary file.
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH 0/2] jn/gitweb-blame fixes
From: Jakub Narebski @ 2009-11-21 14:56 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git
In-Reply-To: <200911210132.44649.jnareb@gmail.com>
On Sat, 21 Nov 2009, Jakub Narebski wrote:
> * Testing it with IE8 (Internet Explorer 8.0.6001.18702) page loading stops
> at 0%, at the very beginning on startBlame() function
>
> IE8 shows that it finds the following errors:
>
> * "firstChild is null or not an object"
> line: 565, char:4
>
> a_sha1.firstChild.data = commit.sha1.substr(0, 8);
>
> It might be caused by the fact that firstChild for this case should be
> text node containing of pure whitespace:
> <a href=""> </a>
> Perhaps IE8 simplifies it in "compatibility view" mode
This bug (be it in gitweb.js or in IE8) is fixed by the following patch:
-- 8< --
diff --git i/gitweb/gitweb.js w/gitweb/gitweb.js
index 200ec5a..c1e425c 100644
--- i/gitweb/gitweb.js
+++ w/gitweb/gitweb.js
@@ -562,7 +562,12 @@ function handleLine(commit, group) {
td_sha1.rowSpan = group.numlines;
a_sha1.href = projectUrl + 'a=commit;h=' + commit.sha1;
- a_sha1.firstChild.data = commit.sha1.substr(0, 8);
+ if (a_sha1.firstChild) {
+ a_sha1.firstChild.data = commit.sha1.substr(0, 8);
+ } else {
+ a_sha1.appendChild(
+ document.createTextNode(commit.sha1.substr(0, 8)));
+ }
if (group.numlines >= 2) {
var fragment = document.createDocumentFragment();
var br = document.createElement("br");
-- >8 --
>
> * "Unspecified error" (twice)
> line: 777, char:2
>
> if (xhr.readyState === 3 && xhr.status !== 200) {
> return;
> }
>
> I don't know what might be the source of error here; I suspect that the
> error position mentioned by IE8 is bogus.
But I have no idea how to fix this. "Unspecified error" isn't very
helpful...
--
Jakub Narebski
Poland
^ permalink raw reply related
* Re: Help creating script that mass-pulls Git(Hub) repos
From: Kumar Appaiah @ 2009-11-21 15:18 UTC (permalink / raw)
To: git
In-Reply-To: <dc191bcd0911210225k3cf946c6k54f1287c818af5a8@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 273 bytes --]
On Sat, Nov 21, 2009 at 11:25:20AM +0100, Tony Maserati wrote:
> Hi,
>
> I got a bunch of repos I've cloned off GitHub and I'm looking for the
> best way to keep them all up to date.
Would mr help?
http://kitenet.net/~joey/code/mr/
Kumar
--
Kumar Appaiah
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* How to make git diff-* ignore some patterns?
From: Dirk Süsserott @ 2009-11-21 16:40 UTC (permalink / raw)
To: Git Mailing List
Hi list,
is there a way to tell "git diff-index" to ignore some special patterns,
such that /^-- Dump completed on .*$/ is NOT recognized as a difference
and "git diff-index" returns 0 if that's the only difference?
-- Dirk
<Background>
I have a mySQL database which I backup daily using mysqldump (cronjob).
The result is a text file (*.sql) with all the "create" and "insert"
statements and some metadata.
I used to use tar and gzip to backup these files and got a huge
collection of backups in the last tree years (500+ MB).
Then I switched to Git and recorded only the diffs between day X and day
X-1. My repository shrunk to 16 MB for the very same data, which was great!
My database doesn't change every day, but I backup it anway and store
the backup files with Git and a cronjob. It does:
---------------
mysqldump ... -r <backupfile> # that's the output file ;-)
git add <backupfile>
if ! git diff-index --quiet HEAD --; then
git commit -m "Backup of <database> at <timestamp>"
fi
---------------
This way, a new commit is only done when the backupfile has changed. So
far, so perfect.
A few days ago my web hoster (where the database actually resides)
changed the mySQL version.
mysqldump now writes "-- Dump completed on <timestamp>" to the file and
Git correctly recognizes this as a change and my script creates a new
commit. Every day, even if only that line has changed.
I'd like to skip these commits if only the "Dump completed" line has
changed.
</Background>
^ permalink raw reply
* Re: How to make git diff-* ignore some patterns?
From: Michael J Gruber @ 2009-11-21 17:31 UTC (permalink / raw)
To: Dirk Süsserott; +Cc: Git Mailing List
In-Reply-To: <4B0817EE.1040000@dirk.my1.cc>
Dirk Süsserott venit, vidit, dixit 21.11.2009 17:40:
> Hi list,
>
> is there a way to tell "git diff-index" to ignore some special patterns,
> such that /^-- Dump completed on .*$/ is NOT recognized as a difference
> and "git diff-index" returns 0 if that's the only difference?
>
> -- Dirk
>
> <Background>
> I have a mySQL database which I backup daily using mysqldump (cronjob).
> The result is a text file (*.sql) with all the "create" and "insert"
> statements and some metadata.
> I used to use tar and gzip to backup these files and got a huge
> collection of backups in the last tree years (500+ MB).
> Then I switched to Git and recorded only the diffs between day X and day
> X-1. My repository shrunk to 16 MB for the very same data, which was great!
>
> My database doesn't change every day, but I backup it anway and store
> the backup files with Git and a cronjob. It does:
>
> ---------------
> mysqldump ... -r <backupfile> # that's the output file ;-)
> git add <backupfile>
> if ! git diff-index --quiet HEAD --; then
> git commit -m "Backup of <database> at <timestamp>"
> fi
> ---------------
>
> This way, a new commit is only done when the backupfile has changed. So
> far, so perfect.
> A few days ago my web hoster (where the database actually resides)
> changed the mySQL version.
> mysqldump now writes "-- Dump completed on <timestamp>" to the file and
> Git correctly recognizes this as a change and my script creates a new
> commit. Every day, even if only that line has changed.
>
> I'd like to skip these commits if only the "Dump completed" line has
> changed.
> </Background>
Is the dump guaranteed to be in a specific order? If yes then this
procedure makes sense. (pdfs etc. are problematic because of reordering.)
You can either egrep -v through the output of git diff-index, or define
a diff driver: set an attribute, say "dumpdiff", for dump files (see
gitattributes) and define diff driver as
git config diff.dumpdiff.textconv = dumpdiff.sh
where dumpdiff.sh is "egrep -v ...". You may need to call diff-index
with --ext-diff. I haven't tried, though ;)
Cheers,
Michael
^ permalink raw reply
* [PATCH] send-email: new 'add-envelope' option
From: Felipe Contreras @ 2009-11-21 17:43 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
Some MTAs make smart decisions based on the 'from' envelope (i.e. msmtp)
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
git-send-email.perl | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index a0279de..92bf491 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -140,6 +140,7 @@ my (@to,@cc,@initial_cc,@bcclist,@xh,
$author,$sender,$smtp_authpass,$annotate,$compose,$time);
my $envelope_sender;
+my $envelope_from;
# Example reply to:
#$initial_reply_to = ''; #<20050203173208.GA23964@foobar.com>';
@@ -208,6 +209,7 @@ my %config_settings = (
"aliasesfile" => \@alias_files,
"suppresscc" => \@suppress_cc,
"envelopesender" => \$envelope_sender,
+ "envelopefrom" => \$envelope_from,
"multiedit" => \$multiedit,
"confirm" => \$confirm,
"from" => \$sender,
@@ -265,6 +267,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"confirm=s" => \$confirm,
"dry-run" => \$dry_run,
"envelope-sender=s" => \$envelope_sender,
+ "envelope-from" => \$envelope_from,
"thread!" => \$thread,
"validate!" => \$validate,
"format-patch!" => \$format_patch,
@@ -861,10 +864,13 @@ X-Mailer: git-send-email $gitversion
my @sendmail_parameters = ('-i', @recipients);
my $raw_from = $sanitized_sender;
- $raw_from = $envelope_sender if (defined $envelope_sender);
+ if (defined $envelope_sender) {
+ $raw_from = $envelope_sender;
+ $envelope_from = 1;
+ }
$raw_from = extract_valid_address($raw_from);
unshift (@sendmail_parameters,
- '-f', $raw_from) if(defined $envelope_sender);
+ '-f', $raw_from) if(defined $envelope_from);
if ($needs_confirm && !$dry_run) {
print "\n$header\n";
--
1.6.5.3.1.ga9388c
^ permalink raw reply related
* Re: Git graph with branch labels for all paths in text environment
From: Jonas Fonseca @ 2009-11-21 17:50 UTC (permalink / raw)
To: rhlee; +Cc: git
In-Reply-To: <1258373038892-4011651.post@n2.nabble.com>
On Mon, Nov 16, 2009 at 07:03, rhlee <richard@webdezign.co.uk> wrote:
> Is there anyway to to view a text based git grah that shows all paths with
> the branch labels? Like a on gitk but ncurses based?
>
> [...]
> I can get all branch labels in tig, but only for the current branch.
You can browse all branches by using: tig --all
However, the graph drawing is rather poor for complex git histories.
--
Jonas Fonseca
^ permalink raw reply
* Re: How to make git diff-* ignore some patterns?
From: Björn Steinbrink @ 2009-11-21 18:07 UTC (permalink / raw)
To: Dirk Süsserott; +Cc: Git Mailing List
In-Reply-To: <4B0817EE.1040000@dirk.my1.cc>
On 2009.11.21 17:40:14 +0100, Dirk Süsserott wrote:
> is there a way to tell "git diff-index" to ignore some special
> patterns, such that /^-- Dump completed on .*$/ is NOT recognized as
> a difference and "git diff-index" returns 0 if that's the only
> difference?
If you don't mind losing that line, you could use a clean filter via
.gitattributes:
echo '*.sql filter=mysql_dump' >> .gitattributes
git config filter.mysql_dump.clean "sed -e '/^-- Dump completed on .*$/d'"
That way, git will filter all *.sql paths through that sed command
before storing them as blobs, dropping that "Dump completed" line from
the data stored in the repo.
Björn
^ permalink raw reply
* [PATCH v2] git-count-objects: Fix a disk-space under-estimate on Cygwin
From: Ramsay Jones @ 2009-11-20 23:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list
On Cygwin, the st_blocks field in 'struct stat' counts in blocks
of st_blksize bytes. At least on NTFS, the st_blksize field is
not 512 bytes, as required by the code, which leads to an under
estimate of the disk-space used.
Setting the build variable NO_ST_BLOCKS_IN_STRUCT_STAT, switches
to an algorithm that only uses the st_size field to compute the
disk-space estimate.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
Changed since v1:
- a commit message!
- removed comment.
ATB,
Ramsay Jones
Makefile | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 5d5976f..8902dba 100644
--- a/Makefile
+++ b/Makefile
@@ -783,6 +783,7 @@ ifeq ($(uname_O),Cygwin)
NO_FAST_WORKING_DIRECTORY = UnfortunatelyYes
NO_TRUSTABLE_FILEMODE = UnfortunatelyYes
OLD_ICONV = UnfortunatelyYes
+ NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
# There are conflicting reports about this.
# On some boxes NO_MMAP is needed, and not so elsewhere.
# Try commenting this out if you suspect MMAP is more efficient
--
1.6.5
^ permalink raw reply related
* Re: [PATCH] git-count-objects: Fix a disk-space under-estimate on Cygwin
From: Ramsay Jones @ 2009-11-21 0:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list
In-Reply-To: <7vlji17i02.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> When estimating the on-disk footprint of a file, we either used st_blocks
> that is counted in 512-byte blocks (traditional unix behaviour), or on
> platforms that do not have such st_blocks field in struct stat, simply the
> file size itself. Building with NO_ST_BLOCKS_IN_STRUCT_STAT will choose
> the latter implementaion.
>
> POSIX.1 says in its <sys/stat.h> description on this issue:
>
> The unit for the st_blocks member of the stat structure is not
> defined within POSIX.1-2008. In some implementations it is 512
> bytes. It may differ on a file system basis. There is no
> correlation between values of the st_blocks and st_blksize,
> and the f_bsize (from <sys/statvfs.h>) structure members.
>
> Even though the above explicitly states st_blksize does not have any
> correlation, at least on one system (Cygwin on NTFS), the st_blocks field
> seems to count in blocks of st_blksize bytes. A new Makefile variable
> ST_BLOCKS_COUNTS_IN_BLKSIZE chooses to use this for the on-disk footprint.
My first attempt to fix this problem was very similar to this. ;-)
BTW, I thought that st_blocks and st_blksize were both XSI/SUS extensions
and not part of POSIX, but your quote above contradicts that. Also, I don't
know that you can count on *both* fields always being present (I have not
personally used a system that didn't have st_blksize if it had st_blocks,
but I don't think it's guaranteed).
Anyway, I decided against this kind of solution because it didn't address
the problem of returning different answers depending on the setting of
core.filemode.
Having said that, maybe that's not a big deal; in everyday use I can't
imagine that anyone would change the core.filemode setting more than once,
if ever. (I *have* been doing that quite a bit while testing an msvc-built
git on cygwin; but again, that's probably *not* an everyday usage :-P )
I haven't tried this patch, but I think you may need to add something like
the following (*not tested*):
--- >8 ---
diff --git a/compat/cygwin.c b/compat/cygwin.c
index b4a51b9..7e9edec 100644
--- a/compat/cygwin.c
+++ b/compat/cygwin.c
@@ -53,6 +53,7 @@ static int do_stat(const char *file_name, struct stat *buf, stat_fn_t cygstat)
buf->st_size = (off_t)fdata.nFileSizeLow;
#endif
buf->st_blocks = size_to_blocks(buf->st_size);
+ buf->st_blksize = 512;
filetime_to_timespec(&fdata.ftLastAccessTime, &buf->st_atim);
filetime_to_timespec(&fdata.ftLastWriteTime, &buf->st_mtim);
filetime_to_timespec(&fdata.ftCreationTime, &buf->st_ctim);
--- >8 ---
ATB,
Ramsay Jones
^ permalink raw reply related
* [PATCH/RFC 0/3] git rerere unresolve file
From: Johannes Sixt @ 2009-11-21 18:58 UTC (permalink / raw)
To: git
When you commit an incorrect conflict resolution, git rerere gets in the way:
rerere clear only clears cache entries of not yet resolved conflicts. But
there is no other way to remove an incorrect resolution short of purging the
whole rr-cache.
This series implements 'git rerere unresolve' that removes a recorded
resolution.
This is RFC for two reasons:
- It changes the contents of MERGE_RR in a way that *may* interfer in unwanted
ways with older versions that do not understand unresolve.
- rerere unresolve also restores the conflict regions. I'm not sure whether
this is good because there is 'git checkout --conflict=merge file' that does
it in a better way. See the commit message of patch 3.
If rerere unresolve does *not* restore conflict regions (and record the result
as preimage right away) we are facing a problem: When the resolution is
committed, the postimage has differences from the preimage that are not
related to the conflict. This may inhibit reusing the resolution later when
the file has new changes.
Johannes Sixt (3):
rerere: keep a list of resolved files in MERGE_RR
rerere: make recording of the preimage reusable
git rerere unresolve file...
Documentation/git-rerere.txt | 10 +++-
builtin-rerere.c | 13 +++-
rerere.c | 153 ++++++++++++++++++++++++++++++++++-------
rerere.h | 4 +-
4 files changed, 148 insertions(+), 32 deletions(-)
^ permalink raw reply
* [PATCH/RFC 1/3] rerere: keep a list of resolved files in MERGE_RR
From: Johannes Sixt @ 2009-11-21 19:00 UTC (permalink / raw)
To: git
In-Reply-To: <200911211958.40872.j6t@kdbg.org>
Previously, MERGE_RR entries that rerere detected as resolved were removed
from MERGE_RR so that it contained only entries for files that still had
conflicts.
This changes the "database" format to also keep the entries about files
for which resolutions have been recorded. The purpose is to allow that
resolved conflicts can be unresolved. To do that it is necessary to have
a mapping from the file name to the conflict hash.
The new format of MERGE_RR is:
1. Entries about unresolved conflicts.
2. An all-zeros SHA1 as boundary marker.
3. Entries about resolved conflicts.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
builtin-rerere.c | 4 +++-
rerere.c | 49 ++++++++++++++++++++++++++++++++++++++++---------
rerere.h | 2 +-
3 files changed, 44 insertions(+), 11 deletions(-)
diff --git a/builtin-rerere.c b/builtin-rerere.c
index adfb7b5..275827d 100644
--- a/builtin-rerere.c
+++ b/builtin-rerere.c
@@ -101,12 +101,13 @@ static int diff_two(const char *file1, const char *label1,
int cmd_rerere(int argc, const char **argv, const char *prefix)
{
struct string_list merge_rr = { NULL, 0, 0, 1 };
+ struct string_list merge_rr_done = { NULL, 0, 0, 1 };
int i, fd;
if (argc < 2)
return rerere();
- fd = setup_rerere(&merge_rr);
+ fd = setup_rerere(&merge_rr, &merge_rr_done);
if (fd < 0)
return 0;
@@ -132,5 +133,6 @@ int cmd_rerere(int argc, const char **argv, const char *prefix)
usage(git_rerere_usage);
string_list_clear(&merge_rr, 1);
+ string_list_clear(&merge_rr_done, 1);
return 0;
}
diff --git a/rerere.c b/rerere.c
index 29f95f6..84d0bb7 100644
--- a/rerere.c
+++ b/rerere.c
@@ -23,8 +23,20 @@ int has_rerere_resolution(const char *hex)
return !stat(rerere_path(hex, "postimage"), &st);
}
-static void read_rr(struct string_list *rr)
+/*
+ * If MERGE_RR is read and rewritten by an old version, the section bound
+ * would not be preserved, and file names from both sections would be
+ * interleaved. We must make sure that the section marker does not end up
+ * in an arbitrary position. In particular, the safest result is that all
+ * paths are now in the first ("not done") section. Therefore, we choose
+ * a file name that sorts last (for all practical purposes).
+ */
+static const char section_mark[] =
+ "0000000000000000000000000000000000000000\t\377\377\377\377";
+
+static void read_rr(struct string_list *rr, struct string_list *rr_done)
{
+ struct string_list *section = rr;
unsigned char sha1[20];
char buf[PATH_MAX];
FILE *in = fopen(merge_rr_path, "r");
@@ -43,14 +55,19 @@ static void read_rr(struct string_list *rr)
; /* do nothing */
if (i == sizeof(buf))
die("filename too long");
- string_list_insert(buf, rr)->util = name;
+ if (prefixcmp(section_mark, name)) {
+ string_list_insert(buf, section)->util = name;
+ } else {
+ free(name);
+ section = rr_done;
+ }
}
fclose(in);
}
static struct lock_file write_lock;
-static int write_rr(struct string_list *rr, int out_fd)
+static void write_rr_section(struct string_list *rr, int out_fd)
{
int i;
for (i = 0; i < rr->nr; i++) {
@@ -65,6 +82,17 @@ static int write_rr(struct string_list *rr, int out_fd)
write_in_full(out_fd, path, length) != length)
die("unable to write rerere record");
}
+}
+
+static int write_rr(struct string_list *rr,
+ struct string_list *rr_done, int out_fd)
+{
+ int length = strlen(section_mark)+1;
+
+ write_rr_section(rr, out_fd);
+ if (write_in_full(out_fd, section_mark, length) != length)
+ die("unable to write rerere record");
+ write_rr_section(rr_done, out_fd);
if (commit_lock_file(&write_lock) != 0)
die("unable to write rerere record");
return 0;
@@ -263,7 +291,8 @@ static int update_paths(struct string_list *update)
return status;
}
-static int do_plain_rerere(struct string_list *rr, int fd)
+static int do_plain_rerere(struct string_list *rr,
+ struct string_list *rr_done, int fd)
{
struct string_list conflict = { NULL, 0, 0, 1 };
struct string_list update = { NULL, 0, 0, 1 };
@@ -328,13 +357,14 @@ static int do_plain_rerere(struct string_list *rr, int fd)
fprintf(stderr, "Recorded resolution for '%s'.\n", path);
copy_file(rerere_path(name, "postimage"), path, 0666);
mark_resolved:
+ string_list_insert(path, rr_done)->util = rr->items[i].util;
rr->items[i].util = NULL;
}
if (update.nr)
update_paths(&update);
- return write_rr(rr, fd);
+ return write_rr(rr, rr_done, fd);
}
static int git_rerere_config(const char *var, const char *value, void *cb)
@@ -367,7 +397,7 @@ static int is_rerere_enabled(void)
return 1;
}
-int setup_rerere(struct string_list *merge_rr)
+int setup_rerere(struct string_list *merge_rr, struct string_list *merge_rr_done)
{
int fd;
@@ -378,17 +408,18 @@ int setup_rerere(struct string_list *merge_rr)
merge_rr_path = git_pathdup("MERGE_RR");
fd = hold_lock_file_for_update(&write_lock, merge_rr_path,
LOCK_DIE_ON_ERROR);
- read_rr(merge_rr);
+ read_rr(merge_rr, merge_rr_done);
return fd;
}
int rerere(void)
{
struct string_list merge_rr = { NULL, 0, 0, 1 };
+ struct string_list merge_rr_done = { NULL, 0, 0, 1 };
int fd;
- fd = setup_rerere(&merge_rr);
+ fd = setup_rerere(&merge_rr, &merge_rr_done);
if (fd < 0)
return 0;
- return do_plain_rerere(&merge_rr, fd);
+ return do_plain_rerere(&merge_rr, &merge_rr_done, fd);
}
diff --git a/rerere.h b/rerere.h
index 13313f3..9bb2f13 100644
--- a/rerere.h
+++ b/rerere.h
@@ -3,7 +3,7 @@
#include "string-list.h"
-extern int setup_rerere(struct string_list *);
+extern int setup_rerere(struct string_list *, struct string_list *);
extern int rerere(void);
extern const char *rerere_path(const char *hex, const char *file);
extern int has_rerere_resolution(const char *hex);
--
1.6.5.2.182.ge039a
^ permalink raw reply related
* [PATCH/RFC 2/3] rerere: make recording of the preimage reusable
From: Johannes Sixt @ 2009-11-21 19:01 UTC (permalink / raw)
To: git
In-Reply-To: <200911212000.19326.j6t@kdbg.org>
This factors the code that computes the conflict hash and records the
preimage into a helper function.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
rerere.c | 30 ++++++++++++++++++++----------
1 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/rerere.c b/rerere.c
index 84d0bb7..11fef88 100644
--- a/rerere.c
+++ b/rerere.c
@@ -229,6 +229,25 @@ static int find_conflict(struct string_list *conflict)
return 0;
}
+static int record_preimage(struct string_list *rr, const char *path, int force)
+{
+ unsigned char sha1[20];
+ char *hex;
+ int ret;
+
+ ret = handle_file(path, sha1, NULL);
+ if (ret < 1)
+ return -1;
+
+ hex = xstrdup(sha1_to_hex(sha1));
+ string_list_insert(path, rr)->util = hex;
+ if (mkdir(git_path("rr-cache/%s", hex), 0755) && !force)
+ return -1;
+
+ handle_file(path, NULL, rerere_path(hex, "preimage"));
+ return 0;
+}
+
static int merge(const char *name, const char *path)
{
int ret;
@@ -310,17 +329,8 @@ static int do_plain_rerere(struct string_list *rr,
for (i = 0; i < conflict.nr; i++) {
const char *path = conflict.items[i].string;
if (!string_list_has_string(rr, path)) {
- unsigned char sha1[20];
- char *hex;
- int ret;
- ret = handle_file(path, sha1, NULL);
- if (ret < 1)
- continue;
- hex = xstrdup(sha1_to_hex(sha1));
- string_list_insert(path, rr)->util = hex;
- if (mkdir(git_path("rr-cache/%s", hex), 0755))
+ if (record_preimage(rr, path, 0))
continue;
- handle_file(path, NULL, rerere_path(hex, "preimage"));
fprintf(stderr, "Recorded preimage for '%s'\n", path);
}
}
--
1.6.5.2.182.ge039a
^ permalink raw reply related
* [PATCH/RFC 3/3] git rerere unresolve file...
From: Johannes Sixt @ 2009-11-21 19:02 UTC (permalink / raw)
To: git
In-Reply-To: <200911212001.06207.j6t@kdbg.org>
There was no way to remove a recorded resolution short of removing the
entire .git/rr-cache. This gets in the way when an incorrect resolution
was recorded.
This implements the subcommand 'git rerere unresolve' that selectively
removes the recorded resolution of the specified files. It also reverts
the resolution so that the files again have conflict markers. However,
these unresolved conflict markers not necessarily reflect "ours" and
"theirs" correctly because the preimage that was stored in the cache has
the conflicted sides in a canonical order.
In handle_file(), the checks for the beginning and end of a conflict
region have to be loosened slightly -- there can be any whitespace,
including a LF, not just a blank -- because after the conflict regions are
restored, there are no trailing blanks and a subsequent 'git rerere' would
not recognize them anymore.
'git checkout --conflict=merge path...' can restore the conflicted file
as well, but it does not remove the recorded resolution.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Documentation/git-rerere.txt | 10 +++++-
builtin-rerere.c | 9 +++--
rerere.c | 74 ++++++++++++++++++++++++++++++++++++++----
rerere.h | 2 +
4 files changed, 84 insertions(+), 11 deletions(-)
diff --git a/Documentation/git-rerere.txt b/Documentation/git-rerere.txt
index 7dd515b..c9bf3f1 100644
--- a/Documentation/git-rerere.txt
+++ b/Documentation/git-rerere.txt
@@ -7,7 +7,7 @@ git-rerere - Reuse recorded resolution of conflicted merges
SYNOPSIS
--------
-'git rerere' ['clear'|'diff'|'status'|'gc']
+'git rerere' ['clear'|'diff'|'status'|'unresolve file...'|'gc']
DESCRIPTION
-----------
@@ -52,6 +52,14 @@ conflicts. Additional arguments are passed directly to the system
Like 'diff', but this only prints the filenames that will be tracked
for resolutions.
+'unresolve'::
+
+Removes the resolution that was recorded for the specified files.
+The conflict sections are restored as well, although the direction of
+the "ours" and "theirs" sections may be inverted.
+You can use 'git checkout --conflict=merge file' to restore the
+original conflict markers in the correct direction.
+
'gc'::
This prunes records of conflicted merges that
diff --git a/builtin-rerere.c b/builtin-rerere.c
index 275827d..5d3a3a5 100644
--- a/builtin-rerere.c
+++ b/builtin-rerere.c
@@ -7,7 +7,7 @@
#include "xdiff-interface.h"
static const char git_rerere_usage[] =
-"git rerere [clear | status | diff | gc]";
+"git rerere [clear | status | diff | unresolve file... | gc]";
/* these values are days */
static int cutoff_noresolve = 15;
@@ -102,7 +102,7 @@ int cmd_rerere(int argc, const char **argv, const char *prefix)
{
struct string_list merge_rr = { NULL, 0, 0, 1 };
struct string_list merge_rr_done = { NULL, 0, 0, 1 };
- int i, fd;
+ int i, fd, ret = 0;
if (argc < 2)
return rerere();
@@ -129,10 +129,13 @@ int cmd_rerere(int argc, const char **argv, const char *prefix)
const char *name = (const char *)merge_rr.items[i].util;
diff_two(rerere_path(name, "preimage"), path, path, path);
}
+ else if (!strcmp(argv[1], "unresolve"))
+ ret = unresolve_rerere(&merge_rr, &merge_rr_done,
+ get_pathspec(prefix, &argv[2]), fd);
else
usage(git_rerere_usage);
string_list_clear(&merge_rr, 1);
string_list_clear(&merge_rr_done, 1);
- return 0;
+ return ret;
}
diff --git a/rerere.c b/rerere.c
index 11fef88..b31008d 100644
--- a/rerere.c
+++ b/rerere.c
@@ -140,7 +140,7 @@ static int handle_file(const char *path,
git_SHA1_Init(&ctx);
while (fgets(buf, sizeof(buf), f)) {
- if (!prefixcmp(buf, "<<<<<<< ")) {
+ if (!prefixcmp(buf, "<<<<<<<") && isspace(buf[7])) {
if (hunk != RR_CONTEXT)
goto bad;
hunk = RR_SIDE_1;
@@ -152,7 +152,7 @@ static int handle_file(const char *path,
if (hunk != RR_SIDE_1 && hunk != RR_ORIGINAL)
goto bad;
hunk = RR_SIDE_2;
- } else if (!prefixcmp(buf, ">>>>>>> ")) {
+ } else if (!prefixcmp(buf, ">>>>>>>") && isspace(buf[7])) {
if (hunk != RR_SIDE_2)
goto bad;
if (strbuf_cmp(&one, &two) > 0)
@@ -248,23 +248,29 @@ static int record_preimage(struct string_list *rr, const char *path, int
force)
return 0;
}
-static int merge(const char *name, const char *path)
+#define RESOLVE 0
+#define UNRESOLVE 1
+#define UNRESOLVE_CHECK 2
+
+static int merge(const char *name, const char *path, int mode)
{
int ret;
mmfile_t cur, base, other;
mmbuffer_t result = {NULL, 0};
xpparam_t xpp = {XDF_NEED_MINIMAL};
+ const char *basename = mode == RESOLVE ? "preimage" : "postimage";
+ const char *othername = mode == RESOLVE ? "postimage" : "preimage";
if (handle_file(path, NULL, rerere_path(name, "thisimage")) < 0)
return 1;
if (read_mmfile(&cur, rerere_path(name, "thisimage")) ||
- read_mmfile(&base, rerere_path(name, "preimage")) ||
- read_mmfile(&other, rerere_path(name, "postimage")))
+ read_mmfile(&base, rerere_path(name, basename)) ||
+ read_mmfile(&other, rerere_path(name, othername)))
return 1;
ret = xdl_merge(&base, &cur, "", &other, "",
&xpp, XDL_MERGE_ZEALOUS, &result);
- if (!ret) {
+ if (!ret && mode != UNRESOLVE_CHECK) {
FILE *f = fopen(path, "w");
if (!f)
return error("Could not open %s: %s", path,
@@ -347,7 +353,7 @@ static int do_plain_rerere(struct string_list *rr,
const char *name = (const char *)rr->items[i].util;
if (has_rerere_resolution(name)) {
- if (!merge(name, path)) {
+ if (!merge(name, path, RESOLVE)) {
if (rerere_autoupdate)
string_list_insert(path, &update);
fprintf(stderr,
@@ -433,3 +439,57 @@ int rerere(void)
return 0;
return do_plain_rerere(&merge_rr, &merge_rr_done, fd);
}
+
+static int unresolve_check(struct string_list *rr_done, const char *path)
+{
+ struct string_list_item *item = string_list_lookup(path, rr_done);
+
+ if (!item) {
+ warning("not resolved using a previous resolution: %s", path);
+ return 0;
+ }
+ if (!has_rerere_resolution(item->util))
+ return error("no resolution found for %s", path);
+ if (merge(item->util, path, UNRESOLVE_CHECK))
+ return error("cannot revert resolution of %s", path);
+ return 0;
+}
+
+int unresolve_rerere_1(struct string_list *rr, struct string_list *rr_done,
+ const char *path)
+{
+ struct string_list_item *item = string_list_lookup(path, rr_done);
+
+ if (!item)
+ return 0;
+ if (merge(item->util, path, UNRESOLVE))
+ return -1;
+
+ if (record_preimage(rr, path, 1))
+ return error("no conflict markers found: %s", path);
+
+ item->util = NULL;
+ unlink_or_warn(rerere_path(item->util, "postimage"));
+ return 0;
+}
+
+int unresolve_rerere(struct string_list *rr, struct string_list *rr_done,
+ const char **pathspec, int fd)
+{
+ int i, ret = 0;
+
+ if (!pathspec)
+ return error("unresolve what?");
+
+ for (i = 0; pathspec[i]; i++) {
+ ret |= unresolve_check(rr_done, pathspec[i]);
+ }
+ if (ret)
+ return ret;
+
+ for (i = 0; !ret && pathspec[i]; i++) {
+ ret = unresolve_rerere_1(rr, rr_done, pathspec[i]);
+ }
+ ret |= write_rr(rr, rr_done, fd);
+ return ret;
+}
diff --git a/rerere.h b/rerere.h
index 9bb2f13..a0fa50f 100644
--- a/rerere.h
+++ b/rerere.h
@@ -7,5 +7,7 @@ extern int setup_rerere(struct string_list *, struct string_list *);
extern int rerere(void);
extern const char *rerere_path(const char *hex, const char *file);
extern int has_rerere_resolution(const char *hex);
+extern int unresolve_rerere(struct string_list *, struct string_list *,
+ const char **, int);
#endif
--
1.6.5.2.182.ge039a
^ permalink raw reply related
* Re: [PATCH] send-email: new 'add-envelope' option
From: Jeff King @ 2009-11-21 19:36 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1258825410-28592-1-git-send-email-felipe.contreras@gmail.com>
On Sat, Nov 21, 2009 at 07:43:30PM +0200, Felipe Contreras wrote:
> Some MTAs make smart decisions based on the 'from' envelope (i.e. msmtp)
So my first thought was "how in the world is this different from setting
the envelope sender?"
Reading the code, it seems:
> - $raw_from = $envelope_sender if (defined $envelope_sender);
> + if (defined $envelope_sender) {
> + $raw_from = $envelope_sender;
> + $envelope_from = 1;
> + }
> $raw_from = extract_valid_address($raw_from);
> unshift (@sendmail_parameters,
> - '-f', $raw_from) if(defined $envelope_sender);
> + '-f', $raw_from) if(defined $envelope_from);
that this is a boolean to mean "use the from address as the envelope
sender".
It was of course all the more confusing for not being documented at all,
but even if documented, --envelope-from is IMHO confusingly similar to
--envelope-sender. Maybe --use-from-in-envelope would be a better name?
And of course, your patch is missing docs and tests.
-Peff
^ 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