* Re: [PATCH] git daemon: avoid calling syslog() from a signal handler
From: Johannes Schindelin @ 2008-07-05 10:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Foster, git
In-Reply-To: <7vej68u6mr.fsf@gitster.siamese.dyndns.org>
Hi,
On Sat, 5 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Signal handlers should never call syslog(), as that can raise signals
> > of its own.
> >
> > Instead, call the syslog() from the master process.
>
> Earlier parts seem to make sense but I am puzzled by these changes.
>
> > @@ -929,7 +945,8 @@ static int service_loop(int socknum, int *socklist)
> > for (;;) {
> > int i;
> >
> > - if (poll(pfd, socknum, -1) < 0) {
> > + i = poll(pfd, socknum, 1);
> > + if (i < 0) {
> > if (errno != EINTR) {
> > error("poll failed, resuming: %s",
> > strerror(errno));
> > @@ -937,6 +954,10 @@ static int service_loop(int socknum, int *socklist)
> > }
> > continue;
> > }
> > + if (i == 0) {
> > + check_dead_children();
> > + continue;
> > + }
>
> So you will check every 1ms to see if there are new dead children, but why
> is this necessary?
This comes from me not reading the man page for poll() properly. Of
course, I want to check every second: syslog timestamps the messages with
a resolution of 1 second, AFAIR, or at least some of them do.
So if you could just squash in this patch, that would be smashing:
-- snipsnap --
@@ -945,8 +945,8 @@ static int service_loop(int socknum, int *socklist)
for (;;) {
int i;
- i = poll(pfd, socknum, 1);
+ i = poll(pfd, socknum, 1000);
if (i < 0) {
if (errno != EINTR) {
error("poll failed, resuming: %s",
strerror(errno));
^ permalink raw reply
* Re: Can I remove stg sync --undo ?
From: Karl Hasselström @ 2008-07-05 8:33 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0807041505oc15660bpcd62a62100e517b9@mail.gmail.com>
On 2008-07-04 23:05:11 +0100, Catalin Marinas wrote:
> 2008/7/4 Karl Hasselström <kha@treskal.com>:
>
> > On 2008-07-03 23:02:28 +0100, Catalin Marinas wrote:
> >
> > > The sync performs three operations - push, merge and refresh (if
> > > the refresh is automatic after merge, it doesn't update the
> > > backup information since it was done by merge).
> > >
> > > If merge fails, the refresh is manual after solving the
> > > conflicts. I suspect this will be recorded as a separate step
> > > for undo
> >
> > Yeah, the new undo stuff will currently handle sync just like e.g.
> > push and pop: write one log entry when the command's all done,
> > plus one extra just before the conflicting push if there is one.
> > So you can always undo the entire command; and in case of
> > conflicts, you also have the option of undoing just the
> > conflicting push. Is this enough for sync?
>
> There are two operations that can conflict for sync - pushing a
> patch and the actual sync'ing, i.e. a three-way merge with the patch
> to be synchronised with (kind of fold).
My guess is that conflicts of the first type would work out of the box
(i.e. they'd get an extra log entry) while conflicts of the second
type would not.
We need a sync undo test.
> > > (BTW, is resolved take into account for undo?).
> >
> > Hmmm, what do you mean by "resolved"?
>
> The current resolved command - the clearing of the conflicting
> entries in the index.
With just "stg undo" (or reset or redo), you get the usual
new-infrastructure check about dirty index and working tree (the whole
index must be clean, and the parts of the worktree we need to touch
must be clean). Which prevents you from undoing a conflicting push,
for example.
With the --hard flag, any uncleanliness in index or worktree simply
gets zapped (just like with git reset --hard). I'm not 100% happy with
this -- what I'd really like is to zap only the files that we need to
touch. But I haven't figured out a good way to do that.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: git sequencer prototype
From: Alex Riesen @ 2008-07-05 8:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephan Beyer, git, Johannes Schindelin
In-Reply-To: <7vwsk1ti6y.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, Sat, Jul 05, 2008 00:09:41 +0200:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
> > Stephan Beyer, Tue, Jul 01, 2008 04:38:30 +0200:
> >> Hi,
> >>
> >> here is the patchset for the git-sequencer prototype, documentation,
> >> test suite and a first git-am and git-rebase-i migration.
> >> Indeed, monster patches. ;)
> >
> > BTW, how about renaming it in something short: git seq. There is
> > already a seq(1) in GNU coreutils, which does roughly the same (prints
> > a sequence of numbers), why not reuse the name?
>
> Is it advantageous to use shorter but less descriptive name for this
> command? It will be a backend to am/rebase and not something the users
> will type from the command line, won't it?
There is not a huge lot of possible meanings of "seq" in the given
context. Somehow I find it hard to believe someone will be confused by
a backend command with a short name "seq" (seq-uence-something?)
It'll make the lines shorter, less need to wrap them.
BTW, what does "am" (git am) mean?
^ permalink raw reply
* Re: [PATCH] git daemon: avoid calling syslog() from a signal handler
From: Junio C Hamano @ 2008-07-05 7:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Brian Foster, git
In-Reply-To: <alpine.DEB.1.00.0807031624020.9925@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Signal handlers should never call syslog(), as that can raise signals
> of its own.
>
> Instead, call the syslog() from the master process.
Earlier parts seem to make sense but I am puzzled by these changes.
> @@ -929,7 +945,8 @@ static int service_loop(int socknum, int *socklist)
> for (;;) {
> int i;
>
> - if (poll(pfd, socknum, -1) < 0) {
> + i = poll(pfd, socknum, 1);
> + if (i < 0) {
> if (errno != EINTR) {
> error("poll failed, resuming: %s",
> strerror(errno));
> @@ -937,6 +954,10 @@ static int service_loop(int socknum, int *socklist)
> }
> continue;
> }
> + if (i == 0) {
> + check_dead_children();
> + continue;
> + }
So you will check every 1ms to see if there are new dead children, but why
is this necessary?
^ permalink raw reply
* Git, merging, and News/Relnotes files
From: Edward Z. Yang @ 2008-07-05 7:24 UTC (permalink / raw)
To: git
As a policy on a project that I manage, almost every commit warrants a
change to our NEWS (changelog) file, which end-users can browse to get
an in-depth idea of the changes that have happened from the last
release. If it's an added feature, the changelog includes a description
of how to use it; if it's a fixed bug, it briefly describes what
happened. Internal changes may or may not get added, depending on the
visibility of the APIs affected.
Something that I've noticed recently, as we've started migrating away
from the ghetto SVN development model to the Git branchy model, is that
this NEWS file ends up being the source of a lot of conflicts. Granted,
they're easy conflicts to resolve, but still, they make a pull a little
more complicated than it should be.
What would you guys, as experienced Git users, recommend in this case?
Scrapping a NEWS file and simply drawing up the release-notes shortly
before release (as the Git project does)? Aggregating the Git commit
messages into one monster release log? Having the release manager add
the NEWS entries himself, and mandate that no patch have it in them?
Thanks!
^ permalink raw reply
* [PATCH 1/5] builtin-commit.c: Use 'git_config_string' to get 'commit.template'
From: Brian Hetro @ 2008-07-05 5:24 UTC (permalink / raw)
To: git; +Cc: gitster, Brian Hetro
In-Reply-To: <cover.1215234749.git.whee@smaertness.net>
Signed-off-by: Brian Hetro <whee@smaertness.net>
---
builtin-commit.c | 11 ++++-------
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index e3ad38b..745c11e 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -45,7 +45,8 @@ static enum {
COMMIT_PARTIAL,
} commit_style;
-static char *logfile, *force_author, *template_file;
+static char *logfile, *force_author;
+static const char *template_file;
static char *edit_message, *use_message;
static char *author_name, *author_email, *author_date;
static int all, edit_flag, also, interactive, only, amend, signoff;
@@ -877,12 +878,8 @@ static void print_summary(const char *prefix, const unsigned char *sha1)
int git_commit_config(const char *k, const char *v, void *cb)
{
- if (!strcmp(k, "commit.template")) {
- if (!v)
- return config_error_nonbool(v);
- template_file = xstrdup(v);
- return 0;
- }
+ if (!strcmp(k, "commit.template"))
+ return git_config_string(&template_file, k, v);
return git_status_config(k, v, cb);
}
--
1.5.6.1.204.g699135
^ permalink raw reply related
* [PATCH 5/5] http.c: Use 'git_config_string' to clean up SSL config.
From: Brian Hetro @ 2008-07-05 5:24 UTC (permalink / raw)
To: git; +Cc: gitster, Brian Hetro
In-Reply-To: <cover.1215234749.git.whee@smaertness.net>
Signed-off-by: Brian Hetro <whee@smaertness.net>
---
http.c | 36 ++++++++++++------------------------
1 files changed, 12 insertions(+), 24 deletions(-)
diff --git a/http.c b/http.c
index 105dc93..c22adcc 100644
--- a/http.c
+++ b/http.c
@@ -13,14 +13,14 @@ static CURL *curl_default;
char curl_errorstr[CURL_ERROR_SIZE];
static int curl_ssl_verify = -1;
-static char *ssl_cert = NULL;
+static const char *ssl_cert = NULL;
#if LIBCURL_VERSION_NUM >= 0x070902
-static char *ssl_key = NULL;
+static const char *ssl_key = NULL;
#endif
#if LIBCURL_VERSION_NUM >= 0x070908
-static char *ssl_capath = NULL;
+static const char *ssl_capath = NULL;
#endif
-static char *ssl_cainfo = NULL;
+static const char *ssl_cainfo = NULL;
static long curl_low_speed_limit = -1;
static long curl_low_speed_time = -1;
static int curl_ftp_no_epsv = 0;
@@ -100,39 +100,27 @@ static int http_options(const char *var, const char *value, void *cb)
}
if (!strcmp("http.sslcert", var)) {
- if (ssl_cert == NULL) {
- if (!value)
- return config_error_nonbool(var);
- ssl_cert = xstrdup(value);
- }
+ if (ssl_cert == NULL)
+ return git_config_string(&ssl_cert, var, value);
return 0;
}
#if LIBCURL_VERSION_NUM >= 0x070902
if (!strcmp("http.sslkey", var)) {
- if (ssl_key == NULL) {
- if (!value)
- return config_error_nonbool(var);
- ssl_key = xstrdup(value);
- }
+ if (ssl_key == NULL)
+ return git_config_string(&ssl_key, var, value);
return 0;
}
#endif
#if LIBCURL_VERSION_NUM >= 0x070908
if (!strcmp("http.sslcapath", var)) {
- if (ssl_capath == NULL) {
- if (!value)
- return config_error_nonbool(var);
- ssl_capath = xstrdup(value);
- }
+ if (ssl_capath == NULL)
+ return git_config_string(&ssl_capath, var, value);
return 0;
}
#endif
if (!strcmp("http.sslcainfo", var)) {
- if (ssl_cainfo == NULL) {
- if (!value)
- return config_error_nonbool(var);
- ssl_cainfo = xstrdup(value);
- }
+ if (ssl_cainfo == NULL)
+ return git_config_string(&ssl_cainfo, var, value);
return 0;
}
--
1.5.6.1.204.g699135
^ permalink raw reply related
* [PATCH 4/5] diff.c: Use 'git_config_string' to get 'diff.external'
From: Brian Hetro @ 2008-07-05 5:24 UTC (permalink / raw)
To: git; +Cc: gitster, Brian Hetro
In-Reply-To: <cover.1215234749.git.whee@smaertness.net>
Signed-off-by: Brian Hetro <whee@smaertness.net>
---
diff.c | 8 ++------
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/diff.c b/diff.c
index 803fbba..6a39b39 100644
--- a/diff.c
+++ b/diff.c
@@ -153,12 +153,8 @@ int git_diff_ui_config(const char *var, const char *value, void *cb)
diff_auto_refresh_index = git_config_bool(var, value);
return 0;
}
- if (!strcmp(var, "diff.external")) {
- if (!value)
- return config_error_nonbool(var);
- external_diff_cmd_cfg = xstrdup(value);
- return 0;
- }
+ if (!strcmp(var, "diff.external"))
+ return git_config_string(&external_diff_cmd_cfg, var, value);
if (!prefixcmp(var, "diff.")) {
const char *ep = strrchr(var, '.');
--
1.5.6.1.204.g699135
^ permalink raw reply related
* [PATCH 3/5] convert.c: Use 'git_config_string' to get 'smudge' and 'clean'
From: Brian Hetro @ 2008-07-05 5:24 UTC (permalink / raw)
To: git; +Cc: gitster, Brian Hetro
In-Reply-To: <cover.1215234749.git.whee@smaertness.net>
Signed-off-by: Brian Hetro <whee@smaertness.net>
---
convert.c | 25 +++++++++----------------
1 files changed, 9 insertions(+), 16 deletions(-)
diff --git a/convert.c b/convert.c
index 1c66844..352b69d 100644
--- a/convert.c
+++ b/convert.c
@@ -319,8 +319,8 @@ static int apply_filter(const char *path, const char *src, size_t len,
static struct convert_driver {
const char *name;
struct convert_driver *next;
- char *smudge;
- char *clean;
+ const char *smudge;
+ const char *clean;
} *user_convert, **user_convert_tail;
static int read_convert_config(const char *var, const char *value, void *cb)
@@ -358,19 +358,12 @@ static int read_convert_config(const char *var, const char *value, void *cb)
* The command-line will not be interpolated in any way.
*/
- if (!strcmp("smudge", ep)) {
- if (!value)
- return config_error_nonbool(var);
- drv->smudge = strdup(value);
- return 0;
- }
+ if (!strcmp("smudge", ep))
+ return git_config_string(&drv->smudge, var, value);
+
+ if (!strcmp("clean", ep))
+ return git_config_string(&drv->clean, var, value);
- if (!strcmp("clean", ep)) {
- if (!value)
- return config_error_nonbool(var);
- drv->clean = strdup(value);
- return 0;
- }
return 0;
}
@@ -576,7 +569,7 @@ int convert_to_git(const char *path, const char *src, size_t len,
struct git_attr_check check[3];
int crlf = CRLF_GUESS;
int ident = 0, ret = 0;
- char *filter = NULL;
+ const char *filter = NULL;
setup_convert_check(check);
if (!git_checkattr(path, ARRAY_SIZE(check), check)) {
@@ -606,7 +599,7 @@ int convert_to_working_tree(const char *path, const char *src, size_t len, struc
struct git_attr_check check[3];
int crlf = CRLF_GUESS;
int ident = 0, ret = 0;
- char *filter = NULL;
+ const char *filter = NULL;
setup_convert_check(check);
if (!git_checkattr(path, ARRAY_SIZE(check), check)) {
--
1.5.6.1.204.g699135
^ permalink raw reply related
* [PATCH 2/5] builtin-log.c: Use 'git_config_string' to get 'format.subjectprefix' and 'format.suffix'
From: Brian Hetro @ 2008-07-05 5:24 UTC (permalink / raw)
To: git; +Cc: gitster, Brian Hetro
In-Reply-To: <cover.1215234749.git.whee@smaertness.net>
Signed-off-by: Brian Hetro <whee@smaertness.net>
---
builtin-log.c | 16 ++++------------
1 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 9979e37..430d876 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -234,12 +234,8 @@ static int git_log_config(const char *var, const char *value, void *cb)
{
if (!strcmp(var, "format.pretty"))
return git_config_string(&fmt_pretty, var, value);
- if (!strcmp(var, "format.subjectprefix")) {
- if (!value)
- config_error_nonbool(var);
- fmt_patch_subject_prefix = xstrdup(value);
- return 0;
- }
+ if (!strcmp(var, "format.subjectprefix"))
+ return git_config_string(&fmt_patch_subject_prefix, var, value);
if (!strcmp(var, "log.date"))
return git_config_string(&default_date_mode, var, value);
if (!strcmp(var, "log.showroot")) {
@@ -489,12 +485,8 @@ static int git_format_config(const char *var, const char *value, void *cb)
add_header(value);
return 0;
}
- if (!strcmp(var, "format.suffix")) {
- if (!value)
- return config_error_nonbool(var);
- fmt_patch_suffix = xstrdup(value);
- return 0;
- }
+ if (!strcmp(var, "format.suffix"))
+ return git_config_string(&fmt_patch_suffix, var, value);
if (!strcmp(var, "format.cc")) {
if (!value)
return config_error_nonbool(var);
--
1.5.6.1.204.g699135
^ permalink raw reply related
* [PATCH 0/5] git_config_string janitorial conversions.
From: Brian Hetro @ 2008-07-05 5:24 UTC (permalink / raw)
To: git; +Cc: gitster, Brian Hetro
These patches are related to the git_config_string "janitorial" work.
There may be more cleanup possible, but these are the straightforward
changes.
Brian Hetro (5):
builtin-commit.c: Use 'git_config_string' to get 'commit.template'
builtin-log.c: Use 'git_config_string' to get 'format.subjectprefix'
and 'format.suffix'
convert.c: Use 'git_config_string' to get 'smudge' and 'clean'
diff.c: Use 'git_config_string' to get 'diff.external'
http.c: Use 'git_config_string' to clean up SSL config.
builtin-commit.c | 11 ++++-------
builtin-log.c | 16 ++++------------
convert.c | 25 +++++++++----------------
diff.c | 8 ++------
http.c | 36 ++++++++++++------------------------
5 files changed, 31 insertions(+), 65 deletions(-)
^ permalink raw reply
* [PATCH v2] Documentation cvs: Clarify when a bare repository is needed
From: Matthew Ogilvie @ 2008-07-05 4:43 UTC (permalink / raw)
To: git; +Cc: gitster, Matthew Ogilvie
In-Reply-To: <1214023712-12361-1-git-send-email-mmogilvi_git@miniinfo.net>
New users sometimes import a project and then immediately
try to use the imported repository as a central shared repository.
This provides pointers about setting up a bare repository for that
in the parts of the documentation dealing with CVS migration.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
I sent an earlier version of this patch about two weeks ago, but never
got any feedback about it. This version rewords a couple of things
and expands the commit message a little. I'll probably abandon it
after this.
This was inspired because occasionally someone asks the mailing list
about the "Index already exists in git repo" error message
from git-cvsserver, and I noticed that two relevant and common
starting points in the documentation (git-cvsserver and
get-cvsimport) do not mention that a shared repository should be bare.
Maybe someone should write up something similar for things like
git-push, git-svn, various other import scripts, etc. I don't really
know enough about any of them and how they interact with non-bare
repositories to write reliable documentation.
Mostly unrelated: While in gitcvs-migration, I also noticed that
it doesn't mention git-cvsexportcommit at all, but I'm
not sure if it should just have a link in the "SEE ALSO"
section, a sentence or two near where it talks about
incremental imports (since if you need incrementatl import, you
likely also need incremental export), or a whole new section.
Since I've never used cvsexportcommit at all, I'm not real
confident on what to say about how to use it with incremental import.
- Matthew Ogilvie
Documentation/git-cvsimport.txt | 6 ++++++
Documentation/git-cvsserver.txt | 3 +++
Documentation/gitcvs-migration.txt | 5 +++++
3 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
index ed79bb8..aec1bca 100644
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@@ -31,6 +31,12 @@ to work with; after that, you need to `git-merge` incremental imports, or
any CVS branches, yourself. It is advisable to specify a named remote via
-r to separate and protect the incoming branches.
+If you intend to set up a shared public repository that all developers can
+read/write, or if you want to use linkgit:git-cvsserver[1], then you
+probably want to make a bare clone of the imported repository,
+and use the clone as the shared repository.
+See linkgit:gitcvs-migration[7].
+
OPTIONS
-------
diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
index e0e35db..71433d7 100644
--- a/Documentation/git-cvsserver.txt
+++ b/Documentation/git-cvsserver.txt
@@ -133,6 +133,9 @@ write access to the log file and to the database (see
<<dbbackend,Database Backend>>. If you want to offer write access over
SSH, the users of course also need write access to the git repository itself.
+You also need to ensure that each repository is "bare" (without a git index
+file) for `cvs commit` to work. See linkgit:gitcvs-migration[7].
+
[[configaccessmethod]]
All configuration variables can also be overridden for a specific method of
access. Valid method names are "ext" (for SSH access) and "pserver". The
diff --git a/Documentation/gitcvs-migration.txt b/Documentation/gitcvs-migration.txt
index 4dc7ec5..af453f2 100644
--- a/Documentation/gitcvs-migration.txt
+++ b/Documentation/gitcvs-migration.txt
@@ -143,6 +143,11 @@ work, you must not modify the imported branches; instead, create new
branches for your own changes, and merge in the imported branches as
necessary.
+If you want a shared repository, you will need to make a bare clone
+of the imported directory, as described above. Then treat the imported
+directory as another development clone for purposes of merging
+incremental imports.
+
Advanced Shared Repository Management
-------------------------------------
--
1.5.6.1.204.g699135
^ permalink raw reply related
* Re: [PATCH] Fix t7601-merge-pull-config.sh on AIX
From: Junio C Hamano @ 2008-07-05 1:49 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Johannes Schindelin, Olivier Marin, git, Mike Ralphson
In-Reply-To: <1215217920-8506-1-git-send-email-vmiklos@frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> diff --git a/t/t7601-merge-pull-config.sh b/t/t7601-merge-pull-config.sh
> index 32585f8..12f71ad 100755
> --- a/t/t7601-merge-pull-config.sh
> +++ b/t/t7601-merge-pull-config.sh
> @@ -70,10 +70,10 @@ test_expect_success 'merge c1 with c2 and c3 (recursive and octopus in pull.octo
>
> conflict_count()
> {
> - eval $1=`{
> + eval $1=$({
> git diff-files --name-only
> git ls-files --unmerged
> - } | wc -l`
> + } | wc -l | tr -d \ )
> }
In any case, this feels like an unnecessary use of eval. The call site
you have look like this:
conflict_count resolve_count
but it is more natural if you are programming in shell to call it like:
resolve_count=$(count_conflicts)
and it is more natural to write count_conflicts like this:
count_conflicts () {
{
git diff-files --name-only --diff-filter=U
git ls-files --unmerged
} | wc -l
}
But I am puzzled about the alledged *breakage* -- look at your call
sites.
reset --hard
.. do a merge ..
conflict_count count_one
reset --hard
.. do another merge ..
conlict_count count_two
reset --hard
.. do yet another merge ..
conlict_count count_three
test "$count_three" = "$count_two"
At any point, you do not do numerical comparison, and I do not think extra
whitespace from other "wc" implementations matter, as long as they are
consistent.
If you are going to do numerical comparison in later versions, you can
just drop the dq around parameters of test:
test $count_three = $count_two
^ permalink raw reply
* [PATCH] Fix t7601-merge-pull-config.sh on AIX
From: Miklos Vajna @ 2008-07-05 0:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Olivier Marin, git, Mike Ralphson
In-Reply-To: <20080705002634.GF4729@genesis.frugalware.org>
The test failed on AIX (and likely other OS, such as apparently OSX)
where wc -l outputs whitespace.
Signed-off-by: Mike Ralphson <mike@abacus.co.uk>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Here is the same, with backticks avoided, and with a proper commit
message.
t/t7601-merge-pull-config.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t7601-merge-pull-config.sh b/t/t7601-merge-pull-config.sh
index 32585f8..12f71ad 100755
--- a/t/t7601-merge-pull-config.sh
+++ b/t/t7601-merge-pull-config.sh
@@ -70,10 +70,10 @@ test_expect_success 'merge c1 with c2 and c3 (recursive and octopus in pull.octo
conflict_count()
{
- eval $1=`{
+ eval $1=$({
git diff-files --name-only
git ls-files --unmerged
- } | wc -l`
+ } | wc -l | tr -d \ )
}
# c4 - c5
--
1.5.6.1
^ permalink raw reply related
* Re: [PATCH 04/15] Add new test to ensure git-merge handles pull.twohead and pull.octopus
From: Miklos Vajna @ 2008-07-05 0:26 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Junio C Hamano, git, Johannes Schindelin, Olivier Marin
In-Reply-To: <e2b179460807040934m27e752e7s4f6a786d45d3bc53@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1204 bytes --]
On Fri, Jul 04, 2008 at 05:34:05PM +0100, Mike Ralphson <mike.ralphson@gmail.com> wrote:
> > +conflict_count()
> > +{
> > + eval $1=`{
> > + git diff-files --name-only
> > + git ls-files --unmerged
> > + } | wc -l`
> > +}
> > +
>
> This here causes the test to fail on AIX (and likely other OS, such as
> apparently OSX) where wc -l outputs whitespace. See
> http://article.gmane.org/gmane.comp.version-control.git/80450
>
> Here we want the line count not just a return value, so is the
> following acceptable?
>
> diff --git a/t/t7601-merge-pull-config.sh b/t/t7601-merge-pull-config.sh
> index 32585f8..9b6097d 100755
> --- a/t/t7601-merge-pull-config.sh
> +++ b/t/t7601-merge-pull-config.sh
> @@ -73,7 +73,7 @@ conflict_count()
> eval $1=`{
> git diff-files --name-only
> git ls-files --unmerged
> - } | wc -l`
> + } | wc -l | tr -d \ `
> }
At least it does not break the test for me on Linux. But haven't this
cause you problems in git-merge.sh? I copied this code chunk from
there.
> Anyway, I thought we preferred $() to backticks?
See above, but sure, we can.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: can I configure git clone to preserve the '.git' when it makes the initial dir
From: Stephan Beyer @ 2008-07-04 23:22 UTC (permalink / raw)
To: Stephen Bannasch; +Cc: git
In-Reply-To: <p06240819c49453b4beda@[192.168.1.105]>
Hi,
Stephen Bannasch wrote:
> As I'm moving to more use of git I find it very helpful to keep the
> '.git' suffix on the names of directories in which I have git
> repositories. This makes it easier to distinguish between checkouts
> using different SCMs.
When you finally fall in love with git, you won't want to
use another SCM. :)
Even, if you have to, there is git-cvs{exportcommit,import}, git-svn,
and some other more or less working interfaces from git to other SCMs.
Perhaps it's also worth having a look at http://kitenet.net/~joey/code/mr/
(I've never used it, but heard of people who like using it.)
> Is there a way to configure git clone to preserve the '.git' suffix when
> creating a directory?
I don't know a configuration for that, but you can simply do:
git clone <repository> <reponame>.git
(e.g. git clone git://example.com/foo.git foo.git)
But, btw, I think some unofficial convention is, that the ".git" suffix
indicates a bare repository and without that suffix it is a checked out
working tree.
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* can I configure git clone to preserve the '.git' when it makes the initial dir
From: Stephen Bannasch @ 2008-07-04 22:28 UTC (permalink / raw)
To: git
As I'm moving to more use of git I find it very helpful to keep the
'.git' suffix on the names of directories in which I have git
repositories. This makes it easier to distinguish between checkouts
using different SCMs.
Is there a way to configure git clone to preserve the '.git' suffix
when creating a directory?
Thanks for any ideas.
--
- Stephen Bannasch
Concord Consortium, http://www.concord.org
^ permalink raw reply
* Re: git sequencer prototype
From: Stephan Beyer @ 2008-07-04 22:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git, Johannes Schindelin
In-Reply-To: <7vwsk1ti6y.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
> > BTW, how about renaming it in something short: git seq. There is
> > already a seq(1) in GNU coreutils, which does roughly the same (prints
> > a sequence of numbers), why not reuse the name?
>
> Is it advantageous to use shorter but less descriptive name for this
> command?
I also think descriptive names are nice for git even if the user should
type that, since tab completion exists.
When I've started with git, I loved the fact that I could use tab
completion to learn new git commands and that often the name was
descriptive enough to get an imagination of what the tool could do (and
then read the manpage to verify...)
> It will be a backend to am/rebase and not something the users
> will type from the command line, won't it?
Usually, but for special cases it is also nicely usable by the user
and the --status and --edit subcommands are intended to be used by the
user, too.
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: git sequencer prototype
From: Junio C Hamano @ 2008-07-04 22:09 UTC (permalink / raw)
To: Alex Riesen; +Cc: Stephan Beyer, git, Johannes Schindelin
In-Reply-To: <20080704210052.GA6984@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Stephan Beyer, Tue, Jul 01, 2008 04:38:30 +0200:
>> Hi,
>>
>> here is the patchset for the git-sequencer prototype, documentation,
>> test suite and a first git-am and git-rebase-i migration.
>> Indeed, monster patches. ;)
>
> BTW, how about renaming it in something short: git seq. There is
> already a seq(1) in GNU coreutils, which does roughly the same (prints
> a sequence of numbers), why not reuse the name?
Is it advantageous to use shorter but less descriptive name for this
command? It will be a backend to am/rebase and not something the users
will type from the command line, won't it?
^ permalink raw reply
* Re: Can I remove stg sync --undo ?
From: Catalin Marinas @ 2008-07-04 22:05 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20080704020918.GA30669@diana.vm.bytemark.co.uk>
2008/7/4 Karl Hasselström <kha@treskal.com>:
> On 2008-07-03 23:02:28 +0100, Catalin Marinas wrote:
>> The sync performs three operations - push, merge and refresh (if the
>> refresh is automatic after merge, it doesn't update the backup
>> information since it was done by merge).
>>
>> If merge fails, the refresh is manual after solving the conflicts. I
>> suspect this will be recorded as a separate step for undo
>
> Yeah, the new undo stuff will currently handle sync just like e.g.
> push and pop: write one log entry when the command's all done, plus
> one extra just before the conflicting push if there is one. So you can
> always undo the entire command; and in case of conflicts, you also
> have the option of undoing just the conflicting push. Is this enough
> for sync?
There are two operations that can conflict for sync - pushing a patch
and the actual sync'ing, i.e. a three-way merge with the patch to be
synchronised with (kind of fold).
>> (BTW, is resolved take into account for undo?).
>
> Hmmm, what do you mean by "resolved"?
The current resolved command - the clearing of the conflicting entries
in the index.
--
Catalin
^ permalink raw reply
* Re: git sequencer prototype
From: Alex Riesen @ 2008-07-04 21:00 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git, Junio C Hamano, Johannes Schindelin
In-Reply-To: <1214879914-17866-1-git-send-email-s-beyer@gmx.net>
Stephan Beyer, Tue, Jul 01, 2008 04:38:30 +0200:
> Hi,
>
> here is the patchset for the git-sequencer prototype, documentation,
> test suite and a first git-am and git-rebase-i migration.
> Indeed, monster patches. ;)
BTW, how about renaming it in something short: git seq. There is
already a seq(1) in GNU coreutils, which does roughly the same (prints
a sequence of numbers), why not reuse the name?
^ permalink raw reply
* Re: [PATCH/v2] git-basis, a script to manage bases for git-bundle
From: Jakub Narebski @ 2008-07-04 20:55 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Johannes Schindelin, Adam Brewster, git, Junio C Hamano
In-Reply-To: <486E540D.8000008@gmail.com>
Mark Levedahl wrote:
> We should have "git push bundle-nick" create the new bundle, updating
> the basis refs kept somewhere in refs/* (possibly refs/remotes, possibly
> refs/bundles?).
I think that because "git push directory" (local push) with error in
directory name, which otherwise would result in error, can be mistaken
for "git push bundle", that we would want to either use pseudo-protocol
("git push bundle://path/to/bundle") or some extension...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [msysGit] Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)
From: Edward Z. Yang @ 2008-07-04 20:11 UTC (permalink / raw)
To: piyo; +Cc: prohaska, Junio C Hamano, johannes.sixt, msysGit, git
In-Reply-To: <1f748ec60807040909r4022d714s4487f5991f6020dc@mail.gmail.com>
Clifford Caoile wrote:
> Perhaps I have traded one problem for another, because the msysgit
> user still has to be aware of MSYSGIT_REAL_PLINK (at least she doesn't
> have to set it up). And of course, the installer has to be modified to
> accommodate plinkssh and my proposal.
This feels unnecessarily complicated.
What would be cool is if we could just set GIT_SSH to plinkssh
-path-to-plink "C:\Path\To\plink.exe" (obviously a shorter flag or
something). Unfortunately, this doesn't seem to work with Git's current
command argument handling.
^ permalink raw reply
* Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)
From: Edward Z. Yang @ 2008-07-04 20:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: msysGit, git, gitster, junio
In-Reply-To: <alpine.DEB.1.00.0807031313140.9925@racer>
> Sorry, that argument does not fly. "My patch is better, because I did not
> test your patch."
Just tested, the patch works.
> That is so totally untrue. We have Perl scripts and Shell scripts (for
> which we need the bash), and then we have the two GUIs which use Tcl/Tk.
I came up with that conclusion by grepping the Git source code for the
word bash; no results. Granted, it's still a null point because the
proposed script doesn't use any bash-specific features.
> Further, would you like to convert and maintain all people's wrapper
> scripts to C code inside Git?
I was under the impression that wrapper scripts were for fleshing out
new APIs and implementing non-performance critical functionality,
without all the overhead of writing in C. There is little to no overhead
from this patch.
Anyway, Johannes still makes some pretty compelling points for the
wrapper script, so you can count me +1 for the wrapper.
> BTW what is the reason why Hannes' mail does not appear to be the mail
> you replied to in GMane, but the patch Steffen sent?
I actually did a "Reply" and so he was the only one who got the email at
first. Then I resent it to the list, as well as the other CC'ed people.
(Thus my comment at the bottom)
^ permalink raw reply
* Re: [PATCH/v2] git-basis, a script to manage bases for git-bundle
From: Jeff King @ 2008-07-04 19:51 UTC (permalink / raw)
To: Adam Brewster; +Cc: git, Mark Levedahl, Junio C Hamano, Jakub Narebski
In-Reply-To: <c376da900807031638l219229bcy983ed994b37512c9@mail.gmail.com>
On Thu, Jul 03, 2008 at 07:38:21PM -0400, Adam Brewster wrote:
> There's still plenty of potential for improvements, like a --gc mode
> to clean up basis files, a --rewind option to undo an incorrect
> --update, or improvements in the way it calculates intersections, but
> I think that with these changes the system is as simple as possible
> while maximizing flexibility, utility, and usability.
I was thinking about Mark's approach, and I think there are two distinct
differences from yours:
1. he updates the basis upon bundle creation, rather than as a
separate step (and I have already commented on this)
2. he stores the basis in the refs hierarchy
I actually think '2' makes a lot of sense. Storing the basis as refs
gets you:
- an easy implementation; you use existing git tools
- correct reachability analysis, since the refs will be taken into
account by git-fsck, meaning you won't ever accidentally prune
your basis objects
- free logging of your basis history, in the form of reflogs
- free gc in the usual reflog way
IIRC, Mark suggested putting them under refs/remotes/<bundle>, and you
objected that you didn't want to clutter that hierarchy. If that is a
problem, you can always use refs/basis/<bundle>, which will be ignored
by gitk and "git branch -a", but will be correctly handled by other
tools.
And then suddenly your perl script gets a lot simpler, and is either a
short shell script, or even better, can be written in C as part of
git-bundle. So you would have something like "git bundle --update-basis
<basis>" instead of "git-basis", and a config option like
"bundle.autoUpdateBasis" to update the basis whenever you create a
bundle.
-Peff
^ 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