[PATCH 3/3] Teach "git branch" about --new-workdir

[PATCH 3/3] Teach "git branch" about --new-workdir

[Johannes Schindelin]

Inspired by contrib/workdir/git-new-workdir, the flag --new-workdir (or
its shortcut, -n) can be used to create a new working directory for the
newly created branch.  All information, except which branch is checked
out (and therefore also the index), will be symlinked from the current
repository.

Example:

	$ git branch -n ~/my-new-topic xy-problem

will create a branch called "xy-problem", which is initially identical
to the current branch, and check out the new branch in ~/my-new-topic/.
You will be able to cherry-pick from, log and diff with the branch
"xy-problem" in the current repository, since most of the metadata is
shared.

Conversely, you can access all the branches in the current repository
from ~/my-new-topic/, too.

A word of warning: switching to _same_ branch that is checked out in
the other repository is asking for trouble.  You are really working not
only on the same object database, but also the same (i.e. not copied)
refs namespace.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
	IMHO this is a better syntax than what is in contrib/, and "git
	branch" is probably the right place for such a thing, from a
	user's perspective.

 Documentation/git-branch.txt |    7 +++-
 builtin-branch.c             |   79 +++++++++++++++++++++++++++++++++++++++--
 t/t3200-branch.sh            |   11 ++++++
 3 files changed, 92 insertions(+), 5 deletions(-)

diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index bc6aa88..a05c795 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -10,7 +10,8 @@ SYNOPSIS
 [verse]
 'git-branch' [--color | --no-color] [-r | -a]
 	   [-v [--abbrev=<length> | --no-abbrev]]
-'git-branch' [--track | --no-track] [-l] [-f] <branchname> [<start-point>]
+'git-branch' [--track | --no-track] [-l] [-f] <branchname>
+	   [-n <dir> | --new-workdir <dir>] [<start-point>]
 'git-branch' (-m | -M) [<oldbranch>] <newbranch>
 'git-branch' (-d | -D) [-r] <branchname>...
 
@@ -91,6 +92,10 @@ OPTIONS
 --no-abbrev::
 	Display the full sha1s in output listing rather than abbreviating them.
 
+-n\|--new-workdir <dir>::
+	Set up a new working directory which shares all information with the
+	current repository, except which branch is checked out.
+
 <branchname>::
 	The name of the branch to create or delete.
 	The new branch name must pass all checks defined by
diff --git a/builtin-branch.c b/builtin-branch.c
index 5f5c182..cba5fac 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -11,9 +11,10 @@
 #include "commit.h"
 #include "builtin.h"
 #include "remote.h"
+#include "unpack-trees.h"
 
 static const char builtin_branch_usage[] =
-  "git-branch [-r] (-d | -D) <branchname> | [--track | --no-track] [-l] [-f] <branchname> [<start-point>] | (-m | -M) [<oldbranch>] <newbranch> | [--color | --no-color] [-r | -a] [-v [--abbrev=<length> | --no-abbrev]]";
+  "git-branch [-r] (-d | -D) <branchname> | [--track | --no-track] [-l] [-f] [-n <dir> | --new-workdir <dir>] <branchname> [<start-point>] | (-m | -M) [<oldbranch>] <newbranch> | [--color | --no-color] [-r | -a] [-v [--abbrev=<length> | --no-abbrev]]";
 
 #define REF_UNKNOWN_TYPE    0x00
 #define REF_LOCAL_BRANCH    0x01
@@ -500,6 +501,67 @@ static void rename_branch(const char *oldname, const char *newname, int force)
 		die("Branch is renamed, but update of config-file failed");
 }
 
+static struct lock_file lockfile;
+
+/* This function free()s path */
+static int create_new_workdir(char *path, const char *branch_name)
+{
+	static const char *links[] = {
+		"config", "refs", "logs/refs", "objects", "info", "hooks",
+		"packed-refs", "remotes", "rr-cache", NULL
+	};
+	const char *git_dir = get_git_dir(), *absolute;
+	struct stat st;
+	unsigned char sha1[20];
+	char *ref;
+	struct object *object;
+	struct unpack_trees_options opts;
+	struct object_list trees;
+	int i, fd;
+
+	if (!has_symlinks)
+		return error("New workdir not possible without symlinks");
+	/* make sure that GIT_DIR is an absolute path */
+	if ((absolute = make_absolute_path(git_dir)) != git_dir &&
+			setup_new_git_dir(absolute))
+		return 1;
+	if (!lstat(git_path("config"), &st) && S_ISLNK(st.st_mode))
+		return error("Will not create a workdir from a workdir");
+	if (safe_create_leading_directories(path) ||
+			mkdir(path, 0777) || chdir(path))
+		return error("Could not create '%s'", path);
+	if (mkdir(DEFAULT_GIT_DIR_ENVIRONMENT, 0777) ||
+			chdir(DEFAULT_GIT_DIR_ENVIRONMENT) ||
+			mkdir("logs", 0777))
+		return error("Could not set up '%s/%s'",
+				path, DEFAULT_GIT_DIR_ENVIRONMENT);
+	for (i = 0; links[i]; i++)
+		if (symlink(git_path(links[i]), links[i]))
+			return error("Could not link '%s'", links[i]);
+	if (chdir("..") || setup_new_git_dir(DEFAULT_GIT_DIR_ENVIRONMENT))
+		return error("Error setting up new workdir");
+	fd = hold_locked_index(&lockfile, 1);
+	if (fd < 0)
+		return error("Could not lock index");
+	if (dwim_ref(branch_name, strlen(branch_name), sha1, &ref) != 1 ||
+			create_symref("HEAD", ref, "new workdir") ||
+			!(object = parse_object(sha1)) ||
+			object->type != OBJ_COMMIT)
+		return error("Could not checkout HEAD");
+	free(ref);
+	trees.item = &((struct commit *)object)->tree->object;
+	trees.next = NULL;
+
+	memset(&opts, 0, sizeof(opts));
+	opts.update = 1;
+	opts.merge = 1;
+	opts.head_idx = 1;
+	opts.fn = oneway_merge;
+	return unpack_trees(&trees, &opts) ||
+		write_cache(fd, active_cache, active_nr) ||
+		close(fd) || commit_locked_index(&lockfile);
+}
+
 int cmd_branch(int argc, const char **argv, const char *prefix)
 {
 	int delete = 0, force_delete = 0, force_create = 0;
@@ -507,6 +569,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
 	int verbose = 0, abbrev = DEFAULT_ABBREV, detached = 0;
 	int reflog = 0, track;
 	int kinds = REF_LOCAL_BRANCH;
+	char *new_workdir = NULL;
 	int i;
 
 	git_config(git_branch_config);
@@ -587,11 +650,17 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
 			branch_use_color = 0;
 			continue;
 		}
+		if (!strcmp(arg, "--new-workdir") || !strcmp(arg, "-n")) {
+			if (++i >= argc)
+				usage(builtin_branch_usage);
+			new_workdir = xstrdup(argv[i]);
+			continue;
+		}
 		usage(builtin_branch_usage);
 	}
 
 	if ((delete && rename) || (delete && force_create) ||
-	    (rename && force_create))
+	    (rename && force_create) || (new_workdir && (delete || rename)))
 		usage(builtin_branch_usage);
 
 	head = resolve_ref("HEAD", head_sha1, 0, NULL);
@@ -615,10 +684,12 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
 		rename_branch(head, argv[i], force_rename);
 	else if (rename && (i == argc - 2))
 		rename_branch(argv[i], argv[i + 1], force_rename);
-	else if (i == argc - 1 || i == argc - 2)
+	else if (i == argc - 1 || i == argc - 2) {
 		create_branch(argv[i], (i == argc - 2) ? argv[i+1] : head,
 			      force_create, reflog, track);
-	else
+		if (new_workdir)
+			return create_new_workdir(new_workdir, argv[i]);
+	} else
 		usage(builtin_branch_usage);
 
 	return 0;
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index ef1eeb7..d9ec82a 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -202,4 +202,15 @@ test_expect_success \
 	 test -f .git/logs/refs/heads/g/h/i &&
 	 diff expect .git/logs/refs/heads/g/h/i'
 
+test_expect_success 'create new workdir' '
+	git branch -n new-workdir forked &&
+	test -d new-workdir &&
+	(cd new-workdir &&
+	 test $HEAD = $(git rev-parse HEAD) &&
+	 test refs/heads/forked = $(git symbolic-ref HEAD) &&
+	 git fsck &&
+	 git diff-files --quiet &&
+	 git diff-index --quiet --cached HEAD)
+'
+
 test_done
-- 
1.5.3.rc2.29.gc4640f

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Daniel Barkalow]

On Sun, 22 Jul 2007, Johannes Schindelin wrote:

> A word of warning: switching to _same_ branch that is checked out in
> the other repository is asking for trouble.  You are really working not
> only on the same object database, but also the same (i.e. not copied)
> refs namespace.

It's probably time to revive Junio's patch for keeping the 
fully-dereferenced value of HEAD in the index, to make this safer.

	-Daniel
*This .sig left intentionally blank*

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Johannes Schindelin]

Hi,

On Sun, 22 Jul 2007, Daniel Barkalow wrote:

> On Sun, 22 Jul 2007, Johannes Schindelin wrote:
> 
> > A word of warning: switching to _same_ branch that is checked out in
> > the other repository is asking for trouble.  You are really working not
> > only on the same object database, but also the same (i.e. not copied)
> > refs namespace.
> 
> It's probably time to revive Junio's patch for keeping the 
> fully-dereferenced value of HEAD in the index, to make this safer.

Yeah, probably.

Anyway, I will probably run with 'master'+this patch until 1.5.3 is 
released.

Ciao,
Dscho

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Julian Phillips]

On Sun, 22 Jul 2007, Johannes Schindelin wrote:

>
> Inspired by contrib/workdir/git-new-workdir, the flag --new-workdir (or
> its shortcut, -n) can be used to create a new working directory for the
> newly created branch.  All information, except which branch is checked
> out (and therefore also the index), will be symlinked from the current
> repository.
>
> Example:
>
> 	$ git branch -n ~/my-new-topic xy-problem
>
> will create a branch called "xy-problem", which is initially identical
> to the current branch, and check out the new branch in ~/my-new-topic/.
> You will be able to cherry-pick from, log and diff with the branch
> "xy-problem" in the current repository, since most of the metadata is
> shared.
>
> Conversely, you can access all the branches in the current repository
> from ~/my-new-topic/, too.
>
> A word of warning: switching to _same_ branch that is checked out in
> the other repository is asking for trouble.  You are really working not
> only on the same object database, but also the same (i.e. not copied)
> refs namespace.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
> 	IMHO this is a better syntax than what is in contrib/, and "git
> 	branch" is probably the right place for such a thing, from a
> 	user's perspective.

