* Re: git submodules and commit
From: Petr Baudis @ 2008-07-16 12:11 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Nigel Magnay, Git Mailing List
In-Reply-To: <487DDCFC.9020007@viscovery.net>
On Wed, Jul 16, 2008 at 01:35:24PM +0200, Johannes Sixt wrote:
> Ah, is this your actual scenario? Just to make sure we are talking about
> the same thing:
>
> - You own superproject P.
> - $Maintainer owns submodule S.
> - You use S in P.
> - You make changes to S that you would like $Maintainer to include in the
> next release.
> x You use in P your changes to S while $Maintainer has not yet released a
> new version of S with your changes.
> - Finally your changes arrive via the new release of S.
>
> That *is* the intended use-case for submodules. But you have to play the
> game by the rules:
>
> - $Maintainer defines the official states of S.
>
> - You must never commit an unofficial state of S in P.
I think the issue here is that $Maintainer = him (or Maintainers(P) =
Maintainers(S), in general); the workflow you described still works, but
is overly complicated and that is the original complaint.
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [PATCH 1/2] t/test-lib.sh: Let test_must_fail fail on signals only
From: Stephan Beyer @ 2008-07-16 11:57 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20080716051829.GB4030@segfault.peff.net>
Hi,
Jeff King wrote:
> On Sat, Jul 12, 2008 at 05:47:51PM +0200, Stephan Beyer wrote:
>
> > The test_must_fail function in test-lib.sh has been designed
> > to distinguish segmentation faults from controlled errors.
> > But in the current implementation this only works if a git
> > command does not return a small negative value, like -1, -2
> > or -3. But some git commands do.
>
> This is probably a fine protective measure, and it looks like Junio has
> already applied it. But shouldn't any git commands returning such values
> be fixed?
I didn't want to change any error codes and I wouldn't say that the term
"fix" is the right one here.
> Which commands return such bogus error codes?
Why bogus?
To answer your question, some are:
git diff-files
git diff-index
git diff
git merge-file
I think at least one test case failed "test_must_fail git merge-file ..."
without that change.
Regards.
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH] Fix buffer overflow in git-grep
From: Dmitry Potapov @ 2008-07-16 11:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807161232110.8503@eeepc-johanness>
On Wed, Jul 16, 2008 at 12:35:06PM +0200, Johannes Schindelin wrote:
> >
> > while (tree_entry(tree, &entry)) {
> > - strcpy(path_buf + len, entry.path);
> > + int te_len = tree_entry_len(entry.path, entry.sha1);
> > + if (len + te_len >= PATH_MAX + tn_len)
> > + die ("path too long: %s", path_buf+tn_len);
> > + memcpy(path_buf + len, entry.path, te_len);
>
> That is brutal. Does grep_tree() not work on tree objects in memory? In
> that case, you prevent the user from grepping, only because she is on a
> suboptimal platform, _even if_ even that platform could cope with it.
Sure, but other git commands do not work much better in this case.
In fact, what you called as "brutal" may be considered as very
polite comparing to what other git commands did.
For instance, git show will show you nothing at all and exit with 0.
The same problem with git whatchanged. The whole history mysteriously
disappeared at that commit, and git whatchanged exited with 0 without
any error or warning... Though git log will show you all history, but
if you run it with -p then it will also exit with zero at this commit
silently like previously history do not exist at all. So, I didn't see
any reason to make git grep to work in the situation where practically
any other git command does not. I guess, they should be corrected too,
but I did not have time to look at them yet.
>
> It's not like the path is ever used to access a file, right?
>
> Maybe you should convert the path_buf to a strbuf instead.
It is probably a good suggestion, but I just wanted to provided a quick
fix to what may be considered as security issue. Of course, you usually
do not grep on untrusted repos, but if you did and something nasty
happened to you. I don't think it will help Git's reputation as being
secure and reliable...
Now the question is whether we really want to fix all Git commands that
do not touch the work tree to work with filenames longer than PATH_MAX?
Dmitry
^ permalink raw reply
* [PATCH] git-cvsserver: fix call to nonexistant cleanupWorkDir()
From: Lars Noschinski @ 2008-07-16 11:35 UTC (permalink / raw)
To: git, gitster; +Cc: fabian.emmes
git-cvsserver.perl contained a single call to a nonexistant function
cleanupWorkDir(). This was obviously a typo for cleanupWorkTree().
Signed-off-by: Lars Noschinski <lars@public.noschinski.de>
---
git-cvsserver.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 920bbe1..b00d1c2 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -1884,7 +1884,7 @@ sub req_annotate
}
# done; get out of the tempdir
- cleanupWorkDir();
+ cleanupWorkTree();
print "ok\n";
--
1.5.5.2
^ permalink raw reply related
* Re: git submodules and commit
From: Johannes Sixt @ 2008-07-16 11:35 UTC (permalink / raw)
To: Nigel Magnay; +Cc: Git Mailing List
In-Reply-To: <320075ff0807160402s7429291ela288b42d99c1ec53@mail.gmail.com>
Nigel Magnay schrieb:
> On Wed, Jul 16, 2008 at 11:47 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>> Nigel Magnay schrieb:
>>> For me, in some really high proportion of cases, I think I want 'git
>>> commit' to mean 'commit to any child repositories, any sibling
>>> repositories, and any parent repositories (updating the submodule sha1
>>> as appropriate). In other words, 'pretend like the whole thing is one
>>> big repo'.
>> And I think that this is the problem: If this way of commiting your
>> changes is *required* in the *majority* of cases, then you are IMO outside
>> the intended use-case of submodules. You are better served by really
>> making this one big repo.
>>
>
> Hm - then my contention is that the scope of submodules needs to be
> expanded (or something needs to be built on top).
>
> One-big-repo doesn't fly - > 75% of the code volume (the 'other'
> modules) are shared between multiple projects. In SVN these are just
> svn:externals (which has it's own imperfections).
>
> I think it's a common usecase. You have 'shared' modules and
> 'project-specific' modules[*]. The 'shared' modules you hope don't
> change very much, but they are part of the overall project
> configuration - it's really nice that you can branch so easily in git,
> then get the module owner to merge those changes into the next release
> at their leisure. The superproject then represents the correct
> configuration of submodule trees to make a valid build.
Ah, is this your actual scenario? Just to make sure we are talking about
the same thing:
- You own superproject P.
- $Maintainer owns submodule S.
- You use S in P.
- You make changes to S that you would like $Maintainer to include in the
next release.
x You use in P your changes to S while $Maintainer has not yet released a
new version of S with your changes.
- Finally your changes arrive via the new release of S.
That *is* the intended use-case for submodules. But you have to play the
game by the rules:
- $Maintainer defines the official states of S.
- You must never commit an unofficial state of S in P.
The critical step in above list I marked with x:
- During the period where only *you* have the new changes to S, you must
*not* commit your submodule state to P. Instead, you write P in such a way
that it can work with both the old version of S and the upcoming release
that will have your changes[*]. This way you make sure that your consumers
of P always have a working version regardless of which version of S they use.
- After you have received the new release of S from $Maintainer, you
commit the new state of S in P. And if you are nice to your consumers of
P, then you *do not* remove the workaround from P just yet, so that you
don't force them to upgrade S. You will remove it later only if it becomes
a maintainance burden.
[*] If it is not possible to make P work with old and new versions, then
you have to work closely with the $Maintainer so that you never need
commit an unofficial state of S into P.
-- Hannes
^ permalink raw reply
* Re: git submodules and commit
From: Nigel Magnay @ 2008-07-16 11:02 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <487DD1C7.3070701@viscovery.net>
On Wed, Jul 16, 2008 at 11:47 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Nigel Magnay schrieb:
>> For me, in some really high proportion of cases, I think I want 'git
>> commit' to mean 'commit to any child repositories, any sibling
>> repositories, and any parent repositories (updating the submodule sha1
>> as appropriate). In other words, 'pretend like the whole thing is one
>> big repo'.
>
> And I think that this is the problem: If this way of commiting your
> changes is *required* in the *majority* of cases, then you are IMO outside
> the intended use-case of submodules. You are better served by really
> making this one big repo.
>
Hm - then my contention is that the scope of submodules needs to be
expanded (or something needs to be built on top).
One-big-repo doesn't fly - > 75% of the code volume (the 'other'
modules) are shared between multiple projects. In SVN these are just
svn:externals (which has it's own imperfections).
I think it's a common usecase. You have 'shared' modules and
'project-specific' modules[*]. The 'shared' modules you hope don't
change very much, but they are part of the overall project
configuration - it's really nice that you can branch so easily in git,
then get the module owner to merge those changes into the next release
at their leisure. The superproject then represents the correct
configuration of submodule trees to make a valid build.
The machinery has everything that's required, it's just the user
experience sucks :(
[*] actually there's more subtlety, there's 'shared', 'product' and
'project', so some 'specific' modules are potentially re-shared
elsewhere.
> IMO, submodules are to be used if you can afford to advance parent project
> and submodules at different paces; i.e. if the parent project can work
> with newer versions of the submodules (and possibly in a degraded mode
> even with outdated versions).
>
> -- Hannes
>
^ permalink raw reply
* Re: [PATCH] Use SHELL_PATH
From: Johannes Schindelin @ 2008-07-16 11:00 UTC (permalink / raw)
To: sverre; +Cc: namsh, git
In-Reply-To: <bd6139dc0807160347n2ebcd64fy7a15fe94bfabe580@mail.gmail.com>
Hi,
On Wed, 16 Jul 2008, Sverre Rabbelier wrote:
> On Wed, Jul 16, 2008 at 3:31 AM, SungHyun Nam <goweol@gmail.com> wrote:
> >
> > Signed-off-by: SungHyun Nam <goweol@gmail.com>
> > ---
> > t/Makefile | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/t/Makefile b/t/Makefile
> > index a778865..0d65ced 100644
> > --- a/t/Makefile
> > +++ b/t/Makefile
> > @@ -26,7 +26,7 @@ clean:
> > $(RM) -r 'trash directory' test-results
> >
> > aggregate-results:
> > - ./aggregate-results.sh test-results/t*-*
> > + '$(SHELL_PATH_SQ)' ./aggregate-results.sh test-results/t*-*
> >
> > # we can test NO_OPTIMIZE_COMMITS independently of LC_ALL
> > full-svn-test:
> > --
> > 1.5.6.3.350.g6c11a
>
> It is not clear to me what this patch does, there is no justification
> in the commit msg either. Instead you say what is being done, which we
> can see from the commit diff. Please clarify?
My _guess_ is that this comes from a platform like Solaris, where /bin/sh
is not even POSIX. And I'd expect aggregate-results to use some
non-trivial shell constructs which break with such a broken shell.
But I completely agree, the commit message desperately wants to include
some justification.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Use SHELL_PATH
From: Sverre Rabbelier @ 2008-07-16 10:47 UTC (permalink / raw)
To: namsh; +Cc: git
In-Reply-To: <g5jj21$bsp$1@ger.gmane.org>
On Wed, Jul 16, 2008 at 3:31 AM, SungHyun Nam <goweol@gmail.com> wrote:
>
> Signed-off-by: SungHyun Nam <goweol@gmail.com>
> ---
> t/Makefile | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/t/Makefile b/t/Makefile
> index a778865..0d65ced 100644
> --- a/t/Makefile
> +++ b/t/Makefile
> @@ -26,7 +26,7 @@ clean:
> $(RM) -r 'trash directory' test-results
>
> aggregate-results:
> - ./aggregate-results.sh test-results/t*-*
> + '$(SHELL_PATH_SQ)' ./aggregate-results.sh test-results/t*-*
>
> # we can test NO_OPTIMIZE_COMMITS independently of LC_ALL
> full-svn-test:
> --
> 1.5.6.3.350.g6c11a
It is not clear to me what this patch does, there is no justification
in the commit msg either. Instead you say what is being done, which we
can see from the commit diff. Please clarify?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git submodules and commit
From: Johannes Sixt @ 2008-07-16 10:47 UTC (permalink / raw)
To: Nigel Magnay; +Cc: Git Mailing List
In-Reply-To: <320075ff0807160332k5e49c256tb4191de628ecf41c@mail.gmail.com>
Nigel Magnay schrieb:
> For me, in some really high proportion of cases, I think I want 'git
> commit' to mean 'commit to any child repositories, any sibling
> repositories, and any parent repositories (updating the submodule sha1
> as appropriate). In other words, 'pretend like the whole thing is one
> big repo'.
And I think that this is the problem: If this way of commiting your
changes is *required* in the *majority* of cases, then you are IMO outside
the intended use-case of submodules. You are better served by really
making this one big repo.
IMO, submodules are to be used if you can afford to advance parent project
and submodules at different paces; i.e. if the parent project can work
with newer versions of the submodules (and possibly in a degraded mode
even with outdated versions).
-- Hannes
^ permalink raw reply
* Re: [PATCH 0/5] add pack index v2 reading capability to git v1.4.4.4
From: Johannes Schindelin @ 2008-07-16 10:46 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <1216189899-14279-1-git-send-email-nico@cam.org>
Hi,
On Wed, 16 Jul 2008, Nicolas Pitre wrote:
> Well, here it is. I know I know, I'm just too nice.
Thanks,
Dscho
^ permalink raw reply
* [PATCH] parse-options.c: make check_typos() static
From: Nanako Shiraishi @ 2008-07-16 10:42 UTC (permalink / raw)
To: git; +Cc: gitster
This function is not used by any other file.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
parse-options.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/parse-options.c b/parse-options.c
index 2fd5edb..987b015 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -214,7 +214,7 @@ is_abbreviated:
return -2;
}
-void check_typos(const char *arg, const struct option *options)
+static void check_typos(const char *arg, const struct option *options)
{
if (strlen(arg) < 3)
return;
--
1.5.6.3
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* [PATCH] builtin-describe.c: make a global variable "pattern" static
From: Nanako Shiraishi @ 2008-07-16 10:42 UTC (permalink / raw)
To: git; +Cc: gitster
This variable is not used by any other file.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
builtin-describe.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-describe.c b/builtin-describe.c
index e515f9c..62a1905 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -20,7 +20,7 @@ static int tags; /* But allow any tags if --tags is specified */
static int longformat;
static int abbrev = DEFAULT_ABBREV;
static int max_candidates = 10;
-const char *pattern = NULL;
+static const char *pattern;
static int always;
struct commit_name {
--
1.5.6.3
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* [PATCH] cache-tree.c: make cache_tree_find() static
From: Nanako Shiraishi @ 2008-07-16 10:42 UTC (permalink / raw)
To: git; +Cc: gitster
This function is not used by any other file.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
cache-tree.c | 2 +-
cache-tree.h | 2 --
2 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/cache-tree.c b/cache-tree.c
index 73cb340..5f8ee87 100644
--- a/cache-tree.c
+++ b/cache-tree.c
@@ -507,7 +507,7 @@ struct cache_tree *cache_tree_read(const char *buffer, unsigned long size)
return read_one(&buffer, &size);
}
-struct cache_tree *cache_tree_find(struct cache_tree *it, const char *path)
+static struct cache_tree *cache_tree_find(struct cache_tree *it, const char *path)
{
while (*path) {
const char *slash;
diff --git a/cache-tree.h b/cache-tree.h
index 44aad42..cf8b790 100644
--- a/cache-tree.h
+++ b/cache-tree.h
@@ -28,8 +28,6 @@ struct cache_tree *cache_tree_read(const char *buffer, unsigned long size);
int cache_tree_fully_valid(struct cache_tree *);
int cache_tree_update(struct cache_tree *, struct cache_entry **, int, int, int);
-struct cache_tree *cache_tree_find(struct cache_tree *, const char *);
-
#define WRITE_TREE_UNREADABLE_INDEX (-1)
#define WRITE_TREE_UNMERGED_INDEX (-2)
#define WRITE_TREE_PREFIX_ERROR (-3)
--
1.5.6.3
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* Re: MSysGit Stability
From: Dmitry Potapov @ 2008-07-16 10:42 UTC (permalink / raw)
To: Joe Fiorini; +Cc: git
In-Reply-To: <73fd69b50807151458u22a383a3l343779e47f4161fa@mail.gmail.com>
On Tue, Jul 15, 2008 at 05:58:43PM -0400, Joe Fiorini wrote:
> I'm curious which is better to use and if MSysGit is
> even stable yet. Does anyone have experience running Git on Windows?
Personally, I don't use it because I rarely use Windows, but I know
people who do since the beginning of this year, and in general they are
happy with it. It works faster than Cygwin version due to some Git
specific optimization put into mingw compatibility layer. So, the only
complain I heard so far is from people who got Cygwin on their computer,
and they don't like that MSysGit installs MSys, which means another set
of POSIX utilities such as bash but different version (usually more old)
and having a different HOME directory.
Dmitry
^ permalink raw reply
* Re: [PATCH] Fix buffer overflow in git-grep
From: Johannes Schindelin @ 2008-07-16 10:35 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git
In-Reply-To: <1216203345-18233-1-git-send-email-dpotapov@gmail.com>
Hi,
On Wed, 16 Jul 2008, Dmitry Potapov wrote:
> If PATH_MAX on your system is smaller than any path stored in the git
> repository, that can cause memory corruption inside of the grep_tree
> function used by git-grep.
Let me guess: Windows? *giggles*
> diff --git a/builtin-grep.c b/builtin-grep.c
> index ef29910..530a53d 100644
> --- a/builtin-grep.c
> +++ b/builtin-grep.c
> @@ -441,14 +441,17 @@ static int grep_tree(struct grep_opt *opt, const char **paths,
> len = strlen(path_buf);
>
> while (tree_entry(tree, &entry)) {
> - strcpy(path_buf + len, entry.path);
> + int te_len = tree_entry_len(entry.path, entry.sha1);
> + if (len + te_len >= PATH_MAX + tn_len)
> + die ("path too long: %s", path_buf+tn_len);
> + memcpy(path_buf + len, entry.path, te_len);
That is brutal. Does grep_tree() not work on tree objects in memory? In
that case, you prevent the user from grepping, only because she is on a
suboptimal platform, _even if_ even that platform could cope with it.
It's not like the path is ever used to access a file, right?
Maybe you should convert the path_buf to a strbuf instead.
Ciao,
Dscho
^ permalink raw reply
* git submodules and commit
From: Nigel Magnay @ 2008-07-16 10:32 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <320075ff0807160331j30e8f832m4de3e3bbe9c26801@mail.gmail.com>
I wonder if this is a fairly common pattern. We tend to have modules
as git repositories, and projects that tie together those git
repositories as submodules. In general, > 90% of the work is done in
one module, and the following stanza gets used a lot:
cd /proj/modA
git commit -s -m "Some change"
git push
cd ..
git add modA
git commit -s -m "Some change (modA)"
git push
But since this is much more cumbersome than (say) "svn ci", what often
happens is developers just commit into modA, then carry on. Or for
people just learning git, they somtimes screw up, and push the parent
proj but not the child modA
This is a shame, as it means any external people pulling updates
directly from proj will not get this change (e.g. CI tools
speculatively compiling against every developer tree).
For me, in some really high proportion of cases, I think I want 'git
commit' to mean 'commit to any child repositories, any sibling
repositories, and any parent repositories (updating the submodule sha1
as appropriate). In other words, 'pretend like the whole thing is one
big repo'.
I guess it probably gets sticky when there are merge conflicts. Is
anyone working on this kind of thing; I might be able to give some
time to help work on it?
^ permalink raw reply
* Re: git-cvsexportcommit keyword mismatch issue
From: Johannes Schindelin @ 2008-07-16 10:31 UTC (permalink / raw)
To: Barak A. Pearlmutter; +Cc: git
In-Reply-To: <E1KJ30U-0004EL-BV@corti>
Hi,
On Wed, 16 Jul 2008, Barak A. Pearlmutter wrote:
> So what I'm hoping is that this lengthy discourse of mine will convince
> someone to add code to git-cvsexportcommit that causes the patch
> creation and application stuff inside it to ignore keyword expansion
> mismatches (on files which do not have -kb on in CVS), perhaps by simply
> contracting keywords on all files/patches from both CVS/git at an early
> stage.
I doubt that this is going to happen. Obviously, it has been nonbody's
itch _enough_ to scratch it.
I see your problem, but unless you start hacking, I do not see it being
solved anytime soon.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] rebase-i: keep old parents when preserving merges
From: Johannes Schindelin @ 2008-07-16 10:24 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git
In-Reply-To: <20080716094301.GA25087@leksak.fem-net>
Hi,
On Wed, 16 Jul 2008, Stephan Beyer wrote:
> Johannes Schindelin wrote:
>
> > On Wed, 16 Jul 2008, Stephan Beyer wrote:
> >
> > > This patch fixes two issues for rebase -i with preserving merges of
> > > unrelated branches.
> >
> > Two? What's the second?
>
> Oh, eh, well ;)
> It's only one bug, but it results in two different behaviors...
Ah, okay. Worthwhile clarifying in the commit message.
Thanks for the patch,
Dscho
^ permalink raw reply
* [PATCH] Fix buffer overflow in git-grep
From: Dmitry Potapov @ 2008-07-16 10:15 UTC (permalink / raw)
To: git; +Cc: Dmitry Potapov
If PATH_MAX on your system is smaller than any path stored in the git
repository, that can cause memory corruption inside of the grep_tree
function used by git-grep.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
---
builtin-grep.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index ef29910..530a53d 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -441,14 +441,17 @@ static int grep_tree(struct grep_opt *opt, const char **paths,
len = strlen(path_buf);
while (tree_entry(tree, &entry)) {
- strcpy(path_buf + len, entry.path);
+ int te_len = tree_entry_len(entry.path, entry.sha1);
+ if (len + te_len >= PATH_MAX + tn_len)
+ die ("path too long: %s", path_buf+tn_len);
+ memcpy(path_buf + len, entry.path, te_len);
if (S_ISDIR(entry.mode))
/* Match "abc/" against pathspec to
* decide if we want to descend into "abc"
* directory.
*/
- strcpy(path_buf + len + tree_entry_len(entry.path, entry.sha1), "/");
+ strcpy(path_buf + len + te_len, "/");
if (!pathspec_matches(paths, down))
;
--
1.5.6.3.1.gb5587a
^ permalink raw reply related
* git-cvsexportcommit keyword mismatch issue
From: Barak A. Pearlmutter @ 2008-07-16 9:09 UTC (permalink / raw)
To: git
I used git-cvsimport -k to create my own git repo to deal with a
project that uses CVS. I push my mods upstream using
git-cvsexportcommit. This works fine *unless* there is a keyword
mismatch, i.e., some file in git has $Id: foo$ while in CVS keyword
expansion somehow changed it to $Id: bar$. In that case
git-cvsexportcommit barfs with a patch failure.
When that happens I use git-format-patch to generate a patch file and
integrate it manually. BLECH! This also confuses git-cvsimport when
I try to pull upstream changes, so I end up manually resolving the
keyword conflict again at that point, i.e., twice.
Simply avoiding expanded keywords should solve the problem. I thought
git-cvsimport -k would keep them out of my git repo, but no such luck.
Even when I use "cvs checkout -kk" for the CVS sandbox and then
"git-cvsimport -k", keywords were *still* expanded in my git repo.
(This is with both git 1.4.4.4 and git 1.5.6.) Either the -k switch
to git-cvsimport is busted, or I'm doing something wrong. In any case
even if this approached worked it would introduce a host of new
issues, since others on the project *are* using keyword expansion, and
the build process relies upon them.
One solution that occurs to me would be for git-cvsexportcommit to do
the dirty work of ignoring keyword mismatches for files that do not
have keywords disabled in CVS. It seems like it is in the best
position to solve the problem---everything else is hacking around to
avoid it instead of actually solving it, which gets brittle. So what
I'm hoping is that this lengthy discourse of mine will convince
someone to add code to git-cvsexportcommit that causes the patch
creation and application stuff inside it to ignore keyword expansion
mismatches (on files which do not have -kb on in CVS), perhaps by
simply contracting keywords on all files/patches from both CVS/git at
an early stage.
The same hack could be used in git-cvsimport to avoid the same problem
in the other direction, albeit with a little more work since keywords
that were not unexpanded in the git files would need to be re-expanded
in git to avoid gratuitous keyword-value-change patches.
Or perhaps I'm missing some other solution...?
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
http://www.bcl.hamilton.ie/~barak/
^ permalink raw reply
* Re: [PATCH] rebase-i: keep old parents when preserving merges
From: Stephan Beyer @ 2008-07-16 9:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807160432480.2841@eeepc-johanness>
Hi,
Johannes Schindelin wrote:
> Hi,
>
> On Wed, 16 Jul 2008, Stephan Beyer wrote:
>
> > This patch fixes two issues for rebase -i with preserving
> > merges of unrelated branches.
>
> Two? What's the second?
Oh, eh, well ;)
It's only one bug, but it results in two different behaviors...
If you have a merge with more than two parents and not all are lost,
then it merges with too few parents.
If you have a merge with exactly two parents and one is lost, then
it tries to cherry-pick (with an error).
"Two" "issues" :)
Regards.
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: git-rebase eats empty commits
From: Michael J Gruber @ 2008-07-16 9:24 UTC (permalink / raw)
To: git
In-Reply-To: <20080715201902.GC6244@leksak.fem-net>
[-- Attachment #1: Type: text/plain, Size: 1503 bytes --]
Stephan Beyer venit, vidit, dixit 15.07.2008 22:19:
> Hi,
...
> any version of git. Or I am missing a point.
>
> $ git cherry-pick empty # empty is an empty commit tagged as "empty"
> Already uptodate!
> Finished one cherry-pick.
> # Not currently on any branch.
> # Untracked files:
> [...]
> nothing added to commit but untracked files present (use "git add" to track)
How would an empty commit produce untracked files? You seem to be
testing something different.
I reattach the test case from my original post, as well as the log of
runs with git 1.5.6.3: once with rebase and once with rebase -i.
Uuuh, doh: I interpreted
Finished one cherry-pick.
# Not currently on any branch.
nothing to commit (working directory clean)
Could not apply e1f497c... empty 1
8d0c67a675bc65d375e8a9d019500bb2a16fb1e9 rewritten 1
as the end of the (interactive) rebase operation! Nothing indicated it
was interrupted: no message and no git status output. It all looked like
a failed rebase.
Now, thanks to your persistence, I tried going ahead with commit --amend
and rebase --continue, and all went fine (stopped again for empty 2,
giving no clue; amend & cont).
So, you're right: cherry-pick stops at empty commits, so that rebase -i
is the way to go. rebase (non-i) uses format-patch resp. merge (-m),
which eat empty commits.
I recall some discussion about informative rb-i messages, may upcoming
git would have saved me and will save others from this misinterpretation.
Thanks!
Michael
[-- Attachment #2: empty.sh --]
[-- Type: application/x-shellscript, Size: 400 bytes --]
[-- Attachment #3: empty.log --]
[-- Type: text/x-log, Size: 816 bytes --]
Initialized empty Git repository in /tmp/mjg/t/empty/.git/
Created initial commit 6b9e2af: 1
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 a
Created commit 8387962: empty 1
Created commit 6c4c3fe: 2
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 b
Created commit 3521900: empty 2
3521900fb7b032aa9e1f5a50a82f71785aa5c208 empty 2
6c4c3fe8b7619e1107256d0b47d0f419c05ceb69 2
8387962b740bb47662dd866eb57b4fe5ad21b355 empty 1
6b9e2afad8bed27378f0c9d23e77631be8447d37 1
Switched to a new branch "temp"
Created commit 1cced89: rewritten 1
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 a
First, rewinding head to replay your work on top of it...
Applying 2
a4116113335fc6be47fb9f8481547ea0923ac09d 2
1cced892a90024f4230a9f7aec1989ffe0b6c16f rewritten 1
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: empty-i.log --]
[-- Type: text/x-log; name="empty-i.log", Size: 873 bytes --]
Initialized empty Git repository in /tmp/mjg/t/empty/.git/
Created initial commit 2796c9d: 1
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 a
Created commit e1f497c: empty 1
Created commit b3867ae: 2
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 b
Created commit 2edad43: empty 2
2edad436286f39e407b83bbb448b3aa62b91aeb9 empty 2
b3867ae2a345ab30bfd68a1c7e0e19999a1eb9eb 2
e1f497c4ee7a040162faa7dcc2b6d8e41d5fd920 empty 1
2796c9d9f8fced86134e5b36462916c938c6f819 1
Switched to a new branch "temp"
Created commit 8d0c67a: rewritten 1
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 a
Rebasing (1/3)\rAlready uptodate!
Finished one cherry-pick.
# Not currently on any branch.
nothing to commit (working directory clean)
Could not apply e1f497c... empty 1
8d0c67a675bc65d375e8a9d019500bb2a16fb1e9 rewritten 1
^ permalink raw reply
* Re: MSysGit Stability
From: Peter Krefting @ 2008-07-16 8:30 UTC (permalink / raw)
To: Joe Fiorini; +Cc: Git Mailing List
In-Reply-To: <73fd69b50807151458u22a383a3l343779e47f4161fa@mail.gmail.com>
Joe Fiorini:
> I'm curious which is better to use and if MSysGit is even stable yet.
> Does anyone have experience running Git on Windows? Any experiences
> you can share? Is MSysGit ready yet or should we wait?
I have been using MSysGit actively for several projects since late last
year. The first time was a bit rough, but with the latest few version,
the MSysGit version has really matured, and I am happy to recommend it
anyone who wants to try out Git.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH] cherry: cache patch-ids to avoid repeating work
From: Johan Herland @ 2008-07-16 7:22 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Schindelin, Geoffrey Irving
In-Reply-To: <7vod4yztf5.fsf@gitster.siamese.dyndns.org>
On Wednesday 16 July 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > Okay, it seems like I never have time to review this, so I'll just
> >
> > take a few minutes to comment on some aspects:
> >> @@ -1094,6 +1104,8 @@ int cmd_cherry(int argc, const char **argv,
> >> const char *prefix)
> >> const char *limit = NULL;
> >> int verbose = 0;
> >>
> >> + git_config(git_cherry_config, NULL);
> >> +
> >> if (argc > 1 && !strcmp(argv[1], "-v")) {
> >> verbose = 1;
> >> argc--;
> >
> > Is this really purely for cherry, and not at all for "log
> > --cherry-pick"? Maybe it should be "cache.patchIds" to begin with.
>
> What other things would we want caches for?
This should be fairly obvious:
- git-notes (uses sha1-to-sha1 cache for storing commit-to-note
relationship)
- integrated bug trackers (uses sha1-to-sha1 cache for storing
commit-to-bugreport (or similar) relationships)
- ...any other mechanism that want to quickly map from a git object to some
associated data
There are probably plenty more ideas and use cases if people start looking.
AFAICS, each different use case would keep its cache in a separate file.
For local-repo-only caches the cache is kept within $GIT_DIR, and for shared
caches (IF that makes sense in any of the use cases) the cache could be
located in the working tree (either as a .git_foo file on relevant
branches, or as a file on a separate domain-specific branch).
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] bash completion: Fix the . -> .. revision range completion
From: Andreas Ericsson @ 2008-07-16 7:20 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Linus Torvalds, Junio C Hamano, Petr Baudis, git
In-Reply-To: <20080715233851.GA23672@spearce.org>
Shawn O. Pearce wrote:
> Andreas Ericsson <ae@op5.se> wrote:
>> I beat you to it ;-) This works just fine for me regardless of whether
>> or not I have a colon in COMP_WORDBREAKS.
> ...
>> Subject: git-completion.bash: Handle "rev:path" completion properly
> ...
>> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
>> index d268e6f..e138022 100755
>> --- a/contrib/completion/git-completion.bash
>> +++ b/contrib/completion/git-completion.bash
>> @@ -293,7 +293,11 @@ __git_complete_file ()
>> *)
>> ls="$ref"
>> ;;
>> - esac
>> + esac
>> + # When completing something like 'rev:path', bash behaves
>> + # differently whether or not COMP_WORDBREAKS contains a
>> + # colon or not. This lets it handle both cases
>> + test "${COMP_WORDBREAKS//:}" = "$COMP_WORDBREAKS" && pfx="$ref:$pfx"
>> COMPREPLY=($(compgen -P "$pfx" \
>> -W "$(git --git-dir="$(__gitdir)" ls-tree "$ls" \
>> | sed '/^100... blob /s,^.* ,,
>
> Yea, I did more or less the same thing in my patch, but I also
> handled this fix in git-fetch and git-push. The : is also used
> there in a refspec and we support completion the right side of the
> : in both cases (and yes, on git-push that can be slow as we do
> network IO, possibly over SSH).
>
> So I'm in favor of my patch over yours, but only because of
> the fetch and push fixes as well.
>
I agree, although I'd rather not have seen the case statement in
yours. It's bash completion after all, so no need to be "portably
fast" ;-)
I don't care that much though so long as it gets fixed.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ 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