push.default documented in man git-push?

[David Glasser]

Is the newish push.default documented in the git push manpage
anywhere? I don't see it mentioned (and there are several references
to the default behavior), but maybe I'm missing something. Is it
left out on purpose (ie, config values aren't supposed to be mentioned
in command manpages)?

--dave

-- 
glas...@davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/
--
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: push.default documented in man git-push?

[David Glasser]

Thanks Rankumar! There's also the reference in the git push origin
example and the This is the default operation mode if no explicit
refspec is found.

(I would have sent my own patch but I can't figure out where the
syntax for the manpages is documented.)

--dave

On Tue, Oct 2, 2012 at 8:09 AM, Ramkumar Ramachandra artag...@gmail.com wrote:
 David Glasser wrote:
 Is the newish push.default documented in the git push manpage
 anywhere? I don't see it mentioned (and there are several references
 to the default behavior), but maybe I'm missing something. Is it
 left out on purpose (ie, config values aren't supposed to be mentioned
 in command manpages)?

 You're right.  It's documented in `man git-config`, but we should
 probably mention it in the `git-push` manpage.

 --8--
 From: Ramkumar Ramachandra artag...@gmail.com
 Date: Tue, 2 Oct 2012 20:37:13 +0530
 Subject: [PATCH] Documentation: mention `push.default` in git-push.txt

 Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
 ---
  Documentation/git-push.txt | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
 index cb97cc1..8751b38 100644
 --- a/Documentation/git-push.txt
 +++ b/Documentation/git-push.txt
 @@ -37,7 +37,8 @@ OPTIONS[[OPTIONS]]
 `+`, followed by the source ref src, followed
 by a colon `:`, followed by the destination ref dst.
 It is used to specify with what src object the dst ref
 -   in the remote repository is to be updated.
 +   in the remote repository is to be updated.  If not specified,
 +   the configuration variable `push.default` is used.
  +
  The src is often the name of the branch you would want to push, but
  it can be any arbitrary SHA-1 expression, such as `master~4` or
 --
 1.7.12.1.428.g652398a.dirty



-- 
glas...@davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/
--
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: push.default documented in man git-push?

[David Glasser]

Thanks Junio! Note that I think the word is usually spelled
controlled not controled.

