On 15-08-12 02:43 AM, Jacob Keller wrote:
> Hello,
>
> Recently there was some discussion about git-notes and how we do not fetch
> notes from remotes by default. The big problem with doing so is because
> refs/remotes/* hierarchy is only setup for branches (heads), so we don't
> have any clean lo
On 15-09-17 10:37 AM, Matthieu Moy wrote:
> strtoul_ui uses strtoul to get a long unsigned, then checks that casting
> to unsigned does not lose information and return the casted value.
>
> On 64 bits architecture, checking that the cast does not change the value
> catches most errors, but when si
On 15-09-17 11:34 AM, Matthieu Moy wrote:
> Marc Branchaud writes:
>
>>> --- a/git-compat-util.h
>>> +++ b/git-compat-util.h
>>> @@ -814,6 +814,9 @@ static inline int strtoul_ui(char const *s, int base,
>>> unsigned int *result)
>>> ch
On 2016-07-01 12:03 PM, Nguyễn Thái Ngọc Duy wrote:
v5 changes the substitute symbol from '$' to '*' in compact mode and
makes sure long lines in compact mode will not make the remote ref
column too big (it's far from perfect but I think it's still good to
do).
I think the first 4 patches are g
On 2016-07-11 04:25 PM, Philip Oakley wrote:
Do not self-define `reachable`, which can lead to misunderstanding.
Instead define `reachability` explictly.
Signed-off-by: Philip Oakley
---
Documentation/revisions.txt | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff -
On 2016-07-11 04:25 PM, Philip Oakley wrote:
While there, also break out the other shorthand notations and
add a title for the revision range summary (which also appears
in git-rev-parse, so keep it mixed case).
Signed-off-by: Philip Oakley
---
Documentation/revisions.txt | 23 +++
On 2016-07-20 05:10 PM, Philip Oakley wrote:
While there, also break out the other shorthand notations and
add a title for the revision range summary (which also appears
in git-rev-parse, so keep it mixed case).
Signed-off-by: Philip Oakley
---
Documentation/revisions.txt | 58 +++
On 2016-07-21 03:54 PM, Philip Oakley wrote:
From: "Marc Branchaud"
On 2016-07-20 05:10 PM, Philip Oakley wrote:
While there, also break out the other shorthand notations and
add a title for the revision range summary (which also appears
in git-rev-parse, so keep it mixed case).
Signed-off-by: Marc Branchaud
---
On 2016-12-18 07:48 PM, Chris Packham wrote:
>
> This feature already exists (although it's not interactive). See
> help.autoCorrect in the git-config man page. "git config
> help.autoCorrect -1" should to the trick.
Awesome, I
'log'.
With help.autoCorrect < 0:
WARNING: You called a Git command named 'lgo', which does not exist.
Continuing under the assumption that you meant 'log'.
Signed-off-by: Marc Branchaud
---
Writing the commit message was more work than the commit! :
On 2016-12-19 11:44 AM, Michael Haggerty wrote:
This patch series changes a bunch of details about how remote-tracking
references are rendered in the commit list of gitk:
Thanks for this! I like the new, compact look very much!
That said, I remember when I was a new git user and I leaned heav
On 2016-12-20 05:17 PM, Paul Mackerras wrote:
On Tue, Dec 20, 2016 at 10:01:15AM -0500, Marc Branchaud wrote:
On 2016-12-19 11:44 AM, Michael Haggerty wrote:
This patch series changes a bunch of details about how remote-tracking
references are rendered in the commit list of gitk:
Thanks for
On 2016-12-20 07:05 PM, Michael Haggerty wrote:
On 12/20/2016 04:01 PM, Marc Branchaud wrote:
On 2016-12-19 11:44 AM, Michael Haggerty wrote:
This patch series changes a bunch of details about how remote-tracking
references are rendered in the commit list of gitk:
Thanks for this! I like
On 2016-12-22 03:15 AM, Michael Haggerty wrote:
On 12/21/2016 08:07 PM, Marc Branchaud wrote:
On 2016-12-20 07:05 PM, Michael Haggerty wrote:
On 12/20/2016 04:01 PM, Marc Branchaud wrote:
[...]
Please don't change the remotebgcolor default.
Also, perhaps the default remoterefbgcolor s
On 2017-01-16 05:54 AM, Johannes Schindelin wrote:
Hi Stephan,
On Mon, 16 Jan 2017, Stephan Beyer wrote:
a git-newbie-ish co-worker uses git-stash sometimes. Last time he used
"git stash pop", he got into a merge conflict. After he resolved the
conflict, he did not know what to do to get the r
On 2017-01-18 11:34 AM, Johannes Schindelin wrote:
Hi Marc,
On Wed, 18 Jan 2017, Marc Branchaud wrote:
On 2017-01-16 05:54 AM, Johannes Schindelin wrote:
On Mon, 16 Jan 2017, Stephan Beyer wrote:
a git-newbie-ish co-worker uses git-stash sometimes. Last time he
used "git stash pop
On 2017-01-19 10:49 AM, Johannes Schindelin wrote:
Hi Marc,
On Wed, 18 Jan 2017, Marc Branchaud wrote:
On 2017-01-18 11:34 AM, Johannes Schindelin wrote:
On Wed, 18 Jan 2017, Marc Branchaud wrote:
On 2017-01-16 05:54 AM, Johannes Schindelin wrote:
On Mon, 16 Jan 2017, Stephan Beyer
On 2017-01-19 04:30 PM, Johannes Schindelin wrote:
At this point I will stop commenting on this issue, as I have said all
that I wanted to say about it, at least once. If I failed to get my points
across so far, I simply won't be understood.
Yes, we're obviously looking at this from completely
On 2016-12-19 11:44 AM, Michael Haggerty wrote:
This patch series changes a bunch of details about how remote-tracking
references are rendered in the commit list of gitk:
I don't see this series in git v2.12.0-rc0, nor in Paul's gitk repo.
I hope this is an oversight, and not that the series g
On 2016-11-23 06:21 PM, Junio C Hamano wrote:
* The original command line syntax for "git merge", which was "git
merge HEAD ...", has been deprecated for quite some
time, and "git gui" was the last in-tree user of the syntax. This
is finally fixed, so that we can move forward with th
Signed-off-by: Marc Branchaud
---
Mostly just missing words and what I feel are clarifications.
The biggest change is to the "git add -N" item. Not 100% sure
I got it right.
M.
Documentation/RelNotes/2.11.0.txt | 145 +++---
1 file c
On 2016-05-06 08:09 AM, Li Peng wrote:
Fix duplicate words in comments.
Signed-off-by: Li Peng
---
git-cvsserver.perl | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 02c0445..392e59e 100755
--- a/git-cvsserver.perl
+++ b
On 2016-05-06 02:54 PM, Junio C Hamano wrote:
I wonder if can we come up with a short and sweet notation to remind
futhre readers that this "initialization" is not initializing but
merely squelching warnings from stupid compilers, and agree to use
it consistently?
Perhaps
#define COMP
On 2016-05-06 03:57 PM, Junio C Hamano wrote:
Marc Branchaud writes:
On 2016-05-06 02:54 PM, Junio C Hamano wrote:
I wonder if can we come up with a short and sweet notation to remind
futhre readers that this "initialization" is not initializing but
merely squelching warnings f
On 2016-05-22 09:59 PM, Duy Nguyen wrote:
On Mon, May 23, 2016 at 7:58 AM, Junio C Hamano wrote:
That is, I wonder if the above can become something like:
From github.com:pclouds/git
* [new branch] { -> pclouds/}2nd-index
* [new branch] { -> pclouds/}3nd-index
* [new branch]
On 2016-05-26 01:42 PM, Junio C Hamano wrote:
True. One of the entries in Marc's example is easily misread as
"pclouds/2nd-index branch at its refs/heads/pclouds/2nd-index was
fetched to its usual place", when Marc wanted to say "they had
2nd-index branch at refs/heads/2nd-index, and it was cop
On 2016-05-26 03:31 PM, Junio C Hamano wrote:
Marc Branchaud writes:
The fact that something is buried in some odd part of the ref tree is
less relevant, IMO. If I'm using custom fetch refspecs or other
oddities, I'll have that in the back of my head. But what I really
care abo
On 2016-05-27 11:56 AM, Ramsay Jones wrote:
Signed-off-by: Ramsay Jones
---
Hi Junio,
While reading an email from Linus earlier (RFC: dynamic "auto" date formats),
I noticed that log.decorate was being set to 'auto'. Since I didn't recall
that setting (even if it's easy to guess), I went look
On 2016-06-03 07:08 AM, Nguyễn Thái Ngọc Duy wrote:
This documents the ref update status of fetch. The structure of this
output is defined in [1]. The ouput content is refined a bit in [2]
s/The ouput/The output/
[3] [4].
This patch is a copy from git-push.txt, modified a bit because the
fla
On 2016-06-03 07:08 AM, Nguyễn Thái Ngọc Duy wrote:
When there are lots of ref updates, each has different name length, this
will make it easier to look because the variable part is at the end.
s/look/read/
For the record, I prefer the earlier stair-step format to this
{xxx -> yyy}/foo
On 2016-06-03 01:04 PM, Junio C Hamano wrote:
Marc Branchaud writes:
What if we detect when the full line exceeds the terminal width, and
insert a newline after the remote ref and indent the -> to the same
offset as its surrounding lines, like this:
* [new branch] 2nd-in
On 2016-06-04 11:11 PM, Nguyễn Thái Ngọc Duy wrote:
This documents the ref update status of fetch. The structure of this
output is defined in [1]. The ouput content is refined a bit in [2]
[3] [4].
This patch is a copy from git-push.txt, modified a bit because the
flag '-' means different things
On 2016-08-12 03:07 AM, Philip Oakley wrote:
While there, also break out the other shorthand notations and
add a title for the revision range summary (which also appears
in git-rev-parse, so keep it mixed case).
We do not quote the notation within the headings as the asciidoc ->
docbook -> groff
On 2016-08-12 03:07 AM, Philip Oakley wrote:
Signed-off-by: Philip Oakley
---
new
Cc: Jakub Narębski
https://public-inbox.org/git/578E4F4A.2020708%40gmail.com/
---
Documentation/revisions.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/revisions.txt b/Do
On 2016-08-12 03:07 AM, Philip Oakley wrote:
Signed-off-by: Philip Oakley
---
new
Junio's final comment
https://public-inbox.org/git/xmqqwpkq6b4d.fsf%40gitster.mtv.corp.google.com/
---
Documentation/revisions.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/revisions.t
On 2016-08-12 03:07 AM, Philip Oakley wrote:
The revisions examples show the revison arguments and the selected
commits, but do not show the intermediate step of the expansion of
the special 'range' notations. Extend the examples, including an
all-parents multi-parent merge commit example.
Sort
On 2016-08-12 03:07 AM, Philip Oakley wrote:
[2nd attempt : ISP troubles]
This has grown like topsy from a little two patch series that tried to
name the 2-dots notation [1] into this extended set of tweaks.
Honestly, I start just trying point out something concrete, like
misrendered headers,
On 2016-08-12 07:45 PM, Philip Oakley wrote:
These are the quick fixes to Marc's comments to patches 5,6,11,
and a consequential change to 12.
Only the changed patches are included.
Looks good to me -- no further comments!
However, I still don't understand why git says 11/12 has "indent with
On 2016-08-15 11:00 AM, Philip Oakley wrote:
From: "Marc Branchaud"
On 2016-08-12 07:45 PM, Philip Oakley wrote:
These are the quick fixes to Marc's comments to patches 5,6,11,
and a consequential change to 12.
Only the changed patches are included.
Looks good to me -- no f
On 2016-08-15 12:55 PM, Marc Branchaud wrote:
On 2016-08-15 11:00 AM, Philip Oakley wrote:
From: "Marc Branchaud"
On 2016-08-12 07:45 PM, Philip Oakley wrote:
These are the quick fixes to Marc's comments to patches 5,6,11,
and a consequential change to 12.
Only the chan
On 16-03-15 09:02 PM, Stefan Beller wrote:
> On Tue, Mar 15, 2016 at 6:00 PM, Stefan Beller wrote:
>>
>> Instead of converting to whitespaces in Git, we could make use of the
>> set_tabs capability for ttys and setup the terminal for having tabs align
>> to 12,+8,+8,+8...
>
> Or rather read in th
On 2016-04-26 06:58 AM, Ævar Arnfjörð Bjarmason wrote:
>
> Makes sense to have an experimental.* config tree for git for stuff like this.
I disagree.
* If the point is to express some kind of warning to users, I think the
community has been much better served by leaving experimental settings
und
On 2016-04-26 12:09 PM, Ævar Arnfjörð Bjarmason wrote:
Basically you can look at patches to a project on a spectrum of:
1. You hacked something up locally
2. It's in someone's *.git repo as a POC
3. It's a third-party patch series used by a bunch of people
4. In an official release but
The new workdir is empty before the checkout, so attempts to recurse into
a non-existent submodule directory fail.
Signed-off-by: Marc Branchaud
---
Until the worktree command supports submodules I've gone back to using the
git-new-workdir script, but it fails if my confi
The new workdir is empty before the checkout, so attempts to recurse into
a non-existent submodule directory fail.
Signed-off-by: Marc Branchaud
---
Changed to use --no-recurse-submodules instead of -c submodule.recurse=false,
as Jonathan suggested.
M.
contrib/workdir/git-new
On 2019-01-14 4:34 p.m., Jonathan Nieder wrote:
Hi,
Marc Branchaud wrote:
The new workdir is empty before the checkout, so attempts to recurse into
a non-existent submodule directory fail.
Signed-off-by: Marc Branchaud
---
Thanks for reporting. Can you describe the error message when it
On 2019-01-14 4:58 p.m., Jonathan Nieder wrote:
Hi,
Junio C Hamano wrote:
Jonathan Nieder writes:
Marc Branchaud wrote:
The new workdir is empty before the checkout, so attempts to recurse into
a non-existent submodule directory fail.
Signed-off-by: Marc Branchaud
---
Thanks for
Also document this fact.
Signed-off-by: Marc Branchaud
---
I ran into this bug when I had both fetch.recurseSubmodules=on-demand and
submodule.recurse=true, and submodule.recurse was set *after*
fetch.recurseSubmodules in my config.
The fix ensures that fetch.recurseSubmodules always overrides
On 2018-09-26 11:48 AM, Duy Nguyen wrote:
I believe the main selling point of multiple worktrees is sharing
refs. You could easily avoid expensive clones with --local, but
synchronizing between different clones is not very convenient. Other
than that, different worktrees tend to behave like sepa
On 2019-09-12 12:29 p.m., Pratyush Yadav wrote:
On 12/09/19 08:05AM, Birger Skogeng Pedersen wrote:
Hi Pratyush,
On Wed, Sep 11, 2019 at 10:55 PM Pratyush Yadav wrote:
Also, I notice that the bindings for other letters have the same
function bound for both small and capital letters (IOW, same
On 2019-09-13 3:50 a.m., Birger Skogeng Pedersen wrote:
Hi Marc and Philip,
On 12/09/2019 22:34, Marc Branchaud wrote:
I disagree! Who expects anything to work properly when capslock is on?
Me :-)
Fair enough, though I imagine you have a pretty narrow definition of
"anything".
On 2019-09-13 10:32 a.m., Pratyush Yadav wrote:
On 13/09/19 12:24PM, Allan Ford wrote:
Dear Git Authors,
Not a bug, but a suggestion consideration for “Git Gui”
Can a double click on the file name in the “unstaged” area move the
item to “staged changes” .. (rather than having to click on the s
On 2019-09-26 3:15 p.m., Pratyush Yadav wrote:
On 26/09/19 08:54PM, Johannes Sixt wrote:
Am 26.09.19 um 19:31 schrieb Birger Skogeng Pedersen:
Every once in a while, I get the "This repository currently has
approximately (some number) loose objects." popup dialog.
I don't want to sound arrogan
On 2019-10-01 6:08 a.m., Bert Wesarg wrote:
Wrapping filenames is an unexpected experience in UX design. Disable
wrapping and add a horizontal scrollbar to the files list to remove this.
(Thanks for working on gitk and git-gui!)
I have to say I'm mildly opposed to this change. The reason is t
On 2019-10-01 2:00 p.m., Pratyush Yadav wrote:
So here's what I propose: why don't we try to do something similar? What
about running `git-gc --auto` in the background when the user makes a
commit (which I assume is the most common operation in git-gui). This
would be disabled when the user sets
So I have
diff.indentHeuristic = true
and I noticed that git-gui was not using the heuristic. This is because
git-gui uses diff-index, and that does not respect the config setting,
even though it supports the --indent-heuristic option.
And it looks like diff-files and diff-tree also
This makes the commands respect diff configuration options, such as
indentHeuristic.
Signed-off-by: Marc Branchaud
---
builtin/diff-files.c | 2 +-
builtin/diff-index.c | 2 +-
builtin/diff-tree.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/diff-files.c b
Signed-off-by: Marc Branchaud
---
diff.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
index 11eef1c85..da96577ea 100644
--- a/diff.c
+++ b/diff.c
@@ -290,9 +290,6 @@ int git_diff_ui_config(const char *var, const char *value,
void *cb
t the diff_indent_heuristic flag is respected regardless of when
diff_setup() is invoked.
M.
Marc Branchaud (2):
Make the indent heuristic part of diff's basic configuration.
Have the diff-* builtins configure diff before initializing revisions.
builtin/diff-files.c | 2
This makes the commands respect diff configuration options, such as
indentHeuristic, because init_revisions() calls diff_setup() which fills
in the diff_options struct.
Signed-off-by: Marc Branchaud
---
builtin/diff-files.c | 2 +-
builtin/diff-index.c | 2 +-
builtin/diff-tree.c| 2
commands,
see prior patches).
Signed-off-by: Stefan Beller
Signed-off-by: Marc Branchaud
---
diff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/diff.c b/diff.c
index da96577ea..2c47ccb4a 100644
--- a/diff.c
+++ b/diff.c
@@ -27,7 +27,7 @@
#endif
static int
ds to respect the setting.
The heuristic itself merely makes the diffs more aesthetically
pleasing, without changing their correctness. Scripts that rely on
the diff plumbing commands should not care whether or not the heuristic
is employed.
Signed-off-by: Marc Branchaud
---
diff.c | 6 +++-
v2: Fixed up the commit messages and added tests.
Marc Branchaud (2):
diff: make the indent heuristic part of diff's basic configuration
diff: have the diff-* builtins configure diff before initializing
revisions
Stefan Beller (1):
diff: enable indent heuristic by default
bu
ds to respect the setting.
The heuristic itself merely makes the diffs more aesthetically
pleasing, without changing their correctness. Scripts that rely on
the diff plumbing commands should not care whether or not the heuristic
is employed.
Signed-off-by: Marc Branchaud
---
diff.c | 6 +++-
This matches how the diff Porcelain works. It makes the plumbing commands
respect diff's configuration options, such as indentHeuristic, because
init_revisions() calls diff_setup() which fills in the diff_options struct.
Signed-off-by: Marc Branchaud
---
builtin/diff-files.c | 2 +-
bu
From: Jeff King
Now that diff.indentHeuristic is handled automatically by the plumbing
commands, there's no need to propagate it manually.
Signed-off-by: Jeff King
Signed-off-by: Marc Branchaud
---
git-add--interactive.perl | 4
1 file changed, 4 deletions(-)
diff --git a/gi
On 2017-04-29 09:14 AM, Jeff King wrote:
> On Sat, Apr 29, 2017 at 08:40:52AM -0400, Jeff King wrote:
>
>> On Fri, Apr 28, 2017 at 06:33:12PM -0400, Marc Branchaud wrote:
>>
>>> v2: Fixed up the commit messages and added tests.
>>>
>>> Marc Brancha
, instead of
simply duplicating it.
Helped-by: Jeff King
Signed-off-by: Stefan Beller
Signed-off-by: Marc Branchaud
---
Tested the sed "2a" command's escaping in both Ubuntu 17.04 and FreeBSD 10.3.
Threw in a little indenting so that it isn't too ugly.
diff.c
On 2017-05-08 03:48 AM, Junio C Hamano wrote:
* mb/diff-default-to-indent-heuristics (2017-05-02) 4 commits
(merged to 'next' on 2017-05-08 at 158f401a92)
I think there's a general open question about this, which is whether or
not we should just drop the diff.indentHeuristic configuration s
):
add--interactive: drop diff.indentHeuristic handling
Marc Branchaud (2):
diff: make the indent heuristic part of diff's basic configuration
diff: have the diff-* builtins configure diff before initializing
revisions
Stefan Beller (1):
diff: enable indent heuristic by default
builtin
From: Jeff King
Now that diff.indentHeuristic is handled automatically by the plumbing
commands, there's no need to propagate it manually.
Signed-off-by: Jeff King
Signed-off-by: Marc Branchaud
---
git-add--interactive.perl | 4
1 file changed, 4 deletions(-)
diff --git a/gi
, instead of
simply duplicating it.
Helped-by: Jeff King
Signed-off-by: Stefan Beller
Signed-off-by: Marc Branchaud
---
diff.c | 2 +-
t/t4051-diff-function-context.sh | 3 +-
t/t4061-diff-indent.sh | 140 +++
3 files
This matches how the diff Porcelain works. It makes the plumbing commands
respect diff's configuration options, such as indentHeuristic, because
init_revisions() calls diff_setup() which fills in the diff_options struct.
Signed-off-by: Marc Branchaud
---
builtin/diff-files.c | 2 +-
bu
ds to respect the setting.
The heuristic itself merely makes the diffs more aesthetically
pleasing, without changing their correctness. Scripts that rely on
the diff plumbing commands should not care whether or not the heuristic
is employed.
Signed-off-by: Marc Branchaud
---
diff.c | 6 +++-
On 2017-05-08 11:22 PM, Jeff King wrote:
On Mon, May 08, 2017 at 12:03:37PM -0400, Marc Branchaud wrote:
This matches how the diff Porcelain works. It makes the plumbing commands
respect diff's configuration options, such as indentHeuristic, because
init_revisions() calls diff_setup()
On 2017-05-10 01:18 AM, Junio C Hamano wrote:
* mb/diff-default-to-indent-heuristics (2017-05-09) 4 commits
- add--interactive: drop diff.indentHeuristic handling
- diff: enable indent heuristic by default
- diff: have the diff-* builtins configure diff before initializing revisions
- diff:
On 2017-05-15 08:23 AM, Ævar Arnfjörð Bjarmason wrote:
Fix a duplicate mention of --contains in the SYNOPSIS to mention
--no-contains.
This fixes an error introduced in my commit ac3f5a3468 ("ref-filter:
add --no-contains option to tag/branch/for-each-ref", 2017-03-24).
Signed-off-by: Ævar Arnf
On 2017-05-15 11:01 AM, Ævar Arnfjörð Bjarmason wrote:
On Mon, May 15, 2017 at 4:20 PM, Marc Branchaud wrote:
On 2017-05-15 08:23 AM, Ævar Arnfjörð Bjarmason wrote:
Fix a duplicate mention of --contains in the SYNOPSIS to mention
--no-contains.
This fixes an error introduced in my commit
On 2018-04-13 01:01 PM, Michał Górny wrote:
Currently git does not control mtimes of files being checked out. This
means that the only assumption you could make is that all files created
or modified within a single checkout action will have mtime between
start time and end time of this checkout.
On 2018-04-25 04:48 AM, Junio C Hamano wrote:
"Robin H. Johnson" writes:
In the thread from 6 years ago, you asked about tar's behavior for
mtimes. 'tar xf' restores mtimes from the tar archive, so relative
ordering after restore would be the same, and would only rebuild if the
original source
On 2018-04-25 09:25 PM, Junio C Hamano wrote:
Marc Branchaud writes:
But Git is not an archiver (tar), but is a source code control
system, so I do not think we should spend any extra cycles to
"improve" its behaviour wrt the relative ordering, at least for the
default case. Only
On 2018-04-27 01:03 PM, Duy Nguyen wrote:
On Wed, Apr 25, 2018 at 5:18 PM, Marc Branchaud wrote:
The best approach to do so is to have those people do the "touch"
thing in their own post-checkout hook. People who use Git as the
source control system won't have to pay runtime co
On 2018-05-09 02:21 PM, Stefan Beller wrote:
+cc Marc and Johannes who know more about rebase.
On Wed, May 9, 2018 at 9:01 AM, Ilya Kantor wrote:
Right now in "git help rebase" for --no-ff:
"Without --interactive, this is a synonym for --force-rebase."
But *with* --interactive, is there any d
just --no-ff
(with -f as a synonym).
M.
---
Best Regards,
Ilya Kantor
On Wed, May 9, 2018 at 10:27 PM, Marc Branchaud wrote:
On 2018-05-09 02:21 PM, Stefan Beller wrote:
+cc Marc and Johannes who know more about rebase.
On Wed, May 9, 2018 at 9:01 AM, Ilya Kantor wrote:
On 2017-06-12 06:58 PM, Jacob Keller wrote:
Hi,
There's no actual code yet, (forgive me), but I've been thinking back
to a while ago about attempting to find a way to share things like
refs/notes, and similar refs which are usually not shared across a
remote.
By default, those refs are not prop
On 2017-06-13 10:41 AM, Marc Branchaud wrote:
So I like your refs/tracking proposal, and hope that it aims for
mirroring a remote's refs, to eventually replace refs/remotes entirely.
To be extra-clear:
I think a refs/tracking hierarchy that starts with notes and maybe some
other bits
On 2017-06-20 02:04 PM, Kaartic Sivaraam wrote:
On Tue, 2016-12-20 at 09:02 -0500, Marc Branchaud wrote:
When auto-correct is enabled, an invalid git command prints a warning
and
a continuation message, which differs depending on whether or not
help.autoCorrect is positive or negative.
With
'log'.
With help.autoCorrect < 0:
WARNING: You called a Git command named 'lgo', which does not exist.
Continuing under the assumption that you meant 'log'.
Signed-off-by: Marc Branchaud
---
So here's the patch again.
M.
help.c
On 2017-06-23 04:54 PM, Junio C Hamano wrote:
Jacob Keller writes:
Instead, lets add support for a new refs/tracking/* hierarchy which is
laid out in such a way to avoid this inconsistency. All refs in
"refs/tracking//*" will include the complete ref, such that
dropping the "tracking/" part wi
On 2017-02-22 06:59 AM, Jessie Hernandez wrote:
HI,
the reason why it is fixed, is because commit messages should be
wrapped at 76 characters to be used in mails. So it helps you with the
wrapping.
Bert
Right ok. I understand.
Knowing this I think I might start writing my commit messages diff
On 2017-03-03 05:57 AM, Sebastian Schuberth wrote:
It does not make sense for these placeholder scripts to depend on Python
just because the real scripts do. At the example of Git for Windows, we
would not even be able to see those warnings as it does not ship with
Python. So just use plain shell
(I'm using git 2.15.0.)
So today "git gc" started complaining:
error: Could not read 2bc277bcb7e9cc6ef2ea677dd1c3dcd1f9af0c2b
fatal: Failed to traverse parents of commit
9c355a7726e31b3033b8e714cf7edb4f0a41d8d4
error: failed to run repack
I suspect I'm a victim of the worktree+submodule bugs
(It turned out that this problem is related to worktrees. CCing some
worktree folks.)
On 2017-11-14 12:53 AM, Jeff King wrote:
On Mon, Nov 13, 2017 at 04:13:19PM -0500, Marc Branchaud wrote:
Various incantations of "git show ... 9c355a7726e31" only fail with the same
error,
On 2017-11-14 01:21 AM, Christian Couder wrote:
On Tue, Nov 14, 2017 at 3:04 AM, wrote:
From: Haaris
Description:
This patch adds a new option to the config command.
Uses flag --expiry-date as a data-type to covert date-strings to
timestamps when reading from config files (GET).
This flag i
On 14-03-14 12:37 AM, Andrew Wong wrote:
> During a merge, "--mixed" is most likely not what the user wants. Using
> "--mixed" during a merge would leave the merged changes and new files
> mixed in with the local changes. The user would have to manually clean
> up the work tree, which is non-trivia
On 14-03-14 04:55 PM, Junio C Hamano wrote:
So I am OK with "eventually error out by default", but not OK with
"we know better than the user and will not allow it at all".
Can I interpret that as you being OK with my proposed "Cowardly
refusing" approach?
M.
--
To unsubscri
ore
thought is also needed here, but not today.
Both Heiko and Robert took issue with this statement of mine:
On 14-08-22 12:00 PM, Marc Branchaud wrote:
> A branch should fork the entire repo, including its submodules. The
> implication is that if you want to push that branch somewhere, t
On 14-08-28 03:35 PM, Heiko Voigt wrote:
> On Thu, Aug 28, 2014 at 01:44:18PM -0400, Marc Branchaud wrote:
>> Heiko also said this:
>>> On Fri, Aug 22, 2014 at 12:00:07PM -0400, Marc Branchaud wrote:
>>>> With relative-path submodules, the push's target repo *mus
On 14-09-02 08:27 AM, Duy Nguyen wrote:
> After reading this "multiple checkout mode" in git-checkout.txt, I'm
> tempted to rewrite it like this. I think the example makes it clearer
> what I mean. If nobody has any comments, I'm going to send v2 with
> this (and other comments collected so far)
O
On 14-09-08 06:52 AM, Duy Nguyen wrote:
>
> While we're changing the terms, I wonder if "primary working
> directory" and "secondary working directories" are better than "main
> checkout" and "linked checkout".
I might have a slight preference for main/linked, because primary/secondary
can imply
1 - 100 of 234 matches
Mail list logo
