Re: [ANNOUNCE] Git v2.0.0-rc4
Felipe Contreras writes: > Junio C Hamano wrote: > >> * The remote-helper interface to fast-import/fast-export via the >>transport-helper has been tightened to avoid leaving the import >>marks file from a failed/crashed run, as such a file that is out-of- >>sync with reality confuses a later invocation of itself. > > Really? Where are the patches for that? The following seems related: commit 10e1feebb454d99eb6644cc53b94255f40e6fe9c Author: Junio C Hamano Date: Wed May 14 12:06:35 2014 -0700 Revert "Merge branch 'fc/transport-helper-sync-error-fix'" This reverts commit d508e4a8e2391ae2596403b6478d01cf3d5f928f, reversing changes made to e42552135a2a396f37053a89f44952ea907870b2. The author of the original topic says he broke the upcoming 2.0 release with something that relates to "synchronization crash regression" while refusing to give further specifics, so this would unfortunately be the safest option for the upcoming release. Signed-off-by: Junio C Hamano -- David Kastrup -- 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
Good Day.
Good day. I am Elizabeth Sakura, a staff of Lloyds TSB Group Plc.here in Hong Kong. I will need you to assist me in executing a business project from Hong Kong to your country.Contact me Email address( tseselizabeth...@yahoo.com ) for more information.Regards,Mrs.Sukura Elizabeth tse -- 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] t6006-*.sh: Fix truncation tests
On Tue, May 20, 2014 at 10:10:46AM -0700, Junio C Hamano wrote: > Alexey Shumkin writes: > > > AFAIU, Junio already applied my patches (existance of a branch > > as/pretty-truncate tells us that). So, we can only send other patches that > > fix errors brought with former patches. > > No, NO, NO > > The existence of a branch merely means that I saw the patches, and > that I thought that the series was not completely useless. In other > words, it indicates that I wanted to make sure that I won't forget > about the topic, and it was worth my time to create the branch and > apply there for that purpose. Oh, I got it! I'll fix my typo (ISO8895-1 vs ISO8859-1) and quotes issue then. And will reroll patches. Thanks! > > Please do not read anything more than that. Presense of a topic > branch by itself does not say that I _read_ the patches or I thought > they did not need reroll. > > When such a branch is merged to 'next', that means I read the > patches myself, or I saw somebody whose judgement I and others in > the community trust read them and gave a positive response or an > Ack, and that I decided that the topic is in a good enough shape to > be worked on further with incremental updates. > > You are talking about the latter state, but as/pretty-truncate is in > the former state. -- 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 v6] format-patch --signature-file
Added option that allows a signature file to be used with format-patch
so that signatures with newlines and other special characters can be
easily included.
$ git format-patch --signature-file ~/.signature -1
The config variable format.signaturefile is also provided so that it
can be added by default.
$ git config format.signaturefile ~/.signature
$ git format-patch -1
Signed-off-by: Jeremiah Mahler
---
Documentation/config.txt | 4
Documentation/git-format-patch.txt | 4
builtin/log.c | 16
t/t4014-format-patch.sh| 32
4 files changed, 56 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1932e9b..140ed77 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1114,6 +1114,10 @@ format.signature::
Set this variable to the empty string ("") to suppress
signature generation.
+format.signaturefile::
+ Works just like format.signature except the contents of the
+ file specified by this variable will be used as the signature.
+
format.suffix::
The default for format-patch is to output files with the suffix
`.patch`. Use this variable to change that suffix (make sure to
diff --git a/Documentation/git-format-patch.txt
b/Documentation/git-format-patch.txt
index 5c0a4ab..c0fd470 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -14,6 +14,7 @@ SYNOPSIS
[(--attach|--inline)[=] | --no-attach]
[-s | --signoff]
[--signature= | --no-signature]
+ [--signature-file=]
[-n | --numbered | -N | --no-numbered]
[--start-number ] [--numbered-files]
[--in-reply-to=Message-Id] [--suffix=.]
@@ -233,6 +234,9 @@ configuration options in linkgit:git-notes[1] to use this
workflow).
signature option is omitted the signature defaults to the Git version
number.
+--signature-file=::
+ Works just like --signature except the signature is read from a file.
+
--suffix=.::
Instead of using `.patch` as the suffix for generated
filenames, use specified suffix. A common alternative is
diff --git a/builtin/log.c b/builtin/log.c
index 39e8836..ab4718b 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -673,6 +673,7 @@ static void add_header(const char *value)
static int thread;
static int do_signoff;
static const char *signature = git_version_string;
+static const char *signature_file;
static int config_cover_letter;
enum {
@@ -742,6 +743,8 @@ static int git_format_config(const char *var, const char
*value, void *cb)
}
if (!strcmp(var, "format.signature"))
return git_config_string(&signature, var, value);
+ if (!strcmp(var, "format.signaturefile"))
+ return git_config_pathname(&signature_file, var, value);
if (!strcmp(var, "format.coverletter")) {
if (value && !strcasecmp(value, "auto")) {
config_cover_letter = COVER_AUTO;
@@ -1230,6 +1233,8 @@ int cmd_format_patch(int argc, const char **argv, const
char *prefix)
PARSE_OPT_OPTARG, thread_callback },
OPT_STRING(0, "signature", &signature, N_("signature"),
N_("add a signature")),
+ OPT_FILENAME(0, "signature-file", &signature_file,
+ N_("add a signature from a file")),
OPT__QUIET(&quiet, N_("don't print the patch filenames")),
OPT_END()
};
@@ -1447,6 +1452,17 @@ int cmd_format_patch(int argc, const char **argv, const
char *prefix)
cover_letter = (config_cover_letter == COVER_ON);
}
+ if (signature_file) {
+ if (signature && signature != git_version_string)
+ die(_("cannot specify both signature and
signature-file"));
+
+ struct strbuf buf = STRBUF_INIT;
+
+ if (strbuf_read_file(&buf, signature_file, 128) < 0)
+ die_errno(_("unable to read signature file '%s'"),
signature_file);
+ signature = strbuf_detach(&buf, NULL);
+ }
+
if (in_reply_to || thread || cover_letter)
rev.ref_message_ids = xcalloc(1, sizeof(struct string_list));
if (in_reply_to) {
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 9c80633..049493d 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -762,6 +762,38 @@ test_expect_success 'format-patch --signature=""
suppresses signatures' '
! grep "^-- \$" output
'
+cat >expect <<-\EOF
+
+Test User
+http://git.kernel.org/cgit/git/git.git
+
+git.kernel.org/?p=git/git.git;a=summary
+
+EOF
+
+test_expect_success 'format-patch --signature-file=file' '
+ git format-patch --stdo
[PATCH v6] format-patch --signature-file
v6 of patch to add format-patch --signature-file option. This revision includes more suggestions from Jeff King and Junio C Hamano: - Adding #define DEFAULT_SIGNATURE was a good idea but it could be used in a way that nullifies the pointer comparison used to see if the default has changed. So this was removed. - The test cases depend on there being two blank lines after a signature from a file. This is an odd problem because if --signature or the default is used only one blank line is produced. This problem can be addressed in another patch. Jeremiah Mahler (1): format-patch --signature-file Documentation/config.txt | 4 Documentation/git-format-patch.txt | 4 builtin/log.c | 16 t/t4014-format-patch.sh| 32 4 files changed, 56 insertions(+) -- Jeremiah Mahler jmmah...@gmail.com http://github.com/jmahler -- 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 v8 29/44] refs.c: make lock_ref_sha1 static
Ronnie Sahlberg wrote: > No external callers reference lock_ref_sha1 any more so lets declare it > static. > > Signed-off-by: Ronnie Sahlberg > --- > refs.c | 2 +- > refs.h | 3 --- > 2 files changed, 1 insertion(+), 4 deletions(-) Reviewed-by: Jonathan Nieder -- 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 v8 28/44] refs.c: make write_ref_sha1 static
Ronnie Sahlberg wrote:
> No external users call write_ref_sha1 any more so lets declare it static.
Yay!
[...]
> +++ b/refs.c
> @@ -251,6 +251,8 @@ struct ref_entry {
[...]
> static void read_loose_refs(const char *dirname, struct ref_dir *dir);
> +static int write_ref_sha1(struct ref_lock *lock,
> + const unsigned char *sha1, const char *logmsg);
Is this forward declaration needed?
[...]
> --- a/refs.h
> +++ b/refs.h
> @@ -150,9 +150,6 @@ extern int commit_ref(struct ref_lock *lock);
> /** Release any lock taken but not written. **/
> extern void unlock_ref(struct ref_lock *lock);
>
> -/** Writes sha1 into the ref specified by the lock. **/
> -extern int write_ref_sha1(struct ref_lock *lock, const unsigned char *sha1,
> const char *msg);
(nit) Would be nice to keep the documentation comment.
Thanks,
Jonathan
--
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: [ANNOUNCE] Git v2.0.0-rc4
Junio C Hamano wrote: > * The remote-helper interface to fast-import/fast-export via the >transport-helper has been tightened to avoid leaving the import >marks file from a failed/crashed run, as such a file that is out-of- >sync with reality confuses a later invocation of itself. Really? Where are the patches for that? I think it's fair to say the way the remote-helpers and transport-helper has been handled for v2.0 has been a total disaster. -- Felipe Contreras -- 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 v8 27/44] walker.c: use ref transaction for ref updates
Ronnie Sahlberg wrote:
> This changes the locking slightly for walker_fetch. Previously the code would
> lock all refs before writing them but now we do not lock the refs until the
> commit stage. There is thus a very short window where changes could be done
> locally during the fetch which would be overwritten when the fetch completes
> and commits its transaction. But this window should be reasonably short.
> Even if this race does trigger, since both the old code and the new code
> just overwrites the refs to the new values without checking or comparing
> them with the previous value, this is not too dissimilar to a similar scenario
> where you first do a ref change locally and then later do a fetch that
> overwrites the local change. With this in mind I do not see the change in
> locking semantics to be critical.
Sounds scary. The usual approach is
old_sha1 = ...
... various checks ...
transaction = transaction_begin(&err)
transaction_update(transaction, refname, new_sha1, old_sha1, ...);
transaction_commit(transaction, &err);
which is not racy because _update checks against old_sha1.
If I understand correctly, you are saying 'have_old' is false here so
we don't have the usual protection. If the "... various checks ..."
section shown above is empty, that should be fine and there is no
actual change in semantics. If the "... various checks ..." section
shown above is nonempty then it could be a problem.
[...]
> --- a/walker.c
> +++ b/walker.c
> @@ -251,24 +251,18 @@ void walker_targets_free(int targets, char **target,
> const char **write_ref)
> int walker_fetch(struct walker *walker, int targets, char **target,
>const char **write_ref, const char *write_ref_log_details)
> {
> - struct ref_lock **lock = xcalloc(targets, sizeof(struct ref_lock *));
> + char ref_name[PATH_MAX];
We tend to prefer strbuf instead of fixed-size buffers in new code.
[...]
> - char *msg;
> + char *msg = NULL;
Needed? The existing code seems to set msg = NULL in the
!write_ref_log_details case already.
[...]
> @@ -294,19 +288,26 @@ int walker_fetch(struct walker *walker, int targets,
> char **target,
> for (i = 0; i < targets; i++) {
> if (!write_ref || !write_ref[i])
> continue;
> - ret = write_ref_sha1(lock[i], &sha1[20 * i], msg ? msg : "fetch
> (unknown)");
Okay, so before this patch we do:
for each target in write_ref:
lock it (with no particular expectation about where it
points)
Then
unless http-fetch was passed --recover:
mark the objects pointed to by current refs as COMPLETE
Then we do HTTP GETs to grab the objects we need from a "dumb" HTTP
server. The COMPLETE objects tell us about objects we don't have to
bother trying to get.
When we're done, we come up with a reflog entry and write out refs
pointing to the requested commits.
This code has two callers:
git-remote-http (aka remote-curl.c::fetch_dumb)
git-http-fetch (aka http-fetch.c)
The codepath in git-remote-http gets wide use, though it's diminishing
as more people switch to "smart" http. It doesn't 't use the "write
out some refs" feature. It just wants the objects and then takes care
of writing refs on its own.
Perhaps it's worth avoiding beginning a transaction in the first place
in the !write_ref case.
The git-http-fetch command is a piece of plumbing that used to be used
by 'git clone' and 'git fetch' in the olden days when they were shell
scripts. I doubt anyone uses it. As you noticed, it doesn't have any
way to specify anything about the expected old values of the refs it
writes to. So this change doesn't introduce any race there.
> + sprintf(ref_name, "refs/%s", write_ref[i]);
> + if (ref_transaction_update(transaction, ref_name,
> +&sha1[20 * i], NULL,
> +0, 0))
> + goto rollback_and_fail;
> + }
Looks good.
> +
> + if (ref_transaction_commit(transaction, msg ? msg : "fetch (unknown)",
> +&err)) {
> + error("%s", err.buf);
> + goto rollback_and_fail;
> }
Also looks good.
Thanks,
Jonathan
--
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] format-patch --signature-file
On Tue, May 20, 2014 at 08:06:50AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > You could do: > > > > #define DEFAULT_SIGNATURE git_version_string > > static const char *signature = DEFAULT_SIGNATURE; > > > > ... > > > > if (signature == DEFAULT_SIGNATURE) > > ... > > > > but maybe that is getting a little unwieldy, considering the scope of > > the original problem. > > I agree. It is an invitation for doing something like > > #define DEFAULT_SIGNATURE "-- \nfoo bar\n" > > which defeats the purpose. > > I have an unrelated and larger design level suggestion, but it may > be better for me to refrain from sending it during the -rc freeze. I will take DEFAULT_SIGNATURE out of the next patch revision. -- Jeremiah Mahler jmmah...@gmail.com http://github.com/jmahler -- 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 v5] format-patch --signature-file
On Tue, May 20, 2014 at 04:27:40AM -0400, Jeff King wrote:
> On Tue, May 20, 2014 at 01:00:06AM -0700, Jeremiah Mahler wrote:
>
...
> > +test_expect_success 'format-patch --signature-file=file' '
> > + git format-patch --stdout --signature-file=expect -1 >output &&
> > + check_patch output &&
> > + sed -n -e "/^-- $/,\$p" > "\$d" >output2 &&
> > + test_cmp expect output2
> > +'
>
> Here we drop two final lines from the email output. But if I just use
> vanilla git and try this, I get nothing:
>
> $ git format-patch -1 --stdout |
> sed -n -e "/^-- $/,\$p" | sed -e "1 d" | sed -e "\$d" | sed -e "\$d"
>
> Removing the second dropped line works:
>
> $ git format-patch -1 --stdout |
> sed -n -e "/^-- $/,\$p" | sed -e "1 d" | sed -e "\$d"
> 2.0.0.rc1.436.g03cb729
>
> I guess the signature code is adding its own newline, so that the
> default signature (or "--signature=foo") works. But it adds it
> unconditionally, which is probably not what we want for signatures read
> from a file.
>
> Do we maybe want something like this right before your patch?
>
> -- >8 --
> Subject: format-patch: make newline after signature conditional
>
> When we print an email signature, we print the divider "--
> \n", then the signature string, then two newlines.
> Traditionally the signature is a one-liner (and the default
> is just the git version), so the extra newline makes sense.
>
> But one could easily specify a longer, multi-line signature,
> like:
>
> git format-patch --signature='
> this is my long signature
>
> it has multiple lines
> ' ...
>
> We should notice that it already has its own trailing
> newline, and suppress one of ours.
>
> Signed-off-by: Jeff King
> ---
> In the example above, there's also a newline before the signature
> starts. Should we suppress the first one, too?
>
> Also, I'm not clear on the purpose of the extra trailing line in the
> first place. Emails now end with (">" added to show blanks):
>
> > --
> > 2.0.0-rc3...
> >
>
> Is there are a reason for that final blank line?
>
> builtin/log.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/log.c b/builtin/log.c
> index 39e8836..5acc048 100644
> --- a/builtin/log.c
> +++ b/builtin/log.c
> @@ -844,8 +844,13 @@ static void gen_message_id(struct rev_info *info, char
> *base)
>
> static void print_signature(void)
> {
> - if (signature && *signature)
> - printf("-- \n%s\n\n", signature);
> + if (!signature || !*signature)
> + return;
> +
> + printf("-- \n%s", signature);
> + if (signature[strlen(signature)-1] != '\n')
> + putchar('\n');
> + putchar('\n');
> }
>
> static void add_branch_description(struct strbuf *buf, const char
> *branch_name)
> --
> 2.0.0.rc1.436.g03cb729
>
The simple solution, leaving things as they are, appeals to me.
For the purposes of testing just expect whatever odd number of blank
lines are produced. Or perhaps slurp all the trailing blank lines and
then compare.
It would be nice if every signature was followed by exactly one blank line.
But if it had two it wouldn't bother me much.
--
Jeremiah Mahler
jmmah...@gmail.com
http://github.com/jmahler
--
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
[ANNOUNCE] Git v2.0.0-rc4
A release candidate Git v2.0.0-rc4, hopefully the final one before
the real thing, is now available for testing at the usual places.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following public repositories all have a copy of the 'v2.0.0-rc4'
tag and the 'master' branch that the tag points at:
url = https://kernel.googlesource.com/pub/scm/git/git
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git v2.0 Release Notes (draft)
==
Backward compatibility notes
When "git push [$there]" does not say what to push, we have used the
traditional "matching" semantics so far (all your branches were sent
to the remote as long as there already are branches of the same name
over there). In Git 2.0, the default is now the "simple" semantics,
which pushes:
- only the current branch to the branch with the same name, and only
when the current branch is set to integrate with that remote
branch, if you are pushing to the same remote as you fetch from; or
- only the current branch to the branch with the same name, if you
are pushing to a remote that is not where you usually fetch from.
You can use the configuration variable "push.default" to change
this. If you are an old-timer who wants to keep using the
"matching" semantics, you can set the variable to "matching", for
example. Read the documentation for other possibilities.
When "git add -u" and "git add -A" are run inside a subdirectory
without specifying which paths to add on the command line, they
operate on the entire tree for consistency with "git commit -a" and
other commands (these commands used to operate only on the current
subdirectory). Say "git add -u ." or "git add -A ." if you want to
limit the operation to the current directory.
"git add " is the same as "git add -A " now, so that
"git add dir/" will notice paths you removed from the directory and
record the removal. In older versions of Git, "git add " used
to ignore removals. You can say "git add --ignore-removal " to
add only added or modified paths in , if you really want to.
The "-q" option to "git diff-files", which does *NOT* mean "quiet",
has been removed (it told Git to ignore deletion, which you can do
with "git diff-files --diff-filter=d").
"git request-pull" lost a few "heuristics" that often led to mistakes.
The default prefix for "git svn" has changed in Git 2.0. For a long
time, "git svn" created its remote-tracking branches directly under
refs/remotes, but it now places them under refs/remotes/origin/ unless
it is told otherwise with its "--prefix" option.
Updates since v1.9 series
-
UI, Workflows & Features
* The "multi-mail" post-receive hook (in contrib/) has been updated
to a more recent version from upstream.
* The "remote-hg/bzr" remote-helper interfaces (in contrib/) are
now maintained separately as a third-party plug-in.
* "git gc --aggressive" learned "--depth" option and
"gc.aggressiveDepth" configuration variable to allow use of a less
insane depth than the built-in default value of 250.
* "git log" learned the "--show-linear-break" option to show where a
single strand-of-pearls is broken in its output.
* The "rev-parse --parseopt" mechanism used by scripted Porcelains to
parse command-line options and to give help text learned to take
the argv-help (the placeholder string for an option parameter,
e.g. "key-id" in "--gpg-sign=").
* The pattern to find where the function begins in C/C++ used in
"diff" and "grep -p" has been updated to improve viewing C++
sources.
* "git rebase" learned to interpret a lone "-" as "@{-1}", the
branch that we were previously on.
* "git commit --cleanup=" learned a new mode, scissors.
* "git tag --list" output can be sorted using "version sort" with
"--sort=version:refname".
* Discard the accumulated "heuristics" to guess from which branch the
result wants to be pulled from and make sure that what the end user
specified is not second-guessed by "git request-pull", to avoid
mistakes. When you pushed out your 'master' branch to your public
repository as 'for-linus', use the new "master:for-linus" syntax to
denote the branch to be pulled.
* "git grep" learned to behave in a way similar to native grep when
"-h" (no header) and "-c" (count) options are given.
* "git push" via transport-helper interface has been updated to
allow forced ref updates in a way similar to the natively
supported transports.
* The "simple" mode is the default for "git push".
* "git add -u" and "git add -A", when run without any pathspec, is a
tree-wide operation even when run inside a subdirectory of a
working tree.
* "git add " is the
Re: Why is --graph --max-count=n so much slower than --graph HEAD~n..?
Surely. I am on a bus with terrible WiFi that does not let me use the usual terminal, but you would find a code in revision.c that sets revs->topo_order = 1 when it parses "--graph" option. If you disable it, that would stop "--graph" from wanting to compute the whole history before starting to emit stuff (and then stop at nth one with --max-count). I do not know what other side effects such a change would have, though. On Tue, May 20, 2014 at 5:13 PM, Mitchel Humpherys wrote: > On Tue, May 20 2014 at 03:50:43 PM, Junio C Hamano wrote: >> Mitchel Humpherys writes: >> >>> I've noticed that --max-count doesn't seem to speed up `git log --graph' >>> computation time. >> >> AFAIK, --graph wants to compute the whole history and the max-count >> only affects the output phase after --graph does its computation. >> >> Besides, "log --max-count=n" and "log HEAD~n.." compute completely >> different things, so the comparison is apples and oranges. > > Yes, apples and oranges in a black box :). I provided the > HEAD~n.. measurements just to show that we can get (almost) the exact > same output another way and it's much faster. It just "seems like" > --max-count=n should speed things up as n decreases... > > > -- > Mitch -- 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: Why is --graph --max-count=n so much slower than --graph HEAD~n..?
On Tue, May 20 2014 at 03:50:43 PM, Junio C Hamano wrote: > Mitchel Humpherys writes: > >> I've noticed that --max-count doesn't seem to speed up `git log --graph' >> computation time. > > AFAIK, --graph wants to compute the whole history and the max-count > only affects the output phase after --graph does its computation. > > Besides, "log --max-count=n" and "log HEAD~n.." compute completely > different things, so the comparison is apples and oranges. Yes, apples and oranges in a black box :). I provided the HEAD~n.. measurements just to show that we can get (almost) the exact same output another way and it's much faster. It just "seems like" --max-count=n should speed things up as n decreases... -- Mitch -- 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/RFC] t0000-*.sh: Fix the GIT_SKIP_TESTS sub-tests
On 20/05/14 23:44, Jonathan Nieder wrote: > Hi, > > Ramsay Jones wrote: >> On 20/05/14 22:40, Jonathan Nieder wrote: > >>> What should happen if I have set GIT_SKIP_TESTS explicitly to run >>> only some of the tests in t-basic? >> >> A quick test (with the above patch applied) shows that >> it works as I would expect: >> >> $ GIT_SKIP_TESTS=t.1[2-6] ./t-basic.sh >> ... >> ok 11 - test --verbose >> ok 12 # skip test --verbose-only (GIT_SKIP_TESTS) >> ok 13 # skip GIT_SKIP_TESTS (GIT_SKIP_TESTS) >> ok 14 # skip GIT_SKIP_TESTS several tests (GIT_SKIP_TESTS) >> ok 15 # skip GIT_SKIP_TESTS sh pattern (GIT_SKIP_TESTS) >> ok 16 # skip --run basic (GIT_SKIP_TESTS) >> ok 17 - --run with a range > > Try GIT_SKIP_TESTS=t.17 ./t-basic.sh: > > ok 13 - GIT_SKIP_TESTS > ok 14 - GIT_SKIP_TESTS several tests > ok 15 - GIT_SKIP_TESTS sh pattern > ok 16 - --run basic > ok 17 - --run with a range Ah, yes. So my original patch was the better patch. :-P That patch is given below; 'git diff -w' makes it easier to see. However, given that this is still in pu on the 'ib/test-selectively-run' branch, hopefully Ilya can simply squash this into a re-roll of his patches. ATB, Ramsay Jones -- >8 -- From: Ramsay Jones Subject: [PATCH] t-*.sh: Fix the GIT_SKIP_TESTS sub-tests Signed-off-by: Ramsay Jones --- t/t-basic.sh | 108 +-- 1 file changed, 57 insertions(+), 51 deletions(-) diff --git a/t/t-basic.sh b/t/t-basic.sh index 8345c8a..f10ba4a 100755 --- a/t/t-basic.sh +++ b/t/t-basic.sh @@ -296,66 +296,72 @@ test_expect_success 'test --verbose-only' ' ' test_expect_success 'GIT_SKIP_TESTS' " - GIT_SKIP_TESTS='git.2' \ + ( + GIT_SKIP_TESTS='git.2' && export GIT_SKIP_TESTS && run_sub_test_lib_test git-skip-tests-basic \ - 'GIT_SKIP_TESTS' <<-\\EOF && - for i in 1 2 3 - do - test_expect_success \"passing test #\$i\" 'true' - done - test_done - EOF - check_sub_test_lib_test git-skip-tests-basic <<-\\EOF - > ok 1 - passing test #1 - > ok 2 # skip passing test #2 (GIT_SKIP_TESTS) - > ok 3 - passing test #3 - > # passed all 3 test(s) - > 1..3 - EOF + 'GIT_SKIP_TESTS' <<-\\EOF && + for i in 1 2 3 + do + test_expect_success \"passing test #\$i\" 'true' + done + test_done + EOF + check_sub_test_lib_test git-skip-tests-basic <<-\\EOF + > ok 1 - passing test #1 + > ok 2 # skip passing test #2 (GIT_SKIP_TESTS) + > ok 3 - passing test #3 + > # passed all 3 test(s) + > 1..3 + EOF + ) " test_expect_success 'GIT_SKIP_TESTS several tests' " - GIT_SKIP_TESTS='git.2 git.5' \ + ( + GIT_SKIP_TESTS='git.2 git.5' && export GIT_SKIP_TESTS && run_sub_test_lib_test git-skip-tests-several \ - 'GIT_SKIP_TESTS several tests' <<-\\EOF && - for i in 1 2 3 4 5 6 - do - test_expect_success \"passing test #\$i\" 'true' - done - test_done - EOF - check_sub_test_lib_test git-skip-tests-several <<-\\EOF - > ok 1 - passing test #1 - > ok 2 # skip passing test #2 (GIT_SKIP_TESTS) - > ok 3 - passing test #3 - > ok 4 - passing test #4 - > ok 5 # skip passing test #5 (GIT_SKIP_TESTS) - > ok 6 - passing test #6 - > # passed all 6 test(s) - > 1..6 - EOF + 'GIT_SKIP_TESTS several tests' <<-\\EOF && + for i in 1 2 3 4 5 6 + do + test_expect_success \"passing test #\$i\" 'true' + done + test_done + EOF + check_sub_test_lib_test git-skip-tests-several <<-\\EOF + > ok 1 - passing test #1 + > ok 2 # skip passing test #2 (GIT_SKIP_TESTS) + > ok 3 - passing test #3 + > ok 4 - passing test #4 + > ok 5 # skip passing test #5 (GIT_SKIP_TESTS) + > ok 6 - passing test #6 + > # passed all 6 test(s) + > 1..6 + EOF + ) " test_expect_success 'GIT_SKIP_TESTS sh pattern' " - GIT_SKIP_TESTS='git.[2-5]' \ + ( + GIT_SKIP_TESTS='git.[2-5]' && export GIT_SKIP_TESTS && run_sub_test_lib_test git-skip-tests-sh-pattern \ - 'GIT_SKIP_TESTS sh pattern' <<-\\EOF && - for i in 1 2 3 4 5 6 - do - test_expect_success \"passing test #\$i\" 'true' - done - test_done - EOF - check_sub_test_lib_test git-skip-tests-sh-pattern <<-\\EOF - > ok 1 - passing test #1 - > ok 2 # skip passing test #2 (GIT
[PATCH] Add an explicit GIT_DIR to the list of excludes
When an explicit '--git-dir' option points to a directory inside
the work tree, git treats it as if it were any other directory.
In particular, 'git status' lists it as untracked, while 'git add -A'
stages the metadata directory entirely
Add GIT_DIR to the list of excludes in setup_standard_excludes(),
while checking that GIT_DIR is not just '.git', in which case it
would be ignored by default, and that GIT_DIR is inside GIT_WORK_TREE
Although an analogous comparison of any given path against '.git'
is done in treat_path(), this does not seem to be the right place
to compare against GIT_DIR. Instead, the excludes provide an
effective mechanism of ignoring a file/directory, and adding GIT_DIR
as an exclude is equivalent of putting it into '.gitignore'. Function
setup_standard_excludes() was chosen because that is the place where
the excludes are initialized by the commands that are concerned about
excludes
Signed-off-by: Pasha Bolokhov
---
dir.c | 20
1 file changed, 20 insertions(+)
diff --git a/dir.c b/dir.c
index 98bb50f..07e36f3 100644
--- a/dir.c
+++ b/dir.c
@@ -1588,6 +1588,26 @@ void setup_standard_excludes(struct dir_struct *dir)
{
const char *path;
char *xdg_path;
+ const char *gitdir = get_git_dir();
+
+ /* Add git directory to the ignores first */
+ if (strcmp(gitdir, ".git") != 0) { /* "--git-dir" has been given */
+ char ngit[PATH_MAX + 1];
+
+ /*
+* See if GIT_DIR is inside the work tree; need to normalize
+* 'gitdir' but 'get_git_work_tree()' always appears absolute
+* and normalized
+*/
+ normalize_path_copy(ngit, real_path(absolute_path(gitdir)));
+
+ if (dir_inside_of(ngit, get_git_work_tree()) >= 0) {
+ struct exclude_list *el = add_exclude_list(dir,
EXC_CMDL,
+ "--git-dir option");
+
+ add_exclude(gitdir, "", 0, el, 0);
+ }
+ }
dir->exclude_per_dir = ".gitignore";
path = git_path("info/exclude");
--
1.9.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: [ANNOUNCE] git reintegrate v0.3; manager of integration branches
On Tue, May 20, 2014 at 5:47 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> I'm not sure what would be the usefulness of using things like >> 'xx/topic~4'. > > As a notation it is not very pretty ;-). > > Imagine that xx/topic is about a multistep introduction of a > backward incompatible feature. The beginning part of the series up > to xx/topic~4 are the step to start warning (i.e. "will change---do > this to keep the old one or do that to live in the future"), > xx/topic~3..xx/topic~1 are the next step to flip the default and > still keep warning (i.e. "have changed---do this to keep the old one > or do that to live in the present"), and the final xx/topic is the > endgame where everybody lives with the new default with no warning, > without having to know what the old default was. > > While the topic is being prepared for the next release, the insn > sheet for 'jch' would have xx/topic~4 before "match next" marker, > and then an entry for xx/topic~1 somewhere after it, and finally an > entry for xx/topic (i.e. the tip, final commit). When the first > step cooked well enough in 'next', selected entries of 'jch' insn > sheet before "match next" ones are used to merge them to 'master' > and the part up to xx/topic~4 (but not later patches on the topic > branch) will be part of the upcoming release. > > You could simulate that with multiple branches stacked on top of > each other, but there are times when keeping things together in a > single branch is more handy. > > In restrospect, if I found xx/topic~4 too ugly, I might have instead > made "branches stacked on top of each other" easier to manage, but > having Reintegrate support "in the middle of a branch" was simpler. > They are both OK solutions to the same problem, and I didn't have to > solve it both ways ;-) Yes, I see how xx/topic~4 would be useful in the instruction sheet, I just didn't see it would be useful to generate that from an existing integration branch. After the explanation above I see how it could be useful to some people (though not all). I'll implement that. -- Felipe Contreras -- 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: Why is --graph --max-count=n so much slower than --graph HEAD~n..?
Mitchel Humpherys writes: > I've noticed that --max-count doesn't seem to speed up `git log --graph' > computation time. AFAIK, --graph wants to compute the whole history and the max-count only affects the output phase after --graph does its computation. Besides, "log --max-count=n" and "log HEAD~n.." compute completely different things, so the comparison is apples and oranges. -- 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: [ANNOUNCE] git reintegrate v0.3; manager of integration branches
Felipe Contreras writes: > I'm not sure what would be the usefulness of using things like > 'xx/topic~4'. As a notation it is not very pretty ;-). Imagine that xx/topic is about a multistep introduction of a backward incompatible feature. The beginning part of the series up to xx/topic~4 are the step to start warning (i.e. "will change---do this to keep the old one or do that to live in the future"), xx/topic~3..xx/topic~1 are the next step to flip the default and still keep warning (i.e. "have changed---do this to keep the old one or do that to live in the present"), and the final xx/topic is the endgame where everybody lives with the new default with no warning, without having to know what the old default was. While the topic is being prepared for the next release, the insn sheet for 'jch' would have xx/topic~4 before "match next" marker, and then an entry for xx/topic~1 somewhere after it, and finally an entry for xx/topic (i.e. the tip, final commit). When the first step cooked well enough in 'next', selected entries of 'jch' insn sheet before "match next" ones are used to merge them to 'master' and the part up to xx/topic~4 (but not later patches on the topic branch) will be part of the upcoming release. You could simulate that with multiple branches stacked on top of each other, but there are times when keeping things together in a single branch is more handy. In restrospect, if I found xx/topic~4 too ugly, I might have instead made "branches stacked on top of each other" easier to manage, but having Reintegrate support "in the middle of a branch" was simpler. They are both OK solutions to the same problem, and I didn't have to solve it both ways ;-) -- 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/RFC] t0000-*.sh: Fix the GIT_SKIP_TESTS sub-tests
Hi, Ramsay Jones wrote: > On 20/05/14 22:40, Jonathan Nieder wrote: >> What should happen if I have set GIT_SKIP_TESTS explicitly to run >> only some of the tests in t-basic? > > A quick test (with the above patch applied) shows that > it works as I would expect: > > $ GIT_SKIP_TESTS=t.1[2-6] ./t-basic.sh > ... > ok 11 - test --verbose > ok 12 # skip test --verbose-only (GIT_SKIP_TESTS) > ok 13 # skip GIT_SKIP_TESTS (GIT_SKIP_TESTS) > ok 14 # skip GIT_SKIP_TESTS several tests (GIT_SKIP_TESTS) > ok 15 # skip GIT_SKIP_TESTS sh pattern (GIT_SKIP_TESTS) > ok 16 # skip --run basic (GIT_SKIP_TESTS) > ok 17 - --run with a range Try GIT_SKIP_TESTS=t.17 ./t-basic.sh: ok 13 - GIT_SKIP_TESTS ok 14 - GIT_SKIP_TESTS several tests ok 15 - GIT_SKIP_TESTS sh pattern ok 16 - --run basic ok 17 - --run with a range Thanks, Jonathan -- 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/RFC] t0000-*.sh: Fix the GIT_SKIP_TESTS sub-tests
On 20/05/14 22:40, Jonathan Nieder wrote: > Ramsay Jones wrote: > >> --- a/t/t-basic.sh >> +++ b/t/t-basic.sh >> @@ -296,8 +296,9 @@ test_expect_success 'test --verbose-only' ' >> ' >> >> test_expect_success 'GIT_SKIP_TESTS' " >> -GIT_SKIP_TESTS='git.2' \ >> -run_sub_test_lib_test git-skip-tests-basic \ >> +GIT_SKIP_TESTS='git.2' && export GIT_SKIP_TESTS && >> +test_when_finished sane_unset GIT_SKIP_TESTS && > > Oof. Good catch. > > What should happen if I have set GIT_SKIP_TESTS explicitly to run > only some of the tests in t-basic? A quick test (with the above patch applied) shows that it works as I would expect: $ GIT_SKIP_TESTS=t.1[2-6] ./t-basic.sh ... ok 11 - test --verbose ok 12 # skip test --verbose-only (GIT_SKIP_TESTS) ok 13 # skip GIT_SKIP_TESTS (GIT_SKIP_TESTS) ok 14 # skip GIT_SKIP_TESTS several tests (GIT_SKIP_TESTS) ok 15 # skip GIT_SKIP_TESTS sh pattern (GIT_SKIP_TESTS) ok 16 # skip --run basic (GIT_SKIP_TESTS) ok 17 - --run with a range ... ok 77 - very long name in the index handled sanely # passed all 77 test(s) 1..77 $ ATB, Ramsay Jones -- 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
Why is --graph --max-count=n so much slower than --graph HEAD~n..?
I've noticed that --max-count doesn't seem to speed up `git log --graph' computation time. Here are some numbers using the linux kernel repository: | command | time* | |--+---| | git log --graph --max-count=5000 | 4.11s | | git log --graph --max-count=1000 | 4.05s | | git log --graph --max-count=500 | 3.95s | | git log --graph --max-count=50 | 3.95s | | git log --graph --max-count=10 | 3.97s | | git log --graph --max-count=1| 3.96s | However, specifying a manual revision range results in a much more dramatic speedup as `n' decreases: | command | time* | |--+---| | git log --graph HEAD~5000.. | 6.69s | | git log --graph HEAD~1000.. | 1.89s | | git log --graph HEAD~500.. | 0.03s | | git log --graph HEAD~50..| 0.02s | | git log --graph HEAD~10..| 0.02s | | git log --graph HEAD~1.. | 0.00s | * All times are "steady state" measurements after warming up the disk cache by running the command a few times. I see that the manual revision range doesn't seem to go back as far in history when I diff the output of the two commands. However, if I add `--max-count=50' to the `HEAD~50..' command I get the exact same commits but with fewer "dangling" lines at the bottom of the graph in the `HEAD~50..' approach. Anyone care to provide any insight about what's going on here? Is this expected behavior? Is there any low-hanging fruit for optimizing --max-count --graph? -- Mitch -- 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: [ANNOUNCE] git reintegrate v0.3; manager of integration branches
Junio C Hamano wrote: > Felipe Contreras writes: > > > Or have an option to specify a dynamic instruction sheet, so you can cat > > the instructions of 'match-next' and replace the base. However, I don't > > see the point of re-applying the branches for 'next' if you already know > > that 'next' and 'match-next' are the same. > > The output from Reintegrate script (in 'todo') only lists the names > of topic branches (or something like "xx/topic~4" when the topic is > not fully merged yet), and a topic branch may acquire a follow-up > change (or two) on top (there is a machinery to see if xx/topic~4 > is still valid in such a case and update the offset as needed). > > Rebuilding 'jch' on top of 'master' with the same insn sheet will > then merge the updated topic branch in its entirety, and the new > commits on the topic branch somehow needs to go to 'next' for the > "match next" on 'jch' and 'next' to be in sync (in addition, updated > 'master' must be merged to 'next', but that goes without saying). > > In other words, I already know that 'next' and "match next" are not > the same, that they must become the same, and there needs a way to > make them so. > > And that is done by re-running the insn sheet for 'jch' up to the > "match next" mark, merging the topic that are not fully merged to > 'next' while ignoring the ones that already are fully in 'next'. There could be a new --merge-missing option that takes the instruction sheet of an integration branch (e.g. 'match-next'), ignores the 'base' applies them in 'HEAD' but only when the topic branch isn't already in 'HEAD'. I'm not sure what would be the usefulness of using things like 'xx/topic~4'. -- Felipe Contreras -- 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] remote-helpers: point at their upstream repositories
Felipe Contreras writes: > Junio C Hamano wrote: >> Felipe Contreras writes: >> ... >> > So to make it clear, I now request that you do: >> > >> > 1) Remove all the code. >> ... >> I'll do that, but just one thing to make sure---do you want the >> helper to exit with status 0? > > It doesn't matter; if the remote helper doesn't respond to the commands > transport-helper exits with 128. You're right. >> > 4) Re-add the following release note: >> > >> > * "git push" via transport-helper interface (e.g. remote-hg) has >> > been updated to allow forced ref updates in a way similar to the >> > natively supported transports >> >> I am not sure if this one is consistent with 1), as remote-hg will >> no longer be with the release. > > Remove '(e.g. remote-hg)', the rest still applies. True enough. I was already deep in today's -rc4 tagging before this exchange, so it may be a while until the result is pushed out, but as far as I know the helpers are now stubs, and README no longer says "a random version that will go stale is kept here merely for convenience". As additional topics that touch contrib/remote-helpers/ need to be reverted from 'next', the final pushout may take longer than usual. We'll see. -- 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] remote-helpers: point at their upstream repositories
Johan Herland wrote: > On Tue, May 20, 2014 at 4:55 PM, Michael Haggerty > wrote: > > On 05/19/2014 11:31 PM, Junio C Hamano wrote: > >> Felipe Contreras writes: > >>> Where is git-imerge packaged? > >> > >> I didn't see it on the archive the said Ubuntu box slurps from, but > >> I did not check all the other distros. > >> > >> Michael, do you know what distro folks are doing with imerge? For > >> the purpose of this thread, "I do not follow distros, and I do not > >> know" is a perfectly acceptable answer, but it would be very > >> relevant if your answer is "I suggested these distros to include it, > >> but so far they have been uncooperative and I haven't had much > >> success". > > > > I haven't heard of any Linux distros that have git-imerge packages. I > > just searched the package archives for Debian, Fedora, Gentoo, and Arch > > without finding it. > > FWIW; someone has made an AUR package (a user-contributed Arch package > recipe) for git-imerge: > https://aur.archlinux.org/packages/git-imerge-git/ That doesn't say much. Anybody can put packages there, and it has a single vote, which suggests not many people use it (if any). -- Felipe Contreras -- 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/RFC] t0000-*.sh: Fix the GIT_SKIP_TESTS sub-tests
Ramsay Jones wrote: > --- a/t/t-basic.sh > +++ b/t/t-basic.sh > @@ -296,8 +296,9 @@ test_expect_success 'test --verbose-only' ' > ' > > test_expect_success 'GIT_SKIP_TESTS' " > - GIT_SKIP_TESTS='git.2' \ > - run_sub_test_lib_test git-skip-tests-basic \ > + GIT_SKIP_TESTS='git.2' && export GIT_SKIP_TESTS && > + test_when_finished sane_unset GIT_SKIP_TESTS && Oof. Good catch. What should happen if I have set GIT_SKIP_TESTS explicitly to run only some of the tests in t-basic? Thanks, Jonathan -- 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] remote-helpers: point at their upstream repositories
Junio C Hamano wrote: > Felipe Contreras writes: > > >> Let's try this in a different way, as I sense there is a > >> misunderstanding somewhere about your "wish". > >> ... > > No, I already said I do not want the code removed from v2.0, that's why > > I sent patches that simply added a warning, and I specifically said > > those were for 2.0. > > Yeah, I think there are mails crossing. I sent that "different way" > way before I read your "already said" happened. > > > So to make it clear, I now request that you do: > > > > 1) Remove all the code. > > > > Since my patches were removed from the list, here's an updated patch > > that applies on top of 'master' > > > > https://github.com/felipec/git/commits/up/remote/remove > > I'll do that, but just one thing to make sure---do you want the > helper to exit with status 0? It doesn't matter; if the remote helper doesn't respond to the commands transport-helper exits with 128. > > 4) Re-add the following release note: > > > > * "git push" via transport-helper interface (e.g. remote-hg) has > > been updated to allow forced ref updates in a way similar to the > > natively supported transports > > I am not sure if this one is consistent with 1), as remote-hg will > no longer be with the release. Remove '(e.g. remote-hg)', the rest still applies. -- Felipe Contreras -- 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/RFC] t0000-*.sh: Fix the GIT_SKIP_TESTS sub-tests
Ramsay Jones writes: > This patch is an RFC, because I take a different approach to the > above solution, only because the diff is much smaller and easier > to read! Is it a better solution? > > ATB, > Ramsay Jones > > t/t-basic.sh | 15 +-- > 1 file changed, 9 insertions(+), 6 deletions(-) > > diff --git a/t/t-basic.sh b/t/t-basic.sh > index 8345c8a..373ad8f 100755 > --- a/t/t-basic.sh > +++ b/t/t-basic.sh > @@ -296,8 +296,9 @@ test_expect_success 'test --verbose-only' ' > ' > > test_expect_success 'GIT_SKIP_TESTS' " > - GIT_SKIP_TESTS='git.2' \ > - run_sub_test_lib_test git-skip-tests-basic \ > + GIT_SKIP_TESTS='git.2' && export GIT_SKIP_TESTS && > + test_when_finished sane_unset GIT_SKIP_TESTS && > + run_sub_test_lib_test git-skip-tests-basic \ > 'GIT_SKIP_TESTS' <<-\\EOF && The original is clearly wrong if run_sub_test_lib_test is a shell function. I thought we hunted those down and killed them already, but apparently we didn't. I think exporting the variable and then clearing it in test-when-finished is fine, and doing the export and run in a subshell so that you do not have to clear is also fine. > for i in 1 2 3 > do > @@ -315,8 +316,9 @@ test_expect_success 'GIT_SKIP_TESTS' " > " > > test_expect_success 'GIT_SKIP_TESTS several tests' " > - GIT_SKIP_TESTS='git.2 git.5' \ > - run_sub_test_lib_test git-skip-tests-several \ > + GIT_SKIP_TESTS='git.2 git.5' && export GIT_SKIP_TESTS && > + test_when_finished sane_unset GIT_SKIP_TESTS && > + run_sub_test_lib_test git-skip-tests-several \ > 'GIT_SKIP_TESTS several tests' <<-\\EOF && > for i in 1 2 3 4 5 6 > do > @@ -337,8 +339,9 @@ test_expect_success 'GIT_SKIP_TESTS several tests' " > " > > test_expect_success 'GIT_SKIP_TESTS sh pattern' " > - GIT_SKIP_TESTS='git.[2-5]' \ > - run_sub_test_lib_test git-skip-tests-sh-pattern \ > + GIT_SKIP_TESTS='git.[2-5]' && export GIT_SKIP_TESTS && > + test_when_finished sane_unset GIT_SKIP_TESTS && > + run_sub_test_lib_test git-skip-tests-sh-pattern \ > 'GIT_SKIP_TESTS sh pattern' <<-\\EOF && > for i in 1 2 3 4 5 6 > do -- 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: [ANNOUNCE] git reintegrate v0.3; manager of integration branches
Felipe Contreras writes: > Or have an option to specify a dynamic instruction sheet, so you can cat > the instructions of 'match-next' and replace the base. However, I don't > see the point of re-applying the branches for 'next' if you already know > that 'next' and 'match-next' are the same. The output from Reintegrate script (in 'todo') only lists the names of topic branches (or something like "xx/topic~4" when the topic is not fully merged yet), and a topic branch may acquire a follow-up change (or two) on top (there is a machinery to see if xx/topic~4 is still valid in such a case and update the offset as needed). Rebuilding 'jch' on top of 'master' with the same insn sheet will then merge the updated topic branch in its entirety, and the new commits on the topic branch somehow needs to go to 'next' for the "match next" on 'jch' and 'next' to be in sync (in addition, updated 'master' must be merged to 'next', but that goes without saying). In other words, I already know that 'next' and "match next" are not the same, that they must become the same, and there needs a way to make them so. And that is done by re-running the insn sheet for 'jch' up to the "match next" mark, merging the topic that are not fully merged to 'next' while ignoring the ones that already are fully in 'next'. -- 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/RFC] t0000-*.sh: Fix the GIT_SKIP_TESTS sub-tests
Signed-off-by: Ramsay Jones --- The test suite has been failing for me on the pu branch for a while now. I finally found a few minutes to take a look. This failure is specific to the dash shell (/bin/sh) on my system (ie it may well affect other shells, but I haven't tested them all ... :). This does not affect bash (or bash as /bin/sh aka bash --posix). The GIT_SKIP_TESTS, 13-15, all fail with verbose output similar to: $ ./t-basic.sh -i -v ... --- expect2014-05-20 20:55:54.138342361 + +++ out 2014-05-20 20:55:54.134342341 + @@ -1,5 +1,5 @@ ok 1 - passing test #1 -ok 2 # skip passing test #2 (GIT_SKIP_TESTS) +ok 2 - passing test #2 ok 3 - passing test #3 # passed all 3 test(s) 1..3 not ok 13 - GIT_SKIP_TESTS # # GIT_SKIP_TESTS='git.2' run_sub_test_lib_test git-skip-tests-basic 'GIT_SKIP_TESTS' <<-\EOF && # for i in 1 2 3 # do # test_expect_success "passing test #$i" 'true' # done # test_done # EOF # check_sub_test_lib_test git-skip-tests-basic <<-\EOF # > ok 1 - passing test #1 # > ok 2 # skip passing test #2 (GIT_SKIP_TESTS) # > ok 3 - passing test #3 # > # passed all 3 test(s) # > 1..3 # EOF # $ ... which looks like the sub-test does not see the GIT_SKIP_TESTS variable at all. Indeed, if I put the entire test in a sub-shell and replace the use of that variable on the run_sub_test_lib_test invocation with a separate explicit assignment and export, then the tests start working. (ie if I do the opposite of some other recent commits!) This patch is an RFC, because I take a different approach to the above solution, only because the diff is much smaller and easier to read! Is it a better solution? ATB, Ramsay Jones t/t-basic.sh | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/t/t-basic.sh b/t/t-basic.sh index 8345c8a..373ad8f 100755 --- a/t/t-basic.sh +++ b/t/t-basic.sh @@ -296,8 +296,9 @@ test_expect_success 'test --verbose-only' ' ' test_expect_success 'GIT_SKIP_TESTS' " - GIT_SKIP_TESTS='git.2' \ - run_sub_test_lib_test git-skip-tests-basic \ + GIT_SKIP_TESTS='git.2' && export GIT_SKIP_TESTS && + test_when_finished sane_unset GIT_SKIP_TESTS && + run_sub_test_lib_test git-skip-tests-basic \ 'GIT_SKIP_TESTS' <<-\\EOF && for i in 1 2 3 do @@ -315,8 +316,9 @@ test_expect_success 'GIT_SKIP_TESTS' " " test_expect_success 'GIT_SKIP_TESTS several tests' " - GIT_SKIP_TESTS='git.2 git.5' \ - run_sub_test_lib_test git-skip-tests-several \ + GIT_SKIP_TESTS='git.2 git.5' && export GIT_SKIP_TESTS && + test_when_finished sane_unset GIT_SKIP_TESTS && + run_sub_test_lib_test git-skip-tests-several \ 'GIT_SKIP_TESTS several tests' <<-\\EOF && for i in 1 2 3 4 5 6 do @@ -337,8 +339,9 @@ test_expect_success 'GIT_SKIP_TESTS several tests' " " test_expect_success 'GIT_SKIP_TESTS sh pattern' " - GIT_SKIP_TESTS='git.[2-5]' \ - run_sub_test_lib_test git-skip-tests-sh-pattern \ + GIT_SKIP_TESTS='git.[2-5]' && export GIT_SKIP_TESTS && + test_when_finished sane_unset GIT_SKIP_TESTS && + run_sub_test_lib_test git-skip-tests-sh-pattern \ 'GIT_SKIP_TESTS sh pattern' <<-\\EOF && for i in 1 2 3 4 5 6 do -- 1.9.0 -- 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: [ANNOUNCE] git reintegrate v0.3; manager of integration branches
Junio C Hamano wrote: > Felipe Contreras writes: > > > ... > > Which will generate the integration instructions for you: > > > > % git reintegrate --cat > > base master > > merge jl/submodule-mv > > > > Moving a regular file in a repository with a .gitmodules file was > > producing a warning 'Could not find section in .gitmodules where > > path='. > > > > merge ap/remote-hg-unquote-cquote > > > > It also has support for "evil merges", so it should be perfectly > > usable for git.git maintenance. > > Yeah, it sounds like it is almost there. > > I think the infrastructure to maintain "What's cooking" could be > updated to use these comments after "merge" instructions if I wanted > to. > > I build two branches on top of 'master', one is called 'jch' and has > a marker line somewhere that says '### match next' that is turned > into an empty commit, and 'pu' that is built on top of the tip of > 'jch'. The marker line is used to apply only an earlier part of the > instruction stream to build 'jch' on top of 'master' on top of > 'next' (i.e. "base master" in the above example will not be applied > to hard-reset 'next' to match master) and stop there, and is meant > to be a way to sanity check 'next' (which is made by repeated > incremental merges on top of 'master' without rewinding) by > comparing the "### match next" commit between 'master' and 'jch' > (which is made afresh from 'master' by taking only the necessary > topics). They must match or I caught a possible mismerge on 'next'. > > I presume that the workflow can be mimicked by having another branch > 'match-next' and building it on top of 'master', and then building > 'jch' on top of it, and then building 'pu' on top of it. Then you > should be able to play 'match-next' instruction on top of 'next' > (provided that there is a way to tell it to replay on HEAD and > ignore "base" and have "merge" instruction become a no-op when the > branch has already been merged) Or have an option to specify a dynamic instruction sheet, so you can cat the instructions of 'match-next' and replace the base. However, I don't see the point of re-applying the branches for 'next' if you already know that 'next' and 'match-next' are the same. I would have two branches: 1) 'match-next' (or 'integration-next') that has the instructions to build 'next' on top of 'master', and 2) 'pu', which has the instructions to build 'pu' on top of 'next'. -- Felipe Contreras -- 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] remote-helpers: point at their upstream repositories
Felipe Contreras writes: >> Let's try this in a different way, as I sense there is a >> misunderstanding somewhere about your "wish". >> ... > No, I already said I do not want the code removed from v2.0, that's why > I sent patches that simply added a warning, and I specifically said > those were for 2.0. Yeah, I think there are mails crossing. I sent that "different way" way before I read your "already said" happened. > So to make it clear, I now request that you do: > > 1) Remove all the code. > > Since my patches were removed from the list, here's an updated patch > that applies on top of 'master' > > https://github.com/felipec/git/commits/up/remote/remove I'll do that, but just one thing to make sure---do you want the helper to exit with status 0? > 4) Re-add the following release note: > > * "git push" via transport-helper interface (e.g. remote-hg) has > been updated to allow forced ref updates in a way similar to the > natively supported transports I am not sure if this one is consistent with 1), as remote-hg will no longer be with the release. -- 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] remote-helpers: point at their upstream repositories
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > Junio C Hamano wrote:
> >>
> >> After looking at the reverse-depends list of packages, my faith is
> >> strengthened in that the Git ecosystem is truly maturing and useful
> >> third-party plug-ins will be picked up by distro packagers.
> >
> > Where is git-imerge packaged?
>
> I didn't see it on the archive the said Ubuntu box slurps from, but
> I did not check all the other distros.
I will help you: it's not packaged anywhere.
> > Do you want to bet? Nah, you don't *ever* want to accept you were wrong,
> > even you clearly where.
> > ...
> > This is what's going to happen: there won't be an official git-hg
> > package for *years*, if there is ever one. That is my prediction based
> > on all the available evidence, I am willing to stand by it and accept I
> > was wrong if it proves otherwise.
> >
> > Are you willing to stand by your own decisions?
>
> If I understand correctly, you have made and you do maintain some
> packages and as an insider, you do not have to wait for "an
> outsider" to step up to make remote-{hg,bzr} packages yourself.
No, you do not understand how packaging works. ArchLinux's AUR[1] is a
community-driven repository, anybody can package anything and put it
there. That doesn't mean people can simply do `pacman -S git-remote-hg`,
far from it.
It's a placeholder for *outsiders*, not official package maintainers.
I am an outsider in ArchLinux.
> You may already have done so for your own use and told other people
> about them, and others may have chosen to wait for you to push them to
> distros instead of championing these tools by packaging them
> themselves.
You clearly haven't tried to package anything for any distro. You can't
just champion packages for a distribution. You have to go through an
arduous process before becoming an official packager.
> When you have such an influence on the outcome either way of your
> choice, I do not see much value in such a bet.
If I champion these packages I would be making you win the bet. Why
would I do that?
> But I actually think that "we package what we want to use" is a good
> thing for programs whose primary audience is the software developer
> types. The packagers are part of their audiences [*1*]. Because of
> that, even if remote-{hg,bzr} do not get packaged for a long time, I
> doubt that it tells us what you are stipulating. The only thing we
> can infer would be that these programs did not interest the software
> developer types to motivate them enough, and we wouldn't know why
> they found the programs uninteresting. It may be because those who
> have history in Hg prefer to interact with remote Git repositories
> by pushing into and fetching from them using Hg tools than using Git
> tools. It would not indicate "useful tools fall through the cracks"
> if it were the case, would it?
Or it might mean that the people that would otherwise do that packaging
instead simply copy the single file needed manually.
> Indeed I saw bzr-git that came from the Bazaar land packaged on the
> box I mentioned, and its description sounded like it is meant to
> work in such a way that allows Bazaar commits to be pushed to Git
> repositories using a bzr tool.
>
> By the way, I also saw git-mediawiki packaged from contrib/ in our
> tree. I found it not very credible to say "contrib/ is treated as a
> single ball of wax without much value by packagers, and we need to
> move the helpers up to core in order for them to be used more
> widely" after seeing that.
You are misconstruing what I said. I said *most* distributions treat
contrib as a ball of wax. And I said there were a few *exceptions* on
this ball of wax, like completions. remote-helpers are not part of these
exceptions (with the exception of git-bzr).
> *1* I saw you called them "wolves" at least twice recently---where
> does such a distrust come from?
It's a jungle out there, and it's every out-of-tree tool by itself. Most
of the tools on the contrib/ area would not survive if you throw them to
those "wolves", and you know it.
[1] https://wiki.archlinux.org/index.php/Arch_User_Repository
--
Felipe Contreras
--
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 v8 26/44] fast-import.c: use a ref transaction when dumping tags
On Tue, May 20, 2014 at 1:38 PM, Jonathan Nieder wrote:
> Ronnie Sahlberg wrote:
>
>> [Subject: fast-import.c: use a ref transaction when dumping tags]
>
> This seems like an odd thing to do: either it would make sense to have
> a single transaction for all imported refs so all fail or succeed
> together, or there would be separate transactions for each ref.
>
> That said, I don't mind, particularly if it's a step on the way to
> using a single transaction for everything being dumped.
For now they are two transactions but I will merge them into a single one later.
>
> [...]
>> --- a/fast-import.c
>> +++ b/fast-import.c
>> @@ -1736,15 +1736,22 @@ static void dump_tags(void)
>> {
>> static const char *msg = "fast-import";
>> struct tag *t;
>> - struct ref_lock *lock;
>> char ref_name[PATH_MAX];
>> + struct strbuf err = STRBUF_INIT;
>> + struct ref_transaction *transaction;
>>
>> + transaction = ref_transaction_begin();
>> for (t = first_tag; t; t = t->next_tag) {
>> - sprintf(ref_name, "tags/%s", t->name);
>> + sprintf(ref_name, "refs/tags/%s", t->name);
>
> Can this overflow the buffer?
Changed to snprint. (We probably should do this everywhere.)
>
>> - lock = lock_ref_sha1(ref_name, NULL);
>> - if (!lock || write_ref_sha1(lock, t->sha1, msg) < 0)
>> - failure |= error("Unable to update %s", ref_name);
>> +
>> + if (ref_transaction_update(transaction, ref_name, t->sha1,
>> +NULL, 0, 0, &err)) {
>> + failure |= 1;
>> + break;
>> + }
>> }
>> + if (failure || ref_transaction_commit(transaction, msg, &err))
>> + failure |= error("Unable to update %s", err.buf);
>
> This 'if (failure || ...) failure |=' idiom seems strange.
> Is err.buf always set if failure is nonzero?
>
> Elsewhere failure is 0 or -1 but this introduces the possibility for
> it to be temporarily 1.
>
> dump_branches could have caused failure to be -1 before dump_tags
> is called. I think the intent is
>
> if (ref_transaction_update(...)) {
> failure |= error(...);
> goto out;
> }
> }
> if (ref_transaction_commit(...))
> failure |= error(...);
> out:
> ref_transaction_free(transaction);
> ...
>
Actually, since the recent change to make _commit fail if the
transaction has an error, what we want is something like this :
...
if (ref_transaction_update(transaction, ref_name, t->sha1,
NULL, 0, 0, &err))
break;
}
if (ref_transaction_commit(transaction, msg, &err))
failure |= error("%s", err.buf);
...
Please see updated ref-transactions branch.
Thanks.
> Thanks,
> Jonathan
--
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] remote-helpers: point at their upstream repositories
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > Junio C Hamano wrote:
> >
> >> 2. add warning that is given every time the scripts are run and
> >> give the same instruction as in README.
> >>
> >> 3. (optional) cripple the script to make them always fail after
> >> showing the same warning as above.
> >
> > This is what I want, and I already sent the patches for; the scripts
> > will be stubs. At this point you would have effectively removed the
> > code, which what I want.
> >
> >> 4. Keep README and retire everything else.
> >
> > After you've removed the code, I don't care what you do, but I'd say you
> > should remove the stubs after a long period of time.
>
> Let's try this in a different way, as I sense there is a
> misunderstanding somewhere about your "wish".
>
> >> "that" does not refer to "remove them at v2.0 (unconditional)". It
> >> refers to "If Felipe really wants for the removal for v2.0, I would
> >> respect that". And I saw you said you did not want to disrupt v2.0.
> >>
> >> If the options I listed all meant removal at v2.0, then I would
> >> understand your complaints, but that is not the case, so I am not
> >> sure what to make of that.
> >
> > It is a weird choice of semantics then. You said you would "respect" my
> > wish, but your proposals did not "follow" my wish.
>
> I understand you do not want to disrupt v2.0. My assumption of that
> "not disrupting v2.0" has been "there still are git-remote-{hg,bzr}
> that work just like what they had in v1.9.x, perhaps with some
> enhancements and regressions you added in the meantime", and I
> understood Peff's comment "If Felipe wants the removal" to mean that
> kind of "disruption", i.e. "there is no git-remote-{hg,bzr} that
> work.", which would be either step 3 or 4.
>
> But your "After you've removed the code" comment above makes me
> wonder that perhaps your definition of "not disrupting" was
> different from ours (which is not good or bad, just different) and
> you consider that step 3. is "removal but not distupting v2.0"?
>
> If that is what you want in v2.0, then please say so, and I already
> said I am fine with that.
No, I already said I do not want the code removed from v2.0, that's why
I sent patches that simply added a warning, and I specifically said
those were for 2.0.
However, after seeing this commit:
10e1fee (Revert "Merge branch 'fc/transport-helper-sync-error-fix'")
Which is:
1) Inaccurate
2) A lie (*you* broke 2.0, not me)
3) A disservice to users
I therefore change my wish for you to remove all the remote helpers code
and a replace them with stubs (the patches I originally sent for
post-2.0).
It was a mistake from me to believe you would do the sensible thing for
2.0.
So to make it clear, I now request that you do:
1) Remove all the code.
Since my patches were removed from the list, here's an updated patch
that applies on top of 'master'
https://github.com/felipec/git/commits/up/remote/remove
2) Reapply d508e4a (Merge branch 'fc/transport-helper-sync-error-fix')
Since the code in question is no longer part of v2.0, a "possible
regression" that you aren't even sure of cannot be the rationale to
revert this code.
Your commit 10e1fee (Revert "Merge branch
'fc/transport-helper-sync-error-fix'") actively hurts the
out-of-tree tools, so I'll consider a failure to re-revert a hostile
action.
3) Update the release notes to mention these tools have been removed
Additionally, you might want to:
4) Re-add the following release note:
* "git push" via transport-helper interface (e.g. remote-hg) has
been updated to allow forced ref updates in a way similar to the
natively supported transports
I don't know why you removed it in the first place. Clearly you pay
no attention at all to these interfaces.
I expect you to do at the very least 1) and 2).
--
Felipe Contreras
--
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 v8 26/44] fast-import.c: use a ref transaction when dumping tags
Ronnie Sahlberg wrote:
> [Subject: fast-import.c: use a ref transaction when dumping tags]
This seems like an odd thing to do: either it would make sense to have
a single transaction for all imported refs so all fail or succeed
together, or there would be separate transactions for each ref.
That said, I don't mind, particularly if it's a step on the way to
using a single transaction for everything being dumped.
[...]
> --- a/fast-import.c
> +++ b/fast-import.c
> @@ -1736,15 +1736,22 @@ static void dump_tags(void)
> {
> static const char *msg = "fast-import";
> struct tag *t;
> - struct ref_lock *lock;
> char ref_name[PATH_MAX];
> + struct strbuf err = STRBUF_INIT;
> + struct ref_transaction *transaction;
>
> + transaction = ref_transaction_begin();
> for (t = first_tag; t; t = t->next_tag) {
> - sprintf(ref_name, "tags/%s", t->name);
> + sprintf(ref_name, "refs/tags/%s", t->name);
Can this overflow the buffer?
> - lock = lock_ref_sha1(ref_name, NULL);
> - if (!lock || write_ref_sha1(lock, t->sha1, msg) < 0)
> - failure |= error("Unable to update %s", ref_name);
> +
> + if (ref_transaction_update(transaction, ref_name, t->sha1,
> +NULL, 0, 0, &err)) {
> + failure |= 1;
> + break;
> + }
> }
> + if (failure || ref_transaction_commit(transaction, msg, &err))
> + failure |= error("Unable to update %s", err.buf);
This 'if (failure || ...) failure |=' idiom seems strange.
Is err.buf always set if failure is nonzero?
Elsewhere failure is 0 or -1 but this introduces the possibility for
it to be temporarily 1.
dump_branches could have caused failure to be -1 before dump_tags
is called. I think the intent is
if (ref_transaction_update(...)) {
failure |= error(...);
goto out;
}
}
if (ref_transaction_commit(...))
failure |= error(...);
out:
ref_transaction_free(transaction);
...
Thanks,
Jonathan
--
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 v8 25/44] receive-pack.c: use a reference transaction for updating the refs
On Tue, May 20, 2014 at 12:42 PM, Jonathan Nieder wrote:
> Ronnie Sahlberg wrote:
>
>> Wrap all the ref updates inside a transaction to make the update atomic.
>
> Interesting.
>
> [...]
>> --- a/builtin/receive-pack.c
>> +++ b/builtin/receive-pack.c
>> @@ -46,6 +46,8 @@ static void *head_name_to_free;
>> static int sent_capabilities;
>> static int shallow_update;
>> static const char *alt_shallow_file;
>> +static struct strbuf err = STRBUF_INIT;
>
> I think it would be cleaner for err to be local. It isn't used for
> communication between functions.
Done.
>
> [...]
>> @@ -580,15 +581,9 @@ static const char *update(struct command *cmd, struct
>> shallow_info *si)
>> update_shallow_ref(cmd, si))
>> return "shallow error";
>>
>> - lock = lock_any_ref_for_update(namespaced_name, old_sha1,
>> -0, NULL);
>> - if (!lock) {
>> - rp_error("failed to lock %s", name);
>> - return "failed to lock";
>> - }
>> - if (write_ref_sha1(lock, new_sha1, "push")) {
>> - return "failed to write"; /* error() already called */
>> - }
>> + if (ref_transaction_update(transaction, namespaced_name,
>> +new_sha1, old_sha1, 0, 1, &err))
>> + return "failed to update";
>
> The original used rp_error to send an error message immediately via
> sideband. This drops that --- intended?
Oops. I misread it as a normal error()
>
> The old error string shown on the push status line was was "failed to
> lock" or "failed to write" which makes it clear that the cause is
> contention or database problems or filesystem problems, respectively.
> After this change it would say "failed to update" which is about as
> clear as "failed".
I changed it to return xstrdup(err.buf) which should be as detailed as
we can get.
>
> Would it be safe to send err.buf as-is over the wire, or does it
> contain information or formatting that wouldn't be suitable for the
> client? (I haven't thought this through completely yet.) Is there
> some easy way to distinguish between failure to lock and failure to
> write? Or is there some one-size-fits-all error for this case?
I think err.buf is what we want.
>
> When the transaction fails, we need to make sure that all ref updates
> emit 'ng' and not 'ok' in receive-pack.c::report (see the example at
> the end of Documentation/technical/pack-protocol.txt for what this
> means). What error string should they use? Is there some way to make
> it clear to the user which ref was the culprit?
>
> What should happen when checks outside the ref transaction system
> cause a ref update to fail? I'm thinking of
>
> * per-ref 'update' hook (see githooks(5))
> * fast-forward check
> * ref creation/deletion checks
> * attempt to push to the currently checked out branch
>
> I think the natural thing to do would be to put each ref update in its
> own transaction to start so the semantics do not change right away.
> If there are obvious answers to all these questions, then a separate
> patch could combine all these into a single transaction; or if there
> are no obvious answers, we could make the single-transaction-per-push
> semantics optional (using a configuration variable or protocol
> capability or something) to make it possible to experiment.
I changed it to use one transaction per ref for now.
Please see the update ref-transactions branch.
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 1/2] remote: defer repacking packed-refs when deleting refs
Junio C Hamano writes: > A bit safer way to organize might be to first create a list of the > refs to be removed in-core, update packed-refs without these refs to > be removed, and then finally remove the loose ones, but I haven't > thought things through. Perhaps a removal of remote can go in this order to be resistant against an abort-in-the-middle. * update packed-refs without the refs that came from the remote. - when interrupted before the new temporary file is renamed to the final, it would be a no-op. - when interrupted after the rename, only some refs that came from the remote may disappear. * remove the loose refs that came from the remote. * finally, remove the configuration related to the remote. This order would let you interrupt "remote rm" without leaving the repository in a broken state. Before the final state, it may appear that you have some but not all remote-tracking refs from the remote in your repository, but you would not have any ref that point at an obsolete object. Running "remote rm" again, once it finishes, will give you the desired result. A longer-term goal might be to have ref-transaction infrastructure clever enough to coalesce the "repack-without-these-refs" requests into one automatically without forcing the callers you are fixing care about these things, though. And such a transaction semantics may have to also cover the updating of configuration files. -- 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 v8 25/44] receive-pack.c: use a reference transaction for updating the refs
Ronnie Sahlberg wrote:
> Wrap all the ref updates inside a transaction to make the update atomic.
Interesting.
[...]
> --- a/builtin/receive-pack.c
> +++ b/builtin/receive-pack.c
> @@ -46,6 +46,8 @@ static void *head_name_to_free;
> static int sent_capabilities;
> static int shallow_update;
> static const char *alt_shallow_file;
> +static struct strbuf err = STRBUF_INIT;
I think it would be cleaner for err to be local. It isn't used for
communication between functions.
[...]
> @@ -580,15 +581,9 @@ static const char *update(struct command *cmd, struct
> shallow_info *si)
> update_shallow_ref(cmd, si))
> return "shallow error";
>
> - lock = lock_any_ref_for_update(namespaced_name, old_sha1,
> -0, NULL);
> - if (!lock) {
> - rp_error("failed to lock %s", name);
> - return "failed to lock";
> - }
> - if (write_ref_sha1(lock, new_sha1, "push")) {
> - return "failed to write"; /* error() already called */
> - }
> + if (ref_transaction_update(transaction, namespaced_name,
> +new_sha1, old_sha1, 0, 1, &err))
> + return "failed to update";
The original used rp_error to send an error message immediately via
sideband. This drops that --- intended?
The old error string shown on the push status line was was "failed to
lock" or "failed to write" which makes it clear that the cause is
contention or database problems or filesystem problems, respectively.
After this change it would say "failed to update" which is about as
clear as "failed".
Would it be safe to send err.buf as-is over the wire, or does it
contain information or formatting that wouldn't be suitable for the
client? (I haven't thought this through completely yet.) Is there
some easy way to distinguish between failure to lock and failure to
write? Or is there some one-size-fits-all error for this case?
When the transaction fails, we need to make sure that all ref updates
emit 'ng' and not 'ok' in receive-pack.c::report (see the example at
the end of Documentation/technical/pack-protocol.txt for what this
means). What error string should they use? Is there some way to make
it clear to the user which ref was the culprit?
What should happen when checks outside the ref transaction system
cause a ref update to fail? I'm thinking of
* per-ref 'update' hook (see githooks(5))
* fast-forward check
* ref creation/deletion checks
* attempt to push to the currently checked out branch
I think the natural thing to do would be to put each ref update in its
own transaction to start so the semantics do not change right away.
If there are obvious answers to all these questions, then a separate
patch could combine all these into a single transaction; or if there
are no obvious answers, we could make the single-transaction-per-push
semantics optional (using a configuration variable or protocol
capability or something) to make it possible to experiment.
Hope that helps,
Jonathan
--
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] Windows: Allow using UNC path for git repository
Stepan Kasal writes: > Hello, > > On Tue, May 20, 2014 at 11:57:56AM -0700, Junio C Hamano wrote: >> It would be nice if somebody in the S-o-b chain can double-check >> that the "combined" version is sane. [...] > > "Combined" was an unfortunate word. There was a pair of successive > commits in msysgit all the time. I just decided to submit them > squashed together. I haven't changed the code, just created a new > commit message. > > That said, reviewing the function is always useful, of course. I did mis-read your message. As the patch shows the current state that exists in msysgit that people are happy about, the function has already been reviewed by stakeholders, and I would be happy to apply it. 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 1/2] remote: defer repacking packed-refs when deleting refs
Jens Lindström writes:
> When 'git remote rm' or 'git remote prune' were used in a repository
> with many refs, and needed to delete many refs, a lot of time was spent
> deleting those refs since for each deleted ref, repack_without_refs()
> was called to rewrite packed-refs without just that deleted ref.
>
> To avoid this, defer the repacking until after all refs have been
> deleted (by delete_ref()), and then call repack_without_refs() once to
> repack without all the deleted refs.
>
> Signed-off-by: Jens Lindström
> ---
> This patch changes behavior when the operation is aborted in the
> middle, so that loose refs and ref logs might have been deleted, but
> not the corresponding entries in packed-refs, since packed-refs is now
> only updated at the end.
Also this makes it a bit more dangerous for processes accessing the
repository while pruning is in progress by exposing stale refs that
may be pointing at objects that are no longer present in the object
store in the packed-refs file for a longer period ("git fsck" may
fail, for example).
As long as we accept that removing a remote or pruning one are kinds
of "maintenance" operations and nobody else should be peeking into
the repository during maintenance period, it may be alright, but
aborting the operation in the middle will essentially leave the
repository in a corrupted state---the "abort corrupts" is a downside
with or without this change and is not a new problem.
A bit safer way to organize might be to first create a list of the
refs to be removed in-core, update packed-refs without these refs to
be removed, and then finally remove the loose ones, but I haven't
thought things through.
--
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] Windows: Allow using UNC path for git repository
Hello, On Tue, May 20, 2014 at 11:57:56AM -0700, Junio C Hamano wrote: > It would be nice if somebody in the S-o-b chain can double-check > that the "combined" version is sane. [...] "Combined" was an unfortunate word. There was a pair of successive commits in msysgit all the time. I just decided to submit them squashed together. I haven't changed the code, just created a new commit message. That said, reviewing the function is always useful, of course. Stepan -- 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
[RFC/PATCH v4 2/3] add trace_performance facility to debug performance issues
Add trace_performance and trace_performance_since macros that print file
name, line number, time and an optional printf-formatted text to the file
specified in environment variable GIT_TRACE_PERFORMANCE.
Unless enabled via GIT_TRACE_PERFORMANCE, these macros have no noticeable
impact on performance, so that test code may be shipped in release builds.
MSVC: variadic macros (__VA_ARGS__) require VC++ 2005 or newer.
Simple use case (measure one code section):
uint64_t start = getnanotime();
/* code section to measure */
trace_performance_since(start, "foobar");
Medium use case (measure consecutive code sections):
uint64_t start = getnanotime();
/* first code section to measure */
start = trace_performance_since(start, "first foobar");
/* second code section to measure */
trace_performance_since(start, "second foobar");
Complex use case (measure repetitive code sections):
uint64_t t = 0;
for (;;) {
/* ignore */
t -= getnanotime();
/* code section to measure */
t += getnanotime();
/* ignore */
}
trace_performance(t, "frotz");
Signed-off-by: Karsten Blees
---
cache.h | 18 ++
trace.c | 40
2 files changed, 58 insertions(+)
diff --git a/cache.h b/cache.h
index 48fc616..cb856d9 100644
--- a/cache.h
+++ b/cache.h
@@ -1363,6 +1363,24 @@ __attribute__((format (printf, 2, 3)))
extern void trace_printf_key(const char *key, const char *fmt, ...);
extern void trace_strbuf(const char *key, const struct strbuf *buf);
extern uint64_t getnanotime(void);
+__attribute__((format (printf, 4, 5)))
+extern uint64_t trace_performance_file_line(const char *file, int lineno,
+ uint64_t nanos, const char *fmt, ...);
+
+/*
+ * Prints specified time (in nanoseconds) if GIT_TRACE_PERFORMANCE is enabled.
+ * Returns current time in nanoseconds.
+ */
+#define trace_performance(nanos, ...) \
+ trace_performance_file_line(__FILE__, __LINE__, nanos, __VA_ARGS__)
+
+/*
+ * Prints time since 'start' if GIT_TRACE_PERFORMANCE is enabled.
+ * Returns current time in nanoseconds.
+ */
+#define trace_performance_since(start, ...) \
+ trace_performance_file_line(__FILE__, __LINE__, \
+ getnanotime() - (start), __VA_ARGS__)
void packet_trace_identity(const char *prog);
diff --git a/trace.c b/trace.c
index 3d72084..1b1903b 100644
--- a/trace.c
+++ b/trace.c
@@ -269,3 +269,43 @@ inline uint64_t getnanotime(void)
return now;
}
}
+
+static const char *GIT_TRACE_PERFORMANCE = "GIT_TRACE_PERFORMANCE";
+
+static inline int trace_want_performance(void)
+{
+ static int enabled = -1;
+ if (enabled < 0)
+ enabled = trace_want(GIT_TRACE_PERFORMANCE);
+ return enabled;
+}
+
+/*
+ * Prints performance data if environment variable GIT_TRACE_PERFORMANCE is
+ * set, otherwise a NOOP. Returns the current time in nanoseconds.
+ */
+__attribute__((format (printf, 4, 5)))
+uint64_t trace_performance_file_line(const char *file, int lineno,
+uint64_t nanos, const char *fmt, ...)
+{
+ struct strbuf buf = STRBUF_INIT;
+ va_list args;
+
+ if (!trace_want_performance())
+ return 0;
+
+ strbuf_addf(&buf, "performance: at %s:%i, time: %.9f s", file, lineno,
+ (double) nanos / 10);
+
+ if (fmt && *fmt) {
+ strbuf_addstr(&buf, ": ");
+ va_start(args, fmt);
+ strbuf_vaddf(&buf, fmt, args);
+ va_end(args);
+ }
+ strbuf_addch(&buf, '\n');
+
+ trace_strbuf(GIT_TRACE_PERFORMANCE, &buf);
+ strbuf_release(&buf);
+ return getnanotime();
+}
--
1.9.2.msysgit.0.493.g47a82c3
--
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
[RFC/PATCH v4 1/3] add high resolution timer function to debug performance issues
Add a getnanotime() function that returns nanoseconds since 01/01/1970 as
unsigned 64-bit integer (i.e. overflows in july 2554). This is easier to
work with than e.g. struct timeval or struct timespec.
The implementation uses gettimeofday() by default; supports high precision
time sources on the following platforms:
* Linux: using clock_gettime(CLOCK_MONOTONIC)
* Windows: using QueryPerformanceCounter()
Todo:
* enable clock_gettime() on more platforms
* implement Mac OSX version using mach_absolute_time
Signed-off-by: Karsten Blees
---
Makefile | 7 +
cache.h | 1 +
config.mak.uname | 1 +
trace.c | 82
4 files changed, 91 insertions(+)
diff --git a/Makefile b/Makefile
index a53f3a8..3c05f8c 100644
--- a/Makefile
+++ b/Makefile
@@ -341,6 +341,8 @@ all::
#
# Define GMTIME_UNRELIABLE_ERRORS if your gmtime() function does not
# return NULL when it receives a bogus time_t.
+#
+# Define HAVE_CLOCK_GETTIME if your platform has clock_gettime in librt.
GIT-VERSION-FILE: FORCE
@$(SHELL_PATH) ./GIT-VERSION-GEN
@@ -1497,6 +1499,11 @@ ifdef GMTIME_UNRELIABLE_ERRORS
BASIC_CFLAGS += -DGMTIME_UNRELIABLE_ERRORS
endif
+ifdef HAVE_CLOCK_GETTIME
+ BASIC_CFLAGS += -DHAVE_CLOCK_GETTIME
+ EXTLIBS += -lrt
+endif
+
ifeq ($(TCLTK_PATH),)
NO_TCLTK = NoThanks
endif
diff --git a/cache.h b/cache.h
index 107ac61..48fc616 100644
--- a/cache.h
+++ b/cache.h
@@ -1362,6 +1362,7 @@ extern int trace_want(const char *key);
__attribute__((format (printf, 2, 3)))
extern void trace_printf_key(const char *key, const char *fmt, ...);
extern void trace_strbuf(const char *key, const struct strbuf *buf);
+extern uint64_t getnanotime(void);
void packet_trace_identity(const char *prog);
diff --git a/config.mak.uname b/config.mak.uname
index 23a8803..5e3b1dd 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -33,6 +33,7 @@ ifeq ($(uname_S),Linux)
HAVE_PATHS_H = YesPlease
LIBC_CONTAINS_LIBINTL = YesPlease
HAVE_DEV_TTY = YesPlease
+ HAVE_CLOCK_GETTIME = YesPlease
endif
ifeq ($(uname_S),GNU/kFreeBSD)
NO_STRLCPY = YesPlease
diff --git a/trace.c b/trace.c
index 08180a9..3d72084 100644
--- a/trace.c
+++ b/trace.c
@@ -187,3 +187,85 @@ int trace_want(const char *key)
return 0;
return 1;
}
+
+#ifdef HAVE_CLOCK_GETTIME
+
+static inline uint64_t highres_nanos(void)
+{
+ struct timespec ts;
+ if (clock_gettime(CLOCK_MONOTONIC, &ts))
+ return 0;
+ return (uint64_t) ts.tv_sec * 10 + ts.tv_nsec;
+}
+
+#elif defined (GIT_WINDOWS_NATIVE)
+
+static inline uint64_t highres_nanos(void)
+{
+ static uint64_t high_ns, scaled_low_ns;
+ static int scale;
+ LARGE_INTEGER cnt;
+
+ if (!scale) {
+ if (!QueryPerformanceFrequency(&cnt))
+ return 0;
+
+ /* high_ns = number of ns per cnt.HighPart */
+ high_ns = (10LL << 32) / (uint64_t) cnt.QuadPart;
+
+ /*
+* Number of ns per cnt.LowPart is 10^9 / frequency (or
+* high_ns >> 32). For maximum precision, we scale this factor
+* so that it just fits within 32 bit (i.e. won't overflow if
+* multiplied with cnt.LowPart).
+*/
+ scaled_low_ns = high_ns;
+ scale = 32;
+ while (scaled_low_ns >= 0x1LL) {
+ scaled_low_ns >>= 1;
+ scale--;
+ }
+ }
+
+ /* if QPF worked on initialization, we expect QPC to work as well */
+ QueryPerformanceCounter(&cnt);
+
+ return (high_ns * cnt.HighPart) +
+ ((scaled_low_ns * cnt.LowPart) >> scale);
+}
+
+#else
+# define highres_nanos() 0
+#endif
+
+static inline uint64_t gettimeofday_nanos(void)
+{
+ struct timeval tv;
+ gettimeofday(&tv, NULL);
+ return (uint64_t) tv.tv_sec * 10 + tv.tv_usec * 1000;
+}
+
+/*
+ * Returns nanoseconds since the epoch (01/01/1970), for performance tracing
+ * (i.e. favoring high precision over wall clock time accuracy).
+ */
+inline uint64_t getnanotime(void)
+{
+ static uint64_t offset;
+ if (offset > 1) {
+ /* initialization succeeded, return offset + high res time */
+ return offset + highres_nanos();
+ } else if (offset == 1) {
+ /* initialization failed, fall back to gettimeofday */
+ return gettimeofday_nanos();
+ } else {
+ /* initialize offset if high resolution timer works */
+ uint64_t now = gettimeofday_nanos();
+ uint64_t highres = highres_nanos();
+ if (highres)
+ offset = now - highres;
+ else
+ offset = 1;
+ return now;
+ }
+}
--
1.9.2.msysgit.0.493
[RFC/PATCH v4 3/3] add command performance tracing to debug scripted commands
Add performance tracing to identify which git commands are called and how
long they execute. This is particularly useful to debug performance issues
of scripted commands.
Usage example: > GIT_TRACE_PERFORMANCE=~/git-trace.log git stash list
Creates a log file like this:
performance: at trace.c:319, time: 0.000303280 s: git command: 'git'
'rev-parse' '--git-dir'
performance: at trace.c:319, time: 0.000334409 s: git command: 'git'
'rev-parse' '--is-inside-work-tree'
performance: at trace.c:319, time: 0.000215243 s: git command: 'git'
'rev-parse' '--show-toplevel'
performance: at trace.c:319, time: 0.000410639 s: git command: 'git' 'config'
'--get-colorbool' 'color.interactive'
performance: at trace.c:319, time: 0.000394077 s: git command: 'git' 'config'
'--get-color' 'color.interactive.help' 'red bold'
performance: at trace.c:319, time: 0.000280701 s: git command: 'git' 'config'
'--get-color' '' 'reset'
performance: at trace.c:319, time: 0.000908185 s: git command: 'git'
'rev-parse' '--verify' 'refs/stash'
performance: at trace.c:319, time: 0.028827774 s: git command: 'git' 'stash'
'list'
Signed-off-by: Karsten Blees
---
cache.h | 1 +
git.c | 2 ++
trace.c | 22 ++
3 files changed, 25 insertions(+)
diff --git a/cache.h b/cache.h
index cb856d9..289e8fd 100644
--- a/cache.h
+++ b/cache.h
@@ -1366,6 +1366,7 @@ extern uint64_t getnanotime(void);
__attribute__((format (printf, 4, 5)))
extern uint64_t trace_performance_file_line(const char *file, int lineno,
uint64_t nanos, const char *fmt, ...);
+extern void trace_command_performance(const char **argv);
/*
* Prints specified time (in nanoseconds) if GIT_TRACE_PERFORMANCE is enabled.
diff --git a/git.c b/git.c
index 9efd1a3..2ea65b1 100644
--- a/git.c
+++ b/git.c
@@ -568,6 +568,8 @@ int main(int argc, char **av)
git_setup_gettext();
+ trace_command_performance(argv);
+
/*
* "git-" is the same as "git ", but we obviously:
*
diff --git a/trace.c b/trace.c
index 1b1903b..9edcb59 100644
--- a/trace.c
+++ b/trace.c
@@ -309,3 +309,25 @@ uint64_t trace_performance_file_line(const char *file, int
lineno,
strbuf_release(&buf);
return getnanotime();
}
+
+static uint64_t command_start_time;
+static struct strbuf command_line = STRBUF_INIT;
+
+static void print_command_performance_atexit(void)
+{
+ trace_performance_since(command_start_time, "git command:%s",
+ command_line.buf);
+}
+
+void trace_command_performance(const char **argv)
+{
+ if (!trace_want_performance())
+ return;
+
+ if (!command_start_time)
+ atexit(print_command_performance_atexit);
+
+ strbuf_reset(&command_line);
+ sq_quote_argv(&command_line, argv, 0);
+ command_start_time = getnanotime();
+}
--
1.9.2.msysgit.0.493.g47a82c3
--
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
[RFC/PATCH v4 0/3] add performance tracing facility
This is the POSIX port of the patches I typically use to track down msysgit performance issues (thus v4, the latest windows-only version is here [1]). Sebastian and Dscho thought this might be useful in core git, so here it is. [1] https://github.com/msysgit/git/pull/46 Karsten Blees (3): add high resolution timer function to debug performance issues add trace_performance facility to debug performance issues add command performance tracing to debug scripted commands Makefile | 7 +++ cache.h | 20 config.mak.uname | 1 + git.c| 2 + trace.c | 144 +++ 5 files changed, 174 insertions(+) -- 1.9.2.msysgit.0.493.g47a82c3 -- 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: EXT :Re: GIT and large files
On Tue, 20 May 2014 18:18:08 + "Stewart, Louis (IS)" wrote: > From you response then there is a method to only obtain the Project, > Directory and Files (which could hold 80 GBs of data) and not the > rest of the Repository that contained the full overall Projects? Please google the phrase "Git shallow cloning". I would also recommend to read up on git-annex [1]. You might also consider using Subversion as it seems you do not need most benefits Git has over it and want certain benefits Subversion has over Git: * You don't need a distributed VCS (as you don't want each developer to have a full clone). * You only need a single slice of the repository history at any given revision on a developer's machine, and this is *almost* what Subversion does: it will keep the so-called "base" (or "pristine") versions of files comprising the revision you will check out, plus the checked out files theirselves. So, twice the space of the files comprising a revision. * Subversion allows you to check out only a single folder out of the entire revision. * IIRC, subversion supports locks, when a developer might tell the server they're editing a file, and this will prevent other devs from locking the same file. This might be used to serialize editions of huge and/or unmergeable files. Git can't do that (without non-standard tools deployed on the side or a centralized "meeting point" repository). My point is that while Git is fantastic for managing source code projects and project of similar types with regard to their contents, it seems your requirements are mainly not suitable for the use case Git is best tailored for. Your apparent lack of familiarity with Git might as well bite you later should you pick it right now. At least please consider reading a book or some other introduction-level material on Git to get the feeling of typical workflows used with it. 1. https://git-annex.branchable.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
Re: [PATCH] Windows: Allow using UNC path for git repository
Stepan Kasal writes:
> From: Cezary Zawadka
> Date: Tue, 13 Jul 2010 16:17:43 +0200
>
> [efl: moved MinGW-specific part to compat/]
> [jes: fixed compilation on non-Windows]
>
> Eric Sunshine fixed mingw_offset_1st_component() to return consistently "foo"
> for UNC "//machine/share/foo", cf
> http://groups.google.com/group/msysgit/browse_thread/thread/c0af578549b5dda0
>
> Author: Eric Sunshine
> Signed-off-by: Cezary Zawadka
> Signed-off-by: Eric Sunshine
> Signed-off-by: Erik Faye-Lund
> Signed-off-by: Johannes Schindelin
> Signed-off-by: Stepan Kasal
> ---
>
> Hello,
> this is another patch that lived in msysGit for years, at least from
> Jul 13, 2010. It was there in two parts, first sketch by Cezary and
> a fix from Eric Sunshine, but I decided to submit the combined
> version.
>
> Let me note that this patch should not affect any non-Windows
> platform. The chnage of offset_1st_component() to a simple macro is
> ok, because has_dos_drive_prefix() is 0 there.
As I do not think anybody takes the address of the function, I agree
it should be a no-op for non-Windows platform.
It would be nice if somebody in the S-o-b chain can double-check
that the "combined" version is sane. I didn't read the mingw.c part
carefully enough for me to say returning 0 upon error is sane with
confidence, for example.
Thanks.
> Regards,
> Stepan
>
> cache.h | 1 -
> compat/mingw.c| 24
> compat/mingw.h| 2 ++
> git-compat-util.h | 4
> path.c| 7 ---
> 5 files changed, 30 insertions(+), 8 deletions(-)
>
> diff --git a/cache.h b/cache.h
> index ebe9a40..0961fb5 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -781,7 +781,6 @@ int normalize_path_copy(char *dst, const char *src);
> int longest_ancestor_length(const char *path, struct string_list *prefixes);
> char *strip_path_suffix(const char *path, const char *suffix);
> int daemon_avoid_alias(const char *path);
> -int offset_1st_component(const char *path);
>
> /* object replacement */
> #define LOOKUP_REPLACE_OBJECT 1
> diff --git a/compat/mingw.c b/compat/mingw.c
> index e9892f8..a0e13bc 100644
> --- a/compat/mingw.c
> +++ b/compat/mingw.c
> @@ -1823,3 +1823,27 @@ pid_t waitpid(pid_t pid, int *status, int options)
> errno = EINVAL;
> return -1;
> }
> +
> +int mingw_offset_1st_component(const char *path)
> +{
> + int offset = 0;
> + if (has_dos_drive_prefix(path))
> + offset = 2;
> +
> + /* unc paths */
> + else if (is_dir_sep(path[0]) && is_dir_sep(path[1])) {
> +
> + /* skip server name */
> + char *pos = strpbrk(path + 2, "\\/");
> + if (!pos)
> + return 0; /* Error: malformed unc path */
> +
> + do {
> + pos++;
> + } while (*pos && !is_dir_sep(*pos));
> +
> + offset = pos - path;
> + }
> +
> + return offset + is_dir_sep(path[offset]);
> +}
> diff --git a/compat/mingw.h b/compat/mingw.h
> index e033e72..3eaf822 100644
> --- a/compat/mingw.h
> +++ b/compat/mingw.h
> @@ -339,6 +339,8 @@ static inline char *mingw_find_last_dir_sep(const char
> *path)
> return ret;
> }
> #define find_last_dir_sep mingw_find_last_dir_sep
> +int mingw_offset_1st_component(const char *path);
> +#define offset_1st_component mingw_offset_1st_component
> #define PATH_SEP ';'
> #define PRIuMAX "I64u"
> #define PRId64 "I64d"
> diff --git a/git-compat-util.h b/git-compat-util.h
> index d493a8c..ec41cfb 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -270,6 +270,10 @@ extern char *gitbasename(char *);
> #define has_dos_drive_prefix(path) 0
> #endif
>
> +#ifndef offset_1st_component
> +#define offset_1st_component(path) (is_dir_sep((path)[0]))
> +#endif
> +
> #ifndef is_dir_sep
> #define is_dir_sep(c) ((c) == '/')
> #endif
> diff --git a/path.c b/path.c
> index f9c5062..bc804a3 100644
> --- a/path.c
> +++ b/path.c
> @@ -823,10 +823,3 @@ int daemon_avoid_alias(const char *p)
> }
> }
> }
> -
> -int offset_1st_component(const char *path)
> -{
> - if (has_dos_drive_prefix(path))
> - return 2 + is_dir_sep(path[2]);
> - return is_dir_sep(path[0]);
> -}
> --
> 1.9.2.msysgit.0.490.ga07b726
>
> --
--
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 01/19] check_bindir: convert test -a/-o to && and ||
Junio C Hamano writes: > As I already said, I think "better known" is much less of an issue > than that "-a/-o" is "more error prone", and that is the reason why > we may want to do this rewrite. > > I do not know offhand how busy the tree would be when we can apply > these patches post-release without them getting rebased, but the > zero-th step before this series may want to be a patch like this. ... and this time with a proposed log message. -- >8 -- Subject: [PATCH] CodingGuidelines: avoid "test -a/-o " The construct is error-prone; "test" being built-in in most modern shells, the reason to avoid "test && test " spawning one extra process by using a single "test -a " no longer exists. Signed-off-by: Junio C Hamano --- Documentation/CodingGuidelines | 13 + 1 file changed, 13 insertions(+) diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index 3d08671..4d90c77 100644 --- a/Documentation/CodingGuidelines +++ b/Documentation/CodingGuidelines @@ -151,6 +151,19 @@ For shell scripts specifically (not exhaustive): interface translatable. See "Marking strings for translation" in po/README. + - We do not write our "test" command with "-a" and "-o" and use "&&" + or "||" to concatenate multiple "test" commands instead, because + the use of "-a/-o" is often error-prone. E.g. + + test -n "$x" -a "$a" = "$b" + + is buggy and breaks when $x is "=", but + + test -n "$x" && test "$a" = "$b" + + does not have such a problem. + + For C programs: - We use tabs to indent, and interpret tabs as taking up to -- 2.0.0-rc3-438-g36dae77 -- 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 v5] format-patch --signature-file
Jeff King writes: > If it were just "--signature", I'd agree. After all, nobody is even > complaining. But this is also in preparation for --signature-file. > Should the user create a file without a trailing newline? Ahh, I missed that part. I am fine with processing it with stripspace(). By the way, at some point we may want to move that helper function to strbuf.c, but that is a separate issue. -- 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: untracked file deleted from the master branch, when checked out to it from a local branch
On 5/20/2014 12:40 PM, Arup Rakshit wrote: On Tuesday, May 20, 2014 11:24:11 AM you wrote: Arup Rakshit writes: Untracked files and modifications to files in your working directory do not belong to your current branch. This is to allow you, after starting to work on one branch then realizing that the changes and additions you are making do not belong there, to switch to a more appropriate branch at that point without losing your work so far, taking these changes and additions with you to the branch you want to commit your changes to. Now, It makes sense. I gave it another try and this time I walk from back to front. Now you can see, that I have created, a new file called *file.txt*, in the *master branch*. NO, you didn't. > arup@linux-wzza:~/Git_tutorial> git status > # On branch master > # Untracked files: > # (use "git add ..." to include in what will be committed) > # > # file.txt See that file.txt is listed under "Untracked files"? Git sees the file, but since you haven't added it with "git add", it's untracked and Git doesn't care about it. It lists it with the status command, so you will see that it's not yet tracked. -- .marius -- 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: untracked file deleted from the master branch, when checked out to it from a local branch
On Tuesday, May 20, 2014 11:24:11 AM you wrote: > Arup Rakshit writes: > > Untracked files and modifications to files in your working directory > do not belong to your current branch. This is to allow you, after > starting to work on one branch then realizing that the changes and > additions you are making do not belong there, to switch to a more > appropriate branch at that point without losing your work so far, > taking these changes and additions with you to the branch you want > to commit your changes to. > Now, It makes sense. I gave it another try and this time I walk from back to front. Now you can see, that I have created, a new file called *file.txt*, in the *master branch*. Now I went to a new branch and made some changes there in the newly created file. This time I didn't add it or commit too. I just came back to *master branch*. Now if I do *ls*, can see the file is present in the *master* branch. arup@linux-wzza:~/Git_tutorial> ls test.txt arup@linux-wzza:~/Git_tutorial> echo "hello" > file.txt arup@linux-wzza:~/Git_tutorial> ls file.txt test.txt arup@linux-wzza:~/Git_tutorial> git status # On branch master # Untracked files: # (use "git add ..." to include in what will be committed) # # file.txt nothing added to commit but untracked files present (use "git add" to track) arup@linux-wzza:~/Git_tutorial> cat file.txt hello arup@linux-wzza:~/Git_tutorial> git checkout -b "file_branch" Switched to a new branch 'file_branch' arup@linux-wzza:~/Git_tutorial> cat file.txt hello arup@linux-wzza:~/Git_tutorial> echo "hello World" > file.txt arup@linux-wzza:~/Git_tutorial> cat file.txt hello World arup@linux-wzza:~/Git_tutorial> git status # On branch file_branch # Untracked files: # (use "git add ..." to include in what will be committed) # # file.txt nothing added to commit but untracked files present (use "git add" to track) arup@linux-wzza:~/Git_tutorial> git checkout master Switched to branch 'master' arup@linux-wzza:~/Git_tutorial> ls file.txt test.txt arup@linux-wzza:~/Git_tutorial> cat file.txt hello World arup@linux-wzza:~/Git_tutorial> -- === Regards, Arup Rakshit -- 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] git-prompt.sh: don't assume the shell expands the value of PS1
Richard Hansen writes:
> Not all shells subject the prompt string to parameter expansion. Test
> whether the shell will expand the value of PS1, and use the result to
> control whether raw ref names are included directly in PS1.
>
> This fixes a regression introduced in commit 8976500 ("git-prompt.sh:
> don't put unsanitized branch names in $PS1"): zsh does not expand PS1
> by default, but that commit assumed it did. The bug resulted in
> prompts containing the literal string '${__git_ps1_branch_name}'
> instead of the actual branch name.
>
> Reported-by: Caleb Thompson
> Signed-off-by: Richard Hansen
> ---
Thanks, applied.
> To prevent a regression like this from happening again, I plan on
> adding new zsh test cases and expanding the bash test cases (to test
> the behavior with 'shopt -u promptvars'). I'd like the zsh tests to
> cover the same stuff as the bash tests. These are the steps I am
> considering:
>
> 1. delete the last test case in t9903 ("prompt - zsh color pc mode")
> 2. add two new functions to t/lib-bash.sh:
> ps1_expansion_enable () { shopt -s promptvars; }
> ps1_expansion_disable () { shopt -u promptvars; }
> 3. loop over the relevant test cases twice: once after calling
> ps1_expansion_enable and once after calling ps1_expansion_disable
> (with appropriate adjustments to the expected output)
> 4. move the test cases in t9903 to a separate library file and
> source it from t9903-bash-prompt.sh
> 5. create two new files:
>* t/lib-zsh.sh (same as t/lib-bash.sh but tweaked for zsh)
>* t/t9904-zsh-prompt.sh (same as t/t9903-bash-prompt.sh but
> tweaked for zsh)
>
> Does this approach sound reasonable?
Sounds like a plan, especially if step 4 does a reasonable job of
factoring out as much common stuff as possible.
--
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] rebase -i: test "Nothing to do" case with autostash
Matthieu Moy writes: > Signed-off-by: Matthieu Moy > --- > Eric Sunshine writes: > >> Simpler (replace above two lines): >> >> test_set_editor "$(pwd)/abort-editor.sh" && > > Indeed. > > And I had debug statements left. > > Hopefully, this after-coffee-v2 will be clear enough and correct ;-). Thanks, will queue on top of Ram's fix. -- 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: untracked file deleted from the master branch, when checked out to it from a local branch
On 5/20/2014 12:20 PM, Arup Rakshit wrote: On Tuesday, May 20, 2014 12:06:49 PM you wrote: It never "came to the new branch", as it was never version controlled, it was an untracked file left behind when you switched branches. Once you added it to the new branch, change_class, it became a version controlled file, This is still didn't get it. If an untracked file didn't come in the new branch, how would I able to add it to stage ? I am not getting this part. You are right, but I am not able to understand this one, my bad! :( Ok, step by step: You've created test.rd, that was never added to the git repo. (You never committed it to the master branch.) > ***HERE I switched to a NEW Branch > Arup-iMac:arup_git shreyas$ git checkout -b change_class > Switched to a new branch 'change_class' > Arup-iMac:arup_git shreyas$ ls > git_1.txt test.rb test.rd is untracked, so still there. Git doesn't touch untracked files. > Arup-iMac:arup_git shreyas$ vi test.rb > Arup-iMac:arup_git shreyas$ head -1 test.rb > class Fooo > Arup-iMac:arup_git shreyas$ head -2 test.rb > class Fooo >def self.bar You modified it > Arup-iMac:arup_git shreyas$ git commit -am 'changed the class name' > # On branch change_class > # Untracked files: > # (use "git add ..." to include in what will be committed) > # > #test.rb > nothing added to commit but untracked files present (use "git add" to track) You did nothing here.. > Arup-iMac:arup_git shreyas$ git add test.rb > Arup-iMac:arup_git shreyas$ git commit -am 'changed the class name' > [change_class 2d40033] changed the class name > 1 file changed, 7 insertions(+) > create mode 100644 test.rb Your previously untracked file has now been checked in. It's no longer untracked, so now Git cares. > Arup-iMac:arup_git shreyas$ cat test.rb > class Fooo >def self.bar > 12 >end > end > > Fooo.bar > Arup-iMac:arup_git shreyas$ git checkout master > Switched to branch 'master' You switched back to master branch, which contains no test.rb (as it's clean and has never been committed to), so therefore Git removes the file, since the now tracked test.rb shouldn't be on the master branch. -- .marius -- 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: EXT :Re: GIT and large files
Am Dienstag, den 20.05.2014, 17:24 + schrieb Stewart, Louis (IS): > Thanks for the reply. I just read the intro to GIT and I am concerned > about the part that it will copy the whole repository to the developers > work area. They really just need the one directory and files under > that one directory. The history has TBs of data. > > Lou > > -Original Message- > From: Junio C Hamano [mailto:gits...@pobox.com] > Sent: Tuesday, May 20, 2014 1:18 PM > To: Stewart, Louis (IS) > Cc: git@vger.kernel.org > Subject: EXT :Re: GIT and large files > > "Stewart, Louis (IS)" writes: > > > Can GIT handle versioning of large 20+ GB files in a directory? > > I think you can "git add" such files, push/fetch histories that > contains such files over the wire, and "git checkout" such files, but > naturally reading, processing and writing 20+GB would take some time. > In order to run operations that need to see the changes, e.g. "git log > -p", a real content-level merge, etc., you would also need sufficient > memory because we do things in-core. Preventing that a clone fetches the whole history can be done with the --depth option of git clone. The question is what do you want to do with these 20G files? Just store them in the repo and *very* occasionally change them? For that you need a 64bit compiled version of git with enough ram. 32G does the trick here. Everything with git 1.9.1. Doing some tests on my machine with a normal harddisc gives (sorry for LC_ALL != C): $time git add file.dat; time git commit -m "add file"; time git status real16m17.913s user13m3.965s sys 0m22.461s [master 15fa953] add file 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 file.dat real15m36.666s user13m26.962s sys 0m16.185s # Auf Branch master nichts zu committen, Arbeitsverzeichnis unverändert real11m58.936s user11m50.300s sys 0m5.468s $ls -lh -rw-r--r-- 1 thomas thomas 20G Mai 20 19:01 file.dat So this works but aint fast. Playing some tricks with --assume-unchanged helps here: $git update-index --assume-unchanged file.dat $time git status # Auf Branch master nichts zu committen, Arbeitsverzeichnis unverändert real0m0.003s user0m0.000s sys 0m0.000s This trick is only save if you *know* that file.dat does not change. And btw I also set $cat .gitattributes *.dat -delta as delta compresssion should be skipped in any case. Pushing and pulling these files to and from a server needs some tweaking on the server side, otherwise the occasional git gc might kill the box. Btw. I happily have files with 1.5GB in my git repositories and also change them. And also work with git for windows. So in this region of file sizes things work quite well. -- 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 v5] format-patch --signature-file
On Tue, May 20, 2014 at 10:53:11AM -0700, Junio C Hamano wrote: > I actually think these "supress extra LFs" trying to be overly smart > and inviting unnecessary surprises. Unlike log messages people type > (in which we do squash runs of blank lines and other prettifying), > mail-signature string is not something people keep typing, and it > would be better to keep it simple and consistent, i.e. we can > declare that the users who use non-default mail-signature can and > should learn to: > > --signature='this is the first line of my long sig > > with a blank line and then it ends here' > > and be done with it, I think. If it were just "--signature", I'd agree. After all, nobody is even complaining. But this is also in preparation for --signature-file. Should the user create a file without a trailing newline? We can special-case --signature-file to strip the final newline from the read file, but it seems friendlier to handle it at the printing stage (and then we handle the unlikely but possible --signature as above for free). I don't think it would adversely impact any real-world case, because somebody would have to: 1. already be including an extra trailing newline 2. really _want_ three newlines at the end > The trailing blank after the mail-signature is a different issue. I > think it is safe to remove it and I also think the result may look > better, but at the same time, it is very close to the "if we were > writing format-patch today, then we would..." category, I would say. Yeah. I think it is probably extraneous and would not hurt to remove. But it may not be worth worrying about (it's really the _two_ lines caused by the unconditional newline above that bugs me). -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: untracked file deleted from the master branch, when checked out to it from a local branch
Arup Rakshit writes: > On Tuesday, May 20, 2014 12:06:49 PM you wrote: > >> >> It never "came to the new branch", as it was never version controlled, >> it was an untracked file left behind when you switched branches. >> >> Once you added it to the new branch, change_class, it became a version >> controlled file, > > This is still didn't get it. If an untracked file didn't come in the new > branch, how would I able to add it to stage ? I am not getting this part. You > are right, but I am not able to understand this one, my bad! :( Untracked files and modifications to files in your working directory do not belong to your current branch. This is to allow you, after starting to work on one branch then realizing that the changes and additions you are making do not belong there, to switch to a more appropriate branch at that point without losing your work so far, taking these changes and additions with you to the branch you want to commit your changes to. -- 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 00/19] convert test -a/-o to && and || patch series
Hi, Elia Pinto wrote: > These patch series convert test -a/-o to && and ||. Should this come with a new check in t/check-non-portable-shell.pl so we don't regress in the future? > Elia Pinto (19): [...] > check_bindir|2 +- > contrib/examples/git-clone.sh |2 +- > contrib/examples/git-commit.sh |4 ++-- > contrib/examples/git-merge.sh |4 ++-- > contrib/examples/git-repack.sh |4 ++-- > contrib/examples/git-resolve.sh |2 +- > git-bisect.sh |2 +- > git-mergetool.sh|4 ++-- > git-rebase--interactive.sh |2 +- > git-submodule.sh| 29 + > t/t0025-crlf-auto.sh|6 +++--- > t/t0026-eol-config.sh |8 > t/t4102-apply-rename.sh |2 +- > t/t5000-tar-tree.sh |2 +- > t/t5403-post-checkout-hook.sh |8 > t/t5537-fetch-shallow.sh|2 +- > t/t5538-push-shallow.sh |2 +- > t/t9814-git-p4-rename.sh|4 ++-- > t/test-lib-functions.sh |4 ++-- > 19 files changed, 49 insertions(+), 44 deletions(-) I still think one patch per file is too many patches for this. It would be easier to read with, e.g., whichever ones were most complex as separate patches and the rest (the "easy" ones) as a single patch. Thanks, Jonathan -- 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: untracked file deleted from the master branch, when checked out to it from a local branch
On Tuesday, May 20, 2014 12:06:49 PM you wrote: > > It never "came to the new branch", as it was never version controlled, > it was an untracked file left behind when you switched branches. > > Once you added it to the new branch, change_class, it became a version > controlled file, This is still didn't get it. If an untracked file didn't come in the new branch, how would I able to add it to stage ? I am not getting this part. You are right, but I am not able to understand this one, my bad! :( -- === Regards, Arup Rakshit -- 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: EXT :Re: GIT and large files
>From you response then there is a method to only obtain the Project, Directory >and Files (which could hold 80 GBs of data) and not the rest of the Repository >that contained the full overall Projects? -Original Message- From: Junio C Hamano [mailto:gits...@pobox.com] Sent: Tuesday, May 20, 2014 2:15 PM To: Stewart, Louis (IS) Cc: git@vger.kernel.org Subject: Re: EXT :Re: GIT and large files "Stewart, Louis (IS)" writes: > Thanks for the reply. I just read the intro to GIT and I am concerned > about the part that it will copy the whole repository to the > developers work area. They really just need the one directory and > files under that one directory. The history has TBs of data. Then you will spend time reading, processing and writing TBs of data when you clone, unless your developers do something to limit the history they fetch, e.g. by shallowly cloning. > > Lou > > -Original Message- > From: Junio C Hamano [mailto:gits...@pobox.com] > Sent: Tuesday, May 20, 2014 1:18 PM > To: Stewart, Louis (IS) > Cc: git@vger.kernel.org > Subject: EXT :Re: GIT and large files > > "Stewart, Louis (IS)" writes: > >> Can GIT handle versioning of large 20+ GB files in a directory? > > I think you can "git add" such files, push/fetch histories that contains such > files over the wire, and "git checkout" such files, but naturally reading, > processing and writing 20+GB would take some time. In order to run > operations that need to see the changes, e.g. "git log -p", a real > content-level merge, etc., you would also need sufficient memory because we > do things in-core. -- 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: EXT :Re: GIT and large files
"Stewart, Louis (IS)" writes: > Thanks for the reply. I just read the intro to GIT and I am > concerned about the part that it will copy the whole repository to > the developers work area. They really just need the one directory > and files under that one directory. The history has TBs of data. Then you will spend time reading, processing and writing TBs of data when you clone, unless your developers do something to limit the history they fetch, e.g. by shallowly cloning. > > Lou > > -Original Message- > From: Junio C Hamano [mailto:gits...@pobox.com] > Sent: Tuesday, May 20, 2014 1:18 PM > To: Stewart, Louis (IS) > Cc: git@vger.kernel.org > Subject: EXT :Re: GIT and large files > > "Stewart, Louis (IS)" writes: > >> Can GIT handle versioning of large 20+ GB files in a directory? > > I think you can "git add" such files, push/fetch histories that contains such > files over the wire, and "git checkout" such files, but naturally reading, > processing and writing 20+GB would take some time. In order to run > operations that need to see the changes, e.g. "git log -p", a real > content-level merge, etc., you would also need sufficient memory because we > do things in-core. -- 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 01/19] check_bindir: convert test -a/-o to && and ||
Elia Pinto writes: > The interaction with unary operators and operator precedence > for && and || are better known than -a and -o, and for that > reason we prefer them. Replace all existing instances > of -a and -o to save readers from the burden of thinking > about such things. > > Signed-off-by: Elia Pinto > --- Thanks. As I already said, I think "better known" is much less of an issue than that "-a/-o" is "more error prone", and that is the reason why we may want to do this rewrite. I do not know offhand how busy the tree would be when we can apply these patches post-release without them getting rebased, but the zero-th step before this series may want to be a patch like this. Documentation/CodingGuidelines | 13 + 1 file changed, 13 insertions(+) diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index ef67b53..7864c5b 100644 --- a/Documentation/CodingGuidelines +++ b/Documentation/CodingGuidelines @@ -106,6 +106,19 @@ For shell scripts specifically (not exhaustive): interface translatable. See "Marking strings for translation" in po/README. + - We do not write our "test" command with "-a" and "-o" and use "&&" + or "||" to concatenate multiple "test" commands instead, because + the use of "-a/-o" is often error-prone. E.g. + + test -n "$x" -a "$a" = "$b" + + is buggy and breaks when $x is "=", but + + test -n "$x" && test "$a" = "$b" + + does not have such a problem. + + For C programs: - We use tabs to indent, and interpret tabs as taking up to -- 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 00/19] convert test -a/-o to && and || patch series
Elia Pinto writes: > These patch series convert test -a/-o to && and ||. > > This is the second version. Perhaps slightly off-topic, but has the remainder of the previous $(...) series been perfected and ready to apply? -- 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 v5] format-patch --signature-file
Jeff King writes:
> But one could easily specify a longer, multi-line signature,
> like:
>
> git format-patch --signature='
> this is my long signature
>
> it has multiple lines
> ' ...
>
> We should notice that it already has its own trailing
> newline, and suppress one of ours.
>
> Signed-off-by: Jeff King
> ---
> In the example above, there's also a newline before the signature
> starts. Should we suppress the first one, too?
>
> Also, I'm not clear on the purpose of the extra trailing line in the
> first place. Emails now end with (">" added to show blanks):
>
> > --
> > 2.0.0-rc3...
> >
>
> Is there are a reason for that final blank line?
I actually think these "supress extra LFs" trying to be overly smart
and inviting unnecessary surprises. Unlike log messages people type
(in which we do squash runs of blank lines and other prettifying),
mail-signature string is not something people keep typing, and it
would be better to keep it simple and consistent, i.e. we can
declare that the users who use non-default mail-signature can and
should learn to:
--signature='this is the first line of my long sig
with a blank line and then it ends here'
and be done with it, I think.
The trailing blank after the mail-signature is a different issue. I
think it is safe to remove it and I also think the result may look
better, but at the same time, it is very close to the "if we were
writing format-patch today, then we would..." category, I would say.
> builtin/log.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/log.c b/builtin/log.c
> index 39e8836..5acc048 100644
> --- a/builtin/log.c
> +++ b/builtin/log.c
> @@ -844,8 +844,13 @@ static void gen_message_id(struct rev_info *info, char
> *base)
>
> static void print_signature(void)
> {
> - if (signature && *signature)
> - printf("-- \n%s\n\n", signature);
> + if (!signature || !*signature)
> + return;
> +
> + printf("-- \n%s", signature);
> + if (signature[strlen(signature)-1] != '\n')
> + putchar('\n');
> + putchar('\n');
> }
>
> static void add_branch_description(struct strbuf *buf, const char
> *branch_name)
--
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: format-patch crashes with a huge patchset
Jeff King writes:
> On Mon, May 19, 2014 at 10:35:56PM +0300, Michael S. Tsirkin wrote:
>
>> I tried to fump the whole history of qemu with format-patch.
>> It crashes both with v2.0.0-rc2-21-g6087111
>> and with git 1.8.3.1:
>>
>> ~/opt/libexec/git-core/git-format-patch --follow -o patches/all
>> e63c3dc74bfb90e4522d075d0d5a7600c5145745..
>
> You can't use "--follow" without specifying a single pathspec. Running
> "git log --follow" notices and blocks this, but format-patch doesn't
> (and segfaults later when the follow code assumes there is a pathspec).
>
> I think we need:
Looks sensible. Intrestingly enough, this dates all the way back to
the original 750f7b66 (Finally implement "git log --follow",
2007-06-19).
Re-reading the log message of that commit was amusing for other
reasons, by the way (the most interesting part comes after "One
thing to look out for:" and especially "Put another way:").
> -- >8 --
> Subject: move "--follow needs one pathspec" rule to diff_setup_done
>
> Because of the way "--follow" is implemented, we must have
> exactly one pathspec. "git log" enforces this restriction,
> but other users of the revision traversal code do not. For
> example, "git format-patch --follow" will segfault during
> try_to_follow_renames, as we have no pathspecs at all.
>
> We can push this check down into diff_setup_done, which is
> probably a better place anyway. It is the diff code that
> introduces this restriction, so other parts of the code
> should not need to care themselves.
>
> Reported-by: "Michael S. Tsirkin"
> Signed-off-by: Jeff King
> ---
> I didn't include a test, as I don't think the current behavior is what
> we want in the long run. That is, it would be nice if eventually
> --follow learned to be more flexible. Any test for this would
> necessarily be looking for the opposite of that behavior. But maybe it's
> worth it to just have in the meantime, and anyone who works on --follow
> can rip out the test.
>
> builtin/log.c | 8 ++--
> diff.c| 3 +++
> 2 files changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/builtin/log.c b/builtin/log.c
> index 39e8836..3b6a6bb 100644
> --- a/builtin/log.c
> +++ b/builtin/log.c
> @@ -158,13 +158,9 @@ static void cmd_log_init_finish(int argc, const char
> **argv, const char *prefix,
> if (rev->show_notes)
> init_display_notes(&rev->notes_opt);
>
> - if (rev->diffopt.pickaxe || rev->diffopt.filter)
> + if (rev->diffopt.pickaxe || rev->diffopt.filter ||
> + DIFF_OPT_TST(&rev->diffopt, FOLLOW_RENAMES))
> rev->always_show_header = 0;
> - if (DIFF_OPT_TST(&rev->diffopt, FOLLOW_RENAMES)) {
> - rev->always_show_header = 0;
> - if (rev->diffopt.pathspec.nr != 1)
> - usage("git logs can only follow renames on one pathname
> at a time");
> - }
>
> if (source)
> rev->show_source = 1;
> diff --git a/diff.c b/diff.c
> index f72769a..68bb8c5 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -3325,6 +3325,9 @@ void diff_setup_done(struct diff_options *options)
> }
>
> options->diff_path_counter = 0;
> +
> + if (DIFF_OPT_TST(options, FOLLOW_RENAMES) && options->pathspec.nr != 1)
> + die(_("--follow requires exactly one pathspec"));
> }
>
> static int opt_arg(const char *arg, int arg_short, const char *arg_long, int
> *val)
--
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: bug: autostash is lost after aborted rebase
Matthieu Moy writes: > [ Cc-ing Ramkumar ] > > Karen Etheridge writes: > >> scenario: >> - edit some tracked files; do not add them to the index >> - "git config rebase.autostash true" >> - "git rebase -i HEAD~3" (an autostash will be created) >> - delete the entire buffer and save/exit the editor - this will abort the >> rebase >> >> poof, the autostash is gone (it is not reapplied) -- it must be explicitly >> applied again via the SHA that was printed earlier. > > Indeed. Confirmed, even with pu (I thought I remembered seeing a fix on > the list, but I must have mixed up with something else). Thanks. I see Ram's patch to address this on the list. Will pick it up and queue for post-release, as this is a fairly old breakage dating as far back as v1.8.4, if I am not mistaken. -- 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] Documentation/technical/api-hashmap: Remove source highlighting
Anders Kaseorg writes: >> How bad does the documentation look with the patch applied (I know how >> bad it looks without source-highlight installed)? If it is not too bad, >> then it sounds like a sensible solution to drop the highlight markup >> unconditionally like the patch that started this thread does, taking the >> "common denominator" approach. You seem to agree, and I do not object, >> either. > > Original version with syntax-highlight installed (pretty): > http://web.mit.edu/andersk/Public/api-hashmap/old-highlight.html > > Original version with syntax-highlight missing (corrupted): > http://web.mit.edu/andersk/Public/api-hashmap/old-no-highlight.html > > Patched version (boring but readable): > http://web.mit.edu/andersk/Public/api-hashmap/patched.html Thanks. I've queued the patch for v2.0 and the comparison between the first and the third clearly shows that it is the right thing to do ;-). -- 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: EXT :Re: GIT and large files
Thanks for the reply. I just read the intro to GIT and I am concerned about the part that it will copy the whole repository to the developers work area. They really just need the one directory and files under that one directory. The history has TBs of data. Lou -Original Message- From: Junio C Hamano [mailto:gits...@pobox.com] Sent: Tuesday, May 20, 2014 1:18 PM To: Stewart, Louis (IS) Cc: git@vger.kernel.org Subject: EXT :Re: GIT and large files "Stewart, Louis (IS)" writes: > Can GIT handle versioning of large 20+ GB files in a directory? I think you can "git add" such files, push/fetch histories that contains such files over the wire, and "git checkout" such files, but naturally reading, processing and writing 20+GB would take some time. In order to run operations that need to see the changes, e.g. "git log -p", a real content-level merge, etc., you would also need sufficient memory because we do things in-core. -- 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: GIT and large files
"Stewart, Louis (IS)" writes: > Can GIT handle versioning of large 20+ GB files in a directory? I think you can "git add" such files, push/fetch histories that contains such files over the wire, and "git checkout" such files, but naturally reading, processing and writing 20+GB would take some time. In order to run operations that need to see the changes, e.g. "git log -p", a real content-level merge, etc., you would also need sufficient memory because we do things in-core. -- 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] t6006-*.sh: Fix truncation tests
Alexey Shumkin writes: > AFAIU, Junio already applied my patches (existance of a branch > as/pretty-truncate tells us that). So, we can only send other patches that > fix errors brought with former patches. No, NO, NO The existence of a branch merely means that I saw the patches, and that I thought that the series was not completely useless. In other words, it indicates that I wanted to make sure that I won't forget about the topic, and it was worth my time to create the branch and apply there for that purpose. Please do not read anything more than that. Presense of a topic branch by itself does not say that I _read_ the patches or I thought they did not need reroll. When such a branch is merged to 'next', that means I read the patches myself, or I saw somebody whose judgement I and others in the community trust read them and gave a positive response or an Ack, and that I decided that the topic is in a good enough shape to be worked on further with incremental updates. You are talking about the latter state, but as/pretty-truncate is in the former state. -- 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: GIT and large files
On 5/20/2014 10:37 AM, Stewart, Louis (IS) wrote: Can GIT handle versioning of large 20+ GB files in a directory? Maybe you're looking for git-annex? https://git-annex.branchable.com/ -- .marius -- 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: untracked file deleted from the master branch, when checked out to it from a local branch
On 5/20/2014 11:03 AM, Arup Rakshit wrote: On Tuesday, May 20, 2014 11:56:57 AM you wrote: On 5/20/2014 10:38 AM, Arup Rakshit wrote: I was following some tutorial (http://gitref.org/branching/#merge) - and doing it in my console : Because you never committed the original file to the master branch before you created and switched to the change_class branch. You're missing git add test.rb git commit -m "initial version of test.rb" before you switch branches the first time. Hum, But when I create a new branch from master, then it came to the new branch, but deleted from the master. Shouldn't it also not come to the new local branch also. That's how I expected. It never "came to the new branch", as it was never version controlled, it was an untracked file left behind when you switched branches. Once you added it to the new branch, change_class, it became a version controlled file, and since you moved to a branch without that file (the pristine clean master branch), git removed it. (your version history says that change_class contains test.rb and master does not.) -- .marius -- 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: GIT and large files
> -Original Message- > From: Stewart, Louis (IS) > Sent: Tuesday, May 20, 2014 11:38 > > Can GIT handle versioning of large 20+ GB files in a directory? Are you asking 20 files of a GB each or files 20GB each? A what and why may help with the underlying questions. v/r, Jason Pyeron -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: untracked file deleted from the master branch, when checked out to it from a local branch
On Tuesday, May 20, 2014 11:56:57 AM you wrote: > On 5/20/2014 10:38 AM, Arup Rakshit wrote: > > I was following some tutorial (http://gitref.org/branching/#merge) - and > > doing it in my console : > > Because you never committed the original file to the master branch > before you created and switched to the change_class branch. > > You're missing > git add test.rb > git commit -m "initial version of test.rb" > before you switch branches the first time. Hum, But when I create a new branch from master, then it came to the new branch, but deleted from the master. Shouldn't it also not come to the new local branch also. That's how I expected. -- === Regards, Arup Rakshit -- 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: untracked file deleted from the master branch, when checked out to it from a local branch
On 5/20/2014 10:38 AM, Arup Rakshit wrote: I was following some tutorial (http://gitref.org/branching/#merge) - and doing it in my console : Arup-iMac:arup_git shreyas$ git status # On branch master nothing to commit, working directory clean Arup-iMac:arup_git shreyas$ touch test.rb Arup-iMac:arup_git shreyas$ ls git_1.txttest.rb Arup-iMac:arup_git shreyas$ cat test.rb Arup-iMac:arup_git shreyas$ vi test.rb Arup-iMac:arup_git shreyas$ cat test.rb class Foo def self.bar 12 end end Foo.bar ***HERE I switched to a NEW Branch ... FROM MASTER BRACH WHY THE FILE test.rb DELETED?*** Arup-iMac:arup_git shreyas$ ls git_1.txt Because you never committed the original file to the master branch before you created and switched to the change_class branch. You're missing git add test.rb git commit -m "initial version of test.rb" before you switch branches the first time. -- .marius -- 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: EXT :Re: GIT and large files
The files in question would be in directory containing many files some small
other huge (example: text files, docs,and jpgs are Mbs, but executables and ova
images are GBs, etc).
Lou
From: Gary Fixler [mailto:gfix...@gmail.com]
Sent: Tuesday, May 20, 2014 12:09 PM
To: Stewart, Louis (IS)
Cc: git@vger.kernel.org
Subject: EXT :Re: GIT and large files
Technically yes, but from a practical standpoint, not really. Facebook recently
revealed that they have a 54GB git repo[1], but I doubt it has 20+GB files in
it. I've put 18GB of photos into a git repo, but everything about the process
was fairly painful, and I don't plan to do it again.
Are your files non-mergeable binaries (e.g. videos)? The biggest problem here
is with branching and merging. Conflict resolution with non-mergeable assets
ends up an us-vs-them fight, and I don't understand all of the particulars of
that. From git's standpoint it's simple - you just have to choose one or the
other. From a workflow standpoint, you end up causing trouble if two people
have changed an asset, and both people consider their change important.
Centralized systems get around this problem with locks.
Git could do this, and I've thought about it quite a bit. I work in games - we
have code, but also a lot of binaries, that I'd like to keep in sync with the
code. For awhile I considered suggesting some ideas to this group, but I'm
pretty sure the locking issue makes it a non-starter. The basic idea - skipping
locking for the moment - would be to allow setting git attributes by file type,
file size threshold, folder, etc., to allow git to know that some files are
considered "bigfiles." These could be placed into the objects folder, but I'd
actually prefer they go into a .git/bigfile folder. They'd still be saved as
contents under their hash, but a normal git transfer wouldn't send them. They'd
be in the tree as 'big' or 'bigfile' (instead of 'blob', 'tree', or 'commit'
(for submodules)).
Git would warn you on push that there were bigfiles to send, and you could add,
say, --with-big to also send them, or send them later with, say, `git push
--big`. They'd simply be zipped up and sent over, without any packfile
fanciness. When you clone, you wouldn't get the bigfiles, unless you specified
--with-big, and it would warn you that there are also bigfiles, and tell you
what command to run to get also get them (`git fetch --big`, perhaps). Git
status would always let you know if you were missing bigfiles. I think hopping
around between commits would follow the same strategy, you'd always have to,
e.g. `git checkout foo --with-big`, or `git checkout foo` and then `git update
big` (or whatever - I'm not married to any of these names).
Resolving conflicts on merge would simply have to be up to you. It would be
documented clearly that you're entering weird territory, and that your team has
to deal with bigfiles somehow, perhaps with some suggested strategies ("Pass
the conch?"). I could imagine some strategies for this. Maybe bigfiles require
connecting to a blessed repo to grab the right to make a commit on it. That has
many problems, of course, and now I can feel everyone reading this shifting
uneasily in their seats :)
-g
[1] https://twitter.com/feross/status/459259593630433280
On Tue, May 20, 2014 at 8:37 AM, Stewart, Louis (IS)
wrote:
Can GIT handle versioning of large 20+ GB files in a directory?
Lou Stewart
AOCWS Software Configuration Management
757-269-2388
--
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
N�r��yb�X��ǧv�^�){.n�+ا���ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf
Re: [PATCH] t6006-*.sh: Fix truncation tests
On 20/05/14 17:02, Alexey Shumkin wrote:
> On Tue, May 20, 2014 at 04:01:22PM +0100, Ramsay Jones wrote:
>> On 20/05/14 15:19, Alexey Shumkin wrote:
>>> On Tue, May 20, 2014 at 02:54:20PM +0100, Ramsay Jones wrote:
Signed-off-by: Ramsay Jones
---
Hi Alexey,
If you need to re-roll your 'as/pretty-truncate' branch, could
you please squash the relevant parts of this patch into the
corresponding patches of your patch series. (ie this is a patch
against the head of the current pu branch ...).
Without this patch I get:
$ ./t6006-rev-list-format.sh
ok 1 - setup
ok 2 - format percent
ok 3 - format hash
ok 4 - format tree
ok 5 - format parents
ok 6 - format author
ok 7 - format committer
ok 8 - format encoding
ok 9 - format subject
./t6006-rev-list-format.sh: 152: ./t6006-rev-list-format.sh: Syntax
error: "(" unexpected
FATAL: Unexpected exit with code 2
$
>>> Ooops, my fault.
(if you have bash as /bin/sh you get different but related errors).
The additional quoting suppresses the 'command redirection' errors, etc...
>>> It's strange but I do have Bash as /bin/sh and unfortunately I have no
>>> this error
>>
>> Hmm, I see this:
>>
>> $ bash t6006-rev-list-format.sh -i
> AFAIK, this is not "running Bash as /bin/sh" :)
> Maybe I'm wrong but Bash as /bin/sh is:
> $ ls -l /bin/sh
> lrwxrwxrwx 1 root root 4 May 12 18:35 /bin/sh -> bash
Ah yes, I keep forgetting that bash behaves differently when invoked as 'sh'.
(i.e. it enters 'posix mode' in this case).
Indeed, this is (roughly) equivalent to:
$ bash --posix t6006-rev-list-format.sh
ok 1 - setup
ok 2 - format percent
ok 3 - format hash
...
ok 52 - oneline with empty message
ok 53 - single-character name is parsed correctly
# passed all 53 test(s)
1..53
$
... which works.
Thanks again.
ATB
Ramsay Jones
--
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
untracked file deleted from the master branch, when checked out to it from a local branch
I was following some tutorial (http://gitref.org/branching/#merge) - and doing it in my console : Arup-iMac:arup_git shreyas$ git status # On branch master nothing to commit, working directory clean Arup-iMac:arup_git shreyas$ touch test.rb Arup-iMac:arup_git shreyas$ ls git_1.txttest.rb Arup-iMac:arup_git shreyas$ cat test.rb Arup-iMac:arup_git shreyas$ vi test.rb Arup-iMac:arup_git shreyas$ cat test.rb class Foo def self.bar 12 end end Foo.bar ***HERE I switched to a NEW Branch Arup-iMac:arup_git shreyas$ git checkout -b change_class Switched to a new branch 'change_class' Arup-iMac:arup_git shreyas$ ls git_1.txttest.rb Arup-iMac:arup_git shreyas$ vi test.rb Arup-iMac:arup_git shreyas$ head -1 test.rb class Fooo Arup-iMac:arup_git shreyas$ head -2 test.rb class Fooo def self.bar Arup-iMac:arup_git shreyas$ git commit -am 'changed the class name' # On branch change_class # Untracked files: # (use "git add ..." to include in what will be committed) # #test.rb nothing added to commit but untracked files present (use "git add" to track) Arup-iMac:arup_git shreyas$ git add test.rb Arup-iMac:arup_git shreyas$ git commit -am 'changed the class name' [change_class 2d40033] changed the class name 1 file changed, 7 insertions(+) create mode 100644 test.rb Arup-iMac:arup_git shreyas$ cat test.rb class Fooo def self.bar 12 end end Fooo.bar Arup-iMac:arup_git shreyas$ git checkout master Switched to branch 'master' Arup-iMac:arup_git shreyas$ git mv test.rb ruby.rb fatal: bad source, source=test.rb, destination=ruby.rb Arup-iMac:arup_git shreyas$ git mv -h usage: git mv [options] ... -v, --verbose be verbose -n, --dry-run dry run -f, --force force move/rename even if target exists -kskip move/rename errors |--| FROM MASTER BRACH WHY THE FILE test.rb DELETED?*** Arup-iMac:arup_git shreyas$ ls git_1.txt Arup-iMac:arup_git shreyas$ -- === Regards, Arup Rakshit -- 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] t6006-*.sh: Fix truncation tests
On Tue, May 20, 2014 at 04:01:22PM +0100, Ramsay Jones wrote:
> On 20/05/14 15:19, Alexey Shumkin wrote:
> > On Tue, May 20, 2014 at 02:54:20PM +0100, Ramsay Jones wrote:
> >>
> >> Signed-off-by: Ramsay Jones
> >> ---
> >>
> >> Hi Alexey,
> >>
> >> If you need to re-roll your 'as/pretty-truncate' branch, could
> >> you please squash the relevant parts of this patch into the
> >> corresponding patches of your patch series. (ie this is a patch
> >> against the head of the current pu branch ...).
> >>
> >> Without this patch I get:
> >>
> >> $ ./t6006-rev-list-format.sh
> >> ok 1 - setup
> >> ok 2 - format percent
> >> ok 3 - format hash
> >> ok 4 - format tree
> >> ok 5 - format parents
> >> ok 6 - format author
> >> ok 7 - format committer
> >> ok 8 - format encoding
> >> ok 9 - format subject
> >> ./t6006-rev-list-format.sh: 152: ./t6006-rev-list-format.sh: Syntax
> >> error: "(" unexpected
> >> FATAL: Unexpected exit with code 2
> >> $
> > Ooops, my fault.
> >>
> >> (if you have bash as /bin/sh you get different but related errors).
> >> The additional quoting suppresses the 'command redirection' errors, etc...
> > It's strange but I do have Bash as /bin/sh and unfortunately I have no
> > this error
>
> Hmm, I see this:
>
> $ bash t6006-rev-list-format.sh -i
AFAIK, this is not "running Bash as /bin/sh" :)
Maybe I'm wrong but Bash as /bin/sh is:
$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 May 12 18:35 /bin/sh -> bash
But it does not matter here much, you've noticed my foolish mistake :)
> ok 1 - setup
> ok 2 - format percent
> ok 3 - format hash
> ok 4 - format tree
> ok 5 - format parents
> ok 6 - format author
> ok 7 - format committer
> ok 8 - format encoding
> ok 9 - format subject
> t6006-rev-list-format.sh: line 152: 20,trunc: command not found
> not ok 10 - format subject-truncated
> #
> # git rev-list --pretty=format:'%/dev/fd/63%s' master
> >output.subject-truncated &&
> # test_cmp expect.subject-truncated
> output.subject-truncated
> #
> $
>
> (Since I'm on Linux Mint, my /bin/sh is dash, which produces the output in my
> previous mail).
>
> ATB,
> Ramsay Jones
>
>
>
--
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
GIT and large files
Can GIT handle versioning of large 20+ GB files in a directory? Lou Stewart AOCWS Software Configuration Management 757-269-2388 -- 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] remote-helpers: point at their upstream repositories
On Tue, May 20, 2014 at 4:55 PM, Michael Haggerty wrote: > On 05/19/2014 11:31 PM, Junio C Hamano wrote: >> Felipe Contreras writes: >>> Where is git-imerge packaged? >> >> I didn't see it on the archive the said Ubuntu box slurps from, but >> I did not check all the other distros. >> >> Michael, do you know what distro folks are doing with imerge? For >> the purpose of this thread, "I do not follow distros, and I do not >> know" is a perfectly acceptable answer, but it would be very >> relevant if your answer is "I suggested these distros to include it, >> but so far they have been uncooperative and I haven't had much >> success". > > I haven't heard of any Linux distros that have git-imerge packages. I > just searched the package archives for Debian, Fedora, Gentoo, and Arch > without finding it. FWIW; someone has made an AUR package (a user-contributed Arch package recipe) for git-imerge: https://aur.archlinux.org/packages/git-imerge-git/ ...Johan -- Johan Herland, www.herland.net -- 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 3/4] rebase: test ack
"Michael S. Tsirkin" writes: > Just to clarify I can post v2 of 4/4 without reposting 1-3 since they > are queued? If you need to update anything queued only on 'pu' but not yet in 'next', it is customary to resend the whole for everybody to see (what is already in 'next' should only be built upon incrementally and not updated with replacement patches), while noting which ones are the same as before. Christian Couder has been doing it nicely in his recent rerolls (if the series were not in 'next', that is). 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 v2] format-patch --signature-file
Jeff King writes: > You could do: > > #define DEFAULT_SIGNATURE git_version_string > static const char *signature = DEFAULT_SIGNATURE; > > ... > > if (signature == DEFAULT_SIGNATURE) > ... > > but maybe that is getting a little unwieldy, considering the scope of > the original problem. I agree. It is an invitation for doing something like #define DEFAULT_SIGNATURE "-- \nfoo bar\n" which defeats the purpose. I have an unrelated and larger design level suggestion, but it may be better for me to refrain from sending it during the -rc freeze. -- 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] t6006 (rev-list-format): quote format strings to avoid error on some shells
On 20/05/14 15:48, Alexey Shumkin wrote:
> Added in 0a144b3 (t4205, t6006: add failing tests for the case when
> i18n.logOutputEncoding is set, 2014-05-19) tests give no error
> (somehow) with Bash as /bin/sh but fail for some other shells.
>
> Quote format strings to avoid errors.
>
> Signed-off-by: Alexey Shumkin
> Suggested-by: Ramsay Jones
> ---
> t/t6006-rev-list-format.sh | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
> index c6e9a73..19434ad 100755
> --- a/t/t6006-rev-list-format.sh
> +++ b/t/t6006-rev-list-format.sh
> @@ -149,7 +149,7 @@ commit $head1
> $added
> EOF
>
> -test_format subject-truncated %<($truncate_count,trunc)%s < +test_format subject-truncated "%<($truncate_count,trunc)%s" < commit $head2
> changed (ge${changed_utf8_part}ndert)..
> commit $head1
> @@ -259,7 +259,7 @@ commit $head1
> $added_iso88591
> EOF
>
> -test_format complex-subject-trunc %<($truncate_count,trunc)%s < +test_format complex-subject-trunc "%<($truncate_count,trunc)%s" < commit $head3
> Test printing of c..
> commit $head2
> @@ -268,7 +268,7 @@ commit $head1
> added (hinzugef${added_utf8_part_iso88591}gt..
> EOF
>
> -test_format complex-subject-mtrunc %<($truncate_count,mtrunc)%s < +test_format complex-subject-mtrunc "%<($truncate_count,mtrunc)%s" < commit $head3
> Test prin..ex bodies
> commit $head2
> @@ -277,7 +277,7 @@ commit $head1
> added (hi..f${added_utf8_part_iso88591}gt) foo
> EOF
>
> -test_format complex-subject-ltrunc %<($truncate_count,ltrunc)%s < +test_format complex-subject-ltrunc "%<($truncate_count,ltrunc)%s" < commit $head3
> .. of complex bodies
> commit $head2
> @@ -314,7 +314,7 @@ commit $head1
> $added
> EOF
>
> -test_format complex-subject-commitencoding-unset-trunc
> %<($truncate_count,trunc)%s < +test_format complex-subject-commitencoding-unset-trunc
> "%<($truncate_count,trunc)%s" < commit $head3
> Test printing of c..
> commit $head2
> @@ -323,7 +323,7 @@ commit $head1
> added (hinzugef${added_utf8_part}gt..
> EOF
>
> -test_format complex-subject-commitencoding-unset-mtrunc
> %<($truncate_count,mtrunc)%s < +test_format complex-subject-commitencoding-unset-mtrunc
> "%<($truncate_count,mtrunc)%s" < commit $head3
> Test prin..ex bodies
> commit $head2
> @@ -332,7 +332,7 @@ commit $head1
> added (hi..f${added_utf8_part}gt) foo
> EOF
>
> -test_format complex-subject-commitencoding-unset-ltrunc
> %<($truncate_count,ltrunc)%s < +test_format complex-subject-commitencoding-unset-ltrunc
> "%<($truncate_count,ltrunc)%s" < commit $head3
> .. of complex bodies
> commit $head2
>
Yep, actually using string quotes works just as well! :-P
Thanks!
ATB,
Ramsay Jones
--
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] t6006-*.sh: Fix truncation tests
On 20/05/14 15:19, Alexey Shumkin wrote:
> On Tue, May 20, 2014 at 02:54:20PM +0100, Ramsay Jones wrote:
>>
>> Signed-off-by: Ramsay Jones
>> ---
>>
>> Hi Alexey,
>>
>> If you need to re-roll your 'as/pretty-truncate' branch, could
>> you please squash the relevant parts of this patch into the
>> corresponding patches of your patch series. (ie this is a patch
>> against the head of the current pu branch ...).
>>
>> Without this patch I get:
>>
>> $ ./t6006-rev-list-format.sh
>> ok 1 - setup
>> ok 2 - format percent
>> ok 3 - format hash
>> ok 4 - format tree
>> ok 5 - format parents
>> ok 6 - format author
>> ok 7 - format committer
>> ok 8 - format encoding
>> ok 9 - format subject
>> ./t6006-rev-list-format.sh: 152: ./t6006-rev-list-format.sh: Syntax error:
>> "(" unexpected
>> FATAL: Unexpected exit with code 2
>> $
> Ooops, my fault.
>>
>> (if you have bash as /bin/sh you get different but related errors).
>> The additional quoting suppresses the 'command redirection' errors, etc...
> It's strange but I do have Bash as /bin/sh and unfortunately I have no
> this error
Hmm, I see this:
$ bash t6006-rev-list-format.sh -i
ok 1 - setup
ok 2 - format percent
ok 3 - format hash
ok 4 - format tree
ok 5 - format parents
ok 6 - format author
ok 7 - format committer
ok 8 - format encoding
ok 9 - format subject
t6006-rev-list-format.sh: line 152: 20,trunc: command not found
not ok 10 - format subject-truncated
#
# git rev-list --pretty=format:'%/dev/fd/63%s' master
>output.subject-truncated &&
# test_cmp expect.subject-truncated
output.subject-truncated
#
$
(Since I'm on Linux Mint, my /bin/sh is dash, which produces the output in my
previous mail).
ATB,
Ramsay Jones
--
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] remote-helpers: point at their upstream repositories
On 05/19/2014 11:31 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> Junio C Hamano wrote: >>> >>> After looking at the reverse-depends list of packages, my faith is >>> strengthened in that the Git ecosystem is truly maturing and useful >>> third-party plug-ins will be picked up by distro packagers. >> >> Where is git-imerge packaged? > > I didn't see it on the archive the said Ubuntu box slurps from, but > I did not check all the other distros. > > Michael, do you know what distro folks are doing with imerge? For > the purpose of this thread, "I do not follow distros, and I do not > know" is a perfectly acceptable answer, but it would be very > relevant if your answer is "I suggested these distros to include it, > but so far they have been uncooperative and I haven't had much > success". I haven't heard of any Linux distros that have git-imerge packages. I just searched the package archives for Debian, Fedora, Gentoo, and Arch without finding it. OTOH I haven't suggested it to any package maintainers nor done much to promote it after the initial flurry of publicity after GitMerge 2013 (blog posts, talk, and interview on GitMinutes). Oh yeah, there's also this animated GIF here [1] :-) Michael [1] https://github.com/blog/1691-michael-haggerty-is-a-githubber -- 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] t6006 (rev-list-format): quote format strings to avoid error on some shells
Added in 0a144b3 (t4205, t6006: add failing tests for the case when i18n.logOutputEncoding is set, 2014-05-19) tests give no error (somehow) with Bash as /bin/sh but fail for some other shells. Quote format strings to avoid errors. Signed-off-by: Alexey Shumkin Suggested-by: Ramsay Jones --- t/t6006-rev-list-format.sh | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh index c6e9a73..19434ad 100755 --- a/t/t6006-rev-list-format.sh +++ b/t/t6006-rev-list-format.sh @@ -149,7 +149,7 @@ commit $head1 $added EOF -test_format subject-truncated %<($truncate_count,trunc)%s
Re: [PATCH 3/4] rebase: test ack
On Mon, May 19, 2014 at 02:34:26PM -0700, Junio C Hamano wrote: > "Michael S. Tsirkin" writes: > > > test ack! handling > > > > Signed-off-by: Michael S. Tsirkin > > Will queue with this squashed in. > > 4/4 seems to have some style issues as well, but I didn't look very > closely. > > Thanks. Just to clarify I can post v2 of 4/4 without reposting 1-3 since they are queued? > t/t3415-rebase-autosquash.sh | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/t/t3415-rebase-autosquash.sh b/t/t3415-rebase-autosquash.sh > index 9d7db13..dcdba6f 100755 > --- a/t/t3415-rebase-autosquash.sh > +++ b/t/t3415-rebase-autosquash.sh > @@ -75,18 +75,18 @@ test_expect_success 'auto squash (option)' ' > ' > > test_expect_success 'auto ack' ' > - ack="Acked-by: xyz" > - msg=$(test_write_lines "ack! first commit" "" "$ack") > + ack="Acked-by: xyz" && > + msg=$(test_write_lines "ack! first commit" "" "$ack") && > git reset --hard base && > git commit --allow-empty -m "$msg" -- && > git tag ack && > test_tick && > git rebase --autosquash -i HEAD^^^ && > git log --oneline >actual && > - git show -s first-commit | grep -v ^commit > expected-msg && > - echo "$ack" >> expected-msg && > - git show -s HEAD^ | grep -v ^commit > actual-msg && > - diff actual-msg expected-msg > + git show -s first-commit | grep -v ^commit >expected-msg && > + echo "$ack" >>expected-msg && > + git show -s HEAD^ | grep -v ^commit >actual-msg && > + test_cmp actual-msg expected-msg > ' > > test_expect_success 'auto squash (config)' ' -- 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 10/19] git-submodule.sh: convert test -a/-o to && and ||
Am 5/20/2014 15:50, schrieb Elia Pinto:
> # If we don't already have a -f flag and the submodule
> has never been checked out
> - if test -z "$subsha1" -a -z "$force"
> + if test -z "$subsha1" || test -z "$force"
Should not be ||, but &&!
> while read mod_src mod_dst sha1_src sha1_dst status sm_path
> do
> # Always show modules deleted or type-changed
> (blob<->module)
> - test $status = D -o $status = T && echo "$sm_path" &&
> continue
> + {
> + test "$status" = D ||
> + test "$status" = T
> + } &&
> + echo "$sm_path"
> + && continue
As Matthieu noted, this is incorrect. It's not just a style violation,
it's a syntax error. Why did your test runs not hickup on that?
In this case you could even leave the original code structure without
changing the meaning:
test $status = D || test $status = T && echo "$sm_path"
&& continue
But a better idiom is
case "$status" in
[DT])
printf '%s\n' "$sm_path" &&
continue
esac
> @@ -1233,7 +1238,7 @@ cmd_status()
> say "U$sha1 $displaypath"
> continue
> fi
> - if test -z "$url" || ! test -d "$sm_path"/.git -o -f
> "$sm_path"/.git
> + if test -z "$url" || ! test -d "$sm_path"/.git || test -f
> "$sm_path"/.git
Wrong grouping. This could be more correct (I didn't test):
if test -z "$url" ||
{
! test -d "$sm_path"/.git &&
! test -f "$sm_path"/.git
}
-- 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: [PATCH] t6006-*.sh: Fix truncation tests
On Tue, May 20, 2014 at 06:19:36PM +0400, Alexey Shumkin wrote:
> On Tue, May 20, 2014 at 02:54:20PM +0100, Ramsay Jones wrote:
> >
> > Signed-off-by: Ramsay Jones
> > ---
> >
> > Hi Alexey,
> >
> > If you need to re-roll your 'as/pretty-truncate' branch, could
> > you please squash the relevant parts of this patch into the
> > corresponding patches of your patch series. (ie this is a patch
> > against the head of the current pu branch ...).
> >
> > Without this patch I get:
> >
> > $ ./t6006-rev-list-format.sh
> > ok 1 - setup
> > ok 2 - format percent
> > ok 3 - format hash
> > ok 4 - format tree
> > ok 5 - format parents
> > ok 6 - format author
> > ok 7 - format committer
> > ok 8 - format encoding
> > ok 9 - format subject
> > ./t6006-rev-list-format.sh: 152: ./t6006-rev-list-format.sh: Syntax
> > error: "(" unexpected
> > FATAL: Unexpected exit with code 2
> > $
> Ooops, my fault.
> >
> > (if you have bash as /bin/sh you get different but related errors).
> > The additional quoting suppresses the 'command redirection' errors, etc...
> It's strange but I do have Bash as /bin/sh and unfortunately I have no
> this error
>
> AFAIU, Junio already applied my patches (existance of a branch
> as/pretty-truncate tells us that). So, we can only send other patches that
> fix errors brought with former patches.
> You can send, too.
> >
> > Thanks.
> >
> > ATB
> > Ramsay Jones
> >
> > t/t6006-rev-list-format.sh | 14 +++---
> > 1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
> > index 9bc089b..e1dec3e 100755
> > --- a/t/t6006-rev-list-format.sh
> > +++ b/t/t6006-rev-list-format.sh
> > @@ -149,7 +149,7 @@ commit $head1
> > $added
> > EOF
> >
> > -test_format subject-truncated %<($truncate_count,trunc)%s < > +test_format subject-truncated %\<\($truncate_count,trunc\)%s
Re: [PATCH] t6006-*.sh: Fix truncation tests
On Tue, May 20, 2014 at 02:54:20PM +0100, Ramsay Jones wrote:
>
> Signed-off-by: Ramsay Jones
> ---
>
> Hi Alexey,
>
> If you need to re-roll your 'as/pretty-truncate' branch, could
> you please squash the relevant parts of this patch into the
> corresponding patches of your patch series. (ie this is a patch
> against the head of the current pu branch ...).
>
> Without this patch I get:
>
> $ ./t6006-rev-list-format.sh
> ok 1 - setup
> ok 2 - format percent
> ok 3 - format hash
> ok 4 - format tree
> ok 5 - format parents
> ok 6 - format author
> ok 7 - format committer
> ok 8 - format encoding
> ok 9 - format subject
> ./t6006-rev-list-format.sh: 152: ./t6006-rev-list-format.sh: Syntax error:
> "(" unexpected
> FATAL: Unexpected exit with code 2
> $
Ooops, my fault.
>
> (if you have bash as /bin/sh you get different but related errors).
> The additional quoting suppresses the 'command redirection' errors, etc...
It's strange but I do have Bash as /bin/sh and unfortunately I have no
this error
AFAIU, Junio already applied my patches (existance of a branch
as/pretty-truncate tells us that). So, we can only send other patches that
fix errors brought with former patches.
You can send, too.
>
> Thanks.
>
> ATB
> Ramsay Jones
>
> t/t6006-rev-list-format.sh | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
> index 9bc089b..e1dec3e 100755
> --- a/t/t6006-rev-list-format.sh
> +++ b/t/t6006-rev-list-format.sh
> @@ -149,7 +149,7 @@ commit $head1
> $added
> EOF
>
> -test_format subject-truncated %<($truncate_count,trunc)%s < +test_format subject-truncated %\<\($truncate_count,trunc\)%s < commit $head2
> changed (ge${changed_utf8_part}ndert)..
> commit $head1
> @@ -256,7 +256,7 @@ commit $head1
> $added_iso88591
> EOF
>
> -test_format complex-subject-trunc %<($truncate_count,trunc)%s < +test_format complex-subject-trunc %\<\($truncate_count,trunc\)%s < commit $head3
> Test printing of c..
> commit $head2
> @@ -265,7 +265,7 @@ commit $head1
> added (hinzugef${added_utf8_part_iso88591}gt..
> EOF
>
> -test_format complex-subject-mtrunc %<($truncate_count,mtrunc)%s < +test_format complex-subject-mtrunc %\<\($truncate_count,mtrunc\)%s < commit $head3
> Test prin..ex bodies
> commit $head2
> @@ -274,7 +274,7 @@ commit $head1
> added (hi..f${added_utf8_part_iso88591}gt) foo
> EOF
>
> -test_format complex-subject-ltrunc %<($truncate_count,ltrunc)%s < +test_format complex-subject-ltrunc %\<\($truncate_count,ltrunc\)%s < commit $head3
> .. of complex bodies
> commit $head2
> @@ -311,7 +311,7 @@ commit $head1
> $added
> EOF
>
> -test_format complex-subject-commitencoding-unset-trunc
> %<($truncate_count,trunc)%s < +test_format complex-subject-commitencoding-unset-trunc
> %\<\($truncate_count,trunc\)%s < commit $head3
> Test printing of c..
> commit $head2
> @@ -320,7 +320,7 @@ commit $head1
> added (hinzugef${added_utf8_part}gt..
> EOF
>
> -test_format complex-subject-commitencoding-unset-mtrunc
> %<($truncate_count,mtrunc)%s < +test_format complex-subject-commitencoding-unset-mtrunc
> %\<\($truncate_count,mtrunc\)%s < commit $head3
> Test prin..ex bodies
> commit $head2
> @@ -329,7 +329,7 @@ commit $head1
> added (hi..f${added_utf8_part}gt) foo
> EOF
>
> -test_format complex-subject-commitencoding-unset-ltrunc
> %<($truncate_count,ltrunc)%s < +test_format complex-subject-commitencoding-unset-ltrunc
> %\<\($truncate_count,ltrunc\)%s < commit $head3
> .. of complex bodies
> commit $head2
> --
> 1.9.0
--
Alexey Shumkin
E-mail: alex.crez...@gmail.com
ICQ: 118001447
Jabber (GoogleTalk): alex.crez...@gmail.com
Skype: crezoff
--
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 00/19] convert test -a/-o to && and || patch series
Elia Pinto writes: > Elia Pinto (19): I went through the series (not very thoroughly) and it sounds good to me. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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 10/19] git-submodule.sh: convert test -a/-o to && and ||
Elia Pinto writes:
> - test $status = D -o $status = T && echo "$sm_path" &&
> continue
> + {
> + test "$status" = D ||
> + test "$status" = T
> + } &&
> + echo "$sm_path"
> + && continue
We usually write the && at the end of the line, hence that would be
echo "$sm_path" &&
continue
(shouldn't block the patch, but you may change if you need to resend)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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] t6006-*.sh: Fix truncation tests
Signed-off-by: Ramsay Jones
---
Hi Alexey,
If you need to re-roll your 'as/pretty-truncate' branch, could
you please squash the relevant parts of this patch into the
corresponding patches of your patch series. (ie this is a patch
against the head of the current pu branch ...).
Without this patch I get:
$ ./t6006-rev-list-format.sh
ok 1 - setup
ok 2 - format percent
ok 3 - format hash
ok 4 - format tree
ok 5 - format parents
ok 6 - format author
ok 7 - format committer
ok 8 - format encoding
ok 9 - format subject
./t6006-rev-list-format.sh: 152: ./t6006-rev-list-format.sh: Syntax error:
"(" unexpected
FATAL: Unexpected exit with code 2
$
(if you have bash as /bin/sh you get different but related errors).
The additional quoting suppresses the 'command redirection' errors, etc...
Thanks.
ATB
Ramsay Jones
t/t6006-rev-list-format.sh | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
index 9bc089b..e1dec3e 100755
--- a/t/t6006-rev-list-format.sh
+++ b/t/t6006-rev-list-format.sh
@@ -149,7 +149,7 @@ commit $head1
$added
EOF
-test_format subject-truncated %<($truncate_count,trunc)%s
[PATCH 16/19] t/t5537-fetch-shallow.sh: convert test -a/-o to && and ||
The interaction with unary operators and operator precedence for && and || are better known than -a and -o, and for that reason we prefer them. Replace all existing instances of -a and -o to save readers from the burden of thinking about such things. Signed-off-by: Elia Pinto --- t/t5537-fetch-shallow.sh |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t5537-fetch-shallow.sh b/t/t5537-fetch-shallow.sh index be951a4..2c75730 100755 --- a/t/t5537-fetch-shallow.sh +++ b/t/t5537-fetch-shallow.sh @@ -173,7 +173,7 @@ EOF ) ' -if test -n "$NO_CURL" -o -z "$GIT_TEST_HTTPD"; then +if test -n "$NO_CURL" || test -z "$GIT_TEST_HTTPD"; then say 'skipping remaining tests, git built without http support' test_done fi -- 1.7.10.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 03/19] contrib/examples/git-commit.sh: convert test -a/-o to && and ||
The interaction with unary operators and operator precedence
for && and || are better known than -a and -o, and for that
reason we prefer them. Replace all existing instances
of -a and -o to save readers from the burden of thinking
about such things.
Signed-off-by: Elia Pinto
---
contrib/examples/git-commit.sh |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/examples/git-commit.sh b/contrib/examples/git-commit.sh
index 5cafe2e..934505b 100755
--- a/contrib/examples/git-commit.sh
+++ b/contrib/examples/git-commit.sh
@@ -51,7 +51,7 @@ run_status () {
export GIT_INDEX_FILE
fi
- if test "$status_only" = "t" -o "$use_status_color" = "t"; then
+ if test "$status_only" = "t" || test "$use_status_color" = "t"; then
color=
else
color=--nocolor
@@ -296,7 +296,7 @@ t,,,[1-9]*)
die "No paths with -i does not make sense." ;;
esac
-if test ! -z "$templatefile" -a -z "$log_given"
+if test ! -z "$templatefile" && test -z "$log_given"
then
if test ! -f "$templatefile"
then
--
1.7.10.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 15/19] t/t5403-post-checkout-hook.sh: convert test -a/-o to && and ||
The interaction with unary operators and operator precedence
for && and || are better known than -a and -o, and for that
reason we prefer them. Replace all existing instances
of -a and -o to save readers from the burden of thinking
about such things.
Signed-off-by: Elia Pinto
---
t/t5403-post-checkout-hook.sh |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/t/t5403-post-checkout-hook.sh b/t/t5403-post-checkout-hook.sh
index 1753ef2..fc898c9 100755
--- a/t/t5403-post-checkout-hook.sh
+++ b/t/t5403-post-checkout-hook.sh
@@ -39,7 +39,7 @@ test_expect_success 'post-checkout receives the right
arguments with HEAD unchan
old=$(awk "{print \$1}" clone1/.git/post-checkout.args) &&
new=$(awk "{print \$2}" clone1/.git/post-checkout.args) &&
flag=$(awk "{print \$3}" clone1/.git/post-checkout.args) &&
- test $old = $new -a $flag = 1
+ test $old = $new && test $flag = 1
'
test_expect_success 'post-checkout runs as expected ' '
@@ -52,7 +52,7 @@ test_expect_success 'post-checkout args are correct with git
checkout -b ' '
old=$(awk "{print \$1}" clone1/.git/post-checkout.args) &&
new=$(awk "{print \$2}" clone1/.git/post-checkout.args) &&
flag=$(awk "{print \$3}" clone1/.git/post-checkout.args) &&
- test $old = $new -a $flag = 1
+ test $old = $new && test $flag = 1
'
test_expect_success 'post-checkout receives the right args with HEAD changed '
'
@@ -60,7 +60,7 @@ test_expect_success 'post-checkout receives the right args
with HEAD changed ' '
old=$(awk "{print \$1}" clone2/.git/post-checkout.args) &&
new=$(awk "{print \$2}" clone2/.git/post-checkout.args) &&
flag=$(awk "{print \$3}" clone2/.git/post-checkout.args) &&
- test $old != $new -a $flag = 1
+ test $old != $new && test $flag = 1
'
test_expect_success 'post-checkout receives the right args when not switching
branches ' '
@@ -68,7 +68,7 @@ test_expect_success 'post-checkout receives the right args
when not switching br
old=$(awk "{print \$1}" clone2/.git/post-checkout.args) &&
new=$(awk "{print \$2}" clone2/.git/post-checkout.args) &&
flag=$(awk "{print \$3}" clone2/.git/post-checkout.args) &&
- test $old = $new -a $flag = 0
+ test $old = $new && test $flag = 0
'
if test "$(git config --bool core.filemode)" = true; then
--
1.7.10.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 11/19] t/t0025-crlf-auto.sh: convert test -a/-o to && and ||
The interaction with unary operators and operator precedence for && and || are better known than -a and -o, and for that reason we prefer them. Replace all existing instances of -a and -o to save readers from the burden of thinking about such things. Signed-off-by: Elia Pinto --- t/t0025-crlf-auto.sh |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/t/t0025-crlf-auto.sh b/t/t0025-crlf-auto.sh index f5f67a6..a13fc56 100755 --- a/t/t0025-crlf-auto.sh +++ b/t/t0025-crlf-auto.sh @@ -36,7 +36,7 @@ test_expect_success 'default settings cause no changes' ' onediff=`git diff one` && twodiff=`git diff two` && threediff=`git diff three` && - test -z "$onediff" -a -z "$twodiff" -a -z "$threediff" + test -z "$onediff" && test -z "$twodiff" && test -z "$threediff" ' test_expect_success 'crlf=true causes a CRLF file to be normalized' ' @@ -111,7 +111,7 @@ test_expect_success 'autocrlf=true does not normalize CRLF files' ' onediff=`git diff one` && twodiff=`git diff two` && threediff=`git diff three` && - test -z "$onediff" -a -z "$twodiff" -a -z "$threediff" + test -z "$onediff" && test -z "$twodiff" && test -z "$threediff" ' test_expect_success 'text=auto, autocrlf=true _does_ normalize CRLF files' ' @@ -126,7 +126,7 @@ test_expect_success 'text=auto, autocrlf=true _does_ normalize CRLF files' ' onediff=`git diff one` && twodiff=`git diff two` && threediff=`git diff three` && - test -z "$onediff" -a -n "$twodiff" -a -z "$threediff" + test -z "$onediff" && test -n "$twodiff" && test -z "$threediff" ' test_expect_success 'text=auto, autocrlf=true does not normalize binary files' ' -- 1.7.10.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 14/19] t/t5000-tar-tree.sh: convert test -a/-o to && and ||
The interaction with unary operators and operator precedence
for && and || are better known than -a and -o, and for that
reason we prefer them. Replace all existing instances
of -a and -o to save readers from the burden of thinking
about such things.
Signed-off-by: Elia Pinto
---
t/t5000-tar-tree.sh |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index 1cf0a4e..4b57cbd 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -72,7 +72,7 @@ check_tar() {
for header in *.paxheader
do
data=${header%.paxheader}.data &&
- if test -h $data -o -e $data
+ if test -h $data || test -e $data
then
path=$(get_pax_header $header path) &&
if test -n "$path"
--
1.7.10.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