On Tue, Oct 2, 2012 at 11:34 AM, Junio C Hamano gits...@pobox.com wrote:
 Ramkumar Ramachandra artag...@gmail.com writes:

 David Glasser wrote:
 Thanks Rankumar! There's also the reference in the git push origin
 example and the This is the default operation mode if no explicit
 refspec is found.

 Sorry;  here's a revised patch.

 --8--

 FYI: the above is not a scissors line.

 From: Ramkumar Ramachandra artag...@gmail.com
 Date: Tue, 2 Oct 2012 21:06:05 +0530
 Subject: [PATCH] Documentation: mention `push.default` in git-push.txt

 Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
 ---
  Documentation/git-push.txt | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

 diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
 index cb97cc1..e1e9aca 100644
 --- a/Documentation/git-push.txt
 +++ b/Documentation/git-push.txt
 @@ -37,7 +37,8 @@ OPTIONS[[OPTIONS]]
 `+`, followed by the source ref src, followed
 by a colon `:`, followed by the destination ref dst.
 It is used to specify with what src object the dst ref
 -   in the remote repository is to be updated.
 +   in the remote repository is to be updated.  If not specified,
 +   the configuration variable `push.default` is used.

 I think this is way suboptimal; it is begging users to do this

 [push]
 default = frotz:xyzzy

 by making it sound as if push.default gives a default for refs.

 @@ -65,7 +66,8 @@ directs git to push matching branches: for every
 branch that
  the local side, the remote side is updated if a branch of the same name
  already exists on the remote side.  This is the default operation mode
  if no explicit refspec is found (that is neither on the command line
 -nor in any Push line of the corresponding remotes file---see below).
 +nor in any Push line of the corresponding remotes file, or `push.default`
 +---see below).

 Likewise.  The added part should not be inside the parentheses,
 which is about what the value used for refspec.  `push.default` is
 about what happens when there is _no_ refspec.

 I'll queue this instead.  Thanks.

 -- 8 --
 From: Ramkumar Ramachandra artag...@gmail.com
 Date: Tue, 2 Oct 2012 21:08:00 +0530
 Subject: [PATCH] Documentation: mention `push.default` in git-push.txt

 It already is listed in the git config documentation, but people
 interested in pushing would first look at git push documentation.

 Noticed-by: David Glasser
 Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
 Acked-by: Matthieu Moy matthieu@grenoble-inp.fr
 Fixed-by: Junio C Hamano gits...@pobox.com
 Signed-off-by: Junio C Hamano gits...@pobox.com
 ---
  Documentation/git-push.txt | 10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)

 diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
 index cb97cc1..70b18bc 100644
 --- a/Documentation/git-push.txt
 +++ b/Documentation/git-push.txt
 @@ -37,7 +37,9 @@ OPTIONS[[OPTIONS]]
 `+`, followed by the source ref src, followed
 by a colon `:`, followed by the destination ref dst.
 It is used to specify with what src object the dst ref
 -   in the remote repository is to be updated.
 +   in the remote repository is to be updated.  If not specified,
 +   the behavior of the command is controled by the `push.default`
 +   configuration variable.
  +
  The src is often the name of the branch you would want to push, but
  it can be any arbitrary SHA-1 expression, such as `master~4` or
 @@ -65,7 +67,8 @@ directs git to push matching branches: for every branch 
 that exists on
  the local side, the remote side is updated if a branch of the same name
  already exists on the remote side.  This is the default operation mode
  if no explicit refspec is found (that is neither on the command line
 -nor in any Push line of the corresponding remotes file---see below).
 +nor in any Push line of the corresponding remotes file---see below) and
 +no `push.default` configuration variable is set.

  --all::
 Instead of naming each ref to push, specifies that all
 @@ -357,7 +360,8 @@ Examples
 `git push origin :`.
  +
  The default behavior of this command when no refspec is given can be
 -configured by setting the `push` option of the remote.
 +configured by setting the `push` option of the remote, or the `push.default`
 +configuration variable.
  +
  For example, to default to pushing only the current branch to `origin`
  use `git config remote.origin.push HEAD`.  Any valid refspec (like
 --
 1.8.0.rc0.45.g7ce8dc5




-- 
glas...@davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/
--
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

Keep original author with git merge --squash?

[David Glasser]

I frequently find myself using `git merge --squash` to combine a
series of commits by the same author into one.

(For example, I fetch my project's GitHub PRs into my repo.
Frequently, a PR consists of the original PR (with a good description)
followed by a few follow-ups based on feedback from me.  While I'd
prefer that the submitter amended their original commit instead of
making it my job, this is rare.  And I don't feel that it's valuable
to my project's git history to contain all the intermediate stages of
code review --- it's usually just one commit.)

So `git merge --squash origin/pr/1234` is a really convenient command
here... except for one thing: it sets the author as me.  I always have
to manually find the author line and make sure to pass it to --author
(perhaps with --amend).

What would people think of a flag (or a config value) that means if
all merged commits are by the same author, use that author for the
resulting commit instead of the default author?

(I'm not sure if this should be a flag to --squash or to commit.
Maybe `git merge --squash`; `git commit --use-squashed-author`?  Seems
like it should be not too hard to implement; SQUASH_MSG is pretty
parseable.  Or just a config value.)

--dave

-- 
glas...@davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/
--
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: Keep original author with git merge --squash?

[David Glasser]

On Thu, Feb 12, 2015 at 4:12 AM, Jeff King p...@peff.net wrote:
 On Thu, Feb 12, 2015 at 12:35:48PM +0100, Michael Haggerty wrote:

  I assume you are already munging in your editor the template provided by
  git commit after the squash? What would be really nice, IMHO, is if
  there was a way to set the author during that edit (e.g., by moving one
  of the Author: lines to the top of the file). That would cover your
  use case, I think, and would also be useful in general.

 If only Git supported options on todo list lines [1], this could be
 implemented via a --use-author option:

 pick --use-author 1234556 blah
 squash 84392ab etc
 fixup 49106a5 another

 Happily, this would work with fixup, too, without forcing the user to go
 into the editor. Also, it wouldn't require metadata to be read in-band
 from the commit message.

 Yes, that would be nice, but I don't think David is using a sequencer
 todo list here at all. It's just:

   git merge --squash pr/100
   git commit

That's correct. I certainly know how to do

  git checkout pr/100
  git rebase -i master  # set things to squash, etc
  git checkout master
  git merge pr/100  # or cherry-pick or whatever

And that's how I always used to do it.  But `merge --squash` is so
much more convenient... except for the minor wrinkle of needing an
extra manual step to give the original author their credit.

--dave


-- 
glas...@davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/
--
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: Keep original author with git merge --squash?

[David Glasser]

On Thu, Feb 12, 2015 at 2:16 PM, David Glasser glas...@davidglasser.net wrote:
 - Before invoking prepare-commit-msg, all of the `Author:` lines found
   in SQUASH_MSG have the same value

OK, and to be very specific: I'm just proposing literally the same
text written after Author; using mailmap to detect that multiple
different Author lines are actually the same author could be a
potential later improvement.

-- 
glas...@davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/
--
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: Keep original author with git merge --squash?

[David Glasser]

On Thu, Feb 12, 2015 at 1:23 PM, Junio C Hamano gits...@pobox.com wrote:
 David Glasser glas...@davidglasser.net writes:

 Well, using -c appears to override SQUASH_MSG entirely; it replaces
 the message as well as the author.  Often I do want to make my own
 message based on all the messages provided by the submitter.  (And
 typically the branch's tip is the least useful message anyway: it's
 usually something like respond to code review.)

 I wonder if there is a bug in the workflow.  Isn't the contributor
 forcing more work to the integrator that way and making it a
 responsibility of the integrator to squash multiple commits into
 one, instead of asking a cleaned-up branch to be merged in the first
 place?  It is a key to keep your project scalable to push as much
 work out of the integrator's plate to the contributors' plates.

 But that is an unrelated tangent.  Among the ideas floated in the
 thread, I tend to like something like what Peff mentioned earlier.

Yes, I agree that the GitHub pull request workflow has some major
disadvantages. It does a good job of enabling unsophisticated
contributors who aren't git experts to propose changes to a codebase,
but not a very good job of encouraging them to do the work of
massaging what may be a series of changes as the patch undergoes code
review into a single patch (or well-structured series of patches).  At
this point in time, the tradeoff of requiring a little more integrator
work makes sense for my project.  I'd rather spend my limited educate
potential contributors energy on ensuring that they include actual
reproductions with their bug reports than on getting them to do
administrative git work that isn't hard for me.

So to be concrete: What I'm proposing (and I'm excited to implement
it!) is the following:

When running git commit and:
- You've fallen into the case where the message was read from SQUASH_MSG
- You haven't used another method of specifying the author (--author,
  -C, -c, --amend)
