* Re: [PATCH v2] git-gui: set NO_MSGFMT to force using pure tcl replacement in msysgit
From: Johannes Schindelin @ 2007-10-10 19:46 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: spearce, git
In-Reply-To: <CC4EB4CA-3BA0-4C00-8B23-31B09032CC69@zib.de>
Hi,
On Wed, 10 Oct 2007, Steffen Prohaska wrote:
> On Oct 10, 2007, at 5:52 PM, Johannes Schindelin wrote:
>
> > On Wed, 10 Oct 2007, Steffen Prohaska wrote:
> >
> > > Shawn's git-gui Makefile supports the pure tcl replacement for
> > > msgfmt if setting NO_MSGFMT. This patch sets the NO_MSGFMT for
> > > msysgit.
> >
> > Would it not be cleaner to set this in 4msysgit and export it?
>
> What does "set this in 4msysgit" mean?
It means what you probably assumed, that we change the Makefile in /git.
> Would running 'make' in /git/git-gui/ be supported by your solution?
No, not really. Just like "make" in /git/t/ does not pick up on the
NO_SYMLINKS option.
Ciao,
Dscho
^ permalink raw reply
* Re: Lots of loose objects
From: Johannes Schindelin @ 2007-10-10 19:37 UTC (permalink / raw)
To: David Kågedal; +Cc: Git Mailing List
In-Reply-To: <87myuqwzp3.fsf@lysator.liu.se>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 778 bytes --]
Hi,
On Wed, 10 Oct 2007, David Kågedal wrote:
> I hade a tree that made git-gui complain that I had too many loose
> objects every time I started it (3072 to be precise). Letting git-gui
> compress it for me didn't help. Neither did git-gc, even with the
> --aggressive flag.
>
> I noticed that I had a lot of loose files in .git/objects, and
> suddenly I remembered that there was a command called "git
> prune". Finally I was able to get rid of those loose objects.
Probably git-gui should check again, after the compacting stage, how many
loose objects there are, and suggest to run git prune after a sufficiently
terrifying warning message ("Should I prune unreferenced objects? (DON'T
do this if you share objects between repositories!) Yes / No").
Ciao,
Dscho
^ permalink raw reply
* Re: [FEATURE REQUEST] git clone, just clone selected branches?
From: Linus Torvalds @ 2007-10-10 19:38 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: git
In-Reply-To: <011401c80b6f$1a11d1f0$04ac10ac@Jocke>
On Wed, 10 Oct 2007, Joakim Tjernlund wrote:
>
> I know I can use git remote to do this, but it is a bit clumsy
> when starting a new repo.
How about just
git init
.. set up remote tracking info in .git/config ..
git fetch remote
which should do what you want.
Linus
^ permalink raw reply
* Re: inexplicable failure to merge recursively across cherry-picks
From: Linus Torvalds @ 2007-10-10 19:35 UTC (permalink / raw)
To: Miklos Vajna; +Cc: David Brown, martin f krafft, git discussion list
In-Reply-To: <20071010190757.GP23810@genesis.frugalware.org>
On Wed, 10 Oct 2007, Miklos Vajna wrote:
>
> Actually, specifically darcs, different merges _always_ result in the same
> data.
No they don't. You don't understand the problem.
Yes, different merges WITH THE SAME PATCHES always result in the same
data.
But that's not a realistic - or even very interesting - schenario.
What's much more common is that the same problem gets solved slightly
differently in two different branches. For example, maybe somebody does it
as two different patches - where the second one fixes a bug in the first
fix. And another person does the same fix, but without the bug in the
first place.
See? A patch-based system gets confused by those kinds of issues (or they
turn into various special cases). And that is fundamentally why you MUST
NOT take history into account (where "history" is some series of
individual patches).
Yes, history is interesting for historical reasons, and to explain what
the context was, but in many ways, history is exactly the *wrong* thing to
use when it comes to merging. You should look at the end result, since
people can - and do - come to the same result through different ways.
Linus
^ permalink raw reply
* Re: [FEATURE REQUEST] git clone, just clone selected branches?
From: Johannes Schindelin @ 2007-10-10 19:35 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: git
In-Reply-To: <011401c80b6f$1a11d1f0$04ac10ac@Jocke>
Hi,
On Wed, 10 Oct 2007, Joakim Tjernlund wrote:
> To my knowlede a git clone always clones all branches from the remote
> repo. I would like the possibly to clone selected branches, like
> git clone <repo URL> -b master -b upstream
> which will only fetch the master and upstream branch.
>
> I know I can use git remote to do this, but it is a bit clumsy when
> starting a new repo.
This is why I suggest: since it is an itch of yours, just fix it. You are
in the prime position to know when you're satisfied.
As a hint how to start: Junio dreamt of a git-clone which is a tiny
wrapper around git-fetch and git-remote.
So you could start by writing a script which would be a replacement for
git-clone.sh, and there you can also include the support for -b that you
would like so much.
It would be nice, though, to keep this in separate patches, which you then
submit to this list.
Thank you,
Dscho
^ permalink raw reply
* Re: [PATCH] git-cvsserver: added support for update -p
From: Johannes Schindelin @ 2007-10-10 19:27 UTC (permalink / raw)
To: Jan Wielemaker; +Cc: Jan Wielemaker, Git Mailing List
In-Reply-To: <200710101927.38949.wielemak@science.uva.nl>
Hi,
On Wed, 10 Oct 2007, Jan Wielemaker wrote:
> > On Wed, 10 Oct 2007, Jan Wielemaker wrote:
> > > Is there a test suite for git-cvsserver?
> >
> > Yes: t/t9400-git-cvsserver-server.sh
>
> Thanks. B.t.w. from the main directory:
>
> gollem (git) 21_> make check
make check is to check with the static code analyzer "sparse".
To test, try "make test". Since this is so commonly used to test
packages (for example, the vast majority of Perl packages have it), I do
not see the need to put a message pointing to "make test" in the "check"
target.
Ciao,
Dscho
^ permalink raw reply
* Lots of loose objects
From: David Kågedal @ 2007-10-10 19:13 UTC (permalink / raw)
To: Git Mailing List
I hade a tree that made git-gui complain that I had too many loose
objects every time I started it (3072 to be precise). Letting git-gui
compress it for me didn't help. Neither did git-gc, even with the
--aggressive flag.
I noticed that I had a lot of loose files in .git/objects, and
suddenly I remembered that there was a command called "git
prune". Finally I was able to get rid of those loose objects.
The problem here is probably mostly that I couldn't get any help from
git-gui or git-gc. git-gui claimed it would fix the problem for me,
but failed. git-gc didn't mention that it left a bunch of files
untouched.
--
David Kågedal
^ permalink raw reply
* Re: [PATCH] Support cvs via git-shell
From: Frank Lichtenheld @ 2007-10-10 19:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, hjemli, Jan Wielemaker, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0710101427160.4174@racer.site>
On Wed, Oct 10, 2007 at 02:29:00PM +0100, Johannes Schindelin wrote:
> On Wed, 10 Oct 2007, Frank Lichtenheld wrote:
> > On Tue, Oct 09, 2007 at 03:33:25PM +0100, Johannes Schindelin wrote:
> > > static struct commands {
> > > const char *name;
> > > int (*exec)(const char *me, char *arg);
> > > } cmd_list[] = {
> > > { "git-receive-pack", do_generic_cmd },
> > > { "git-upload-pack", do_generic_cmd },
> > > + { "cvs", do_cvs_cmd },
> > > { NULL },
> >
> > Maybe this should also allow git-cvsserver for completeness' sake?
>
> Umm. Why?
Symmetry? ;)
The "for completeness' sake" was as good a reason as I could think of.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: inexplicable failure to merge recursively across cherry-picks
From: Miklos Vajna @ 2007-10-10 19:07 UTC (permalink / raw)
To: David Brown; +Cc: Linus Torvalds, martin f krafft, git discussion list
In-Reply-To: <20071010154831.GA19226@old.davidb.org>
[-- Attachment #1: Type: text/plain, Size: 2199 bytes --]
On Wed, Oct 10, 2007 at 08:48:31AM -0700, David Brown <git@davidb.org> wrote:
> On Wed, Oct 10, 2007 at 08:25:15AM -0700, Linus Torvalds wrote:
> >Yes, *some* SCM's have tried to do that. In particular, the ones that are "patch-based" tend to think that patches are "identical" regardless of where they are, and while re-ordering of them is a special event, it's not somethign that changes the fundamental 'ID' of the patch.
> >For example, I think the darcs "patch algebra" works that way.
> >It's a really horrible model. Not only doesn't it scale, but it leads to various very strange linkages between patches, and it fails the most important part: it means that merges get different results just because people are doing the same changes two different ways.
> Actually, specifically darcs, different merges _always_ result in the same
> data. It's a fundamental part of is patch algebra. No matter what order
> you apply a given set of patches, even with conflicts and reordering, you
> always get the same result, or no result. Conflicts are "resolved" by
> inserting conflict markers in the file, ordered by the patch ID. It
> doesn't matter which order you apply them in, you get the same markers.
> Then there will be a merge patch which fixes the markers that someone could
> apply, no matter what order the applied the previous patches.
> Darcs breaks down in a few places, though.
> - The no result. Sometimes, it just can't figure out how to reorder
> patches. Even worse, occasionally, the implementation will fail to
> terminate try to figure this out. There isn't much to do at this
> point, except manually apply the patch, hence generating a new patch
> ID.
> - It doesn't scale well.
> The strange linkages between patches could be thought of as a feature,
> since it is basically constraining the order that the patches can be
> applied in.
> There is a darcs-git project that tries to do the darcs things on top of
> git.
> Dave
> -
> 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
thanks,
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [FEATURE REQUEST] git clone, just clone selected branches?
From: Joakim Tjernlund @ 2007-10-10 18:55 UTC (permalink / raw)
To: git
To my knowlede a git clone always clones all branches from the remote repo.
I would like the possibly to clone selected branches, like
git clone <repo URL> -b master -b upstream
which will only fetch the master and upstream branch.
I know I can use git remote to do this, but it is a bit clumsy
when starting a new repo.
What do you think?
Jocke
^ permalink raw reply
* Re: git stash clear
From: Eric Davis @ 2007-10-10 18:17 UTC (permalink / raw)
To: git
In-Reply-To: <feivdo$sgi$1@sea.gmane.org>
Disregard, It was user error. Sorry.
Thanks,
Eric
^ permalink raw reply
* git stash clear
From: Eric Davis @ 2007-10-10 16:42 UTC (permalink / raw)
To: git
Hey Everyone,
I have a problem that happened when using git stash.
I was working on a branch and applied a stash to it. There were no
conflicts. I figured I was done with the stuff in stash, so I did a git
stash clear. Not good. It also reverted my branch to before I did the
stash apply and now I have none of the changes because the stash is also
gone. Is this by design? If so, why?
Is there anyway to get this stash back?
Thanks,
Eric
^ permalink raw reply
* Re: [PATCH v2] mergetool: support setting path to tool as config var mergetool.<tool>.path
From: Steffen Prohaska @ 2007-10-10 17:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: tytso, frank, git
In-Reply-To: <Pine.LNX.4.64.0710101759080.4174@racer.site>
On Oct 10, 2007, at 7:03 PM, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 10 Oct 2007, Steffen Prohaska wrote:
>
>> On Oct 10, 2007, at 4:33 PM, Johannes Schindelin wrote:
>>
>>> On Tue, 9 Oct 2007, Steffen Prohaska wrote:
>>>
>>>> This commit adds a mechanism to provide absolute paths to the
>>>> external programs called by 'git mergetool'. A path can be
>>>> specified
>>>> in the configuation variable mergetool.<tool>.path. The
>>>> configuration variable is similar to how we name branches and
>>>> remotes. It is extensible if we need to specify more details
>>>> about a
>>>> tool.
>>>
>>> Okay, let's step back a bit.
>>>
>>> What does mergetool do? It calls different merge helpers, each
>>> with its
>>> own convention how to call it. For example, tkdiff is called
>>> either as
>>>
>>> tkdiff -a "$BASE" -o "$path" -- "$LOCAL" "$REMOTE"
>>>
>>> or as
>>>
>>> tkdiff -o "$path" -- "$LOCAL" "$REMOTE"
>>>
>>> depending if there is a base or not. Another example is gvimdiff:
>>>
>>> gvimdiff -f -- "$LOCAL" "$path" "$REMOTE"
>>>
>>> which seems not to care if there is a base.
>>>
>>> Now, would it not be much better if we had a way to specify the tool
>>> and the convention indepentently? Like
>>>
>>> merge.tkdiff.path = C:\bla\blub\wish.exe C:\blub\bleh\tkdiff.tcl
>>> merge.tkdiff.options = -o %p -- %l %r
>>> merge.tkdiff.optionsWithBase = -a %b -o %p -- %l %r
>>>
>>> and have defaults for the tools we have in git-mergetool.sh
>>> _already_?
>>
>> If you provide a generic mechanism to call an external tool,
>> there's no
>> need to name the tool. A single mechanism (let's call it external)
>> would
>> be sufficient, like
>>
>> mergetool.external.path = c:\any\path\merge.exe
>> mergetool.external.arg2way = %l %r --merge2 --to=%p
>> mergetool.external.arg3way = %b %l %r --merge3 --to=%p
>>
>> But this places the burdon on the user to figure out the command
>> line syntax
>> and specify it correctly using git-config.
>
> Guess why I did not want to have a single mechanism. I did _not_
> propose
> to place the burden on the user to figure out the command line.
>
> Besides, I do not want to do away with the automatic detection of the
> tool, which _implies_ having a list of defaults for the command line
> syntax, which in turn _commands_ having the name instead of
> "external".
>
> While your solution is an obvious short term fix, I maintain that my
> proposal is the Right Thing in the long run.
I did not intend to replace everything with an external mechanism.
What I
wanted to say is the following: If you add a generic mechanism in
addition
to the known tools it is sufficient to add a single generic mechanism
called 'external'. You could then choose from the list of known tools or
you could choose 'external' and provide everything needed as described
above.
Steffen
^ permalink raw reply
* Re: [PATCH] git-cvsserver: added support for update -p
From: Jan Wielemaker @ 2007-10-10 17:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jan Wielemaker, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0710101740400.4174@racer.site>
> On Wed, 10 Oct 2007, Jan Wielemaker wrote:
> > Is there a test suite for git-cvsserver?
>
> Yes: t/t9400-git-cvsserver-server.sh
Thanks. B.t.w. from the main directory:
gollem (git) 21_> make check
for i in *.c; do
sparse -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DETC_GITCONFIG='"/home/jan/etc/gitconfig"' -DNO_STRLCPY -D__BIG_ENDIAN__ -D__powerpc__
$i || exit; done
/bin/sh: sparse: command not found
make: *** [check] Error 127
Dunno, but maybe something like this is more appropriate:
echo "See t/README for testing GIT"
Cheers --- Jan
P.s. My modified version passes all tests.
^ permalink raw reply
* Re: Adding color to git-add--interactive
From: Jeff King @ 2007-10-10 17:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jonathan del Strother, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0710101604350.4174@racer.site>
On Wed, Oct 10, 2007 at 04:06:09PM +0100, Johannes Schindelin wrote:
> I think the reason git-add--interactive does not use it is that some
> people (me included) experienced heavy problems with perl modules.
> However, I do not recall to which extent they have been solved. I guess
> when git-add--interactive goes Git.pm and stops working for me, I'll do my
> famous "aargh, I'll just make it a builtin" song.
I had thought this was the case, too (and in fact, I started to write
"we don't have a good solution for sharing perl code"), but it looks
like git-remote, git-svn, and git-send-email are all using Git.pm these
days.
-Peff
^ permalink raw reply
* Re: [PATCH v2] mergetool: support setting path to tool as config var mergetool.<tool>.path
From: Johannes Schindelin @ 2007-10-10 17:03 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: tytso, frank, git
In-Reply-To: <FBE79360-4B3A-4C92-B8AA-76989D933009@zib.de>
Hi,
On Wed, 10 Oct 2007, Steffen Prohaska wrote:
> On Oct 10, 2007, at 4:33 PM, Johannes Schindelin wrote:
>
> > On Tue, 9 Oct 2007, Steffen Prohaska wrote:
> >
> > > This commit adds a mechanism to provide absolute paths to the
> > > external programs called by 'git mergetool'. A path can be specified
> > > in the configuation variable mergetool.<tool>.path. The
> > > configuration variable is similar to how we name branches and
> > > remotes. It is extensible if we need to specify more details about a
> > > tool.
> >
> > Okay, let's step back a bit.
> >
> > What does mergetool do? It calls different merge helpers, each with its
> > own convention how to call it. For example, tkdiff is called either as
> >
> > tkdiff -a "$BASE" -o "$path" -- "$LOCAL" "$REMOTE"
> >
> > or as
> >
> > tkdiff -o "$path" -- "$LOCAL" "$REMOTE"
> >
> > depending if there is a base or not. Another example is gvimdiff:
> >
> > gvimdiff -f -- "$LOCAL" "$path" "$REMOTE"
> >
> > which seems not to care if there is a base.
> >
> > Now, would it not be much better if we had a way to specify the tool
> > and the convention indepentently? Like
> >
> > merge.tkdiff.path = C:\bla\blub\wish.exe C:\blub\bleh\tkdiff.tcl
> > merge.tkdiff.options = -o %p -- %l %r
> > merge.tkdiff.optionsWithBase = -a %b -o %p -- %l %r
> >
> > and have defaults for the tools we have in git-mergetool.sh _already_?
>
> If you provide a generic mechanism to call an external tool, there's no
> need to name the tool. A single mechanism (let's call it external) would
> be sufficient, like
>
> mergetool.external.path = c:\any\path\merge.exe
> mergetool.external.arg2way = %l %r --merge2 --to=%p
> mergetool.external.arg3way = %b %l %r --merge3 --to=%p
>
> But this places the burdon on the user to figure out the command line syntax
> and specify it correctly using git-config.
Guess why I did not want to have a single mechanism. I did _not_ propose
to place the burden on the user to figure out the command line.
Besides, I do not want to do away with the automatic detection of the
tool, which _implies_ having a list of defaults for the command line
syntax, which in turn _commands_ having the name instead of "external".
While your solution is an obvious short term fix, I maintain that my
proposal is the Right Thing in the long run.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-cvsserver: added support for update -p
From: Johannes Schindelin @ 2007-10-10 16:41 UTC (permalink / raw)
To: Jan Wielemaker; +Cc: Git Mailing List
In-Reply-To: <200710101626.53303.jan@swi-prolog.org>
Hi,
On Wed, 10 Oct 2007, Jan Wielemaker wrote:
> Is there a test suite for git-cvsserver?
Yes: t/t9400-git-cvsserver-server.sh
Hth,
Dscho
^ permalink raw reply
* Re: git-rev-parse --verify could be friendlier
From: Matthieu Moy @ 2007-10-10 16:37 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20071010142417.8892.qmail@science.horizon.com>
linux@horizon.com writes:
> Something like the following would certainly help, but perhaps git-rev-parse
> could be slightly more forthcoming, too?
I think this should be fixed in git-rev-parse itself, yes.
Following is an attempt to make the message better. It still has at
least the following problems (which are already in today's git):
* Duplicate error message when the revision is ambiguous.
* No distinction between syntactically incorrect revisions
(impossible~branchname for example), and inexisting revision
(a34b6c, if there's no such revision).
What would be really cool is to extend this to have a fine-granularity
error number returned by get_sha1 and friends.
>From f033ba755e6bc46dcd0f5767699458bacb840587 Mon Sep 17 00:00:00 2001
From: Matthieu Moy <Matthieu.Moy@imag.fr>
Date: Wed, 10 Oct 2007 18:15:39 +0200
Subject: [PATCH] Better error message for git-rev-parse.
The existing error message is "Needed a single revision", which is
inacurate if the revision provided is syntactically incorrect or
inexistant.
---
builtin-rev-parse.c | 20 ++++++++++++++++----
cache.h | 3 +++
sha1_name.c | 5 +----
3 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/builtin-rev-parse.c b/builtin-rev-parse.c
index 8d78b69..d2145f1 100644
--- a/builtin-rev-parse.c
+++ b/builtin-rev-parse.c
@@ -213,6 +213,8 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
{
int i, as_is = 0, verify = 0;
unsigned char sha1[20];
+ const char *error_param;
+ int err_no = 0;
git_config(git_default_config);
@@ -249,6 +251,7 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
}
if (!strcmp(arg, "--default")) {
def = argv[i+1];
+ error_param = def;
i++;
continue;
}
@@ -390,16 +393,20 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
continue;
}
+ error_param = arg;
/* Not a flag argument */
if (try_difference(arg))
continue;
- if (!get_sha1(arg, sha1)) {
+ if (!(err_no = get_sha1(arg, sha1))) {
show_rev(NORMAL, sha1, arg);
continue;
}
- if (*arg == '^' && !get_sha1(arg+1, sha1)) {
- show_rev(REVERSED, sha1, arg+1);
- continue;
+ if (*arg == '^') {
+ error_param = arg+1;
+ if (!(err_no = get_sha1(arg+1, sha1))) {
+ show_rev(REVERSED, sha1, arg+1);
+ continue;
+ }
}
as_is = 1;
if (!show_file(arg))
@@ -409,6 +416,11 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
verify_filename(prefix, arg);
}
show_default();
+ if (verify && revs_count == 0)
+ if (err_no == SHORT_NAME_AMBIGUOUS)
+ die("%s: Ambiguous revision", error_param);
+ else
+ die("%s: No such revision", error_param);
if (verify && revs_count != 1)
die("Needed a single revision");
return 0;
diff --git a/cache.h b/cache.h
index e0abcd6..a537afa 100644
--- a/cache.h
+++ b/cache.h
@@ -399,6 +399,9 @@ static inline unsigned int hexval(unsigned char c)
#define MINIMUM_ABBREV 4
#define DEFAULT_ABBREV 7
+#define SHORT_NAME_NOT_FOUND (-1)
+#define SHORT_NAME_AMBIGUOUS (-2)
+
extern int get_sha1(const char *str, unsigned char *sha1);
extern int get_sha1_with_mode(const char *str, unsigned char *sha1, unsigned *mode);
extern int get_sha1_hex(const char *hex, unsigned char *sha1);
diff --git a/sha1_name.c b/sha1_name.c
index 2d727d5..5091420 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -127,9 +127,6 @@ static int find_short_packed_object(int len, const unsigned char *match, unsigne
return found;
}
-#define SHORT_NAME_NOT_FOUND (-1)
-#define SHORT_NAME_AMBIGUOUS (-2)
-
static int find_unique_short_object(int len, char *canonical,
unsigned char *res, unsigned char *sha1)
{
@@ -186,7 +183,7 @@ static int get_short_sha1(const char *name, int len, unsigned char *sha1,
status = find_unique_short_object(i, canonical, res, sha1);
if (!quietly && (status == SHORT_NAME_AMBIGUOUS))
- return error("short SHA1 %.*s is ambiguous.", len, canonical);
+ error("short SHA1 %.*s is ambiguous.", len, canonical);
return status;
}
--
1.5.3.4.205.g52b6c
--
Matthieu
^ permalink raw reply related
* Re: [PATCH v2] git-gui: add mingw specific startup wrapper
From: Steffen Prohaska @ 2007-10-10 16:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, Git Mailing List, msysGit
In-Reply-To: <Pine.LNX.4.64.0710101653400.4174@racer.site>
On Oct 10, 2007, at 5:56 PM, Johannes Schindelin wrote:
> On Wed, 10 Oct 2007, Steffen Prohaska wrote:
>
>> The wrapper adds the directory it is installed in to PATH.
>> This is required for the git commands implemented in shell.
>> git-gui fails to launch them if PATH is not modified.
>>
>> The wrapper script also accepts an optional command line
>> switch '--working-dir <dir>' and changes to <dir> before
>> launching the actual git-gui. This is required to implement
>> the "Git Gui Here" Explorer shell extension.
>
> It should be mentioned here that the Explorer shell extension you talk
> about is the very simple extension provided by the Inno Installer.
Yes, but it's already there. And Shawn even finds --working-dir
interesting
as a general feature.
> I have a much larger and versatile shell extension in mind: git-
> cheetah.
> And fixing it is probably trivial; it can both change directory to the
> current directory (sounds wrong, doesn't it?) and extend the PATH
> appropriately before calling git-gui.
I know, but it's not yet there.
> Note: the latter is not even necessary once we (correctly) add git
> to the
> PATH in the installer.
(wrongly ;) Adding git to the PATH will only become an option. git-gui
should also work if it's not added.
I comment on the PATH question in reply to another mail.
Steffen
^ permalink raw reply
* Re: [PATCH 1/4] git-gui i18n: Add more words to glossary.
From: Johannes Schindelin @ 2007-10-10 16:01 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Christian Stimming, git
In-Reply-To: <20071010060328.GO2137@spearce.org>
Hi,
On Wed, 10 Oct 2007, Shawn O. Pearce wrote:
> The i18n fork as it currently stands is pretty far away from my own
> tree; it probably should be reset to my tree in the near future.
Yep. Sorry. Will do in a few moments.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] git-gui: set NO_MSGFMT to force using pure tcl replacement in msysgit
From: Steffen Prohaska @ 2007-10-10 15:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: spearce, git
In-Reply-To: <Pine.LNX.4.64.0710101651360.4174@racer.site>
On Oct 10, 2007, at 5:52 PM, Johannes Schindelin wrote:
> On Wed, 10 Oct 2007, Steffen Prohaska wrote:
>
>> Shawn's git-gui Makefile supports the pure tcl replacement for
>> msgfmt if
>> setting NO_MSGFMT. This patch sets the NO_MSGFMT for msysgit.
>
> Would it not be cleaner to set this in 4msysgit and export it?
What does "set this in 4msysgit" mean?
Would running 'make' in /git/git-gui/ be supported by your solution?
Steffen
^ permalink raw reply
* Re: [PATCH v2] git-gui: add mingw specific startup wrapper
From: Johannes Schindelin @ 2007-10-10 15:56 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: spearce, git, msysgit
In-Reply-To: <11919995392881-git-send-email-prohaska@zib.de>
Hi,
On Wed, 10 Oct 2007, Steffen Prohaska wrote:
> The wrapper adds the directory it is installed in to PATH.
> This is required for the git commands implemented in shell.
> git-gui fails to launch them if PATH is not modified.
>
> The wrapper script also accepts an optional command line
> switch '--working-dir <dir>' and changes to <dir> before
> launching the actual git-gui. This is required to implement
> the "Git Gui Here" Explorer shell extension.
It should be mentioned here that the Explorer shell extension you talk
about is the very simple extension provided by the Inno Installer.
I have a much larger and versatile shell extension in mind: git-cheetah.
And fixing it is probably trivial; it can both change directory to the
current directory (sounds wrong, doesn't it?) and extend the PATH
appropriately before calling git-gui.
Note: the latter is not even necessary once we (correctly) add git to the
PATH in the installer.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] git-gui: set NO_MSGFMT to force using pure tcl replacement in msysgit
From: Johannes Schindelin @ 2007-10-10 15:52 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: spearce, git
In-Reply-To: <11919995392158-git-send-email-prohaska@zib.de>
Hi,
On Wed, 10 Oct 2007, Steffen Prohaska wrote:
> Shawn's git-gui Makefile supports the pure tcl replacement for msgfmt if
> setting NO_MSGFMT. This patch sets the NO_MSGFMT for msysgit.
Would it not be cleaner to set this in 4msysgit and export it?
Ciao,
Dscho
^ permalink raw reply
* Re: inexplicable failure to merge recursively across cherry-picks
From: David Brown @ 2007-10-10 15:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: martin f krafft, git discussion list
In-Reply-To: <alpine.LFD.0.999.0710100808150.3838@woody.linux-foundation.org>
On Wed, Oct 10, 2007 at 08:25:15AM -0700, Linus Torvalds wrote:
>Yes, *some* SCM's have tried to do that. In particular, the ones that are
>"patch-based" tend to think that patches are "identical" regardless of
>where they are, and while re-ordering of them is a special event, it's not
>somethign that changes the fundamental 'ID' of the patch.
>
>For example, I think the darcs "patch algebra" works that way.
>
>It's a really horrible model. Not only doesn't it scale, but it leads to
>various very strange linkages between patches, and it fails the most
>important part: it means that merges get different results just because
>people are doing the same changes two different ways.
Actually, specifically darcs, different merges _always_ result in the same
data. It's a fundamental part of is patch algebra. No matter what order
you apply a given set of patches, even with conflicts and reordering, you
always get the same result, or no result. Conflicts are "resolved" by
inserting conflict markers in the file, ordered by the patch ID. It
doesn't matter which order you apply them in, you get the same markers.
Then there will be a merge patch which fixes the markers that someone could
apply, no matter what order the applied the previous patches.
Darcs breaks down in a few places, though.
- The no result. Sometimes, it just can't figure out how to reorder
patches. Even worse, occasionally, the implementation will fail to
terminate try to figure this out. There isn't much to do at this
point, except manually apply the patch, hence generating a new patch
ID.
- It doesn't scale well.
The strange linkages between patches could be thought of as a feature,
since it is basically constraining the order that the patches can be
applied in.
There is a darcs-git project that tries to do the darcs things on top of
git.
Dave
^ permalink raw reply
* Re: [msysGit] Re: [PATCH] git-gui: offer a list of recent repositories on startup
From: Johannes Schindelin @ 2007-10-10 15:43 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Steffen Prohaska, Git Mailing List, msysGit
In-Reply-To: <20071010044030.GJ2137@spearce.org>
Hi,
On Wed, 10 Oct 2007, Shawn O. Pearce wrote:
> Steffen Prohaska <prohaska@zib.de> wrote:
> > On Oct 9, 2007, at 1:43 PM, Johannes Schindelin wrote:
> > >On Mon, 8 Oct 2007, Steffen Prohaska wrote:
> > >
> > >>commit a483fdd562d6c44d68a998224e0bbb17933b624a
> > >>Author: Steffen Prohaska <prohaska@zib.de>
> > >>Date: Mon Oct 8 08:25:47 2007 +0200
> > >>
> > >> git-gui: offer a list of recent repositories on startup
> > >
> > >May I suggest not putting this list into ~/.gitconfig, but rather
> > >~/.gitguirc? It is not really a user-specific git configuration...
> >
> > git-gui already stores other options as global variables gui.*.
> > (see git-gui/lib/option.tcl). I just added gui.recentrepo. The
> > list of recent repos should go to wherever git-gui stores its options.
> >
> > Right now this is in ~/.gitconfig, if I understand correctly. Shawn?
>
> Yes, that's correct.
>
> An item on my todo list (see todo branch in git-gui.git) is to move
> this into a ~/.gitguiconfig or something like that, but I was going
> to keep it as a git-config style file so git-config can be used to
> process its contents.
>
> Until that task is complete I'd rather keep all of the "gui" options
> in ~/.gitconfig (global) or .git/config (per-repository). When I
> split stuff out to git-gui specific files I'll have to migrate the
> entire "gui" section at once.
FWIW I was only concerned about the recent repos, since strictly speaking,
they are not options to git-gui... But I do not care deeply.
Ciao,
Dscho
^ 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