* Re: Rebasing Multiple branches at once...
From: David Kastrup @ 2008-10-16 13:59 UTC (permalink / raw)
To: git
In-Reply-To: <48F730D0.9040008@calicojack.co.uk>
Rick Moynihan <rick@calicojack.co.uk> writes:
> Hi,
>
> I have a master branch, a dev branch and a number of feature branches
> from dev. And I was wondering if there was an easy way to rebase dev
> and all of it's sub-branches onto master.
>
> I know I can run this as a series of commands, and use --onto to do
> this, but was wondering if there was an easier way. As running:
>
> git rebase master
>
> when on the dev branch only rebases dev and not it's dependent branches.
Rebasing has no relation to dependent branches. It creates a new branch
from the branch point. After it finishes, it just reseats HEAD of the
branch to the new one. There is no operation that would work implicitly
on originally dependent branches.
--
David Kastrup
^ permalink raw reply
* Re: Rebasing Multiple branches at once...
From: Miklos Vajna @ 2008-10-16 13:59 UTC (permalink / raw)
To: Rick Moynihan; +Cc: git
In-Reply-To: <48F730D0.9040008@calicojack.co.uk>
[-- Attachment #1: Type: text/plain, Size: 506 bytes --]
On Thu, Oct 16, 2008 at 01:17:20PM +0100, Rick Moynihan <rick@calicojack.co.uk> wrote:
> I have a master branch, a dev branch and a number of feature branches from
> dev. And I was wondering if there was an easy way to rebase dev and all of
> it's sub-branches onto master.
In general this is considered harmful. Why do you rebase your branch
from time to time? For example in git.git, topic branches are based on
master, then merged to master when they are ready, but they are never
rebased.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Rebasing Multiple branches at once...
From: Rick Moynihan @ 2008-10-16 12:17 UTC (permalink / raw)
To: git
Hi,
I have a master branch, a dev branch and a number of feature branches
from dev. And I was wondering if there was an easy way to rebase dev
and all of it's sub-branches onto master.
I know I can run this as a series of commands, and use --onto to do
this, but was wondering if there was an easier way. As running:
git rebase master
when on the dev branch only rebases dev and not it's dependent branches.
Thanks!
R.
^ permalink raw reply
* Re: [gambit-list] Separating generated files?
From: Santi Béjar @ 2008-10-16 13:29 UTC (permalink / raw)
To: Christian Jaeger
Cc: Michael J Gruber, Matthieu Moy, Nguyen Thai Ngoc Duy,
Git Mailing List, Marc Feeley, Gambit List
In-Reply-To: <48F73463.2050902@pflanze.mine.nu>
On Thu, Oct 16, 2008 at 2:32 PM, Christian Jaeger
<christian@pflanze.mine.nu> wrote:
> Santi Béjar wrote:
>>
>> It looks like the html and man branches of git.git.
>>
>> http://git.kernel.org/?p=git/git.git;a=shortlog;h=html
>> http://git.kernel.org/?p=git/git.git;a=shortlog;h=man
>>
>> They are automatically generated when Junio pushes the branches to
>> kernel.org. Afterwards you can do a "make quick-install-html" and
>> install the preformated html pages from these branches. They are
>> generated with the dodoc.sh script from the todo branch in git.git
>> (look inside for instructions):
>>
>> http://git.kernel.org/?p=git/git.git;a=blob_plain;f=dodoc.sh;hb=todo
>
> This script only generates the html / man branches, it doesn't help find the
> right version for a given git version, right?
Right, one script to generate and one to get the right version.
>
> The differences are:
>
> - the html / man branches have a strictly linear history
Yes, because in this case it is not needed to replicate the whole
history, but it could be improved.
> and are centrally maintained. This solves the distribution issue for end users. But while
> developping the compiler, the developers may need to go back in the history
> of their own development (e.g. when the current compiler doesn't work
> anymore), and the suspected usefulness of being able to see and track
> differences in the generated code also isn't available for a strictly
> central approach.
So, you can divide the problem in two: (a) generated files in the
remote repositories (these can be generated automatically on the
server or in a dedicated server) (b) local generated files for local
commits. If both follow the same format to specify the original commit
you can use the same script to get it.
>
> - the script above is only for creating and committing the derived files, in
> a hook similar to the one I suggested in build/.git/hooks/commit-msg; this
> is the "cd build; git commit -m 'generated files for source repository
> commit
>> `git rev-parse HEAD`'" part; the more interesting part comes from
>> automatically finding the right commit in the generated branches for a given
>> source commit. This is what I intend to solve with the
>> "intergit-find-matching-commit-in" script. Said in a simpler way: the git
>> html / man branches do not offer automatically resolvable linking.
They offer this (Autogenerated HTML docs for v1.6.0.2-530-g67faa) but
there is no script around it.
My point was that there are other project keeping generated files (and
sometimes I would like it too), so you can see what they are doing. At
the end, maybe, you system could be usefull for them also.
Santi
^ permalink raw reply
* [PATCH v2] parse-opt: migrate builtin-checkout-index.
From: Miklos Vajna @ 2008-10-16 13:28 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Junio C Hamano, git
In-Reply-To: <20081016082340.GB15266@artemis.corp>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Thu, Oct 16, 2008 at 10:23:40AM +0200, Pierre Habouzit <madcoder@debian.org> wrote:
> Since git checkout-index -h will show you all the options, I usually
> prefer to use "[options] [--] <file>...", it's 10x as readable, and the
> user will have the [options] detail just below.
OK, changed.
builtin-checkout-index.c | 151 +++++++++++++++++++++++++---------------------
1 files changed, 82 insertions(+), 69 deletions(-)
diff --git a/builtin-checkout-index.c b/builtin-checkout-index.c
index 4ba2702..bc91f94 100644
--- a/builtin-checkout-index.c
+++ b/builtin-checkout-index.c
@@ -40,6 +40,7 @@
#include "cache.h"
#include "quote.h"
#include "cache-tree.h"
+#include "parse-options.h"
#define CHECKOUT_ALL 4
static int line_termination = '\n';
@@ -153,11 +154,55 @@ static void checkout_all(const char *prefix, int prefix_length)
exit(128);
}
-static const char checkout_cache_usage[] =
-"git checkout-index [-u] [-q] [-a] [-f] [-n] [--stage=[123]|all] [--prefix=<string>] [--temp] [--] <file>...";
+static const char * const builtin_checkout_index_usage[] = {
+ "git checkout-index [options] [--] <file>...",
+ NULL
+};
static struct lock_file lock_file;
+static int option_parse_u(const struct option *opt,
+ const char *arg, int unset)
+{
+ int *newfd = opt->value;
+
+ state.refresh_cache = 1;
+ if (*newfd < 0)
+ *newfd = hold_locked_index(&lock_file, 1);
+ return 0;
+}
+
+static int option_parse_z(const struct option *opt,
+ const char *arg, int unset)
+{
+ line_termination = unset;
+ return 0;
+}
+
+static int option_parse_prefix(const struct option *opt,
+ const char *arg, int unset)
+{
+ state.base_dir = arg;
+ state.base_dir_len = strlen(arg);
+ return 0;
+}
+
+static int option_parse_stage(const struct option *opt,
+ const char *arg, int unset)
+{
+ if (!strcmp(arg, "all")) {
+ to_tempfile = 1;
+ checkout_stage = CHECKOUT_ALL;
+ } else {
+ int ch = arg[0];
+ if ('1' <= ch && ch <= '3')
+ checkout_stage = arg[0] - '0';
+ else
+ die("stage should be between 1 and 3 or all");
+ }
+ return 0;
+}
+
int cmd_checkout_index(int argc, const char **argv, const char *prefix)
{
int i;
@@ -165,6 +210,33 @@ int cmd_checkout_index(int argc, const char **argv, const char *prefix)
int all = 0;
int read_from_stdin = 0;
int prefix_length;
+ int force = 0, quiet = 0, not_new = 0;
+ struct option builtin_checkout_index_options[] = {
+ OPT_BOOLEAN('a', "all", &all,
+ "checks out all files in the index"),
+ OPT_BOOLEAN('f', "force", &force,
+ "forces overwrite of existing files"),
+ OPT__QUIET(&quiet),
+ OPT_BOOLEAN('n', "no-create", ¬_new,
+ "don't checkout new files"),
+ { OPTION_CALLBACK, 'u', "index", &newfd, NULL,
+ "update stat information in the index file",
+ PARSE_OPT_NOARG, option_parse_u },
+ { OPTION_CALLBACK, 'z', NULL, NULL, NULL,
+ "paths are separated with NUL character",
+ PARSE_OPT_NOARG, option_parse_z },
+ OPT_BOOLEAN(0, "stdin", &read_from_stdin,
+ "read list of paths from the standard input"),
+ OPT_BOOLEAN(0, "temp", &to_tempfile,
+ "write the content to temporary files"),
+ OPT_CALLBACK(0, "prefix", NULL, "string",
+ "when creating files, prepend <string>",
+ option_parse_prefix),
+ OPT_CALLBACK(0, "stage", NULL, NULL,
+ "copy out the files from named stage",
+ option_parse_stage),
+ OPT_END()
+ };
git_config(git_default_config, NULL);
state.base_dir = "";
@@ -174,72 +246,13 @@ int cmd_checkout_index(int argc, const char **argv, const char *prefix)
die("invalid cache");
}
- for (i = 1; i < argc; i++) {
- const char *arg = argv[i];
-
- if (!strcmp(arg, "--")) {
- i++;
- break;
- }
- if (!strcmp(arg, "-a") || !strcmp(arg, "--all")) {
- all = 1;
- continue;
- }
- if (!strcmp(arg, "-f") || !strcmp(arg, "--force")) {
- state.force = 1;
- continue;
- }
- if (!strcmp(arg, "-q") || !strcmp(arg, "--quiet")) {
- state.quiet = 1;
- continue;
- }
- if (!strcmp(arg, "-n") || !strcmp(arg, "--no-create")) {
- state.not_new = 1;
- continue;
- }
- if (!strcmp(arg, "-u") || !strcmp(arg, "--index")) {
- state.refresh_cache = 1;
- if (newfd < 0)
- newfd = hold_locked_index(&lock_file, 1);
- continue;
- }
- if (!strcmp(arg, "-z")) {
- line_termination = 0;
- continue;
- }
- if (!strcmp(arg, "--stdin")) {
- if (i != argc - 1)
- die("--stdin must be at the end");
- read_from_stdin = 1;
- i++; /* do not consider arg as a file name */
- break;
- }
- if (!strcmp(arg, "--temp")) {
- to_tempfile = 1;
- continue;
- }
- if (!prefixcmp(arg, "--prefix=")) {
- state.base_dir = arg+9;
- state.base_dir_len = strlen(state.base_dir);
- continue;
- }
- if (!prefixcmp(arg, "--stage=")) {
- if (!strcmp(arg + 8, "all")) {
- to_tempfile = 1;
- checkout_stage = CHECKOUT_ALL;
- } else {
- int ch = arg[8];
- if ('1' <= ch && ch <= '3')
- checkout_stage = arg[8] - '0';
- else
- die("stage should be between 1 and 3 or all");
- }
- continue;
- }
- if (arg[0] == '-')
- usage(checkout_cache_usage);
- break;
- }
+ argc = parse_options(argc, argv, builtin_checkout_index_options,
+ builtin_checkout_index_usage, 0);
+ state.force = force;
+ state.quiet = quiet;
+ state.not_new = not_new;
+ if (argc && read_from_stdin)
+ die("--stdin must be at the end");
if (state.base_dir_len || to_tempfile) {
/* when --prefix is specified we do not
@@ -253,7 +266,7 @@ int cmd_checkout_index(int argc, const char **argv, const char *prefix)
}
/* Check out named files first */
- for ( ; i < argc; i++) {
+ for (i = 0; i < argc; i++) {
const char *arg = argv[i];
const char *p;
--
1.6.0.2
^ permalink raw reply related
* Re: Feedback outside of the user survey
From: Richard Hartmann @ 2008-10-16 13:18 UTC (permalink / raw)
To: Garry Dolley; +Cc: git
In-Reply-To: <20081016115628.GA24836@garry-x300.arpnetworks.com>
On Thu, Oct 16, 2008 at 13:56, Garry Dolley <gdolley@arpnetworks.com> wrote:
> I know from an external point of view, it seems pulling a subdir
> wouldn't be a big deal; but if you look at git internals, you start
> to realize why it's an option that isn't on the table.
That's my understanding as well. And you can simply branch
out a subdir when you want to work on it.
I am not saying this should be changed, just that it should
be mention in The Big Overview.
Richard
^ permalink raw reply
* Re: [gambit-list] Separating generated files?
From: Christian Jaeger @ 2008-10-16 12:32 UTC (permalink / raw)
To: Santi Béjar
Cc: Michael J Gruber, Matthieu Moy, Nguyen Thai Ngoc Duy,
Git Mailing List, Marc Feeley, Gambit List
In-Reply-To: <adf1fd3d0810160512if056c3dt5eeec6a097e1a7a7@mail.gmail.com>
Santi Béjar wrote:
> It looks like the html and man branches of git.git.
>
> http://git.kernel.org/?p=git/git.git;a=shortlog;h=html
> http://git.kernel.org/?p=git/git.git;a=shortlog;h=man
>
> They are automatically generated when Junio pushes the branches to
> kernel.org. Afterwards you can do a "make quick-install-html" and
> install the preformated html pages from these branches. They are
> generated with the dodoc.sh script from the todo branch in git.git
> (look inside for instructions):
>
> http://git.kernel.org/?p=git/git.git;a=blob_plain;f=dodoc.sh;hb=todo
This script only generates the html / man branches, it doesn't help find
the right version for a given git version, right?
The differences are:
- the html / man branches have a strictly linear history and are
centrally maintained. This solves the distribution issue for end users.
But while developping the compiler, the developers may need to go back
in the history of their own development (e.g. when the current compiler
doesn't work anymore), and the suspected usefulness of being able to see
and track differences in the generated code also isn't available for a
strictly central approach.
- the script above is only for creating and committing the derived
files, in a hook similar to the one I suggested in
build/.git/hooks/commit-msg; this is the "cd build; git commit -m
'generated files for source repository commit
> `git rev-parse HEAD`'" part; the more interesting part comes from
automatically finding the right commit in the generated branches for a
given source commit. This is what I intend to solve with the
"intergit-find-matching-commit-in" script. Said in a simpler way: the
git html / man branches do not offer automatically resolvable linking.
Christian.
^ permalink raw reply
* Re: [PATCH] Preserve file permissions on git-reflog expire
From: Johannes Schindelin @ 2008-10-16 12:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Samuel Lucas Vaz de Mello, git, Shawn O. Pearce
In-Reply-To: <7v3aix4ud4.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 15 Oct 2008, Junio C Hamano wrote:
> Samuel Lucas Vaz de Mello <samuellucas@datacom.ind.br> writes:
>
> > samuel@erdinger:~/myrepo$ git push
> > Counting objects: 5, done.
> > Compressing objects: 100% (3/3), done.
> > Unpacking objects: 100% (3/3), done.
> > Writing objects: 100% (3/3), 295 bytes, done.
> > Total 3 (delta 2), reused 0 (delta 0)
> > error: Unable to append to logs/refs/heads/master: Permission denied
> > To /remote/myrepo/
> > ! [remote rejected] master -> master (failed to write)
> > error: failed to push some refs to '/remote/myrepo/'
>
> Thanks for a reproduction recipe. I think an abbreviated version of this
> would deserve to be in the commit log message proper.
Or as a test script.
Ciao,
Dscho
^ permalink raw reply
* Re: [BUG] git status doesn't handle submodules properly on OSX
From: Lars Hoss @ 2008-10-16 12:30 UTC (permalink / raw)
To: Johannes Sixt
Cc: Lars Hoss, Pedro Melo, Pieter de Bie, Jeff King, Git Mailinglist
In-Reply-To: <48F7280C.3080205@viscovery.net>
Thanks again for your feedback, guys!
Ok, I've done it and tracked it down. Unfortunately my MacBook
has no access to the company network or internet (must get an iPhone ;-),
so I cannot copy&paste my finding.
For now I can you give this:
1.5.6.rc1.24.gd629 fails
1.5.6.rc1.23.g6c2ce works
The commit was on Jun 5, 14:47:50 by Marius Storm-Olsen and the relevant
file is wt-status.c.
Ok, I think I found the issue. I enabled showUntrackedFiles in my gitconfig:
status.showUntrackedFiles = all
On the one hand it makes sense to list submodule folder as untracked
files. Then again it feels wrong because it is a registered submodule. Hm
:-)
Anyway, bisect is really impressive!
Yours,
Lars
^ permalink raw reply
* Re: [gambit-list] Separating generated files?
From: Santi Béjar @ 2008-10-16 12:12 UTC (permalink / raw)
To: Christian Jaeger
Cc: Michael J Gruber, Matthieu Moy, Nguyen Thai Ngoc Duy,
Git Mailing List, Marc Feeley, Gambit List
In-Reply-To: <48F72CED.6030508@pflanze.mine.nu>
On Thu, Oct 16, 2008 at 2:00 PM, Christian Jaeger
<christian@pflanze.mine.nu> wrote:
>
> (In the meantime I've read the following pages:
> http://nopugs.com/2008/09/06/ext-tutorial
> http://nopugs.com/2008/09/04/why-ext
> http://flavoriffic.blogspot.com/2008/05/managing-git-submodules-with-gitrake.html
> (a post to the latter article suggests to use subtree merging instead, but
> that would be a very bad match for our use case; the mentioned problem of
> merging of the git superproject makes me think, though--the superproject
> could be updated only by the one person doing the publish onto the public
> repository, but then it leaves the problem of handling merges by developers
> completely unsolved.)
> )
>
> I'm starting to think that maybe a better idea than the
> superproject+2submodules approach would be just using the two repositories
> ("source" + "build"), and storing the linking information inside the "build"
> repository (by adding the source repository commitid to every commit message
> in the build repository [or using tags, but that doesn't seem a better
> idea]), and use a program that is able to check out the matching "build"
> repository for a given "source" repository checkout.
>
> I'm willing to write this program (let's call it
> "intergit-find-matching-commit-in" for the purpose of this email); question:
> which language to write it in, is Perl good? (C would be a hassle for
> Windows users because of the C compiler requirement; shell may be too
> limited.)
>
> Description of the workings in more detail:
>
> - one would work with the "source" repository just as one would with any
> project only employing one repository; do some changes to the project,
> commit them, test them (includes regeneration of generated files);
>
> - once in a while one would commit the current generated files in the
> "build" repository; by either (a) using a make target (like "make
> commit_generated") which runs something like
>
> eval "cd build; git commit -m 'generated files for source repository commit
> `git rev-parse HEAD`'"
>
> or (b) setting up a build/.git/hooks/commit-msg script which appends
> 'generated files for source repository commit `git rev-parse HEAD`' line to
> the commit message given from running "cd build; git commit -a" manually.
>
> - for publication, one would push both the "source" as well as the "build"
> repository (i.e. "cd build; git push; cd ..; git push")
>
> - for checkout (our "make update" make target), about the following would
> happen:
>
> git pull
> eval "(cd build; git checkout `intergit-find-matching-commit-in build`)"
>
> where "intergit-find-matching-commit-in build" would first refresh an index
> of the links (iterate over all unseen commits, parse commit messages for
> /source repository commit (\w+)/ and store $1 => $commitid_in_build_repo
> mappings in the index), then go through "git log --pretty=format:%H" (should
> I also specify --topo-order (or --date-order)?) looking up the commitids in
> the index, stopping at the first match and outputting the mapped
> $commitid_in_build_repo.
>
> This way, the "latest" or "probably best-matching" corresponding commit in
> the "build" repo can always be found, even if the "source" repo is ahead,
> which should allow building the compiler even if none is previously
> installed. This workflow seems more natural than the superproject+submodules
> approach, and it seems to entail no hassle with merge issues (only the
> "source" repo really needs proper merging; merging the "build" repo would
> only be worthwhile for maintaining the history, and as mentioned if there
> are conflicts, one would probably usually just regenerate the files there;
> there's no need to maintain linking info (with associated merge etc issues)
> in a separate entity (superproject) anymore, and during development, commits
> to the "build" repo need only be done if backwards-incompatible changes have
> been introduced).
>
> Does anyone else think this is sane/interesting? Should I go ahead
> implementing this? Any comments, like on how the interface of the
> intergit-find-matching-commit-in tool should look like?
>
It looks like the html and man branches of git.git.
http://git.kernel.org/?p=git/git.git;a=shortlog;h=html
http://git.kernel.org/?p=git/git.git;a=shortlog;h=man
They are automatically generated when Junio pushes the branches to
kernel.org. Afterwards you can do a "make quick-install-html" and
install the preformated html pages from these branches. They are
generated with the dodoc.sh script from the todo branch in git.git
(look inside for instructions):
http://git.kernel.org/?p=git/git.git;a=blob_plain;f=dodoc.sh;hb=todo
HTH,
Santi
^ permalink raw reply
* Re: [gambit-list] Separating generated files?
From: Christian Jaeger @ 2008-10-16 12:00 UTC (permalink / raw)
To: Michael J Gruber
Cc: Matthieu Moy, Nguyen Thai Ngoc Duy, Git Mailing List, Marc Feeley,
Gambit List
In-Reply-To: <48F62834.9080102@pflanze.mine.nu>
I wrote:
> Michael J Gruber wrote:
>> I wonder whether a clever use of "excludes" and GIT_DIR would allow
>> tracking the different filesets in the same dir, but using different
>> repos. I'm just afraid it's a fragile setup, in the sense that it relies
>> on config stuff which is not tracked (and thus not reproduced
>> automatically on clone).
>
> I expect that using a superproject repository to tie together the two
> repositories is good and necessary because it is the link that allows
> to specify which commit in the repo of generated files belongs
> together with a commit in the repo of source files. So just using two
> separate repositories without making them submodules of a superproject
> does not seem to be a good idea to me.
(In the meantime I've read the following pages:
http://nopugs.com/2008/09/06/ext-tutorial
http://nopugs.com/2008/09/04/why-ext
http://flavoriffic.blogspot.com/2008/05/managing-git-submodules-with-gitrake.html
(a post to the latter article suggests to use subtree merging instead,
but that would be a very bad match for our use case; the mentioned
problem of merging of the git superproject makes me think, though--the
superproject could be updated only by the one person doing the publish
onto the public repository, but then it leaves the problem of handling
merges by developers completely unsolved.)
)
I'm starting to think that maybe a better idea than the
superproject+2submodules approach would be just using the two
repositories ("source" + "build"), and storing the linking information
inside the "build" repository (by adding the source repository commitid
to every commit message in the build repository [or using tags, but that
doesn't seem a better idea]), and use a program that is able to check
out the matching "build" repository for a given "source" repository
checkout.
I'm willing to write this program (let's call it
"intergit-find-matching-commit-in" for the purpose of this email);
question: which language to write it in, is Perl good? (C would be a
hassle for Windows users because of the C compiler requirement; shell
may be too limited.)
Description of the workings in more detail:
- one would work with the "source" repository just as one would with any
project only employing one repository; do some changes to the project,
commit them, test them (includes regeneration of generated files);
- once in a while one would commit the current generated files in the
"build" repository; by either (a) using a make target (like "make
commit_generated") which runs something like
eval "cd build; git commit -m 'generated files for source repository
commit `git rev-parse HEAD`'"
or (b) setting up a build/.git/hooks/commit-msg script which appends
'generated files for source repository commit `git rev-parse HEAD`' line
to the commit message given from running "cd build; git commit -a" manually.
- for publication, one would push both the "source" as well as the
"build" repository (i.e. "cd build; git push; cd ..; git push")
- for checkout (our "make update" make target), about the following
would happen:
git pull
eval "(cd build; git checkout `intergit-find-matching-commit-in build`)"
where "intergit-find-matching-commit-in build" would first refresh an
index of the links (iterate over all unseen commits, parse commit
messages for /source repository commit (\w+)/ and store $1 =>
$commitid_in_build_repo mappings in the index), then go through "git log
--pretty=format:%H" (should I also specify --topo-order (or
--date-order)?) looking up the commitids in the index, stopping at the
first match and outputting the mapped $commitid_in_build_repo.
This way, the "latest" or "probably best-matching" corresponding commit
in the "build" repo can always be found, even if the "source" repo is
ahead, which should allow building the compiler even if none is
previously installed. This workflow seems more natural than the
superproject+submodules approach, and it seems to entail no hassle with
merge issues (only the "source" repo really needs proper merging;
merging the "build" repo would only be worthwhile for maintaining the
history, and as mentioned if there are conflicts, one would probably
usually just regenerate the files there; there's no need to maintain
linking info (with associated merge etc issues) in a separate entity
(superproject) anymore, and during development, commits to the "build"
repo need only be done if backwards-incompatible changes have been
introduced).
Does anyone else think this is sane/interesting? Should I go ahead
implementing this? Any comments, like on how the interface of the
intergit-find-matching-commit-in tool should look like?
Christian.
^ permalink raw reply
* Re: Feedback outside of the user survey
From: Garry Dolley @ 2008-10-16 11:56 UTC (permalink / raw)
To: Richard Hartmann; +Cc: git
In-Reply-To: <2d460de70810160319r4bed8643g884508cdeba772@mail.gmail.com>
On Thu, Oct 16, 2008 at 12:19:36PM +0200, Richard Hartmann wrote:
> svn's ability to pull a subdirectory, which is, ttbomk, lacking
> in git, should be included, as well. I am sure there are other
> examples [2].
Pulling a subdirectory with svn is possible because svn (and others
like it) tracks your files and directories. Git, on the other hand,
tracks the _content_ of the files in the repo. The information that
Git presents (logs, diff's, file contents, etc.) is built from
objects that are created from content you add to the repo.
Pulling a subdirectory and thereby excluding the files that make up the
content that git used to build its structures in the first place, is
something that I don't think would make sense.
I know from an external point of view, it seems pulling a subdir
wouldn't be a big deal; but if you look at git internals, you start
to realize why it's an option that isn't on the table.
Someone please correct me if I'm wrong here.
--
Garry Dolley
ARP Networks, Inc.
http://scie.nti.st
Los Angeles County REACT, Unit 336
WQGK336
^ permalink raw reply
* Re: [BUG] git status doesn't handle submodules properly on OSX
From: Lars Hoss @ 2008-10-16 11:53 UTC (permalink / raw)
To: Johannes Sixt
Cc: Lars Hoss, Pedro Melo, Pieter de Bie, Jeff King, Git Mailinglist
In-Reply-To: <48F7280C.3080205@viscovery.net>
>> So something between 1.5.6.5 and 1.6.0-rc0 broke it for me.
>> A quick diff between the two version revealed a lot of changes. Thus
>> tracking down the issue might not be easy for someone who is not
>> involved
>> in the code.
>
> Start with:
>
> $ git bisect start v1.6.0-rc0 v1.5.6.5 v1.6.0~6^2 v1.6.0.2~16^2 # [*]
>
> and test the version that this command gives you. Then say either
>
> $ git bisect good # if the version works
> $ git bisect bad # if the version fails
>
> Test again and repeat until the command tells you "First bad revision
> is..." and report back. (Finally, say 'git bisect reset' to get you back
> to where you started.)
>
> [*] The revisions v1.6.0~6^2 v1.6.0.2~16^2 are from gitk and git-gui,
> which we assume are good.
>
> -- Hannes
Wow, thank you Hannes! Will do so.
^ permalink raw reply
* Re: [BUG] git status doesn't handle submodules properly on OSX
From: Johannes Sixt @ 2008-10-16 11:39 UTC (permalink / raw)
To: Lars Hoss; +Cc: Pedro Melo, Pieter de Bie, Jeff King, Git Mailinglist
In-Reply-To: <3520b7a9009f072cfc3aeb82ae205e6b.squirrel@webmail.highteq.net>
Lars Hoss schrieb:
> Ok, I compiled several git versions from the git repo with the following
> results:
>
> v1.5.6.5 works
> v1.6.0.2 fails
> v1.6.0 fails
> v1.6.0-rc0 fails
...
> So something between 1.5.6.5 and 1.6.0-rc0 broke it for me.
> A quick diff between the two version revealed a lot of changes. Thus
> tracking down the issue might not be easy for someone who is not involved
> in the code.
Start with:
$ git bisect start v1.6.0-rc0 v1.5.6.5 v1.6.0~6^2 v1.6.0.2~16^2 # [*]
and test the version that this command gives you. Then say either
$ git bisect good # if the version works
$ git bisect bad # if the version fails
Test again and repeat until the command tells you "First bad revision
is..." and report back. (Finally, say 'git bisect reset' to get you back
to where you started.)
[*] The revisions v1.6.0~6^2 v1.6.0.2~16^2 are from gitk and git-gui,
which we assume are good.
-- Hannes
^ permalink raw reply
* Re: [PATCH v2] gitk: Update swedish translation.
From: Paul Mackerras @ 2008-10-16 10:07 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: Peter Krefting, Git Mailing List
In-Reply-To: <alpine.LNX.1.00.0809251413300.11806@localhost>
Mikael Magnusson writes:
> Signed-off-by: Mikael Magnusson <mikachu@gmail.com>
>
> ---
> This should be incorporating all the changes we discussed.
I went to apply this, but it's whitespace-damaged: all the lines that
should have just a single space character are empty (the space has
been removed). Could you please resend after fixing your mailer?
Thanks,
Paul.
^ permalink raw reply
* Re: Usability of git stash
From: David Kastrup @ 2008-10-16 11:24 UTC (permalink / raw)
To: git
In-Reply-To: <nKimSsYZj6xfGNCQS3i5cRwnWQfbHrtUrwdGB2zGWVfMOcfZMwJDKg@cipher.nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> writes:
> Anders Melchiorsen wrote:
>
>> When trying to recover from that scenario, I do "git stash apply" as
>> recommended by the "git stash" output. Now I still lost my index
>> state, all changes are unstaged.
>
> See the documentation, apply has a '--index' option.
Still, the shoot-yourself-in-the-foot potential is quite larger than
appropriate for what is mostly workflow porcelaine. It is even larger
than appropriate for plumbing IMHO.
I mean, even misspellings like
git stash lisp
cause action that is not easily reversible, and the given help output is
misleading with regard to index state.
--
David Kastrup
^ permalink raw reply
* Re: [BUG] git status doesn't handle submodules properly on OSX
From: Lars Hoss @ 2008-10-16 11:23 UTC (permalink / raw)
To: Pedro Melo; +Cc: Lars Hoss, Pieter de Bie, Jeff King, Git Mailinglist
In-Reply-To: <524C98C8-C3A5-4501-932A-2F0ACDE2886A@simplicidade.org>
Update:
Ok, I compiled several git versions from the git repo with the following
results:
v1.5.6.5 works
v1.6.0.2 fails
v1.6.0 fails
v1.6.0-rc0 fails
Given a git repo with a submodule 1.5.6.5 works (no untracked files) but
the same repo fails with 1.6.0-rc0 (lists submodule folders under
untracked files).
So something between 1.5.6.5 and 1.6.0-rc0 broke it for me.
A quick diff between the two version revealed a lot of changes. Thus
tracking down the issue might not be easy for someone who is not involved
in the code.
Maybe someone can give me a hint where to look? For example where does
"git status" decide whether a given filesystem folder should be ignored
with regard to .gitmodules?
Yours,
Lars
>
> On Oct 15, 2008, at 3:51 PM, Lars Hoss wrote:
>
>>> Works for me on Leopard
>>>
>>> Vienna:a pieter$ git submodule add ~/projects/GitX/ gitx
>>> Initialized empty Git repository in /Users/pieter/a/gitx/.git/
>>> Vienna:a pieter$ git st
>>> # On branch master
>>> # Changes to be committed:
>>> # (use "git reset HEAD <file>..." to unstage)
>>> #
>>> # new file: .gitmodules
>>> # new file: gitx
>>> #
>>> Vienna:a pieter$ git --version
>>> git version 1.6.0.2.415.gf9137
>>
>> My git version "1.6.0.2" says:
>>
>> # On branch master
>> # Changes to be committed:
>> # (use "git reset HEAD <file>..." to unstage)
>> #
>> # new file: .gitmodules
>> # new file: lib
>> #
>> # Untracked files:
>> # (use "git add <file>..." to include in what will be committed)
>> #
>> # lib/
>> git --version
>> git version 1.6.0.2
>>
>> Git was build from macports.
>
> hmms.. Really, I know about fink and Macports and all others, but I'm
> using Mac OS X since version 10.1 (when compiling OSS software was
> near impossible due to Apple decisions) and I've always had better
> results with compiling my own than using any of those OSS repositories.
>
> I understand the appeal, it seems easier, but I would recommend that
> you compile yourself the software packages you depend on.
>
> Regarding git, I saw a git-build.sh script floating around. If you
> cannot find it, you might want to try my own recipe
> (http://tinyurl.com/4ayze6
> ). I compile git master every day (cron) and thats the one I use on my
> main machine.
>
> Best regards,
> --
> Pedro Melo
> Blog: http://www.simplicidade.org/notes/
> XMPP ID: melo@simplicidade.org
> Use XMPP!
>
>
>
^ permalink raw reply
* Re: Feedback outside of the user survey
From: Richard Hartmann @ 2008-10-16 11:08 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081016102835.GC20762@sigill.intra.peff.net>
On Thu, Oct 16, 2008 at 12:28, Jeff King <peff@peff.net> wrote:
> Is there something about these that doesn't meet your criteria? Or did
> you not know about them (in which case, maybe we need to be more
> prominently pointing to them)?
In best slapstick fashion, I found the pages you mentioned in 1) and 3)
after sending off my email. Maybe they did not exist back when I last
looked, maybe they are easier to find now, maybe I was too stupid to
look, back then.
In any case, those two fit my needs nicely. In fact, I would have said
as much on this list if I had not become stuck in reading said docs :)
As to the resource you mention in 2), it is nice, but it does not fit
exactly to what I had in mind. You have a lot of snippets and single
steps, which is fine. What I was imagining was more like a use case
& workflow-driven layout.
A basic or complex task could give a short overview of steps, all of
which would be hyperlinked to detailed explanations. As a lot (more)
documentation seems to exist since I last gave git a serious try,
this is probably mainly a work of coming up with workflows and
linking to the correct places, not so much of writing any actual new
text.
And yes, I think the fact that these newbie-friendly docs exist these
days should be pushed more agressively. As you can see from the
links in my initial mail, a _lot_ of people have the same
misinformation I used to have. That will mainly be due to old
knowledge, but the situation exists. Worse, those people will warn
others about the lack of starter-level docs, making more people
shun git for all the wrong reasons.
An easy step in this direction might be to _prominently_ display
direct links to the newbie docs on the entry points, for most users.
I.e. the main site [1] and the wiki [2] along with the FAQ. I would
edit the wiki myself, but I could not find
MoinMaster:MoinPagesEditorGroup nor MoinMaster anywhere
in said wiki, thus decided to heed the warning & not edit at all.
Richard
[1] http://git.or.cz/
[2] http://git.or.cz/gitwiki
^ permalink raw reply
* Re: Feedback outside of the user survey
From: Jeff King @ 2008-10-16 10:28 UTC (permalink / raw)
To: Richard Hartmann; +Cc: git
In-Reply-To: <2d460de70810160319r4bed8643g884508cdeba772@mail.gmail.com>
On Thu, Oct 16, 2008 at 12:19:36PM +0200, Richard Hartmann wrote:
> 1) A table/An overview along the lines of "So, you are used to
> foo and that is how you do it in git."
> For example "What is the equivalent of svn co" (yes, that is an
> easy one ;). This should not be limited to things git can do.
How about:
Git - SVN Crash Course
http://git.or.cz/course/svn.html
> 2) A use case repository. "So you want to merge two
> branches", etc. This would be a good place to explain the
> different ways git offers to do stuff, as well.
How about:
Git User's Manual
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
(though I do think a user-contributed "recipe" database might be useful.
Maybe such a thing even exists already and I don't know about it).
> 3) A tutorial. It does not even have to be as sophisticated
> as vimtutor. A simple text file specifying steps to do stuff
> would be enough.
How about:
The Git Tutorial
http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
Is there something about these that doesn't meet your criteria? Or did
you not know about them (in which case, maybe we need to be more
prominently pointing to them)?
-Peff
^ permalink raw reply
* Re: [BUG] git status doesn't handle submodules properly on OSX
From: Lars Hoss @ 2008-10-16 10:30 UTC (permalink / raw)
To: Pedro Melo; +Cc: Lars Hoss, Pieter de Bie, Jeff King, Git Mailinglist
In-Reply-To: <524C98C8-C3A5-4501-932A-2F0ACDE2886A@simplicidade.org>
Hi!
I've cloned git this morning in order to try a build from this.
But chances are small that it will make a difference. Because from
the portfile I can see that macports just downloads 1.6.0.2 release
and builds it without any special patches or configure options.
As I said before, 1.5.6 works fine for me. But why 1.6.0.2 does not
work on my box - I don't know yet. Since Pedro uses a case-insensitive
volume as well, the problem seems not be related to sensitve/insensitive.
Now that I have a git clone on my box I might try bisect as well.
Yours,
Lars
> On Oct 15, 2008, at 3:51 PM, Lars Hoss wrote:
>
>>> Works for me on Leopard
>>>
>>> Vienna:a pieter$ git submodule add ~/projects/GitX/ gitx
>>> Initialized empty Git repository in /Users/pieter/a/gitx/.git/
>>> Vienna:a pieter$ git st
>>> # On branch master
>>> # Changes to be committed:
>>> # (use "git reset HEAD <file>..." to unstage)
>>> #
>>> # new file: .gitmodules
>>> # new file: gitx
>>> #
>>> Vienna:a pieter$ git --version
>>> git version 1.6.0.2.415.gf9137
>>
>> My git version "1.6.0.2" says:
>>
>> # On branch master
>> # Changes to be committed:
>> # (use "git reset HEAD <file>..." to unstage)
>> #
>> # new file: .gitmodules
>> # new file: lib
>> #
>> # Untracked files:
>> # (use "git add <file>..." to include in what will be committed)
>> #
>> # lib/
>> git --version
>> git version 1.6.0.2
>>
>> Git was build from macports.
>
> hmms.. Really, I know about fink and Macports and all others, but I'm
> using Mac OS X since version 10.1 (when compiling OSS software was
> near impossible due to Apple decisions) and I've always had better
> results with compiling my own than using any of those OSS repositories.
>
> I understand the appeal, it seems easier, but I would recommend that
> you compile yourself the software packages you depend on.
>
> Regarding git, I saw a git-build.sh script floating around. If you
> cannot find it, you might want to try my own recipe
> (http://tinyurl.com/4ayze6
> ). I compile git master every day (cron) and thats the one I use on my
> main machine.
>
> Best regards,
> --
> Pedro Melo
> Blog: http://www.simplicidade.org/notes/
> XMPP ID: melo@simplicidade.org
> Use XMPP!
>
>
>
^ permalink raw reply
* Re: --diff-filter=T does not list x changes
From: Jeff King @ 2008-10-16 10:22 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: git
In-Reply-To: <871vyhbsys.fsf@cup.kalibalik.dk>
On Wed, Oct 15, 2008 at 08:42:35PM +0200, Anders Melchiorsen wrote:
> From documentation, I would expect --diff-filter to list changes in
> the execute bit, but it does not. I hear on #git that this is
> intended, though I still do not know how to filter on the execute bit.
> Is it impossible?
Looking at the code, I think it's impossible, and one would have to add
a new --diff-filter letter. However, at the very least, the
documentation should clarify this situation. The --diff-filter
explanation says:
Select only files [...] have their type (mode) changed (T) [...]
which to me indicates that your test case should work.
-Peff
^ permalink raw reply
* Feedback outside of the user survey
From: Richard Hartmann @ 2008-10-16 10:19 UTC (permalink / raw)
To: git
Hi all,
unfortunately, I did not know there was a survey, so I did not
participate in it.
I still want to give some feedback from my experiences with
git.
From browsing the results [1] of said survey, I see one
request being made a lot of times. It's basically my main
gripe with git, as well :)
git can do a lot of things, but, as a new user, you are never
quite sure where to start. Docs are geared towards advanced
users (which is fine), but there is no easy entry point (which
is bad).
I would suggest three approaches to fix this:
1) A table/An overview along the lines of "So, you are used to
foo and that is how you do it in git."
For example "What is the equivalent of svn co" (yes, that is an
easy one ;). This should not be limited to things git can do.
svn's ability to pull a subdirectory, which is, ttbomk, lacking
in git, should be included, as well. I am sure there are other
examples [2].
2) A use case repository. "So you want to merge two
branches", etc. This would be a good place to explain the
different ways git offers to do stuff, as well.
3) A tutorial. It does not even have to be as sophisticated
as vimtutor. A simple text file specifying steps to do stuff
would be enough.
Thanks,
Richard
[1] http://www.survs.com/app/2/wo/7OeqmUsbjaDuuaLsOCLeSg/0.0.9.3.3.0.1.3.33.1.7.1
[2] http://www.survs.com/app/2/wo/7OeqmUsbjaDuuaLsOCLeSg/0.0.9.3.3.0.1.3.14.1.7.1
^ permalink raw reply
* Re: What's in git.git (Oct 2008, #03; Tue, 14)
From: Jeff King @ 2008-10-16 10:08 UTC (permalink / raw)
To: Brandon Casey
Cc: Junio C Hamano, git, Arjen Laarhoven, Shawn O. Pearce,
Mike Ralphson
In-Reply-To: <bsftmRx17krWBpVlulipoJEO1fWsD0hZfF3HOZcajX6GV66RKW8W6A@cipher.nrlssc.navy.mil>
On Wed, Oct 15, 2008 at 10:35:30AM -0500, Brandon Casey wrote:
> 2) Do we want to stick with compat/regex on
>
> Darwin: Arjen
> FreeBSD: Jeff
> AIX: Mike
>
> now that the builtin funcname patterns have been converted to Extended
> Regular Expressions?
t4018 passes without compat/regex on FreeBSD. Is that a sufficient test?
-Peff
^ permalink raw reply
* Re: git-scm.com
From: Petr Baudis @ 2008-10-16 9:49 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Scott Chacon, Wincent Colaiuta, git
In-Reply-To: <20081016184239.6117@nanako3.lavabit.com>
On Thu, Oct 16, 2008 at 06:42:39PM +0900, Nanako Shiraishi wrote:
> Quoting Petr Baudis <pasky@suse.cz>:
> > On Wed, Oct 15, 2008 at 09:21:50AM -0700, Scott Chacon wrote:
> >> I do wish that there wasn't this 'us vs them' mentality on this list,
> >> though. I think GitHub is doing some good things for the community,
> >> and I also think that 'the community' is bigger than this list.
> >
> > I think this last sentence is where we differ - for (most of?) us the
> > Git developers, 'the community' pretty much _is_ this list (with the IRC
> > channel as its casual extension).
>
> Curiously, whenever somebody says "git-scm.com is the official git homepage", you are not involved in the discussion. Could you share your position on this issue with the rest of the "community"?
To possibly save Junio some archives digging, he did share his
position in the original thread at
http://thread.gmane.org/gmane.comp.version-control.git/90079/focus=90167
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [BUG] git status doesn't handle submodules properly on OSX
From: Pedro Melo @ 2008-10-16 9:49 UTC (permalink / raw)
To: Lars Hoss; +Cc: Richard Bubel, Pieter de Bie, Jeff King, Git Mailinglist
In-Reply-To: <c84d2f2498509bfb916c060317892998.squirrel@webmail.highteq.net>
Hi,
On Oct 15, 2008, at 4:21 PM, Lars Hoss wrote:
> Ok, this might be the difference. I am pretty sure my
> filesystem is not case-sensitive (default?).
> At least "mkdir Foo" fails when "foo" exists.
My filesystem is Mac OS Extended (Journaled) case-insensitive like
yours, and submodules work.
Best regards,
>
>
> Yours,
> Lars
>
>> Hi,
>>
>> On Oct 15, 2008, at 16:51 , Lars Hoss wrote:
>>
>>>> Works for me on Leopard
>>>> [...]
>>>> Vienna:a pieter$ git --version
>>>> git version 1.6.0.2.415.gf9137
>>>
>>> My git version "1.6.0.2" says:
>>>
>>> # On branch master
>>> [...]
>>> git --version
>>> git version 1.6.0.2
>>>
>>> Git was build from macports.
>>
>>
>> works for me too on OS X 10.5.5 with git 1.6.0.2 from MacPorts. As it
>> deviates from the default, it might be worth mentioning that the
>> filesystem in use here is the case-sensitive version of HFS+.
>>
>> Best Regards,
>> Richard
>>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo@simplicidade.org
Use XMPP!
^ 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