Jonathan Tan writes:
> +test_expect_success 'warn if using server-option with ls-remote with legacy
> protocol' '
> + GIT_TEST_PROTOCOL_VERSION=0 test_must_fail git -c protocol.version=0 \
> + ls-remote -o hello -o world "file://$(pwd)/file_parent" master
> 2>err &&
test_must_f
Nguyễn Thái Ngọc Duy writes:
> v2 should address all the comments from v1. I still haven't done that
> --intent-to-add thing yet even though I'd like to make it default
> behavior too. Anyway changes are
>
> - --index is renamed to --staged to avoid conflict with --index from
> git-apply, whic
Hi,
Jeff Hostetler wrote:
> Initialize opts structure in repo_read_config().
Good find. I wonder if there are some flags we can turn on with
DEVELOPER=1 to prevent this kind of issue going undetected in the
future (or maybe this means we need to get the valgrind or ASan
testing modes to be fast
"Eckhard Maaß" writes:
> ... Wouldn't it be the more sane approach here to fail, when the old
> tag is (or as in your example will) still be referenced?
That is unworkable in the distributed world. There may be somebody
else who has a copy of the old tag and you may end up getting that
later.
"Emily Shaffer via GitGitGadget" writes:
> diff --git a/Documentation/MyFirstContribution
> b/Documentation/MyFirstContribution
> new file mode 100644
> index 00..9b87e424d6
> --- /dev/null
> +++ b/Documentation/MyFirstContribution
> @@ -0,0 +1,674 @@
> +My First Contribution
> +
"Emily Shaffer via GitGitGadget" writes:
> RFC. I am still working on adding a section on handling refs and objects.
Thanks. Is 'lab' understood widely enough? I _think_ you are
abbreviating what is known as 'codelab' by your colleagues at work,
but would it make it more in line with what we a
On Fri, Apr 12, 2019 at 11:32:25AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Thu, Apr 11, 2019 at 03:20:52PM -0300, Bárbara de Castro Fernandes wrote:
> >
> >> This new proposed --amend option, although semantically different,
> >> would have a very similar functionality to the a
Jeff King writes:
> On Thu, Apr 11, 2019 at 03:20:52PM -0300, Bárbara de Castro Fernandes wrote:
>
>> This new proposed --amend option, although semantically different,
>> would have a very similar functionality to the already existing -f
>> option. So should we, perhaps, change -f's behavior to
"Jeff Hostetler via GitGitGadget" writes:
> Here is version 3.
> [] It incorporates Ævar's suggestions WRT the format and uniqueness of the
> SID. [] It now reads both system and global config for trace2 settings and
> handles includes as Jonathan suggested.
Following the ISO more closely with T
Johannes Schindelin writes:
> For me, this does not work without this squashed in:
>
> -- snipsnap --
> diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
> index 33a1d70b434d..7767cb1fab64 100755
> --- a/t/t7004-tag.sh
> +++ b/t/t7004-tag.sh
> @@ -1688,7 +1688,7 @@ test_expect_success '--points-at fin
Jeff King writes:
> Yeah, every struct on a platform where FLEX_ARRAY is 1 ends up
> over-allocated by 1 byte. We could account for that in all of our flex
> allocations, but I don't it affects enough platforms to be worth the
> bother.
It was an explicit design decision to declare that the
over
Duy Nguyen writes:
> But gitattributes.txt explicitly says that it's wrong. One would need
> to do "path/** precious" to achieve the same thing.
>
> So yeah maybe doing this before S_ISDIR() is wrong. The definition of
> `precious` also only says "... is set on _files_". Maybe best to
> ignore at
Torsten Bögershausen writes:
> It seems that I haven't read all messages in my mailbox (or messages crossed).
>
> The V2 patch describes the problem well and looks OK for me.
Yeah, I just re-read the log message with a fresh pair of eyes, and
I think it is clear enough.
Thanks, both.
On Thu, Apr 11, 2019 at 10:58:57PM +0200, SZEDER Gábor wrote:
> On Thu, Apr 11, 2019 at 10:51:46PM +0200, SZEDER Gábor wrote:
> > On Wed, Apr 10, 2019 at 10:56:52PM +0200, Johannes Schindelin wrote:
> > > > ...>}
> > > >
> > > > @@
> > > > + expression c;
> > > > ++expression
On Thu, Apr 11, 2019 at 01:44:06PM -0400, Eric Sunshine wrote:
> On Wed, Apr 10, 2019 at 7:35 PM brian m. carlson
> wrote:
> > [...]
> > Note that we are guaranteed to always correctly encode carriage returns
> > when writing quoted-printable since we explicitly specify the line
> > ending as "\n"
I'm using git 2.20.1 from Debian. Git is usually careful not to
overwrite untracked files, including ignored files. But interactive
rebase doesn't detect this (non-interactive rebase works fine).
Reproduction:
-
#!/bin/sh
mkdir upstream
cd upstream
git init
echo 1 >feature-1
git add feature-1
On Thu, Apr 11, 2019 at 10:28:30PM +0100, Thomas Gummerer wrote:
> > I didn't see any comment on this, but it seems like it must be obviously
> > correct, since as you note we do define those fields as unsigned. I'm
> > really surprised that -Wformat doesn't catch this, though. I wonder why.
>
>
On 04/11, Duy Nguyen wrote:
> Try
>
> git range-diff from...to
>
> with those two branches from https://gitlab.com/pclouds/git.git. The
> interesting part is this
>
> diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt
> --- a/Documentation/gitcli.txt
> @@ -120,1
On 04/11, Jeff King wrote:
> On Sun, Apr 07, 2019 at 07:47:51PM +0100, Thomas Gummerer wrote:
>
> > struct stat_data and struct cache_time both use unsigned ints for all
> > their members. However the format string for 'git ls-files --debug'
> > currently uses %d for formatting these numbers. Th
On 04/10, Matheus Tavares Bernardino wrote:
> > > diff --git a/dir-iterator.h b/dir-iterator.h
> > > index 970793d07a..93646c3bea 100644
> > > --- a/dir-iterator.h
> > > +++ b/dir-iterator.h
> > > @@ -19,7 +19,7 @@
> > > * A typical iteration looks like this:
> > > *
> > > * int ok;
> > >
On 2019.04.11 11:32, Emily Shaffer via GitGitGadget wrote:
> RFC. I am still working on adding a section on handling refs and objects.
>
> A tutorial for beginners explaining how to commit to git/git from clone to
> push. This tutorial attempts to explain the GitGitGadget workflow; with the
> revi
On Thu, Apr 11, 2019 at 10:51:46PM +0200, SZEDER Gábor wrote:
> On Wed, Apr 10, 2019 at 10:56:52PM +0200, Johannes Schindelin wrote:
> > > ...>}
> > >
> > > @@
> > > + expression c;
> > > ++expression r;
> > > + expression s;
> > > + @@
> > > +-- get_commit_tree(c)
On Wed, Apr 10, 2019 at 10:56:52PM +0200, Johannes Schindelin wrote:
> Hi Duy,
>
> On Sat, 6 Apr 2019, Nguyễn Thái Ngọc Duy wrote:
>
> > 10: 68876a150f ! 11: 848456f59c commit.c: add repo_get_commit_tree()
> > @@ -2,6 +2,11 @@
> >
> > commit.c: add repo_get_commit_tree()
> >
> >
Hi,
On Thu, 11 Apr 2019, Duy Nguyen wrote:
> On Thu, Apr 11, 2019 at 3:56 AM Johannes Schindelin
> wrote:
> > > @@
> > > + expression c;
> > > ++expression r;
> > > + expression s;
> > > + @@
> > > +-- get_commit_tree(c) = s
> > > ++- repo_get_commit_tree(r, c) = s
Commit 5e3548ef16 ("fetch: send server options when using protocol v2",
2018-04-24) taught "fetch" the ability to send server options when using
protocol v2, but not "clone". This ability is triggered by "-o" or
"--server-option".
Teach "clone" the same ability, except that because "clone" already
Thanks, Jonathan Nieder, for your review.
> Thanks for writing this. I'd be in favor of making this die().
> Compare what we already do in push:
>
> if (args->push_options && !push_options_supported)
> die(_("the receiving end does not support push options"));
Thanks for poi
Server options were added in commit 5e3548ef16 ("fetch: send server
options when using protocol v2", 2018-04-24), supported only for
protocol version 2. But if the user specifies server options, and the
protocol version being used doesn't support them, the server options are
silently ignored.
Teac
On Thu, Apr 11, 2019 at 03:16:22PM -0400, Can Gemicioglu wrote:
> I noticed a problem when trying to apply a patch file that contained
> many separate patches in a single file.
To quote the first line of its manpage :) 'git apply' is meant to
"Apply a patch to files and/or to the index". Note the
On Thu, Apr 11, 2019 at 12:43:08PM -0700, Taylor Blau wrote:
> > I don't think we can ban malloc, since we have to use it ourselves. :)
> >
> > With some contortions, we probably could unban it specifically in
> > wrapper.c (though note there are a few other calls I've left which would
> > need to
Hi,
I noticed a problem when trying to apply a patch file that contained many
separate patches in a single file. Trying to apply this patch gave me a "No
such file or directory" error for one of the files in the middle and after
looking around I realised this file was also created earlier in th
Hi Peff,
On Thu, Apr 11, 2019 at 03:37:35PM -0400, Jeff King wrote:
> On Thu, Apr 11, 2019 at 12:14:52PM -0700, Taylor Blau wrote:
>
> > > This series cleans up most of the bare calls found by:
> > >
> > > git grep -E '[^a-z_](m|c|re)alloc\(' '*.c' :^compat :^contrib
> > > :^wrapper.c
> >
> > T
On Thu, Apr 11, 2019 at 12:14:52PM -0700, Taylor Blau wrote:
> > This series cleans up most of the bare calls found by:
> >
> > git grep -E '[^a-z_](m|c|re)alloc\(' '*.c' :^compat :^contrib :^wrapper.c
>
> This (admittedly pretty awesome) 'git grep' invocation reminds me of a
> series I was pre
Hi Peff,
On Thu, Apr 11, 2019 at 09:47:36AM -0400, Jeff King wrote:
> It was reported on the Git security list that there are a few spots
> which use a bare malloc() but don't check the return value, which could
> dereference NULL. I don't think any of these are exploitable in an
> interesting way
On Thu, Apr 04, 2019 at 08:27:22AM -0400, Jeff King wrote:
> IMHO the difference between those cases is that it is very easy to type
> something natural to get a tag of tag, like:
>
> git tag -m foo mytag
> # oops, try again
> git tag -m bar -f mytag mytag
Could it be that the semantics of
From: Emily Shaffer
This code lab covers how to add a new command to Git and, in the
process, everything from cloning git/git to getting reviewed on the mail
list. It's meant for new contributors to go through interactively,
learning the techniques generally used by the git/git development
commun
RFC. I am still working on adding a section on handling refs and objects.
A tutorial for beginners explaining how to commit to git/git from clone to
push. This tutorial attempts to explain the GitGitGadget workflow; with the
review I'm hoping to understand whether it's worth the effort to detail h
On Thu, Apr 11, 2019 at 03:20:52PM -0300, Bárbara de Castro Fernandes wrote:
> This new proposed --amend option, although semantically different,
> would have a very similar functionality to the already existing -f
> option. So should we, perhaps, change -f's behavior to treat the tag
> as a new o
Em sex, 5 de abr de 2019 às 19:21, Jeff King escreveu:
>
> On Thu, Apr 04, 2019 at 08:56:16AM -0500, Robert Dailey wrote:
>
> > > I was thinking it was just the --no-edit fix. :) Even with the "--amend"
> > > thing, though, it's probably a little light for a 3-month-long GSoC
> > > project. :)
> >
On Wed, Apr 10, 2019 at 7:35 PM brian m. carlson
wrote:
> [...]
> Note that we are guaranteed to always correctly encode carriage returns
> when writing quoted-printable since we explicitly specify the line
> ending as "\n", forcing MIME::QuotedPrint to encode our carriage return
> as "=OD".
s/=O
This is useful when investigating performance of pushes, and other times
when no progress information is written (because the pack is written to
stdout).
Signed-off-by: Jonathan Tan
---
Thanks, Duy and Jeff for your comments. I've switched to Jeff's
suggestion (trace2_data_intmax), which also sid
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi folks,
I am a heavy user of git now at version 2.20.1 on debian.
Since some weeks I have the problem that I get often "fatal: unable to
read ..." and a unclear repository after a git commit. The commit itself
is correct and so a git reset --hard
From: Jeff Hostetler
Teach git to read the system and global config files for
default Trace2 settings. This allows system-wide Trace2 settings to
be installed and inherited to make it easier to manage a collection of
systems.
The original GIT_TR2* environment variables are loaded afterwards and
From: Jeff Hostetler
Create trace2_initialize_clock() and call from main() to capture
process start time in isolation and before other sub-systems are
ready.
Signed-off-by: Jeff Hostetler
---
Documentation/technical/api-trace2.txt | 12 ++--
common-main.c | 2 ++
From: Jeff Hostetler
Teach Git to resolve the executable directory before initializing
Trace2. This allows the system configuration directory to be
discovered earlier (because it is sometimes relative to the prefix
or runtime-prefix).
This will be used by the next commit to allow trace2 setting
From: Jeff Hostetler
Created an even lighter version of read_early_config() that
only looks at system and global config settings. It omits
repo-local, worktree-local, and command-line settings.
Signed-off-by: Jeff Hostetler
---
config.c | 25 ++---
config.h | 4
2 fi
From: Jeff Hostetler
Add elapsed process time to "start" event to measure
the performance of early process startup.
Signed-off-by: Jeff Hostetler
---
Documentation/technical/api-trace2.txt | 11 ++-
t/t0211-trace2-perf.sh | 12 ++--
trace2.c
From: Jeff Hostetler
Signed-off-by: Jeff Hostetler
---
Documentation/config.txt | 2 +
Documentation/config/trace2.txt| 56 ++
Documentation/technical/api-trace2.txt | 141 ++---
Documentation/trace2-target-values.txt | 10 ++
4 files change
From: Jeff Hostetler
Update SID component construction to use the current UTC datetime
and a portion of the SHA1 of the hostname.
Use an simplified date/time format to make it easier to use the
SID component as a logfile filename.
Signed-off-by: Jeff Hostetler
---
Documentation/technical/api-
From: Jeff Hostetler
Update tr2_tbuf_utc_datetime to generate extended UTC format.
Update tr2_tgt_event target to use extended format in 'time' columns.
Signed-off-by: Jeff Hostetler
---
Documentation/technical/api-trace2.txt | 12 ++--
trace2/tr2_tbuf.c | 4 ++--
From: Jeff Hostetler
Teach Windows version of git to report peak memory usage
during exit() processing.
Signed-off-by: Jeff Hostetler
---
common-main.c| 2 +-
compat/win32/trace2_win32_process_info.c | 50 ++--
trace2.c
Here is version 3.
[] It incorporates Ævar's suggestions WRT the format and uniqueness of the
SID. [] It now reads both system and global config for trace2 settings and
handles includes as Jonathan suggested.
I added a read_very_early_config() function that is similar to
read_early_config()but om
From: Jeff Hostetler
Initialize opts structure in repo_read_config().
This change fixes a crash in later commit after a new field is added
to the structure.
In commit 3b256228a66f8587661481ef3e08259864f3ba2a, repo_read_config()
was added. It only initializes 3 fields in the opts structure. It
On Tue, Apr 9, 2019 at 8:08 PM Junio C Hamano wrote:
> * cc/replace-graft-peel-tags (2019-04-01) 4 commits
> - replace: fix --graft when passing a tag first
> - replace: fix --graft when passing a tag as parent
> - t6050: redirect expected error output to a file
> - t6050: use test_line_count
Since the early days of Git, the progress code allocates its struct with
a bare malloc(), not xmalloc(). If the allocation fails, we just avoid
showing progress at all.
While perhaps a noble goal not to fail the whole operation because of
optional progress, in practice:
1. Any failure to alloca
Most of xdiff uses a bare malloc() to allocate memory, and returns an
error when we get NULL. However, there are a few spots which don't check
the return value and may segfault, including at least xdl_merge() and
xpatience.c's find_longest_common_sequence().
Let's use xmalloc() everywhere instead,
Since the xdiff library was not originally part of Git, it does its own
system includes. Let's instead use git-compat-util, which has two
benefits:
1. It adjusts for any system-specific quirks in how or what we should
include (though xdiff's needs are light enough that this hasn't
been
test-prio-queue.c doesn't check the return value of malloc, and could
segfault.
It's unlikely for this to matter in practice; it's a small allocation,
and this code isn't even installed alongside the rest of Git. But let's
use xmalloc(), which makes auditing for other accidental uses of bare
mallo
It was reported on the Git security list that there are a few spots
which use a bare malloc() but don't check the return value, which could
dereference NULL. I don't think any of these are exploitable in an
interesting way, beyond Git just segfaulting more or less immediately.
But we should still
The third column in command-list.txt determines what group a common
command is printed in 'git help'.
"git reset" is currently in the "work on the current change (see also:
git help everyday)" group. While it's true that "git reset" can
manipulate the index and can be in this group, its unique
fun
After the last patch, "git status" now suggests
- add to stage some changes
- restore [--worktree] to undo worktree changes
- restore --staged to undo index changes
- rm --cached to remove files from the index
This change is to make the suggestions for more consisten
The new command "git restore" (together with "git switch") are added
to avoid the confusion of one-command-do-all "git checkout" for new
users. They are also helpful to avoid ambiguous context.
For these reasons, promote it everywhere possible. This includes
documentation, suggestions/advice from
Completion for restore is straightforward. We could still do better
though by giving the list of just tracked files instead of all present
ones. But let's leave it for later.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
contrib/completion/git-completion.bash | 15 +++
1 file changed, 15 i
Signed-off-by: Nguyễn Thái Ngọc Duy
---
t/lib-patch-mode.sh | 12
t/t2070-restore.sh (new +x) | 99 +++
t/t2071-restore-patch.sh (new +x) | 110 ++
3 files changed, 221 insertions(+)
diff --git a/t/lib-patch-mode.sh b
Since the operation in progress is merge, stick to the 'git merge'
variant of aborting. 'git reset --hard' does not really tell you about
aborting the merge by just looking, longer to type, and even though I
know by heart what --hard do, I still dislike it when I need to consider
whether --hard, --
git-checkout rejects plenty of invalid option combinations. Since
git-checkout is equivalent of either
git restore --source --staged --worktree
or
git restore --worktree
that still leaves the new mode 'git restore --index' unprotected. Reject
some more invalid option combinations.
The
"git restore --staged" without --source does not make much sense since
by default we restore from the index. Instead of copying the index to
itself, set the default source to HEAD in this case, yielding behavior
that matches "git reset -- ".
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/check
'git checkout ' updates both index and
worktree. But updating the index when you want to restore worktree
files is non-intuitive. The index contains the data ready for the next
commit, and there's no indication that the user will want to commit
the restored versions.
'git restore' therefore by de
Use a more specific option name to express its purpose. --force may come
back as an alias of --ignore-unmerged and possibly more. But since this
is a destructive operation, I don't see why we need to "force" anything
more. We already don't hold back.
When 'checkout --force' or 'restore --ignore-un
git-restore is different from git-checkout that it only restores the
worktree by default, not both worktree and index. add--interactive
needs some update to support this mode.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/checkout.c| 6 +++--
git-add--interactive.perl | 52 +++
Overlay mode is considered confusing when the command is about
restoring files on worktree. Disable it by default. The user can still
turn it on, or use 'git checkout' which still has overlay mode on by
default.
While at it, make the check in checkout_branch() stricter. Neither
--overlay or --no-o
This is another departure from 'git checkout' syntax, which uses -- to
separate ref and pathspec. The observation is restore (or "git
checkout -- ") is most often used to restore some files from
the index. If this is correct, we can simplify it by taking away the
ref, so that we can write
git
"git restore" without arguments does not make much sense when
it's about restoring files (what files now?). We could default to
either
git restore .
or
git restore :/
Neither is intuitive. Make the user always give pathspec, force the
user to think the scope of restore they want because
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/checkout.c | 108 +
1 file changed, 59 insertions(+), 49 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 9c5abe170e..1753c8c5ed 100644
--- a/builtin/checkout.c
+++ b/builtin/checko
Previously the switching branch business of 'git checkout' becomes a
new command 'switch'. This adds the restore command for the checking
out paths path.
Similar to git-switch, a new man page is added to describe what the
command will become. The implementation will be updated shortly to
match the
This is the companion of "git switch" and is based on that topic.
This command peforms the "checkout paths" from git-checkout, git-reset
and also has a third mode to reset only worktree, leaving the index
alone.
For new people not aware of previous discussions, this command is
supposed to be a fri
On Thu, Apr 11, 2019 at 7:49 PM NoName Req wrote:
>
> Summary
>`git -C (folder path) diff-files --name-only` output is not correct
>
> Steps to Reproduce
> 1. Apply change to a clean git repository. Go to another folder (not
> within this repository) and apply the command
>`git -C repo-pat
On Thu, Apr 11, 2019 at 03:47:58PM +0300, NoName Req wrote:
> Summary
>`git -C (folder path) diff-files --name-only` output is not correct
>
> Steps to Reproduce
> 1. Apply change to a clean git repository. Go to another folder (not
> within this repository) and apply the command
>`git -C
Summary
`git -C (folder path) diff-files --name-only` output is not correct
Steps to Reproduce
1. Apply change to a clean git repository. Go to another folder (not
within this repository) and apply the command
`git -C repo-path diff-files --name-only`
The above command lists dirty files in t
Try
git range-diff from...to
with those two branches from https://gitlab.com/pclouds/git.git. The
interesting part is this
diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt
--- a/Documentation/gitcli.txt
@@ -120,10 +111,11 @@
* linkgit:git-commit[1] to
Sorry mistyped 'y', please ignore.
On Thu, Apr 11, 2019 at 6:10 PM Duy Nguyen wrote:
>
>
--
Duy
First, let me thank you for your very thorough review!
>From Junio C Hamano, Tue 09 Apr 2019 at 17:03:12 (+0900) :
> It may be better to present the whole remedy, not just this new
> piece that is an ingredient of it, i.e.
> Teach a new --no-fetch option to `git pull`, so that the old
>
On Wed, Mar 13, 2019 at 11:58 AM Junio C Hamano wrote:
>
> Duy Nguyen writes:
>
> >> Just curious: At what point did git checkout become not commonly
> >> used? Git switch and git restore are not yet in git as of 2.21.0,
> >> which is rather current. Maybe I missed a thread.
> >
> > I declare "gi
Greetings From Mrs.elodie antoine,
May be this letter will definitely come to you as a huge surprise, but I
implore you to take the time to go through it carefully as the decision you
make will go off a long way to determine my future and continued existence. I
am Mrs.elodie antoine, aging w
84 matches
Mail list logo
