Re: ephemeral-branches instead of detached-head?
On Mon, Aug 12, 2013 at 3:37 PM, David Jeske dav...@gmail.com wrote: Is there currently any way to say hey, git, show me what commits are dangling that might be lost in the reflog? How do you define dangling commits? When you do git commit --amend, the current commit will become dangling (in the sense that it's not referred by any ref, but the commit exists) and those are just noise in my opinion. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help with sparse checkouts
On Tue, Aug 13, 2013 at 1:27 AM, Ari Entlich atrig...@ccs.neu.edu wrote: Hello all! At my current workplace, I have a git-svn repository which has an extremely large working directory. I did not use the --stdlayout option in this clone, so I have a number of branches in my working directory which duplicate large amounts of trunk. There is a particularly large subdirectory which has now been copied to branches four times (and hence shows up in my working directory 5 times). This directory and its copies are making up the vast majority of the files and storage space in my working directory. Furthermore, I do not need or want to have access to the data in these particular directories. Hence, I would like to use the sparse checkouts feature to exclude them from my working directory. Let's say that these directories are all called thedir. What I would like to do with the sparse checkouts feature is to simply ignore directories with this name anywhere in the working tree. Intuitively, it seems like I should be able to put: !thedir or possibly !thedir/ I think this should work (but I haven't tested it) / !thedir The first rule is to include all, the we exclude what we don't want using the second one (trailing slash or not is ok). in the sparse-checkout file, but these don't seem to work. I've tried a number of other things, but I always seem to either get the sparse checkout leaves no entry on working directory error or no effect at all. In the end, I basically just don't really understand how this file is supposed to work, so I'd rather get some expert help here rather than thrashing about randomly. I realize that sparse checkouts is usually used to select a specific directory rather than what I'm trying to do, so I accept that what I want may simply not be possible with the current implementation. I've asked on IRC, but I wanted to ask here also since it seemed that most of the people I talked to weren't that familiar with the sparse checkouts feature. Note that, while using --stdlayout would mitigate the massive working directory somewhat, I would still probably want to exclude this directory from my worktree. I will probably do a reclone at some point and use --stdlayout, but I will still want to exclude this particular directory even at that point. I had a lot of people on IRC telling me to just use --stdlayout, which was a good suggestion, but didn't fully fulfill my needs. Thanks! Ari -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Remove old forgotten command: whatchanged
Junio C Hamano gits...@pobox.com writes: +changes. You can emulate `git log` with a trivial script that pipes I'd say You can emulate `git log` and `git log -p` here, but I'm fine with your version too. -[NOTE] -Most likely, you are not directly using the core -Git Plumbing commands, but using Porcelain such as 'git add', `git-rm' -and `git-commit'. This removal sounds unrelated, but I don't understand what this note was doing here anyway, so it's good to remove it. Thanks, -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
Junio C Hamano gits...@pobox.com writes: (2) configure include.path to point at ~/.git-profile/open at the very end I'd rather have it ~/.config/git/profile/ (or $XDG_CONFIG_HOME/git/profile if $XDG_CONFIG_HOME is set), but the proposal makes sense. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
Jonathan Nieder jrnie...@gmail.com writes: Hi Thorsten, Thorsten Glaser wrote[1]: git config user.email SHOULD NOT default to $(id -un)@$(hostname -f) because just too many cow-orkers seem to be unable to follow basic instructions Heh. Can you say a little more about your setup? In a university environment with sysadmin-managed email and /etc/mailname set up correctly it is handy that people can start working without doing anything special to configure git's [user] email setting. I also work with a university environment. The guessed user.email is almost right (actually, it's not the official email address, but an internal one we ask students not to use). Still, I'd love to see Git error out by default, as most students use Git from several machines. They usually learn and write their first ~/.gitconfig on the school's machines, and then start working from their personal laptops, where the guessed user.email is plain wrong. We do teach them to set user.email in ~/.gitconfig as a very first step, but many don't (because they don't read the tutorial, or because they do something wrong like putting .gitconfig in the wrong directory). We do tell them to set up ~/.gitconfig on every host they work from, but many don't either. And unfortunately, the warning is not scary enough for some of them :-\ (Err, did I get a warning? where?). An opt-in auto-detection would be cool for people who really work in a controlled environment, so that the sysadmin could enable it from /etc/gitconfig. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
Felipe Contreras felipe.contre...@gmail.com writes:
This is how to implement that:
From f1feaa05ce3772d8006078c4aeabcbd55b52d58e Mon Sep 17 00:00:00 2001
From: Felipe Contreras 2nd felipe.contrera...@gmail.com
Date: Tue, 13 Nov 2012 07:33:12 +0100
Subject: [PATCH] ident: don't allow implicit email addresses
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
ident.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ident.c b/ident.c
index 1c123e6..85fc729 100644
--- a/ident.c
+++ b/ident.c
@@ -301,9 +301,9 @@ const char *fmt_ident(const char *name, const char *email,
}
if (strict email == git_default_email.buf
- strstr(email, (none))) {
+ !(user_ident_explicitly_given IDENT_MAIL_GIVEN)) {
fputs(env_hint, stderr);
- die(unable to auto-detect email address (got '%s'), email);
+ die(no explicit email address);
}
if (want_date) {
That's a first step, but something should also be done in
builtin/commit.c, which currently displays a detailed warning
(implicit_ident_advice) /after/ performing the commit. I think your
patch would turn this warning into dead code.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
Matthieu Moy dixit: An opt-in auto-detection would be cool for people who really work in a controlled environment, so that the sysadmin could enable it from Sounds like a plan ;-) I think with several people chiming in on this, while that proposal would affect a majority of people, it would do so in a less intrusive way as the current behaviour of autodetection which negatively affects some users, although not few either, in a strong way. bye, //mirabilos -- emacs als auch vi zum Kotzen finde (joe rules) und pine für den einzig bedienbaren textmode-mailclient halte (und ich hab sie alle ausprobiert). ;) Hallo, ich bin der Holger (Hallo Holger!), und ich bin ebenfalls ... pine-User, und das auch noch gewohnheitsmäßig (Oooohhh). [aus dasr] -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git stash takes excessively long when many untracked files present
Josh Triplett josh at joshtriplett.org writes:
[CCing folks involved in the recent stash-refuse-to-kill merge.]
I keep portions of my home directory in git. I tried to git stash
some local changes, and it ran for several minutes with no progress. ps
showed that it was running git ls-files --killed, which was taking
100% CPU, and occasionally reading the disk very slowly.
I've recently got the same problem, though in this case it's my
openembedded directory that's giving me those problems. (Having an
untracked build-directory of quiet a few GB takes some time).
I worked around it by locally patching git-stash:
---
diff --git a/git-stash.sh b/git-stash.sh
index 85c9e2c..e5a2043 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -263,7 +263,7 @@ save_stash () {
exit 0
fi
if test -z $untracked$force
- test -n $(git ls-files --killed | head -n 1)
+ test -n $(git ls-files --killed --directory | head -n 1)
then
say $(gettext The following untracked files would NOT be
saved
test -n $GIT_QUIET || git ls-files --killed | sed
's/^/\t/'
---
It seems to work in my extremely limited testing. Though, I'm pretty sure
that there'll be quite a few error cases... (Especially, as I just made
a naive attempt at patching git-stash, so I could go on with a few other
things).
Do anyone have any better idea on how to approach this?
strace shows that git ls-files --killed is doing a full recursive
enumeration of my entire home directory. That's a Really Bad Idea:
~$ find | wc -l
3248997
~$ find -type d | wc -l
350680
Not only that, but it also appears to be attempting to stat and open
several files in every single directory; for instance:
stat(.ccache/1/3/.git, 0x7fff254bc7a0) = -1 ENOENT (No such file or
directory)
open(.ccache/1/3/.git/HEAD, O_RDONLY) = -1 ENOENT (No such file or
directory)
stat(.ccache/1/3/.git, 0x7fff254bc770) = -1 ENOENT (No such file or
directory)
open(.ccache/1/3/.git/packed-refs, O_RDONLY) = -1 ENOENT (No such file
or directory)
(Yes, in that order.)
I see a lot of room for optimization here. Most importantly, git
ls-files --killed really doesn't need to look at any directory entry
unless something in the index would conflict with it.
I guess that this would be a good optimization. Or, are ls-files --killed
used in other cases where the current behaviour would be requiered?
Cheers,
Anders
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
On Mon, Aug 12, 2013 at 11:01:03PM +1000, Andrew Ardill wrote: On 12 August 2013 22:39, Jeff King p...@peff.net wrote: We could do something like the patch below, which allows: $ git config --global include./magic/.path .gitconfig-magic to read ~/.gitconfig-magic only when we are in a repository with a directory component /magic/. Thanks, this looks great! I'll have a play with it tomorrow. I applied this on top of latest next (1da3ebde8999d07), and it worked perfectly for my use case. For what it's worth, it also passed the test suite! Would be great to see this, or something on the same theme, get into master. I'd be happy to review patches/write tests/write documentation if needed. Regards, Andrew Ardill -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
On Tue, Aug 13, 2013 at 09:05:40PM +1000, Andrew Ardill wrote: I applied this on top of latest next (1da3ebde8999d07), and it worked perfectly for my use case. For what it's worth, it also passed the test suite! Would be great to see this, or something on the same theme, get into master. I'd be happy to review patches/write tests/write documentation if needed. Like I said, I do not have a particular use for it, but I don't think it would hurt anybody who does not use it. If you want to polish it up into a real patch with docs and tests, I don't mind. The only downside I can think of is that we might want to use the subsection in include.SUBSECTION.* for some other limiting conditions (e.g., only include this config when running version = X.Y, or even include only when environment variable FOO is true). I guess we could do something like: [include repo:...your regex here...] path = .gitconfig-only-for-some-repos [include env:USE_MY_MAGIC_CONFIG] path = .gitconfig-only-when-magic-env-set Adding the repo: prefix for this repo-dir matching is pretty trivial. Adding a similar env-matching is only slightly less trivial; but does anybody actually want it? -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
On Tue, Aug 13, 2013 at 07:46:35AM -0400, Jeff King wrote:
The only downside I can think of is that we might want to use the
subsection in include.SUBSECTION.* for some other limiting conditions
(e.g., only include this config when running version = X.Y, or even
include only when environment variable FOO is true).
I guess we could do something like:
[include repo:...your regex here...]
path = .gitconfig-only-for-some-repos
[include env:USE_MY_MAGIC_CONFIG]
path = .gitconfig-only-when-magic-env-set
Adding the repo: prefix for this repo-dir matching is pretty trivial.
Adding a similar env-matching is only slightly less trivial; but does
anybody actually want it?
Here it is with the repo: prefix, if you want to build on that.
Adding the env spec is as easy as doing this on top:
diff --git a/config.c b/config.c
index f1ca6fa..64ba141 100644
--- a/config.c
+++ b/config.c
@@ -150,6 +150,8 @@ static int match_config_include(const char *spec)
const char *val;
if ((val = skip_prefix(spec, repo:)))
return match_repo_path(val);
+ if ((val = skip_prefix(spec, env:)))
+ return git_env_bool(val, 0);
/* Unknown specs are considered no match. */
return 0;
---
diff --git a/config.c b/config.c
index e13a7b6..f1ca6fa 100644
--- a/config.c
+++ b/config.c
@@ -119,10 +119,55 @@ int git_config_include(const char *var, const char
*value, void *data)
return ret;
}
+static NORETURN void die_bad_regex(int err, regex_t *re)
+{
+ char errbuf[1024];
+ regerror(err, re, errbuf, sizeof(errbuf));
+ if (cf cf-name)
+ die(bad regex (at %s:%d): %s, cf-name, cf-linenr, errbuf);
+ else
+ die(bad regex: %s, errbuf);
+}
+
+static int match_repo_path(const char *re_str)
+{
+ regex_t re;
+ int ret;
+ const char *repo_path;
+
+ ret = regcomp(re, re_str, REG_EXTENDED);
+ if (ret)
+ die_bad_regex(ret, re);
+
+ repo_path = absolute_path(get_git_dir());
+ ret = regexec(re, repo_path, 0, NULL, 0);
+ regfree(re);
+ return !ret;
+}
+
+static int match_config_include(const char *spec)
+{
+ const char *val;
+ if ((val = skip_prefix(spec, repo:)))
+ return match_repo_path(val);
+
+ /* Unknown specs are considered no match. */
+ return 0;
+}
+
+static int match_config_include_mem(const char *spec, int spec_len)
+{
+ char *spec_str = xmemdupz(spec, spec_len);
+ int ret = match_config_include(spec_str);
+ free(spec_str);
+ return ret;
+}
+
int git_config_include(const char *var, const char *value, void *data)
{
struct config_include_data *inc = data;
- const char *type;
+ const char *match, *type;
+ int match_len;
int ret;
/*
@@ -133,8 +178,9 @@ int git_config_include(const char *var, const char *value,
void *data)
if (ret 0)
return ret;
- type = skip_prefix(var, include.);
- if (!type)
+ if (parse_config_key(var, include, match, match_len, type))
+ return ret;
+ if (match !match_config_include_mem(match, match_len))
return ret;
if (!strcmp(type, path))
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
On 13 August 2013 21:46, Jeff King p...@peff.net wrote: Like I said, I do not have a particular use for it, but I don't think it would hurt anybody who does not use it. If you want to polish it up into a real patch with docs and tests, I don't mind. I'll have a go at this. The only downside I can think of is that we might want to use the subsection in include.SUBSECTION.* for some other limiting conditions (e.g., only include this config when running version = X.Y, or even include only when environment variable FOO is true). It seems as though gitconfig doesn't have a standard way of dealing with 'sub-subsections', which is essentially what this is trying to implement. It makes sense that there could be different 'modes' of includes. These could be the ones you mentioned already, such as repo and env, but could also be things like branch where the config changes depending on which branch you are on. Ideally, multiple entries per mode would be allowed. Implementing all that initially would be overkill however if this sort of functionality is desirable the ability to easily add new modes would be a great boon down the track. The four pieces of information we need to include are that this is an include, the path to the include, the mode, and the mode specific parameter. Your proposal is to allow the sub-subsection by concatenating with a : like this [include mode:mode-param] path = path Alternatively, we could allow chaining of subsections (couldn't find any previous discussion on this) by adding whitespace between each subsection. Seems like lots of potentially unnecessary work, but maybe this has already been discussed or is the most appropriate way of doing it. $ git config --global include.repo./magic/.path ~/.gitconfig-magic [include repo /magic/] path = .gitconfig-magic We could also require a unique key that grouped the options together. This seems like the easiest and most flexible method, and doesn't require any 'special' considerations for the subsection. It would be harder for a user to configure, and the concept of a mode seems less intuitive. $ git config --global include.magicrepos.mode repo $ git config --global include.magicrepos.param /magic/ $ git config --global include.magicrepos.path ~/.gitconfig-magic [include magicrepos] mode = repo param = /magic/ path = ~/.gitconfig-magic Of the three I probably think the subsection chaining is the nicest overall, though your original repo: proposal seems to be the easiest to implement. Regards, Andrew Ardill -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH] git-remote-mediawiki: reset private ref after non-dumb push
Git-mediawiki's dumb push sends the local revisions to the remote wiki,
but does not update the local metadata to reflect the push (hence, the
next pull will have to re-import the exported revisions).
The previous implementation was simply omitting the update to the private
ref after a dumb push. This was broken by 664059fb62 (Felipe Contreras,
Apr 17 2013, transport-helper: update remote helper namespace), which
does an automatic update of the private ref (not just the
remote-tracking) on push.
This patch fixes git-remote-mediawiki to reset the private ref after the
push is completed, cancelling the automatic update triggered by
664059fb62.
Signed-off-by: Matthieu Moy matthieu@imag.fr
---
Felipe: Is this the right fix for git-remote-mediawiki? Any better idea?
Thanks,
contrib/mw-to-git/git-remote-mediawiki.perl | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index f8d7d2c..13919ad 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -53,6 +53,7 @@ if (@ARGV != 2) {
my $remotename = $ARGV[0];
my $url = $ARGV[1];
+my $reset_private_ref_to = undef;
# Accept both space-separated and multiple keys in config file.
# Spaces should be written as _ anyway because we'll use chomp.
@@ -161,6 +162,9 @@ sub parse_command {
my ($line) = @_;
my @cmd = split(/ /, $line);
if (!defined $cmd[0]) {
+ if ($reset_private_ref_to) {
+ run_git(update-ref -m \Git-MediaWiki non-dumb push\
refs/mediawiki/$remotename/master $reset_private_ref_to);
+ }
return 0;
}
if ($cmd[0] eq 'capabilities') {
@@ -1209,9 +1213,10 @@ sub mw_push_revision {
die(Unknown error from mw_push_file()\n);
}
}
- if (!$dumb_push) {
+ if ($dumb_push) {
+ $reset_private_ref_to = $remoteorigin_sha1;
+ } else {
run_git(qq(notes --ref=${remotename}/mediawiki add -f
-m mediawiki_revision: ${mw_revision} ${sha1_commit}));
- run_git(qq(update-ref -m Git-MediaWiki push
refs/mediawiki/${remotename}/master ${sha1_commit} ${sha1_child}));
}
}
--
1.8.2.1.349.ge888d28.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ephemeral-branches instead of detached-head?
On Tue, Aug 13, 2013 at 9:44 PM, David Jeske dav...@gmail.com wrote: On Aug 12, 2013 11:06 PM, Duy Nguyen pclo...@gmail.com wrote: On Mon, Aug 12, 2013 at 3:37 PM, David Jeske dav...@gmail.com wrote: Is there currently any way to say hey, git, show me what commits are dangling that might be lost in the reflog? How do you define dangling commits? Any commit which I did not explicitly do something with. (Merge, rebase, amend, branch name, discard) Today every one of those actions is explicit except discard. So basically everything that is (1) produced by git commit, (2) not connected to any ref and (3) not an amend. I think (1) and (3) can be achieved with git log -g --grep-reflog commit: HEAD. We only need to filter out ones that are connected to some ref. Not sure if that can be done with script though. Maybe add --dangling to git log -g to do such filtering? -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: ephemeral-branches instead of detached-head?
On Aug 12, 2013 11:06 PM, Duy Nguyen pclo...@gmail.com wrote: On Mon, Aug 12, 2013 at 3:37 PM, David Jeske dav...@gmail.com wrote: Is there currently any way to say hey, git, show me what commits are dangling that might be lost in the reflog? How do you define dangling commits? Any commit which I did not explicitly do something with. (Merge, rebase, amend, branch name, discard) Today every one of those actions is explicit except discard. When you do git commit --amend, the current commit will become dangling (in the sense that it's not referred by any ref, but the commit exists) and those are just noise in my opinion. This is *exactly* my point. There is no way to distinguish a commit which was accidentally and implicitly dangled due to checkout or submodule update on a detached head, from all those other intentionally dangling refs which were explicitly handled with merge, rebase, amend. Ephemeral branches would change only the implicit discard.. Turning it into a named branch and requiring an explicit discard. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
On Tue, Aug 13, 2013 at 10:52:34PM +1000, Andrew Ardill wrote: The only downside I can think of is that we might want to use the subsection in include.SUBSECTION.* for some other limiting conditions (e.g., only include this config when running version = X.Y, or even include only when environment variable FOO is true). It seems as though gitconfig doesn't have a standard way of dealing with 'sub-subsections', which is essentially what this is trying to implement. Right. Syntactically, the config keys are: SECTION.SUBSECTION.KEY where SUBSECTION is optional. SECTION and KEY cannot contain spaces or dots and are case insensitive, but SUBSECTION is handled literally. It can contain whatever data is useful to the config parser (for example, remote names, branch names, or even URLs), including spaces or dots. We could introduce the notion of sub-subsections, but that would not play well with existing uses of subsection, which assume that they can put arbitrary data into it. It makes sense that there could be different 'modes' of includes. These could be the ones you mentioned already, such as repo and env, but could also be things like branch where the config changes depending on which branch you are on. Ideally, multiple entries per mode would be allowed. Implementing all that initially would be overkill however if this sort of functionality is desirable the ability to easily add new modes would be a great boon down the track. Right. We don't have to decide on all of it now; we just have to leave the door open syntactically for future growth. The four pieces of information we need to include are that this is an include, the path to the include, the mode, and the mode specific parameter. Your proposal is to allow the sub-subsection by concatenating with a : like this [include mode:mode-param] path = path Right. The config parser does not care about the sub-subsection; it is up to the interpreter of the key to split the subsection if it chooses. I arbitrarily chose : as the internal delimiter because I thought it looked nice. You could make it dot or space, too. Alternatively, we could allow chaining of subsections (couldn't find any previous discussion on this) by adding whitespace between each subsection. Seems like lots of potentially unnecessary work, but maybe this has already been discussed or is the most appropriate way of doing it. $ git config --global include.repo./magic/.path ~/.gitconfig-magic [include repo /magic/] path = .gitconfig-magic I don't think it has been discussed before. But as I mentioned above, you would not want to apply this everywhere. For existing config callbacks, they want to take the section literally. So it is going to be up to the callback to parse the section into subsections anyway, at which point it does not really matter what syntax you use. We could teach the config parser to normalize: [section with many spaces] key as section.with.many.spaces.key or section.with many spaces.key (I do not think it is even valid in today's code, but I didn't check). But personally I do not find that any easier to read or understand than the colon syntax. This seems like the easiest and most flexible method, and doesn't require any 'special' considerations for the subsection. It would be harder for a user to configure, and the concept of a mode seems less intuitive. $ git config --global include.magicrepos.mode repo $ git config --global include.magicrepos.param /magic/ $ git config --global include.magicrepos.path ~/.gitconfig-magic [include magicrepos] mode = repo param = /magic/ path = ~/.gitconfig-magic Yeah, that is the most flexible. You could introduce multiple conditions or other options, as well (e.g., instead of mode and param, have include.magic.repo, include.magic.env, etc). But it seems like over-engineering. I do not mind making the code a little harder to write, but it seems unnecessarily complicated for the user, too. Of the three I probably think the subsection chaining is the nicest overall, though your original repo: proposal seems to be the easiest to implement. I think I favor the colon proposal because of its simplicity. And because the sub-section chaining cannot be applied consistently across config keys, I don't think there is much value in trying to introduce a new general config syntax. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] whatchanged: document its historical nature
John Keeping j...@keeping.me.uk writes: Hmm, I hadn't realised that specifying -p would disable the --raw. I still find the last sentence of the original patch slightly awkward though. How about New users are encouraged to use linkgit:git-log[1] instead. The `whatchanged` command is essentially the same as linkgit:git-log[1] but defaults to ``raw'' diff output and does not show merge commits. ? I've pushed out a new version with slight rewording based on your version. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Remove old forgotten command: whatchanged
Matthieu Moy matthieu@grenoble-inp.fr writes: Junio C Hamano gits...@pobox.com writes: +changes. You can emulate `git log` with a trivial script that pipes I'd say You can emulate `git log` and `git log -p` here, but I'm fine with your version too. By `git log`, I meant `git log` with its various options, as it felt unnecessary to single `-p` out. But will reword anyway. -[NOTE] -Most likely, you are not directly using the core -Git Plumbing commands, but using Porcelain such as 'git add', `git-rm' -and `git-commit'. This removal sounds unrelated, but I don't understand what this note was doing here anyway, so it's good to remove it. Yeah, the removal is part of ...and this document is not where the end users learn what `git log` command is about. Stop at briefly mentioning the possibility of combining rev-list with diff-tree to build your own log, and leave the end-user documentation of `log` to the new tutorial and the user manual. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
Jeff King p...@peff.net writes:
diff --git a/config.c b/config.c
index e13a7b6..a31dc85 100644
--- a/config.c
+++ b/config.c
@@ -119,10 +119,45 @@ int git_config_include(const char *var, const char
*value, void *data)
return ret;
}
+static NORETURN void die_bad_regex(int err, regex_t *re)
+{
+ char errbuf[1024];
+ regerror(err, re, errbuf, sizeof(errbuf));
+ if (cf cf-name)
+ die(bad regex (at %s:%d): %s, cf-name, cf-linenr, errbuf);
+ else
+ die(bad regex: %s, errbuf);
+}
+
+static int match_repo_path(const char *re_str)
+{
+ regex_t re;
+ int ret;
+ const char *repo_path;
+
+ ret = regcomp(re, re_str, REG_EXTENDED);
+ if (ret)
+ die_bad_regex(ret, re);
+
+ repo_path = absolute_path(get_git_dir());
+ ret = regexec(re, repo_path, 0, NULL, 0);
+ regfree(re);
+ return !ret;
We do this every time during the parsing?
Hmph, if you had include.repo:/home/junio/frotz/.path and
include.repo:/srv/project/git.git/.path in your ~/.gitconfig,
then a single regexp that is lazily prepared once will not cut it,
so I guess that you cannot avoid it.
Unlike git init|clone --profile=foo that requires you to be
explicit about your profile upon invocation, this mechanism is much
easier to use by having include.magic.path in some global
configuration, and the existing precedence rule makes it perfect.
By starting /etc/gitconfig and/or your $HOME/.gitconfig with series
of include.magic.path, you can have the default definitions
included from these magic include to take effect before anything
else, and settings from other configuration files can override it.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git should not use a default user.email config value
Jeff King p...@peff.net writes: I guess we could do something like: [include repo:...your regex here...] path = .gitconfig-only-for-some-repos [include env:USE_MY_MAGIC_CONFIG] path = .gitconfig-only-when-magic-env-set I am not sure if env is very useful, but there certainly are other possibilities (e.g. apply this only on this host, only for members of this UNIX group, etc.), so having repo: prefix even if we only support the repository path mapping in the initial version is a good way forward. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] push: respect --no-thin
Duy Nguyen pclo...@gmail.com writes: transport_get() actually sets thin option to 1 by default. Yeah, I missed your message in the nearby thread. It indeed does. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ephemeral-branches instead of detached-head?
Duy Nguyen pclo...@gmail.com writes: On Mon, Aug 12, 2013 at 3:37 PM, David Jeske dav...@gmail.com wrote: Is there currently any way to say hey, git, show me what commits are dangling that might be lost in the reflog? How do you define dangling commits? When you do git commit --amend, the current commit will become dangling (in the sense that it's not referred by any ref, but the commit exists) and those are just noise in my opinion. fsck lost-and-found would be one way. It would be nice if we had something like (note: the following will _NOT_ work) git log -g HEAD --not --branches to say walk the reflog of HEAD, but exclude anything that can be reached from the tips of branches. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: ephemeral-branches instead of detached-head?
David Jeske dav...@gmail.com writes: When you do git commit --amend, the current commit will become dangling (in the sense that it's not referred by any ref, but the commit exists) and those are just noise in my opinion. This is *exactly* my point. There is no way to distinguish a commit which was accidentally and implicitly dangled due to checkout or submodule update on a detached head, from all those other intentionally dangling refs which were explicitly handled with merge, rebase, amend. I do not follow. Just like commit --amend, checking out another branch to leave a detached HEAD _is_ an explicit way to discard what you started experimenting behind, declaring it useless. Otherwise you would have saved it to some named branch. This of course assumes that, as you said in one of your earlier messages, the user knows what he is doing, though. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git stash takes excessively long when many untracked files present
Anders Darander anders.daran...@gmail.com writes:
diff --git a/git-stash.sh b/git-stash.sh
index 85c9e2c..e5a2043 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -263,7 +263,7 @@ save_stash () {
exit 0
fi
if test -z $untracked$force
- test -n $(git ls-files --killed | head -n 1)
+ test -n $(git ls-files --killed --directory | head -n 1)
then
say $(gettext The following untracked files would NOT be
saved
test -n $GIT_QUIET || git ls-files --killed | sed
's/^/\t/'
---
It seems to work in my extremely limited testing. Though, I'm pretty sure
that there'll be quite a few error cases... (Especially, as I just made
a naive attempt at patching git-stash, so I could go on with a few other
things).
I am not sure adding --directory there is safe. Aren't there
cases where saving a stash and going back to the committed state
will involve killing no directories, but some files? If your local
change is to remove a directory and files in it from your working
tree and then deposit a newly created file at the path where the
directory was in the HEAD, stashing that local change and then going
back to the HEAD will involve removing the new file from the working
tree, and unless you have git added the new file, it will be lost.
Do anyone have any better idea on how to approach this?
Teaching ls-files to leave early once it seens even a single
output is probably a possibility.
I see a lot of room for optimization here. Most importantly, git
ls-files --killed really doesn't need to look at any directory entry
unless something in the index would conflict with it.
This observation probably is correct, even though I didn't think
about it long enough.
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: ephemeral-branches instead of detached-head?
Junio C Hamano gits...@pobox.com writes: David Jeske dav...@gmail.com writes: When you do git commit --amend, the current commit will become dangling (in the sense that it's not referred by any ref, but the commit exists) and those are just noise in my opinion. This is *exactly* my point. There is no way to distinguish a commit which was accidentally and implicitly dangled due to checkout or submodule update on a detached head, from all those other intentionally dangling refs which were explicitly handled with merge, rebase, amend. I do not follow. Just like commit --amend, checking out another branch to leave a detached HEAD _is_ an explicit way to discard what you started experimenting behind, declaring it useless. Otherwise you would have saved it to some named branch. This of course assumes that, as you said in one of your earlier messages, the user knows what he is doing, though. By the way, by the above I do not mean checking out a named branch should not be protected. I am saying treating commits lost by running 'commit --amend' differently does not make sense to me. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git stash takes excessively long when many untracked files present
(I'm resending this as Gmail added some html parts...)
Junio C Hamano gits...@pobox.com wrote:
Anders Darander anders.daran...@gmail.com writes:
diff --git a/git-stash.sh b/git-stash.sh
index 85c9e2c..e5a2043 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -263,7 +263,7 @@ save_stash () {
exit 0
fi
if test -z $untracked$force
- test -n $(git ls-files --killed | head -n 1)
+ test -n $(git ls-files --killed --directory | head -n 1)
then
say $(gettext The following untracked files would
NOT be
saved
test -n $GIT_QUIET || git ls-files --killed | sed
's/^/\t/'
---
It seems to work in my extremely limited testing. Though, I'm pretty
sure
that there'll be quite a few error cases... (Especially, as I just
made
a naive attempt at patching git-stash, so I could go on with a few
other
things).
I am not sure adding --directory there is safe. Aren't there
cases where saving a stash and going back to the committed state
will involve killing no directories, but some files? If your local
change is to remove a directory and files in it from your working
tree and then deposit a newly created file at the path where the
directory was in the HEAD, stashing that local change and then going
back to the HEAD will involve removing the new file from the working
tree, and unless you have git added the new file, it will be lost.
Yes, it's more than likely that there are some real issues with adding -
-directory here. I just realised that in the specific case I needed to run
stash, I could do that by adding either of -u or -f as options. Obviously,
Do anyone have any better idea on how to approach this?
Teaching ls-files to leave early once it seens even a single
output is probably a possibility.
Would that mean that we're able to fail early? That's certainly an improvement,
but not a working situation.
In my case, running stash in an OpenEmbedded checkout (including untracked
directories for builds and caches), I gave up waiting on stash running ls-files
after running at 100% for more than 12 minutes. Git status returned after a
couple of seconds.
I see a lot of room for optimization here. Most importantly, git
ls-files --killed really doesn't need to look at any directory entry
unless something in the index would conflict with it.
This observation probably is correct, even though I didn't think
about it long enough.
I'd think that something like this is needed. As the index should be rather
small, compared to e.g. some large untracked directory.
Cheers,
Anders
.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git-po] [fr] first commits for French localization (#62)
Jiang Xin worldhello@gmail.com writes: Haven't seen new languages support for git l10n for over 1 year. Here comes French translation. Nice. Pulled, and will be part of -rc3. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH master] convert: The native line-ending is \r\n on MinGW
Brice Lambson bricelam at live.com writes: +1, this is a significant issue downstream in Git for Windows: https://github.com/msysgit/git/issues/57 Effectively this renders .gitattributes useless for the scenario of enforcing normalized line ending characters. +100 Folks, the problem is still there, with the very latest Git built with MinGW on Windows. Having eol=native in gitattributes means *LF* EOLs on Windows/MinGW. So, essentially, eol=native is completely broken. And this is the most useful option to put into gitattributes and share among those working on the project. Currently, I have to put eol=crlf there, and that means that those working on Linux will end up with CRLF files in their working copies. The link quoted above does contain an additional fix that resolves the problem. Thanks, --Tvangeste -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git stash takes excessively long when many untracked files present
Anders Darander anders.daran...@gmail.com writes: Do anyone have any better idea on how to approach this? Teaching ls-files to leave early once it seens even a single output is probably a possibility. Would that mean that we're able to fail early? Heh, good point. Leave once you find one path does not help the most common sane case where you do not kill any path, so it does not help us at all. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH master] convert: The native line-ending is \r\n on MinGW
Tvangeste i.4m.l...@yandex.ru writes: Brice Lambson bricelam at live.com writes: +1, this is a significant issue downstream in Git for Windows: https://github.com/msysgit/git/issues/57 Effectively this renders .gitattributes useless for the scenario of enforcing normalized line ending characters. +100 Folks, the problem is still there, with the very latest Git built with MinGW on Windows. Having eol=native in gitattributes means *LF* EOLs on Windows/MinGW. The patch in the thread you are responding to is v1.8.3-rc0~65, so as far as the upstream git.git is concerned the issue is closed, but I cannot say that inter-project coordination between us and Git for Windows are stellar (no we are not fighting against each other, but being less intimate with what the other is doing than we could be). Judging from how the original thread ended: http://thread.gmane.org/gmane.comp.version-control.git/148436/focus=221438 Eric and J6t (cc'ed) are aware of this patch that went into 1.8.3, so... -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
FGT
Dear winner, Microsoft organization is glad to pronounce your email ID as the lucky winner of £1,000,000'00 send us the following details to claims award.Do note that no ticket was sold nor ballot paper,it was conducted via random selection of so many emails and your email emerge as a beneficiary send us the following details. Name in Full: Date of birth: Gender: Full Address: Mobile Number: Job: Thank you. IRENE TINA MICROSOFT. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] unpack-trees: plug a memory leak
From: Felipe Contreras felipe.contre...@gmail.com
Before overwriting the destination index, first let's discard its
contents.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Tested-by: Лежанкин Иван abys...@gmail.com wrote:
---
Felipe sent this patch as part of multiple series in June, but it can
stand on its own. This version is trivially rebased against master.
The leak seems to have been introduced by 34110cd4 (2008-03-06,
Make 'unpack_trees()' have a separate source and destination index).
unpack-trees.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index bf01717..1a61e6f 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1154,8 +1154,10 @@ int unpack_trees(unsigned len, struct tree_desc *t,
struct unpack_trees_options
o-src_index = NULL;
ret = check_updates(o) ? (-2) : 0;
- if (o-dst_index)
+ if (o-dst_index) {
+ discard_index(o-dst_index);
*o-dst_index = o-result;
+ }
done:
clear_exclude_list(el);
--
1.8.3.3
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
re-ignoring a force added file
Dear Git Mailing List, I have force added a file we usually like to ignore (but keep in the repository). That was a change a while ago, and cannot be undone without serious pain. I would like to re-ignore the file though, as we dont want to track changes to it. Some of the options I came across are not useful for me. For example git rm --cached FILE // removes the file from the remote repository if I push, not desirable git update-index --assume-unchanged //Will ignore changes to the file locally, but someone else clones and the file is tracked for them. What we would like is to go back to the old state of affairs: the file was in the working directory when someone cloned from the remote repository, but changes to the file werent tracked or committed. Any help would be appreciated. regards Raza -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Rewriting git-repack in C
Hello, a few days ago, I asked how I would proceed if I'd want to rewrite git-repack. The general consensus (Duy, Junio and Matthieu) was to not touch git-pack-objects, but rather translate the shell version of the git-repack to C. I'll send a very rough patch, which still contains 2 todos, so it is not yet feature complete. I was using the run_command api and the string-list api a lot. The following patch is definitle not recommended for a fine review, but I'd still ask for feedback, whether this seems like the right approach. Also I'd like to propose a small technical change: I found no easy way to get a subset of files in a specific directory, which is very easy in the shell version via * (rm file/in/dir/startswithprefix-*), So maybe instead of just prefixing the temporary files such as: $PACKDIR/.tmp-$PID-pack-* we could put all the temporary files in a temporary directory. This would come handy as there already exists functions to manipulate a directory recursively (such as remove_dir_recursively) That patch requires the patches of jc/parseopt-command-modes Stefan Stefan Beller (1): repack: rewrite the shell script in C. Makefile | 2 +- builtin.h | 1 + builtin/repack.c | 313 + contrib/examples/git-repack.sh | 194 + git-repack.sh | 194 - git.c | 1 + 6 files changed, 510 insertions(+), 195 deletions(-) create mode 100644 builtin/repack.c create mode 100755 contrib/examples/git-repack.sh delete mode 100755 git-repack.sh -- 1.8.4.rc2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] repack: rewrite the shell script in C.
This is the beginning of the rewrite of the repacking.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
Makefile | 2 +-
builtin.h | 1 +
builtin/repack.c | 313 +
contrib/examples/git-repack.sh | 194 +
git-repack.sh | 194 -
git.c | 1 +
6 files changed, 510 insertions(+), 195 deletions(-)
create mode 100644 builtin/repack.c
create mode 100755 contrib/examples/git-repack.sh
delete mode 100755 git-repack.sh
diff --git a/Makefile b/Makefile
index 3588ca1..69e5267 100644
--- a/Makefile
+++ b/Makefile
@@ -464,7 +464,6 @@ SCRIPT_SH += git-pull.sh
SCRIPT_SH += git-quiltimport.sh
SCRIPT_SH += git-rebase.sh
SCRIPT_SH += git-remote-testgit.sh
-SCRIPT_SH += git-repack.sh
SCRIPT_SH += git-request-pull.sh
SCRIPT_SH += git-stash.sh
SCRIPT_SH += git-submodule.sh
@@ -971,6 +970,7 @@ BUILTIN_OBJS += builtin/reflog.o
BUILTIN_OBJS += builtin/remote.o
BUILTIN_OBJS += builtin/remote-ext.o
BUILTIN_OBJS += builtin/remote-fd.o
+BUILTIN_OBJS += builtin/repack.o
BUILTIN_OBJS += builtin/replace.o
BUILTIN_OBJS += builtin/rerere.o
BUILTIN_OBJS += builtin/reset.o
diff --git a/builtin.h b/builtin.h
index 8afa2de..b56cf07 100644
--- a/builtin.h
+++ b/builtin.h
@@ -102,6 +102,7 @@ extern int cmd_reflog(int argc, const char **argv, const
char *prefix);
extern int cmd_remote(int argc, const char **argv, const char *prefix);
extern int cmd_remote_ext(int argc, const char **argv, const char *prefix);
extern int cmd_remote_fd(int argc, const char **argv, const char *prefix);
+extern int cmd_repack(int argc, const char **argv, const char *prefix);
extern int cmd_repo_config(int argc, const char **argv, const char *prefix);
extern int cmd_rerere(int argc, const char **argv, const char *prefix);
extern int cmd_reset(int argc, const char **argv, const char *prefix);
diff --git a/builtin/repack.c b/builtin/repack.c
new file mode 100644
index 000..bfec56d
--- /dev/null
+++ b/builtin/repack.c
@@ -0,0 +1,313 @@
+/*
+ * The shell version was written by Linus Torvalds (2005) and many others.
+ * This is a translation into C by Stefan Beller (2013)
+ */
+
+#include builtin.h
+#include cache.h
+#include dir.h
+#include parse-options.h
+#include run-command.h
+#include sigchain.h
+#include strbuf.h
+#include string-list.h
+
+#include sys/types.h
+#include unistd.h
+#include stdio.h
+#include dirent.h
+
+static const char * const git_repack_usage[] = {
+ N_(git repack [options]),
+ NULL
+};
+
+static int delta_base_offset = 1; // enabled by default since 22c79eab
(2008-06-25)
+
+static int repack_config(const char *var, const char *value, void *cb)
+{
+ if (!strcmp(var, repack.usedeltabaseoffset)) {
+ delta_base_offset = git_config_bool(var, value);
+ return 0;
+ }
+ return git_default_config(var, value, cb);
+}
+
+static void remove_pack_on_signal(int signo)
+{
+ struct strbuf packtmpbuf = STRBUF_INIT;
+ /* todo: the files are not in a subdirectory, but only a subset in
%s/pack, see disscussion */
+ strbuf_addf(packtmpbuf, %s/pack/.tmp-%d-pack,
get_object_directory(), getpid());
+ remove_dir_recursively(packtmpbuf, 0);
+ sigchain_pop(signo);
+ raise(signo);
+}
+
+int cmd_repack(int argc, const char **argv, const char *prefix) {
+
+ int pack_everything = 0;
+ int pack_everything_but_loose = 0;
+ int delete_redundant = 0;
+ int unpack_unreachable = 0;
+ int window = 0, window_memory = 0;
+ int depth = 0;
+ int max_pack_size = 0;
+ int no_reuse_delta = 0, no_reuse_object = 0;
+ int no_update_server_info = 0;
+ int quiet = 0;
+ int local = 0;
+ char *packdir, *packtmp;
+ const char *cmd_args[20];
+ int cmd_i = 0;
+ struct child_process cmd;
+
+ struct option builtin_repack_options[] = {
+ OPT_BOOL('a', all, pack_everything,
+ N_(pack everything in a single pack)),
+ OPT_BOOL('A', all-but-loose, pack_everything_but_loose,
+ N_(same as -a, and turn unreachable objects
loose)),
+ OPT_BOOL('d', delete-redundant, delete_redundant,
+ N_(remove redundant packs, and run
git-prune-packed)),
+ OPT_BOOL('f', no-reuse-delta, no_reuse_delta,
+ N_(pass --no-reuse-delta to
git-pack-objects)),
+ OPT_BOOL('F', no-reuse-object, no_reuse_object,
+ N_(pass --no-reuse-object to
git-pack-objects)),
+ OPT_BOOL('n', NULL, no_update_server_info,
+ N_(do not run git-update-server-info)),
+ OPT__QUIET(quiet, N_(be quiet)),
+ OPT_BOOL('l', local, local,
+
Re: [PATCH 3/3] contacts: reduce git-blame invocations
Eric Sunshine sunsh...@sunshineco.com writes:
git-contacts invokes git-blame once for each patch hunk it encounters.
No attempt is made to consolidate invocations for multiple hunks
referencing the same file at the same revision. This can become
expensive quickly.
Reduce the number of git-blame invocations by taking advantage of the
ability to specify multiple -L ranges for a single invocation.
Without this patch, on a randomly chosen range of commits:
% time git-contacts 25fba78d36be6297^..23c339c0f262aad2 /dev/null
real 0m6.142s
user 0m5.429s
sys 0m0.356s
With this patch:
% time git-contacts 25fba78d36be6297^..23c339c0f262aad2 /dev/null
real 0m2.285s
user 0m2.093s
sys 0m0.165s
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
Nice. Will queue.
---
contrib/contacts/git-contacts | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/contrib/contacts/git-contacts b/contrib/contacts/git-contacts
index b4d3526..fb6429b 100755
--- a/contrib/contacts/git-contacts
+++ b/contrib/contacts/git-contacts
@@ -59,9 +59,11 @@ sub import_commits {
}
sub get_blame {
- my ($commits, $source, $start, $len, $from) = @_;
+ my ($commits, $source, $from, $ranges) = @_;
+ return unless @$ranges;
open my $f, '-|',
- qw(git blame --porcelain -C), '-L', $start,+$len,
+ qw(git blame --porcelain -C),
+ map({-L$_-[0],+$_-[1]} @$ranges),
'--since', $since, $from^, '--', $source or die;
while ($f) {
if (/^([0-9a-f]{40}) \d+ \d+ \d+$/) {
@@ -78,10 +80,7 @@ sub blame_sources {
my ($sources, $commits) = @_;
for my $s (keys %$sources) {
for my $id (keys %{$sources-{$s}}) {
- for my $range (@{$sources-{$s}{$id}}) {
- get_blame($commits, $s,
- $range-[0], $range-[1], $id);
- }
+ get_blame($commits, $s, $id, $sources-{$s}{$id});
}
}
}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] unpack-trees: plug a memory leak
René Scharfe l@web.de writes:
From: Felipe Contreras felipe.contre...@gmail.com
Before overwriting the destination index, first let's discard its
contents.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Tested-by: Лежанкин Иван abys...@gmail.com wrote:
---
Felipe sent this patch as part of multiple series in June, but it can
stand on its own. This version is trivially rebased against master.
The leak seems to have been introduced by 34110cd4 (2008-03-06,
Make 'unpack_trees()' have a separate source and destination index).
It was lost in the follow-up discussion and I missed it.
I assume that this is signed-off by you as a forwarder? I'd prefer
to even mark it Reviewed-by: you.
Thanks.
unpack-trees.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index bf01717..1a61e6f 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1154,8 +1154,10 @@ int unpack_trees(unsigned len, struct tree_desc *t,
struct unpack_trees_options
o-src_index = NULL;
ret = check_updates(o) ? (-2) : 0;
- if (o-dst_index)
+ if (o-dst_index) {
+ discard_index(o-dst_index);
*o-dst_index = o-result;
+ }
done:
clear_exclude_list(el);
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] unpack-trees: plug a memory leak
Am 13.08.2013 23:12, schrieb Junio C Hamano: René Scharfe l@web.de writes: From: Felipe Contreras felipe.contre...@gmail.com Before overwriting the destination index, first let's discard its contents. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com Tested-by: Лежанкин Иван abys...@gmail.com wrote: --- Felipe sent this patch as part of multiple series in June, but it can stand on its own. This version is trivially rebased against master. The leak seems to have been introduced by 34110cd4 (2008-03-06, Make 'unpack_trees()' have a separate source and destination index). It was lost in the follow-up discussion and I missed it. I had forgotten about it as well, until Felipe mentioned it again. I assume that this is signed-off by you as a forwarder? I'd prefer to even mark it Reviewed-by: you. Right, I did review the patch and you can tag it as such. Thanks, René -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git stash takes excessively long when many untracked files present
[administrivia: people on the original thread added back on CC] Junio C Hamano gits...@pobox.com writes: Anders Darander anders.daran...@gmail.com writes: Do anyone have any better idea on how to approach this? Teaching ls-files to leave early once it seens even a single output is probably a possibility. Would that mean that we're able to fail early? Heh, good point. Leave once you find one path does not help the most common sane case where you do not kill any path, so it does not help us at all. In any case, this is a regression introduced in 'master' since the last release, and the attempted fix was for an issue that has long been with us, so I'll revert a7365313 (git stash: avoid data loss when git stash save kills a directory, 2013-06-28) soon. For today's -rc3, I'm already deep into the integration cycle, so it is too late to do the revert it and then redo everything. Then we will plan to re-apply the patch once ls-files --killed gets fixed not to waste too much cycles needlessly, after the coming release. Thanks for a report and discussion. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] unpack-trees: plug a memory leak
René Scharfe l@web.de writes: It was lost in the follow-up discussion and I missed it. I had forgotten about it as well, until Felipe mentioned it again. I assume that this is signed-off by you as a forwarder? I'd prefer to even mark it Reviewed-by: you. Right, I did review the patch and you can tag it as such. OK, will queue and soon merge to and cook in 'next'. Thanks, everybody. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
What's cooking in git.git (Aug 2013, #03; Tue, 13)
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 -rc3 has been tagged; we will need to revert a7365313 (git stash: avoid data loss when git stash save kills a directory, 2013-06-28) that is killing git stash in repositories with too many untracked cruft before the final, with a plan to reapply it after trying to whip ls-files --killed into a reasonable performer, which needs to happen after the final. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [Graduated to master] * sb/mailmap-updates (2013-08-12) 1 commit + .mailmap: update long-lost friends with multiple defunct addresses -- [New Topics] * es/blame-L-twice (2013-08-06) 16 commits (merged to 'next' on 2013-08-08 at 9d6f821) + line-range: reject -L line numbers less than 1 + t8001/t8002: blame: add tests of -L line numbers less than 1 + line-range: teach -L^:RE to search from start of file + line-range: teach -L:RE to search from end of previous -L range + line-range: teach -L^/RE/ to search from start of file + line-range-format.txt: document -L/RE/ relative search + log: teach -L/RE/ to search from end of previous -L range + blame: teach -L/RE/ to search from end of previous -L range + line-range: teach -L/RE/ to search relative to anchor point + blame: document multiple -L support + t8001/t8002: blame: add tests of multiple -L options + blame: accept multiple -L ranges + blame: inline one-line function into its lone caller + range-set: publish API for re-use by git-blame -L + line-range-format.txt: clarify -L:regex usage form + git-log.txt: place each -L option variation on its own line (this branch is used by es/contacts-blame-L-multi; uses es/blame-L-more.) Teaches git blame to take more than one -L ranges. Will cook in 'next'. * mm/no-shell-escape-in-die-message (2013-08-07) 1 commit (merged to 'next' on 2013-08-08 at bddff86) + die_with_status: use printf '%s\n', not echo Fixes a minor bug in git rebase -i (there could be others, as the root cause is pretty generic) where the code feeds a random, data dependeant string to 'echo' and expects it to come out literally. Will cook in 'next'. * tr/fd-gotcha-fixes (2013-08-06) 1 commit (merged to 'next' on 2013-08-08 at f452c5b) + t0070: test that git_mkstemps correctly checks return value of open() Finishing touches to an earlier fix already in 'master'. Will cook in 'next'. * ap/remote-hg-tilde-is-home-directory (2013-08-09) 1 commit - remote-hg: fix path when cloning with tilde expansion Will merge to and cook in 'next'. * es/rebase-i-no-abbrev (2013-08-11) 3 commits - rebase: interactive: fix short SHA-1 collision - t3404: rebase: interactive: demonstrate short SHA-1 collision - t3404: restore specialized rebase-editor following commentchar test Will merge to and cook in 'next'. * fc/remote-hg-shared-setup (2013-08-11) 2 commits - remote-hg: add shared repo upgrade - remote-hg: ensure shared repo is initialized Will merge to and cook in 'next'. * jc/transport-do-not-use-connect-twice-in-fetch (2013-08-07) 5 commits - fetch: work around transport-take-over hack - fetch: refactor code that fetches leftover tags - fetch: refactor code that prepares a transport - fetch: rename file-scope global transport to gtransport - t5802: add test for connect helper The auto-tag-following code in git fetch tries to reuse the same transport twice when the serving end does not cooperate and does not give tags that point to commits that are asked for as part of the primary transfer. Unfortunately, Git-aware transport helper interface is not designed to be used more than once, hence this does not work over smart-http transfer. I'll try to see if this workaround can be done in a cleaner way before merging this to 'next'. * ks/p4-view-spec (2013-08-11) 3 commits - WAITING FOR ACK - git p4: implement view spec wildcards with p4 where - git p4 test: sanitize P4CHARSET Waiting for an ack. * mm/war-on-whatchanged (2013-08-13) 2 commits - whatchanged: document its historical nature - core-tutorial: trim the section on Inspecting Changes Will merge to and cook in 'next'. * nd/gc-lock-against-each-other (2013-08-09) 1 commit - gc: reject if another gc is running, unless --force is given Will merge to and cook in 'next'. * rt/doc-merge-file-diff3 (2013-08-09) 1 commit - Documentation/git-merge-file: document option --diff3 Will merge to and cook in 'next'. * sb/misc-cleanup (2013-08-09) 3 commits - rm: remove unneeded null pointer check - diff: fix a possible null pointer dereference - diff: remove ternary operator evaluating always to true Will merge to and cook in 'next'. *
[ANNOUNCE] Git v1.8.4-rc3
A release candidate Git v1.8.4-rc3 is now available for testing at the usual places. Things have calmed down on the 'master' front; we will still need to revert one commit that killed git stash in a large directory with a lot of cruft before the final, but other than that, everything else should be pretty much the same as what we will see in the final release. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: 4017553f4543c00c392a299b6a67f8ca4ca5e325 git-1.8.4.rc3.tar.gz 1a3a6c6a59df7b60377a0ae86f04b8b0f09e45f4 git-htmldocs-1.8.4.rc3.tar.gz 19281d6fb14e66c5b215bad52e3857418052bfeb git-manpages-1.8.4.rc3.tar.gz The following public repositories all have a copy of the v1.8.4-rc3 tag and the master branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v1.8.4 Release Notes (draft) Backward compatibility notes (for Git 2.0) -- When git push [$there] does not say what to push, we have used the traditional matching semantics so far (all your branches were sent to the remote as long as there already are branches of the same name over there). In Git 2.0, the default will change to the simple semantics that pushes: - only the current branch to the branch with the same name, and only when the current branch is set to integrate with that remote branch, if you are pushing to the same remote as you fetch from; or - only the current branch to the branch with the same name, if you are pushing to a remote that is not where you usually fetch from. Use the user preference configuration variable push.default to change this. If you are an old-timer who is used to the matching semantics, you can set the variable to matching to keep the traditional behaviour. If you want to live in the future early, you can set it to simple today without waiting for Git 2.0. When git add -u (and git add -A) is run inside a subdirectory and does not specify which paths to add on the command line, it will operate on the entire tree in Git 2.0 for consistency with git commit -a and other commands. There will be no mechanism to make plain git add -u behave like git add -u .. Current users of git add -u (without a pathspec) should start training their fingers to explicitly say git add -u . before Git 2.0 comes. A warning is issued when these commands are run without a pathspec and when you have local changes outside the current directory, because the behaviour in Git 2.0 will be different from today's version in such a situation. In Git 2.0, git add path will behave as git add -A path, so that git add dir/ will notice paths you removed from the directory and record the removal. Versions before Git 2.0, including this release, will keep ignoring removals, but the users who rely on this behaviour are encouraged to start using git add --ignore-removal path now before 2.0 is released. Updates since v1.8.3 Foreign interfaces, subsystems and ports. * Cygwin port has been updated for more recent Cygwin 1.7. * git rebase -i now honors --strategy and -X options. * Git-gui has been updated to its 0.18.0 version. * MediaWiki remote helper (in contrib/) has been updated to use the credential helper interface from Git.pm. * Update build for Cygwin 1.[57]. Torsten Bögershausen reports that this is fine with Cygwin 1.7 ($gmane/225824) so let's try moving it ahead. * The credential helper to talk to keychain on OS X (in contrib/) has been updated to kick in not just when talking http/https but also imap(s) and smtp. * Remote transport helper has been updated to report errors and maintain ref hierarchy used to keep track of its own state better. * With export remote-helper protocol, (1) a push that tries to update a remote ref whose name is different from the pushing side does not work yet, and (2) the helper may not know how to do --dry-run; these problematic cases are disabled for now. * git-remote-hg/bzr (in contrib/) updates. * git-remote-mw (in contrib/) hints users to check the certificate, when https:// connection failed. * git-remote-mw (in contrib/) adds a command to allow previewing the contents locally before pushing it out, when working with a MediaWiki remote. UI, Workflows Features * Sample post-receive-email hook script got an enhanced replacement multimail (in contrib/). * Also in contrib/ is a new contacts script that runs git blame to find out the people who may be interested in a set of changes. * git clean command learned an interactive mode. * The --head option to git show-ref was only to add HEAD to the
Re: ephemeral-branches instead of detached-head?
On 08/13/2013 10:19 PM, Junio C Hamano wrote: Duy Nguyen pclo...@gmail.com writes: On Mon, Aug 12, 2013 at 3:37 PM, David Jeske dav...@gmail.com wrote: Is there currently any way to say hey, git, show me what commits are dangling that might be lost in the reflog? How do you define dangling commits? When you do git commit --amend, the current commit will become dangling (in the sense that it's not referred by any ref, but the commit exists) and those are just noise in my opinion. fsck lost-and-found would be one way. It would be nice if we had something like (note: the following will _NOT_ work) git log -g HEAD --not --branches to say walk the reflog of HEAD, but exclude anything that can be reached from the tips of branches. I've been using the following 3 aliases for some time now, to find various dangling stuff. The middle one (d1) seems to do approximately what you want, but will probably fail on repos with lots of activity when the command line length limit is (b)reached. # all stashed entries (since they don't chain) sk = !gitk --date-order $(git stash list | cut -d: -f1) --not --branches --tags --remotes # all reflog entries that are not on a branch, tag, or remote d1 = !gitk --date-order $(git log -g --pretty=%H) --not --branches --tags --remotes # all dangling commits not on a branch, tag, or remote d2 = !gitk --date-order $(git fsck | grep dangling.commit | cut -f3 -d' ') --not --branches --tags --remotes (Apologies if something like this was already said; I was not following the discussion closely enough to notice) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ephemeral-branches instead of detached-head?
Sitaram Chamarty sitar...@gmail.com writes: # all reflog entries that are not on a branch, tag, or remote d1 = !gitk --date-order $(git log -g --pretty=%H) --not --branches --tags --remotes # all dangling commits not on a branch, tag, or remote d2 = !gitk --date-order $(git fsck | grep dangling.commit | cut -f3 -d' ') --not --branches --tags --remotes (Apologies if something like this was already said; I was not following the discussion closely enough to notice) Yup. A potential problem is that the output from log -g --pretty=%H or fsck | grep dangling may turn out to be humongous. Other than that, they correctly compute what you want. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Possible git bug
Hey, Not sure if this is a bug or not. I commonly am finding myself wanting to remove some recent commits, either all or just a select few. So I use rebase in interactive mode for this. The problem I find is that when I do a rebase and leave no commits to pick (where I would think that this would do the same as a reset --hard) just tells me that there is nothing to be done. So would that be a bug? Or maybe a feature? I would like it that when you do a rebase and select no commits, it will rebase ontop of the commit you chose, and remove all the commits not shown in the interactive listing (so all). Any ideas are welcome. Cheers, Hugh -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible git bug
On Wed, Aug 14, 2013 at 6:50 AM, Hugh Davenport h...@davenport.net.nz wrote: Hey, Not sure if this is a bug or not. I commonly am finding myself wanting to remove some recent commits, either all or just a select few. So I use rebase in interactive mode for this. The problem I find is that when I do a rebase and leave no commits to pick (where I would think that this would do the same as a reset --hard) just tells me that there is nothing to be done. This is left as a way to abort a rebase if you change your mind just before actually executing it. This also works parallel to committing with an empty commit message. So would that be a bug? Or maybe a feature? I would like it that when you do a rebase and select no commits, it will rebase ontop of the commit you chose, and remove all the commits not shown in the interactive listing (so all). You can just use `git reset --hard commit to rollback to` to discard all commits after the given commit (Unless they're part of another branch, of course). `git reset --soft` if you want to keep the state of your current working directory. Cheers, Daniel -- typed with http://neo-layout.org -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