- You have not specified --reset-author
- You have set the commit.useSquashAuthor option
- Before invoking prepare-commit-msg, all of the `Author:` lines found
  in SQUASH_MSG have the same value

then that author is used, as if it were specified with --author.  (And
this will show up, commented-out, at the bottom of COMMIT_EDITMSG.)

If you have the config option set but you don't want this logic to
take place for a particular post-squash merge, just specify
--reset-author.

I think this makes git more internally consistent, since it makes
`merge --squash` act more like the squash rebase action.  (Personally
I'd be happy if this behavior was the default, but since it is not
backwards-compatible I've included a config option in my
proposal.)

(It is my understanding, based on reading the code, that the format of
SQUASH_MSG is not user-configurable, and that scanning for Author:
lines in it is straightforward.)

--dave

-- 
glas...@davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/
--
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: Keep original author with git merge --squash?

[David Glasser]

On Thu, Feb 12, 2015 at 4:17 PM, David Glasser glas...@davidglasser.net wrote:
 On Thu, Feb 12, 2015 at 2:34 PM, Junio C Hamano gits...@pobox.com wrote:
 David Glasser glas...@davidglasser.net writes:

 So to be concrete: What I'm proposing (and I'm excited to implement
 it!) is the following:

 When running git commit and:
 - You've fallen into the case where the message was read from SQUASH_MSG
 - You haven't used another method of specifying the author (--author,
   -C, -c, --amend)
 - You have not specified --reset-author
 - You have set the commit.useSquashAuthor option
 - Before invoking prepare-commit-msg, all of the `Author:` lines found
   in SQUASH_MSG have the same value

 then that author is used, as if it were specified with --author.  (And
 this will show up, commented-out, at the bottom of COMMIT_EDITMSG.)


 I actually was hoping that this would extend to cases other than
 git merge --squash.

 When running git commit and:

  - You didn't use a more explicit method of specifying the
