Re: [ANNOUNCE] Git v2.9.1

On Thu, Jul 14, 2016 at 9:38 AM, Lars Schneider wrote: > > On 13 Jul 2016, at 22:43, Junio C Hamano wrote: > >> Junio C Hamano writes: >> >>> It is somewhat disturbing that nobody seems to be regularly building >>> on 32-bit

Re: Plugin mechanism(s) for Git?

On Fri, Jul 15, 2016 at 11:28 PM, Eric Wong wrote: > Konstantin Khomoutov wrote: >> Ben Peart wrote: >> > > Lars Schneider wrote: >> > > >> > > We could dynamically load libraries but this would force us to >> > > freeze the ABI as

Re: [PATCH] contrib/persistent-https: update ldflags syntax for Go 1.7+

[+cc Shawn, who participated in the original discussion, as I don't think Colby really works on git any more] On Fri, Jul 15, 2016 at 01:44:14PM -0700, Parker Moore wrote: > From: Parker Moore > > This fixes contrib/persistent-https builds for Go v1.7+ and is >

[PATCH v4 2/4] test-lib.sh: introduce and use $EMPTY_BLOB

Similar to $EMPTY_TREE this makes it easier to recognize this special SHA-1 and change hash later. Signed-off-by: Nguyễn Thái Ngọc Duy --- t/t1011-read-tree-sparse-checkout.sh | 8 t/t1700-split-index.sh | 24

[PATCH v4 4/4] cache-tree: do not generate empty trees as a result of all i-t-a subentries

If a subdirectory contains nothing but i-t-a entries, we generate an empty tree object and add it to its parent tree. Which is wrong. Such a subdirectory should not be added. Note that this has a cascading effect. If subdir 'a/b/c' contains nothing but i-t-a entries, we ignore it. But then if

[PATCH v4 0/4] cache-tree building fix in the presence of ita entries

v4 removes the leading underscore from _EMPTY_BLOB and _EMPTY_TREE and updates 4/4 slightly like this. diff --git a/cache-tree.c b/cache-tree.c index 2d50640..f28b1f4 100644 --- a/cache-tree.c +++ b/cache-tree.c @@ -325,6 +325,7 @@ static int update_one(struct cache_tree *it,

[PATCH v4 1/4] test-lib.sh: introduce and use $EMPTY_TREE

This is a special SHA1. Let's keep it at one place, easier to replace later when the hash change comes, easier to recognize. Signed-off-by: Nguyễn Thái Ngọc Duy --- t/t-basic.sh| 2 +- t/t1100-commit-tree-options.sh | 2 +- t/t4010-diff-pathspec.sh

[PATCH v4 3/4] cache-tree.c: fix i-t-a entry skipping directory updates sometimes

Commit 3cf773e (cache-tree: fix writing cache-tree when CE_REMOVE is present - 2012-12-16) skips i-t-a entries when building trees objects from the index. Unfortunately it may skip too much. The code in question checks if an entry is an i-t-a one, then no tree entry will be written. But it does

Re: obsolete index in wt_status_print after pre-commit hook runs

Am 15.07.2016 um 6:03 nachm. schrieb Junio C Hamano : > Junio C Hamano writes: >> On Fri, Jul 15, 2016 at 1:30 PM, Andrew Keller wrote: >>> Am 15.07.2016 um 12:34 nachm. schrieb Andrew Keller : >>> I pulled

Re: obsolete index in wt_status_print after pre-commit hook runs

Am 15.07.2016 um 5:19 nachm. schrieb Junio C Hamano : > > On Fri, Jul 15, 2016 at 1:30 PM, Andrew Keller wrote: >> Am 15.07.2016 um 12:34 nachm. schrieb Andrew Keller : >> >>> I pulled out the source for version 2.9.1 and briefly

Re: [PATCH 05/12] check_connected: relay errors to alternate descriptor

On Fri, Jul 15, 2016 at 11:19:23AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > + /* > > +* If non-zero, send error messages to this descriptor rather > > +* than stderr. The descriptor is closed before check_connected > > +* returns. > > +*/ > > +

Re: [PATCH 04/12] check_everything_connected: use a struct with named options

On Fri, Jul 15, 2016 at 11:13:40AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > The number of variants of check_everything_connected has > > grown over the years, so that the "real" function takes > > several possibly-zero, possibly-NULL arguments. We hid the > >

Re: [PATCH 02/12] rev-list: add optional progress reporting

On Fri, Jul 15, 2016 at 11:00:52AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > diff --git a/builtin/rev-list.c b/builtin/rev-list.c > > index b82bcc3..88d95a7 100644 > > --- a/builtin/rev-list.c > > +++ b/builtin/rev-list.c > > @@ -9,6 +9,7 @@ > > #include

[PATCH v3 1/2] blame: Allow to blame paths freshly added to the index

When blaming files, changes in the work tree are taken into account and displayed as being "Not Committed Yet". However, when blaming a file that is not known to the current HEAD, git blame fails with `no such path 'foo' in HEAD`, even when the file was git add'ed. This would seem uninteresting

[PATCH v3 2/2] t/t8003-blame-corner-cases.sh: Use here documents

Somehow, this test was using: { echo A echo B } > file block to feed file contents. This changes those to the form most common in git test scripts: cat >file <<-\EOF A B EOF Signed-off-by: Mike Hommey --- t/t8003-blame-corner-cases.sh | 34

Re: [PATCH] blame: Allow to blame paths freshly added to the index

> I suspect that this would be useful without copy detection. If you > "git mv fileA fileB" (optionally followed by "edit fileB"), fileB > would not be in HEAD but you should be able to trace the lineage of > the lines in it back through the renaming event, and this change > also allows that use

Re: obsolete index in wt_status_print after pre-commit hook runs

Junio C Hamano writes: > On Fri, Jul 15, 2016 at 1:30 PM, Andrew Keller wrote: >> Am 15.07.2016 um 12:34 nachm. schrieb Andrew Keller : >> >>> I pulled out the source for version 2.9.1 and briefly skimmed how >>> run_commit and

Re: Plugin mechanism(s) for Git?

Konstantin Khomoutov wrote: > Ben Peart wrote: > > > Lars Schneider wrote: > > > > > > We could dynamically load libraries but this would force us to > > > freeze the ABI as mentioned by Duy: > > >

[ANNOUNCE] Git v2.9.2

The latest maintenance release Git v2.9.2 is now available at the usual places. This is only a fix to the test suite; there is no change in the actual code produced for your daily use of Git. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public

Re: obsolete index in wt_status_print after pre-commit hook runs

On Fri, Jul 15, 2016 at 1:30 PM, Andrew Keller wrote: > Am 15.07.2016 um 12:34 nachm. schrieb Andrew Keller : > >> I pulled out the source for version 2.9.1 and briefly skimmed how run_commit >> and >> prepare_to_commit work. It seems that Git

Re: [PATCH] blame: Allow to blame paths freshly added to the index

Junio C Hamano writes: > I suspect that the above change needs to be updated further if the > user wants to run "blame path" during a conflicted renaming merge, > i.e. > > 0. Before two histories diverged, there was old_path. > 1. Our side updated contents of that file and

Re: [PATCH] blame: Allow to blame paths freshly added to the index

Mike Hommey writes: > When blaming files, changes in the work tree are taken into account > and displayed as being "Not Committed Yet". > > However, when blaming a file that is not known to the current HEAD, > git blame fails with `no such path 'foo' in HEAD`, even when the

[PATCH] contrib/persistent-https: update ldflags syntax for Go 1.7+

From: Parker Moore This fixes contrib/persistent-https builds for Go v1.7+ and is compatible with Go v1.5+. Running `make all` in `contrib/persistent-https` results in a failure on Go 1.7 and above. Specifically, the error is: go build -o git-remote-persistent-https

Re: [PATCH] git-clean: remove fifo, devices, socket files

Am 15.07.2016 um 09:46 schrieb Andrey Vagin: On Thu, Jul 14, 2016 at 10:56 PM, Johannes Sixt wrote: IOW: These special files are invisible for Git unless it already knows the names. The latter case is outside 'git clean's domain, and the former case really means that special

Re: obsolete index in wt_status_print after pre-commit hook runs

Am 15.07.2016 um 12:34 nachm. schrieb Andrew Keller : > I pulled out the source for version 2.9.1 and briefly skimmed how run_commit > and > prepare_to_commit work. It seems that Git already understands that a > pre-commit > hook can change the index, and it rereads the

Re: [PATCH 12/12] receive-pack: send keepalives during quiet periods

Jeff King writes: > diff --git a/builtin/index-pack.c b/builtin/index-pack.c > index 1cba120..54f2cfb 100644 > --- a/builtin/index-pack.c > +++ b/builtin/index-pack.c > @@ -1626,6 +1626,7 @@ int cmd_index_pack(int argc, const char **argv, const > char *prefix) > struct

[StGit PATCH] contrib/vim: Fix filetype detection in VIM >=7.4

The command "setfiletype" will not override an existing filetype. This was never a problem for me previously, but since upgrading from VIM 7.3 to 7.4 the filetype for StGit's files is explicitly set to "text", preventing the stgit ftdetect plugin overriding it. Use "setlocal filetype=" instead to

[SOLVED] Re: Two consecutive clones of a remote produces different files

Hi Jeff. Hmmm. You are the master of blind guessing - spot on. Also, that is kind of embaressing to me. However, should your way cross mine, you hereby have a voucer for a drink after your choice as long as it is beer. Thanks, Morten. > Just a blind guess, but might you have two files with

Re: [PATCH 05/12] check_connected: relay errors to alternate descriptor

Jeff King writes: > + /* > + * If non-zero, send error messages to this descriptor rather > + * than stderr. The descriptor is closed before check_connected > + * returns. > + */ > + int err_fd; Theoretically speaking it may be possible that a caller

Re: [PATCH 04/12] check_everything_connected: use a struct with named options

Jeff King writes: > The number of variants of check_everything_connected has > grown over the years, so that the "real" function takes > several possibly-zero, possibly-NULL arguments. We hid the > complexity behind some wrapper functions, but this doesn't > scale well when we

Re: [PATCH 02/12] rev-list: add optional progress reporting

Jeff King writes: > diff --git a/builtin/rev-list.c b/builtin/rev-list.c > index b82bcc3..88d95a7 100644 > --- a/builtin/rev-list.c > +++ b/builtin/rev-list.c > @@ -9,6 +9,7 @@ > #include "log-tree.h" > #include "graph.h" > #include "bisect.h" > +#include "progress.h" > >

Re: obsolete index in wt_status_print after pre-commit hook runs

On 15.07.2016, at 1:28 nachm., Junio C Hamano wrote: > Earlier you said you are working on a patch series. Since you have > already looked at the codepath already, perhaps you may want to try > a patch series to add the missing error-return instead, if you are > interested?

Re: obsolete index in wt_status_print after pre-commit hook runs

Andrew Keller writes: > On 15.07.2016, at 1:02 nachm., Junio C Hamano wrote: > >> Expected outcome is an error saying "do not modify the index inside >> pre-commit hook", and a rejection. It was meant as a verification >> mechansim (hence it can be

Re: [PATCH 12/12] receive-pack: send keepalives during quiet periods

On Fri, Jul 15, 2016 at 3:43 AM, Jeff King wrote: > > Signed-off-by: Jeff King Read-entirely-by Stefan ;) Thanks! > @@ -319,10 +331,60 @@ static void rp_error(const char *err, ...) > static int copy_to_sideband(int in, int out, void *arg) > { > char

Re: obsolete index in wt_status_print after pre-commit hook runs

On 15.07.2016, at 1:02 nachm., Junio C Hamano wrote: > Expected outcome is an error saying "do not modify the index inside > pre-commit hook", and a rejection. It was meant as a verification > mechansim (hence it can be bypassed with --no-verify), not as a way > to make

Re: [PATCH 2/1] Verify that --cherry-pick avoids looking at full diffs

Johannes Schindelin writes: > The entire point of the previous patch was to make sure that we look at > abbreviated patch IDs (using the diff *headers* only, but avoiding > to load the blobs into memory and diff them) first, and only look at > full patch IDs when the

Re: obsolete index in wt_status_print after pre-commit hook runs

Andrew Keller writes: > I have observed an interesting scenario. Here are example reproduction steps: > > 1. new repository > 2. create new pre-commit hook that invokes `git mv one two` > 3. touch one > 4. git add one > 5. git commit > > Expected outcome: In the

Re: Plugin mechanism(s) for Git?

On Fri, 15 Jul 2016 16:18:28 + (UTC) Ben Peart wrote: > > Thanks for this great summary of the problem, Christian! > > > > I think a generic plugin mechanism would be great but how would we > > do it? > > I’m also very glad to see the discussion about coming up with a

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

Johannes Schindelin writes: > So what are your plans with 2.9.2? I ask because I do not want to engineer > a 2.9.1 release just to see that 2.9.2 is out and having to spend the same > amount of time for another release ;-) Essentially unchanged from what I said in

obsolete index in wt_status_print after pre-commit hook runs

Hi everyone, I have observed an interesting scenario. Here are example reproduction steps: 1. new repository 2. create new pre-commit hook that invokes `git mv one two` 3. touch one 4. git add one 5. git commit Expected outcome: In the commit message template, I expect to see “Changes to be

Re: Plugin mechanism(s) for Git?

Lars Schneider gmail.com> writes: > > Thanks for this great summary of the problem, Christian! > > I think a generic plugin mechanism would be great but how would we do it? I’m also very glad to see the discussion about coming up with a good pattern for how git can interact with external

[PATCH 2/1] Verify that --cherry-pick avoids looking at full diffs

The entire point of the previous patch was to make sure that we look at abbreviated patch IDs (using the diff *headers* only, but avoiding to load the blobs into memory and diff them) first, and only look at full patch IDs when the abbreviated patch IDs were not for the --cherry-pick test. Let's

Re: Plugin mechanism(s) for Git?

Jeff King peff.net> writes: > > On Fri, Jul 15, 2016 at 02:46:28PM +0200, Ævar Arnfjörð Bjarmason wrote: > > > On Fri, Jul 15, 2016 at 2:18 PM, Jeff King peff.net> wrote: > > > Some features, like the index-helper, aren't quite so easy. One reason > > > is that its data needs to persist as a

Re: gc and repack ignore .git/*HEAD when checking reachability

On Wed, Jul 13, 2016 at 8:59 PM, Johannes Schindelin wrote: >> No. > > Oh? So you do not see that we are already heading into serious trouble > ourselves? I do see problems, that have solutions. But I have not yet seen that we are heading to a dead end. >> I prefer

Re: Server-side preventing some files from being overwritten

On Fri, 15 Jul 2016, Ævar Arnfjörð Bjarmason wrote: > I.e. it allows pushing a series which is a series of two commits which: > > 1. Change the forbidden file(s) > 2. Undo changes to the forbidden file(s) That’s precisely allowed. bye, //mirabilos -- tarent solutions GmbH Rochusstraße

Re: [PATCH v2] blame: Allow to blame paths freshly added to the index

Hi Mike, On Fri, 15 Jul 2016, Mike Hommey wrote: > diff --git a/t/t8003-blame-corner-cases.sh b/t/t8003-blame-corner-cases.sh > index a9b266f..2812d7c 100755 > --- a/t/t8003-blame-corner-cases.sh > +++ b/t/t8003-blame-corner-cases.sh > @@ -41,12 +41,12 @@ test_expect_success setup ' >

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

Hi Junio, On Thu, 14 Jul 2016, Junio C Hamano wrote: > Jeff King writes: > > > Yeah, that is what I was trying to get at, but you stated it much more > > clearly. LONG_IS_64BIT is good. I wonder if the "git version > > --build-options" should be "sizeof-long", too. It's shorter,

Re: Server-side preventing some files from being overwritten

On Thu, Jul 14, 2016 at 8:44 PM, Junio C Hamano wrote: > On Thu, Jul 14, 2016 at 11:27 AM, Junio C Hamano wrote: >> Thorsten Glaser writes: >> >>> if test x"0" != x"$(comm -23z \ >>> <(git ls-tree -r -z "$old" "$subdir" |

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

On Fri, Jul 15, 2016 at 03:37:32PM +0200, Torsten Bögershausen wrote: > > So off_t is probably better. We do need to be careful, though, when > > allocating objects. E.g., this: > > > > off_t size; > > struct git_istream *stream; > > void *buf; > > > > stream = open_istream(sha1, , ,

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

On 07/15/2016 12:38 AM, Jeff King wrote: On Thu, Jul 14, 2016 at 03:30:58PM -0700, Junio C Hamano wrote: If we move to time_t everywhere, I think we'll need an extra TIME_T_IS_64BIT, but we can cross that bridge when we come to it. Likewise I think we'll need SIZE_T_IS_64BIT eventually (for

Re: Plugin mechanism(s) for Git?

On Fri, Jul 15, 2016 at 02:46:28PM +0200, Ævar Arnfjörð Bjarmason wrote: > On Fri, Jul 15, 2016 at 2:18 PM, Jeff King wrote: > > Some features, like the index-helper, aren't quite so easy. One reason > > is that its data needs to persist as a cache between multiple git > >

[PATCH v2] blame: Allow to blame paths freshly added to the index

When blaming files, changes in the work tree are taken into account and displayed as being "Not Committed Yet". However, when blaming a file that is not known to the current HEAD, git blame fails with `no such path 'foo' in HEAD`, even when the file was git add'ed. This would seem uninteresting

Re: Plugin mechanism(s) for Git?

On Fri, Jul 15, 2016 at 2:18 PM, Jeff King wrote: > Some features, like the index-helper, aren't quite so easy. One reason > is that its data needs to persist as a cache between multiple git > invocations. In general, I think it would be nice to solve that by > communicating via

Re: [PATCH] blame: Allow to blame paths freshly added to the index

On Fri, Jul 15, 2016 at 08:37:59AM -0400, Jeff King wrote: > On Fri, Jul 15, 2016 at 09:32:45PM +0900, Mike Hommey wrote: > > > > > +test_expect_success 'blame wholesale copy and more in the index' ' > > > > + > > > > + { > > > > + echo ABC > > > > + echo DEF > >

Re: [PATCH] blame: Allow to blame paths freshly added to the index

On Fri, Jul 15, 2016 at 09:32:45PM +0900, Mike Hommey wrote: > > > +test_expect_success 'blame wholesale copy and more in the index' ' > > > + > > > + { > > > + echo ABC > > > + echo DEF > > > + echo > > > + echo > > > + echo GHIJK > > > + }

Re: [PATCH] blame: Allow to blame paths freshly added to the index

On Fri, Jul 15, 2016 at 12:45:15PM +0200, Johannes Schindelin wrote: > Hi Mike, > > On Fri, 15 Jul 2016, Mike Hommey wrote: > > > When blaming files, changes in the work tree are taken into account > > and displayed as being "Not Committed Yet". > > > > However, when blaming a file that is not

Re: Plugin mechanism(s) for Git?

On Fri, Jul 15, 2016 at 08:46:03AM +0200, Christian Couder wrote: > One way to extend it for better performance is to require that the > configured command should be able to deal with a number or a stream of > files or objects (instead of just one objec/file) that are passed to > it. It looks

Re: Multiple Keys in ssh-agent, fail to clone

> On Jul 13, 2016, at 3:32 PM, Junio C Hamano wrote: > > Benjamin Fritsch writes: > >> I read the Changelog for 2.9 and couldn’t find any reference to changed key >> handling. Is there anything that I can add to the `git clone` command to get >> the old

Re: [PATCH] Use path comparison for patch ids before the file content

Hi Kevin, congratulations for your first patch on the Git mailing list! On Thu, 14 Jul 2016, Kevin Willford wrote: > When limiting the list in a revision walk using cherry pick, patch ids are > calculated by producing the diff of the content of the files. This would > be more efficent by using

Re: [PATCH] git-clean: remove fifo, devices, socket files

Hi Andrey, On Fri, 15 Jul 2016, Andrey Vagin wrote: > What will be wrong if 'git status' will reports these [fifo/socket] files? `git status` is intended to give you an idea what to commit next. And... > What will be wrong if 'git add' will returns an error instead of > skipping them silently?

Re: [PATCH] blame: Allow to blame paths freshly added to the index

Hi Mike, On Fri, 15 Jul 2016, Mike Hommey wrote: > When blaming files, changes in the work tree are taken into account > and displayed as being "Not Committed Yet". > > However, when blaming a file that is not known to the current HEAD, > git blame fails with `no such path 'foo' in HEAD`, even

[PATCH 12/12] receive-pack: send keepalives during quiet periods

After a client has sent us the complete pack, we may spend some time processing the data and running hooks. If the client asked us to be quiet, receive-pack won't send any progress data during the index-pack or connectivity-check steps. And hooks may or may not produce their own progress output.

[PATCH 10/12] receive-pack: relay connectivity errors to sideband

If the connectivity check encounters a problem when receiving a push, the error output goes to receive-pack's stderr, whose destination depends on the protocol used (ssh tends to send it to the user, though without a "remote" prefix; http will generally eat it in the server's error log). The

[PATCH 11/12] receive-pack: turn on connectivity progress

When we receive a large push, the server side of the connection may spend a lot of time (30s or more for a full push of linux.git) walking the object graph without producing any output. Let's give the user some indication that we're actually working. Signed-off-by: Jeff King ---

[PATCH 09/12] receive-pack: turn on index-pack resolving progress

When we receive a large push, the server side may have to spend a lot of CPU processing the incoming packfile. During the "receiving" phase, we are typically network bound, and the client is writing its own progress to the user. But during the delta resolution phase, we may spend minutes (e.g.,

[PATCH 08/12] index-pack: add flag for showing delta-resolution progress

The index-pack command has two progress meters: one for "receiving objects", and one for "resolving deltas". You get neither by default, or both with "-v". But for a push through receive-pack, we would want only the "resolving deltas" phase, _not_ the "receiving objects" progress. There are two

[PATCH 07/12] clone: use a real progress meter for connectivity check

Because the initial connectivity check for a cloned repository can be slow, 0781aa4 (clone: let the user know when check_everything_connected is run, 2013-05-03) added a "fake" progress meter; we simply say "Checking connectivity" when it starts, and "done" at the end, with nothing between. Since

[PATCH 05/12] check_connected: relay errors to alternate descriptor

Unless the "quiet" flag is given, check_connected sends any errors to the stderr of the caller (because the child rev-list inherits that descriptor). However, server-side callers may want to send these over a sideband channel instead. Let's make that possible. Signed-off-by: Jeff King

[PATCH 06/12] check_connected: add progress flag

Connectivity checks have to traverse the entire object graph in the worst case (e.g., a full clone or a full push). For large repositories like linux.git, this can take 30-60 seconds, during which time git may produce little or no output. Let's add the option of showing progress, which is taken

[PATCH 04/12] check_everything_connected: use a struct with named options

The number of variants of check_everything_connected has grown over the years, so that the "real" function takes several possibly-zero, possibly-NULL arguments. We hid the complexity behind some wrapper functions, but this doesn't scale well when we want to add new options. If we add more wrapper

[PATCH 02/12] rev-list: add optional progress reporting

It's easy to ask rev-list to do a traversal that may take many seconds (e.g., by calling "--objects --all"). In theory you can monitor its progress by the output you get to stdout, but this isn't always easy. Some operations, like "--count", don't make any output until the end. And some callers,

[PATCH 03/12] check_everything_connected: convert to argv_array

This avoids the magic "9" array-size which we must avoid overflowing, making further patches simpler. Signed-off-by: Jeff King --- connected.c | 21 + 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/connected.c b/connected.c index

[PATCH 01/12] check_everything_connected: always pass --quiet to rev-list

The check_everything_connected function takes a "quiet" parameter which does two things if non-zero: 1. redirect rev-list's stderr to /dev/null to avoid showing errors to the user 2. pass "--quiet" to rev-list Item (1) is obviously useful. But item (2) is surprisingly not. For

[PATCH 0/12] push progress reporting and keepalives

If you push a large number of objects, the server side may have to chew CPU for a long time processing the input (delta resolution, connectivity check, and whatever any hooks choose to do). During this time, you get no feedback that anything is happening, unless the hooks feel like writing

Re: Two consecutive clones of a remote produces different files

On Fri, Jul 15, 2016 at 10:45:47AM +0200, Morten W. J. wrote: > I have a repository hosted on a GitLab server on my LAN and when I clone that > repository to a linux box and a windows box I get different files! > > It is very hard to explain in words, so I have recorded my desktop while >

Two consecutive clones of a remote produces different files

Hi All. I have experienced something weird today. I have a repository hosted on a GitLab server on my LAN and when I clone that repository to a linux box and a windows box I get different files! It is very hard to explain in words, so I have recorded my desktop while reproducing it, which I

Re: Plugin mechanism(s) for Git?

Christian Couder writes: > If people think that evolution is better than intelligent design, and > want each current topic/work to just implement what is best for it, > then that's ok for me. If on the other hand standardizing on some ways > to interact with external

Re: Plugin mechanism(s) for Git?

On Fri, Jul 15, 2016 at 08:46:03AM +0200, Christian Couder wrote: > Hi, > > It seems to me that there are many current topics/patch series in > flight that are about making Git interact with external code/processes > and that it could be interesting to step back a bit and see if we > could find a

Re: [PATCH] git-clean: remove fifo, devices, socket files

On Thu, Jul 14, 2016 at 10:56 PM, Johannes Sixt wrote: > Am 15.07.2016 um 04:42 schrieb Andrey Vagin: >> >> Currently git-clean removes only links and files, but >> there can be special files like fifo, sockets, devices. >> >> I think git-clean has to remove them too. > > > I think

Re: Plugin mechanism(s) for Git?

> On 15 Jul 2016, at 08:46, Christian Couder wrote: > > [...] > > The current topics/work I can think of are: > > - the ref backend work by Michael based on Ronnie Sahlberg's and others' work, > - the smudge/clean filters work by Joey and Lars, > - the

Plugin mechanism(s) for Git?

Hi, It seems to me that there are many current topics/patch series in flight that are about making Git interact with external code/processes and that it could be interesting to step back a bit and see if we could find a common approach/mechanism for at least some of these current topics. (This

Re: [PATCH 3/3] fsck: optionally show more helpful info for broken links

On Thu, Jul 14, 2016 at 11:30 AM, Johannes Schindelin wrote: > When reporting broken links between commits/trees/blobs, it would be > quite helpful at times if the user would be told how the object is > supposed to be reachable. > > With the new --name-objects option,