On 27 Nov 2018, at 19:24, Stefan Beller wrote:
> The different phases taking each one line takes up precious
> screen real estate, so another approach would be delete the line
> after one phase is finished, such that you'd only see the currently
> active phase (that can be useful for debugging
I’m far from being a guru, but I consider myself a competent Git user.
Yet, here’s my understanding of the output of one the most-used
commands, `git push`:
Counting objects: 6, done.
No idea what an “object” is. Apparently there’s 6 of them here.
What does “counting” them means? Should I care?
On Mon, Jun 8, 2015 at 5:39 PM, Junio C Hamano wrote:
> Will Palmer writes:
>> diff --git a/t/t1511-rev-parse-caret.sh b/t/t1511-rev-parse-caret.sh
>> index e0fe102..8a5983f 100755
>> --- a/t/t1511-rev-parse-caret.sh
>> +++ b/t/t1511-rev-parse-caret.sh
>> @@ -19
for a commit
whose message contains the string "!Message".
Signed-off-by: Will Palmer
---
t/t1511-rev-parse-caret.sh | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/t/t1511-rev-parse-caret.sh b/t/t1511-rev-parse-caret.sh
index 15973f2..e0fe1
base, push"-style
workflow, which generates a lot of "WIP foo" commits. While rebasing is
usually handled via "git rebase -i origin/master", occasionally I will
already have several "good, but not yet ready to push" commits hanging
around while I finish work
To name a commit, you can now say
$ git rev-parse HEAD^{/!-foo}
and it will return the hash of the first commit reachable from HEAD,
whose commit message does not contain "foo". This is the opposite of the
existing ^{/} syntax.
The specific use-case this is intended for is to
;
Thank you for that additional context, which I didn't see previously.
> Using "/!Message" to match commits that do not match Message
> directly goes against that extensivility design.
>
> We need to always remind ourselves that our latest shiny new toy
> will not be the f
rch for a commit
whose message contains the string "!Message".
Signed-off-by: Will Palmer
---
t/t1511-rev-parse-caret.sh | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/t/t1511-rev-parse-caret.sh b/t/t1511-rev-parse-caret.sh
index 15973f2..0c46e5c
base, push"-style
workflow, which generates a lot of "WIP foo" commits. While rebasing is
usually handled via "git rebase -i origin/master", occasionally I will
already have several "good, but not yet ready to push" commits hanging
around while I finish work on rela
To name a commit, you can now say
$ git rev-parse HEAD^{/!foo}
and it will return the hash of the first commit reachable from HEAD,
whose commit message does not contain "foo".
Since the ability to reference a commit by "name" was introduced (way
back in 1.5, in 364d3
, git will look for the needed object in LINKEDOBJECTDIR,
similar to how it looks in GIT_ALTERNATE_OBJECT_DIRECTORIES. If it is
not found, the object is received as normal and then hard linked into
the object store at LINKEDOBJECTDIR.
USAGE - CACHE HIT:
During another pull or clone on a different
>From d3fe2c76e6fa53e4cfa6f81600685c21bdadd4e3 Mon Sep 17 00:00:00 2001
From: William Entriken
Date: Thu, 21 Feb 2013 23:10:07 -0500
Subject: [PATCH] submodule update: when using recursion, show full path
Previously when using update with recursion, only the path for the
inner-most module was pri
Hello,
I am running:
git submodule update --recursive
And get the output:
Submodule path 'Submodules/evernote-ios-sdk': checked out
'391ca643c5b1cd02e9fa869a6b0760436ea452ed'
Submodule path 'Submodules/facebook-ios-sdk': checked out
'ada467f754febd4f2871d15943e9be16b323f114'
Sub
13 matches
Mail list logo