authorship identity (--author, --date, -C, -c --amend,
--reset-author options, or environment variables GIT_AUTHOR_*);

  - You have commit.useAuthorFromEditorComment variable;

  - You have # Author:  line that are identical in the result of
the editor,

 then use that author.  That would allow git commit --amend to
 update a misspelled author name, for example.

 Is that a bit too liberal?  Would it invite mistakes?

 That does sound pretty good.  And for the specific case of squash,
 what I would do would be (a) take one of the existing Author:  lines
 and turn it into an # Author: line and (b) do the ordinary editing
 that I do to combine the existing messages?

 (Maybe my proposed detect that they're all the same code would run
 at `merge --squash` time, producing a trailing # Author: line if all
 of the produced Author:  lines were identical?)

Or, well, as Peff suggested, maybe SQUASH_MSG should look exactly like
the message that rebase's squash gives you, which in fact is a lot
better: no random indent, # Author, etc.  So making your suggested
change to parse # Author in `git commit`, plus a second change to
make SQUASH_MSG look like rebase's squash, would achieve my goals.


-- 
glas...@davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/
--
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: Keep original author with git merge --squash?

[David Glasser]

On Thu, Feb 12, 2015 at 2:34 PM, Junio C Hamano gits...@pobox.com wrote:
 David Glasser glas...@davidglasser.net writes:

 So to be concrete: What I'm proposing (and I'm excited to implement
 it!) is the following:

 When running git commit and:
 - You've fallen into the case where the message was read from SQUASH_MSG
 - You haven't used another method of specifying the author (--author,
   -C, -c, --amend)
 - You have not specified --reset-author
 - You have set the commit.useSquashAuthor option
 - Before invoking prepare-commit-msg, all of the `Author:` lines found
   in SQUASH_MSG have the same value

 then that author is used, as if it were specified with --author.  (And
 this will show up, commented-out, at the bottom of COMMIT_EDITMSG.)


 I actually was hoping that this would extend to cases other than
 git merge --squash.

 When running git commit and:

  - You didn't use a more explicit method of specifying the
authorship identity (--author, --date, -C, -c --amend,
--reset-author options, or environment variables GIT_AUTHOR_*);

  - You have commit.useAuthorFromEditorComment variable;

  - You have # Author:  line that are identical in the result of
the editor,

 then use that author.  That would allow git commit --amend to
 update a misspelled author name, for example.

 Is that a bit too liberal?  Would it invite mistakes?

That does sound pretty good.  And for the specific case of squash,
what I would do would be (a) take one of the existing Author:  lines
and turn it into an # Author: line and (b) do the ordinary editing
that I do to combine the existing messages?

(Maybe my proposed detect that they're all the same code would run
at `merge --squash` time, producing a trailing # Author: line if all
of the produced Author:  lines were identical?)

--dave

-- 
glas...@davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/
--
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: Keep original author with git merge --squash?

[David Glasser]

On Thu, Feb 12, 2015 at 12:18 PM, Junio C Hamano gits...@pobox.com wrote:
 Jeff King p...@peff.net writes:

 On Wed, Feb 11, 2015 at 09:21:04AM -0800, David Glasser wrote:

 (I'm not sure if this should be a flag to --squash or to commit.
 Maybe `git merge --squash`; `git commit --use-squashed-author`?  Seems
 like it should be not too hard to implement; SQUASH_MSG is pretty
 parseable.  Or just a config value.)

 It sounds like git commit -c is close to what you want, which will
 pull the author and commit message from a particular commit. But I don't
 think there is a convenient way to name the commit in your case (it is
 likely to be the first commit on the branch you are squash-merging, but
 there isn't a shorthand for that).

 I thought David was primarily interested in the case where a branch
 authored by a single person, so specifying the tip of the branch
 being merged would be sufficient, no?

Well, using -c appears to override SQUASH_MSG entirely; it replaces
the message as well as the author.  Often I do want to make my own
message based on all the messages provided by the submitter.  (And
typically the branch's tip is the least useful message anyway: it's
usually something like respond to code review.)

--dave


-- 
glas...@davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/
--
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] doc: mention `git -c` in git-config(1)

[David Glasser]

On Sun, Sep 11, 2016 at 6:54 PM, Junio C Hamano  wrote:
> The patch that was commented on in that exchange should be part of
> v2.10.0 already.

My mistake: I was accidentally searching for the paragraph I added in
config.txt instead of git-config.txt. Thanks and sorry for wasting
your time!

--dave

-- 
glas...@davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/

Re: [PATCH] doc: mention `git -c` in git-config(1)

[David Glasser]

On Tue, Aug 23, 2016 at 11:02 AM, Junio C Hamano <gits...@pobox.com> wrote:
> David Glasser <glas...@davidglasser.net> writes:
>
> That might be something we want to fix up further in later patches;
> the change we see in this patch is good regardless.


Perhaps I am looking at the wrong branch, but I'm not sure that this
got merged? Is there something I should do to move this along?

--dave

-- 
glas...@davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/

[PATCH] doc: mention `git -c` in git-config(1)

[David Glasser]

Signed-off-by: David Glasser <glas...@davidglasser.net>
---
 Documentation/git-config.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index f163113..83f86b9 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -263,6 +263,9 @@ The files are read in the order given above, with
last value found taking
 precedence over values read earlier.  When multiple values are taken then all
 values of a key from all files will be used.

+You may override individual configuration parameters when running any git
+command by using the `-c` option. See linkgit:git[1] for details.
+
 All writing options will per default write to the repository specific
 configuration file. Note that this also affects options like `--replace-all`
 and `--unset`. *'git config' will only ever change one file at a time*.
-- 
2.8.1
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git-config(1) should mention `git -c`

[David Glasser]

On Tue, Aug 23, 2016 at 10:16 AM, Junio C Hamano  wrote:
> Jeff King  writes:
>
>> That seems like the most sensible place, as that is where we should
>> cover the order of reading and precedence. Perhaps FILES should be
>> renamed to SOURCES or something (though I do not recall if we are
>> restricted to "usual" manpage section names or not).
>>
>> Arguably this is not about git-config the program at all, but the
>> general concept of "configuration for git", because the precedence rules
>> apply equally to all of the git programs that read config.
>
> True, but that argument leads us to say git(1) is the best place ;-)
>
> If the user wants to know "how does the configuration values get
> read?", and wishes not having to go around fishing for the
> information in multiple places (and I think that is a reasonable
> thing to wish for), I think adding it to the FILES section of
> git-config(1) is a better option than inventing a separate
> gitconfig(7), which would still require the user to consult two
> places.

