* 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
* Re: [PATCH v2] mergetool: support setting path to tool as config var mergetool.<tool>.path
From: Steffen Prohaska @ 2007-10-10 15:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: tytso, frank, git
In-Reply-To: <Pine.LNX.4.64.0710101526060.4174@racer.site>
On Oct 10, 2007, at 4:33 PM, Johannes Schindelin wrote:
> Hi,
>
> 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. Things like proper
escaping may
be a hassel.
The solution I'm proposing is more user-friendly. Only the information
that is hard to figure out automatically and is easy to provide by the
user is asked for. The user only needs to tell the path to the
executable.
git-mergetool 'knows' about the correct command line syntax. There's
no need
to ask the user. The command line syntax is fixed and know. No option
here.
"git mergetool" could, for example, know that a certain tool just
doesn't
support 3-way.
And the code of git-mergetool is also quite easy. The only input
validation
that is needed is to check if mergetool.<tool>.path points to a valid
executable. If we provide a complex syntax for specifying command line
options we may have to do a lot more of input validation and processing.
I strongly favor my solution of including the command line syntax in
git-mergetool, and only ask the user for the path. I'm not against a
generic
mechanism to configure any tool. However, I do not plan to implement it.
If someone plans to develop a generic mechanism I see two options:
1) What's explained above.
2) _Define_ the parameters passed to the external command and ask the
user
to write a wrapper script to call his tool of choice. Similar to
what
GIT_EXTERNAL_DIFF does. Wrapper scripts would go to contrib/.
Both solutions would require more work from the user than needed.
Steffen
^ permalink raw reply
* Re: inexplicable failure to merge recursively across cherry-picks
From: Linus Torvalds @ 2007-10-10 15:25 UTC (permalink / raw)
To: martin f krafft; +Cc: git discussion list
In-Reply-To: <20071010102528.GB20390@lapse.madduck.net>
On Wed, 10 Oct 2007, martin f krafft wrote:
> also sprach Linus Torvalds <torvalds@linux-foundation.org> [2007.10.10.0354 +0100]:
> > Cherry-picking is immaterial. It doesn't matter how the changes
> > come into the tree. It doesn't matter what the history is. The
> > only thing git cares about is the content, and the end result.
>
> This is the part I over-estimated. I thought that Git would figure
> out that commits 1-3 had been merged into the target and thus apply,
> in sequence, only the commits from the source which had not been
> merged.
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.
> Many thanks (again), Linus! Looking forward to your next content
> manager; you know, the one with artificial intelligence built in!
> You could call it "wit" :)
Well, the git model is really largely the reverse: the system is supposed
to be as *stupid* as humanly possible, but:
- make it predictable exactly because it's stupid and doesn't do anything
even half-ways smart.
This is part of the "it doesn't matter *how* you got to a particular
state, git will always do the same thing regardless of whether you
moved an existing patch around or whether you re-did the changes as
(possibly more than one) new and unrelated commits".
- conflicts aren't bad - they're *good*. Trying to aggressively resolve
them automatically when two branches have done slightly different
things in the same area is stupid and just results in more problems.
Instead, git tries to do what I don't think *anybody* else has done:
make the conflicts easy to resolve, by allowing you to work with them
in your normal working tree, and still giving you a lot of tools to
help you see what's going on.
So git doesn't try to avoid conflicts per se: the merge strategies are
fundamentally pretty simple (rename detection and the whole "recursive
merge" thing may not be simple code, but the concepts are pretty
straightforward), and they handle all the really *obvious* cases, but at
the same time, I feel strongly that anything even half-way subtle should
not be left to the SCM - the SCM should show it and make it really easy
for the user to then fix it up.
Side note: even with a totally obvious three-way merge, with absolutely
zero conflicts even remotely close to each other, you can have the merge
algorithm generate a good merge that doesn't actually *work*.
For example, it's happened a few times that one branch renames a structure
member name (and changes all the uses) and another branch adds new code
that uses the old member name. The end result: the code will *merge* fine,
and there are zero conflicts in the content, because all the changes were
totally disjoint, but the end result doesn't actually work or even
compile!
So no merge strategy is ever perfect. The git approach is to be simple and
predictable, and also to make it easy to fix up (ie even if you get the
above kind of automatic merge problem, if you catch it in compiling, you
can fix it up, and do a "git commit --amend" to fix up the merge itself
before you push it out).
Linus
^ permalink raw reply
* Re: [PATCH] git-gui: update Italian translation
From: Paolo Ciarrocchi @ 2007-10-10 15:16 UTC (permalink / raw)
To: Michele Ballabio; +Cc: git, Shawn O. Pearce, Johannes Schindelin
In-Reply-To: <200710101658.32229.barra_cuda@katamail.com>
On 10/10/07, Michele Ballabio <barra_cuda@katamail.com> wrote:
> On Wednesday 10 October 2007, Paolo Ciarrocchi wrote:
> > In short, I'm still think we should leave the word untranslated.
> >
> > How about posting the new file to ltp and move there the discussion?
>
> Uhm. What about "nuova revisione"/"creare una nuova revisione"? Otherwise,
> I'll select some strings and post them there.
I like "nuova revisione".
Ciao,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
^ permalink raw reply
* Re: Adding color to git-add--interactive
From: Johannes Schindelin @ 2007-10-10 15:06 UTC (permalink / raw)
To: Jeff King; +Cc: Jonathan del Strother, Git Mailing List
In-Reply-To: <20071009234020.GA20952@coredump.intra.peff.net>
Hi,
On Tue, 9 Oct 2007, Jeff King wrote:
> On Tue, Oct 09, 2007 at 02:06:31PM +0100, Jonathan del Strother wrote:
>
> > For me at least, adding color would make the interactive mode far more
> > readable. I hacked in basic color support (just coloring PROMPT &
> > HEADER in list_and_choose, and the "Stage this hunk?" prompt) - which
> > helped a lot - but then reached the limits of my perl knowledge. For
> > instance, I can't see a sensible way of reusing git-svn's
> > log_use_color function without importing the entire file, and I can't
> > figure out how you'd go about diff-coloring the hunks. Is anyone with
> > more perl knowledge than me interested in taking this on?
>
> Why don't you post what you have, and we can make comments on it?
>
> As far as reusing code from git-svn, there is a 'Git.pm' module in the
> perl/ subdirectory. You can move the code there and 'use Git' in
> git-add--interactive.perl (git-svn already uses it).
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.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-gui: update Italian translation
From: Michele Ballabio @ 2007-10-10 14:58 UTC (permalink / raw)
To: git; +Cc: Paolo Ciarrocchi, Shawn O. Pearce, Johannes Schindelin
In-Reply-To: <4d8e3fd30710100722m650d4bb0yf76869ae6f8944df@mail.gmail.com>
On Wednesday 10 October 2007, Paolo Ciarrocchi wrote:
> In short, I'm still think we should leave the word untranslated.
>
> How about posting the new file to ltp and move there the discussion?
Uhm. What about "nuova revisione"/"creare una nuova revisione"? Otherwise,
I'll select some strings and post them there.
^ permalink raw reply
* Re: removing content from git history
From: Johannes Schindelin @ 2007-10-10 14:41 UTC (permalink / raw)
To: Bill Lear
Cc: Shawn O. Pearce, Linus Torvalds, J. Bruce Fields,
Michael Hendricks, git
In-Reply-To: <18187.60305.613904.547916@lisa.zopyra.com>
Hi,
On Tue, 9 Oct 2007, Bill Lear wrote:
> Our company has content in our central git repository that we need to
> remove per a contractual obligation. I believe the content in question
> is limited to one sub-directory, that has existed since (or near to) the
> beginning of the repo, if that matters. We obviously would just like to
> issue a "git nuke" operation and be done with it, if that is available.
> Barring that, we could probably follow reasonably simple steps to purge
> the content and rebuild the repo.
>
> So, what options do we have at present?
git filter-branch. I suggest using the index filter. There is even a
nice example in the man page of git filter-branch.
Which reminds me that I have some TODOs left in filter-branch...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] mergetool: support setting path to tool as config var mergetool.<tool>.path
From: Johannes Schindelin @ 2007-10-10 14:33 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: tytso, frank, git
In-Reply-To: <11919632613176-git-send-email-prohaska@zib.de>
Hi,
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_?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-cvsserver: added support for update -p
From: Jan Wielemaker @ 2007-10-10 14:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0710101442571.4174@racer.site>
On Wednesday 10 October 2007 15:47, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 10 Oct 2007, Jan Wielemaker wrote:
> > [PATCH] git-cvsserver: added support for update -p
> > ---
>
> Proposed alternative for the commit message:
>
> -- snip --
> The cvs subcommand "update -p <file>" is frequently used to see the
> contents of a given file in HEAD, sort of our "git show <file>". It
> is not that hard to support it, so here it is.
>
> Commit-message-proposed-by: Johannes Schindelin <johannes.schindelin.de>
> Signed-off-by: Jan Wielemaker <jan@swi-prolog.org>
> -- snap --
Ok. I'm still a guy of ChangeLog files, which you generally needed for
CVS to keep track of a large project :-) As the CVS commit message
aren't much good anyway, I kept them short. Also for my own project I'm
considering to replace these with larger commit messages and drop the
ChangeLog files.
> P.S.: Have not reviewed the patch at all, so cannot say anything about the
> merits of it; will leave it to djpig ;-)
Don't trust my Perl; its just copy and intelligent(-ish) paste :-) Works
for me though and this isn't very complicated. Is there a test suite for
git-cvsserver?
Cheers --- Jan
^ permalink raw reply
* Suggestions for improvements to post-receive hook
From: Bill Lear @ 2007-10-10 14:32 UTC (permalink / raw)
To: git; +Cc: Andy Parkins
We have made a few changes to the post-receive hook for operation in
our company. I wanted to pass them on in case they are suitable for
more general use. Below I mix description of the change, a
justification of the change, along with a snippet of code and/or code
comments illustrating the change. I'm sure there are more
sophisticated ways to do what we've done, but it seems to work for us.
1. Support per-branch mailing lists. This allows me to collaborate
with several different people on different mini-projects from the
same "hub" repository without each of them getting mail they don't
care about.
Code:
# hooks.{branch}mailinglist
# This is the list that all pushes to a given branch will go to;
# leave it blank to not send emails for every ref update to this branch.
[...]
if [ -z "$recipients" ]; then
# Essentially an associative array,
# hooks.${short_refname}mailinglist: allows a separate mailing
# list for each branch/tag thingie.
recipients=$(git-repo-config hooks.${short_refname}mailinglist)
fi
# One last try ...
if [ -z "$recipients" ]; then
recipients=$(git repo-config hooks.mailinglist)
fi
# Check if we've got anyone to send to
if [ -z "$recipients" ]; then
echo >&2 "*** hooks.recipients is not set so no email will be sent"
echo >&2 "*** for $refname update $oldrev->$newrev"
exit 0
fi
2. Allow specification of a prefix for the subject line. This allows
us to better filter our email --- we use a mailing list for some
projects and the mailing list prefixes the subject with its own
string, for example.
Code:
# hooks.prefix
# Set the email subject prefix to "[$hooks.prefix]". Defaults to empty string.
[...]
# Notes
# -----
# All emails have their subjects prefixed with "[$hooks.prefix]"
# to aid filtering, if hooks.prefix is set. If it is not set, no
# prefix is used.
[...]
prefix=$(git-repo-config hooks.prefix)
if [ -n "$prefix" ]; then
EMAILPREFIX="[${prefix}] "
else
EMAILPREFIX=""
fi
[... elsewhere in the code]
generate_email_header()
{
# --- Email (all stdout will be the email)
# Generate header
cat <<-EOF
From: $committer
To: $recipients
Subject: ${EMAILPREFIX}$projectdesc $refname_type "$short_refname" ${change_type}d. $describe
X-Git-Refname: $refname
X-Git-Reftype: $refname_type
[...]
3. Provide change content in email. The current hook does not produce
enough information for us --- we like to see the content of the change
so we can code-review on-the-fly. I hacked the code, in my ignorance,
to use git-whatchanged, as it seemed to provide what we wanted. I
am not currently controlling this behavior with a config flag, though
presumably it could be, easily.
Code (simple diff):
408,411c399,400
< echo "Diffstat:"
< git-diff-tree --no-color --stat -M -C --find-copies-harder $newrev ^$oldrev
< echo ""
< git-whatchanged --no-color -p --find-copies-harder $oldrev..$newrev
---
> echo "Summary of changes:"
> git diff-tree --stat --summary --find-copies-harder $oldrev..$newrev
4 and 5.
4: Log the content of the emails, if desired, to a log file.
Our email archiving system here is between lame and nonexistent,
so we like to be able to look back at the logs if a problem should
occur.
5: Allow sending only a certain number of lines maximum to email
recipients. Some diffs are huge, so we don't want to overwhelm
recipients' inboxes.
Note: currently, specifying the maximum number of email lines
only works when you specify logging, though this is not necessary.
Also: this might only be useful if you have a flag that controls
the use of git-whatchanged (or whatever) to produce a fuller diff
set in the email.
Code:
# hooks.maxemaillines
# Clip the email sent out to this number of lines. If unset,
# defaults to 500 lines.
[...]
# hooks.logfile
# If set then the entire email content sent will be logged to this file.
# If unset, no logging is done.
[...]
maxemaillines=$(git-repo-config --int hooks.maxemaillines)
logfile=$(git-repo-config hooks.logfile)
[...]
# If a log file was specified, tee to the logfile, head, and then
# sendmail, else just send the mail directly.
if [ -n "$logfile" ]; then
while read oldrev newrev refname
do
generate_email $oldrev $newrev $refname |
/usr/bin/tee -a ${logfile} 2>/dev/null |
/usr/bin/head -${maxemaillines} |
/usr/sbin/sendmail -t $envelopesender
done
else
while read oldrev newrev refname
do
generate_email $oldrev $newrev $refname |
/usr/sbin/sendmail -t $envelopesender
done
fi
6. Support an author filter. I don't have this running currently,
but I believe this feature was in the update script. Basically
(and here follows most likely confusion on my part) it allows you
to filter your changes out of a change set so that when you
push a change set that includes your changes to a hub, it only
sends them once (here, I'm most certainly not expressing this
correctly).
Anyway, someone on the list suggested this, and it was in
the update hook, like this:
authorfilter=$(git-repo-config hooks.authorfilter)
case "$refname_type" in
"tracking branch"|branch)
if expr "$oldrev" : '0*$' >/dev/null
then
# If the old reference is "0000..0000" then this is a new branch
# and so oldrev is not valid
echo " as a new $refname_type"
echo " to $newrev ($newrev_type)"
echo ""
# This shows all log entries that are not already covered by
# another ref - i.e. commits that are now accessible from this
# ref that were previously not accessible
git-whatchanged -p ${authorfilter:+--author="$authorfilter"} --pretty $newref $(git-rev-parse --not --all)
else
# oldrev is valid
oldrev_type=$(git-cat-file -t "$oldrev")
# Now the problem is for cases like this:
# * --- * --- * --- * (oldrev)
# \
# * --- * --- * (newrev)
# i.e. there is no guarantee that newrev is a strict subset
# of oldrev - (would have required a force, but that's allowed).
# So, we can't simply say rev-list $oldrev..$newrev. Instead
# we find the common base of the two revs and list from there
baserev=$(git-merge-base $oldrev $newrev)
# Commit with a parent
for rev in $(git-rev-list ${authorfilter:+--author="$authorfilter"} $newrev ^$baserev)
do
revtype=$(git-cat-file -t "$rev")
echo " via $rev ($revtype)"
done
if [ "$baserev" = "$oldrev" ]; then
echo " from $oldrev ($oldrev_type)"
else
echo " based on $baserev"
echo " from $oldrev ($oldrev_type)"
echo ""
echo "This ref update crossed a branch point; i.e. the old rev is not a strict subset"
echo "of the new rev. This occurs, when you --force push a change in a situation"
echo "like this:"
echo ""
echo " * -- * -- B -- O -- O -- O ($oldrev)"
echo " \\"
echo " N -- N -- N ($newrev)"
echo ""
echo "Therefore, we assume that you've already had alert emails for all of the O"
echo "revisions, and now give you all the revisions in the N branch from the common"
echo "base, B ($baserev), up to the new revision."
fi
echo ""
echo "Diffstat:"
git-diff-tree --no-color --stat -M -C --find-copies-harder $newrev ^$baserev
echo ""
git-whatchanged -p ${authorfilter:+--author="$authorfilter"} --pretty $newrev ^$baserev
fi
;;
"annotated tag")
Ok, I think that's about it. Andy, let me know if I can help
clarify anything.
Bill
^ permalink raw reply
* git-rev-parse --verify could be friendlier
From: linux @ 2007-10-10 14:24 UTC (permalink / raw)
To: git; +Cc: linux
I accidentally typed "git rebase --onto typo ancestor", where "typo"
was a branch that didn't exist.
The error message (which is actually generated by git-rev-parse --verify)
is "fatal: Needed a single revision".
This is perhaps a bit obscure. For starters, it doesn't even tell me
which argument is problematic.
If I do "git rebase --onto dest typo", I at least get
fatal: Needed a single revision
invalid upstream typo
Something like the following would certainly help, but perhaps git-rev-parse
could be slightly more forthcoming, too?
diff --git a/git-rebase b/git-rebase
index 058fcac..b14ac95 100755
--- a/git-rebase
+++ b/git-rebase
@@ -268,7 +268,8 @@ upstream=`git rev-parse --verify "${upstream_name}^0"` ||
# Make sure the branch to rebase onto is valid.
onto_name=${newbase-"$upstream_name"}
-onto=$(git rev-parse --verify "${onto_name}^0") || exit
+onto=$(git rev-parse --verify "${onto_name}^0") ||
+ die "invalid target $upstream_name"
# If a hook exists, give it a chance to interrupt
if test -x "$GIT_DIR/hooks/pre-rebase"
@@ -294,7 +295,8 @@ case "$#" in
fi
;;
esac
-branch=$(git rev-parse --verify "${branch_name}^0") || exit
+branch=$(git rev-parse --verify "${branch_name}^0") ||
+ die "invalid branch name $upstream_name"
# Now we are rebasing commits $upstream..$branch on top of $onto
^ permalink raw reply related
* Re: [PATCH] git-gui: update Italian translation
From: Paolo Ciarrocchi @ 2007-10-10 14:22 UTC (permalink / raw)
To: Michele Ballabio; +Cc: git, Shawn O. Pearce, Johannes Schindelin
In-Reply-To: <200710101607.55452.barra_cuda@katamail.com>
On 10/10/07, Michele Ballabio <barra_cuda@katamail.com> wrote:
> On Wednesday 10 October 2007, Paolo Ciarrocchi wrote:
> > > #: git-gui.sh:1527
> > > msgid "Modified, not staged"
> > > -msgstr "Modificato, non pronto per il commit"
> > > +msgstr "Modificato, non preparato per l'archiviazione"
> >
> > I vote for leaving the word commit.
> > I would be confused by the word "archiviazione".
>
> Well, yes, most people currently using git will be as well.
> But that's because they're used to it. The thread that talked
> about the German translation decided to look for a fitting
> German word, so I decided to follow them. If you're vetoing
> these changes, I'll redo them. Otherwise, if you don't have
> a strong adverse opinion, I think this translation is quite
> clear, and would leave less people asking
> "What's a commit?". Don't you think?
I understand that we should aim for a complete Italian translation but
"archiviazione" to me sounds like "backup" or "archive". It doesn't
sound like a proper translation.
I discussed this topic on the Linux Translation Project mailing list
and the majority of the people seems to agree on leaving the word
untraslated but I really cannot say that I reached a _real_ agreement.
In short, I'm still think we should leave the word untranslated.
How about posting the new file to ltp and move there the discussion?
Ciao,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
http://ubuntista.blogspot.com
^ 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