* Re: clone fails: Could not get the current working directory
From: Alex Riesen @ 2008-09-23 14:12 UTC (permalink / raw)
To: John Freeman; +Cc: git
In-Reply-To: <48D8EDDA.3050804@cs.tamu.edu>
2008/9/23 John Freeman <jfreeman@cs.tamu.edu>:
> Alex Riesen wrote:
>>
>> Do these work:
>> $ ssh john@remote.system.edu ls -R /home/bob/path/to/repo
>> $ ssh john@remote.system.edu 'cd /home/bob/path/to/repo && pwd'
>>
>
> Yes, they do. I wish the mailing list did better threading; please see my
> other posts if you happened to miss them:
>
> http://article.gmane.org/gmane.comp.version-control.git/96442
> http://article.gmane.org/gmane.comp.version-control.git/96505
>
Saw them. .bashrc (/etc/bashrc too) is not used for non-interactive sessions,
like yours (of course, you can source them from
.profile/.bash_login/.bash_profile).
Have you tried the commands exactly? (Even more interesting would be to try
a simple getpwd program which prints errno)
^ permalink raw reply
* [PATCH] add GIT_FAST_STAT mode for Cygwin
From: Dmitry Potapov @ 2008-09-23 14:06 UTC (permalink / raw)
To: git; +Cc: Johannes Sixt, Junio C Hamano, Steffen Prohaska
This patch introduces the GIT_FAST_STAT environment variable. If this
variable is not set then Git will work as before. However, if it is set
then the Cygwin version of Git will try to use a Win32 API function if
it is possible to speed up stat/lstat.
This fast mode works only for relative paths. It is assumed that the
whole repository is located inside one directory without using Cygwin
mount to bind external paths inside of the current tree.
Symbol links are supported by falling back on the cygwin version of
these functions.
A very superficial testing shows 'git status' in the fast mode works more
than twice faster than in the normal mode, i.e. with about the same speed
as the native MinGW version.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
---
After getting used to how strikingly fast Git is on Linux, using Git on
Windows (even only for a few hours) was not so pleasant. So, here is
this patch.
For those who wonder why I don't know use MinGW version of Git, the
answer is simple -- I have Cygwin install and I happy with it, while
the MinGW version comes with MSYS, so it cannot be used in Cygwin.
Makefile | 4 ++
compat/cygwin.c | 133 +++++++++++++++++++++++++++++++++++++++++++++++++++++
compat/cygwin.h | 9 ++++
git-compat-util.h | 1 +
4 files changed, 147 insertions(+), 0 deletions(-)
create mode 100644 compat/cygwin.c
create mode 100644 compat/cygwin.h
diff --git a/Makefile b/Makefile
index 3c0664a..0708390 100644
--- a/Makefile
+++ b/Makefile
@@ -347,6 +347,7 @@ LIB_H += cache.h
LIB_H += cache-tree.h
LIB_H += commit.h
LIB_H += compat/mingw.h
+LIB_H += compat/cygwin.h
LIB_H += csum-file.h
LIB_H += decorate.h
LIB_H += delta.h
@@ -747,6 +748,9 @@ ifeq ($(uname_S),HP-UX)
NO_SYS_SELECT_H = YesPlease
SNPRINTF_RETURNS_BOGUS = YesPlease
endif
+ifneq (,$(findstring CYGWIN,$(uname_S)))
+ COMPAT_OBJS += compat/cygwin.o
+endif
ifneq (,$(findstring MINGW,$(uname_S)))
NO_MMAP = YesPlease
NO_PREAD = YesPlease
diff --git a/compat/cygwin.c b/compat/cygwin.c
new file mode 100644
index 0000000..0b63d2f
--- /dev/null
+++ b/compat/cygwin.c
@@ -0,0 +1,133 @@
+#define WIN32_LEAN_AND_MEAN
+#include "../git-compat-util.h"
+#include <windows.h>
+
+static inline void filetime_to_timespec(const FILETIME *ft, struct timespec *ts)
+{
+ long long winTime = ((long long)ft->dwHighDateTime << 32) + ft->dwLowDateTime;
+ winTime -= 116444736000000000LL; /* Windows to Unix Epoch conversion */
+ ts->tv_sec = (time_t)(winTime/10000000); /* 100-nanosecond interval to seconds */
+ ts->tv_nsec = (long)(winTime - ts->tv_sec) * 100; /* nanoseconds */
+}
+
+#define size_to_blocks(s) (((s)+511)/512)
+
+/* do_stat is a common implementation for cygwin_lstat and cygwin_stat.
+ *
+ * To simplify its logic, in the case of cygwin symlinks, this implementation
+ * falls back to the cygwin version of stat/lstat, which is provided as the
+ * last argument.
+ */
+static int do_stat(const char *file_name, struct stat *buf, stat_fn_t cygstat)
+{
+ WIN32_FILE_ATTRIBUTE_DATA fdata;
+
+ if (file_name[0] == '/')
+ return cygstat (file_name, buf);
+
+ if (GetFileAttributesExA(file_name, GetFileExInfoStandard, &fdata)) {
+ int fMode = S_IREAD;
+ /*
+ * If the system attribute is set and it is not a directory then
+ * it could be a symbol link created in the nowinsymlinks mode.
+ * Normally, Cygwin works in the winsymlinks mode, so this situation
+ * is very unlikely. For the sake of simplicity of our code, let's
+ * Cygwin to handle it.
+ */
+ if ((fdata.dwFileAttributes & FILE_ATTRIBUTE_SYSTEM) &&
+ !(fdata.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY))
+ return cygstat (file_name, buf);
+
+ if (fdata.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)
+ fMode |= S_IFDIR;
+ else
+ fMode |= S_IFREG;
+ if (!(fdata.dwFileAttributes & FILE_ATTRIBUTE_READONLY))
+ fMode |= S_IWRITE;
+
+ /* st_dev, st_rdev are not used by Git */
+ buf->st_dev = buf->st_rdev = 0;
+ /* it is difficult to obtain the inode number on Windows,
+ * so let's set it to zero as MinGW Git does. */
+ buf->st_ino = 0;
+ buf->st_mode = fMode;
+ buf->st_nlink = 1;
+ buf->st_uid = buf->st_gid = 0;
+#ifdef __CYGWIN_USE_BIG_TYPES__
+ buf->st_size = ((_off64_t)fdata.nFileSizeHigh << 32) +
+ fdata.nFileSizeLow;
+#else
+ buf->st_size = (off_t)fdata.nFileSizeLow;
+#endif
+ buf->st_blocks = size_to_blocks(buf->st_size);
+ filetime_to_timespec(&fdata.ftLastAccessTime, &buf->st_atim);
+ filetime_to_timespec(&fdata.ftLastWriteTime, &buf->st_mtim);
+ filetime_to_timespec(&fdata.ftCreationTime, &buf->st_ctim);
+ errno = 0;
+ return 0;
+ }
+
+ switch (GetLastError()) {
+ case ERROR_ACCESS_DENIED:
+ case ERROR_SHARING_VIOLATION:
+ case ERROR_LOCK_VIOLATION:
+ case ERROR_SHARING_BUFFER_EXCEEDED:
+ errno = EACCES;
+ break;
+ case ERROR_BUFFER_OVERFLOW:
+ errno = ENAMETOOLONG;
+ break;
+ case ERROR_NOT_ENOUGH_MEMORY:
+ errno = ENOMEM;
+ break;
+ default:
+ /* In the winsymlinks mode (which is the default), Cygwin
+ * emulates symbol links using Windows shortcut files. These
+ * files are formed by adding .lnk extension. So, if we have
+ * not found the specified file name, it could be that it is
+ * a symbol link. Let's Cygwin to deal with that.
+ */
+ return cygstat (file_name, buf);
+ }
+ return -1;
+}
+
+/* We provide our own lstat/stat functions, since the provided Cygwin versions
+ * of these functions are too slow. These stat functions are tailored for Git's
+ * usage, and therefore they are not meant to be complete and correct emulation
+ * of lstat/stat functionality.
+ */
+static int cygwin_lstat(const char *path, struct stat *buf)
+{
+ return do_stat(path, buf, lstat);
+}
+
+static int cygwin_stat(const char *path, struct stat *buf)
+{
+ return do_stat(path, buf, stat);
+}
+
+/*
+ * This are startup stubs, which choose what implementation of lstat/stat
+ * should be used. If GIT_FAST_STAT is not set then the standard functions
+ * included in the cygwin library are used. If it is set then our fast and
+ * dirty implementation is invoked, which should be 2-3 times faster than
+ * cygwin functions.
+ */
+static int cygwin_stat_choice(const char *file_name, struct stat *buf)
+{
+ cygwin_stat_fn = getenv("GIT_FAST_STAT") ?
+ cygwin_stat : stat;
+ return (*cygwin_stat_fn)(file_name, buf);
+}
+
+static int cygwin_lstat_choice(const char *file_name, struct stat *buf)
+{
+ cygwin_lstat_fn = getenv("GIT_FAST_STAT") ?
+ cygwin_lstat : lstat;
+ return (*cygwin_lstat_fn)(file_name, buf);
+}
+
+stat_fn_t cygwin_stat_fn = cygwin_stat_choice;
+stat_fn_t cygwin_lstat_fn = cygwin_lstat_choice;
+
diff --git a/compat/cygwin.h b/compat/cygwin.h
new file mode 100644
index 0000000..a3229f5
--- /dev/null
+++ b/compat/cygwin.h
@@ -0,0 +1,9 @@
+#include <sys/types.h>
+#include <sys/stat.h>
+
+typedef int (*stat_fn_t)(const char*, struct stat*);
+extern stat_fn_t cygwin_stat_fn;
+extern stat_fn_t cygwin_lstat_fn;
+
+#define stat(path, buf) (*cygwin_stat_fn)(path, buf)
+#define lstat(path, buf) (*cygwin_lstat_fn)(path, buf)
diff --git a/git-compat-util.h b/git-compat-util.h
index db2836f..cd9752c 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -85,6 +85,7 @@
#undef _XOPEN_SOURCE
#include <grp.h>
#define _XOPEN_SOURCE 600
+#include "compat/cygwin.h"
#else
#undef _ALL_SOURCE /* AIX 5.3L defines a struct list with _ALL_SOURCE. */
#include <grp.h>
--
1.6.0
^ permalink raw reply related
* Re: Locking binary files
From: Mario Pareja @ 2008-09-23 13:56 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <48D8A97E.8070003@op5.se>
> So it's a communication issue then.
Yes, but I think the communication of this information needs to happen
as part of a developers normal work-flow rather than requiring them to
remember to check an external system.
> The way I understand locks in svn
> and cvs is that they also only bother you when you want to check in the
> file you've just recently modified, or if multiple people want to lock
> the same file at the same time.
The SVN client will make locked files read-only until a lock is
obtained for them. This helps "remind" you that a lock should be
obtained before editing such a file. Requiring the developer to obtain
a lock ensures that nobody else is editing the file and prevents
wasted work. Upon commit, the file is marked as unlocked and the
local file is once again read-only.
>
> Note that locking would be completely advisory though, and nothing
> would prevent people from committing changes to a locked file.
If git were to support locking then it could prevent people from
committing without first locking. Even if it is not supported
directly by git - perhaps using a lock daemon - a wrapper would need
to be written around git commit/push to prevent developers from
committing/pushing changes that would cause binary merging conflicts.
> Then
> again, insofar as I understand SVN/CVS locking, that's how those
> work too, except that an SVN "checkin" would be the equivalent of
> "git commit && git push" (the push part of the git sequence won't
> work).
>
Generally in SVN you need to lock the file before being able to commit.
Really, I am just curious about how others deal with this issue. Do
you simply start editing binary files and hope nobody else edits the
same file? Do you send out an email telling people you are working on
such a file?
Mario
^ permalink raw reply
* Re: [ANNOUNCE] Git-1.6.0.2-preview20080923
From: Johan Herland @ 2008-09-23 13:54 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska, msysGit
In-Reply-To: <B463062F-DD48-44A7-B2BB-8E5E0D177616@zib.de>
On Tuesday 23 September 2008, Steffen Prohaska wrote:
> On Sep 21, 2008, at 7:33 PM, Steffen Prohaska wrote:
> > Git-1.6.0.2-preview20080921 for Windows is available at
> >
> > http://code.google.com/p/msysgit/downloads
>
> I updated the installer to Git-1.6.0.2-preview20080923.
> The problems reported on the mailing list during the
> last two days should be fixed.
Confirmed. SSH works again. :)
> I apologize for the quality of Git-1.6.0.2-preview20080921.
> It was unacceptable.
You have absolutely nothing to apologize for. I highly appreciate the
effort you and others put into msysGit. :)
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Recording "partial merges" (was: Re: [RFC] origin link for cherry-pick and revert)
From: Peter Krefting @ 2008-09-23 13:51 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <20080909211355.GB10544@machine.or.cz>
Petr Baudis:
> I think this is misguided. In general case, cherrypicks can be from
> completely unrelated histories, and if you are doing the cherry pick,
> you are saying that actually, the history *does not matter*.
As my workflow sometimes make me do cherry-picks where history does
matter, in form of me doing a "partial merge" of one or more than one
commit from branch A into branch B, which does not necessarily have to
be directly related,
is there a way to perform something like that, while keeping history?
Perhaps I'm damaged by having used CVS for too long, and merging just
some files, or abusing CVS internals to make some files on branch A
also be part of branch B by having their branches point to the same RCS
branch revision number, but sometimes I find that I miss being able to
do it in Git.
Not really a big deal, just curious.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* git svn rebase does not call post-update hook
From: Thomas Koch @ 2008-09-23 13:45 UTC (permalink / raw)
To: Git Mailing List
Hi,
I've followed a blogpost[1] on how to set up a GIT mirror of a SVN repo.
It works just fine, only that I've called the post-update hook manually
so far. It won't get called by "git svn rebase".
Yes, it is executable.
Yes, git svn rebase does fetch updates and rebases master.
[1] http://gsocblog.jsharpe.net/archives/12
Thanks for your bandwidth,
--
Thomas Koch, Software Developer
http://www.koch.ro
Young Media Concepts GmbH
Sonnenstr. 4
CH-8280 Kreuzlingen
Switzerland
Tel +41 (0)71 / 508 24 86
Fax +41 (0)71 / 560 53 89
Mobile +49 (0)170 / 753 89 16
Web www.ymc.ch
^ permalink raw reply
* Re: Locking binary files
From: Dmitry Potapov @ 2008-09-23 13:44 UTC (permalink / raw)
To: Mario Pareja; +Cc: git
In-Reply-To: <94c1db200809222339t7d65081eq7471fef86fb5ec73@mail.gmail.com>
On Tue, Sep 23, 2008 at 02:39:41AM -0400, Mario Pareja wrote:
>
> How else can one developer be sure that time spent editing a
> binary file will not be wasted because another developer submitted a
> change?
That sounds to me more like a communication problem than anything
related to Git itself.
>
> To achieve the effects of locking, a "central" repository must be
> identified. Regardless of the distributed nature of git, most
> _companies_ will have a "central" repository for a software project.
> We should be able to mark a file as requiring a lock from the
> governing git repository at a specified address. Is this made
> difficult because git tracks file contents not files?
The problem exists regardless the distributed nature of git. Let's
consider a single repository with only two branches: A and B. Now, one
developer has decided to edit some binary file called pretty.img on A.
Should this file be locked only on the branch A or on both branches? The
answer is if A is going to merge to B then this file on B too and remain
locking till A is merged to B. In fact, it may be *absolutely* pointless
to lock the file on the developer's topic branch, because another
developer can edit it on another topic branch without noticing that this
lock exists at all. So, it may be enough to lock it only B enough, but
this is impossible to Git to know, because Git does not understand
_your_ particular workflow, and without any locking scheme is rather
meaningless.
Perhaps, a more general solution can be based exactly on the content,
not on the name, i.e. in some share directory on the server I create
a file with name based on SHA-1 of the binary file where I put comment
explaining why I locked it. Obviously, this lock is purely advisory,
but it is good, in some situation you really may want to edit two
files with the same SHA-1 on different branches that never get merge.
Moreover, this lock is never deleted. So, it could make sense instead
of having a separate file per lock to organize it in some more compact
storage, which may look like history of editing binary files... But it
is just an idea how I would do that.
Dmitry
^ permalink raw reply
* Re: [ANNOUNCE] TopGit v0.3
From: Petr Baudis @ 2008-09-23 13:27 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: martin f krafft, git, Jan Holesovsky
In-Reply-To: <1222175590.10363.14.camel@heerbeest>
Hi,
On Tue, Sep 23, 2008 at 03:13:10PM +0200, Jan Nieuwenhuizen wrote:
> On ma, 2008-09-22 at 17:27 +0200, Petr Baudis wrote:
> [about adding and removing topic branch dependencies]
>
> > Do you really expect you will need this kind of functionality often,
> > though?
>
> Yes. This is what people are used to and do now with our patches based
> system. We cannot take away such basic functionality. Also, currently
> it is very easy to do, however, it is quite error prone. That's also
> why using [top]git would be so great.
>
> There are ~300 topic branches. Usually, a combination of most of these
> is used as the master branch. There are a number of scenarios where
> you would want to add/remove some of these topic branches from master.
>
> The most pressing case for this is for packagers making a release.
> Unless we also make their life easier, we can forget about moving to
> [top]git.
I think that would be possible to do, too. ;-) It really depends on
how general your patch tree is - what we can't make to work is just the
most generic case, but e.g. if master is a *leaf* branch nothing else
depends on and it can't get the branch through multiple paths, you can
do the dependency removal rather easily (if it can get through multiple
paths, you can still do it but you might have to deal with big
conflicts).
But if you scenario indeed is totally generic, I'm afraid I don't know
how to make TopGit remove dependencies, except perhaps for the price of
massive complexity and massive slowdown (pretty much redoing all the
history walking etc.). Maybe someone else comes by with a genial
solution...
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates
^ permalink raw reply
* Re: clone fails: Could not get the current working directory
From: John Freeman @ 2008-09-23 13:23 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0809230539x340bd579q3489d5e257b9740@mail.gmail.com>
Alex Riesen wrote:
> Do these work:
> $ ssh john@remote.system.edu ls -R /home/bob/path/to/repo
> $ ssh john@remote.system.edu 'cd /home/bob/path/to/repo && pwd'
>
Yes, they do. I wish the mailing list did better threading; please see
my other posts if you happened to miss them:
http://article.gmane.org/gmane.comp.version-control.git/96442
http://article.gmane.org/gmane.comp.version-control.git/96505
Thank you,
John
^ permalink raw reply
* Re: [ANNOUNCE] TopGit v0.3
From: Jan Nieuwenhuizen @ 2008-09-23 13:13 UTC (permalink / raw)
To: Petr Baudis; +Cc: martin f krafft, git, Jan Holesovsky
In-Reply-To: <20080922152712.GN10360@machine.or.cz>
On ma, 2008-09-22 at 17:27 +0200, Petr Baudis wrote:
Hi,
[about adding and removing topic branch dependencies]
> Do you really expect you will need this kind of functionality often,
> though?
Yes. This is what people are used to and do now with our patches based
system. We cannot take away such basic functionality. Also, currently
it is very easy to do, however, it is quite error prone. That's also
why using [top]git would be so great.
There are ~300 topic branches. Usually, a combination of most of these
is used as the master branch. There are a number of scenarios where
you would want to add/remove some of these topic branches from master.
The most pressing case for this is for packagers making a release.
Unless we also make their life easier, we can forget about moving to
[top]git.
Greetings,
Jan.
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
^ permalink raw reply
* Re: clone fails: Could not get the current working directory
From: Alex Riesen @ 2008-09-23 12:39 UTC (permalink / raw)
To: John Freeman; +Cc: git
In-Reply-To: <48D59A30.5020403@cs.tamu.edu>
2008/9/21 John Freeman <jfreeman@cs.tamu.edu>:
> - The repository is bare, under Bob's home directory on a remote Sun system.
> - Bob has set the group permissions for the repo directory to repogroup.
> - I have an account on the remote system that is in repogroup.
>
> I am trying to clone the repo on my home machine, using
>
>> git clone ssh://john@remote.system.edu/home/bob/path/to/repo
>
> It fails with
>
> remote: fatal: Could not get the current working directory
Do these work:
$ ssh john@remote.system.edu ls -R /home/bob/path/to/repo
$ ssh john@remote.system.edu 'cd /home/bob/path/to/repo && pwd'
?
^ permalink raw reply
* Re: [PATCH] typo (dashes)
From: Johannes Schindelin @ 2008-09-23 12:18 UTC (permalink / raw)
To: Frederik Schwarzer; +Cc: git
In-Reply-To: <200809231359.17068.schwarzerf@gmail.com>
Hi,
On Tue, 23 Sep 2008, Frederik Schwarzer wrote:
> >From 0d511a231d150ecb20308cb346da1432b1db2646 Mon Sep 17 00:00:00 2001
> From: Frederik Schwarzer <schwarzerf@gmail.com>
> Date: Tue, 23 Sep 2008 13:54:37 +0200
> Subject: [PATCH] typo (dashes)
>
> Signed-off-by: Frederik Schwarzer <schwarzerf@gmail.com>
> ---
I like the commit message.
Ciao,
Dscho
^ permalink raw reply
* Re: [ANNOUNCE] Git-1.6.0.2-preview20080923
From: Lee Henson @ 2008-09-23 12:09 UTC (permalink / raw)
To: prohaska; +Cc: msysGit, Git Mailing List
In-Reply-To: <B463062F-DD48-44A7-B2BB-8E5E0D177616@zib.de>
[-- Attachment #1: Type: text/plain, Size: 493 bytes --]
Thanks Steffen.
2008/9/23 Steffen Prohaska <prohaska@zib.de>
>
> On Sep 21, 2008, at 7:33 PM, Steffen Prohaska wrote:
>
> > Git-1.6.0.2-preview20080921 for Windows is available at
> >
> > http://code.google.com/p/msysgit/downloads
>
>
> I updated the installer to Git-1.6.0.2-preview20080923.
> The problems reported on the mailing list during the
> last two days should be fixed.
>
> I apologize for the quality of Git-1.6.0.2-preview20080921.
> It was unacceptable.
>
> Steffen
>
[-- Attachment #2: Type: text/html, Size: 940 bytes --]
^ permalink raw reply
* [PATCH] typo (dashes)
From: Frederik Schwarzer @ 2008-09-23 11:59 UTC (permalink / raw)
To: git
>From 0d511a231d150ecb20308cb346da1432b1db2646 Mon Sep 17 00:00:00 2001
From: Frederik Schwarzer <schwarzerf@gmail.com>
Date: Tue, 23 Sep 2008 13:54:37 +0200
Subject: [PATCH] typo (dashes)
Signed-off-by: Frederik Schwarzer <schwarzerf@gmail.com>
---
git.c | 2 +-
help.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git.c b/git.c
index 905acc2..bab0c0b 100644
--- a/git.c
+++ b/git.c
@@ -495,7 +495,7 @@ int main(int argc, const char **argv)
if (errno == ENOENT) {
if (done_alias) {
fprintf(stderr, "Expansion of alias '%s' failed; "
- "'%s' is not a git-command\n",
+ "'%s' is not a git command\n",
cmd, argv[0]);
exit(1);
}
diff --git a/help.c b/help.c
index 300cd38..e1dd449 100644
--- a/help.c
+++ b/help.c
@@ -330,7 +330,7 @@ const char *help_unknown_cmd(const char *cmd)
return assumed;
}
- fprintf(stderr, "git: '%s' is not a git-command. See 'git --help'.\n", cmd);
+ fprintf(stderr, "git: '%s' is not a git command. See 'git --help'.\n", cmd);
if (best_similarity < 6) {
fprintf(stderr, "\nDid you mean %s?\n",
--
1.6.0.1
^ permalink raw reply related
* Re: [PATCH v2 00/14] Sparse checkout
From: Santi Béjar @ 2008-09-23 11:57 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1221904913-25887-1-git-send-email-pclouds@gmail.com>
Hi,
Just some comments.
When you exclude the .gitignore file all the ignored files are
reported as "Untracked files". I.e, as in:
$git clone $git_url
$ cd git
$ make
$ git checkout --reset-path=Documentation/
$ git status
When you have local changes it says that it cannot switch branches
$ git checkout --reset-path=Documentation/
error: You have local changes to 'Makefile'; cannot switch branches.
$ git checkout -h
...
--reset-path <prefixes>
reset to new sparse checkout
--add-path <prefixes>
widen checkout area
--remove-path <prefixes>
narrow checkout area
s/prefixes/sparse patterns/
Best regards,
Santi
^ permalink raw reply
* Re: [PATCH v2 00/14] Sparse checkout
From: Nguyen Thai Ngoc Duy @ 2008-09-23 11:56 UTC (permalink / raw)
To: =?ISO-8859-1?Q?Santi_B=E9jar_; +Cc: Junio C Hamano, Jakub Narebski, git
In-Reply-To: <adf1fd3d0809230406r598f6d1l41cd860568de761f@mail.gmail.com>
On Tue, Sep 23, 2008 at 01:06:47PM +0200, =?ISO-8859-1?Q?Santi_B=E9jar_ wrote:
> While I agree that the checkout attr looks like an attribute (so
> reusing attr.c is a good idea) and $GIT_DIR/info/gitattributes seems a
> good place to specify them, I think it will be better in the config
> $GIT_DIR/config. There it is clear that it is a local thing and you
> have "git config" to read and write them. Additionally you could have
> different patterns in the config (sparse.default, sparse.doc,
> sparse.src,...), although maybe it is not very useful.
>
> I think the main UI to sparse checkout should be a default sparse
> pattern that is used for "all" commands, like merge, reset, and
> checkout. Now it is too easy to escape from the sparse checkout, when
> you merge or checkout a branch with new files, when doing a "git reset
> --hard" (when you abort a failed merge), or when doing a diff
> (specially when you pull).
It should not escape that easy (except newly added files). There is a
bug in my apply_narrow_spec() that effectively disables sparse
checkkout for other unpack_trees() calls except checkout/clone. Try
the below patch.
diff --git a/unpack-trees.c b/unpack-trees.c
index 10f377c..5bbe016 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -146,8 +146,10 @@ static int apply_narrow_spec(struct unpack_trees_options *o)
struct index_state *index = &o->result;
int i;
+ /*
if (!(o->new_narrow_path | o->add_narrow_path | o->remove_narrow_path))
return 0;
+ */
for (i = 0; i < index->cache_nr; i++) {
struct cache_entry *ce = index->cache[i];
--
Duy
^ permalink raw reply related
* Re: [QGit] Can't compile under windows (MSVC2008)
From: Abdelrazak Younes @ 2008-09-23 11:41 UTC (permalink / raw)
To: git; +Cc: Marco Costalba, Steffen Prohaska
In-Reply-To: <gbak2u$v9b$1@ger.gmane.org>
On 23/09/2008 13:31, Abdelrazak Younes wrote:
> Hello,
>
> I tried to follow README_WIN.txt:
>
> C:\devel\qgit\qgit4>qmake qgit.pro
>
> The Makefile (attached to this mail) seems to be correctly generated in
> the same directory (C:\devel\qgit\qgit4).
>
> Then, under MSVC2008 Express, I get this error:
Just wanted to add that command-line compilation with nmake was
successful and a bin/qgit.exe was generated that seems to work correctly
with latest Git-1.6.0.2-preview20080923 for Windows.
Thanks to all developers involved.
Abdel.
^ permalink raw reply
* [QGit] Can't compile under windows (MSVC2008)
From: Abdelrazak Younes @ 2008-09-23 11:31 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1344 bytes --]
Hello,
I tried to follow README_WIN.txt:
C:\devel\qgit\qgit4>qmake qgit.pro
The Makefile (attached to this mail) seems to be correctly generated in
the same directory (C:\devel\qgit\qgit4).
Then, under MSVC2008 Express, I get this error:
1>------ Début de la génération : Projet : qgit, Configuration : Debug
Win32 ------
1>Actions de projet Makefile en cours
1>Microsoft (R) Program Maintenance Utility Version 9.00.21022.08
1>Copyright (C) Microsoft Corporation. Tous droits rÚservÚs.
1> cd src\ && "C:\Program Files\Microsoft Visual Studio
9.0\VC\bin\nmake.exe" debug
1>Microsoft (R) Program Maintenance Utility Version 9.00.21022.08
1>Copyright (C) Microsoft Corporation. Tous droits rÚservÚs.
1>NMAKE : fatal error U1073: incapable d'obtenir 'src\\Makefile'
1>Stop.
1>NMAKE : fatal error U1077: 'cd'á: code retour '0x2'
1>Stop.
1>Project : error PRJ0019: Un outil a retourné un code d'erreur à partir
de "Actions de projet Makefile en cours"
1>Le journal de génération a été enregistré à l'emplacement
"file://c:\devel\qgit\qgit4\Debug\BuildLog.htm"
1>qgit - 3 erreur(s), 0 avertissement(s)
========== Génération : 0 a réussi, 1 a échoué, 0 mis à jour, 0 a été
ignoré ==========
Idea someone?
Wouldn't it be nice to use CMake instead of qmake so that the MSVC
solution is generated directly?
Abdel.
[-- Attachment #2: Makefile --]
[-- Type: text/plain, Size: 5078 bytes --]
#############################################################################
# Makefile for building: qgit
# Generated by qmake (2.01a) (Qt 4.4.2-snapshot-20080730) on: mar. 23. sept. 13:26:35 2008
# Project: qgit.pro
# Template: subdirs
# Command: c:\devel\qt\4.4\bin\qmake.exe -win32 -o Makefile qgit.pro
#############################################################################
first: make_default
MAKEFILE = Makefile
QMAKE = c:\devel\qt\4.4\bin\qmake.exe
DEL_FILE = del
CHK_DIR_EXISTS= if not exist
MKDIR = mkdir
COPY = copy /y
COPY_FILE = $(COPY)
COPY_DIR = xcopy /s /q /y /i
INSTALL_FILE = $(COPY_FILE)
INSTALL_PROGRAM = $(COPY_FILE)
INSTALL_DIR = $(COPY_DIR)
DEL_FILE = del
SYMLINK =
DEL_DIR = rmdir
MOVE = move
CHK_DIR_EXISTS= if not exist
MKDIR = mkdir
SUBTARGETS = \
sub-src
src\$(MAKEFILE):
@$(CHK_DIR_EXISTS) src\ $(MKDIR) src\
cd src\ && $(QMAKE) src.pro -win32 -o $(MAKEFILE)
sub-src-qmake_all: FORCE
@$(CHK_DIR_EXISTS) src\ $(MKDIR) src\
cd src\ && $(QMAKE) src.pro -win32 -o $(MAKEFILE)
sub-src: src\$(MAKEFILE) FORCE
cd src\ && $(MAKE) -f $(MAKEFILE)
sub-src-make_default: src\$(MAKEFILE) FORCE
cd src\ && $(MAKE) -f $(MAKEFILE)
sub-src-make_first: src\$(MAKEFILE) FORCE
cd src\ && $(MAKE) -f $(MAKEFILE) first
sub-src-all: src\$(MAKEFILE) FORCE
cd src\ && $(MAKE) -f $(MAKEFILE) all
sub-src-clean: src\$(MAKEFILE) FORCE
cd src\ && $(MAKE) -f $(MAKEFILE) clean
sub-src-distclean: src\$(MAKEFILE) FORCE
cd src\ && $(MAKE) -f $(MAKEFILE) distclean
sub-src-install_subtargets: src\$(MAKEFILE) FORCE
cd src\ && $(MAKE) -f $(MAKEFILE) install
sub-src-uninstall_subtargets: src\$(MAKEFILE) FORCE
cd src\ && $(MAKE) -f $(MAKEFILE) uninstall
Makefile: qgit.pro ..\..\qt\4.4\mkspecs\default\qmake.conf ..\..\qt\4.4\mkspecs\qconfig.pri \
..\..\qt\4.4\mkspecs\features\qt_functions.prf \
..\..\qt\4.4\mkspecs\features\qt_config.prf \
..\..\qt\4.4\mkspecs\features\exclusive_builds.prf \
..\..\qt\4.4\mkspecs\features\default_pre.prf \
..\..\qt\4.4\mkspecs\features\win32\default_pre.prf \
..\..\qt\4.4\mkspecs\features\debug.prf \
..\..\qt\4.4\mkspecs\features\debug_and_release.prf \
..\..\qt\4.4\mkspecs\features\default_post.prf \
..\..\qt\4.4\mkspecs\features\win32\rtti.prf \
..\..\qt\4.4\mkspecs\features\win32\exceptions.prf \
..\..\qt\4.4\mkspecs\features\shared.prf \
..\..\qt\4.4\mkspecs\features\win32\embed_manifest_exe.prf \
..\..\qt\4.4\mkspecs\features\win32\embed_manifest_dll.prf \
..\..\qt\4.4\mkspecs\features\warn_on.prf \
..\..\qt\4.4\mkspecs\features\qt.prf \
..\..\qt\4.4\mkspecs\features\win32\thread.prf \
..\..\qt\4.4\mkspecs\features\moc.prf \
..\..\qt\4.4\mkspecs\features\win32\windows.prf \
..\..\qt\4.4\mkspecs\features\win32\stl_off.prf \
..\..\qt\4.4\mkspecs\features\resources.prf \
..\..\qt\4.4\mkspecs\features\uic.prf \
..\..\qt\4.4\mkspecs\features\yacc.prf \
..\..\qt\4.4\mkspecs\features\lex.prf
$(QMAKE) -win32 -o Makefile qgit.pro
..\..\qt\4.4\mkspecs\qconfig.pri:
..\..\qt\4.4\mkspecs\features\qt_functions.prf:
..\..\qt\4.4\mkspecs\features\qt_config.prf:
..\..\qt\4.4\mkspecs\features\exclusive_builds.prf:
..\..\qt\4.4\mkspecs\features\default_pre.prf:
..\..\qt\4.4\mkspecs\features\win32\default_pre.prf:
..\..\qt\4.4\mkspecs\features\debug.prf:
..\..\qt\4.4\mkspecs\features\debug_and_release.prf:
..\..\qt\4.4\mkspecs\features\default_post.prf:
..\..\qt\4.4\mkspecs\features\win32\rtti.prf:
..\..\qt\4.4\mkspecs\features\win32\exceptions.prf:
..\..\qt\4.4\mkspecs\features\shared.prf:
..\..\qt\4.4\mkspecs\features\win32\embed_manifest_exe.prf:
..\..\qt\4.4\mkspecs\features\win32\embed_manifest_dll.prf:
..\..\qt\4.4\mkspecs\features\warn_on.prf:
..\..\qt\4.4\mkspecs\features\qt.prf:
..\..\qt\4.4\mkspecs\features\win32\thread.prf:
..\..\qt\4.4\mkspecs\features\moc.prf:
..\..\qt\4.4\mkspecs\features\win32\windows.prf:
..\..\qt\4.4\mkspecs\features\win32\stl_off.prf:
..\..\qt\4.4\mkspecs\features\resources.prf:
..\..\qt\4.4\mkspecs\features\uic.prf:
..\..\qt\4.4\mkspecs\features\yacc.prf:
..\..\qt\4.4\mkspecs\features\lex.prf:
qmake: qmake_all FORCE
@$(QMAKE) -win32 -o Makefile qgit.pro
qmake_all: sub-src-qmake_all FORCE
make_default: sub-src-make_default FORCE
make_first: sub-src-make_first FORCE
all: sub-src-all FORCE
clean: sub-src-clean FORCE
distclean: sub-src-distclean FORCE
-$(DEL_FILE) Makefile
install_subtargets: sub-src-install_subtargets FORCE
uninstall_subtargets: sub-src-uninstall_subtargets FORCE
sub-src-sub_Debug: src\\$(MAKEFILE)
cd src\ && $(MAKE) debug
debug: sub-src-sub_Debug
sub-src-sub_Release: src\\$(MAKEFILE)
cd src\ && $(MAKE) release
release: sub-src-sub_Release
mocclean: compiler_moc_header_clean compiler_moc_source_clean
mocables: compiler_moc_header_make_all compiler_moc_source_make_all
install: install_subtargets FORCE
uninstall: uninstall_subtargets FORCE
FORCE:
^ permalink raw reply
* Re: Locking binary files
From: Boaz Harrosh @ 2008-09-23 11:20 UTC (permalink / raw)
To: Mario Pareja; +Cc: git
In-Reply-To: <48D8CFF1.8030403@panasas.com>
Boaz Harrosh wrote:
> Mario Pareja wrote:
>> Hi,
>>
>> For one and a half years, I have been keeping my eyes on the git
>> community in hopes of making the switch away from SVN. One particular
>> issue holding me back is the inability to lock binary files.
>> Throughout the past year, I have yet to see developments on this
>> issue. I understand that locking files goes against the fundamental
>> principles of distributed source control, but I think we need to come
>> up with some workarounds. For Linux kernel development this is may
>> not be an issue; however, for application development this is a major
>> issue. How else can one developer be sure that time spent editing a
>> binary file will not be wasted because another developer submitted a
>> change?
>>
>> To achieve the effects of locking, a "central" repository must be
>> identified. Regardless of the distributed nature of git, most
>> _companies_ will have a "central" repository for a software project.
>> We should be able to mark a file as requiring a lock from the
>> governing git repository at a specified address. Is this made
>> difficult because git tracks file contents not files?
>>
>> In any case, I think this is a crucial issue that needs to be
>> addressed if git is going to be adopted by companies with binary file
>> conflict potential. I don't see how a web development company can take
>> advantage of git to track source code and image file changes. Any
>> advice would be great!
>>
>> Regards,
>>
>> Mario
>> --
>
> It should be easy for a company to set a policy where a couple of scripts
> must be run for particular type of files. Given that, the implementation
> of such scripts is easy:
>
> For every foo.bin there is possibly a foo.bin.lock file.
>
> Lock-script look for absence of the lock-file at upstream then git-add
> the file (With some info that tells users things like who has the file).
> If git-push fails, since I'm adding a file and someone already added
> it while I was pushing, then the lock is not granted.
>
> Unlock-script will git-rm the lock-file and push.
>
> In both scripts mod-bits of original file can be toggled for
> read-only/write signaling to the user. (At upstream the file is always
> read-only)
>
> This can also work in a distributed system with more then one tier of
> servers. (Locks pushed to the most upstream server)
>
> Combine that with git's mail notifications for commits and you have a
> system far more robust then svn will ever want to be
>
> My $0.017
> Boaz
>
OK combine that with a technic presented in this ml thread:
"Management of opendocument (openoffice.org) files in git"
And make all this automatic for particular type of files
Boaz
^ permalink raw reply
* Re: rebasing merges
From: SZEDER Gábor @ 2008-09-23 11:16 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Stephen Haberman, Johannes Sixt, git
In-Reply-To: <48D8B2C1.5070800@op5.se>
Hi,
On Tue, Sep 23, 2008 at 11:11:29AM +0200, Andreas Ericsson wrote:
> That's beside the point though, as I firmly believe git should be more
> helpful in this situation. If "git rebase -i -p" doesn't help you fix
> the problems, I'll see what I can do to help.
I will just throw in an other workflow, where keeping merges during
(non-interactive) rebase would be really helpful for me.
The DAG looks like this:
-A--------------H master
\
B--C------F--G topic
\ /
D--E subtopic
I develop a new feature in my private repository on branch 'topic'.
Every now and then there are two or more commits that somehow belong
together (e.g. a refactoring consisting of multiple commits). I
prefer having this "belong together" information explicitly in the
repository, therefore for these commits (D and E) I create the new
branch 'subtopic' that will be merged back into 'topic' (with
--no-ff). This way I can see in the logs or in gitk explicitly that
those commits belong together. While working on a bigger feature
there might be multiple 'subtopic' branches that get merged back into
'topic'.
But now I can't rebase 'topic' on top of master, because rebase would
linearize the history, losing the subtopic merges.
Best,
Gábor
^ permalink raw reply
* Re: Locking binary files
From: Boaz Harrosh @ 2008-09-23 11:16 UTC (permalink / raw)
To: Mario Pareja; +Cc: git
In-Reply-To: <94c1db200809222339t7d65081eq7471fef86fb5ec73@mail.gmail.com>
Mario Pareja wrote:
> Hi,
>
> For one and a half years, I have been keeping my eyes on the git
> community in hopes of making the switch away from SVN. One particular
> issue holding me back is the inability to lock binary files.
> Throughout the past year, I have yet to see developments on this
> issue. I understand that locking files goes against the fundamental
> principles of distributed source control, but I think we need to come
> up with some workarounds. For Linux kernel development this is may
> not be an issue; however, for application development this is a major
> issue. How else can one developer be sure that time spent editing a
> binary file will not be wasted because another developer submitted a
> change?
>
> To achieve the effects of locking, a "central" repository must be
> identified. Regardless of the distributed nature of git, most
> _companies_ will have a "central" repository for a software project.
> We should be able to mark a file as requiring a lock from the
> governing git repository at a specified address. Is this made
> difficult because git tracks file contents not files?
>
> In any case, I think this is a crucial issue that needs to be
> addressed if git is going to be adopted by companies with binary file
> conflict potential. I don't see how a web development company can take
> advantage of git to track source code and image file changes. Any
> advice would be great!
>
> Regards,
>
> Mario
> --
It should be easy for a company to set a policy where a couple of scripts
must be run for particular type of files. Given that, the implementation
of such scripts is easy:
For every foo.bin there is possibly a foo.bin.lock file.
Lock-script look for absence of the lock-file at upstream then git-add
the file (With some info that tells users things like who has the file).
If git-push fails, since I'm adding a file and someone already added
it while I was pushing, then the lock is not granted.
Unlock-script will git-rm the lock-file and push.
In both scripts mod-bits of original file can be toggled for
read-only/write signaling to the user. (At upstream the file is always
read-only)
This can also work in a distributed system with more then one tier of
servers. (Locks pushed to the most upstream server)
Combine that with git's mail notifications for commits and you have a
system far more robust then svn will ever want to be
My $0.017
Boaz
^ permalink raw reply
* Re: Management of opendocument (openoffice.org) files in git
From: Peter Krefting @ 2008-09-23 11:08 UTC (permalink / raw)
To: Sergio Callegari; +Cc: git
In-Reply-To: <loom.20080915T222909-709@post.gmane.org>
Sergio Callegari:
> To try it, save the following as "rezip" with execution permission:
I had some problems when I tried to implement this a Windows machine,
it did not handle paths with spaces in them properly, and "Documents
and Settings" does contain spaces.
The following patch fixes that for me:
---
rezip | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/rezip b/rezip
index 15f83a4..845e875 100755
--- a/rezip
+++ b/rezip
@@ -66,7 +66,7 @@ done
if [ $# = 0 ] ; then
tmpcopy=$(mktemp rezip.zip.XXXXXX)
- cat > $tmpcopy
+ cat > "$tmpcopy"
filename="$tmpcopy"
else
tmpcopy=""
@@ -76,12 +76,12 @@ fi
workdir=$(mktemp -d -t rezip.workdir.XXXXXX)
curdir=$(pwd)
-cd $workdir
+cd "$workdir"
unzip $UNZIP_OPTS "$curdir/$filename"
zip $ZIP_OPTS "$curdir/$filename" .
-cd $curdir
-rm -fr $workdir
+cd "$curdir"
+rm -fr "$workdir"
if [ ! -z "$tmpcopy" ] ; then
- cat $filename
- rm $tmpcopy
+ cat "$filename"
+ rm "$tmpcopy"
fi
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply related
* Re: [PATCH v2 00/14] Sparse checkout
From: Santi Béjar @ 2008-09-23 11:06 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, Jakub Narebski, git
In-Reply-To: <fcaeb9bf0809210311x7e9337fbmd978e95aa7998525@mail.gmail.com>
On Sun, Sep 21, 2008 at 12:11 PM, Nguyen Thai Ngoc Duy
<pclouds@gmail.com> wrote:
> On 9/21/08, Junio C Hamano <gitster@pobox.com> wrote:
>> "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
>>
>> > On 9/21/08, Jakub Narebski <jnareb@gmail.com> wrote:
>>
>> > ...
>>
>> >> >> BTW I think that the same rules are used in gitattributes, aren't
>> >> >> they?
>> >> >
>> >> > They have different implementations. Though the rules may be the same.
>> >>
>> >> Were you able to reuse either one?
>> >
>> > No. .gitignore is tied to read_directory() while .gitattributes has
>> > attributes attached. So I rolled out another one for index.
>>
>>
>> I am sorry, but that sounds like a rather lame excuse. It certainly is
>> possible to introduce an "ignored" attribute and have .gitattributes file
>> specify that, instead of having an entry in .gitignore file, if you teach
>> read_directory() to pay attention to the attributes mechanism. If we had
>> from day one that a more generic gitattributes mechanism, I would imagine
>> we wouldn't even had a separate .gitignore codepath but used the attribute
>> mechanism throughout the system.
>>
>> Now I do not think we are ever going to deprecate gitignore and move
>> everybody to "ignored" attributes, because such a transition would not buy
>> the end users anything, but it technically is possible and would have been
>> the right thing to do, if we were building the system from scratch. We
>> still could add it as an optional feature (i.e. if a path has the
>> attribute that says "ignored" or "not ignored", then that determines the
>> fate of the path, otherwise we look at gitignore).
>>
>> I wouldn't be surprised if an alternative implementation of your code to
>> assign "sparseness" to each path internally used "to-be-checked-out"
>> attribute, and used that attribute to control how ls-files filters its
>> output.
>>
>> A better excuse might have been that "I am not reading these patterns from
>> anywhere but command line", but that got me thinking further.
>
> That "from command line" piece makes a bit of difference. For example
> patterns separated by colons and backslash escape, but that does not
> stop it from reusing attr.c.
>
>> How would that --narrow-match that is not stored anywhere on the
>> filesystem but used only for filtering the output be any more useful than
>> a grep that filters ls-files output in practice?
>
> Well, it works exactly like 'grep' internally.
>
>> I would imagine it would be much more useful if .git/info/attributes can
>> specify "checkout" attribute that is defined like this:
>>
>> `checkout`
>> ^^^^^^^^^^
>>
>> This attribute controls if the path can be left not checked-out to the
>> working tree.
>>
>> Unset::
>> Unsetting the `checkout` marks the path not to be checked out.
>>
>> Unspecified::
>> A path which does not have any `checkout` attribute specified is
>> handled in no special way.
>>
>> Any value set to `checkout` is ignored, and git acts as if the
>> attribute is left unspecified.
>>
>> Then whenever a new path enters the index, you _could_ check with the
>> attribute mechanism to set the CE_NOCHECKOUT flag. Just like an already
>> tracked path is not ignored even if it matches .gitignore pattern, a path
>> without CE_NOCHECKOUT that is in the index is checked out even if it has
>> checkout attribute Unset.
>>
>> Hmm?
>
> Well I think people would want to save no-checkout rules eventually.
> But I don't know how they want to use it. Will the saved rules be hard
> restriction, that no files can be checked out outside defined areas?
> Will it be to save a couple of keystrokes, that is, instead of
> typing "--reset-sparse=blah" all the time, now just "--reset-sparse"
> and default rules will be applied? Your suggestion would be the third,
> applying on new files only.
>
> Anyway I will try to extend attr.c a bit to take input from command
> line, then move "sparse patterns" over to use attr.c.
While I agree that the checkout attr looks like an attribute (so
reusing attr.c is a good idea) and $GIT_DIR/info/gitattributes seems a
good place to specify them, I think it will be better in the config
$GIT_DIR/config. There it is clear that it is a local thing and you
have "git config" to read and write them. Additionally you could have
different patterns in the config (sparse.default, sparse.doc,
sparse.src,...), although maybe it is not very useful.
I think the main UI to sparse checkout should be a default sparse
pattern that is used for "all" commands, like merge, reset, and
checkout. Now it is too easy to escape from the sparse checkout, when
you merge or checkout a branch with new files, when doing a "git reset
--hard" (when you abort a failed merge), or when doing a diff
(specially when you pull).
Santi
^ permalink raw reply
* Re: TopGit: how to deal with upstream inclusion
From: Petr Baudis @ 2008-09-23 9:55 UTC (permalink / raw)
To: martin f krafft; +Cc: git
In-Reply-To: <20080923063550.GC19084@piper.oerlikon.madduck.net>
On Tue, Sep 23, 2008 at 08:35:50AM +0200, martin f krafft wrote:
> also sprach Petr Baudis <pasky@suse.cz> [2008.09.21.1619 +0200]:
> > > Yes, it does. One might want to consider to make the use of -s ours
> > > in (iiii) configurable, but otherwise that's it.
> >
> > That might be pretty dangerous, since then your topic branch will have
> > outstanding branches of the retired branch, but they will _NOT_ be
> > visible to tg patch and others since they will be in both the base and
> > head.
>
> Well, but what if upstream implemented our solution slightly
> differently, and if it's only because they used tabs instead of
> spaces? We wouldn't want -s ours then, huh?
You still would want to get tabs in other patches that depended on the
merged one, no? Otherwise tg patch output will produce patches that do
not apply and tg export will change the tabs back to spaces.
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [ANNOUNCE] Git-1.6.0.2-preview20080923
From: Johannes Schindelin @ 2008-09-23 9:36 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: msysGit, Git Mailing List
In-Reply-To: <B463062F-DD48-44A7-B2BB-8E5E0D177616@zib.de>
Hi,
On Tue, 23 Sep 2008, Steffen Prohaska wrote:
> I apologize for the quality of Git-1.6.0.2-preview20080921.
> It was unacceptable.
No, that is too harsh. There is some meaning in the infix "preview", and
given that you gave everybody (me included, I have to admit) the chance to
work on this installer earlier, there is nothing to apologize for.
Ciao,
Dscho
^ 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