Surely checkout would make more sense than branch?  You are effectively 
checking out into a new directory ... also you may want to get an existing 
branch (certainly most of my usage of new-workdir is checking out existing 
branches, e.g. to look at - as in build and play with - an interesting 
branch that someone else has pushed out).

Definitely in favour of moving this into git proper though.

-- 
Julian

  ---
Lack of capability is usually disguised by lack of interest.

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Johannes Schindelin]

Hi,

On Sun, 22 Jul 2007, Julian Phillips wrote:

> On Sun, 22 Jul 2007, Johannes Schindelin wrote:
> 
> > 	IMHO this is a better syntax than what is in contrib/, and "git
> > 	branch" is probably the right place for such a thing, from a
> > 	user's perspective.
> 
> Surely checkout would make more sense than branch?  You are effectively 
> checking out into a new directory ... also you may want to get an 
> existing branch (certainly most of my usage of new-workdir is checking 
> out existing branches, e.g. to look at - as in build and play with - an 
> interesting branch that someone else has pushed out).

My rationale here was:

- to make sure that the user cannot check out the same branch as in the 
  current repo, _or some other workdir of it_, and

- to have finer grained lock control, as well as respecting has_symlinks.

Ciao,
Dscho

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Julian Phillips]

On Sun, 22 Jul 2007, Johannes Schindelin wrote:

> Hi,
>
> On Sun, 22 Jul 2007, Julian Phillips wrote:
>
>> On Sun, 22 Jul 2007, Johannes Schindelin wrote:
>>
>>> 	IMHO this is a better syntax than what is in contrib/, and "git
>>> 	branch" is probably the right place for such a thing, from a
>>> 	user's perspective.
>>
>> Surely checkout would make more sense than branch?  You are effectively
>> checking out into a new directory ... also you may want to get an
>> existing branch (certainly most of my usage of new-workdir is checking
>> out existing branches, e.g. to look at - as in build and play with - an
>> interesting branch that someone else has pushed out).
>
> My rationale here was:
>
> - to make sure that the user cannot check out the same branch as in the
>  current repo, _or some other workdir of it_, and

Since you can checkout any branch you like once you have the workdir, 
this is really an artificial limitation - you are protected when you 
create the workdir, but not after.  This seems more likely to bite 
someone than just making them aware of the pitfalls before hand.  One of 
the main reasons that I aimed for contrib rather than proper git 
originally was the ability to do bad things with realising.

If you want to have a workdir for an exisiting branch then you have to 
create a new one, and then switch it over.  That seems like a really big 
usability wart to me ... certainly it would make the option pretty much 
useless to me.  My original motivation for the new-workdir script was to 
give me the ability to flatten out branches from a single repo for when 
I'm working on multiple branches at the same time.

> - to have finer grained lock control, as well as respecting has_symlinks.

Not really sure what this means, since I am too tired to have read the 
actual patch - is it referring to the fact that checkout is shell rather 
than C?  If so, surely that is not really a good justification for putting 
the option in the "wrong" command?

-- 
Julian

  ---
Thud. Thud. Thud. Splat.
         -- (Terry Pratchett & Neil Gaiman, Good Omens)

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Johannes Schindelin]

Hi,

On Sun, 22 Jul 2007, Julian Phillips wrote:

> On Sun, 22 Jul 2007, Johannes Schindelin wrote:
> 
> > On Sun, 22 Jul 2007, Julian Phillips wrote:
> > 
> > > On Sun, 22 Jul 2007, Johannes Schindelin wrote:
> > > 
> > > > 	IMHO this is a better syntax than what is in contrib/, and "git
> > > > 	branch" is probably the right place for such a thing, from a
> > > > 	user's perspective.
> > > 
> > > Surely checkout would make more sense than branch?  You are effectively
> > > checking out into a new directory ... also you may want to get an
> > > existing branch (certainly most of my usage of new-workdir is checking
> > > out existing branches, e.g. to look at - as in build and play with - an
> > > interesting branch that someone else has pushed out).
> > 
> > My rationale here was:
> > 
> > - to make sure that the user cannot check out the same branch as in the
> >  current repo, _or some other workdir of it_, and
> 
> Since you can checkout any branch you like once you have the workdir, 
> this is really an artificial limitation - you are protected when you 
> create the workdir, but not after.

Well, it is not really an artificial limitation.  IMHO it is much more 
likely that you keep in mind what you should not do, when you have to work 
around such a limitation if you really want to do.

> If you want to have a workdir for an exisiting branch then you have to create
> a new one, and then switch it over.  That seems like a really big usability
> wart to me ... certainly it would make the option pretty much useless to me.
> My original motivation for the new-workdir script was to give me the ability
> to flatten out branches from a single repo for when I'm working on multiple
> branches at the same time.

Nowadays, we have separate remotes layout by default.  (Indeed, you cannot 
even disable it, as I found out recently).  Which means that you already 
have to branch off your local branch.  So the consequences are lesser.

> > - to have finer grained lock control, as well as respecting has_symlinks.
> 
> Not really sure what this means, since I am too tired to have read the 
> actual patch - is it referring to the fact that checkout is shell rather 
> than C?  If so, surely that is not really a good justification for 
> putting the option in the "wrong" command?

Well, I am really not interested in shooting myself in the foot, and 
having that option in checkout would make that much more likely.  So I 
really, really want to have this in git-branch.

Once git-checkout is builtin, we can still come back and add this option 
to git-checkout (with a big fat red warning, to be sure); it is not like 
we have git-branch and git-checkout functionality well separated...

Ciao,
Dscho

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Julian Phillips]

On Sun, 22 Jul 2007, Johannes Schindelin wrote:

>>> - to make sure that the user cannot check out the same branch as in the
>>>  current repo, _or some other workdir of it_, and
>>
>> Since you can checkout any branch you like once you have the workdir,
>> this is really an artificial limitation - you are protected when you
>> create the workdir, but not after.
>
> Well, it is not really an artificial limitation.  IMHO it is much more
> likely that you keep in mind what you should not do, when you have to work
> around such a limitation if you really want to do.

Well, the point I was trying to make is that you _only_ protect them 
against the initial creation.  The user can then happily shoot themselves 
in the foot.  They can quite easily "work around" the limitation without 
realising that they are.  Say that you create a workdir for a new branch. 
Then a month later you want to do something to a branch you are working on 
in your main branch - but you are halfway through something complicated 
that you haven't checked in, but you think "aha! I still have that old 
workdir, I can just switch it over and use that" ...

You haven't made workdirs themselves safer - only the creation.  You still 
need a great big THIS CAN REALLY MESS THINGS UP warning.

>
>> If you want to have a workdir for an exisiting branch then you have to create
>> a new one, and then switch it over.  That seems like a really big usability
>> wart to me ... certainly it would make the option pretty much useless to me.
>> My original motivation for the new-workdir script was to give me the ability
>> to flatten out branches from a single repo for when I'm working on multiple
>> branches at the same time.
>
> Nowadays, we have separate remotes layout by default.  (Indeed, you cannot
> even disable it, as I found out recently).  Which means that you already
> have to branch off your local branch.  So the consequences are lesser.

This is true - yet I still find that 99% of the time I am using 
new-workdir to get an existing branch.  Probably because there is usually 
a delay between creating a local branch and needing to work on it in 
parallel.

Working pattern is something like:

start off with 0 workdirs - just using the original repo
... work using 1 working copy - switching branch as needed ...
need to do two things in parallel - 1 workdir
... work using 2 working copies - switching both/either as needed ...
need to do three things in parallel - 2 workdirs
... work using 3 working copies - switching any/all as needed ...

etc. (sometimes removing workdirs as they are no longer needed too)

>>> - to have finer grained lock control, as well as respecting has_symlinks.
>>
>> Not really sure what this means, since I am too tired to have read the
>> actual patch - is it referring to the fact that checkout is shell rather
>> than C?  If so, surely that is not really a good justification for
>> putting the option in the "wrong" command?
>
> Well, I am really not interested in shooting myself in the foot, and
> having that option in checkout would make that much more likely.  So I
> really, really want to have this in git-branch.

Fair enough.  Your patch - so you get to choose.  I don't have any strong 
objections (and no power to express any if I did :P) - just airing my POV 
;)

I just think that to a user it feels like a checkout operation ... and 
that would less confusing as an option to checkout.  Trying to explain 
that branch just creates a new branch, unless you give this option then it 
creates a working copy over there seems more compilcated than saying the 
checkout updates/creates this working copy, unless you use this option to 
create one over there.

> Once git-checkout is builtin, we can still come back and add this option
> to git-checkout (with a big fat red warning, to be sure); it is not like
> we have git-branch and git-checkout functionality well separated...

As I said I have been thinking from a user POV not an implementation one 
...

Assuming this patch goes in, then I'll probably update the new-workdir 
script to keep it's existing syntax, but use your new option as mechanism 
... so that will let me keep doing things the way I am anyway ... ;)

And as I said originally - you got my vote on this going into git proper 
_somewhere_ ...

-- 
Julian

  ---
When it is not necessary to make a decision, it is necessary not to
make a decision.

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Jakub Narebski]

Julian Phillips wrote:

> I just think that to a user it feels like a checkout operation ... and 
> that would less confusing as an option to checkout.  Trying to explain 
> that branch just creates a new branch, unless you give this option then it 
> creates a working copy over there seems more compilcated than saying the 
> checkout updates/creates this working copy, unless you use this option to 
> create one over there.

IMVHO git-checkout is characterized that it changes _current_ working
directory. But having this in git-checkout would mean that you can create
new workdir for _existing_ branch. git-branch is rather (except from
listing) for creating new branches.

It is a fact that functionalities of git-checkout (-b) and git-branch
(--new-work-dir) intersect a bit.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Johannes Schindelin]

Hi,

