* Re: Git GUI client SmartGit released
From: Dilip M @ 2009-12-06 6:37 UTC (permalink / raw)
To: David Aguilar, Johannes Schindelin, Marc Strapetz, git
In-Reply-To: <20091205204455.GA49665@gmail.com>
Hi, yes..Cheetah has more feature set. Have to give a try once.
I really don't know the diff of Cheetah and Tortise. Want to know more
on Cheetah...any links would help. Some time back when googled all
resulted in Tortise.
On 12/6/09, David Aguilar <davvid@gmail.com> wrote:
> On Sat, Dec 05, 2009 at 10:02:08PM +0530, Dilip M wrote:
>> On Sat, Dec 5, 2009 at 8:31 PM, <Johannes.Schindelin@gmx.de> wrote:
>>
>> > As for "missing", do you refer to "paid service", or "yet another GUI"?
>>
>> Ahaha! I can say "a good gui" :)
>>
>> I was not knowing that this was "paid service". I saw the screenshot
>> and tried it. No doubt, it has a _great_ ui interface. While installation
>> I
>> realized that it is licensed.
>>
>> - SOFTWARE Non-Commercial License,
>> - SOFTWARE Commercial License,
>> - SOFTWARE Enterprise License.
>
>
> Aside from the other good GUIs out there, have you tried
> git-cola?
>
> http://cola.tuxfamily.org/
>
> It's GPL and not too shabby.
> The screenshots on the webpage are a bit out of date, though.
> I should probably get to writing the release announcment and
> updating the screenshots ;)
>
> It probably also depends on your platform of choice.
> I know some Windows users like explorer-integration, so stuff
> like git-cheetah make a lot of sense for them. I was a little
> sad to see that the tortoise-git guys didn't get the joke
> (who wants a tortoise when you have a cheetah?) and didn't
> just work on cheetah instead, but hey, it's all good.
>
> Another example: eclipse users like eclipse integration so for
> them egit makes perfect sense.
>
> Maybe that makes git-cola the poor man's smartgit?
> If that's the case then it looks like the poor man is still
> winning according to the feature matrix on the git wiki ;)
> I don't know.. I haven't used smartgit, but if there are
> any features that people are itching to have that git-cola
> doesn't then feel free to throw it on the backlog:
>
> http://github.com/davvid/git-cola/issues
>
> At first glance, the gitk-like history widget in smartgit
> is very nice. I've been thinking about how to implement that in
> PyQt for a while but haven't yet hammered it out.
>
>
> Have fun,
>
> --
> David
>
--
Sent from my mobile device
Dilip
^ permalink raw reply
* clang static analyzer
From: Tomas Carnecky @ 2009-12-06 6:11 UTC (permalink / raw)
To: git list
There have been several attempts at running the clang static analyzer on the git source code, some even resulted in patches. I tried it, too, and among the many false positives I think clang found a few real issues. The results can be seen at [1].
Clang again found many dead assignments/increments, but in the earlier discussions you concluded that you want to keep those around. So I focussed on another class of potential bugs: Argument with 'nonnull' attribute passed null. There were a total of seven such issues. I then tried to look through the code and see if they are valid or false positives:
xdiff-interface.c:xdiff_set_find_func() - When 'value' is a string with no newline character in it, the loop at line 291 sets 'value' to NULL on its first iteration and then passes 'value' to strchr() in the second iteration.
utf8.c:utf8_strwidth() - 'string' may be set to NULL in utf8_width() which makes this one a false positive.
pretty.c:get_header() - if 'line' doesn't contain a newline character, line is set to NULL on first iteration and then passed to strchr() in the second itration.
attr.c:prepare_attr_stack() - bootstrap_attr_stack() sets attr_stack so this one is a false positive as well.
test-parse-options.c:length_callback() - if arg == NULL and unset == 0 then the function passes NULL to strlen().
builtin-pack-objects.c:check_pbase_path() - false positive, if done_pbase_paths == NULL then also done_pbase_paths_alloc == 0 and so step 4 can't take the false branch.
builtin-ls-files.c:verify_pathspec() - false positive, pathspec is not NULL when the function is called.
- Some of the issues might be purely hypothetical, for example I don't know if it's possible that get_header() can be passed a string with no newlines, maybe this is prevented earlier in the code path.
- Some of the false positives (such as the last one) could be avoided by giving clang a hint that a certain variable can't be NULL (by using assert() or if (!foo) return).
tom
[1] http://78.46.209.101/stuff/clang-static-analyzer/git/v1.6.6-rc1-32-g97f3d79/
^ permalink raw reply
* Re: [PATCH] Add commit.infodisplay option to give message editor empty file
From: Jeff King @ 2009-12-06 4:22 UTC (permalink / raw)
To: James P. Howard, II; +Cc: git
In-Reply-To: <20091205230903.GA3816@thermopylae.local>
On Sat, Dec 05, 2009 at 06:09:03PM -0500, James P. Howard, II wrote:
> On Sat, Dec 05, 2009 at 11:28:27AM -0500, Jeff King wrote:
>
> > If the latter, I think we would be better served by an option to simply
> > turn off the template. Then that is also helpful for the case of people
> > using decent editors, but who don't want to waste the CPU time on
> > generating the template information (which can be substantial for things
> > like media repositories).
>
> Actually, I find this a reasonable solution for both cases and would be
> willing to reimplment my change this way, as it meets my needs and would
> be useful to others. The only question I have is, what should variable/
> command line option be called?
I would be tempted to call it "--no-template", but I think that is too
confusing. The "--template" option is not really about the git-generated
template, but about a user-defined template that goes on top of the
git-generated one (I would have expected --template=/dev/null to do what
you want, too, but it retains the git template).
Probably "--no-status" would be a good name, as the generated template
is the format generated by "git status".
-Peff
^ permalink raw reply
* Re: git reset --hard in .git causes a checkout in that directory
From: Jeff King @ 2009-12-06 4:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Maarten Lankhorst, git
In-Reply-To: <7vocmdutph.fsf@alter.siamese.dyndns.org>
On Sat, Dec 05, 2009 at 11:06:02AM -0800, Junio C Hamano wrote:
> > Junio, I think the following should go to maint (I didn't bother
> > splitting the --merge and --hard code; --merge is in v1.6.2. I assumed
> > we don't care about maint releases that far back).
>
> Although I'll apply your patch to 'maint' and will merge it for 1.6.6, I
> am not quite sure if this is the best fix in the longer run. Shouldn't we
> go back to the top of the work tree and running what was asked there?
I actually considered that, too, when writing the patch. But that would
be inconsistent with all of the other commands that use SETUP_WORK_TREE.
For example:
$ git init && cd .git && git clean
fatal: This operation must be run in a work tree
So I think we are better to be consistent with the other commands. If
somebody wants to make a separate patch to discover the work tree while
in the $GIT_DIR and chdir to it, that should then be applied to all
commands. I'm not opposed to it, but I also don't see it as a
particularly pressing need.
-Peff
^ permalink raw reply
* Re: git reset --hard in .git causes a checkout in that directory
From: Jeff King @ 2009-12-06 4:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Maarten Lankhorst, git
In-Reply-To: <7vfx7pwa6p.fsf@alter.siamese.dyndns.org>
On Sat, Dec 05, 2009 at 10:24:46AM -0800, Junio C Hamano wrote:
> > ... The test already checks that the change won't break soft reset,
> > which is good, but it does not seem to check/specify what should happen in
> > the mixed reset in this case (I think it should be allowed).
>
> Heh, I was not thinking straight. A bare repository does not have the
> index, so allowing (cd .git && git reset) is Ok but mixed in a bare
> repository (cd bare.git && git reset) is not.
Hmm. I would have thought it would be allowed in a bare repository, to
explicitly let people treat the bare repo as a pseudo-database, just
pulling out the files when they want to. And I was all set to argue
against restricting it, but looking at your tests, it seems we already
disallow it. So I don't see a harm in verifying the current behavior.
-Peff
^ permalink raw reply
* Re: [PATCH] Allow --quiet option to git remote, particularly for `git remote update`
From: Junio C Hamano @ 2009-12-06 2:04 UTC (permalink / raw)
To: Alex Vandiver; +Cc: git
In-Reply-To: <1260057623-28960-1-git-send-email-alex@chmrr.net>
Alex Vandiver <alex@chmrr.net> writes:
> Signed-off-by: Alex Vandiver <alex@chmrr.net>
Sounds good as it makes the behaviour consistent with the underlying "git
fetch".
> ...
> "git remote prune [-n | --dry-run] <name>",
> - "git remote [-v | --verbose] update [-p | --prune] [group | remote]",
> + "git remote [-v | --verbose] [-q | --quiet] update [-p | --prune] [group]",
We say "<name>" everywhere else except for "update" we call the parameter
"group" or "remote" using different typography. It is not the fault of
your patch, but has been this way since 1918278 (Allow git-remote to
update named groups of remotes, 2007-02-20).
Three issues to consider:
- shouldn't we use the same typography, i.e. <group>?
- should we say <name> _if_ we are not going to say <group>|<remote>?
- should we keep it as <group>|<remote> to make it clear that only this
subcommand allows the group nickname?
The first two are easy and I expect the answers to be both yes. The third
one needs some studying and further thought.
- is "remote update" the only one that takes group nickname?
- should "remote update" the only one? e.g. does "remote prune" also
take group? if not, shouldn't it?
^ permalink raw reply
* Re: Continued work on sr/vcs-helper and sr/gfi-options
From: Junio C Hamano @ 2009-12-06 1:47 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git List
In-Reply-To: <fabb9a1e0912051653s77ba25e1g9ff1e21219cd06c9@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> I'm planning to start finishing up git-remote-hg this week, and for
> that I need both sr/vcs-helper (in next) and sr/gfi-options (in pu).
> How can I best go about working on these? I _think_ what I want is to
> merge sr/vcs-helper and sr/gfi-options, into either master or next
> (with a three-way merge), but I'm not sure? Also, when I try to rebase
> sr/vcs-helper onto master I get conflicts yet again, since these were
> already resolved in next, what is the best way for me to proceed in
> such a way that it is convenient for you (Junio) and the list, if
> possible, without having to untangle those merge conflicts.
Some observations.
- sr/vcs-helper seems to be near completion; I'd expect it to be among
the first batch of topics to go to 'master' after 1.6.6 final (some
fixes may happen between now and 1.6.6 final to make the series a bit
longer, though).
- sr/gfi-options started moving again and there could be a couple more
iterations before it would hit 'next'.
Until sr/gfi-options becomes more solid, one way we can manage
sr/remote-hg is (thinking aloud):
- Fork sr/remote-hg from today's sr/vcs-helper;
- Merge today's 'master' to sr/remote-hg (optional);
- Whenever any updates to vcs-helper topic appears, apply them to
sr/vcs-helper, and merge the result to sr/remote-hg;
- Create an unstable sr/pu-remote-hg branch that:
- is reset to the tip of sr/remote-hg at the beginning of the day;
- merges the day's sr/gfi-options on top;
- re-applies patches to implement Hg interoperation on top of the
result.
When sr/gfi-options becomes solid, we can merge it to sr/remote-hg itself,
get rid of sr/pu-remote-hg "patch queue", and move the Hg interoperation
patches we helpd in sr/pu-remote-hg to sr/remote-hg branch. We will merge
early parts of sr/remote-hg (at least up to the merge with sr/gfi-options,
and perhaps early parts of individual Hg interoperation patches as well)
to 'next', and remaining parts on the branch to 'pu' (and they can be
replaced).
^ permalink raw reply
* Re: Continued work on sr/vcs-helper and sr/gfi-options
From: Miklos Vajna @ 2009-12-06 1:05 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, Git List
In-Reply-To: <fabb9a1e0912051653s77ba25e1g9ff1e21219cd06c9@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 300 bytes --]
On Sun, Dec 06, 2009 at 01:53:03AM +0100, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> (with a three-way merge), but I'm not sure? Also, when I try to rebase
> sr/vcs-helper onto master I get conflicts yet again, since these were
That part is fairly easy, just don't forget to enable rerere. :)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Continued work on sr/vcs-helper and sr/gfi-options
From: Sverre Rabbelier @ 2009-12-06 0:53 UTC (permalink / raw)
To: Junio C Hamano, Git List
Heya,
I'm planning to start finishing up git-remote-hg this week, and for
that I need both sr/vcs-helper (in next) and sr/gfi-options (in pu).
How can I best go about working on these? I _think_ what I want is to
merge sr/vcs-helper and sr/gfi-options, into either master or next
(with a three-way merge), but I'm not sure? Also, when I try to rebase
sr/vcs-helper onto master I get conflicts yet again, since these were
already resolved in next, what is the best way for me to proceed in
such a way that it is convenient for you (Junio) and the list, if
possible, without having to untangle those merge conflicts.
Thanks!
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH] Allow --quiet option to git remote, particularly for `git remote update`
From: Alex Vandiver @ 2009-12-06 0:00 UTC (permalink / raw)
To: git
Signed-off-by: Alex Vandiver <alex@chmrr.net>
---
builtin-remote.c | 19 ++++++++++++-------
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index a501939..a34006f 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -8,14 +8,14 @@
#include "refs.h"
static const char * const builtin_remote_usage[] = {
- "git remote [-v | --verbose]",
+ "git remote [-v | --verbose] [-q | --quiet]",
"git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>",
"git remote rename <old> <new>",
"git remote rm <name>",
"git remote set-head <name> (-a | -d | <branch>)",
"git remote [-v | --verbose] show [-n] <name>",
"git remote prune [-n | --dry-run] <name>",
- "git remote [-v | --verbose] update [-p | --prune] [group | remote]",
+ "git remote [-v | --verbose] [-q | --quiet] update [-p | --prune] [group]",
NULL
};
@@ -58,7 +58,7 @@ static const char * const builtin_remote_update_usage[] = {
#define GET_HEAD_NAMES (1<<1)
#define GET_PUSH_REF_STATES (1<<2)
-static int verbose;
+static int verbosity;
static int show_all(void);
static int prune_remote(const char *remote, int dry_run);
@@ -84,9 +84,12 @@ static int opt_parse_track(const struct option *opt, const char *arg, int not)
static int fetch_remote(const char *name)
{
const char *argv[] = { "fetch", name, NULL, NULL };
- if (verbose) {
+ if (verbosity > 0) {
argv[1] = "-v";
argv[2] = name;
+ } else if (verbosity < 0) {
+ argv[1] = "-q";
+ argv[2] = name;
}
printf("Updating %s\n", name);
if (run_command_v_opt(argv, RUN_GIT_CMD))
@@ -1236,8 +1239,10 @@ static int update(int argc, const char **argv)
if (prune)
fetch_argv[fetch_argc++] = "--prune";
- if (verbose)
+ if (verbosity > 0)
fetch_argv[fetch_argc++] = "-v";
+ if (verbosity < 0)
+ fetch_argv[fetch_argc++] = "-q";
if (argc < 2) {
fetch_argv[fetch_argc++] = "default";
} else {
@@ -1301,7 +1306,7 @@ static int show_all(void)
sort_string_list(&list);
for (i = 0; i < list.nr; i++) {
struct string_list_item *item = list.items + i;
- if (verbose)
+ if (verbosity > 0)
printf("%s\t%s\n", item->string,
item->util ? (const char *)item->util : "");
else {
@@ -1318,7 +1323,7 @@ static int show_all(void)
int cmd_remote(int argc, const char **argv, const char *prefix)
{
struct option options[] = {
- OPT_BOOLEAN('v', "verbose", &verbose, "be verbose; must be placed before a subcommand"),
+ OPT__VERBOSITY(&verbosity),
OPT_END()
};
int result;
--
1.6.6.rc0.360.gc408
^ permalink raw reply related
* Re: [PATCH] cvsserver: make the output of 'update' more compatible with cvs.
From: mmogilvi_git @ 2009-12-05 23:48 UTC (permalink / raw)
To: Sergei Organov; +Cc: git, gitster
In-Reply-To: <87zl5z4y0w.fsf@osv.gnss.ru>
On Thu, Dec 03, 2009 at 11:12:47PM +0300, Sergei Organov wrote:
>
> + my $last_dirname = "///";
> +
> # foreach file specified on the command line ...
> foreach my $filename ( @{$state->{args}} )
> {
> $filename = filecleanup($filename);
> + my $cur_dirname = dirname($filename);
> + if ( $cur_dirname ne $last_dirname )
> + {
> + $last_dirname = $cur_dirname;
> + if ( $cur_dirname eq "" )
> + {
> + $cur_dirname = ".";
> + }
> + print "E cvs update: Updating $cur_dirname\n";
> + }
>
> $log->debug("Processing file $filename");
This should probably be conditional on the absense of the
global "cvs -q update" and "cvs -Q update" options, in case
other CVS clients depend on quiet operation when they specify
those options.
--
Matthew Ogilvie [mmogilvi_git@miniinfo.net]
^ permalink raw reply
* Re: [spf:guess] Re: [PATCH 2/5] git-svn: Make merge metadata accessible to make_log_entry
From: Alex Vandiver @ 2009-12-05 23:10 UTC (permalink / raw)
To: Sam Vilain; +Cc: Eric Wong, git
In-Reply-To: <1260053972.22680.5.camel@denix>
At Sat Dec 05 17:59:32 -0500 2009, Sam Vilain wrote:
> Hi, I've just seen the series, looks like a good idea. Just a couple of
> questions then I'll review the code;
>
> - when a change is merged upstream with svk, you will get multiple log
> entries in a single commit message. What do you do with commits like
> that?
If the user edited the merge message and supplied their own message,
nothing. If the first line is an SVK merge line, it inserts a message
"Merged from /svn/path/to/trunk:12345\n\n" at the top.
> - there are quite a few repos which will have empty commits (ie, no
> changes), but with one or more of the above log entries, owing to a bug
> which I can't seem to find the details of right now.. how might those
> appear?
Without seeing an example, I'm not sure offhand -- but what you're
describing does ring a bell, so I'm sure I've seen the mismerges
you're talking about as well.
- Alex
--
Networking -- only one letter away from not working
^ permalink raw reply
* Re: [PATCH] Add commit.infodisplay option to give message editor empty file
From: James P. Howard, II @ 2009-12-05 23:09 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091205162827.GA9584@sigill.intra.peff.net>
On Sat, Dec 05, 2009 at 11:28:27AM -0500, Jeff King wrote:
> If the latter, I think we would be better served by an option to simply
> turn off the template. Then that is also helpful for the case of people
> using decent editors, but who don't want to waste the CPU time on
> generating the template information (which can be substantial for things
> like media repositories).
Actually, I find this a reasonable solution for both cases and would be
willing to reimplment my change this way, as it meets my needs and would
be useful to others. The only question I have is, what should variable/
command line option be called?
James
--
James P. Howard, II, MPA MBCS
jh@jameshoward.us
^ permalink raw reply
* Re: [PATCH] Cast &cp to eliminate a compile-time warning on FreeBSD 8-STABLE.
From: James P. Howard, II @ 2009-12-05 23:03 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091205161405.GA9272@sigill.intra.peff.net>
On Sat, Dec 05, 2009 at 11:14:05AM -0500, Jeff King wrote:
> On Fri, Dec 04, 2009 at 06:12:02PM -0500, James P. Howard, II wrote:
>
> > --- a/utf8.c
> > +++ b/utf8.c
> > @@ -449,7 +449,7 @@ char *reencode_string(const char *in, const char *out_encoding, const char *in_e
> > cp = (iconv_ibp)in;
> >
> > while (1) {
> > - size_t cnt = iconv(conv, &cp, &insz, &outpos, &outsz);
> > + size_t cnt = iconv(conv, (const char **)&cp, &insz, &outpos, &outsz);
> >
> > if (cnt == -1) {
> > size_t sofar;
>
> Aren't you now introducing a warning for all of the other platforms
> which take a "char **"? Should you instead just be building with
> OLD_ICONV=Yes on your platform? See commit fd547a9 for details.
Yes, and it was brought to my attention within 10 minutes of my first
post.
James
--
James P. Howard, II, MPA MBCS
jh@jameshoward.us
^ permalink raw reply
* Re: [spf:guess] Re: [PATCH 2/5] git-svn: Make merge metadata accessible to make_log_entry
From: Sam Vilain @ 2009-12-05 22:59 UTC (permalink / raw)
To: Alex Vandiver; +Cc: Eric Wong, git
In-Reply-To: <1260052934-sup-9563@utwig>
On Sat, 2009-12-05 at 17:51 -0500, Alex Vandiver wrote:
> At Sat Dec 05 17:32:41 -0500 2009, Eric Wong wrote:
> > I'll continue to defer to Sam for ack-ing SVK-related things.
> >
> > One thing I am very picky about is wrapping lines at 80-columns or
> > less (hard tabs being 8 characters wide).
>
> *nod* I've fixed up my local copy for v2 to rewrap things at < 80
> columns, and will keep that in mind for the future.
Hi, I've just seen the series, looks like a good idea. Just a couple of
questions then I'll review the code;
- when a change is merged upstream with svk, you will get multiple log
entries in a single commit message. What do you do with commits like
that?
- there are quite a few repos which will have empty commits (ie, no
changes), but with one or more of the above log entries, owing to a bug
which I can't seem to find the details of right now.. how might those
appear?
Thanks for your submission!
Sam
^ permalink raw reply
* Re: [PATCH 2/5] git-svn: Make merge metadata accessible to make_log_entry
From: Alex Vandiver @ 2009-12-05 22:51 UTC (permalink / raw)
To: Eric Wong; +Cc: Sam Vilain, git
In-Reply-To: <20091205223241.GB2120@dcvr.yhbt.net>
At Sat Dec 05 17:32:41 -0500 2009, Eric Wong wrote:
> I'll continue to defer to Sam for ack-ing SVK-related things.
>
> One thing I am very picky about is wrapping lines at 80-columns or
> less (hard tabs being 8 characters wide).
*nod* I've fixed up my local copy for v2 to rewrap things at < 80
columns, and will keep that in mind for the future.
- Alex
--
Networking -- only one letter away from not working
^ permalink raw reply
* Re: svn svn returning 'fatal: Not a valid object name' on sourceforge svn repo
From: Eric Wong @ 2009-12-05 22:49 UTC (permalink / raw)
To: Stephen Bannasch; +Cc: git
In-Reply-To: <p0624081ac73dd6a1aaff@[63.138.152.192]>
Stephen Bannasch <stephen.bannasch@deanbrook.org> wrote:
> I use git svn often and normally it works fine.
>
> I getting a fatal error trying to clone the asciimathm svn repo at sourceforge:
>
> $ git svn clone --trunk=trunk --branches=branches http://asciimathml.svn.sourceforge.net/svnroot/asciimathml asciimathml-svn-git
> fatal: Not a valid object name
> ls-tree -z ./: command returned error: 128
>
> Anybody seen this kind of problem before.
>
> A svn co works fine.
>
> I'm using git version 1.6.5.1 on mac os 10.5.8.
Hi Stephen,
Passing the "-r4:HEAD" parameter to "git svn clone" should work. It
looks like the repository was initially miscreated and "trunk" was a
symlink (and not a directory) in r1.
I have not yet thought of a good solution to this, yet...
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 2/5] git-svn: Make merge metadata accessible to make_log_entry
From: Eric Wong @ 2009-12-05 22:32 UTC (permalink / raw)
To: Sam Vilain, Alex Vandiver; +Cc: git
In-Reply-To: <1259786690-sup-8337@utwig>
Alex Vandiver <alex@chmrr.net> wrote:
> This hunk is wrong due to a mis-merge on my part -- the first 'push'
> line should have been removed, obviously. I'll wait for other
> comments before I push a v2, however.
Hi Alex,
I'll continue to defer to Sam for ack-ing SVK-related things.
One thing I am very picky about is wrapping lines at 80-columns or
less (hard tabs being 8 characters wide).
--
Eric Wong
^ permalink raw reply
* Re: git-svn breakage on repository rename
From: Eric Wong @ 2009-12-05 22:22 UTC (permalink / raw)
To: Guido Stevens; +Cc: git, George Kuk
In-Reply-To: <4B197078.6050203@cosent.net>
Guido Stevens <guido.stevens@cosent.net> wrote:
> Hi Eric e.a.,
>
> I have a weird git-svn corner case that might interest you (or not at
> all). I'd appreciate any help or hints for moving beyond this problem.
>
> I'm using git-svn to do a full commit history analysis of the Zope +
> Plone CMS code bases as part of a research project with the University
> of Nottingham into open source knowledge dynamics.
>
> One of the repositories I'm importing breaks with a "Checksum mismatch",
> indicating a corruption. However, this error message occurs exactly at
> the point where the repository was renamed: from "Products.CMFPlone" to
> "Plone" (22715->22716). (Yes, it's the Plone core itself that resists
> analysis :-()
>
> The git-svn url for the later commits would be:
> http://svn-mirror.plone.org/svn/plone/Plone/trunk
>
> Whereas an older part of the code base lives at:
> http://svn-mirror.plone.org/svn/plone/Products.CMFPlone/trunk
>
> Funny thing is, git-svn detects this rename upfront but then breaks
> anyway. Which raises the questions:
>
> - is this breakage caused by the rename?
Hi Guido,
Yes. By default, git svn without --stdlayout does not attempt
to determine a repository root so parent following can be done.
On the other hand, Plone does appear to use a standard SVN layout.
> - or does git-svn handle the rename, and there is an actual corruption?
It should, let me know if the example I give below doesn't work
It looks like a big repo and they're worried about bandwidth:
"Do not make a checkout of the entire repository! This is likely to
get you blacklisted."
(ref: http://dev.plone.org/plone/wiki/RepoInfo)
> - is there any way I can work around this and get a valid or semi-valid
> git history for this project?
>
> I don't mind missing a few commits, since I'm not doing code development
> on this repository, only statistical analysis.
I would mind very much if git svn missed commits :>
> Solving this would also be helpful for anyone who wants to work on Plone
> development through git rather than through raw svn.
>
> :*CU#
>
> ----------------------------------------------------
> To reconstruct this error:
> ----------------------------------------------------
>
> $ git svn init https://svn-mirror.plone.org/svn/plone/Plone/trunk Plone
> $ cd Plone
> $ git svn fetch
Since Plone appears to use a standard trunk/branches/tags layout
recommended by SVN developers, can you try this instead?:
git svn clone -s http://svn-mirror.plone.org/svn/plone/Plone
If you don't care about branches/tags at all, you can also try
git svn clone --no-follow-parent \
https://svn-mirror.plone.org/svn/plone/Plone/trunk Plone
Also, in the future it'd be nice to know which version of git svn
you're using since bugs may be fixed in a newer version. Thanks!
--
Eric Wong
^ permalink raw reply
* Re: [PATCHv3 0/3] git-gui: more robust handling of fancy repos
From: Shawn O. Pearce @ 2009-12-05 22:15 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Markus Heidelberg
In-Reply-To: <1250467128-29839-1-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> wrote:
> As promised a long time ago (March 30), version 3 of the small patchset
> to improve handling of repositories in git gui. The most significant
> change is the addition of the third patch.
...
> Giuseppe Bilotta (3):
> git-gui: handle non-standard worktree locations
> git-gui: handle bare repos correctly
> git-gui: work from the .git dir
>
> git-gui/git-gui.sh | 88 +++++++++++++++++++++++++++++++++++++++++++---------
> 1 files changed, 73 insertions(+), 15 deletions(-)
Unfortunately this series doesn't apply to my tree, and I don't
have the blobs which are recorded in the index line, so I can't
easily 3-way merge it onto the current tip.
Would you be able to rebase it?
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH v2 0/2] git-gui: (un)stage a range of changes at once
From: Shawn O. Pearce @ 2009-12-05 21:36 UTC (permalink / raw)
To: Jeff Epler; +Cc: git
In-Reply-To: <20091026193903.GA27319@unpythonic.net>
Jeff Epler <jepler@unpythonic.net> wrote:
> I've found another problem, which I'll work on as soon as I find a
> chance.
>
> When staging multiple "+" lines preceded by a "-" line that must be
> turned into context, the converted "-" line must come after *all* the
> "+" lines, not just the first one.
So the reason this series got stuck was this message, this bug is
enough to suggest we shouldn't apply it to my tree yet, so I've
been waiting for an update on the topic.
Also, I need a Signed-off-by line.
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH 1/2] Fix applying a line when all following lines are deletions
From: Shawn O. Pearce @ 2009-12-05 21:32 UTC (permalink / raw)
To: Jeff Epler; +Cc: git
In-Reply-To: <1256160023-29629-2-git-send-email-jepler@unpythonic.net>
Jeff Epler <jepler@unpythonic.net> wrote:
> If a diff looked like
> @@
> context
> -del1
> -del2
> and you wanted to stage the deletion 'del1', the generated patch
> wouldn't apply because it was missing the line 'del2' converted to
> context, but this line was counted in the @@-line
> ---
> lib/diff.tcl | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/lib/diff.tcl b/lib/diff.tcl
> index bd5d189..066755b 100644
> --- a/lib/diff.tcl
> +++ b/lib/diff.tcl
> @@ -664,6 +664,7 @@ proc apply_line {x y} {
> }
> set i_l $next_l
> }
> + set patch "$patch$pre_context"
Signed-off-by ?
--
Shawn.
^ permalink raw reply
* Re: Re: [RFC PATCH v2 0/2] git-gui: (un)stage a range of changes at once
From: Shawn O. Pearce @ 2009-12-05 21:19 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Peter Baumann, Jeff Epler, git
In-Reply-To: <20091204220730.GB3979@book.hvoigt.net>
Heiko Voigt <hvoigt@hvoigt.net> wrote:
> On Thu, Oct 29, 2009 at 08:34:54AM +0100, Peter Baumann wrote:
> > Cc ing Shawn as the git gui maintainer, as he might have missed this series
> > during his away time.
>
> Ping? A short reminder for Shawn as I do not see the patches in his
> tree.
I have a stack of git-gui patches which I've just ignored in
my inbox. I'll work through them this afternoon.
--
Shawn.
^ permalink raw reply
* Re: [PATCH RESEND] git gui: make current branch default in "remote delete branch" merge check
From: Shawn O. Pearce @ 2009-12-05 21:18 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git, Jens Lehmann, Junio C Hamano
In-Reply-To: <20091204212648.GA3979@book.hvoigt.net>
Heiko Voigt <hvoigt@hvoigt.net> wrote:
> We already do the same when locally deleting a branch.
>
> Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
> ---
>
> lib/remote_branch_delete.tcl | 8 +++++++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
Thanks, applied.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] bash: update 'git commit' completion
From: Shawn O. Pearce @ 2009-12-05 21:17 UTC (permalink / raw)
To: SZEDER G??bor; +Cc: Junio C Hamano, git
In-Reply-To: <1259974301-11593-1-git-send-email-szeder@ira.uka.de>
SZEDER G??bor <szeder@ira.uka.de> wrote:
> I just wanted to add the recently learnt '--reset-author' option, but
> then noticed that there are many more options missing. This patch
> adds support for all of 'git commit's options, except '--allow-empty',
> because it is primarily there for foreign scm interfaces.
>
> Furthermore, this patch also adds support for completing the arguments
> of those options that take a non-filename argument: valid modes are
> offered for '--cleanup' and '--untracked-files', while refs for
> '--reuse-message' and '--reedit-message', because these two take a
> commit as argument.
>
> Signed-off-by: SZEDER G??bor <szeder@ira.uka.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> contrib/completion/git-completion.bash | 22 +++++++++++++++++++++-
> 1 files changed, 21 insertions(+), 1 deletions(-)
--
Shawn.
^ 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