* Re: [PATCH 3/6] Fix grammar
From: Junio C Hamano @ 2012-11-27 20:39 UTC (permalink / raw)
To: Max Horn; +Cc: git
In-Reply-To: <1354038279-76475-4-git-send-email-max@quendi.de>
Max Horn <max@quendi.de> writes:
> Subject: Re: [PATCH 3/6] Fix grammar
Please run "git shortlog -200 --no-merges" from the tip of your
topic branch before sending a series out, and see if you can
immediately identify what area each of your patches affects.
> Signed-off-by: Max Horn <max@quendi.de>
> ---
> Documentation/git-remote-helpers.txt | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
> index db63541..7eb43d7 100644
> --- a/Documentation/git-remote-helpers.txt
> +++ b/Documentation/git-remote-helpers.txt
> @@ -235,9 +235,9 @@ Commands are given by the caller on the helper's standard input, one per line.
> 'capabilities'::
> Lists the capabilities of the helper, one per line, ending
> with a blank line. Each capability may be preceded with '*',
> - which marks them mandatory for git version using the remote
> - helper to understand (unknown mandatory capability is fatal
> - error).
> + which marks them mandatory for git versions using the remote
> + helper to understand. Any unknown mandatory capability is a
> + fatal error.
>
> 'list'::
> Lists the refs, one per line, in the format "<value> <name>
^ permalink raw reply
* Re: Operations on unborn branch
From: Martin von Zweigbergk @ 2012-11-27 20:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd2yyn685.fsf@alter.siamese.dyndns.org>
On Tue, Nov 27, 2012 at 12:25 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Martin von Zweigbergk <martinvonz@gmail.com> writes:
>
>> simplify a lot of things (maybe I'm biased because of the things I
>> have happened to work on?)
>
> Yes. Do not waste time on it.
Yes, no way I would waste time on that; I was mostly just curious.
What I might spend time on is to fix cherry-pick.
^ permalink raw reply
* Re: git-gui: textconv not used on unstaged files
From: Peter Oberndorfer @ 2012-11-27 20:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk3t8qe4s.fsf@alter.siamese.dyndns.org>
On 2012-11-26 21:54, Junio C Hamano wrote:
> Peter Oberndorfer <kumbayo84@arcor.de> writes:
>
>> Does anybody have a idea which git command would output the diff
>> of a untracked file against /dev/null?
> The "--no-index" option is meant as a bolt-on to let you use various
> features of "git diff" that is missing from other people's "diff" in
> a context where git does not know anything about that file. It
> should be usable even outside a git repository.
>
> $ git diff --no-index /dev/null new-file.txt
>
> I do not know offhand (and didn't bother to check) if textconv
> applies, though. It does need access to a git repository as it
> reads from the $GIT_DIR/config to learn what to do.
Hi,
this seems to work when adding the --textconv option.
I will try to see if I can modify git gui to use this command
when clicking a unstaged file.
Thanks,
Greetings Peter
^ permalink raw reply
* RE: Interesting git-format-patch bug
From: Olsen, Alan R @ 2012-11-27 20:31 UTC (permalink / raw)
To: Perry Hutchison, gitster@pobox.com; +Cc: git@vger.kernel.org
In-Reply-To: <50b4304c.EwQy4JquPwsUyMfZ%perryh@pluto.rain.com>
[Sorry for the top posting. Outlook is crap.]
You are correct. I should only get one copy of the patch on branch A. Branch B was modified after the merge and git-format-patch includes the original patch from the merge and a duplicate copy with the changed comments. Note that this patch only has different comments. The body of the patch is exactly the same.
How gerrit mangles things is out of my control. I would prefer that they cherry-pick instead of merges. I have to live with the bad choices of both gerrit and developers in this case.
I guess I will have to diagram out a better example of what is happening here.
-----Original Message-----
From: Perry Hutchison [mailto:perryh@pluto.rain.com]
Sent: Monday, November 26, 2012 8:15 PM
To: gitster@pobox.com
Cc: git@vger.kernel.org; Olsen, Alan R
Subject: Re: Interesting git-format-patch bug
Junio C Hamano <gitster@pobox.com> wrote:
> "Olsen, Alan R" <alan.r.olsen@intel.com> writes:
> > I found an interesting bug in git-format-patch.
> >
> > Say you have a branch A. You create branch B and add a patch to it.
> > You then merge that patch into branch A. After the merge, some other
> > process (we will call it 'gerrit') uses annotate and changes the
> > comment on the patch that exists on branch B.
> >
> > Now someone runs git-format-patch for the last n patches on branch
> > A. You should just get the original patch that was merged over to
> > branch A. What you get is the patch that was merged to branch A
> > *and* the patch with the modified commit comment on branch B.
> > (Double the patches, double the
> > clean-up...)
>
> As you literally have patches that do essentially the same or similar
> things on two branches that was merged, you cannot expect to export
> each individual commit into a patch and not have conflicts among them.
> So I do not think there is no answer than "don't do that".
To me, this seems to miss Alan's point: only one patch was merged to branch A, so git-format-patch applied to branch A should find only one patch. It can be argued either way whether that one-patch report should include the gerrit annotations, but surely the application of gerrit on branch B, _after the merge to branch A has already been performed_, should not cause an additional patch to magically appear on branch A.
^ permalink raw reply
* Re: Operations on unborn branch
From: Junio C Hamano @ 2012-11-27 20:25 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git
In-Reply-To: <CANiSa6isDKAgxHWqh5XiQ-adT3-ASFtvAshp028DTcotjQxzmQ@mail.gmail.com>
Martin von Zweigbergk <martinvonz@gmail.com> writes:
> simplify a lot of things (maybe I'm biased because of the things I
> have happened to work on?)
Yes. Do not waste time on it.
^ permalink raw reply
* Re: [PATCH v4 3/4] git-submodule update: Add --branch option
From: W. Trevor King @ 2012-11-27 20:21 UTC (permalink / raw)
To: Heiko Voigt
Cc: Git, Junio C Hamano, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <20121127185142.GB4185@book.hvoigt.net>
[-- Attachment #1: Type: text/plain, Size: 3615 bytes --]
On Tue, Nov 27, 2012 at 07:51:42PM +0100, Heiko Voigt wrote:
> On Mon, Nov 26, 2012 at 04:00:18PM -0500, W. Trevor King wrote:
> > -b::
> > --branch::
> > - Branch of repository to add as submodule.
> > + When used with the add command, gives the branch of repository to
> > + add as submodule.
> > ++
> > +When used with the update command, checks out a branch named
> > +`submodule.<name>.branch` (as set by `--local-branch`) pointing at the
> > +current HEAD SHA-1. This is useful for commands like `update
> > +--rebase` that do not work on detached heads.
>
> Since you are reusing this option for update it further convinces me
> that reusing it for add makes sense and simplifies the logic for users.
>
> I think an optional argument for --branch would be nice in the update
> case:
>
> $ git submodule update --branch=master
>
> would then allow a user that has not configured anything (except the
> branch tracking info in the submodule of course) to pull all submodules
> master branches.
Sounds good to me. Remember that this is checking the branch and
pointing it at $sha1 (preparing for the pull), not pulling remote
branches. The pull happens in a later
$ git submodules foreach 'git pull'
> > diff --git a/git-submodule.sh b/git-submodule.sh
> > index c51b6ae..28eb4b1 100755
> > --- a/git-submodule.sh
> > +++ b/git-submodule.sh
> > @@ -627,7 +631,7 @@ Maybe you want to use 'update --init'?")"
> > die "$(eval_gettext "Unable to find current revision in submodule path '\$sm_path'")"
> > fi
> >
> > - if test "$subsha1" != "$sha1" -o -n "$force"
> > + if test "$subsha1" != "$sha1" -o -n "$force" -o "$update_module" = "branch"
>
> As said before I think separating your code from the current update
> logic will simplify the handling below.
This felt less invasive (it avoids duplicating the recursion logic),
but I don't mind breaking it into a separate function/block.
> > must_die_on_failure=
> > case "$update_module" in
> > rebase)
> > command="git rebase"
> > - die_msg="$(eval_gettext "Unable to rebase '\$sha1' in submodule path '\$sm_path'")"
> > + die_msg="$(eval_gettext "Unable to rebase '\$sha1' in submodule path '\$sm_path'")"
> > say_msg="$(eval_gettext "Submodule path '\$sm_path': rebased into '\$sha1'")"
> > - must_die_on_failure=yes
> > + must_die_on_failure=yes
>
> Please always cleanup whitespace changes.
Oops, sloppy me. Will fix.
> > then
> > - die_with_status 2 "$die_msg"
> > - else
> > - err="${err};$die_msg"
> > - continue
> > + if (clear_local_git_env; cd "$sm_path" &&
> > + git branch -f "$branch" "$sha1" &&
> > + git checkout "$branch")
>
> You wrote in earlier emails that you wanted to protect the user from
> non-fastforward changes. So I would expect a
>
> $ git pull --ff-only
I'm not pulling here, I'm doing a regular `submodule update`, and
after that's done I checkout the branch pointing at the $sha1 to which
the branch was just updated. All the submodule-state-clobbering
caveats of a usual `submodule update` still apply to this new
`submodule update --branch`, and I'm fine with that.
> BTW, I am more and more convinced that an automatically manufactured
> commit on update with --branch should be the default.
Again, there's nothing to update. The pull happens in a separate
step.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v4 0/4] git-submodule add: Add --local-branch option
From: W. Trevor King @ 2012-11-27 19:01 UTC (permalink / raw)
To: Heiko Voigt
Cc: Junio C Hamano, Git, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <20121123175402.GH2806@odin.tremily.us>
[-- Attachment #1: Type: text/plain, Size: 4525 bytes --]
On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote:
> On Mon, Nov 26, 2012 at 04:00:15PM -0500, W. Trevor King wrote:
> > From: "W. Trevor King" <wking@tremily.us>
> >
> > On Fri, Nov 23, 2012 at 12:54:02PM -0500, W. Trevor King wrote:
> > > We could add
> > >
> > > $ git submodule update --branch
> > >
> > > to checkout the gitlinked SHA1 as submodule.<name>.branch in each of
> > > the submodules, leaving the submodules on the .gitmodules-configured
> > > branch. Effectively (for each submodule):
> > >
> > > $ git branch -f $branch $sha1
> > > $ git checkout $branch
> >
> > I haven't gotten any feedback on this as an idea, but perhaps someone
> > will comment on it as a patch series ;).
>
> I am not sure I understand you correctly. You are suggesting that the
> branch option as an alias for the registered SHA1 in the superproject?
>
> I though the goal of your series was that you want to track submodules
> branch which come from the remote side?
That's what I'd initially thought, but when I went to implement
`update --pull`, I realized that
$ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && …'
is using submodule.<name>.branch as the local branch name. The remote
branch name was actually setup in .git/modules/<name>/config during
the initial "clone -b <branch> …".
The v4 series leaves the remote branch amigious, but it helps you
point the local branch at the right hash so that future calls to
$ git submodule foreach 'git pull'
can use the branch's .git/modules/<name>/config settings.
> I would think more of some convention like:
>
> $ git checkout -t origin/$branch
>
> when first initialising the submodule with e.g.
>
> $ git submodule update --init --branch
>
> Then later calls of
>
> $ git submodule update --branch
>
> would have a branch configured to pull from. I imagine that results in
> a similar behavior gerrit is doing on the server side?
That sounds like it's doing pretty much the same thing. Can you think
of a test that would distinguish it from my current v4 implementation?
> > Changes since v3:
> >
> > * --record=??? is now --local-branch=???
> > * Dropped patches 2 ($submodule_ export) and 3 (motivating documentation)
> > * Added local git-config overrides of .gitmodules' submodule.<name>.branch
> > * Added `submodule update --branch`
>
> I would prefer if we could squash all these commits together into one
> since it seems to me one logical step, using the new variable for update
> belongs together with its configuration on initialization.
>
> How about reusing the -b|--branch option for add? Since we only change
> the behavior when submodule.$name.update is set to branch it seems
> reasonable to me. Opinions?
That was the approach I used in v1, but people were concerned that we
would be stomping on previously unclaimed config space. Since noone
has pointed out other uses besides Gerrit's very similar case, I'm not
sure if that is still an issue.
> > Because you need to recurse through submodules for `update --branch`
> > even if "$subsha1" == "$sha1", I had to amend the conditional
> > controlling that block. This broke one of the existing tests, which I
> > "fixed" in patch 4. I think a proper fix would involve rewriting
> >
> > (clear_local_git_env; cd "$sm_path" &&
> > ( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&
> > test -z "$rev") || git-fetch)) ||
> > die "$(eval_gettext "Unable to fetch in submodule path '\$sm_path'")"
> >
> > but I'm not familiar enough with rev-list to want to dig into that
> > yet. If feedback for the earlier three patches is positive, I'll work
> > up a clean fix and resubmit.
>
> You probably need to separate your handling here. The comparison of the
> currently checked out sha1 and the recorded sha1 is an optimization
> which skips unnecessary fetching in case the submodules commits are
> already correct. This code snippet checks whether the to be checked out
> sha1 is already local and also skips the fetch if it is. We should not
> break that.
Agreed. However, determining if the target $sha1 is local should have
nothing to do with the current checked out $subsha1.
Thanks for the feedback!
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Re: [PATCH v4 0/4] git-submodule add: Add --local-branch option
From: Heiko Voigt @ 2012-11-27 19:16 UTC (permalink / raw)
To: W. Trevor King
Cc: Git, Junio C Hamano, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <20121127183125.GA4185@book.hvoigt.net>
Hi,
I just realized that I gave you an confusing suggestion.
On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote:
> if test "$subsha1" != "$sha1"
> then
> handle_on_demand_fetch_update ...
> else
> handle_tracked_branch_update ...
> fi
That obviously does not work. Here I meant of course something like:
if test "$update_module" = "branch"
then
handle_tracked_branch_update ...
else
handle_on_demand_fetch_update ...
fi
Cheers Heiko
^ permalink raw reply
* Re: [PATCH] diff: Fixes shortstat number of files
From: Junio C Hamano @ 2012-11-27 19:14 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: git, Linus Torvalds
In-Reply-To: <CALWbr2z+9fJGg34q7zp3knZVWgaTwtvzFBvFHRSmXfH+hc-jNw@mail.gmail.com>
Antoine Pelisse <apelisse@gmail.com> writes:
> Indeed stat seems to be broken on master by commit 74faaa16 from Linus Torvalds
>
> There are three separated issues here:
> - unmerged files are marked as "interesting" in stat and probably
> shouldn't, with some patch like this:
>
> data->is_interesting = p->status != 0;
>
> if (!one || !two) {
> data->is_unmerged = 1;
> + data->is_interesting = 0;
> return;
> }
>
> By the way, I don't get the point of this code then:
>
> else if (data->files[i]->is_unmerged) {
> fprintf(options->file, "%s", line_prefix);
> show_name(options->file, prefix, name, len);
> fprintf(options->file, " Unmerged\n");
> continue;
> }
>
> and
>
> if (file->is_unmerged) {
> /* "Unmerged" is 8 characters */
> bin_width = bin_width < 8 ? 8 : bin_width;
> continue;
> }
>
> Are we ever supposed to print that ? I feel like it could be removed.
Yes, we have been showing two entries in --stat output:
file | Unmerged
file | 4 ++++
and that is not going to change.
There are a few problems in diff.c around --stat area, partially
caused by Linus's patch (like s/is_rename/is_interesting/ change
started ignoring unmerged entries in the diff queue and made the
existing loop not go into the codepath we see above), and largely
caused by the earlier change that introduced when --stat-count was
added (the second loop that decrements total_files does so only for
the paths within the "count" horizon determined by the first loop;
total_files must be adjusted for _all_ uninteresting and unchanged
filepairs and exclude unmerged entries).
Also the initialization of data->is_interesting is wrong. These
days, p->status is never zero.
I'll send out a fix later today.
^ permalink raw reply
* Re: [PATCH v4 0/4] git-submodule add: Add --local-branch option
From: W. Trevor King @ 2012-11-27 19:04 UTC (permalink / raw)
To: Heiko Voigt
Cc: Git, Junio C Hamano, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <20121127183125.GA4185@book.hvoigt.net>
[-- Attachment #1: Type: text/plain, Size: 704 bytes --]
On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote:
> I would prefer if we could squash all these commits together into
> one since it seems to me one logical step, using the new variable
> for update belongs together with its configuration on
> initialization.
Works for me. I could also try to rework the patch boundaries if a
monolithic patch is not acceptable. I agree that the current
documentation assignments are fairly arbitrary. If I don't hear from
anyone in favor of keeping them separate, v5 will be monolithic.
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v4 3/4] git-submodule update: Add --branch option
From: Heiko Voigt @ 2012-11-27 18:51 UTC (permalink / raw)
To: W. Trevor King
Cc: Git, Junio C Hamano, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <95edff1c97c513c555652014f9c2bbf61c8e7560.1353962698.git.wking@tremily.us>
On Mon, Nov 26, 2012 at 04:00:18PM -0500, W. Trevor King wrote:
> From: "W. Trevor King" <wking@tremily.us>
>
> This allows users to checkout the current
> superproject-recorded-submodule-sha as a branch, avoiding the detached
> head state that the standard submodule update creates. This may be
> useful for the existing --rebase/--merge workflows which already avoid
> detached heads.
>
> It is also useful if you want easy tracking of upstream branches. The
> particular upstream branch to be tracked is configured locally with
> .git/modules/<name>/config. With the new option Ævar's suggested
>
> $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitm
> odules submodule.$name.branch) && git pull'
>
> reduces to a
>
> $ git submodule update --branch
>
> after each supermodule .gitmodules edit, and a
>
> $ git submodule foreach 'git pull'
>
> whenever you feel like updating the submodules. Your still on you're
> own to commit (or not) the updated submodule hashes in the
> superproject's .gitmodules.
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
> Documentation/git-submodule.txt | 20 +++++++++++------
> git-submodule.sh | 48 +++++++++++++++++++++++++++++----------
> t/t7406-submodule-update.sh | 50 ++++++++++++++++++++++++++++++++++++++++-
> 3 files changed, 98 insertions(+), 20 deletions(-)
>
> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
> index d0b4436..34392a1 100644
> --- a/Documentation/git-submodule.txt
> +++ b/Documentation/git-submodule.txt
> @@ -13,7 +13,7 @@ SYNOPSIS
> [-f|--force] [--reference <repository>] [--] <repository> [<path>]
> 'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
> 'git submodule' [--quiet] init [--] [<path>...]
> -'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]
> +'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--branch] [--rebase]
> [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
> 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>]
> [commit] [--] [<path>...]
> @@ -136,11 +136,11 @@ init::
>
> update::
> Update the registered submodules, i.e. clone missing submodules and
> - checkout the commit specified in the index of the containing repository.
> - This will make the submodules HEAD be detached unless `--rebase` or
> - `--merge` is specified or the key `submodule.$name.update` is set to
> - `rebase`, `merge` or `none`. `none` can be overridden by specifying
> - `--checkout`.
> + checkout the commit specified in the index of the containing
> + repository. This will make the submodules HEAD be detached unless
> + `--branch`, `--rebase`, `--merge` is specified or the key
> + `submodule.$name.update` is set to `branch`, `rebase`, `merge` or
> + `none`. `none` can be overridden by specifying `--checkout`.
> +
> If the submodule is not yet initialized, and you just want to use the
> setting as stored in .gitmodules, you can automatically initialize the
> @@ -207,7 +207,13 @@ OPTIONS
>
> -b::
> --branch::
> - Branch of repository to add as submodule.
> + When used with the add command, gives the branch of repository to
> + add as submodule.
> ++
> +When used with the update command, checks out a branch named
> +`submodule.<name>.branch` (as set by `--local-branch`) pointing at the
> +current HEAD SHA-1. This is useful for commands like `update
> +--rebase` that do not work on detached heads.
Since you are reusing this option for update it further convinces me
that reusing it for add makes sense and simplifies the logic for users.
I think an optional argument for --branch would be nice in the update
case:
$ git submodule update --branch=master
would then allow a user that has not configured anything (except the
branch tracking info in the submodule of course) to pull all submodules
master branches.
> diff --git a/git-submodule.sh b/git-submodule.sh
> index c51b6ae..28eb4b1 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -627,7 +631,7 @@ Maybe you want to use 'update --init'?")"
> die "$(eval_gettext "Unable to find current revision in submodule path '\$sm_path'")"
> fi
>
> - if test "$subsha1" != "$sha1" -o -n "$force"
> + if test "$subsha1" != "$sha1" -o -n "$force" -o "$update_module" = "branch"
As said before I think separating your code from the current update
logic will simplify the handling below.
> then
> subforce=$force
> # If we don't already have a -f flag and the submodule has never been checked out
> @@ -650,16 +654,21 @@ Maybe you want to use 'update --init'?")"
> case ";$cloned_modules;" in
> *";$name;"*)
> # then there is no local change to integrate
> - update_module= ;;
> + case "$update_module" in
> + rebase|merge)
> + update_module=
> + ;;
> + esac
> + ;;
> esac
>
> must_die_on_failure=
> case "$update_module" in
> rebase)
> command="git rebase"
> - die_msg="$(eval_gettext "Unable to rebase '\$sha1' in submodule path '\$sm_path'")"
> + die_msg="$(eval_gettext "Unable to rebase '\$sha1' in submodule path '\$sm_path'")"
> say_msg="$(eval_gettext "Submodule path '\$sm_path': rebased into '\$sha1'")"
> - must_die_on_failure=yes
> + must_die_on_failure=yes
Please always cleanup whitespace changes.
> ;;
> merge)
> command="git merge"
> @@ -674,15 +683,30 @@ Maybe you want to use 'update --init'?")"
> ;;
> esac
>
> then
> - die_with_status 2 "$die_msg"
> - else
> - err="${err};$die_msg"
> - continue
> + if (clear_local_git_env; cd "$sm_path" &&
> + git branch -f "$branch" "$sha1" &&
> + git checkout "$branch")
You wrote in earlier emails that you wanted to protect the user from
non-fastforward changes. So I would expect a
$ git pull --ff-only
here and the setup of that in the initialization of the submodule.
BTW, I am more and more convinced that an automatically manufactured
commit on update with --branch should be the default. What do other
think? Sascha raised a concern that he would not want this, but as far as
I understood he let the CI-server do that so I see no downside to
natively adding that to git. People who want to manually craft those
commits can still amend the generated commit. Since this is all about
helping people keeping their submodules updated why not go the full way?
Cheers Heiko
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Eric S. Raymond @ 2012-11-27 18:35 UTC (permalink / raw)
To: Magnus Bäck; +Cc: Felipe Contreras, Michael Haggerty, git
In-Reply-To: <20121127143510.GA15831@google.com>
Magnus Bäck <baeck@google.com>:
> While "constant traffic" probably overstates the issue, these are not
> theoretical problems. I recall at least three cases in the last year
> or so where Git has seen breakage with Solaris or Mac OS X because
> of sed or tr incompatibilities, and I don't even read this list that
> thoroughly.
This is exactly the sort of of pain experience would lead me to
expect.
OK, this is where I assume the full Old Fart position (30-year
old-school Unix guy, author of "The Art of Unix Programming", can
remember the years before Perl and still has sh idioms in his
fingertips) and say "Get with the 21st century, people! Or at least
1990..."
As a general scripting language shell sucks *really badly* compared to
anything new-school. Performance, portability, you name it, it's a
mess. It's not so much the shell interpreters itself that are the
portabilty problem, but (as Magnus implicitly points out) all those
userland dependencies on sed and tr and awk and even variants of
expr(!) that get dragged in the second you try to get any actual work
done.
Can we cease behaving like we're still pounding keys on 110-baud
teletypes now? Some old-school Unix habits have persisted long past
the point that they're even remotely sane. Shell programming at any
volume above a few lines of throwaway code is one of them - it's
*nuts* and we should *stop doing it*.
(Yes, I too still make this mistake occasionally out of ancient reflex.
But I know I shouldn't, and I always end up regretting it.)
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: [PATCH v4 0/4] git-submodule add: Add --local-branch option
From: Heiko Voigt @ 2012-11-27 18:31 UTC (permalink / raw)
To: W. Trevor King
Cc: Git, Junio C Hamano, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <cover.1353962698.git.wking@tremily.us>
Hi,
On Mon, Nov 26, 2012 at 04:00:15PM -0500, W. Trevor King wrote:
> From: "W. Trevor King" <wking@tremily.us>
>
> On Fri, Nov 23, 2012 at 12:54:02PM -0500, W. Trevor King wrote:
> > We could add
> >
> > $ git submodule update --branch
> >
> > to checkout the gitlinked SHA1 as submodule.<name>.branch in each of
> > the submodules, leaving the submodules on the .gitmodules-configured
> > branch. Effectively (for each submodule):
> >
> > $ git branch -f $branch $sha1
> > $ git checkout $branch
>
> I haven't gotten any feedback on this as an idea, but perhaps someone
> will comment on it as a patch series ;).
I am not sure I understand you correctly. You are suggesting that the
branch option as an alias for the registered SHA1 in the superproject?
I though the goal of your series was that you want to track submodules
branch which come from the remote side?
Doing the above does not assist you much in that does it?
I would think more of some convention like:
$ git checkout -t origin/$branch
when first initialising the submodule with e.g.
$ git submodule update --init --branch
Then later calls of
$ git submodule update --branch
would have a branch configured to pull from. I imagine that results in
a similar behavior gerrit is doing on the server side?
> Changes since v3:
>
> * --record=??? is now --local-branch=???
> * Dropped patches 2 ($submodule_ export) and 3 (motivating documentation)
> * Added local git-config overrides of .gitmodules' submodule.<name>.branch
> * Added `submodule update --branch`
I would prefer if we could squash all these commits together into one
since it seems to me one logical step, using the new variable for update
belongs together with its configuration on initialization.
How about reusing the -b|--branch option for add? Since we only change
the behavior when submodule.$name.update is set to branch it seems
reasonable to me. Opinions?
> Because you need to recurse through submodules for `update --branch`
> even if "$subsha1" == "$sha1", I had to amend the conditional
> controlling that block. This broke one of the existing tests, which I
> "fixed" in patch 4. I think a proper fix would involve rewriting
>
> (clear_local_git_env; cd "$sm_path" &&
> ( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&
> test -z "$rev") || git-fetch)) ||
> die "$(eval_gettext "Unable to fetch in submodule path '\$sm_path'")"
>
> but I'm not familiar enough with rev-list to want to dig into that
> yet. If feedback for the earlier three patches is positive, I'll work
> up a clean fix and resubmit.
You probably need to separate your handling here. The comparison of the
currently checked out sha1 and the recorded sha1 is an optimization
which skips unnecessary fetching in case the submodules commits are
already correct. This code snippet checks whether the to be checked out
sha1 is already local and also skips the fetch if it is. We should not
break that.
Maybe we need an else block here and possibly extract the current code
inside the if statement into a function. E.g. that the final code looks
something like this:
if test "$subsha1" != "$sha1"
then
handle_on_demand_fetch_update ...
else
handle_tracked_branch_update ...
fi
Not sure about the function names though. If we decide to go that route:
The extraction into a function should go in an extra preparation patch
which does not change any functionality.
I will reply to the patches for further comments.
Cheers Heiko
^ permalink raw reply
* Re: [PATCH 2/4] t4041 (diff-submodule-option): rewrite add_file() routine
From: Junio C Hamano @ 2012-11-27 17:56 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List
In-Reply-To: <1354005692-2809-3-git-send-email-artagnon@gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Instead of "cd there and then come back", use the "cd there in a
> subshell" pattern. Also fix '&&' chaining in one place.
>
> Suggested-by: Junio C Hamano <gitster@pobox.com>
> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
> ---
> t/t4041-diff-submodule-option.sh | 13 +++++--------
> 1 files changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/t/t4041-diff-submodule-option.sh b/t/t4041-diff-submodule-option.sh
> index cfb71e5..103c690 100755
> --- a/t/t4041-diff-submodule-option.sh
> +++ b/t/t4041-diff-submodule-option.sh
> @@ -11,18 +11,15 @@ This test tries to verify the sanity of the --submodule option of git diff.
> . ./test-lib.sh
>
> add_file () {
> + (cd "$1" &&
> + shift &&
> + for name; do
> echo "$name" > "$name" &&
> git add "$name" &&
> test_tick &&
> git commit -m "Add $name"
> + done >/dev/null &&
> + git rev-parse --short --verify HEAD)
While at it, why not do the "indent with a single tab", and other
style fixes? e.g.
(
cd "$1" &&
shift &&
for name
do
echo "$name" >"$name" &&
git add $name" &&
test_tick &&
git commit -m "Add $name" || exit
done >/dev/null &&
git rev-parse --short --verify HEAD
)
The "|| exit" is needed to catch failures inside the loop (not that
"git commit" there is likely to fail, so it is just for
completeness).
^ permalink raw reply
* Re: [PATCH] Third try at documenting command integration requirements.
From: Eric S. Raymond @ 2012-11-27 17:56 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Junio C Hamano, git
In-Reply-To: <50B4A8E1.7050801@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu>:
> OK, now let's discuss *which* minimum Python version that git should
> support in the hypothetical new world...
By all means!
> It would be a shame to leave RHEL 5 users behind if Python is used to
> implement important git functionality. Python 2.4 is missing some of
> Python's shiny new features, but still quite OK. What features would
> you miss the most if we were to target Python 2.4 instead of 2.6?
Off the top of my head...the 'with' statement, the conditional
expression, and built-in JSON support. Other developers would be
likely to kick about the string format() method; personally I'm
cheerfully old-school about that.
I agree that 2.4 is still quite OK. I'm a little concerned that dropping that
far back might store up some transition problems for the day we decide to
make the jump to Python 3.
On the other hand, I think gating features on RHEL5 might be
excessively cautious. According to [1], RHEL will red-zone within 30
days if it hasn't done so already ([1] says "Q4"). And RHEL6 (with
Python 2.6) has been shipping for two years.
Policy suggestion: we aim to stay friendly for every version of RHEL that
is still in Support 1. I doubt anyone will code anything critical
in Python before Dec 31st - I'm certainly not planning to!
[1] http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux RHEL5 is going
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: [PATCH 4/4] t4041 (diff-submodule-option): change tense of test names
From: Junio C Hamano @ 2012-11-27 17:51 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List
In-Reply-To: <1354005692-2809-5-git-send-email-artagnon@gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Change the tense of test names from past to present, as this is the
> prevalent style.
>
> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
> ---
I see most of them are not "past" but "past particle" used as if
they are adjectives.
For example, I think this test
> -test_expect_success 'added submodule' '
tries to say "See what happens to an added submodule".
The same for the others.
> -test_expect_success 'modified submodule(forward)' '
"See what is shown for modified submodule."
> -test_expect_success 'typechanged submodule(submodule->blob), --cached' '
"See what is shown for typechanged one, when --cached option is
given".
So I do not think this patch is needed; the current wording looks
not so grammatically kosher, but still is understandable. Updated
result isn't.
^ permalink raw reply
* Why is this known by git but not by gitk
From: Kevin O'Gorman @ 2012-11-27 17:50 UTC (permalink / raw)
To: git
I just converted a SourceForge CVS repo to git using cvs2svn. One
directory in the result is named CVSROOT and everything would be fine,
but I wan to know why gitk does not see it.
Git itself does not report it either, but it lets me "git rm -r
CVSROOT" and stages the change.
I just want to know what's up with this before I commit myself to
using this converted repo.
--
Kevin O'Gorman
programmer, n. an organism that transmutes caffeine into software.
^ permalink raw reply
* [PATCH 0/6] Improve remote helper documentation
From: Max Horn @ 2012-11-27 17:44 UTC (permalink / raw)
To: git; +Cc: Max Horn
Various remote helper capabilities and commands were not
documented, in particular 'export', or documented in a misleading
way (e.g. 'for-push' was listed as a ref attribute understood by
git, which is not the case). This patch series changes that, and
also address some other things in the remote helper documentation
that I found jarring when reading through it.
Note that the description of export and (im|ex)port-marks probably can be
improved, and I hope that somebody who knows more about them
than me and/or is better at writing documentation will do just that.
But I felt it was better to provide something than to do nothing
and only complain, as I did previously on this subject ;-).
Max Horn (6):
Document invocation first, then input format
Document missing remote helper capabilities
Fix grammar
Rearrange the description of remote helper capabilities
Make clearer which commands must be supported for which capabilities
Remove 'for-push' from ref list attributes list, link to subsections
Documentation/git-remote-helpers.txt | 241 ++++++++++++++++++++---------------
1 file changed, 136 insertions(+), 105 deletions(-)
--
1.8.0.393.gcc9701d
^ permalink raw reply
* [PATCH 1/6] Document invocation first, then input format
From: Max Horn @ 2012-11-27 17:44 UTC (permalink / raw)
To: git; +Cc: Max Horn
In-Reply-To: <1354038279-76475-1-git-send-email-max@quendi.de>
In the distant past, the order was 'Invocation', 'Commands',
'Capabilities', ...
Then it was decided that before giving a list of Commands, there
should be an overall description of the 'Input format', which was
a wise decision. However, this description was put as the very
first thing, with the rationale that any implementor would want
to know that first.
However, it seems an implementor would actually first need to
know how the remote helper will be invoked, so moving
'Invocation' to the front again seems logical. Moreover, we now
don't switch from discussing the input format to the invocation
style and then back to input related stuff.
Signed-off-by: Max Horn <max@quendi.de>
---
Documentation/git-remote-helpers.txt | 62 ++++++++++++++++++------------------
1 file changed, 31 insertions(+), 31 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
index 5ce4cda..9a7e583 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -35,6 +35,37 @@ transport protocols, such as 'git-remote-http', 'git-remote-https',
'git-remote-ftp' and 'git-remote-ftps'. They implement the capabilities
'fetch', 'option', and 'push'.
+INVOCATION
+----------
+
+Remote helper programs are invoked with one or (optionally) two
+arguments. The first argument specifies a remote repository as in git;
+it is either the name of a configured remote or a URL. The second
+argument specifies a URL; it is usually of the form
+'<transport>://<address>', but any arbitrary string is possible.
+The 'GIT_DIR' environment variable is set up for the remote helper
+and can be used to determine where to store additional data or from
+which directory to invoke auxiliary git commands.
+
+When git encounters a URL of the form '<transport>://<address>', where
+'<transport>' is a protocol that it cannot handle natively, it
+automatically invokes 'git remote-<transport>' with the full URL as
+the second argument. If such a URL is encountered directly on the
+command line, the first argument is the same as the second, and if it
+is encountered in a configured remote, the first argument is the name
+of that remote.
+
+A URL of the form '<transport>::<address>' explicitly instructs git to
+invoke 'git remote-<transport>' with '<address>' as the second
+argument. If such a URL is encountered directly on the command line,
+the first argument is '<address>', and if it is encountered in a
+configured remote, the first argument is the name of that remote.
+
+Additionally, when a configured remote has 'remote.<name>.vcs' set to
+'<transport>', git explicitly invokes 'git remote-<transport>' with
+'<name>' as the first argument. If set, the second argument is
+'remote.<name>.url'; otherwise, the second argument is omitted.
+
INPUT FORMAT
------------
@@ -173,37 +204,6 @@ advertised with this capability must cover all refs reported by
the list command. If no 'refspec' capability is advertised,
there is an implied `refspec *:*`.
-INVOCATION
-----------
-
-Remote helper programs are invoked with one or (optionally) two
-arguments. The first argument specifies a remote repository as in git;
-it is either the name of a configured remote or a URL. The second
-argument specifies a URL; it is usually of the form
-'<transport>://<address>', but any arbitrary string is possible.
-The 'GIT_DIR' environment variable is set up for the remote helper
-and can be used to determine where to store additional data or from
-which directory to invoke auxiliary git commands.
-
-When git encounters a URL of the form '<transport>://<address>', where
-'<transport>' is a protocol that it cannot handle natively, it
-automatically invokes 'git remote-<transport>' with the full URL as
-the second argument. If such a URL is encountered directly on the
-command line, the first argument is the same as the second, and if it
-is encountered in a configured remote, the first argument is the name
-of that remote.
-
-A URL of the form '<transport>::<address>' explicitly instructs git to
-invoke 'git remote-<transport>' with '<address>' as the second
-argument. If such a URL is encountered directly on the command line,
-the first argument is '<address>', and if it is encountered in a
-configured remote, the first argument is the name of that remote.
-
-Additionally, when a configured remote has 'remote.<name>.vcs' set to
-'<transport>', git explicitly invokes 'git remote-<transport>' with
-'<name>' as the first argument. If set, the second argument is
-'remote.<name>.url'; otherwise, the second argument is omitted.
-
COMMANDS
--------
--
1.8.0.393.gcc9701d
^ permalink raw reply related
* [PATCH 6/6] Remove 'for-push' from ref list attributes list, link to subsections
From: Max Horn @ 2012-11-27 17:44 UTC (permalink / raw)
To: git; +Cc: Max Horn
In-Reply-To: <1354038279-76475-1-git-send-email-max@quendi.de>
The documentation was misleading in that it gave the impression that
'for-push' could be used as a ref attribute in the output of the
'list' command. That is wrong.
Signed-off-by: Max Horn <max@quendi.de>
---
Documentation/git-remote-helpers.txt | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
index 023dcca..081cb06 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -227,6 +227,8 @@ Support for this command is mandatory.
the name; unrecognized attributes are ignored. The list ends
with a blank line.
+
+See REF LIST ATTRIBUTES for a list of currently defined options.
++
Supported if the helper has the "fetch" or "import" capability.
'list for-push'::
@@ -248,6 +250,8 @@ Supported if the helper has the "push" or "export" capability.
for it). Options should be set before other commands,
and may influence the behavior of those commands.
+
+See OPTIONS for a list of currently defined options.
++
Supported if the helper has the "option" capability.
'fetch' <sha1> <name>::
@@ -256,7 +260,7 @@ Supported if the helper has the "option" capability.
per line, terminated with a blank line.
Outputs a single blank line when all fetch commands in the
same batch are complete. Only objects which were reported
- in the ref list with a sha1 may be fetched this way.
+ in the output of 'list' with a sha1 may be fetched this way.
+
Optionally may output a 'lock <file>' line indicating a file under
GIT_DIR/objects/pack which is keeping a pack until refs can be
@@ -360,10 +364,9 @@ capabilities reported by the helper.
REF LIST ATTRIBUTES
-------------------
-'for-push'::
- The caller wants to use the ref list to prepare push
- commands. A helper might chose to acquire the ref list by
- opening a different type of connection to the destination.
+The 'list' command produces a list of refs in which each ref
+may be followed by a list of attributes. The following ref list
+attributes are defined.
'unchanged'::
This ref is unchanged since the last import or fetch, although
--
1.8.0.393.gcc9701d
^ permalink raw reply related
* [PATCH 5/6] Make clearer which commands must be supported for which capabilities
From: Max Horn @ 2012-11-27 17:44 UTC (permalink / raw)
To: git; +Cc: Max Horn
In-Reply-To: <1354038279-76475-1-git-send-email-max@quendi.de>
In particular, document 'list for-push' separately from 'list',
as the former needs only be supported for the 'push' capability,
and the latter only for fetch/import/export. In particular,
a hypothetically 'push-only' helper only needs to support the
former, not the latter.
Signed-off-by: Max Horn <max@quendi.de>
---
Documentation/git-remote-helpers.txt | 21 ++++++++++++++++-----
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
index 7ac1461..023dcca 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -216,6 +216,8 @@ Commands are given by the caller on the helper's standard input, one per line.
which marks them mandatory for git versions using the remote
helper to understand. Any unknown mandatory capability is a
fatal error.
++
+Support for this command is mandatory.
'list'::
Lists the refs, one per line, in the format "<value> <name>
@@ -225,9 +227,18 @@ Commands are given by the caller on the helper's standard input, one per line.
the name; unrecognized attributes are ignored. The list ends
with a blank line.
+
-If 'push' is supported this may be called as 'list for-push'
-to obtain the current refs prior to sending one or more 'push'
-commands to the helper.
+Supported if the helper has the "fetch" or "import" capability.
+
+'list for-push'::
+ Similar to 'list', except that it is used if and only if
+ the caller wants to the resulting ref list to prepare
+ push commands.
+ A helper supporting both push and fetch can use this
+ to distinguish for which operation the output of 'list'
+ is going to be used, possibly reducing the amount
+ of work that needs to be performed.
++
+Supported if the helper has the "push" or "export" capability.
'option' <name> <value>::
Sets the transport helper option <name> to <value>. Outputs a
@@ -306,7 +317,7 @@ sequence has to be buffered before starting to send data to fast-import
to prevent mixing of commands and fast-import responses on the helper's
stdin.
+
-Supported if the helper has the 'import' capability.
+Supported if the helper has the "import" capability.
'export'::
Instructs the remote helper that any subsequent input is
@@ -322,7 +333,7 @@ fast-export', which then will load/store a table of marks for
local objects. This can be used to implement for incremental
operations.
+
-Supported if the helper has the 'export' capability.
+Supported if the helper has the "export" capability.
'connect' <service>::
Connects to given service. Standard input and standard output
--
1.8.0.393.gcc9701d
^ permalink raw reply related
* [PATCH 3/6] Fix grammar
From: Max Horn @ 2012-11-27 17:44 UTC (permalink / raw)
To: git; +Cc: Max Horn
In-Reply-To: <1354038279-76475-1-git-send-email-max@quendi.de>
Signed-off-by: Max Horn <max@quendi.de>
---
Documentation/git-remote-helpers.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
index db63541..7eb43d7 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -235,9 +235,9 @@ Commands are given by the caller on the helper's standard input, one per line.
'capabilities'::
Lists the capabilities of the helper, one per line, ending
with a blank line. Each capability may be preceded with '*',
- which marks them mandatory for git version using the remote
- helper to understand (unknown mandatory capability is fatal
- error).
+ which marks them mandatory for git versions using the remote
+ helper to understand. Any unknown mandatory capability is a
+ fatal error.
'list'::
Lists the refs, one per line, in the format "<value> <name>
--
1.8.0.393.gcc9701d
^ permalink raw reply related
* [PATCH 2/6] Document missing remote helper capabilities
From: Max Horn @ 2012-11-27 17:44 UTC (permalink / raw)
To: git; +Cc: Max Horn
In-Reply-To: <1354038279-76475-1-git-send-email-max@quendi.de>
The 'export' and '(im|ex)port-marks' capabilities were not
documented at all
Signed-off-by: Max Horn <max@quendi.de>
---
Documentation/git-remote-helpers.txt | 45 +++++++++++++++++++++++++++++++++---
1 file changed, 42 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
index 9a7e583..db63541 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -106,6 +106,10 @@ to the `capabilities` command (see COMMANDS, below).
For listing remote refs and fetching the associated history to
the local object store.
+'export'::
+ For listing remote refs and pushing specified objects from a
+ fast-import stream to remote refs.
+
'import'::
For listing remote refs and fetching the associated history as
a fast-import stream.
@@ -143,6 +147,16 @@ there is an implied `refspec *:*`.
This is to prevent mixing commands and fast-import responses on the
helper's stdin.
+'export-marks' <file>::
+ This modifies the 'export' capability, instructing git to dump the
+ internal marks table to <file> when complete. For details,
+ read up on '--export-marks=<file>' in linkgit:git-fast-export[1].
+
+'import-marks' <file>::
+ This modifies the 'export' capability, instructing git to load the
+ marks specified in <file> before processing any input. For details,
+ read up on '--import-marks=<file>' in linkgit:git-fast-export[1].
+
Capabilities for Pushing
~~~~~~~~~~~~~~~~~~~~~~~~
'connect'::
@@ -158,9 +172,18 @@ Supported commands: 'connect'.
+
Supported commands: 'list for-push', 'push'.
-If a helper advertises both 'connect' and 'push', git will use
-'connect' if possible and fall back to 'push' if the helper requests
-so when connecting (see the 'connect' command under COMMANDS).
+'export'::
+ Can discover remote refs and push specified objects from a
+ fast-import stream to remote refs.
++
+Supported commands: 'list for-push', 'export'.
+
+If a helper advertises 'connect', git will use it if possible and
+fall back to another capability if the helper requests so when
+connecting (see the 'connect' command under COMMANDS).
+When choosing between 'push' and 'export', git prefers 'push'.
+Other frontends may have some other order of preference.
+
Capabilities for Fetching
~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -307,6 +330,22 @@ stdin.
+
Supported if the helper has the 'import' capability.
+'export'::
+ Instructs the remote helper that any subsequent input is
+ part of a fast-import stream (generated by 'git fast-export')
+ containing objects which should be pushed to the remote.
++
+Especially useful for interoperability with a foreign versioning
+system.
++
+The 'export-marks' and 'import-marks' capabilities, if specified,
+affect this command in so far as they are passed on to 'git
+fast-export', which then will load/store a table of marks for
+local objects. This can be used to implement for incremental
+operations.
++
+Supported if the helper has the 'export' capability.
+
'connect' <service>::
Connects to given service. Standard input and standard output
of helper are connected to specified service (git prefix is
--
1.8.0.393.gcc9701d
^ permalink raw reply related
* [PATCH 4/6] Rearrange the description of remote helper capabilities
From: Max Horn @ 2012-11-27 17:44 UTC (permalink / raw)
To: git; +Cc: Max Horn
In-Reply-To: <1354038279-76475-1-git-send-email-max@quendi.de>
This also remove some duplication in the descriptions
(e.g. refspec was explained twice with similar level of detail)
Signed-off-by: Max Horn <max@quendi.de>
---
Documentation/git-remote-helpers.txt | 134 +++++++++++++++--------------------
1 file changed, 56 insertions(+), 78 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
index 7eb43d7..7ac1461 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -88,81 +88,17 @@ Each remote helper is expected to support only a subset of commands.
The operations a helper supports are declared to git in the response
to the `capabilities` command (see COMMANDS, below).
-'option'::
- For specifying settings like `verbosity` (how much output to
- write to stderr) and `depth` (how much history is wanted in the
- case of a shallow clone) that affect how other commands are
- carried out.
-
-'connect'::
- For fetching and pushing using git's native packfile protocol
- that requires a bidirectional, full-duplex connection.
-
-'push'::
- For listing remote refs and pushing specified objects from the
- local object store to remote refs.
-
-'fetch'::
- For listing remote refs and fetching the associated history to
- the local object store.
-
-'export'::
- For listing remote refs and pushing specified objects from a
- fast-import stream to remote refs.
-
-'import'::
- For listing remote refs and fetching the associated history as
- a fast-import stream.
-
-'refspec' <refspec>::
- This modifies the 'import' capability, allowing the produced
- fast-import stream to modify refs in a private namespace
- instead of writing to refs/heads or refs/remotes directly.
- It is recommended that all importers providing the 'import'
- capability use this.
-+
-A helper advertising the capability
-`refspec refs/heads/*:refs/svn/origin/branches/*`
-is saying that, when it is asked to `import refs/heads/topic`, the
-stream it outputs will update the `refs/svn/origin/branches/topic`
-ref.
-+
-This capability can be advertised multiple times. The first
-applicable refspec takes precedence. The left-hand of refspecs
-advertised with this capability must cover all refs reported by
-the list command. If no 'refspec' capability is advertised,
-there is an implied `refspec *:*`.
-
-'bidi-import'::
- The fast-import commands 'cat-blob' and 'ls' can be used by remote-helpers
- to retrieve information about blobs and trees that already exist in
- fast-import's memory. This requires a channel from fast-import to the
- remote-helper.
- If it is advertised in addition to "import", git establishes a pipe from
- fast-import to the remote-helper's stdin.
- It follows that git and fast-import are both connected to the
- remote-helper's stdin. Because git can send multiple commands to
- the remote-helper it is required that helpers that use 'bidi-import'
- buffer all 'import' commands of a batch before sending data to fast-import.
- This is to prevent mixing commands and fast-import responses on the
- helper's stdin.
-
-'export-marks' <file>::
- This modifies the 'export' capability, instructing git to dump the
- internal marks table to <file> when complete. For details,
- read up on '--export-marks=<file>' in linkgit:git-fast-export[1].
-
-'import-marks' <file>::
- This modifies the 'export' capability, instructing git to load the
- marks specified in <file> before processing any input. For details,
- read up on '--import-marks=<file>' in linkgit:git-fast-export[1].
+In the following, we list all defined capabilities and for
+each we list which commands a helper with that capability
+must provide.
Capabilities for Pushing
-~~~~~~~~~~~~~~~~~~~~~~~~
+^^^^^^^^^^^^^^^^^^^^^^^^
'connect'::
Can attempt to connect to 'git receive-pack' (for pushing),
- 'git upload-pack', etc for communication using the
- packfile protocol.
+ 'git upload-pack', etc for communication using
+ git's native packfile protocol. This
+ requires a bidirectional, full-duplex connection.
+
Supported commands: 'connect'.
@@ -186,11 +122,12 @@ Other frontends may have some other order of preference.
Capabilities for Fetching
-~~~~~~~~~~~~~~~~~~~~~~~~~
+^^^^^^^^^^^^^^^^^^^^^^^^^
'connect'::
Can try to connect to 'git upload-pack' (for fetching),
'git receive-pack', etc for communication using the
- packfile protocol.
+ git's native packfile protocol. This
+ requires a bidirectional, full-duplex connection.
+
Supported commands: 'connect'.
@@ -212,14 +149,27 @@ connecting (see the 'connect' command under COMMANDS).
When choosing between 'fetch' and 'import', git prefers 'fetch'.
Other frontends may have some other order of preference.
+Miscellaneous capabilities
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+'option'::
+ For specifying settings like `verbosity` (how much output to
+ write to stderr) and `depth` (how much history is wanted in the
+ case of a shallow clone) that affect how other commands are
+ carried out.
+
'refspec' <refspec>::
- This modifies the 'import' capability.
+ This modifies the 'import' capability, allowing the produced
+ fast-import stream to modify refs in a private namespace
+ instead of writing to refs/heads or refs/remotes directly.
+ It is recommended that all importers providing the 'import'
+ capability use this.
+
-A helper advertising
+A helper advertising the capability
`refspec refs/heads/*:refs/svn/origin/branches/*`
-in its capabilities is saying that, when it handles
-`import refs/heads/topic`, the stream it outputs will update the
-`refs/svn/origin/branches/topic` ref.
+is saying that, when it is asked to `import refs/heads/topic`, the
+stream it outputs will update the `refs/svn/origin/branches/topic`
+ref.
+
This capability can be advertised multiple times. The first
applicable refspec takes precedence. The left-hand of refspecs
@@ -227,6 +177,34 @@ advertised with this capability must cover all refs reported by
the list command. If no 'refspec' capability is advertised,
there is an implied `refspec *:*`.
+'bidi-import'::
+ This modifies the 'import' capability.
+ The fast-import commands 'cat-blob' and 'ls' can be used by remote-helpers
+ to retrieve information about blobs and trees that already exist in
+ fast-import's memory. This requires a channel from fast-import to the
+ remote-helper.
+ If it is advertised in addition to "import", git establishes a pipe from
+ fast-import to the remote-helper's stdin.
+ It follows that git and fast-import are both connected to the
+ remote-helper's stdin. Because git can send multiple commands to
+ the remote-helper it is required that helpers that use 'bidi-import'
+ buffer all 'import' commands of a batch before sending data to fast-import.
+ This is to prevent mixing commands and fast-import responses on the
+ helper's stdin.
+
+'export-marks' <file>::
+ This modifies the 'export' capability, instructing git to dump the
+ internal marks table to <file> when complete. For details,
+ read up on '--export-marks=<file>' in linkgit:git-fast-export[1].
+
+'import-marks' <file>::
+ This modifies the 'export' capability, instructing git to load the
+ marks specified in <file> before processing any input. For details,
+ read up on '--import-marks=<file>' in linkgit:git-fast-export[1].
+
+
+
+
COMMANDS
--------
--
1.8.0.393.gcc9701d
^ permalink raw reply related
* Re: [PATCH 1/4] t4041 (diff-submodule-option): parse digests sensibly
From: Junio C Hamano @ 2012-11-27 17:38 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List
In-Reply-To: <1354005692-2809-2-git-send-email-artagnon@gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> `git rev-list --max-count=1 HEAD` is a roundabout way of saying `git
> rev-parse --verify HEAD`; replace a bunch of instances of the former
> with the latter. Also, don't unnecessarily `cut -c1-7` the rev-parse
> output when the `--short` option is available.
>
> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
> ---
> t/t4041-diff-submodule-option.sh | 14 +++++++-------
> 1 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/t/t4041-diff-submodule-option.sh b/t/t4041-diff-submodule-option.sh
> index 5377639..cfb71e5 100755
> --- a/t/t4041-diff-submodule-option.sh
> +++ b/t/t4041-diff-submodule-option.sh
> @@ -21,7 +21,7 @@ add_file () {
> test_tick &&
> git commit -m "Add $name"
> done >/dev/null
> - git rev-parse --verify HEAD | cut -c1-7
> + git rev-parse --short --verify HEAD
> cd "$owd"
> }
> commit_file () {
> @@ -33,7 +33,7 @@ test_create_repo sm1 &&
> add_file . foo >/dev/null
>
> head1=$(add_file sm1 foo1 foo2)
> -fullhead1=$(cd sm1; git rev-list --max-count=1 $head1)
> +fullhead1=$(cd sm1; git rev-parse --verify $head1)
That still is a roundabout way to say "git rev-parse --verify HEAD",
no? Why feed a shortened one to get the expanded result when you
know the full representation of HEAD is what you want?
> test_expect_success 'added submodule' "
> git add sm1 &&
> @@ -116,8 +116,8 @@ EOF
> test_cmp expected actual
> "
>
> -fullhead2=$(cd sm1; git rev-list --max-count=1 $head2)
> test_expect_success 'modified submodule(forward) --submodule=short' "
> +fullhead2=$(cd sm1; git rev-parse --verify $head2)
> git diff --submodule=short >actual &&
> cat >expected <<-EOF &&
> diff --git a/sm1 b/sm1
> @@ -135,7 +135,7 @@ commit_file sm1 &&
> head3=$(
> cd sm1 &&
> git reset --hard HEAD~2 >/dev/null &&
> - git rev-parse --verify HEAD | cut -c1-7
> + git rev-parse --short --verify HEAD
> )
>
> test_expect_success 'modified submodule(backward)' "
> @@ -220,8 +220,8 @@ EOF
> rm -f sm1 &&
> test_create_repo sm1 &&
> head6=$(add_file sm1 foo6 foo7)
> -fullhead6=$(cd sm1; git rev-list --max-count=1 $head6)
> test_expect_success 'nonexistent commit' "
> +fullhead6=$(cd sm1; git rev-parse --verify $head6)
> git diff-index -p --submodule=log HEAD >actual &&
> cat >expected <<-EOF &&
> Submodule sm1 $head4...$head6 (commits not present)
> @@ -318,8 +318,8 @@ EOF
> "
>
> (cd sm1; git commit -mchange foo6 >/dev/null) &&
> -head8=$(cd sm1; git rev-parse --verify HEAD | cut -c1-7) &&
> test_expect_success 'submodule is modified' "
> +head8=$(cd sm1; git rev-parse --short --verify HEAD) &&
> git diff-index -p --submodule=log HEAD >actual &&
> cat >expected <<-EOF &&
> Submodule sm1 $head6..$head8:
> @@ -461,7 +461,7 @@ EOF
> test_cmp expected actual
> "
>
> -fullhead7=$(cd sm2; git rev-list --max-count=1 $head7)
> +fullhead7=$(cd sm2; git rev-parse --verify $head7)
>
> test_expect_success 'given commit --submodule=short' "
> git diff-index -p --submodule=short HEAD^ >actual &&
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox