* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Marius Storm-Olsen @ 2007-08-06 5:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Torgil Svensson, Dmitry Kakurin, git
In-Reply-To: <Pine.LNX.4.64.0708060054020.14781@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]
Johannes Schindelin said the following on 06.08.2007 02:11:
> On Mon, 6 Aug 2007, Torgil Svensson wrote:
>>>> 2. rxvt-terminal had some freezes
>>> I did not experience those. Could you research further?
>
> Those "freezes" were due to the fact that Rxvt incorrectly updates
> stderr in a blocking way, or not at all (don't know which). There
> are more things that do not work in Rxvt, and only after trying the
> same in cmd (which I do not like for various reasons) I found out
> that rxvt.exe is at fault.
>
> I would be glad if somebody managed to compile rxvt herself and fix
> all those bugs (see http://code.google.com/p/msysgit/ for a short
> list of the most pressing issues I found). As it is, I have enough
> work to do with the rest of msysGit, and for the moment, I can at
> least work in cmd. Even ssh push works.
Hi guys,
Instead of hacking away on this old terminal, what about simply
including another nice Open Source project?
On Windows we have a replacement terminal, which has all the features
you want, and also supports tabs like Konsole. I've used it for
several years, and it works great. Have a look and see if you like it,
then we can add it to the repo:
http://sourceforge.net/projects/console/
Original name, ey? :-)
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: [RFC (take 3)] Git User's Survey 2007
From: Asger Ottar Alstrup @ 2007-08-06 5:48 UTC (permalink / raw)
To: git
In-Reply-To: <f95srg$dki$1@sea.gmane.org>
Jakub Narebski wrote:
> I don't quite understand: what would be the question? Note that survey is
> meant to help git community notice what needs improvements.
Maybe include a question about hosting?
Do you use, or have a need for, a git hosting service?
[ ] No
[ ] Yes, an open source hosting service
[ ] Yes, a hosting service for commercial projects
Regards,
Asger
^ permalink raw reply
* [PATCH] setup.c:verify_non_filename(): don't die unnecessarily while disambiguating
From: Junio C Hamano @ 2007-08-06 7:24 UTC (permalink / raw)
To: git; +Cc: spearce
If you have a working tree _file_ "foo", attempt to refer to a
branch "foo/bar" without -- to disambiguate, like this:
$ git log foo/bar
tried to make sure that foo/bar cannot be naming a working tree
file "foo/bar" (in which case we would say "which one do you
want? A rev or a working tree file? clarify with -- please").
We run lstat("foo/bar") to check that. If it does not succeed,
there is no ambiguity.
That is good. But we also checked the error status for the
lstat() and expected it to fail with ENOENT. For this
particular case, however, it fails with ENOTDIR. That one
should be treated as "expected error" as well.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This was from a real-life experience Shawn had.
setup.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/setup.c b/setup.c
index a45ea83..2b8e8c0 100644
--- a/setup.c
+++ b/setup.c
@@ -103,7 +103,7 @@ void verify_non_filename(const char *prefix, const char *arg)
if (!lstat(name, &st))
die("ambiguous argument '%s': both revision and filename\n"
"Use '--' to separate filenames from revisions", arg);
- if (errno != ENOENT)
+ if (errno != ENOENT && errno != ENOTDIR)
die("'%s': %s", arg, strerror(errno));
}
--
1.5.3.rc4.15.ga2c3d
^ permalink raw reply related
* Re: way to automatically add untracked files?
From: Johan Herland @ 2007-08-06 7:30 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <f95q7l$8lv$2@sea.gmane.org>
On Monday 06 August 2007, Jakub Narebski wrote:
> Johan Herland wrote:
>
> > So different users seem to have two different (almost incompatible)
> > expectations to git-add:
> >
> > 1. git-add adds new files into the index. git-add has _no_ business removing
> > deleted files from the index.
> >
> > 2. git-add updates the index according to the state of the working tree.
> > This includes adding new files and removing deleted files.
> >
> >
> > Both interpretations are useful and worth supporting, but git-add currently
> > seems focused on #1 (and rightly so, IMHO).
> >
> > Even though #2 can be achieved by using a couple of git-add commmands (or a
> > longer series of more obscure plumbing-level commands), it might be worth
> > considering the more user-friendly alternative of adding a dedicated
> > command for supporting #2. Such a command already exists in a similar RCS:
> >
> > ---
> > $ hg addremove --help
> > hg addremove [OPTION]... [FILE]...
> >
> > add all new files, delete all missing files
>
> git update-index --add --remove?
This is actually the nicest looking command I've seen so far in this thread.
It's reasonably simple to deduce what it does, or rather, should do...
Of course it has some shortcomings:
- It only works on individual files. Supplying a directory (subdir or '.')
is not supported.
- It _seems_ to not support .gitignore, i.e. new files that are already in
.gitignore give the same feedback (add 'foo') as new files that are not
ignored. But when you commit, the ignored files will in fact _not_ be
committed (which is correct, AFAICS). It would be nice if git-update-index
told me that up front.
Of course, It may be that git-update-index is too low-level (i.e. plumbing)
to support the above use case in a user-friendly fashion. In that case, feel
free to ignore the above issues.
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: way to automatically add untracked files?
From: Johan Herland @ 2007-08-06 7:46 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Miles Bader
In-Reply-To: <Pine.LNX.4.64.0708060419230.14781@racer.site>
On Monday 06 August 2007, Johannes Schindelin wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > >> But I'm wondering whether we'd want to include it in git by default
> > >> (instead of having to tell confused users to add the alias).
> > >
> > > I recommend against that, too. All too often, I have some temporary files
> > > in the working tree, and I'll be dimmed if I'm the only one. So
> > > "addremove" adds too much possibility for pilot errors.
> >
> > "Recommend against it"? Why?
>
> Didn't I say that? It just _asks_ for pilot errors.
Ok, in that spirit I also suggest removing _all_ git plumbing-level commands
from the default installation. I also suggest adding confirmation dialog to
any command that alters the repo, since we have to protect the user against
"pilot errors".
Get real. Adding a separate command (provided it's well implemented and
documented) does not push the user off a cliff. Just because the command
doesn't fit your workflow doesn't mean it's dangerous and should never be
included. Just don't use it.
If git were only to support the (probably non-existing) intersection of its
user's workflows, we would probably have to pull e.g. git-rebase out of the
tree, because (according to some) rewriting history is evil, and extremely
prone to "pilot errors".
> > It's a separate command, so if it doesn't fit your working style, don't
> > use it.
>
> Hah! If that were true, we'd have a lot less mails like "I tried this and
> it did not work", only to find out that the person assumed that
> documentation is for wimps, and tried a command that "sounded" like it
> would do the right thing.
Having commands that "sound" like they do the right thing is not a bad idea
at all. We should have more of those.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] setup.c:verify_non_filename(): don't die unnecessarily while disambiguating
From: Shawn O. Pearce @ 2007-08-06 8:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk5s9dt2b.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> wrote:
> If you have a working tree _file_ "foo", attempt to refer to a
> branch "foo/bar" without -- to disambiguate, like this:
>
> $ git log foo/bar
> ---
>
> * This was from a real-life experience Shawn had.
Ack. I have done this many times, and every time I thought I was
going nuts. Until Junio found this bug tonight. Many thanks.
--
Shawn.
^ permalink raw reply
* [PATCH] Documentation/git-svn: Instructions for cloning a git-svn-created repository
From: Adam Roben @ 2007-08-06 8:16 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Shawn O. Pearce, Eric Wong, Adam Roben
These instructions tell you how to create a clone of a repository created with
git-svn, that can in turn be used with git-svn.
Signed-off-by: Adam Roben <aroben@apple.com>
---
> gitster: (3) you prepare one git-svn managed git repository, allow others to
> clone it via git, and have each of these cloned git repositories to interact
> with svn via git-svn -- this third mode of operation is not supported.
>
> spearce: be nice if someone who cared about git-svn supporting (3) either wrote
> a patch for the documentation, or taught the tool how to do this more
> automatically.
Here's that patch. Maybe I'll get around to Shawn's second (far more ideal)
suggestion sometime.
Documentation/git-svn.txt | 19 +++++++++++++++++++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 0a210e4..3e3b597 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -435,6 +435,25 @@ Tracking and contributing to an entire Subversion-managed project
# of dcommit/rebase/show-ignore should be the same as above.
------------------------------------------------------------------------
+The initial 'git-svn clone' Subversion can be quite time-consuming (especially
+for large repositories). If multiple people (or one person with multiple
+machines) want to use git-svn to interact with the same Subversion repository,
+you can do the initial 'git-svn clone' to a repository on a server and have
+each person clone that repository with 'git clone':
+
+------------------------------------------------------------------------
+# Do the initial import on a server
+ ssh server "cd /pub && git-svn clone http://svn.foo.org/project
+# Clone locally
+ git clone server:/pub/project
+# Tell git-svn which branch contains the Subversion commits
+ git update-ref refs/remotes/git-svn origin/master
+# Initialize git-svn locally (be sure to use the same URL and -T/-b/-t options as were used on server)
+ git-svn init http://svn.foo.org/project
+# Pull the latest changes from Subversion
+ git-svn rebase
+------------------------------------------------------------------------
+
REBASE VS. PULL/MERGE
---------------------
--
1.5.2.2
^ permalink raw reply related
* Re: possible bug in git apply?
From: Junio C Hamano @ 2007-08-06 8:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: david, git, rob
In-Reply-To: <alpine.LFD.0.999.0708050949220.5037@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> That said, if we really wanted to get it right, we should do this as a
> three-phase thing: (1) remove old files (2) create new files (3) for all
> removals and renames, try to remove source directories that might have
> become empty.
>
> That would fix it properly and for all cases.
Actually that will break the case of removing foo/bar, which is
the only file in directory foo, and creating a new file foo. So
if we really want to do all the corner cases, we would need to
do something like:
* scan the list of files that will remain (i.e., renamed-to,
modifed-in-place and created-anew) to note which directories
should remain in the result;
* remove old files, and remove its empty parent directories
that are not in the above list;
* create new files.
But in the meantime for 1.5.3, I think your patch is better than
what we currently have.
^ permalink raw reply
* Re: [PATCH] send-email: let sanitize_address_rfc822 do rfc2047 quoting
From: Uwe Kleine-König @ 2007-08-06 8:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <f95pie$8lv$1@sea.gmane.org>
Hello Jakub,
Jakub Narebski wrote:
> > The former version tried to fix-up the real name part with double quotes
> > if it includes a '.'. I removed this as rfc2047 can handle a dot, too.
>
> Not nice. I'd rather use double quotes if rfc2047 is not needed.
> It means:
> - no quotes for us-ascii name, without '.'
> - quotes for us-ascii name with '.' and perhaps other forbidden characters
> like '"' or something
> - full rfc2047 quoting if name contains characters outside us-ascii.
Well, that is OK for me, too. I just thought to do just one thing that
is able to handle all cases. So the code is easier to read and most of
the time you don't see the quoted result anyhow.
I will follow up with a new version later that will leave the second
part out. I don't know which chars can be quoted by "...", is it more
than .?
Best regards
Uwe
--
Uwe Kleine-König
http://www.google.com/search?q=1+stone%3D
^ permalink raw reply
* Re: [PATCH] Documentation/git-svn: Instructions for cloning a git-svn-created repository
From: Junio C Hamano @ 2007-08-06 8:34 UTC (permalink / raw)
To: Adam Roben; +Cc: git, Shawn O. Pearce, Eric Wong
In-Reply-To: <1186388203181-git-send-email-aroben@apple.com>
Thanks.
As I said on #git, I was just saying I got the impression that
this mode of operation is not supported from the #git traffic
during the past few days, without knowing if it is myself.
Making it clear how to do this in our documentation would help
those people who come to #git and ask about it, as it seems that
many people want to clone and share a git repository created by
git-svn.
^ permalink raw reply
* Re: way to automatically add untracked files?
From: Junio C Hamano @ 2007-08-06 8:45 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Miles Bader, git
In-Reply-To: <20070805041320.GH9527@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> We recently talked about this on the mailing list and decided that
> git-add shouldn't remove files that have disappeared, as doing so
> might break most user's expections of what git-add does.
> ...
> "git commit -a" will remove disappeared files. It has for quite
> some time.
It obviously is not the time to do this as I have already said
that I won't look at anything but fixes and documentation
updates until 1.5.3, but I am not opposed to have "git add -a $paths"
which would do something like "git add $paths && git add -u $paths".
We also might want to add "git add --refresh $paths" while at
it, which were brought up recently in a separate thread.
^ permalink raw reply
* Re: GIT push to sftp (feature request)
From: Matthieu Moy @ 2007-08-06 8:59 UTC (permalink / raw)
To: Martin Langhoff; +Cc: pavlix, git
In-Reply-To: <46a038f90708051700t7a758f8fwdf7c63c8aeef9ee8@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> On 8/6/07, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
>> > Using dumb protocols it's impossible to do either.
>>
>> That's not exactly true. You can't be as efficient with dumb protocols
>
> You are right -- I should have said: it's pretty hard, and we haven't
> put the effort ;-)
Yes, that seems more accurate.
>> (its ancestor,
>> GNU Arch, also had a way to be network-efficient on dumb protocols).
>
> Do I remember your name from gnuarch-users?
Possibly so, yes. I also remembered yours from the old good time where
people started explaining why they unsubscribed the list and migrated
to something better ;-).
> -- that Arch/tla was never particularly efficient, and fetches of
> large updates were slow and painful. Surely it was efficient on
> paper though :-p
It was actually efficient in terms of bandwidth. You downloaded only
the needed pieces (this has to do with the fact that the original
author wrote it at a time when he had only a slow modem connection).
But badly pipelined, and local operations were slow, so the result was
obviously _very_ far from what git can do.
--
Matthieu
^ permalink raw reply
* Re: Some ideas for StGIT
From: Catalin Marinas @ 2007-08-06 9:36 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1186163410.26110.55.camel@dv>
Hi Pavel,
All the interesting discussion usually happen during my holidays :-).
On 03/08/2007, Pavel Roskin <proski@gnu.org> wrote:
> I was recently disappointed to learn that one of the Linux drivers
> (bcm43xx_mac80211, to be precise) switched from git to quilt. I asked
> whether StGIT was considered, a discussion followed, and I think the key
> points need to be shared with StGIT developers. I'll add some of my
> ideas to the mix.
Thanks for the feedback.
> The main point in favor of quilt is that it allows to edit the patches
> with the text editor. One can pop all patches, edit them and push the
> all back.
If this is the main feature they need, they probably don't need git at
all and quilt would be enough. I was using quilt before starting StGIT
but the main problem I had with plain patches approach was the
conflict solving.
StGIT does a 'git-diff | git-apply' as a patch push optimization and
we could even cache the diff but the current algorithm is that if
git-apply fails, StGIT falls back to a three-way merge and even an
interactive user merge (via xxdiff for example). I find the three-way
merging (automatic or interactive) much more powerful than fuzzy patch
application.
If we would allow patch editing, the 'stg push' algorithms wouldn't
know when git-apply failed because the patch was edited or the base
was changed. Falling back to the three-way merge would lose the edited
patch. If one doesn't need three-way merging, quilt is good enough.
Other advantages of the three-way merging is the detection of full
patches or hunks merged upstream (the former can also be achieved by
testing the reverse-application of the patches).
I don't usually edit patches during development, I prefer to edit the
source files and review the diff. It happens many times to move hunks
between patches but I usually towards the bottom patches in the stack
(using stg export and emacs) and the three-way merging automatically
removes the merged hunks from top patches.
> I don't suggest that StGIT gives up on the git-based storage, but this
> mode of operation could be implemented in two ways.
>
> One is to have a command opposite to "export". It would read the files
> that "export" produces, replacing the existing patches.
As Yann said, we already have 'stg import --replace'. I mainly use
this feature with series sent to me and when they need some editing to
apply cleanly. There is also 'stg import --ignore' to ignore the
patches already applied (mainly when the importing fails in the middle
of a series, there is no need to re-import the first patches).
> Another approach would be to reexamine the patch after "stg refresh -es"
> and to apply it instead of the original patch. If the patch doesn't
> apply, the options would be to discard the edits or to re-launch the
> editor.
That's an interesting idea but maybe we should have a separate command
like --edit-full to edit the full patch + log (part of the
functionality already available in import).
> Next issue is that it should be possible to create a patch in one
> operation. StGIT follows quilt too closely here in requiring "new" and
> "refresh", instead of utilizing the advantage of the workflow that
> allows immediate editing of the sources without any commands.
>
> Basically, I want one command that:
>
> 1) shows user what was changed
> 2) allows user to name the patch
> 3) allows user to describe the patch
> 4) allows user to exclude files from the patch
> 5) doesn't require another command to put the changes to the patch
>
> I think the most natural approach would be to enhance "stg new". I see
> "stg new -s" is supposed to show the changes, but it's currently broken.
Thanks for reporting this. I don't use the --showpatch options much
and we don't have any tests (yet) for the interactive options.
> Finally, it would be great to have TLS support in the mail command.
> Mercurial has it, and looking at their mail.py, it doesn't seem to be
> much work.
Indeed, the SMTP Python objects already provide support for TLS via starttls().
--
Catalin
^ permalink raw reply
* Re: [PATCH v2] user-manual: mention git gui citool (commit, amend)
From: Steven Grimm @ 2007-08-06 9:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steffen Prohaska, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0708060119320.14781@racer.site>
Johannes Schindelin wrote:
> But how do you make sure that it works as expected? I.e. when you commit
> a hunk using, say, variable "rule_the_world", and by mistake (happen to me
> all the time, maybe to you, too?) forgot to select the hunk which declares
> that variable, maybe because it is hidden in a forest of other variables?
>
For cases like that, sure, partial commits are dangerous. On the other
hand, I've sometimes done partial commits for things like correcting
erroneous comments in code I'm working on, where there is no functional
change whatsoever in the hunk I'm committing and where I want to isolate
the corrections from the functional changes I *am* working on.
Also, when I'm working on a topic branch in my local sandbox I like to
do lots of work-in-progress commits. I usually do those based on the
granularity of my mental model of what I'm working on, and I have no
expectation whatsoever that any particular percentage of them represent
working code or even code that compiles. Sometimes I do partial commits
in that situation too: I make a change to some function in a file that
I'm editing elsewhere, and commit just that hunk with a commit log
message reminding me of why I made the change. Those commits are not
intended for public consumption; they're just to help me keep track of
my own work. Once everything is in a working state, I do a squash merge
or a bunch of cherry-pick -n invocations to build some revisions to
publish to the outside world, and *then* I am in "each commit must
represent a non-broken state" mode.
The great thing about git (well, *one* of the great things) is that it
unifies those two workflows in one system. With, say, svn, the "lots of
little checkpoints of my work in progress" part of that is awkward at
best, because it's very much oriented around an "if the version control
system knows about a change, it is by definition published to the
outside world" model.
So I guess my point, after all that, is just that assumptions that are
valid in the context of one workflow are not necessarily as valid in
others, and that even in a particular context, not all changes are
created equal.
-Steve
^ permalink raw reply
* Re: possible bug in git apply?
From: Junio C Hamano @ 2007-08-06 9:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: david, git, rob
In-Reply-To: <7vabt5dq11.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Actually that will break the case of removing foo/bar, which is
> the only file in directory foo, and creating a new file foo.
Sorry. The creation codepath already has enough code to remove
the left-over directory foo/ when creating the file foo. I
think your three-step process should be Ok.
^ permalink raw reply
* [MinGW PATCH] git clone was failing with 'invalid object name HEAD' if ran from cmd.exe directly
From: Dmitry Kakurin @ 2007-08-06 9:44 UTC (permalink / raw)
To: git
environment.c caches results of many getenv calls.
Under MinGW setenv(X) invalidates all previous values returned by getenv(X)
so cached values become dangling pointers.
Added cache-aware function set_git_dir to complement get_git_dir
Signed-off-by: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
---
builtin-init-db.c | 4 +---
cache.h | 1 +
environment.c | 6 ++++++
git.c | 6 +++---
path.c | 2 +-
setup.c | 6 +++---
7 files changed, 21 insertions(+), 10 deletions(-)
create mode 100644 config.mak
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 5c0feba..62e579d 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -344,9 +344,7 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
/*
* Set up the default .git directory contents
*/
- git_dir = getenv(GIT_DIR_ENVIRONMENT);
- if (!git_dir)
- git_dir = DEFAULT_GIT_DIR_ENVIRONMENT;
+ git_dir = get_git_dir();
safe_create_dir(git_dir, 0);
/* Check to see if the repository version is right.
diff --git a/cache.h b/cache.h
index 91e9f71..bc2916e 100644
--- a/cache.h
+++ b/cache.h
@@ -210,6 +210,7 @@ extern int is_bare_repository(void);
extern int is_inside_git_dir(void);
extern int is_inside_work_tree(void);
extern const char *get_git_dir(void);
+extern void set_git_dir(const char *newDir);
extern char *get_object_directory(void);
extern char *get_refs_directory(void);
extern char *get_index_file(void);
diff --git a/environment.c b/environment.c
index f83fb9e..6ea7088 100644
--- a/environment.c
+++ b/environment.c
@@ -80,6 +80,12 @@ const char *get_git_dir(void)
return git_dir;
}
+void set_git_dir(const char *newDir)
+{
+ setenv(GIT_DIR_ENVIRONMENT, newDir, 1);
+ git_dir = NULL; // reset cache
+}
+
char *get_object_directory(void)
{
if (!git_object_dir)
diff --git a/git.c b/git.c
index 210a763..53dfa05 100644
--- a/git.c
+++ b/git.c
@@ -67,14 +67,14 @@ static int handle_options(const char*** argv, int* argc, int* envchanged)
fprintf(stderr, "No directory given for --git-dir.\n" );
usage(git_usage_string);
}
- setenv(GIT_DIR_ENVIRONMENT, (*argv)[1], 1);
+ set_git_dir( (*argv)[1] );
if (envchanged)
*envchanged = 1;
(*argv)++;
(*argc)--;
handled++;
} else if (!prefixcmp(cmd, "--git-dir=")) {
- setenv(GIT_DIR_ENVIRONMENT, cmd + 10, 1);
+ set_git_dir(cmd + 10);
if (envchanged)
*envchanged = 1;
} else if (!strcmp(cmd, "--work-tree")) {
@@ -93,7 +93,7 @@ static int handle_options(const char*** argv, int* argc, int* envchanged)
*envchanged = 1;
} else if (!strcmp(cmd, "--bare")) {
static char git_dir[PATH_MAX+1];
- setenv(GIT_DIR_ENVIRONMENT, getcwd(git_dir, sizeof(git_dir)), 1);
+ set_git_dir(getcwd(git_dir, sizeof(git_dir)));
if (envchanged)
*envchanged = 1;
} else {
diff --git a/path.c b/path.c
index 8a06cf7..14af033 100644
--- a/path.c
+++ b/path.c
@@ -266,7 +266,7 @@ char *enter_repo(char *path, int strict)
if (access("objects", X_OK) == 0 && access("refs", X_OK) == 0 &&
validate_headref("HEAD") == 0) {
- setenv(GIT_DIR_ENVIRONMENT, ".", 1);
+ set_git_dir(".");
check_repository_format();
return path;
}
diff --git a/setup.c b/setup.c
index 47cd790..c5cf3ea 100644
--- a/setup.c
+++ b/setup.c
@@ -292,7 +292,7 @@ const char *setup_git_directory_gently(int *nongit_ok)
}
die("Not a git repository");
}
- setenv(GIT_DIR_ENVIRONMENT, cwd, 1);
+ set_git_dir(cwd);
gitdirenv = getenv(GIT_DIR_ENVIRONMENT);
if (!gitdirenv)
die("getenv after setenv failed");
@@ -332,8 +332,8 @@ const char *setup_git_directory_gently(int *nongit_ok)
* In case there is a work tree we may change the directory,
* therefore make GIT_DIR an absolute path.
*/
- if ( !is_absolute_path( gitdirenv ) ) {
- setenv(GIT_DIR_ENVIRONMENT, gitdir, 1);
+ if (!is_absolute_path(gitdirenv)) {
+ set_git_dir(gitdir);
gitdirenv = getenv(GIT_DIR_ENVIRONMENT);
if (!gitdirenv)
die("getenv after setenv failed");
--
1.5.3.GIT
- Dmitry
^ permalink raw reply related
* Re: Some ideas for StGIT
From: Catalin Marinas @ 2007-08-06 9:49 UTC (permalink / raw)
To: Yann Dirson; +Cc: Pavel Roskin, git
In-Reply-To: <20070803232351.GC30277@nan92-1-81-57-214-146.fbx.proxad.net>
On 04/08/2007, Yann Dirson <ydirson@altern.org> wrote:
> On Fri, Aug 03, 2007 at 01:50:10PM -0400, Pavel Roskin wrote:
> > I see
> > "stg new -s" is supposed to show the changes, but it's currently broken.
> > This is run in a clean StGIT repository with no patches:
> >
> > $ stg new -s foo
>
> Hm, I'm not sure what -s would be supposed to show here, since we're
> asking for the creation of a patch, which currently always starts
> empty.
The story for the 'new -s' option was that with StGIT (not possible
with Quilt), one can start modifying the local tree and only create a
patch afterwards. The newly created patch is always empty, even if
there were local changes and showing them was useful for writing the
patch description. One can use refresh for checking the changes in.
Indeed, the 'new' command can be improved to have part of the
'refresh' functionality, though I don't really like this duplication.
> Especially confusing is that if there are already applied patches, the
> diff shown is the one of the previous top patch
Are you sure it doesn't only show the local changes (which you might
want to add in a new patch)?
> - and if there is no
> applied patches, we get the exception you noticed.
That's a bug, indeed.
> I guess -s should be removed for 0.13.1.
I'll still like to keep it for the rare cases when I use the diff to
write the patch description.
> I also tried with "stg refresh -m ''" to see if it caused the same
> problem, but it appears to have another problem instead: it does not
> refresh the patch description at all.
>
> My guess is that we should not allow empty patch description (and
> maybe fill it with provided patchname).
I think we should put some default patch description.
--
Catalin
^ permalink raw reply
* Re: Some ideas for StGIT
From: Karl Hasselström @ 2007-08-06 9:56 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Pavel Roskin, git
In-Reply-To: <b0943d9e0708060236x19674e4cjf04cec716ae6246c@mail.gmail.com>
On 2007-08-06 10:36:25 +0100, Catalin Marinas wrote:
> On 03/08/2007, Pavel Roskin <proski@gnu.org> wrote:
>
> > Another approach would be to reexamine the patch after "stg
> > refresh -es" and to apply it instead of the original patch. If the
> > patch doesn't apply, the options would be to discard the edits or
> > to re-launch the editor.
>
> That's an interesting idea but maybe we should have a separate
> command like --edit-full to edit the full patch + log (part of the
> functionality already available in import).
I never really understood why commit message editing had to be part of
the "refresh" command. If it were a separate command and not tied to
refresh, we could allow editing the message (and author, committer,
date, ...) of any commit in the stack -- since the tree objects would
be unchanged, we could just reuse the same tree objects when rewriting
the commit objects on top of it.
That's obviously not going to work if we allow editing of the patch.
But patch editing isn't a good fit as a refresh switch either, since
it's not at all related to replacing the tree of the current patch
with the working tree.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Some ideas for StGIT
From: Catalin Marinas @ 2007-08-06 10:01 UTC (permalink / raw)
To: Yann Dirson; +Cc: Pavel Roskin, Andy Parkins, git
In-Reply-To: <20070804080801.GD30277@nan92-1-81-57-214-146.fbx.proxad.net>
On 04/08/2007, Yann Dirson <ydirson@altern.org> wrote:
> FWIW, I have written a couple of scripts to help moving stuff around
> between patches. Those are not yet integrated in stgit proper, and it
> happens that the 0.13 tarball does not contain them, they are only
> available from the git tree (better use my tree[1], since I updated them
> recently).
That's probably because I haven't updated the MANIFEST.in file (I
don't look in the contrib directory much :-)).
--
Catalin
^ permalink raw reply
* [PATCH] Add support for an info version of the user manual
From: David Kastrup @ 2007-08-06 9:41 UTC (permalink / raw)
To: git
These patches use docbook2x in order to create an info version of the
git user manual. No existing Makefile targets (including "all") are
touched, so you need to explicitly say
make info
sudo make install-info
to get git.info created and installed. If the info target directory
does not already contain a "dir" file, no directory entry is created.
This facilitates $(DESTDIR)-based installations. The same could be
achieved with
sudo make INSTALL_INFO=: install-info
explicitly.
awk is used for patching up sub-par file and directory information in
the Texinfo file. It would be cleaner to place the respective info
straight into user-manual.txt or the conversion configurations, but I
find myself unable to find out how to do this with Asciidoc/Texinfo.
Signed-off-by: David Kastrup <dak@gnu.org>
---
Documentation/Makefile | 28 ++++++++++++++++++++++++++++
Makefile | 6 ++++++
2 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 443114b..5a5961b 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -44,6 +44,11 @@ INSTALL?=install
RM ?= rm -f
DOC_REF = origin/man
+infodir?=$(prefix)/share/info
+MAKEINFO=makeinfo
+INSTALL_INFO=install-info
+DOCBOOK2X_TEXI=docbook2x-texi
+
-include ../config.mak.autogen
-include ../config.mak
@@ -67,6 +72,8 @@ man1: $(DOC_MAN1)
man5: $(DOC_MAN5)
man7: $(DOC_MAN7)
+info: git.info
+
install: man
$(INSTALL) -d -m755 $(DESTDIR)$(man1dir)
$(INSTALL) -d -m755 $(DESTDIR)$(man5dir)
@@ -75,6 +82,14 @@ install: man
$(INSTALL) -m644 $(DOC_MAN5) $(DESTDIR)$(man5dir)
$(INSTALL) -m644 $(DOC_MAN7) $(DESTDIR)$(man7dir)
+install-info: info
+ $(INSTALL) -d -m755 $(DESTDIR)$(infodir)
+ if test -r $(DESTDIR)$(infodir)/dir; then \
+ $(INSTALL_INFO) --info-dir=$(DESTDIR)$(infodir) git.info ;\
+ else \
+ $(INSTALL) -m644 git.info $(DESTDIR)$(infodir) ; \
+ echo "No directory found in $(DESTDIR)$(infodir)" >&2 ; \
+ fi
../GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
$(MAKE) -C ../ GIT-VERSION-FILE
@@ -138,6 +153,19 @@ XSLTOPTS = --xinclude --stringparam html.stylesheet docbook-xsl.css
user-manual.html: user-manual.xml
xsltproc $(XSLTOPTS) -o $@ $(XSLT) $<
+git.info: user-manual.xml
+ $(RM) $@ $*.texi
+ $(DOCBOOK2X_TEXI) user-manual.xml --to-stdout | \
+ awk '/^@setfilename/{$$2="git.info"};\
+ /^@direntry/{print "@dircategory Development"; \
+ print "@direntry"; \
+ print "* Git: (git). A fast distributed revision control system"; \
+ print "@end direntry"}; \
+ /^@direntry/,/^@end direntry/ { next }; \
+ {print}' > $*.texi
+ $(MAKEINFO) --no-split $*.texi
+ $(RM) $*.texi
+
howto-index.txt: howto-index.sh $(wildcard howto/*.txt)
$(RM) $@+ $@
sh ./howto-index.sh $(wildcard howto/*.txt) >$@+
diff --git a/Makefile b/Makefile
index 2f3b9b2..b685c7e 100644
--- a/Makefile
+++ b/Makefile
@@ -913,6 +913,9 @@ perl/Makefile: perl/Git.pm perl/Makefile.PL GIT-CFLAGS
doc:
$(MAKE) -C Documentation all
+info:
+ $(MAKE) -C Documentation info
+
TAGS:
$(RM) TAGS
$(FIND) . -name '*.[hcS]' -print | xargs etags -a
@@ -1005,6 +1008,9 @@ endif
install-doc:
$(MAKE) -C Documentation install
+install-info:
+ $(MAKE) -C Documentation install-info
+
quick-install-doc:
$(MAKE) -C Documentation quick-install
--
1.5.3.rc4.21.ga63eb
^ permalink raw reply related
* Re: [PATCH] Add support for an info version of the user manual
From: David Kastrup @ 2007-08-06 10:19 UTC (permalink / raw)
To: git
In-Reply-To: <86r6mhc6k7.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> writes:
> These patches use docbook2x in order to create an info version of the
> git user manual. No existing Makefile targets (including "all") are
> touched, so you need to explicitly say
Scrap that. The installation case where install-info is used does not
work properly yet. Another version coming up.
--
David Kastrup
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Johannes Schindelin @ 2007-08-06 10:24 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Torgil Svensson, Dmitry Kakurin, git
In-Reply-To: <46B6B60C.4080805@trolltech.com>
Hi,
On Mon, 6 Aug 2007, Marius Storm-Olsen wrote:
> Instead of hacking away on this old terminal, what about simply including
> another nice Open Source project?
>
> On Windows we have a replacement terminal, which has all the features you
> want, and also supports tabs like Konsole. I've used it for several years, and
> it works great. Have a look and see if you like it, then we can add it to the
> repo:
> http://sourceforge.net/projects/console/
>
> Original name, ey? :-)
That sounds awesome. However, from their sourceforge page, it seems they
support only 2k and xp? What about 95 and nt?
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Add support for an info version of the user manual
From: David Kastrup @ 2007-08-06 10:22 UTC (permalink / raw)
To: git
These patches use docbook2x in order to create an info version of the
git user manual. No existing Makefile targets (including "all") are
touched, so you need to explicitly say
make info
sudo make install-info
to get git.info created and installed. If the info target directory
does not already contain a "dir" file, no directory entry is created.
This facilitates $(DESTDIR)-based installations. The same could be
achieved with
sudo make INSTALL_INFO=: install-info
explicitly.
awk is used for patching up sub-par file and directory information in
the Texinfo file. It would be cleaner to place the respective info
straight into user-manual.txt or the conversion configurations, but I
find myself unable to find out how to do this with Asciidoc/Texinfo.
Signed-off-by: David Kastrup <dak@gnu.org>
---
Documentation/Makefile | 28 ++++++++++++++++++++++++++++
Makefile | 6 ++++++
2 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 443114b..97ee067 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -44,6 +44,11 @@ INSTALL?=install
RM ?= rm -f
DOC_REF = origin/man
+infodir?=$(prefix)/share/info
+MAKEINFO=makeinfo
+INSTALL_INFO=install-info
+DOCBOOK2X_TEXI=docbook2x-texi
+
-include ../config.mak.autogen
-include ../config.mak
@@ -67,6 +72,8 @@ man1: $(DOC_MAN1)
man5: $(DOC_MAN5)
man7: $(DOC_MAN7)
+info: git.info
+
install: man
$(INSTALL) -d -m755 $(DESTDIR)$(man1dir)
$(INSTALL) -d -m755 $(DESTDIR)$(man5dir)
@@ -75,6 +82,14 @@ install: man
$(INSTALL) -m644 $(DOC_MAN5) $(DESTDIR)$(man5dir)
$(INSTALL) -m644 $(DOC_MAN7) $(DESTDIR)$(man7dir)
+install-info: info
+ $(INSTALL) -d -m755 $(DESTDIR)$(infodir)
+ $(INSTALL) -m644 git.info $(DESTDIR)$(infodir)
+ if test -r $(DESTDIR)$(infodir)/dir; then \
+ $(INSTALL_INFO) --info-dir=$(DESTDIR)$(infodir) git.info ;\
+ else \
+ echo "No directory found in $(DESTDIR)$(infodir)" >&2 ; \
+ fi
../GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
$(MAKE) -C ../ GIT-VERSION-FILE
@@ -138,6 +153,19 @@ XSLTOPTS = --xinclude --stringparam html.stylesheet docbook-xsl.css
user-manual.html: user-manual.xml
xsltproc $(XSLTOPTS) -o $@ $(XSLT) $<
+git.info: user-manual.xml
+ $(RM) $@ $*.texi
+ $(DOCBOOK2X_TEXI) user-manual.xml --to-stdout | \
+ awk '/^@setfilename/{$$2="git.info"};\
+ /^@direntry/{print "@dircategory Development"; \
+ print "@direntry"; \
+ print "* Git: (git). A fast distributed revision control system"; \
+ print "@end direntry"}; \
+ /^@direntry/,/^@end direntry/ { next }; \
+ {print}' > $*.texi
+ $(MAKEINFO) --no-split $*.texi
+ $(RM) $*.texi
+
howto-index.txt: howto-index.sh $(wildcard howto/*.txt)
$(RM) $@+ $@
sh ./howto-index.sh $(wildcard howto/*.txt) >$@+
diff --git a/Makefile b/Makefile
index 2f3b9b2..b685c7e 100644
--- a/Makefile
+++ b/Makefile
@@ -913,6 +913,9 @@ perl/Makefile: perl/Git.pm perl/Makefile.PL GIT-CFLAGS
doc:
$(MAKE) -C Documentation all
+info:
+ $(MAKE) -C Documentation info
+
TAGS:
$(RM) TAGS
$(FIND) . -name '*.[hcS]' -print | xargs etags -a
@@ -1005,6 +1008,9 @@ endif
install-doc:
$(MAKE) -C Documentation install
+install-info:
+ $(MAKE) -C Documentation install-info
+
quick-install-doc:
$(MAKE) -C Documentation quick-install
--
1.5.3.rc4.21.ga63eb
^ permalink raw reply related
* Re: [MinGW PATCH] git clone was failing with 'invalid object name HEAD' if ran from cmd.exe directly
From: Johannes Schindelin @ 2007-08-06 10:42 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: git
In-Reply-To: <BD28FA320B7749FFBE3135FE92380BCE@ntdev.corp.microsoft.com>
Hi,
On Mon, 6 Aug 2007, Dmitry Kakurin wrote:
> environment.c caches results of many getenv calls. Under MinGW setenv(X)
> invalidates all previous values returned by getenv(X) so cached values
> become dangling pointers.
>
> Added cache-aware function set_git_dir to complement get_git_dir
The real problem here: mingw.git did not merge with upstream git.git in a
long time (mainly because its maintainer is on holiday). In the meantime,
set_git_dir() is already there!
I had more problems than I thought with setting up a fork of mingw.git.
It seems that the relative alternates path to mingw.git is followed, but
not that one from mingw.git to git.git. So I could upload, but not fetch.
So I propose to use http://repo.or.cz/w/git/mingw4msysgit.git/ in the
meantime. (Just give me your account name, and you'll be able to push to
it.)
BTW your patch was white-space mangled.
Ciao,
Dscho
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Marius Storm-Olsen @ 2007-08-06 11:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Torgil Svensson, Dmitry Kakurin, git
In-Reply-To: <Pine.LNX.4.64.0708061123450.14781@racer.site>
[-- Attachment #1: Type: text/plain, Size: 885 bytes --]
Johannes Schindelin said the following on 06.08.2007 12:24:
> Hi,
>
> On Mon, 6 Aug 2007, Marius Storm-Olsen wrote:
>
>> Instead of hacking away on this old terminal, what about simply including
>> another nice Open Source project?
>>
>> On Windows we have a replacement terminal, which has all the features you
>> want, and also supports tabs like Konsole. I've used it for several years, and
>> it works great. Have a look and see if you like it, then we can add it to the
>> repo:
>> http://sourceforge.net/projects/console/
>>
>> Original name, ey? :-)
>
> That sounds awesome. However, from their sourceforge page, it seems they
> support only 2k and xp? What about 95 and nt?
Hmm, nope. Just tried it on 98, and that didn't fly. It requires
symbols to do top-level transparency, which is only accessible from
Win2K and later.
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox