From: David Glasser
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 scr
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 t
From: David Glasser
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
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!
--dav
On Tue, Aug 23, 2016 at 11:02 AM, Junio C Hamano wrote:
> David Glasser 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 th
Signed-off-by: David Glasser
---
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
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
>> restri
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).)
Howev
On Thu, Feb 12, 2015 at 4:17 PM, David Glasser wrote:
> On Thu, Feb 12, 2015 at 2:34 PM, Junio C Hamano wrote:
>> David Glasser writes:
>>
>>> So to be concrete: What I'm proposing (and I'm excited to implement
>>> it!) is the following:
>>
On Thu, Feb 12, 2015 at 2:34 PM, Junio C Hamano wrote:
> David Glasser 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 fa
On Thu, Feb 12, 2015 at 2:16 PM, David Glasser 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 m
On Thu, Feb 12, 2015 at 1:23 PM, Junio C Hamano wrote:
> David Glasser 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
On Thu, Feb 12, 2015 at 12:18 PM, Junio C Hamano wrote:
> Jeff King 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`; `
On Thu, Feb 12, 2015 at 4:12 AM, Jeff King 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 s
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.
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 wrote:
> Ramkumar Ramachandra writes:
>
>> David Glasser wrote:
>>> Thanks Rankumar! There's also the referenc
e
On Tue, Oct 2, 2012 at 8:09 AM, Ramkumar Ramachandra 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
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)?
--dav
18 matches
Mail list logo
