* Re: [PATCH] git-merge: do up-to-date check also for strategies ours, subtree.
From: Junio C Hamano @ 2007-08-10 8:51 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
In-Reply-To: <7vejibu69w.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Right now I do not have time to dig mailing list archive around
>> mid March 2006, and I do not recall the requestor's original
>> rationale, but I have a vague recollection that we added this
>> "no fast-forward check" specifically in response to a user
>> request.
>
> I do not think of a valid reason not to apply your patch. We
> wanted to avoid the trivial-merge codepath, but that is not a
> valid reason to record a fast forward situation as a merge of
> any kind.
Gaah. I take it back. At least, subtree _MUST_ not honor
fast-forward blindly. git-gui.git project is merged into
git.git with that strategy, but if I pull from Shawn once, and
then he has more updates while I do not have anything on my
tree, it will be a fast-forward. I should not be setting the
git.git tree to that of git-gui.git in such a case.
^ permalink raw reply
* [PATCH] git-apply: apply submodule changes
From: Sven Verdoolaege @ 2007-08-10 9:30 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Steffen Prohaska
Apply "Subproject commit HEX" changes produced by git-diff.
As usual in the current git, only the superproject itself is actually
modified (possibly creating empty directories for new submodules).
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
---
This also makes rebase handle submodules.
builtin-apply.c | 49 ++++++++++++++++++++++++++++++++++++++-----------
1 files changed, 38 insertions(+), 11 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index da27075..24df282 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -1984,6 +1984,26 @@ static int apply_fragments(struct buffer_desc *desc, struct patch *patch)
return 0;
}
+static int read_file_or_gitlink(struct cache_entry *ce, char **buf_p,
+ unsigned long *size_p)
+{
+ if (!ce)
+ return 0;
+
+ if (S_ISGITLINK(ntohl(ce->ce_mode))) {
+ *buf_p = xmalloc(100);
+ *size_p = snprintf(*buf_p, 100,
+ "Subproject commit %s\n", sha1_to_hex(ce->sha1));
+ } else {
+ enum object_type type;
+ *buf_p = read_sha1_file(ce->sha1, &type, size_p);
+ if (!*buf_p)
+ return -1;
+ }
+
+ return 0;
+}
+
static int apply_data(struct patch *patch, struct stat *st, struct cache_entry *ce)
{
char *buf;
@@ -1994,20 +2014,18 @@ static int apply_data(struct patch *patch, struct stat *st, struct cache_entry *
alloc = 0;
buf = NULL;
if (cached) {
- if (ce) {
- enum object_type type;
- buf = read_sha1_file(ce->sha1, &type, &size);
- if (!buf)
- return error("read of %s failed",
- patch->old_name);
- alloc = size;
- }
+ if (read_file_or_gitlink(ce, &buf, &size))
+ return error("read of %s failed", patch->old_name);
+ alloc = size;
}
else if (patch->old_name) {
size = xsize_t(st->st_size);
alloc = size + 8192;
buf = xmalloc(alloc);
- if (read_old_data(st, patch->old_name, &buf, &alloc, &size))
+ if (S_ISGITLINK(patch->old_mode))
+ size = snprintf(buf, alloc,
+ "Subproject commit %s\n", sha1_to_hex(ce->sha1));
+ else if (read_old_data(st, patch->old_name, &buf, &alloc, &size))
return error("read of %s failed", patch->old_name);
}
@@ -2098,7 +2116,7 @@ static int check_patch(struct patch *patch, struct patch *prev_patch)
}
if (!cached)
changed = ce_match_stat(ce, &st, 1);
- if (changed)
+ if (changed && !S_ISGITLINK(patch->old_mode))
return error("%s: does not match index",
old_name);
if (cached)
@@ -2387,7 +2405,9 @@ static void add_index_file(const char *path, unsigned mode, void *buf, unsigned
die("unable to stat newly created file %s", path);
fill_stat_cache_info(ce, &st);
}
- if (write_sha1_file(buf, size, blob_type, ce->sha1) < 0)
+ if (S_ISGITLINK(mode))
+ get_sha1_hex(buf + strlen("Subproject commit "), ce->sha1);
+ else if (write_sha1_file(buf, size, blob_type, ce->sha1) < 0)
die("unable to create backing store for newly created file %s", path);
if (add_cache_entry(ce, ADD_CACHE_OK_TO_ADD) < 0)
die("unable to add cache entry for %s", path);
@@ -2398,6 +2418,13 @@ static int try_create_file(const char *path, unsigned int mode, const char *buf,
int fd;
char *nbuf;
+ if (S_ISGITLINK(mode)) {
+ struct stat st;
+ if (!lstat(path, &st) && S_ISDIR(st.st_mode))
+ return 0;
+ return mkdir(path, 0777);
+ }
+
if (has_symlinks && S_ISLNK(mode))
/* Although buf:size is counted string, it also is NUL
* terminated.
--
1.5.3.rc4.29.g74276-dirty
^ permalink raw reply related
* Re: msysgit: does git gui work?
From: Johannes Schindelin @ 2007-08-10 10:16 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Marius Storm-Olsen, Git Mailing List, Shawn O. Pearce
In-Reply-To: <B6C82889-ABE0-4B3D-A455-A2EE1CE48297@zib.de>
Hi,
On Fri, 10 Aug 2007, Steffen Prohaska wrote:
> I recognized that '.' is included in the PATH in /etc/profile.
> I don't think this is a good idea. At least it bit me once when
> I expected to run /bin/git but instead /git/./git was chosen.
> Shouldn't we remove '.' from the PATH?
In my experience, Windows users (not Mac users forced to use Windows)
_expect_ "." to be in the PATH.
Regarding the tclsh thing: IMHO to unwaste space, we should add a
#!/bin/sh
exec tclsh84 "$@"
instead. MinGW does not have symlinks, and we should not put more space
to waste than Windows does already, by copying files around (yes, the
repository will not care, but the working tree will).
Ciao,
Dscho
^ permalink raw reply
* Re: msysgit: does git gui work?
From: Steffen Prohaska @ 2007-08-10 10:26 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <46BC1827.1060409@trolltech.com>
On Aug 10, 2007, at 9:47 AM, Marius Storm-Olsen wrote:
>
> I cherry-picked your patches into my local devel branch, but I
> still have issues with the version number being
> 1.5.3.rc2.690.g8ca1f6-dirty.
> (You mentioned that you also needed to change the Makefile to a
> different version numbering scheme, right?)
>
> So, your patches are still not enough to make it work out-of-box.
> I'll push your patches to the devel branch though, but won't move
> master until we have something which works. Ok?
Ok. If you tested with a dirty working tree you run into the
following problem. git-gui in msysgit doesn't understand
'-dirty' versions. You need to cherry pick from main git the
following commits:
2dfa54c6cb39c443652440f1ee6fdf5a6067364a git-gui: Skip -dirty suffix
on core git versions
ec4fceece4a9f155afcadec254caff5cef781c67 git-gui: Brown paper bag
"dirty git version fix"
btw, does someone know, where stderr of wish is piped to.
It doesn't appear on the mingw console, which makes debugging
more challenging.
Steffen
^ permalink raw reply
* Re: git on Cygwin: Not a valid object name HEAD
From: Johannes Schindelin @ 2007-08-10 10:30 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Torgil Svensson, Git Mailing List
In-Reply-To: <2383328F-300E-459C-A299-90242DA230F7@zib.de>
Hi,
On Fri, 10 Aug 2007, Steffen Prohaska wrote:
> On Aug 10, 2007, at 8:07 AM, Torgil Svensson wrote:
>
> > On 8/9/07, Steffen Prohaska <prohaska@zib.de> wrote:
> >
> > > Will all this run on Windows XP 64 bit and Windows Vista 64 bit?
> >
> > How fast can you type?
>
> I don't see your point. The question is if git runs flawlessly
> on 64 bit systems, which we use for development. I have no experience
> with mingw. Maybe there are some issues with 64 bit Windows, maybe
> not. But its a reasonable question?
It would be, if
- more people had 64-bit platforms to run on, and
- more people had Windows 64-bit.
Both cost money, so I suggest just trying it for yourself if you are one
of the few lucky ones being actually _able_ to test.
And no, I will not buy a Windows 64-bit just to test it for you.
> > Why does it have to be the _official_ repo? Git have submodule
> > support, so you could do a repo called
> > "my_excellent_git_environment_for_windows.git" and have the official
> > repo as submodule (msysgit is done this way).
>
> The official repo would indicate a real commitment to me that
> Windows support if officially maintained.
I cannot speak for others, of course, but this is a freeloader mentality I
do not want to support.
If you want first class Windows support, you'll have to pay for that,
methinks. And seeing all those less-than-even-lousy SCMs getting major
financial contributions to support their mediocrity, I do not see a reason
to get small amounts from private people, but rather substantial
money-flow from big companies.
Git is an excellent tool. If people want it badly enough, they should do
something for it.
> I agree that there may be more tools group around core git. But
> core git itself should be the master from the official repo.
> This seems to be a reasonable goal to me. At least that is what
> we do. The head must compile on all supported platforms
> out-of-the-box.
Guess why mingw.git is called a "fork"? It is _not good enough_ yet to be
included. Not necessarily function-wise, but definitely code-wise. We
have quite strict coding rules, being an Open Source project where
everybody can see your mess, should there be one.
It has _never_ been the plan to maintain mingw.git independently for
eternity. But the progress has been slow, and the _only_ reason that
there was any progress _at all_ was that Hannes stepped up, and did some
actual work instead of talking.
So yes, mingw.git's target destination is git.git.
Ciao,
Dscho
^ permalink raw reply
* Re: msysgit: does git gui work?
From: Steffen Prohaska @ 2007-08-10 10:51 UTC (permalink / raw)
To: Johannes Schindelin, Marius Storm-Olsen; +Cc: Git Mailing List, Shawn O. Pearce
In-Reply-To: <Pine.LNX.4.64.0708101113380.21857@racer.site>
On Aug 10, 2007, at 12:16 PM, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 10 Aug 2007, Steffen Prohaska wrote:
>
>> I recognized that '.' is included in the PATH in /etc/profile.
>> I don't think this is a good idea. At least it bit me once when
>> I expected to run /bin/git but instead /git/./git was chosen.
>> Shouldn't we remove '.' from the PATH?
>
> In my experience, Windows users (not Mac users forced to use Windows)
> _expect_ "." to be in the PATH.
Ah, what a crazy and dangerous world Windows is ;)
> Regarding the tclsh thing: IMHO to unwaste space, we should add a
>
> #!/bin/sh
> exec tclsh84 "$@"
>
> instead. MinGW does not have symlinks, and we should not put more
> space
> to waste than Windows does already, by copying files around (yes, the
> repository will not care, but the working tree will).
I agree and pushed the following to mob
faeb4e3df9fb7c853dd1a46d6942776d4a743545
I forced a non-fast-forward of mob. Is this ok? Apparently it's allowed.
Another question related to mob. How do I need to setup /git/.git/config
to be able to push to git's mob?
ssh://mob@repo.or.cz/srv/git/mingw/4msysgit.git
doesn't work for me.
Could the installer setup the mob branches? Or is this too dangerous?
At least it would help new developers to get going. It took me some time
to find the right setup for mob of msysgit and I was not able to set it
up for git. And I heard about the mob concept already before.
Steffen
^ permalink raw reply
* Re: git on Cygwin: Not a valid object name HEAD
From: Steffen Prohaska @ 2007-08-10 11:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Torgil Svensson, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0708101121240.21857@racer.site>
On Aug 10, 2007, at 12:30 PM, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 10 Aug 2007, Steffen Prohaska wrote:
>
>> On Aug 10, 2007, at 8:07 AM, Torgil Svensson wrote:
>>
>>> On 8/9/07, Steffen Prohaska <prohaska@zib.de> wrote:
>>>
>>>> Will all this run on Windows XP 64 bit and Windows Vista 64 bit?
>>>
>>> How fast can you type?
>>
>> I don't see your point. The question is if git runs flawlessly
>> on 64 bit systems, which we use for development. I have no experience
>> with mingw. Maybe there are some issues with 64 bit Windows, maybe
>> not. But its a reasonable question?
>
> It would be, if
>
> - more people had 64-bit platforms to run on, and
> - more people had Windows 64-bit.
>
> Both cost money, so I suggest just trying it for yourself if you
> are one
> of the few lucky ones being actually _able_ to test.
>
> And no, I will not buy a Windows 64-bit just to test it for you.
I'll try. I only asked if there is any experience on this. I didn't
ask you to test it for me.
>>> Why does it have to be the _official_ repo? Git have submodule
>>> support, so you could do a repo called
>>> "my_excellent_git_environment_for_windows.git" and have the official
>>> repo as submodule (msysgit is done this way).
>>
>> The official repo would indicate a real commitment to me that
>> Windows support if officially maintained.
>
> I cannot speak for others, of course, but this is a freeloader
> mentality I
> do not want to support.
>
> If you want first class Windows support, you'll have to pay for that,
> methinks. And seeing all those less-than-even-lousy SCMs getting
> major
> financial contributions to support their mediocrity, I do not see a
> reason
> to get small amounts from private people, but rather substantial
> money-flow from big companies.
>
> Git is an excellent tool. If people want it badly enough, they
> should do
> something for it.
You may have noticed that I'm willing to put some time into
it. I can't offer money. Time should be fine, too as you
state on msysgit's homepage
"Testing and reporting bugs is really already a big help.
Of course, it is even better if you get involved, for example
by hacking on mingw.git."
That is what I'm doing. You get bug reports and you get
patches. I don't understand your point about freeloader
mentality. In the long run it's just easier to keep functionality
in sync if it is maintained in a single repo, and this is what
you're basically also saying below.
>> I agree that there may be more tools group around core git. But
>> core git itself should be the master from the official repo.
>> This seems to be a reasonable goal to me. At least that is what
>> we do. The head must compile on all supported platforms
>> out-of-the-box.
>
> Guess why mingw.git is called a "fork"? It is _not good enough_
> yet to be
> included. Not necessarily function-wise, but definitely code-
> wise. We
> have quite strict coding rules, being an Open Source project where
> everybody can see your mess, should there be one.
Well and here, again, is my point of one single repo that officially
supports Windows. If the official support is part of the 'quite
strict coding' rules then I'm more convinced that Windows is
supported with appropriate quality. This is the point I want to make.
It has nothing to do with freeloader mentality.
> It has _never_ been the plan to maintain mingw.git independently for
> eternity. But the progress has been slow, and the _only_ reason that
> there was any progress _at all_ was that Hannes stepped up, and did
> some
> actual work instead of talking.
>
> So yes, mingw.git's target destination is git.git.
Good to hear. Again, I prefer to put work into pushing the merge
with git.git forward, than putting work into any fancy gui stuff,
as you proposed recently.
So if there's a list of todos that hinder a merge back to git.git,
I'd happy to learn about it.
Steffen
^ permalink raw reply
* Re: [PATCH] Reinstate the old behaviour when GIT_DIR is set and GIT_WORK_TREE is unset
From: Uwe Kleine-König @ 2007-08-10 11:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vr6mbu8iv.fsf_-_@assigned-by-dhcp.cox.net>
Hello Junio,
Junio C Hamano wrote:
> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Date: Sun, 5 Aug 2007 14:12:53 +0100
>
> The old behaviour was to unilaterally default to the cwd is the work tree
> when GIT_DIR was set, but GIT_WORK_TREE wasn't, no matter if we are inside
> the GIT_DIR, or if GIT_DIR is actually something like ../../../.git.
>
> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > I think I sent a patch for that, but was negative about it, even if I
> > promised not to question your decision.
>
> Yes you did. Here is a refresher with an affected test
> adjusted.
>
> We already have a few changes that worked around the semantics
> change by either setting GIT_WORK_TREE or cd'ing up, but I
> think they should not need to be reverted.
>
> It makes more sense to keep the old semantics -- people who use
> unusual GIT_DIR setting should know what they are doing, and
> the new GIT_WORK_TREE feature (and core.worktree) would give
> them better control. We just should not break existing users
> that set GIT_DIR and nothing else. Which means I need another
> rewrite on the Release Notes, and probably yet another rc
> cycle.
I don't know if you planed to make
git checkout-index --prefix=/tmp/tra -a
work (again) in a bare repo. Probably not, so it's no surprise that it
still doesn't work.
Best regards
Uwe
--
Uwe Kleine-König
cat /*dev/null; echo 'Hello World!';
cat > /dev/null <<*/
() { } int main() { printf("Hello World!\n");}
/* */
^ permalink raw reply
* Re: msysgit: does git gui work?
From: Alex Riesen @ 2007-08-10 11:40 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Steffen Prohaska, Marius Storm-Olsen, Git Mailing List,
Shawn O. Pearce
In-Reply-To: <Pine.LNX.4.64.0708101113380.21857@racer.site>
On 8/10/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Fri, 10 Aug 2007, Steffen Prohaska wrote:
>
> > I recognized that '.' is included in the PATH in /etc/profile.
> > I don't think this is a good idea. At least it bit me once when
> > I expected to run /bin/git but instead /git/./git was chosen.
> > Shouldn't we remove '.' from the PATH?
>
> In my experience, Windows users (not Mac users forced to use Windows)
> _expect_ "." to be in the PATH.
...because they _cannot_ know otherwise. In Windows, you cannot remove "."
from PATH, it is implicitly in it.
It is actually worse than that: the system directories are in PATH
too. Unconditionally.
Yes, the same system directories all them programs put their .exes into.
^ permalink raw reply
* Re: msysgit: does git gui work?
From: Johannes Schindelin @ 2007-08-10 12:13 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Marius Storm-Olsen, Git Mailing List, Shawn O. Pearce
In-Reply-To: <3351C69E-C0A8-4D02-9E04-085E18F1DF75@zib.de>
Hi,
On Fri, 10 Aug 2007, Steffen Prohaska wrote:
> On Aug 10, 2007, at 12:16 PM, Johannes Schindelin wrote:
>
> > On Fri, 10 Aug 2007, Steffen Prohaska wrote:
> >
> > > I recognized that '.' is included in the PATH in /etc/profile.
> > > I don't think this is a good idea. At least it bit me once when
> > > I expected to run /bin/git but instead /git/./git was chosen.
> > > Shouldn't we remove '.' from the PATH?
> >
> > In my experience, Windows users (not Mac users forced to use Windows)
> > _expect_ "." to be in the PATH.
>
> Ah, what a crazy and dangerous world Windows is ;)
Yes, and I'd rather not disappoint those expectations.
> > Regarding the tclsh thing: IMHO to unwaste space, we should add a
> >
> > #!/bin/sh
> > exec tclsh84 "$@"
> >
> > instead. MinGW does not have symlinks, and we should not put more space
> > to waste than Windows does already, by copying files around (yes, the
> > repository will not care, but the working tree will).
>
> I agree and pushed the following to mob
>
> faeb4e3df9fb7c853dd1a46d6942776d4a743545
>
> I forced a non-fast-forward of mob. Is this ok? Apparently it's allowed.
Yes, it is allowed exactly for this purpose. When you want to redo/undo
commits.
> Another question related to mob. How do I need to setup /git/.git/config
> to be able to push to git's mob?
My understanding is that the GitMe installer already sets up a remote
named "mob".
$ git push mob
It automatically pushes the "master" branch to "mob". If you have to
force the push, you'll have to do this:
$ git push mob +master:mob
But please avoid this when possible, since you might well overwrite other
people's work.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-apply: apply submodule changes
From: Johannes Schindelin @ 2007-08-10 12:34 UTC (permalink / raw)
To: Sven Verdoolaege; +Cc: Junio C Hamano, git, Steffen Prohaska
In-Reply-To: <20070810093049.GA868MdfPADPa@greensroom.kotnet.org>
Hi,
On Fri, 10 Aug 2007, Sven Verdoolaege wrote:
> Apply "Subproject commit HEX" changes produced by git-diff.
> As usual in the current git, only the superproject itself is actually
> modified (possibly creating empty directories for new submodules).
For rebase and cherry-pick, it would be nice if git just ignored the
changes in the submodules, provided that the submodule commit was not
affected by the to-be-applied patches.
Hmm?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-apply: apply submodule changes
From: Johannes Schindelin @ 2007-08-10 12:39 UTC (permalink / raw)
To: Sven Verdoolaege; +Cc: Junio C Hamano, git, Steffen Prohaska
In-Reply-To: <20070810093049.GA868MdfPADPa@greensroom.kotnet.org>
Hi,
On Fri, 10 Aug 2007, Sven Verdoolaege wrote:
> @@ -2387,7 +2405,9 @@ static void add_index_file(const char *path, unsigned mode, void *buf, unsigned
> die("unable to stat newly created file %s", path);
> fill_stat_cache_info(ce, &st);
> }
> - if (write_sha1_file(buf, size, blob_type, ce->sha1) < 0)
> + if (S_ISGITLINK(mode))
> + get_sha1_hex(buf + strlen("Subproject commit "), ce->sha1);
> + else if (write_sha1_file(buf, size, blob_type, ce->sha1) < 0)
> die("unable to create backing store for newly created file %s", path);
> if (add_cache_entry(ce, ADD_CACHE_OK_TO_ADD) < 0)
> die("unable to add cache entry for %s", path);
I guess that you need to catch an error from get_sha1_hex(), too.
I hope it is not to much to ask for a patch to t7400 to show what this
patch fixes?
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Fix handle leak in "git branch -D"
From: Alex Riesen @ 2007-08-10 13:06 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 372 bytes --]
On Windows (it can't touch open files in any way) the following fails:
git branch -D branch1 branch2
if the both branches are in packed-refs.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
refs.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
BTW, why does not commit_lock_file takes care of closing the file
opened by hold_lock_file_for_update?
[-- Attachment #2: 0001-Fix-handle-leak-in-git-branch-D.txt --]
[-- Type: text/plain, Size: 790 bytes --]
From 4e219bf5b2c7de091973336f6143f77fe9a96efc Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Fri, 10 Aug 2007 15:06:22 +0200
Subject: [PATCH] Fix handle leak in "git branch -D"
On Windows (it can't touch open files in any way) the following fails:
git branch -D branch1 branch2
if the both branches are in packed-refs.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
refs.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/refs.c b/refs.c
index fac6548..09a2c87 100644
--- a/refs.c
+++ b/refs.c
@@ -869,6 +869,7 @@ static int repack_without_ref(const char *refname)
die("too long a refname '%s'", list->name);
write_or_die(fd, line, len);
}
+ close(fd);
return commit_lock_file(&packlock);
}
--
1.5.3.rc4.81.gbd62
^ permalink raw reply related
* Re: git-gui console app ?
From: Jonas Fonseca @ 2007-08-10 13:31 UTC (permalink / raw)
To: Jeff King; +Cc: Erik Colson, git
In-Reply-To: <20070805101953.GI12507@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote Sun, Aug 05, 2007:
> On Sat, Aug 04, 2007 at 02:38:34PM +0200, Erik Colson wrote:
>
> > > By default, it will show the changes between your working tree and the
> > > index (i.e., changed but not updated). You can show the diff of "updated
> > > but not commited" with "git-diff --cached".
> >
> > yep that is the info I would like to browse in a way git-gui does it...
> > showing a list of the files in the diff, and letting the user select a
> > file to show the part of the diff for that file.
>
> Ah, I see. There is a status mode for tig (tig -S), but you can't jump
> to the diff of a particular file. It shouldn't be that difficult to add
> for somebody familiar with the tig codebase, but I am not such a
> somebody.
>
> Jonas, am I right that this should be a one-liner? If you can point me
> in the right direction, I can try to take a closer look, but I'm having
> trouble following the code.
Not quite a one-liner, but I've implemented something that will show
diffs of staged/unstaged changes as well as the content of untracked
files when pressing Enter on a file in the status view. To update the
status of a file (unstaged->staged, untracked->staged, etc) you now
have to press 'u'.
Hope this helps.
--
Jonas Fonseca
^ permalink raw reply
* Re: msysgit: does git gui work?
From: Steffen Prohaska @ 2007-08-10 13:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Marius Storm-Olsen, Git Mailing List, Shawn O. Pearce
In-Reply-To: <Pine.LNX.4.64.0708101309430.21857@racer.site>
On Aug 10, 2007, at 2:13 PM, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 10 Aug 2007, Steffen Prohaska wrote:
>
>> On Aug 10, 2007, at 12:16 PM, Johannes Schindelin wrote:
>>
>>> On Fri, 10 Aug 2007, Steffen Prohaska wrote:
>>
>> I agree and pushed the following to mob
>>
>> faeb4e3df9fb7c853dd1a46d6942776d4a743545
>>
>> I forced a non-fast-forward of mob. Is this ok? Apparently it's
>> allowed.
>
> Yes, it is allowed exactly for this purpose. When you want to redo/
> undo
> commits.
>
>> Another question related to mob. How do I need to setup /git/.git/
>> config
>> to be able to push to git's mob?
>
> My understanding is that the GitMe installer already sets up a remote
> named "mob".
>
> $ git push mob
>
> It automatically pushes the "master" branch to "mob". If you have to
> force the push, you'll have to do this:
>
> $ git push mob +master:mob
>
> But please avoid this when possible, since you might well overwrite
> other
> people's work.
I have a mob for /.git, but I do not have the setup for /git/.git. Maybe
I deleted it because I didn't understand what is means.
So, what is the right remote for pushing /git/.git?
Where is the mob branch for git://repo.or.cz/git/mingw/4msysgit.git/ ?
Whoever has setup the mob configurations, maybe it would be a good idea
to forbid non-fast-forward but instead allow the creation of new mob*
branches. If I can't push to mob, I could push to mob-topic instead.
Cleanup would be in the responsibility of the repository owner.
Steffen
^ permalink raw reply
* Re: msysgit: does git gui work?
From: Johannes Schindelin @ 2007-08-10 13:53 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Marius Storm-Olsen, Git Mailing List, Shawn O. Pearce
In-Reply-To: <31EFF30A-CC7A-4BB0-B083-13A1F7B62781@zib.de>
Hi,
On Fri, 10 Aug 2007, Steffen Prohaska wrote:
> On Aug 10, 2007, at 2:13 PM, Johannes Schindelin wrote:
>
> > On Fri, 10 Aug 2007, Steffen Prohaska wrote:
> >
> > > On Aug 10, 2007, at 12:16 PM, Johannes Schindelin wrote:
> > >
> > > > On Fri, 10 Aug 2007, Steffen Prohaska wrote:
> > >
> > > I agree and pushed the following to mob
> > >
> > > faeb4e3df9fb7c853dd1a46d6942776d4a743545
> > >
> > > I forced a non-fast-forward of mob. Is this ok? Apparently it's allowed.
> >
> > Yes, it is allowed exactly for this purpose. When you want to redo/undo
> > commits.
> >
> > > Another question related to mob. How do I need to setup /git/.git/config
> > > to be able to push to git's mob?
> >
> > My understanding is that the GitMe installer already sets up a remote
> > named "mob".
> >
> > $ git push mob
> >
> > It automatically pushes the "master" branch to "mob". If you have to
> > force the push, you'll have to do this:
> >
> > $ git push mob +master:mob
> >
> > But please avoid this when possible, since you might well overwrite other
> > people's work.
>
> I have a mob for /.git, but I do not have the setup for /git/.git. Maybe
> I deleted it because I didn't understand what is means.
Ah, I misunderstood. Yes, it is quite possible to have a mob installed
for 4msysgit.git by default. Should by done in
msysgit.git:share/GitMe/setup-msysgit.sh.
> Whoever has setup the mob configurations, maybe it would be a good idea
> to forbid non-fast-forward but instead allow the creation of new mob*
> branches. If I can't push to mob, I could push to mob-topic instead.
> Cleanup would be in the responsibility of the repository owner.
This is not possible. The refusal of a non-fast-forward is a per-repo,
not a per-user, configuration.
Ciao,
Dscho
^ permalink raw reply
* [PATCH resend] git-apply: apply submodule changes
From: Sven Verdoolaege @ 2007-08-10 13:57 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Steffen Prohaska, Johannes.Schindelin
In-Reply-To: <20070810093049.GA868MdfPADPa@greensroom.kotnet.org>
Apply "Subproject commit HEX" changes produced by git-diff.
As usual in the current git, only the superproject itself is actually
modified (possibly creating empty directories for new submodules).
Any checked-out submodule is left untouched and is not required to
be up-to-date.
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
---
This second version has a test and an extra sanity check.
I seem to be experiencing some problems receiving emails,
so I'll reply to a message from Dscho here.
Johannes Schindelin <Johannes.Schindelin <at> gmx.de> writes:
> For rebase and cherry-pick, it would be nice if git just ignored the
> changes in the submodules, provided that the submodule commit was not
> affected by the to-be-applied patches.
I have no idea what you mean.
The checked out copies of the submodules are ignored completely
(if that is what you were talking about, then I hope this issue
is clarified by the updated commit message). In the superproject,
the change to the submodule is obviously not ignored, since it's
an integral part of the patch. However, git-apply will fail if
the original submodule commit does not correspond exactly to the
"from-file" submodule commit.
I don't think there is anything else we can do without a true
recursive git-diff/git-apply.
skimo
builtin-apply.c | 50 ++++++++++++++++++++++++++++++++++---------
t/t7400-submodule-basic.sh | 8 +++++++
2 files changed, 47 insertions(+), 11 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index da27075..a38dbf1 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -1984,6 +1984,26 @@ static int apply_fragments(struct buffer_desc *desc, struct patch *patch)
return 0;
}
+static int read_file_or_gitlink(struct cache_entry *ce, char **buf_p,
+ unsigned long *size_p)
+{
+ if (!ce)
+ return 0;
+
+ if (S_ISGITLINK(ntohl(ce->ce_mode))) {
+ *buf_p = xmalloc(100);
+ *size_p = snprintf(*buf_p, 100,
+ "Subproject commit %s\n", sha1_to_hex(ce->sha1));
+ } else {
+ enum object_type type;
+ *buf_p = read_sha1_file(ce->sha1, &type, size_p);
+ if (!*buf_p)
+ return -1;
+ }
+
+ return 0;
+}
+
static int apply_data(struct patch *patch, struct stat *st, struct cache_entry *ce)
{
char *buf;
@@ -1994,20 +2014,18 @@ static int apply_data(struct patch *patch, struct stat *st, struct cache_entry *
alloc = 0;
buf = NULL;
if (cached) {
- if (ce) {
- enum object_type type;
- buf = read_sha1_file(ce->sha1, &type, &size);
- if (!buf)
- return error("read of %s failed",
- patch->old_name);
- alloc = size;
- }
+ if (read_file_or_gitlink(ce, &buf, &size))
+ return error("read of %s failed", patch->old_name);
+ alloc = size;
}
else if (patch->old_name) {
size = xsize_t(st->st_size);
alloc = size + 8192;
buf = xmalloc(alloc);
- if (read_old_data(st, patch->old_name, &buf, &alloc, &size))
+ if (S_ISGITLINK(patch->old_mode))
+ size = snprintf(buf, alloc,
+ "Subproject commit %s\n", sha1_to_hex(ce->sha1));
+ else if (read_old_data(st, patch->old_name, &buf, &alloc, &size))
return error("read of %s failed", patch->old_name);
}
@@ -2098,7 +2116,7 @@ static int check_patch(struct patch *patch, struct patch *prev_patch)
}
if (!cached)
changed = ce_match_stat(ce, &st, 1);
- if (changed)
+ if (changed && !S_ISGITLINK(patch->old_mode))
return error("%s: does not match index",
old_name);
if (cached)
@@ -2387,7 +2405,10 @@ static void add_index_file(const char *path, unsigned mode, void *buf, unsigned
die("unable to stat newly created file %s", path);
fill_stat_cache_info(ce, &st);
}
- if (write_sha1_file(buf, size, blob_type, ce->sha1) < 0)
+ if (S_ISGITLINK(mode)) {
+ if (get_sha1_hex(buf + strlen("Subproject commit "), ce->sha1))
+ die("corrupt patch for subproject %s", path);
+ } else if (write_sha1_file(buf, size, blob_type, ce->sha1) < 0)
die("unable to create backing store for newly created file %s", path);
if (add_cache_entry(ce, ADD_CACHE_OK_TO_ADD) < 0)
die("unable to add cache entry for %s", path);
@@ -2398,6 +2419,13 @@ static int try_create_file(const char *path, unsigned int mode, const char *buf,
int fd;
char *nbuf;
+ if (S_ISGITLINK(mode)) {
+ struct stat st;
+ if (!lstat(path, &st) && S_ISDIR(st.st_mode))
+ return 0;
+ return mkdir(path, 0777);
+ }
+
if (has_symlinks && S_ISLNK(mode))
/* Although buf:size is counted string, it also is NUL
* terminated.
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index e8ce7cd..cede2e7 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -175,4 +175,12 @@ test_expect_success 'checkout superproject with subproject already present' '
git-checkout master
'
+test_expect_success 'rebase with subproject changes' '
+ git-checkout initial &&
+ echo t > t &&
+ git add t &&
+ git-commit -m "change t" &&
+ git-rebase HEAD master
+'
+
test_done
--
1.5.3.rc4.29.g74276-dirty
^ permalink raw reply related
* Re: [PATCH] git-merge: do up-to-date check also for strategies ours, subtree.
From: Gerrit Pape @ 2007-08-10 13:58 UTC (permalink / raw)
To: git, Junio C Hamano
In-Reply-To: <7v3aysxvk3.fsf@assigned-by-dhcp.cox.net>
On Thu, Aug 09, 2007 at 02:11:24PM -0700, Junio C Hamano wrote:
> Right now I do not have time to dig mailing list archive around
> mid March 2006, and I do not recall the requestor's original
> rationale, but I have a vague recollection that we added this
> "no fast-forward check" specifically in response to a user
> request.
Hmm, I don't think my patch affects fast-forwards at all, it checks for
no_trivial_merge_strategies whether the remote, that should be merged,
has any commits that are not in the current head. If not, no merge
strategy should have to do anything.
The patch moves the first case switch at the third position. If, with
the patch, the first switch matches, it doesn't change behavior as it
does the same as the third; if the second switch matches, git-merge will
report 'Already up-to-date.' and exit.
This is with the patch:
$ (git init && touch foo && git add foo && git commit -m foo) >/dev/null
$ git checkout -b b
Switched to a new branch "b"
$ (touch bar && git add bar && git commit -m bar) >/dev/null
$ git checkout master
Switched to branch "master"
$ git merge b
Updating 769e777..8a03d99
Fast forward
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 bar
$ git reset --hard HEAD^
HEAD is now at 769e777... foo
$ git merge -s ours b
Merge made by ours.
$ git show
commit f0dc487c15e502bc7ee823b6907468eb78668dbb
Author: Gerrit Pape <pape@smarden.org>
Date: Fri Aug 10 13:44:10 2007 +0000
Merge branch 'b'
diff --git a/bar b/bar
deleted file mode 100644
index e69de29..0000000
$ git merge -s ours b
Already up-to-date.
$
Without the patch, the last command results in
$ git merge -s ours b
Merge made by ours.
$ git show
commit 21154261ff23f64fc38e8a2ae79c7a1cccaeacd4
Author: Gerrit Pape <pape@smarden.org>
Date: Fri Aug 10 13:48:54 2007 +0000
Merge branch 'b'
$
Regards, Gerrit.
^ permalink raw reply
* [PATCH] git-filter-branch.sh: Fix broken setting of GIT_DIR
From: David Kastrup @ 2007-08-10 14:02 UTC (permalink / raw)
To: git
If filter-branch is entered with an unset GIT_DIR, things are rather
fragile. The GIT_DIR variable setting then points to something like
$(pwd)/../.. which is neither guaranteed to be a git directory
(depends on where filter-branch is started), nor will it continue to
work once the temporary directory (for which the pwd is output) ceases
to exist.
So we just call git-name-rev in order to get the correct setting here
for exporting.
Signed-off-by: David Kastrup <dak@gnu.org>
---
git-filter-branch.sh | 12 ++++--------
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index b5fa449..6cd489e 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -170,14 +170,10 @@ do
esac
done < "$tempdir"/backup-refs
-case "$GIT_DIR" in
-/*)
- ;;
-*)
- GIT_DIR="$(pwd)/../../$GIT_DIR"
- ;;
-esac
-export GIT_DIR GIT_WORK_TREE=.
+GIT_DIR=$(cd ../..;git-name-rev --git-dir)
+GIT_WORK_TREE=.
+
+export GIT_DIR GIT_WORK_TREE
# These refs should be updated if their heads were rewritten
--
1.5.3.rc4.43.gaf14
^ permalink raw reply related
* Re: git-gui console app ?
From: Jeff King @ 2007-08-10 14:21 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Erik Colson, git
In-Reply-To: <20070810133132.GA3770@diku.dk>
On Fri, Aug 10, 2007 at 03:31:32PM +0200, Jonas Fonseca wrote:
> Not quite a one-liner, but I've implemented something that will show
> diffs of staged/unstaged changes as well as the content of untracked
> files when pressing Enter on a file in the status view. To update the
> status of a file (unstaged->staged, untracked->staged, etc) you now
> have to press 'u'.
Nice. This was exactly what I had envisioned. Minor help text fixup is
below.
-Peff
-- >8 --
status window: mention 'u' instead of Enter
Commits ca1d71ea and 89d917a bound the Enter functionality
to 'u' (and Enter now shows the diff).
Signed-off-by: Jeff King <peff@peff.net>
---
tig.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tig.c b/tig.c
index d9c9df8..40670e2 100644
--- a/tig.c
+++ b/tig.c
@@ -3156,15 +3156,15 @@ status_select(struct view *view, struct line *line)
switch (line->type) {
case LINE_STAT_STAGED:
- text = "Press Enter to unstage file for commit";
+ text = "Press 'u' to unstage file for commit";
break;
case LINE_STAT_UNSTAGED:
- text = "Press Enter to stage file for commit ";
+ text = "Press 'u' to stage file for commit ";
break;
case LINE_STAT_UNTRACKED:
- text = "Press Enter to stage file for addition";
+ text = "Press 'u' to stage file for addition";
break;
case LINE_STAT_NONE:
--
1.5.2.4
^ permalink raw reply related
* Re: git-gui console app ?
From: Erik Colson @ 2007-08-10 14:25 UTC (permalink / raw)
To: git
In-Reply-To: <20070810133132.GA3770@diku.dk>
On Fri, Aug 10, 2007 at 03:31:32PM +0200, Jonas Fonseca wrote:
> Not quite a one-liner, but I've implemented something that will show
> diffs of staged/unstaged changes as well as the content of untracked
> files when pressing Enter on a file in the status view. To update the
> status of a file (unstaged->staged, untracked->staged, etc) you now
> have to press 'u'.
>
> Hope this helps.
Works like a charm ! Thanks for the implementation. Btw, I'm using
git (and tig) on MacosX and got it compiled by using the same remarks
you mention for FreeBSD, so may be you could add this to the INSTALL
document...
--
Erik
^ permalink raw reply
* Re: git-p4 question
From: Govind Salinas @ 2007-08-10 15:17 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0708100110w6ff90215gd5c367fb65e2ae21@mail.gmail.com>
I am having some problems running the script. It seems that (line
1425) $f->{sha1} is uninitialized and causing the import to fail (the
perforce path is missing the leading "//" I don't know if that is
intentional). Let me know if you want to continue this off list since
it isn't really a part of git.
On 8/10/07, Alex Riesen <raa.lkml@gmail.com> wrote:
> On 8/10/07, Alex Riesen <raa.lkml@gmail.com> wrote:
> > On 8/10/07, Govind Salinas <govindsalinas@gmail.com> wrote:
> > > If I can just sync from p4 and then sync my binary share and THEN tell
> > > git-p4 that //depot/my/product/... maps to c:\path\src\realworkhere,
> > > get it to import history etc, then I would be set.
> >
> > git-p4-import.bat can import a state from the client have-list,
> > but it does not import the history. It can import the history
> > separately, so that you can stitch it into a merge which will be
> > the state imported from the client. Complicated, but I couldn't
> > bring myself to figure out the history automatically.
>
> Err, example:
>
> Import a state from p4 client:
>
> git-p4-import -y -c client-name -e
>
> Import p4 history of a path mapping:
>
> git-p4-import --p4-path //perforce/path \
> --local-path very-local-path \
> --p4-range '@1234,5678' \
> --start start-commit \
> --branch branch-name
>
> The last argument (--branch) is optional, will just store the last imported
> commit there. start-commit will be assumed current HEAD, if omitted.
>
^ permalink raw reply
* call external editor from git-gui?
From: Karl Hasselström @ 2007-08-10 15:30 UTC (permalink / raw)
To: git
git-gui is very good at composing commits. But for writing the actual
commit message -- especially if it's long and needs paragraph
reflowing, indentation, and so on -- I vastly prefer emacs over
git-gui's text field.
It seems to me like it would be straightforward to have a button or
something to launch the user's favorite editor for editing of the
commit message -- after all, git even knows what editor that is!
Unfortunately, with my tcl expertise, this is likely a whole-weekend
project, so I probably won't try to build it myself in the near
future.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Bug in gitk: can't unset "idinlist(...) ..."
From: Brian Hetro @ 2007-08-10 15:41 UTC (permalink / raw)
To: git
Hi,
I have a problem with gitk not being able to show one of my
repositories (git version 1.5.3.rc4.41.g7efe). I get this error while
gitk starts:
can't unset "idinlist(f1d795add789ec43d3ccf1d35f3c39fb464f6e72)": no
such element in array
can't unset "idinlist(f1d795add789ec43d3ccf1d35f3c39fb464f6e72)": no
such element in array
while executing
"unset idinlist($id)"
(procedure "layouttail" line 11)
invoked from within
"layouttail"
(procedure "layoutmore" line 35)
invoked from within
"layoutmore $tlimit $allread"
(procedure "chewcommits" line 9)
invoked from within
"chewcommits 1"
("eval" body line 1)
invoked from within
"eval $script"
(procedure "dorunq" line 9)
invoked from within
"dorunq"
("after" script)
The repository log is partially displayed. gitk does work in git
version 1.5.2.4, and qgit and giggle also work. git-fsck --full
--strict indicates no problems.
I performed a bisect and commit
1ed84157a21a3e868228b15588e4aadfbe5a030b appears to be the culprit
(Revert 88494423 (removal of duplicate parents in the output
codepath)).
Brian
^ permalink raw reply
* Re: git and larger trees, not so fast?
From: Linus Torvalds @ 2007-08-10 15:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sean, moe, git
In-Reply-To: <7vy7gkue5s.fsf@assigned-by-dhcp.cox.net>
On Thu, 9 Aug 2007, Junio C Hamano wrote:
>
> FWIW, moe's script with and without two patches gives these
> numbers for me.
Btw, I really think it's worth doing even just the hacky patches at this
stage, even though it's late in the game for 1.5.3.
That performance problem is serious enough that I'd call it a major bug.
Performance has always been one of the goals of git, and when you have a
difference between 17s and 0.7s for "git status", that's a *huge*
usability thing. It would be sad to release 1.5.3 with a known bug.
[ Some people don't think performance issues are "real bugs", and I think
such people shouldn't be allowed to program. ]
Side note: your first patch is actually quite noticeable on even just the
kernel. Not nearly as much, but without it, I get about 0.5s, and with it,
I get consistently under 0.3s. So it's about a 40% improvement even for
smaller projects (and it's probably much more if you have a CPU with a
smaller cache: my Core 2 Duo has 4MB of L2 cache, and a lot of the index
will even fit in the L1 - a slower CPU with less cache will see a bigger
impact, and with smaller repositories, from the unnecessary memory
moving).
While 0.5s -> 0.3s may not sound like much, on a slower machine where it
might otherwise be 2.5s -> 1.5s, that's likely to be quite noticeable.
In fact, I can tell even on my machine: 0.3s is visible as a "I'm clearly
thinking about it" delay (quite frankly, it would be better at 0.1s, which
is "immediate"), but 0.5s is already approaching the point where you
actually wait for the answer (rather than just notice that it wasn't quite
immediate).
Linus
^ 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