* [PATCH 0/5] hg-to-git fixes
From: Miklos Vajna @ 2008-07-06 3:15 UTC (permalink / raw)
To: Stelian Pop; +Cc: Junio C Hamano, git
Hi,
I just noticed that hg-to-git was not updated to use dash-less git
commands, which now causes problems on 'next'. If I was at it, I fixed a
few minor issues I noticed as well.
Miklos Vajna (5):
hg-to-git: avoid raising a string exception
hg-to-git: abort if the project directory is not a hg repo
hg-to-git: rewrite "git-frotz" to "git frotz"
hg-to-git: use git init instead of git init-db
hg-to-git: use git rev-parse instead of git show
contrib/hg-to-git/hg-to-git.py | 27 +++++++++++++++------------
1 files changed, 15 insertions(+), 12 deletions(-)
^ permalink raw reply
* Re: [PATCH v5]
From: Adam Brewster @ 2008-07-06 2:49 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vskunpyqz.fsf@gitster.siamese.dyndns.org>
>
> Yeah, it is simply a bad taste to use helper in builtin-A from builtin-B.
> More library-ish files such as revision.c are better home for utility
> functions to be shared between builtins and commands.
>
> Here is what I queued.
>
Thank you.
> By the way did you compile test your fix before sending?
>
I ran make and test, but I didn't notice the warnings that prompted
the question. I also forgot to re-check it after re-working the
commits to put everything in order.
> -- >8 --
Thank you again for your help and patience in dealing with my multiple
failed attempts to get this right.
Adam
^ permalink raw reply
* Re: [PATCH v5]
From: Junio C Hamano @ 2008-07-06 1:50 UTC (permalink / raw)
To: Adam Brewster; +Cc: git, gitster, mdl123, Johannes.Schindelin, jnareb, vmiklos
In-Reply-To: <1215293200-28199-1-git-send-email-adambrewster@gmail.com>
Adam Brewster <adambrewster@gmail.com> writes:
> The real reason read_revisions_from_stdin moved to revision.c is because I was
> asked to do it that way.
Yeah, it is simply a bad taste to use helper in builtin-A from builtin-B.
More library-ish files such as revision.c are better home for utility
functions to be shared between builtins and commands.
Here is what I queued.
By the way did you compile test your fix before sending?
-- >8 --
Move read_revisions_from_stdin from builtin-rev-list.c to revision.c
Reading rev-list parameters from the command line can be reused by
commands other than rev-list. Move this function to more "library-ish"
place to promote code reuse.
Signed-off-by: Adam Brewster <asb@bu.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 83a7b13..54b6672 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -565,23 +565,6 @@ static struct commit_list *find_bisection(struct commit_list *list,
return best;
}
-static void read_revisions_from_stdin(struct rev_info *revs)
-{
- char line[1000];
-
- while (fgets(line, sizeof(line), stdin) != NULL) {
- int len = strlen(line);
- if (len && line[len - 1] == '\n')
- line[--len] = 0;
- if (!len)
- break;
- if (line[0] == '-')
- die("options not supported in --stdin mode");
- if (handle_revision_arg(line, revs, 0, 1))
- die("bad revision '%s'", line);
- }
-}
-
int cmd_rev_list(int argc, const char **argv, const char *prefix)
{
struct commit_list *list;
diff --git a/revision.c b/revision.c
index fc66755..6ce6042 100644
--- a/revision.c
+++ b/revision.c
@@ -910,6 +910,23 @@ int handle_revision_arg(const char *arg, struct rev_info *revs,
return 0;
}
+void read_revisions_from_stdin(struct rev_info *revs)
+{
+ char line[1000];
+
+ while (fgets(line, sizeof(line), stdin) != NULL) {
+ int len = strlen(line);
+ if (len && line[len - 1] == '\n')
+ line[--len] = '\0';
+ if (!len)
+ break;
+ if (line[0] == '-')
+ die("options not supported in --stdin mode");
+ if (handle_revision_arg(line, revs, 0, 1))
+ die("bad revision '%s'", line);
+ }
+}
+
static void add_grep(struct rev_info *revs, const char *ptn, enum grep_pat_token what)
{
if (!revs->grep_filter) {
diff --git a/revision.h b/revision.h
index abce500..83f364a 100644
--- a/revision.h
+++ b/revision.h
@@ -111,6 +111,8 @@ struct rev_info {
#define REV_TREE_DIFFERENT 2
/* revision.c */
+void read_revisions_from_stdin(struct rev_info *revs);
+
typedef void (*show_early_output_fn_t)(struct rev_info *, struct commit_list *);
volatile show_early_output_fn_t show_early_output;
^ permalink raw reply related
* Re: About -X<option>
From: Johannes Schindelin @ 2008-07-06 1:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pieter de Bie, Miklos Vajna, git
In-Reply-To: <7v63rktekf.fsf@gitster.siamese.dyndns.org>
Hi,
On Sat, 5 Jul 2008, Junio C Hamano wrote:
> Also I do not see why -X<option> is not easy with parseopt() as Dscho
> claimed in the original message in this thread...
Isn't that obvious? -X looks like a short option, but the rest of that
string does not consist of aggregated short options.
Besides, it is extremely ugly a syntax. Just like git-log's -S thing.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git daemon: avoid calling syslog() from a signal handler
From: Johannes Schindelin @ 2008-07-06 1:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Foster, git
In-Reply-To: <7vabgwtf6m.fsf@gitster.siamese.dyndns.org>
Hi,
On Sat, 5 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> 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.
>
> Hmm.
>
> The question was not about the millisecond typo, but about why time-out
> at all.
Because I do not want to change the semantics!
ATM, in those cases where it works (as opposed to hanging!), git-daemon
--verbose reports in the syslog when a client disconnected, possibly with
an error. It does so with a timestamp so that you can see how long the
connection lasted. That is what logs are useful for.
Now, syslog has timestamps at second-resolution (at least here it does),
and I wanted to imitate that.
The alternative would be to deprive all users of an (mostly) accurate
timestamp of the disconnect time.
> Another way would be to set up a pipe to ourself that is included in the
> poll() and write a byte to the pipe from the signal handler.
It still would need to break out of the poll(), in which case the effect
would be _exactly_ the same, but with a lot of more trouble, and
opportunities for me to bring in new bugs, right?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Allow cherry-picking root commits
From: Johannes Schindelin @ 2008-07-06 1:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephan Beyer, git, Daniel Barkalow, Christian Couder
In-Reply-To: <7vzlovq0t6.fsf@gitster.siamese.dyndns.org>
Hi,
On Sat, 5 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > There is no good reason why cherry-picking root commits should not be
> > allowed.
>
> Hmm, does "cherry-pick a root commit" even have a well defined
> semantics, other than "if there is no overlap in files just add the
> files in"?
Yes. You can easily add the files identically, or some similar files, in
which case you get an easily-resolved conflict.
> I have a feeling that it is more likely to be a user error, a sign that
> the user mistyped the name of the commit to pick.
Now, now, that is too harsh a statement!
Often I start my work from a tarball, just because the git import takes so
long that I can fiddle with the thing already while the import runs.
And guess what, it would be easier to rebase that series onto an imported
tag for me. The first commit would not result in changes, since it would
import the identical tree. Or it would barf, in which case I would know
that I got the wrong branch point to rebase onto.
At the moment, I play games that need a deep knowledge of Git, which _I_
have, but not necessarily occasional Git users.
Ciao,
Dscho
^ permalink raw reply
* Re: git-clone --quiet broken?
From: Daniel Barkalow @ 2008-07-06 1:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dave Jones, git
In-Reply-To: <7vmykvrfta.fsf@gitster.siamese.dyndns.org>
On Sat, 5 Jul 2008, Junio C Hamano wrote:
> Dave Jones <davej@codemonkey.org.uk> writes:
>
> > The server I run various git snapshots on recently got upgraded to git 1.5.6,
> > ...
> > I could run the clone with 2>/dev/null, but I'd really like to get
> > mail when something breaks instead of it being totally silent.
> >
> > I'm assuming this was an unintentional side-effect of some other recent change?
>
> Yeah, I would assume so, too ;-)
>
> Daniel, is this enough? From re-reading the scripted version of
> git-clone, it appears that we *might* need to squelch no-progress if the
> stdout is not tty; I do not offhand if you got that right when you
> rewrote this in C.
This is probably enough for what people actually care about (when stdout
isn't a tty and isn't /dev/null, people are likely to ask for "quiet"
anyway, because this command's output isn't interesting after the fact).
But no-progress is probably a good idea anyway.
Oh, and you're fixing the corresponding regressions in fetch, which nobody
seems to have mentioned previously.
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
> transport.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/transport.c b/transport.c
> index 3ff8519..b2f0d8a 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -645,7 +645,8 @@ static int fetch_refs_via_pack(struct transport *transport,
> args.lock_pack = 1;
> args.use_thin_pack = data->thin;
> args.include_tag = data->followtags;
> - args.verbose = transport->verbose > 0;
> + args.verbose = (transport->verbose > 0);
> + args.quiet = (transport->verbose < 0);
And:
+ args.no_progress = !isatty(1);
> args.depth = data->depth;
>
> for (i = 0; i < nr_heads; i++)
^ permalink raw reply
* Re: [PATCH] Allow cherry-picking root commits
From: Junio C Hamano @ 2008-07-06 1:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Stephan Beyer, git, Daniel Barkalow, Christian Couder
In-Reply-To: <alpine.DEB.1.00.0807041617320.9925@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> There is no good reason why cherry-picking root commits should not be
> allowed.
Hmm, does "cherry-pick a root commit" even have a well defined semantics,
other than "if there is no overlap in files just add the files in"? I
have a feeling that it is more likely to be a user error, a sign that the
user mistyped the name of the commit to pick.
^ permalink raw reply
* Re: Teach git-bundle to read revision arguments from stdin like git-rev-list
From: Junio C Hamano @ 2008-07-06 0:57 UTC (permalink / raw)
To: Adam Brewster; +Cc: git, gitster, mdl123, Johannes.Schindelin, jnareb, vmiklos
In-Reply-To: <1215293200-28199-3-git-send-email-adambrewster@gmail.com>
Adam Brewster <adambrewster@gmail.com> writes:
> @@ -227,8 +228,16 @@ int create_bundle(struct bundle_header *header, const char *path,
>
> /* write references */
> argc = setup_revisions(argc, argv, &revs, NULL);
> - if (argc > 1)
> - return error("unrecognized argument: %s'", argv[1]);
> +
> + for (i = 1; i < argc; i++) {
> + if (!strcmp(argv[i], "--stdin")) {
> + if (read_from_stdin++)
> + die("--stdin given twice?");
Hmm, do we deeply care about this case? What bad things coulc happen if
you call read_revisions_from_stdin() twice?
> + read_revisions_from_stdin(&revs);
> + continue;
> + }
> + return error("unrecognized argument: %s'", argv[i]);
> + }
>
> for (i = 0; i < revs.pending.nr; i++) {
> struct object_array_entry *e = revs.pending.objects + i;
^ permalink raw reply
* Re: [PATCH] Move read_revisions_from_stdin from builtin-rev-list.c to revision.c
From: Junio C Hamano @ 2008-07-06 0:57 UTC (permalink / raw)
To: Miklos Vajna
Cc: Adam Brewster, git, gitster, mdl123, Johannes.Schindelin, jnareb,
Adam Brewster
In-Reply-To: <20080705204849.GJ4729@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> I think it's fine to move such a function, but this is a false commit
> message, you can use read_revisions_from_stdin() from builtin-bundle if
> it lives in builtin-rev-list.c as well.
At the mechanical level, yes you _can_, but it is simply a bad taste to do
so. More library-ish files such as revision.c are better home for utility
functions to be shared between builtins and commands.
^ permalink raw reply
* Re: [PATCH/RFC] Fix some warnings (on cygwin) to allow -Werror
From: Junio C Hamano @ 2008-07-06 0:57 UTC (permalink / raw)
To: Ramsay Jones; +Cc: GIT Mailing-list
In-Reply-To: <486FDB2F.3050800@ramsay1.demon.co.uk>
Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
> Junio C Hamano wrote:
> ...
>>> @@ -1718,7 +1720,8 @@ static int add_ref_tag(const char *path, const unsigned char *sha1, int flag, vo
>>> static void prepare_pack(int window, int depth)
>>> {
>>> struct object_entry **delta_list;
>>> - uint32_t i, n, nr_deltas;
>>> + uint32_t i, nr_deltas;
>>> + unsigned n;
>>
>> Hmm. Is this change necessary?
>
> Yes, otherwise:
>
> builtin-pack-objects.c: In function `prepare_pack':
> builtin-pack-objects.c:1760: warning: passing arg 2 of `find_deltas' from incompatible pointer type
> make: *** [builtin-pack-objects.o] Error 1
>
> Note that ll_find_deltas() is #defined to find_deltas() in the #else arm
> of #ifdef THREADED_DELTA_SEARCH, and find_deltas() takes an "unsigned *"
Ah, I missed that. So it is not just warning squelch but is a bugfix in
case unsigned and uint32_t are of different sizes.
^ permalink raw reply
* Re: git-clone --quiet broken?
From: Junio C Hamano @ 2008-07-06 0:56 UTC (permalink / raw)
To: Dave Jones; +Cc: git, Daniel Barkalow
In-Reply-To: <20080705211616.GA3874@codemonkey.org.uk>
Dave Jones <davej@codemonkey.org.uk> writes:
> The server I run various git snapshots on recently got upgraded to git 1.5.6,
> ...
> I could run the clone with 2>/dev/null, but I'd really like to get
> mail when something breaks instead of it being totally silent.
>
> I'm assuming this was an unintentional side-effect of some other recent change?
Yeah, I would assume so, too ;-)
Daniel, is this enough? From re-reading the scripted version of
git-clone, it appears that we *might* need to squelch no-progress if the
stdout is not tty; I do not offhand if you got that right when you
rewrote this in C.
transport.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/transport.c b/transport.c
index 3ff8519..b2f0d8a 100644
--- a/transport.c
+++ b/transport.c
@@ -645,7 +645,8 @@ static int fetch_refs_via_pack(struct transport *transport,
args.lock_pack = 1;
args.use_thin_pack = data->thin;
args.include_tag = data->followtags;
- args.verbose = transport->verbose > 0;
+ args.verbose = (transport->verbose > 0);
+ args.quiet = (transport->verbose < 0);
args.depth = data->depth;
for (i = 0; i < nr_heads; i++)
^ permalink raw reply related
* error: unlink(.git/refs/remotes/origin/testbranch) failed: was remote does not support deleting refs
From: Martin @ 2008-07-06 0:20 UTC (permalink / raw)
To: git
In-Reply-To: <486FE602.3060301@gmx.de>
Hi,
it seems that an old verison on the remote site was the problem:
On debian/etch git seems to be too old. I upgraded git to the testing
version and now I can delete remote branches.
But I get another error:
$ git push origin :testbranch
To ssh://myserver.com/my/path/to/repository
- [deleted] testbranch
error: unlink(.git/refs/remotes/origin/testbranch) failed: No such file
or directory
error: Failed to delete
Any idea?
Thanks,
Martin
Martin schrieb:
> Hi,
>
> I tried to setup a central git repository. Access is via ssh.
> How do I delete a remote branch? If I try it using
> > git branch -d -r origin/testbranch
> > git push origin :refs/heads/testbranch
> I get the error
>
> To ssh://myserver.com/my/path/to/repository
> ! [rejected] testbranch (remote does not support deleting refs)
> error: failed to push some refs to
> 'ssh://myserver.com/my/path/to/repository'
>
> So how do I setup my remote repository to allow deleting remote branches?
>
> Thanks,
> Martin
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH/RFC] Fix some warnings (on cygwin) to allow -Werror
From: Ramsay Jones @ 2008-07-05 20:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list
In-Reply-To: <7vskuquisp.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
>
>> Despite the subject line, this should be useful on any system for
>> which uint32_t is defined to be unsigned long rather than
>> unsigned int. (and where the return type of htonl() is similarly
>> defined).
>
> Correct. Perhaps "Use %PRIu32 and such to print integers of fixed length"?
>
> The only worry I have with this patch is with systems with not-so-ANSI
> headers; as you noticed, we already have:
>
> #ifndef PRIuMAX
> #define PRIuMAX "llu"
> #endif
>
> in git-compat-util.h, which does include <inttypes.h>, so PRIu32 and
> friends could be problematic on these platforms.
>
Yes, I had the same worry, since I did not know which system(s) required
the above #ifdef and, perhaps more important, why. Having said that, I
suspect (hope?) that the affected system(s) are somewhat rare. I guess
it would not be long before someone complained otherwise...
[Note: I can't just blame the above #ifdef because I don't have a real
git repo ;-) - it would simply blame me!]
>> @@ -1718,7 +1720,8 @@ static int add_ref_tag(const char *path, const unsigned char *sha1, int flag, vo
>> static void prepare_pack(int window, int depth)
>> {
>> struct object_entry **delta_list;
>> - uint32_t i, n, nr_deltas;
>> + uint32_t i, nr_deltas;
>> + unsigned n;
>
> Hmm. Is this change necessary?
>
Yes, otherwise:
builtin-pack-objects.c: In function `prepare_pack':
builtin-pack-objects.c:1760: warning: passing arg 2 of `find_deltas' from incompatible pointer type
make: *** [builtin-pack-objects.o] Error 1
Note that ll_find_deltas() is #defined to find_deltas() in the #else arm
of #ifdef THREADED_DELTA_SEARCH, and find_deltas() takes an "unsigned *"
ATB,
Ramsay Jones
^ permalink raw reply
* Re: [PATCH/RFC] Fix some warnings (on cygwin) to allow -Werror
From: Ramsay Jones @ 2008-07-05 20:56 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: GIT Mailing-list, Junio C Hamano
In-Reply-To: <E4D3A379-9EB2-49D1-AD42-CFFC453A2B08@zib.de>
Steffen Prohaska wrote:
> On Jul 3, 2008, at 5:52 PM, Ramsay Jones wrote:
>
>> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
>> ---
>>
>> Despite the subject line, this should be useful on any system for
>> which uint32_t is defined to be unsigned long rather than
>> unsigned int. (and where the return type of htonl() is similarly
>> defined).
>
> For MINGW, we fixed these warnings in the compat layer, see cd800eecc2:
>
> diff --git a/compat/mingw.h b/compat/mingw.h
> index a87cc96..6bc049a 100644
> --- a/compat/mingw.h
> +++ b/compat/mingw.h
> @@ -186,6 +186,10 @@ pid_t mingw_spawnvpe(const char *cmd, const char
> **argv, char **env);
> void mingw_execvp(const char *cmd, char *const *argv);
> #define execvp mingw_execvp
>
> +static inline unsigned int git_ntohl(unsigned int x)
> +{ return (unsigned int)ntohl(x); }
> +#define ntohl git_ntohl
> +
> sig_handler_t mingw_signal(int sig, sig_handler_t handler);
> #define signal mingw_signal
>
Yes, I had something similar at one point (but not in compat).
However, not all of these warnings are solved by the above.
For example, the changes to builtin-fast-export.c, builtin-pack-objects.c,
and pack-check.c do not involve ntohl() at all. (some hunks in other
files do not involve ntohl() either).
When the PRIu32 macro idea was suggested (I think it was Simon 'corecode' Schubert
who first mentioned it), I thought it would look so ugly, no one would
agree to such a patch... Having implemented it, well I guess it's not
quite as bad as I feared ;-) YMMV!
ATB,
Ramsay Jones
^ permalink raw reply
* Re: "make test" works again (sort-of) on cygwin.
From: Ramsay Jones @ 2008-07-05 20:09 UTC (permalink / raw)
To: Alex Riesen; +Cc: GIT Mailing-list, Junio C Hamano
In-Reply-To: <20080703202637.GC3546@steel.home>
Alex Riesen wrote:
> Ramsay Jones, Thu, Jul 03, 2008 19:44:28 +0200:
>
>> Anyhow, the "sort-of" in the subject line, relates to the fact that
>> I am seeing some test failures. In particular, all tests in
>> t0004-unwritable.sh and tests 21->24 in t3700-add.sh. All of these
>> tests involve chmod/permissions ...
>
> Don't run "make test" as root (or "backup operator" on windows).
> OTOH, a windows machine is almost useless, unless you're a member of
> local administrators group (which includes "backup" permission).
>
Ah, yes... I am a "Computer administator" aren't I ;-) I totally forgot!
Hmm, but is that really the reason for these failures? After all, (referring
to the example you snipped) the permissions are respected for creating
files in the directory, just not directories. Is the "root" user on
windows only selectively omnipotent?
ATB,
Ramsay Jones
^ permalink raw reply
* [PATCH] git-bundle: add --stdin
From: Adam Brewster @ 2008-07-05 21:26 UTC (permalink / raw)
To: git; +Cc: gitster, mdl123, Johannes.Schindelin, jnareb, adambrewster,
vmiklos
In-Reply-To: <1215293200-28199-2-git-send-email-adambrewster@gmail.com>
Teach git-bundle to read revision arguments from stdin like git-rev-list.
This patch allows the caller to feed the revision parameters to git-bundle
from its standard input. This way, a script do not have to worry about
limitation of the length of command line.
Documentation/git-bundle.txt says that git-bundle takes arguments acceptable
to git-rev-list. Obviously some arguments that git-rev-list handles don't
make sense for git-bundle (e.g. --bisect) but --stdin is pretty reasonable.
Signed-off-by: Adam Brewster <adambrewster@gmail.com>
---
bundle.c | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/bundle.c b/bundle.c
index 0ba5df1..00b2aab 100644
--- a/bundle.c
+++ b/bundle.c
@@ -178,6 +178,7 @@ int create_bundle(struct bundle_header *header, const char *path,
int i, ref_count = 0;
char buffer[1024];
struct rev_info revs;
+ int read_from_stdin = 0;
struct child_process rls;
FILE *rls_fout;
@@ -227,8 +228,16 @@ int create_bundle(struct bundle_header *header, const char *path,
/* write references */
argc = setup_revisions(argc, argv, &revs, NULL);
- if (argc > 1)
- return error("unrecognized argument: %s'", argv[1]);
+
+ for (i = 1; i < argc; i++) {
+ if (!strcmp(argv[i], "--stdin")) {
+ if (read_from_stdin++)
+ die("--stdin given twice?");
+ read_revisions_from_stdin(&revs);
+ continue;
+ }
+ return error("unrecognized argument: %s'", argv[i]);
+ }
for (i = 0; i < revs.pending.nr; i++) {
struct object_array_entry *e = revs.pending.objects + i;
--
1.5.5.1.211.g65ea3.dirty
^ permalink raw reply related
* [PATCH v5]
From: Adam Brewster @ 2008-07-05 21:26 UTC (permalink / raw)
To: git; +Cc: gitster, mdl123, Johannes.Schindelin, jnareb, adambrewster,
vmiklos
In-Reply-To: <20080705204849.GJ4729@genesis.frugalware.org>
Apparently I'm dumber than I thought. Here's what they look like without
random and unnecessary mode changes. The patch to add git-basis under contrib
is not affected.
The real reason read_revisions_from_stdin moved to revision.c is because I was
asked to do it that way. If my commit message doesn't accurately describe the
reason for the change, go ahead and edit the message, or let me know what the
real reason is so I can provide a better message.
Adam
^ permalink raw reply
* [PATCH] Move read_revisions_from_stdin from builtin-rev-list.c to revision.c
From: Adam Brewster @ 2008-07-05 21:26 UTC (permalink / raw)
To: git
Cc: gitster, mdl123, Johannes.Schindelin, jnareb, adambrewster,
vmiklos, Adam Brewster
In-Reply-To: <1215293200-28199-1-git-send-email-adambrewster@gmail.com>
Some other commands might like to support the --stdin option like
git-rev-list. Since they don't want to depend on builtin-rev-list, the
function has to be somewhere else.
Signed-off-by: Adam Brewster <asb@bu.edu>
---
builtin-rev-list.c | 17 -----------------
revision.c | 17 +++++++++++++++++
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 11a7eae..b4a2c44 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -575,23 +575,6 @@ static struct commit_list *find_bisection(struct commit_list *list,
return best;
}
-static void read_revisions_from_stdin(struct rev_info *revs)
-{
- char line[1000];
-
- while (fgets(line, sizeof(line), stdin) != NULL) {
- int len = strlen(line);
- if (len && line[len - 1] == '\n')
- line[--len] = 0;
- if (!len)
- break;
- if (line[0] == '-')
- die("options not supported in --stdin mode");
- if (handle_revision_arg(line, revs, 0, 1))
- die("bad revision '%s'", line);
- }
-}
-
int cmd_rev_list(int argc, const char **argv, const char *prefix)
{
struct commit_list *list;
diff --git a/revision.c b/revision.c
index 5a1a948..0191160 100644
--- a/revision.c
+++ b/revision.c
@@ -911,6 +911,23 @@ int handle_revision_arg(const char *arg, struct rev_info *revs,
return 0;
}
+void read_revisions_from_stdin(struct rev_info *revs)
+{
+ char line[1000];
+
+ while (fgets(line, sizeof(line), stdin) != NULL) {
+ int len = strlen(line);
+ if (len && line[len - 1] == '\n')
+ line[--len] = '\0';
+ if (!len)
+ break;
+ if (line[0] == '-')
+ die("options not supported in --stdin mode");
+ if (handle_revision_arg(line, revs, 0, 1))
+ die("bad revision '%s'", line);
+ }
+}
+
static void add_grep(struct rev_info *revs, const char *ptn, enum grep_pat_token what)
{
if (!revs->grep_filter) {
--
1.5.5.1.211.g65ea3.dirty
^ permalink raw reply related
* remote does not support deleting refs
From: Martin @ 2008-07-05 21:22 UTC (permalink / raw)
To: git
Hi,
I tried to setup a central git repository. Access is via ssh.
How do I delete a remote branch? If I try it using
> git branch -d -r origin/testbranch
> git push origin :refs/heads/testbranch
I get the error
To ssh://myserver.com/my/path/to/repository
! [rejected] testbranch (remote does not support deleting refs)
error: failed to push some refs to
'ssh://myserver.com/my/path/to/repository'
So how do I setup my remote repository to allow deleting remote branches?
Thanks,
Martin
^ permalink raw reply
* git-clone --quiet broken?
From: Dave Jones @ 2008-07-05 21:16 UTC (permalink / raw)
To: git
The server I run various git snapshots on recently got upgraded to git 1.5.6,
and I started getting a lot more mail from cron than usual.
It seems that passing -q to git-clone at some point changed from 'silent'
to 'slightly less noisy'. Only the difference is so slight that it may
as well be nil..
Here's a normal clone..
Initialize git/.git
Initialized empty Git repository in /home/davej/git-trees/git/.git/
remote: Counting objects: 76925, done.
remote: Compressing objects: 100% (25373/25373), done.
remote: Total 76925 (delta 55699), reused 70336 (delta 50160)
Receiving objects: 100% (76925/76925), 17.09 MiB | 1111 KiB/s, done.
Resolving deltas: 100% (55699/55699), done.
And here's the 'quiet' clone..
Initialize git/.git
remote: Counting objects: 76925, done.
remote: Compressing objects: 100% (25373/25373), done.
remote: Total 76925 (delta 55699), reused 70336 (delta 50160)
Receiving objects: 100% (76925/76925), 17.09 MiB | 1128 KiB/s, done.
Resolving deltas: 100% (55699/55699), done.
Spot the difference :)
It looks even worse in mail from cron, where you get one line of text
for every % that git progresses through.
I could run the clone with 2>/dev/null, but I'd really like to get
mail when something breaks instead of it being totally silent.
I'm assuming this was an unintentional side-effect of some other recent change?
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply
* [PATCH] Move 'stupid' merge strategy to contrib.
From: Miklos Vajna @ 2008-07-05 21:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git, Johannes Schindelin
In-Reply-To: <1215269031-19559-1-git-send-email-vmiklos@frugalware.org>
As pointed out by Linus, this strategy tries to take the best merge
base, but 'recursive' just does it better. If one needs something more
than 'resolve' then he/she should really use 'recursive' and not
'stupid'.
Given that it may still serve as a good example, don't remove it, just
move it to contrib/examples.
---
n Sat, Jul 05, 2008 at 04:43:51PM +0200, Miklos Vajna <vmiklos@frugalware.org> wrote:
> Here is one.
Oops, I forgot -M with format-patch.
.gitignore | 1 -
Makefile | 3 +--
.../examples/git-merge-stupid.sh | 0
3 files changed, 1 insertions(+), 3 deletions(-)
rename git-merge-stupid.sh => contrib/examples/git-merge-stupid.sh (100%)
diff --git a/.gitignore b/.gitignore
index 4ff2fec..8054d9d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -75,7 +75,6 @@ git-merge-one-file
git-merge-ours
git-merge-recursive
git-merge-resolve
-git-merge-stupid
git-merge-subtree
git-mergetool
git-mktag
diff --git a/Makefile b/Makefile
index 78e08d3..bddd1a7 100644
--- a/Makefile
+++ b/Makefile
@@ -241,7 +241,6 @@ SCRIPT_SH += git-merge-octopus.sh
SCRIPT_SH += git-merge-one-file.sh
SCRIPT_SH += git-merge-resolve.sh
SCRIPT_SH += git-merge.sh
-SCRIPT_SH += git-merge-stupid.sh
SCRIPT_SH += git-mergetool.sh
SCRIPT_SH += git-parse-remote.sh
SCRIPT_SH += git-pull.sh
@@ -1429,7 +1428,7 @@ check-docs::
do \
case "$$v" in \
git-merge-octopus | git-merge-ours | git-merge-recursive | \
- git-merge-resolve | git-merge-stupid | git-merge-subtree | \
+ git-merge-resolve | git-merge-subtree | \
git-fsck-objects | git-init-db | \
git-?*--?* ) continue ;; \
esac ; \
diff --git a/git-merge-stupid.sh b/contrib/examples/git-merge-stupid.sh
similarity index 100%
rename from git-merge-stupid.sh
rename to contrib/examples/git-merge-stupid.sh
--
1.5.6.1.322.ge904b.dirty
^ permalink raw reply related
* Re: [PATCH] Move read_revisions_from_stdin from builtin-rev-list.c to revision.c
From: Miklos Vajna @ 2008-07-05 20:48 UTC (permalink / raw)
To: Adam Brewster
Cc: git, gitster, mdl123, Johannes.Schindelin, jnareb, Adam Brewster
In-Reply-To: <1215290434-27694-2-git-send-email-adambrewster@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 554 bytes --]
On Sat, Jul 05, 2008 at 04:40:32PM -0400, Adam Brewster <adambrewster@gmail.com> wrote:
> Some other commands might like to support the --stdin option like
> git-rev-list. Since they don't want to depend on builtin-rev-list, the
> function has to be somewhere else.
I think it's fine to move such a function, but this is a false commit
message, you can use read_revisions_from_stdin() from builtin-bundle if
it lives in builtin-rev-list.c as well.
> mode change 100644 => 100755 builtin-rev-list.c
> mode change 100644 => 100755 revision.c
Hm? ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] Add git-basis.perl to contrib directory
From: Adam Brewster @ 2008-07-05 20:40 UTC (permalink / raw)
To: git
Cc: gitster, mdl123, Johannes.Schindelin, jnareb, adambrewster,
Adam Brewster
In-Reply-To: <1215290434-27694-3-git-send-email-adambrewster@gmail.com>
Git-basis is a perl script that remembers bases for use by git-bundle.
This script shouldn't be needed because git-push and git-remote should do this
kind of work. Unfortunately they currently don't so some might find this
script useful.
Signed-off-by: Adam Brewster <asb@bu.edu>
---
contrib/basis/git-basis.perl | 77 ++++++++++++++++++++++++++++++++++++
contrib/basis/git-basis.txt | 90 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 167 insertions(+), 0 deletions(-)
create mode 100755 contrib/basis/git-basis.perl
create mode 100644 contrib/basis/git-basis.txt
diff --git a/contrib/basis/git-basis.perl b/contrib/basis/git-basis.perl
new file mode 100755
index 0000000..b3e753f
--- /dev/null
+++ b/contrib/basis/git-basis.perl
@@ -0,0 +1,77 @@
+#!/usr/bin/perl
+
+use strict;
+
+use Git;
+
+require Time::Local;
+my $git_epoch = Time::Local::timegm(0, 0, 0, 1, 0, 70);
+
+my $r = Git->repository();
+my $d = $r->repo_path();
+
+if ( ! -d "$d/bases" ) {
+ mkdir("$d/bases") || die "Could not create $d/bases: $!";
+}
+
+if ( $#ARGV == -1 || ($#ARGV == 0 && $ARGV[0] eq '--update') ) {
+ print STDERR "usage: git-basis [--update] basis1...\n";
+ exit;
+} elsif ( $ARGV[0] eq '--update' ) {
+ shift @ARGV;
+
+ my %new = ();
+ while (<STDIN>) {
+ if (!/^^?([a-z0-9]{40})/) {next;}
+ $new{$1} = 1;
+ }
+
+ foreach my $f (@ARGV) {
+ my %these = ();
+ my $fh;
+
+ open $fh, "+<$d/bases/$f" || die "Can't open bases/$f: $!";
+ while (<$fh>) {
+ if (!/^([a-z0-9]{40})/) {next;}
+ $these{$1} = 1;
+ }
+
+ print $fh "# ", gmtime() - $git_epoch,
+ " +0000 // ", scalar(localtime()), "\n";
+
+ foreach my $b (keys %new) {
+ if (exists($these{$b})) {next;}
+ print $fh "$b\n";
+ }
+ close $fh;
+ }
+} else {
+ my $n = 0;
+ my %basis = ();
+
+ my $f = shift @ARGV;
+ open F, "<$d/bases/$f" || die "Can't open bases/$f: $!";
+ while (<F>) {
+ if (!/^([a-z0-9]{40})/) {next;}
+ $basis{$1} = $n;
+ }
+ close F;
+
+ foreach $f (@ARGV) {
+ open F, "<$d/bases/$f" || die "Can't open bases/$f: $!";
+ while (<F>) {
+ if (!/^([a-z0-9]{40})/) {next;}
+ if (!exists($basis{$1})) {next;}
+
+ if ($basis{$1} == $n) {$basis{$1}++;}
+ else {delete $basis{$1};}
+ }
+ close F;
+ $n++;
+ }
+
+ foreach my $b (keys %basis) {
+ if ( $basis{$b} != $n ) {next;}
+ print "^$b\n";
+ }
+}
diff --git a/contrib/basis/git-basis.txt b/contrib/basis/git-basis.txt
new file mode 100644
index 0000000..97cfc20
--- /dev/null
+++ b/contrib/basis/git-basis.txt
@@ -0,0 +1,90 @@
+git-basis(1)
+============
+
+NAME
+----
+git-basis - Track sets of references available on remote systems (bases)
+
+SYNOPSIS
+--------
+[verse]
+'git-basis' <basis> [<basis>...]
+'git-basis' --update <basis> [<basis>...] < <object list or bundle>
+
+DESCRIPTION
+-----------
+Maintains lists of objects that are known to be accessible on remote
+computer systems that are not accessible by network.
+
+OPTIONS
+-------
+
+basis::
+ List of bases to operate on. Any valid filename can be
+ the name of a basis. Bases that do not exist are taken
+ to be empty.
+
+--update::
+ Tells git-basis to read a list of objects from stdin and
+ add them to each of the given bases. git-basis produces
+ no output when this option is given. Bases will be created
+ if necessary.
+
+object list or bundle::
+ Git-basis --update reads object names, one per line from stdin.
+ Leading caret ("^") characters are ignored, as is anything
+ after the object name. Lines that don't begin with an object
+ name are ignored. The output of linkgit:git-ls-remote[1] or a
+ bundle created by linkgit:git-bundle[1] are both suitable input.
+
+DISCUSSION
+----------
+git-basis is probably only useful with linkgit:git-bundle[1].
+
+To create a bundle that excludes all objects that are part of my-basis,
+use
+
+git-basis my-basis | git-bundle create my-bundle --all --stdin
+
+To add the objects in my-bundle to my-basis, use
+
+git-basis --update my-basis < my-bundle
+
+DETAILS
+-------
+Bases are stored as plain text files under .git/bases/. One object
+entry per line.
+
+git-basis without --update reads all of the basis names given on the
+command line, and outputs the intersection of them to stdout, with each
+object prefixed by "^".
+
+git-basis --update reads object names from stdin, and adds all of the
+references to each of the bases listed. Duplicate references will not
+be listed twice, but otherwise redundant information will be included.
+Each update is prefixed by a line with the current date.
+
+BUGS
+----
+Git-baisis has no undo function. Once an object is added to a basis,
+it will stay there forever. If you need to remove objects from a basis,
+use a text editor to alter the file .git/bases/<basis name>.
+
+Git-basis --update does not remove redundant information from bases.
+(Having an object implies that it's parents are also available.) This
+is done intentionally to make sure git-basis --update is
+non-destructive.
+
+Bug reports are welcome, and patches are encouraged.
+
+SEE ALSO
+--------
+linkgit:git-bundle[1]
+
+AUTHOR
+------
+Written by Adam Brewster <asb@bu.edu>
+
+GIT
+---
+Part of the linkgit:git[1] suite
--
1.5.5.1.211.g65ea3.dirty
^ permalink raw reply related
* [PATCH] Move read_revisions_from_stdin from builtin-rev-list.c to revision.c
From: Adam Brewster @ 2008-07-05 20:40 UTC (permalink / raw)
To: git
Cc: gitster, mdl123, Johannes.Schindelin, jnareb, adambrewster,
Adam Brewster
In-Reply-To: <1215290434-27694-1-git-send-email-adambrewster@gmail.com>
Some other commands might like to support the --stdin option like
git-rev-list. Since they don't want to depend on builtin-rev-list, the
function has to be somewhere else.
Signed-off-by: Adam Brewster <asb@bu.edu>
---
builtin-rev-list.c | 17 -----------------
revision.c | 17 +++++++++++++++++
2 files changed, 17 insertions(+), 17 deletions(-)
mode change 100644 => 100755 builtin-rev-list.c
mode change 100644 => 100755 revision.c
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
old mode 100644
new mode 100755
index 11a7eae..b4a2c44
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -575,23 +575,6 @@ static struct commit_list *find_bisection(struct commit_list *list,
return best;
}
-static void read_revisions_from_stdin(struct rev_info *revs)
-{
- char line[1000];
-
- while (fgets(line, sizeof(line), stdin) != NULL) {
- int len = strlen(line);
- if (len && line[len - 1] == '\n')
- line[--len] = 0;
- if (!len)
- break;
- if (line[0] == '-')
- die("options not supported in --stdin mode");
- if (handle_revision_arg(line, revs, 0, 1))
- die("bad revision '%s'", line);
- }
-}
-
int cmd_rev_list(int argc, const char **argv, const char *prefix)
{
struct commit_list *list;
diff --git a/revision.c b/revision.c
old mode 100644
new mode 100755
index 5a1a948..0191160
--- a/revision.c
+++ b/revision.c
@@ -911,6 +911,23 @@ int handle_revision_arg(const char *arg, struct rev_info *revs,
return 0;
}
+void read_revisions_from_stdin(struct rev_info *revs)
+{
+ char line[1000];
+
+ while (fgets(line, sizeof(line), stdin) != NULL) {
+ int len = strlen(line);
+ if (len && line[len - 1] == '\n')
+ line[--len] = '\0';
+ if (!len)
+ break;
+ if (line[0] == '-')
+ die("options not supported in --stdin mode");
+ if (handle_revision_arg(line, revs, 0, 1))
+ die("bad revision '%s'", line);
+ }
+}
+
static void add_grep(struct rev_info *revs, const char *ptn, enum grep_pat_token what)
{
if (!revs->grep_filter) {
--
1.5.5.1.211.g65ea3.dirty
^ permalink raw reply related
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