On Mon, Aug 22, 2016 at 08:39:19PM +0200, Jakub Narębski wrote:
> W dniu 21.08.2016 o 16:26, Josh Triplett pisze:
> > On Sun, Aug 21, 2016 at 03:46:36PM +0200, Jakub Narębski wrote:
> >> W dniu 21.08.2016 o 00:50, Josh Triplett pisze:
> >>> Currently, if you have a branch "somebranch" that contains
On Mon, Aug 22, 2016 at 5:28 PM, Stefan Beller wrote:
> On Mon, Aug 22, 2016 at 4:43 PM, Jacob Keller
> wrote:
>
> Bad rebase?
Ya not sure what happened here. Will find out tomorrow.
Thanks,
Jake
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majo
Alfred Perlstein wrote:
> I hadn't anticipated there be to translation between svn props and
> .gitattributes, it sounds a bit messy but possible, that said, is it
> not possible to commit .gitattribute files to the svn repo? Even in
> FreeBSD land such small token files are permitted.
I'm not s
On 8/22/16 8:07 PM, Eric Wong wrote:
Adding Alfred to the Cc:, more below...
Lucian Smith wrote:
I'm attempting to use the git-svn bridge, and am having problems with
line endings on Windows.
The setup is that we have a git repository on github, and I've checked
out a branch on my Windows m
On Mon, Aug 22, 2016 at 08:55:39AM -0700, Brian Henderson wrote:
> Jeff, I love your idea. how's this looking?
Much more readable, IMHO.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vg
Adding Alfred to the Cc:, more below...
Lucian Smith wrote:
> I'm attempting to use the git-svn bridge, and am having problems with
> line endings on Windows.
>
> The setup is that we have a git repository on github, and I've checked
> out a branch on my Windows machine using Tortoise svn. I ma
On Mon, Aug 22, 2016 at 4:43 PM, Jacob Keller wrote:
> From: Jacob Keller
>
> A few suggestions from Stefan in regards to falling back to
> .git/modules/ being a bad idea. I've chosen I think to avoid using
> die() as we just stick with the current path if we can't find its name.
Which makes the
On Mon, Aug 22, 2016 at 11:18:06PM +, Eric Wong wrote:
> > As a bonus, the list_entry() macro lets us place the lru
> > pointers anywhere inside the delta_base_cache_entry struct
> > (as opposed to just casting the pointer, which requires it
> > at the front of the struct). This will be useful
On Mon, Aug 22, 2016 at 4:43 PM, Jacob Keller wrote:
Bad rebase?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
I'm attempting to use the git-svn bridge, and am having problems with
line endings on Windows.
The setup is that we have a git repository on github, and I've checked
out a branch on my Windows machine using Tortoise svn. I make
changes, commit them, and the branch is updated. In general, this
wo
From: Jacob Keller
A future patch will add a new format for displaying the difference of
a submodule. Make it easier by changing how we store the current
selected format. Replace the DIFF_OPT flag with an enumeration, as each
format will be mutually exclusive.
Signed-off-by: Jacob Keller
---
d
From: Jacob Keller
Since we're going to be changing this function in a future patch, lets
go ahead and convert this to use object_id now.
Signed-off-by: Jacob Keller
---
diff.c | 2 +-
submodule.c | 16
submodule.h | 2 +-
3 files changed, 10 insertions(+), 10 deletions
From: Jacob Keller
Teach git-diff and friends a new format for displaying the difference
of a submodule. The new format is an inline diff of the contents of the
submodule between the commit range of the update. This allows the user
to see the actual code change caused by a submodule update.
Add
From: Jacob Keller
Similar to is_null_oid(), and is_empty_blob_sha1() add an
empty_tree_oid along with helper function is_empty_tree_oid(). For
completeness, also add an "is_empty_tree_sha1()",
"is_empty_blob_sha1()", "is_empty_tree_oid()" and "is_empty_blob_oid()"
helpers.
To ensure we only get
From: Jacob Keller
Currently, do_submodule_path will attempt locating the .git directory by
using read_gitfile on /.git. If this fails it just assumes the
/.git is actually a git directory.
This is good because it allows for handling submodules which were cloned
in a regular manner first before
From: Junio C Hamano
"diff/log --stat" has a logic that determines the display columns
available for the diffstat part of the output and apportions it for
pathnames and diffstat graph automatically.
5e71a84a (Add output_prefix_length to diff_options, 2012-04-16)
added the output_prefix_length fi
From: Jacob Keller
A future patch is going to add a new submodule diff format which
displays an inline diff of the submodule changes. To make this easier,
and to ensure that both submodule diff formats use the same initial
header, factor out show_submodule_header() function which will print the
c
From: Jacob Keller
Add an extension to git-diff and git-log (and any other graph-aware
displayable output) such that "--line-prefix=" will print the
additional line-prefix on every line of output.
To make this work, we have to fix a few bugs in the graph API that force
graph_show_commit_msg to b
From: Jacob Keller
A few suggestions from Stefan in regards to falling back to
.git/modules/ being a bad idea. I've chosen I think to avoid using
die() as we just stick with the current path if we can't find its name.
I think this should be safe since we already do this today. The new flow
only c
From: Junio C Hamano
Signed-off-by: Junio C Hamano
---
Documentation/RelNotes/2.10.0.txt | 31 +++
GIT-VERSION-GEN | 2 +-
2 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/Documentation/RelNotes/2.10.0.txt
b/Documentation/RelNotes/2.
Jeff King wrote:
> We keep an LRU list of entries for when we need to drop
> something from an over-full cache. The list is implemented
> as a circular doubly-linked list, which is exactly what
> list.h provides. We can save a few lines by using the list.h
> macros and functions. More importantly,
Johannes Schindelin wrote:
> On Fri, 19 Aug 2016, Eric Wong wrote:
> > Johannes Schindelin wrote:
> > > On Thu, 18 Aug 2016, Eric Wong wrote:
> > > > Johannes Schindelin wrote:
> > > >
> > > > > Old dogs claim the mail list-approach works for them. Nope.
> > > > > Doesn't. Else you would not ha
This just shows off the improvements done by the last few
patches, and gives us a baseline for noticing regressions in
the future. Here are the results with linux.git as the perf
"large repo":
TestoriginHEAD
--
Sorry if I'm dropping in at the wrong point (this is one I'd bookmarked)..
From: "Duy Nguyen"
Sent: Wednesday, July 20, 2016 3:44 PM
On Wed, Jul 20, 2016 at 2:28 PM, Johannes Schindelin
wrote:
But that strategy *still* ignores the distributed nature of Git. Just
because *you* make that merg
The fundamental data structure of the delta base cache is a
hash table mapping pairs of "(packfile, offset)" into
structs containing the actual object data. The hash table
implementation dates back to e5e0161 (Implement a simple
delta_base cache, 2007-03-17), and uses a fixed-size table.
The curren
We keep an LRU list of entries for when we need to drop
something from an over-full cache. The list is implemented
as a circular doubly-linked list, which is exactly what
list.h provides. We can save a few lines by using the list.h
macros and functions. More importantly, this makes the code
easier
When the delta base cache runs out of allowed memory, it has
to drop entries. It does so by walking an LRU list, dropping
objects until we are under the memory limit. But we actually
walk the list twice: once to drop blobs, and then again to
drop other objects (which are generally trees). This come
This function drops an entry entirely from the cache,
meaning that aside from the freeing of the buffer, it is
exactly equivalent to detach_delta_base_cache_entry(). Let's
build on top of the detach function, which shortens the code
and will make it simpler when we change out the underlying
storage
There is only one caller of cache_or_unpack_entry() and it
always passes 1 for the keep_cache parameter. We can
simplify it by dropping the "!keep_cache" case.
Another call, which did pass 0, was dropped in abe601b
(sha1_file: remove recursion in unpack_entry, 2013-03-27),
as unpack_entry() now do
The delta base cache entries are stored in a fixed-length
hash table. So the way to remove an entry is to "clear" the
slot in the table, and that is what this function does.
However, the name is a leaky abstraction. If we were to
change the hash table implementation, it would no longer be
about "c
After the experiments I did with --depth=50 recently, I noticed there
seemed to be a lot of room for improvement in the delta-base-cache (and
in particular, there seemed to be a lack of actual numbers).
So I tried a series of experiments, and these are the tweaks I came up
with. There are a lot of
From: "Duy Nguyen"
On Mon, Aug 22, 2016 at 8:06 PM, Johannes Schindelin
wrote:
My point stands. We are way more uninviting to contributors than
necessary. And a huge part of the problem is that we require contributors
to send their patches inlined into whitespace-preserving mails.
We probabl
On 22 August 2016 at 20:16, Josh Triplett wrote:
> On Mon, Aug 22, 2016 at 07:36:31PM +0100, Richard wrote:
>> On 21 Aug 2016 15:07, "Josh Triplett" wrote:
>> > I'd like to see it work more automatically than that. Perhaps a
>> > separate environment variable to set the client-side namespace?
>>
On Fri, Aug 19, 2016 at 09:55:54AM -0700, Stefan Beller wrote:
> It was not my intend to start this discussion again with my initial email.
> I rather wanted to point out how I make progress in doing my own
> tooling.
>
> I mean if email works well for Junio (both as a maintainer as
> well as a c
On Mon, Aug 22, 2016 at 07:36:31PM +0100, Richard wrote:
> On 21 Aug 2016 15:07, "Josh Triplett" wrote:
> > I'd like to see it work more automatically than that. Perhaps a
> > separate environment variable to set the client-side namespace?
>
> How about a config option? That could be set globall
W dniu 21.08.2016 o 17:19, n...@dad.org pisze:
> I am learning how to use git. I would like to know:
>
> How can I correct a typo in the message I gave to an old "git commit"? I see
> that the typo occurs in exactly two files in .git:
>
> .git/logs/refs/heads/master
> .git/logs/HEAD
>
> /usr/bi
On Mon, Aug 22, 2016 at 11:42:52AM -0700, David Glasser wrote:
> In addition to describing the `git config` command, git-config(1) also
> appears to be where the algorithm for determining the active
> configuration values is documented, in the FILES and ENVIRONMENT
> sections. (There is minimal d
In addition to describing the `git config` command, git-config(1) also
appears to be where the algorithm for determining the active
configuration values is documented, in the FILES and ENVIRONMENT
sections. (There is minimal documentation of these files and
environment variables in git(1).)
Howev
W dniu 21.08.2016 o 16:26, Josh Triplett pisze:
> On Sun, Aug 21, 2016 at 03:46:36PM +0200, Jakub Narębski wrote:
>> W dniu 21.08.2016 o 00:50, Josh Triplett pisze:
>>> Currently, if you have a branch "somebranch" that contains a gitlink
>>> "somecommit", you can write "somebranch:somecommit" to re
On Aug 21 2016, Eric Wong wrote:
> Nikolaus Rath wrote:
>> What's the easiest way to find the most recent revision (of any file in
>> the repository, including those that have been deleted in the current
>> HEAD) that contains a given string?
>
> I normally do something like:
>
> git log -r
W dniu 22.08.2016 o 15:18, Johannes Schindelin pisze:
> So unfortunately this thread has devolved. Which is sad. Because all I
> wanted is to have a change in Git's submission process that would not
> exclude *so many* developers. That is really all I care about. Not about
> tools. Not about open
Johannes Schindelin wrote:
> As Eric Wong pointed out, we need to be careful to handle the case where
> the Linux headers used to compile Git support O_CLOEXEC but the Linux
> kernel used to run Git does not: it returns an EINVAL.
> +++ b/git-compat-util.h
> @@ -667,6 +667,10 @@ void *gitmemmem(c
On Fri, Aug 19, 2016 at 11:16 PM, Jacob Keller wrote:
>>
>>> + if (submodule_config)
>>> + strbuf_git_path(buf, "%s/%s", "modules",
>>> + submodule_config->name);
>>> + else
>>
>> I do not think we want to assu
git branch -vv will show "gone" next to a remote tracking branch if it
does not exist. for-each-ref is suitable for parsing but had no way of
showing this information.
This introduces "%(upstream:gone)" to display "gone" in the formatted
output if the ref does not exist or an empty string otherwis
On 19.08.16 17:00, Johannes Schindelin wrote:
> Hi Torsten,
>
> On Fri, 19 Aug 2016, Torsten Bögershausen wrote:
>
>> On Thu, Aug 18, 2016 at 02:46:17PM +0200, Johannes Schindelin wrote:
>>
>>> +--filters::
>>> + Show the content as transformed by the filters configured in
>> Minor comment:
>> s/
Jeff, I love your idea. how's this looking?
Junio, I wasn't meaning to be stubborn, although definitely a fault of mine. I
understand a lot better now, thanks for your patience.
---
contrib/diff-highlight/Makefile | 5 +
contrib/diff-highlight/t/Makefile| 22 +
On Thu, Aug 18, 2016 at 3:37 PM, Johannes Schindelin
wrote:
> Hi Junio,
>
> On Wed, 17 Aug 2016, Junio C Hamano wrote:
>
>> Johannes Schindelin writes:
>>
>> >> And then your "git cat-file" patch can be upstreamed with the option
>> >> renamed to (or with an additional synonym) "--filters", which
Hi Stefan,
On Fri, 19 Aug 2016, Stefan Beller wrote:
> >> I see a choice of mail client as no different than a choice of text
> >> editor. Neither my mail client or text editor is heavily customized.
> >> The key feature I rely on from both tools is piping data to external
> >> commands.
> >
> >
On Mon, Aug 22, 2016 at 8:22 PM, Matthieu Moy
wrote:
>>> I think the syntax should be design to allow arbitrary boolean
>>> expression later if needed.
>>
>> I would be against that. We may extend it more in future, but it
>> should be under control, not full boolean expressions.
>
> Why?
>
> I'm
Hi Eric,
On Fri, 19 Aug 2016, Eric Wong wrote:
> Johannes Schindelin wrote:
> > On Thu, 18 Aug 2016, Eric Wong wrote:
> > > Johannes Schindelin wrote:
> > >
> > > > Old dogs claim the mail list-approach works for them. Nope.
> > > > Doesn't. Else you would not have written all those custom
> >
On Mon, Aug 22, 2016 at 8:06 PM, Johannes Schindelin
wrote:
> My point stands. We are way more uninviting to contributors than
> necessary. And a huge part of the problem is that we require contributors
> to send their patches inlined into whitespace-preserving mails.
We probably can settle this
Duy Nguyen writes:
> On Mon, Aug 22, 2016 at 7:59 PM, Matthieu Moy
> wrote:
>> Duy Nguyen writes:
>>
>>> On Sun, Aug 21, 2016 at 4:08 AM, Jakub Narębski wrote:
W dniu 19.08.2016 o 15:54, Jeff King pisze:
> On Sat, Aug 13, 2016 at 03:40:59PM +0700, Duy Nguyen wrote:
>
>> Ping..
On Mon, Aug 22, 2016 at 7:59 PM, Matthieu Moy
wrote:
> Duy Nguyen writes:
>
>> On Sun, Aug 21, 2016 at 4:08 AM, Jakub Narębski wrote:
>>> W dniu 19.08.2016 o 15:54, Jeff King pisze:
On Sat, Aug 13, 2016 at 03:40:59PM +0700, Duy Nguyen wrote:
> Ping..
There was some discus
Hi Peff,
On Fri, 19 Aug 2016, Jeff King wrote:
> On Thu, Aug 18, 2016 at 02:42:34PM +0200, Johannes Schindelin wrote:
>
> > BTW I take this thread as yet another proof that people are unhappy
> > with mail list-based review: if you have to build *that much* tooling
> > around it (and Peff & Juni
Duy Nguyen writes:
> On Sun, Aug 21, 2016 at 4:08 AM, Jakub Narębski wrote:
>> W dniu 19.08.2016 o 15:54, Jeff King pisze:
>>> On Sat, Aug 13, 2016 at 03:40:59PM +0700, Duy Nguyen wrote:
>>>
Ping..
>>>
>>> There was some discussion after v4. I think the open issues are:
>>>
>>> - the comm
From: Ben Wijen
On Windows, a file cannot be removed unless all file handles to it have
been released. Hence it is particularly important to close handles when
spawning children (which would probably not even know that they hold on
to those handles).
The example chosen for this test is a custom
Hi,
On Fri, 19 Aug 2016, Junio C Hamano wrote:
> Eric Wong writes:
>
> > I'd be more comfortable keeping the EINVAL check that got
> > snipped in your reply. O_CLOEXEC can be defined to non-zero in
> > new userspace headers, but an older kernel chokes on it with
> > EINVAL.
>
> Good point. T
This issue was originally reported and fixed in
https://github.com/git-for-windows/git/pull/755
The problem is that file handles to temporary files (such as
index.lock) were inherited by spawned processes. If those spawned
processes do not exit before the parent process wants to delete or
rename t
From: Ben Wijen
When the index is locked and child processes inherit the handle to
said lock and the parent process wants to remove the lock before the
child process exits, on Windows there is a problem: it won't work
because files cannot be deleted if a process holds a handle on them.
The sympto
On Sun, Aug 21, 2016 at 4:08 AM, Jakub Narębski wrote:
> W dniu 19.08.2016 o 15:54, Jeff King pisze:
>> On Sat, Aug 13, 2016 at 03:40:59PM +0700, Duy Nguyen wrote:
>>
>>> Ping..
>>
>> There was some discussion after v4. I think the open issues are:
>>
>> - the commit message is rather terse (it
This should speed up "git checkout :/long/path/taken/from/diffstat"
because we don't have to walk through the commit graph to see if
"long/path/taken/from/diffstat" exists in any commit message.
This is in the the same spirit as 4db86e8 (Update :/abc ambiguity check
- 2013-01-21), but instead of c
This space is important because the %s could be ":/abc", which makes
the final output "tham chiếu không phải là một cây::/abc".
"cây::/abc" looks like a new fancy form of extended SHA-1 syntax. But
it's not.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
po/vi.po | 2 +-
1 file changed, 1 insertion(+),
"git blame" already parsed generic diff options from the command line
via diff_opt_parse(), but instead of passing the resulting xdl_opts to
xdi_diff(), it sent its own xdl_opts, which only reflected the values of
the self-parsed options "-w" and "--minimal". Instead, rely on
diff_opt_parse() to pa
There is no reason for it to take an array and two indexes as argument,
as it only accesses two elements of the array.
Signed-off-by: Michael Haggerty
---
xdiff/xdiffi.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/xdiff/xdiffi.c b/xdiff/xdiffi.c
index ed2df
The idea of xdl_change_compact() is fairly simple:
* Proceed through groups of changed lines in the file to be compacted,
keeping track of the corresponding location in the "other" file.
* If possible, slide the group up and down to try to give the most
aesthetically pleasing diff. Whenever i
Some groups of added/deleted lines in diffs can be slid up or down,
because lines at the edges of the group are not unique. Picking good
shifts for such groups is not a matter of correctness but definitely has
a big effect on aesthetics. For example, consider the following two
diffs. The first is w
There is no reason for it to take an array and index as argument, as it
only accesses a single element of the array.
Signed-off-by: Michael Haggerty
---
xdiff/xdiffi.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xdiff/xdiffi.c b/xdiff/xdiffi.c
index 61deed8..ed2df
The code branch used for the compaction heuristic forgot to keep ixo in
sync while the group was shifted. This is certainly wrong, as it causes
the two counters to get out of sync.
I *think* that this bug could also have caused the function to read past
the end of the rchgo array, though I haven't
This is v2 of a patch series to improve the heuristics that `git diff`
and related commands use to position ambiguous blocks of added/deleted
lines. Thanks to Stefan, Jacob, Peff, Junio, and Jakub for their
comments about v1 [1]. This patch series is also available from my
GitHub account [2] as bra
If the changed group of lines can be matched to a group in the other
file, then that positioning should take precedence over the compaction
heuristic.
The old code tried the heuristic unconditionally, which cost redundant
effort and also was broken if the matching code had already shifted the
grou
70 matches
Mail list logo
