Check that we are configured to display colors in the given context when
the user specifies a format string of `%C(auto)`, instead of always
displaying the default color for the given context. This makes
`%C(auto)` obey the `color=auto` setting and brings its behavior in line
with the behavior of
On Tue, May 24, 2016 at 05:55:02PM -0700, Junio C Hamano wrote:
> Looks obviously the right thing to do from a cursory read.
> Missing sign-off?
Yes, apologies for the oversight; will re-send.
Thanks-
-ed
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message t
the ability to specify that color should be
displayed only when the output is a tty, and to use the default color
for the given context (instead of a hardcoded color value).
Signed-off-by: Edward Thomson
---
pretty.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pretty.c b
command allows users to set a file
executable in a single command that they're already familiar with.
Signed-off-by: Edward Thomson
---
builtin/add.c | 18 +-
cache.h| 2 ++
read-cache.c | 6 ++
t/t3700-add.sh | 19 +++
4 files changed, 44 ins
d as being applicable to
`%C(auto)`.
Signed-off-by: Edward Thomson
Tests from Jeff King.
Signed-off-by: Jeff King
---
pretty.c | 2 +-
t/t6006-rev-list-format.sh | 26 +++---
2 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/pretty.c b/pret
On Wed, May 25, 2016 at 05:39:04PM -0500, Jeff King wrote:
> Looks like we didn't have any tests at all for %C(auto). And the tests
> for %C(auto,...) were labeled as %C(auto), making it all the more
> confusing. Perhaps it is worth squashing this in:
Thanks, peff. Indeed I did squash that into m
On Wed, May 25, 2016 at 12:36:55AM -0700, Junio C Hamano wrote:
>
> At the design level, I have a few comments.
Thanks, I will submit a new patch that incorporates your (and dscho's)
comments.
> * This is about a repository with core.filemode=0; I wonder if
>something for a repository with
On Fri, May 27, 2016 at 11:30:40AM -0700, Junio C Hamano wrote:
>
> Oh, having said all of that, the comments on the implementation
> still stand.
Certainly; sorry for the delay. I've squashed in your tests and applied
your recommendations. Resending the patch momentarily.
Thanks-
-ed
--
To u
27;re already familiar with.
Signed-off-by: Edward Thomson
---
builtin/add.c | 12 +++-
cache.h| 2 ++
read-cache.c | 11 +--
t/t3700-add.sh | 30 ++
4 files changed, 52 insertions(+), 3 deletions(-)
diff --git a/builtin/add.c b/builtin/add.c
On Wed, Jun 01, 2016 at 09:00:34AM -0700, Junio C Hamano wrote:
>
> Unlike the "something like this" we saw earlier, this draws the
> boundary of responsibility between the caller and the API at a much
> more sensible place.
This makes sense to me - Junio, are you taking (or have you already
take
On Sun, Jun 10, 2018 at 09:44:45PM +0200, Clemens Buchacher wrote:
>
> It is safe to do this on Linux file systems, even if open file handles
> still exist, because unlink only removes the directory reference to the
> file. On Windows, however, a file cannot be deleted until all handles to
> it ar
On Tue, Jun 12, 2018 at 09:13:54AM +0300, Orgad Shaneh wrote:
> Some of my colleagues use an ancient version of Source Insight, which also
> locks files for write.
If that application is locking files for writing (that is to say, it did
not specify the `FILE_SHARE_WRITE` bit in the sharing modes d
On Fri, Jul 20, 2018 at 09:52:20PM +, brian m. carlson wrote:
>
> To summarize the discussion that's been had in addition to the above,
> Ævar has also stated a preference for SHA-256 and I would prefer BLAKE2b
> over SHA-256 over SHA3-256, although any of them would be fine.
>
> Are there ot
ll be written to
the current working directory and named using its 40 character object ID,
unless the `-f` option is specified.
-f , --filename
When specified after an object ID, the file written will use this filename.
In addition, any filters (for example: CRLF conversion or Git-LFS) will be
ru
in your repository that were deleted
+# from the working tree.
+#
+# Copyright (c) 2017-2018 Edward Thomson.
+
+set -e
+
+IFS=$'\n'
+
+PROGNAME=$(echo "$0" | sed -e 's/.*\///')
+GIT_DIR=$(git rev-parse --git-dir)
+
+DO_RECOVER=0
+DO_FULL=0
+DO_INTERACTIVE=0
+BLOB
On Sat, Aug 04, 2018 at 08:54:49AM -0700, Junio C Hamano wrote:
>
> My first reaction was to say that I am not going to take a new
> command written only for bash with full bashism, even if it came
> with docs, tests nor Makefile integration, for Git itself. Then I
> reconsidered, as not everythi
On Tue, Aug 28, 2018 at 2:50 PM, Ævar Arnfjörð Bjarmason
wrote:
> If we instead had something like clean/smudge filters:
>
> [extensions]
> objectFilter = sha256-to-sha1
> compatObjectFormat = sha1
> [objectFilter "sha256-to-sha1"]
> clean = ...
> smudge =
Hello-
Microsoft would like to invite the contributors summit to dinner tonight;
it will take place at 8pm:
La Tagliatella (Placa Catalunya)
Ronda de la Universitat, 31
It's conveniently right around the corner from the Beers with Bitbucket
event, in case you're going to that.
Hope to see y
On Mon, Mar 26, 2018 at 2:08 PM, Derrick Stolee wrote:
> Since most heavily-used tools that didn't spawn Git processes use
> LibGit2 to interact with Git repos, I added Ed Thomson to CC to see
> if libgit2 could ever write these bad header comments.
We added the `sorted` capability to our `packed
This talk looks at the basic principles that
support best practice for scripting Git and how to avoid some common
pitfalls.
Building Git Tools with libgit2: Edward Thomson
Edward introduces the libgit2 framework (http://libgit2.org), which is a
portable, implementation of Git as a library. If y
On Tue, Jan 23, 2018 at 7:08 AM, Josh Bleecher Snyder
wrote:
> Looking over your list above, at a minimum, libgit2 might not have a
> particularly good way to represent submodule/file or
> submodule/directory conflicts, because is-a-submodule is defined
> external to a git_index_entry.
libgit2 sh
The libgit2 community is hosting the libgit2 Summit 2018 on March 9th 2018
in Barcelona.
As peff previously announced, Git Merge 2018 is happening in Barcelona on
March 8th (and the Git Contributor's Summit is planned for March 7.) We
will follow the Git Merge event and have our summit on March 9
On Tue, Sep 23, 2014 at 11:47:51AM -0400, Jeff King wrote:
> As far as I can tell, fsck's mode-checking has been totally broken
> basically forever. Which makes me a little nervous to fix it. :)
> linux.git does have some bogus modes, but they are 100664, which is
> specifically ignored here unless
Keep poll's timeout at -1 when uploadpack.keepalive = 0, instead of
setting it to -1000, since some pedantic old systems (eg HP-UX) and
the gnulib compat/poll will treat only -1 as the valid value for
an infinite timeout.
Signed-off-by: Edward Thomson
---
upload-pack.c |4 +++-
1
On Fri, Aug 22, 2014 at 12:03:34PM -0400, Jeff King wrote:
>
> Yeah, I wasn't thinking we would get negative values from the user (we
> don't document them at all), but we should probably do something
> sensible. Let's just leave it at Ed's patch.
Thanks, both. Apologies for the dumb question: i
Junio C Hamano [mailto:gits...@pobox.com] wrote:
> Edward Thomson writes:
>
> > I would propose that we store the data about the file in conflict as
> > it occurred through the renames. For example, in a rename 1->2
> > conflict where A was renamed to both B and
Junio C Hamano [mailto:gits...@pobox.com] wrote:
> Edward Thomson writes:
> > I would propose a new extension, 'CONF', to handle conflict data,
> > differing from the stage >0 entries in the index in that this
> > extension tracks the conflicting file across
Junio C Hamano [mailto:gits...@pobox.com] wrote:
> Edward Thomson writes:
> > I would propose that this not simply track rename conflicts, but all
> > conflicts.
>
> That is a no starter.
So. Can you explain to me why this would be a non starter? Can you suggest
some al
Junio C Hamano [mailto:gits...@pobox.com] wrote:
> We do not gratuitously break existing implementations. If no conflict is
> stored
> as higher-stage index entries in an index that has your index extension, no
> existing implementation can read a conflicted index written by your
> implementation
Junio C Hamano [mailto:gis...@pobox.com] wrote:
> As long as
> the format will be backward compatible to allow existing users use existing
> tools
> to deal with cases the existing tools can handle, then that is OK. I didn't
> get that
> impression which is where my "non starter" came from.
I s
Edward Thomson [ethom...@microsoft.com] wrote:
> Junio C Hamano [mailto:gis...@pobox.com] wrote:
> > * Path A may have only stage #1, while path B and C has only stage
> >#2 and stage #3 (the user would have to notice these three
> >correspond to each other,
Junio C Hamano [mailto:gits...@pobox.com] wrote:
> Edward Thomson writes:
> > Junio, did you have additional thoughts on this?
>
> Not at this moment.
>
> I think we have covered the principles (do not unnecessarily duplicate
> information, do not break existing imple
Hi-
I've been investigating the cases where merge is allowed to proceed when
there are staged changes in the index or unstaged files in the working
directory. There are cases where I find the behavior surprising and I
hope I can get clarification. There are also two cases that I will report
as b
On 2/20/13 2:21 PM, "Junio C Hamano" wrote:
>Both are very much on purpose. The integrator may have seen the
>patch on the list, ran "git apply [--index]" on it to contemplate on
>it, and before commiting the result, saw a pull request for a branch
>that contains the change. The above two allow
When a rename conflict occurs, the information about the conflict is
written to stdout and the index is updated as if the conflict were a
simpler conflict that did not involve renames. This doesn't give a lot of
information to users after the fact - a status of "added in ours" does not
provide a l
Junio C Hamano [mailto:gits...@pobox.com] wrote:
> I do not offhand see anything particularly stupid; a new optional index
> extension
> section CACHE_EXT_RENAME_CONFLICT might be a good addition.
>
> Is "one side moves A to B while the other side moves it to C" the only case,
> or is
> it just
36 matches
Mail list logo