Great, I sent a patch in a new thread. I hope I formatted it
correctly; haven't sent a patch via email in a while.



-- 
glas...@davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

git-config(1) should mention `git -c`

[David Glasser]

In addition to describing the `git config` command, git-config(1) also
appears to be where the algorithm for determining the active
configuration values is documented, in the FILES and ENVIRONMENT
sections.  (There is minimal documentation of these files and
environment variables in git(1).)

However, `git -c name=value` is not documented in this manpage. So to
understand the full set of ways to affect the configuration of a git
command, you need to know to read both git(1) and git-config(1).

I'd like to add a reference to `git -c` to git-config(1). I would
happily send a patch but I'm not sure of the best place to put it —
maybe in the FILES section?

--dave

-- 
glas...@davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/
--
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 v2] doc: list filter-branch subdirectory-filter first

[David Glasser]

From: David Glasser <glas...@davidglasser.net>

The docs claim that filters are applied in the listed order, so
subdirectory-filter should come first.

For consistency, apply the same order to the SYNOPSIS and the script's usage, as
well as the switch while parsing arguments.

Add missing --prune-empty to the script's usage.

Signed-off-by: David Glasser <glas...@davidglasser.net>
---
 Documentation/git-filter-branch.txt | 20 ++--
 git-filter-branch.sh| 20 ++--
 2 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/Documentation/git-filter-branch.txt 
b/Documentation/git-filter-branch.txt
index 9e5169aa64f4f..394f74451a659 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -8,11 +8,11 @@ git-filter-branch - Rewrite branches
 SYNOPSIS
 
 [verse]
-'git filter-branch' [--setup ] [--env-filter ]
-   [--tree-filter ] [--index-filter ]
-   [--parent-filter ] [--msg-filter ]
-   [--commit-filter ] [--tag-name-filter ]
-   [--subdirectory-filter ] [--prune-empty]
+'git filter-branch' [--setup ] [--subdirectory-filter ]
+   [--env-filter ] [--tree-filter ]
+   [--index-filter ] [--parent-filter ]
+   [--msg-filter ] [--commit-filter ]
+   [--tag-name-filter ] [--prune-empty]
[--original ] [-d ] [-f | --force]
[--] [...]
 
@@ -89,6 +89,11 @@ OPTIONS
can be used or modified in the following filter steps except
the commit filter, for technical reasons.
 
+--subdirectory-filter ::
+   Only look at the history which touches the given subdirectory.
+   The result will contain that directory (and only that) as its
+   project root. Implies <>.
+
 --env-filter ::
This filter may be used if you only need to modify the environment
in which the commit will be performed.  Specifically, you might
@@ -167,11 +172,6 @@ be removed, buyer beware. There is also no support for 
changing the
 author or timestamp (or the tag message for that matter). Tags which point
 to other tags will be rewritten to point to the underlying commit.
 
---subdirectory-filter ::
-   Only look at the history which touches the given subdirectory.
-   The result will contain that directory (and only that) as its
-   project root. Implies <>.
-
 --prune-empty::
Some filters will generate empty commits that leave the tree untouched.
This option instructs git-filter-branch to remove such commits if they
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 3a74602ef3771..b7827e745a92a 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -81,12 +81,12 @@ set_ident () {
finish_ident COMMITTER
 }
 
-USAGE="[--setup ] [--env-filter ]
-   [--tree-filter ] [--index-filter ]
-   [--parent-filter ] [--msg-filter ]
-   [--commit-filter ] [--tag-name-filter ]
-   [--subdirectory-filter ] [--original ]
-   [-d ] [-f | --force]
+USAGE="[--setup ] [--subdirectory-filter ]
+   [--env-filter ] [--tree-filter ]
+   [--index-filter ] [--parent-filter ]
+   [--msg-filter ] [--commit-filter ]
+   [--tag-name-filter ] [--prune-empty]
+   [--original ] [-d ] [-f | --force]
[--] [...]"
 
 OPTIONS_SPEC=
