Hi Kevin,
On Fri, 2 Sep 2016, Kevin Daudt wrote:
> On Wed, Aug 31, 2016 at 10:54:02AM +0200, Johannes Schindelin wrote:
> > @@ -43,16 +51,20 @@ static GIT_PATH_FUNC(rebase_path_gpg_sign_opt,
> > "rebase-merge/gpg_sign_opt")
> > /* We will introduce the 'interactive rebase' mode later */
> > st
When moving code (e.g. a function is moved to another part of the file or
to a different file), the review process is different than reviewing new
code. When reviewing moved code we are only interested in the diff as
where there are differences in the moved code, e.g. namespace changes.
However th
When moving code (e.g. a function is moved to another part of the file or
to a different file), the review process is different than reviewing new
code. When reviewing moved code we are only interested in the diff as
where there are differences in the moved code, e.g. namespace changes.
However th
Color is WIP, I just make space for a different case.
Signed-off-by: Stefan Beller
---
diff.c | 26 ++
diff.h | 4 +++-
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/diff.c b/diff.c
index 534c12e..57d435c 100644
--- a/diff.c
+++ b/diff.c
@@ -52,6 +52,8 @
Signed-off-by: Stefan Beller
---
xdiff/xemit.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/xdiff/xemit.c b/xdiff/xemit.c
index 49aa16f..b52b4b9 100644
--- a/xdiff/xemit.c
+++ b/xdiff/xemit.c
@@ -22,15 +22,6 @@
#include "xinclude.h"
-
-
-
-static long xdl_get_rec(xdfile_t *xdf
Jonathan Tan writes:
> Sample-field: multiple-line field body
> that causes a blank line below
I am not sure this is unconditionally good, or may cause problems to
those with workflows you did not consider when you wrote this patch.
Not being too lenient here historically has been a deliberate
"Philip Oakley" writes:
> As I understand this it's implied by design. The issue is that the
> rebase is looking for that named commit within its current rebase
> range, and can't find it, so ignores it.
>
> There is a separate issue that all the fixup! fixup! messages are
> essentially treated a
On Fri, Sep 02, 2016 at 07:03:30PM -0700, Shawn Pearce wrote:
> > Is it useful for upload-pack? If we have no refs, there's traditionally
> > been nothing to fetch. Perhaps that's something that could change,
> > though. For example, there could be a capability to allow fetching
> > arbitrary sha1
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
Git 2.10 has been tagged. In a fe
Welcome to the Git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports
The latest feature release Git v2.10.0 is now available at the
usual places. It is comprised of 639 non-merge commits since
v2.9.0, contributed by 76 people, 22 of which are new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repositories
On Fri, Sep 2, 2016 at 1:13 PM, Jeff King wrote:
>
> Hmm. So since this is backwards-compatible, I'm not overly concerned
> with changing the client. But I wonder if you considered that the
> documentation is wrong, and that JGit should stop sending the extra
> capabilities line?
No, JGit needs t
On Fri, Sep 02, 2016 at 04:51:45PM -0700, Jonathan Nieder wrote:
> > I'd be more interested in the pain of this transition if there was a
> > concrete use case for "hide literally all refs, but still allow
> > fetches". Is that a thing that people do?
>
> Sure, it is a thing that people do. For
The patterns in question do contain a slash, although they don't start
with a slash.
I tried changing it to "!/.vim/colors/*" as you recommended, with no
change in behavior. I even tried adding a leading slash to every
pattern in gitignore, with no effect.
Removing the line with "!/.vim/colors/*"
Stefan Beller wrote:
> On Fri, Sep 2, 2016 at 4:35 PM, Jeff King wrote:
>> I'd be more interested in the pain of this transition if there was a
>> concrete use case for "hide literally all refs, but still allow
>> fetches". Is that a thing that people do?
[...]
> Not to derail the discussion to m
On Fri, Sep 2, 2016 at 4:06 PM, Brian Levinstein wrote:
> The relevant repo is here:
> https://github.com/blevinstein/dotfiles
>
> My gitignore file looks like this:
> https://github.com/blevinstein/dotfiles/blob/2400ca8642a7b454a2bfc54e8402343d008836aa/.gitignore
> It basically ignores all files,
Jeff King wrote:
> On Fri, Sep 02, 2016 at 03:06:12PM -0700, Jonathan Tan wrote:
> But combining hideRefs with
> allowTipSHA1InWant could trigger this case.
Yes.
[...]
> I'd be more interested in the pain of this transition if there was a
> concrete use case for
On Fri, Sep 2, 2016 at 4:35 PM, Jeff King wrote:
> I'd be more interested in the pain of this transition if there was a
> concrete use case for "hide literally all refs, but still allow
> fetches". Is that a thing that people do?
>
Not yet, I would think.
Not to derail the discussion to much, bu
On Fri, Sep 02, 2016 at 03:06:12PM -0700, Jonathan Tan wrote:
> The cause is that, since v3.1.0.201309270735-rc1~22 (Advertise capabilities
> with no refs in upload service., 2013-08-08), JGit's ref advertisement
> includes
> a ref named capabilities^{} to advertise its capabilities on, while git
On Fri, Sep 02, 2016 at 03:11:16PM -0700, Jonathan Tan wrote:
> On 09/02/2016 01:13 PM, Jeff King wrote:
> > On Fri, Sep 02, 2016 at 10:15:39AM -0700, Jonathan Tan wrote:
> > > (git-daemon should probably also be changed to serve zero IDs, but such
> > > a change can be considered independently fr
The relevant repo is here:
https://github.com/blevinstein/dotfiles
My gitignore file looks like this:
https://github.com/blevinstein/dotfiles/blob/2400ca8642a7b454a2bfc54e8402343d008836aa/.gitignore
It basically ignores all files, except for specifically whitelisted
files. However, when I run "git
Jonathan Tan wrote:
> Signed-off-by: Jonathan Tan
> ---
> connect.c| 3 +++
> t/t5512-ls-remote.sh | 39 +++
> 2 files changed, 42 insertions(+)
Reviewed-by: Jonathan Nieder
Thanks.
From: "Robert Dailey"
Suppose I have a branch with 4 commits, in the following order (as you
might see during interactive rebase):
pick 123 Original Change
pick 789 fixup! Original Change
pick 456 Some Other Thing
pick abc fixup! fixup! Original Change
However, let's say the first commit is al
On 09/02/2016 01:13 PM, Jeff King wrote:
On Fri, Sep 02, 2016 at 10:15:39AM -0700, Jonathan Tan wrote:
(git-daemon should probably also be changed to serve zero IDs, but such
a change can be considered independently from this change; even if both
the client and server changes were made in one co
When cloning an empty repository served by standard git, "git clone" produces
the following reassuring message:
$ git clone git://localhost/tmp/empty
Cloning into 'empty'...
warning: You appear to have cloned an empty repository.
Checking connectivity... done.
Mean
This enables JGIT to be used as a prereq in invocations of
test_expect_success (and other functions) in other test scripts.
Signed-off-by: Jonathan Tan
---
t/t5310-pack-bitmaps.sh | 4
t/test-lib.sh | 4
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/t/t5310-p
Thanks - I've updated the following:
o better patch description as suggested by Jonathan Nieder
o checking for capabilities^{} - all such lines are ignored without any further
checks, similar to the behavior for .have
o minor fix to test_lazy_prereq GIT_DAEMON
o test waits for output of `jgit da
On Wed, Aug 31, 2016 at 10:54:02AM +0200, Johannes Schindelin wrote:
> @@ -43,16 +51,20 @@ static GIT_PATH_FUNC(rebase_path_gpg_sign_opt,
> "rebase-merge/gpg_sign_opt")
> /* We will introduce the 'interactive rebase' mode later */
> static inline int is_rebase_i(const struct replay_opts *opts)
>
On vr, 2016-09-02 at 18:23 +0200, Johannes Schindelin wrote:
> In particular on Windows, where shell scripts are even more expensive
> than on MacOSX or Linux, it makes sense to move a loop that forks
> Git at least once for every line in the todo list into a builtin.
Heh, this was the one thing t
On vr, 2016-09-02 at 18:23 +0200, Johannes Schindelin wrote:
> This is crucial to improve performance on Windows, as the speed is now
> mostly dominated by the SHA-1 transformation (because it spawns a new
> rev-parse process for *every* line, and spawning processes is pretty
> slow from Git for Wi
On Fri, Sep 02, 2016 at 10:15:39AM -0700, Jonathan Tan wrote:
> connect.c, when processing packfiles, treats a zero ID (with
> `capabilities^{}` in place of the refname) as an actual ref instead of a
> placeholder for a capability declaration, contrary to the specification
> in Reference Discovery
On Fri, Sep 2, 2016 at 12:56 PM, Stefan Beller wrote:
> On Fri, Sep 2, 2016 at 12:39 PM, Shawn Pearce wrote:
>> On Fri, Sep 2, 2016 at 10:15 AM, Jonathan Tan
>> wrote:
>>>
>>> + if (is_null_oid(&old_oid)) {
>>> + if (strcmp(name, "capabilities^{}"))
>>
>> Its
When running `git cherry-pick -x`, a blank line would be inserted if a line in
the footer was broken into multiple lines (which is inconsistent with its
behavior if no lines were broken). For example, this command would produce:
---
Sample-field: no blank line below
(cherry picked from commit ...)
On Fri, Sep 2, 2016 at 12:39 PM, Shawn Pearce wrote:
> On Fri, Sep 2, 2016 at 10:15 AM, Jonathan Tan
> wrote:
>>
>> + if (is_null_oid(&old_oid)) {
>> + if (strcmp(name, "capabilities^{}"))
>
> Its not the zero ID that is special, its the "capabilities^{}" name
Jeff King writes:
> Splitting to single lines means you need to remember to add the matched
> pairs, which might be arbitrarily far apart. That's not really any
> different than dumping the hunk in your editor, but I find there that
> it's easy to rearrange and group things as appropriate.
My m
On Fri, Sep 2, 2016 at 10:15 AM, Jonathan Tan wrote:
>
> + if (is_null_oid(&old_oid)) {
> + if (strcmp(name, "capabilities^{}"))
Its not the zero ID that is special, its the "capabilities^{}" name
that is special when its the first entry in the stream. In the w
Hi,
Jonathan Tan wrote:
> connect.c, when processing packfiles, treats a zero ID (with
> `capabilities^{}` in place of the refname) as an actual ref instead of a
> placeholder for a capability declaration, contrary to the specification
> in Reference Discovery in Documentation/technical/pack-prot
Suppose I have a branch with 4 commits, in the following order (as you
might see during interactive rebase):
pick 123 Original Change
pick 789 fixup! Original Change
pick 456 Some Other Thing
pick abc fixup! fixup! Original Change
However, let's say the first commit is already pushed upstream on
Below is a simple reproduction of the issue.
The _real_ problem is that this is how our pull request merges work,
they're not allowed to do fast-forward merges. To work around this we
are having to split this up into two pull requests/merges: One that
copies the submodules to the new location and
On Fri, Sep 02, 2016 at 03:36:58PM +0100, Beau Martinez wrote:
> I'd like to inquire as to why `git add -p` can only split hunks so
> much. The limit is too large; why can't you split until each hunk is
> only a line? I often have to run `edit` and split them manually
> myself.
There's some previ
connect.c, when processing packfiles, treats a zero ID (with
`capabilities^{}` in place of the refname) as an actual ref instead of a
placeholder for a capability declaration, contrary to the specification
in Reference Discovery in Documentation/technical/pack-protocol.txt.
This is an issue when in
This enables JGIT to be used as a prereq in invocations of
test_expect_success (and other functions) in other test scripts.
Signed-off-by: Jonathan Tan
---
t/t5310-pack-bitmaps.sh | 4
t/test-lib.sh | 4
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/t/t5310-p
This issue was noticed when trying to clone an empty repository served by a
server that uses the JGit library.
Reference Discovery in Documentation/technical/pack-protocol.txt dictates that
servers should send a zero ID when there are no refs in the queried repository,
and implementations like JGi
On vr, 2016-09-02 at 16:22 +0200, Johannes Schindelin wrote:
> I hope this clarifies why I am not so concerned about some issues
> such as translation, or commit messages, or grammar, and more so
> about others, such as incorrect code.
It does, thanks!
D.
Johannes Schindelin writes:
> Hi Ævar,
>
> On Fri, 2 Sep 2016, Ævar Arnfjörð Bjarmason wrote:
>
>> On Wed, Aug 31, 2016 at 5:05 PM, Johannes Schindelin
>> wrote:
>>
>> > The biggest problem with Strawberry Perl is that it is virtually
>> > impossible to build the Subversion-Perl bindings using t
This patch series reimplements the expensive pre- and post-processing of
the todo script in C.
And it concludes the work I did to accelerate rebase -i.
Johannes Schindelin (9):
rebase -i: generate the script via rebase--helper
rebase -i: remove useless indentation
rebase -i: do not invent
This is crucial to improve performance on Windows, as the speed is now
mostly dominated by the SHA-1 transformation (because it spawns a new
rev-parse process for *every* line, and spawning processes is pretty
slow from Git for Windows' MSYS2 Bash).
Signed-off-by: Johannes Schindelin
---
builtin
In particular on Windows, where shell scripts are even more expensive
than on MacOSX or Linux, it makes sense to move a loop that forks
Git at least once for every line in the todo list into a builtin.
Note: The original code did not try to skip unnecessary picks of root
commits but punts instead
The commands used to be indented, and it is nice to look at, but when we
transform the SHA-1s, the indentation is removed. So let's do away with it.
For the moment, at least: when we will use the upcoming rebase--helper
to transform the SHA-1s, we *will* keep the indentation and can
reintroduce it
This operation has quadratic complexity, which is especially painful
on Windows, where shell scripts are *already* slow (mainly due to the
overhead of the POSIX emulation layer).
Let's reimplement this with linear complexity (using a hash map to
match the commits' subject lines) for the common cas
The `git commit --fixup` command unwraps wrapped onelines when
constructing the commit message, without wrapping the result.
We need to make sure that `git rebase --autosquash` keeps handling such
cases correctly, in particular since we are about to move the autosquash
handling into the rebase--he
To avoid problems with short SHA-1s that become non-unique during the
rebase, we rewrite the todo script with short/long SHA-1s before and
after letting the user edit the script. Since SHA-1s are not intuitive
for humans, rebase -i also provides the onelines (commit message
subjects) in the script,
These tests were a bit anal about the *exact* warning/error message
printed by git rebase. But those messages are intended for the *end
user*, therefore it does not make sense to test so rigidly for the
*exact* wording.
In the following, we will reimplement the missing commits check in
the sequenc
In particular on Windows, where shell scripts are even more expensive
than on MacOSX or Linux, it makes sense to move a loop that forks
Git at least once for every line in the todo list into a builtin.
Signed-off-by: Johannes Schindelin
---
builtin/rebase--helper.c | 7 +-
git-rebase--intera
The first step of an interactive rebase is to generate the so-called "todo
script", to be stored in the state directory as "git-rebase-todo" and to
be edited by the user.
Originally, we adjusted the output of `git log ` using a simple
sed script. Over the course of the years, the code became more
Hi git developers and community,
I'd like to inquire as to why `git add -p` can only split hunks so
much. The limit is too large; why can't you split until each hunk is
only a line? I often have to run `edit` and split them manually
myself.
I'd like to contribute a patch to change it, although my
On Fri, Sep 2, 2016 at 11:02 AM, Jeff King wrote:
>
> I'm happy to act as admin. We will need a few things:
>
> - to arrange funding for the stipend. GitHub offered to cover this
> last time, and if we are interested, I can see if this is still the
> case. We can also cover it out of the
Hi Dennis,
On Fri, 2 Sep 2016, Dennis Kaarsemaker wrote:
> On vr, 2016-09-02 at 09:13 +0200, Johannes Schindelin wrote:
>
> > As Git for Windows does not ship with translations (for multiple
> > reasons), it would not be a regression.
>
> I'm confused, how does "git for windows does not ship wi
Hi Kuba,
On Fri, 2 Sep 2016, Jakub Narębski wrote:
> W dniu 29.08.2016 o 10:03, Johannes Schindelin pisze:
>
> > This patch series marks the '4' in the countdown to speed up rebase -i
> > by implementing large parts in C. It is based on the `libify-sequencer`
> > patch series that I submitted l
Hi Junio,
Another update comes, please pull.
The following changes since commit 5b18e70009487bb156cac18546d6f91105338f4c:
A few more fixes before the final 2.10 (2016-08-31 10:21:05 -0700)
are available in the git repository at:
git://github.com/git-l10n/git-po tags/l10n-2.10.0-rnd2.2
for
Hi Ævar,
On Fri, 2 Sep 2016, Ævar Arnfjörð Bjarmason wrote:
> On Wed, Aug 31, 2016 at 5:05 PM, Johannes Schindelin
> wrote:
>
> > The biggest problem with Strawberry Perl is that it is virtually
> > impossible to build the Subversion-Perl bindings using the Git for
> > Windows SDK when using Str
On vr, 2016-09-02 at 09:13 +0200, Johannes Schindelin wrote:
> As Git for Windows does not ship with translations (for multiple
> reasons), it would not be a regression.
I'm confused, how does "git for windows does not ship with
translations" translate to "this is not a regression"? Is this patch
W dniu 29.08.2016 o 10:03, Johannes Schindelin pisze:
> This patch series marks the '4' in the countdown to speed up rebase -i
> by implementing large parts in C. It is based on the `libify-sequencer`
> patch series that I submitted last week.
Which of those got reviewed (and perhaps accepted),
On Wed, Aug 31, 2016 at 5:05 PM, Johannes Schindelin
wrote:
> Hi Ævar,
>
> On Wed, 31 Aug 2016, Ævar Arnfjörð Bjarmason wrote:
>
>> I haven't used it myself (or any Windows thing) but people say good
>> things about http://strawberryperl.com
>
> Ah yes. This comes up frequently. Many a Git for Win
Probably off-topic.
On Fri, Sep 2, 2016 at 2:32 PM, Jeff King wrote:
> As some of you may recall, we signed up to participate in Outreachy for
> the May-August session, but did not end up selecting an intern. The
> original thread with details is here:
>
> http://public-inbox.org/git/2016030822
On Sep 01 2016, Junio C Hamano wrote:
> I think we should.
>
> t1401 expects to be able to, but if you really do it:
>
> $ cd /tmp
> $ git init throwaway
> $ cd throwaway
> $ git symbolic-ref -d HEAD
>
> the setup machinery considers that you are no longer in a working
On Fri, Sep 02, 2016 at 11:01:54AM +0200, Dennis Kaarsemaker wrote:
> Well, 'git init' is a valid operation to run inside an existing repo to
> reinitialize some bits, so we definitely need to not ignore the config
> once we're sure we're not creating a new repo.
Good point, I hadn't considered r
As some of you may recall, we signed up to participate in Outreachy for
the May-August session, but did not end up selecting an intern. The
original thread with details is here:
http://public-inbox.org/git/20160308224625.ga29...@sigill.intra.peff.net/
There's another session that runs from Dece
On vr, 2016-09-02 at 04:04 -0400, Jeff King wrote:
> On Wed, Aug 31, 2016 at 05:32:33PM +0200, Dennis Kaarsemaker wrote:
>
> >
> > >
> > > We may need to do something like turn off the
> > > need_shared_repository_from_config in init-db, since I think it would
> > > not want to ever read from th
On Fri, Sep 02, 2016 at 04:04:16AM -0400, Jeff King wrote:
> So here's the minimal fix that seems to work for me:
>
> diff --git a/builtin/init-db.c b/builtin/init-db.c
> index 3a45f0b..56e7b9a 100644
> --- a/builtin/init-db.c
> +++ b/builtin/init-db.c
I also wonder if "clone" should be doing so
Git's interactive rebase is still implemented as a shell script, despite
its complexity. This implies that it suffers from the portability point
of view, from lack of expressibility, and of course also from
performance. The latter issue is particularly serious on Windows, where
we pay a hefty price
Now that the sequencer learned to process a "normal" interactive rebase,
we use it. The original shell script is still used for "non-normal"
interactive rebases, i.e. when --root or --preserve-merges was passed.
Please note that the --root option (via the $squash_onto variable) needs
special handl
After all of these patch series y'all had to review, this is finally the
one that switches things over.
Please note that it does not (yet) handle the `git rebase -i --root`
invocation; I tried to focus on the common case, and I rarely use --root
myself.
Please note also that --preserve-merges is
On Wed, Aug 31, 2016 at 05:32:33PM +0200, Dennis Kaarsemaker wrote:
> > We may need to do something like turn off the
> > need_shared_repository_from_config in init-db, since I think it would
> > not want to ever read from the default config sources in most of its
> > code-paths (OTOH, it should i
Hi Junio,
On Thu, 1 Sep 2016, Junio C Hamano wrote:
> Hopefully that [patch removing the - suffix] would help making
> Dscho's "what are the failed tests?" logic simpler.
Of course.
It also makes sure that those 2 hours I spent on writing and perfecting
the sed magic were spent in vain... ;-)
Hi Dennis,
On Thu, 1 Sep 2016, Dennis Kaarsemaker wrote:
> /*
> * Note that ordering matters in this enum. Not only must it match the
> * mapping below, it is also divided into several sections that matter.
> * When adding new commands, make sure you add it in the right section.
> */
> enum t
Hi Junio,
On Thu, 1 Sep 2016, Junio C Hamano wrote:
> For those who were not paying attention on the 'master' front during
> this pre-release period [*1*], I have to point out that the scripted
> Porcelain has been updated to lose the Anglo-centric st/nd/rd/th and
> this series would want to get
Hi Dennis,
On Thu, 1 Sep 2016, Dennis Kaarsemaker wrote:
> On do, 2016-09-01 at 17:17 +0200, Johannes Schindelin wrote:
>
> > And I see that the beautiful ordinal computation was given up in favor
> > of a lousy "#1", "#2", "#3", etc (it used to be "1st", "2nd", "3rd"
> > etc).
> >
> > In any ca
78 matches
Mail list logo