[re Cc'ed Julian]

On Mon, 23 Jul 2007, Jakub Narebski wrote:

> Julian Phillips wrote:
> 
> > I just think that to a user it feels like a checkout operation ... and 
> > that would less confusing as an option to checkout. ?Trying to explain 
> > that branch just creates a new branch, unless you give this option 
> > then it creates a working copy over there seems more compilcated than 
> > saying the checkout updates/creates this working copy, unless you use 
> > this option to create one over there.
> 
> IMVHO git-checkout is characterized that it changes _current_ working 
> directory.

Actually, the name suggests that the important action is "checkout", so I 
agree with Julian here.

> But having this in git-checkout would mean that you can create new 
> workdir for _existing_ branch. git-branch is rather (except from 
> listing) for creating new branches.

Note that it is possible to checkout the current branch with "git checkout 
HEAD".  Indeed, you can get the same effect with "git checkout -f HEAD" as 
with "git reset --hard" AFAIK.

> It is a fact that functionalities of git-checkout (-b) and git-branch
> (--new-work-dir) intersect a bit.

Yes, I pointed that out, too.  But we're not Python, so we do not have to 
pretend that it is a bad thing to have several way to do the same.  Which 
allows us better to cater for user's expectations.

Ciao,
Dscho

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Johannes Schindelin]

Hi,

On Sun, 22 Jul 2007, Julian Phillips wrote:

> On Sun, 22 Jul 2007, Johannes Schindelin wrote:
> 
> > Well, I am really not interested in shooting myself in the foot, and 
> > having that option in checkout would make that much more likely.  So I 
> > really, really want to have this in git-branch.
> 
> Fair enough.  Your patch - so you get to choose.  I don't have any 
> strong objections (and no power to express any if I did :P) - just 
> airing my POV ;)

;-)

In related news, you got me convinced that my "solution" is not 
sufficient.  So I guess this patch has to wait until after 1.5.3 _and_ 
after we convinced Junio to put his BASE index extension in again.

FWIW once git-checkout is builtin, I'll add "--new-workdir" for it.  Deal?

Ciao,
Dscho

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Shawn O. Pearce]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Sun, 22 Jul 2007, Julian Phillips wrote:
> 
> > On Sun, 22 Jul 2007, Johannes Schindelin wrote:
> > 
> > > Well, I am really not interested in shooting myself in the foot, and 
> > > having that option in checkout would make that much more likely.  So I 
> > > really, really want to have this in git-branch.
> > 
> > Fair enough.  Your patch - so you get to choose.  I don't have any 
> > strong objections (and no power to express any if I did :P) - just 
> > airing my POV ;)
> 
> In related news, you got me convinced that my "solution" is not 
> sufficient.  So I guess this patch has to wait until after 1.5.3 _and_ 
> after we convinced Junio to put his BASE index extension in again.

The last time we had that thing in Git it really screwed with git-gui.
I'm not looking forward to it coming back.


But anyway, I think there's something else that needs to be fixed
before this symlink workdir thing is fully in core git.  Right now we
delete the .git/config and .git/packed-refs files when we edit them.
This means it is *very* unsafe to run `git-config` or `git-tag -d`
in a symlinked workdir, as the workdir will get its own config or
packed-refs file and the real repository directory won't be affected.

Now .git/config switching from symlink to real file is maybe almost
a feature.

But .git/packed-refs switching from symlink to real file is *not*
a feature.  Its a massive bug.

I live by new-workdir.  I do everything with it.  And today I just
spent over an hour sorting out cases where my many, many workdirs
have different refs than their base repositories, because their
packed-refs files are different.  Grrrrrrrrrrrrrrrrrr.


So we really need to make anyone that edits packed-refs (and
maybe also config) resolve the symlink and do the edit in the
target directory.  Then we can consider adding this workdir thing
to core git.

Yes, I know, stop whining and submit a patch.  I'll get around to
it soon if nobody else beats me.  I just want to voice yet another
reason why this shouldn't be in 1.5.3.

-- 
Shawn.

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> I live by new-workdir.  I do everything with it.  And today I just
> spent over an hour sorting out cases where my many, many workdirs
> have different refs than their base repositories, because their
> packed-refs files are different.  Grrrrrrrrrrrrrrrrrr.
>
> So we really need to make anyone that edits packed-refs (and
> maybe also config) resolve the symlink and do the edit in the
> target directory.  Then we can consider adding this workdir thing
> to core git.

This is actually not limited to packed-refs file, but applies to
other things as well.

I have been wondering if something like this patch would be
sufficient.  The idea essentially is to take the lock on the
link target when we try to take a lock on something that is a
symlink pointing elsewhere.

---

 lockfile.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/lockfile.c b/lockfile.c
index fb8f13b..7fc71d9 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -28,6 +28,17 @@ static void remove_lock_file_on_signal(int signo)
 static int lock_file(struct lock_file *lk, const char *path)
 {
 	int fd;
+	struct stat st;
+
+	if ((!lstat(path, &st)) && S_ISLNK(st.st_mode)) {
+		ssize_t sz;
+		static char target[PATH_MAX];
+		sz = readlink(path, target, sizeof(target));
+		if (sz < 0)
+			warning("Cannot readlink %s", path);
+		else
+			path = target;
+	}
 	sprintf(lk->filename, "%s.lock", path);
 	fd = open(lk->filename, O_RDWR | O_CREAT | O_EXCL, 0666);
 	if (0 <= fd) {

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
> > I live by new-workdir.  I do everything with it.  And today I just
> > spent over an hour sorting out cases where my many, many workdirs
> > have different refs than their base repositories, because their
> > packed-refs files are different.  Grrrrrrrrrrrrrrrrrr.
> >
> > So we really need to make anyone that edits packed-refs (and
> > maybe also config) resolve the symlink and do the edit in the
> > target directory.  Then we can consider adding this workdir thing
> > to core git.
> 
> This is actually not limited to packed-refs file, but applies to
> other things as well.

Yes, but most other things aren't symlinks, they are in symlinked
directories.  But better to cover it in a single location and have
it Just Work(tm) then to special case things.
 
> diff --git a/lockfile.c b/lockfile.c
> index fb8f13b..7fc71d9 100644
> --- a/lockfile.c
> +++ b/lockfile.c
> @@ -28,6 +28,17 @@ static void remove_lock_file_on_signal(int signo)
>  static int lock_file(struct lock_file *lk, const char *path)
>  {
>  	int fd;
> +	struct stat st;
> +
> +	if ((!lstat(path, &st)) && S_ISLNK(st.st_mode)) {
> +		ssize_t sz;
> +		static char target[PATH_MAX];
> +		sz = readlink(path, target, sizeof(target));
> +		if (sz < 0)
> +			warning("Cannot readlink %s", path);
> +		else
> +			path = target;
> +	}
>  	sprintf(lk->filename, "%s.lock", path);
>  	fd = open(lk->filename, O_RDWR | O_CREAT | O_EXCL, 0666);
>  	if (0 <= fd) {

Right.  But don't you have to resolve target relative to path?
If the symlink is an absolute path its fine as-is, but if it was
relative its relative to path, not pwd.

-- 
Shawn.

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Shawn O. Pearce]

"Shawn O. Pearce" <spearce@spearce.org> wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
> >  static int lock_file(struct lock_file *lk, const char *path)
> >  {
> >  	int fd;
> > +	struct stat st;
> > +
> > +	if ((!lstat(path, &st)) && S_ISLNK(st.st_mode)) {
> > +		ssize_t sz;
> > +		static char target[PATH_MAX];
> > +		sz = readlink(path, target, sizeof(target));
> > +		if (sz < 0)
> > +			warning("Cannot readlink %s", path);
> > +		else
> > +			path = target;
> > +	}
> >  	sprintf(lk->filename, "%s.lock", path);
> >  	fd = open(lk->filename, O_RDWR | O_CREAT | O_EXCL, 0666);
> >  	if (0 <= fd) {
> 
> Right.  But don't you have to resolve target relative to path?
> If the symlink is an absolute path its fine as-is, but if it was
> relative its relative to path, not pwd.

It might just be OK to refuse to lock a symlink that isn't absolute.
git-new-workdir already uses absolute paths to setup the symlinks.

-- 
Shawn.

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Johannes Schindelin]

Hi,

On Sun, 22 Jul 2007, Junio C Hamano wrote:

> @@ -28,6 +28,17 @@ static void remove_lock_file_on_signal(int signo)
>  static int lock_file(struct lock_file *lk, const char *path)
>  {
>  	int fd;
> +	struct stat st;
> +
> +	if ((!lstat(path, &st)) && S_ISLNK(st.st_mode)) {
> +		ssize_t sz;
> +		static char target[PATH_MAX];
> +		sz = readlink(path, target, sizeof(target));
> +		if (sz < 0)
> +			warning("Cannot readlink %s", path);
> +		else
> +			path = target;
> +	}

I wonder if we should not make this a while loop:

	struct stat st;
	int i = 0;

	while (i++ < 10 && !lstat(path, &st) && S_ISLNK(st.st_mode)) {
		ssize_t sz;
		static char target[PATH_MAX];
		sz = readlink(path, target, sizeof(target));
		if (sz < 0)
			die("Cannot readlink %s", path);
		else
			path = target;
	}
	if (i == 10)
		die ("Too deep symlink depth: %s", path);

(As you see, I would not warn, but die if readlink fails.)

Ciao,
Dscho

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Johannes Schindelin]

Hi,

On Mon, 23 Jul 2007, Johannes Schindelin wrote:

> 	struct stat st;
> 	int i = 0;
> 
> 	while (i++ < 10 && !lstat(path, &st) && S_ISLNK(st.st_mode)) {
> 		ssize_t sz;
> 		static char target[PATH_MAX];
> 		sz = readlink(path, target, sizeof(target));
> 		if (sz < 0)
> 			die("Cannot readlink %s", path);
> 		else
> 			path = target;

Probably this should be "make_absolute_path(target)" after applying the 
minipatch I provided elsewhere.

Ciao,
Dscho

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Marius Storm-Olsen]

[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]

>> I live by new-workdir.  I do everything with it.  And today I
>> just spent over an hour sorting out cases where my many, many
>> workdirs have different refs than their base repositories,
>> because their packed-refs files are different.
>> Grrrrrrrrrrrrrrrrrr.
>> 
>> So we really need to make anyone that edits packed-refs (and 
>> maybe also config) resolve the symlink and do the edit in the 
>> target directory.  Then we can consider adding this workdir thing
>>  to core git.
> 
> This is actually not limited to packed-refs file, but applies to 
> other things as well.
> 
> I have been wondering if something like this patch would be 
> sufficient.  The idea essentially is to take the lock on the link
> target when we try to take a lock on something that is a symlink
> pointing elsewhere.
(..snip..)

While you guys are discussing this, please please keep in mind that 
there are Windows users (/me raises his hand) out there that really 
really want this too. So, please try to keep it light on the symlinks.

-- 
.marius


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Johannes Schindelin]

Hi,

On Tue, 24 Jul 2007, Marius Storm-Olsen wrote:

> > > I live by new-workdir.  I do everything with it.  And today I
> > > just spent over an hour sorting out cases where my many, many
> > > workdirs have different refs than their base repositories,
> > > because their packed-refs files are different.
> > > Grrrrrrrrrrrrrrrrrr.
> > > 
> > > So we really need to make anyone that edits packed-refs (and maybe also
> > > config) resolve the symlink and do the edit in the target directory.  Then
> > > we can consider adding this workdir thing
> > >  to core git.
> > 
> > This is actually not limited to packed-refs file, but applies to other
> > things as well.
> > 
> > I have been wondering if something like this patch would be sufficient.  The
> > idea essentially is to take the lock on the link
> > target when we try to take a lock on something that is a symlink
> > pointing elsewhere.
> (..snip..)
> 
> While you guys are discussing this, please please keep in mind that there are
> Windows users (/me raises his hand) out there that really really want this
> too. So, please try to keep it light on the symlinks.

Easy: use cygwin.

Okay, a bit more seriously again: in the recent weeks, it seems that more 
and more Windows users are asking for features.  Since I guess you are a 
developer (why else would you want to use git), IMHO it is your itch to 
scratch.

Ciao,
Dscho

P.S.: Sorry if this came over as rude, but I am growing slightly annoyed 
by the expectation of so many that since it is Open Source, I should work 
for free.

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> While you guys are discussing this, please please keep in mind that there are
>> Windows users (/me raises his hand) out there that really really want this
>> too. So, please try to keep it light on the symlinks.
>
> Easy: use cygwin.
>
> Okay, a bit more seriously again: in the recent weeks, it seems that more 
> and more Windows users are asking for features.  Since I guess you are a 
> developer (why else would you want to use git), IMHO it is your itch to 
> scratch.

I do not know this is an appropriate itch to scratch for a
Windows developer to begin with.  The new-workdir setting *is*
about symlinked .git/ metainfo space.  If somebody wants to work
on a filesystem without symlink, he should not be using
new-workdir but something else.  E.g. GIT_DIR + GIT_WORK_TREE,
or perhaps GIT_DIR + core.worktree comes to mind.

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Johannes Schindelin]

Hi,

On Tue, 24 Jul 2007, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >> While you guys are discussing this, please please keep in mind that there are
> >> Windows users (/me raises his hand) out there that really really want this
> >> too. So, please try to keep it light on the symlinks.
> >
> > Easy: use cygwin.
> >
> > Okay, a bit more seriously again: in the recent weeks, it seems that more 
> > and more Windows users are asking for features.  Since I guess you are a 
> > developer (why else would you want to use git), IMHO it is your itch to 
> > scratch.
> 
> I do not know this is an appropriate itch to scratch for a
> Windows developer to begin with.  The new-workdir setting *is*
> about symlinked .git/ metainfo space.  If somebody wants to work
> on a filesystem without symlink, he should not be using
> new-workdir but something else.  E.g. GIT_DIR + GIT_WORK_TREE,
> or perhaps GIT_DIR + core.worktree comes to mind.

... which reminds me that I wanted to overhaul that patch series.

Ciao,
Dscho

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Marius Storm-Olsen]

[-- Attachment #1: Type: text/plain, Size: 2655 bytes --]

Junio C Hamano said the following on 24.07.2007 11:47:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>> While you guys are discussing this, please please keep in mind
>>> that there are Windows users (/me raises his hand) out there
>>> that really really want this too. So, please try to keep it
>>> light on the symlinks.
>> Easy: use cygwin.
>> 
>> Okay, a bit more seriously again: in the recent weeks, it seems
>> that more and more Windows users are asking for features.  Since
>> I guess you are a developer (why else would you want to use git),
>> IMHO it is your itch to scratch.

Yes, I fully agree with this, and I don't have the attitude that 
others should work for me. I'm trying to free up some 'spare time' 
resources so I can pitch in on the effort of making Git work neatly on 
Windows. However, I feared I won't be able to get working on it before 
you guys had decided on a design, so I just wanted voice my opinion on 
the design, so Windows users are not lost in this.


> I do not know this is an appropriate itch to scratch for a Windows
> developer to begin with.  The new-workdir setting *is* about
> symlinked .git/ metainfo space.  If somebody wants to work on a
> filesystem without symlink, he should not be using new-workdir but
> something else.  E.g. GIT_DIR + GIT_WORK_TREE, or perhaps GIT_DIR +
> core.worktree comes to mind.

That's is definitely an option, though it seems to me that its more 
like giving up than a finding a proper solution. In any case, it would 
result in two completely different workflows on systems with and 
without symlink support. I work on both, and would like my workflow to 
be consistent. Of course I could easily add my own scripts on top to 
achieve this, but then we're going back into h4x0r land and not making 
Git more 'available'.

The new-workdir feature doesn't *have* to be about symlinked .git/ 
metainfo space, but could also be about symref'ed .git/ metainfo.
(A discussion was done in 2005s "Getting rid of symlinks in .git?", 
but the conclusion was that it would slow it down too much? *ponder*)

I think you're right in that this is probably not the appropriate itch 
to scratch for a Windows developer to start with, and I have my own 
list of issues to work on when I get the time. File stat'ing 
(daemon/service), CRLF issues, de-SH'ifying commands, non-MinGW native 
build of Git, etc.. Lots to keep my fingers busy :-)

Though, let me also say that I already love working with Git on 
Windows. And I thank each and every one who's working on it, for 
providing such an excellent tool.

-- 
.marius


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Julian Phillips]

