Re: [PATCH 2/2] am: plug FILE * leak in split_mail_conv()
On Thu, May 12, 2016 at 6:47 AM, Jeff King <p...@peff.net> wrote:
> On Wed, May 11, 2016 at 04:35:46PM -0700, Junio C Hamano wrote:
>
>> Signed-off-by: Junio C Hamano <gits...@pobox.com>
>> ---
>> builtin/am.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/builtin/am.c b/builtin/am.c
>> index f1a84c6..a373928 100644
>> --- a/builtin/am.c
>> +++ b/builtin/am.c
>> @@ -761,9 +761,11 @@ static int split_mail_conv(mail_conv_fn fn, struct
>> am_state *state,
>> mail = mkpath("%s/%0*d", state->dir, state->prec, i + 1);
>>
>> out = fopen(mail, "w");
>> - if (!out)
>> + if (!out) {
>> + fclose(in);
>> return error(_("could not open '%s' for writing: %s"),
>> mail, strerror(errno));
>> + }
>
> Presumably `fclose` doesn't ever overwrite errno in practice, but I
> guess it could in theory.
It probably does pretty often in general, but not when the file is
opened for input only.
--
Mikael Magnusson
--
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 0/1] Introduce a way to create a branch and worktree at the same time
On Thu, Mar 10, 2016 at 2:21 PM, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > Hi Duy, > > On Thu, 10 Mar 2016, Duy Nguyen wrote: > >> On Thu, Mar 10, 2016 at 6:34 PM, Johannes Schindelin >> <johannes.schinde...@gmx.de> wrote: >> > One possible improvement would be to add "/xyz/" to the parent >> > repository's .git/info/exclude, but this developer hesitates to >> > introduce that feature without the "delete" counterpart: those exclude >> > entries would likely go stale very quickly. Besides, there might be a >> > plan in the working to exclude worktrees automagically? >> >> That's needed because you add a worktree inside another worktree? I >> know that feeling, but I've changed my layout from ~/w/git as main >> worktree (and ~/w/git/.git as repo) to ~/w/git as a non-worktree dir >> that contains all worktrees, e.g. ~/w/git/reinclude-dir, >> ~/w/git/worktree-config, ~/w/git/lmdb... My typical worktree add >> command is "git worktree add ../" then move there and do >> stuff. No nested worktrees, no need to update exclude file (and no >> messing up emacs' rgrep command, which does not understand .gitignore >> anyway) > > This feels to me like it is working around the problem rather than solving > it. My worktrees are inside the corresponding top-level project for a > reason: I work with multiple projects, and having all of their worktrees > in a single $HOME/w/ directory would be rather confusing to me. > > I really want to keep my Git worktrees inside /usr/src/git/ (in Git for > Windows' SDK). You can have /usr/src/git/master, /usr/src/git/some-work-tree, etc, and /usr/src/git itself is not a git repository at all. That way /usr/src only has one git-related directory and no worktrees are nested. The only downside is if you work in master most of the time, you have to type "/master" more. I think this is what Duy suggested too, but you interpreted it as having /usr/src/git-master, /usr/src/git-some-work-tree etc? -- Mikael Magnusson -- 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: Forcing git to pack objects
On Sat, Dec 19, 2015 at 2:03 AM, Edmundo Carmona Antoranz <eantor...@gmail.com> wrote: > Hi! > > Recently I was running manually a git gc --prune command (wanted to > shrink my 2.8G .git directory by getting rid of loose objects) and I > ended up running out of space on my HD. After freaking out a little > bit (didn't know if the repo would end up in a 'stable' state), I > ended up freeing up some space and I again have a working repo... > _but_ I noticed that basically _all_ objects on my repo are laying > around in directories .git/objects/00 to ff (and taking a whole lot of > space... like the .git directory is now like 5 GBs). After running git > gc manually again it ended up taking a lot of time and the objects are > still there. Also git svn sometimes gcs after fetching and it took to > run cause of the gc execution (ended up killing it) and the files are > still there. Is it possible to ask git to put all those objects in > .pack files? Or did I mess something on my repo? > > Just in case, that's a repo I use at work that's working on a windows > box (git for windows 2.6.3). > > Thanks in advance. git repack -d should do it. -- Mikael Magnusson -- 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] Optimize usage of grep by passing -q
On Mon, Nov 16, 2015 at 10:43 PM, Stefan Beller <sbel...@google.com> wrote: > Instead of redirecting all grep output to /dev/null, we can just > pass in -q instead. This preserves the exit code behavior, but is faster. > As grep returns true if it finds at least one match, grep can exit promptly > after finding the first line and doesn't need to find more occurrences > which would be redirected to /dev/null anyways. > > This is true for the gnu version of grep. I am not sure if all > versions of grep support this optimization. In case it is not, > we'd revert this patch. POSIX specifies -q, so you should be fine. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/grep.html -- Mikael Magnusson -- 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 feature request: mark a commit as minor
On Sat, Oct 3, 2015 at 8:11 AM, Jacob Keller <jacob.kel...@gmail.com> wrote: > On Fri, Oct 2, 2015 at 2:38 PM, Felipe Micaroni Lalli > <micar...@walltime.info> wrote: >> A minor change (also called "cosmetic") usually is a typo fix, doc >> improvement, a little code refactoring that don't change the behavior etc. >> >> In Wikipedia we can mark an edition as "minor". >> >> It would be nice to have an argument like "--minor" in git-commit to >> mark the commit as minor. Also, filter in git-log (like --hide-minor) to >> hide the minor changes. The git-log could be optimized to show minor >> commits more discreetly. >> >> > > This should just be part of the commit message log, generally projects > use something like TRIVIAL in the patch subject or similar. You could > also standardize for your project(s) what would be considered a minor > change. The issue is that not everyone considers these changes as > "minor". You should be able to use a combination of the --grep option > in log to search for all commits who don't contain that string in the > right format. Could also be a good use for notes, since you might want to add this markup after the fact. -- Mikael Magnusson -- 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: [FEATURE REQUEST] Filter-branch extend progress with a simple estimated time remaning
On Sun, Aug 30, 2015 at 10:11 AM, Gabor Bernat ber...@primeranks.net wrote: this can work instead of the data command for getting the time elapsed, however for getting the actual date of a timestamp is not possible generally; so I think I will just remove that part. Bernát GÁBOR On Sun, Aug 30, 2015 at 10:04 AM, Mikael Magnusson mika...@gmail.com wrote: On Sun, Aug 30, 2015 at 5:15 AM, Eric Sunshine sunsh...@sunshineco.com wrote: (Please don't top-post on this list.) Ah, I got caught up on the ETA part. Do note that date +%s is also a gnu extension and won't work everywhere. -- Mikael Magnusson -- 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: [FEATURE REQUEST] Filter-branch extend progress with a simple estimated time remaning
On Sun, Aug 30, 2015 at 6:58 PM, Gabor Bernat ber...@primeranks.net wrote:
I would argue against the every n commit check, or at least making it
configurable, as in my case the speed is something between 0.01 and
1.5 seconds per commit. Checking it every n commit would make it I
feel quite slow to adapt. But it's debatable.
You must have missed the previous times someone said this, but please
don't top post on this list.
Here are some timings for running the command in question 1000 times
on my computer:
awk 'BEGIN{srand();print srand()}'
0.32s user 1.20s system 65% cpu 2.332 total
perl -e 'print time'
0.69s user 1.45s system 73% cpu 2.921 total
date +%s
0.27s user 0.99s system 78% cpu 1.604 total
and for comparison,
/bin/true
0.02s user 0.26s system 24% cpu 1.127 total
--
Mikael Magnusson
--
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: [FEATURE REQUEST] Filter-branch extend progress with a simple estimated time remaning
On Sun, Aug 30, 2015 at 5:15 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
(Please don't top-post on this list.)
On Sat, Aug 29, 2015 at 11:00 PM, Gabor Bernat ber...@primeranks.net wrote:
Reading after it, I think the most close we can get with this is, awk
'BEGIN { print strftime(%c, 1271603087); }; and just ignore setting
this value (and avoid displaying it) if that fails too. Do you agree?
strftime() in awk is a GNU-ism. It doesn't exist in awk on Mac OS X or
FreeBSD, or even the default awk on Linux (which is mawk on Linux
installations I've checked).
Most portable likely would be Perl, however, that's probably too
heavyweight inside a loop like this, even if called only once each N
iterations.
http://stackoverflow.com/questions/2445198/get-seconds-since-epoch-in-any-posix-compliant-shell
Found this,
awk 'BEGIN{srand();print srand()}'
srand() in awk returns the previous seed value, and calling it without
an argument sets it to time of day, so the above sequence should
return seconds since the epoch, or at least something in seconds that
is relative to a fixed point which is all that's needed in this
thread.
--
Mikael Magnusson
--
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 v5 2/2] worktree: add 'list' command
On Sat, Aug 22, 2015 at 11:51 PM, Michael Rappazzo rappa...@gmail.com wrote: 'git worktree list' uses the for_each_worktree function to iterate, and outputs in the format: 'worktree (short-ref)' Signed-off-by: Michael Rappazzo rappa...@gmail.com --- Documentation/git-worktree.txt | 11 +- builtin/worktree.c | 55 t/t2027-worktree-list.sh | 81 ++ 3 files changed, 146 insertions(+), 1 deletion(-) create mode 100755 t/t2027-worktree-list.sh diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt index fb68156..e953b4e 100644 --- a/Documentation/git-worktree.txt +++ b/Documentation/git-worktree.txt @@ -11,6 +11,7 @@ SYNOPSIS [verse] 'git worktree add' [-f] [--detach] [-b new-branch] path [branch] 'git worktree prune' [-n] [-v] [--expire expire] +'git worktree list' [--path-only] DESCRIPTION --- @@ -59,6 +60,12 @@ prune:: Prune working tree information in $GIT_DIR/worktrees. +list:: + +List the main worktree followed by all of the linked worktrees. The default +format of the list includes the full path to the worktree and the branch or +revision that the head of that worktree is currently pointing to. Maybe just and the branch or revision currently checked out in that worktree.? -- Mikael Magnusson -- 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: Draft of Git Rev News edition 6
On Fri, Aug 7, 2015 at 12:18 AM, Thomas Ferris Nicolaisen tfn...@gmail.com wrote: On Mon, Aug 3, 2015 at 10:49 PM, Thomas Ferris Nicolaisen tfn...@gmail.com wrote: I hope we can attract more contributors in the future, so the weight of this doesn't lie too much on his shoulders. Perhaps we should send out the draft earlier next time, and beckon for more contributions from the list. Just to follow up on this point: The draft for the next edition is available here (still empty): https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-7.md Suggestions and comments can go here: https://github.com/git/git.github.io/issues/94 We could also add a call-for-help at the bottom of the respective section, asking people who are trawling the mailing list to contribute. You may have spotted that I added this in the recently published edition, but I think it can bear repeating here for git@vger: It is surprisingly difficult to get to the actual post of edition 6 from this thread. The link in the original post is just a 404, and to get to it from the link in this mail, which you might not have sent at all, I had to click like 5 things, and a few of those turned out to be dead ends. I suppose once you know where they are published, it is easy to find, but I did not :). -- Mikael Magnusson -- 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: [ANNOUNCE] Git v2.5.0
On Mon, Jul 27, 2015 at 10:47 PM, Junio C Hamano gits...@pobox.com wrote: The latest feature release Git v2.5.0 is now available at the usual places. It is comprised of 583 non-merge commits since v2.4.0, contributed by 70 people, 21 of which are new faces. ... Git 2.5 Release Notes = Updates since v2.4 -- UI, Workflows Features ... * A replacement for contrib/workdir/git-new-workdir that does not rely on symbolic links and make sharing of objects and refs safer by making the borrowee and borrowers aware of each other. Consider this as still an experimental feature; its UI is still likely to change. It might be helpful to list what the replacement actually is in this entry. -- Mikael Magnusson -- 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: [RFC/PATCH] worktree: replace checkout --to with worktree new
On Wed, Jul 1, 2015 at 12:27 AM, Junio C Hamano gits...@pobox.com wrote: Eric Sunshine sunsh...@sunshineco.com writes: On Tue, Jun 30, 2015 at 12:56 AM, Eric Sunshine sunsh...@sunshineco.com wrote Speaking of git worktree new --force, should we revisit git checkout --ignore-other-worktrees before it gets set in stone? In particular, I'm wondering if it makes sense to overload git-checkout's existing --force option to encompass the functionality of --ignore-other-worktrees as well. I don't think there would be any semantic conflict by overloading --force, and I do think that --force is more discoverable and more intuitive. git checkout -f is to throw-away local changes, which is a very sensible thing to do and I can see why that would be useful, but does --ignore-other-worktrees have the same kind of common-ness? It primarily is a safety measure, and if the user wants to jump around freely to different commits in multiple worktrees, a more sensible thing to do so without getting the nono, you have that branch checked out elsewhere is to detach HEADs in the non-primary worktrees that may want to have the same commit checked out as the current branch of the primary worktree. I would mildly object to make --ignore-other-worktrees more discoverable and moderately object to make that feature more accessible by overloading it into --force. I personally would not mind if we removed --ignore-other-worktrees, but that might be going too far ;-) This probably falls under not common, but one of my uses for git new-workdir is to check out the current branch in another directory, rebase it to upstream, delete that worktree, and then git reset --hard in the original checkout. The result is a rebased branch that touches a minimum of source files so the rebuild is faster. (In some projects I have a lot of local commits that get rebased, but maybe upstream only touched a single .c file). -- Mikael Magnusson -- 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/RFC v2 2/2] git-am: add am.threeWay config variable
On Tue, Jun 2, 2015 at 3:24 PM, Remi Lespinet remi.lespi...@ensimag.grenoble-inp.fr wrote: Add the am.threeWay configuration variable to use the -3 or --3way option of git am by default. When am.threeway is set and not desired for a specific git am command, the --no-3way option can be used to override it. Signed-off-by: Remi Lespinet remi.lespi...@ensimag.grenoble-inp.fr --- Documentation/config.txt | 7 +++ Documentation/git-am.txt | 6 -- git-am.sh| 7 +++ t/t4150-am.sh| 19 +++ 4 files changed, 37 insertions(+), 2 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index d44bc85..8e42752 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -769,6 +769,13 @@ am.keepcr:: by giving '--no-keep-cr' from the command line. See linkgit:git-am[1], linkgit:git-mailsplit[1]. +am.threeWay:: + If true, git-am will fall back on 3-way merge when the patch + cannot be applied cleanly, in the same way as the '-3' or + '--3-way' option. Can be overridden by giving '--no-3-way' + from the command line. + See linkgit:git-am[1]. + This part spells it 3-way while everywhere else appears to be 3way. -- Mikael Magnusson -- 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: BUG: 'error: invalid key: pager.show_ref' on 'git show_ref'
On Fri, Feb 6, 2015 at 8:44 PM, Junio C Hamano gits...@pobox.com wrote: Jeff King p...@peff.net writes: On Fri, Feb 06, 2015 at 01:45:28PM +0100, Andreas Krey wrote: $ git show_ref error: invalid key: pager.show_ref error: invalid key: alias.show_ref git: 'show_ref' is not a git command. See 'git --help'. Apparently we need to squelch this message from within git_config_get_* in this case? I reported this issue a few months ago, http://permalink.gmane.org/gmane.comp.version-control.git/258886 Someone sent a patch that never went anywhere, http://comments.gmane.org/gmane.comp.version-control.git/258895 -- Mikael Magnusson -- 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] difftool: honor --trust-exit-code for builtin tools
On Fri, Nov 14, 2014 at 10:51 PM, Junio C Hamano gits...@pobox.com wrote:
David Aguilar dav...@gmail.com writes:
run_merge_tool() was not setting $status, which prevented the
exit code for builtin tools from being forwarded to the caller.
Capture the exit status and add a test to guarantee the behavior.
Reported-by: Adria Farres 14farr...@gmail.com
Signed-off-by: David Aguilar dav...@gmail.com
---
git-mergetool--lib.sh | 1 +
t/t7800-difftool.sh | 5 +
2 files changed, 6 insertions(+)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index a40d3df..2b66351 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -221,6 +221,7 @@ run_merge_tool () {
else
run_diff_cmd $1
fi
+ status=$?
return $status
}
Thanks for a quick turn-around. As a hot-fix for what is already in
-rc I am fine with this fix but the patch makes me wonder if $status
as a global shell variable has any significance.
$status is an alias for $? in zsh, and so cannot be assigned to. But
other than that I don't think it holds any meaning and should be fine
in a .sh script.
--
Mikael Magnusson
--
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
git foo_bar prints two config errors
% git foo_bar error: invalid key: pager.foo_bar error: invalid key: alias.foo_bar git: 'foo_bar' is not a git command. See 'git --help'. git.c calls alias_lookup() and check_pager_config() resulting in calls to git_config_parse_key() with the above keys. I looked at the code and it's not immediately obvious how to suppress the error in this particular case. You also get an error for the empty argument and anything that isn't (isalnum || '-') (I discovered the _ case by accidentally leaving out the 'grep' before searching for a function), % git ''; git の error: key does not contain variable name: pager. error: key does not contain variable name: alias. git: '' is not a git command. See 'git --help'. error: invalid key: pager.の error: invalid key: alias.の git: 'の' is not a git command. See 'git --help'. but, % ln -s /bin/tty ~/bin/git-の; ln -s /bin/tty ~/bin/git-foo_bar % git の error: invalid key: pager.の /dev/pts/51 % git foo_bar error: invalid key: pager.foo_bar /dev/pts/51 The command itself is accepted, so I think we shouldn't print the errors. -- Mikael Magnusson -- 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: let git grep consider sub projects
On 7 October 2014 20:25, Junio C Hamano gits...@pobox.com wrote: Olaf Hering o...@aepfle.de writes: How can I teach 'git grep $string' to also consider subprojects? The build system of xen.git clones 4 other trees into a directory in its source tree during build. It would be nice if my 'git grep' searches also in these cloned subdirs. Somehow there must be some knowledge because 'git clean -dfx' leaves them alone, while 'git clean -dffx' wipes everything. Olaf PS: Sometimes I miss a 'git clean -dfx --also-sub-repos' useful to really clean everything before starting over. Is submodule foreach under-advertised or with less than adequate features? It sounds like in these use cases, you would want the commands to run on all the submodules but also in the parent repo, am I wrong in thinking that git submodule foreach does only the former part? So you would either need to make a wrapper thing yourself or run the command twice. In the first case with the git grep, I can also imagine that with some nontrivial patterns, having to quote the metacharacters not only once, but twice, can be a significant annoyance. Eg, first protect it from git submodule foreach parsing it, and then from the shell running the individual commands. -- Mikael Magnusson -- 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
