{"thread":{"id":"9150","subject":"[PATCH 3/3] Teach \"git branch\" about --new-workdir","startedAt":"2007-07-22T18:56:31Z","lastAt":"2007-07-26T11:51:12Z","messageCount":46,"participants":["Johannes Schindelin","Daniel Barkalow","Julian Phillips","Jakub Narebski","Shawn O. Pearce","Junio C Hamano","Marius Storm-Olsen","Josef Weidendorfer","Alex Riesen","Steven Grimm","Andy Parkins","Linus Torvalds","Christian MICHON"],"isPatch":true,"patchVersion":1,"patchTotal":3},"messages":[{"id":"48164","messageId":"Pine.LNX.4.64.0707221956210.14781@racer.site","threadId":"9150","inReplyTo":null,"subject":"[PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-22T18:56:31Z","receivedAt":"2007-07-22T18:56:31Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nInspired by contrib/workdir/git-new-workdir, the flag --new-workdir (or\nits shortcut, -n) can be used to create a new working directory for the\nnewly created branch. All information, except which branch is checked\nout (and therefore also the index), will be symlinked from the current\nrepository.\n\nExample:\n\n\t$ git branch -n ~/my-new-topic xy-problem\n\nwill create a branch called \"xy-problem\", which is initially identical\nto the current branch, and check out the new branch in ~/my-new-topic/.\nYou will be able to cherry-pick from, log and diff with the branch\n\"xy-problem\" in the current repository, since most of the metadata is\nshared.\n\nConversely, you can access all the branches in the current repository\nfrom ~/my-new-topic/, too.\n\nA word of warning: switching to _same_ branch that is checked out in\nthe other repository is asking for trouble. You are really working not\nonly on the same object database, but also the same (i.e. not copied)\nrefs namespace.\n\nSigned-off-by: Johannes Schindelin \n---\n\tIMHO this is a better syntax than what is in contrib/, and \"git\n\tbranch\" is probably the right place for such a thing, from a\n\tuser's perspective.\n\n Documentation/git-branch.txt | 7 +++-\n builtin-branch.c | 79 +++++++++++++++++++++++++++++++++++++++--\n t/t3200-branch.sh | 11 ++++++\n 3 files changed, 92 insertions(+), 5 deletions(-)\n\ndiff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt\nindex bc6aa88..a05c795 100644\n--- a/Documentation/git-branch.txt\n+++ b/Documentation/git-branch.txt\n@@ -10,7 +10,8 @@ SYNOPSIS\n [verse]\n 'git-branch' [--color | --no-color] [-r | -a]\n \t [-v [--abbrev= | --no-abbrev]]\n-'git-branch' [--track | --no-track] [-l] [-f] []\n+'git-branch' [--track | --no-track] [-l] [-f] \n+\t [-n | --new-workdir ] []\n 'git-branch' (-m | -M) [] \n 'git-branch' (-d | -D) [-r] ...\n \n@@ -91,6 +92,10 @@ OPTIONS\n --no-abbrev::\n \tDisplay the full sha1s in output listing rather than abbreviating them.\n \n+-n\\|--new-workdir ::\n+\tSet up a new working directory which shares all information with the\n+\tcurrent repository, except which branch is checked out.\n+\n ::\n \tThe name of the branch to create or delete.\n \tThe new branch name must pass all checks defined by\ndiff --git a/builtin-branch.c b/builtin-branch.c\nindex 5f5c182..cba5fac 100644\n--- a/builtin-branch.c\n+++ b/builtin-branch.c\n@@ -11,9 +11,10 @@\n #include \"commit.h\"\n #include \"builtin.h\"\n #include \"remote.h\"\n+#include \"unpack-trees.h\"\n \n static const char builtin_branch_usage[] =\n- \"git-branch [-r] (-d | -D) | [--track | --no-track] [-l] [-f] [] | (-m | -M) [] | [--color | --no-color] [-r | -a] [-v [--abbrev= | --no-abbrev]]\";\n+ \"git-branch [-r] (-d | -D) | [--track | --no-track] [-l] [-f] [-n | --new-workdir ] [] | (-m | -M) [] | [--color | --no-color] [-r | -a] [-v [--abbrev= | --no-abbrev]]\";\n \n #define REF_UNKNOWN_TYPE 0x00\n #define REF_LOCAL_BRANCH 0x01\n@@ -500,6 +501,67 @@ static void rename_branch(const char *oldname, const char *newname, int force)\n \t\tdie(\"Branch is renamed, but update of config-file failed\");\n }\n \n+static struct lock_file lockfile;\n+\n+/* This function free()s path */\n+static int create_new_workdir(char *path, const char *branch_name)\n+{\n+\tstatic const char *links[] = {\n+\t\t\"config\", \"refs\", \"logs/refs\", \"objects\", \"info\", \"hooks\",\n+\t\t\"packed-refs\", \"remotes\", \"rr-cache\", NULL\n+\t};\n+\tconst char *git_dir = get_git_dir(), *absolute;\n+\tstruct stat st;\n+\tunsigned char sha1[20];\n+\tchar *ref;\n+\tstruct object *object;\n+\tstruct unpack_trees_options opts;\n+\tstruct object_list trees;\n+\tint i, fd;\n+\n+\tif (!has_symlinks)\n+\t\treturn error(\"New workdir not possible without symlinks\");\n+\t/* make sure that GIT_DIR is an absolute path */\n+\tif ((absolute = make_absolute_path(git_dir)) != git_dir &&\n+\t\t\tsetup_new_git_dir(absolute))\n+\t\treturn 1;\n+\tif (!lstat(git_path(\"config\"), &st) && S_ISLNK(st.st_mode))\n+\t\treturn error(\"Will not create a workdir from a workdir\");\n+\tif (safe_create_leading_directories(path) ||\n+\t\t\tmkdir(path, 0777) || chdir(path))\n+\t\treturn error(\"Could not create '%s'\", path);\n+\tif (mkdir(DEFAULT_GIT_DIR_ENVIRONMENT, 0777) ||\n+\t\t\tchdir(DEFAULT_GIT_DIR_ENVIRONMENT) ||\n+\t\t\tmkdir(\"logs\", 0777))\n+\t\treturn error(\"Could not set up '%s/%s'\",\n+\t\t\t\tpath, DEFAULT_GIT_DIR_ENVIRONMENT);\n+\tfor (i = 0; links[i]; i++)\n+\t\tif (symlink(git_path(links[i]), links[i]))\n+\t\t\treturn error(\"Could not link '%s'\", links[i]);\n+\tif (chdir(\"..\") || setup_new_git_dir(DEFAULT_GIT_DIR_ENVIRONMENT))\n+\t\treturn error(\"Error setting up new workdir\");\n+\tfd = hold_locked_index(&lockfile, 1);\n+\tif (fd < 0)\n+\t\treturn error(\"Could not lock index\");\n+\tif (dwim_ref(branch_name, strlen(branch_name), sha1, &ref) != 1 ||\n+\t\t\tcreate_symref(\"HEAD\", ref, \"new workdir\") ||\n+\t\t\t!(object = parse_object(sha1)) ||\n+\t\t\tobject->type != OBJ_COMMIT)\n+\t\treturn error(\"Could not checkout HEAD\");\n+\tfree(ref);\n+\ttrees.item = &((struct commit *)object)->tree->object;\n+\ttrees.next = NULL;\n+\n+\tmemset(&opts, 0, sizeof(opts));\n+\topts.update = 1;\n+\topts.merge = 1;\n+\topts.head_idx = 1;\n+\topts.fn = oneway_merge;\n+\treturn unpack_trees(&trees, &opts) ||\n+\t\twrite_cache(fd, active_cache, active_nr) ||\n+\t\tclose(fd) || commit_locked_index(&lockfile);\n+}\n+\n int cmd_branch(int argc, const char **argv, const char *prefix)\n {\n \tint delete = 0, force_delete = 0, force_create = 0;\n@@ -507,6 +569,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \tint verbose = 0, abbrev = DEFAULT_ABBREV, detached = 0;\n \tint reflog = 0, track;\n \tint kinds = REF_LOCAL_BRANCH;\n+\tchar *new_workdir = NULL;\n \tint i;\n \n \tgit_config(git_branch_config);\n@@ -587,11 +650,17 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\t\tbranch_use_color = 0;\n \t\t\tcontinue;\n \t\t}\n+\t\tif (!strcmp(arg, \"--new-workdir\") || !strcmp(arg, \"-n\")) {\n+\t\t\tif (++i >= argc)\n+\t\t\t\tusage(builtin_branch_usage);\n+\t\t\tnew_workdir = xstrdup(argv[i]);\n+\t\t\tcontinue;\n+\t\t}\n \t\tusage(builtin_branch_usage);\n \t}\n \n \tif ((delete && rename) || (delete && force_create) ||\n-\t (rename && force_create))\n+\t (rename && force_create) || (new_workdir && (delete || rename)))\n \t\tusage(builtin_branch_usage);\n \n \thead = resolve_ref(\"HEAD\", head_sha1, 0, NULL);\n@@ -615,10 +684,12 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\trename_branch(head, argv[i], force_rename);\n \telse if (rename && (i == argc - 2))\n \t\trename_branch(argv[i], argv[i + 1], force_rename);\n-\telse if (i == argc - 1 || i == argc - 2)\n+\telse if (i == argc - 1 || i == argc - 2) {\n \t\tcreate_branch(argv[i], (i == argc - 2) ? argv[i+1] : head,\n \t\t\t force_create, reflog, track);\n-\telse\n+\t\tif (new_workdir)\n+\t\t\treturn create_new_workdir(new_workdir, argv[i]);\n+\t} else\n \t\tusage(builtin_branch_usage);\n \n \treturn 0;\ndiff --git a/t/t3200-branch.sh b/t/t3200-branch.sh\nindex ef1eeb7..d9ec82a 100755\n--- a/t/t3200-branch.sh\n+++ b/t/t3200-branch.sh\n@@ -202,4 +202,15 @@ test_expect_success \\\n \t test -f .git/logs/refs/heads/g/h/i &&\n \t diff expect .git/logs/refs/heads/g/h/i'\n \n+test_expect_success 'create new workdir' '\n+\tgit branch -n new-workdir forked &&\n+\ttest -d new-workdir &&\n+\t(cd new-workdir &&\n+\t test $HEAD = $(git rev-parse HEAD) &&\n+\t test refs/heads/forked = $(git symbolic-ref HEAD) &&\n+\t git fsck &&\n+\t git diff-files --quiet &&\n+\t git diff-index --quiet --cached HEAD)\n+'\n+\n test_done\n-- \n1.5.3.rc2.29.gc4640f\n"},{"id":"48173","messageId":"Pine.LNX.4.64.0707221511410.29679@iabervon.org","threadId":"9150","inReplyTo":"Pine.LNX.4.64.0707221956210.14781@racer.site","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-07-22T19:16:34Z","receivedAt":"2007-07-22T19:16:34Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 22 Jul 2007, Johannes Schindelin wrote:\n\n> A word of warning: switching to _same_ branch that is checked out in\n> the other repository is asking for trouble. You are really working not\n> only on the same object database, but also the same (i.e. not copied)\n> refs namespace.\n\nIt's probably time to revive Junio's patch for keeping the \nfully-dereferenced value of HEAD in the index, to make this safer.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"48175","messageId":"Pine.LNX.4.64.0707222023360.14781@racer.site","threadId":"9150","inReplyTo":"Pine.LNX.4.64.0707221511410.29679@iabervon.org","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-22T19:24:30Z","receivedAt":"2007-07-22T19:24:30Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 22 Jul 2007, Daniel Barkalow wrote:\n\n> On Sun, 22 Jul 2007, Johannes Schindelin wrote:\n> \n> > A word of warning: switching to _same_ branch that is checked out in\n> > the other repository is asking for trouble. You are really working not\n> > only on the same object database, but also the same (i.e. not copied)\n> > refs namespace.\n> \n> It's probably time to revive Junio's patch for keeping the \n> fully-dereferenced value of HEAD in the index, to make this safer.\n\nYeah, probably.\n\nAnyway, I will probably run with 'master'+this patch until 1.5.3 is \nreleased.\n\nCiao,\nDscho\n"},{"id":"48191","messageId":"Pine.LNX.4.64.0707222205050.23426@reaper.quantumfyre.co.uk","threadId":"9150","inReplyTo":"Pine.LNX.4.64.0707221956210.14781@racer.site","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-07-22T21:09:11Z","receivedAt":"2007-07-22T21:09:11Z","isPatch":true,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Sun, 22 Jul 2007, Johannes Schindelin wrote:\n\n>\n> Inspired by contrib/workdir/git-new-workdir, the flag --new-workdir (or\n> its shortcut, -n) can be used to create a new working directory for the\n> newly created branch. All information, except which branch is checked\n> out (and therefore also the index), will be symlinked from the current\n> repository.\n>\n> Example:\n>\n> \t$ git branch -n ~/my-new-topic xy-problem\n>\n> will create a branch called \"xy-problem\", which is initially identical\n> to the current branch, and check out the new branch in ~/my-new-topic/.\n> You will be able to cherry-pick from, log and diff with the branch\n> \"xy-problem\" in the current repository, since most of the metadata is\n> shared.\n>\n> Conversely, you can access all the branches in the current repository\n> from ~/my-new-topic/, too.\n>\n> A word of warning: switching to _same_ branch that is checked out in\n> the other repository is asking for trouble. You are really working not\n> only on the same object database, but also the same (i.e. not copied)\n> refs namespace.\n>\n> Signed-off-by: Johannes Schindelin \n> ---\n> \tIMHO this is a better syntax than what is in contrib/, and \"git\n> \tbranch\" is probably the right place for such a thing, from a\n> \tuser's perspective.\n\nSurely checkout would make more sense than branch? You are effectively \nchecking out into a new directory ... also you may want to get an existing \nbranch (certainly most of my usage of new-workdir is checking out existing \nbranches, e.g. to look at - as in build and play with - an interesting \nbranch that someone else has pushed out).\n\nDefinitely in favour of moving this into git proper though.\n\n-- \nJulian\n\n ---\nLack of capability is usually disguised by lack of interest.\n"},{"id":"48194","messageId":"Pine.LNX.4.64.0707222223460.14781@racer.site","threadId":"9150","inReplyTo":"Pine.LNX.4.64.0707222205050.23426@reaper.quantumfyre.co.uk","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-22T21:25:40Z","receivedAt":"2007-07-22T21:25:40Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 22 Jul 2007, Julian Phillips wrote:\n\n> On Sun, 22 Jul 2007, Johannes Schindelin wrote:\n> \n> > \tIMHO this is a better syntax than what is in contrib/, and \"git\n> > \tbranch\" is probably the right place for such a thing, from a\n> > \tuser's perspective.\n> \n> Surely checkout would make more sense than branch? You are effectively \n> checking out into a new directory ... also you may want to get an \n> existing branch (certainly most of my usage of new-workdir is checking \n> out existing branches, e.g. to look at - as in build and play with - an \n> interesting branch that someone else has pushed out).\n\nMy rationale here was:\n\n- to make sure that the user cannot check out the same branch as in the \n current repo, _or some other workdir of it_, and\n\n- to have finer grained lock control, as well as respecting has_symlinks.\n\nCiao,\nDscho\n"},{"id":"48202","messageId":"Pine.LNX.4.64.0707222234020.5382@reaper.quantumfyre.co.uk","threadId":"9150","inReplyTo":"Pine.LNX.4.64.0707222223460.14781@racer.site","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-07-22T21:50:20Z","receivedAt":"2007-07-22T21:50:20Z","isPatch":true,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Sun, 22 Jul 2007, Johannes Schindelin wrote:\n\n> Hi,\n>\n> On Sun, 22 Jul 2007, Julian Phillips wrote:\n>\n>> On Sun, 22 Jul 2007, Johannes Schindelin wrote:\n>>\n>>> \tIMHO this is a better syntax than what is in contrib/, and \"git\n>>> \tbranch\" is probably the right place for such a thing, from a\n>>> \tuser's perspective.\n>>\n>> Surely checkout would make more sense than branch? You are effectively\n>> checking out into a new directory ... also you may want to get an\n>> existing branch (certainly most of my usage of new-workdir is checking\n>> out existing branches, e.g. to look at - as in build and play with - an\n>> interesting branch that someone else has pushed out).\n>\n> My rationale here was:\n>\n> - to make sure that the user cannot check out the same branch as in the\n> current repo, _or some other workdir of it_, and\n\nSince you can checkout any branch you like once you have the workdir, \nthis is really an artificial limitation - you are protected when you \ncreate the workdir, but not after. This seems more likely to bite \nsomeone than just making them aware of the pitfalls before hand. One of \nthe main reasons that I aimed for contrib rather than proper git \noriginally was the ability to do bad things with realising.\n\nIf you want to have a workdir for an exisiting branch then you have to \ncreate a new one, and then switch it over. That seems like a really big \nusability wart to me ... certainly it would make the option pretty much \nuseless to me. My original motivation for the new-workdir script was to \ngive me the ability to flatten out branches from a single repo for when \nI'm working on multiple branches at the same time.\n\n> - to have finer grained lock control, as well as respecting has_symlinks.\n\nNot really sure what this means, since I am too tired to have read the \nactual patch - is it referring to the fact that checkout is shell rather \nthan C? If so, surely that is not really a good justification for putting \nthe option in the \"wrong\" command?\n\n-- \nJulian\n\n ---\nThud. Thud. Thud. Splat.\n -- (Terry Pratchett & Neil Gaiman, Good Omens)\n"},{"id":"48204","messageId":"Pine.LNX.4.64.0707222255010.14781@racer.site","threadId":"9150","inReplyTo":"Pine.LNX.4.64.0707222234020.5382@reaper.quantumfyre.co.uk","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-22T21:59:55Z","receivedAt":"2007-07-22T21:59:55Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 22 Jul 2007, Julian Phillips wrote:\n\n> On Sun, 22 Jul 2007, Johannes Schindelin wrote:\n> \n> > On Sun, 22 Jul 2007, Julian Phillips wrote:\n> > \n> > > On Sun, 22 Jul 2007, Johannes Schindelin wrote:\n> > > \n> > > > \tIMHO this is a better syntax than what is in contrib/, and \"git\n> > > > \tbranch\" is probably the right place for such a thing, from a\n> > > > \tuser's perspective.\n> > > \n> > > Surely checkout would make more sense than branch? You are effectively\n> > > checking out into a new directory ... also you may want to get an\n> > > existing branch (certainly most of my usage of new-workdir is checking\n> > > out existing branches, e.g. to look at - as in build and play with - an\n> > > interesting branch that someone else has pushed out).\n> > \n> > My rationale here was:\n> > \n> > - to make sure that the user cannot check out the same branch as in the\n> > current repo, _or some other workdir of it_, and\n> \n> Since you can checkout any branch you like once you have the workdir, \n> this is really an artificial limitation - you are protected when you \n> create the workdir, but not after.\n\nWell, it is not really an artificial limitation. IMHO it is much more \nlikely that you keep in mind what you should not do, when you have to work \naround such a limitation if you really want to do.\n\n> If you want to have a workdir for an exisiting branch then you have to create\n> a new one, and then switch it over. That seems like a really big usability\n> wart to me ... certainly it would make the option pretty much useless to me.\n> My original motivation for the new-workdir script was to give me the ability\n> to flatten out branches from a single repo for when I'm working on multiple\n> branches at the same time.\n\nNowadays, we have separate remotes layout by default. (Indeed, you cannot \neven disable it, as I found out recently). Which means that you already \nhave to branch off your local branch. So the consequences are lesser.\n\n> > - to have finer grained lock control, as well as respecting has_symlinks.\n> \n> Not really sure what this means, since I am too tired to have read the \n> actual patch - is it referring to the fact that checkout is shell rather \n> than C? If so, surely that is not really a good justification for \n> putting the option in the \"wrong\" command?\n\nWell, I am really not interested in shooting myself in the foot, and \nhaving that option in checkout would make that much more likely. So I \nreally, really want to have this in git-branch.\n\nOnce git-checkout is builtin, we can still come back and add this option \nto git-checkout (with a big fat red warning, to be sure); it is not like \nwe have git-branch and git-checkout functionality well separated...\n\nCiao,\nDscho\n"},{"id":"48223","messageId":"Pine.LNX.4.64.0707222302170.19212@reaper.quantumfyre.co.uk","threadId":"9150","inReplyTo":"Pine.LNX.4.64.0707222255010.14781@racer.site","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-07-22T22:24:48Z","receivedAt":"2007-07-22T22:24:48Z","isPatch":true,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Sun, 22 Jul 2007, Johannes Schindelin wrote:\n\n>>> - to make sure that the user cannot check out the same branch as in the\n>>> current repo, _or some other workdir of it_, and\n>>\n>> Since you can checkout any branch you like once you have the workdir,\n>> this is really an artificial limitation - you are protected when you\n>> create the workdir, but not after.\n>\n> Well, it is not really an artificial limitation. IMHO it is much more\n> likely that you keep in mind what you should not do, when you have to work\n> around such a limitation if you really want to do.\n\nWell, the point I was trying to make is that you _only_ protect them \nagainst the initial creation. The user can then happily shoot themselves \nin the foot. They can quite easily \"work around\" the limitation without \nrealising that they are. Say that you create a workdir for a new branch. \nThen a month later you want to do something to a branch you are working on \nin your main branch - but you are halfway through something complicated \nthat you haven't checked in, but you think \"aha! I still have that old \nworkdir, I can just switch it over and use that\" ...\n\nYou haven't made workdirs themselves safer - only the creation. You still \nneed a great big THIS CAN REALLY MESS THINGS UP warning.\n\n>\n>> If you want to have a workdir for an exisiting branch then you have to create\n>> a new one, and then switch it over. That seems like a really big usability\n>> wart to me ... certainly it would make the option pretty much useless to me.\n>> My original motivation for the new-workdir script was to give me the ability\n>> to flatten out branches from a single repo for when I'm working on multiple\n>> branches at the same time.\n>\n> Nowadays, we have separate remotes layout by default. (Indeed, you cannot\n> even disable it, as I found out recently). Which means that you already\n> have to branch off your local branch. So the consequences are lesser.\n\nThis is true - yet I still find that 99% of the time I am using \nnew-workdir to get an existing branch. Probably because there is usually \na delay between creating a local branch and needing to work on it in \nparallel.\n\nWorking pattern is something like:\n\nstart off with 0 workdirs - just using the original repo\n... work using 1 working copy - switching branch as needed ...\nneed to do two things in parallel - 1 workdir\n... work using 2 working copies - switching both/either as needed ...\nneed to do three things in parallel - 2 workdirs\n... work using 3 working copies - switching any/all as needed ...\n\netc. (sometimes removing workdirs as they are no longer needed too)\n\n>>> - to have finer grained lock control, as well as respecting has_symlinks.\n>>\n>> Not really sure what this means, since I am too tired to have read the\n>> actual patch - is it referring to the fact that checkout is shell rather\n>> than C? If so, surely that is not really a good justification for\n>> putting the option in the \"wrong\" command?\n>\n> Well, I am really not interested in shooting myself in the foot, and\n> having that option in checkout would make that much more likely. So I\n> really, really want to have this in git-branch.\n\nFair enough. Your patch - so you get to choose. I don't have any strong \nobjections (and no power to express any if I did :P) - just airing my POV \n;)\n\nI just think that to a user it feels like a checkout operation ... and \nthat would less confusing as an option to checkout. Trying to explain \nthat branch just creates a new branch, unless you give this option then it \ncreates a working copy over there seems more compilcated than saying the \ncheckout updates/creates this working copy, unless you use this option to \ncreate one over there.\n\n> Once git-checkout is builtin, we can still come back and add this option\n> to git-checkout (with a big fat red warning, to be sure); it is not like\n> we have git-branch and git-checkout functionality well separated...\n\nAs I said I have been thinking from a user POV not an implementation one \n...\n\nAssuming this patch goes in, then I'll probably update the new-workdir \nscript to keep it's existing syntax, but use your new option as mechanism \n... so that will let me keep doing things the way I am anyway ... ;)\n\nAnd as I said originally - you got my vote on this going into git proper \n_somewhere_ ...\n\n-- \nJulian\n\n ---\nWhen it is not necessary to make a decision, it is necessary not to\nmake a decision.\n"},{"id":"48230","messageId":"f80mbc$si1$1@sea.gmane.org","threadId":"9150","inReplyTo":"Pine.LNX.4.64.0707222302170.19212@reaper.quantumfyre.co.uk","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-07-22T22:46:29Z","receivedAt":"2007-07-22T22:46:29Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Julian Phillips wrote:\n\n> I just think that to a user it feels like a checkout operation ... and \n> that would less confusing as an option to checkout.  Trying to explain \n> that branch just creates a new branch, unless you give this option then it \n> creates a working copy over there seems more compilcated than saying the \n> checkout updates/creates this working copy, unless you use this option to \n> create one over there.\n\nIMVHO git-checkout is characterized that it changes _current_ working\ndirectory. But having this in git-checkout would mean that you can create\nnew workdir for _existing_ branch. git-branch is rather (except from\nlisting) for creating new branches.\n\nIt is a fact that functionalities of git-checkout (-b) and git-branch\n(--new-work-dir) intersect a bit.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"48236","messageId":"Pine.LNX.4.64.0707230000020.14781@racer.site","threadId":"9150","inReplyTo":"Pine.LNX.4.64.0707222302170.19212@reaper.quantumfyre.co.uk","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-22T23:02:09Z","receivedAt":"2007-07-22T23:02:09Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 22 Jul 2007, Julian Phillips wrote:\n\n> On Sun, 22 Jul 2007, Johannes Schindelin wrote:\n> \n> > Well, I am really not interested in shooting myself in the foot, and \n> > having that option in checkout would make that much more likely. So I \n> > really, really want to have this in git-branch.\n> \n> Fair enough. Your patch - so you get to choose. I don't have any \n> strong objections (and no power to express any if I did :P) - just \n> airing my POV ;)\n\n;-)\n\nIn related news, you got me convinced that my \"solution\" is not \nsufficient. So I guess this patch has to wait until after 1.5.3 _and_ \nafter we convinced Junio to put his BASE index extension in again.\n\nFWIW once git-checkout is builtin, I'll add \"--new-workdir\" for it. Deal?\n\nCiao,\nDscho\n"},{"id":"48240","messageId":"Pine.LNX.4.64.0707230033310.14781@racer.site","threadId":"9150","inReplyTo":"f80mbc$si1$1@sea.gmane.org","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-22T23:37:03Z","receivedAt":"2007-07-22T23:37:03Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\n[re Cc'ed Julian]\n\nOn Mon, 23 Jul 2007, Jakub Narebski wrote:\n\n> Julian Phillips wrote:\n> \n> > I just think that to a user it feels like a checkout operation ... and \n> > that would less confusing as an option to checkout. ?Trying to explain \n> > that branch just creates a new branch, unless you give this option \n> > then it creates a working copy over there seems more compilcated than \n> > saying the checkout updates/creates this working copy, unless you use \n> > this option to create one over there.\n> \n> IMVHO git-checkout is characterized that it changes _current_ working \n> directory.\n\nActually, the name suggests that the important action is \"checkout\", so I \nagree with Julian here.\n\n> But having this in git-checkout would mean that you can create new \n> workdir for _existing_ branch. git-branch is rather (except from \n> listing) for creating new branches.\n\nNote that it is possible to checkout the current branch with \"git checkout \nHEAD\". Indeed, you can get the same effect with \"git checkout -f HEAD\" as \nwith \"git reset --hard\" AFAIK.\n\n> It is a fact that functionalities of git-checkout (-b) and git-branch\n> (--new-work-dir) intersect a bit.\n\nYes, I pointed that out, too. But we're not Python, so we do not have to \npretend that it is a bad thing to have several way to do the same. Which \nallows us better to cater for user's expectations.\n\nCiao,\nDscho\n"},{"id":"48256","messageId":"20070723035644.GC32566@spearce.org","threadId":"9150","inReplyTo":"Pine.LNX.4.64.0707230000020.14781@racer.site","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-07-23T03:56:44Z","receivedAt":"2007-07-23T03:56:44Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> On Sun, 22 Jul 2007, Julian Phillips wrote:\n> \n> > On Sun, 22 Jul 2007, Johannes Schindelin wrote:\n> > \n> > > Well, I am really not interested in shooting myself in the foot, and \n> > > having that option in checkout would make that much more likely. So I \n> > > really, really want to have this in git-branch.\n> > \n> > Fair enough. Your patch - so you get to choose. I don't have any \n> > strong objections (and no power to express any if I did :P) - just \n> > airing my POV ;)\n> \n> In related news, you got me convinced that my \"solution\" is not \n> sufficient. So I guess this patch has to wait until after 1.5.3 _and_ \n> after we convinced Junio to put his BASE index extension in again.\n\nThe last time we had that thing in Git it really screwed with git-gui.\nI'm not looking forward to it coming back.\n\n\nBut anyway, I think there's something else that needs to be fixed\nbefore this symlink workdir thing is fully in core git. Right now we\ndelete the .git/config and .git/packed-refs files when we edit them.\nThis means it is *very* unsafe to run `git-config` or `git-tag -d`\nin a symlinked workdir, as the workdir will get its own config or\npacked-refs file and the real repository directory won't be affected.\n\nNow .git/config switching from symlink to real file is maybe almost\na feature.\n\nBut .git/packed-refs switching from symlink to real file is *not*\na feature. Its a massive bug.\n\nI live by new-workdir. I do everything with it. And today I just\nspent over an hour sorting out cases where my many, many workdirs\nhave different refs than their base repositories, because their\npacked-refs files are different. Grrrrrrrrrrrrrrrrrr.\n\n\nSo we really need to make anyone that edits packed-refs (and\nmaybe also config) resolve the symlink and do the edit in the\ntarget directory. Then we can consider adding this workdir thing\nto core git.\n\nYes, I know, stop whining and submit a patch. I'll get around to\nit soon if nobody else beats me. I just want to voice yet another\nreason why this shouldn't be in 1.5.3.\n\n-- \nShawn.\n"},{"id":"48261","messageId":"7v1wezohi4.fsf@assigned-by-dhcp.cox.net","threadId":"9150","inReplyTo":"20070723035644.GC32566@spearce.org","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-23T04:45:23Z","receivedAt":"2007-07-23T04:45:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> I live by new-workdir. I do everything with it. And today I just\n> spent over an hour sorting out cases where my many, many workdirs\n> have different refs than their base repositories, because their\n> packed-refs files are different. Grrrrrrrrrrrrrrrrrr.\n>\n> So we really need to make anyone that edits packed-refs (and\n> maybe also config) resolve the symlink and do the edit in the\n> target directory. Then we can consider adding this workdir thing\n> to core git.\n\nThis is actually not limited to packed-refs file, but applies to\nother things as well.\n\nI have been wondering if something like this patch would be\nsufficient. The idea essentially is to take the lock on the\nlink target when we try to take a lock on something that is a\nsymlink pointing elsewhere.\n\n---\n\n lockfile.c | 11 +++++++++++\n 1 files changed, 11 insertions(+), 0 deletions(-)\n\ndiff --git a/lockfile.c b/lockfile.c\nindex fb8f13b..7fc71d9 100644\n--- a/lockfile.c\n+++ b/lockfile.c\n@@ -28,6 +28,17 @@ static void remove_lock_file_on_signal(int signo)\n static int lock_file(struct lock_file *lk, const char *path)\n {\n \tint fd;\n+\tstruct stat st;\n+\n+\tif ((!lstat(path, &st)) && S_ISLNK(st.st_mode)) {\n+\t\tssize_t sz;\n+\t\tstatic char target[PATH_MAX];\n+\t\tsz = readlink(path, target, sizeof(target));\n+\t\tif (sz < 0)\n+\t\t\twarning(\"Cannot readlink %s\", path);\n+\t\telse\n+\t\t\tpath = target;\n+\t}\n \tsprintf(lk->filename, \"%s.lock\", path);\n \tfd = open(lk->filename, O_RDWR | O_CREAT | O_EXCL, 0666);\n \tif (0 <= fd) {\n"},{"id":"48263","messageId":"20070723051437.GE32566@spearce.org","threadId":"9150","inReplyTo":"7v1wezohi4.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-07-23T05:14:37Z","receivedAt":"2007-07-23T05:14:37Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> \"Shawn O. Pearce\" writes:\n> \n> > I live by new-workdir. I do everything with it. And today I just\n> > spent over an hour sorting out cases where my many, many workdirs\n> > have different refs than their base repositories, because their\n> > packed-refs files are different. Grrrrrrrrrrrrrrrrrr.\n> >\n> > So we really need to make anyone that edits packed-refs (and\n> > maybe also config) resolve the symlink and do the edit in the\n> > target directory. Then we can consider adding this workdir thing\n> > to core git.\n> \n> This is actually not limited to packed-refs file, but applies to\n> other things as well.\n\nYes, but most other things aren't symlinks, they are in symlinked\ndirectories. But better to cover it in a single location and have\nit Just Work(tm) then to special case things.\n \n> diff --git a/lockfile.c b/lockfile.c\n> index fb8f13b..7fc71d9 100644\n> --- a/lockfile.c\n> +++ b/lockfile.c\n> @@ -28,6 +28,17 @@ static void remove_lock_file_on_signal(int signo)\n> static int lock_file(struct lock_file *lk, const char *path)\n> {\n> \tint fd;\n> +\tstruct stat st;\n> +\n> +\tif ((!lstat(path, &st)) && S_ISLNK(st.st_mode)) {\n> +\t\tssize_t sz;\n> +\t\tstatic char target[PATH_MAX];\n> +\t\tsz = readlink(path, target, sizeof(target));\n> +\t\tif (sz < 0)\n> +\t\t\twarning(\"Cannot readlink %s\", path);\n> +\t\telse\n> +\t\t\tpath = target;\n> +\t}\n> \tsprintf(lk->filename, \"%s.lock\", path);\n> \tfd = open(lk->filename, O_RDWR | O_CREAT | O_EXCL, 0666);\n> \tif (0 <= fd) {\n\nRight. But don't you have to resolve target relative to path?\nIf the symlink is an absolute path its fine as-is, but if it was\nrelative its relative to path, not pwd.\n\n-- \nShawn.\n"},{"id":"48265","messageId":"20070723052224.GF32566@spearce.org","threadId":"9150","inReplyTo":"20070723051437.GE32566@spearce.org","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-07-23T05:22:24Z","receivedAt":"2007-07-23T05:22:24Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"Shawn O. Pearce\" wrote:\n> Junio C Hamano wrote:\n> > static int lock_file(struct lock_file *lk, const char *path)\n> > {\n> > \tint fd;\n> > +\tstruct stat st;\n> > +\n> > +\tif ((!lstat(path, &st)) && S_ISLNK(st.st_mode)) {\n> > +\t\tssize_t sz;\n> > +\t\tstatic char target[PATH_MAX];\n> > +\t\tsz = readlink(path, target, sizeof(target));\n> > +\t\tif (sz < 0)\n> > +\t\t\twarning(\"Cannot readlink %s\", path);\n> > +\t\telse\n> > +\t\t\tpath = target;\n> > +\t}\n> > \tsprintf(lk->filename, \"%s.lock\", path);\n> > \tfd = open(lk->filename, O_RDWR | O_CREAT | O_EXCL, 0666);\n> > \tif (0 <= fd) {\n> \n> Right. But don't you have to resolve target relative to path?\n> If the symlink is an absolute path its fine as-is, but if it was\n> relative its relative to path, not pwd.\n\nIt might just be OK to refuse to lock a symlink that isn't absolute.\ngit-new-workdir already uses absolute paths to setup the symlinks.\n\n-- \nShawn.\n"},{"id":"48283","messageId":"Pine.LNX.4.64.0707230930140.20832@reaper.quantumfyre.co.uk","threadId":"9150","inReplyTo":"Pine.LNX.4.64.0707230000020.14781@racer.site","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-07-23T08:31:36Z","receivedAt":"2007-07-23T08:31:36Z","isPatch":true,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Mon, 23 Jul 2007, Johannes Schindelin wrote:\n\n> Hi,\n>\n> On Sun, 22 Jul 2007, Julian Phillips wrote:\n>\n>> On Sun, 22 Jul 2007, Johannes Schindelin wrote:\n>>\n>>> Well, I am really not interested in shooting myself in the foot, and\n>>> having that option in checkout would make that much more likely. So I\n>>> really, really want to have this in git-branch.\n>>\n>> Fair enough. Your patch - so you get to choose. I don't have any\n>> strong objections (and no power to express any if I did :P) - just\n>> airing my POV ;)\n>\n> ;-)\n>\n> In related news, you got me convinced that my \"solution\" is not\n> sufficient. So I guess this patch has to wait until after 1.5.3 _and_\n> after we convinced Junio to put his BASE index extension in again.\n>\n> FWIW once git-checkout is builtin, I'll add \"--new-workdir\" for it. Deal?\n\nSounds good to me. Even gives me some motivation to see checkout a \nbuiltin sooner rather than later ;)\n\n-- \nJulian\n\n ---\nLogic is the chastity belt of the mind!\n"},{"id":"48295","messageId":"Pine.LNX.4.64.0707231129010.14781@racer.site","threadId":"9150","inReplyTo":"7v1wezohi4.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-23T10:32:01Z","receivedAt":"2007-07-23T10:32:01Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 22 Jul 2007, Junio C Hamano wrote:\n\n> @@ -28,6 +28,17 @@ static void remove_lock_file_on_signal(int signo)\n> static int lock_file(struct lock_file *lk, const char *path)\n> {\n> \tint fd;\n> +\tstruct stat st;\n> +\n> +\tif ((!lstat(path, &st)) && S_ISLNK(st.st_mode)) {\n> +\t\tssize_t sz;\n> +\t\tstatic char target[PATH_MAX];\n> +\t\tsz = readlink(path, target, sizeof(target));\n> +\t\tif (sz < 0)\n> +\t\t\twarning(\"Cannot readlink %s\", path);\n> +\t\telse\n> +\t\t\tpath = target;\n> +\t}\n\nI wonder if we should not make this a while loop:\n\n\tstruct stat st;\n\tint i = 0;\n\n\twhile (i++ < 10 && !lstat(path, &st) && S_ISLNK(st.st_mode)) {\n\t\tssize_t sz;\n\t\tstatic char target[PATH_MAX];\n\t\tsz = readlink(path, target, sizeof(target));\n\t\tif (sz < 0)\n\t\t\tdie(\"Cannot readlink %s\", path);\n\t\telse\n\t\t\tpath = target;\n\t}\n\tif (i == 10)\n\t\tdie (\"Too deep symlink depth: %s\", path);\n\n(As you see, I would not warn, but die if readlink fails.)\n\nCiao,\nDscho\n"},{"id":"48297","messageId":"Pine.LNX.4.64.0707231141080.14781@racer.site","threadId":"9150","inReplyTo":"Pine.LNX.4.64.0707231129010.14781@racer.site","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-23T10:42:18Z","receivedAt":"2007-07-23T10:42:18Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 23 Jul 2007, Johannes Schindelin wrote:\n\n> \tstruct stat st;\n> \tint i = 0;\n> \n> \twhile (i++ < 10 && !lstat(path, &st) && S_ISLNK(st.st_mode)) {\n> \t\tssize_t sz;\n> \t\tstatic char target[PATH_MAX];\n> \t\tsz = readlink(path, target, sizeof(target));\n> \t\tif (sz < 0)\n> \t\t\tdie(\"Cannot readlink %s\", path);\n> \t\telse\n> \t\t\tpath = target;\n\nProbably this should be \"make_absolute_path(target)\" after applying the \nminipatch I provided elsewhere.\n\nCiao,\nDscho\n"},{"id":"48405","messageId":"46A5B5F5.6000202@trolltech.com","threadId":"9150","inReplyTo":"7v1wezohi4.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-07-24T08:19:01Z","receivedAt":"2007-07-24T08:19:01Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":">> I live by new-workdir. I do everything with it. And today I\n>> just spent over an hour sorting out cases where my many, many\n>> workdirs have different refs than their base repositories,\n>> because their packed-refs files are different.\n>> Grrrrrrrrrrrrrrrrrr.\n>> \n>> So we really need to make anyone that edits packed-refs (and \n>> maybe also config) resolve the symlink and do the edit in the \n>> target directory. Then we can consider adding this workdir thing\n>> to core git.\n> \n> This is actually not limited to packed-refs file, but applies to \n> other things as well.\n> \n> I have been wondering if something like this patch would be \n> sufficient. The idea essentially is to take the lock on the link\n> target when we try to take a lock on something that is a symlink\n> pointing elsewhere.\n(..snip..)\n\nWhile you guys are discussing this, please please keep in mind that \nthere are Windows users (/me raises his hand) out there that really \nreally want this too. So, please try to keep it light on the symlinks.\n\n-- \n.marius\n\n"},{"id":"48410","messageId":"Pine.LNX.4.64.0707241002410.14781@racer.site","threadId":"9150","inReplyTo":"46A5B5F5.6000202@trolltech.com","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-24T09:02:58Z","receivedAt":"2007-07-24T09:02:58Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 24 Jul 2007, Marius Storm-Olsen wrote:\n\n> > > I live by new-workdir. I do everything with it. And today I\n> > > just spent over an hour sorting out cases where my many, many\n> > > workdirs have different refs than their base repositories,\n> > > because their packed-refs files are different.\n> > > Grrrrrrrrrrrrrrrrrr.\n> > > \n> > > So we really need to make anyone that edits packed-refs (and maybe also\n> > > config) resolve the symlink and do the edit in the target directory. Then\n> > > we can consider adding this workdir thing\n> > > to core git.\n> > \n> > This is actually not limited to packed-refs file, but applies to other\n> > things as well.\n> > \n> > I have been wondering if something like this patch would be sufficient. The\n> > idea essentially is to take the lock on the link\n> > target when we try to take a lock on something that is a symlink\n> > pointing elsewhere.\n> (..snip..)\n> \n> While you guys are discussing this, please please keep in mind that there are\n> Windows users (/me raises his hand) out there that really really want this\n> too. So, please try to keep it light on the symlinks.\n\nEasy: use cygwin.\n\nOkay, a bit more seriously again: in the recent weeks, it seems that more \nand more Windows users are asking for features. Since I guess you are a \ndeveloper (why else would you want to use git), IMHO it is your itch to \nscratch.\n\nCiao,\nDscho\n\nP.S.: Sorry if this came over as rude, but I am growing slightly annoyed \nby the expectation of so many that since it is Open Source, I should work \nfor free.\n"},{"id":"48421","messageId":"7vd4yigmla.fsf@assigned-by-dhcp.cox.net","threadId":"9150","inReplyTo":"Pine.LNX.4.64.0707241002410.14781@racer.site","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-24T09:47:13Z","receivedAt":"2007-07-24T09:47:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> While you guys are discussing this, please please keep in mind that there are\n>> Windows users (/me raises his hand) out there that really really want this\n>> too. So, please try to keep it light on the symlinks.\n>\n> Easy: use cygwin.\n>\n> Okay, a bit more seriously again: in the recent weeks, it seems that more \n> and more Windows users are asking for features. Since I guess you are a \n> developer (why else would you want to use git), IMHO it is your itch to \n> scratch.\n\nI do not know this is an appropriate itch to scratch for a\nWindows developer to begin with. The new-workdir setting *is*\nabout symlinked .git/ metainfo space. If somebody wants to work\non a filesystem without symlink, he should not be using\nnew-workdir but something else. E.g. GIT_DIR + GIT_WORK_TREE,\nor perhaps GIT_DIR + core.worktree comes to mind.\n"},{"id":"48437","messageId":"Pine.LNX.4.64.0707241207390.14781@racer.site","threadId":"9150","inReplyTo":"7vd4yigmla.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-24T11:07:59Z","receivedAt":"2007-07-24T11:07:59Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 24 Jul 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> >> While you guys are discussing this, please please keep in mind that there are\n> >> Windows users (/me raises his hand) out there that really really want this\n> >> too. So, please try to keep it light on the symlinks.\n> >\n> > Easy: use cygwin.\n> >\n> > Okay, a bit more seriously again: in the recent weeks, it seems that more \n> > and more Windows users are asking for features. Since I guess you are a \n> > developer (why else would you want to use git), IMHO it is your itch to \n> > scratch.\n> \n> I do not know this is an appropriate itch to scratch for a\n> Windows developer to begin with. The new-workdir setting *is*\n> about symlinked .git/ metainfo space. If somebody wants to work\n> on a filesystem without symlink, he should not be using\n> new-workdir but something else. E.g. GIT_DIR + GIT_WORK_TREE,\n> or perhaps GIT_DIR + core.worktree comes to mind.\n\n... which reminds me that I wanted to overhaul that patch series.\n\nCiao,\nDscho\n"},{"id":"48439","messageId":"46A5DF1F.2030307@trolltech.com","threadId":"9150","inReplyTo":"7vd4yigmla.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-07-24T11:14:39Z","receivedAt":"2007-07-24T11:14:39Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Junio C Hamano said the following on 24.07.2007 11:47:\n> Johannes Schindelin writes:\n>>> While you guys are discussing this, please please keep in mind\n>>> that there are Windows users (/me raises his hand) out there\n>>> that really really want this too. So, please try to keep it\n>>> light on the symlinks.\n>> Easy: use cygwin.\n>> \n>> Okay, a bit more seriously again: in the recent weeks, it seems\n>> that more and more Windows users are asking for features. Since\n>> I guess you are a developer (why else would you want to use git),\n>> IMHO it is your itch to scratch.\n\nYes, I fully agree with this, and I don't have the attitude that \nothers should work for me. I'm trying to free up some 'spare time' \nresources so I can pitch in on the effort of making Git work neatly on \nWindows. However, I feared I won't be able to get working on it before \nyou guys had decided on a design, so I just wanted voice my opinion on \nthe design, so Windows users are not lost in this.\n\n\n> I do not know this is an appropriate itch to scratch for a Windows\n> developer to begin with. The new-workdir setting *is* about\n> symlinked .git/ metainfo space. If somebody wants to work on a\n> filesystem without symlink, he should not be using new-workdir but\n> something else. E.g. GIT_DIR + GIT_WORK_TREE, or perhaps GIT_DIR +\n> core.worktree comes to mind.\n\nThat's is definitely an option, though it seems to me that its more \nlike giving up than a finding a proper solution. In any case, it would \nresult in two completely different workflows on systems with and \nwithout symlink support. I work on both, and would like my workflow to \nbe consistent. Of course I could easily add my own scripts on top to \nachieve this, but then we're going back into h4x0r land and not making \nGit more 'available'.\n\nThe new-workdir feature doesn't *have* to be about symlinked .git/ \nmetainfo space, but could also be about symref'ed .git/ metainfo.\n(A discussion was done in 2005s \"Getting rid of symlinks in .git?\", \nbut the conclusion was that it would slow it down too much? *ponder*)\n\nI think you're right in that this is probably not the appropriate itch \nto scratch for a Windows developer to start with, and I have my own \nlist of issues to work on when I get the time. File stat'ing \n(daemon/service), CRLF issues, de-SH'ifying commands, non-MinGW native \nbuild of Git, etc.. Lots to keep my fingers busy :-)\n\nThough, let me also say that I already love working with Git on \nWindows. And I thank each and every one who's working on it, for \nproviding such an excellent tool.\n\n-- \n.marius\n\n"},{"id":"48449","messageId":"Pine.LNX.4.64.0707241252040.28577@reaper.quantumfyre.co.uk","threadId":"9150","inReplyTo":"46A5DF1F.2030307@trolltech.com","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-07-24T12:06:29Z","receivedAt":"2007-07-24T12:06:29Z","isPatch":true,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Tue, 24 Jul 2007, Marius Storm-Olsen wrote:\n\n>> I do not know this is an appropriate itch to scratch for a Windows\n>> developer to begin with. The new-workdir setting *is* about\n>> symlinked .git/ metainfo space. If somebody wants to work on a\n>> filesystem without symlink, he should not be using new-workdir but\n>> something else. E.g. GIT_DIR + GIT_WORK_TREE, or perhaps GIT_DIR +\n>> core.worktree comes to mind.\n>\n> That's is definitely an option, though it seems to me that its more like \n> giving up than a finding a proper solution. In any case, it would result in \n> two completely different workflows on systems with and without symlink \n> support. I work on both, and would like my workflow to be consistent. Of \n> course I could easily add my own scripts on top to achieve this, but then \n> we're going back into h4x0r land and not making Git more 'available'.\n>\n> The new-workdir feature doesn't *have* to be about symlinked .git/ metainfo \n> space, but could also be about symref'ed .git/ metainfo.\n> (A discussion was done in 2005s \"Getting rid of symlinks in .git?\", but the \n> conclusion was that it would slow it down too much? *ponder*)\n\nSymref'ed isn't really the right term ... we're not talking about refs \nhere. You would have to basically implement symlinks _inside_ git ...\n\nNew-workdir really _is_ all about symlinks. It already exists as a \ncontrib feature - and moving it into core is (as I understand it) really \njust moving it, not redesigning.\n\nIf you were going to avoid symlinks, then probably the cleanest way would \nbe to have an explict way to point at the actual repo - rather than making \nthe working look like a repo if you squint hard enough. Which sounds \nrather like it would be an extension to GIT_DIR + GIT_WORK_TREE. I \nhaven't looked at it, but it shouldn't be too hard to have a mechanism \nthat automatically does GIT_DIR= GIT_WORK_TREE== when the \nappropriate setup is in place? Though you would have to get it into all \nthe appropriate places ...\n\n-- \nJulian\n\n ---\n coffee on an empty stomach is pretty nasy\n aav: time to run to the vending machine for cheetos\n cheetos? :)\n"},{"id":"48451","messageId":"46A5F066.9040201@trolltech.com","threadId":"9150","inReplyTo":"Pine.LNX.4.64.0707241252040.28577@reaper.quantumfyre.co.uk","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-07-24T12:28:22Z","receivedAt":"2007-07-24T12:28:22Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":">> The new-workdir feature doesn't *have* to be about symlinked\n>> .git/ metainfo space, but could also be about symref'ed .git/\n>> metainfo. (A discussion was done in 2005s \"Getting rid of\n>> symlinks in .git?\", but the conclusion was that it would slow it\n>> down too much? *ponder*)\n> \n> Symref'ed isn't really the right term ... we're not talking about\n> refs here. You would have to basically implement symlinks _inside_\n> git ...\n\nYes, sorry for mixing up the terms here.\n\n> New-workdir really _is_ all about symlinks. It already exists as a\n> contrib feature - and moving it into core is (as I understand it)\n> really just moving it, not redesigning.\n\nYes, if simply moving into is core is good enough. IMHO since its \nbased largely on FS symlinks it needs a slight redesign before it can \nbe moved into core to make it platform agnostic. If not, it should \nremain contrib [again, IMHO].\n\n> If you were going to avoid symlinks, then probably the cleanest way\n> would be to have an explict way to point at the actual repo -\n> rather than making the working look like a repo if you squint hard\n> enough. Which sounds rather like it would be an extension to\n> GIT_DIR + GIT_WORK_TREE. I haven't looked at it, but it shouldn't\n> be too hard to have a mechanism that automatically does\n> GIT_DIR= GIT_WORK_TREE== when the appropriate setup is\n> in place? Though you would have to get it into all the appropriate\n> places ...\n\n*nod*\n\n-- \n.marius\n\n"},{"id":"48452","messageId":"Pine.LNX.4.64.0707241336090.14781@racer.site","threadId":"9150","inReplyTo":"Pine.LNX.4.64.0707241252040.28577@reaper.quantumfyre.co.uk","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-24T12:37:41Z","receivedAt":"2007-07-24T12:37:41Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 24 Jul 2007, Julian Phillips wrote:\n\n> If you were going to avoid symlinks, then probably the cleanest way would be\n> to have an explict way to point at the actual repo - rather than making the\n> working look like a repo if you squint hard enough. Which sounds rather like\n> it would be an extension to GIT_DIR + GIT_WORK_TREE.\n\nAlmost. .git/{config,HEAD} are not shared. So it would be some extension \nthat is triggered by something like\n\n\t[core]\n\t\trealGitDir = /bla/bla/.git/\n\nHmm?\n\nCiao,\nDscho\n"},{"id":"48453","messageId":"Pine.LNX.4.64.0707241337470.14781@racer.site","threadId":"9150","inReplyTo":"46A5DF1F.2030307@trolltech.com","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-24T12:42:27Z","receivedAt":"2007-07-24T12:42:27Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 24 Jul 2007, Marius Storm-Olsen wrote:\n\n> The new-workdir feature doesn't *have* to be about symlinked .git/ \n> metainfo space, but could also be about symref'ed .git/ metainfo. (A \n> discussion was done in 2005s \"Getting rid of symlinks in .git?\", but the \n> conclusion was that it would slow it down too much? *ponder*)\n\nRight. I would not do it as symrefs, but as a (potentially ugly, but \nsmall) change to have the git_dir set to the shared one, and only in case \nof config and HEAD resort to the new_worktree_git_dir.\n\nThis would probably be one variable in environment.c, exported in cache.h, \nset in config.c (which would say \"new_worktree_git_dir = get_git_dir(); \nsetup_new_git_dir(value);\"), and the appropriate special handling in\ngit_path() in path.c.\n\n> I think you're right in that this is probably not the appropriate itch \n> to scratch for a Windows developer to start with, and I have my own list \n> of issues to work on when I get the time. File stat'ing \n> (daemon/service), CRLF issues, de-SH'ifying commands, non-MinGW native \n> build of Git, etc.. Lots to keep my fingers busy :-)\n\n;-)\n\nBTW a friend reported a CRLF issue on Windows, _in spite_ of setting the \ngitattributes appropriately... Did you ever get something like that?\n\n> Though, let me also say that I already love working with Git on Windows. \n> And I thank each and every one who's working on it, for providing such \n> an excellent tool.\n\nGood to hear!\n\nCiao,\nDscho\n"},{"id":"48457","messageId":"46A5FDF0.3060801@trolltech.com","threadId":"9150","inReplyTo":"Pine.LNX.4.64.0707241337470.14781@racer.site","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-07-24T13:26:08Z","receivedAt":"2007-07-24T13:26:08Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":" > BTW a friend reported a CRLF issue on Windows, _in spite_ of\n > setting the gitattributes appropriately... Did you ever get\n > something like that?\n\nHmm, I haven't really had problems with the gitattributes files in the \ndirectory of the file to be ignored, but rather .git/info/attributes.\n\nThere I have had problems with directories containing spaces. The \nescaping of the spaces doesn't work, so even if you do\n foo/bar\\ baz/file.txt -crlf\nit doesn't work. So, you have to do\n foo/*/file.txt -crlf\ninstead.\n\n\nI mainly have the problem with the following:\n\n1) User on Windows is using MinGW port or Cygwin setup with\n DOS EOL.\n2) Has core.autocrlf=true\n3) Files for XML testcases (for example) is checked into\n repo on Linux (File contains CRLF EOL, since its crucial\n for testing the XML parser)\n4) git diff shows all lineending changed, since the\n autocrlf tries to convert the files which are really\n checked into the repo with DOS EOL.\n\n5) You end up adding a bunch of\n foo/bar/baz/* -crlf\n into your .git/info/attributes file or the like.\n\n\nSo, it's look like this ('yes' mean CRLF EOL):\n Repo | Working dir | Convert EOL?\n ---------------------------------\n1) - LF no\n2) - CRLF yes\n3) LF LF no\n4) LF CRLF yes\n5) CRLF LF no\n6) CRLF CRLF yes\n\nThe problem is that currently 6) is 'yes', and turns the file into a \nLF file, which it shouldn't.\n\nSo, to fix the problem the crlf convertor should really check if the \nfile has crlf EOL in the repo, if so, avoid EOL conversion. (6) should \nbe 'no' :-)\n\n-- \n.marius\n\n"},{"id":"48458","messageId":"46A5FEA1.3030300@trolltech.com","threadId":"9150","inReplyTo":"46A5FDF0.3060801@trolltech.com","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-07-24T13:29:05Z","receivedAt":"2007-07-24T13:29:05Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Marius Storm-Olsen said the following on 24.07.2007 15:26:\n> So, it's look like this ('yes' mean CRLF EOL):\n\nBah, ignore \"('yes' mean CRLF EOL)\". I rewrote the table and forgot to \nnuke that part.\n\n-- \n.marius\n\n"},{"id":"48460","messageId":"Pine.LNX.4.64.0707241431540.14781@racer.site","threadId":"9150","inReplyTo":"46A5FDF0.3060801@trolltech.com","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-24T13:33:04Z","receivedAt":"2007-07-24T13:33:04Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 24 Jul 2007, Marius Storm-Olsen wrote:\n\n> So, it's look like this ('yes' mean CRLF EOL):\n> Repo | Working dir | Convert EOL?\n> ---------------------------------\n> 1) - LF no\n> 2) - CRLF yes\n> 3) LF LF no\n> 4) LF CRLF yes\n> 5) CRLF LF no\n> 6) CRLF CRLF yes\n> \n> The problem is that currently 6) is 'yes', and turns the file into a LF file,\n> which it shouldn't.\n\nShouldn't it? But then you should set core.autocrlf = false, no?\n\nAFAIU the purpose of autocrlf is to _always_ have UNIX line endings in the \nchecked in stuff.\n\nCiao,\nDscho\n"},{"id":"48466","messageId":"200707241547.16681.Josef.Weidendorfer@gmx.de","threadId":"9150","inReplyTo":"Pine.LNX.4.64.0707241336090.14781@racer.site","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2007-07-24T13:47:15Z","receivedAt":"2007-07-24T13:47:15Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Tuesday 24 July 2007, Johannes Schindelin wrote:\n> Hi,\n> \n> On Tue, 24 Jul 2007, Julian Phillips wrote:\n> \n> > If you were going to avoid symlinks, then probably the cleanest way would be\n> > to have an explict way to point at the actual repo - rather than making the\n> > working look like a repo if you squint hard enough. Which sounds rather like\n> > it would be an extension to GIT_DIR + GIT_WORK_TREE.\n> \n> Almost. .git/{config,HEAD} are not shared.\n\n.git/index, too. And for .git/config, it would probably be better to merge the\ntwo config's (the one from \"realGitDir\" with 2nd priority).\n\n> So it would be some extension \n> that is triggered by something like\n> \n> \t[core]\n> \t\trealGitDir = /bla/bla/.git/\n\nThat is more or less almost exacty the last agreement about how to\nimplement the lightweight checkouts, a few months ago.\n\nShould this even work recursively?\n\nJosef\n"},{"id":"48469","messageId":"Pine.LNX.4.64.0707241453350.14781@racer.site","threadId":"9150","inReplyTo":"200707241547.16681.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-24T13:54:58Z","receivedAt":"2007-07-24T13:54:58Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 24 Jul 2007, Josef Weidendorfer wrote:\n\n> On Tuesday 24 July 2007, Johannes Schindelin wrote:\n> \n> > On Tue, 24 Jul 2007, Julian Phillips wrote:\n> > \n> > > If you were going to avoid symlinks, then probably the cleanest way would be\n> > > to have an explict way to point at the actual repo - rather than making the\n> > > working look like a repo if you squint hard enough. Which sounds rather like\n> > > it would be an extension to GIT_DIR + GIT_WORK_TREE.\n> > \n> > Almost. .git/{config,HEAD} are not shared.\n> \n> .git/index, too. And for .git/config, it would probably be better to merge the\n> two config's (the one from \"realGitDir\" with 2nd priority).\n\nI blame it on me being tired. .git/config _is_ shared, and I meant to \nwrite \"index\" instead of \"config\" there. Not really a typo, is it?\n\n> > So it would be some extension \n> > that is triggered by something like\n> > \n> > \t[core]\n> > \t\trealGitDir = /bla/bla/.git/\n> \n> That is more or less almost exacty the last agreement about how to\n> implement the lightweight checkouts, a few months ago.\n\nOh? I saw no code... To me it is not an agreement, if no code comes out \nof it.\n\nCiao,\nDscho\n"},{"id":"48473","messageId":"200707241621.41719.Josef.Weidendorfer@gmx.de","threadId":"9150","inReplyTo":"Pine.LNX.4.64.0707241453350.14781@racer.site","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2007-07-24T14:21:41Z","receivedAt":"2007-07-24T14:21:41Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Tuesday 24 July 2007, Johannes Schindelin wrote:\n> > > So it would be some extension \n> > > that is triggered by something like\n> > > \n> > > \t[core]\n> > > \t\trealGitDir = /bla/bla/.git/\n> > \n> > That is more or less almost exacty the last agreement about how to\n> > implement the lightweight checkouts, a few months ago.\n> \n> Oh? I saw no code... To me it is not an agreement, if no code comes out \n> of it.\n\nHmm. Probably depends on any real need for the feature agreed upon.\nThe new-workdir script simply was \"good enough\" with Linux.\n\nJosef\n"},{"id":"48494","messageId":"46A63EAA.6080203@trolltech.com","threadId":"9150","inReplyTo":"Pine.LNX.4.64.0707241431540.14781@racer.site","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-07-24T18:02:18Z","receivedAt":"2007-07-24T18:02:18Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":">> So, it's look like this ('yes' mean CRLF EOL):\n>> Repo | Working dir | Convert EOL?\n>> ---------------------------------\n>> 1) - LF no\n>> 2) - CRLF yes\n>> 3) LF LF no\n>> 4) LF CRLF yes\n>> 5) CRLF LF no\n>> 6) CRLF CRLF yes\n>>\n>> The problem is that currently 6) is 'yes', and turns the file into\n>> a LF file, which it shouldn't.\n> \n> Shouldn't it? But then you should set core.autocrlf = false, no?\n> \n> AFAIU the purpose of autocrlf is to _always_ have UNIX line endings\n> in the checked in stuff.\n\nI realize that I might be talking 'out of context', so to speak; so it's\nhard to see where I'm going with this. So, I'll start from the\nbeginning. :-)\n\n1) IMO, git should on Windows always do CRLF conversion, as this is what\nWindows developers in general expect. (CRLF text-files that is, not the\nconversion.) Meaning that\n core.autocrlf = Windows\nby default. Where 'Windows' would be of true/false value which is true\nwhen on Windows and false when on other platforms. (Not that we should\n_have_ such an option, but the concept at least.)\n\n2) Most Windows developers in the category above currently do\n git-config --global core.autocrlf true\nonce, and be done with it.\nHowever, for every text-file they want in the repo which _should_\ncontain CRLF EOLs they would have to add this file to either a\n.gitattributes file in that same directory, or to\n .git/info/attributes\nwith the\n -crlf\nto ensure that the autocrlf conversion is not triggered for those files.\nNow, for Unix users that seems like a small price to pay, and of course\n_they_ don't have to worry about it. It's up to the Windows developers\nto take the pain and add these .gitattributes files, and keep track\nwhenever new CRLF files appear in the repo from other non-Windows\ndevelopers.\n\n3) My suggestion in the previous mail would to a large extent alleviate\nthis problem, since once in the repo with CRLF lineendings the 'autocrlf\nconversion' routine wouldn't automatically try to convert it back to LF\nendings, even if this file is not in any attributes file with '-crlf'.\n\nIt would mean that we wouldn't have to add _any_ files to attributes\nfiles at all, but only have to teach git a way to avoid crlf-converting\na given file when commiting a change. For example, on Windows you could\nthen do something like:\n git update-index --crlf my_DOS_file.txt\n git commit -m \"Add a CRLF file to the repo\"\nthen forget about it.\n\nNo need to add a .gitattributes in your own repo.\nNo need for linux users to worry about Windows users.\nNo need to Windows users to clean up the repos for the linux users.\n\nIMO, the .gitattributes file with ' -crlf' is a hack-fix to a\nproblem we shouldn't be having in the first place. We should be able to\nwrite in the git documentation:\n \"Text files are stored with Unix line ending in Git. If you need a\ntext file to contain DOS line endings on all platforms, use the --crlf\noption on the update-index command.\"... or something to that effect.\n\nOk, a bit longer mail than I expected/wanted, but I hope it explains the\nidea successfully, and convincingly. ;-)\n\nLater!\n\n--\n.marius\n\n"},{"id":"48496","messageId":"Pine.LNX.4.64.0707241923450.14781@racer.site","threadId":"9150","inReplyTo":"46A63EAA.6080203@trolltech.com","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-24T18:30:04Z","receivedAt":"2007-07-24T18:30:04Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 24 Jul 2007, Marius Storm-Olsen wrote:\n\n> 1) IMO, git should on Windows always do CRLF conversion, as this is what\n> Windows developers in general expect. (CRLF text-files that is, not the\n> conversion.) Meaning that\n> core.autocrlf = Windows\n> by default. Where 'Windows' would be of true/false value which is true\n> when on Windows and false when on other platforms. (Not that we should\n> _have_ such an option, but the concept at least.)\n\nI do not think so.\n\ncore.autocrlf is only about the relationship between the working tree and \nthe repository.\n\nSo if you want CR/LF line endings always, just do not set that flag \n(which defaults to false).\n\nIf you want LF line endings in the repo, but not necessarily in the \nworking tree, set core.autocrlf to input.\n\nIf you want LF line endings sometimes, but CR/LF at other times, but do \nnot care if the revisions in the repository will have LF or CR/LF, do not \nset that flag.\n\nGit is really slowed down tremendously just by the fact that it runs on \nWindows. You should not add to that.\n\nIMHO in most cases -- even on Windows -- you do not want to set autocrlf \nat all. Because you do not need to store the file different from the \nversion you have in the working tree.\n\nThe only situation where I think it makes sense, is when you have both \nWindows and Unix developers, _and_ your Windows tools sometimes produce \nCR/LF stupidly. But then I'd set it to \"input\".\n\nBTW no need to fuzz about binary files, which want to be in the object \ndatabase without being converted. Our heuristics has so far been pretty \nsuccessful in discerning binary from text files.\n\nCiao,\nDscho\n"},{"id":"48504","messageId":"46A654A6.5070802@trolltech.com","threadId":"9150","inReplyTo":"Pine.LNX.4.64.0707241923450.14781@racer.site","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-07-24T19:36:06Z","receivedAt":"2007-07-24T19:36:06Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":">> 1) IMO, git should on Windows always do CRLF conversion, as this is what\n>> Windows developers in general expect. (CRLF text-files that is, not the\n>> conversion.) Meaning that\n>> core.autocrlf = Windows\n> \n> I do not think so.\n> \n> core.autocrlf is only about the relationship between the working tree and \n> the repository.\n> \n> So if you want CR/LF line endings always, just do not set that flag \n> (which defaults to false).\n> \n> If you want LF line endings in the repo, but not necessarily in the \n> working tree, set core.autocrlf to input.\n> \n> If you want LF line endings sometimes, but CR/LF at other times, but do \n> not care if the revisions in the repository will have LF or CR/LF, do not \n> set that flag.\n\nOk, here we fundamentally disagree.\nIMO Windows user expect files to be DOS style, since all other files\nare. Yes, most newer tools 'handle' Unix style files, but creating new\nones will mostly be DOS style. Some will actually wreak havoc on your\nfiles, and start adding DOS line endings in the middle of your Unix line\nending file. I've seen it happen. So, dealing with Unix style text files\non Windows can be a problem for some people.\n\nSo, normally, when developing on Windows you'd expect DOS files, nothing\nelse. (Note that we're not talking about your average MinGW or Cygwin\nuser here, since they are known to the issues and how to tackle them)\n\n> Git is really slowed down tremendously just by the fact that it runs on \n> Windows. You should not add to that.\n\nThe auto crlf conversion is not the slow down here, and the time spent\nthere is negligible. I use autocrlf on all my repos on Windows, and\ndon't notice it. Filestat'ing on the other hand.. :-)\n\n\n> IMHO in most cases -- even on Windows -- you do not want to set autocrlf \n> at all. Because you do not need to store the file different from the \n> version you have in the working tree.\n\nNot true. I believe, especially at the moment, most Git users on Windows\nare mostly developing code in a cross-platform manner, and therefore\ncare about this problem.\n\n\n> The only situation where I think it makes sense, is when you have both \n> Windows and Unix developers, _and_ your Windows tools sometimes produce \n> CR/LF stupidly. But then I'd set it to \"input\".\n\nThat's ok _now_, because most of the Git user group is experienced\ndeveloper that understand the problem. I'm trying to see past that\nstate, and prepare Git for more 'common' usage on Windows. They'd expect\ntext files on Windows to be handled correctly, without any fuzz.\nNo tweaking of config options to make it work on Windows. No problems\nwith sharing repositories with Unix developers. Just work. That's not\nthe current state. But it could be.\n\n\n> BTW no need to fuzz about binary files, which want to be in the\n> object database without being converted. Our heuristics has so far\n> been pretty successful in discerning binary from text files.\n\nYeah, I have no beef with the binary detection. It seems to work fine.\nAt least I haven't had a problem with it yet, and it's not what we're\ndiscussing.\n\nOk, I come from the Perforce world, so here how it works there:\n1) Files are stored with Unix line endings in the repository.\n2) Conversion is done on Windows (and older Macs) upon checkout, if the\nfile is a text file.\n3) It has binary file detection when you add it to the depot, so if you\nand to add a DOS line ending file to the repo, you have to mark it as a\nbinary file manually\n\nGit does 1) and 2) already, and with the EOL detection in the repo file,\n(when you've already detected that a file has changed, so there's not\nmuch time wasted with that) to eliminate the 'yes' in point 6) in the\noriginal mail, should help implement 3) above well enough. It's simply,\n\"If it was a CRLF file before, no need to convert it to LF now\", and the\nproblem is largely fixed. Then it's only when we want to commit a new\nCRLF file that we need a way to 'turning off' the autocrlf for just\n_that_ file for _that_ commit. And presto, you'd have something which\nmost Windows users would expect. And Git would probably be adapted on\nWindows more quickly, which this is all about. :-) IMHO.\n\n--\n.marius\n\n"},{"id":"48529","messageId":"20070724231529.GA29156@steel.home","threadId":"9150","inReplyTo":"46A654A6.5070802@trolltech.com","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-07-24T23:15:29Z","receivedAt":"2007-07-24T23:15:29Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Marius Storm-Olsen, Tue, Jul 24, 2007 21:36:06 +0200:\n> IMO Windows user expect files to be DOS style, since all other files\n> are. Yes, most newer tools 'handle' Unix style files, but creating new\n> ones will mostly be DOS style. Some will actually wreak havoc on your\n> files, and start adding DOS line endings in the middle of your Unix line\n> ending file. I've seen it happen. So, dealing with Unix style text files\n> on Windows can be a problem for some people.\n\nI have to stay with Windows, but I'd absolute hate having their stupid\nline-ending by default. As will my project supervisor, and he gets\nchanges from something like 300 developers. You will definitely get\ntheir votes against changing the default\n\n> > Git is really slowed down tremendously just by the fact that it runs on \n> > Windows. You should not add to that.\n> \n> The auto crlf conversion is not the slow down here, and the time spent\n> there is negligible. I use autocrlf on all my repos on Windows, and\n> don't notice it. Filestat'ing on the other hand.. :-)\n\nOf course you wont notice it: you're already on Windows.\n\n> > IMHO in most cases -- even on Windows -- you do not want to set autocrlf \n> > at all. Because you do not need to store the file different from the \n> > version you have in the working tree.\n> \n> Not true. I believe, especially at the moment, most Git users on Windows\n> are mostly developing code in a cross-platform manner, and therefore\n> care about this problem.\n\nYes. They solve it by working fulltime in \\n-lineending. Avoiding that\nstupid Visual Studio and Notepad helps too.\n\n> > The only situation where I think it makes sense, is when you have both \n> > Windows and Unix developers, _and_ your Windows tools sometimes produce \n> > CR/LF stupidly. But then I'd set it to \"input\".\n> \n> That's ok _now_, because most of the Git user group is experienced\n> developer that understand the problem. I'm trying to see past that\n> state, and prepare Git for more 'common' usage on Windows. They'd expect\n> text files on Windows to be handled correctly, without any fuzz.\n\nJust make the windows installer to setup templates for CR/LF depending\non checkbox \"[ ] I am Windows idiot, standard issue\".\n\n> No tweaking of config options to make it work on Windows. No problems\n> with sharing repositories with Unix developers. Just work. That's not\n> the current state. But it could be.\n\nIt is for me. It will not be that with your suggested default.\n\n> Ok, I come from the Perforce world, so here how it works there:\n> 1) Files are stored with Unix line endings in the repository.\n> 2) Conversion is done on Windows (and older Macs) upon checkout, if the\n> file is a text file.\n> 3) It has binary file detection when you add it to the depot, so if you\n> and to add a DOS line ending file to the repo, you have to mark it as a\n> binary file manually\n\nYou always setup the lineending conversion in perforce. For each and\nevery client. There is no default. I just don't see what to learn from\nthem (if there ever was something to learn from).\n\n> ... And Git would probably be adapted on\n> Windows more quickly, which this is all about. :-) IMHO.\n\nIt is hardly worth it. Git already has to put up with ugly workarounds\njust because of the stupidities coming from that windows. It has had\nseldom any benefit from supporting this !@#$ing awkward platform.\n"},{"id":"48534","messageId":"f864c6$bg5$1@sea.gmane.org","threadId":"9150","inReplyTo":"Pine.LNX.4.64.0707241252040.28577@reaper.quantumfyre.co.uk","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-07-25T00:09:46Z","receivedAt":"2007-07-25T00:09:46Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Julian Phillips wrote:\n\n> On Tue, 24 Jul 2007, Marius Storm-Olsen wrote:\n> \n>>> I do not know this is an appropriate itch to scratch for a Windows\n>>> developer to begin with. The new-workdir setting *is* about\n>>> symlinked .git/ metainfo space. If somebody wants to work on a\n>>> filesystem without symlink, he should not be using new-workdir but\n>>> something else. E.g. GIT_DIR + GIT_WORK_TREE, or perhaps GIT_DIR +\n>>> core.worktree comes to mind.\n>>\n>> That's is definitely an option, though it seems to me that its more like \n>> giving up than a finding a proper solution. In any case, it would result in \n>> two completely different workflows on systems with and without symlink \n>> support. I work on both, and would like my workflow to be consistent. Of \n>> course I could easily add my own scripts on top to achieve this, but then \n>> we're going back into h4x0r land and not making Git more 'available'.\n>>\n>> The new-workdir feature doesn't *have* to be about symlinked .git/ metainfo \n>> space, but could also be about symref'ed .git/ metainfo.\n>> (A discussion was done in 2005s \"Getting rid of symlinks in .git?\", but the \n>> conclusion was that it would slow it down too much? *ponder*)\n> \n> Symref'ed isn't really the right term ... we're not talking about refs \n> here. You would have to basically implement symlinks _inside_ git ...\n> \n> New-workdir really _is_ all about symlinks. It already exists as a \n> contrib feature - and moving it into core is (as I understand it) really \n> just moving it, not redesigning.\n> \n> If you were going to avoid symlinks, then probably the cleanest way would \n> be to have an explict way to point at the actual repo - rather than making \n> the working look like a repo if you squint hard enough. Which sounds \n> rather like it would be an extension to GIT_DIR + GIT_WORK_TREE. I \n> haven't looked at it, but it shouldn't be too hard to have a mechanism \n> that automatically does GIT_DIR= GIT_WORK_TREE== when the \n> appropriate setup is in place? Though you would have to get it into all \n> the appropriate places ...\n\nI think it could be best solved by having in \"worktree\" .git/config with\ncore.gitdir which functions like lower layer in UnionFS like manner. It\nmeans that if git cannot find a file or directory in .git, then it tries\nto find it in core.gitdir.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"48542","messageId":"46A6F21D.2010306@trolltech.com","threadId":"9150","inReplyTo":"20070724231529.GA29156@steel.home","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-07-25T06:47:57Z","receivedAt":"2007-07-25T06:47:57Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Alex Riesen said the following on 25.07.2007 01:15:\n> Marius Storm-Olsen, Tue, Jul 24, 2007 21:36:06 +0200:\n>> IMO Windows user expect files to be DOS style, since all other files\n>> are. Yes, most newer tools 'handle' Unix style files, but creating new\n>> ones will mostly be DOS style. Some will actually wreak havoc on your\n>> files, and start adding DOS line endings in the middle of your Unix line\n>> ending file. I've seen it happen. So, dealing with Unix style text files\n>> on Windows can be a problem for some people.\n> \n> I have to stay with Windows, but I'd absolute hate having their stupid\n> line-ending by default. As will my project supervisor, and he gets\n> changes from something like 300 developers. You will definitely get\n> their votes against changing the default\n\nOk, so maybe not changing the default.\nThough it's weird behavior for _most_ Windows developers out there, I \nagree that the current Windows Git population would mostly prefer the \nUnix line endings. And I can see how someone who's working on Windows \nand handling a lot of patches from other developers of multiple OSs \nalso wanting the non-platform-standard Unix line-endings.\nI still would argue that it's not the norm. Currently yes, in the \nforeseeable future, I doubt it.\n\n\n>>> Git is really slowed down tremendously just by the fact that it runs on \n>>> Windows. You should not add to that.\n>> The auto crlf conversion is not the slow down here, and the time spent\n>> there is negligible. I use autocrlf on all my repos on Windows, and\n>> don't notice it. Filestat'ing on the other hand.. :-)\n> \n> Of course you wont notice it: you're already on Windows.\n\nCome on, when did a search and replace in a normal size source file \ntake any time? It's really not an argument for not doing CRLF \nconversion on a platform that creates CRLF files by default!\n\nIf you want files to be stored in the repo with Unix line-endings, \nwhich I expect most people would want, to share it with other \nnon-Windows developers, you _have_ to do it. (No, not the MSys/Cygwin \nusers)\n\n\n>>> IMHO in most cases -- even on Windows -- you do not want to set autocrlf \n>>> at all. Because you do not need to store the file different from the \n>>> version you have in the working tree.\n>> Not true. I believe, especially at the moment, most Git users on Windows\n>> are mostly developing code in a cross-platform manner, and therefore\n>> care about this problem.\n> \n> Yes. They solve it by working fulltime in \\n-lineending. Avoiding that\n> stupid Visual Studio and Notepad helps too.\n\nHuh? You just removed more than 3 _million_[1] potential users.. (Some \nsay 8 million [2]) Is that a good argument? Why should developers on \nWindows avoid using Windows tools? Because they're 'idiots'? (ref \nfurther down in your reply)\n\nAnyways, even if a tool on Windows _handles_ LF line-endings perfectly \nfine, most of these tools still create CR/LF files when you create a \nnew text file.\n(No, again not the MSys or LF-configured Cygwin vim/emacs/. But the native editors which handles both \nformats. There's plenty of those too.)\n\n\n>>> The only situation where I think it makes sense, is when you have both \n>>> Windows and Unix developers, _and_ your Windows tools sometimes produce \n>>> CR/LF stupidly. But then I'd set it to \"input\".\n>> That's ok _now_, because most of the Git user group is experienced\n>> developer that understand the problem. I'm trying to see past that\n>> state, and prepare Git for more 'common' usage on Windows. They'd expect\n>> text files on Windows to be handled correctly, without any fuzz.\n> \n> Just make the windows installer to setup templates for CR/LF depending\n> on checkbox \"[ ] I am Windows idiot, standard issue\".\n\nMmm, ok. If I'm an idiot just for using Windows, I guess the battle is \nlost already.\n\n\n>> No tweaking of config options to make it work on Windows. No problems\n>> with sharing repositories with Unix developers. Just work. That's not\n>> the current state. But it could be.\n> \n> It is for me. It will not be that with your suggested default.\n\nThen I wouldn't put you in the normal Windows developer category, but \nrather the one which is dependent on MSys or Cygwin, and live in \nbash/zsh on Windows. I would argue that most of those 3/8 million VS \nusers are not in the same category as you.\n\nBut sure, I don't mind having to set core.autocrlf=true when I \nconfigure Git, but then I would like that mode to work without the \nextra hassle. (Most people don't want to change already incorporated \noptions, which is fully understandable)\n\n\n>> Ok, I come from the Perforce world, so here how it works there:\n>> 1) Files are stored with Unix line endings in the repository.\n>> 2) Conversion is done on Windows (and older Macs) upon checkout, if the\n>> file is a text file.\n>> 3) It has binary file detection when you add it to the depot, so if you\n>> and to add a DOS line ending file to the repo, you have to mark it as a\n>> binary file manually\n> \n> You always setup the lineending conversion in perforce. For each and\n> every client. There is no default. I just don't see what to learn from\n> them (if there ever was something to learn from).\n\nNo you don't. You _can_, but the default when you create a 'client \nspec' is the platform specific line endings. Only 'Unix' users working \non Windows really take the trouble of changing the line endings to \nthey work with their MSys or Cygwin enviroments.\n\n\n>> ... And Git would probably be adapted on\n>> Windows more quickly, which this is all about. :-) IMHO.\n> \n> It is hardly worth it. Git already has to put up with ugly workarounds\n> just because of the stupidities coming from that windows. It has had\n> seldom any benefit from supporting this !@#$ing awkward platform.\n\nWell, I guess with this opinion there really no point in me trying to \nprove a point. If all Windows users are 'idiots' on a '!@#$ing \nawkward' platform, I'm probably just an 'idiot' trying to help out.\n\nI hope it's not the general opinion of the Git team that Windows users \nshould just bugger off..\n\nNow, personally I don't have a problem with all this line ending \nstuff. I work on Windows and Unix on a daily basis, addicted to MSys \nand Cygwin for performing my daily tasks, and use tools which handles \nLF and CR/LF interchangeably without any problems. So, the current \nstate of Git works for me. I'm just trying to help figuring out what \nwe can do to make the tool even more platform agnostic, and work as \nexpected.\n\n\n[1] http://msdn.microsoft.com/vsip\n[2] http://www.regdeveloper.co.uk/2007/06/09/vs_shell_eclipse/\n\n-- \n.marius\n\n"},{"id":"48548","messageId":"Pine.LNX.4.64.0707251024390.14781@racer.site","threadId":"9150","inReplyTo":"46A6F21D.2010306@trolltech.com","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-25T09:39:14Z","receivedAt":"2007-07-25T09:39:14Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 25 Jul 2007, Marius Storm-Olsen wrote:\n\n> Alex Riesen said the following on 25.07.2007 01:15:\n>\n> > I have to stay with Windows, but I'd absolute hate having their stupid \n> > line-ending by default. As will my project supervisor, and he gets \n> > changes from something like 300 developers. You will definitely get \n> > their votes against changing the default\n> \n> Ok, so maybe not changing the default.\n> Though it's weird behavior for _most_ Windows developers out there, I agree\n> that the current Windows Git population would mostly prefer the Unix line\n> endings. And I can see how someone who's working on Windows and handling a lot\n> of patches from other developers of multiple OSs also wanting the\n> non-platform-standard Unix line-endings.\n\nEven MacOSX saw the light. More and more tools on Windows (not from M$, \nmind you, they still want to lock you in, and I am continually amazed at \nthe _willingness_ to be locked in!) are behaving sane.\n\n> > Marius said:\n> >\n> > > I believe, especially at the moment, most Git users on Windows are \n> > > mostly developing code in a cross-platform manner, and therefore \n> > > care about this problem.\n> > \n> > Yes. They solve it by working fulltime in \\n-lineending. Avoiding that \n> > stupid Visual Studio and Notepad helps too.\n> \n> Huh? You just removed more than 3 _million_[1] potential users.. (Some say 8\n> million [2]) Is that a good argument? Why should developers on Windows avoid\n> using Windows tools? Because they're 'idiots'? (ref further down in your\n> reply)\n\nWhen somebody does not want the same as you, it comes natural to think of \nthat person as an idiot. That's psychology, not something rational.\n\nHowever, I think we are talking about an almost non-issue here: those 3-80 \nmillion users \"just waiting\" for Git probably would not touch it without a \ncomplete installer. And that installer could just ask \"which line ending \ndo you want to suffer through today?\"\n\nWhich brings _me_ back to my pet hate: why on earth is _no_ one of those \n30-800 billion Windows users trying to do something about the lack of a \nproper native Windows support for Git? The MinGW port contains commits \nfrom these people (skipping everything that is in official git.git):\n\nJohannes Schindelin\nJohannes Sixt\nJunio C Hamano\nMark Levedahl\nSimon 'corecode' Schubert\n\nI know for certain that the first person, and also the third person, are \nnot exactly Windows users. I guess not even the last two persons are.\n\nNote that more work has been done on git-gui, because those poor Windows \ndevelopers are evidently so uncomfortable with the keyboard that a GUI is \nneeded. AFAIK only Johannes Sixt and Shawn Pearce worked on the \nWindows/git-gui interaction (and again, Shawn is not a Windows user).\n\nHan-Wen made an installer, right, but that installer is lacking bash and \nperl, and proper testing, because it was just a proof-of-concept. \nHan-Wen is no Windows user either. I tried to pick up on that work, but \nunfortunately \"gub\" (the cross compiling framework he used) is so \nPythonesque that I was put off.\n\nSo this leaves me with the question: do Windows users really want a proper \nnative Windows support for Git? If the answer is yes, why don't they _do_ \n(as in \"not talk\") something about it?\n\n(Let me take a BIG, BIIIIIG exception here: Johannes Sixt has worked long \nand hard and extremely well on this beast. He is certainly the exception \nthat proves the rule.)\n\nCiao,\nDscho\n"},{"id":"48551","messageId":"46A72458.1000004@midwinter.com","threadId":"9150","inReplyTo":"Pine.LNX.4.64.0707251024390.14781@racer.site","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-07-25T10:22:16Z","receivedAt":"2007-07-25T10:22:16Z","isPatch":true,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> So this leaves me with the question: do Windows users really want a proper \n> native Windows support for Git? If the answer is yes, why don't they _do_ \n> (as in \"not talk\") something about it?\n> \n\nI'm not a Windows user, but I know some, so I can maybe answer this: \nThey do want that, but what they primarily want is a good DVCS they can \nuse without trouble. I know at least two Windows people who took a look \nat the Win32 git, had trouble with it, then looked at Mercurial (which, \nwhatever opinions you might have about it, does work better on Windows) \nand just stuck with that since it met their needs.\n\nThe fact that Mercurial exists is a big disincentive for Windows people \nto work on git; unless they specifically want to interoperate with an \nexisting git repository, hg gives them a lot of the same features that \nwe enjoy in git land. And they don't have to fiddle with MinGW or Cygwin \nor anything like that. The distance between git and hg is small enough \nin their minds that it's not worth the unknown amount of effort to work \non making git run better.\n\nAt least, that's my take on it. Maybe an actual Windows git user will \ntell me I'm full of it...\n\n-Steve\n"},{"id":"48554","messageId":"200707251205.48235.andyparkins@gmail.com","threadId":"9150","inReplyTo":"Pine.LNX.4.64.0707251024390.14781@racer.site","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-07-25T11:05:43Z","receivedAt":"2007-07-25T11:05:43Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2007 July 25, Johannes Schindelin wrote:\n\n> So this leaves me with the question: do Windows users really want a proper\n> native Windows support for Git? If the answer is yes, why don't they _do_\n> (as in \"not talk\") something about it?\n\nI don't disagree with you at all - it is completely ridiculous for Windows \nusers to moan about lack of Windows support without contributing any help. \nHowever, I think there is a good reason.\n\nI think it's a chicken and egg problem. The only reason I started making \n(small) contributions to git was because I was using it already. I didn't \nset out with the goal \"to improve git\"; I set out looking for a DVCS. \nLuckily for me, I use Linux so git worked pretty well for me straight away.\n\nThe same is not true for Windows users. Even if we ignore the fact that \nWindows users are notoriously less open-source savvy; it's unlikely that \nwe'll get any Windows contributions until there are some threshold number of \ndevelopers using git on Windows.\n\nOpen-source is all about scratching an itch, I can't see how Windows \ndevelopers can get a gitch to scratch without being users of git first. On \nthe positive side though, there surely must come a point when the Windows \nport is \"good enough\" that it will start to gather users and hence \ndevelopers. Until then, I suppose it's just a matter of shouting \"patch\" \nevery time a windows user asks for a feature :-)\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"48558","messageId":"46A73DB6.4090007@trolltech.com","threadId":"9150","inReplyTo":"200707251205.48235.andyparkins@gmail.com","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-07-25T12:10:30Z","receivedAt":"2007-07-25T12:10:30Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Andy Parkins said the following on 25.07.2007 13:05:\n> On Wednesday 2007 July 25, Johannes Schindelin wrote:\n> \n>> So this leaves me with the question: do Windows users really want\n>> a proper native Windows support for Git? If the answer is yes,\n>> why don't they _do_ (as in \"not talk\") something about it?\n> \n> I don't disagree with you at all - it is completely ridiculous for\n> Windows users to moan about lack of Windows support without\n> contributing any help. However, I think there is a good reason.\n> \n> I think it's a chicken and egg problem. The only reason I started\n> making (small) contributions to git was because I was using it\n> already. I didn't set out with the goal \"to improve git\"; I set\n> out looking for a DVCS. Luckily for me, I use Linux so git worked\n> pretty well for me straight away.\n> \n> The same is not true for Windows users. Even if we ignore the fact\n> that Windows users are notoriously less open-source savvy; it's\n> unlikely that we'll get any Windows contributions until there are\n> some threshold number of developers using git on Windows.\n> \n> Open-source is all about scratching an itch, I can't see how\n> Windows developers can get a gitch to scratch without being users\n> of git first. On the positive side though, there surely must come\n> a point when the Windows port is \"good enough\" that it will start\n> to gather users and hence developers. Until then, I suppose it's\n> just a matter of shouting \"patch\" every time a windows user asks\n> for a feature :-)\n\nHi Andy,\n\nYour mail is refreshingly spot on. I agree fully with what you say.\nI will try to do my part to get Git to this 'threshold', so we can get \na proper Windows community behind it too. (It's just a matter of time \nand resources, which I hope we clear up soon)\nMy first roadmap item will be to get a fully native compile of the \nbuilt-in code. If we at least have a Git built with native tools, I \nthink we'll have a lot more people wanting(/able?) to contribute.\n\nAFAIK the MinGW port is cross-compiled on Linux, and can be hard to \nset up on Windows. The required MinGW packages are scattered all over \nthe place. So, it's not impossible at the moment, but I guess most \nWindows users feel a bit unmotivated to work on the code mostly since \nthey'll have to develop using Cygwin. (I don't know if that's the \nreason, just a hunch)\n\nSo, IMO its not that Windows users don't _want_ to contribute. I think \nthey feel they can't. Let's see if we can fix that. I'll let the list \nknow as soon as I get native builds going.\n\nLater!\n\n--\n.marius\n\n"},{"id":"48564","messageId":"Pine.LNX.4.64.0707251505420.14781@racer.site","threadId":"9150","inReplyTo":"46A73DB6.4090007@trolltech.com","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-25T14:09:21Z","receivedAt":"2007-07-25T14:09:21Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 25 Jul 2007, Marius Storm-Olsen wrote:\n\n> Andy Parkins said the following on 25.07.2007 13:05:\n> > On Wednesday 2007 July 25, Johannes Schindelin wrote:\n> > \n> > > So this leaves me with the question: do Windows users really want\n> > > a proper native Windows support for Git? If the answer is yes,\n> > > why don't they _do_ (as in \"not talk\") something about it?\n> > \n> > I don't disagree with you at all - it is completely ridiculous for\n> > Windows users to moan about lack of Windows support without\n> > contributing any help. However, I think there is a good reason.\n> > \n> > I think it's a chicken and egg problem. The only reason I started\n> > making (small) contributions to git was because I was using it\n> > already. I didn't set out with the goal \"to improve git\"; I set\n> > out looking for a DVCS. Luckily for me, I use Linux so git worked\n> > pretty well for me straight away.\n> > \n> > The same is not true for Windows users. Even if we ignore the fact\n> > that Windows users are notoriously less open-source savvy; it's\n> > unlikely that we'll get any Windows contributions until there are\n> > some threshold number of developers using git on Windows.\n> > \n> > Open-source is all about scratching an itch, I can't see how\n> > Windows developers can get a gitch to scratch without being users\n> > of git first. On the positive side though, there surely must come\n> > a point when the Windows port is \"good enough\" that it will start\n> > to gather users and hence developers. Until then, I suppose it's\n> > just a matter of shouting \"patch\" every time a windows user asks\n> > for a feature :-)\n> \n> Hi Andy,\n> \n> Your mail is refreshingly spot on. I agree fully with what you say.\n> I will try to do my part to get Git to this 'threshold', so we can get a\n> proper Windows community behind it too. (It's just a matter of time and\n> resources, which I hope we clear up soon)\n> My first roadmap item will be to get a fully native compile of the built-in\n> code. If we at least have a Git built with native tools, I think we'll have a\n> lot more people wanting(/able?) to contribute.\n\nWell, why don't people come here then, say \"I am willing to test whatever \nyou throw at me, and contribute the installer\"? Huh?\n\nI once (AGAIN!) extend this offer to _anybody_. I'll make a zip of \neverything you need, I'll fix bugs as you report them, I'll do plenty of \nstuff.\n\nBut you have to give me an INCENTIVE!\n\n(I am usually not such a shouter, but underlining seems not to help here. \nAs can be seen by the infamous \"When can I expect\" mail.)\n\n> AFAIK the MinGW port is cross-compiled on Linux, and can be hard to set \n> up on Windows. The required MinGW packages are scattered all over the \n> place. So, it's not impossible at the moment, but I guess most Windows \n> users feel a bit unmotivated to work on the code mostly since they'll \n> have to develop using Cygwin. (I don't know if that's the reason, just a \n> hunch)\n\nNo, not even close. It is written in README.MinGW how to go about \ncompiling yourself. Only Han-Wen cross-compiled the beast on Linux.\n\n> So, IMO its not that Windows users don't _want_ to contribute. I think \n> they feel they can't. Let's see if we can fix that.\n\nI beg to differ here, strongly. On the two first points at least. On the \nthird point, I am already disap-point-ed.\n\nCiao,\nDscho\n"},{"id":"48589","messageId":"alpine.LFD.0.999.0707251327390.3607@woody.linux-foundation.org","threadId":"9150","inReplyTo":"200707251205.48235.andyparkins@gmail.com","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-25T20:40:54Z","receivedAt":"2007-07-25T20:40:54Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 25 Jul 2007, Andy Parkins wrote:\n> \n> I don't disagree with you at all - it is completely ridiculous for Windows \n> users to moan about lack of Windows support without contributing any help. \n> However, I think there is a good reason.\n> \n> I think it's a chicken and egg problem. The only reason I started making \n> (small) contributions to git was because I was using it already.\n\nI think this is 100% true, and worth repeating.\n\nA lot of people seem to think that open source is about having lots of \npeople help with the project, and that development happens much faster \nthat way.\n\nBut what people often seem to miss is that pretty much all projects \ndidn't start out \"open source\". They *all* started out as somebodys \npersonal project (where \"somebody\" could be a small group, not just an \nindividual, of course), and while maybe the _license_ was open source from \nthe beginning, you cannot get away from the fact that in order to actually \nbe developed as open source, in the end some *individual* has to just do \nit.\n\nNo project ever gets useful help until it's already useful. Being open \nsource doesn't get you past that hump - it only helps you *after* you've \nalready gotten past it.\n\nNow, admittedly, I think one issue with Windows is that the \"hump\" is \nsimply much bigger. The initial cost (not necessarily in money, but in \neffort) of getting involved in a development process is just a *lot* \nhigher for Windows users than it is for just about any UNIX.\n\nIf you're on some unix platform, the cost of getting involved is basically \nthat the project should already work to some degree, and then there may be \nsome relatively *trivial* issues with making sure that you've got a \ncompiler installed and the basic libraries. But that's really quite easy \non just about any UNIX, to the point that most people don't even have to \nthink about it.\n\nIn contrast, on Windows that \"hump\" is a whole lot harder. You don't just \nhave to have a compiler, you have to have some *specific* compiler, \nbecause under Windows, they all have different development environments, \nand few projects support them all. \n\nSo you have a double whammy: not only are people doing less development on \nWindows to start with (so the project itself is likely not as usable), but \nsomething as totally *trivial* as getting a simple C development \nenvironment isn't even trivial. And git makes it worse by requiring a very \nodd component (in Windows terms): the shell.\n\nI really hope we'll get the the C rewrite merged soon. Especially the big \nones, ie commit / merge / am / clone / fetch. Those are the complex ones \nthat it's hard to get excited about when they don't work. Once those work \nwell, you could probably use git pretty completely even without shell, \neven if you'd be missing a few features - and those features would now be \nsmall enough that a relative beginner can cut their teeth on them.\n\nThe good news seems to be that most of those big scripts already exist in \na C version, so it's not like it's some utopian dream any more.\n\nBut getting a development environment is still much more painful under \nWindows than just about anywhere else.\n\n\t\t\tLinus\n"},{"id":"48692","messageId":"46d6db660707260451l7dd6b54o3b4d434e0468cf55@mail.gmail.com","threadId":"9150","inReplyTo":"alpine.LFD.0.999.0707251327390.3607@woody.linux-foundation.org","subject":"Re: [PATCH 3/3] Teach \"git branch\" about --new-workdir","fromName":"Christian MICHON","fromEmail":"christian.michon@gmail.com","sentAt":"2007-07-26T11:51:12Z","receivedAt":"2007-07-26T11:51:12Z","isPatch":true,"sender":{"key":"christian.michon@gmail.com","avatar":"https://gravatar.com/avatar/8a7c327b21187fbcab5c27640a49450eec72e0355dc292501197f27a5a744ec4?d=mp&s=160"},"body":"On 7/25/07, Linus Torvalds wrote:\n> Now, admittedly, I think one issue with Windows is that the \"hump\" is\n> simply much bigger. The initial cost (not necessarily in money, but in\n> effort) of getting involved in a development process is just a *lot*\n> higher for Windows users than it is for just about any UNIX.\n>\n> If you're on some unix platform, the cost of getting involved is basically\n> that the project should already work to some degree, and then there may be\n> some relatively *trivial* issues with making sure that you've got a\n> compiler installed and the basic libraries. But that's really quite easy\n> on just about any UNIX, to the point that most people don't even have to\n> think about it.\n\nhttp://www.openlina.org could closing this gap, as a temp fix.\n\nIt's supposed to help running linux native binaries on windows through\nsome virtualization layer. Speed is supposed to be good, the host filesystem\nis supposed to be accessible. Many suppositions, I haven't evaluated\nthis beast yet.\n\nIf this is truly usable, it would mean an easy migration for unix users,\nusing the command line.\n\nFor true windows users, git-gui, gitk and ultimately a windows explorer\nplugin/addon will be needed still, as mentionned earlier in this thread.\n\nIt is to be noted though that C conversion and shell replacement\nwill not be all that is needed.\n\nToday, I've a colinux environment containing git-1.5.2.3 and all needed\ntools for development (shell, compiler, editor). When I perform some git\noperations in any linux controlled filesystem (ramfs, ext2 over cobd), no\nproblem, git works as advertised.\n\nWhen I used shared windows folder in the ntfs filesystem, there are\nissues. Fsync fails when writing files (could be colinux related), but\ngit-init produces different .git/config file and git-commit does not work\n(fatal: index file smaller than expected). The last 2 problems should be\nwindows related I believe and should hit as soon as the shell over C\nportage will be done.\n\nUnless the current patches in mingw.git can fix these of course.\n\n-- \nChristian\n--\nhttp://detaolb.sourceforge.net/, a linux distribution for Qemu\n"}]}