On Tue, 24 Jul 2007, Marius Storm-Olsen wrote:

>>  I do not know this is an appropriate itch to scratch for a Windows
>>  developer to begin with.  The new-workdir setting *is* about
>>  symlinked .git/ metainfo space.  If somebody wants to work on a
>>  filesystem without symlink, he should not be using new-workdir but
>>  something else.  E.g. GIT_DIR + GIT_WORK_TREE, or perhaps GIT_DIR +
>>  core.worktree comes to mind.
>
> That's is definitely an option, though it seems to me that its more like 
> giving up than a finding a proper solution. In any case, it would result in 
> two completely different workflows on systems with and without symlink 
> support. I work on both, and would like my workflow to be consistent. Of 
> course I could easily add my own scripts on top to achieve this, but then 
> we're going back into h4x0r land and not making Git more 'available'.
>
> The new-workdir feature doesn't *have* to be about symlinked .git/ metainfo 
> space, but could also be about symref'ed .git/ metainfo.
> (A discussion was done in 2005s "Getting rid of symlinks in .git?", but the 
> conclusion was that it would slow it down too much? *ponder*)

Symref'ed isn't really the right term ... we're not talking about refs 
here.  You would have to basically implement symlinks _inside_ git ...

New-workdir really _is_ all about symlinks.  It already exists as a 
contrib feature - and moving it into core is (as I understand it) really 
just moving it, not redesigning.

If you were going to avoid symlinks, then probably the cleanest way would 
be to have an explict way to point at the actual repo - rather than making 
the working look like a repo if you squint hard enough.  Which sounds 
rather like it would be an extension to GIT_DIR + GIT_WORK_TREE.  I 
haven't looked at it, but it shouldn't be too hard to have a mechanism 
that automatically does GIT_DIR=<there> GIT_WORK_TREE==<here> when the 
appropriate setup is in place?  Though you would have to get it into all 
the appropriate places ...

-- 
Julian

  ---
<aav> coffee on an empty stomach is pretty nasy
<knghtbrd> aav: time to run to the vending machine for cheetos
<aav> cheetos? :)

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Marius Storm-Olsen]

[-- Attachment #1: Type: text/plain, Size: 1503 bytes --]

>> The new-workdir feature doesn't *have* to be about symlinked
>> .git/ metainfo space, but could also be about symref'ed .git/
>> metainfo. (A discussion was done in 2005s "Getting rid of
>> symlinks in .git?", but the conclusion was that it would slow it
>> down too much? *ponder*)
> 
> Symref'ed isn't really the right term ... we're not talking about
> refs here.  You would have to basically implement symlinks _inside_
> git ...

Yes, sorry for mixing up the terms here.

> New-workdir really _is_ all about symlinks.  It already exists as a
>  contrib feature - and moving it into core is (as I understand it)
> really just moving it, not redesigning.

Yes, if simply moving into is core is good enough. IMHO since its 
based largely on FS symlinks it needs a slight redesign before it can 
be moved into core to make it platform agnostic. If not, it should 
remain contrib [again, IMHO].

> If you were going to avoid symlinks, then probably the cleanest way
> would be to have an explict way to point at the actual repo -
> rather than making the working look like a repo if you squint hard
> enough.  Which sounds rather like it would be an extension to
> GIT_DIR + GIT_WORK_TREE.  I haven't looked at it, but it shouldn't
> be too hard to have a mechanism that automatically does
> GIT_DIR=<there> GIT_WORK_TREE==<here> when the appropriate setup is
> in place?  Though you would have to get it into all the appropriate
> places ...

*nod*

-- 
.marius


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Johannes Schindelin]

Hi,

On Tue, 24 Jul 2007, Julian Phillips wrote:

> If you were going to avoid symlinks, then probably the cleanest way would be
> to have an explict way to point at the actual repo - rather than making the
> working look like a repo if you squint hard enough.  Which sounds rather like
> it would be an extension to GIT_DIR + GIT_WORK_TREE.

Almost.  .git/{config,HEAD} are not shared.  So it would be some extension 
that is triggered by something like

	[core]
		realGitDir = /bla/bla/.git/

Hmm?

Ciao,
Dscho

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Josef Weidendorfer]

On Tuesday 24 July 2007, Johannes Schindelin wrote:
> Hi,
> 
> On Tue, 24 Jul 2007, Julian Phillips wrote:
> 
> > If you were going to avoid symlinks, then probably the cleanest way would be
> > to have an explict way to point at the actual repo - rather than making the
> > working look like a repo if you squint hard enough.  Which sounds rather like
> > it would be an extension to GIT_DIR + GIT_WORK_TREE.
> 
> Almost.  .git/{config,HEAD} are not shared.

