* [PATCH 2/2] Display warning for default git push with no push.default config
From: Finn Arne Gangstad @ 2009-03-16 15:42 UTC (permalink / raw)
To: git; +Cc: gitster, Finn Arne Gangstad
In-Reply-To: <1237218172-16565-1-git-send-email-finnag@pvv.org>
If a git push without any refspecs is attempted, display a warning.
The current default behavior is to push all matching refspecs, which
may come as a surprise to new users, so the warning shows how
push.default can be configured and what the possible values are.
Traditionalists who wish to keep the current behaviour are also told
how to configure this once and never see the warning again.
Signed-off-by: Finn Arne Gangstad <finnag@pvv.org>
---
Documentation/RelNotes-1.6.3.txt | 7 +++++++
builtin-push.c | 23 +++++++++++++++++++++++
2 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/Documentation/RelNotes-1.6.3.txt b/Documentation/RelNotes-1.6.3.txt
index 679ad28..d961bc8 100644
--- a/Documentation/RelNotes-1.6.3.txt
+++ b/Documentation/RelNotes-1.6.3.txt
@@ -22,6 +22,13 @@ branch pointed at by its HEAD, gets a large warning. You can choose what
should happen upon such a push by setting the configuration variable
receive.denyDeleteCurrent in the receiving repository.
+In a future release, the default of "git push" without further
+arguments may be changed. Currently, it will push all matching
+refspecs to the current remote. A configuration variable push.default
+has been introduced to select the default behaviour. To ease the
+transition, a big warning is issued if this is not configured and a
+git push without arguments is attempted.
+
Updates since v1.6.2
--------------------
diff --git a/builtin-push.c b/builtin-push.c
index 45fe843..c8e559f 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -64,11 +64,34 @@ static void setup_push_tracking(void)
add_refspec(refspec.buf);
}
+static const char *warn_unconfigured_push_msg[] = {
+ "You did not specify any refspecs to push, and the current remote",
+ "has not configured any push refspecs. The default action in this",
+ "case has been to push all matching refspecs, that is, all branches",
+ "that exist both locally and remotely will be updated.",
+ "This default may change in the future.",
+ "",
+ "You can specify what action you want to take in this case, and",
+ "avoid seeing this message again, by configuring 'push.default' to:",
+ " 'nothing' : Do not push anythig",
+ " 'matching' : Push all matching branches (the current default)",
+ " 'tracking' : Push the current branch to whatever it is tracking",
+ " 'current' : Push the current branch"
+};
+
+static void warn_unconfigured_push(void)
+{
+ int i;
+ for (i = 0; i < ARRAY_SIZE(warn_unconfigured_push_msg); i++)
+ warning("%s", warn_unconfigured_push_msg[i]);
+}
+
static void setup_default_push_refspecs(void)
{
git_config(git_default_config, NULL);
switch (push_default) {
case PUSH_DEFAULT_UNSPECIFIED:
+ warn_unconfigured_push();
/* fallthrough */
case PUSH_DEFAULT_MATCHING:
--
1.6.2.1.138.gc403b.dirty
^ permalink raw reply related
* Re: [PATCH v2] New config push.default to decide default behavior for push
From: Finn Arne Gangstad @ 2009-03-16 15:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viqmayslg.fsf@gitster.siamese.dyndns.org>
On Sun, Mar 15, 2009 at 09:55:23PM -0700, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> As some people still seem to object to the change of default (and that
> includes 20-30% of myself), we may end up deciding not to switch the
> default after all, but even in that case, applying the first half would
> benefit people who would want different behaviour.
I think the suggested new default is a lot safer then the current
one. A default of "nothing" will print a nice message if you end up
pushing nothing, which you will fix in a heartbeat with a single git
config command.
If you erroneously push one or more branches however, cleanup might
end up being very complicated. Many pushable repos are set up with
disallowing non-fast-forward pushes, so it may require intervention by
someone else to clean up, and by then someone else have already
fetched the bad push.
- Finn Arne
^ permalink raw reply
* Re: Transparently encrypt repository contents with GPG
From: Michael J Gruber @ 2009-03-16 16:01 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sverre Rabbelier, Thomas Rast, Matthias Nothhaft, git, Jeff King
In-Reply-To: <7viqmcaqov.fsf@gitster.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 14.03.2009 19:45:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> Since both the cleaned and the smudged version are supposed to be
>> "authoritative" (as opposed to the textconv'ed one) one may argue either
>> way what's the right approach.
>
> Smudged one can never be authoritative. That is the whole point of smudge
> filter and in general the whole convert_to_working_tree() infrastructure.
> It changes depending on who you are (e.g. on what platform you are on).
> So running comparison between two clean versions is the only sane thing to
> do.
Yes. I guess I'm being too much of a mathematician here: if clean is a
well-defined function, then clean(x) is well defined by specifying x. In
that sense x is equally authoritative.
Again, if smudge is the inverse of clean, i.e. smudge and clean are
bijective, then x differs from y iff clean(x) differs from clean(y).
> You could argue textconv should work on smudged contents or on clean
> contents before smudging. As long as it is done consistently, I do not
> care either way too deeply, as its output is not supposed to be used for
> anything but human consumption. Two equally sane arrangement would be:
>
> (1) Start from two clean contents (run convert_to_git() if contents were
> obtained from the work tree), run textconv, run diff, and output the
> result literally; or
>
> (2) Start from two smudged contents (run convert_to_working_tree() for
> contents taken from the repository), run textconv, run diff, and
> run clean before sending the result to the output.
>
> The former assumes a textconv filter that wants to work on clean
> contents, the latter for a one that expects smudged input. I probably
> would suggest going the former approach, as it is consistent with the
> general principle in other parts of the system (the internal processing
> happens on clean contents).
>
> Both of the above two assumes that the output should come in clean form;
> it is consistent with the way normal diff is generated for consumption by
> git-apply. You can certainly argue that the final output should be in
> smudged form when textconv is used, as it is purely for human consumption,
> and is not even supposed to be fed to apply.
Also, I don't expect clean to be necessarily meaningful when applied to
the result of textconv, and even less so to the output of diff.
Now, a simple test shows that git diff obviously does this when diffing
HEAD to worktree:
diff between HEAD and clean(worktree)
Which is the right thing. It just seems so that textconv is not even
called "in the wrong place of the chain", but messes the diff up in this
way:
diff between textconv(HEAD) and textconv(worktree)
(I expected clean(textconv(worktree)) first, which would be wrong, too).
I.e., the clean filter is ignored completely in the presence of textconv.
OK, I'll stop bugging you, until I checked the existing tests and the
code...
Michael
^ permalink raw reply
* Re: [PATCH 0/2] git checkout: one bugfix and one cosmetic change
From: Michael J Gruber @ 2009-03-16 16:12 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: git, Junio C Hamano
In-Reply-To: <cover.1237115791.git.barvik@broadpark.no>
Kjetil Barvik venit, vidit, dixit 15.03.2009 12:38:
> Just one small bugfix patch, and one small cosmetic change.
>
> By the way, I wonder how often the list of 'Primary Authors' and
> 'Contributors' on the webpage http://git-scm.com/about is updated.
> Should'nt it be updated when a new release, like v1.6.2, is made?
Assuming it looks at all non-merge commits on master, I can tell you it
has been updated after Dec 18 09:55:53 2008 -0800 and before Jan 14
09:29:24 2009 -0800 ;)
Cheers,
Michael
^ permalink raw reply
* Re: [StGit PATCH 5/5] Convert "float" to the lib infrastructure
From: Catalin Marinas @ 2009-03-16 16:36 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20090313024137.GE15393@diana.vm.bytemark.co.uk>
2009/3/13 Karl Hasselström <kha@treskal.com>:
> On 2009-03-12 12:09:18 +0000, Catalin Marinas wrote:
>> options = [
>> opt('-s', '--series', action = 'store_true',
>> - short = 'Rearrange according to a series file')]
>> + short = 'Rearrange according to a series file')
>> + ] + argparse.keep_option()
>
> This flag should take the filename as a parameter, both because it's
> the right thing to do and because it'll make the tab completion work
> right (as is, it'll complete on patch names after the -s flag).
>
> Something like
>
> opt('-s', '--series', type = 'string')
>
> ought to do it.
This command was accepting series via the stdin as well (maybe for
easier use in other scripts or from stgit.el). Anyway, it doesn't seem
to make any difference with the bash completion. It still tries to
complete patches but when this fails bash lists files if the prefix
matches some.
--
Catalin
^ permalink raw reply
* Re: [PATCH] Give error when no remote is configured
From: Daniel Barkalow @ 2009-03-16 16:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: bernie, git, Giovanni Bajo
In-Reply-To: <7vocw2x7ob.fsf@gitster.siamese.dyndns.org>
On Mon, 16 Mar 2009, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > When there's no explicitly-named remote, we use the remote specified
> > for the current branch, which in turn defaults to "origin". But it
> > this case should require the remote to actually be configured, and not
> > fall back to the path "origin".
>
> This is seriously broken.
>
> > @@ -643,11 +656,22 @@ static int valid_remote_nick(const char *name)
> > struct remote *remote_get(const char *name)
> > {
> > struct remote *ret;
> > + int name_given = 0;
> >
> > read_config();
> > - if (!name)
> > + if (name)
> > + name_given = 1;
> > + else {
> > name = default_remote_name;
> > - ret = make_remote(name, 0);
> > + name_given = explicit_default_remote_name;
> > + }
> > + if (name_given)
> > + ret = make_remote(name, 0);
> > + else {
> > + ret = get_remote_by_name(name);
> > + if (!ret)
> > + return NULL;
> > + }
>
> When you do not have any config entry to name your remotes but have been
> using .git/remotes/origin happily, you may have read config already at
> this point, but when you call get_remote_by_name() you haven't read
> anything from .git/remotes/* (nor .git/branches/* for that matter). The
> caller will get NULL in such a case. This happens for both fetch and
> push.
That's actually a simple bug; the block that's just after what you quoted
should be just before it. I thought we had a test for having "origin"
defined by one of the old methods, but I guess not. Your version is
better, though; I'd forgotten that using the name as the URL was in
remote_get() and not make_remote().
> Because you did not have any test to protect whatever you wanted to "fix"
> with your patch, I have no way knowing if I am breaking something else you
> wanted to do with your patch,
$ git init
$ git fetch
Shouldn't try fetching from ./origin/.git; I suppose the best test would
be to do something like:
$ mkdir origin
$ (cd origin; git init; touch a; git add a; git commit -m "initial")
$ git init
$ git fetch
With test_must_fail. (But I'm more going for having it not give weird
errors in an error situation, which is kind of fluffy to try to test.)
> but the patch below at least fixes the
> regression for me when running "git pull" in a repository I initialized
> long time ago that does not use the .git/config file to specify where my
> remote repositories are.
>
> It applies on top of fa685bd (Give error when no remote is configured,
> 2009-03-11)
>
> -- >8 --
> Subject: Remove total confusion from git-fetch and git-push
>
> The config file is not the only place remotes are defined, and without
> consulting .git/remotes and .git/branches, you won't know if "origin" is
> configured by the user. Don't give up too early and insult the user with
> a wisecrack "Where do you want to fetch from today?"
You actually wrote that message, in 853a3697. I think a better message
would probably be something like:
No default remote is configured for your current branch, and the default
remote "origin" is not configured either.
I think the message missed being made user-friendly in earlier passes due
to being inaccessible at the time.
> Insulting is ok, but I personally get really pissed off if a tool is both
> confused and insulting. At least be _correct_ and insulting.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> remote.c | 21 ++++-----------------
> 1 files changed, 4 insertions(+), 17 deletions(-)
>
> diff --git a/remote.c b/remote.c
> index 199830e..9f07dbc 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -105,16 +105,6 @@ static void add_url_alias(struct remote *remote, const char *url)
> add_url(remote, alias_url(url));
> }
>
> -static struct remote *get_remote_by_name(const char *name)
> -{
> - int i;
> - for (i = 0; i < remotes_nr; i++) {
> - if (!strcmp(name, remotes[i]->name))
> - return remotes[i];
> - }
> - return NULL;
> -}
> -
> static struct remote *make_remote(const char *name, int len)
> {
> struct remote *ret;
> @@ -665,19 +655,16 @@ struct remote *remote_get(const char *name)
> name = default_remote_name;
> name_given = explicit_default_remote_name;
> }
> - if (name_given)
> - ret = make_remote(name, 0);
> - else {
> - ret = get_remote_by_name(name);
> - if (!ret)
> - return NULL;
> - }
> +
> + ret = make_remote(name, 0);
> if (valid_remote_nick(name)) {
> if (!ret->url)
> read_remotes_file(ret);
> if (!ret->url)
> read_branches_file(ret);
> }
> + if (!name_given && !ret->url)
> + return NULL;
> if (!ret->url)
> add_url_alias(ret, name);
> if (!ret->url)
>
^ permalink raw reply
* Re: adding files in .git?
From: Matthieu Moy @ 2009-03-16 16:56 UTC (permalink / raw)
To: E R; +Cc: git
In-Reply-To: <3a69fa7c0903160814u42fbb461qf03a37176546357d@mail.gmail.com>
E R <pc88mxer@gmail.com> writes:
> 1) Use another file in .git similar to the "description" file (such as
> .git/short-description)
> 2) Use a setting in the .git/config file.
>
> Any comments on the advantages/disadvantages of these approaches?
Neither of them will propagate through clone. Depending on your
use-case, this is an advantage or not.
--
Matthieu
^ permalink raw reply
* [PATCHv2 0/2] Allow running the test suite against installed git
From: Michael J Gruber @ 2009-03-16 17:03 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7v3adfc0n4.fsf@gitster.siamese.dyndns.org>
Part 1 corrects only an inconsistency which does not matter as long as
you run tests against git compiled in a checkout only: There,
$GIT_EXEC_PATH contains git, in general it does not.
Part 2 allows running the test suite against a git installed anywhere in
the file system. This has at least 2 use cases:
- Test an installed distro package after the installation.
- Run easily current tests against older versions, or vice versa, if you
have those versions installed somewhere.
Note that one still needs git compiled in git.git for test helpers etc.,
and also because I did not adjust the paths to templates and such. I did
not really feel a need for that.
Also, in t0000 there is still one explicit use of "../git" which is fine
because it simply tests for the presence of a build, which we need
anyways.
v2 incorporates feed-back by JCH: variables are named GIT_TEST_INSTALLED
and GIT_TEST_EXEC_PATH now, the latter defaulting to the output of
$GIT_TEST_INSTALLED/git --exec-path.
Also, we exit gracefully in case we cannot run $GIT_TEST_INSTALLED/git.
Michael J Gruber (2):
test-lib.sh: Test for presence of git-init in the right path.
test-lib.sh: Allow running the test suite against installed git
t/test-lib.sh | 14 +++++++++++---
1 files changed, 11 insertions(+), 3 deletions(-)
^ permalink raw reply
* [PATCHv2 1/2] test-lib.sh: Test for presence of git-init in the right path.
From: Michael J Gruber @ 2009-03-16 17:03 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7v3adfc0n4.fsf@gitster.siamese.dyndns.org>
It just happens so that when GIT_EXEC_PATH points to a compiled checkout
of git.git it contains "git". Since this is not true in general make
test-lib check for "git-init" which is always in GIT_EXEC_PATH.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
t/test-lib.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 7a847ec..b9da86e 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -454,7 +454,7 @@ test_create_repo () {
repo="$1"
mkdir -p "$repo"
cd "$repo" || error "Cannot setup test environment"
- "$GIT_EXEC_PATH/git" init "--template=$owd/../templates/blt/" >&3 2>&4 ||
+ "$GIT_EXEC_PATH/git-init" "--template=$owd/../templates/blt/" >&3 2>&4 ||
error "cannot run git init -- have you built things yet?"
mv .git/hooks .git/hooks-disabled
cd "$owd"
--
1.6.2.149.g6462
^ permalink raw reply related
* [PATCHv2 2/2] test-lib.sh: Allow running the test suite against installed git
From: Michael J Gruber @ 2009-03-16 17:03 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7v3adfc0n4.fsf@gitster.siamese.dyndns.org>
Introduce variables GIT_TEST_INSTALLED and GIT_TEST_EXEC_PATH such that
the test suite can be run against a git which is installed at
GIT_TEST_INSTALLED with subcommands at GIT_TEST_EXEC_PATH.
GIT_TEST_INSTALLED defaults to the git.git checkout, GIT_TEST_EXEC_PATH
defaults to the output of '$GIT_TEST_INSTALLED/git --exec-path'. Run the
suite e.g. as
GIT_TEST_INSTALLED=/some/path make test
but note that this requires and uses parts of a compiled git in the
git.git checkout: test helpers, templates and perl libraries are taken
from there.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
t/test-lib.sh | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index b9da86e..c677904 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -514,8 +514,16 @@ test_done () {
TEST_DIRECTORY=$(pwd)
if test -z "$valgrind"
then
- PATH=$TEST_DIRECTORY/..:$PATH
- GIT_EXEC_PATH=$TEST_DIRECTORY/..
+ if test -z "$GIT_TEST_INSTALLED"
+ then
+ PATH=$TEST_DIRECTORY/..:$PATH
+ GIT_EXEC_PATH=$TEST_DIRECTORY/..
+ else
+ GIT_EXEC_PATH=$($GIT_TEST_INSTALLED/git --exec-path) ||
+ error "Cannot run git from $GIT_TEST_INSTALLED."
+ PATH=$GIT_TEST_INSTALLED:$TEST_DIRECTORY/..:$PATH
+ GIT_EXEC_PATH=${GIT_TEST_EXEC_PATH:-$GIT_EXEC_PATH}
+ fi
else
make_symlink () {
test -h "$2" &&
--
1.6.2.149.g6462
^ permalink raw reply related
* Re: [PATCH] grep: prefer builtin over external one when coloring results
From: René Scharfe @ 2009-03-16 17:31 UTC (permalink / raw)
To: pclouds; +Cc: git, gitster, thiago.salves
In-Reply-To: <1237170004-27768-1-git-send-email-pclouds@gmail.com>
pclouds@gmail.com schrieb:
> As far as I know, not all grep programs support coloring, so we should
> rely on builtin grep. If you want external grep, set
> color.grep.external to empty string.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> How about this?
>
> builtin-grep.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/builtin-grep.c b/builtin-grep.c
> index 9e7e766..89489dd 100644
> --- a/builtin-grep.c
> +++ b/builtin-grep.c
> @@ -825,6 +825,8 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
> }
> }
>
> + if (opt.color && !opt.color_external)
> + builtin_grep = 1;
> if (!opt.pattern_list)
> die("no pattern given.");
> if ((opt.regflags != REG_NEWLINE) && opt.fixed)
Makes sense, thanks!
René
^ permalink raw reply
* [PATCH] jgit: upload-pack: Force an fd flush after receiving flush pkt from client
From: Dima Zavin @ 2009-03-16 17:34 UTC (permalink / raw)
To: git; +Cc: spearce, Dima Zavin
Signed-off-by: Dima Zavin <dima@android.com>
---
.../src/org/spearce/jgit/transport/UploadPack.java | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/UploadPack.java b/org.spearce.jgit/src/org/spearce/jgit/transport/UploadPack.java
index 71acda1..80c154b 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/UploadPack.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/UploadPack.java
@@ -351,7 +351,7 @@ private void negotiate() throws IOException {
if (line.length() == 0) {
if (commonBase.isEmpty() || multiAck)
pckOut.writeString("NAK\n");
-
+ pckOut.flush();
} else if (line.startsWith("have ") && line.length() == 45) {
final ObjectId id = ObjectId.fromString(line.substring(5));
if (matchHave(id)) {
@@ -372,7 +372,6 @@ private void negotiate() throws IOException {
} else if (line.equals("done")) {
if (commonBase.isEmpty())
pckOut.writeString("NAK\n");
-
else if (multiAck)
pckOut.writeString("ACK " + last.name() + "\n");
break;
--
1.6.2
^ permalink raw reply related
* Re: git-p4 workflow suggestions?
From: Sam Hocevar @ 2009-03-16 18:01 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git
In-Reply-To: <20090311125805.GA28155@padd.com>
On Wed, Mar 11, 2009, Pete Wyckoff wrote:
> sam@zoy.org wrote on Mon, 09 Mar 2009 15:21 +0100:
> > I have modified git and git-p4 to a point where they are usable in
> > my work environment. I am now faced with a new problem: Perforce's
> > composite workspaces. They allow you to "mount" parts of the repo onto
> > other directories, even nonempty ones.
> >
> > Take the following example repository, where a "framework" project
> > contains an example subdirectory with build files and other directories,
> > and a "project1" project contains subdirectories that are meant to
> > replace the ones in "example":
> >
> > //work/framework/example/src/
> > /include/
> > /Makefile
> > /...
> > //work/project1/src/
> > /include/
>
> In perforce terms, your "view mapping" looks like:
>
> //work/framework/example/src/... //client/src/...
> //work/project1/src/include/... //client/src/include/...
Yes, like this. More precisely:
//work/framework/example/... //client/...
//work/project1/src/... //client/src/...
//work/project1/include/... //client/include/...
> I'm not a pro with p4, but do deal with many-line mappings like
> this. Stock git-p4 handles these, except doesn't map correctly to
> the right-hand side. I haven't tried to see if it would correctly
> use the include files from project1 instead of framework in your
> example.
No luck here. If I clone //work with git-p4, I get two separate
/framework and /project1 directories, and the mapping is not done.
The "solution" I found so far was to clone //work and hack git-p4
so that it ignores //work/framework/example/src, and then symlink
//work/project1/src to //work/framework/example/src. This allows me to
pull changes with a single "git-p4 rebase" command. Unfortunately it
also requires me to clone a full, separate //work p4 workspace in order
to use "git-p4 submit" later, and that's more than 120 GiB wasted.
> If you can get git-p4 to figure out the mapping correctly, I don't
> expect any problems with respect to atomicity of commits. As far as
> perforce goes, a server seems to manage its entire p4 space as one
> big single project. Similarly with the git side of things---it's
> just a matter of getting this mapping correct.
>
> I too hacked the getClientSpec() part of git-p4 to put files into
> the correct directories in the git side. My changes are a bit
> messy, and may interfere with other usage models, hence not
> submitted. Maybe we should make an effort to get this right though.
> Do you have any changes to show how you are modifying things?
I'm curious to see your changes. I don't feel I completely understand
the p4 way to do things yet.
My changes are extremely messy but I will refactor them as time goes.
There is at least one other important thing my git-p4 does, which is not
storing the whole commit in memory. Combined with the patches I sent
last week to this list, it's the only way I can import the p4 repository
we have at work. (See http://zoy.org/~sam/git/clumsily-hacked-git-p4)
Feel free to contact me in private if you have questions or want
information that may not be mailing-list relevant. I'm all for cleaning
up things and getting a fully featured git-p4. I'm on that project for
at least three years, and there is absolutely no way my blood pressure
can stand that long with Perforce.
Cheers,
--
Sam.
^ permalink raw reply
* [PATCH] pickaxe: count regex matches only once
From: René Scharfe @ 2009-03-16 18:38 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Petr Baudis
When --pickaxe-regex is used, forward past the end of matches instead of
advancing to the byte after their start. This way matches count only
once, even if the regular expression matches their tail -- like in the
fixed-string fork of the code.
E.g.: /.*/ used to count the number of bytes instead of the number of
lines. /aa/ resulted in a count of two in "aaa" instead of one.
Also document the fact that regexec() needs a NUL-terminated string as
its second argument by adding an assert().
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
diffcore-pickaxe.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/diffcore-pickaxe.c b/diffcore-pickaxe.c
index 574b3e8..d0ef839 100644
--- a/diffcore-pickaxe.c
+++ b/diffcore-pickaxe.c
@@ -25,10 +25,12 @@ static unsigned int contains(struct diff_filespec *one,
regmatch_t regmatch;
int flags = 0;
+ assert(data[sz] == '\0');
while (*data && !regexec(regexp, data, 1, ®match, flags)) {
flags |= REG_NOTBOL;
- data += regmatch.rm_so;
- if (*data) data++;
+ data += regmatch.rm_eo;
+ if (*data && regmatch.rm_so == regmatch.rm_eo)
+ data++;
cnt++;
}
--
1.6.2.1
^ permalink raw reply related
* git confusing a submodule & subdirectory?
From: Juan Zanos @ 2009-03-16 18:39 UTC (permalink / raw)
To: git
Is it possible for git to confuse a submodule with a subdirectory?
When I modify my submodule git seems to think the directory has
changed. A commit isn't going to add all that content to the
containing repository. Is it?
Best,
Juan
^ permalink raw reply
* Re: fetch and pull
From: John Dlugosz @ 2009-03-16 19:00 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
=== Re: ===
> So, after inspecting the changes, how do you fast-forward your local
dev
> to sync up with origin/dev?
$ git push . origin/dev dev
=== end ===
That did not work. It just reports "everything up to date". If I
understand the point of what it does correctly, I think
$ git push . +origin/dev:dev
is correct.
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* Re: git-svn: creating tags from a subdirectory of trunk
From: Tom Huybrechts @ 2009-03-16 19:02 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20090315232105.GA21667@dcvr.yhbt.net>
On Mon, Mar 16, 2009 at 12:21 AM, Eric Wong <normalperson@yhbt.net> wrote:
> Tom Huybrechts <tom.huybrechts@gmail.com> wrote:
>> Hi,
>>
>> I'm trying to setup a git mirror of a svn repository. The tags in
>> this repository are not created trunk it self, but from subdirectories
>> of trunk. The tags and branches are in the standard places.
>> e.g:
>> /trunk/main -> tags/main-1
>> /trunk/plugins/foo -> tags/foo-1
>> /trunk/plugins/bar -> tags/bar-1
>>
>> I run 'git svn clone -s svn-url target'. It starts going over the
>> history nicely until it reaches the first branch. It calls this branch
>> something like tags/tag-name@revision, and starts retrieving the
>> entire project history again from r1. This is repeated for every
>> branch.
>
> Hi Tom,
>
> This is a known problem with some repositories. My suggestion is to
> use individual "fetch" directives for each of those tags you want to
> follow.
>
> The -s/--stdlayout is only for projects that follow the SVN-recommended
> repository layout exactly and we haven't thought of a generic way to
> handle those non-standard tags in repos...
>
> --
> Eric Wong
>
Hi Eric,
The repository I'm trying to convert is that of Hudson. I did some
digging in the list archives, and found this came up earlier
(2009/01/08).
Back then you replied:
"""
Alternately, you could just clone the root and have all the branches all
over the place in one tree (your eventually working copy will be huge).
git svn clone https://svn.dev.java.net/svn/hudson
Basically this is the equivalent of:
svn co https://svn.dev.java.net/svn/hudson
Except you'll have the full history.
"""
Is that still valid ? That is what I did, and which caused the
behaviour I described.
Tom
^ permalink raw reply
* undoing something
From: John Dlugosz @ 2009-03-16 19:06 UTC (permalink / raw)
To: git
I made a mistake. Big deal, now that I know that git storage is
immutable and changes just add to what's already there.
A quick look at
git reflog show topic
tells me that {1} is the one I want. So, how do I rewind branch topic
to point to topic@{1} ?
I did it by making a tag, and then in gitk pointing to it and picking
"reset to here" from the context menu.
A while back I was looking for the right/easy way to simply repoint my
branch to where I wanted. The best answer was to use push. But, I
wonder if gitk and other high-level commands simply call a more
primitive command that does this? And can I call it directly? Or is
push with a dot as the repository just doing this with no excessive
processing and trust that the side-effects are all vacuous?
--John
(please excuse the footer; it's not my choice)
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* Re: undoing something
From: Junio C Hamano @ 2009-03-16 19:14 UTC (permalink / raw)
To: John Dlugosz; +Cc: git
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E70A2AEFA4@EXCHANGE.trad.tradestation.com>
"John Dlugosz" <JDlugosz@TradeStation.com> writes:
> I made a mistake. Big deal, now that I know that git storage is
> immutable and changes just add to what's already there.
>
> A quick look at
> git reflog show topic
> tells me that {1} is the one I want. So, how do I rewind branch topic
> to point to topic@{1} ?
> I did it by making a tag, and then in gitk pointing to it and picking
> "reset to here" from the context menu.
>
> A while back I was looking for the right/easy way to simply repoint my
> branch to where I wanted. The best answer was to use push.
The answer was best only because in your previous question you wanted to
ensure fast-forwardness, i.e. "git push . origin/dev:dev" without plus in
front to cause it to fail if it is not fast-forward.
If you know you have one unwanted commit you would want to discard at the
tip of topic, you do not want fast-foward safety to kick in.
(1) if you are on the topic branch, you can say "git reset --hard HEAD^";
or
(2) if you are not, you can obviously check out topic and do the above,
or "git branch -f topic topic^".
If the garbage you have at the tip of the topic is not just a single
commit, you can replace HEAD^ and topic^ in the above with whatever commit
you would want to point the tip at.
^ permalink raw reply
* RE: undoing something
From: John Dlugosz @ 2009-03-16 19:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7veiwxwa9z.fsf@gitster.siamese.dyndns.org>
=== Re: ===
The answer was best only because in your previous question you wanted to
ensure fast-forwardness, i.e. "git push . origin/dev:dev" without plus
in
front to cause it to fail if it is not fast-forward.
=== end ===
No, I don't want to ensure ff. The remote may have been changed in
other ways. Though in that case I will avoid doing so; when it is not
the case it's even more important to see that your local copy is
different, and understand the tree, rather than blindly pulling.
=== Re: ===
If you know you have one unwanted commit you would want to discard at
the
tip of topic, you do not want fast-foward safety to kick in.
(1) if you are on the topic branch, you can say "git reset --hard
HEAD^";
or
=== end ===
It was a rebase, so the old value is not under the current, or even
visible on the tree. That's why I needed the reflog to find it.
Tagging it let it appear in gitk.
=== Re: ===
(2) if you are not, you can obviously check out topic and do the above,
or "git branch -f topic topic^".
=== end ===
As documented, this destroys the existing branch and makes a new one.
That would, by design, blow away the reflog for that branch. What I
want is a way to re-point it, and record that repointing =in= the
reflog. That is, a command-line version that does what I can do with
the GUI, but isn't limited to what I can point to with the mouse.
--John
(please excuse the footer, yadda yadda)
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* Re: [PATCH] Give error when no remote is configured
From: Jay Soffian @ 2009-03-16 20:01 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, bernie, git, Giovanni Bajo
In-Reply-To: <alpine.LNX.1.00.0903161204240.19665@iabervon.org>
On Mon, Mar 16, 2009 at 12:55 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> No default remote is configured for your current branch, and the default
> remote "origin" is not configured either.
The use of "default" twice is slightly confusing. Perhaps:
No remote is configured for the current branch, and the default
remote "origin" is not configured either.
j.
^ permalink raw reply
* Re: fetch and pull
From: Jay Soffian @ 2009-03-16 20:03 UTC (permalink / raw)
To: John Dlugosz; +Cc: git, Junio C Hamano
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E70A2AEF9A@EXCHANGE.trad.tradestation.com>
On Mon, Mar 16, 2009 at 3:00 PM, John Dlugosz <JDlugosz@tradestation.com> wrote:
> === Re: ===
>> So, after inspecting the changes, how do you fast-forward your local
> dev
>> to sync up with origin/dev?
>
> $ git push . origin/dev dev
> === end ===
>
> That did not work. It just reports "everything up to date". If I
> understand the point of what it does correctly, I think
>
> $ git push . +origin/dev:dev
>
> is correct.
You very likely do not want the '+' at the start:
$ git push . origin/dev:dev
j.
^ permalink raw reply
* Re: [PATCH2/2] Libify blame
From: Miklos Vajna @ 2009-03-16 20:04 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: pi song, git, gitster, rene.scharfe
In-Reply-To: <fabb9a1e0903160649o6b576976jeb884e18713c154e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 260 bytes --]
On Mon, Mar 16, 2009 at 02:49:31PM +0100, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> It would be nice if you could paste the output of "git diff -M" after
> the triple-dash to show that it is indeed only a small change.
Or just use git format-patch -M?
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] jgit: upload-pack: Force an fd flush after receiving flush pkt from client
From: Shawn O. Pearce @ 2009-03-16 20:05 UTC (permalink / raw)
To: Dima Zavin; +Cc: git
In-Reply-To: <1237224864-15649-1-git-send-email-dima@android.com>
Dima Zavin <dima@android.com> wrote:
> diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/UploadPack.java b/org.spearce.jgit/src/org/spearce/jgit/transport/UploadPack.java
> index 71acda1..80c154b 100644
> --- a/org.spearce.jgit/src/org/spearce/jgit/transport/UploadPack.java
> +++ b/org.spearce.jgit/src/org/spearce/jgit/transport/UploadPack.java
> @@ -351,7 +351,7 @@ private void negotiate() throws IOException {
> if (line.length() == 0) {
> if (commonBase.isEmpty() || multiAck)
> pckOut.writeString("NAK\n");
> -
> + pckOut.flush();
> } else if (line.startsWith("have ") && line.length() == 45) {
> final ObjectId id = ObjectId.fromString(line.substring(5));
> if (matchHave(id)) {
Applied, but with this more verbose commit message:
--8<--
upload-pack: Force an fd flush after receiving flush pkt from client
The client is blocked waiting for an ACK or NAK line from the server.
If we don't call flush() here there is a very good chance the
ACK/NAK is stuck in our stream buffer within the JRE, and doesn't
make it into the kernel's TCP buffer. This causes the server to
wait for more have lines, and the client to wait for the ACK/NAK,
and the entire thing just deadlocks.
We flush anytime we see a pkt-line flush command, as there may be
buffered ACK lines from prior evaulations that need to be sent to
the waiting client.
Signed-off-by: Dima Zavin <dima@android.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
--
Shawn.
^ permalink raw reply
* Re: [JGIT PATCH] Create a debugging tool "jgit rebuild-commitgraph"
From: Robin Rosenberg @ 2009-03-16 20:09 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20090316144450.GN22920@spearce.org>
måndag 16 mars 2009 15:44:50 skrev "Shawn O. Pearce" <spearce@spearce.org>:
> Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> >
> > I'd hate to put such a dangerous thing in the list of normal tools. If the user
> > want to shoot him/her-self in the foot they should get a license first.
>
> How about squashing this in?
Does it have to be a utility accessible through the pgm interface? Why not
just run ut as java org.spearce.jgit.pgm.debug.RebuildCommitGraph ?
>
> diff --git a/org.spearce.jgit.pgm/src/org/spearce/jgit/pgm/RebuildCommitGraph.java b/org.spearce.jgit.pgm/src/org/spearce/jgit/pgm/RebuildCommitGraph.java
> index ccee997..cc23438 100644
> --- a/org.spearce.jgit.pgm/src/org/spearce/jgit/pgm/RebuildCommitGraph.java
> +++ b/org.spearce.jgit.pgm/src/org/spearce/jgit/pgm/RebuildCommitGraph.java
> @@ -50,6 +50,7 @@
> import java.util.Map;
>
> import org.kohsuke.args4j.Argument;
> +import org.kohsuke.args4j.Option;
> import org.spearce.jgit.errors.MissingObjectException;
> import org.spearce.jgit.errors.ObjectWritingException;
> import org.spearce.jgit.lib.Commit;
> @@ -85,6 +86,11 @@
> * <p>
> */
> class RebuildCommitGraph extends TextBuiltin {
> + private final String REALLY = "--destroy-this-repository";
> +
> + @Option(name = REALLY, usage = "approve destruction of repository")
> + boolean really;
> +
> @Argument(index = 0, required = true, metaVar = "REFS", usage = "for-each-ref output")
> File refList;
>
> @@ -97,6 +103,30 @@
>
> @Override
> protected void run() throws Exception {
> + if (!really && !db.getAllRefs().isEmpty()) {
> + final StringBuilder m = new StringBuilder();
> + m.append("fatal: ");
> + m.append("This program will destroy the repository:");
> + m.append("\n");
> + m.append("fatal:\n");
> + m.append("fatal: ");
> + m.append(db.getDirectory().getAbsolutePath());
> + m.append("\n");
> + m.append("fatal:\n");
> + m.append("fatal: ");
> + m.append("To continue, add ");
> + m.append(REALLY);
> + m.append(" to the command line");
> + m.append("\n");
> + m.append("fatal:");
> + System.err.println(m);
> + throw die("Need approval to destroy current repository");
What's wrong with old fashioned '+' ? (which just translated to exactly this series
of StringBuilder calls anyway?
> + }
> + if (!refList.isFile())
> + throw die("no such file: " + refList.getPath());
> + if (!graph.isFile())
> + throw die("no such file: " + graph.getPath());
> +
> recreateCommitGraph();
> detachHead();
> deleteAllRefs();
-- robin
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox