In t0021.15 one of the things we are checking is that the clean filter
is run when checking out empty-branch. The clean filter needs to be
run to make sure there are no modifications on the file system for the
test.r file, and thus it isn't dangerous to overwrite it.
However in the current test s
Bryan Turner writes:
> Is there any way, with "git for-each-ref", to output the "fully"
> peeled SHA of a tag's ultimate target, regardless of how many layers
> must be traversed?
I do not think I wrote it to allow different degree of peeling, not
because I wanted to explicitly forbid a use case
Hi, everyone
I just posted the penultimate report on my project:
https://matheustavares.gitlab.io/posts/going-for-a-too-big-step This
week I’ve been working on a v2 of threaded git-grep w/ parallel
inflation, to allow threads when grepping submodules. I also tried
some more optimizations along the
Hi Everyone
Please ignore this patch. I forgot to clean the output dir before
sending this iteration.
Thanks
Rohit
On Tue, Aug 20, 2019 at 9:15 AM Rohit Ashiwal
wrote:
>
> I've tries to incorporated all the suggestions.
I've tried to incorporate all the suggestions.
On Mon, Aug 19, 2019 at 7:53 PM Denton Liu wrote:
> We used to populate the subject of the cover letter generated by
> git-format-patch with "*** SUBJECT HERE ***". However, if a user submits
> multiple patchsets, they may want to keep a consistent subject between
> rerolls.
>
> If git-format-patc
rebase am already has this flag to "lie" about the author date
by changing it to the committer (current) date. Let's add the same
for interactive machinery.
Signed-off-by: Rohit Ashiwal
---
Documentation/git-rebase.txt| 6 +--
builtin/rebase.c| 16 ---
se
There are two backends available for rebasing, viz, the am and the
interactive. Naturally, there shall be some features that are
implemented in one but not in the other. One such flag is
--ignore-whitespace which indicates merge mechanism to treat lines
with only whitespace changes as unchanged. Wi
The previous commit introduced --ignore-date flag to interactive
rebase, but the name is actually very vague in context of rebase -i
since there are two dates we can work with. Add an alias to convey
the precise purpose.
Signed-off-by: Rohit Ashiwal
---
Documentation/git-rebase.txt | 1 +
builti
The previous commit introduced --ignore-date flag to interactive
rebase, but the name is actually very vague in context of rebase -i
since there are two dates we can work with. Add an alias to convey
the precise purpose.
Signed-off-by: Rohit Ashiwal
---
Documentation/git-rebase.txt | 1 +
builti
The purpose of amend_author was to free() the malloc()'d string
obtained from get_author() while amending a commit. But we can
also use the variable to free() the author at our convenience.
Rename it to convey this meaning.
Signed-off-by: Rohit Ashiwal
---
sequencer.c | 6 +++---
1 file changed,
I've tries to incorporated all the suggestions.
Some points:
- According to v2.0.0's git-am.sh, ignore-date should override
committer-date-is-author-date. Ergo, we are not barfing out
when both flags are provided.
- Should the 'const' qualifier be removed[2]? Since it is leaving
a
rebase am already has this flag to "lie" about the committer date
by changing it to the author date. Let's add the same for
interactive machinery.
Signed-off-by: Rohit Ashiwal
---
Documentation/git-rebase.txt| 10 +++--
builtin/rebase.c| 17 +---
sequencer
read_author_script reads name, email and author date from the author
script. However, it does not check if the arguments are NULL. Adding
NULL checks will allow us to selectively get the required value, for
example:
char *date;
if (read_author_script(_path_, NULL, NULL, &date, _int_))
On 2019-08-19 at 09:55:27, Phillip Wood wrote:
> On 19/08/2019 10:41, Phillip Wood wrote:
> > [...]
> > > diff --git a/convert.c b/convert.c
> > > index 94ff837649..030e9b81b9 100644
> > > --- a/convert.c
> > > +++ b/convert.c
> > > @@ -1293,10 +1293,11 @@ struct conv_attrs {
> > > const char
On Mon, Aug 19, 2019 at 7:53 PM Denton Liu wrote:
> diff --git a/Documentation/config/format.txt b/Documentation/config/format.txt
> @@ -74,7 +74,8 @@ format.signOff::
> format.coverLetter::
> - A boolean that controls whether to generate a cover-letter when
> + A boolean which lets y
On 2019-08-19 at 09:41:42, Phillip Wood wrote:
> Hi Brian
>
> On 18/08/2019 19:44, brian m. carlson wrote:
> > When applying multiple patches with git am, or when rebasing using the
> > am backend, it's possible that one of our patches has updated a
> > gitattributes file. Currently, we cache this
On Mon, Aug 19, 2019 at 7:53 PM Denton Liu wrote:
> In git-format-patch.txt, we were missing some key user information.
> First of all, using the `--to` and `--cc` options don't override
> `format.to` and `format.cc` variables, respectively. They add on to each
> other. Document this.
This entire
On Mon, Aug 19, 2019 at 7:53 PM Denton Liu wrote:
> In Git's tests, there is typically no space between the redirection
> operator and the filename. Remove these spaces.
>
> Since output is silenced when running without `-v` and debugging
> output is useful with `-v`, remove redirections to /dev/n
19.08.2019, 13:30, "Aaron Miller" :
> Hi all,
>
> Is it possible to `git p4 clone --detect-branches` from a Perforce
> path which contains bidirectional integrations?
Yes, but it would require some manual work most likely.
First of all, git-p4 should normally take only one direction from bidire
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
Signed-off-by: Denton Liu
---
Documentation/config/format.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/config/format.txt b/Documentation/config/format.txt
index 414a5a8a9d..60e4e92885 100644
--- a/Documentation/config/format.txt
+++ b/Documentation/confi
In Git's tests, there is typically no space between the redirection
operator and the filename. Remove these spaces.
Since output is silenced when running without `-v` and debugging
output is useful with `-v`, remove redirections to /dev/null.
Change here-docs from `<<\EOF` to `<<-\EOF` so that th
In git-format-patch.txt, we were missing some key user information.
First of all, using the `--to` and `--cc` options don't override
`format.to` and `format.cc` variables, respectively. They add on to each
other. Document this.
In addition, document the special value of `--base=auto`.
Next, while
We used to populate the subject of the cover letter generated by
git-format-patch with "*** SUBJECT HERE ***". However, if a user submits
multiple patchsets, they may want to keep a consistent subject between
rerolls.
If git-format-patch is run with `--infer-cover-letter` or
`format.inferCoverSubj
Thanks for the review, Eric. I've incorporated all of your suggestions
and, while I was doing that, I found a couple more places for cleanup.
Currently, format-patch only puts "*** SUBJECT HERE ***" when a cover
letter is generated. However, it is already smart enough to be able to
populate the co
When running "git for-each-ref", it's possible to use %(*objectname)
to get the SHA of the object a tag is tagging, and %(*objecttype) to
get the type. However, in the case of an annotated tag of an annotated
tag, this still isn't "fully" peeled--%(*objectname) is the tagged
tag's SHA.
Is there an
On Mon, Aug 19, 2019 at 01:09:04PM -0400, Eric Sunshine wrote:
> On Sun, Aug 18, 2019 at 10:37 PM Denton Liu wrote:
> > In git-format-patch.txt, we were missing some key user information.
> > First of all, using the `--to` and `--cc` options don't override
> > `format.to` and `format.cc` variables
Ben Milman writes:
> In the description of 'objects/pack', 'object' should be
> pluralized to match the subject and agree with the
> rest of the sentence.
Thanks.
Beat Bolli writes:
> This information is useful and not visible anywhere else, so show it.
>
> Signed-off-by: Beat Bolli
> Suggested-by: Johannes Schindelin
>
> ---
> This applies on top of 'ab/pcre-jit-fixes', currently in pu.
Thanks.
We saw a few people exchanging patches on the list and
Ben Wijen writes:
> When using `git rebase --autostash ` and
> the workarea is dirty, the active branch is incorrectly reset
> to the rebase branch.
>
> This test will check for such behavior.
>
> Signed-off-by: Ben Wijen
> ---
> t/t3420-rebase-autostash.sh | 9 +
> 1 file changed, 9
Hi,
This series adds the ability to revert selected lines and hunks in
git-gui. Partially based on the patch by Bert Wesarg [0].
The commits can be found in the topic branch 'py/git-gui-revert-lines'
at https://github.com/prati0100/git/tree/py/git-gui-revert-lines
Once reviewed, pull the commits
Just like the user can select lines to stage or unstage, add the
ability to revert selected lines.
Signed-off-by: Pratyush Yadav
---
git-gui/git-gui.sh | 25 -
git-gui/lib/diff.tcl | 31 ++-
2 files changed, 50 insertions(+), 6 deletions(-)
Upcoming commits will introduce reverting lines and hunks. They also
need to prompt the user for confirmation. Put the dialog creation in its
separate function so the same code won't be repeated again and again.
Signed-off-by: Pratyush Yadav
---
git-gui/lib/index.tcl | 27 +--
Just like the user can select a hunk to stage or unstage, add the
ability to revert hunks.
Signed-off-by: Pratyush Yadav
---
git-gui/git-gui.sh | 14 +-
git-gui/lib/diff.tcl | 34 +-
2 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/git
In the description of 'objects/pack', 'object' should be
pluralized to match the subject and agree with the
rest of the sentence.
Signed-off-by: Ben Milman
---
Documentation/gitrepository-layout.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/gitrepository-l
Am 19.08.19 um 22:44 schrieb Stephen Boyd:
> Quoting Johannes Sixt (2019-08-19 11:40:47)
>> Am 17.08.19 um 00:56 schrieb Stephen Boyd:
>>> diff --git a/t/t4018/dts-labels b/t/t4018/dts-labels
>>> new file mode 100644
>>> index ..27cd4921cfb6
>>> --- /dev/null
>>> +++ b/t/t4018/dts-label
The Linux kernel receives many patches to the devicetree files each
release. The hunk header for those patches typically show nothing,
making it difficult to figure out what node is being modified without
applying the patch or opening the file and seeking to the context. Let's
add a builtin 'dts' p
From: Ibrahim El Rhezzali
2f8f82549 Added documentation for the new signing interface
This contains a model document and updated Documentation detailing new
interface and config aliases and their description
Signed-off-by: Ibrahim El
---
Documentation/config/commit.txt | 12 ++
Following previous introduction mail [1], this first series of 5 patches is a
re-write of the signing interface API in an effort to support easily the
addition of new tools with minimal effort and also keeping backwards
compatibility with current tools and configuration.
All existing tests curr
From: Ibrahim El Rhezzali
8a89a97d4 Removed old gpg interface and gpg mentions in code
Removing old GPG interface and updating the code to remove gpg mentions and
make it transparent the signign tool that is used
Signed-off-by: Ibrahim El
---
Makefile | 1 -
built
From: Ibrahim El Rhezzali
7e3e6c9e4 Added new signing interface API
Adding files for the new signing interface and also support drivers for the two
existing GPG and GPGSM X.509 tools
Signed-off-by: Ibrahim El
---
Makefile | 3 +
signing-interface.c| 487 ++
From: Ibrahim El Rhezzali
0affa9e2a Migrated to the new signing interface API
Updating the code to use the new signing interface API. Old GPG interface code
is commented and not used
Signed-off-by: Ibrahim El
---
builtin/am.c| 3 ++-
builtin/commit-tree.c | 4 ++--
builtin/co
Quoting Johannes Sixt (2019-08-19 11:40:47)
> Am 17.08.19 um 00:56 schrieb Stephen Boyd:
> > The Linux kernel receives many patches to the devicetree files each
> > release. The hunk header for those patches typically show nothing,
> > making it difficult to figure out what node is being modified w
On Mon, 19 Aug 2019 at 18:30, Aaron Miller wrote:
>
> Hi all,
>
> Is it possible to `git p4 clone --detect-branches` from a Perforce
> path which contains bidirectional integrations?
>
> I've tried a bunch of things to get this to work, but here's an
> example which hopefully illustrates what I'm
Varun Naik writes:
> This function is probably not the place where we want to make changes.
> It would be better to change diff-lib.c:show_modified() and
> diff.c:diff_change() to consider the intent-to-add bit when performing a
> diff.
I do agree that diff-lib.c::show_modified(), which is about
Matthieu Moy writes:
> To me, it depends on the involvement in the project. If I plan to send
> several contributions to a project, I'd usually clone the upstream and
> add my fork. But I also often do:
>
> - Find a project on GitHub/GitLab/...
> - Think about a minor contribution I can make
> -
Varun Naik writes:
>> Either is fine as the implementation of the same semantics; I
>> however am not sure if two I-T-A entries should compare "same" or
>> "not same", or if we are better off catching the caller that feeds
>> two I-T-A entries to same() with a BUG().
>
> I'd argue that two ita ca
Hi
I run a MacBook Pro (15-inch, 2018) with macOS 10.14.6 (18G87)
I run git version 2.23.0 via brew install git.
As soon as I launch gitk, I get an empty gitk window for about 0.5
seconds before getting thrown back to the macOS login screen due to a
SIGSEGV in com.apple.WindowServer.
If I launch
Am 17.08.19 um 00:56 schrieb Stephen Boyd:
> The Linux kernel receives many patches to the devicetree files each
> release. The hunk header for those patches typically show nothing,
> making it difficult to figure out what node is being modified without
> applying the patch or opening the file and
Ben writes:
> Hi Phillip,
>
> The expected behavior: (as per v2.21.0:/git-legacy-rebase.sh:679)
> AUTOSTASH=$(git stash create autostash)
> git reset --hard
> git checkout master
> git rebase upstream
> git stash apply $AUTOSTASH
>
>
> The actual behavior:
> AUTOSTASH=$(g
Mischa POSLAWSKY writes:
> Formatting $(taggername) on headerless tags such as v0.99 in Git
> causes a SIGABRT with error "munmap_chunk(): invalid pointer",
> because of an oversight in commit f0062d3b74 (ref-filter: free
> item->value and item->value->s, 2018-10-19).
>
> Signed-off-by: Mischa PO
"brian m. carlson" writes:
> trivial. I'm definitely not opposed if someone else is interested in
> picking it up or writing it; I don't believe my outstanding patches
> (which will likely show up on the list this weekend now that 2.23 is
> out) would affect it in any way.
>
> I'll try to push up
Jeff King writes:
> I'm undecided on this. I think reftables are still a while off, and even
> once they are here, many people will still be using the older format. So
> it makes sense to still apply fixes to the old code.
Yeah.
> What I wonder, though, is whether always refreshing will cause a
Hi all,
Is it possible to `git p4 clone --detect-branches` from a Perforce
path which contains bidirectional integrations?
I've tried a bunch of things to get this to work, but here's an
example which hopefully illustrates what I'm trying to accomplish
and the issue I'm having.
Perforce setup, a
On Sun, Aug 18, 2019 at 10:37 PM Denton Liu wrote:
> We used to populate the subject of the cover letter generated by
> git-format-patch with "*** SUBJECT HERE ***". However, if a user submits
> multiple patchsets, they may want to keep a consistent subject between
> rerolls.
>
> If git-format-pat
Elijah Newren writes:
> merge_options has several internal fields that should not be set or read
> by external callers. This just complicates the API. Move them into an
> opaque merge_options_internal struct that is defined only in
> merge-recursive.c and keep these out of merge-recursive.h.
M
On Sun, Aug 18, 2019 at 10:37 PM Denton Liu wrote:
> In git-format-patch.txt, we were missing some key user information.
> First of all, using the `--to` and `--cc` options don't override
> `format.to` and `format.cc` variables, respectively. They add on to each
> other. Document this.
>
> In addi
On 8/19/2019 11:02 AM, SZEDER Gábor wrote:
> On Mon, Aug 19, 2019 at 10:50:48AM -0400, Derrick Stolee wrote:
>> Note that I don't include the "without patch" numbers. For some
>> reason the path provided is particularly nasty and caused 20,000+
>> missing blobs to be downloaded one-by-one (remember
On Mon, Aug 19, 2019 at 5:18 AM Phillip Wood via GitGitGadget
wrote:
> Adapt try_to_commit() to create a new root commit rather than special
> casing this in run_git_commit(). The significantly reduces the amount of
s/The/This/
> special case code for creating the root commit and reduces the num
On Sun, Aug 18, 2019 at 10:38 PM Denton Liu wrote:
> diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
> @@ -96,7 +97,7 @@ test_expect_success "format-patch doesn't consider merge
> commits" '
> git merge --no-ff slave &&
> - cnt=$(git format-patch -3 --stdout | grep "^
On Thu, Aug 15, 2019 at 12:06 PM Junio C Hamano wrote:
>
> /*
> * i-t-a entries do not actually exist in the index (if we're
> * looking at its content)
> */
> if (o->index_only &&
> revs->diffopt.ita_invisible_in_index &&
> idx &&
On Thu, Aug 15, 2019 at 9:34 AM Junio C Hamano wrote:
>
> Varun Naik writes:
>
> > On Tue, Aug 13, 2019 at 1:33 PM Junio C Hamano wrote:
> >>
> >> So perhaps
> >>
> >> + !ce_intent_to_add(a) && !ce_intent_to_add(b) &&
> >>
> >> i.e. "a cache entry is eligible to be same with something else
Hi Phillip,
The expected behavior: (as per v2.21.0:/git-legacy-rebase.sh:679)
AUTOSTASH=$(git stash create autostash)
git reset --hard
git checkout master
git rebase upstream
git stash apply $AUTOSTASH
The actual behavior:
AUTOSTASH=$(git stash create autostash)
git
On Mon, Aug 19, 2019 at 10:50:48AM -0400, Derrick Stolee wrote:
> Note that I don't include the "without patch" numbers. For some
> reason the path provided is particularly nasty and caused 20,000+
> missing blobs to be downloaded one-by-one (remember: VFS for Git
> has many partial-clone-like beha
On 8/19/2019 9:03 AM, SZEDER Gábor wrote:
> On Mon, Aug 19, 2019 at 08:00:11AM -0400, Derrick Stolee wrote:
>> On 8/18/2019 2:27 PM, SZEDER Gábor wrote:
>>> Line-level log performs a preprocessing step in
>>> prepare_revision_walk(), during which it filters and rewrites history
>>> to keep only com
Hi everyone!
A draft of a new Git Rev News edition is available here:
https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-54.md
Everyone is welcome to contribute in any section either by editing the
above page on GitHub and sending a pull request, or by commenting on
this
On Mon, Aug 19, 2019 at 08:00:11AM -0400, Derrick Stolee wrote:
> On 8/18/2019 2:27 PM, SZEDER Gábor wrote:
> > Line-level log performs a preprocessing step in
> > prepare_revision_walk(), during which it filters and rewrites history
> > to keep only commits modifying the given line range. This
>
On 8/18/2019 2:28 PM, SZEDER Gábor wrote:
> To be clear: this patch doesn't actually optimize the line-level log,
> but merely moves most of the work from the preprocessing step to the
> history travelsal, so the commits modifying the line range can be
s/travelsal/traversal/
-Stolee
On Sun, Aug 18, 2019 at 08:28:00PM +0200, SZEDER Gábor wrote:
> The current line-level log implementation performs a preprocessing
> step in prepare_revision_walk(), during which the line_log_filter()
> function filters and rewrites history to keep only commits modifying
> the given line range. Th
On 8/18/2019 2:27 PM, SZEDER Gábor wrote:
> Line-level log performs a preprocessing step in
> prepare_revision_walk(), during which it filters and rewrites history
> to keep only commits modifying the given line range. This
> preprocessing causes significant delay before the first commit is
> show
On 8/18/2019 2:27 PM, SZEDER Gábor wrote:
> Remove the unused fields 'status', 'arg_alloc', 'arg_nr' and 'args'
> from 'struct line_log_data'. They were already part of the struct
> when it was introduced in commit 12da1d1f6 (Implement line-history
> search (git log -L), 2013-03-28), but as far as
On August 16, 2019 5:00 PM, Junio C Hamano wrote:
> The latest feature release Git v2.23.0 is now available at the usual places.
> It
> is comprised of 505 non-merge commits since v2.22.0, contributed by 77
> people, 26 of which are new faces.
We are having a transient failure in t0021. It runs
On August 19, 2019 5:41 AM, Ed Avis wrote:
> To: git@vger.kernel.org
> Subject: git switch and restore user interface
>
> I think it would be helpful for git switch to print a reminder of the old
and
> new branches.
>
> Hi, a couple of suggestions for these experimental new commands. Git
> switc
On 19/08/2019 10:41, Phillip Wood wrote:
[...]
diff --git a/convert.c b/convert.c
index 94ff837649..030e9b81b9 100644
--- a/convert.c
+++ b/convert.c
@@ -1293,10 +1293,11 @@ struct conv_attrs {
const char *working_tree_encoding; /* Supported encoding or
default encoding if NULL */
};
+
Hi Brian
On 18/08/2019 19:44, brian m. carlson wrote:
When applying multiple patches with git am, or when rebasing using the
am backend, it's possible that one of our patches has updated a
gitattributes file. Currently, we cache this information, so if a
file in a subsequent patch has attributes
I think it would be helpful for git switch to print a reminder of the old and
new branches.
Hi, a couple of suggestions for these experimental new commands. Git switch
should print the branch you are leaving:
% git switch foo
You were previously on branch bar (abcdef).
You are now on branch fo
Hi Ben
On 18/08/2019 10:53, Ben Wijen wrote:
I found an issue with git rebase --autostash with an dirty
worktree/index.
It seems the currently active branch is moved, which is not correct.
I'm not sure I understand what you mean by "the currently active branch
is moved". 'git rebase --auto
This series contains a couple of patches to make the C version of rebase
--interactive behave more like the scripted version. The third patch is not
strictly related to the first two but is included here to avoid merge
conflicts.
Phillip Wood (3):
rebase -i: always update HEAD before rewording
From: Phillip Wood
If the user runs git log while rewording a commit it is confusing if
sometimes we're amending the commit that's being reworded and at other
times we're creating a new commit depending on whether we could
fast-forward or not[1]. Fix this inconsistency by always committing the
pi
From: Phillip Wood
Adapt try_to_commit() to create a new root commit rather than special
casing this in run_git_commit(). The significantly reduces the amount of
special case code for creating the root commit and reduces the number of
commit code paths we have to worry about.
Signed-off-by: Phil
From: Phillip Wood
While a rebase is stopped for the user to edit a commit message it can
be convenient for them to also edit the todo list. The scripted version
of rebase supported this but the C version does not. We already check to
see if the todo list has been updated by an exec command so ex
From: Corentin BOMPARD
Add the --set-upstream option to git pull/fetch
which lets the user set the upstream configuration
(branch..merge and
branch..remote) for the current branch.
A typical use-case is:
git clone http://example.com/my-public-fork
git remote add main http://example.com/
Pratyush Yadav writes:
> This is not really a review. Just some minor nitpicks I spotted while
> reading through.
Thanks for the comments.
>> -static int all, append, dry_run, force, keep, multiple, update_head_ok,
>> verbosity, deepen_relative;
>> +static int all, append, dry_run, force, kee
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> From: Corentin BOMPARD
>>
>> Add the --set-upstream option to git pull/fetch
>> which lets the user set the upstream configuration
>> (branch..merge and
>> branch..remote) for the current branch.
>>
>> A typical use-case is:
>>
>> git clone
85 matches
Mail list logo
