On Tue, Jul 28, 2015 at 08:23:40AM -0700, Junio C Hamano wrote:
> I can see that "symbolic-ref --short" is much newer than the other
> one, so addition of "--abbrev-ref" to "rev-parse" may have been a
> mistake made while being desperate (i.e. not having a way to do so
> with plumbing, we wanted "
At GitHub, we keep some information in a private part of the refs
namespace. We use transfer.hideRefs so that users do not see it when
fetching or pushing, and that works well. However, sometimes we want to
expose part of the hidden namespace (e.g., for an internal fetch or
push), and that cannot b
).
This avoids duplication, and will make it easier to document
changes to the config option without having to copy and
paste the description in two places.
While we're at it, this fixes some bogus subject/verb
agreement in the original description.
Signed-off-by: Jeff King
---
I think this m
is
actually valid in a ref-name, but all entries here
should be fully-qualified, starting with "refs/").
Signed-off-by: Jeff King
---
Documentation/config.txt | 5 +
refs.c | 18 +-
t/t5512-ls-remote.sh | 15 +++
3 fi
se we could internally parse that to a single
list, respecting the ordering, which saves us having to
invent the new "!" syntax. But using a single name
communicates to the user that the ordering _is_
important. And "!" is well-known for negation, and
should
On Thu, Jul 30, 2015 at 04:17:35PM -0400, Eric Sunshine wrote:
> > + test_expect_success "Override hiding of $configsection.hiderefs" '
> > + test_when_finished "test_unconfig $configsection.hiderefs"
> > &&
> > + git config --add $configsection.hiderefs refs/tag
On Mon, Aug 03, 2015 at 10:34:14AM +0200, Patrick Steinhardt wrote:
> One more question for backwards compatibility remains then.
> Currently when we clone something like 'http://example.com:/'
> we'd create a git repository '' as we'd split on the first
> occurrence of ':'. Should we rema
On Tue, Aug 04, 2015 at 09:31:18AM +0200, Sebastian Schuberth wrote:
> On Tue, Aug 4, 2015 at 6:34 AM, Lukas Fleischer wrote:
>
> > I am currently on vacation and cannot bisect or debug this but I am
> > pretty confident that this patch changes the behaviour of directory name
> > guessing. With
On Tue, Aug 04, 2015 at 06:42:46PM -0400, Jeff King wrote:
> > I did not intend this change in behavior, and I can confirm that
> > reverting my patch restores the original behavior. Thanks for bringing
> > this to my attention, I'll work on a patch.
>
> I think thi
7e837c6.
- cloning the root is not very smart about URL parsing,
and usernames and port numbers may end up in the
directory name
All of these tests are marked as failures.
Signed-off-by: Jeff King
---
t/t5603-clone-dirname.sh | 69
1 fil
early part, we
can just compute the length from "start" when we need
it.
Signed-off-by: Jeff King
---
I suspect you _could_ clean up this logic further, but I
really wanted to do the minimal fix for the regression.
Especially because Patrick is hopefully going to sweep
through and
On Wed, Aug 05, 2015 at 08:08:52AM +0200, Patrick Steinhardt wrote:
> > Sadly we cannot just `strip_suffix_mem(repo, &len, "/.git"))` in the
> > earlier code, as we have to account for multiple directory separators. I
> > believe the above code does the right thing, though. I haven't looked at
> >
On Wed, Aug 05, 2015 at 11:06:03AM +0200, Patrick Steinhardt wrote:
> You're welcome. And yes, your tests help me quite a lot here. Got
> tedious to always set up the chroot. Guess I'll still send my
> fixes for the chroot-tests as a separate patch series, even
> though I don't require them anymor
On Wed, Aug 05, 2015 at 10:19:56AM -0700, Junio C Hamano wrote:
> >> I think this regression is in v2.4.8, as well. We should be able to use
> >> a running "len" instead of the "end" pointer in the earlier part, and
> >> then use strip_suffix_mem later (to strip from our already-reduced
> >> lengt
On Wed, Aug 05, 2015 at 10:34:34AM -0700, Junio C Hamano wrote:
> > As you can see, there is a lot of complexity in there and I'm not
> > convinced this is better than just exposing
> > 'parse_connect_url()', which already handles everything for us.
>
> If the function "handles everything for us"
On Wed, Aug 05, 2015 at 03:55:23PM -0700, Junio C Hamano wrote:
> * jk/negative-hiderefs (2015-07-28) 2 commits
> - refs: support negative transfer.hideRefs
> - docs/config.txt: reorder hideRefs config
>
> Allow negative !ref entry in multi-value transfer.hideRefs
> configuration to say "don'
On Thu, Aug 06, 2015 at 12:55:35AM -0400, Jeff King wrote:
> PS I don't recall the outcome of our last discussion on the "verbose"
>test function. Here it makes debug output for the "grep" above more
>readable when it fails. But it also looks weird not
val ...
as the behavior of one-shot variables for function calls
is not portable.
Signed-off-by: Jeff King
---
t/test-lib.sh | 5 +
1 file changed, 5 insertions(+)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index cea6cda..374bfcb 100644
--- a/t/test-lib.sh
+++ b/t/test-li
g.
The normal case of just "./t5512-ls-remote.sh -x" stays the
same, as "-x" already implies "--verbose" (and
"--verbose-only" overrides "--verbose", which is why this
works at all). And for our test, we need only check
$verbose, as maybe_setup_verbose
On Thu, Aug 06, 2015 at 02:18:26PM -0400, Eric Sunshine wrote:
> However, that begs the question: Why do you need argv_array_copy() at
> all? Isn't the same functionality already provided by
> argv_array_pushv()? To wit, a caller which wants to copy from 'src' to
> 'dst' can already do:
>
> s
On Fri, Aug 07, 2015 at 08:42:52AM +0200, JuanLeon Lahoz wrote:
> # This prints nothing on git < 1.8.4; prints a commit that corresponds with
> # "Merge branch 'b3' into b2_3" in git >= 1.8.4 (tested with 1.8.4 and 2.5.0)
> echo COMMITS checkpoint..b2_3: $(git rev-list checkpoint..b2_3 -- version)
On Fri, Aug 07, 2015 at 05:24:29PM -0700, Junio C Hamano wrote:
> Since 5a688fe4 ("core.sharedrepository = 0mode" should set, not
> loosen, 2009-03-25), we kept reminding ourselves:
>
> NEEDSWORK: this should be renamed to finalize_temp_file() as
> "moving" is only a part of what it does,
On Fri, Aug 07, 2015 at 06:50:52PM -0400, Jarkko Hietaniemi wrote:
> Or another way to illustrate my idea: assume a create-once-no-delete
> filesystem.
>
> echo 42 > the_answr.txt
>
> Oh, darn it...
>
> ln -s the_answr.txt the_answer.txt
>
> Now both names still point to the content "42\n". T
On Mon, Aug 03, 2015 at 01:28:05PM +, Dror Livne wrote:
> I have noticed that when cloning a repository, I get a
> refs/remotes/origin/HEAD symbolic ref.
>
> On the other hand, when fetching a new remote, the remote HEAD is not set by
> git-fetch (but can be added later by `git remote set-hea
On Mon, Aug 03, 2015 at 05:21:43PM +0200, Per Cederqvist wrote:
> If you run:
>
> git config pager.pull true
>
> in the hope of getting the output of "git pull" via a pager, you are
> in for a surpise the next time you run "git pull --rebase" and it has
> to rebase your work. It will fail w
This function basically reimplements git_env_bool (because
it predates it). Let's reuse that helper, which is shorter
and avoids repeating a string literal.
Signed-off-by: Jeff King
---
pager.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/pager.c b/pager.c
On Sun, Aug 09, 2015 at 07:42:38PM -0400, Jeff King wrote:
> It looks like the use of a pager is fooling our "should we colorize the
> diff" check when generating the patches. Usually we check isatty(1) to
> see if we should use color, so "git format-patch >patches"
, not by
pretending you have a pager.
Rather than delete the test, though, we simply re-title it
here. It actually makes a good check of the "scripts which
set PAGER_IN_USE but not PAGER_PIPE_ID" historical
compatibility mentioned above.
Signed-off-by: Jeff King
---
+cc Jonathan, whose
Recently Michael and I were working on a patch series (not yet
published), which did something like:
const char *path = git_path("foo");
... do stuff with path ...
for_each_ref(some_callback, NULL);
... do some other stuff ...
unlink(path);
Clever readers may have spotted the bug i
o move the existing comment to
sha1_file_name. Commit d40d535 (sha1_file.c: document a
bunch of functions defined in the file, 2014-02-21) already
added a much more descriptive comment to it.
Signed-off-by: Jeff King
---
cache.h | 17 -
1 file changed, 12 insertions(+), 5 deleti
strbuf behind the scenes, it's
easy to expose all three of these interfaces with thin
wrappers.
Signed-off-by: Jeff King
---
cache.h | 5 +
path.c | 35 ++-
2 files changed, 35 insertions(+), 5 deletions(-)
diff --git a/cache.h b/cache.h
index 8db884e.
formatting nits, like the
opening quote of the test block on the wrong line,
spaces after ">", etc
This patch fixes the style issues, and uses a few helper
functions, along with subshells and "git -C", to avoid
changing the cwd of the main script.
Signed-off-by: Jeff
tatic-buffer mkpath and git_path functions.
Signed-off-by: Jeff King
---
This is a polishing of the thread at:
http://thread.gmane.org/gmane.comp.version-control.git/270341
sha1_file.c| 47 +++---
t/t5700-clone-reference.sh | 5 +
2
that we must remember to free the result).
Signed-off-by: Jeff King
---
builtin/repack.c | 24 +---
refs.c | 6 --
2 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/builtin/repack.c b/builtin/repack.c
index af7340c..70b9b1e 100644
--- a/builtin
er of magnitude cheaper than a
system call (which we are clearly about to make, since we
are constructing a filename). The real cost is that we must
remember to free the result.
Signed-off-by: Jeff King
---
builtin/fsck.c | 4 +++-
fast-import.c | 4 +++-
http-backend.c | 3 ++-
notes-merge.c |
;t be used.
[jk: tweaked commit message, and dropped declaration and
documentation, too]
Signed-off-by: Jim Hill
Signed-off-by: Jeff King
---
And this is the obvious continuation of the last patch.
Documentation/technical/api-lockfile.txt | 26 --
lockf
e's no bug.
We can just pass the result directly to unlink_or_warn,
which is a known-simple function. As a bonus, the code flow
is a little more obvious, as we eliminate an extra
conditional (a reader does not have to wonder any more
"under which circumstances is 'path'
ath buffer (".git/refs/foo/"). We could get by with one
buffer, indexing the length of $GIT_DIR when we want the
refname. However, having tried this, the resulting code
actually ends up a little more confusing, and the efficiency
improvement is tiny (and almost certainly dwarfed by the
system
There are no callers of the slightly-dangerous static-buffer
git_path_submodule left. Let's drop it.
Signed-off-by: Jeff King
---
cache.h | 5 ++---
path.c | 10 --
2 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/cache.h b/cache.h
index 6f74f33..7a4fa90 100644
about this aliasing. It's a larger diff, but
the resulting code is simpler.
Signed-off-by: Jeff King
---
refs.c | 38 +++---
1 file changed, 15 insertions(+), 23 deletions(-)
diff --git a/refs.c b/refs.c
index 06f95c4..3666132 100644
--- a/refs.c
+++ b/r
is a non-trivial function that might use the pathname
buffers itself (this is _probably_ OK, as the likely culprit
would be calling resolve_gitlink_ref, but we do not pass the
proper flags to ask it to avoid blowing away gitlinks).
Signed-off-by: Jeff King
---
refs.c
it
in all code paths).
As a bonus, we get rid of a confusing variable-reuse
("ref_file" is used for two distinct purposes).
Signed-off-by: Jeff King
---
refs.c | 32 +++-
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/refs.c b/refs.c
in
Because it's not safe to store the static-buffer results of
git_path for a long time, we end up formatting the same
filename over and over. We can fix this by using a
function-local strbuf to store the formatted pathname and
avoid repeating ourselves.
Signed-off-by: Jeff King
---
refs.c
et in trouble by calling find_hook in quick
succession, which is less likely to happen and more obvious
to notice.
While we're at it, let's add some documentation of the
function's limitations.
Signed-off-by: Jeff King
---
run-command.c | 10 ++
run-command.h | 5 +
that happens in all of the early-return
code paths.
Signed-off-by: Jeff King
---
builtin/clone.c | 43 +--
1 file changed, 29 insertions(+), 14 deletions(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index 303a3a7..5864ad1 100644
--- a/builtin/clone.c
cessor in favor of
generating these with a script, we could get much fancier.
E.g., normalizing "FOO/BAR-BAZ" into "git_path_foo_bar_baz".
But the small amount of saved typing is probably not worth
the resulting confusion to readers who want to grep for the
function's definit
d use "logfile.buf" directly, we do not
have to worry about this aliasing. It's a larger diff, but
the resulting code is simpler.
Signed-off-by: Jeff King
---
refs.c | 38 +++---
1 file changed, 15 insertions(+), 23 deletions(-)
diff --git a/refs.c b/refs
On Mon, Aug 10, 2015 at 02:05:14PM +0200, Michael Haggerty wrote:
> I was wondering whether this memoization could interact badly with
> update_common_dir(). For example, if any of the memoized functions were
> called before git_common_dir is initialized, then the pre-git_common_dir
> value would
On Mon, Aug 10, 2015 at 10:42:30AM +, Ed Avis wrote:
> I would find it useful to ask 'git stash pop' to always drop the stash after
> applying it to the working tree, even if there were conflicts. (Only if there
> was some hard error, such as an I/O error updating some of the files, should
>
On Mon, Aug 10, 2015 at 12:50:51PM +, Ed Avis wrote:
> An alternative would be for git stash to always print the name of the stash
> it is applying. Then you can drop it afterwards by name and be sure you got
> the right one. Printing the name of the stash sounds like a reasonable
> bit of c
On Mon, Aug 10, 2015 at 11:46:06AM +0200, SZEDER Gábor wrote:
> 'git config' can only show values or name-value pairs, so if a shell
> script needs the names of set config variables it has to run 'git config
> --list' or '--get-regexp' and parse the output to separate config
> variable names from
ks like a pretty straight-forward application of part 1, and the
resulting code is much nicer to read.
Both patches:
Acked-by: Jeff King
though I do not think my "ack" on completion code is worth anything. :)
-Peff
--
To unsubscribe from this list: send the line "unsubscribe
On Mon, Aug 10, 2015 at 01:43:07PM +, Ed Avis wrote:
> Jeff King peff.net> writes:
>
> >>An alternative would be for git stash to always print the name of the stash
> >>it is applying.
>
> > Applying refs/stash@{0} (31cb86c3d700d241e315d989f460e3
On Mon, Aug 10, 2015 at 06:38:10PM +0200, Johannes Schindelin wrote:
> > +const char *pipe_id_get(int fd)
> > +{
> > + static struct strbuf id = STRBUF_INIT;
> > + struct stat st;
> > +
> > + if (fstat(fd, &st) < 0 || !S_ISFIFO(st.st_mode))
> > + return NULL;
>
> Just a quick note
On Mon, Aug 10, 2015 at 10:31:32AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > The problem is that git_path uses a static buffer that gets overwritten
> > by subsequent calls.
>
> As the rotating static buffer pattern used in get_pathname() was
> modeled a
On Mon, Aug 10, 2015 at 03:36:14PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > No users of hold_lock_file_for_append remain, so remove it.
>
> This does not seem to have anything to do with rotating static buffers
> used in get_pathname(); the only effect
On Mon, Aug 10, 2015 at 03:57:31PM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Jeff King writes:
> >
> >> There are no callers of the slightly-dangerous static-buffer
> >> git_path_submodule left. Let's drop it.
> >
&g
On Tue, Aug 11, 2015 at 06:00:20AM +0200, Michael Haggerty wrote:
> > Instead of using hold_lock_file_for_append, let's copy the
> > file line by line, which ensures all records are properly
> > terminated. If we see an extra line, we can simply abort the
> > update (there is no point in even copy
rary data)
- the results of strerror(errno)
both of which should be predictably small.
Signed-off-by: Jeff King
---
So this solution tries to change vreportf and vwritef as little as
possible, and ends up slightly complex as a result. But reading
vreportf's:
vsnprintf(msg, sizeof(msg)
On Tue, Aug 11, 2015 at 09:28:34AM -0700, Stefan Beller wrote:
> On Tue, Aug 11, 2015 at 9:17 AM, Jeff King wrote:
> > We use a fixed-size buffer of 4096 bytes to format die() and
> > error() messages. We explicitly avoided using a strbuf or
> > other fanciness here, because
On Tue, Aug 11, 2015 at 09:34:31AM -0700, Junio C Hamano wrote:
> > As for vwritef, it exists solely to work over write(), _and_ it doesn't
> > get the "one-shot" thing right (which is probably OK, as we use it only
> > when exec fails). But we could probably teach run-command to fdopen(),
> > and
problem, we instead introduce a
new "set_error_handle" function, which lets the normal
vreportf calls output to a handle besides stderr. Thus we
can get rid of our custom handlers entirely, and just ask
the regular handlers to output to our new descriptor.
And as vwritef has no more calle
flush due to hitting the buffer
limit).
We may still break the output into two writes if the content
is larger than our buffer, but there's not much we can do
there; depending on the stdio implementation, that might
have happened even with a single fprintf call.
Signed-off-by: Jeff King
---
ory is still open while the
> callback is called. Close the directory before calling the callback.
Makes sense, and the patch looks good to me. Sorry for breaking things
on Windows.
Acked-by: Jeff King
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body o
On Fri, Aug 14, 2015 at 03:35:58PM -0700, Junio C Hamano wrote:
> Max Kirillov writes:
>
> > * do not limit number of warnings - does not worth complicating the code
>
> Unless the warning leads to a quick "die()", wouldn't this make Git
> unusable by spewing a "falling back to verbatim copy" f
On Thu, Aug 20, 2015 at 04:14:22PM +0200, SZEDER Gábor wrote:
> Commit 578625fa91 (config: add '--name-only' option to list only
> variable names, 2015-08-10) modified format_config() such that it
> returned from the middle of the function when showing only keys,
> resulting in ugly code structure
in the first place is
that we need to know before writing the value whether to
insert a delimiter. Instead of delaying the write of the
value, we speculatively write the delimiter, and roll it
back in the single case that cares.
Signed-off-by: Jeff King
---
I admit the rollback is a little gross
We create a strbuf only to insert a single string, pass the
resulting buffer to a function (which does not modify the
string), and then free it. We can just pass the original
string instead.
Signed-off-by: Jeff King
---
I keep staring at this thinking I missed something, but I think this is
an
;s no leak, as the initialized buffer doesn't have
anything in it. But let's bump the strbuf_init out to the
one caller who needs it, making format_config more
idiomatic.
Signed-off-by: Jeff King
---
builtin/config.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
On Thu, Aug 20, 2015 at 12:05:34PM -0700, Junio C Hamano wrote:
> This is a tangent, but the above is different from saying that with
> a single liner test.c that has
>
> #include "wt-status.h"
>
> your compilation "cc -c test.c" should succeed. But for that goal,
> direct inclusion of to
On Mon, Aug 17, 2015 at 05:22:03PM -0700, Stefan Beller wrote:
> +static int module_clone(int argc, const char **argv, const char *prefix)
> [...]
> + /* Redirect the worktree of the submodule in the superprojects config */
> + if (!is_absolute_path(sm_gitdir)) {
> + char *s =
On Wed, Aug 19, 2015 at 03:46:27PM -0400, Anders Kaseorg wrote:
> git fast-export | git fast-import fails to preserve a commit that replaces
> a symlink with a directory. Add a failing test case demonstrating this
> bug.
>
> The fast-export output for the commit in question looks like
>
> c
On Wed, Aug 19, 2015 at 03:46:25PM -0400, Dave Borowitz wrote:
> >> + unsigned dry_run = 0;
> >> + unsigned send_mirror = 0;
> >> + unsigned force_update = 0;
> >> + unsigned quiet = 0;
> >> + unsigned push_cert = 0;
> >> + unsigned use_thin_pack = 0;
> >> +
signifying error would be enough. The error
output shown to the user is useless and confusing in this case, so add a
flag to suppress errors in such cases.
Helped-by: Junio C Hamano
Helped-by: Jeff King
Signed-off-by: Tanay Abhra
Signed-off-by: Jeff King
---
builtin/config.c | 2 +-
cache.h
On Fri, Aug 21, 2015 at 10:43:58AM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > I wonder if we can do this instead
> >
> > if (!omit_values) {
> > - if (show_keys)
> > + if (show_keys && value_)
> > strbuf_addch(buf, key_delim);
> >
> >
On Fri, Aug 21, 2015 at 12:05:13PM -0700, Junio C Hamano wrote:
> The primary reason I suspect is because you sent to a wrong set of
> people. Submodule folks have largely been working in the scripted
> ones, and may not necessarily be the ones who are most familiar with
> the run-command infrast
On Fri, Aug 21, 2015 at 12:48:23PM -0700, Stefan Beller wrote:
> > Before even looking at the implementation, my first question would be
> > whether this pattern is applicable in several places in git (i.e., is it
> > worth the extra complexity of abstracting out in the first place). I
> > think t
On Sun, Aug 23, 2015 at 05:27:46PM +0200, CoDEmanX wrote:
> the question how to list tags, that point to commits contained in a certain
> branch came up on StackOverflow couple times, and this appears to be the
> only fast solution (example for local devel branch):
>
> git log --simplify-by-d
On Sat, Aug 22, 2015 at 05:14:39PM +0200, Johannes Schindelin wrote:
> The `format_display_notes()` function clearly assumes that the data
> structure holding the notes has been initialized already, i.e. that the
> `display_notes_trees` variable is no longer `NULL`.
>
> However, when there are no
On Sun, Aug 23, 2015 at 01:43:09PM -0400, Jeff King wrote:
> I don't know how deeply anybody _cares_ about showing notes via
> rev-list. It has clearly never worked. But rather than silently
> accepting --show-notes (and not showing any notes!), perhaps we should
> tell the user
On Sun, Aug 23, 2015 at 08:06:39PM +0200, CoDEmanX wrote:
> > in a future version of git you should be able to do "git tag
> --merged" to get the tags that are "merged" to a particular branch.
>
> Would it return every tag in the branch, even if it was created in
> that branch, and not merged f
On Sun, Aug 23, 2015 at 12:05:32PM -0700, Junio C Hamano wrote:
> > - write_file(am_path(state, "threeway"), 1, state->threeway ? "t" : "f");
> > + write_file(am_path(state, "threeway"), 1, "%s\n", state->threeway ? "t"
> > : "f");
>
> Stepping back a bit, after realizing that "write_file()"
On Fri, Aug 21, 2015 at 12:47:30PM -0400, Anders Kaseorg wrote:
> On Fri, 21 Aug 2015, Jeff King wrote:
> > - we may still have the opposite problem with renames. That is, a
> > rename is _also_ a deletion, but will go to the end. So I would
> > expect renaming the
On Fri, Aug 21, 2015 at 03:13:38PM -0700, Junio C Hamano wrote:
> > diff --git a/config.c b/config.c
> > index 9fd275f..dd0cb52 100644
> > --- a/config.c
> > +++ b/config.c
> > @@ -1314,7 +1314,7 @@ static struct config_set_element
> > *configset_find_element(struct config_set *cs,
> > * `ke
On Mon, Aug 24, 2015 at 01:43:27AM -0400, Jeff King wrote:
> > I wonder if alias_lookup() and check_pager_config(), two functions
> > that *know* that the string they have, cmd, could be invalid and
> > unusable key to give to the config API, should be doing an extra
>
On Sun, Aug 23, 2015 at 11:48:44PM -0700, Junio C Hamano wrote:
> > I think the "if" here is redundant; strbuf_complete_line already handles
> > it.
>
> True. And I like your write_state_bool() wrapper (which should be
> "static void" to the builtin/am.c) very much.
>
> On top of that, I think
On Mon, Aug 24, 2015 at 12:23:52PM +0200, Johannes Schindelin wrote:
> You're right. I think the best approach for now is to error out when
> `--show-notes` is passed to rev-list. Do you agree?
Yes (I imagine you didn't yet read my follow-up patch when you wrote
this). :)
-Peff
--
To unsubscribe
On Mon, Aug 24, 2015 at 10:09:41AM -0700, Junio C Hamano wrote:
> So here is an solution based on the "write_file() is primarily to
> produce text, so it should be able to correct the incomplete line
> at the end" approach.
This all looks good to me. The topics-in-flight compatibility stuff in
pa
On Mon, Aug 24, 2015 at 11:15:55AM -0700, Junio C Hamano wrote:
> > This all looks good to me. The topics-in-flight compatibility stuff in
> > patches 3 and 5 is neatly done. Usually I would just cheat and change
> > the order of arguments to make the compiler notice such problems, but
> > that's
On Mon, Aug 24, 2015 at 01:58:06PM -0700, Junio C Hamano wrote:
> We forgot to terminate the payload given to write_file() with LF,
> resulting in files that end with an incomplete line. Teach the
> wrappers builtin/am uses to make sure it adds LF at the end as
> necessary.
Is it even worth doin
On Mon, Aug 24, 2015 at 01:58:04PM -0700, Junio C Hamano wrote:
> The workhorse helper function that implements "we have this (short)
> body of text; create a new file that contains it" has a "fatal"
> parameter, to which 1 was passed by almost all callers, but to
> casual readers, it was unclear
On Mon, Aug 24, 2015 at 12:11:13PM -0400, Aaron Dufour wrote:
> I use git (2.2.1) on OS X (10.9.5) and recently my repo got into a bad
> state. I think this involves a mis-handling of case-insensitive file
> systems.
>
> This reproduces the problem:
>
> > git init
> Initialized empty Gi
On Tue, Aug 25, 2015 at 09:19:13AM -0700, Junio C Hamano wrote:
> As to "flags exposed to callers" vs "with and without gently", when
> we change the system to allow new modes of operations (e.g. somebody
> wants to write a binary file, or allocate more flag bits for their
> special case), I'd exp
On Tue, Aug 25, 2015 at 05:01:01PM +0200, Gabor Bernat wrote:
> So it would be great if the filter-branch beside the Rewrite
> f8f0b351ae35ff7ac4bd58078cbba1aa34243779 (523/22625), would also
> append a basic ETA signaling the end of the operation.
>
> It could be as simple as the the average num
On Tue, Aug 25, 2015 at 11:33:49AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > +start=$(date +%s)
>
> Is that a GNU extension?
Thanks, I meant to mention that, too. POSIX has "+" formats, but
apparently no way to get an integer number of seconds. I d
On Tue, Aug 25, 2015 at 02:52:10PM -0400, Jeff King wrote:
> Yeah, that would probably be a good solution, assuming there is a
> portable "how many seconds" (I do not relish the thought of
> reconstructing it based on the current hours/minutes/seconds).
A little googling cam
On Tue, Aug 25, 2015 at 10:28:25AM -0700, Stefan Beller wrote:
> By treating each object as its own task the workflow is easier to follow
> as the function used in the worker threads doesn't need any control logic
> any more.
Have you tried running t/perf/p5302 on this?
I seem to get a pretty co
On Tue, Aug 25, 2015 at 04:12:54PM -0400, Eric Sunshine wrote:
> > A little googling came up with:
> >
> > awk 'END { print systime() }' >
> > which probably (?) works everywhere.
>
> On Mac OS X and FreeBSD:
>
> $ awk 'END { print systime() }' awk: calling undefined function systi
On Tue, Aug 25, 2015 at 10:28:24AM -0700, Stefan Beller wrote:
> +int module_foreach_parallel(int argc, const char **argv, const char *prefix)
> +{
> [...]
> + for (i = 0; i < ce_used; i++) {
> + const struct submodule *sub;
> + const struct cache_entry *ce = ce_entries
On Fri, Aug 28, 2015 at 06:55:52PM +0200, Ralf Thielow wrote:
> With 77b9b1d (add_to_alternates_file: don't add duplicate entries,
> 2015-08-10) the last caller of function "hold_lock_file_for_append"
> has been removed, so we can remove the function as well.
Heh. I have the same patch, but was h
1 - 100 of 15671 matches
Mail list logo
