Re: Improving auto conflict resolving while merge
On Mon, Sep 07, 2015 at 08:15:46PM +0300, KES wrote: > 1. git clone https://github.com/KES777/Plack > [...] > At this point I have same changes on master and branch. > master head is d095870 > branch head is a3db36a > fork point is 0a5ff84 I tried re-merging d095870 and a3db36a. I think what is happening is that even though you have many similar hunks near each, there are still some differences in the area, and they are close enough that the merge isn't sure what is right. We err on the side of conservatism with conflicts, because it's hard to say what is dependent and what is not. For example, if you have the content: foo(); bar(); baz(); and one side makes it: foo(); x = 1; bar(); baz(); and the other side does: foo(); bar(); y = 2; baz(); you _could_ argue that those changes are independent (and write a merge algorithm that silently merges them). They're touching two different lines, and doing two different things. But it's close enough that there's a good chance the two need to be reconciled, and a human should at least take a look. I think what further confuses things in your case is that the content added by the two sides contains a lot of similar lines (because of the cherry-pick), and the default "merge" conflict-markers try to shrink the size of the conflicts. Try running: git config merge.conflictstyle diff3 and re-doing the merge. It will give you a much better sense of how git is breaking down the hunks (because it does not try to shrink the conflicts, and because it shows the base content for each conflict). -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: [PATCH v3 00/11] Make "local" orthogonal to date format
On Thu, Sep 03, 2015 at 10:48:50PM +0100, John Keeping wrote: > Since version 2 there are four new preparatory patches which remove > lists of date formats from documentation in favour of referring to the > detailed list in git-rev-list(1) or git-log(1) (both generated from > Documentation/rev-list-options.txt) depending on whether the page in > question is plumbing/porcelain. This version looks good to me. It turned out to be a bigger job than we expected at first; thanks for seeing it through. > In patch 7 (date: check for "local" before anything else), we no longer > reject "relative-local" and "raw-local" now prints the user's local > timezone offset. The error message for invalid formats that are > prefixed with a valid format name is now the same as that if there is no > valid prefix. That sounds OK. We have enough information in our parsing state to say "I understood the 'iso8601', but '-foobar' did not make any sense to me". But it's doubtful that would ever come up in practice. -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
[Feature request] help.autocorrect suggestion with Y/N
When you type git clone https://repo.git now you get git: 'glone' is not a git command. See 'git --help'. Did you mean this? clone It would be handsome if you could say "Yes" to this question so you don't have to manually correct your last command like: Did you mean this? clone [Y/n] -- 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: Conditionally define vars to improve portability
> On Sep 8, 2015, at 03:30, Jeff King wrote: > > On Mon, Sep 07, 2015 at 02:51:42PM -0300, Renato Botelho wrote: > >> Default variables used to build are set using = on Makefile, (e.g. CC, >> INSTALL, CFLAGS, …). GNU make overwrite these values if it’s passed as >> an argument (make CC=clang) and it works as expected. >> >> Default method of passing arguments for make operations on FreeBSD >> ports tree is using environment variables instead of make arguments, >> then we have CC set on env before call gmake. Today these values are >> ignored by git Makefile, and we ended up patching Makefile replacing = >> by ?= on variable assignments [1]. > > Hmm. I can't really think of a downside to doing so, unless we expect > users to have things like CC set in the environment and _not_ want them > to bleed through to our build. > > But doesn't "gmake -e" solve your problem without a patch? Good idea, let me try it… :) -- Renato Botelho -- 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] git_connect: clarify conn->use_shell flag
On Sat, Sep 05, 2015 at 03:50:08PM +0200, Giuseppe Bilotta wrote:
> which matches my previous findings in that the problem was
> GIT_WORK_TREE being leaked. Since setting GIT_WORK_TREE when setting
> GIT_DIR is correct, the solution is indeed to clear GIT_* environment
> variables for ssh, as you propose. I tested your patch and indeed it
> fixes my problem.
Yeah, that makes sense.
> I still don't understand why you cannot replicate the issue on your
> side. One thing that is _extremely_ important in reproducing the
> problem is that the leaked GIT_WORK_TREE point to a non-existent (or
> otherwise inaccessible) directory in the server machine. For example,
> on my first attempt to reproduce I was trying to use my clone of the
> git repo, and it wouldn't work because I _did_ have a ~/src/git on
> both machines, even though I was pushing to a
> remote.machine:/tmp/test.git
I checked that the path in question is not accessible in my test setup.
I'm also confused why it doesn't replicate for me.
I noticed that your original report shows receive-pack behaving well,
but the child unpack-objects complaining. That process should not care
about GIT_WORK_TREE either, though.
> Would it be worth looking at the issue server-side too, as this looks
> like something that might have exploit potential? (At the very least,
> it could be used to test if/which directories the remote user has
> access to.)
I think if anything, the server side should be clearing GIT_DIR,
GIT_WORK_TREE, etc, when it does enter_repo(). The point of that
function is to enter a repository which is given externally (generally
on the command-line, though in the case of git-daemon, across the
socket). Clearing any existing local-repo environment variables seems
like it should be part of that.
That's as easy as:
diff --git a/path.c b/path.c
index 95acbaf..395a75d 100644
--- a/path.c
+++ b/path.c
@@ -383,6 +383,10 @@ const char *enter_repo(const char *path, int strict)
{
static char used_path[PATH_MAX];
static char validated_path[PATH_MAX];
+ const char * const *env;
+
+ for (env = local_repo_env; *env; env++)
+ unsetenv(*env);
if (!path)
return NULL;
but I suspect it would break some esoteric cases. E.g.:
git clone -u 'git -c some.option=true upload-pack' foo.git
does what you'd expect now. With that patch, upload-pack would clear its
env before entering "foo.git", and would ignore it.
It would probably be OK to clean GIT_DIR (since we overwrite it in
enter_repo anyway) and GIT_WORK_TREE (since upload-pack, etc, should not
care about it). But the others are much more confusing (should we clear
GIT_ALTERNATE_OBJECT_DIRECTORIES? You would not want that to bleed over
between repositories, but setting it manually seems like a legitimate,
if uncommon, thing to do).
So I'm hesitant to do a patch like that because it seems like the wrong
layer. It's at the interface between the old and new repos that we need
clean these up. And we are (with my other patch) doing that on the
client side. If the server side wants to enforce some protection, that's
a good idea, too. But it should be happening at the ssh layer; i.e.,
disabling "AcceptEnv GIT_*".
> > -- >8 --
> > Subject: git_connect: clear GIT_* environment for ssh
> >
> > When we "switch" to another local repository to run the server
> > side of a fetch or push, we must clear the variables in
> > local_repo_env so that our local $GIT_DIR, etc, do not
> > pollute the upload-pack or receive-pack that is executing in
> > the "remote" repository.
>
> I think we might want to mention GIT_WORK_TREE explicitly here, since
> this seems to be the one causing issues.
Heh. I avoided doing so because I could not convince it to cause an
issue (and even with that aside, the config thing is wrong by itself,
and I _could_ test that).
> The patch works for me, so aside from the suggested commit message
> change, I'm all for it.
Thanks for testing/reviewing.
> > @@ -778,8 +780,6 @@ struct child_process *git_connect(int fd[2], const char
> > *url,
> > }
> > argv_array_push(&conn->args, ssh_host);
> > } else {
> > - /* remove repo-local variables from the environment
> > */
> > - conn->env = local_repo_env;
> > conn->use_shell = 1;
>
> Of course we're now left with just conn->use_shell = 1 in the non-ssh
> case. This could be moved in front of the if, and replaced with
> something like conn>use_shell = !(procol == PROTO_SSH), but maybe this
> would kill legibility. It's just that a single line i the else clause
> of a large if looks odd.
Yeah, I noticed that, too, but I wanted to keep the diff minimal. Maybe
it is worth doing this cleanup on top.
-- >8 --
Subject: [PATCH] git_connect: clarify conn->use_shell flag
When executing user-specified programs, we generally always
want to use a shell, for flexibil
Update Vietnamese translation for git-gui
Dear git-gui maintainers, Please pull the commit 1fa18b72184612e6615b1f119535183f40694fa4 from: https://github.com/vnwildman/git-gui.git on ``master'' branch. Thanks, -- Trần Ngọc Quân. -- 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: [Feature request] help.autocorrect suggestion with Y/N
On Tue, Sep 08, 2015 at 10:11:20AM +0200, rubenk...@spacetrace.org wrote: > git: 'glone' is not a git command. See 'git --help'. > > Did you mean this? > clone > > It would be handsome if you could say "Yes" to this question so you > don't have to manually correct your last command like: > > Did you mean this? > clone > [Y/n] There is currently no way to ask, but you might want to check out help.autoCorrect: $ git config --global help.autoCorrect 10 $ git glone ... WARNING: You called a Git command named 'gclone', which does not exist. Continuing under the assumption that you meant 'clone' in 1.0 seconds automatically... You can set it to "-1" if you want no delay at all. If you (or someone) wanted to add an interactive version, it would probably make sense to trigger it by setting help.autoCorrect to "ask". -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: bash completion lacks options
On Mon, Sep 7, 2015 at 5:36 PM, Olaf Hering wrote: > Am 07.09.2015 um 17:34 schrieb Ævar Arnfjörð Bjarmason: >> On Mon, Sep 7, 2015 at 5:07 PM, Olaf Hering wrote: > >>> https://github.com/libguestfs/libguestfs/commit/0306c98d319d189281af3c15101c8d343e400f13 >> >> This is an interesting approach, but wouldn't help with git-send-email >> in particular, it's a Perl script, so there's no ELF section to parse. > > format-patch is a ELF binary, a link to git itself as I notice > just now. Yes, format-patch is written in C, but you mentioned send-email, which is a Perl script. -- 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: git-upload-pack will return successfully even when it can't read all references
On Tue, Sep 8, 2015 at 8:53 AM, Jeff King wrote:
> On Mon, Sep 07, 2015 at 02:11:15PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> This turned out to be a pretty trivial filesystem error.
>> refs/heads/master wasn't readable by the backup process, but some
>> other stuff in refs/heads and objects/* was.
>>
>> [...]
>>
>> I wanted to check if this was a regression and got as far back as
>> v1.4.3 with the same behavior before the commands wouldn't work
>> anymore due to changes in the git config parsing code.
>
> Right, it has basically always been this way. for_each_ref() silently
> eats oddities or errors while reading refs. Calling for_each_rawref()
> will include them, but we don't do it in most places; it would make
> non-critical operations on a corrupted repo barf. And it is difficult
> to know what is "critical" inside the code. You might be calling
> "upload-pack" to salvage what you can from a corrupted repo, or to make
> a backup where you want to know what is corrupted and what is not.
>
> Commit 49672f2 introduced a "ref paranoia" environment variable to let
> you specify this (and robust backups was definitely one of the use cases
> I had in mind). It's a little tricky to use with upload-pack because you
> may be crossing an ssh boundary, but:
>
> git clone -u 'GIT_REF_PARANOIA=1 git-upload-pack' ...
>
> should work.
>
> With your case:
>
> $ git clone --no-local -u 'GIT_REF_PARANOIA=1 git-upload-pack' repo
> repo-checkout
> Cloning into 'repo-checkout'...
> fatal: git upload-pack: not our ref
> fatal: The remote end hung up unexpectedly
>
> Without "--no-local" it behaves weirdly, but I would not recommend local
> clones in general if you are trying to be careful. They optimize out a
> lot of the safety checks, and we do things like copy the packed-refs
> file wholesale.
>
> And certainly the error message is not the greatest. upload-pack is not
> checking for the REF_ISBROKEN flag, so it just dumps:
>
> refs/heads/master
>
> in the advertisement, and the client happily requests that object.
> REF_PARANOIA is really just a band-aid to feed the broken refs to the
> normal code paths, which typically barf on their own. :)
>
> Something like this:
>
> diff --git a/upload-pack.c b/upload-pack.c
> index 89e832b..3c621a5 100644
> --- a/upload-pack.c
> +++ b/upload-pack.c
> @@ -731,6 +731,9 @@ static int send_ref(const char *refname, const struct
> object_id *oid,
> if (mark_our_ref(refname, oid))
> return 0;
>
> + if (flag & REF_ISBROKEN)
> + warning("remote ref '%s' is broken", refname);
> +
> if (capabilities) {
> struct strbuf symref_info = STRBUF_INIT;
>
> kind of helps, but the advertisement is too early for us to send
> sideband messages. So it makes it to the user if the transport is local
> or ssh, but not over git:// or http.
>
> That's something we could do better with protocol v2 (we'll negotiate
> capabilities before the advertisement).
Fantastic. REF_PARANOIA does exactly what I need, i.e. stall the fetch
process so permissions can be manually repaired.
I think it makes sense to keep the default at "let's try to copy over
what we can", for salvage purposes. I think the bug is that we still
return success in that case, and should return non-zero, but as you
point out this is easier said than done due to needing to deal with
the case where the remote transport sends us the ... ref.
I wonder if --upload-pack="GIT_REF_PARANOIA=1 git-upload-pack" should
be the default when running fetch if you have --prune enabled. There's
a particularly bad edge case now where if you have permission errors
on the master repository and run --prune on your backup along with a
--mirror clone to mirror the refs, then when you have permission
issues you'll prune everything from the backup.
But yeah, a proper fix needs protocol v2. Because among other things
that --upload-pack hack will only work for ssh, not http.
--
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] git-multimail version 1.2 Alpha 1
The changes are described in CHANGES. Contributions-by: Job Snijders Contributions-by: Richard Hansen Contributions-by: Elijah Newren Contributions-by: Michael Haggerty Contributions-by: Paul Sokolovsky Contributions-by: Vadim Zeitlin Contributions-by: Edward d'Auvergne Contributions-by: Elijah Newren Signed-off-by: Matthieu Moy --- This patch is not meant to be merged in master, but it probably makes sense to get it in pu to give it some exposure and allow people to provide feedback before the final release. I'm tagging this as "Alpha" because the UI may still change depending on user feedback. contrib/hooks/multimail/CHANGES | 41 ++ contrib/hooks/multimail/README | 255 --- contrib/hooks/multimail/README.Git | 4 +- contrib/hooks/multimail/doc/gerrit.rst | 56 ++ contrib/hooks/multimail/doc/gitolite.rst| 109 +++ contrib/hooks/multimail/git_multimail.py| 912 contrib/hooks/multimail/migrate-mailhook-config | 2 +- contrib/hooks/multimail/post-receive.example| 8 +- 8 files changed, 1163 insertions(+), 224 deletions(-) create mode 100644 contrib/hooks/multimail/doc/gerrit.rst create mode 100644 contrib/hooks/multimail/doc/gitolite.rst diff --git a/contrib/hooks/multimail/CHANGES b/contrib/hooks/multimail/CHANGES index 6bb1230..768f455 100644 --- a/contrib/hooks/multimail/CHANGES +++ b/contrib/hooks/multimail/CHANGES @@ -1,3 +1,44 @@ +Release 1.2.0 Alpha 1 += + +This release has been well tested, but contains possibly controversial +changes visible to the user. It is an alpha release in the sense that +the user-interface may still change before the final release depending +on the user feedback. + +* It is now possible to exclude some refs (e.g. exclude some branches + or tags). See refFilterDoSendRegex, refFilterDontSendRegex, + refFilterInclusionRegex and refFilterExclusionRegex. + +* New commitEmailFormat option which can be set to "html" to generate + simple colorized diffs using HTML for the commit emails. + +* git-multimail can now be ran as a Gerrit ref-updated hook, or from + Atlassian Stash. + +* The From: field is now more customizeable. It can be set + independently for refchange emails and commit emails (see + fromCommit, fromRefChange). The special values pusher and author can + be used in these configuration variable. + +* A new command-line option, --version, was added. The version is also + available in the X-Git-Multimail-Version header of sent emails. + +* Set X-Git-NotificationType header to differentiate the various types + of notifications. Current values are: diff, ref_changed_plus_diff, + ref_changed. + +* Preliminary support for Python 3. The testsuite passes with Python 3, + but it has not received as much testing as the Python 2 version yet. + +* Several encoding-related fixes. UTF-8 characters work in more + situations (but non-ascii characters in email address are still not + supported). + +* The testsuite and its documentation has been greatly improved. + +Plus all the bugfixes from version 1.1.1. + Release 1.1.1 (bugfix-only release) === diff --git a/contrib/hooks/multimail/README b/contrib/hooks/multimail/README index e552c90..619653f 100644 --- a/contrib/hooks/multimail/README +++ b/contrib/hooks/multimail/README @@ -1,5 +1,5 @@ -git-multimail Version 1.1.1 -=== +git-multimail (version 1.2 Alpha 1) +=== .. image:: https://travis-ci.org/git-multimail/git-multimail.svg?branch=master :target: https://travis-ci.org/git-multimail/git-multimail @@ -53,11 +53,13 @@ By default, for each push received by the repository, git-multimail: + [git] 07/08: Merge branch 'mm/api-credentials-doc' + [git] 08/08: Git 1.7.11-rc2 - Each commit appears in exactly one commit email, the first time - that it is pushed to the repository. If a commit is later merged - into another branch, then a one-line summary of the commit is - included in the reference change email (as usual), but no - additional commit email is generated. + By default, each commit appears in exactly one commit email, the + first time that it is pushed to the repository. If a commit is later + merged into another branch, then a one-line summary of the commit + is included in the reference change email (as usual), but no + additional commit email is generated. See + `multimailhook.refFilter(Inclusion|Exclusion|DoSend|DontSend)Regex` + below to configure which branches and tags are watched by the hook. By default, reference change emails have their "Reply-To" field set to the person who pushed the change, and commit emails have their @@ -73,21 +75,8 @@ Requirements * Python 2.x, version 2.4 or later. No non-standard Python modules - are required. git-multimail does *not* currently work with Python - 3.x. - -
Re: bash completion lacks options
Am 08.09.2015 um 13:28 schrieb Ævar Arnfjörð Bjarmason: > Yes, format-patch is written in C, but you mentioned send-email, which > is a Perl script. send-mail is handled in my copy of the bash_completion, at the end the list the format-patch options gets appended. That list could be autogenerated at build time. Maybe I will find the time to do it myself at some point. Olaf -- 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] Pinning of submodules
Jens Lehmann writes: > Am 07.09.2015 um 01:43 schrieb Eric Sunshine: > >> My concern in asking was that some future person might come up with >> another scenario which also wants to use a "magic value" and would >> have to invent / arrive at another "illegal" representation. Hence, an >> explicit setting might be more appropriate. However, as stated, I >> don't even use submodules, so I may be far off the mark. I've cc'd a >> few of the submodule maintainers with the hope that they will chime >> in. > > Added Trevor to the CC, who is the original author of --remote (see > 06b1abb5b). > > While I believe that adding such functionality makes perfect sense, > I do not find it terribly obvious that setting the branch to '@' will > make --remote skip this submodule. I wouldn't care so much if we'd > only use this value internally, but this is user visible (and has to > be set by the user if she wants to skip a submodule in --remote). > > Setting the branch to an empty value feels a bit more natural, but > I'm not so sure our config handling supports that well (we seem to > assume in quite some places that empty equals unset). So I tend to > prefer a new option for that. As I stare at both the code change and log message of 06b1abb5 (submodule update: add --remote for submodule's upstream changes, 2012-12-19), I cannot shake this feeling that the change to default submodule.$name.branch to 'master' is doubly misdesigned. The stated goal of users of --remote is to declare "This submodule does not care what the top-level integrator happened to have seen at the tip when the integration of the history of submodule. It always follows the tip of a specific branch at the upstream." If we were to use any default, the only justification would be "the users of --remote would want this mode of update to happen for all submodules, and having to specify which specific branch to be followed is too cumbersome". But if that is the case, defaulting to 'master' does not make any sense---if it defaulted to 'HEAD' for each submodule, it may have made some sense, as that is the usual convention to denote which branch is the default branch in a repository. Also Anders' proposal refutes that "when --remote is used, all submodules should behave that way" assumption. I wonder if it is a sensible way forward to introduce a new configuration variable 'submodule.remoteFallBackBranch' so that the users can customize this line (near l.800 in git-submodule.sh) branch=$(get_submodule_config "$name" branch master) The possible values for that new configuration value would be: - an empty string: disable "update --remote" for any submodule '$name' for which submodule.$name.branch is not set. - 'master': behave the same way as the current code; we can make this the default, when submodule.remoteFallBackBranch is unset, to ease transition. - any user-chosen branch name. On notable example may be 'HEAD', which 06b1abb5 (submodule update: add --remote for submodule's upstream changes, 2012-12-19) should have chosen as the default. But I am not the target audience of "update --remote", so let's hear what the real-world use cases are. -- 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_connect: clarify conn->use_shell flag
Jeff King writes:
> Subject: [PATCH] git_connect: clarify conn->use_shell flag
>
> When executing user-specified programs, we generally always
> want to use a shell, for flexibility and consistency. One
> big exception is executing $GIT_SSH, which for historical
> reasons must not use a shell.
>
> Once upon a time the logic in git_connect looked like:
>
> if (protocol == PROTO_SSH) {
> ... setup ssh ...
> } else {
> ... setup local connection ...
> conn->use_shell = 1;
> }
>
> But over time the PROTO_SSH block has grown, and the "local"
> block has shrunk so that it contains only conn->use_shell;
> it's easy to miss at the end of the large block. Moreover,
> PROTO_SSH now also sometimes sets use_shell, when the new
> GIT_SSH_COMMAND is used.
>
> To make the flow easier to follow, let's just set
> conn->use_shell when we're setting up the "conn" struct, and
> unset it (with a comment) in the historical GIT_SSH case.
Makes perfect sense. I think another thing that falls into the same
class wrt readability is 'putty'; if the code does putty=0 at the
beginning of "various flavours of SSH", and sets it only when it
checks with "various flavours of plink" when GIT_SSH_COMMAND is not
set, the logic would be even clearer, I suspect.
> Note that for clarity we leave "use_shell" on in the case
> that we fall back to our default "ssh" This looks like a
> behavior change, but in practice run-command.c optimizes
> shell invocations without metacharacters into a straight
> execve anyway.
Hmm, interesting. I am not sure if that has to be the way, though.
Wouldn't the resulting code become simpler if you do not do that?
That is, is is what I have in mind on top of your patch. Did I
break something?
connect.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/connect.c b/connect.c
index 6f3f85e..acd39d7 100644
--- a/connect.c
+++ b/connect.c
@@ -727,7 +727,7 @@ struct child_process *git_connect(int fd[2], const char
*url,
conn->in = conn->out = -1;
if (protocol == PROTO_SSH) {
const char *ssh;
- int putty, tortoiseplink = 0;
+ int putty = 0, tortoiseplink = 0;
char *ssh_host = hostandport;
const char *port = NULL;
get_host_and_port(&ssh_host, &port);
@@ -749,9 +749,7 @@ struct child_process *git_connect(int fd[2], const char
*url,
}
ssh = getenv("GIT_SSH_COMMAND");
- if (ssh)
- putty = 0;
- else {
+ if (!ssh) {
const char *base;
char *ssh_dup;
@@ -760,10 +758,10 @@ struct child_process *git_connect(int fd[2], const char
*url,
* GIT_SSH_COMMAND (and must remain so for
* historical compatibility).
*/
+ conn->use_shell = 0;
+
ssh = getenv("GIT_SSH");
- if (ssh)
- conn->use_shell = 0;
- else
+ if (!ssh)
ssh = "ssh";
ssh_dup = xstrdup(ssh);
@@ -771,8 +769,9 @@ struct child_process *git_connect(int fd[2], const char
*url,
tortoiseplink = !strcasecmp(base,
"tortoiseplink") ||
!strcasecmp(base, "tortoiseplink.exe");
- putty = !strcasecmp(base, "plink") ||
- !strcasecmp(base, "plink.exe") ||
tortoiseplink;
+ putty = tortoiseplink ||
+ !strcasecmp(base, "plink") ||
+ !strcasecmp(base, "plink.exe");
free(ssh_dup);
}
--
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] filter-branch: add passed/remaining seconds on progress
Eric Sunshine writes:
> On Mon, Sep 7, 2015 at 9:52 AM, Gábor Bernát wrote:
>...
>> # Rewrite the commits
>> +report_progress ()
>> +{
>> +if test -n "$progress"
>> +then
>
> Indent code within the function...
Also git_filter_branch__commit_count is now used only inside this
function, so it is easier to follow to increment it here.
I suspect that the variable has this unwieldy name for historic
reasons, perhaps an attempt to avoid name clashes with the end user
script, but it has many variables (e.g. $commits, $ref, etc.) that
are way too generic and that I can see no attempt of name clash
avoidance, so renaming it to $total_commits or something _might_
make some sense.
> ...
>> +printf "\rRewrite $commit
>> ($git_filter_branch__commit_count/$commits)$progress"
>
> The "\r" causes this status line to be overwritten each time through,
> and since the processed commit count always increases, we know that
> the original (without ETA) will never leave junk at the end of the
> line. However, with estimated seconds also being displayed, does this
> still hold?
Good point.
Perhaps like this squashed in?
git-filter-branch.sh | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 565144a..30ef513 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -277,27 +277,28 @@ test $commits -eq 0 && die "Found nothing to rewrite"
# Rewrite the commits
report_progress ()
{
-if test -n "$progress"
-then
- if test $git_filter_branch__commit_count -gt $next_sample_at
+ git_filter_branch__commit_count=$(($git_filter_branch__commit_count+1))
+
+ if test -n "$progress"
then
- now_timestamp=$(date +%s)
- elapsed_seconds=$(($now_timestamp - $start_timestamp))
- remaining_second=$(( ($commits -
$git_filter_branch__commit_count) * $elapsed_seconds /
$git_filter_branch__commit_count ))
- if test $elapsed_seconds -gt 0
+ if test "$git_filter_branch__commit_count" -gt "$next_sample_at"
then
- next_sample_at=$(( ($elapsed_seconds + 1) *
$git_filter_branch__commit_count / $elapsed_seconds ))
- else
- next_sample_at=$(($next_sample_at + 1))
+ now_timestamp=$(date "+%s")
+ elapsed_seconds=$(($now_timestamp - $start_timestamp))
+ remaining_second=$(( ($commits -
$git_filter_branch__commit_count) * $elapsed_seconds /
$git_filter_branch__commit_count ))
+ if test $elapsed_seconds -gt 0
+ then
+ next_sample_at=$(( ($elapsed_seconds + 1) *
$git_filter_branch__commit_count / $elapsed_seconds ))
+ else
+ next_sample_at=$(($next_sample_at + 1))
+ fi
+ progress=" ($elapsed_seconds seconds passed, remaining
$remaining_second predicted)"
fi
- progress=" ($elapsed_seconds seconds passed, remaining
$remaining_second predicted)"
fi
-fi
-printf "\rRewrite $commit ($git_filter_branch__commit_count/$commits)$progress"
+ printf "\rRewrite $commit
($git_filter_branch__commit_count/$commits)$progress"
}
git_filter_branch__commit_count=0
-
progress= start_timestamp=
if date '+%s' 2>/dev/null | grep -q '^[0-9][0-9]*$'
then
@@ -306,9 +307,8 @@ then
start_timestamp=$(date '+%s')
fi
-while read commit parents; do
- git_filter_branch__commit_count=$(($git_filter_branch__commit_count+1))
-
+while read commit parents
+do
report_progress
case "$filter_subdir" in
--
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] filter-branch: add passed/remaining seconds on progress
On Tue, Sep 8, 2015 at 1:32 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>> On Mon, Sep 7, 2015 at 9:52 AM, Gábor Bernát wrote:
>>...
>>> # Rewrite the commits
>>> +report_progress ()
>>> +{
>>> +if test -n "$progress"
>>> +then
>>
>> Indent code within the function...
>
> Also git_filter_branch__commit_count is now used only inside this
> function, so it is easier to follow to increment it here.
Make sense.
>>> +printf "\rRewrite $commit
>>> ($git_filter_branch__commit_count/$commits)$progress"
>>
>> The "\r" causes this status line to be overwritten each time through,
>> and since the processed commit count always increases, we know that
>> the original (without ETA) will never leave junk at the end of the
>> line. However, with estimated seconds also being displayed, does this
>> still hold?
>
> Good point.
> Perhaps like this squashed in?
>
> -printf "\rRewrite $commit
> ($git_filter_branch__commit_count/$commits)$progress"
> + printf "\rRewrite $commit
> ($git_filter_branch__commit_count/$commits)$progress"
Yes, for an expedient "fix", this is what I had in mind, although I
would also have added an equal number of backspaces (\b) following the
spaces, as a minor aesthetic improvement.
--
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: Issue with Orphaned Files After Aborted Rebase
I began a rebase, and was unable to add two files that appeared as changed (1). When I aborted this rebase, these two files were left in my tree, showing as changed, and did not respond to checkout ‹(2), reset(3), or stash(4). My expectation would be that after a rebase ‹abort, the tree would be returned to the original state pre-rebase. My expectation for checkout and reset is that the tree would be returned to its state based on the last commit. My expectation for stash is that the files would be stashed and thus changes would be reverted. Have I done something wrong/missed something? For reference, feature/RED-599-Bundling was created from feature/fanatics. I¹ll be keeping this repository in this state in case I can provide any additional useful information. Thanks, Johnny (1) https://gist.github.com/sheeley/537f6562e762b288cef8#file-orphaned-txt-L1-L 159 (2) https://gist.github.com/sheeley/537f6562e762b288cef8#file-orphaned-txt-L160 -L186 (3) https://gist.github.com/sheeley/537f6562e762b288cef8#file-orphaned-txt-L187 -L201 (4) https://gist.github.com/sheeley/537f6562e762b288cef8#file-orphaned-txt-L187 -L201 Information contained in this e-mail message is confidential. This e-mail message is intended only for the personal use of the recipient(s) named above. If you are not an intended recipient, do not read, distribute or reproduce this transmission (including any attachments). If you have received this email in error, please immediately notify the sender by email reply and delete the original message. -- 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] am: match --signoff to the original scripted version
Jeff King writes:
> On Sat, Sep 05, 2015 at 09:56:27PM -0700, Junio C Hamano wrote:
>
>> +static void am_signoff(struct strbuf *sb)
>> +{
>> +char *cp;
>> +struct strbuf mine = STRBUF_INIT;
>> +
>> +/* Does it end with our own sign-off? */
>> +strbuf_addf(&mine, "\n%s%s\n",
>> +sign_off_header,
>> +fmt_name(getenv("GIT_COMMITTER_NAME"),
>> + getenv("GIT_COMMITTER_EMAIL")));
>> +if (mine.len < sb->len &&
>> +!strcmp(mine.buf, sb->buf + sb->len - mine.len))
>> +goto exit; /* no need to duplicate */
>
> Here you insert the "\n" directly at the start of "mine", so the test
> "does it contain S-o-b at the beginning of a line" does not count the
> first line. Probably fine, as somebody putting a S-o-b in their subject
> deserves whatever they get.
Yup.
>> +/* Does it have any Signed-off-by: in the text */
>> +for (cp = sb->buf;
>> + cp && *cp && (cp = strstr(cp, sign_off_header)) != NULL;
>> + cp = strchr(cp, '\n')) {
>> +if (sb->buf == cp || cp[-1] == '\n')
>> +break;
>> +}
>
> Here you are more careful about finding S-o-b at sb->buf.
It is not being careful for that, actually. It just is avoiding to
access sb->buf[-1], which would be a realproblem. "The beginning of
buffer is also at the beginning of a line" is merely a happy side
effect ;-).
--
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: Standardization of messages - dot after the sentence
Michael J Gruber writes: > sigo venit, vidit, dixit 05.09.2015 14:22: >> I've found really "little bug" with dots in the git output. >> >> $ git push >> Everything up-to-date >> >> git pull >> Already up-to-date. >> >> Could all phrases contain dots? :) >> > > In this case, also both messages mean the same but are phrased > differently, which is suboptimal in more than one way. I do not particularly care between these two commands, but I think "git pull" says the same "Already up-to-date" in two situations that are two quite different ones. That ambiguity bothers me a lot more. -- 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[2]: Improving auto conflict resolving while merge
Hi, Jeff. JK> For example, if you have the content: JK> foo(); JK> bar(); JK> baz(); JK> and one side makes it: JK> foo(); JK> x = 1; JK> bar(); JK> baz(); JK> and the other side does: JK> foo(); JK> bar(); JK> y = 2; JK> baz(); JK> you _could_ argue that those changes are independent But it's close JK> enough that there's a good chance the two need to be reconciled, JK> and a human should at least take a look. You are right and your words make sense. But this thought may apply for this: We have one method/function about 200 lines. One author make change at line 1 of this method and other on 199 line. Both changes are done in one method so **human should at least take a look** Example 2: one author make change in method 1 second author make change in method 2 Method 1 is called from method 2. Those changes work fine on its own branch and does not work together. **human should at least take a look** This task is not for human and must be left for test system. So your example and two mine must not rise conflicts. This make useless noise. Another example of useless merge conflicts A--C--C'--F--? master \ \ / B--C--D--G feature Here I start branch feature. While developing update my branch from master by (C) changes While developing feature (C) were changed by (C') on master When I merge feature branch back to master I will get merge conflicts on lines in patch (C). I am not author of (C) and I do not care about it. Even more I can not care and must not. Implemented option (like --theirs in last example) to not be so conservative and do not rise merge conflicts for enough close changes will be good. -- 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 v16 00/14] port tag.c to use ref-filter APIs
Matthieu Moy writes:
>>> This line still looks overlong. Would it help to stop spelling this
>>> as a double "a = b = overlong expression" assignment?
>>>
>>
>> I'm not sure, I get what you mean.
>
> I guess
>
> format = xstrfmt("%%(align:15,left)%%(refname:short)%%(end)
> %%(contents:lines=%d)",
> filter->lines);
> to_free = format;
>
> (still 83 columns + indentation, but that's a bit shorter than your
> version).
Sure. This may also be possible
xstrfmt("%s %%(contents:lines=%d)",
"%(align:15,left)%(refname:short)%(end)", filter->lines);
and highlights that the only thing that is variable is the number
of lines, which might be better.
--
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 v16 00/14] port tag.c to use ref-filter APIs
Karthik Nayak writes: >> I am flexible with the terminology, but the point is that I think >> the quoting rules are better be specified _outside_ the description >> of a particular atom, but as a general rule. > > I definitely agree, but like Matthieu said, corrently we have only > one such atom and it makes sense to note this behaviour under that. > When we get %(if) to work we could move this over to a more general > section? Sure. -- 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: Questions about git-push for huge repositories
Jeff King writes: > If you turn on reachability bitmaps, git _will_ do the thorough set > difference, because it becomes much cheaper to do so. E.g., try: > > git repack -adb > > in repo A to build a single pack with bitmaps enabled. Then a subsequent > push should send only a single object (the new commit). Hmph, A has the tip of B, and has a new commit B hasn't seen but A knows that new commit's tree matches the tree of the tip of B. Wouldn't --thin transfer from A to B know to send only that new commit object without sending anything below the tree in such a case, even without the bitmap? -- 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: bash completion lacks options
Ævar Arnfjörð Bjarmason writes: > On Mon, Sep 7, 2015 at 5:36 PM, Olaf Hering wrote: >> Am 07.09.2015 um 17:34 schrieb Ævar Arnfjörð Bjarmason: >>> On Mon, Sep 7, 2015 at 5:07 PM, Olaf Hering wrote: >> https://github.com/libguestfs/libguestfs/commit/0306c98d319d189281af3c15101c8d343e400f13 >>> >>> This is an interesting approach, but wouldn't help with git-send-email >>> in particular, it's a Perl script, so there's no ELF section to parse. >> >> format-patch is a ELF binary, a link to git itself as I notice >> just now. > > Yes, format-patch is written in C, but you mentioned send-email, which > is a Perl script. I think Olaf means that send-email has a mode where it can drive format-patch directly from the command line. This is a slightly related tangent, but I've been wondering if it makes sense to discourage, deprecate and eventually remove that mode of operation. It appears it is the biggest single source of poorly proof-read series, when compared to "format-patch to a directory with --cover option and then give them a final scan before running send-email on them" workflow. -- 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: [PATCHv5 3/3] submodule: Reimplement `module_clone` shell function in C
On Thu, Sep 3, 2015 at 3:07 PM, Junio C Hamano wrote:
>> +
>> + cp.no_stdin = 1;
>> + cp.no_stdout = 1;
>> + cp.no_stderr = 1;
>
> Output from "git clone" is not shown, regardless of --quiet option?
Removed that.
>> + argc = parse_options(argc, argv, prefix, module_clone_options,
>> + git_submodule_helper_usage, 0);
>> +
>> + strbuf_addf(&sb, "%s/modules/%s", get_git_dir(), name);
>
> The original says
>
> base_name=$(dirname "$name")
>
> before doing this %s/modules/%s concatenation. I do not think we
> intended to allow a slash in submodule name, so this difference may
> be showing that the original was doing an unnecessary thing.
The way I understood the code, this was a workaround of now having
safe_create_leading_directories, which takes the base directory of
a given path and creates that directory. (base_name is only used as an
argument for mkdir -p).
Slashes are already in use for submodule names as the name defaults
to the path if no explicit name is given. And the path may contain slashes
as it may be nested. In Gerrit we have a .gitmodules:
[submodule "plugins/commit-message-length-validator"]
path = plugins/commit-message-length-validator
url = ../plugins/commit-message-length-validator
[...
>
>> + sm_gitdir = strbuf_detach(&sb, NULL);
>> +
>> + if (!file_exists(sm_gitdir)) {
>> + if (safe_create_leading_directories_const(sm_gitdir) < 0)
>> + die(_("could not create directory '%s'"), sm_gitdir);
>> + if (clone_submodule(path, sm_gitdir, url, depth, reference,
>> quiet))
>> + die(_("clone of '%s' into submodule path '%s' failed"),
>> + url, path);
>> + } else {
>> + if (safe_create_leading_directories_const(path) < 0)
>> + die(_("could not create directory '%s'"), path);
>> + strbuf_addf(&sb, "%s/index", sm_gitdir);
>> + if (unlink(sb.buf) < 0)
>> + die_errno(_("failed to delete '%s'"), sm_gitdir);
>
> The original says "we do not care if it failed" with
>
> rm -f "$gitdir/index"
>
> I think the intention of the original is "we do not care if it
> failed because it did not exist." in which case unconditional
> die_errno() here may be something we do not want?
Right, this was a short-circuit reaction from me on Erics comment
to check for the return value of unlink. I think we can use
unlink_or_warn here as that only warns if we cannot remove
an existing file. non existent files are not warned about.
>
>> + strbuf_reset(&sb);
>> + }
>> +
>> + /* Write a .git file in the submodule to redirect to the superproject.
>> */
>> + if (safe_create_leading_directories_const(path) < 0)
>> + die(_("could not create directory '%s'"), path);
>> +
>> + if (path && *path)
>> + strbuf_addf(&sb, "%s/.git", path);
>> + else
>> + strbuf_addf(&sb, ".git");
>> +
>> + if (safe_create_leading_directories_const(sb.buf) < 0)
>> + die(_("could not create leading directories of '%s'"), sb.buf);
>> + submodule_dot_git = fopen(sb.buf, "w");
>> + if (!submodule_dot_git)
>> + die_errno(_("cannot open file '%s'"), sb.buf);
>> +
>> + fprintf(submodule_dot_git, "gitdir: %s\n",
>> + relative_path(sm_gitdir, path, &rel_path));
>> + if (fclose(submodule_dot_git))
>> + die(_("could not close file %s"), sb.buf);
>> + strbuf_reset(&sb);
>> + strbuf_reset(&rel_path);
>
> The original seems to go quite a length to make sure symbolic links
> do not fool the comparison between $gitdir and $sm_path, and also it
> makes sure one is not a subpath of the other. Do we need the same
> level of carefulness, or is textual relative_path() enough?
I think the original was doing an "optimized" version of relative_path()
as we know that they have an anchor at the superproject root directory.
relative_path() seems to deal with the symbolic links just fine, as all
tests pass. (6eafa6d096ce, "submodules: don't stumble over symbolic
links when cloning recursively" did add code as well as testing for symbolic
link problems, Thanks Jens!)
>> --depth=*)
>> - depth=$1
>> + depth="$1"
>
> This seems to be an unrelated change.
A leftover from earlier, when I mucked around with --depth and
--reference in the shell scipt.
On Thu, Sep 3, 2015 at 4:17 PM, Eric Sunshine wrote:
>> + if (path && *path)
>> + strbuf_addf(&sb, "%s/.git", path);
>> + else
>> + strbuf_addf(&sb, ".git");
>
> Minor: strbuf_addstr(...);
done
--
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
[PATCHv6 2/3] submodule: Reimplement `module_name` shell function in C
This implements the helper `name` in C instead of shell,
yielding a nice performance boost.
Before this patch, I measured a time (best out of three):
$ time ./t7400-submodule-basic.sh >/dev/null
real0m11.066s
user0m3.348s
sys 0m8.534s
With this patch applied I measured (also best out of three)
$ time ./t7400-submodule-basic.sh >/dev/null
real0m10.063s
user0m3.044s
sys 0m7.487s
Signed-off-by: Stefan Beller
---
builtin/submodule--helper.c | 22 ++
git-submodule.sh| 32 +++-
2 files changed, 29 insertions(+), 25 deletions(-)
diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
index 10db4e6..bc79c41 100644
--- a/builtin/submodule--helper.c
+++ b/builtin/submodule--helper.c
@@ -5,6 +5,9 @@
#include "pathspec.h"
#include "dir.h"
#include "utf8.h"
+#include "submodule.h"
+#include "submodule-config.h"
+#include "string-list.h"
struct module_list {
const struct cache_entry **entries;
@@ -102,6 +105,24 @@ static int module_list(int argc, const char **argv, const
char *prefix)
return 0;
}
+static int module_name(int argc, const char **argv, const char *prefix)
+{
+ const struct submodule *sub;
+
+ if (argc != 2)
+ usage(_("git submodule--helper name "));
+
+ gitmodules_config();
+ sub = submodule_from_path(null_sha1, argv[1]);
+
+ if (!sub)
+ die(_("no submodule mapping found in .gitmodules for path
'%s'"),
+ argv[1]);
+
+ printf("%s\n", sub->name);
+
+ return 0;
+}
struct cmd_struct {
const char *cmd;
@@ -110,6 +131,7 @@ struct cmd_struct {
static struct cmd_struct commands[] = {
{"list", module_list},
+ {"name", module_name},
};
int cmd_submodule__helper(int argc, const char **argv, const char *prefix)
diff --git a/git-submodule.sh b/git-submodule.sh
index 95c04fc..2be8da2 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -178,24 +178,6 @@ get_submodule_config () {
printf '%s' "${value:-$default}"
}
-
-#
-# Map submodule path to submodule name
-#
-# $1 = path
-#
-module_name()
-{
- # Do we have "submodule..path = $1" defined in .gitmodules
file?
- sm_path="$1"
- re=$(printf '%s\n' "$1" | sed -e 's/[].[^$\\*]/\\&/g')
- name=$( git config -f .gitmodules --get-regexp '^submodule\..*\.path$' |
- sed -n -e 's|^submodule\.\(.*\)\.path '"$re"'$|\1|p' )
- test -z "$name" &&
- die "$(eval_gettext "No submodule mapping found in .gitmodules for path
'\$sm_path'")"
- printf '%s\n' "$name"
-}
-
#
# Clone a submodule
#
@@ -498,7 +480,7 @@ cmd_foreach()
then
displaypath=$(relative_path "$sm_path")
say "$(eval_gettext "Entering '\$prefix\$displaypath'")"
- name=$(module_name "$sm_path")
+ name=$(git submodule--helper name "$sm_path")
(
prefix="$prefix$sm_path/"
clear_local_git_env
@@ -554,7 +536,7 @@ cmd_init()
while read mode sha1 stage sm_path
do
die_if_unmatched "$mode"
- name=$(module_name "$sm_path") || exit
+ name=$(git submodule--helper name "$sm_path") || exit
displaypath=$(relative_path "$sm_path")
@@ -636,7 +618,7 @@ cmd_deinit()
while read mode sha1 stage sm_path
do
die_if_unmatched "$mode"
- name=$(module_name "$sm_path") || exit
+ name=$(git submodule--helper name "$sm_path") || exit
displaypath=$(relative_path "$sm_path")
@@ -758,7 +740,7 @@ cmd_update()
echo >&2 "Skipping unmerged submodule $prefix$sm_path"
continue
fi
- name=$(module_name "$sm_path") || exit
+ name=$(git submodule--helper name "$sm_path") || exit
url=$(git config submodule."$name".url)
branch=$(get_submodule_config "$name" branch master)
if ! test -z "$update"
@@ -1022,7 +1004,7 @@ cmd_summary() {
# Respect the ignore setting for --for-status.
if test -n "$for_status"
then
- name=$(module_name "$sm_path")
+ name=$(git submodule--helper name "$sm_path")
ignore_config=$(get_submodule_config "$name"
ignore none)
test $status != A && test $ignore_config = all
&& continue
fi
@@ -1184,7 +1166,7 @@ cmd_status()
while read mode sha1 stage sm_path
do
die_if_unmatched "$mode"
- name=$(module_name "$sm_path") || exit
+ name=$(gi
Re: Conditionally define vars to improve portability
Jeff King writes: > On Mon, Sep 07, 2015 at 02:51:42PM -0300, Renato Botelho wrote: > >> Default variables used to build are set using = on Makefile, (e.g. CC, >> INSTALL, CFLAGS, …). GNU make overwrite these values if it’s passed as >> an argument (make CC=clang) and it works as expected. >> >> Default method of passing arguments for make operations on FreeBSD >> ports tree is using environment variables instead of make arguments, >> then we have CC set on env before call gmake. Today these values are >> ignored by git Makefile, and we ended up patching Makefile replacing = >> by ?= on variable assignments [1]. > > Hmm. I can't really think of a downside to doing so, unless we expect > users to have things like CC set in the environment and _not_ want them > to bleed through to our build. I do think that is the reason behind the choice. I am not saying I necessarily personally agree with it, though. Common things like CC are not so problematic, but more problematic are various Git build customization in our Makefile that can be left behind from a previous build. It is easier for users to forget, as a "GIT_FOO=NoThanks; export GIT_FOO" that was run previously in the same shell does not leave trace once the shell exits, compared to other avenues of customization including config.mak and explicit command line settings given to the 'make' utility (i.e. can be seen in 'history' as a single entry, without having to trace the sequence of 'GIT_FOO=NoThanks', 'export GIT_FOO' and possible 'unset GIT_FOO' to find what was in effect when 'make' was run). So from that point of view, if you encourage users to be less explicit by keeping them in the environment, you are making it easier for the users to hurt themselves. In an environment to build with a "make world" style propagation of settings from top-level to down below, "environment bleeding" is a non-issue. It is merely a convention in that build environment how the settings are passed to submakes in a whole system and everybody in that environment understands the ramifications. I agree that your suggestion of using "gmake -e" may be a good workaround for handling cases like that. -- 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
[PATCHv6 1/3] submodule: Reimplement `module_list` shell function in C
Most of the submodule operations work on a set of submodules.
Calculating and using this set is usually done via:
module_list "$@" | {
while read mode sha1 stage sm_path
do
# the actual operation
done
}
Currently the function `module_list` is implemented in the
git-submodule.sh as a shell script wrapping a perl script.
The rewrite is in C, such that it is faster and can later be
easily adapted when other functions are rewritten in C.
git-submodule.sh, similar to the builtin commands, will navigate
to the top-most directory of the repository and keep the
subdirectory as a variable. As the helper is called from
within the git-submodule.sh script, we are already navigated
to the root level, but the path arguments are still relative
to the subdirectory we were in when calling git-submodule.sh.
That's why there is a `--prefix` option pointing to an alternative
path which to anchor relative path arguments.
Signed-off-by: Stefan Beller
---
.gitignore | 1 +
Makefile| 1 +
builtin.h | 1 +
builtin/submodule--helper.c | 128
git-submodule.sh| 54 +++
git.c | 1 +
6 files changed, 138 insertions(+), 48 deletions(-)
create mode 100644 builtin/submodule--helper.c
diff --git a/.gitignore b/.gitignore
index 4fd81ba..1c2f832 100644
--- a/.gitignore
+++ b/.gitignore
@@ -155,6 +155,7 @@
/git-status
/git-stripspace
/git-submodule
+/git-submodule--helper
/git-svn
/git-symbolic-ref
/git-tag
diff --git a/Makefile b/Makefile
index 24b636d..d434e73 100644
--- a/Makefile
+++ b/Makefile
@@ -901,6 +901,7 @@ BUILTIN_OBJS += builtin/shortlog.o
BUILTIN_OBJS += builtin/show-branch.o
BUILTIN_OBJS += builtin/show-ref.o
BUILTIN_OBJS += builtin/stripspace.o
+BUILTIN_OBJS += builtin/submodule--helper.o
BUILTIN_OBJS += builtin/symbolic-ref.o
BUILTIN_OBJS += builtin/tag.o
BUILTIN_OBJS += builtin/unpack-file.o
diff --git a/builtin.h b/builtin.h
index 839483d..924e6c4 100644
--- a/builtin.h
+++ b/builtin.h
@@ -119,6 +119,7 @@ extern int cmd_show(int argc, const char **argv, const char
*prefix);
extern int cmd_show_branch(int argc, const char **argv, const char *prefix);
extern int cmd_status(int argc, const char **argv, const char *prefix);
extern int cmd_stripspace(int argc, const char **argv, const char *prefix);
+extern int cmd_submodule__helper(int argc, const char **argv, const char
*prefix);
extern int cmd_symbolic_ref(int argc, const char **argv, const char *prefix);
extern int cmd_tag(int argc, const char **argv, const char *prefix);
extern int cmd_tar_tree(int argc, const char **argv, const char *prefix);
diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
new file mode 100644
index 000..10db4e6
--- /dev/null
+++ b/builtin/submodule--helper.c
@@ -0,0 +1,128 @@
+#include "builtin.h"
+#include "cache.h"
+#include "parse-options.h"
+#include "quote.h"
+#include "pathspec.h"
+#include "dir.h"
+#include "utf8.h"
+
+struct module_list {
+ const struct cache_entry **entries;
+ int alloc, nr;
+};
+#define MODULE_LIST_INIT { NULL, 0, 0 }
+
+static int module_list_compute(int argc, const char **argv,
+ const char *prefix,
+ struct pathspec *pathspec,
+ struct module_list *list)
+{
+ int i, result = 0;
+ char *max_prefix, *ps_matched = NULL;
+ int max_prefix_len;
+ parse_pathspec(pathspec, 0,
+ PATHSPEC_PREFER_FULL |
+ PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP,
+ prefix, argv);
+
+ /* Find common prefix for all pathspec's */
+ max_prefix = common_prefix(pathspec);
+ max_prefix_len = max_prefix ? strlen(max_prefix) : 0;
+
+ if (pathspec->nr)
+ ps_matched = xcalloc(pathspec->nr, 1);
+
+ if (read_cache() < 0)
+ die(_("index file corrupt"));
+
+ for (i = 0; i < active_nr; i++) {
+ const struct cache_entry *ce = active_cache[i];
+
+ if (!S_ISGITLINK(ce->ce_mode) ||
+ !match_pathspec(pathspec, ce->name, ce_namelen(ce),
+ max_prefix_len, ps_matched, 1))
+ continue;
+
+ ALLOC_GROW(list->entries, list->nr + 1, list->alloc);
+ list->entries[list->nr++] = ce;
+ while (i + 1 < active_nr &&
+ !strcmp(ce->name, active_cache[i + 1]->name))
+ /*
+* Skip entries with the same name in different stages
+* to make sure an entry is returned only once.
+*/
+ i++;
+ }
+ free(max_prefix);
+
+ if (ps_matched && report_path_error(ps_matched, pathspec, prefix))
+
[PATCHv6 0/3] submodule--helper: Have some refactoring only patches first
Added suggestions from Eric and Junio. Interdiff to v5 below.
Stefan Beller (3):
submodule: Reimplement `module_list` shell function in C
submodule: Reimplement `module_name` shell function in C
submodule: Reimplement `module_clone` shell function in C
.gitignore | 1 +
Makefile| 1 +
builtin.h | 1 +
builtin/submodule--helper.c | 282
git-submodule.sh| 164 +++---
git.c | 1 +
6 files changed, 301 insertions(+), 149 deletions(-)
create mode 100644 builtin/submodule--helper.c
diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
index 4e30d8e..f4c3eff 100644
--- a/builtin/submodule--helper.c
+++ b/builtin/submodule--helper.c
@@ -10,12 +10,16 @@
#include "string-list.h"
#include "run-command.h"
-static const struct cache_entry **ce_entries;
-static int ce_alloc, ce_used;
+struct module_list {
+ const struct cache_entry **entries;
+ int alloc, nr;
+};
+#define MODULE_LIST_INIT { NULL, 0, 0 }
static int module_list_compute(int argc, const char **argv,
- const char *prefix,
- struct pathspec *pathspec)
+ const char *prefix,
+ struct pathspec *pathspec,
+ struct module_list *list)
{
int i, result = 0;
char *max_prefix, *ps_matched = NULL;
@@ -40,12 +44,11 @@ static int module_list_compute(int argc, const char **argv,
if (!S_ISGITLINK(ce->ce_mode) ||
!match_pathspec(pathspec, ce->name, ce_namelen(ce),
- max_prefix_len, ps_matched,
- S_ISGITLINK(ce->ce_mode) |
S_ISDIR(ce->ce_mode)))
+ max_prefix_len, ps_matched, 1))
continue;
- ALLOC_GROW(ce_entries, ce_used + 1, ce_alloc);
- ce_entries[ce_used++] = ce;
+ ALLOC_GROW(list->entries, list->nr + 1, list->alloc);
+ list->entries[list->nr++] = ce;
while (i + 1 < active_nr &&
!strcmp(ce->name, active_cache[i + 1]->name))
/*
@@ -68,6 +71,7 @@ static int module_list(int argc, const char **argv, const
char *prefix)
{
int i;
struct pathspec pathspec;
+ struct module_list list = MODULE_LIST_INIT;
struct option module_list_options[] = {
OPT_STRING(0, "prefix", &prefix,
@@ -84,13 +88,13 @@ static int module_list(int argc, const char **argv, const
char *prefix)
argc = parse_options(argc, argv, prefix, module_list_options,
git_submodule_helper_usage, 0);
- if (module_list_compute(argc, argv, prefix, &pathspec) < 0) {
+ if (module_list_compute(argc, argv, prefix, &pathspec, &list) < 0) {
printf("#unmatched\n");
return 1;
}
- for (i = 0; i < ce_used; i++) {
- const struct cache_entry *ce = ce_entries[i];
+ for (i = 0; i < list.nr; i++) {
+ const struct cache_entry *ce = list.entries[i];
if (ce_stage(ce))
printf("%06o %s U\t", ce->ce_mode,
sha1_to_hex(null_sha1));
@@ -142,10 +146,7 @@ static int clone_submodule(const char *path, const char
*gitdir, const char *url
cp.git_cmd = 1;
cp.env = local_repo_env;
-
cp.no_stdin = 1;
- cp.no_stdout = 1;
- cp.no_stderr = 1;
return run_command(&cp);
}
@@ -206,8 +207,7 @@ static int module_clone(int argc, const char **argv, const
char *prefix)
if (safe_create_leading_directories_const(path) < 0)
die(_("could not create directory '%s'"), path);
strbuf_addf(&sb, "%s/index", sm_gitdir);
- if (unlink(sb.buf) < 0)
- die_errno(_("failed to delete '%s'"), sm_gitdir);
+ unlink_or_warn(sb.buf);
strbuf_reset(&sb);
}
@@ -218,7 +218,7 @@ static int module_clone(int argc, const char **argv, const
char *prefix)
if (path && *path)
strbuf_addf(&sb, "%s/.git", path);
else
- strbuf_addf(&sb, ".git");
+ strbuf_addstr(&sb, ".git");
if (safe_create_leading_directories_const(sb.buf) < 0)
die(_("could not create leading directories of '%s'"), sb.buf);
diff --git a/git-submodule.sh b/git-submodule.sh
index 7cfdc2c..8b0eb9a 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -227,7 +227,7 @@ cmd_add()
shift
;;
--depth=*)
- depth="$1"
+ depth=$1
;;
--)
shift
--
2
[PATCHv6 3/3] submodule: Reimplement `module_clone` shell function in C
This reimplements the helper function `module_clone` in shell
in C as `clone`. This functionality is needed for converting
`git submodule update` later on, which we want to add threading
to.
Signed-off-by: Stefan Beller
---
builtin/submodule--helper.c | 132
git-submodule.sh| 78 +-
2 files changed, 134 insertions(+), 76 deletions(-)
diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
index bc79c41..f4c3eff 100644
--- a/builtin/submodule--helper.c
+++ b/builtin/submodule--helper.c
@@ -8,6 +8,7 @@
#include "submodule.h"
#include "submodule-config.h"
#include "string-list.h"
+#include "run-command.h"
struct module_list {
const struct cache_entry **entries;
@@ -123,6 +124,136 @@ static int module_name(int argc, const char **argv, const
char *prefix)
return 0;
}
+static int clone_submodule(const char *path, const char *gitdir, const char
*url,
+ const char *depth, const char *reference, int quiet)
+{
+ struct child_process cp;
+ child_process_init(&cp);
+
+ argv_array_push(&cp.args, "clone");
+ argv_array_push(&cp.args, "--no-checkout");
+ if (quiet)
+ argv_array_push(&cp.args, "--quiet");
+ if (depth && *depth)
+ argv_array_pushl(&cp.args, "--depth", depth, NULL);
+ if (reference && *reference)
+ argv_array_pushl(&cp.args, "--reference", reference, NULL);
+ if (gitdir && *gitdir)
+ argv_array_pushl(&cp.args, "--separate-git-dir", gitdir, NULL);
+
+ argv_array_push(&cp.args, url);
+ argv_array_push(&cp.args, path);
+
+ cp.git_cmd = 1;
+ cp.env = local_repo_env;
+ cp.no_stdin = 1;
+
+ return run_command(&cp);
+}
+
+static int module_clone(int argc, const char **argv, const char *prefix)
+{
+ const char *path = NULL, *name = NULL, *url = NULL;
+ const char *reference = NULL, *depth = NULL;
+ int quiet = 0;
+ FILE *submodule_dot_git;
+ char *sm_gitdir, *cwd, *p;
+ struct strbuf rel_path = STRBUF_INIT;
+ struct strbuf sb = STRBUF_INIT;
+
+ struct option module_clone_options[] = {
+ OPT_STRING(0, "prefix", &prefix,
+ N_("path"),
+ N_("alternative anchor for relative paths")),
+ OPT_STRING(0, "path", &path,
+ N_("path"),
+ N_("where the new submodule will be cloned to")),
+ OPT_STRING(0, "name", &name,
+ N_("string"),
+ N_("name of the new submodule")),
+ OPT_STRING(0, "url", &url,
+ N_("string"),
+ N_("url where to clone the submodule from")),
+ OPT_STRING(0, "reference", &reference,
+ N_("string"),
+ N_("reference repository")),
+ OPT_STRING(0, "depth", &depth,
+ N_("string"),
+ N_("depth for shallow clones")),
+ OPT__QUIET(&quiet, "Suppress output for cloning a submodule"),
+ OPT_END()
+ };
+
+ const char *const git_submodule_helper_usage[] = {
+ N_("git submodule--helper clone [--prefix=] [--quiet] "
+ "[--reference ] [--name ] [--url ]"
+ "[--depth ] [--] [...]"),
+ NULL
+ };
+
+ argc = parse_options(argc, argv, prefix, module_clone_options,
+git_submodule_helper_usage, 0);
+
+ strbuf_addf(&sb, "%s/modules/%s", get_git_dir(), name);
+ sm_gitdir = strbuf_detach(&sb, NULL);
+
+ if (!file_exists(sm_gitdir)) {
+ if (safe_create_leading_directories_const(sm_gitdir) < 0)
+ die(_("could not create directory '%s'"), sm_gitdir);
+ if (clone_submodule(path, sm_gitdir, url, depth, reference,
quiet))
+ die(_("clone of '%s' into submodule path '%s' failed"),
+ url, path);
+ } else {
+ if (safe_create_leading_directories_const(path) < 0)
+ die(_("could not create directory '%s'"), path);
+ strbuf_addf(&sb, "%s/index", sm_gitdir);
+ unlink_or_warn(sb.buf);
+ strbuf_reset(&sb);
+ }
+
+ /* Write a .git file in the submodule to redirect to the superproject.
*/
+ if (safe_create_leading_directories_const(path) < 0)
+ die(_("could not create directory '%s'"), path);
+
+ if (path && *path)
+ strbuf_addf(&sb, "%s/.git", path);
+ else
+ strbuf_addstr(&sb, ".git");
+
+ if (safe_create_leading_directories_const(sb.buf) < 0)
+ die(_("could not create leading directories of '%s'"), sb.buf);
+
Re: Conditionally define vars to improve portability
On Tue, Sep 8, 2015 at 11:57 AM, Junio C Hamano wrote: > Common things like CC are not so problematic, but more problematic > are various Git build customization in our Makefile that can be left > behind from a previous build. It is easier for users to forget, as > a "GIT_FOO=NoThanks; export GIT_FOO" that was run previously in the > same shell does not leave trace once the shell exits, compared to > other avenues of customization including config.mak and explicit > command line settings given to the 'make' utility (i.e. can be seen > in 'history' as a single entry, without having to trace the sequence > of 'GIT_FOO=NoThanks', 'export GIT_FOO' and possible 'unset GIT_FOO' > to find what was in effect when 'make' was run). So from that point > of view, if you encourage users to be less explicit by keeping them > in the environment, you are making it easier for the users to hurt > themselves. It should be noted that a common idiom is also "VARIABLE=VALUE Make" where we set the variable in the environment before running the command. This would begin working if you allow the =? setting of variables. That being said, since "make VARIABLE=VALUE" already works, and is really just as easy to type as above, I think I prefer your argument overall. We shouldn't encourage people to use the environment, and instead use config.mak or other methods which are far more explicit. -- 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_connect: clarify conn->use_shell flag
On Tue, Sep 08, 2015 at 10:18:41AM -0700, Junio C Hamano wrote: > > To make the flow easier to follow, let's just set > > conn->use_shell when we're setting up the "conn" struct, and > > unset it (with a comment) in the historical GIT_SSH case. > > Makes perfect sense. I think another thing that falls into the same > class wrt readability is 'putty'; if the code does putty=0 at the > beginning of "various flavours of SSH", and sets it only when it > checks with "various flavours of plink" when GIT_SSH_COMMAND is not > set, the logic would be even clearer, I suspect. Yeah, I think so. > > Note that for clarity we leave "use_shell" on in the case > > that we fall back to our default "ssh" This looks like a > > behavior change, but in practice run-command.c optimizes > > shell invocations without metacharacters into a straight > > execve anyway. > > Hmm, interesting. I am not sure if that has to be the way, though. > Wouldn't the resulting code become simpler if you do not do that? Heh, I originally wrote it that way, and waffled between sending one or the other. > That is, is is what I have in mind on top of your patch. Did I > break something? > > connect.c | 17 - > 1 file changed, 8 insertions(+), 9 deletions(-) I think both changes are correct, and the result looks nice to read. Feel free to squash them in as you apply. -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: [PATCH] filter-branch: add passed/remaining seconds on progress
On Tue, Sep 08, 2015 at 10:32:12AM -0700, Junio C Hamano wrote: > Also git_filter_branch__commit_count is now used only inside this > function, so it is easier to follow to increment it here. > > I suspect that the variable has this unwieldy name for historic > reasons, perhaps an attempt to avoid name clashes with the end user > script, but it has many variables (e.g. $commits, $ref, etc.) that > are way too generic and that I can see no attempt of name clash > avoidance, so renaming it to $total_commits or something _might_ > make some sense. I briefly wondered if it had the opposite reason; could it have a well-defined name because it is meant to be a public value the user-defined shell snippets can access? But it is not documented, and I can imagine that "the current count" is not really useful without "total number of commits", so in practice I doubt anybody's filter branch script is relying on it. And looking through the history turns up d5b0c97 (git-filter-branch: avoid collisions with variables in eval'ed commands, 2009-03-25), which seems fairly clear. :) The original name was "i", which I think is probably too short. Calling it something meaningful but longer than one character is probably sufficient. -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: Questions about git-push for huge repositories
On Tue, Sep 08, 2015 at 11:24:06AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > If you turn on reachability bitmaps, git _will_ do the thorough set > > difference, because it becomes much cheaper to do so. E.g., try: > > > > git repack -adb > > > > in repo A to build a single pack with bitmaps enabled. Then a subsequent > > push should send only a single object (the new commit). > > Hmph, A has the tip of B, and has a new commit B hasn't seen but A > knows that new commit's tree matches the tree of the tip of B. > > Wouldn't --thin transfer from A to B know to send only that new > commit object without sending anything below the tree in such a > case, even without the bitmap? I started to write about that in my analysis, but it gets confusing quickly. There are actually many tip trees, because A and B also share all of their tags. We do not mark every blob of every tip tree as a preferred base, because it is expensive to do so (and it just clogs our object array). Plus this only helps in the narrow circumstance that we have the exact same tree as the tip (and not, say, the same tree as master^, which I think it would be unreasonable to expect git to find). But if we do: (cd ../B && git tag | git tag -d) to delete all of the other tips besides master, leaving only the one that we know has the same tree, I'd expect git to figure it out. Certainly I would not expect it to save all of the delta compression, in the sense that we may throw away on-disk delta bases to older objects (because we don't realize the other side has those older objects). But I would have thought before we even hit that phase, adding those objects as "preferred bases" would have marked them as "do not send" in the first place. There is code in have_duplicate_entry() to handle this. I wonder why it doesn't kick in. -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: Improving auto conflict resolving while merge
On Tue, Sep 08, 2015 at 09:08:09PM -0300, Eugen Konkov wrote: > JK> you _could_ argue that those changes are independent But it's close > JK> enough that there's a good chance the two need to be reconciled, > JK> and a human should at least take a look. > > You are right and your words make sense. But this thought may apply > for this: We have one method/function about 200 lines. One author make > change at line 1 of this method and other on 199 line. Both changes > are done in one method so **human should at least take a look** Right, there is definitely a concept of "close enough" here, and git cannot catch everything. Semantic changes may even happen across files (e.g., function interface changes). So you do need to rely on things like testing and compilation to verify a merge result. But I would agree there is room for being able to tune the "closeness" of changes that cause a conflict. Right now that isn't implemented, and I'm not familiar enough with the xdiff merge code to even point you in the right direction. -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: Bug: git-upload-pack will return successfully even when it can't read all references
On Tue, Sep 08, 2015 at 02:16:03PM +0200, Ævar Arnfjörð Bjarmason wrote: > I wonder if --upload-pack="GIT_REF_PARANOIA=1 git-upload-pack" should > be the default when running fetch if you have --prune enabled. There's > a particularly bad edge case now where if you have permission errors > on the master repository and run --prune on your backup along with a > --mirror clone to mirror the refs, then when you have permission > issues you'll prune everything from the backup. > > But yeah, a proper fix needs protocol v2. Because among other things > that --upload-pack hack will only work for ssh, not http. Right. There is no real way to flip the flag from the client side, because we cannot reliably communicate it. Once we have such a mechanism, it might actually make sense to _always_ flip on paranoia. That is, we would rather an operation fail and be retried with in a "loose" mode explicitly. That's safer. It's less convenient when you have a broken repo, but surely that's the exception, right? -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: [PATCHv5 3/3] submodule: Reimplement `module_clone` shell function in C
Stefan Beller writes: > On Thu, Sep 3, 2015 at 3:07 PM, Junio C Hamano wrote: >>> + >>> + cp.no_stdin = 1; >>> + cp.no_stdout = 1; >>> + cp.no_stderr = 1; >> >> Output from "git clone" is not shown, regardless of --quiet option? > > Removed that. > >>> + argc = parse_options(argc, argv, prefix, module_clone_options, >>> + git_submodule_helper_usage, 0); >>> + >>> + strbuf_addf(&sb, "%s/modules/%s", get_git_dir(), name); >> >> The original says >> >> base_name=$(dirname "$name") >> ... > Slashes are already in use for submodule names as the name defaults > to the path if no explicit name is given. Ahh, OK, that base_name thing is so that "mkdir -p" can create a surrounding directory without creating the final level, which is left for 'git clone" to prepare. I misread the code. 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
[ANNOUNCE] Git v2.6.0-rc1
A release candidate Git v2.6.0-rc1 is now available for testing at the usual places. It is comprised of 409 non-merge commits since v2.5.0, contributed by 50 people, 12 of which are new faces. 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.6.0-rc1' 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 = 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 New contributors whose contributions weren't in v2.5.0 are as follows. Welcome to the Git development community! Antoine Delaite, Brett Randall, Brian Degenhardt, Erik Elfström, Galan Rémi, Guillaume Pagès, Jan Viktorin, Jose F. Morales, Lars Schneider, Michael Rappazzo, Simon A. Eugster, and Zoë Blade. Returning contributors who helped this release are as follows. Thanks for your continued support. Alex Henrie, Andreas Schwab, brian m. carlson, Charles Bailey, Christian Couder, Clemens Buchacher, Dave Borowitz, David Aguilar, David Turner, Elia Pinto, Eric Sunshine, Heiko Voigt, Ilya Bobyr, Jacob Keller, Jeff King, Jiang Xin, Jim Hill, Johannes Schindelin, Johannes Sixt, Junio C Hamano, Karsten Blees, Karthik Nayak, Kevin Daudt, Matthieu Moy, Michael Haggerty, Mike Hommey, Nguyễn Thái Ngọc Duy, Patrick Steinhardt, Paul Tan, Philip Oakley, Ralf Thielow, Remi Lespinet, René Scharfe, Stefan Beller, Sven Strickroth, SZEDER Gábor, Thomas Ackermann, and Thomas Braun. Git 2.6 Release Notes (draft) = Updates since v2.5 -- UI, Workflows & Features * An asterisk as a substring (as opposed to the entirety) of a path component for both side of a refspec, e.g. "refs/heads/o*:refs/remotes/heads/i*", is now allowed. * New userdiff pattern definition for fountain screenwriting markup format has been added. * "git log" and friends learned a new "--date=format:..." option to format timestamps using system's strftime(3). * "git fast-import" learned to respond to the get-mark command via its cat-blob-fd interface. * "git rebase -i" learned "drop commit-object-name subject" command as another way to skip replaying of a commit. * A new configuration variable can enable "--follow" automatically when "git log" is run with one pathspec argument. * "git status" learned to show a more detailed information regarding the "rebase -i" session in progress. * "git cat-file" learned "--batch-all-objects" option to enumerate all available objects in the repository more quickly than "rev-list --all --objects" (the output includes unreachable objects, though). * "git fsck" learned to ignore errors on a set of known-to-be-bad objects, and also allows the warning levels of various kinds of non-critical breakages to be tweaked. * "git rebase -i"'s list of todo is made configurable. * "git send-email" now performs alias-expansion on names that are given via --cccmd, etc. * An environment variable GIT_REPLACE_REF_BASE tells Git to look into refs hierarchy other than refs/replace/ for the object replacement data. * Allow untracked cache (experimental) to be used when sparse checkout (experimental) is also in use. * "git pull --rebase" has been taught to pay attention to rebase.autostash configuration. * The command-line completion script (in contrib/) has been updated. * A negative !ref entry in multi-value transfer.hideRefs configuration can be used to say "don't hide this one". * After "git am" without "-3" stops, running "git am -" pays attention to "-3" only for the patch that caused the original invocation to stop. * When linked worktree is used, simultaneous "notes merge" instances for the same ref in refs/notes/* are prevented from stomping on each other. * "git send-email" learned a new option --smtp-auth to limit the SMTP AUTH mechanisms to be used to a subset of what the system library supports. * A new configuration variable http.sslVersion can be used to specify what specific version of SSL/TLS to use to make a connection. * "git notes merge" can be told with "--strategy=" option how to automatically handle conflicts; this can now be configured by setting notes.mergeStrategy configuration variable. * "git log --cc" did not show any patch, even though most of the time the user meant "git log --cc -p -m" to see patch output for commits with a single parent, and combined diff for merge commits. The command is taught to DWIM "--cc" (without "--raw" and other forms of output specification) to "--cc -p -m". * "git config --list" output was hard to parse when values consist of multiple lines. "--name-only" o
Bug report: GIT PRO/Branches chapter
Hi, Just reading this chapter: https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell I believe that: Figure 3-9. Divergent history (https://git-scm.com/book/en/v2/book/03-git-branching/images/advance-master.png) does not show the final "2 branch situation" as described in the example in this chapter. On the picture, the master and testing branch do not point to correct commit hashes in the picture. I was thinking for a while why they are swapped and the only conclusion I made is that it's simply a bug in the picture as it also does not correspond to the correct git log output in the chapter. $ git log --oneline --decorate --graph --all * c2b9e (HEAD, master) made other changes | * 87ab2 (testing) made a change I suggest to fix the picture or clarify the reason in the chapter. Hope it helps, Robert -- 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
