* 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: [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
* 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
* [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
* [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] 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
* 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
* 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] 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: [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: 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: 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
* [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: [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
* 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: 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: MSysGit Stability
From: Peter Harris @ 2008-07-16 12:33 UTC (permalink / raw)
To: Joe Fiorini; +Cc: git
In-Reply-To: <73fd69b50807151458u22a383a3l343779e47f4161fa@mail.gmail.com>
On Tue, Jul 15, 2008 at 5:58 PM, Joe Fiorini wrote:
>
> Does anyone have experience running Git on Windows?
I use msysgit regularly. The core git is quite stable, although
occasionally peripherals have a bit of trouble. For example, git-svn
was broken recently.
Overall, I would recommend msysgit for anyone stuck on Windows.
Peter Harris
^ permalink raw reply
* [PATCH] Documentation/git-cherry-pick.txt et al.: Fix misleading -n description
From: Petr Baudis @ 2008-07-16 12:35 UTC (permalink / raw)
To: git; +Cc: gitster
The manual page of git-cherry-pick and git-revert asserts that -n works
primarily on the working tree, while in fact the primary object it operates
on is the index, and the changes only "accidentally" propagate to the
working tree. This e.g. leads innocent #git IRC folks to believe that you
can use -n to prepare changes for git-add -i staging.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
I'm actually not *entirely* sure about the exact working tree vs. index
semantics of the -n parameter, this is a guess based on the code.
Unfortunately, I'm currently too busy with other things to check
thoroughly, and I'm sure other people on the list will know off-hand.
Documentation/git-cherry-pick.txt | 10 +++++-----
Documentation/git-revert.txt | 16 ++++++++--------
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
index a691173..50fb3d5 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -58,14 +58,14 @@ OPTIONS
Usually the command automatically creates a commit with
a commit log message stating which commit was
cherry-picked. This flag applies the change necessary
- to cherry-pick the named commit to your working tree,
- but does not make the commit. In addition, when this
- option is used, your working tree does not have to match
+ to cherry-pick the named commit to your working tree
+ and the index, but does not make the commit. In addition,
+ when this option is used, your index does not have to match
the HEAD commit. The cherry-pick is done against the
- beginning state of your working tree.
+ beginning state of your index.
+
This is useful when cherry-picking more than one commits'
-effect to your working tree in a row.
+effect to your index in a row.
-s::
--signoff::
diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt
index 5411edc..271850f 100644
--- a/Documentation/git-revert.txt
+++ b/Documentation/git-revert.txt
@@ -43,16 +43,16 @@ OPTIONS
-n::
--no-commit::
Usually the command automatically creates a commit with
- a commit log message stating which commit was reverted.
- This flag applies the change necessary to revert the
- named commit to your working tree, but does not make the
- commit. In addition, when this option is used, your
- working tree does not have to match the HEAD commit.
- The revert is done against the beginning state of your
- working tree.
+ a commit log message stating which commit was
+ reverted. This flag applies the change necessary
+ to revert the named commit to your working tree
+ and the index, but does not make the commit. In addition,
+ when this option is used, your index does not have to match
+ the HEAD commit. The revert is done against the
+ beginning state of your index.
+
This is useful when reverting more than one commits'
-effect to your working tree in a row.
+effect to your index in a row.
-s::
--signoff::
^ permalink raw reply related
* Re: git submodules and commit
From: Nigel Magnay @ 2008-07-16 12:48 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <487DDCFC.9020007@viscovery.net>
> 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:
>
Yes, that is the situation - with the proviso that it's not always
clear in company environments who $Maintainer actually is. For
example, if the only changes occurring in S come from me, then chances
are come release cycle, $Maintainer == me.
P and S aren't distant projects, they're closely coupled.
> - $Maintainer defines the official states of S.
>
Yes - there is one branch ('master') which the changes eventually
should be merged to, and releases will be performed on
> - You must never commit an unofficial state of S in P.
>
If by that you mean that the only person to move the branch 'master'
is $Maintainer, then I agree.
If by that you mean that you can't commit at all to the S tree (and
the S submodule pointer) then I don't agree, and I think that's a
serious limitation in productivity.
> 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.
>
Just to be clear - there's more than just 'me' working on P - there's
a whole team of people working on it. And there's Q R S and T teams
also working on projects that also have S.
Changes that happen to S are, often, new features or bug fixes. We
can't just stop because there isn't an 'official' version of S yet
(and the official version might end up simply being a FF anyway), so
saying 'don't commit your submodule state to P' is unrealistic.
And that should be the big advantage of git. If we suddenly find we
need some additional functionality in S, we just add it to our
P-branch-of-S. The $Maintainer (if he exists) can review these
upcoming changes in the tree, and merge them to master as appropriate
(or work with the projects to iron out cross-branch
incompatibilities). The best example is that S is a "product", and (by
management decree), the only product changes that happen will occur
because of *projects* (like P). And we can do this (and it's
infinitely better than svn, where 'ooh, branches too hard, everyone in
[P-T] just commit to trunk'. But the UI is an ache.
> - 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.
>
Maintaining backwards compatibility isn't an issue at all for us.
> [*] 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: MSysGit Stability
From: Johannes Schindelin @ 2008-07-16 12:58 UTC (permalink / raw)
To: Peter Harris; +Cc: Joe Fiorini, git
In-Reply-To: <eaa105840807160532t73e6b851h5b78c0d8ad4c1c1a@mail.gmail.com>
Hi,
On Wed, 16 Jul 2008, Peter Harris wrote:
> On Tue, Jul 15, 2008 at 5:58 PM, Joe Fiorini wrote:
> >
> > Does anyone have experience running Git on Windows?
>
> I use msysgit regularly. The core git is quite stable, although
> occasionally peripherals have a bit of trouble. For example, git-svn
> was broken recently.
Note that git-svn will be removed in the next alpha release of msysGit,
due to lack of people interested in fixing the thing. No, complaining and
asking others to do all the work does not account for "interest".
Ciao,
Dscho
^ permalink raw reply
* Re: git submodules and commit
From: Johannes Sixt @ 2008-07-16 13:38 UTC (permalink / raw)
To: Nigel Magnay; +Cc: Git Mailing List
In-Reply-To: <320075ff0807160548qae5d702jafe3df63363c512c@mail.gmail.com>
Nigel Magnay schrieb:
> P and S aren't distant projects, they're closely coupled.
And I'm saying that submodules are designed for *loosely* coupled projects.
It's no wonder that this tool is awkward to use in your workflow.
-- Hannes
^ permalink raw reply
* Re: Breakage caused by 2fe403e7 git-svn.perl: workaround assertions in svn library 1.5.0
From: SZEDER Gábor @ 2008-07-16 13:45 UTC (permalink / raw)
To: Kevin Ballard; +Cc: Git Mailing List, pape, Eric Wong
In-Reply-To: <6583867F-ED86-4E3D-AE8B-39FB974C43D7@sb.org>
Hi,
On Tue, Jul 08, 2008 at 05:41:48PM -0700, Kevin Ballard wrote:
> Commit 2fe403e7 causes `git svn info` and `git svn info .` to break.
>
> Use of uninitialized value in localtime at /usr/local/libexec/git-
> core/git-svn line 4277.
> No such file or directory at /usr/local/libexec/git-core/git-svn line
> 897.
>
> If it makes a difference, I have svn 1.4.4 installed, not svn 1.5.
the same problem here, except that I have svn v1.4.6.
The patch in question adds the following line to git-svn.perl's
canonicalize_path():
+ $path =~ s#^\.$##;
which makes an empty string from the path ".". This is especially
unfortunate for 'git svn info', cmd_info() begins with
my $path = canonicalize_path(shift or ".");
and from that point everything is ruined, but it boils out only when
it tries to actually open() the empty path.
Removing the mentioned line from canonicalize_path() does resolve this
issue on svn v1.4.6, but I'm afraid it will brake again on svn v1.5.
Gábor
^ permalink raw reply
* Re: git submodules and commit
From: Nigel Magnay @ 2008-07-16 14:03 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <487DF9BB.10107@viscovery.net>
On Wed, Jul 16, 2008 at 2:38 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Nigel Magnay schrieb:
>> P and S aren't distant projects, they're closely coupled.
>
> And I'm saying that submodules are designed for *loosely* coupled projects.
>
> It's no wonder that this tool is awkward to use in your workflow.
>
Ok in a sense. I don't think it's particularly clear from the
documentation that this is a limitation of submodules though.
Given that
- The only way in git to separate out re-usable modules is by the use
of submodules
and
- It's a pretty common usecase for these submodules to be interrelated
and
- Looking over the list archives, it seems this is quite common complaint
"I really like the git submodule implementation, I just don't like how
hard it is to work with"
"The current behaviour strongly encourages me to avoid submodules
when I would otherwise like to use them, just to keep the rest of my
team members (who are not git experts) from going insane."
"For my use case, I passionately dislike the fact that a submodule is
not updated automatically. There's never a time when I don't want to
update the submodule. The submodule is a very important piece of our
project and the super-project depends on it being at the right
version."
and
- All the technical capability is there, it's just the porcelain
that's causing the friction.
then
would this not seem to be an area that could be improved? Even if it
were an optional mode of working?
^ permalink raw reply
* Re: git submodules and commit
From: Petr Baudis @ 2008-07-16 14:17 UTC (permalink / raw)
To: Nigel Magnay; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <320075ff0807160703v3f16ff5bue722b760ad66488e@mail.gmail.com>
On Wed, Jul 16, 2008 at 03:03:41PM +0100, Nigel Magnay wrote:
> - All the technical capability is there, it's just the porcelain
> that's causing the friction.
> then
> would this not seem to be an area that could be improved? Even if it
> were an optional mode of working?
So, were there already any patches posted to add such a functionality
that were rejected? If not, apparently noone cared _enough_, yet. ;-)
You may be the first!
I don't know if there are any _present_ "free developers" willing to
pick up this task now. For many (most?) Git developers, submodules
simply aren't a priority. For me, they actually currently are, but I
probably won't want to use them in your way either (even though I can
agree that your sentiments are valid), so I will personally invest my
time in doing other things than figuring out the precise semantics
these operations should have etc.
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
^ permalink raw reply
* Re: git submodules and commit
From: Nigel Magnay @ 2008-07-16 14:31 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <20080716141738.GN32184@machine.or.cz>
> On Wed, Jul 16, 2008 at 03:03:41PM +0100, Nigel Magnay wrote:
>> - All the technical capability is there, it's just the porcelain
>> that's causing the friction.
>> then
>> would this not seem to be an area that could be improved? Even if it
>> were an optional mode of working?
>
> So, were there already any patches posted to add such a functionality
> that were rejected? If not, apparently noone cared _enough_, yet. ;-)
> You may be the first!
>
> I don't know if there are any _present_ "free developers" willing to
> pick up this task now. For many (most?) Git developers, submodules
> simply aren't a priority. For me, they actually currently are, but I
> probably won't want to use them in your way either (even though I can
> agree that your sentiments are valid), so I will personally invest my
> time in doing other things than figuring out the precise semantics
> these operations should have etc.
>
That's cool. I was guessing it might be the case (or alternatively
that someone might say 'yeah, but it's 25% of the way there'); my
original query was also one of an offer of help ;-) My guess though is
that the core-devs have much more connected neural pathways at
thinking about the problems around the edge cases to be able to give
warnings of 'there be dragons'!
Nigel
^ 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