.git/index, too. And for .git/config, it would probably be better to merge the
two config's (the one from "realGitDir" with 2nd priority).

> So it would be some extension  
> that is triggered by something like
> 
> 	[core]
> 		realGitDir = /bla/bla/.git/

That is more or less almost exacty the last agreement about how to
implement the lightweight checkouts, a few months ago.

Should this even work recursively?

Josef

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Johannes Schindelin]

Hi,

On Tue, 24 Jul 2007, Josef Weidendorfer wrote:

> On Tuesday 24 July 2007, Johannes Schindelin wrote:
> 
> > On Tue, 24 Jul 2007, Julian Phillips wrote:
> > 
> > > If you were going to avoid symlinks, then probably the cleanest way would be
> > > to have an explict way to point at the actual repo - rather than making the
> > > working look like a repo if you squint hard enough.  Which sounds rather like
> > > it would be an extension to GIT_DIR + GIT_WORK_TREE.
> > 
> > Almost.  .git/{config,HEAD} are not shared.
> 
> .git/index, too. And for .git/config, it would probably be better to merge the
> two config's (the one from "realGitDir" with 2nd priority).

I blame it on me being tired.  .git/config _is_ shared, and I meant to 
write "index" instead of "config" there.  Not really a typo, is it?

> > So it would be some extension  
> > that is triggered by something like
> > 
> > 	[core]
> > 		realGitDir = /bla/bla/.git/
> 
> That is more or less almost exacty the last agreement about how to
> implement the lightweight checkouts, a few months ago.

Oh?  I saw no code...  To me it is not an agreement, if no code comes out 
of it.

Ciao,
Dscho

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Josef Weidendorfer]

On Tuesday 24 July 2007, Johannes Schindelin wrote:
> > > So it would be some extension  
> > > that is triggered by something like
> > > 
> > > 	[core]
> > > 		realGitDir = /bla/bla/.git/
> > 
> > That is more or less almost exacty the last agreement about how to
> > implement the lightweight checkouts, a few months ago.
> 
> Oh?  I saw no code...  To me it is not an agreement, if no code comes out 
> of it.

Hmm. Probably depends on any real need for the feature agreed upon.
The new-workdir script simply was "good enough" with Linux.

Josef

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Jakub Narebski]

Julian Phillips wrote:

> On Tue, 24 Jul 2007, Marius Storm-Olsen wrote:
> 
>>>  I do not know this is an appropriate itch to scratch for a Windows
>>>  developer to begin with.  The new-workdir setting *is* about
>>>  symlinked .git/ metainfo space.  If somebody wants to work on a
>>>  filesystem without symlink, he should not be using new-workdir but
>>>  something else.  E.g. GIT_DIR + GIT_WORK_TREE, or perhaps GIT_DIR +
>>>  core.worktree comes to mind.
>>
>> That's is definitely an option, though it seems to me that its more like 
>> giving up than a finding a proper solution. In any case, it would result in 
>> two completely different workflows on systems with and without symlink 
>> support. I work on both, and would like my workflow to be consistent. Of 
>> course I could easily add my own scripts on top to achieve this, but then 
>> we're going back into h4x0r land and not making Git more 'available'.
>>
>> The new-workdir feature doesn't *have* to be about symlinked .git/ metainfo 
>> space, but could also be about symref'ed .git/ metainfo.
>> (A discussion was done in 2005s "Getting rid of symlinks in .git?", but the 
>> conclusion was that it would slow it down too much? *ponder*)
> 
> Symref'ed isn't really the right term ... we're not talking about refs 
> here.  You would have to basically implement symlinks _inside_ git ...
> 
> New-workdir really _is_ all about symlinks.  It already exists as a 
> contrib feature - and moving it into core is (as I understand it) really 
> just moving it, not redesigning.
> 
> If you were going to avoid symlinks, then probably the cleanest way would 
> be to have an explict way to point at the actual repo - rather than making 
> the working look like a repo if you squint hard enough.  Which sounds 
> rather like it would be an extension to GIT_DIR + GIT_WORK_TREE.  I 
> haven't looked at it, but it shouldn't be too hard to have a mechanism 
> that automatically does GIT_DIR=<there> GIT_WORK_TREE==<here> when the 
> appropriate setup is in place?  Though you would have to get it into all 
> the appropriate places ...

I think it could be best solved by having in "worktree" .git/config with
core.gitdir which functions like lower layer in UnionFS like manner. It
means that if git cannot find a file or directory in .git, then it tries
to find it in core.gitdir.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Johannes Schindelin]

Hi,

On Tue, 24 Jul 2007, Marius Storm-Olsen wrote:

> The new-workdir feature doesn't *have* to be about symlinked .git/ 
> metainfo space, but could also be about symref'ed .git/ metainfo. (A 
> discussion was done in 2005s "Getting rid of symlinks in .git?", but the 
> conclusion was that it would slow it down too much? *ponder*)

Right.  I would not do it as symrefs, but as a (potentially ugly, but 
small) change to have the git_dir set to the shared one, and only in case 
of config and HEAD resort to the new_worktree_git_dir.

This would probably be one variable in environment.c, exported in cache.h, 
set in config.c (which would say "new_worktree_git_dir = get_git_dir(); 
setup_new_git_dir(value);"), and the appropriate special handling in
git_path() in path.c.

> I think you're right in that this is probably not the appropriate itch 
> to scratch for a Windows developer to start with, and I have my own list 
> of issues to work on when I get the time. File stat'ing 
> (daemon/service), CRLF issues, de-SH'ifying commands, non-MinGW native 
> build of Git, etc.. Lots to keep my fingers busy :-)

;-)

BTW a friend reported a CRLF issue on Windows, _in spite_ of setting the 
gitattributes appropriately... Did you ever get something like that?

> Though, let me also say that I already love working with Git on Windows. 
> And I thank each and every one who's working on it, for providing such 
> an excellent tool.

Good to hear!

Ciao,
Dscho

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Marius Storm-Olsen]

