If I do this:
$ git config merge.ff false
And then:
$ git merge --squash topic
I get:
> fatal: You cannot combine --squash with --no-ff.
I can work around this by executing:
$ git merge --squash --ff topic
Which essentially negates the `merge.ff` configuration. In this
scenario, wouldn't it
but what does mean in the sense of branching and
merging? will i get *precisely* 10 commits of history? and in the
context of merging, *which* 10 commits?
sorry if this should be obvious.
rday
--
====
Robert P. J. Day
On Fri, Sep 13, 2019 at 10:30 PM Jeff King wrote:
> SNIP
>
> > Now this looks more like it. I can actually see a useful diff here,
> > instead of everything looking like a new file. But there is a lot of
> > confusion here:
> >
> > 1. `diff --follow` is not a documented[1] option. Why does it work
potentially saving massive
amounts of disk space and network traffic.
However, when cloning a repo with submodules, the variable is cleared
when the submodules are cloned recursively.
Is this a bug, or intentional?
Thanks,
Robert Schmidt
I'm using Git version 2.23. I have the `diff.renames` setting set to
`copies`. My code base has a file named `JniPaymentManager.hpp` (and
`cpp`) that had too much code in it, so I refactored this file by
splitting out a significant portion of the code in it to another file,
named `ZPayClient.hpp` (
I've observed that when merging a branch, and there's a submodule
conflict, sometimes Git will prompt a suggested resolution like so:
```
Failed to merge submodule Core (not fast-forward)
Found a possible merge resolution for the submodule:
If this is correct simply add it to the index for exampl
Thanks Junio.
I was looking at 'smimesign' and working to understand how, when set
within 'gpg.program', it conformed with gpg's usage within git
sign,verify etc. I happened to look at the docs for the 'gpg.program'
config variable and noticed the discrepancy.
From: Robert Morgan
The gpg --verify usage example within the 'gpg.program' variable
reference provides an incorrect example of the gpg --verify command
arguments.
The command argument order, when providing both a detached signature
and data, should be signature first and data sec
umentation/manuals/gnupg/Operational-GPG-Commands.html#index-verify
.
Signed-off-by: Robert T Morgan robert.thomas.mor...@gmail.com
[robert.thomas.mor...@gmail.com]
Robert Morgan (1):
gpg(docs): use correct --verify syntax
Documentation/config/gpg.txt | 2 +-
1 file changed, 1 insertion(+),
Apologies list! Thanks Kevin. That's what I get for troubleshooting
plain-text in Gmail and quickly sending a subscribe email before
walking out.
Robert
On Thu, Jul 11, 2019 at 3:18 PM Kevin Daudt wrote:
>
> On Thu, Jul 11, 2019 at 03:11:33PM -0500, Robert Morgan wrote:
> &
subscribe git
On Tue, May 28, 2019 at 8:35 AM Robert Dailey wrote:
>
> On Fri, May 24, 2019 at 12:11 PM Andreas Schwab wrote:
> >
> > On Mai 24 2019, Robert Dailey wrote:
> >
> > > Can anyone provide some advice on how to properly restructure this
> > > repository
On Fri, May 24, 2019 at 12:11 PM Andreas Schwab wrote:
>
> On Mai 24 2019, Robert Dailey wrote:
>
> > Can anyone provide some advice on how to properly restructure this
> > repository to create some ancestry, as if all along a `master` existed
> > and all release branc
On Fri, May 24, 2019 at 9:04 AM Robert Dailey wrote:
>
> Everything I'm going to describe is related to this repository:
>
> https://github.com/powervr-graphics/Native_SDK
>
> This repo has several distinct branches. None of them seem to be tied
> to each other. Instead
Everything I'm going to describe is related to this repository:
https://github.com/powervr-graphics/Native_SDK
This repo has several distinct branches. None of them seem to be tied
to each other. Instead of having a `master` where they branched off
each of their releases (e.g. 3.1, 3.2, 4.0), it
On Tue, May 7, 2019 at 9:10 AM Robert Dailey wrote:
> Your example is very helpful. I understand what you're saying for
> conflicted lines. But the "whatever the default merge resolution would
> have been" doesn't exist, because there's no reality where line
On Mon, May 6, 2019 at 6:52 PM Ævar Arnfjörð Bjarmason wrote:
> Maybe an example helps, let's say you have two paint buckets, one with
> red paint, one with yellow paint. You mix them. What happens?
>
> (
> rm -rf /tmp/git &&
> git init /tmp/git &&
> cd /tmp/git &&
>
I feel like you got hung up too much on exact wording of what I was
trying to describe. I do apologize I don't have the background to
explain things 100% accurately, especially at a low level. My
explanations are mostly intended to be as a user, based on what is
observable, and based on intent. I'l
I'm hoping this is mostly a learning opportunity for me. I'm assuming
things are working as designed, but I just don't understand something
fundamental.
I have a merge commit. HEAD is currently pointing at this merge
commit. To be exact, HEAD points to master, which points to the merge
commit. My
ntainer could adjust them when he picks up the patch). But
> there are just enough that it's probably worth making his life easier
> with a v3.
> You can put my Reviewed-by on it, too. :)
Here it is:
>8
From: Damien Robert
Date: Tue, 16 Apr 2019 14:16:46 +0200
Subject: [PA
pple effects of the test changes, since I think we'll end up
> changing them again to make sure ":trackshort" is distinct.
There are now less impactful than before because the master branch in the
test refers to the same commit as before; there is just a new commit for the
'myf
so that the upstream branch is ahead by 2 while the push
branch is ahead by 1, this allow us to test that %(push:track) refer to
the correct branch.
This change the expected value of some following tests, so update them
too.
Signed-off-by: Damien Robert
---
ref-filter.c| 7
ch in two, one
introducing `stat_push_info` in remote.c and the following one using it in
ref-filter.c
Damien Robert (1):
Fix %(push:track) in ref-filter
ref-filter.c| 7 ++--
remote.c| 78 +++--
remote.h| 2 ++
t/
epends on the state of the git repositories of previous tests rather
than creating the git repos from scratch (presumably for the sake of
speed), so I was afraid to break things. But I see that I can probably
reuse the repos from the test 'setupt for detecting upstreamed changes'.
So I'll try (when I have time...) to do a RFC implementation of a 'noop
fetch' approach. I first need to understand the source of fetch.c better,
in particular how to do something like store_updated_refs when we are doing
a noop fetch (so without using transports).
--
Damien Robert
http://www.normalesup.org/~robert/pro
When I perform a rebase and it stops at a commit due to a conflict,
the messages printed are very verbose. Example:
```
Applying: Delete run configuration for zPayServiceStandalone
Using index info to reconstruct a base tree...
A .idea/runConfigurations/zPayServiceStandalone.xml
Falling back
>From Damien Robert, Mon 08 Apr 2019 at 16:53:40 (+0200) :
> > Others may have a better idea, but I do not immediately see any
> > solution better than inventing a new option to "git pull".
So here is a RFC patch that implements --no-fetch. (I am not sure about
the wor
not sure I understand what a no-op `git fetch` means exactly.
In the "git fetch; ; git pull" scenario,
after I do the real `git fetch` and want to merge/rebase the changes, how
would I prevent `git pull` to pull new commits that were pushed in between?
--
Damien Robert
feature be accepted?
--
Damien Robert
On Thu, Apr 4, 2019 at 4:50 PM Junio C Hamano wrote:
>
> Robert Dailey writes:
>
> > It might be fine within the realm of git itself, because git knows how
> > to deal with them by peeling, as you say, but there are 3 reasons I
> > dislike that this is allowed:
>
On Thu, Apr 4, 2019 at 8:56 AM Robert Dailey wrote:
>
> On Thu, Apr 4, 2019 at 7:06 AM Jeff King wrote:
> >
> > On Wed, Apr 03, 2019 at 08:26:06PM -0700, Taylor Blau wrote:
> >
> > > Agreed.
> > >
> > > I think that the implement is a little
{ OPTION_INTEGER, 'n', NULL, &filter.lines, N_("n"),
>
> which even does the right thing with "git tag --no-edit -a foo" (it dies
> with "fatal: no tag message?"
>
> > This makes me think that we should do two things:
> >
On Thu, Apr 4, 2019 at 4:32 AM Junio C Hamano wrote:
>
> Robert Dailey writes:
>
> >> > more clear in the doc and/or in the proposed log message what
> >> > practical downside there are to the end users if we do not stop this
> >> > "mistake&quo
On Wed, Apr 3, 2019 at 3:50 AM Junio C Hamano wrote:
>
> Junio C Hamano writes:
>
> > I am not sure if this is so bad, actually. Why do we need to treat
> > it as a mistake? When a command that wants a commit is fed a tag
> > (either a tag that directly refers to a commit, or a tag that tags
>
Similar to git commit, it would be nice to have a --no-edit option for
git tag. Use case is when I force-recreate a tag:
$ git tag -af 1.0 123abc
An editor will be prompted with the previous annotated tag message. I
would like to add --no-edit to instruct it to use any previously
provided message
t
$ git diff --
rday
--
====
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://
On Wed, Mar 27, 2019 at 5:27 AM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Wed, Mar 27 2019, Elijah Newren wrote:
>
> > On Tue, Mar 26, 2019 at 12:56 AM Denton Liu wrote:
> >>
> >> Robert Dailey reported confusion on the mailing list about a recursive
>
On Mon, Mar 25, 2019 at 9:49 AM Jeff King wrote:
> I think "just commits" is too restrictive. linux.git contains a tag of a
> tree, for example (we also have tags pointing to blobs in git.git, but
> they are not annotated).
>
> However, I could see an argument for the git-tag porcelain to notice a
On Thu, Mar 21, 2019 at 2:29 PM Jeff King wrote:
> Tags can point to any object, including another tag. It looks like
> somebody made an annotated tag of an annotated tag (probably by
> mistake, given that they have the same tag-name).
>
> Try this:
>
> git init
> git commit -m commit --allow-
I have a particular tag in my repo that shows 2 annotated
descriptions, which is very confusing.
The command I ran:
```
git show --format=fuller 4.2.0.1900
```
And the output:
```
tag 4.2.0/1900
Tagger: John Doe
TaggerDate: Fri Jul 18 10:46:30 2014 -0500
QA/Internal Release for 4.2.0.19
On Sat, 16 Mar 2019, Johannes Sixt wrote:
> Am 16.03.19 um 13:22 schrieb Robert P. J. Day:
> > as a working example, i looked at the top-level .gitattributes file
> > in the git source code itself, which opens with:
> >
> > * whitespace=!indent,trail,space
> >
On Sat, 16 Mar 2019, Ævar Arnfjörð Bjarmason wrote:
>
> On Sat, Mar 16 2019, Robert P. J. Day wrote:
>
> > more nitpicking, but i'm working my way through the intricacies of
> > attributes and putting together some (allegedly) simple examples for a
> > class i&#
l,space
does the "!" apply to "indent" or to the entire list? the man page
doesn't say.
just being pedantic again.
rday
--
====
Robert P. J. Day Ottawa, Ontario, CANADA
On Sat, 16 Mar 2019, Duy Nguyen wrote:
> On Fri, Mar 15, 2019 at 9:31 PM Robert P. J. Day
> wrote:
> > also, i think "man git-clone" could really use a set of examples for
> > shallow cloning. i'd offer to write it but i'm still figuring it out.
>
>
On Fri, 15 Mar 2019, Duy Nguyen wrote:
> On Fri, Mar 15, 2019 at 8:19 PM Robert P. J. Day
> wrote:
> > this is the first time i've played with this feature, so i'm
> > still working my way through the man page, trying to figure out
> > the various vali
On Fri, 15 Mar 2019, Duy Nguyen wrote:
> On Fri, Mar 15, 2019 at 7:17 PM Robert P. J. Day
> wrote:
> >
> >
> > probably doing something idiotic but i'm enumerating variations of
> > shallow cloning, and tried the following:
> >
> > $ git cl
clearly don't understand
what this option is supposed to do.
rday
--
====
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter:
On Thu, 14 Mar 2019, Konstantin Ryabitsev wrote:
> On Wed, 13 Mar 2019 at 16:56, Jeff King wrote:
> > - preferences between Canada and US?
>
> If you're looking at Canada, East coast is generally more affordable
> than West Coast in terms of venues and accommodation. The three main
> tech hubs
On Tue, 12 Mar 2019, Bryan Turner wrote:
> On Tue, Mar 12, 2019 at 11:01 AM Robert P. J. Day
> wrote:
> >
> > On Tue, 12 Mar 2019, Bryan Turner wrote:
> >
> > > On Tue, Mar 12, 2019 at 10:23 AM Robert P. J. Day
> > > wrote:
> > > >
>
ah, i'm starting to get it. predictably, i think this needs to be
mentioned in a man page. :-) thanks muchly for clearing that up.
rday
--
====
Robert P. J. Day Ottawa, Ontario, CANADA
On Tue, 12 Mar 2019, Bryan Turner wrote:
> On Tue, Mar 12, 2019 at 10:23 AM Robert P. J. Day
> wrote:
> >
> > never noticed this before ... when i do a regular "git commit" and
> > enter my "vi" edit session and change my mind, i can bail with &q
On Tue, 12 Mar 2019, Bryan Turner wrote:
> On Tue, Mar 12, 2019 at 10:23 AM Robert P. J. Day
> wrote:
> >
> > never noticed this before ... when i do a regular "git commit" and
> > enter my "vi" edit session and change my mind, i can bail with &q
quot; that the
revert was cancelled:
Aborting commit due to empty commit message.
that seems ... inconsistent. am i misunderstanding something?
rday
--
Robert P. J. Day Ottawa, Onta
t;all") || !strcmp(date, "now"))
... snip ...
is the preference to simply list both alternatives, or to
*encourage* the more intuitive "now" and "never" values while politely
deprecating the others? the impression i get is the latter.
rday
-
age
collected?
rday
--
====
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn:
utting in an
extra line or two mentioning this in the man page? that is, as long as
i've understood this correctly.
rday
--
====
Robert P. J. Day Ottawa, Ontario, CANADA
http
nio's
take on this here:
https://marc.info/?l=git&m=152695527902711&w=2
was to banish the phrase entirely in favour of some combination of
"tracked" and/or "added to the index."
thoughts?
rday
--
====
Correct misspelled ".gitattribute" in comments only, so no functional
change.
Signed-off-by: Robert P. J. Day
---
diff --git a/attr.c b/attr.c
index fdd110bec5..93dc16b59c 100644
--- a/attr.c
+++ b/attr.c
@@ -431,14 +431,14 @@ static struct match_attr *parse_attr_line(const c
On Tue, 5 Mar 2019, Junio C Hamano wrote:
> "Robert P. J. Day" writes:
>
> > Currently, all of the examples for "man git-rebase" show rebasing from
> > a branch that has had no further development, which might mislead
> > readers into thinking tha
On Tue, 5 Mar 2019, Junio C Hamano wrote:
> "Robert P. J. Day" writes:
>
> > one of the things i've noticed about the examples in "man
> > git-rebase" is that they invariably show rebasing relative to a
> > branch point that has not moved. fo
arify that.
Signed-off-by: Robert P. J. Day
---
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 5629ba4c5d..ba3c44fdaf 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -109,8 +109,8 @@ functionality which is found in 'next'.
before running the rebase, then leaving off that final argument?
everything i've seen suggests those two things are identical, but
i've been fooled before.
rday
--
====
Robert P. J. Day
any further. (yes, i
realize that, if you read carefully, it *should* make it clear, but i
think it would be helpful to at least graphically show that
happening.)
thoughts?
rday
--
====
Robert P. J. Day
Signed-off-by: Robert P. J. Day
---
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index a7442499f6..a7c1b0f60e 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -76,7 +76,7 @@ be performed as well.
--prune=::
Prune loose objects older than
argv_array_push(&repack, "-a");
else {
... snip ...
while the man page does not seem to mention the possible value of
"now".
am i misreading something? should the man page mention the possible
value of "now" as opposed to "all"?
rday
--
On Sat, 23 Feb 2019, Johannes Schindelin wrote:
> Hi,
>
> On Sat, 23 Feb 2019, Johannes Schindelin wrote:
>
> > On Sat, 23 Feb 2019, Junio C Hamano wrote:
> >
> > > "Robert P. J. Day" writes:
> > >
> > > > am i misreading som
On Sat, 23 Feb 2019, Todd Zullinger wrote:
> Hi,
>
> Robert P. J. Day wrote:
> >
> > not so much a git issue as what looks like a fedora packaging
> > issue.
>
> Yeah, it's just a minor packaging issue. The gitweb manpages are
> included in the m
perusing the source code
doesn't seem to show that command checking that config option.
am i misreading something? and if not, is there a reason git clean
does not consult core.excludesFile?
rday
--
====
works fine.
the question is, is it not inconsistent for fedora's basic "git"
package to include the man page for gitweb, without including the
corresponding functionality? is this something i should submit a
fedora bugzilla report for? or am i misunderstanding somethi
esses
those two arguments, as "v4.19" is, of course, a reference to a
specific commit, but "^v4.19^" appears to define all those commits not
reachable from "v4.19^". how should one read this?
rday
--
=
The default pre-commit script checks the config variable
"hooks.allownonascii" to determine whether to allow non-ASCII file
names -- mention this in "man githooks", just as the section on
"update" mentions the use of "hooks.allowunannotated".
Signed-off-
On Tue, 19 Feb 2019, Ævar Arnfjörð Bjarmason wrote:
>
> On Tue, Feb 19 2019, Robert P. J. Day wrote:
>
> > was just perusing the sample hook scripts, and the sample pre-commit
> > script provided with git does the following check:
> >
> > # If you want to a
was just perusing the sample hook scripts, and the sample pre-commit
script provided with git does the following check:
# If you want to allow non-ASCII filenames set this variable to true.
allownonascii=$(git config --bool hooks.allownonascii)
but that config variable (hooks.allownonascii)
at all is fine - perhaps to do with
the index? Or does this seem to be more likely an issue we created
ourselves? Would there have been any other commands we could have run
to resolve this issue or should have tried out first? (Apart from just
deleting each of our clones and starting again)
Robert
gt; Git. Its management seems much more willing to accept the kind of
> changes I make, as shown by their reaction to the excellent work by
> Robert Day.
thank ya, thank ya very much. :-) most of my submissions to that
book have been cosmetic -- punctuation, font changes, clarifications
-- and
On Sat, 8 Dec 2018, Duy Nguyen wrote:
> On Sat, Dec 8, 2018 at 6:32 PM Robert P. J. Day wrote:
> >
> > On Sat, 8 Dec 2018, Duy Nguyen wrote:
> >
> > > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day
> > > wrote:
> > > >
> > >
On Sat, 8 Dec 2018, Duy Nguyen wrote:
> On Sat, Dec 8, 2018 at 6:32 PM Robert P. J. Day wrote:
> >
> > On Sat, 8 Dec 2018, Duy Nguyen wrote:
> >
> > > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day
> > > wrote:
> > > >
> > >
On Sat, 8 Dec 2018, Duy Nguyen wrote:
> On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day wrote:
> >
> >
> > from "man git-reset":
> >
> > SYNOPSIS
> > git reset [-q] [] [--] ...
> > git reset (--patch | -p) [] [--] [...]
> >
On Sun, 2 Dec 2018, Duy Nguyen wrote:
> On Sun, Dec 2, 2018 at 6:05 PM Robert P. J. Day wrote:
> > > Patch update>> 2
> > > staged unstaged path
> > > * 1:unchanged+1/-0 README.md
> > > * 2:unchanged+
e valid in that third case (at least for
"--mixed"). thoughts? is that just an oversight in the man page?
rday
--
====
Robert P. J. Day Ottawa, Ontario, CANADA
Current "man git-add" emphasizes single letter interactive
shortcut commands with "[]".
Signed-off-by: Robert P. J. Day
---
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 45652fe4a6..ad9bd7c7a6 100644
--- a/Documentation/git-add.txt
+++ b/Docum
On Sun, 2 Dec 2018, Duy Nguyen wrote:
> On Sun, Dec 2, 2018 at 6:05 PM Robert P. J. Day wrote:
> > > Patch update>> 2
> > > staged unstaged path
> > > * 1:unchanged+1/-0 README.md
> > > * 2:unchanged+
On Sun, 2 Dec 2018, SZEDER Gábor wrote:
> On Sun, Dec 02, 2018 at 11:30:19AM -0500, Robert P. J. Day wrote:
> >
> > testing adding by patch for the very first time (i've just never
> > needed this), and reading the "progit" book and reading the man page,
&
On Sun, 2 Dec 2018, SZEDER Gábor wrote:
> On Sun, Dec 02, 2018 at 11:30:19AM -0500, Robert P. J. Day wrote:
> >
> > testing adding by patch for the very first time (i've just never
> > needed this), and reading the "progit" book and reading the man page,
&
On Sun, 2 Dec 2018, Kevin Daudt wrote:
> On Sun, Dec 02, 2018 at 11:30:19AM -0500, Robert P. J. Day wrote:
> >
> > testing adding by patch for the very first time (i've just never
> > needed this), and reading the "progit" book and reading the man page,
&
patch mode -- certainly "p" doesn't do it. am i stupidly missing
something trivial? is the explanation misleading or inncomplete?
rday
--
Robert P. J. Day
On Sun, 2 Dec 2018, Ævar Arnfjörð Bjarmason wrote:
> On Sun, Dec 02 2018, Robert P. J. Day wrote:
>
> > as part of an upcoming git class i'm delivering, i thought it
> > would be amusing to demonstrate the maximum length of colliding
> > SHA-1 prefixes in a repo
as part of an upcoming git class i'm delivering, i thought it would
be amusing to demonstrate the maximum length of colliding SHA-1
prefixes in a repository (in my case, i use the linux kernel git repo
for most of my examples).
is there a way to display the objects in the object database tha
the reason for these inconsistencies?
---
Robert White
On Wed, Oct 17, 2018 at 1:47 PM Jeff King wrote:
> Hmm, I feel like another person asked for this recently, but I can't
> seem to find the thread.
Is it this one?
https://www.mail-archive.com/git@vger.kernel.org/msg159212.html
That's the only one I was able to find, but no one replied. Thanks fo
I'd like to sort the output of `git diff --stat` such that files are
listed in descending order based on number of lines changed. The
closest solution I've found online[1] has several readability issues.
I'd rather see a built-in solution in git, if one exists. Can anyone
recommend a solution?
[1]
so what is the difference?
rday
--
====
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/
would display exclusively
objects in the object store corresponding to objects that are suddenly
unreferenced due to the removal of a remote? i was just curious as it
would be neat to demo that in a class.
rday
--
Robert
On Wed, Aug 29, 2018 at 11:54 PM Jonathan Nieder wrote:
>
> Hi,
>
> Robert Dailey wrote:
>
> > Is there an 'auto' setting for the 'core.autocrlf' config? Reason I
> > ask is, I want that setting to be 'input' on linux but 'true
On Mon, Aug 27, 2018 at 12:32 PM Andrei Rybak wrote:
>
> On 2018-08-27 17:52, Duy Nguyen wrote:
> > On Mon, Aug 27, 2018 at 5:37 PM Torsten Bögershausen wrote:
> >>> In those cases, when it falls back to
> >>> configuration for line ending management, I want it to be
> >>> automatically configure
On Mon, Aug 27, 2018 at 10:53 AM Duy Nguyen wrote:
>
> On Mon, Aug 27, 2018 at 5:37 PM Torsten Bögershausen wrote:
> > > In those cases, when it falls back to
> > > configuration for line ending management, I want it to be
> > > automatically configured based on the host platform.
> >
> > There i
Is there an 'auto' setting for the 'core.autocrlf' config? Reason I
ask is, I want that setting to be 'input' on linux but 'true' on
Windows. I have a global .gitconfig that I sync across different
platforms with Google Drive, and I hate to manage 2 copies of it on
each platform (linux and Windows)
On Mon, Aug 6, 2018 at 10:41 AM, Jonathan Nieder wrote:
> Robert Dailey wrote:
>
>> Automatic would be
>> great if submodules were treated as integrated in a similar manner to
>> subtree, but it's not there. I wasn&#
On Thu, Aug 2, 2018 at 1:08 AM, Jonathan Nieder wrote:
> I think I misread this the first time. I got distracted by your
> mention of the --remote option, but you mentioned you want to use the
> SHA-1 of the submodule listed, so that was silly of me.
>
> I think you'll find that "git fetch --no-r
. i have no idea
what relationship those packages have to official git, or who decides
what goes into them.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter:
1 - 100 of 591 matches
Mail list logo
