* Re: Git-gui: crashes on OS X when entering combining ("dead") keys
From: Pat Thoyts @ 2012-02-04 23:07 UTC (permalink / raw)
To: Beat Bolli; +Cc: git
In-Reply-To: <4F2B085C.2000508@drbeat.li>
Beat Bolli <ig@drbeat.li> writes:
>Hi
>
>I've just had git-gui crash on me when I tried to enter the ~ (tilde)
>character on my Mac mini under OS X 10.6.8:
>
This doesn't look git-gui specific so you will likely get more results
posting to the comp.lang.tcl newsgroup about this - or there is a
mac-specific tcl/tk list someplace.
Not posessing a Mac I can't look into this at all - but an
NSException -- that is a problem from the Tk to native layer.
--
Pat Thoyts http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
^ permalink raw reply
* Re: [PATCH 0/9] respect binary attribute in grep
From: Jeff King @ 2012-02-04 23:18 UTC (permalink / raw)
To: Pete Wyckoff
Cc: Junio C Hamano, Thomas Rast, Conrad Irwin, git,
Nguyen Thai Ngoc Duy, Dov Grobgeld
In-Reply-To: <20120204192252.GA15319@padd.com>
On Sat, Feb 04, 2012 at 02:22:52PM -0500, Pete Wyckoff wrote:
> I took a look at this series. It's nice. My worry was that the
> extra open() of non-existent .gitattributes files in all the
> directories would cause performance problems across networked
> filesystems like NFS.
Yeah, I was able to measure a small slow-down on a quick grep even with
a warm cache. So it does take some extra effort, but I think the
correctness is worth it (and note that the slow down is in the tens of
milliseconds if you have a reasonable stat()).
If people have big trees on NFS (or some other slow-stat system) where
these lookups are actually a problem, I'd rather see a global option to
disable .gitattributes lookups for both diff and grep (i.e., a "trust
me, I'm not using gitattributes, and don't bother with stat" flag). In
practice, though, I think such a thing is not necessary because the
stat() is local to the file being examined (e.g., for "foo/bar/baz", we
look only at "foo/bar/.gitattributes", "foo/.gitattributes", and
".gitattributes", without having to touch other parts of the tree).
Anyway, thanks for doing some performance testing. More data is always
good.
> It could be plausible that deep directory structures with few
> grep-able files will suffer with this change. For example, many
> big binary blobs in deep directory hierarchies, but also some
> useful files here and there.
>
> One could argue that with the use of .gitattributes to specify
> which blobs should not be searched, this series makes this faster
> by not having to to read the binary blobs at all. And I'd be
> okay with that.
Yes, exactly. I think this will end up being a big win for such cases,
because the cost of loading even one large binary file from disk will
dwarf all of the stats. But it does depend on people marking their
binaries and using "-I".
-Peff
^ permalink raw reply
* Re: [bug] blame duplicates trailing ">" in mailmapped emails
From: Jeff King @ 2012-02-04 23:20 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Junio C Hamano, Jonathan Nieder, git, SZEDER Gábor
In-Reply-To: <CAMP44s2r-fcnfpdT4u5U7TwF1z6Abp+J1U7oqfsSrYMuD6weOQ@mail.gmail.com>
On Sat, Feb 04, 2012 at 09:30:42PM +0200, Felipe Contreras wrote:
> > but it feels like the fix should go into map_user. I tried a few things,
> > like "git log -1 --format=%aE", and couldn't find other code paths with
> > this problem. So presumably they are all feeding email addresses without
> > the closing ">" (so one option is to just say "map_user needs to get
> > NUL-terminated strings).
>
> Perhaps, but I though the idea was to make it efficient. I think the
> above fix should be ok.
Because of the calling convention of map_user, the buffer with the input
must also be writable (since it holds the result). So there should be no
loss of efficiency to convert the ">" into a "\0" (and in fact, the
simplest fix is probably to just have map_user "tie off" any ">" it
detects).
> We should have tests for this though, to make sure it doesn't get
> broken again. I'm on that.
Definitely. Thanks for working on it.
-Peff
^ permalink raw reply
* Re: Git-gui: crashes on OS X when entering combining ("dead") keys
From: Beat Bolli @ 2012-02-04 23:29 UTC (permalink / raw)
To: Pat Thoyts; +Cc: git
In-Reply-To: <871uqafba4.fsf@fox.patthoyts.tk>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 05.02.12 00:07, Pat Thoyts wrote:
> Beat Bolli <ig@drbeat.li> writes:
>
>> Hi
>>
>> I've just had git-gui crash on me when I tried to enter the ~
>> (tilde) character on my Mac mini under OS X 10.6.8:
>>
>
> This doesn't look git-gui specific so you will likely get more
> results posting to the comp.lang.tcl newsgroup about this - or
> there is a mac-specific tcl/tk list someplace.
OK, I'll try to find the appropriate group.
Thanks,
Beat
- --
mail: echo '<bNbolOli@ewaSPnetAM.ch>' | tr -d '[A-S]'
pgp: 0x506A903A; 49D5 794A EA77 F907 764F D89E 304B 93CF 506A 903A
gsm: 4.7.7.6.0.7.7.9.7.1.4.e164.arpa
icbm: 47.0452 N, 7.2715 E
"It takes love over gold, and mind over matter" -- Dire Straits
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8tv2AACgkQMEuTz1BqkDqWAgCeOvSzdtYqzAsIZ3VFxd7HbNmY
HxYAoMpAdrYx8QoxlSX7blBj/y66wMQP
=WvyW
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH 1/3] blame: fix email output with mailmap
From: Jeff King @ 2012-02-04 23:39 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Junio C Hamano, Brian Gianforcaro, Marius Storm-Olsen,
Junio C Hamano
In-Reply-To: <1328385024-6955-2-git-send-email-felipe.contreras@gmail.com>
On Sat, Feb 04, 2012 at 09:50:22PM +0200, Felipe Contreras wrote:
> diff --git a/builtin/blame.c b/builtin/blame.c
> index 5a67c20..dd69e51 100644
> --- a/builtin/blame.c
> +++ b/builtin/blame.c
> @@ -1403,10 +1403,13 @@ static void get_ac_line(const char *inbuf, const char *what,
> * Now, convert both name and e-mail using mailmap
> */
> if (map_user(&mailmap, mail+1, mail_len-1, person, tmp-person-1)) {
> - /* Add a trailing '>' to email, since map_user returns plain emails
> - Note: It already has '<', since we replace from mail+1 */
> + /*
> + * Add a trailing '>' to email, since map_user returns plain
> + * emails when it finds a matching mail.
> + * Note: It already has '<', since we replace from mail + 1
> + */
> mailpos = memchr(mail, '\0', mail_len);
> - if (mailpos && mailpos-mail < mail_len - 1) {
> + if (mailpos && mailpos-mail < mail_len - 1 && *(mailpos - 1) != '>') {
> *mailpos = '>';
> *(mailpos+1) = '\0';
I'm not sure if it's possible, but do you need to be checking that
"mailpos > mail" to avoid reading off the beginning of the buffer?
It would mean the email field is empty, which may or may not be
possible.
-Peff
^ permalink raw reply
* Re: [PATCH 3/3] t: mailmap: add simple name translation test
From: Jeff King @ 2012-02-04 23:42 UTC (permalink / raw)
To: Felipe Contreras
Cc: Jonathan Nieder, git, Junio C Hamano, Marius Storm-Olsen,
Jim Meyering
In-Reply-To: <CAMP44s0Z=k6VBfv0HOGHyMBLRcPauK7K5RNvuRDbfq5=5aKVpg@mail.gmail.com>
On Sun, Feb 05, 2012 at 12:19:53AM +0200, Felipe Contreras wrote:
> > Thanks. I guess you think I'm stupid. I have no idea how I can
> > correct that assumption and help you to actually work with me to make
> > the code better. :/
>
> You mean the commit message, you haven't made any comment about the code.
>
> If you want to know why I had to modify those test assertions, you
> really need to look at the code. In essence; all of them use the same
> repo, and obviously adding a new commit message changes the output of
> the commands.
Then say that in the commit message.
Looking at this series, I wonder if the tests should simply be squashed
into the bugfix patch, which might make what is going on more obvious.
Keep in mind that as reviewers now, we read the whole series. But in a
year, as "git log" users, we may see the commits in isolation.
-Peff
^ permalink raw reply
* Specifying revisions in the future
From: jpaugh @ 2012-02-04 15:58 UTC (permalink / raw)
To: git
Hello.
Is it possible to specify revisions in the future? The gitrevisions man
page implies otherwise. Alternatively, is there a way to find out the
number of commits between two revs---assuming one is an ancestor of the
other?
I want to do a certain arbitrary operation for each revision between
where I am now and the tip of the branch.
v1.0-a master
\ \
o---o---o---o---o---o---o
|
I am here
I've been using the following to do what I want:
ref=master; \
for i in {5..1}; do \
echo; \
git log --stat $ref~$i^\!; \
read -p 'Full diff? '; \
echo; \
if [[ $REPLY == 'y' ]]; then \
git diff $ref~$i^\!; \
fi; \
done;
which lists the log and diffstat for last 5 commits between master and
where I am (e.g. an older tag/branch) with an optional full diff. I know
implementing revision specifiers to the future is nontrivial. (I
realized that when I considered non-linear histories.) In this case,
I've distilled it to the point that all I need is the number of commits
between two revs. Can this be had without manually inspecting git log?
Or, is there a better way to get detailed diffs like this?
Thanks.
Jonathan Paugh
^ permalink raw reply
* [PATCH] Change include order in two compat/ files to avoid compiler warning
From: Ben Walton @ 2012-02-05 1:08 UTC (permalink / raw)
To: git, gitster; +Cc: Ben Walton
The inet_ntop and inet_pton compatibility wrapper source files
included system headers before git-compat-utils.h. This was causing a
warning on Solaris as _FILE_OFFSET_BITS was being redefined in
git-compat-utils.h. Including git-compat-utils.h first avoids the
warnings.
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
---
I verified that this re-ordering doesn't affect either the build or the
test suite completion on both i386 and sparc. I think the ordering is
simply the result of placing the git-compat-utils.h include where some
others were removed in da523cc597b1.
compat/inet_ntop.c | 4 +---
compat/inet_pton.c | 4 +---
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/compat/inet_ntop.c b/compat/inet_ntop.c
index 60b5a1d..f1bf81c 100644
--- a/compat/inet_ntop.c
+++ b/compat/inet_ntop.c
@@ -15,11 +15,9 @@
* SOFTWARE.
*/
+#include "../git-compat-util.h"
#include <errno.h>
#include <sys/types.h>
-
-#include "../git-compat-util.h"
-
#include <stdio.h>
#include <string.h>
diff --git a/compat/inet_pton.c b/compat/inet_pton.c
index 2ec995e..1d44a5d 100644
--- a/compat/inet_pton.c
+++ b/compat/inet_pton.c
@@ -15,11 +15,9 @@
* WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
+#include "../git-compat-util.h"
#include <errno.h>
#include <sys/types.h>
-
-#include "../git-compat-util.h"
-
#include <stdio.h>
#include <string.h>
--
1.7.8.3
^ permalink raw reply related
* Re: Specifying revisions in the future
From: Jakub Narebski @ 2012-02-05 2:44 UTC (permalink / raw)
To: Jonathan Paugh; +Cc: git
In-Reply-To: <jgjkk0$qrg$1@dough.gmane.org>
jpaugh@gmx.us writes:
> Hello.
> I want to do a certain arbitrary operation for each revision between
> where I am now and the tip of the branch.
>
> v1.0-a master
> \ \
> o---o---o---o---o---o---o
> |
> I am here
That is the problem X.
> Is it possible to specify revisions in the future? The gitrevisions man
> page implies otherwise. Alternatively, is there a way to find out the
> number of commits between two revs---assuming one is an ancestor of the
> other?
That is your idea of a solution, Y.
You have XY problem. You need to do X, and you think you can use Y to
do X, so you ask about how to do Y.
If you want to list all revsions between v1.0-a and master, use
git rev-list v1.0a..master
or
git rev-list --ancestry-path v1.0a..master
depending on definition of _between_ (see "History simplification" in
git-log(1) manpage for description of `--ancestry-path` option).
>
> I've been using the following to do what I want:
>
> ref=master; \
> for i in {5..1}; do \
> echo; \
> git log --stat $ref~$i^\!; \
> read -p 'Full diff? '; \
> echo; \
> if [[ $REPLY == 'y' ]]; then \
> git diff $ref~$i^\!; \
> fi; \
> done;
>
> which lists the log and diffstat for last 5 commits between master and
> where I am (e.g. an older tag/branch) with an optional full diff. I know
> implementing revision specifiers to the future is nontrivial. (I
> realized that when I considered non-linear histories.) In this case,
> I've distilled it to the point that all I need is the number of commits
> between two revs. Can this be had without manually inspecting git log?
> Or, is there a better way to get detailed diffs like this?
--
Jakub Narebski
^ permalink raw reply
* Re: Specifying revisions in the future
From: Jakub Narebski @ 2012-02-05 3:07 UTC (permalink / raw)
To: Jonathan Paugh; +Cc: git
In-Reply-To: <4F2DEF89.4030302@gmx.us>
Jonathan Paugh wrote:
> > You have XY problem. You need to do X, and you think you can use Y to
> > do X, so you ask about how to do Y.
> >
> > If you want to list all revsions between v1.0-a and master, use
> >
> > git rev-list v1.0a..master
> >
> > or
> >
> > git rev-list --ancestry-path v1.0a..master
> Thanks. This Y' will take me to lot's of exciting destinations---and I
> must confess I haven't messed with the plumbing heretofore.
Of course you can also do
git log --ancestry-path v1.0a..master
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Git performance results on a large repository
From: Nguyen Thai Ngoc Duy @ 2012-02-05 3:47 UTC (permalink / raw)
To: Joshua Redstone; +Cc: git@vger.kernel.org
In-Reply-To: <243C23AF01622E49BEA3F28617DBF0AD5912CA85@SC-MBX02-5.TheFacebook.com>
On Sun, Feb 5, 2012 at 1:05 AM, Joshua Redstone <joshua.redstone@fb.com> wrote:
> It's also conceivable that, if there were an external interface in git to attach other
> systems to efficiently report which files have changed (e.g., via file-system integration),
> it's possible that we could omit managing the index in many cases.
> I know that would be a big change, but the benefits are intriguing.
The "interface to report which files have changed" is exactly "git
update-index --[no-]assume-unchanged" is for. Have a look at the man
page. Basically you can mark every file "unchanged" in the beginning
and git won't bother lstat() them. What files you change, you have to
explicitly run "git update-index --no-assume-unchanged" to tell git.
Someone on HN suggested making assume-unchanged files read-only to
avoid 90% accidentally changing a file without telling git. When
assume-unchanged bit is cleared, the file is made read-write again.
--
Duy
^ permalink raw reply
* Re: Git performance results on a large repository
From: david @ 2012-02-05 4:30 UTC (permalink / raw)
To: Joshua Redstone; +Cc: git@vger.kernel.org
In-Reply-To: <CB5074CF.3AD7A%joshua.redstone@fb.com>
On Fri, 3 Feb 2012, Joshua Redstone wrote:
> The test repo has 4 million commits, linear history and about 1.3 million
> files. The size of the .git directory is about 15GB, and has been
> repacked with 'git repack -a -d -f --max-pack-size=10g --depth=100
> --window=250'. This repack took about 2 days on a beefy machine (I.e.,
> lots of ram and flash). The size of the index file is 191 MB.
This may be a silly thought, but what if instead of one pack file of your
entire history (4 million commits) you create multiple packs (say every
half million commits) and mark all but the most recent pack as .keep (so
that they won't be modified by a repack)
that way things that only need to worry about recent history (blame, etc)
will probably never have to go past the most recent pack file or two
I may be wrong, but I think that when git is looking for 'similar files'
for delta compression, it limits it's search to the current pack, so this
will also keep you from searching the entire project history.
David Lang
^ permalink raw reply
* Re: [PATCH 3/3] t: mailmap: add simple name translation test
From: Jonathan Nieder @ 2012-02-05 6:17 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano, Marius Storm-Olsen, Jim Meyering
In-Reply-To: <CAMP44s0Z=k6VBfv0HOGHyMBLRcPauK7K5RNvuRDbfq5=5aKVpg@mail.gmail.com>
Felipe Contreras wrote:
> You mean the commit message, you haven't made any comment about the code.
No, for this patch, more important than the absence of any explanation
in the commit message (which is also important) is the code change
that seems unnecessarily invasive.
You've already demonstrated that I do not have the right communication
style to explain such things to you and work towards a fix that
addresses both our concerns. So I give up. I'll just give my
feedback on patches that concern code I care about and an explanation
for the sake of others on the list that are better able to interact
with you. I am willing to work with or answer questions from anyone
including you, though.
Sorry,
Jonathan
^ permalink raw reply
* Build oddities
From: Michael @ 2012-02-05 6:34 UTC (permalink / raw)
To: git
Hi there,
I ran into a build oddity with git today - the environment variable $X is
appended to most binaries. At the time, I had X=last, so I ended up with
gitlast, git-peek-remotelast etc.
Does anyone know why this behaviour exists, and if it is still desired?
Best regards,
Michael
^ permalink raw reply
* Re: Build oddities
From: Nguyen Thai Ngoc Duy @ 2012-02-05 6:46 UTC (permalink / raw)
To: Michael; +Cc: git
In-Reply-To: <loom.20120205T072940-523@post.gmane.org>
On Sun, Feb 5, 2012 at 1:34 PM, Michael <kensington@astralcloak.net> wrote:
> Hi there,
>
> I ran into a build oddity with git today - the environment variable $X is
> appended to most binaries. At the time, I had X=last, so I ended up with
> gitlast, git-peek-remotelast etc.
$X is to append .exe for Windows build so you would get git.exe,
git-peek-remote.exe... We should set X to empty from the beginning.
Patches are welcome.
--
Duy
^ permalink raw reply
* [PATCH 0/3] On compresing large index
From: Nguyễn Thái Ngọc Duy @ 2012-02-05 8:30 UTC (permalink / raw)
To: git; +Cc: Joshua Redstone, Nguyễn Thái Ngọc Duy
I was thinking whether compressing index might help when it contained
~2M files. It turns out that only makes the situation worse. Anyway, I
post the code and some numbers here.
The index is created artifically with the program [1]
$ git init
$ touch foo
$ git hash-object -w foo
$ ./a.out 256 256 32 | git update-index --index-info
That gives ~2M files in index, 209 MB in size.
$ time ~/w/git/git ls-files | head >/dev/null
real 0m4.635s
user 0m4.258s
sys 0m0.329s
$ time ~/w/git/git update-index level-0-0000/foo
real 0m4.593s
user 0m4.264s
sys 0m0.323s
Index is compressed with GIT_ZCACHE=1.
$ GIT_ZCACHE=1 ~/w/git/git update-index level-0-0000/foo
which gives 6.8 MB index (the true number may be less impressive
because compressing rate in my artificial tree is really high). The
only problem with this is git uses more time, not less
$ time ~/w/git/git ls-files | head >/dev/null
real 0m4.970s
user 0m4.675s
sys 0m0.289s
$ time GIT_ZCACHE=1 ~/w/git/git update-index level-0-0000/foo
real 0m4.959s
user 0m4.682s
sys 0m0.273s
My guess is Linux caches the whole index in memory already so I/O time
does not really matter, while we still have to pay for zlib's time. We
need to figure out what git uses 4s user time for.
This series may be useful on OSes that do not cache heavily. Though
I'm not sure if there is any out there nowadays.
Nguyễn Thái Ngọc Duy (3):
read-cache: factor out cache entries reading code
read-cache: reduce malloc/free during writing index
Support compressing index when GIT_ZCACHE=1
cache.h | 1 +
read-cache.c | 172 +++++++++++++++++++++++++++++++++++++++++++++++++---------
2 files changed, 148 insertions(+), 25 deletions(-)
[1]
-- 8< --
#include <stdio.h>
#include <string.h>
int main(int argc, char **argv)
{
const char *prefix = "100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0\t";
int l1, l2, l3;
int m1, m2, m3;
m1 = atoi(argv[1]);
m2 = atoi(argv[2]);
m3 = atoi(argv[3]);
for (l1 = 0; l1 < m1; l1++) {
printf("%slevel-0-%04d/foo\n", prefix, l1);
for (l2 = 0; l2 < m2; l2++)
for (l3 = 0; l3 < m3; l3++)
printf("%slevel-0-%04d/level-1-%04d/foo-%04d\n",
prefix, l1, l2, l3);
}
return 0;
}
-- 8< --
--
1.7.8.36.g69ee2
^ permalink raw reply
* [PATCH 2/3] read-cache: reduce malloc/free during writing index
From: Nguyễn Thái Ngọc Duy @ 2012-02-05 8:30 UTC (permalink / raw)
To: git; +Cc: Joshua Redstone, Nguyễn Thái Ngọc Duy
In-Reply-To: <1328430605-4566-1-git-send-email-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
read-cache.c | 26 ++++++++++++++++++--------
1 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index 2dbf923..7b9a989 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1521,12 +1521,19 @@ static void ce_smudge_racily_clean_entry(struct cache_entry *ce)
}
}
-static int ce_write_entry(git_SHA_CTX *c, int fd, struct cache_entry *ce)
+static int ce_prepare_ondisk_entry(struct cache_entry *ce,
+ void **ondisk_p, int *ondisk_size)
{
int size = ondisk_ce_size(ce);
- struct ondisk_cache_entry *ondisk = xcalloc(1, size);
+ struct ondisk_cache_entry *ondisk;
char *name;
- int result;
+
+ if (size <= *ondisk_size)
+ ondisk = *ondisk_p;
+ else {
+ ondisk = *ondisk_p = xrealloc(*ondisk_p, size);
+ *ondisk_size = size;
+ }
ondisk->ctime.sec = htonl(ce->ce_ctime.sec);
ondisk->mtime.sec = htonl(ce->ce_mtime.sec);
@@ -1549,10 +1556,7 @@ static int ce_write_entry(git_SHA_CTX *c, int fd, struct cache_entry *ce)
else
name = ondisk->name;
memcpy(name, ce->name, ce_namelen(ce));
-
- result = ce_write(c, fd, ondisk, size);
- free(ondisk);
- return result;
+ return size;
}
static int has_racy_timestamp(struct index_state *istate)
@@ -1588,6 +1592,8 @@ int write_index(struct index_state *istate, int newfd)
struct cache_entry **cache = istate->cache;
int entries = istate->cache_nr;
struct stat st;
+ void *ce_ondisk = NULL;
+ int ce_ondisk_size = 0;
for (i = removed = extended = 0; i < entries; i++) {
if (cache[i]->ce_flags & CE_REMOVE)
@@ -1612,13 +1618,17 @@ int write_index(struct index_state *istate, int newfd)
for (i = 0; i < entries; i++) {
struct cache_entry *ce = cache[i];
+ int size;
+
if (ce->ce_flags & CE_REMOVE)
continue;
if (!ce_uptodate(ce) && is_racy_timestamp(istate, ce))
ce_smudge_racily_clean_entry(ce);
- if (ce_write_entry(&c, newfd, ce) < 0)
+ size = ce_prepare_ondisk_entry(ce, &ce_ondisk, &ce_ondisk_size);
+ if (ce_write(&c, newfd, ce_ondisk, size) < 0)
return -1;
}
+ free(ce_ondisk);
/* Write extension data here */
if (istate->cache_tree) {
--
1.7.8.36.g69ee2
^ permalink raw reply related
* [PATCH 3/3] Support compressing index when GIT_ZCACHE=1
From: Nguyễn Thái Ngọc Duy @ 2012-02-05 8:30 UTC (permalink / raw)
To: git; +Cc: Joshua Redstone, Nguyễn Thái Ngọc Duy
In-Reply-To: <1328430605-4566-1-git-send-email-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
cache.h | 1 +
read-cache.c | 118 ++++++++++++++++++++++++++++++++++++++++++++++++++++++---
2 files changed, 112 insertions(+), 7 deletions(-)
diff --git a/cache.h b/cache.h
index 10afd71..112bc52 100644
--- a/cache.h
+++ b/cache.h
@@ -99,6 +99,7 @@ unsigned long git_deflate_bound(git_zstream *, unsigned long);
*/
#define CACHE_SIGNATURE 0x44495243 /* "DIRC" */
+#define ZCACHE_SIGNATURE 0x4452435A /* "DRCZ" */
struct cache_header {
unsigned int hdr_signature;
unsigned int hdr_version;
diff --git a/read-cache.c b/read-cache.c
index 7b9a989..45c1712 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1182,12 +1182,17 @@ static struct cache_entry *refresh_cache_entry(struct cache_entry *ce, int reall
return refresh_cache_ent(&the_index, ce, really, NULL, NULL);
}
-static int verify_hdr(struct cache_header *hdr, unsigned long size)
+static int verify_hdr(struct cache_header *hdr, unsigned long size,
+ int *deflated)
{
git_SHA_CTX c;
unsigned char sha1[20];
- if (hdr->hdr_signature != htonl(CACHE_SIGNATURE))
+ if (hdr->hdr_signature == htonl(CACHE_SIGNATURE))
+ *deflated = 0;
+ else if (hdr->hdr_signature == htonl(ZCACHE_SIGNATURE))
+ *deflated = 1;
+ else
return error("bad signature");
if (hdr->hdr_version != htonl(2) && hdr->hdr_version != htonl(3))
return error("bad index version");
@@ -1273,6 +1278,43 @@ static struct cache_entry *create_from_disk(struct ondisk_cache_entry *ondisk)
return ce;
}
+static int inflate_cache_entries(struct index_state *istate,
+ const unsigned char *mmap, size_t mmap_size,
+ unsigned long src_offset)
+{
+ unsigned char buf[sizeof(struct ondisk_cache_entry) + PATH_MAX];
+ struct ondisk_cache_entry *disk_ce;
+ struct cache_entry *ce;
+ struct git_zstream stream;
+ int i, status;
+
+ memset(&stream, 0, sizeof(stream));
+ stream.next_in = (unsigned char*)mmap + src_offset;
+ stream.avail_in = mmap_size - src_offset;
+ stream.next_out = buf;
+ stream.avail_out = sizeof(buf);
+ git_inflate_init(&stream);
+
+ for (i = 0; i < istate->cache_nr; i++) {
+ int remaining;
+ do {
+ status = git_inflate(&stream, Z_FINISH);
+ } while (status == Z_OK);
+
+ disk_ce = (struct ondisk_cache_entry *)buf;
+ ce = create_from_disk(disk_ce);
+ set_index_entry(istate, i, ce);
+
+ remaining = stream.next_out - (buf + ondisk_ce_size(ce));
+ memmove(buf, buf + ondisk_ce_size(ce), remaining);
+ stream.next_out = buf + remaining;
+ stream.avail_out = sizeof(buf) - remaining;
+ }
+ assert(status == Z_STREAM_END);
+ git_inflate_end(&stream);
+ return stream.next_in - mmap;
+}
+
static int read_cache_entries(struct index_state *istate,
const char *mmap, unsigned long src_offset)
{
@@ -1300,6 +1342,7 @@ int read_index_from(struct index_state *istate, const char *path)
struct cache_header *hdr;
void *mmap;
size_t mmap_size;
+ int deflated;
errno = EBUSY;
if (istate->initialized)
@@ -1329,7 +1372,7 @@ int read_index_from(struct index_state *istate, const char *path)
die_errno("unable to map index file");
hdr = mmap;
- if (verify_hdr(hdr, mmap_size) < 0)
+ if (verify_hdr(hdr, mmap_size, &deflated) < 0)
goto unmap;
istate->cache_nr = ntohl(hdr->hdr_entries);
@@ -1337,7 +1380,11 @@ int read_index_from(struct index_state *istate, const char *path)
istate->cache = xcalloc(istate->cache_alloc, sizeof(struct cache_entry *));
istate->initialized = 1;
- src_offset = read_cache_entries(istate, mmap, sizeof(*hdr));
+ if (deflated)
+ src_offset = inflate_cache_entries(istate, mmap, mmap_size,
+ sizeof(*hdr));
+ else
+ src_offset = read_cache_entries(istate, mmap, sizeof(*hdr));
istate->timestamp.sec = st.st_mtime;
istate->timestamp.nsec = ST_MTIME_NSEC(st);
@@ -1594,6 +1641,10 @@ int write_index(struct index_state *istate, int newfd)
struct stat st;
void *ce_ondisk = NULL;
int ce_ondisk_size = 0;
+ struct git_zstream stream;
+ int deflate, status;
+ unsigned char *dbuf_out;
+ unsigned char *dbuf_in;
for (i = removed = extended = 0; i < entries; i++) {
if (cache[i]->ce_flags & CE_REMOVE)
@@ -1607,7 +1658,8 @@ int write_index(struct index_state *istate, int newfd)
}
}
- hdr.hdr_signature = htonl(CACHE_SIGNATURE);
+ deflate = getenv("GIT_ZCACHE") != NULL;
+ hdr.hdr_signature = htonl(deflate ? ZCACHE_SIGNATURE : CACHE_SIGNATURE);
/* for extended format, increase version so older git won't try to read it */
hdr.hdr_version = htonl(extended ? 3 : 2);
hdr.hdr_entries = htonl(entries - removed);
@@ -1616,6 +1668,17 @@ int write_index(struct index_state *istate, int newfd)
if (ce_write(&c, newfd, &hdr, sizeof(hdr)) < 0)
return -1;
+ if (deflate) {
+ dbuf_out = xmalloc(WRITE_BUFFER_SIZE);
+ dbuf_in = xmalloc(WRITE_BUFFER_SIZE);
+ memset(&stream, 0, sizeof(stream));
+ stream.next_out = dbuf_out;
+ stream.avail_out = WRITE_BUFFER_SIZE;
+ stream.next_in = dbuf_in;
+ stream.avail_in = 0;
+ git_deflate_init(&stream, zlib_compression_level);
+ }
+
for (i = 0; i < entries; i++) {
struct cache_entry *ce = cache[i];
int size;
@@ -1625,11 +1688,52 @@ int write_index(struct index_state *istate, int newfd)
if (!ce_uptodate(ce) && is_racy_timestamp(istate, ce))
ce_smudge_racily_clean_entry(ce);
size = ce_prepare_ondisk_entry(ce, &ce_ondisk, &ce_ondisk_size);
- if (ce_write(&c, newfd, ce_ondisk, size) < 0)
- return -1;
+ if (!deflate) {
+ if (ce_write(&c, newfd, ce_ondisk, size) < 0)
+ return -1;
+ continue;
+ }
+
+ if (stream.avail_in)
+ memmove(dbuf_in, stream.next_in, stream.avail_in);
+ memcpy(dbuf_in + stream.avail_in, ce_ondisk, size);
+ stream.next_in = dbuf_in;
+ stream.avail_in += size;
+ do {
+ status = git_deflate(&stream, 0);
+ if (stream.next_out > dbuf_out) {
+ size = stream.next_out - dbuf_out;
+ if (ce_write(&c, newfd, dbuf_out, size) < 0)
+ return -1;
+ stream.next_out = dbuf_out;
+ stream.avail_out = WRITE_BUFFER_SIZE;
+ }
+ } while (status == Z_OK);
}
free(ce_ondisk);
+ if (deflate) {
+ do {
+ status = git_deflate(&stream, Z_FINISH);
+ if (stream.next_out > dbuf_out) {
+ int size = stream.next_out - dbuf_out;
+ if (ce_write(&c, newfd, dbuf_out, size) < 0)
+ return -1;
+ stream.next_out = dbuf_out;
+ stream.avail_out = WRITE_BUFFER_SIZE;
+ }
+ } while (status == Z_OK);
+
+ git_deflate_end(&stream);
+ if (stream.next_out > dbuf_out) {
+ int size = stream.next_out - dbuf_out;
+ if (ce_write(&c, newfd, dbuf_out, size) < 0)
+ return -1;
+ }
+ free(dbuf_in);
+ free(dbuf_out);
+ }
+
/* Write extension data here */
if (istate->cache_tree) {
struct strbuf sb = STRBUF_INIT;
--
1.7.8.36.g69ee2
^ permalink raw reply related
* [PATCH 1/3] read-cache: factor out cache entries reading code
From: Nguyễn Thái Ngọc Duy @ 2012-02-05 8:30 UTC (permalink / raw)
To: git; +Cc: Joshua Redstone, Nguyễn Thái Ngọc Duy
In-Reply-To: <1328430605-4566-1-git-send-email-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
read-cache.c | 32 ++++++++++++++++++++------------
1 files changed, 20 insertions(+), 12 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index a51bba1..2dbf923 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1273,10 +1273,28 @@ static struct cache_entry *create_from_disk(struct ondisk_cache_entry *ondisk)
return ce;
}
+static int read_cache_entries(struct index_state *istate,
+ const char *mmap, unsigned long src_offset)
+{
+ const char *buf = mmap + src_offset;
+ int i;
+
+ for (i = 0; i < istate->cache_nr; i++) {
+ struct ondisk_cache_entry *disk_ce;
+ struct cache_entry *ce;
+
+ disk_ce = (struct ondisk_cache_entry *)buf;
+ ce = create_from_disk(disk_ce);
+ set_index_entry(istate, i, ce);
+ buf += ondisk_ce_size(ce);
+ }
+ return buf - mmap;
+}
+
/* remember to discard_cache() before reading a different cache! */
int read_index_from(struct index_state *istate, const char *path)
{
- int fd, i;
+ int fd;
struct stat st;
unsigned long src_offset;
struct cache_header *hdr;
@@ -1319,17 +1337,7 @@ int read_index_from(struct index_state *istate, const char *path)
istate->cache = xcalloc(istate->cache_alloc, sizeof(struct cache_entry *));
istate->initialized = 1;
- src_offset = sizeof(*hdr);
- for (i = 0; i < istate->cache_nr; i++) {
- struct ondisk_cache_entry *disk_ce;
- struct cache_entry *ce;
-
- disk_ce = (struct ondisk_cache_entry *)((char *)mmap + src_offset);
- ce = create_from_disk(disk_ce);
- set_index_entry(istate, i, ce);
-
- src_offset += ondisk_ce_size(ce);
- }
+ src_offset = read_cache_entries(istate, mmap, sizeof(*hdr));
istate->timestamp.sec = st.st_mtime;
istate->timestamp.nsec = ST_MTIME_NSEC(st);
--
1.7.8.36.g69ee2
^ permalink raw reply related
* Re: Installing git-svn on Linux without root
From: Jakub Narebski @ 2012-02-05 10:11 UTC (permalink / raw)
To: Andrew Keller; +Cc: git
In-Reply-To: <AD682311-372A-4AED-B575-E77EB862ABD8@kellerfarm.com>
Andrew Keller wrote:
> On Feb 4, 2012, at 6:32 AM, Jakub Narebski wrote:
> > Andrew Keller <andrew@kellerfarm.com> writes:
> > > So, the module does exist, but not in a location included by @INC.
> >
> > From the above error message it looks like
> >
> > /homedirs/kelleran/local/lib/perl5/site_perl/5.8.8
> >
> > is in @INC, but
> > /homedirs/kelleran/local/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/
> >
> > is not. Strange.
> >
> > Do you use local::lib?
>
> No - Where should I use it?
local::lib is a way to install Perl modules / packages e.g. in your
home directory. Please read and follow the instructions on local::lib
manpage ("The bootstrapping technique" section):
http://search.cpan.org/~apeiron/local-lib-1.008004/lib/local/lib.pm
Then you can install Alien::SVN (or any other Perl package) using
'cpan' client (or intstall 'cpanm' / 'App::cpanminus').
HTH
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] Explicitly set X to avoid potential build breakage
From: Michael @ 2012-02-05 10:41 UTC (permalink / raw)
To: git
$X is appended to binary names for Windows builds (ie. git.exe).
Pollution from the environment can inadvertently trigger this behaviour,
resulting in 'git' turning into 'gitwhatever' without warning.
Signed-off-by: Michael <kensington@astralcloak.net>
---
Makefile | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index c457c34..380d96f 100644
--- a/Makefile
+++ b/Makefile
@@ -388,6 +388,9 @@ SCRIPT_SH =
SCRIPT_LIB =
TEST_PROGRAMS_NEED_X =
+# Binary suffix used for Windows builds
+X =
+
# Having this variable in your environment would break pipelines because
# you cause "cd" to echo its destination to stdout. It can also take
# scripts to unexpected places. If you like CDPATH, define it for your
--
1.7.8.4
^ permalink raw reply related
* Re: Git performance results on a large repository
From: David Barr @ 2012-02-05 11:24 UTC (permalink / raw)
To: david; +Cc: Joshua Redstone, git@vger.kernel.org
In-Reply-To: <alpine.DEB.2.02.1202042026280.6541@asgard.lang.hm>
On Sun, Feb 5, 2012 at 3:30 PM, <david@lang.hm> wrote:
> On Fri, 3 Feb 2012, Joshua Redstone wrote:
>
>> The test repo has 4 million commits, linear history and about 1.3 million
>> files. The size of the .git directory is about 15GB, and has been
>> repacked with 'git repack -a -d -f --max-pack-size=10g --depth=100
>> --window=250'. This repack took about 2 days on a beefy machine (I.e.,
>> lots of ram and flash). The size of the index file is 191 MB.
>
>
> This may be a silly thought, but what if instead of one pack file of your
> entire history (4 million commits) you create multiple packs (say every half
> million commits) and mark all but the most recent pack as .keep (so that
> they won't be modified by a repack)
>
> that way things that only need to worry about recent history (blame, etc)
> will probably never have to go past the most recent pack file or two
>
> I may be wrong, but I think that when git is looking for 'similar files' for
> delta compression, it limits it's search to the current pack, so this will
> also keep you from searching the entire project history.
I don't know if there is an easy way to determine with the with the
current tools
in git but one useful statistic for tuning packing performance is the
size of the
largest component in the delta-chain graph. The significance of this number is
that the product of window-size and maximum depth need not be larger than it.
I've found that with some older repositories I could have a depth as low as 3
and still get good performance from a moderate window size.
--
David Barr
^ permalink raw reply
* Re: [RFD] Rewriting safety - warn before/when rewriting published history
From: Ben Walton @ 2012-02-05 14:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <201202042045.54114.jnareb@gmail.com>
Excerpts from Jakub Narebski's message of Sat Feb 04 14:45:53 -0500 2012:
Hi Jakub,
These items are as much about UI as anything else, I think. UI that
better helps users to know the state of their commits and branches can
only be a good thing. People that have used git for a while and are
comfortable with it may not see the need/point of these, but I think
they could both really help new users.
> In Mercurial 2.1 there are three available phases: 'public' for
> published commits, 'draft' for local un-published commits and
> 'secret' for local un-published commits which are not meant to be
> published.
How do you envision such a feature in git?
A 'draft' commit (or chain of commits) could be determined from the
push matching definitions and then marked with simple decorations in
log output...This would extend the ability of status to note that your
are X commits ahead of foo. This would see any commit on a branch
that would be pushed automatically decorated with a 'draft' status.
> While default "push matching" behavior makes it possible to have
> "secret" commits, being able to explicitly mark commits as not for
> publishing might be a good idea also for Git.
Do you see using configuration or convention to achieve this?
For example, any branch named private/foo could, by convention, be
un-pushable without a force option? Alternately, a config item
similar to the push matching stuff to allow the users to designate
un-pushable branches could work too.
Please don't take the above implementation possibilities as anything
more than a starting point for discussion as they may be deeply
flawed. I'm just tossing a few things out there as I think this is a
good discussion to have.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
^ permalink raw reply
* Fwd: Breakage in master?
From: Erik Faye-Lund @ 2012-02-05 14:46 UTC (permalink / raw)
To: bug-gnu-gettext; +Cc: msysGit, Git Mailing List
In-Reply-To: <CABPQNSbj8QKqkdY49Y7tpAOQd53t+z6Gc5U-CS0-TZWyNz1WfQ@mail.gmail.com>
Git has recently switched to using gettext for translations, and I
have observed a breakage on Windows due to the way gettext handles
vsnprintf.
On MinGW, vsnprintf and _vsnprintf are two different implementations;
vsnprintf is from MinGW-runtime, and provides a reasonably sane
implementation. _vnsprintf on the other hand is from MSVCRT.dll, and
has some issues with it's return value. Before using gettext, the
MinGW-built version of Git called the version from mingw-runtime, and
everything worked fine. When built with MSVC, a shim was used to fixup
the bogus return value. This shim was injected through a define,
similar to what gettext does.
The shim in gettext lead to issues for Git, both on MinGW and on MSVC.
For MinGW, the problem is that libintl_vsnprintf calls _vsnprintf
rather than vsnprintf, giving us the same, broken return value that we
tried to prevent. This means that our code intended to call the
MinGW-runtime version, but gettext ended up calling the MSVCRT.dll
version. I don't find this very reasonable; a call to vsnprintf ends
up as a call to _vsnprintf.
On MSVC the problem is a bit easier to spot; libgnuintl.h.in contains
the following:
---8<---
#if !(defined vsnprintf && defined _GL_STDIO_H) /* don't override gnulib */
#undef vsnprintf
#define vsnprintf libintl_vsnprintf
extern int vsnprintf (char *, size_t, const char *, va_list);
#endif
---8<---
Uhm, what? Unless we're using Gnulib, our definition of vsnprintf
should simply be ignored?
I'm not saying figuring out what to do here is exactly trivial; but I
think undefining any definitions of vsnprintf that aren't exactly
"_vsnprintf" is dangerous. The forwarded mail below contains a
quick-fix I did locally that seems to side-step the problem for me, by
not using _vsnprintf on MinGW. But perhaps there's something better we
can do?
---------- Forwarded message ----------
From: Erik Faye-Lund <kusmabite@gmail.com>
Date: Sat, Feb 4, 2012 at 10:55 PM
Subject: Re: Breakage in master?
To: Jeff King <peff@peff.net>
Cc: Git Mailing List <git@vger.kernel.org>, msysGit
<msysgit@googlegroups.com>, Ævar Arnfjörð <avarab@gmail.com>
On Fri, Feb 3, 2012 at 1:28 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
> On Thu, Feb 2, 2012 at 6:46 PM, Jeff King <peff@peff.net> wrote:
>> On Thu, Feb 02, 2012 at 01:14:19PM +0100, Erik Faye-Lund wrote:
>>
>>> But here's the REALLY puzzling part: If I add a simple, unused
>>> function to diff-lib.c, like this:
>>> [...]
>>> "git status" starts to error out with that same vsnprintf complaint!
>>>
>>> ---8<---
>>> $ git status
>>> # On branch master
>>> # Changes not staged for commit:
>>> # (use "git add <file>..." to update what will be committed)
>>> fatal: BUG: your vsnprintf is broken (returned -1)
>>> ---8<---
>>
>> OK, that's definitely odd.
>>
>> At the moment of the die() in strbuf_vaddf, what does errno say?
>
> If I apply this patch:
> ---8<---
> diff --git a/strbuf.c b/strbuf.c
> index ff0b96b..52dfdd6 100644
> --- a/strbuf.c
> +++ b/strbuf.c
> @@ -218,7 +218,7 @@ void strbuf_vaddf(struct strbuf *sb, const char
> *fmt, va_list ap)
> len = vsnprintf(sb->buf + sb->len, sb->alloc - sb->len, fmt, cp);
> va_end(cp);
> if (len < 0)
> - die("BUG: your vsnprintf is broken (returned %d)", len);
> + die_errno("BUG: your vsnprintf is broken (returned %d)", len);
> if (len > strbuf_avail(sb)) {
> strbuf_grow(sb, len);
> len = vsnprintf(sb->buf + sb->len, sb->alloc - sb->len, fmt, ap);
> ---8<---
>
> Then I get "fatal: BUG: your vsnprintf is broken (returned -1): Result
> too large". This goes both for both failure cases I described. I
> assume this means errno=ERANGE.
>
>> vsnprintf should generally never be returning -1 (it should return the
>> number of characters that would have been written). Since you're on
>> Windows, I assume you're using the replacement version in
>> compat/snprintf.c.
>
> No. SNPRINTF_RETURNS_BOGUS is only set for the MSVC target, not for
> the MinGW target. I'm assuming that means MinGW-runtime has a sane
> vsnprintf implementation. But even if I enable SNPRINTF_RETURNS_BOGUS,
> the problem occurs. And it's still "Result too large".
>
> So I decided to do a bit of stepping, and it seems libintl takes over
> vsnprintf, directing us to libintl_vsnprintf instead. I guess this is
> so it can ensure we support reordering the parameters with $1 etc...
> And aparently this vsnprintf implementation calls the system vnsprintf
> if the format string does not contain '$', and it's using _vsnprintf
> rather than vsnprintf on Windows. _vsnprintf is the MSVCRT-version,
> and not the MinGW-runtime, which needs SNPRINTF_RETURNS_BOGUS.
>
> So I guess I can patch libintl to call vsnprintf from MinGW-runtime instead.
>
Indeed, I just got around to testing this, and doing this on top of
gettext seems to fix the problem for me. For the MSVC, a more
elaborate fix is needed, as it doesn't have a sane vsnprintf.
---
diff --git a/gettext-runtime/intl/printf.c b/gettext-runtime/intl/printf.c
index b7cdc5d..f55023e 100644
--- a/gettext-runtime/intl/printf.c
+++ b/gettext-runtime/intl/printf.c
@@ -192,7 +192,7 @@ libintl_sprintf (char *resultbuf, const char *format, ...)
#if HAVE_SNPRINTF
-# if HAVE_DECL__SNPRINTF
+# if HAVE_DECL__SNPRINTF && !defined(__MINGW32__)
/* Windows. */
# define system_vsnprintf _vsnprintf
# else
^ permalink raw reply related
* Re: [RFD] Rewriting safety - warn before/when rewriting published history
From: Jakub Narebski @ 2012-02-05 15:05 UTC (permalink / raw)
To: Ben Walton; +Cc: git
In-Reply-To: <1328452328-sup-6643@pinkfloyd.chass.utoronto.ca>
On Sun, 5 Feb 2012, Ben Walton wrote:
> Excerpts from Jakub Narebski's message of Sat Feb 04 14:45:53 -0500 2012:
>
> Hi Jakub,
>
> These items are as much about UI as anything else, I think. UI that
> better helps users to know the state of their commits and branches can
> only be a good thing. People that have used git for a while and are
> comfortable with it may not see the need/point of these, but I think
> they could both really help new users.
As I said, 1500+ git users would like to have such feature, according
to latest Git User's Survey.
> > In Mercurial 2.1 there are three available phases: 'public' for
> > published commits, 'draft' for local un-published commits and
> > 'secret' for local un-published commits which are not meant to be
> > published.
>
> How do you envision such a feature in git?
>
> A 'draft' commit (or chain of commits) could be determined from the
> push matching definitions and then marked with simple decorations in
> log output...This would extend the ability of status to note that your
> are X commits ahead of foo. This would see any commit on a branch
> that would be pushed automatically decorated with a 'draft' status.
I think that in its basic form (treating all remotes equally) commits
in 'public' phase would be those reachable from remote-tracking branches.
Otherwise commits would be in 'draft' phase, unless explicitly marked
as 'secret' (it we implement 'secret' phase, that is).
The safety new I think of would (similarly to Mercurial phases) prevent
or warn about amending published commit, and rebasing commits which were
already published (in 'public' phase). That would require modifications
to git-commit and git-amend, I think...
Maybe even Git could refuse or warn on the local side about non
fast-forward update of public branch, to help users of third-party tools.
> > While default "push matching" behavior makes it possible to have
> > "secret" commits, being able to explicitly mark commits as not for
> > publishing might be a good idea also for Git.
>
> Do you see using configuration or convention to achieve this?
>
> For example, any branch named private/foo could, by convention, be
> un-pushable without a force option? Alternately, a config item
> similar to the push matching stuff to allow the users to designate
> un-pushable branches could work too.
I'm not sure, but the config item might be a good solution. Git would
skip publishing 'secret' commits (commits from 'secret' branch) if it
would otherwise publish it due to glob refspec, and refuse (or warn)
publishing 'secret' branches explicitly.
Currently if you use default "push matching", then those branches that
you didn't push explicitly wouldn't be pushed. But that does not prevent
pushing them by accident, and does not give UI to check if branch is
private or not (e.g. to use in git-aware shell prompt).
--
Jakub Narebski
Poland
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox