* Re: Bizarre missing changes (git bug?)
From: Alex Riesen @ 2008-07-21 20:42 UTC (permalink / raw)
To: Tim Harper; +Cc: git
In-Reply-To: <8502DF7C-5303-49E8-8C67-F837343E2F0C@gmail.com>
Tim Harper, Mon, Jul 21, 2008 22:26:06 +0200:
> I ran into a strange issue that has left me scratching my head.
>
> I have a commit in my history, that does indeed show up in my branch,
> named "sprint"
>
...
>
> Any help or clues VERY much apperciated. Thanks!
>
Try looking at the history graph in gitk
$ gitk --all -- app/controllers/events_controller.rb spec/fixtures/factors.yml
It usually shows the history in a very understandable way and
it can help to detect when the histories have diverged.
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Linus Torvalds @ 2008-07-21 20:37 UTC (permalink / raw)
To: Tim Harper; +Cc: git
In-Reply-To: <8502DF7C-5303-49E8-8C67-F837343E2F0C@gmail.com>
On Mon, 21 Jul 2008, Tim Harper wrote:
>
> Anyone run into this before? Any idea what might have caused it? We're a bit
> concerned about this because if we don't know how to avoid this, we no longer
> can feel certain that when something is committed, it will make it out in our
> release.
Read up on '--full-history'.
By default, git simplifies the history for logs that have path
simplification: only walking down the side of a merge that all the data
came from (ie the unchanged side). So it only leaves merges around if
there was changes from _all_ parents.
So without --full-history, if any parent matches the state, it just
removes the merge and picks that parent that contained all the state.
Obviously, any changes to that file can be sufficiently explained by
walking just that limited history, because they must have changed in
_that_ history too!
That default behaviour leads to a *much* simpler history, and is usually
what you want - it avoids unnecessary duplication when something was
changed trivially the same way in both branches - 'git log' will just pick
the first branch.
So, if you had two (or more) commits that both fixed the same bug in
different branches, and thus both branches actually ended up with the same
contents, it does mean that "git log <filename>" will only show _one_ of
the fixes.
In this case, it apparently showed another version than the one you were
looking for.
Linus
^ permalink raw reply
* Bizarre missing changes (git bug?)
From: Tim Harper @ 2008-07-21 20:26 UTC (permalink / raw)
To: git
I ran into a strange issue that has left me scratching my head.
I have a commit in my history, that does indeed show up in my branch,
named "sprint"
The following commands yield as follows (I've modified the output
slightly to conceal any potentially proprietary information):
#########################
git log HEAD -p
commit 8f9effffb0dcdacd514085608e8923fbbe00ff29
Author: Name Concealed <email@email.com>
Date: Mon Jul 14 16:19:18 2008 -0600
commit message....
diff --git a/app/controllers/events_controller.rb b/app/controllers/
events_controller.rb
index 6905ba4..a0b7dfc 100644
--- a/app/controllers/events_controller.rb
+++ b/app/controllers/events_controller.rb
@@ -238,36 +238,37 @@ class EventsController < ApplicationController
}.freeze
RUBY_STUFF = {
- changes...
- changes...
- changes...
+ changes...
+ changes...
+ changes...
diff --git a/spec/fixtures/factors.yml b/spec/fixtures/factors.yml
index 186ed73..3c76e86 100755
--- a/spec/fixtures/factors.yml
+++ b/spec/fixtures/factors.yml
@@ -2483,4 +2483,54 @@ some_branch:
file:
contents:
- reliable_on:
\ No newline at end of file
+ data:
+fixture_name:
+ id: 115
+ file: Event
+ contents: behavior
#########################
git log spec/fixtures/factors.yml
... commit 8f9effff is not listed anywhere
#########################
git log app/controllers/events_controller.rb
... commit 8f9effff shows up
#########################
git branch --contains 8f9effff
some-task-branch
* sprint
The changes in 8f9effff for app/controllers/events_controller.rb show
up in the working copy, however the changes for spec/fixtures/
factors.yml are nowhere to be seen. It's as if the history of that
particular file diverged somehow, but I know that can't be true since
git doesn't track files.
Anyone run into this before? Any idea what might have caused it?
We're a bit concerned about this because if we don't know how to avoid
this, we no longer can feel certain that when something is committed,
it will make it out in our release.
Any help or clues VERY much apperciated. Thanks!
Tim
^ permalink raw reply related
* [GSoC] Git popularity on GSoC
From: Sverre Rabbelier @ 2008-07-21 20:07 UTC (permalink / raw)
To: Git Mailinglist
Heya,
There was a poll on the GSoC students mailing list: "What is your
favorite revision control system?". From the 100 responses so far, my
vote topled the balance in favor of Git ;). As a statistics junkie I
think it's fun to see that the only real competition among GSoC
students is Subversion, which has about as much market share as Git.
(Surely the 1 vote for TFS/SourceSafe must have been a misclick.) At
least nobody can claim we're the underdog RCS anymore!
Git 40% (40)
Subversion 39% (39)
Mercurial 7% (7)
CVS 6% (6)
Bazaar 5% (5)
Perforce 1% (1)
Monotone 1% (1)
Microsoft TFS/SourceSafe 1% (1)
Other 0% (0)
BitKeeper 0% (0)
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH] checkout without arguments does not make sense
From: Johannes Sixt @ 2008-07-21 20:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
builtin-checkout.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/builtin-checkout.c b/builtin-checkout.c
index fbd5105..669be0e 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -487,7 +487,8 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
}
return checkout_paths(source_tree, pathspec);
- }
+ } else if (!new.name && !opts.new_branch)
+ usage_with_options(checkout_usage, options);
if (new.name && !new.commit) {
die("Cannot switch branch to a non-commit.");
--
1.6.0.rc0.18.g6aef2
^ permalink raw reply related
* Re: Git Branding Overview, Re: Git.or.cz Experimental Design
From: Matt Graham @ 2008-07-21 20:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Michael J Gruber, git
In-Reply-To: <alpine.DEB.1.00.0807211218470.8986@racer>
On Mon, Jul 21, 2008 at 7:20 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 21 Jul 2008, Michael J Gruber wrote:
>
>> Martin Langhoff venit, vidit, dixit 20.07.2008 23:50:
>> > On Fri, Jul 18, 2008 at 10:39 PM, Petr Baudis <pasky@suse.cz> wrote:
>> > > On Wed, Jul 02, 2008 at 11:11:02PM -0400, David Baldwin wrote:
>> > > > http://baldwindev.com/git.or.cz/
>> > > I'm not sure if this is really an improvement on the current state,
>> > > but then again, the current state pretty much matches my idea and maybe
>> > > others will agree that your proposal is better. Thus, it's better to
>> > > show this to the Git community at large. :-)
>> >
>> > FWIW, I like it. I like both the better font and whitespace layout and
>> > the 3-color-spot-merge-to-white. As Petr says, we have had the
>> > (apologies, but to me) ugly logo for a while, so it is widely used,
>> > and perhaps it has even grown on people.
>> >
>> > BazaarNG managed to grab the best concept logo of the lot, IMHO, with
>> > the 'merge' roadsign.
>> >
>> > > If you think you have a cooler logo, that's fine too, but then it's
>> > > again better to present it explicitly, I believe.
>> >
>> > Can we separate the 2 things? The better fonts and layout look like a win to
>> > me.
>> >
>> > WRT the logo, the current one is not a particularly strong image, and
>> > we haven't spent millions in plastering it over magazines or anything.
>> > So a good new logo would be something to take on.
>>
>> I like that new logo (plusminus G), too, it's very descriptive. I just want to
>> raise one question which I can't answer myself:
>>
>> Are there any potential issues with the Helvetica license?
>>
>> In any case it may be safer do redo it with a GPL sans serif font. If one
>> wants to keep the association of the shape of "G" with a circular arrow then
>> FreeSans and Nimbus Sans L seem to be the only options.
>>
>> Alternatively, it may be easier to redo it in plain PS. I'll attach 2 KISS
>> variants. 1.5k for the eps, 3 colors only.
>
> You could have spared yourself the trouble:
>
> http://repo.or.cz/w/msysgit.git?a=blob_plain;f=share/resources/gitlogo.svg;h=c0d67e70ab31394f0635c141998e512437a138b4;hb=HEAD
The sideways Git is sweet, but as a favicon, it's awfully small. I
think it would be easier to see with just the sideways G or just the
+- as a favicon and the whole thing for larger images.
^ permalink raw reply
* Re: [PATCH] Fix update-index --refresh for submodules if stat(2) returns st_size 0
From: Alex Riesen @ 2008-07-21 19:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0807211917440.8986@racer>
Johannes Schindelin, Mon, Jul 21, 2008 20:20:43 +0200:
> Hi,
>
> On Mon, 21 Jul 2008, Alex Riesen wrote:
>
> > For example - Cygwin.
>
> Please enhance: your oneline is too long, and your commit message body too
> short.
Well, I'm really not sure. I just found this difference between linux
and cygwin (st_stat is 0 for dirs on cygwin). Than I noticed that the
routine where I made the change explicitely checks for st_size not
being 0. I must admit I can't make much out of comment, and hope this
discussion will help to clear the check up.
> > Can MSys folks please try it? I noticed it when the test
> > t2103-update-index-ignore-missing.sh (the 5th case) started failing.
>
> Since M$' documentation says "This member does not have a meaning for
> directories." about the member nFileSizeLow of WIN32_FILE_ATTRIBUTE_DATA
> which we use to implement a sane "lstat()", I think this bug hits MinGW
> (not MSys) as well.
Could you, just for completeness, try? I don't have mingw at hand
and SUSv3 (http://www.opengroup.org/onlinepubs/009695399/toc.htm)
does not tells much too. No UNIX system I know about has it 0 for
directories.
^ permalink raw reply
* [PATCH 10/9] git-gui: git.git now uses $(gitexec_instdir) to point to the exec-path
From: Johannes Sixt @ 2008-07-21 19:26 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano
In-Reply-To: <1216667998-8879-10-git-send-email-johannes.sixt@telecom.at>
In git.git the Makefile variable $(gitexecdir) can be relative. It now
exports the actual install location in $(gitexec_instdir).
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
Makefile | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index b19fb2d..c8660fb 100644
--- a/Makefile
+++ b/Makefile
@@ -30,8 +30,12 @@ ifndef SHELL_PATH
endif
ifndef gitexecdir
+ifdef gitexec_instdir
+ gitexecdir := $(gitexec_instdir)
+else
gitexecdir := $(shell git --exec-path)
endif
+endif
ifndef sharedir
sharedir := $(dir $(gitexecdir))share
--
1.6.0.rc0.18.g6aef2
^ permalink raw reply related
* [PATCH 8/9] Windows: Make sure argv[0] has a path
From: Johannes Sixt @ 2008-07-21 19:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <1216667998-8879-8-git-send-email-johannes.sixt@telecom.at>
Since the exec-path on Windows is derived from the program invocation path,
we must ensure that argv[0] always has a path. Unfortunately, if a program
is invoked from CMD, argv[0] has no path. But on the other hand, the
C runtime offers a global variable, _pgmptr, that always has the full path
to the program. We hook into main() with a preprocessor macro, where we
replace argv[0].
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
compat/mingw.h | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/compat/mingw.h b/compat/mingw.h
index 8ffec51..290a9e6 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -223,3 +223,15 @@ void mingw_open_html(const char *path);
char **copy_environ(void);
void free_environ(char **env);
char **env_setenv(char **env, const char *name);
+
+/*
+ * A replacement of main() that ensures that argv[0] has a path
+ */
+
+#define main(c,v) main(int argc, const char **argv) \
+{ \
+ static int mingw_main(); \
+ argv[0] = xstrdup(_pgmptr); \
+ return mingw_main(argc, argv); \
+} \
+static int mingw_main(c,v)
--
1.6.0.rc0.18.g6aef2
^ permalink raw reply related
* [PATCH 7/9] Windows: Make $(gitexecdir) relative
From: Johannes Sixt @ 2008-07-21 19:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <1216667998-8879-7-git-send-email-johannes.sixt@telecom.at>
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
Makefile | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 908c1cb..1bfffff 100644
--- a/Makefile
+++ b/Makefile
@@ -745,6 +745,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
COMPAT_OBJS += compat/mingw.o compat/fnmatch.o compat/regex.o compat/winansi.o
EXTLIBS += -lws2_32
X = .exe
+ gitexecdir = ../libexec/git-core
template_dir = ../share/git-core/templates/
ETC_GITCONFIG = ../etc/gitconfig
endif
--
1.6.0.rc0.18.g6aef2
^ permalink raw reply related
* [PATCH 9/9] Windows: Do not compile git-shell
From: Johannes Sixt @ 2008-07-21 19:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <1216667998-8879-9-git-send-email-johannes.sixt@telecom.at>
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
Makefile | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 1bfffff..f8dd7e6 100644
--- a/Makefile
+++ b/Makefile
@@ -283,7 +283,6 @@ PROGRAMS += git-pack-redundant$X
PROGRAMS += git-patch-id$X
PROGRAMS += git-receive-pack$X
PROGRAMS += git-send-pack$X
-PROGRAMS += git-shell$X
PROGRAMS += git-show-index$X
PROGRAMS += git-unpack-file$X
PROGRAMS += git-update-server-info$X
@@ -812,6 +811,7 @@ EXTLIBS += -lz
ifndef NO_POSIX_ONLY_PROGRAMS
PROGRAMS += git-daemon$X
PROGRAMS += git-imap-send$X
+ PROGRAMS += git-shell$X
endif
ifndef NO_OPENSSL
OPENSSL_LIBSSL = -lssl
@@ -1348,7 +1348,7 @@ endif
fi && \
{ $(foreach p,$(BUILT_INS), $(RM) "$$execdir/$p" && ln "$$execdir/git$X" "$$execdir/$p" ;) } && \
$(RM) "$$execdir/git$X" && \
- ./check_bindir "z$$bindir" "z$$execdir" "$$bindir/git-shell$X"
+ ./check_bindir "z$$bindir" "z$$execdir" "$$bindir/git-add$X"
install-doc:
$(MAKE) -C Documentation install
--
1.6.0.rc0.18.g6aef2
^ permalink raw reply related
* [PATCH 6/9] Allow add_path() to add non-existent directories to the path
From: Johannes Sixt @ 2008-07-21 19:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <1216667998-8879-6-git-send-email-johannes.sixt@telecom.at>
This function had used make_absolute_path(); but this function dies if
the directory that contains the entry whose relative path was supplied in
the argument does not exist. This is a problem if the argument is, for
example, "../libexec/git-core", and that "../libexec" does not exist.
Since the resolution of symbolic links is not required for elements in
PATH, we can fall back to using make_nonrelative_path(), which simply
prepends $PWD to the path.
We have to move make_nonrelative_path() alongside make_absolute_path() in
abspath.c so that git-shell can be linked. See 5b8e6f85f.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
abspath.c | 36 ++++++++++++++++++++++++++++++++++++
exec_cmd.c | 2 +-
path.c | 36 ------------------------------------
3 files changed, 37 insertions(+), 37 deletions(-)
diff --git a/abspath.c b/abspath.c
index 4f95a95..0d56124 100644
--- a/abspath.c
+++ b/abspath.c
@@ -66,3 +66,39 @@ const char *make_absolute_path(const char *path)
return buf;
}
+
+static const char *get_pwd_cwd(void)
+{
+ static char cwd[PATH_MAX + 1];
+ char *pwd;
+ struct stat cwd_stat, pwd_stat;
+ if (getcwd(cwd, PATH_MAX) == NULL)
+ return NULL;
+ pwd = getenv("PWD");
+ if (pwd && strcmp(pwd, cwd)) {
+ stat(cwd, &cwd_stat);
+ if (!stat(pwd, &pwd_stat) &&
+ pwd_stat.st_dev == cwd_stat.st_dev &&
+ pwd_stat.st_ino == cwd_stat.st_ino) {
+ strlcpy(cwd, pwd, PATH_MAX);
+ }
+ }
+ return cwd;
+}
+
+const char *make_nonrelative_path(const char *path)
+{
+ static char buf[PATH_MAX + 1];
+
+ if (is_absolute_path(path)) {
+ if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX)
+ die("Too long path: %.*s", 60, path);
+ } else {
+ const char *cwd = get_pwd_cwd();
+ if (!cwd)
+ die("Cannot determine the current working directory");
+ if (snprintf(buf, PATH_MAX, "%s/%s", cwd, path) >= PATH_MAX)
+ die("Too long path: %.*s", 60, path);
+ }
+ return buf;
+}
diff --git a/exec_cmd.c b/exec_cmd.c
index c236034..0ed768d 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -50,7 +50,7 @@ static void add_path(struct strbuf *out, const char *path)
if (is_absolute_path(path))
strbuf_addstr(out, path);
else
- strbuf_addstr(out, make_absolute_path(path));
+ strbuf_addstr(out, make_nonrelative_path(path));
strbuf_addch(out, PATH_SEP);
}
diff --git a/path.c b/path.c
index 504eae0..9df447b 100644
--- a/path.c
+++ b/path.c
@@ -291,42 +291,6 @@ int adjust_shared_perm(const char *path)
return 0;
}
-static const char *get_pwd_cwd(void)
-{
- static char cwd[PATH_MAX + 1];
- char *pwd;
- struct stat cwd_stat, pwd_stat;
- if (getcwd(cwd, PATH_MAX) == NULL)
- return NULL;
- pwd = getenv("PWD");
- if (pwd && strcmp(pwd, cwd)) {
- stat(cwd, &cwd_stat);
- if (!stat(pwd, &pwd_stat) &&
- pwd_stat.st_dev == cwd_stat.st_dev &&
- pwd_stat.st_ino == cwd_stat.st_ino) {
- strlcpy(cwd, pwd, PATH_MAX);
- }
- }
- return cwd;
-}
-
-const char *make_nonrelative_path(const char *path)
-{
- static char buf[PATH_MAX + 1];
-
- if (is_absolute_path(path)) {
- if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX)
- die ("Too long path: %.*s", 60, path);
- } else {
- const char *cwd = get_pwd_cwd();
- if (!cwd)
- die("Cannot determine the current working directory");
- if (snprintf(buf, PATH_MAX, "%s/%s", cwd, path) >= PATH_MAX)
- die ("Too long path: %.*s", 60, path);
- }
- return buf;
-}
-
const char *make_relative_path(const char *abs, const char *base)
{
static char buf[PATH_MAX + 1];
--
1.6.0.rc0.18.g6aef2
^ permalink raw reply related
* [PATCH 5/9] Allow the built-in exec path to be relative to the command invocation path
From: Johannes Sixt @ 2008-07-21 19:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <1216667998-8879-5-git-send-email-johannes.sixt@telecom.at>
If $(gitexecdir) is relative, it is interpreted relative to the command's
invocation path, which usually is $(bindir).
The Makefile rules were written with the assumption that $(gitexecdir) is
an absolute path. We introduce a separate variable that names the
(absolute) installation directory.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
Makefile | 16 ++++++++++++----
exec_cmd.c | 38 ++------------------------------------
2 files changed, 14 insertions(+), 40 deletions(-)
diff --git a/Makefile b/Makefile
index 23f2185..908c1cb 100644
--- a/Makefile
+++ b/Makefile
@@ -1316,10 +1316,18 @@ template_instdir = $(template_dir)
endif
export template_instdir
+ifeq ($(firstword $(subst /, ,$(gitexecdir))),..)
+gitexec_instdir = $(bindir)/$(gitexecdir)
+else
+gitexec_instdir = $(gitexecdir)
+endif
+gitexec_instdir_SQ = $(subst ','\'',$(gitexec_instdir))
+export gitexec_instdir
+
install: all
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
- $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexecdir_SQ)'
- $(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
+ $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
+ $(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
$(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X '$(DESTDIR_SQ)$(bindir_SQ)'
$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
@@ -1328,10 +1336,10 @@ ifndef NO_TCLTK
$(MAKE) -C git-gui install
endif
ifneq (,$X)
- $(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';)
+ $(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p';)
endif
bindir=$$(cd '$(DESTDIR_SQ)$(bindir_SQ)' && pwd) && \
- execdir=$$(cd '$(DESTDIR_SQ)$(gitexecdir_SQ)' && pwd) && \
+ execdir=$$(cd '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' && pwd) && \
if test "z$$bindir" != "z$$execdir"; \
then \
ln -f "$$bindir/git$X" "$$execdir/git$X" || \
diff --git a/exec_cmd.c b/exec_cmd.c
index 45f92eb..c236034 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -7,40 +7,6 @@ extern char **environ;
static const char *argv_exec_path;
static const char *argv0_path;
-static const char *builtin_exec_path(void)
-{
-#ifndef __MINGW32__
- return GIT_EXEC_PATH;
-#else
- int len;
- char *p, *q, *sl;
- static char *ep;
- if (ep)
- return ep;
-
- len = strlen(_pgmptr);
- if (len < 2)
- return ep = ".";
-
- p = ep = xmalloc(len+1);
- q = _pgmptr;
- sl = NULL;
- /* copy program name, turn '\\' into '/', skip last part */
- while ((*p = *q)) {
- if (*q == '\\' || *q == '/') {
- *p = '/';
- sl = p;
- }
- p++, q++;
- }
- if (sl)
- *sl = '\0';
- else
- ep[0] = '.', ep[1] = '\0';
- return ep;
-#endif
-}
-
const char *system_path(const char *path)
{
if (!is_absolute_path(path) && argv0_path) {
@@ -75,7 +41,7 @@ const char *git_exec_path(void)
return env;
}
- return builtin_exec_path();
+ return system_path(GIT_EXEC_PATH);
}
static void add_path(struct strbuf *out, const char *path)
@@ -99,7 +65,7 @@ void setup_path(void)
add_path(&new_path, argv_exec_path);
add_path(&new_path, getenv(EXEC_PATH_ENVIRONMENT));
- add_path(&new_path, builtin_exec_path());
+ add_path(&new_path, system_path(GIT_EXEC_PATH));
add_path(&new_path, argv0_path);
if (old_path)
--
1.6.0.rc0.18.g6aef2
^ permalink raw reply related
* [PATCH 3/9] Record the command invocation path early
From: Johannes Sixt @ 2008-07-21 19:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <1216667998-8879-3-git-send-email-johannes.sixt@telecom.at>
We will need the command invocation path in system_path(). This path was
passed to setup_path(), but system_path() can be called earlier, for
example via:
main
commit_pager_choice
setup_pager
git_config
git_etc_gitconfig
system_path
Therefore, we introduce git_set_argv0_path() and call it as soon as
possible.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
exec_cmd.c | 10 ++++++++--
exec_cmd.h | 3 ++-
git.c | 5 ++---
receive-pack.c | 2 +-
shell.c | 4 ++--
upload-pack.c | 2 +-
6 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index 8899e31..dedb01d 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -5,6 +5,7 @@
extern char **environ;
static const char *argv_exec_path;
+static const char *argv0_path;
static const char *builtin_exec_path(void)
{
@@ -50,6 +51,11 @@ const char *system_path(const char *path)
return path;
}
+void git_set_argv0_path(const char *path)
+{
+ argv0_path = path;
+}
+
void git_set_argv_exec_path(const char *exec_path)
{
argv_exec_path = exec_path;
@@ -84,7 +90,7 @@ static void add_path(struct strbuf *out, const char *path)
}
}
-void setup_path(const char *cmd_path)
+void setup_path(void)
{
const char *old_path = getenv("PATH");
struct strbuf new_path;
@@ -94,7 +100,7 @@ void setup_path(const char *cmd_path)
add_path(&new_path, argv_exec_path);
add_path(&new_path, getenv(EXEC_PATH_ENVIRONMENT));
add_path(&new_path, builtin_exec_path());
- add_path(&new_path, cmd_path);
+ add_path(&new_path, argv0_path);
if (old_path)
strbuf_addstr(&new_path, old_path);
diff --git a/exec_cmd.h b/exec_cmd.h
index 7eb94e5..0c46cd5 100644
--- a/exec_cmd.h
+++ b/exec_cmd.h
@@ -2,8 +2,9 @@
#define GIT_EXEC_CMD_H
extern void git_set_argv_exec_path(const char *exec_path);
+extern void git_set_argv0_path(const char *path);
extern const char* git_exec_path(void);
-extern void setup_path(const char *);
+extern void setup_path(void);
extern int execv_git_cmd(const char **argv); /* NULL terminated */
extern int execl_git_cmd(const char *cmd, ...);
extern const char *system_path(const char *path);
diff --git a/git.c b/git.c
index 74ea0e6..9c0dd88 100644
--- a/git.c
+++ b/git.c
@@ -418,7 +418,6 @@ int main(int argc, const char **argv)
{
const char *cmd = argv[0] && *argv[0] ? argv[0] : "git-help";
char *slash = (char *)cmd + strlen(cmd);
- const char *cmd_path = NULL;
int done_alias = 0;
/*
@@ -431,7 +430,7 @@ int main(int argc, const char **argv)
while (cmd <= slash && !is_dir_sep(*slash));
if (cmd <= slash) {
*slash++ = 0;
- cmd_path = cmd;
+ git_set_argv0_path(cmd);
cmd = slash;
}
@@ -475,7 +474,7 @@ int main(int argc, const char **argv)
* environment, and the $(gitexecdir) from the Makefile at build
* time.
*/
- setup_path(cmd_path);
+ setup_path();
while (1) {
/* See if it's an internal command */
diff --git a/receive-pack.c b/receive-pack.c
index fa653b4..d44c19e 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -482,7 +482,7 @@ int main(int argc, char **argv)
if (!dir)
usage(receive_pack_usage);
- setup_path(NULL);
+ setup_path();
if (!enter_repo(dir, 0))
die("'%s': unable to chdir or not a git archive", dir);
diff --git a/shell.c b/shell.c
index 91ca7de..6a48de0 100644
--- a/shell.c
+++ b/shell.c
@@ -15,7 +15,7 @@ static int do_generic_cmd(const char *me, char *arg)
{
const char *my_argv[4];
- setup_path(NULL);
+ setup_path();
if (!arg || !(arg = sq_dequote(arg)))
die("bad argument");
if (prefixcmp(me, "git-"))
@@ -37,7 +37,7 @@ static int do_cvs_cmd(const char *me, char *arg)
if (!arg || strcmp(arg, "server"))
die("git-cvsserver only handles server: %s", arg);
- setup_path(NULL);
+ setup_path();
return execv_git_cmd(cvsserver_argv);
}
diff --git a/upload-pack.c b/upload-pack.c
index 9f82941..c911e70 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -638,7 +638,7 @@ int main(int argc, char **argv)
if (i != argc-1)
usage(upload_pack_usage);
- setup_path(NULL);
+ setup_path();
dir = argv[i];
--
1.6.0.rc0.18.g6aef2
^ permalink raw reply related
* [PATCH 4/9] Fix relative built-in paths to be relative to the command invocation
From: Johannes Sixt @ 2008-07-21 19:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <1216667998-8879-4-git-send-email-johannes.sixt@telecom.at>
$(gitexecdir) (as defined in the Makefile) has gained another path
component, but the relative paths in the MINGW section of the Makefile,
which are interpreted relative to it, do not account for it.
Instead of adding another ../ in front of the path, we change the code that
constructs the absolute paths to do it relative to the command's directory,
which is essentially $(bindir). We do it this way because we will also
allow a relative $(gitexecdir) later.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
Makefile | 2 +-
exec_cmd.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 226dd03..23f2185 100644
--- a/Makefile
+++ b/Makefile
@@ -1310,7 +1310,7 @@ remove-dashes:
### Installation rules
ifeq ($(firstword $(subst /, ,$(template_dir))),..)
-template_instdir = $(gitexecdir)/$(template_dir)
+template_instdir = $(bindir)/$(template_dir)
else
template_instdir = $(template_dir)
endif
diff --git a/exec_cmd.c b/exec_cmd.c
index dedb01d..45f92eb 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -43,9 +43,9 @@ static const char *builtin_exec_path(void)
const char *system_path(const char *path)
{
- if (!is_absolute_path(path)) {
+ if (!is_absolute_path(path) && argv0_path) {
struct strbuf d = STRBUF_INIT;
- strbuf_addf(&d, "%s/%s", git_exec_path(), path);
+ strbuf_addf(&d, "%s/%s", argv0_path, path);
path = strbuf_detach(&d, NULL);
}
return path;
--
1.6.0.rc0.18.g6aef2
^ permalink raw reply related
* [PATCH 0/9] Make gitexecdir relative to $(bindir) on Windows
From: Johannes Sixt @ 2008-07-21 19:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
This is a revival of the series of a week or so ago.
I found a workaround for the problem that made me abondon the effort.
The problem was that argv[0] does not have a path in certain cases.
The workaround is in 8/9, namely to redefine main() and replace
argv[0] by the value of _pgmptr that the C runtime on Windows provides
and that always has a full path.
Steffen has suggested not to the path discovery for 'git-*' programs.
No change is necessary to do that because programs with a 'git-' prefix
already take the path via handle_internal_command() early.
9/9 actually is off-topic, but it depends on 2/9 because it replaces
the instance of git-shell in the ./check_bindir line by git-add. If
you think it's worthwhile, you could squash this hunk into 2/9.
I'll follow-up with 10/9, which is git-gui specific.
Johannes Sixt (9):
Makefile: Do not install a copy of 'git' in $(gitexecdir)
Makefile: Normalize $(bindir) and $(gitexecdir) before comparing
Record the command invocation path early
Fix relative built-in paths to be relative to the command invocation
Allow the built-in exec path to be relative to the command invocation
path
Allow add_path() to add non-existent directories to the path
Windows: Make $(gitexecdir) relative
Windows: Make sure argv[0] has a path
Windows: Do not compile git-shell
Makefile | 38 ++++++++++++++++++++++++--------------
abspath.c | 36 ++++++++++++++++++++++++++++++++++++
compat/mingw.h | 12 ++++++++++++
exec_cmd.c | 54 +++++++++++++-----------------------------------------
exec_cmd.h | 3 ++-
git.c | 5 ++---
path.c | 36 ------------------------------------
receive-pack.c | 2 +-
shell.c | 4 ++--
upload-pack.c | 2 +-
10 files changed, 93 insertions(+), 99 deletions(-)
^ permalink raw reply
* [PATCH 2/9] Makefile: Normalize $(bindir) and $(gitexecdir) before comparing
From: Johannes Sixt @ 2008-07-21 19:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <1216667998-8879-2-git-send-email-johannes.sixt@telecom.at>
The install target needs to check whether the user has opted to make
$(gitexecdir) equal to $(bindir). It did so by a straight string
comparison. Since we are going to allow a relative $(gitexecdir), we have
to normalize paths before comparison, which we do with $(cd there && pwd).
The normalized paths are stored in shell variables. These we can now
reuse in the subsequent install statements, which conveniently shortens
the lines a bit.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
Makefile | 20 ++++++++++----------
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/Makefile b/Makefile
index cbab4f9..226dd03 100644
--- a/Makefile
+++ b/Makefile
@@ -1327,19 +1327,19 @@ ifndef NO_TCLTK
$(MAKE) -C gitk-git install
$(MAKE) -C git-gui install
endif
- if test 'z$(bindir_SQ)' != 'z$(gitexecdir_SQ)'; \
- then \
- ln -f '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \
- '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' || \
- cp '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \
- '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'; \
- fi
- $(foreach p,$(BUILT_INS), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
- $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'
ifneq (,$X)
$(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';)
endif
- ./check_bindir 'z$(bindir_SQ)' 'z$(gitexecdir_SQ)' '$(DESTDIR_SQ)$(bindir_SQ)/git-shell$X'
+ bindir=$$(cd '$(DESTDIR_SQ)$(bindir_SQ)' && pwd) && \
+ execdir=$$(cd '$(DESTDIR_SQ)$(gitexecdir_SQ)' && pwd) && \
+ if test "z$$bindir" != "z$$execdir"; \
+ then \
+ ln -f "$$bindir/git$X" "$$execdir/git$X" || \
+ cp "$$bindir/git$X" "$$execdir/git$X"; \
+ fi && \
+ { $(foreach p,$(BUILT_INS), $(RM) "$$execdir/$p" && ln "$$execdir/git$X" "$$execdir/$p" ;) } && \
+ $(RM) "$$execdir/git$X" && \
+ ./check_bindir "z$$bindir" "z$$execdir" "$$bindir/git-shell$X"
install-doc:
$(MAKE) -C Documentation install
--
1.6.0.rc0.18.g6aef2
^ permalink raw reply related
* [PATCH 1/9] Makefile: Do not install a copy of 'git' in $(gitexecdir)
From: Johannes Sixt @ 2008-07-21 19:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <1216667998-8879-1-git-send-email-johannes.sixt@telecom.at>
There is already a copy in $(bindir). A subsequent patch will enable git
to derive the exec-path from its invocation path. If git is invoked
recursively, the first invocation puts the exec-path into PATH, so that
the recursive invocation would find the instance in the exec-path. This
second instance would again try to derive an exec-path from its invocation
path, but would base its result on the wrong "bindir".
We do install the copy of git first, but remove it later, so that we can
use it as the source of the hardlinks for the builtins.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
Makefile | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 551bde9..cbab4f9 100644
--- a/Makefile
+++ b/Makefile
@@ -1335,6 +1335,7 @@ endif
'$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'; \
fi
$(foreach p,$(BUILT_INS), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
+ $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'
ifneq (,$X)
$(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';)
endif
--
1.6.0.rc0.18.g6aef2
^ permalink raw reply related
* Re: [PATCH] parse-options: fix segmentation fault when a required value is missing
From: Pierre Habouzit @ 2008-07-21 19:07 UTC (permalink / raw)
To: Olivier Marin; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <4884D5CC.2070007@free.fr>
[-- Attachment #1: Type: text/plain, Size: 1411 bytes --]
On Mon, Jul 21, 2008 at 06:30:36PM +0000, Olivier Marin wrote:
> From: Olivier Marin <dkr@freesurf.fr>
>
> p->argc represent the number of arguments that have not been parsed yet,
> _including_ the one we are currently parsing. If it is not greater than
> one then there is no more argument.
>
> Signed-off-by: Olivier Marin <dkr@freesurf.fr>
Acked-by: Pierre Habouzit <madcoder@debian.org>
> ---
> I hope this is the right fix.
>
> parse-options.c | 2 +-
> t/t0040-parse-options.sh | 7 +++++++
> 2 files changed, 8 insertions(+), 1 deletions(-)
>
> diff --git a/parse-options.c b/parse-options.c
> index 987b015..71a7acf 100644
> --- a/parse-options.c
> +++ b/parse-options.c
> @@ -22,7 +22,7 @@ static int get_arg(struct parse_opt_ctx_t *p, const struct option *opt,
> p->opt = NULL;
> } else if (p->argc == 1 && (opt->flags & PARSE_OPT_LASTARG_DEFAULT)) {
> *arg = (const char *)opt->defval;
> - } else if (p->argc) {
> + } else if (p->argc > 1) {
> p->argc--;
> *arg = *++p->argv;
> } else
Gasp thanks, Junio pointed it to me already, and for some reason this
hasn't made it.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: making a branch with just one file and keeping its whole history
From: Johannes Schindelin @ 2008-07-21 18:39 UTC (permalink / raw)
To: Eric Raible; +Cc: git
In-Reply-To: <279b37b20807211122w3a1e0687wc84693bd95689326@mail.gmail.com>
Hi,
On Mon, 21 Jul 2008, Eric Raible wrote:
> On Mon, Jul 21, 2008 at 11:08 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Mon, 21 Jul 2008, Eric Raible wrote:
> >
> >> http://www.gitcasts.com/posts/empty-branches
> >
> > Beware! This is one of the sites that triggered my mail about considering
> > teaching plumbing to new users harmful.
> >
> > In other words, I think that these "git casts" are not really the best way
> > to teach Git to new users, but rather confusing.
> >
> > Which is a pity, because they are nicely done otherwise.
>
> I understand your concern, but if you treat that particular gitcast
> simple as a recipe to be followed it accomplishes the goal in the in the
> most straightforward way I've seen.
Note, I haven't even bothered to watch that Gitcast, since it would make
me mad again.
> A new-user pure-porcelain way would be to branch then delete all of the
> files in the branch. Which seems a bit dirty to me.
This will not start a new branch, which is what I presume you want to do.
The "correct" (as in: probably the best) way to do it is to make a new
directory, initialize a new git repository in it, and when you have
something, push that branch into the other repository.
However, I think that the OP was talking about something completely
different: extracting the history of a single file as a new branch.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] parse-options: fix segmentation fault when a required value is missing
From: Olivier Marin @ 2008-07-21 18:30 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Junio C Hamano, Git Mailing List
From: Olivier Marin <dkr@freesurf.fr>
p->argc represent the number of arguments that have not been parsed yet,
_including_ the one we are currently parsing. If it is not greater than
one then there is no more argument.
Signed-off-by: Olivier Marin <dkr@freesurf.fr>
---
I hope this is the right fix.
parse-options.c | 2 +-
t/t0040-parse-options.sh | 7 +++++++
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/parse-options.c b/parse-options.c
index 987b015..71a7acf 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -22,7 +22,7 @@ static int get_arg(struct parse_opt_ctx_t *p, const struct option *opt,
p->opt = NULL;
} else if (p->argc == 1 && (opt->flags & PARSE_OPT_LASTARG_DEFAULT)) {
*arg = (const char *)opt->defval;
- } else if (p->argc) {
+ } else if (p->argc > 1) {
p->argc--;
*arg = *++p->argv;
} else
diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
index 6309aed..03dbe00 100755
--- a/t/t0040-parse-options.sh
+++ b/t/t0040-parse-options.sh
@@ -78,6 +78,13 @@ test_expect_success 'long options' '
test_cmp expect output
'
+test_expect_success 'missing required value' '
+ test-parse-options -s;
+ test $? = 129 &&
+ test-parse-options --string;
+ test $? = 129
+'
+
cat > expect << EOF
boolean: 1
integer: 13
--
1.6.0.rc0.1.g75f42
^ permalink raw reply related
* [PATCH] bring description of git diff --cc up to date
From: Jonathan Nieder @ 2008-07-21 18:27 UTC (permalink / raw)
To: git; +Cc: David Greaves
In February 2006 [1], the behavior of diff --cc was changed to
fit a more appropriate notion of "interesting hunks" in Octopus
merges. This patch updates documentation accordingly.
[1] commit bf1c32bdec8223785c779779d0a660a099f69a63
combine-diff: update --cc "uninteresting hunks" logic
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
---
Hello, all. A while ago when someone was asking about the diff
--cc output, I noticed some mistakes in the documentation but
never got around to fixing them. So here's a small fix. After
this patch, many issues remain:
- The user would usually look to git-diff(1) or git-log(1) for
an explanation of the --cc option, not git-diff-tree(1) or
git-rev-list(1).
- diff-format.txt contains the cryptic text "Note that
'combined diff' lists only files which were modified from
all parents." I have no idea what that means.
- There is some duplication of text between git-diff-tree(1)
and git-rev-list(1) here. I don't think that's such a big
deal, though.
- My proposed text here is not very intuitive or clear, and it
does not suggest very strongly what --cc is intended to do
(to point out "evil merges" and other merges where the
integrator is likely to have made a mistake). Alternate
wordings welcome!
At least this patch would not makes matters worse.
Documentation/git-diff-tree.txt | 12 +++++++-----
Documentation/rev-list-options.txt | 9 +++++----
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
index 0e45b58..5a81d5d 100644
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -92,12 +92,14 @@ include::pretty-options.txt[]
--cc::
This flag changes the way a merge commit patch is displayed,
in a similar way to the '-c' option. It implies the '-c'
- and '-p' options and further compresses the patch output
- by omitting hunks that show differences from only one
- parent, or show the same change from all but one parent
- for an Octopus merge. When this optimization makes all
+ and '-p' options and makes the patch output
+ even more compact by omitting uninteresting hunks. A hunk is
+ considered interesting only if either (a) it shows changes from
+ all parents or (b) in an Octopus merge, it shows different changes
+ from at least three different parents.
+ When this optimization makes all
hunks disappear, the commit itself and the commit log
- message is not shown, just like in any other "empty diff" case.
+ message are not shown, just like in any other "empty diff" case.
--always::
Show the commit itself and the commit log message even
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index b6f5d87..a399e2b 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -111,10 +111,11 @@ options may be given. See linkgit:git-diff-files[1] for more options.
--cc::
- This flag implies the '-c' options and further compresses the
- patch output by omitting hunks that show differences from only
- one parent, or show the same change from all but one parent for
- an Octopus merge.
+ This flag implies the '-c' option and makes the patch output
+ even more compact by omitting uninteresting hunks. A hunk is
+ considered interesting only if either (a) it shows changes from
+ all parents or (b) in an Octopus merge, it shows different changes
+ from at least three different parents.
-r::
--
1.5.6.3.549.g8ca11
^ permalink raw reply related
* Re: making a branch with just one file and keeping its whole history
From: Eric Raible @ 2008-07-21 18:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807211907270.8986@racer>
On Mon, Jul 21, 2008 at 11:08 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> On Mon, 21 Jul 2008, Eric Raible wrote:
>
>> http://www.gitcasts.com/posts/empty-branches
>
> Beware! This is one of the sites that triggered my mail about considering
> teaching plumbing to new users harmful.
>
> In other words, I think that these "git casts" are not really the best way
> to teach Git to new users, but rather confusing.
>
> Which is a pity, because they are nicely done otherwise.
>
> Ciao,
> Dscho
I understand your concern, but if you treat that particular gitcast
simple as a recipe to be followed it accomplishes the goal in the
in the most straightforward way I've seen.
A new-user pure-porcelain way would be to branch then delete all
of the files in the branch. Which seems a bit dirty to me.
Or is there some more intuitive porcelain-ish way of creating
a new empty branch that I haven't thought of?
- Eric
^ permalink raw reply
* Re: [PATCH] Fix update-index --refresh for submodules if stat(2) returns st_size 0
From: Johannes Schindelin @ 2008-07-21 18:20 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <20080721173511.GB5387@steel.home>
Hi,
On Mon, 21 Jul 2008, Alex Riesen wrote:
> For example - Cygwin.
Please enhance: your oneline is too long, and your commit message body too
short.
> Can MSys folks please try it? I noticed it when the test
> t2103-update-index-ignore-missing.sh (the 5th case) started failing.
Since M$' documentation says "This member does not have a meaning for
directories." about the member nFileSizeLow of WIN32_FILE_ATTRIBUTE_DATA
which we use to implement a sane "lstat()", I think this bug hits MinGW
(not MSys) as well.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] builtin-merge: missing structure bzero.
From: Pierre Habouzit @ 2008-07-21 18:18 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git, gitster
In-Reply-To: <20080721172119.GE32057@genesis.frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]
On Mon, Jul 21, 2008 at 05:21:19PM +0000, Miklos Vajna wrote:
> On Mon, Jul 21, 2008 at 07:03:50PM +0200, Pierre Habouzit <madcoder@debian.org> wrote:
> > This cause segfaults when replacing a directory with a submodule in a
> > fast-forward.
>
> Thanks.
>
> > +test_expect_failure 'Replace a directory with a submodule, with a file conflict' '
> > + mkdir test &&
> > + cd test &&
> > + : create our repository with a sub/a file &&
> > + git init &&
> > + mkdir sub && echo a > sub/a &&
> > + git add sub && git commit -asm"initial repository" &&
> > + : save this state in a new branch &&
> > + git branch temp &&
> > + : then replace sub with it &&
> > + git rm -rf sub &&
> > + git submodule add -- "$(pwd)/../submodule/.git/" sub &&
> > + git commit -asm "replace sub/ with a submodule" &&
> > + : then try to update the "temp" branch &&
> > + git checkout temp &&
>
> It seems this one fails. I guess this will be a problem in the low-level
> merge code (read-tree -m) and not in builtin-merge.
Yeah, I saw that afterwards, the error was misleading (as it tells
about some "merge" issue), but when I tried to debug it, it was indeed
in git checkout. The easiest way to reproduce, is to have a submodule
that replace a file that was previously versionned (which is something
that will happen in real life when you take out a subdirectory of a
project to make it live into a submodule) and that you then git checkout
HEAD~1.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 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