[-- Attachment #1: Type: text/plain, Size: 1701 bytes --]

 > BTW a friend reported a CRLF issue on Windows, _in spite_ of
 > setting the gitattributes appropriately... Did you ever get
 > something like that?

Hmm, I haven't really had problems with the gitattributes files in the 
directory of the file to be ignored, but rather .git/info/attributes.

There I have had problems with directories containing spaces. The 
escaping of the spaces doesn't work, so even if you do
     foo/bar\ baz/file.txt -crlf
it doesn't work. So, you have to do
     foo/*/file.txt -crlf
instead.


I mainly have the problem with the following:

1) User on Windows is using MinGW port or Cygwin setup with
    DOS EOL.
2) Has core.autocrlf=true
3) Files for XML testcases (for example) is checked into
    repo on Linux (File contains CRLF EOL, since its crucial
    for testing the XML parser)
4) git diff shows all lineending changed, since the
    autocrlf tries to convert the files which are really
    checked into the repo with DOS EOL.

5) You end up adding a bunch of
        foo/bar/baz/* -crlf
    into your .git/info/attributes file or the like.


So, it's look like this ('yes' mean CRLF EOL):
     Repo | Working dir | Convert EOL?
     ---------------------------------
1)  -      LF            no
2)  -      CRLF          yes
3)  LF     LF            no
4)  LF     CRLF          yes
5)  CRLF   LF            no
6)  CRLF   CRLF          yes

The problem is that currently 6) is 'yes', and turns the file into a 
LF file, which it shouldn't.

So, to fix the problem the crlf convertor should really check if the 
file has crlf EOL in the repo, if so, avoid EOL conversion. (6) should 
be 'no' :-)

-- 
.marius


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Marius Storm-Olsen]

[-- Attachment #1: Type: text/plain, Size: 220 bytes --]

Marius Storm-Olsen said the following on 24.07.2007 15:26:
> So, it's look like this ('yes' mean CRLF EOL):

Bah, ignore "('yes' mean CRLF EOL)". I rewrote the table and forgot to 
nuke that part.

-- 
.marius


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Johannes Schindelin]

Hi,

On Tue, 24 Jul 2007, Marius Storm-Olsen wrote:

> So, it's look like this ('yes' mean CRLF EOL):
>     Repo | Working dir | Convert EOL?
>     ---------------------------------
> 1)  -      LF            no
> 2)  -      CRLF          yes
> 3)  LF     LF            no
> 4)  LF     CRLF          yes
> 5)  CRLF   LF            no
> 6)  CRLF   CRLF          yes
> 
> The problem is that currently 6) is 'yes', and turns the file into a LF file,
> which it shouldn't.

Shouldn't it?  But then you should set core.autocrlf = false, no?

AFAIU the purpose of autocrlf is to _always_ have UNIX line endings in the 
checked in stuff.

Ciao,
Dscho

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Marius Storm-Olsen]

[-- Attachment #1: Type: text/plain, Size: 3287 bytes --]

>> So, it's look like this ('yes' mean CRLF EOL):
>>     Repo | Working dir | Convert EOL?
>>     ---------------------------------
>> 1)  -      LF            no
>> 2)  -      CRLF          yes
>> 3)  LF     LF            no
>> 4)  LF     CRLF          yes
>> 5)  CRLF   LF            no
>> 6)  CRLF   CRLF          yes
>>
>> The problem is that currently 6) is 'yes', and turns the file into
>> a LF file, which it shouldn't.
> 
> Shouldn't it?  But then you should set core.autocrlf = false, no?
> 
> AFAIU the purpose of autocrlf is to _always_ have UNIX line endings
> in the checked in stuff.

I realize that I might be talking 'out of context', so to speak; so it's
hard to see where I'm going with this. So, I'll start from the
beginning. :-)

1) IMO, git should on Windows always do CRLF conversion, as this is what
Windows developers in general expect. (CRLF text-files that is, not the
conversion.) Meaning that
    core.autocrlf = Windows
by default. Where 'Windows' would be of true/false value which is true
when on Windows and false when on other platforms. (Not that we should
_have_ such an option, but the concept at least.)

2) Most Windows developers in the category above currently do
    git-config --global core.autocrlf true
once, and be done with it.
However, for every text-file they want in the repo which _should_
contain CRLF EOLs they would have to add this file to either a
.gitattributes file in that same directory, or to
    .git/info/attributes
with the
    <filepath> -crlf
to ensure that the autocrlf conversion is not triggered for those files.
Now, for Unix users that seems like a small price to pay, and of course
_they_ don't have to worry about it. It's up to the Windows developers
to take the pain and add these .gitattributes files, and keep track
whenever new CRLF files appear in the repo from other non-Windows
developers.

3) My suggestion in the previous mail would to a large extent alleviate
this problem, since once in the repo with CRLF lineendings the 'autocrlf
conversion' routine wouldn't automatically try to convert it back to LF
endings, even if this file is not in any attributes file with '-crlf'.

It would mean that we wouldn't have to add _any_ files to attributes
files at all, but only have to teach git a way to avoid crlf-converting
a given file when commiting a change. For example, on Windows you could
then do something like:
    git update-index --crlf my_DOS_file.txt
    git commit -m "Add a CRLF file to the repo"
then forget about it.

No need to add a .gitattributes in your own repo.
No need for linux users to worry about Windows users.
No need to Windows users to clean up the repos for the linux users.

IMO, the .gitattributes file with '<filepath> -crlf' is a hack-fix to a
problem we shouldn't be having in the first place. We should be able to
write in the git documentation:
   "Text files are stored with Unix line ending in Git. If you need a
text file to contain DOS line endings on all platforms, use the --crlf
option on the update-index command."... or something to that effect.

Ok, a bit longer mail than I expected/wanted, but I hope it explains the
idea successfully, and convincingly. ;-)

Later!

--
.marius


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Johannes Schindelin]

Hi,

On Tue, 24 Jul 2007, Marius Storm-Olsen wrote:

> 1) IMO, git should on Windows always do CRLF conversion, as this is what
> Windows developers in general expect. (CRLF text-files that is, not the
> conversion.) Meaning that
>     core.autocrlf = Windows
> by default. Where 'Windows' would be of true/false value which is true
> when on Windows and false when on other platforms. (Not that we should
> _have_ such an option, but the concept at least.)

I do not think so.

core.autocrlf is only about the relationship between the working tree and 
the repository.

So if you want CR/LF line endings always, just do not set that flag 
(which defaults to false).

If you want LF line endings in the repo, but not necessarily in the 
working tree, set core.autocrlf to input.

If you want LF line endings sometimes, but CR/LF at other times, but do 
not care if the revisions in the repository will have LF or CR/LF, do not 
set that flag.

Git is really slowed down tremendously just by the fact that it runs on 
Windows.  You should not add to that.

IMHO in most cases -- even on Windows -- you do not want to set autocrlf 
at all.  Because you do not need to store the file different from the 
version you have in the working tree.

The only situation where I think it makes sense, is when you have both 
Windows and Unix developers, _and_ your Windows tools sometimes produce 
CR/LF stupidly.  But then I'd set it to "input".

BTW no need to fuzz about binary files, which want to be in the object 
database without being converted.  Our heuristics has so far been pretty 
successful in discerning binary from text files.

Ciao,
Dscho

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Marius Storm-Olsen]

[-- Attachment #1: Type: text/plain, Size: 4238 bytes --]

>> 1) IMO, git should on Windows always do CRLF conversion, as this is what
>> Windows developers in general expect. (CRLF text-files that is, not the
>> conversion.) Meaning that
>>     core.autocrlf = Windows
> 
> I do not think so.
> 
> core.autocrlf is only about the relationship between the working tree and 
> the repository.
> 
> So if you want CR/LF line endings always, just do not set that flag 
> (which defaults to false).
> 
> If you want LF line endings in the repo, but not necessarily in the 
> working tree, set core.autocrlf to input.
> 
> If you want LF line endings sometimes, but CR/LF at other times, but do 
> not care if the revisions in the repository will have LF or CR/LF, do not 
> set that flag.

Ok, here we fundamentally disagree.
IMO Windows user expect files to be DOS style, since all other files
are.  Yes, most newer tools 'handle' Unix style files, but creating new
ones will mostly be DOS style. Some will actually wreak havoc on your
files, and start adding DOS line endings in the middle of your Unix line
ending file. I've seen it happen. So, dealing with Unix style text files
on Windows can be a problem for some people.

So, normally, when developing on Windows you'd expect DOS files, nothing
else. (Note that we're not talking about your average MinGW or Cygwin
user here, since they are known to the issues and how to tackle them)

> Git is really slowed down tremendously just by the fact that it runs on 
> Windows.  You should not add to that.

The auto crlf conversion is not the slow down here, and the time spent
there is negligible. I use autocrlf on all my repos on Windows, and
don't notice it. Filestat'ing on the other hand.. :-)


> IMHO in most cases -- even on Windows -- you do not want to set autocrlf 
> at all.  Because you do not need to store the file different from the 
> version you have in the working tree.

Not true. I believe, especially at the moment, most Git users on Windows
are mostly developing code in a cross-platform manner, and therefore
care about this problem.


> The only situation where I think it makes sense, is when you have both 
> Windows and Unix developers, _and_ your Windows tools sometimes produce 
> CR/LF stupidly.  But then I'd set it to "input".

That's ok _now_, because most of the Git user group is experienced
developer that understand the problem. I'm trying to see past that
state, and prepare Git for more 'common' usage on Windows. They'd expect
text files on Windows to be handled correctly, without any fuzz.
No tweaking of config options to make it work on Windows. No problems
with sharing repositories with Unix developers. Just work. That's not
the current state. But it could be.


> BTW no need to fuzz about binary files, which want to be in the
> object database without being converted.  Our heuristics has so far
> been pretty successful in discerning binary from text files.

Yeah, I have no beef with the binary detection. It seems to work fine.
At least I haven't had a problem with it yet, and it's not what we're
discussing.

Ok, I come from the Perforce world, so here how it works there:
1) Files are stored with Unix line endings in the repository.
2) Conversion is done on Windows (and older Macs) upon checkout, if the
file is a text file.
3) It has binary file detection when you add it to the depot, so if you
and to add a DOS line ending file to the repo, you have to mark it as a
binary file manually

Git does 1) and 2) already, and with the EOL detection in the repo file,
(when you've already detected that a file has changed, so there's not
much time wasted with that) to eliminate the 'yes' in point 6) in the
original mail, should help implement 3) above well enough. It's simply,
"If it was a CRLF file before, no need to convert it to LF now", and the
problem is largely fixed. Then it's only when we want to commit a new
CRLF file that we need a way to 'turning off' the autocrlf for just
_that_ file for _that_ commit. And presto, you'd have something which
most Windows users would expect. And Git would probably be adapted on
Windows more quickly, which this is all about. :-) IMHO.

--
.marius


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Alex Riesen]

Marius Storm-Olsen, Tue, Jul 24, 2007 21:36:06 +0200:
> IMO Windows user expect files to be DOS style, since all other files
> are.  Yes, most newer tools 'handle' Unix style files, but creating new
> ones will mostly be DOS style. Some will actually wreak havoc on your
> files, and start adding DOS line endings in the middle of your Unix line
> ending file. I've seen it happen. So, dealing with Unix style text files
> on Windows can be a problem for some people.

I have to stay with Windows, but I'd absolute hate having their stupid
line-ending by default. As will my project supervisor, and he gets
changes from something like 300 developers. You will definitely get
their votes against changing the default

> > Git is really slowed down tremendously just by the fact that it runs on 
> > Windows.  You should not add to that.
> 
> The auto crlf conversion is not the slow down here, and the time spent
> there is negligible. I use autocrlf on all my repos on Windows, and
> don't notice it. Filestat'ing on the other hand.. :-)

Of course you wont notice it: you're already on Windows.

> > IMHO in most cases -- even on Windows -- you do not want to set autocrlf 
> > at all.  Because you do not need to store the file different from the 
> > version you have in the working tree.
> 
> Not true. I believe, especially at the moment, most Git users on Windows
> are mostly developing code in a cross-platform manner, and therefore
> care about this problem.

Yes. They solve it by working fulltime in \n-lineending. Avoiding that
stupid Visual Studio and Notepad helps too.

> > The only situation where I think it makes sense, is when you have both 
> > Windows and Unix developers, _and_ your Windows tools sometimes produce 
> > CR/LF stupidly.  But then I'd set it to "input".
> 
> That's ok _now_, because most of the Git user group is experienced
> developer that understand the problem. I'm trying to see past that
> state, and prepare Git for more 'common' usage on Windows. They'd expect
> text files on Windows to be handled correctly, without any fuzz.

Just make the windows installer to setup templates for CR/LF depending
on checkbox "[ ] I am Windows idiot, standard issue".

> No tweaking of config options to make it work on Windows. No problems
> with sharing repositories with Unix developers. Just work. That's not
> the current state. But it could be.

It is for me. It will not be that with your suggested default.

> Ok, I come from the Perforce world, so here how it works there:
> 1) Files are stored with Unix line endings in the repository.
> 2) Conversion is done on Windows (and older Macs) upon checkout, if the
> file is a text file.
> 3) It has binary file detection when you add it to the depot, so if you
> and to add a DOS line ending file to the repo, you have to mark it as a
> binary file manually

You always setup the lineending conversion in perforce. For each and
every client. There is no default. I just don't see what to learn from
them (if there ever was something to learn from).

> ... And Git would probably be adapted on
> Windows more quickly, which this is all about. :-) IMHO.

It is hardly worth it. Git already has to put up with ugly workarounds
just because of the stupidities coming from that windows. It has had
seldom any benefit from supporting this !@#$ing awkward platform.

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Marius Storm-Olsen]

[-- Attachment #1: Type: text/plain, Size: 6757 bytes --]

Alex Riesen said the following on 25.07.2007 01:15:
> Marius Storm-Olsen, Tue, Jul 24, 2007 21:36:06 +0200:
>> IMO Windows user expect files to be DOS style, since all other files
>> are.  Yes, most newer tools 'handle' Unix style files, but creating new
>> ones will mostly be DOS style. Some will actually wreak havoc on your
>> files, and start adding DOS line endings in the middle of your Unix line
>> ending file. I've seen it happen. So, dealing with Unix style text files
>> on Windows can be a problem for some people.
> 
> I have to stay with Windows, but I'd absolute hate having their stupid
> line-ending by default. As will my project supervisor, and he gets
> changes from something like 300 developers. You will definitely get
> their votes against changing the default

Ok, so maybe not changing the default.
Though it's weird behavior for _most_ Windows developers out there, I 
agree that the current Windows Git population would mostly prefer the 
Unix line endings. And I can see how someone who's working on Windows 
and handling a lot of patches from other developers of multiple OSs 
also wanting the non-platform-standard Unix line-endings.
I still would argue that it's not the norm. Currently yes, in the 
foreseeable future, I doubt it.


>>> Git is really slowed down tremendously just by the fact that it runs on 
>>> Windows.  You should not add to that.
>> The auto crlf conversion is not the slow down here, and the time spent
>> there is negligible. I use autocrlf on all my repos on Windows, and
>> don't notice it. Filestat'ing on the other hand.. :-)
> 
> Of course you wont notice it: you're already on Windows.

Come on, when did a search and replace in a normal size source file 
take any time? It's really not an argument for not doing CRLF 
conversion on a platform that creates CRLF files by default!

If you want files to be stored in the repo with Unix line-endings, 
which I expect most people would want, to share it with other 
non-Windows developers, you _have_ to do it. (No, not the MSys/Cygwin 
users)


>>> IMHO in most cases -- even on Windows -- you do not want to set autocrlf 
>>> at all.  Because you do not need to store the file different from the 
>>> version you have in the working tree.
>> Not true. I believe, especially at the moment, most Git users on Windows
>> are mostly developing code in a cross-platform manner, and therefore
>> care about this problem.
> 
> Yes. They solve it by working fulltime in \n-lineending. Avoiding that
> stupid Visual Studio and Notepad helps too.

Huh? You just removed more than 3 _million_[1] potential users.. (Some 
say 8 million [2]) Is that a good argument? Why should developers on 
Windows avoid using Windows tools? Because they're 'idiots'? (ref 
further down in your reply)

Anyways, even if a tool on Windows _handles_ LF line-endings perfectly 
fine, most of these tools still create CR/LF files when you create a 
new text file.
(No, again not the MSys or LF-configured Cygwin vim/emacs/<insert your 
favorite unix editor here>. But the native editors which handles both 
formats. There's plenty of those too.)


>>> The only situation where I think it makes sense, is when you have both 
>>> Windows and Unix developers, _and_ your Windows tools sometimes produce 
>>> CR/LF stupidly.  But then I'd set it to "input".
>> That's ok _now_, because most of the Git user group is experienced
>> developer that understand the problem. I'm trying to see past that
>> state, and prepare Git for more 'common' usage on Windows. They'd expect
>> text files on Windows to be handled correctly, without any fuzz.
> 
> Just make the windows installer to setup templates for CR/LF depending
> on checkbox "[ ] I am Windows idiot, standard issue".

Mmm, ok. If I'm an idiot just for using Windows, I guess the battle is 
lost already.


>> No tweaking of config options to make it work on Windows. No problems
>> with sharing repositories with Unix developers. Just work. That's not
>> the current state. But it could be.
> 
> It is for me. It will not be that with your suggested default.

Then I wouldn't put you in the normal Windows developer category, but 
rather the one which is dependent on MSys or Cygwin, and live in 
bash/zsh on Windows. I would argue that most of those 3/8 million VS 
users are not in the same category as you.

But sure, I don't mind having to set core.autocrlf=true when I 
configure Git, but then I would like that mode to work without the 
extra hassle. (Most people don't want to change already incorporated 
options, which is fully understandable)


>> Ok, I come from the Perforce world, so here how it works there:
>> 1) Files are stored with Unix line endings in the repository.
>> 2) Conversion is done on Windows (and older Macs) upon checkout, if the
>> file is a text file.
>> 3) It has binary file detection when you add it to the depot, so if you
>> and to add a DOS line ending file to the repo, you have to mark it as a
>> binary file manually
> 
> You always setup the lineending conversion in perforce. For each and
> every client. There is no default. I just don't see what to learn from
> them (if there ever was something to learn from).

No you don't. You _can_, but the default when you create a 'client 
spec' is the platform specific line endings. Only 'Unix' users working 
on Windows really take the trouble of changing the line endings to 
they work with their MSys or Cygwin enviroments.


>> ... And Git would probably be adapted on
>> Windows more quickly, which this is all about. :-) IMHO.
> 
> It is hardly worth it. Git already has to put up with ugly workarounds
> just because of the stupidities coming from that windows. It has had
> seldom any benefit from supporting this !@#$ing awkward platform.

Well, I guess with this opinion there really no point in me trying to 
prove a point. If all Windows users are 'idiots' on a '!@#$ing 
awkward' platform, I'm probably just an 'idiot' trying to help out.

I hope it's not the general opinion of the Git team that Windows users 
should just bugger off..

Now, personally I don't have a problem with all this line ending 
stuff. I work on Windows and Unix on a daily basis, addicted to MSys 
and Cygwin for performing my daily tasks, and use tools which handles 
LF and CR/LF interchangeably without any problems. So, the current 
state of Git works for me. I'm just trying to help figuring out what 
we can do to make the tool even more platform agnostic, and work as 
expected.


[1] http://msdn.microsoft.com/vsip
[2] http://www.regdeveloper.co.uk/2007/06/09/vs_shell_eclipse/

-- 
.marius


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Johannes Schindelin]

Hi,

On Wed, 25 Jul 2007, Marius Storm-Olsen wrote:

> Alex Riesen said the following on 25.07.2007 01:15:
>
> > I have to stay with Windows, but I'd absolute hate having their stupid 
> > line-ending by default. As will my project supervisor, and he gets 
> > changes from something like 300 developers. You will definitely get 
> > their votes against changing the default
> 
> Ok, so maybe not changing the default.
> Though it's weird behavior for _most_ Windows developers out there, I agree
> that the current Windows Git population would mostly prefer the Unix line
> endings. And I can see how someone who's working on Windows and handling a lot
> of patches from other developers of multiple OSs also wanting the
> non-platform-standard Unix line-endings.

Even MacOSX saw the light.  More and more tools on Windows (not from M$, 
mind you, they still want to lock you in, and I am continually amazed at 
the _willingness_ to be locked in!) are behaving sane.

> > Marius said:
> >
> > > I believe, especially at the moment, most Git users on Windows are 
> > > mostly developing code in a cross-platform manner, and therefore 
> > > care about this problem.
> > 
> > Yes. They solve it by working fulltime in \n-lineending. Avoiding that 
> > stupid Visual Studio and Notepad helps too.
> 
> Huh? You just removed more than 3 _million_[1] potential users.. (Some say 8
> million [2]) Is that a good argument? Why should developers on Windows avoid
> using Windows tools? Because they're 'idiots'? (ref further down in your
> reply)

When somebody does not want the same as you, it comes natural to think of 
that person as an idiot.  That's psychology, not something rational.

However, I think we are talking about an almost non-issue here: those 3-80 
million users "just waiting" for Git probably would not touch it without a 
complete installer.  And that installer could just ask "which line ending 
do you want to suffer through today?"

Which brings _me_ back to my pet hate: why on earth is _no_ one of those 
30-800 billion Windows users trying to do something about the lack of a 
proper native Windows support for Git?  The MinGW port contains commits 
from these people (skipping everything that is in official git.git):

Johannes Schindelin
Johannes Sixt
Junio C Hamano
Mark Levedahl
Simon 'corecode' Schubert

I know for certain that the first person, and also the third person, are 
not exactly Windows users.  I guess not even the last two persons are.

Note that more work has been done on git-gui, because those poor Windows 
developers are evidently so uncomfortable with the keyboard that a GUI is 
needed.  AFAIK only Johannes Sixt and Shawn Pearce worked on the 
Windows/git-gui interaction (and again, Shawn is not a Windows user).

Han-Wen made an installer, right, but that installer is lacking bash and 
perl, and proper testing, because it was just a proof-of-concept.  
Han-Wen is no Windows user either.  I tried to pick up on that work, but 
unfortunately "gub" (the cross compiling framework he used) is so 
Pythonesque that I was put off.

So this leaves me with the question: do Windows users really want a proper 
native Windows support for Git?  If the answer is yes, why don't they _do_ 
(as in "not talk") something about it?

(Let me take a BIG, BIIIIIG exception here: Johannes Sixt has worked long 
and hard and extremely well on this beast.  He is certainly the exception 
that proves the rule.)

Ciao,
Dscho

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Steven Grimm]

Johannes Schindelin wrote:
> So this leaves me with the question: do Windows users really want a proper 
> native Windows support for Git?  If the answer is yes, why don't they _do_ 
> (as in "not talk") something about it?
>   

I'm not a Windows user, but I know some, so I can maybe answer this: 
They do want that, but what they primarily want is a good DVCS they can 
use without trouble. I know at least two Windows people who took a look 
at the Win32 git, had trouble with it, then looked at Mercurial (which, 
whatever opinions you might have about it, does work better on Windows) 
and just stuck with that since it met their needs.

The fact that Mercurial exists is a big disincentive for Windows people 
to work on git; unless they specifically want to interoperate with an 
existing git repository, hg gives them a lot of the same features that 
we enjoy in git land. And they don't have to fiddle with MinGW or Cygwin 
or anything like that. The distance between git and hg is small enough 
in their minds that it's not worth the unknown amount of effort to work 
on making git run better.

At least, that's my take on it. Maybe an actual Windows git user will 
tell me I'm full of it...

-Steve

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Andy Parkins]

On Wednesday 2007 July 25, Johannes Schindelin wrote:

> So this leaves me with the question: do Windows users really want a proper
> native Windows support for Git?  If the answer is yes, why don't they _do_
> (as in "not talk") something about it?

I don't disagree with you at all - it is completely ridiculous for Windows 
users to moan about lack of Windows support without contributing any help.  
However, I think there is a good reason.

I think it's a chicken and egg problem.  The only reason I started making 
(small) contributions to git was because I was using it already.  I didn't 
set out with the goal "to improve git"; I set out looking for a DVCS.  
Luckily for me, I use Linux so git worked pretty well for me straight away.

The same is not true for Windows users.  Even if we ignore the fact that 
Windows users are notoriously less open-source savvy; it's unlikely that 
we'll get any Windows contributions until there are some threshold number of 
developers using git on Windows.

Open-source is all about scratching an itch, I can't see how Windows 
developers can get a gitch to scratch without being users of git first.  On 
the positive side though, there surely must come a point when the Windows 
port is "good enough" that it will start to gather users and hence 
developers.  Until then, I suppose it's just a matter of shouting "patch" 
every time a windows user asks for a feature :-)


Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Marius Storm-Olsen]

[-- Attachment #1: Type: text/plain, Size: 2615 bytes --]

Andy Parkins said the following on 25.07.2007 13:05:
> On Wednesday 2007 July 25, Johannes Schindelin wrote:
> 
>> So this leaves me with the question: do Windows users really want
>> a proper native Windows support for Git?  If the answer is yes,
>> why don't they _do_ (as in "not talk") something about it?
> 
> I don't disagree with you at all - it is completely ridiculous for
> Windows users to moan about lack of Windows support without
> contributing any help. However, I think there is a good reason.
> 
> I think it's a chicken and egg problem.  The only reason I started
> making (small) contributions to git was because I was using it
> already.  I didn't set out with the goal "to improve git"; I set
> out looking for a DVCS. Luckily for me, I use Linux so git worked
> pretty well for me straight away.
> 
> The same is not true for Windows users.  Even if we ignore the fact
> that Windows users are notoriously less open-source savvy; it's
> unlikely that we'll get any Windows contributions until there are
> some threshold number of developers using git on Windows.
> 
> Open-source is all about scratching an itch, I can't see how
> Windows developers can get a gitch to scratch without being users
> of git first.  On the positive side though, there surely must come
> a point when the Windows port is "good enough" that it will start
> to gather users and hence developers.  Until then, I suppose it's
> just a matter of shouting "patch" every time a windows user asks
> for a feature :-)

Hi Andy,

Your mail is refreshingly spot on. I agree fully with what you say.
I will try to do my part to get Git to this 'threshold', so we can get 
a proper Windows community behind it too. (It's just a matter of time 
and resources, which I hope we clear up soon)
My first roadmap item will be to get a fully native compile of the 
built-in code. If we at least have a Git built with native tools, I 
think we'll have a lot more people wanting(/able?) to contribute.

AFAIK the MinGW port is cross-compiled on Linux, and can be hard to 
set up on Windows. The required MinGW packages are scattered all over 
the place. So, it's not impossible at the moment, but I guess most 
Windows users feel a bit unmotivated to work on the code mostly since 
they'll have to develop using Cygwin. (I don't know if that's the 
reason, just a hunch)

So, IMO its not that Windows users don't _want_ to contribute. I think 
they feel they can't. Let's see if we can fix that. I'll let the list 
know as soon as I get native builds going.

Later!

--
.marius


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Johannes Schindelin]

Hi,

On Wed, 25 Jul 2007, Marius Storm-Olsen wrote:

> Andy Parkins said the following on 25.07.2007 13:05:
> > On Wednesday 2007 July 25, Johannes Schindelin wrote:
> > 
> > > So this leaves me with the question: do Windows users really want
> > > a proper native Windows support for Git?  If the answer is yes,
> > > why don't they _do_ (as in "not talk") something about it?
> > 
> > I don't disagree with you at all - it is completely ridiculous for
> > Windows users to moan about lack of Windows support without
> > contributing any help. However, I think there is a good reason.
> > 
> > I think it's a chicken and egg problem.  The only reason I started
> > making (small) contributions to git was because I was using it
> > already.  I didn't set out with the goal "to improve git"; I set
> > out looking for a DVCS. Luckily for me, I use Linux so git worked
> > pretty well for me straight away.
> > 
> > The same is not true for Windows users.  Even if we ignore the fact
> > that Windows users are notoriously less open-source savvy; it's
> > unlikely that we'll get any Windows contributions until there are
> > some threshold number of developers using git on Windows.
> > 
> > Open-source is all about scratching an itch, I can't see how
> > Windows developers can get a gitch to scratch without being users
> > of git first.  On the positive side though, there surely must come
> > a point when the Windows port is "good enough" that it will start
> > to gather users and hence developers.  Until then, I suppose it's
> > just a matter of shouting "patch" every time a windows user asks
> > for a feature :-)
> 
> Hi Andy,
> 
> Your mail is refreshingly spot on. I agree fully with what you say.
> I will try to do my part to get Git to this 'threshold', so we can get a
> proper Windows community behind it too. (It's just a matter of time and
> resources, which I hope we clear up soon)
> My first roadmap item will be to get a fully native compile of the built-in
> code. If we at least have a Git built with native tools, I think we'll have a
> lot more people wanting(/able?) to contribute.

Well, why don't people come here then, say "I am willing to test whatever 
you throw at me, and contribute the installer"?  Huh?

I once (AGAIN!) extend this offer to _anybody_.  I'll make a zip of 
everything you need, I'll fix bugs as you report them,  I'll do plenty of 
stuff.

But you have to give me an INCENTIVE!

(I am usually not such a shouter, but underlining seems not to help here.  
As can be seen by the infamous "When can I expect" mail.)

> AFAIK the MinGW port is cross-compiled on Linux, and can be hard to set 
> up on Windows. The required MinGW packages are scattered all over the 
> place. So, it's not impossible at the moment, but I guess most Windows 
> users feel a bit unmotivated to work on the code mostly since they'll 
> have to develop using Cygwin. (I don't know if that's the reason, just a 
> hunch)

No, not even close.  It is written in README.MinGW how to go about 
compiling yourself.  Only Han-Wen cross-compiled the beast on Linux.

> So, IMO its not that Windows users don't _want_ to contribute. I think 
> they feel they can't. Let's see if we can fix that.

I beg to differ here, strongly.  On the two first points at least.  On the 
third point, I am already disap-point-ed.

Ciao,
Dscho

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Linus Torvalds]

On Wed, 25 Jul 2007, Andy Parkins wrote:
> 
> I don't disagree with you at all - it is completely ridiculous for Windows 
> users to moan about lack of Windows support without contributing any help.  
> However, I think there is a good reason.
> 
> I think it's a chicken and egg problem.  The only reason I started making 
> (small) contributions to git was because I was using it already.

I think this is 100% true, and worth repeating.

A lot of people seem to think that open source is about having lots of 
people help with the project, and that development happens much faster 
that way.

But what people often seem to miss is that pretty much all projects 
didn't start out "open source". They *all* started out as somebodys 
personal project (where "somebody" could be a small group, not just an 
individual, of course), and while maybe the _license_ was open source from 
the beginning, you cannot get away from the fact that in order to actually 
be developed as open source, in the end some *individual* has to just do 
it.

No project ever gets useful help until it's already useful. Being open 
source doesn't get you past that hump - it only helps you *after* you've 
already gotten past it.

Now, admittedly, I think one issue with Windows is that the "hump" is 
simply much bigger. The initial cost (not necessarily in money, but in 
effort) of getting involved in a development process is just a *lot* 
higher for Windows users than it is for just about any UNIX.

If you're on some unix platform, the cost of getting involved is basically 
that the project should already work to some degree, and then there may be 
some relatively *trivial* issues with making sure that you've got a 
compiler installed and the basic libraries. But that's really quite easy 
on just about any UNIX, to the point that most people don't even have to 
think about it.

In contrast, on Windows that "hump" is a whole lot harder. You don't just 
have to have a compiler, you have to have some *specific* compiler, 
because under Windows, they all have different development environments, 
and few projects support them all. 

So you have a double whammy: not only are people doing less development on 
Windows to start with (so the project itself is likely not as usable), but 
something as totally *trivial* as getting a simple C development 
environment isn't even trivial. And git makes it worse by requiring a very 
odd component (in Windows terms): the shell.

I really hope we'll get the the C rewrite merged soon. Especially the big 
ones, ie commit / merge / am / clone / fetch. Those are the complex ones 
that it's hard to get excited about when they don't work. Once those work 
well, you could probably use git pretty completely even without shell, 
even if you'd be missing a few features - and those features would now be 
small enough that a relative beginner can cut their teeth on them.

The good news seems to be that most of those big scripts already exist in 
a C version, so it's not like it's some utopian dream any more.

But getting a development environment is still much more painful under 
Windows than just about anywhere else.

			Linus

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Christian MICHON]

On 7/25/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> Now, admittedly, I think one issue with Windows is that the "hump" is
> simply much bigger. The initial cost (not necessarily in money, but in
> effort) of getting involved in a development process is just a *lot*
> higher for Windows users than it is for just about any UNIX.
>
> If you're on some unix platform, the cost of getting involved is basically
> that the project should already work to some degree, and then there may be
> some relatively *trivial* issues with making sure that you've got a
> compiler installed and the basic libraries. But that's really quite easy
> on just about any UNIX, to the point that most people don't even have to
> think about it.

http://www.openlina.org could closing this gap, as a temp fix.

It's supposed to help running linux native binaries on windows through
some virtualization layer. Speed is supposed to be good, the host filesystem
is supposed to be accessible. Many suppositions, I haven't evaluated
this beast yet.

If this is truly usable, it would mean an easy migration for unix users,
using the command line.

For true windows users, git-gui, gitk and ultimately a windows explorer
plugin/addon will be needed still, as mentionned earlier in this thread.

It is to be noted though that C conversion and shell replacement
will not be all that is needed.

Today, I've a colinux environment containing git-1.5.2.3 and all needed
tools for development (shell, compiler, editor). When I perform some git
operations in any linux controlled filesystem (ramfs, ext2 over cobd), no
problem, git works as advertised.

When I used shared windows folder in the ntfs filesystem, there are
issues. Fsync fails when writing files (could be colinux related), but
git-init produces different .git/config file and git-commit does not work
(fatal: index file smaller than expected). The last 2 problems should be
windows related I believe and should hit as soon as the shell over C
portage will be done.

Unless the current patches in mingw.git can fix these of course.

-- 
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Julian Phillips]

On Mon, 23 Jul 2007, Johannes Schindelin wrote:

> Hi,
>
> On Sun, 22 Jul 2007, Julian Phillips wrote:
>
>> On Sun, 22 Jul 2007, Johannes Schindelin wrote:
>>
>>> Well, I am really not interested in shooting myself in the foot, and
>>> having that option in checkout would make that much more likely.  So I
>>> really, really want to have this in git-branch.
>>
>> Fair enough.  Your patch - so you get to choose.  I don't have any
>> strong objections (and no power to express any if I did :P) - just
>> airing my POV ;)
>
> ;-)
>
> In related news, you got me convinced that my "solution" is not
> sufficient.  So I guess this patch has to wait until after 1.5.3 _and_
> after we convinced Junio to put his BASE index extension in again.
>
> FWIW once git-checkout is builtin, I'll add "--new-workdir" for it.  Deal?

Sounds good to me.  Even gives me some motivation to see checkout a 
builtin sooner rather than later ;)

-- 
Julian

  ---
Logic is the chastity belt of the mind!