Re: [PATCH v2] Thunderbird: fix appp.sh format problems
Il 30/08/2012 19:00, Junio C Hamano ha scritto:
Marco Stornelli marco.storne...@gmail.com writes:
The current script has got the following problems:
1) It doesn't work if the language used by Thunderbird is not English;
2) The field To: filled by format-patch is not evaluated;
3) The field Cc: is loaded only from Cc used in the commit message
instead of using even the Cc field filled by format-patch in the email
header.
Added comments for point 1). Fixed point 2) and 3).
Signed-off-by: Marco Stornelli marco.storne...@gmail.com
---
v2: changed the commit message to reflect better the script implementation
I actually thought what the log message of the previous version
claimed to do was much more sensible.
The language used in the above 3 items describe what you perceive as
a problem, but it is unclear what the desired behaviour that is
different from the current one is. (2) ... is not evaluated
implies , which is a problem, so fix it by evaluating it, but
there is no single obvious fix to (3) loaded only from Cc in commit
and not Cc from format-patch. Should it ignore Cc from commit log
message, or should it take Cc from both log message and e-mail
header? I personally think it should the former, but it is not
clear which you think is the right thing to do (or perhaps you have
a third answer) if you only say Fixed point 3.
Ok, I can change the commit. Actually with the new implementation Cc: is
evaluated in both cases.
contrib/thunderbird-patch-inline/appp.sh | 18 ++
1 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/contrib/thunderbird-patch-inline/appp.sh
b/contrib/thunderbird-patch-inline/appp.sh
index 5eb4a51..e6e1b85 100755
--- a/contrib/thunderbird-patch-inline/appp.sh
+++ b/contrib/thunderbird-patch-inline/appp.sh
@@ -6,6 +6,9 @@
# ExternalEditor can be downloaded at
http://globs.org/articles.php?lng=enpg=2
+# NOTE: You must change some words in this script according to the language
+# used by Mozilla Thunderbird, as Subject, To, Don't remove this line.
+
CONFFILE=~/.appprc
SEP=-=-=-=-=-=-=-=-=-=# Don't remove this line #=-=-=-=-=-=-=-=-=-
@@ -26,17 +29,24 @@ fi
cd - /dev/null
SUBJECT=`sed -n -e '/^Subject: /p' ${PATCH}`
-HEADERS=`sed -e '/^'${SEP}'$/,$d' $1`
BODY=`sed -e 1,/${SEP}/d $1`
CMT_MSG=`sed -e '1,/^$/d' -e '/^---$/,$d' ${PATCH}`
DIFF=`sed -e '1,/^---$/d' ${PATCH}`
-CCS=`echo -e $CMT_MSG\n$HEADERS | sed -n -e 's/^Cc: \(.*\)$/\1,/gp' \
- -e 's/^Signed-off-by: \(.*\)/\1,/gp'`
+export PATCH
+CCS=`perl -e 'local $/=undef; open FILE, $ENV{'PATCH'}; $text=FILE;
+close FILE; $cc = $1 if $text =~ /Cc: (.*?(,\n .*?)*)\n/s; $cc =~ s/\n//g;
+print $cc;'`
+
+TO=`perl -e 'local $/=undef; open FILE, $ENV{'PATCH'}; $text=FILE;
+close FILE; $to = $1 if $text =~ /To: (.*?(,\n .*?)*)\n/s; $to =~ s/\n//g;
+print $to;'`
+# Change Subject before next line according to Thunderbird language
echo $SUBJECT $1
before next line??? I do not think you meant to rename the
variable $SUBJECT to $localized string for subject.
In my case I add a line before in this way:
SUBJECT=`echo $SUBJECT | sed 's/Subject/Oggetto/g'`
echo $SUBJECT $1
+# Change To according to Thunderbird language
# Change To: according to...
Ok.
would be less confusing, as the line has to to on it when viewed
case insensitively.
+echo To: $TO $1
echo Cc: $CCS $1
-echo $HEADERS | sed -e '/^Subject: /d' -e '/^Cc: /d' $1
echo $SEP $1
echo $CMT_MSG $1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] test: set the realpath of CWD as TRASH_DIRECTORY
On 08/30/2012 07:26 AM, Junio C Hamano wrote: Michael Haggerty mhag...@alum.mit.edu writes: By the way, is the use of realpath(3) permissible in git code? GIT_CEILING_DIRECTORIES handling could be fixed relatively easily by using this function to canonicalize pathnames before comparison. As long as we can add a compat/realpath.c (perhaps lift one from glibc before they went GPLv3) for platforms that matter, I do not see it as a huge problem. How close is abspath.c::real_path() to what you need? Cool, I didn't know about that function. It's approximately what is needed, except that it dies if fed an invalid path (unacceptable when processing GIT_CEILING_DIRECTORIES) and it's buggy (try test-path-utils real_path '' or test-path-utils real_path '/foo'). However, I'm working on fixing it and splitting off a variant that returns NULL on errors. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] i18n: mark more index-pack strings for translation
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
The main string I'm after is completed with %d local objects, which
is part of typical UI. The rest is just while at there...
To my surprise, (GNU) gettext does seem to know how to deal with
PRIu32 macro in the middle of the string.
builtin/index-pack.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 953dd30..43d364b 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -291,7 +291,7 @@ static void parse_pack_header(void)
if (hdr-hdr_signature != htonl(PACK_SIGNATURE))
die(_(pack signature mismatch));
if (!pack_version_ok(hdr-hdr_version))
- die(pack version %PRIu32 unsupported,
+ die(_(pack version %PRIu32 unsupported),
ntohl(hdr-hdr_version));
nr_objects = ntohl(hdr-hdr_entries);
@@ -1061,7 +1061,8 @@ static void resolve_deltas(void)
int ret = pthread_create(thread_data[i].thread, NULL,
threaded_second_pass,
thread_data + i);
if (ret)
- die(unable to create thread: %s,
strerror(ret));
+ die(_(unable to create thread: %s),
+ strerror(ret));
}
for (i = 0; i nr_threads; i++)
pthread_join(thread_data[i].thread, NULL);
@@ -1108,7 +1109,7 @@ static void conclude_pack(int fix_thin_pack, const char
*curr_pack, unsigned cha
* sizeof(*objects));
f = sha1fd(output_fd, curr_pack);
fix_unresolved_deltas(f, nr_unresolved);
- sprintf(msg, completed with %d local objects,
+ sprintf(msg, _(completed with %d local objects),
nr_objects - nr_objects_initial);
stop_progress_msg(progress, msg);
sha1close(f, tail_sha1, 0);
@@ -1117,8 +1118,8 @@ static void conclude_pack(int fix_thin_pack, const char
*curr_pack, unsigned cha
curr_pack, nr_objects,
read_sha1, consumed_bytes-20);
if (hashcmp(read_sha1, tail_sha1) != 0)
- die(Unexpected tail checksum for %s
- (disk corruption?), curr_pack);
+ die(_(Unexpected tail checksum for %s
+ (disk corruption?)), curr_pack);
}
if (nr_deltas != nr_resolved_deltas)
die(Q_(pack has %d unresolved delta,
@@ -1327,17 +1328,17 @@ static int git_index_pack_config(const char *k, const
char *v, void *cb)
if (!strcmp(k, pack.indexversion)) {
opts-version = git_config_int(k, v);
if (opts-version 2)
- die(bad pack.indexversion=%PRIu32, opts-version);
+ die(_(bad pack.indexversion=%PRIu32), opts-version);
return 0;
}
if (!strcmp(k, pack.threads)) {
nr_threads = git_config_int(k, v);
if (nr_threads 0)
- die(invalid number of threads specified (%d),
+ die(_(invalid number of threads specified (%d)),
nr_threads);
#ifdef NO_PTHREADS
if (nr_threads != 1)
- warning(no threads support, ignoring %s, k);
+ warning(_(no threads support, ignoring %s), k);
nr_threads = 1;
#endif
return 0;
@@ -1510,8 +1511,8 @@ int cmd_index_pack(int argc, const char **argv, const
char *prefix)
usage(index_pack_usage);
#ifdef NO_PTHREADS
if (nr_threads != 1)
- warning(no threads support,
- ignoring %s, arg);
+ warning(_(no threads support,
+ ignoring %s), arg);
nr_threads = 1;
#endif
} else if (!prefixcmp(arg, --pack_header=)) {
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Aw: Re: git blame shows wrong Not commited yet entries
You are right but as I mentioned in my posting I am using core.ignorecase=true so I expected file.txt and File.txt to be treated the same. The man-page for git-config says: core.ignorecase If true, this option enables various workarounds to enable git to work better on filesystems that are not case sensitive, like FAT. For example, if a directory listing finds makefile when git expects Makefile, git will assume it is really the same file, and continue to remember it as Makefile. So various workarounds does _not_ mean that _all_ filenames are processed modulo upper/lower case, or? --- Thomas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] Thunderbird: fix appp.sh format problems
The current script has got the following problems:
1) It doesn't work if the language used by Thunderbird is not english;
2) The field To: filled by format-patch is not evaluated;
3) The field Cc: is loaded from Cc used in the commit message
instead of using the Cc field filled by format-patch in the email
header.
Added comments for point 1), added parsing of To: for point 2) and
added parsing of Cc: in the email header for point 3), removing the
Cc: parsing from commit message.
Signed-off-by: Marco Stornelli marco.storne...@gmail.com
---
v4: create a tmp file to allow correct perl parsing
v3: parse only To: and Cc: in the email header, fix some comments
v2: changed the commit message to reflect better the script implementation
v1: first draft
contrib/thunderbird-patch-inline/appp.sh | 26 ++
1 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/contrib/thunderbird-patch-inline/appp.sh
b/contrib/thunderbird-patch-inline/appp.sh
index 5eb4a51..0daeb29 100755
--- a/contrib/thunderbird-patch-inline/appp.sh
+++ b/contrib/thunderbird-patch-inline/appp.sh
@@ -6,6 +6,9 @@
# ExternalEditor can be downloaded at http://globs.org/articles.php?lng=enpg=2
+# NOTE: You must change some words in this script according to the language
+# used by Mozilla Thunderbird, as Subject, To, Don't remove this line.
+
CONFFILE=~/.appprc
SEP=-=-=-=-=-=-=-=-=-=# Don't remove this line #=-=-=-=-=-=-=-=-=-
@@ -26,17 +29,32 @@ fi
cd - /dev/null
SUBJECT=`sed -n -e '/^Subject: /p' ${PATCH}`
-HEADERS=`sed -e '/^'${SEP}'$/,$d' $1`
BODY=`sed -e 1,/${SEP}/d $1`
CMT_MSG=`sed -e '1,/^$/d' -e '/^---$/,$d' ${PATCH}`
DIFF=`sed -e '1,/^---$/d' ${PATCH}`
+MAILHEADER=`sed '/^$/q' ${PATCH}`
+PATCHTMP=${PATCH}.tmp
+
+echo $MAILHEADER $PATCHTMP
+
+export PATCHTMP
+CCS=`perl -e 'local $/=undef; open FILE, $ENV{'PATCHTMP'}; $text=FILE;
+close FILE; $addr = $1 if $text =~ /Cc: (.*?(,\n .*?)*)\n/s; $addr =~ s/\n//g;
+print $addr;'`
+
+TO=`perl -e 'local $/=undef; open FILE, $ENV{'PATCHTMP'}; $text=FILE;
+close FILE; $addr = $1 if $text =~ /To: (.*?(,\n .*?)*)\n/s; $addr =~ s/\n//g;
+print $addr;'`
-CCS=`echo -e $CMT_MSG\n$HEADERS | sed -n -e 's/^Cc: \(.*\)$/\1,/gp' \
- -e 's/^Signed-off-by: \(.*\)/\1,/gp'`
+rm -rf $PATCHTMP
+# Change Subject: before next line according to Thunderbird language
+# for example:
+# SUBJECT=`echo $SUBJECT | sed -e 's/Subject/Oggetto/g'`
echo $SUBJECT $1
+# Change To: according to Thunderbird language
+echo To: $TO $1
echo Cc: $CCS $1
-echo $HEADERS | sed -e '/^Subject: /d' -e '/^Cc: /d' $1
echo $SEP $1
echo $CMT_MSG $1
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] checkout: warn users if action is taken in ambiguous situation
git checkout foo (no more arguments) always checks out existing
branch foo even if foo exists on working directory. To avoid
confusion to users who do not know this exception, say something along
the action.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Personally I disagree with the comment above the top chunk about
stopping annoying users in this case. I think the annoyance is a good
sign for them to rename their branches to something more sensible.
builtin/checkout.c | 6 --
cache.h| 2 ++
setup.c| 21 +
3 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 7d922c6..7bc4e8a 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -899,8 +899,10 @@ static int parse_branchname_arg(int argc, const char
**argv,
* even if there happen to be a file called 'branch';
* it would be extremely annoying.
*/
- if (argc)
- verify_non_filename(NULL, arg);
+ const char *action = NULL;
+ if (!argc)
+ action = _(Checked out the new branch.);
+ verify_non_filename_gently(NULL, arg, action);
} else {
argcount++;
argv++;
diff --git a/cache.h b/cache.h
index 95daa69..95f11df 100644
--- a/cache.h
+++ b/cache.h
@@ -404,6 +404,8 @@ extern void verify_filename(const char *prefix,
const char *name,
int diagnose_misspelt_rev);
extern void verify_non_filename(const char *prefix, const char *name);
+extern void verify_non_filename_gently(const char *prefix, const char *name,
+ const char *preferred_action);
extern int path_inside_repo(const char *prefix, const char *path);
#define INIT_DB_QUIET 0x0001
diff --git a/setup.c b/setup.c
index 3a1b2fd..4b776cf 100644
--- a/setup.c
+++ b/setup.c
@@ -133,7 +133,8 @@ void verify_filename(const char *prefix,
* and we parsed the arg as a refname. It should not be interpretable
* as a filename.
*/
-void verify_non_filename(const char *prefix, const char *arg)
+void verify_non_filename_gently(const char *prefix, const char *arg,
+ const char *preferred_action)
{
if (!is_inside_work_tree() || is_inside_git_dir())
return;
@@ -141,9 +142,21 @@ void verify_non_filename(const char *prefix, const char
*arg)
return; /* flag */
if (!check_filename(prefix, arg))
return;
- die(ambiguous argument '%s': both revision and filename\n
- Use '--' to separate paths from revisions, like this:\n
- 'git command [revision...] -- [file...]', arg);
+ if (!preferred_action)
+ die(_(ambiguous argument '%s': both revision and filename\n
+ Use '--' to separate paths from revisions, like this:\n
+ 'git command [revision...] -- [file...]'), arg);
+ else {
+ warning(_(ambiguous argument '%s': both revision and
filename\n
+ Use '--' to separate paths from revisions, like
this:\n
+ 'git command [revision...] -- [file...]'),
arg);
+ warning(%s, preferred_action);
+ }
+}
+
+void verify_non_filename(const char *prefix, const char *arg)
+{
+ verify_non_filename_gently(prefix, arg, NULL);
}
/*
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] branch: introduce --set-upstream-to
Ralf Thielow ralf.thie...@gmail.com writes: On Thu, Aug 30, 2012 at 7:23 PM, Carlos Martín Nieto c...@elego.de wrote: behaviour. To work around this, introduce --set-upstream-to which accepts a compulsory argument indicating what the new upstream branch should be and one optinal argument indicating which branch to change, defaulting to HEAD. Could you please also add this new option to the contrib/completion/git-completion.bash script? If I knew how those things work... Is this enough? cmn --8-- Subject: [PATCH] completion: add --set-upstream-to and --unset-upstream --- contrib/completion/git-completion.bash | 1 + 1 file changed, 1 insertion(+) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index ffedce7..4f46357 100644 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -880,6 +880,7 @@ _git_branch () --color --no-color --verbose --abbrev= --no-abbrev --track --no-track --contains --merged --no-merged --set-upstream --edit-description --list + --unset-upstream --set-upstream-to= ;; *) -- 1.7.12.3.g0dd8ef6 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] branch: introduce --set-upstream-to
On Fri, Aug 31, 2012 at 5:22 PM, Carlos Martín Nieto c...@elego.de wrote: Ralf Thielow ralf.thie...@gmail.com writes: On Thu, Aug 30, 2012 at 7:23 PM, Carlos Martín Nieto c...@elego.de wrote: behaviour. To work around this, introduce --set-upstream-to which accepts a compulsory argument indicating what the new upstream branch should be and one optinal argument indicating which branch to change, defaulting to HEAD. Could you please also add this new option to the contrib/completion/git-completion.bash script? If I knew how those things work... Is this enough? Yes, Thanks. cmn --8-- Subject: [PATCH] completion: add --set-upstream-to and --unset-upstream --- contrib/completion/git-completion.bash | 1 + 1 file changed, 1 insertion(+) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index ffedce7..4f46357 100644 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -880,6 +880,7 @@ _git_branch () --color --no-color --verbose --abbrev= --no-abbrev --track --no-track --contains --merged --no-merged --set-upstream --edit-description --list + --unset-upstream --set-upstream-to= ;; *) -- 1.7.12.3.g0dd8ef6 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] merge-base: --is-ancestor A B
(Resending as plain text, sorry about duplicate, Junio.) On Thu, Aug 30, 2012 at 4:13 PM, Junio C Hamano gits...@pobox.com wrote: In many scripted Porcelain commands, we find this idiom: if test $(git rev-parse --verify A) = $(git merge-base A B) then ... A is an ancestor of B ... fi But you do not have to compute exact merge-base only to see if A is an ancestor of B. Give them a more direct way to use the underlying machinery. Thanks! It has bugged me ever since I first saw that idiom that there was no way that better shows the intent. + if (argc != 2) + die(--is-ancestor takes exactly two commits); I think git merge-base shows the usage message regardless if argc 2, so this only happens when more than two arguments are given. Maybe include --is-ancestor in the usage message? + if (is_ancestor (show_all | octopus | reduce)) + die(--is-reachable cannot be used with other options); I suppose --is-reachable should be --is-ancestor. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/4] wincred: port to generic credential helper (UNTESTED)
On Thu, Aug 30, 2012 at 8:27 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Mon, Aug 27, 2012 at 12:04 AM, Philipp A. Hartmann p...@qo.cx wrote:
From: Philipp A. Hartmann p...@qo.cx
This patch is an experiment to port the wincred helper
to the generic implementation. As of know, it is
completely untested.
In addition to porting the helper to the generic API,
this patch clears up all passwords from memory, which
reduces the total amount to saved lines.
Signed-off-by: Philipp A. Hartmann p...@qo.cx
---
The porting was fairly easy, but due to the lack of a testing
platform, it is completely untested.
Erik: Can you try to have look?
Sorry for the late reply, I'm currently in bed with pneumonia.
But I gave it a quick go, but as-is it's a NACK; a wall of warnings and
errors.
But with this patch on top, it seems to at least compile OK:
---8---
diff --git a/contrib/credential/helper/credential_helper.h
b/contrib/credential/helper/credential_helper.h
index 7e73fc6..13b611e 100644
--- a/contrib/credential/helper/credential_helper.h
+++ b/contrib/credential/helper/credential_helper.h
@@ -125,6 +125,7 @@ static inline char *xstrdup(const char *str)
return ret;
}
+#ifndef NO_STRNDUP
static inline char *xstrndup(const char *str, size_t len)
{
char *ret = strndup(str,len);
@@ -133,5 +134,6 @@ static inline char *xstrndup(const char *str, size_t len)
return ret;
}
+#endif
#endif /* CREDENTIAL_HELPER_H_INCLUDED_ */
diff --git a/contrib/credential/wincred/Makefile
b/contrib/credential/wincred/Makefile
index ee7a8ef..3900322 100644
--- a/contrib/credential/wincred/Makefile
+++ b/contrib/credential/wincred/Makefile
@@ -1,9 +1,10 @@
MAIN:=git-credential-wincred
-all:: $(MAIN)
+all:: $(MAIN).exe
CC = gcc
RM = rm -f
CFLAGS = -O2 -Wall
+CPPFLAGS = -DNO_STRNDUP
-include ../../../config.mak.autogen
-include ../../../config.mak
diff --git a/contrib/credential/wincred/git-credential-wincred.c
b/contrib/credential/wincred/git-credential-wincred.c
index 721e59f..e26ba47 100644
--- a/contrib/credential/wincred/git-credential-wincred.c
+++ b/contrib/credential/wincred/git-credential-wincred.c
@@ -6,6 +6,7 @@
#include stdio.h
#include io.h
#include fcntl.h
+#include credential_helper.h
/* MinGW doesn't have wincred.h, so we need to define stuff */
@@ -124,9 +125,8 @@ static int prepare_credential(struct credential *c)
wusername = utf8_to_utf16_dup(c-username);
if (c-password)
wpassword = utf8_to_utf16_dup(c-password);
- if (c-port) {
- snprintf(port_buf,%hd,c-port);
- }
+ if (c-port)
+ snprintf(port_buf, sizeof(port_buf), %hd, c-port);
return EXIT_SUCCESS;
}
@@ -170,7 +170,7 @@ static int get_credential(struct credential *c)
/* search for the first credential that matches username */
for (i = 0; i num_creds; ++i)
- if (match_cred(creds[i])) {
+ if (match_cred(creds[i], c)) {
cred = creds[i];
break;
}
---8---
However, I haven't been able to successfully run the tests on the
result. When I did, I got this error:
---8---
rm: cannot remove `t/trash directory.t0303-credential-external/stderr':
Permissi
on denied
rm: cannot remove `t/trash directory.t0303-credential-external/stdout':
Permissi
on denied
rm: cannot remove directory `t/trash directory.t0303-credential-external':
Direc
tory not empty
---8---
And I'm not currently feeling up to debugging stuck processes or whatever it
is.
OK, that was due to a stuck process, and after killing it I got to
test properly. However, three tests fail now:
$ (cd t GIT_TEST_CREDENTIAL_HELPER=wincred ./t0303-credential-external.sh)
ok 1 - helper (wincred) has no existing data
ok 2 - helper (wincred) stores password
not ok - 3 helper (wincred) can retrieve password
#
# check fill $HELPER -\EOF
# protocol=https
# host=example.com
# --
# protocol=https
# host=example.com
# username=store-user
# password=store-pass
# --
# EOF
#
ok 4 - helper (wincred) requires matching protocol
ok 5 - helper (wincred) requires matching host
ok 6 - helper (wincred) requires matching username
ok 7 - helper (wincred) requires matching path
ok 8 - helper (wincred) can forget host
not ok - 9 helper (wincred) can store multiple users
#
# check approve $HELPER -\EOF
# protocol=https
# host=example.com
# username=user1
# password=pass1
# EOF
# check approve $HELPER -\EOF
#
Re: GC of alternate object store
On Thu, Aug 30, 2012 at 09:03:34AM -0700, Junio C Hamano wrote: Oswald Buddenhagen o...@kde.org writes: Doesn't git push $over_there 'refs/*:refs/remotes/mine/*' push your tag v1.0 to refs/remotes/mine/v1.0 over there? The version of git I ship seems to do this just fine. as i wrote before, i'm pulling, not pushing,... You would need to decline the automatic tag following with --no-tags (which in hindsight is misnamed; it really means do not auto-follow tags), like so: cd $over_there git fetch --no-tags $my_repository 'refs/*:refs/remotes/mine/*' Otherwise, you will also get tags in refs/tags/. git seems to be happily ignoring that flag. git fetch --prune --all --no-tags still re-populates the tags after i delete them manually. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] branch: introduce --set-upstream-to
Ralf Thielow ralf.thie...@gmail.com writes: On Fri, Aug 31, 2012 at 5:22 PM, Carlos Martín Nieto c...@elego.de wrote: Ralf Thielow ralf.thie...@gmail.com writes: On Thu, Aug 30, 2012 at 7:23 PM, Carlos Martín Nieto c...@elego.de wrote: behaviour. To work around this, introduce --set-upstream-to which accepts a compulsory argument indicating what the new upstream branch should be and one optinal argument indicating which branch to change, defaulting to HEAD. Could you please also add this new option to the contrib/completion/git-completion.bash script? If I knew how those things work... Is this enough? Yes, Thanks. While you are at it, perhaps you may want to unadvertise --set-upstream? cmn --8-- Subject: [PATCH] completion: add --set-upstream-to and --unset-upstream --- contrib/completion/git-completion.bash | 1 + 1 file changed, 1 insertion(+) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index ffedce7..4f46357 100644 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -880,6 +880,7 @@ _git_branch () --color --no-color --verbose --abbrev= --no-abbrev --track --no-track --contains --merged --no-merged --set-upstream --edit-description --list + --unset-upstream --set-upstream-to= ;; *) -- 1.7.12.3.g0dd8ef6 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
rev-parse -q --verify with not existent upstream branch
Documentation to git-rev-parse claims that
-q, --quiet
Only meaningful in --verify mode. Do not output an error
message if the first argument is not a valid object name; instead exit
with non-zero status silently.
However when I try to check if the current branch has a configured
upstream one with:
git rev-parse -q --verify '@{u}'
I still receives the error message:
error: No upstream configured for branch 'threading'
Additinally withour -q --verify options the error message is printed
twice:
error: No upstream configured for branch 'threading'
@{u}
error: No upstream configured for branch 'threading'
fatal: ambiguous argument '@{u}': unknown revision or path not in the
working tree.
Use '--' to separate paths from revision
--
Kacper
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] merge-base: --is-ancestor A B
Martin von Zweigbergk martinv...@gmail.com writes:
+ if (argc != 2)
+ die(--is-ancestor takes exactly two commits);
I think git merge-base shows the usage message regardless if argc 2,
so this only happens when more than two arguments are given.
Yes, but it is a good discipline not to depend too much on what
other parts of the code may have done, when you do not have to.
Maybe
include --is-ancestor in the usage message?
I think merge-base -h will get this for free thanks to parseopt.
+ if (is_ancestor (show_all | octopus | reduce))
+ die(--is-reachable cannot be used with other options);
I suppose --is-reachable should be --is-ancestor.
Thanks, that was a renaming error.
I'll squash the fix in with documentation.
Documentation/git-merge-base.txt | 28
builtin/merge-base.c | 6 +++---
2 files changed, 31 insertions(+), 3 deletions(-)
diff --git i/Documentation/git-merge-base.txt w/Documentation/git-merge-base.txt
index b295bf8..87842e3 100644
--- i/Documentation/git-merge-base.txt
+++ w/Documentation/git-merge-base.txt
@@ -11,6 +11,7 @@ SYNOPSIS
[verse]
'git merge-base' [-a|--all] commit commit...
'git merge-base' [-a|--all] --octopus commit...
+'git merge-base' --is-ancestor commit commit
'git merge-base' --independent commit...
DESCRIPTION
@@ -50,6 +51,12 @@ from linkgit:git-show-branch[1] when used with the
`--merge-base` option.
from any other. This mimics the behavior of 'git show-branch
--independent'.
+--is-ancestor::
+ Check if the first commit is an ancestor of the second commit,
+ and exit with status 0 if true, or with status 1 if not.
+ Errors are signaled by a non-zero status that is not 1.
+
+
OPTIONS
---
-a::
@@ -110,6 +117,27 @@ both '1' and '2' are merge-bases of A and B. Neither one
is better than
the other (both are 'best' merge bases). When the `--all` option is not given,
it is unspecified which best one is output.
+A common idiom to check fast-forward-ness between two commits A
+and B is (or at least used to be) to compute the merge base between
+A and B, and check if it is the same as A, in which case, A is an
+ancestor of B. You will see this idiom used often in older scripts.
+
+ A=$(git rev-parse --verify A)
+ if test $A = $(git merge-base A B)
+ then
+ ... A is an ancestor of B ...
+ fi
+
+In modern git, you can say this in a more direct way:
+
+ if git merge-base --is-ancestor A B
+ then
+ ... A is an ancestor of B ...
+ fi
+
+instead.
+
+
See also
linkgit:git-rev-list[1],
diff --git i/builtin/merge-base.c w/builtin/merge-base.c
index 615aa04..447ab7c 100644
--- i/builtin/merge-base.c
+++ w/builtin/merge-base.c
@@ -70,7 +70,7 @@ static int handle_octopus(int count, const char **args, int
reduce, int show_all
return 0;
}
-static int show_is_ancestor(int argc, const char **argv)
+static int handle_is_ancestor(int argc, const char **argv)
{
struct commit *one, *two;
@@ -107,9 +107,9 @@ int cmd_merge_base(int argc, const char **argv, const char
*prefix)
if (!octopus !reduce argc 2)
usage_with_options(merge_base_usage, options);
if (is_ancestor (show_all | octopus | reduce))
- die(--is-reachable cannot be used with other options);
+ die(--is-ancestor cannot be used with other options);
if (is_ancestor)
- return show_is_ancestor(argc, argv);
+ return handle_is_ancestor(argc, argv);
if (reduce (show_all || octopus))
die(--independent cannot be used with other options);
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Aw: Re: git blame shows wrong Not commited yet entries
Thomas Ackermann th.acke...@arcor.de writes: The man-page for git-config says: core.ignorecase If true, this option enables various workarounds to enable git to work better on filesystems that are not case sensitive, like FAT. For example, if a directory listing finds makefile when git expects Makefile, git will assume it is really the same file, and continue to remember it as Makefile. So various workarounds does _not_ mean that _all_ filenames are processed modulo upper/lower case, or? Keywords in that paragraph include various (not all) and better (not perfectly), and the most important one is when git expects. When running git add file.txt with File.txt in the index, git expects File.txt, but the ignorecase logic makes git assume they are the same, and add content from file.txt as File.txt. And git blame $path probably should expect $path is something that appear in the tree of HEAD; apparently it does not. Patches welcome. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: (minor concern) git using the pager should not be a default
Junio C Hamano gits...@pobox.com writes: In other words, Porcelain (roughly speaking, those that page by default when their standard output is terminal), are not command line applications; they have a layer on top with a built-in UI. Is status considered a plumbing layer command? Because I have often wondered why it does not use the pager by default. I pipe it through less all the time and it's kind of annoying that it works differently than everything else. -Dave -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] t9164: More style fixes
Robert Luberda rob...@debian.org writes:
Make sure t9164 conforms with the coding guidelines:
- remove spaces after redirection operators;
- insert spaces between function names and parentheses;
- split `if ...; then' lines;
- use `test' instead of `['.
Signed-off-by: Robert Luberda rob...@debian.org
---
t/t9164-git-svn-dcommit-concurrent.sh | 69
-
1 file changed, 33 insertions(+), 36 deletions(-)
Interesting.
$ git log --oneline --stat -1 -- 't/t9164-*'
e48fb75 git svn: handle errors and concurrent commits in dcommit
t/t9164-git-svn-dcommit-concrrent.sh | 216 +++
1 file changed, 216 insertions(+)
I wonder where the typo in filename came from (notice the missing u)?
Perhaps the More in your subject implies there were some earlier
patches I haven't seen? The patch does not seem to apply to my tree
even with the target file renamed.
diff --git a/t/t9164-git-svn-dcommit-concurrent.sh
b/t/t9164-git-svn-dcommit-concurrent.sh
index d8464d4..d75ebdc 100755
--- a/t/t9164-git-svn-dcommit-concurrent.sh
+++ b/t/t9164-git-svn-dcommit-concurrent.sh
@@ -12,16 +12,15 @@ test_expect_success 'setup svn repository' '
svn_cmd checkout $svnrepo work.svn
(
cd work.svn
- echo file echo auto_updated_file
+ echo file echo auto_updated_file
svn_cmd add file auto_updated_file
svn_cmd commit -m initial commit
)
svn_cmd checkout $svnrepo work-auto-commits.svn
'
N=0
-next_N()
-{
- N=$(( $N + 1 ))
+next_N () {
+ N=$(($N + 1))
}
# Setup SVN repository hooks to emulate SVN failures or concurrent commits
@@ -35,39 +34,39 @@ next_N()
# the hook should be applied for (each time the hook is run, the given
# number is decreased by one until it gets 0, in which case the hook
# will execute its real action)
-setup_hook()
-{
+setup_hook () {
hook_type=$1 # pre-commit or post-commit
skip_revs=$2
- [ $hook_type = pre-commit ] ||
- [ $hook_type = post-commit ] ||
+ test $hook_type = pre-commit ||
+ test $hook_type = post-commit ||
{ echo ERROR: invalid argument ($hook_type) \
passed to setup_hook 2 ; return 1; }
- echo cnt=$skip_revs $hook_type-counter
+ echo cnt=$skip_revs $hook_type-counter
rm -f $rawsvnrepo/hooks/*-commit # drop previous hooks
hook=$rawsvnrepo/hooks/$hook_type
- cat $hook - 'EOF1'
+ cat $hook -'EOF1'
#!/bin/sh
set -e
cd $1/.. # $1 is repository location
- exec svn-hook.log 21
+ exec svn-hook.log 21
hook=$(basename $0)
echo *** Executing $hook $@
set -x
- . ./$hook-counter
+ . ./$hook-counter
cnt=$(($cnt - 1))
- echo cnt=$cnt ./$hook-counter
- [ $cnt = 0 ] || exit 0
+ echo cnt=$cnt ./$hook-counter
+ test $cnt = 0 || exit 0
EOF1
- if [ $hook_type = pre-commit ]; then
+ if test $hook_type = pre-commit
+ then
echo echo 'commit disallowed' 2; exit 1 $hook
else
echo PATH=\$PATH\; export PATH $hook
echo svnconf=\$svnconf\ $hook
- cat $hook - 'EOF2'
+ cat $hook -'EOF2'
cd work-auto-commits.svn
svn up --config-dir $svnconf
- echo $$ auto_updated_file
+ echo $$ auto_updated_file
svn commit --config-dir $svnconf \
-m auto-committing concurrent change
exit 0
@@ -76,8 +75,7 @@ EOF2
chmod 755 $hook
}
-check_contents()
-{
+check_contents () {
gitdir=$1
(cd ../work.svn svn_cmd up)
test_cmp file ../work.svn/file
@@ -89,7 +87,7 @@ test_expect_success 'check if post-commit hook creates a
concurrent commit' '
(
cd work.svn
cp auto_updated_file au_file_saved
- echo 1 file
+ echo 1 file
svn_cmd commit -m changing file
svn_cmd up
test_must_fail test_cmp auto_updated_file au_file_saved
@@ -100,9 +98,9 @@ test_expect_success 'check if pre-commit hook fails' '
setup_hook pre-commit 2
(
cd work.svn
- echo 2 file
+ echo 2 file
svn_cmd commit -m changing file once again
- echo 3 file
+ echo 3 file
test_must_fail svn_cmd commit -m this commit should fail
svn_cmd revert file
)
@@ -113,9 +111,9 @@ test_expect_success 'dcommit error handling' '
next_N git svn clone $svnrepo work$N.git
(
cd work$N.git
-
Re: (minor concern) git using the pager should not be a default
d...@cray.com writes: Is status considered a plumbing layer command? Because I have often wondered why it does not use the pager by default. I pipe it through less all the time and it's kind of annoying that it works differently than everything else. I would be pretty annoyed if git status would page by default. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] checkout: warn users if action is taken in ambiguous situation
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: git checkout foo (no more arguments) always checks out existing branch foo even if foo exists on working directory. To avoid confusion to users who do not know this exception, say something along the action. I do not think the extra noise Checked out the new branch. your patch adds is necessary: $ git checkout master Already on 'master' $ next $ git checkout next Switched to branch 'next' If the user wanted to grab the contents from the index for path 'next' and deposit it to the file 'next' in the working tree, we are already telling the user that that is not what happened. Even though I agree with you that it is a good goal to help users who want to disambiguate between branch and path differently from what the annoyance avoidance does, I do not think butchering the annoyance avoidance in parse_branchname_arg() is the right way to do so. I wouldn't mind if the above interaction went like this: $ git checkout next Switched to branch 'next' hint: if you meant to check out the contents of 'next' out of hint: the index to the file 'next' in your working tree, say hint: git checkout -- next instead. To squelch this advice, hint: git config set advice.checkoutWarnFileAndBranchName false. This should trigger only when the advice is not set (or set to true), and only when you have 'next' in the index. Presense or absense of 'next' in the working tree should not make a difference. And doing it that way covers anoter valid case in which the user would want the exact same help from Git that your patch would not cover: $ git branch Makefile $ git checkout master Already on 'master' $ rm Makefile $ git checkout Makefile D Makefile Switched to branch 'Makefile' Another thing to look out for is this case: $ git branch Makefile master $ git checkout next Already on 'next' $ rm Makefile $ echo archive.c ;# different between master and next $ git checkout Makefile error: Your local changes to the following files would be overwritten by checkout: archive.c Please, commit your changes or stash them before you can switch branches. Aborting We would want the exact same hint (with the obvious s/next/Makefile/) after the above output. Just for a reference, with your patch, I think the output would like this (I didn't apply nor run it): $ git checkout Makefile warning: ambiguous argument 'Makefile': both revision and filename Use '--' to separate paths from revisions, like this: 'git command [reviosion] -- [file...]' warning: checked out the new branch. error: Your local changes... archive.c Please, commit your ... Aborting which would be far worse and confusing. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] merge-base: --is-ancestor A B
Martin von Zweigbergk martinv...@gmail.com writes: On Fri, Aug 31, 2012 at 10:25 AM, Junio C Hamano gits...@pobox.com wrote: ... I think merge-base -h will get this for free thanks to parseopt. It seems not, or maybe I'm using the wrong terminology; I meant to include it in the first part of the below. usage: git merge-base [-a|--all] commit commit... or: git merge-base [-a|--all] --octopus commit... or: git merge-base --independent commit... -a, --all output all common ancestors --octopus find ancestors for a single n-way merge --independent list revs not reachable from others --is-ancestor is the first one ancestor of the other? Ahh. As most of the modern parse-optified ones just say git cmd args or something like that, I wasn't paying attention to the upper part. Will amend again. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GC of alternate object store
On Fri, Aug 31, 2012 at 12:26 PM, Oswald Buddenhagen o...@kde.org wrote: On Thu, Aug 30, 2012 at 09:03:34AM -0700, Junio C Hamano wrote: Oswald Buddenhagen o...@kde.org writes: Doesn't git push $over_there 'refs/*:refs/remotes/mine/*' push your tag v1.0 to refs/remotes/mine/v1.0 over there? The version of git I ship seems to do this just fine. as i wrote before, i'm pulling, not pushing,... You would need to decline the automatic tag following with --no-tags (which in hindsight is misnamed; it really means do not auto-follow tags), like so: cd $over_there git fetch --no-tags $my_repository 'refs/*:refs/remotes/mine/*' Otherwise, you will also get tags in refs/tags/. git seems to be happily ignoring that flag. git fetch --prune --all --no-tags still re-populates the tags after i delete them manually. I believe that is bad interaction with --all (probably a bug). If I am remembering correctly, --no-tags is internally a per-remote setting, so I'm guessing it's not getting set on all remotes here. I'll look into this more a bit later tonight. Does fetch --no-tags work when you specify a remote? -- -Dan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GC of alternate object store
Dan Johnson computerdr...@gmail.com writes: I believe that is bad interaction with --all (probably a bug). If I am remembering correctly, --no-tags is internally a per-remote setting, so I'm guessing it's not getting set on all remotes here. I'll look into this more a bit later tonight. Does fetch --no-tags work when you specify a remote? Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] Thunderbird: fix appp.sh format problems
Marco Stornelli marco.storne...@gmail.com writes:
+PATCHTMP=${PATCH}.tmp
+
+echo $MAILHEADER $PATCHTMP
+
+export PATCHTMP
+CCS=`perl -e 'local $/=undef; open FILE, $ENV{'PATCHTMP'}; $text=FILE;
+close FILE; $addr = $1 if $text =~ /Cc: (.*?(,\n .*?)*)\n/s; $addr =~
s/\n//g;
+print $addr;'`
+
+TO=`perl -e 'local $/=undef; open FILE, $ENV{'PATCHTMP'}; $text=FILE;
+close FILE; $addr = $1 if $text =~ /To: (.*?(,\n .*?)*)\n/s; $addr =~
s/\n//g;
+print $addr;'`
-CCS=`echo -e $CMT_MSG\n$HEADERS | sed -n -e 's/^Cc: \(.*\)$/\1,/gp' \
- -e 's/^Signed-off-by: \(.*\)/\1,/gp'`
+rm -rf $PATCHTMP
One thing I forgot to say. Make sure you quote your variables (when
in doubt, quote). Also make it a habit not to say rm -r when you
know you are removing a regular file you created. I.e.
rm -f $PATCHTMP
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i18n: mark more index-pack strings for translation
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- The main string I'm after is completed with %d local objects, which is part of typical UI. The rest is just while at there... To my surprise, (GNU) gettext does seem to know how to deal with PRIu32 macro in the middle of the string. ;-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] Thunderbird: fix appp.sh format problems
Am 31.08.2012 16:09, schrieb Marco Stornelli:
+CCS=`perl -e 'local $/=undef; open FILE, $ENV{'PATCHTMP'}; $text=FILE;
+close FILE; $addr = $1 if $text =~ /Cc: (.*?(,\n .*?)*)\n/s; $addr =~
s/\n//g;
+print $addr;'`
The quoting is broken in this line (sq within sq does not work).
Am I correct that you intend to treat continuation lines with this
non-trivial perl script? All this processing gets tedious and
unreadable. Let me suggest this pattern instead:
# translate to Thunderbird language
LANG_TO=To:
LANG_SUBJ=Subject:
LANG_CC=Cc:
LF= # terminates the _previous_ line
while read -r line
do
case $line in
'To: '*)
printf ${LF}%s $LANG_TO ${line#To: }
;;
'Cc: '*) ...similar...
'Subject: '*) ...similar...
' '*) # continuation line
printf %s $line
;;
'')
print ${LF}\n
cat
;;
esac
LF='\n'
done $PATCH $1
Instead of printing right away, you can also accumulate the data in
variables and print them right before the 'cat'. I would do that only if
a particular order of To:, Cc:, and Subject: is required in the output.
(I don't know how the do not delete this line line fits in the
picture, but I'm sure you can figure it out.)
-- Hannes
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: (minor concern) git using the pager should not be a default
On Fri, Aug 31, 2012 at 08:09:34PM +0200, Andreas Schwab wrote: d...@cray.com writes: Is status considered a plumbing layer command? Because I have often wondered why it does not use the pager by default. I pipe it through less all the time and it's kind of annoying that it works differently than everything else. I would be pretty annoyed if git status would page by default. This one has been debated for a while. People used to complain that it did not page, and then we turned on the pager, and then people complained that it did page. I wrote 4e10738 (Allow per-command pager config, 2008-07-03) to help settle it, and now you can do: git config pager.status true if you really want it. As of 9bad723 (allow command-specific pagers in pager.cmd, 2010-11-17), you can even set it to an arbitrary pager for each git command. With all those options, it's amazing that we can still have threads about what should page. :) -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: (minor concern) git using the pager should not be a default
Jeff King p...@peff.net writes: if you really want it. As of 9bad723 (allow command-specific pagers in pager.cmd, 2010-11-17), you can even set it to an arbitrary pager for each git command. Cool! With all those options, it's amazing that we can still have threads about what should page. :) Well to be fair, it's hard to know when to read the documentation again. :) -Dave -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Grafting Alternate History
I have an unfortunate situation where I have two subversion repositories for the same project, one a public version and one a private version. Because they are mirrors of svn repositories, they have very different histories as far as git is concerned. This is not all that uncommon but of course I would like to manage things in git. git-svn is great for interacting with one svn repository. The public svn repository has a fully-supported git mirror. The private repository also has a fully-supported git mirror. But I need to check in changes to the private repository via git-svn. I eventually need to check in changes to the public repository as well but that is orders of magnitude less frequent. A manual diff+patch+git-svn is acceptable for now. I am wondering if it's possible to graft the history of one of the git mirrors onto an empty branch of the other and share changes between them. I need to take updates from the public repository and apply them to the private repository. This is a frequent operation. I have been essentially using manual diff+patch but that is highly error-prone and annoying. For example, let's say we take a local copy of the private repository. I would like to somehow create an empty branch in that local copy and then populate it with the history of the public repository. I would like to be able to specify a git diff-like command on the public graft branch to get some changes over a range of commits and apply those changes to one of the private branches (say master). If I could use a git-merge-like or git-rebase-like command, so much the better. I would like to do the same in reverse but as I said that is a much less common operation. Has anyone done anything like this before? Is it even theoretically possible to manage disjoint histories like this? Thanks for your help! -Dave -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] fetch --all: pass --tags/--no-tags through to each remote
Reported-by: Oswald Buddenhagen o...@kde.org Signed-off-by: Dan Johnson computerdr...@gmail.com --- Junio C Hamano gits...@pobox.com writes: Dan Johnson computerdr...@gmail.com writes: I believe that is bad interaction with --all (probably a bug). If I am remembering correctly, --no-tags is internally a per-remote setting, so I'm guessing it's not getting set on all remotes here. I'll look into this more a bit later tonight. Does fetch --no-tags work when you specify a remote? Thanks. And here it is. Apparently we just don't pass those options through. I didn't look to see if there are any other options we should consider passing through; it's quite possible there are. I also have not written a test to ensure that this doesn't break in the future. I will hopefully have time for these things tomorrow. It's getting too late for me to be able to put sentences together, so hopefully this mail comes out readable ;) builtin/fetch.c | 4 1 file changed, 4 insertions(+) diff --git a/builtin/fetch.c b/builtin/fetch.c index bb9a074..c6bcbdc 100644 --- a/builtin/fetch.c +++ b/builtin/fetch.c @@ -857,6 +857,10 @@ static void add_options_to_argv(int *argc, const char **argv) argv[(*argc)++] = --recurse-submodules; else if (recurse_submodules == RECURSE_SUBMODULES_ON_DEMAND) argv[(*argc)++] = --recurse-submodules=on-demand; + if (tags == TAGS_SET) + argv[(*argc)++] = --tags; + else if (tags == TAGS_UNSET) + argv[(*argc)++] = --no-tags; if (verbosity = 2) argv[(*argc)++] = -v; if (verbosity = 1) -- 1.7.11.1.59.gbc9e7dd.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
