On Fri, Jun 5, 2015, 2:58 AM lucamilanesio wrote:
>>
>> Some devs of my Team complained that with submodules it is
>> difficult to see the “full picture” of the difference
>> between two SHA1 on the root project, as the submodules
>> would just show as different SHA1s. When you Google
>> “subtree
On Tue, Jun 9, 2015 at 2:40 PM, Jens Lehmann wrote:
> Am 07.06.2015 um 08:26 schrieb Stefan Beller:
>>
>> On 06.06.2015 12:53, Luca Milanesio wrote:
>>>>
>>>> On 6 Jun 2015, at 18:49, Phil Hord wrote:
>>>> On Fri, Jun 5, 2015, 2:58 AM lucami
On Mon, Jun 15, 2015 at 5:06 PM, Heiko Voigt wrote:
> In a superproject some commands need to interact with submodules. They
> need to query values from the .gitmodules file either from the worktree
> of from certain revisions. At the moment this is quite hard since a
> caller would need to read t
On Tue, Jan 24, 2017 at 1:54 AM Stefan Hajnoczi wrote:
> > The use of "git show" you are demonstrating is still about showing
> > the commit object, whose behaviour is defined to show the log
> > message and the diff relative to its sole parent, limited to the
> > paths that match the pathspec.
>
I noticed some weird spacing when comparing files with git diff
--color-words. The space before a colored word disappears sometimes.
$ git --version
git version 2.11.0.485.g4e59582ff
echo "FOO foo; foo = bar" > a
echo "FOO foo = baz" > b
git diff --color-words --no-index a b
FOOfoo; foo = barbaz
On Mon, Feb 6, 2017 at 3:36 PM Ron Pero wrote:
> I almost got bit by git: I knew there were changes on the remote
> server, but git status said I was uptodate with the remote.
>
Do you mean you almost pushed some changed history with "--force"
which would have lost others' changes? Use of this o
Wouldn't we need to extend this to cherry-pick, too? Suppose I do this:
$ git log -2 --oneline --decorate foo
abcd123456 (foo) Revert 123456
123456 Some useful commit for the future, but not now
$ git checkout bar
$ git cherry-pick foo^ foo
$ git log -2 --one
The current url leads to a 404 error. The corrected url was determined
empirically.
Signed-off-by: Phil Hord
---
MaintNotes | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MaintNotes b/MaintNotes
index b7fa21f5cc..168f0b0969 100644
--- a/MaintNotes
+++ b/MaintNotes
@@ -63,7
"Junio C Hamano via vger.kernel.org" writes:
> > When cherry-picking or reverting a sequence of commits and if the final
> > pick/revert has conflicts and the user uses `git commit` to commit the
> > conflict resolution and does not run `git cherry-pick --continue` then
> > the sequencer state is
heading in this
API direction anyway, so I put it on a shelf. I guess I'm just
surprised the state checking is still so manual. I'll explore more.
On Fri, Apr 19, 2019 at 12:46 PM Jeff King wrote:
>
> On Fri, Apr 19, 2019 at 10:57:33AM -0700, Phil Hord wrote:
>
>
From: Phil Hord
I have a local patch to rebase--interactive.sh that adds "edit" switches
to rebase, permitting me to say, for example,
git rebase --drop $sha
This command creates a todo-list but drops the mentioned commit from the
list by changing the "pick" to "
From: Phil Hord
Expand the rebase edit switches to include the break switch. This
switch lets the user add a "break" instruction to the todo-list
before the mentioned reference.
This switch is a little different from the ones added so far because
it adds a new instruction between comm
From: Phil Hord
A common use for rebase is to drop or edit some commit in a
feature branch. The commit to be changed is known in advance,
so a user will say 'git rebase -i that-commit^' to see the todo
list in her editor. Then she will change the command on the line
for "that-
On Sun, Apr 21, 2019 at 6:13 PM Junio C Hamano wrote:
>
> Phil Hord writes:
>
> > Currently it supports these switches:
> >
> > usage: git rebase [-i] [options] [--exec ] ...
> >:
> > --break stop before the mentioned ref
> >
On Mon, Apr 22, 2019 at 7:44 AM Phillip Wood wrote:
> Doing "git rebase -i master" and then editing the todo list has the side
> effect of rebasing the branch. Often I find I want to amend or reword a
> commit without rebasing (for instance when preparing a re-roll). To do
> this I use a script th
On Mon, Apr 22, 2019 at 12:16 PM Phil Hord wrote:
>
> I have the same need. I plan to have some switch that invokes this
> "in-place rebase" behavior so that git can choose the upstream for me
> as `mergebase $sequence-edits`. In fact, I want to make that the
> defaul
On Mon, Apr 22, 2019 at 6:21 PM Junio C Hamano wrote:
>
> Phillip Wood writes:
>
> > Doing "git rebase -i master" and then editing the todo list has the
> > side effect of rebasing the branch. Often I find I want to amend or
> > reword a commit without rebasing (for instance when preparing a
> >
You should probably add some test that demonstrates what your change
intends to do. For that matter, though, your test already breaks at
least two tests in t7508-status.sh:
not ok 14 - status (advice.statusHints false)
not ok 23 - status -uno (advice.statusHints false)
Phil
On Tue, Apr 23, 2019
On Tue, Apr 23, 2019 at 12:35 PM Emily Shaffer wrote:
>
> This tutorial covers how to add a new command to Git and, in the
> process, everything from cloning git/git to getting reviewed on the
> mailing list. It's meant for new contributors to go through
> interactively, learning the techniques ge
On Fri, Jun 14, 2019 at 12:29 AM Vincent Legoll
wrote:
> On Fri, Jun 14, 2019 at 12:56 AM Elijah Newren wrote:
> > When you cherry-pick a commit, it reapplies its diff on top of a
> > (usually different) commit, preserving the author name/email/date, but
> > throwing away the committer name/email
I know name-scrubbing is already covered in filter-branch and other
places. But we have a scenario becoming more common that makes it a
more sensitive topic.
At $work we have a long time employee who has changed their name from
Alice to Bob. Bob doesn't want anyone to call him "Alice" anymore and
On Sat, Jun 15, 2019 at 1:19 AM Ævar Arnfjörð Bjarmason
wrote:
> On Sat, Jun 15 2019, Phil Hord wrote:
>
> > At $work we have a long time employee who has changed their name from
> > Alice to Bob. Bob doesn't want anyone to call him "Alice" anymore and
>
From: Phil Hord
'git tag -d' accepts one or more tag refs to delete, but each deletion
is done by calling `delete_ref` on each argv. This is painfully slow
when removing from packed refs. Use delete_refs instead so all the
removals can be done inside a single transaction with a single
On Thu, Aug 8, 2019 at 11:15 AM Elijah Newren wrote:
>
> On Wed, Aug 7, 2019 at 9:11 PM Phil Hord wrote:
> >
> > From: Phil Hord
> >
> > 'git tag -d' accepts one or more tag refs to delete, but each deletion
> > is done by calling `delete_ref`
On Thu, Aug 8, 2019 at 12:39 PM Junio C Hamano wrote:
>
> Phil Hord writes:
>
> > From: Phil Hord
> >
> > 'git tag -d' accepts one or more tag refs to delete, but each deletion
> > is done by calling `delete_ref` on each argv. This is painfully s
The issue of deadnaming aside, turning on log.mailmap by default is
the sensible thing to do given that other Git features already honor
it that way. Having it ignored-by-default (but only sometimes) just
adds confusion when a mailmap is available.
> > > - The '.mailmap' provides a list of trans
On Fri, Aug 9, 2019 at 4:41 AM Jeff King wrote:
>
> On Thu, Aug 08, 2019 at 08:07:36PM -0700, Phil Hord wrote:
>
> > The long form you give there is to be used in case the old email
> > address is not a unique key. See 'git help shortlog'.
> >
> > The
On Fri, Aug 9, 2019 at 10:48 AM Junio C Hamano wrote:
>
> Jeff King writes:
>
> > I don't know of any plans for checkout in particular, but I think the
> > docs for restore/switch make it clear that it's way too early to start
> > scripting around them:
> >
> > $ git grep EXPERIMENTAL Documenta
From: Phil Hord
'git tag -d' and 'git branch -d' both accept one or more refs to
delete, but each deletion is done by calling `delete_ref` on each argv.
This is very slow when removing from packed refs as packed-refs is
locked and rewritten each time. Use delete_refs instead
I'm trying to include "Bug" numbers from commit messages in my
one-line log output, like this:
git log --pretty="%h %(trailers:key=Bug,valueonly,separator=;) %s"
But I have a problem. We have a tool that appends a trailer to commit
messages like this:
Reviewed at https://reviews.myco.com/0123
On Tue, Aug 20, 2019 at 11:01 AM Leam Hall wrote:
> On 8/20/19 1:46 PM, Pratyush Yadav wrote:
> > So in your case, what's wrong with just tracking the source files needed
> > to generate the other files, and then when you want a release binary,
> > just clone the repo, run your build system, and
ent HEAD, to
begin logging from. Here is what I see after running your setup
script.
$ git log --graph --decorate --all
* commit 3262040f2d8d5f31b4918bda9987e6b5f788531f (foo)
| Author: Phil Hord
| Date: Tue Aug 20 12:44:32 2019
|
| 1.2.1
|
* commit fc66c4311bf954d455f468581f2913dffa0f9c2b
| Autho
Although `git stash save` was deprecated recently, some parts of the
documentation still refer to it instead of `push`.
Signed-off-by: Phil Hord
---
Documentation/git-stash.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation
work for `git commit`, and my fingers have learned this pattern long
ago.
Teach `git stash` to parse -mFoo and --message=Foo the same as
`git commit` would do.
Signed-off-by: Phil Hord
---
git-stash.sh | 18 ++
1 file changed, 18 insertions(+)
diff --git a/git-stash.sh
Hm.. Sorry about the formatting here. It's been a while. I'll try again.
On Tue, Nov 21, 2017 at 3:07 PM, Phil Hord wrote:
> `git stash push -m foo` uses "foo" as the message for the stash. But
> `git stash push -m"foo"` does not parse successfully. Simil
work for `git commit`, and my fingers have learned this pattern long
ago.
Teach `git stash` to parse -mFoo and --message=Foo the same as
`git commit` would do.
Signed-off-by: Phil Hord
---
git-stash.sh | 18 ++
1 file changed, 18 insertions(+)
diff --git a/git-stash.sh
Although `git stash save` was deprecated recently, some parts of the
documentation still refer to it.
Signed-off-by: Phil Hord
---
Documentation/git-stash.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index
With many thousands of references, a simple `git rev-parse HEAD` may take
more than a second to return because it first loads all the refs into
memory even though it will never use them.
Defer loading any references until we actually need them.
Signed-off-by: Phil Hord
---
log-tree.c | 9
You probably already noticed this was my fault for filtering the patch
through Gmail's GUI. I did also push a replacement which hopefully
does apply.
On Tue, Nov 21, 2017 at 8:39 PM, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
>> Phil Hord wrote:
>>
>>&g
On Tue, Nov 21, 2017, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> I am not sure if "maybe_" is a good name here, though. If anything,
> you are making the semantics of "load_ref_decorations()" to "maybe"
> (but I do not suggest renaming that one).
>
> How about calling it to load_ref_deco
but gitcli
does and my fingers have learned this pattern long ago for `commit`.
Teach `git stash` and `git store` to parse -mFoo and --message=Foo
the same as `git commit` would do. Even though it's an internal
function, add similar support to create_stash() for consistency.
Reviewd-by:
stash-store cannot create a new stash with the same ref as stash@{0}. No
error is returned even though no new stash log is created. Add a failing
test to track.
Signed-off-by: Phil Hord
---
t/t3903-stash.sh | 11 +++
1 file changed, 11 insertions(+)
diff --git a/t/t3903-stash.sh b/t
On Wed, Nov 22, 2017 at 1:27 PM, Jeff King wrote:
> On Tue, Nov 21, 2017 at 03:43:36PM -0800, Phil Hord wrote:
>
>> With many thousands of references, a simple `git rev-parse HEAD` may take
>> more than a second to return because it first loads all the refs into
>> me
This week a user accidentally did this:
$ git push origin origin/master
Total 0 (delta 0), reused 0 (delta 0)
To parent.git
* [new branch] origin/master -> origin/master
He saw his mistake when the "new branch" message appeared, but he was
confused about how to fix it and wo
On Mon, Mar 13, 2017 at 1:55 AM Jacob Keller wrote:
> On Fri, Mar 10, 2017 at 2:13 PM, Junio C Hamano wrote:
> > Phil Hord writes:
> >> I think git should be smarter about deducing the dest ref from the
> >> source ref if the source ref is in refs/remotes, but I'
I thought you had the URLs backwards, but that doesn't seem to be the
problem, assuming I am reading your transcription correctly. Maybe the
'insteadOf' is being applied in addition to (and cancelling out) the
pushInsteadOf. Does it work as expected if you remove one or the
other?
In any case, it
On Tue, Mar 11, 2014 at 11:37 PM, Andrew Keller wrote:
> I am considering developing a new feature, and I'd like to poll the group for
> opinions.
>
> Background: A couple years ago, I wrote a set of scripts that speed up
> cloning of frequently used repositories. The scripts utilize a bare Git
During a 'git rebase --continue', I got an error about having left a
file in place which the next commit intended to add as new. Stupid me.
So I rm'ed the file and tried again. This time, git rebase --continue
succeeded. But it accidentally left out the next commit in my rebase-todo.
I looked
On Fri, Oct 31, 2014 at 4:40 AM, Alexandre Garnier wrote:
> When merging 2 branches with the same modifications on the both sides,
> depending the merge side, one branch disappear from the file history.
>
> To be more clear, there is a script in attachment to reproduce, but
> here is the result :
On Tue, Oct 21, 2014 at 1:24 PM, Junio C Hamano wrote:
> John Tapsell writes:
>
>> Hi all,
>>
>> Could we add a default to "--date" so that:
>>
>> git reflog --date
>>
>> just works? (Currently you need to do: git reflog --date=iso) It
>> should probably obey the default in log.date?
>
> Hm
On Thu, Oct 23, 2014 at 8:34 AM, Henning Moll wrote:
> Hi,
>
> i need to squash several commits into a single one in a automated way. I know
> that there is interactive rebase, which can also be automated using
> GIT_SEQUENCE_EDITOR. Unfortunately my history is very large and i need to
> squash
When I use zsh tab-completion to complete the submodule name in 'git
submodule init', I get more than I expected.
>From the gerrit repository (which has plugins):
$ git submodule init plugins/
plugins/commit-message-length-validator\ \(v1.0-rc1-9-g545000b\)
plugins/reviewnotes\ \(v1.0-rc1-8-
On Thu, May 1, 2014 at 6:35 PM, Felipe Contreras
wrote:
> Phil Hord wrote:
>> When I use zsh tab-completion to complete the submodule name in 'git
>> submodule init', I get more than I expected.
>>
>> From the gerrit repository (which has plugins):
>>
Hi Fabian,
Thanks for looking into this.
On 05/27/2014 07:56 AM, Michael Haggerty wrote:
>> +reschedule_last_action () {
>> +tail -n 1 "$done" | cat - "$todo" >"$todo".new
>> +sed -e \$d <"$done" >"$done".new
>> +mv -f "$todo".new "$todo"
>> +mv -f "$done".new "$done"
>> +}
>> +
>
On 06/10/2014 01:56 PM, Junio C Hamano wrote:
> Fabian Ruch writes:
>
>> On 05/27/2014 08:42 PM, Junio C Hamano wrote:
>>> Fabian Ruch writes:
[..]
In order to signal the three possible situations (not only success and
failure to complete) after a pick through porcelain comma
On Wed, Jun 11, 2014 at 8:49 AM, Peter Krefting wrote:
> I am rebasing a branch to combine a couple of commits. One is a revert of a
> previous commit. Since there are commits in-between, I do "squash" to make
> sure I get everything, and then add the actual change on top of that. The
> problem
On Wed, Jun 11, 2014 at 1:57 PM, Peter Krefting wrote:
> Phil Hord:
>
>
>> What does it mean when you say it worked as expected? Did it leave
>> the empty commit, omit the empty commit, or leave some un-squashed
>> commit?
>
>
> Actually, it did not work as
On Mon, Jun 23, 2014 at 9:15 PM, Jeremy Scott wrote:
> I just encountered a situation where a merge was made, with no
> apparent changes in files (ie no log), but the result was that some
> files were deleted.
>
> person A adds some files
> person B adds some files from the same point
You mean fr
On Fri, Jun 27, 2014 at 4:47 PM, Jason Pyeron wrote:
> There are two identical files from the same original parent, but both were
> renamed in their own branches. One branch moved the file to a new folder, the
> other renamed the file in the same folder.
You have not stated what you think the iss
On Fri, Jun 27, 2014 at 6:39 PM, Jason Pyeron wrote:
>> On Fri, Jun 27, 2014 at 4:47 PM, Jason Pyeron
>> wrote:
>> > There are two identical files from the same original
>> parent, but both were
>> > renamed in their own branches. One branch moved the file to
>> a new folder, the
>> > other renam
On Fri, Jun 27, 2014 at 8:42 PM, Jason Pyeron wrote:
> Sorry for the http://pastebin.com/1R68v6jt (changes the merge to
> 1ca13ed2271d60ba93d40bcc8db17ced8545f172, and manually reconciles the merge),
> but it was too long to be readable in the email.
>
> git blame HEAD -- src/Main/Forms/CipherShed
On Sun, Jun 29, 2014 at 11:31 AM, Phil Hord wrote:
> On Fri, Jun 27, 2014 at 8:42 PM, Jason Pyeron wrote:
>> Sorry for the http://pastebin.com/1R68v6jt (changes the merge to
>> 1ca13ed2271d60ba93d40bcc8db17ced8545f172, and manually reconciles the merge),
>> but it was too l
On Sun, Jun 29, 2014 at 4:20 PM, Jason Pyeron wrote:
>> -Original Message-
>> From: Phil Hord
>> Sent: Sunday, June 29, 2014 16:09
>>
>> On Sun, Jun 29, 2014 at 11:31 AM, Phil Hord
>> wrote:
>> > On Fri, Jun 27, 2014 at 8:42 PM, Jas
On Sun, Jun 29, 2014 at 5:13 PM, Jason Pyeron wrote:
>> -Original Message-
>> From: Phil Hord
>> Sent: Sunday, June 29, 2014 16:27
>>
>> On Sun, Jun 29, 2014 at 4:20 PM, Jason Pyeron
>> wrote:
>> >> -Original Message-
>> >
ance to undo it on the spot. Specifying the `--keep-empty`
> option tells git-rebase to keep empty squash commits in the
> rebased history without notification.
>
> Add tests.
>
> Reported-by: Peter Krefting
> Signed-off-by: Fabian Ruch
> ---
> Hi,
>
> Peter Krefti
On Sun, Dec 29, 2013 at 8:49 PM, Francesco Pretto wrote:
>
> by default "git submodule" performs its add or update operations on a detached
> HEAD. This works well when using an existing full-fledged/indipendent project
> as
> the submodule, as there's less frequent need to update it or commit ba
On Tue, Aug 27, 2013 at 12:07 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Not necessarily. If the user is asking the question in a more
>> natural way (I want to see where in 'next' branch's tip commit hits
>> appear, by the way, I know I am only interested in builtin/ so I'd
>> give
On Fri, Sep 6, 2013 at 6:30 AM, Joergen Edelbo wrote:
> Problem: It is not possible to push for Gerrit review as you will
> always try to push to "refs/heads/..." on the remote.
>
> Changes done:
>
> Add an option to select "Gerrit review" and a corresponding entry
> for a branch name. If this opt
Someone at $work asked me this week how to find the current and
previous tags on his branch so he could generate release notes. I
just need "last two tags on head in topo-order". I was surprised by
how complicated this turned out to be. I ended up with this:
git log --decorate=full --pretty=for
On Fri, Sep 27, 2013 at 8:10 AM, Ramkumar Ramachandra
wrote:
> Enhance 'git for-each-ref' with color formatting options. You can now
> use the following format in for-each-ref:
>
> %C(green)%(refname:short)%C(reset)
>
> Signed-off-by: Ramkumar Ramachandra
> ---
> Documentation/git-for-each-re
On Fri, Sep 27, 2013 at 8:10 AM, Ramkumar Ramachandra
wrote:
> Introduce %(upstream:track) to display "[ahead M, behind N]" and
> %(upstream:trackshort) to display "=", ">", "<", or "<>"
> appropriately (inspired by contrib/completion/git-prompt.sh).
>
> Now you can use the following format in for
On Fri, Sep 27, 2013 at 4:07 AM, Morten Stenshorne wrote:
> If I don't go via the ssh tunnel (I finally have some VPN stuff these
> days, so I don't really need the tunnel thing anymore, but that's going
> to be a lot of remotes to update, so I'd prefer it just worked like it
> used to):
>
> -
On Thu, Oct 24, 2013 at 9:46 AM, Duy Nguyen wrote:
> On Thu, Oct 24, 2013 at 2:49 PM, Perry Hutchison
> wrote:
>> Duy Nguyen wrote:
>>
>>> ... it's not easy to determine ambiguity here, especially when the
>>> repo finding code does not know anything about "bar/barz.c" (is it
>>> a pathname or
The help text for the --force-with-lease option to git-push
does not parse cleanly. Clean up the wording and syntax to
be more sensible. Also remove redundant information in the
"--force-with-lease alone" description.
Signed-off-by: Phil Hord
---
Documentation/git-pus
until they are resolved or the changes
are not recorded in the index (return value neither 0 nor 1) and
rebase has to try again with the same task.
Add a test cases for regression testing to the "rebase-interactive"
test suite.
Signed-off-by: Fabian Ruch
Signed-off-by: Phil Hord
> On Mon, Apr 27, 2015 at 10:07 AM, Adam Steel wrote:
>> Stefan,
>>
>> So I switched git versions.
>>
>> $ git --version
>> git version 2.3.1
>>
>> I'm still getting the same regular rebase failures.
>>
>> ---
>>
>> fatal: Unable to create
>> '/Users/asteel/Repositories/rails-teespring/.git/index.
On Wed, Apr 29, 2015 at 1:15 PM, Junio C Hamano wrote:
>
> Thanks, will queue.
>
> Aside from the "much more invasive" possibility, the patch makes me
> wonder if it would have been a better design to have a static "todo"
> with a "current" pointer as two state files. Then reschedule would
> have
It would be nice to support more generic specs for the --branch
switch. But it is complicated because the refs have not been fetched
yet during the clone, and so normal refs operations -- which expect to
work on a local repository -- do not work. So, the ref is looked up
locally from a list in exp
On Thu, Aug 8, 2013 at 3:07 AM, Luke San Antonio
wrote:
>
> Hi, my name's Luke!
>
> Today, I had a problem merging a stash after immediately creating it.
> This is exactly what I did!
>
> git stash save --keep-index
> git stash pop
>
> And BAM! Merge conflict! This was especially weird because my
On Wed, Aug 7, 2013 at 5:07 PM, shawn wilson wrote:
> On Wed, Aug 7, 2013 at 6:43 AM, Johannes Sixt wrote:
>> Am 8/7/2013 8:24, schrieb shawn wilson:> ... create a repo for one of
>>> these scripts and I'd like to keep the commit history.
>>>
>>> Ok, so:
>>> % find -type f ! -iname "webban.pl" |
On Fri, Aug 9, 2013 at 6:03 AM, shawn wilson wrote:
> On Fri, Aug 9, 2013 at 2:50 AM, Johannes Sixt wrote:
>> Let's check: After running your command above to remove other files, does
>> the command
>>
>>git filter-branch -f HEAD webban.pl
>>
>
> Ahha, no but:
> git filter-branch -f HEAD -- w
ain
also means the return values of all the previous commands in
this test are also being ignored.
Fix the path and add the chain operator so the entire test
sequence can be properly validated.
Signed-off-by: Phil Hord
---
t/t7407-submodule-foreach.sh | 2 +-
1 file changed, 1 insertion(+), 1
On Tue, Aug 13, 2013 at 1:31 AM, Luke San Antonio
wrote:
>
> So I found an isolated case, it's very strange...
>
> Here's a script!
>
>
Thanks for that. It was hard to read, but it demonstrates the problem well.
> ... Copy and paste that into a terminal and you should have a recreated
> versi
When the pathspec given to grep includes a tree name, the full
name of matched files is assembled using colon as a separator.
If the pathspec includes a tree name, it should use a slash
instead.
Check if the pathspec already names a tree and ref (including
a colon) and use a slash if so.
---
I'm
On Sat, Aug 24, 2013 at 9:35 PM, Phil Hord wrote:
>
> When the pathspec given to grep includes a tree name, the full
> name of matched files is assembled using colon as a separator.
> If the pathspec includes a tree name, it should use a slash
> instead.
>
> Check if the pat
On Mon, Aug 26, 2013 at 3:14 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Jonathan Nieder writes:
>>
>>> I think Phil meant that when "git grep" is asked to search within
>>> "HEAD:some/path", filenames tacked on at the end should be appended
>>> with a '/' separator instead of the us
When a commit is grepped and matching filenames are printed, grep-objects
creates the filename by prefixing the original cmdline argument to the
matched path separated by a colon. Normally this forms a valid blob
reference to the filename, like this:
git grep -l foo HEAD
HEAD:some/path/to/foo
On Mon, Aug 26, 2013 at 12:23 PM, Junio C Hamano wrote:
> Phil Hord writes:
>
>> On Mon, Aug 26, 2013 at 3:14 AM, Junio C Hamano wrote:
>>> Junio C Hamano writes:
>>>
>>>> Jonathan Nieder writes:
>>>>
>>>>> I think Phil
On Mon, Aug 26, 2013 at 12:49 PM, Phil Hord wrote:
> If so, then I would like to point out to you the convenience I
> accidentally encountered using this tool. Perhaps you didn't realize
> how helpful it was when you chose to use a colon there.
My itch comes from a case where I
On Mon, Aug 26, 2013 at 1:03 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> If your justification were "above says 'there may be a readon why
>> the user wanted to ask it in that way', i.e. 'find in this tree
>> object HEAD:some/path and report where hits appear', but the reason
>> can o
On Mon, Aug 26, 2013 at 1:26 PM, Junio C Hamano wrote:
> Phil Hord writes:
>
>>> If your justification were "above says 'there may be a readon why
>>> the user wanted to ask it in that way', i.e. 'find in this tree
>>> object HEAD:some/path
On Mon, Aug 26, 2013 at 4:13 PM, Johannes Sixt wrote:
> Am 26.08.2013 21:56, schrieb Jeff King:
>> Also, prevent the delimiter being added twice, as happens now in these
>> examples:
>>
>> git grep -l foo HEAD:
>> HEAD::some/path/to/foo.txt
>>^
>
> Which one of these two does it print
On Mon, Aug 26, 2013 at 4:52 PM, Jeff King wrote:
> On Mon, Aug 26, 2013 at 10:13:14PM +0200, Johannes Sixt wrote:
>
>> Am 26.08.2013 21:56, schrieb Jeff King:
>> > Also, prevent the delimiter being added twice, as happens now in these
>> > examples:
>> >
>> > git grep -l foo HEAD:
>> > HEAD::
I think this series is fairly complete at this point. I am still
missing some tests in 4/4, but only because I am not sure how to
induce those conditions. Maybe I should enlist help from $(git-blame).
[PATCHv3 1/4] Refactor print_state into get_state
[PATCHv3 2/4] wt-status: More state retrieva
functions so others can get this state info and
share common code.
Signed-off-by: Phil Hord
---
wt-status.c | 31 +++
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 2a9658b..760f52b 100644
--- a/wt-status.c
+++ b/wt
wt_status_print_state retrieves some sequencer state information via
wt_status_get_state, but other state information it deduces on its
own. Replace these "local knowledge" deductions with wt_status
variables so we can share more common code in the future.
---
wt-status.c | 16 +---
w
sequencer-related. But
it is possible I am being too short-sighted or have chosen the
switch name poorly.
changed-index Changes exist in the index
changed-files Changes exist in the working directory
untracked New files exist in the working directory
Signed-off-by: Phil Hord
---
rebase-interactive splitting status
Signed-off-by: Phil Hord
---
t/t7061-status-sequence.sh | 96 ++
1 file changed, 96 insertions(+)
create mode 100755 t/t7061-status-sequence.sh
diff --git a/t/t7061-status-sequence.sh b/t/t7061-status-sequence.sh
new
Junio C Hamano wrote:
> Phil Hord writes:
>
>> State token strings which may be emitted and their meanings:
>> merge a merge is in progress
>> am an am is in progress
>> am-is-emptythe am patch is empty
>>
Phil Hord wrote:
> Junio C Hamano wrote:
>> Phil Hord writes:
>>
>>> State token strings which may be emitted and their meanings:
>>> merge a merge is in progress
>>> am an am is in progress
>>> am-i
1 - 100 of 234 matches
Mail list logo