@@ -153,6 +153,10 @@ do
--setup)
filter_setup="$OPTARG"
;;
+   --subdirectory-filter)
+   filter_subdir="$OPTARG"
+   remap_to_ancestor=t
+   ;;
--env-filter)
filter_env="$OPTARG"
;;
@@ -174,10 +178,6 @@ do
--tag-name-filter)
filter_tag_name="$OPTARG"
;;
-   --subdirectory-filter)
-   filter_subdir="$OPTARG"
-   remap_to_ancestor=t
-   ;;
--original)
orig_namespace=$(expr "$OPTARG/" : '\(.*[^/]\)/*$')/
;;

--
https://github.com/git/git/pull/415

Adding a target prefix to git filter-branch --subdirectory-filter

[David Glasser]

git filter-branch --subdirectory-filter is really useful and easy to
use.  It's a commonly used step as part of moving a directory from one
repo to another.  It lets you move a subdirectory to the root of the
repo.

I've found that, when moving directories between repos, I often want
to do a task that is very similar to --subdirectory-filter but not
quite the same — I want to put the subdirectory under a prefix (and
maybe in this case the "subdirectory" should just be the entire repo).

Searching the web for  shows
that wanting to do something like this is pretty common.

It's certainly possible to do this with --index-filter or
--tree-filter, and the man page even has an example:

   git filter-branch --index-filter \
   'git ls-files -s | sed "s-\t\"*-/-" |
   GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
   git update-index --index-info &&
mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE"' HEAD

But gosh, this is just a pain to write.

I'd like to add direct support to git filter-branch for having a
non-root target for subdirectory-filter.

I have a couple questions:

(1) What interface should this have? I'd lean towards having this just
be part of --subdirectory-filter as a separate option
--subdirectory-target-prefix.  For the "move root to subdir" you maybe
would have to type --subdirectory-filter=/, or maybe empty
--subdirectory-filter combined with --subdirectory-target-prefix does
the trick.

Alternatively, it could be a new filter type specific to moving
subdirectories around, but I don't know that that makes sense.

(2) The way I'd imagine I would implement this would be to replace the
current `git read-tree -i -m $commit:"$filter_subdir"` with `git
read-tree --empty && git read-tree --prefix=PREFIX/
$commit:"$filter_subdir"`.  --prefix is incompatible with -m, and I
don't really understand the importance of the stat reuse that is done
by `-i -m` single-tree merge. Is it OK to just drop the -i -m?

--dave

[PATCH] doc: list filter-branch subdirectory-filter first

[David Glasser]

From: David Glasser <glas...@davidglasser.net>

The docs claim that filters are applied in the listed order, so
subdirectory-filter should come first.
---
 Documentation/git-filter-branch.txt | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/git-filter-branch.txt 
b/Documentation/git-filter-branch.txt
index 9e5169aa64f4f..605583c0ad2b5 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -89,6 +89,11 @@ OPTIONS
can be used or modified in the following filter steps except
the commit filter, for technical reasons.
 
+--subdirectory-filter ::
+   Only look at the history which touches the given subdirectory.
+   The result will contain that directory (and only that) as its
+   project root. Implies <>.
+
 --env-filter ::
This filter may be used if you only need to modify the environment
in which the commit will be performed.  Specifically, you might
@@ -167,11 +172,6 @@ be removed, buyer beware. There is also no support for 
changing the
 author or timestamp (or the tag message for that matter). Tags which point
 to other tags will be rewritten to point to the underlying commit.
 
---subdirectory-filter ::
-   Only look at the history which touches the given subdirectory.
-   The result will contain that directory (and only that) as its
-   project root. Implies <>.
-
 --prune-empty::
Some filters will generate empty commits that leave the tree untouched.
This option instructs git-filter-branch to remove such commits if they

--
https://github.com/git/git/pull/415