Hi,
diger wrote:
This patch fixes build git on Haiku
Lovely. May we have your sign-off? (See
Documentation/SubmittingPatches for what this means.) Does make
test pass? (Just curious --- it's fine if it doesn't, though in that
case a list of test failures would be helpful.)
Thanks,
Nguyễn Thái Ngọc Duy wrote:
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -145,7 +145,15 @@ you will need to handle the situation manually.
--index-version n::
Write the resulting index out in the named on-disk format version.
- The
Nguyễn Thái Ngọc Duy wrote:
Oops, bogus indentation in the first 3/2
Oops, I missed this. Ok, ignore the comment on indentation on v1. :)
With or without the other changes I suggested,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Nguyễn Thái Ngọc Duy wrote:
+ Version 4 performs a simple pathname compression that could
+ reduce index size by 30%-50% on large repositories, which
+ results in faster load time. Version 4 is relatively young
library
to make these consistent.
Scripts could be grepping for Usage:, but they are asking for
trouble and if anything should check for status 129 instead.
And luckily we have been careful about not checking for this
in tests. Thanks for the fix.
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
.
With or without that change, all of these except patches 11 and 12 are
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
I have no opinion about patches 11 and 12. :)
Thanks,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord
Paul Campbell wrote:
Four of the eight original authors now have dead email addresses. As I
found out when I started getting the mail bounces when I started
sending these patches out. Would it be acceptable for those patches to
leave the From line, add a Based-on-patch-by and then sign of
for your help on it
so far.
Jonathan Nieder (2):
shell doc: emphasize purpose and security model
shell: allow customization of interactive login disabled message
Documentation/git-shell.txt | 86 +
shell.c | 13 +++
2 files
also section with related reading.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Changes since v2:
- use command -v instead of which in synopsis to subtly reinforce
good habits
- use user instead of hardcoding git username in synopsis
- give up on typesetting git in monospace, since
-eval-print loop.
* Otherwise, print the usual configuration hint and hang up.
Reported-by: Ethan Reesor firelizz...@gmail.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
Improved-by: Jeff King p...@peff.net
---
v2 jammed this functionality into the help command, which was kind
of silly
Hi,
Michael Fallows wrote:
--- a/git.c
+++ b/git.c
@@ -316,8 +316,7 @@ static void handle_internal_command(int argc, const char
**argv)
{ check-ignore, cmd_check_ignore, RUN_SETUP | NEED_WORK_TREE
},
{ check-ref-format, cmd_check_ref_format },
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
If I disable git-shell's interactive mode by removing the
~/git-shell-commands directory, attempts to use 'ssh' in produce a
message intended for the administrator:
Sorry, but -ECANTPARSE. s/in produce/produces/ perhaps
Ramkumar Ramachandra wrote:
Jonathan Nieder wrote:
* If the file ~/git-shell-commands/no-interactive-login exists,
run no-interactive-login to let the server say what it likes,
then hang up.
[...]
If no-interactive-login doesn't have execute permissions, we'll get
an error from here
is dropped because an url.$TRASH.insteadOf
setting leaks in from a previous test.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
t/t5516-fetch-push.sh | 27 ++-
1 file changed, 10 insertions(+), 17 deletions(-)
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
When it is unclear which command from a test has failed, usual
practice these days is to debug by running the test again with sh -x
instead of relying on debugging 'echo' statements.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
t/t5516-fetch-push.sh | 15 ---
1 file changed
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Test nits:
...
Hope that helps,
Jonathan Nieder (3):
push test: use test_config where appropriate
push test: simplify check of push result
push test: rely on -chaining instead of 'if bad; then echo Oops; fi
is
that it shouldn't make a difference the way people usually use git,
no?
In other words, how about the following patches? With them applied,
hopefully no one would mind even if the warning becomes a fatal error.
Looking forward to your thoughts,
Jonathan Nieder (4):
add: make pathless 'add [-u|-A]' warning
that will not change through the call
chain.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
builtin/add.c | 69 +++
1 file changed, 36 insertions(+), 33 deletions(-)
diff --git a/builtin/add.c b/builtin/add.c
index ab1c9e8f..a4028eea
-by: Jonathan Nieder jrnie...@gmail.com
---
builtin/add.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/builtin/add.c b/builtin/add.c
index a4028eea..a424e69d 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -33,8 +33,13 @@ static const char *short_option_with_implicit_dot;
static void
suppress the warning
unless there are changes outside the cwd that are not being added.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
builtin/add.c | 51 ---
1 file changed, 44 insertions(+), 7 deletions(-)
diff --git a/builtin/add.c b/builtin
In the spirit of the recent similar change for 'git add -u', avoid
pestering users that restrict their attention to a subdirectory and
will not be affected by the coming change in the behavior of pathless
'git add -A'.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
builtin/add.c | 21
detail.
The warning about use of 'git add -u' with no pathspec is annoying
because it serves no purpose in this case. So suppress the warning
unless there are changes outside the cwd that are not being added.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
builtin/add.c | 41
Junio C Hamano wrote:
The implemenation appears to run an extra diff_files() in addition
to the one we already have to run in order to implement the add -u
to collect modified/deleted paths. Is that the best we can do?
At least the following should be squashed in to avoid wasted effort in
Duy Nguyen wrote:
My concern is run full-tree diff can be expensive on large repos (one
of the reasons the user may choose to work from within a
subdirectory). We can exit as soon as we find a difference outside
$prefix. But in case we find nothing, we need to diff the whole
worktree.
Yes.
Junio C Hamano wrote:
Matthieu Moy matthieu@grenoble-inp.fr writes:
No time to review the code now. I thought about implementing something
like that, but did not do it because I didn't want the change in the
code to be too big. At some point, we'll have to remove the warning and
it's
Junio C Hamano wrote:
Incidentally, I am rebuilding the 'next' by kicking many of the
topics back to 'pu' (essentially, only the ones marked as Safe in
the latest issue of What's cooking are kept in 'next'), so perhaps
we can rebuild the jc/add-2.0-u-A-sans-pathspec topic with your
series at
in the 2.0 cycle.
Jeff King (1):
t2200: check that add -u limits itself to subdirectory
Jonathan Nieder (4):
add: make pathless 'add [-u|-A]' warning a file-global function
add: make warn_pathless_add() a no-op after first call
add -u: only show pathless 'add -u' warning when changes
when
we do make it.
Signed-off-by: Jeff King p...@peff.net
Signed-off-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Unchanged, only included for reference.
t/t2200-add-update.sh | 16
1 file changed, 16 insertions(+)
diff --git a/t
that will not change through the call
chain.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Unchanged.
builtin/add.c | 69 +++
1 file changed, 36 insertions(+), 33 deletions(-)
diff --git a/builtin/add.c b/builtin/add.c
index ab1c9e8
-by: Jonathan Nieder jrnie...@gmail.com
---
As before.
builtin/add.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/builtin/add.c b/builtin/add.c
index a4028ee..a424e69 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -33,8 +33,13 @@ static const char *short_option_with_implicit_dot;
static
clue to users of such
repositories to get into the habit of explicitly passing '.'.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
Acked-by: Jeff King p...@peff.net
Improved-by: Junio C Hamano gits...@pobox.com
---
This is the interesting one.
Changes since v1:
* run only one diff-files pass
In the spirit of the recent similar change for 'git add -u', avoid
pestering users that restrict their attention to a subdirectory and
will not be affected by the coming change in the behavior of pathless
'git add -A'.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
As before.
builtin
subdirectories.
Signed-off-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Thanks for reading.
Documentation/git-add.txt | 16 +++
builtin/add.c | 110 --
t/t2200-add-update.sh | 9
Ramkumar Ramachandra wrote:
--- a/remote.c
+++ b/remote.c
@@ -356,9 +356,7 @@ static int handle_config(const char *key, const char
*value, void *cb)
return 0;
branch = make_branch(name, subkey - name);
if (!strcmp(subkey, .remote)) {
-
Ramkumar Ramachandra wrote:
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -1,6 +1,6 @@
#!/bin/sh
-test_description='fetching and pushing, with or without wildcard'
+test_description='fetching and pushing'
I'm not thrilled with the description before or after. Would it
Ramkumar Ramachandra wrote:
mk_test() creates a repository with the constant name testrepo, and
this may be limiting for tests that need to create more than one
repository for testing. To fix this, create a new mk_test_with_name()
which accepts the repository name as $1. Reimplement
Ramkumar Ramachandra wrote:
Currently, do_push() in push.c calls remote_get(), which gets the
configured remote for fetching and pushing. Replace this call with a
call to pushremote_get() instead, a new function that will return the
remote configured specifically for pushing. This function
Ramkumar Ramachandra wrote:
This new configuration variable defines the default remote to push to,
and overrides `branch.name.remote` for all branches.
Micronit: I think this would be easier to explain if it came after
patch 6, since then you could say In other words, it is a default for
Ramkumar Ramachandra wrote:
When I want to add a test for branch.name.pushremote, I grep
for branch.*.pushurl, and open files with sensible names; I'm not
going to open up the file and read a long description of what tests it
already contains.
Huh? The test_description is output for
,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
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
Ramkumar Ramachandra wrote:
Jonathan Nieder wrote:
I dunno. The helper functions at the top of this test are already
intimidating, so I guess I am looking for a way to avoid making that
problem worse.
[...]
My patch does not make the situation worse in any way:
Um, yes it does. It adds
could go either way on it.
It is certainly useful to document the current state before
considering changing it, so with the tweaks mentioned above,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord
Jeff King wrote:
I
tend to read the tests in a top-down manner: a test is interesting
(usually because it fails), and then I want to see what it is doing, so
I look at any functions it calls, and so forth.
What I usually
Ramkumar Ramachandra wrote:
Andrew Wong wrote:
You can actually rely on rebase to run the appropriate command.
Didn't Junio explicitly mention that this is undesirable earlier (from
the point of view of `rebase -i` design)?
I missed the earlier discussion. Does the documentation (e.g.,
Jeff King wrote:
Instead of using the x = x hack, let's handle the default
case in the switch() statement with a die(BUG). That tells
the compiler and any readers of the code exactly what the
function's input assumptions are.
Sounds reasonable.
We could also convert the flag to an enum,
Junio C Hamano wrote:
+Consequently a request `git merge --ff-only v1.2.3` to merge such a
+tag would fail.
+
+When you want to just integrate with the work leading to the commit
+that happens to be tagged, e.g. synchronizing with an upstream
+release point, you may not want to make an
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Jeff King wrote:
+ default:
+ die(BUG: unhandled change_type %d in
wt_status_print_change_data,
+ change_type);
Micronit: s/unhandled/invalid/.
I actually think unhandled is more correct
Junio C Hamano wrote:
Here is a replacement.
Looks good. Thanks for taking care of this.
--
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
, looks correct. For what it's worth,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
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
think perhaps we should encourage people to use
-Wno-error=uninitialized, in addition to cleaning up our code where
reasonably recent optimizers reveal it to be confusing.
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body
).
So fwiw
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
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
Jeff King wrote:
Two patches to follow.
[5/4]: fast-import: clarify inline logic in file_change_m
This one is clearly a bug / missing feature in gcc's control flow
analysis, but your workaround looks reasonable.
[6/4]: run-command: always set failed_errno in start_command
Very sane.
Yann Droneaud wrote:
Anyway, having a README at the Documentation/ level could also help to
explain what to be found in this directory:
- user-manual
- howto
- technical
- RelNote
- SubmittingPatches
- CodingGuidelines
- etc.
A Documentation/README or Documentation/INDEX in the spirit
Yann Droneaud wrote:
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Yes, I think this is in good shape now.
--
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
Hi Josh,
Josh Sharpe wrote:
For example, I have my ~/.gitconfig that has one email address in it,
but I also have multiple repos inside ~/dev which I want to use a
different email address for. The only way to do that now is to edit
all of these: ~/dev/*/.git/conf -- and there are lots of
Ramkumar Ramachandra wrote:
I'd really to have that final 'git continue' in Git 2.0. Can someone
attempt to break up the migration path into manageable logical steps
that we can start working on?
Is there any deadline or migration path needed? Depending on the
design, it might be possible
Ramkumar Ramachandra wrote:
A small segment where handle_config() parses the branch.remote
configuration variable can be simplified using git_config_string().
Looks correct.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
Ramkumar Ramachandra wrote:
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -1,6 +1,6 @@
#!/bin/sh
-test_description='fetching and pushing, with or without wildcard'
+test_description='fetching and pushing'
The description before and after are equally useless. You might as
Junio C Hamano wrote:
I would prefer to see a preparatory patch to teach mk_test/mk_empty
to _always_ take the new name (i.e. the result of your patch) and
then do whatever new things on top.
Yes, that sounds like a good way to go.
By the way, I am planning to _not_ look at new stuff today.
Ramkumar Ramachandra wrote:
This patch has no visible impact, but
serves to enable future patches to introduce configuration variables
to set pushremote_name. For example, you can now do the following in
handle_config():
if (!strcmp(key, remote.pushdefault))
Hi,
Sebastian Götte wrote:
git merge/pull:
When --verify-signatures is specified on the command-line of git-merge
or git-pull, check whether the commits being merged have good gpg
signatures and abort the merge in case they do not. This allows e.g.
auto-deployment from untrusted repo hosts.
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
- struct remote *remote = remote_get(repo);
+ struct remote *remote = pushremote_get(repo);
struct remote has url and pushurl fields. What do they mean in the
context of these two accessors? /me is confused
Jeff King wrote:
On Fri, Mar 22, 2013 at 11:22:11AM -0700, Jonathan Nieder wrote:
It would be easier to understand
the configuration if ~/.gitconfig could spell out the rule
explicitly:
[...]
It sounds hard to do right, especially considering use
Hi,
Nguyễn Thái Ngọc Duy wrote:
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -180,6 +180,13 @@ branch by running git rm -rf . from the top level of
the working tree.
Afterwards you will be ready to prepare your new files, repopulating the
working tree, by
Duy Nguyen wrote:
On Mon, Mar 25, 2013 at 1:17 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Hm, should this be the default?
In principle, I would expect
git checkout -- .
to make the worktree match the index, respecting the sparse checkout.
And something like
git
Ramkumar Ramachandra wrote:
Junio C Hamano wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
Git 2.0 is coming soon, so I'm excited about breaking a lot of
backward compatibility ;)
Don't.
push.default is the necessary exception?
A while ago there was a discussion of changes of the
Ramkumar Ramachandra wrote:
Okay, I'm confused: why are you waiting for 2.0 to change push.default
then? Isn't that just a slightly better default at the porcelain
level and hence a regular enhancement?
No. Among other aspects, git push is used heavily by scripts.
--
To unsubscribe from
Ramkumar Ramachandra wrote:
This whole backward compatibility thing is not black-or-white: it's
shades of gray. Can I ask about how backward incompatible the other
suggestions I listed were, just so I get a rough idea of your scale?
It depends on how important the change is and how painful
Jeff King wrote:
When we are streaming an index blob to disk, we store the
error from stream_blob_to_fd in the result variable, and
then immediately overwrite that with the return value of
close.
Good catch.
[...]
--- a/entry.c
+++ b/entry.c
@@ -126,8 +126,10 @@ static int
Hi,
Richard Weinberger wrote:
In my scripts I'm setting GIT_DIR to use git-fetch and git-reset without
changing the
current working directory all the time.
Yeah, for historical reasons GIT_WORK_TREE defaults to $(pwd) when
GIT_DIR is explicitly set.
In git versions including the patch
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
In git versions including the patch 2cd83d10bb6b (setup: suppress
implicit . work-tree for bare repos, 2013-03-08, currently in next
but not master), you can set GIT_IMPLICIT_WORK_TREE=0 to avoid this
behavior.
WAT
GIT_IMPLICIT_WORK_TREE exposed to let scripts cache the result of the
search for .git. Maybe something like GIT_BARE=(arbitrary value)
would be a good interface.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
diff --git a/cache.h b/cache.h
index 59e5b53..8f92b6d 100644
--- a/cache.h
+++ b/cache.h
Richard Weinberger wrote:
Okay, I have to set GIT_DIR _and_ GIT_WORK_TREE to make my scripts safe again?
I've always set only GIT_DIR because it just worked (till today...).
chdir-ing into the git repo without setting any GIT_* vars is probably
the simplest way to go.
--
To unsubscribe from
Jeff King wrote:
Both fixed in my re-roll.
Thanks! This and the rest of the patches up to and including patch 8
look good to me.
I haven't decided what to think about patch 9 yet, but I suspect it
would be good, too. In the long term I suspect git clone
--worktree-only repo (or some other
Jeff King wrote:
--- a/environment.c
+++ b/environment.c
@@ -194,6 +194,7 @@ void set_git_work_tree(const char *new_work_tree)
}
git_work_tree_initialized = 1;
work_tree = xstrdup(real_path(new_work_tree));
+ setenv(GIT_WORK_TREE_ENVIRONMENT, work_tree, 1);
}
Jeff King wrote:
On Tue, Mar 26, 2013 at 01:21:42PM -0700, Jonathan Nieder wrote:
If we want this warning, would something like the following do?
warning: You have set GIT_DIR without setting GIT_WORK_TREE
hint: In this case, GIT_WORK_TREE defaults to '.'
hint: To suppress
Jeff King wrote:
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -377,10 +377,40 @@ static void remove_junk(void)
static const char *junk_work_tree;
static const char *junk_git_dir;
static pid_t junk_pid;
+enum {
+ JUNK_LEAVE_NONE,
+ JUNK_LEAVE_REPO,
+ JUNK_LEAVE_ALL
+}
Hi,
Rich Fromm wrote:
The host executing the clone
command is different than the the host on which the remote repository lives,
and I am using ssh as a transport protocol. If there is corruption, can I
or can I not expect the clone operation to
Rob Hoelz wrote:
--- a/remote.c
+++ b/remote.c
@@ -465,7 +465,11 @@ static void alias_all_urls(void)
if (!remotes[i])
continue;
for (j = 0; j remotes[i]-pushurl_nr; j++) {
- remotes[i]-pushurl[j] =
Jeff King wrote:
There was a big thread about a month ago on whether Git should do Google
Summer of Code this year[1].
[...]
In my opinion, a lot of the issues come down to project selection;
Let me throw in some other issues. :)
* I think the git project has been very disorganized in
Ramkumar Ramachandra wrote:
Even then, working with one worktree embedded
inside another is something git never designed for: it explains why I
have to literally fight with git when using submodules
Do you mean that you wish you could ignore subrepository boundaries
and
flags. This way, authors of patches adding new flags that might want to
use the same bit can know to be careful.
Requested-by: Jeff King p...@peff.net
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Thanks,
Jonathan
builtin/add.c | 1 -
cache.h | 1 +
2 files changed, 1 insertion
Rob Hoelz wrote:
My mistake; I had not seen it! I thought you may have found a bug in
my implementation, so I wanted to double check. =)
Well, I had found an unfortunate consequence of the implementation
that uses an unnecessary copy. :)
Will follow up to the updated patch.
--
To unsubscribe
Josh Triplett wrote:
I have a .gitconfig in my git-managed home
directory which sets pushInsteadOf so that I can clone via git:// and
immediately have working push. I work with a number of systems that
don't have inbound access to each other but do have outbound access
Hi Carlos,
Carlos Martín Nieto wrote:
Add this shortcut just like git-push has it.
[...]
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -724,7 +724,7 @@ int cmd_branch(int argc, const char **argv, const char
*prefix)
OPT__QUIET(quiet, suppress informational messages),
: suppress signed/unsigned comparison warnings
vcs-svn: suppress a signed/unsigned comparison warning
Jonathan Nieder (4):
vcs-svn: allow import of 4GiB files
vcs-svn: suppress -Wtype-limits warning
vcs-svn: suppress a signed/unsigned comparison warning
vcs-svn: allow 64-bit
From: David Barr davidb...@google.com
Date: Fri, 1 Jun 2012 00:41:30 +1000
Since v1.7.5~42^2~6 (vcs-svn: remove buffer_read_string)
buffer_reset() does nothing thus fast_export_reset() also.
Signed-off-by: David Barr davidb...@google.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
-by: Jonathan Nieder jrnie...@gmail.com
---
Changes since v2:
- new description
vcs-svn/svndiff.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/vcs-svn/svndiff.c b/vcs-svn/svndiff.c
index c89d9623..e810d0c3 100644
--- a/vcs-svn/svndiff.c
+++ b/vcs-svn/svndiff.c
project which has not
needed to implement prefixcmp() yet.
Signed-off-by: David Barr davidb...@google.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Description clarified. No other change.
vcs-svn/svndump.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/vcs-svn
.
Signed-off-by: David Barr davidb...@google.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Clarified description. No other change since v2.
vcs-svn/fast_export.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/vcs-svn/fast_export.c b/vcs-svn/fast_export.c
index
for convenience using it in other projects.
Signed-off-by: David Barr davidb...@google.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
This is the easy part of what is a larger patch[1] in v2, split out
and given a new description for easier review.
[1] http://thread.gmane.org
From: David Barr davidb...@google.com
Date: Fri, 1 Jun 2012 00:41:29 +1000
The preceding code checks that view-max_off is nonnegative and
(off + width) fits in an off_t, so this code is already safe.
Signed-off-by: David Barr davidb...@google.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
From: Jonathan Nieder jrnie...@gmail.com
Date: Thu, 5 Jul 2012 22:21:09 -0500
All callers pass a nonnegative delta_len, so the code is already safe.
Add an assertion to ensure that remains so and add a cast to keep
clang and gcc -Wsign-compare from worrying.
Reported-by: David Barr davidb
.
So now you can import from a dump with more than 2 GiB of properties
for a node. In practice that isn't likely to happen often, and this
is mostly meant as a cleanup.
Based-on-patch-by: David Barr davidb...@google.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Another change
Hi,
I finally found some moments to revisit this series, so I'm starting
here. I think the justification for this patch is something like
this:
Keeping track of what files include each header is an error-prone
chore. On top of that, for l10n, these days we have to keep a master
list of
GIT_OBJS and VCSSVN_TEST_OBJS separately from the list of all
OBJECTS.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Jeff King wrote:
On Wed, Jun 20, 2012 at 04:07:30PM -0500, Jonathan Nieder wrote:
Should XDIFF_H and VCSSVN_H be folded into STATIC_HEADERS, too?
I stopped short
on an explanation from Jeff King.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Jeff King wrote:
On Wed, Jun 20, 2012 at 04:12:25PM -0500, Jonathan Nieder wrote:
Wouldn't it be simpler to put the ground rules in a comment or a
document somewhere under Documentation/ where they can
-off-by: Jeff King p...@peff.net
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Jeff King wrote:
I am tempted to get rid of the informative message altogether.
Like this?
.gitignore |1 +
Makefile | 10 --
2 files changed, 9 insertions(+), 2 deletions(-)
diff
mistake it replaces,
though.
Here's a patch on top to play with that names the new option
--set-upstream=. Untested.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
diff --git i/Documentation/git-branch.txt w/Documentation/git-branch.txt
index f572913f..57935a64 100644
--- i/Documentation/git
Hi,
Quick nitpicks.
Carlos Martín Nieto wrote:
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -864,10 +864,32 @@ int cmd_branch(int argc, const char **argv, const char
*prefix)
info and making sure new_upstream is correct */
create_branch(head,
901 - 1000 of 2895 matches
Mail list logo
