Hello Kevin,
Yes, you're right - I didn't commit the change to the .gitignore file,
so that addition is also being stashed.
Thanks
Sam
Sam Partington
Senior Developer
www.whiteoctober.co.uk
Office: +44 (0)1865 920 707
This email message and any attachments are confidential and solely for
the
Sign-off added should be that of the "committer" not that of the
"commit's author".
Use the correct logical variable that identifies the committer.
Signed-off-by: Kaartic Sivaraam
---
This fixes a small issue when trying to do the following with the script
enabled,
$ git commit --amend -s
Hi,
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-30.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 GitHub is
On Wednesday 09 August 2017 12:03 AM, Martin Ågren wrote:
(Also, is this really a refactoring?)
Not quite.
--set-upstream::
- If specified branch does not exist yet or if `--force` has been
- given, acts exactly like `--track`. Otherwise sets up configuration
- like `--tra
The '--set-upstream' option of branch was deprecated in,
b347d06bf branch: deprecate --set-upstream and show help if we
detect possible mistaken use (Thu, 30 Aug 2012 19:23:13 +0200)
It was deprecated for the reasons specified in the commit message of the
referenced commit.
Make 'branch'
On 01/08/2017 11:03, Paolo Bonzini wrote:
> From: Paolo Bonzini
>
> These options are useful to experiment with "git interpret-trailers"
> without having to tinker with .gitconfig (Junio said git should ahve
> done this first and only added configuration afterwards). It can
> be useful in the ca
£1.5 Million Has Been Granted To You As A Donation Visit
www.bbc.co.uk/news/uk-england-19254228 Sendname Address Phone for more info
On 08/07/2017 03:47 AM, Shawn Pearce wrote:
> 6th iteration of the reftable storage format.
Thanks!
> Changes from v5:
> - extensions.refStorage = reftable is used to select this format.
>
> - Log records can be explicitly deleted (for refs/stash).
> - Log records may use Michael Haggerty's chai
Howard Chu wrote:
The primary issue with using LMDB over NFS is with performance. All reads are
performed thru accesses of mapped memory, and in general, NFS implementations
don't cache mmap'd pages. I believe this is a consequence of the fact that
they also can't guarantee cache coherence, so
They don't. In particular, information about commits that are parts of merges
is missing.
Here's an example. There are only two entries listed in 'gitk --all' for a
particular file (sorry, I'd prefer to include a screen sho, but the mailing
list doesn't allow HTML messages).
gitk --all MANIF
Hi Junio,
On Thu, 10 Aug 2017, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > On Wed, 9 Aug 2017, Stefan Beller wrote:
> >
> >> > I am sure that something even better will be possible: a Continuous
> >> > "Integration" that fixes the coding style automatically by using
> >> > `filter
> -Original Message-
> From: Howard Chu [mailto:h...@symas.com]
> Sent: Monday, August 14, 2017 8:31 AM
> To: spea...@spearce.org
> Cc: David Turner ; ava...@gmail.com;
> ben.a...@acegi.com.au; dborow...@google.com; git@vger.kernel.org;
> gits...@pobox.com; mhag...@alum.mit.edu; p...@peff.n
Hi Christoph,
On Fri, 11 Aug 2017, Dr.-Ing. Christoph Cullmann wrote:
> on Windows 64-bit, for a repository having a .pack file > 4GB I get
> during cloning:
The reason is Git's source code that over-uses the `unsigned long`
datatype.
In a nearby-thread, an underappreciated effort by Martin Koe
Am 13.08.2017 um 06:53 schrieb David Adam:
> Hi all,
>
> I think I have a bug in git (tested 2.11.0 on Debian 8, 2.14.1 on OS X and
> 2.14.1.145.gb3622a4 on OS X).
>
> Given a repository with an export-ignore directive for a subdirectory in
> .gitattributes, `git archive` with a pathspec that exc
Jeff King writes:
> On Sat, Aug 12, 2017 at 09:06:18AM +0100, Philip Oakley wrote:
>
>> > > > + progress = start_progress_delay(_("Generating patches"), total, 0,
>> > > > 1);
>> > >
>> > > I don't really have an opinion on a 1 second delay versus 2. I thought
>> > > we used 2 pretty consistent
I do not know if you can do what you want, mostly if you can do what you want
as simply as you might be wanting that you want it, but I guess you could use
this gitk boot command as a _simple_ work around somehow aliased within your
command line configuration:
$ gitk (--all)? $(git log -m --fo
Martin Koegler writes:
> From: Martin Koegler
>
> Signed-off-by: Martin Koegler
> ---
> Applies on top of my size_t series
>
> I'm not sure, if die or error is better.
As there is no fallback when we hit it, die would be sufficient; the
only thing the callers of this helper, or their callers,
Martin Koegler writes:
> From: Martin Koegler
>
> Signed-off-by: Martin Koegler
> ---
> Applies on top of my size_t series
>
> I'm not sure, if die or error is better.
As there is no fallback when we hit it, die would be sufficient; the
only thing the callers of this helper, or their callers,
> Technical description
> =
>
> This patch series adds a new refs backend, stacking on top of the files
> backend,
> based on whether `core.namespace` is set in git config.
Currently there is another Big Thing getting started in in the refs backend.
https://public-inbox.org/gi
On Mon, Aug 14, 2017 at 9:05 AM, Johannes Schindelin
wrote:
> Hi Christoph,
>
> On Fri, 11 Aug 2017, Dr.-Ing. Christoph Cullmann wrote:
>
>> on Windows 64-bit, for a repository having a .pack file > 4GB I get
>> during cloning:
>
> The reason is Git's source code that over-uses the `unsigned long`
Junio C Hamano writes:
> One interesting question is which of these two types we should use
> for the size of objects Git uses.
>
> Most of the "interesting" operations done by Git require that the
> thing is in core as a whole before we can do anything (e.g. compare
> two such things to produc
On Fri, Aug 11, 2017 at 3:49 PM, Jonathan Tan wrote:
> No code in diff.c sets DIFF_SYMBOL_MOVED_LINE except in
> mark_color_as_moved(), so it is redundant to clear it for the current
> line. Therefore, clear it only for previous lines.
Oh that part. I remember debating with myself if I rather wan
On Fri, Aug 11, 2017 at 3:49 PM, Jonathan Tan wrote:
> Currently, MIN_BLOCK_LENGTH is only checked when diff encounters a line
> that does not belong to the current block. In particular, this means
> that MIN_BLOCK_LENGTH is not checked after all lines are encountered.
>
> Perform that check.
Tha
On Fri, Aug 11, 2017 at 3:49 PM, Jonathan Tan wrote:
> When noticing that the current line is not the continuation of the
> current block, but the start of a new one, mark_color_as_moved() does
> not check the length of the current block. Perform that check.
As far as I remember that behavior is
On Fri, Aug 11, 2017 at 5:39 PM, Junio C Hamano wrote:
> Jonathan Tan writes:
>
>> Note that these patches are for "next", depending on the "--color-moved"
>> patches.
>
> As we have finished Git 2.14 cycle, in preparation for the next one,
> the 'next' branch will be rewound and rebuilt early ne
tbo...@web.de writes:
> From: Torsten Bögershausen
>
> When a file had been commited with CRLF and core.autocrlf is true,
> the following does not roundtrip, `git apply` fails:
>
> printf "Added line\r\n" >>file &&
> git diff >patch &&
> git checkout -- . &&
> git apply patch
Should this tweak b
Andreas Heiduk writes:
> `git config --bool xxx.yyy` returns `true` for `[xxx]yyy` but
> `false` for `[xxx]yyy=` or `[xxx]yyy=""`. This is tested in
> t1300-repo-config.sh since 09bc098c2.
>
> Signed-off-by: Andreas Heiduk
> ---
> Documentation/config.txt | 3 ++-
> Documentation/git.txt|
On Mon, Aug 14, 2017 at 1:46 AM, Kaartic Sivaraam
wrote:
> Sign-off added should be that of the "committer" not that of the
> "commit's author".
>
> Use the correct logical variable that identifies the committer.
>
> Signed-off-by: Kaartic Sivaraam
> ---
> This fixes a small issue when trying to
Neither of those two work for me. They don't limit the view to the single file
of interest.
Also, I tried "additional arguments to git log", using "-m --follow". I filled
in the single file of interest in the 'Enter files' section. The error message
was:
Can't parse git log output
Paolo Bonzini writes:
> On 01/08/2017 11:03, Paolo Bonzini wrote:
>> From: Paolo Bonzini
>>
>> These options are useful to experiment with "git interpret-trailers"
>> without having to tinker with .gitconfig (Junio said git should ahve
>> done this first and only added configuration afterwards)
On Fri, Aug 11, 2017 at 1:41 PM, Harry Putnam wrote:
> Stefan Beller writes:
>
>
> [...]
>
>> Ah. Sorry for confusing even more.
>> By pointing out the options for git-diff, I just wanted to point out that
>> such a mechanism ("rename/copy detection") exists.
>
>
> [...]
>
>>> What am I missing?
Kaartic Sivaraam writes:
> Sign-off added should be that of the "committer" not that of the
> "commit's author".
>
> Use the correct logical variable that identifies the committer.
>
> Signed-off-by: Kaartic Sivaraam
> ---
> This fixes a small issue when trying to do the following with the scri
Maybe there is a chance that combining `gitk `git log -m --follow
--pretty=format:%h PATHSPEC`` with typing in _Enter files and directories to
include, one per line:_ any (or maybe all) of the paths the doc had through
history, would do; but /me more pessimistic now.
Uxío Prego
Madiva Soluciones
Junio C Hamano writes:
> Perhaps we may want to replace the calls to progress_delay() with a
> call to a simpler wrapper that does not let the callers give their
> own delay threashold to simplify the API.
... which does not look too bad, but because it makes me wonder if
we even need to make th
Jeff King writes:
> On Thu, Aug 10, 2017 at 11:58:34AM -0700, Stefan Beller wrote:
>
>> On Thu, Aug 10, 2017 at 11:47 AM, Kevin Willford
>> wrote:
>> > String formatting can be a performance issue when there are
>> > hundreds of thousands of trees.
>>
>> When changing this for the sake of perf
Attention My Dear
Your first payment of $5000.00 will be sent today via Western Union.if you
provide the needed information
You are advise to Contact Western Union with your full information to enable
them give
you the Senders Name, Question and Answer to pick up your First $5000
For more
Stefan Beller writes:
> On Mon, Aug 14, 2017 at 9:05 AM, Johannes Schindelin
> wrote:
>> Hi Christoph,
>>
>> On Fri, 11 Aug 2017, Dr.-Ing. Christoph Cullmann wrote:
>>
>>> on Windows 64-bit, for a repository having a .pack file > 4GB I get
>>> during cloning:
>>
>> The reason is Git's source cod
On 14 August 2017 at 10:54, Kaartic Sivaraam
wrote:
> The '--set-upstream' option of branch was deprecated in,
>
> b347d06bf branch: deprecate --set-upstream and show help if we
> detect possible mistaken use (Thu, 30 Aug 2012 19:23:13 +0200)
>
> It was deprecated for the reasons specified
Stefan Beller writes:
> On Fri, Aug 11, 2017 at 1:41 PM, Harry Putnam wrote:
>> Stefan Beller writes:
>>
>>
>> [...]
>>
>>> Ah. Sorry for confusing even more.
>>> By pointing out the options for git-diff, I just wanted to point out that
>>> such a mechanism ("rename/copy detection") exists.
>>
On 14/08/17 18:08, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> One interesting question is which of these two types we should use
>> for the size of objects Git uses.
>>
>> Most of the "interesting" operations done by Git require that the
>> thing is in core as a whole before we can d
Stefan Beller writes:
> On Fri, Aug 11, 2017 at 5:39 PM, Junio C Hamano wrote:
> ...
>> My preference however is to keep sb/diff-color-move topic as-is
>> without replacing and fixing it with incremental updates like these
>> patches.
>
> I would have hoped to not need to reroll that topic.
> Th
Kevin Daudt writes:
> The no_changes function calls the untracked_files function through
> command substitution. untracked_files will return null bytes because it
> runs ls-files with the '-z' option.
>
> Bash since version 4.4 warns about these null bytes. As they are not
> required for the test
On Mon, Aug 14, 2017 at 12:37 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> On Fri, Aug 11, 2017 at 5:39 PM, Junio C Hamano wrote:
>> ...
>>> My preference however is to keep sb/diff-color-move topic as-is
>>> without replacing and fixing it with incremental updates like these
>>> patch
Ramsay Jones writes:
> In a previous comment, I said that (on 32-bit Linux) it was likely
> that an object of > 4GB could not be handled correctly anyway. (more
> likely > 2GB). This was based on the code from (quite some) years ago.
> In particular, before you added the "streaming API". So, mayb
sum(1) is a command for calculating checksums of the contents of files.
It was part of early editions of Unix ("Research Unix", 1972/1973, [1]).
cksum(1) appeared in 4.4BSD (1993) as a replacement [2], and became part
of POSIX.1-2008 [3]. OpenBSD 5.6 (2014) removed sum(1).
We only use sum(1) in t
Kaartic Sivaraam writes:
> The '--set-upstream' option of branch was deprecated in,
>
> b347d06bf branch: deprecate --set-upstream and show help if we
> detect possible mistaken use (Thu, 30 Aug 2012 19:23:13 +0200)
>
> It was deprecated for the reasons specified in the commit message of
Hi René,
On Thu, 10 Aug 2017, René Scharfe wrote:
> If realloc() fails then the original buffer is still valid. Free it
> before exiting the function.
>
> Signed-off-by: Rene Scharfe
The subject had me worried for a second... The realloc() fails so rarely
that I, for one, have never encounter
On Mon, Aug 14, 2017 at 08:31:50PM +0100, Ramsay Jones wrote:
>
>
> On 14/08/17 18:08, Junio C Hamano wrote:
> > Junio C Hamano writes:
> >
> >> One interesting question is which of these two types we should use
> >> for the size of objects Git uses.
> >>
> >> Most of the "interesting" operat
On Mon, Aug 14, 2017 at 12:51:26PM -0700, Junio C Hamano wrote:
> Kevin Daudt writes:
>
> > The no_changes function calls the untracked_files function through
> > command substitution. untracked_files will return null bytes because it
> > runs ls-files with the '-z' option.
> >
> > Bash since ver
René Scharfe writes:
> It's more convenient because it shows differences nicely, it's faster on
> MinGW because we have a special implementation there based only on
> shell-internal commands,...
This made me wonder why we are not using that "faster" one
everywhere, but it turns out that it depen
Kevin Daudt writes:
> On Mon, Aug 14, 2017 at 12:51:26PM -0700, Junio C Hamano wrote:
>> Kevin Daudt writes:
>>
>> > The no_changes function calls the untracked_files function through
>> > command substitution. untracked_files will return null bytes because it
>> > runs ls-files with the '-z' o
On Fri, Aug 11, 2017 at 10:48 AM, Jameson Miller
wrote:
> The set of files listed by "--ignored" changes when different
> values are given to "--untracked-files". If would be nice to
> be able to make the ignored output independent of the untracked
> settings. This patch attempts to do that whil
Changes in v2:
* Changed a couple rules to be more inline with our coding style.
* Added a Makefile build rule to run git-clang-format on the diff of the
working tree to suggest style changes.
I found that the llvm project also has the git-clang-format tool which will
allow for doing formatin
Add the 'style' build rule which will run git-clang-format on the diff
between HEAD and the current worktree. The result is a diff of
suggested changes.
Signed-off-by: Brandon Williams
---
Makefile | 4
1 file changed, 4 insertions(+)
diff --git a/Makefile b/Makefile
index ba4359ef8..acfd
Currently, MIN_BLOCK_LENGTH is only checked when diff encounters a line
that does not belong to the current block. In particular, this means
that MIN_BLOCK_LENGTH is not checked after all lines are encountered.
Perform that check.
Signed-off-by: Jonathan Tan
---
diff.c | 29
The existing documentation states "If there are fewer than 3 adjacent
moved lines, they are not marked up as moved", which is ambiguous as to
whether "adjacent moved lines" must be adjacent both at the source and
at the destination, or be adjacent merely at the source or merely at the
destination.
These patches are on sb/diff-color-move.
Patches 1 and 2 are unchanged.
It was pointed out to me that the documentation for
"--color-moved=zebra" is ambiguous, but could plausibly describe the
current behavior. I still think that the current behavior is confusing,
so I have retained patch 3, but
No code in diff.c sets DIFF_SYMBOL_MOVED_LINE except in
mark_color_as_moved(), so it is redundant to clear it for the current
line. Therefore, clear it only for previous lines.
This makes a refactoring in a subsequent patch easier.
Signed-off-by: Jonathan Tan
---
diff.c | 2 +-
1 file changed,
Add a '.clang-format' file which outlines the git project's coding
style. This can be used with clang-format to auto-format .c and .h
files to conform with git's style.
Signed-off-by: Brandon Williams
---
.clang-format | 165 ++
1 file cha
On 08/14, Brandon Williams wrote:
> Changes in v2:
> * Changed a couple rules to be more inline with our coding style.
> * Added a Makefile build rule to run git-clang-format on the diff of the
>working tree to suggest style changes.
>
> I found that the llvm project also has the git-clang-f
The `no_changes` function calls the `untracked_files` function through
command substitution. `untracked_files` will return null bytes because it
runs ls-files with the '-z' option.
Bash since version 4.4 warns about these null bytes. As they are not
required for the test that is being done, make s
Hi Paolo,
On Thu, 10 Aug 2017, Paolo Ciarrocchi wrote:
> Il 10 ago 2017 11:39 AM, "Johannes Schindelin"
> ha scritto:
>
>
>
> Footnote *1*: It is no secret that I find our patch submission less than
> inviting. Granted, *I* use it. *I* did not have problems entering the
> mailing list. But th
On Mon, Aug 14, 2017 at 2:30 PM, Brandon Williams wrote:
> Add the 'style' build rule which will run git-clang-format on the diff
> between HEAD and the current worktree. The result is a diff of
> suggested changes.
Notes from in-office discussion:
* 'git clang-format --style file -f --extensio
If there is not a pre-commit hook, there is no reason to discard
the index and reread it.
This change checks to presence of a pre-commit hook and then only
discards the index if there was one.
Signed-off-by: Kevin Willford
---
builtin/commit.c | 15 +--
1 file changed, 9 insertions(
On Mon, Aug 14, 2017 at 2:30 PM, Brandon Williams wrote:
> Add a '.clang-format' file which outlines the git project's coding
> style. This can be used with clang-format to auto-format .c and .h
> files to conform with git's style.
>
> Signed-off-by: Brandon Williams
Applying this patch and run
Am 14.08.2017 um 19:53 schrieb Junio C Hamano:
> Andreas Heiduk writes:
>
>> `git config --bool xxx.yyy` returns `true` for `[xxx]yyy` but
>> `false` for `[xxx]yyy=` or `[xxx]yyy=""`. This is tested in
>> t1300-repo-config.sh since 09bc098c2.
>>
>> Signed-off-by: Andreas Heiduk
>> ---
>> Docum
`git config --bool xxx.yyy` returns `true` for `[xxx]yyy` but
`false` for `[xxx]yyy=` or `[xxx]yyy=""`. This is tested in
t1300-repo-config.sh since 09bc098c2.
Signed-off-by: Andreas Heiduk
---
Documentation/config.txt | 10 +-
Documentation/git.txt| 3 ++-
2 files changed, 7 inser
On Mon, Aug 14, 2017 at 03:54:25PM -0600, Kevin Willford wrote:
> If there is not a pre-commit hook, there is no reason to discard
> the index and reread it.
>
> This change checks to presence of a pre-commit hook and then only
> discards the index if there was one.
>
> Signed-off-by: Kevin Will
Andreas Heiduk writes:
>> However, I think this "no value (but still with '=')" is making it
>> more confusing than necessary for two reasons.
> [...]
>
>> I notice that in this Values section (where the boolean:: is the
>> first entry) there is no mention on how to spell a string value.
>
> I
Andreas Heiduk writes:
> `git config --bool xxx.yyy` returns `true` for `[xxx]yyy` but
> `false` for `[xxx]yyy=` or `[xxx]yyy=""`. This is tested in
> t1300-repo-config.sh since 09bc098c2.
>
> Signed-off-by: Andreas Heiduk
> ---
> Documentation/config.txt | 10 +-
> Documentation/git.t
Brandon Williams writes:
> Add the 'style' build rule which will run git-clang-format on the diff
> between HEAD and the current worktree. The result is a diff of
> suggested changes.
>
> Signed-off-by: Brandon Williams
> ---
> Makefile | 4
> 1 file changed, 4 insertions(+)
>
> diff --gi
On Mon, Aug 14, 2017 at 3:25 PM, Junio C Hamano wrote:
> Brandon Williams writes:
>
>> Add the 'style' build rule which will run git-clang-format on the diff
>> between HEAD and the current worktree. The result is a diff of
>> suggested changes.
>>
>> Signed-off-by: Brandon Williams
>> ---
>>
On Mon, Aug 14, 2017 at 11:35:33AM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Perhaps we may want to replace the calls to progress_delay() with a
> > call to a simpler wrapper that does not let the callers give their
> > own delay threashold to simplify the API.
>
> ... which d
Jeff King writes:
> If it's smooth, the (50,1) case is slightly nicer in that it puts the
> progress in front of the user more quickly. I'm not sure if that's
> actually worth pushing an additional decision onto the person writing
> the calling code, though (especially when we are just now puzzli
On Mon, Aug 14, 2017 at 2:31 PM, Jonathan Tan wrote:
> The existing documentation states "If there are fewer than 3 adjacent
> moved lines, they are not marked up as moved", which is ambiguous as to
> whether "adjacent moved lines" must be adjacent both at the source and
> at the destination, or b
On Mon, Aug 14, 2017 at 02:30:45PM -0700, Brandon Williams wrote:
> +# Align escaped newlines as far left as possible
> +# #define A \
> +# int ; \
> +# int b;\
> +# int ;
> +AlignEscapedNewlines: Left
I get:
$ git clang-format-5.0 --style file -p --extensions c,h
YAM
On Mon, Aug 14, 2017 at 06:48:31PM -0400, Jeff King wrote:
> On Mon, Aug 14, 2017 at 02:30:45PM -0700, Brandon Williams wrote:
>
> > +# Align escaped newlines as far left as possible
> > +# #define A \
> > +# int ; \
> > +# int b;\
> > +# int ;
> > +AlignEscapedNewlines: L
Hi.
Is it possible to add an option akin to git-rev-list's '--ignore-missing' to
git-pack-objects?
I use git bundles to (incrementally) backup my repositories. My script inspects
all bundles in the backup and passes their contained refs as excludes to
git-pack-objects to build the pack for the n
On 08/14, Jeff King wrote:
> On Mon, Aug 14, 2017 at 06:48:31PM -0400, Jeff King wrote:
>
> > On Mon, Aug 14, 2017 at 02:30:45PM -0700, Brandon Williams wrote:
> >
> > > +# Align escaped newlines as far left as possible
> > > +# #define A \
> > > +# int ; \
> > > +# int b;\
> > > +#
On Mon, Aug 14, 2017 at 03:28:50PM -0700, Stefan Beller wrote:
> >> +.PHONY: style
> >> +style:
> >> + git clang-format --style file --diff --extensions c,h
> >
> > Did we get "git clang-format" subcommand, or is "s/git //" implied
> > somewhere?
>
> You need to have clang-format installed (d
On Mon, Aug 14, 2017 at 03:54:30PM -0700, Brandon Williams wrote:
> > And removing that gives me a clean output. I have no idea why my clang
> > doesn't like these (but presumably yours does). It's clang-format-5.0 in
> > Debian unstable (and clang-format-3.8, etc).
>
> Those must be features in
On Mon, Aug 14, 2017 at 02:30:44PM -0700, Brandon Williams wrote:
> Changes in v2:
> * Changed a couple rules to be more inline with our coding style.
> * Added a Makefile build rule to run git-clang-format on the diff of the
>working tree to suggest style changes.
>
> I found that the llvm
On Mon, Aug 14, 2017 at 03:42:14PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > If it's smooth, the (50,1) case is slightly nicer in that it puts the
> > progress in front of the user more quickly. I'm not sure if that's
> > actually worth pushing an additional decision onto the person
+ llvm-...@lists.llvm.org
The Git community is currently discussing adopting a coding style
defined by clang-format, here is a bug report:
On Mon, Aug 14, 2017 at 4:06 PM, Jeff King wrote:
>
> One more oddity I found while playing with this that Git folks might run
> into:
>
> $ git init tmp &
Jeff King writes:
> On Mon, Aug 14, 2017 at 03:42:14PM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > If it's smooth, the (50,1) case is slightly nicer in that it puts the
>> > progress in front of the user more quickly. I'm not sure if that's
>> > actually worth pushing an additio
Jeff King writes:
> I suspect the "-p" version is going to be the one people invoke the most
> often. Should it take the coveted "make style" slot, and the diff get
> pushed off to another target?
>
> I was also confused at first that the "-p" version requires you to stage
> the changes first. I
Junio C Hamano writes:
> By the way, I do not know which vintage of /usr/bin/git-clang-format
> I happen to have on my box, but I needed a crude workaround patch
> (attached at the end) ...
I guess you hit the same thing while our messages crossing ;-)
> As to what it does, the first example I
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.
The tip of 'next' has been rebuilt
These patches are on sb/diff-color-move.
Patches 1 and 2 are unchanged.
If we're planning to cook a heuristic, we might as well try a better
one. What do you think of this? A heuristic of number of non-whitespace
characters, applied at the block level, and not dependent on the block's
neighbors.
No code in diff.c sets DIFF_SYMBOL_MOVED_LINE except in
mark_color_as_moved(), so it is redundant to clear it for the current
line. Therefore, clear it only for previous lines.
This makes a refactoring in a subsequent patch easier.
Signed-off-by: Jonathan Tan
---
diff.c | 2 +-
1 file changed,
Currently, MIN_BLOCK_LENGTH is only checked when diff encounters a line
that does not belong to the current block. In particular, this means
that MIN_BLOCK_LENGTH is not checked after all lines are encountered.
Perform that check.
Signed-off-by: Jonathan Tan
---
diff.c | 29
The existing behavior of diff --color-moved=zebra does not define the
minimum size of a block at all, instead relying on a heuristic applied
later to filter out sets of adjacent moved lines that are shorter than 3
lines long. This can be confusing, because a block could thus be colored
as moved at
On 08/14, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > By the way, I do not know which vintage of /usr/bin/git-clang-format
> > I happen to have on my box, but I needed a crude workaround patch
> > (attached at the end) ...
>
> I guess you hit the same thing while our messages crossing ;
On 14/08/17 21:32, Torsten Bögershausen wrote:
> In general, yes.
> I had a patch that allowed a 32 bit linux to commit a file >4GB.
> There is however a restriction: The file must not yet be known to the
> index. Otherwise the "diff" machinery kicks in, and tries to
> compare the "old" and the "
On Wed, Aug 09, 2017 at 07:19:00PM -0400, Jeff King wrote:
> On Wed, Aug 09, 2017 at 03:53:17PM -0700, Stefan Beller wrote:
>
> > >> Right, the reason I stopped pursuing it was that I couldn't find a way
> > >> to have it make suggestions for new code without nagging about existing
> > >> code. If
Hi,
René Scharfe wrote:
> sum(1) is a command for calculating checksums of the contents of files.
> It was part of early editions of Unix ("Research Unix", 1972/1973, [1]).
> cksum(1) appeared in 4.4BSD (1993) as a replacement [2], and became part
> of POSIX.1-2008 [3]. OpenBSD 5.6 (2014) remove
Hi,
brian m. carlson wrote:
>> On Wed, Aug 09, 2017 at 03:53:17PM -0700, Stefan Beller wrote:
>>> We may have different opinions on what is readable/beautiful code.
>>> If we were to follow a mutual agreed style that is produced by a tool,
>>> we could use clean/smudge filters with different sett
On Mon, Aug 14, 2017 at 04:15:40PM -0700, Stefan Beller wrote:
> + llvm-...@lists.llvm.org
>
> The Git community is currently discussing adopting a coding style
> defined by clang-format, here is a bug report:
Since we've added a cc, let me try to give a little more context.
> > One more oddity
On Mon, Aug 14, 2017 at 04:47:45PM -0700, Junio C Hamano wrote:
> > By the way, I do not know which vintage of /usr/bin/git-clang-format
> > I happen to have on my box, but I needed a crude workaround patch
> > (attached at the end) ...
>
> I guess you hit the same thing while our messages crossi
On Mon, Aug 14, 2017 at 4:57 PM, Jonathan Tan wrote:
> The existing behavior of diff --color-moved=zebra does not define the
> minimum size of a block at all, instead relying on a heuristic applied
> later to filter out sets of adjacent moved lines that are shorter than 3
> lines long. This can be
1 - 100 of 107 matches
Mail list logo
