* Re: minor problems in git.c
From: Sven Verdoolaege @ 2005-12-01 13:51 UTC (permalink / raw)
To: Alex Riesen; +Cc: Robert Watson, git, Junio C Hamano
In-Reply-To: <81b0412b0512010448u7fcdddacnd7de5df217ab3ca@mail.gmail.com>
On Thu, Dec 01, 2005 at 01:48:35PM +0100, Alex Riesen wrote:
> @@ -283,16 +283,15 @@ int main(int argc, char **argv, char **e
> len = strlen(git_command);
> prepend_to_path(git_command, len);
>
> - strncat(&git_command[len], "/git-", sizeof(git_command) - len);
> - len += 5;
> - strncat(&git_command[len], argv[i], sizeof(git_command) - len);
> + snprintf(git_command + len, sizeof(git_command) - len, "/git-%s",
> + argv[i]);
Shouldn't you check the return value of snprintf
> if (access(git_command, X_OK))
> usage(exec_path, "'%s' is not a git-command", argv[i]);
or use the (possibly) truncated version of the command in the error message ?
skimo
^ permalink raw reply
* Re: unexpected EOF?
From: Tim O'Callaghan @ 2005-12-01 13:49 UTC (permalink / raw)
To: git
In-Reply-To: <E1EhohG-0001iZ-IB@jdl.com>
On Thu, Dec 01, 2005 at 07:42:02AM -0600, Jon Loeliger wrote:
>
> I thought I had imagined this last time, but now
> that it has happened twice, I'm not so sure what
> is going on. First pull attempt garners an
> unexpected EOF message; immediately pull again
> seems to work.
>
> Some state:
>
> jdl@ubuntu:/usr/src/git-core$ git --version
> git version 0.99.9j
>
> jdl@ubuntu:/usr/src/git-core$ cat .git/remotes/origin
> URL: git://git.kernel.org/pub/scm/git/git.git/
> Pull: master:origin
> Pull: todo:todo
> Pull: maint:maint
> Pull: pu:pu
>
> And the error capture:
>
> jdl@ubuntu:/usr/src/git-core$ git pull origin
> fatal: unexpected EOF
> Fetch failure: git://git.kernel.org/pub/scm/git/git.git/
> jdl@ubuntu:/usr/src/git-core$ git pull origin
> Unpacking 17 objects
> 100% (17/17) done
> * committish: d175455acaaba6bd39dd2d5ec71961bf238f06d4
> branch 'todo' of git://git.kernel.org/pub/scm/git/git
> * refs/heads/todo: same as branch 'todo' of git://git.kernel.org/pub/scm/git/git* committish: 93dcab2937624ebb97f91807576cddb242a55a46
> branch 'maint' of git://git.kernel.org/pub/scm/git/git
> * refs/heads/maint: same as branch 'maint' of git://git.kernel.org/pub/scm/git/git
> * committish: b34403aa97047f90c0cdd5177e63a8e7530e3388
> branch 'master' of git://git.kernel.org/pub/scm/git/git
> * refs/heads/origin: same as branch 'master' of git://git.kernel.org/pub/scm/git/git
> * committish: 6e35634a4d595d554423b04438bfa8b523414c54
> branch 'pu' of git://git.kernel.org/pub/scm/git/git
> * refs/heads/pu: does not fast forward to branch 'pu' of git://git.kernel.org/pub/scm/git/git;
> not updating.
> Already up-to-date.
I noticed this myself this morning. It happened twice, then after leaving it
for a minute or two, it worked. Possibly traffic problems to kernel.org?
I should also report that if a spurious lockfile exists (under cygwin at
least), git just dies with the cryptic "unable to create new cachefile".
Tim.
"I've worked myself up from nothing to a state of supreme poverty."
-- Groucho Marx
^ permalink raw reply
* unexpected EOF?
From: Jon Loeliger @ 2005-12-01 13:42 UTC (permalink / raw)
To: git
I thought I had imagined this last time, but now
that it has happened twice, I'm not so sure what
is going on. First pull attempt garners an
unexpected EOF message; immediately pull again
seems to work.
Some state:
jdl@ubuntu:/usr/src/git-core$ git --version
git version 0.99.9j
jdl@ubuntu:/usr/src/git-core$ cat .git/remotes/origin
URL: git://git.kernel.org/pub/scm/git/git.git/
Pull: master:origin
Pull: todo:todo
Pull: maint:maint
Pull: pu:pu
And the error capture:
jdl@ubuntu:/usr/src/git-core$ git pull origin
fatal: unexpected EOF
Fetch failure: git://git.kernel.org/pub/scm/git/git.git/
jdl@ubuntu:/usr/src/git-core$ git pull origin
Unpacking 17 objects
100% (17/17) done
* committish: d175455acaaba6bd39dd2d5ec71961bf238f06d4
branch 'todo' of git://git.kernel.org/pub/scm/git/git
* refs/heads/todo: same as branch 'todo' of git://git.kernel.org/pub/scm/git/git* committish: 93dcab2937624ebb97f91807576cddb242a55a46
branch 'maint' of git://git.kernel.org/pub/scm/git/git
* refs/heads/maint: same as branch 'maint' of git://git.kernel.org/pub/scm/git/git
* committish: b34403aa97047f90c0cdd5177e63a8e7530e3388
branch 'master' of git://git.kernel.org/pub/scm/git/git
* refs/heads/origin: same as branch 'master' of git://git.kernel.org/pub/scm/git/git
* committish: 6e35634a4d595d554423b04438bfa8b523414c54
branch 'pu' of git://git.kernel.org/pub/scm/git/git
* refs/heads/pu: does not fast forward to branch 'pu' of git://git.kernel.org/pub/scm/git/git;
not updating.
Already up-to-date.
^ permalink raw reply
* Re: [PROBE] cg-commit: show and enable editing of changes with --review
From: Jonas Fonseca @ 2005-12-01 13:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbr03564t.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote Tue, Nov 29, 2005:
> Jonas Fonseca <fonseca@diku.dk> writes:
>
> > Show changes being commited as a patch appended to the commit message
> > buffer. If the original patch is different from the patch extracted from
> > the commit message file the original patch will be reverted and the edited
> > patch applied before completing the commit.
> >
> > Due to limitations with cg-patch this can only be used when commiting
> > from the project root directory. The error handling if the either the
> > original patch or the edited patch does not apply is not optimal, since
> > cg-patch will not report errors properly.
>
> I do not do Porcelains,
I am curious since you have also used this phrase in the past: didn't
you do your own jit porcelain once and are you saying that git does not
ship with it's own porcelain?
> I am not a Cogito user, and I generally
> do not like encouraging people who are playing an individual
> developer role to commit something that has never existed in
> their working tree (hence by definition never been tested),
> but...
I see your point. I mostly intend to use it for fixing small typos in
comments and documentation. It can help to cure some "post-commit
stress". Also I hope you will agree that it is always a good idea to
review your changes one more time although I agree it might be a little
silly.
> > + echo "Updating changes to edited patch"
> > + # FIXME: Can only be run from the top level
> > + # FIXME: Is very 'fragile' error handling. We should probably
> > + # save the original patch in a local file for recovery?
> > + if ! cg-patch -R < $PATCH; then
> > + backup=$(mktemp commit-backup.XXXXXX)
> > + cp $PATCH $backup
> > + error_msg="unable to revert original patch, backup saved to $backup"
>
> I suspect at least you should be able to use checkout-index for
> the first one instead of cg-patch.
Oh, great, thanks. I guess I should work some more on the git docs to
get to know these kind of things.
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH] gitk: add Update menu item.
From: Sven Verdoolaege @ 2005-12-01 13:07 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Junio C Hamano, git
In-Reply-To: <17294.58317.317337.145932@cargo.ozlabs.ibm.com>
On Thu, Dec 01, 2005 at 10:51:41PM +1100, Paul Mackerras wrote:
> I put this in although I'm not completely happy with it (though it is
> a good step in the right direction).
Thanks. That's what it was meant to be (a step in the right direction).
> Why do we unset children and nchildren in the phase == updatecommits
> case? Wouldn't it give the same result if we set ncleft to nchildren
> for each commit and then we didn't call updatechildren in
> finishcommits? I think that would end up simpler.
Well, you probably know your own code better than I do,
but I'll have a look later.
> I tried removing some commits (using git reset --hard) and then doing
> selecting update from the menu, and it redrew everything, but the
> removed commits were still shown.
Hmmm... I'll have look at this over the weekend (unless you beat
me to it).
> Also, what will happen if the user selects update while gitk is still
> drawing the graph? I think that will cause havoc. At _best_ we'll
> end up with a truncated list of commits AFAICS. We need to make that
> robust.
Agreed. I hadn't thought a user would do that, but that was just
my lack of imagination.
skimo
^ permalink raw reply
* Re: [PATCH] Move couple of ifdefs after "include config.mk"
From: Alex Riesen @ 2005-12-01 12:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7japjf53.fsf@assigned-by-dhcp.cox.net>
On 12/1/05, Junio C Hamano <junkio@cox.net> wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
> > On 12/1/05, Junio C Hamano <junkio@cox.net> wrote:
> >> > I have even my specific targets in the config.mak (and would actually
> >> > like to have the default target put before including config.mak, so
> >> > default call to make is always the same).
>
> Hmph. Do you mean something like this?
>
> -- >8 --
> diff --git a/Makefile b/Makefile
> index 00521fe..45db357 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1,3 +1,6 @@
> +# The default target of this Makefile is...
> +all:
> +
Yes. In fact, that is what I have in my tree :)
^ permalink raw reply
* Re: minor problems in git.c
From: Alex Riesen @ 2005-12-01 12:48 UTC (permalink / raw)
To: Robert Watson; +Cc: git, Junio C Hamano
In-Reply-To: <72499e3b0512010400i1de76ed2la22cd745f811007f@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 386 bytes --]
On 12/1/05, Robert Watson <robert.oo.watson@gmail.com> wrote:
> There are some minor problems in git.c:
I had the following patches in my tree for some time. Even forgot
about them, sorry.
The second on top of the first.
- Use stderr for error output
- Build git_command more careful
- ENOENT is good enough for check of failed exec to show usage, no
access() check needed
[-- Attachment #2: 0001-used-stderr-for-error-output-and-build-git_command-more-careful.txt --]
[-- Type: text/plain, Size: 984 bytes --]
Use stderr for error output and build git_command more careful
---
git.c | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
081fc78a8c8e640420ac7e44d93a2a45246f5c2f
diff --git a/git.c b/git.c
index bdd3f8d..9468b58 100644
--- a/git.c
+++ b/git.c
@@ -283,16 +283,15 @@ int main(int argc, char **argv, char **e
len = strlen(git_command);
prepend_to_path(git_command, len);
- strncat(&git_command[len], "/git-", sizeof(git_command) - len);
- len += 5;
- strncat(&git_command[len], argv[i], sizeof(git_command) - len);
+ snprintf(git_command + len, sizeof(git_command) - len, "/git-%s",
+ argv[i]);
if (access(git_command, X_OK))
usage(exec_path, "'%s' is not a git-command", argv[i]);
/* execve() can only ever return if it fails */
execve(git_command, &argv[i], envp);
- printf("Failed to run command '%s': %s\n", git_command, strerror(errno));
+ fprintf(stderr, "git: '%s': %s\n", git_command, strerror(errno));
return 1;
}
--
0.99.9.GIT
[-- Attachment #3: 0002-ENOENT-is-good-enough-no-access-check-needed.txt --]
[-- Type: text/plain, Size: 855 bytes --]
ENOENT is good enough, no access() check needed
---
git.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
ac97adc8152a1e5ac78a03f218a3dab012bf8ba9
diff --git a/git.c b/git.c
index 9468b58..c8c2b4a 100644
--- a/git.c
+++ b/git.c
@@ -286,12 +286,12 @@ int main(int argc, char **argv, char **e
snprintf(git_command + len, sizeof(git_command) - len, "/git-%s",
argv[i]);
- if (access(git_command, X_OK))
- usage(exec_path, "'%s' is not a git-command", argv[i]);
-
/* execve() can only ever return if it fails */
execve(git_command, &argv[i], envp);
- fprintf(stderr, "git: '%s': %s\n", git_command, strerror(errno));
+ if ( ENOENT == errno )
+ usage(exec_path, "'%s' is not a git-command", argv[i]);
+ else
+ fprintf(stderr, "git: '%s': %s\n", git_command, strerror(errno));
return 1;
}
--
0.99.9.GIT
^ permalink raw reply related
* minor problems in git.c
From: Robert Watson @ 2005-12-01 12:00 UTC (permalink / raw)
To: git
Hi,
There are some minor problems in git.c:
(1) potential buffer overrun.
strncat(&git_command[len], "/git-", sizeof(git_command) - len);
len += 5;
strncat(&git_command[len], argv[i], sizeof(git_command) - len);
The first line will write one byte ('\0') beyond the end of
git_command, when sizeof(git_command) - len == 5.
The second line increase len by 5, without regarding how many bytes
are written in the first line. It is possible to make len greater
than sizeof(git_command), therefore make the third argument of the
third line underflow, allowing almost any number of bytes from argv[1]
to be copied.
(2) environ
int main(int argc, char **argv, char **envp)
{
...
execve(git_command, &argv[i], envp);
...
}
I am wondering whether the global variable "environ" could change when
you do setenv. Would it be clear by using the "environ" as the third
argument of evecve()?
(3) printf("Failed to run command '%s': %s\n", git_command, strerror(errno));
should go to stderr?
Regards,
Robertoo
^ permalink raw reply
* Re: [PATCH] gitk: add Update menu item.
From: Paul Mackerras @ 2005-12-01 11:51 UTC (permalink / raw)
To: skimo; +Cc: Junio C Hamano, git
In-Reply-To: <20051129211551.GF8383MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege writes:
> Update will redraw the commits if any commits have been added to any
> of the selected heads. The new commits appear on the top.
I put this in although I'm not completely happy with it (though it is
a good step in the right direction).
Why do we unset children and nchildren in the phase == updatecommits
case? Wouldn't it give the same result if we set ncleft to nchildren
for each commit and then we didn't call updatechildren in
finishcommits? I think that would end up simpler.
I tried removing some commits (using git reset --hard) and then doing
selecting update from the menu, and it redrew everything, but the
removed commits were still shown.
Also, what will happen if the user selects update while gitk is still
drawing the graph? I think that will cause havoc. At _best_ we'll
end up with a truncated list of commits AFAICS. We need to make that
robust.
Paul.
^ permalink raw reply
* Re: [PATCH] Move couple of ifdefs after "include config.mk"
From: Junio C Hamano @ 2005-12-01 10:16 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0512010153t3f768a82m8f9a12effa4a715e@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> On 12/1/05, Junio C Hamano <junkio@cox.net> wrote:
>> > I have even my specific targets in the config.mak (and would actually
>> > like to have the default target put before including config.mak, so
>> > default call to make is always the same).
Hmph. Do you mean something like this?
-- >8 --
diff --git a/Makefile b/Makefile
index 00521fe..45db357 100644
--- a/Makefile
+++ b/Makefile
@@ -1,3 +1,6 @@
+# The default target of this Makefile is...
+all:
+
# Define MOZILLA_SHA1 environment variable when running make to make use of
# a bundled SHA1 routine coming from Mozilla. It is GPL'd and should be fast
# on non-x86 architectures (e.g. PowerPC), while the OpenSSL version (default
^ permalink raw reply related
* Re: git-name-rev off-by-one bug
From: Junio C Hamano @ 2005-12-01 10:14 UTC (permalink / raw)
To: linux; +Cc: git, Petr Baudis
In-Reply-To: <20051128234256.1508.qmail@science.horizon.com>
linux@horizon.com writes:
> Anyway, if it's portable enough, it's faster. Ah... I just found discussion
> of this in late September, but it's not clear what the resolution was.
> http://marc.theaimsgroup.com/?t=112746188000003
Although updating our shell scripts to this century is lower on
my priority scale, ideally I'd want to see things work with
dash, not because I do not like bash/ksh, but because it seems
the smallest minimally POSIXy shell.
Speaking of shell gotchas, I do not know what the resolution was
on the problem Merlyn was having the other day in "lost again on
syntax change - local repository?" thread, which seemed that the
failure described in <868xv86dam.fsf@blue.stonehenge.com> was
his bash mishandling an if..then..elif..else..fi chain, which
was sort of unexpected for me. I was curious but do not
remember seeing the conclusion. Pasky, what happened to that
thread?
^ permalink raw reply
* Re: [PATCH] Move couple of ifdefs after "include config.mk"
From: Alex Riesen @ 2005-12-01 9:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viru9jgku.fsf@assigned-by-dhcp.cox.net>
On 12/1/05, Junio C Hamano <junkio@cox.net> wrote:
> > I have even my specific targets in the config.mak (and would actually
> > like to have the default target put before including config.mak, so
> > default call to make is always the same).
>
> Surely you can do that by having your own "makefile" and include
> "Makefile" I ship, and run "make", which prefers makefile over
> Makefile ;-).
But that is not the same:
- I can put my targets and variables either before or after Makefile,
not somewhere inbetween
- I have to work on an especially brain-damaged filesystems, like FAT
^ permalink raw reply
* Re: [PATCH] Move couple of ifdefs after "include config.mk"
From: Junio C Hamano @ 2005-12-01 9:45 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0512010140m1b96db84x70c7d92f8f644a2a@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> I have even my specific targets in the config.mak (and would actually
> like to have the default target put before including config.mak, so
> default call to make is always the same).
Surely you can do that by having your own "makefile" and include
"Makefile" I ship, and run "make", which prefers makefile over
Makefile ;-).
^ permalink raw reply
* Re: [PATCH] Move couple of ifdefs after "include config.mk"
From: Alex Riesen @ 2005-12-01 9:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Timo Hirvonen, git
In-Reply-To: <7vmzjlkx2f.fsf@assigned-by-dhcp.cox.net>
On 12/1/05, Junio C Hamano <junkio@cox.net> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > But it is only one line, heck only 20 bytes!
>
> Hey, don't get so piped up. Timo's patch has already been
> merged (thanks, Timo).
>
> But think about it a bit.
>
> If you need an override, you have to write down and maintain
> those YesPlease _somewhere_ yourself anyway, outside what I
> ship. Either "config.mak" or "Make" script.
>
> If we have '-include' in the Makefile, we need to make a
> decision if what we are adding to the Makefile should be
> overridable by that config.mak every time, exactly because
> whatever is included becomes part of the Makefile. IOW, that
> "only 20 bytes" adds work for the Makefile maintainer.
>
> "Make" script method is a command line override to the "make"
> program, which takes precedence and does not have that problem.
>
I have even my specific targets in the config.mak (and would actually
like to have the default target put before including config.mak, so
default call to make is always the same).
^ permalink raw reply
* Re: What's new in git.git master branch
From: Junio C Hamano @ 2005-12-01 9:38 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: git
In-Reply-To: <20051201085433.GA7866@c165.ib.student.liu.se>
Fredrik Kuivinen <freku045@student.liu.se> writes:
> It turns out that this change breaks the directory/file conflict
> handling in git-merge-recursive.
>
> git-ls-tree -r -z <tree SHA1>
>
> Should we do it that way or should ls-tree be changed?
Ouch. Sorry, I should have been more careful. For this
particular one, I think updating merge-recursive is less work,
so for now I'd vote for that approach. However, as you might
already be aware, I am not convinced that the new behaviour is
better than the previous round (there is no question about the
implementation quality and the clean-up value the rewrite
brings), so we might want to also add the "show tree entry in
recursive cases too" option to ls-tree as well. What I am
saying is essentially, "why not do both?" ;-).
I was looking at the merge-recursive, and there is another topic
I wanted to discuss with you about. Conflicts in renaming
merges and index collapsing. The latest merge-one-file leaves
index entries uncollapsed when the file content changes cannot
be automerged, and I think we would want to match that in
merge-recursive. When there is no rename involved it can do the
same thing as merge-one-file does -- just leave the index
unmerged. Renaming case is different.
Currently, rename result is recorded by using "git-update-index
--cacheinfo" to populate the index. This method unfortunately
can only create a stage0 entry. We can go two ways. One way is
to support "register this mode/sha1 tuple at stageN for path" to
update-index. Another would be for merge-recursive to first
construct three trees with the final directory structure
(i.e. prepare three temporary trees with renames applied) and
run read-tree 3-way merge on these temporary trees. I suspect
the former is probably of lesser impact. Thoughts?
Also I think I broke the case where base trees need to be merged
in 58cce8a8 commit (I changed processEntry not to collapse the
index entry when file content changes cannot be automerged, but
that change has to be done only for the final merge, and merges
between base trees must collapse to be able to write the index
file out as a tree).
^ permalink raw reply
* Re: [PATCH] Move couple of ifdefs after "include config.mk"
From: Junio C Hamano @ 2005-12-01 9:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Timo Hirvonen, git
In-Reply-To: <Pine.LNX.4.63.0512010906400.22709@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> But it is only one line, heck only 20 bytes!
Hey, don't get so piped up. Timo's patch has already been
merged (thanks, Timo).
But think about it a bit.
If you need an override, you have to write down and maintain
those YesPlease _somewhere_ yourself anyway, outside what I
ship. Either "config.mak" or "Make" script.
If we have '-include' in the Makefile, we need to make a
decision if what we are adding to the Makefile should be
overridable by that config.mak every time, exactly because
whatever is included becomes part of the Makefile. IOW, that
"only 20 bytes" adds work for the Makefile maintainer.
"Make" script method is a command line override to the "make"
program, which takes precedence and does not have that problem.
^ permalink raw reply
* Re: What's new in git.git master branch
From: Fredrik Kuivinen @ 2005-12-01 8:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkz5n3r1.fsf@assigned-by-dhcp.cox.net>
On Wed, Nov 30, 2005 at 02:57:06PM -0800, Junio C Hamano wrote:
[...]
> - ls-tree rewrite (Linus).
[...]
> One interesting change is ls-tree rewrite by Linus. The command
> does _not_ show tree nodes when running with -r flag anymore.
> Running "git diff v0.99.9i t/t3100-ls-tree-restrict.sh"
> after updating to the master tells you the summary of changes in
> the behaviour.
It turns out that this change breaks the directory/file conflict
handling in git-merge-recursive. Right now merge-recursive uses
git-ls-tree -r -z <tree SHA1>
to get a listing of every blob object (which corresponds to files) and
every tree object (which corresponds to directories) in the tree
designated by the SHA1. With the new ls-tree behaviour we don't get
any tree objects and hence merge-recursive can't do the d/f conflict
detection as it doesn't know about the directories. As we don't track
empty directories it could be fixed within git-merge-recursive, a list
of the directory names can be obtained from the list of file names by
stripping everything after the last slash in the file names.
Should we do it that way or should ls-tree be changed?
- Fredrik
^ permalink raw reply
* Re: Question about handling of heterogeneous repositories
From: Alex Riesen @ 2005-12-01 8:16 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git, Johannes Schindelin
In-Reply-To: <200511301749.18073.Josef.Weidendorfer@gmx.de>
On 11/30/05, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> git-mv would have to do exactly something like this to detect
> inter-repo renames at all ;-)
> But in general, this is really messy.
That's is what I'm most afraid of.
> See my suggestion in a previous thread with similar topic
> http://www.gelato.unsw.edu.au/archives/git/0511/12028.html
Oh, thanks! Pity, I missed that discussion,
Pasky's subprojects is exactly what I am looking for.
^ permalink raw reply
* Re: [PATCH] Move couple of ifdefs after "include config.mk"
From: Johannes Schindelin @ 2005-12-01 8:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Timo Hirvonen, git
In-Reply-To: <7vhd9tmw1g.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 30 Nov 2005, Junio C Hamano wrote:
> Honestly speaking, I'd personally prefer to just get rid of "-include
> config.mak" from Makefile.
But it is only one line, heck only 20 bytes!
And you can still use your "./Make" method, and it is not widely
advertised, and you can override settings from the platform-dependent
code, and I feel much better at having my littly config.mak, my precious!
Ciao,
Dscho
^ permalink raw reply
* Re: git-name-rev off-by-one bug
From: Junio C Hamano @ 2005-12-01 7:46 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511301707020.25300@iabervon.org>
Delight in working on free software project is you have so many
good people with you that you can have many "Aha, lightbulb!"
moments. This is one of them for me. I realized where the
trouble I felt when reading your table came from; it was that I
was focused on the old way the table was organized too much.
When one constructs a case table to make sure one covered
everything, one first lists the variables and the possible
values they can take, and make NxMxOxPx... grid. In the
original table I did, I chose what is in O and A and B as my
variables (and that's where my comment about O being bit2 etc
comes from). I did not realize the semantics and algorithm you
used can be better described by different set of variables
(namely, how ancestors match the HEAD, and how the remote
matches the HEAD, if I understand correctly). I had trouble
understanding your version only because I kept thinking in terms
of (O,A,B).
So after thinking about that...
Daniel Barkalow <barkalow@iabervon.org> writes:
> On Wed, 30 Nov 2005, Junio C Hamano wrote:
>
> Perhaps the table would be clearer if the lines were grouped
> in exists/missing? (With 5ALT repeated in the 011 and 111
> groups, since it applies to both) Then you would only need
> to look at 5 lines with cascading (in the most complex
> case), rather than having to read the whole top of the
> table.
I think the current ordering of cases makes more sense. If we
forget about the case labels from the original table (and the
way the original table classified cases), I suspect we could
reorganize the cases to describe the semantics even better and
clearer. That is, not grouping by exists/missing, but grouping
by matching/unmatching.
> (It is actually written like that, with the exception of 5ALT, 2ALT, and
> 3ALT, but it's not visually obvious.)
Yeah, I now realize that.
> The tricky bit is really cases 2ALT and 3ALT, which can be used in cases
> where some but not all of the ancestors are empty, and can't be used if
> there's a directory/file conflict; neither of these conditions matters for
> anything else in the table, so it's hard to fit this in. My strategy is to
> have those as special cases, and have the rest of the table cover
> everything (rather than having case 2 require a directory/file conflict
> and case 7 require that no ancestor be empty, which would be accurate, but
> would make it harder to check for missing cases).
Makes sense. Thanks for the clarification and lightbulb moment.
^ permalink raw reply
* Re: [PATCH 7/7] Use a separate directory for patches under each branch subdir
From: Chuck Lever @ 2005-12-01 2:53 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0511301432m10b25887r@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 664 bytes --]
Catalin Marinas wrote:
> A separate stg command for this would be useful. Anyway since the
> repository structure might change again in the future, I think it
> would be better to have a version string saved somewhere in
> .git/patches/version for reference.
note that we have the same problem with .git/patches that this patch
fixes in the .git/patches/<series> directories; namely, that if we add
files in .git/patches, we can't have branches with the same names.
i was thinking of perhaps creating a .git/stgit subdirectory that might
contain the config file, an stgit metadata version file, and perhaps any
locally modified copies of the template files.
[-- Attachment #2: cel.vcf --]
[-- Type: text/x-vcard, Size: 439 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Charles
org:Network Appliance, Incorporated;Linux NFS Client Development
adr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA
email;internet:cel@citi.umich.edu
title:Member of Technical Staff
tel;work:+1 734 763-4415
tel;fax:+1 734 763 4434
tel;home:+1 734 668-1089
x-mozilla-html:FALSE
url:http://www.monkey.org/~cel/
version:2.1
end:vcard
^ permalink raw reply
* Re: keeping remote repo checked out?
From: Junio C Hamano @ 2005-12-01 2:43 UTC (permalink / raw)
To: James Cloos; +Cc: git
In-Reply-To: <m38xv5r50x.fsf@lugabout.cloos.reno.nv.us>
James Cloos <cloos@jhcloos.com> writes:
>>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
>
> Junio> Creative use of hooks/post-update would solve that.
>
> I'll have to look into that.
Documentation/howto/rebuild-from-update-hook.txt may help.
I push into the master repository, and its post-update hook
checks out the updated "master" head to rebuild the HTML
documentation that is shown at
http://kernel.org/pub/software/scm/git/docs/
The checkout happens not in the master repository but in a
separate repository by pulling into the latter, since the master
is a naked repository without a working tree associated with it.
^ permalink raw reply
* Re: keeping remote repo checked out?
From: James Cloos @ 2005-12-01 1:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbr051ad1.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> Creative use of hooks/post-update would solve that.
I'll have to look into that.
Junio> However, you should be very careful if you sometimes edit on
Junio> server and sometimes push from other machine to the server on
Junio> the same branch on the server.
I always pull before editing on the laptop....
Thanks,
-JimC
--
James H. Cloos, Jr. <cloos@jhcloos.com>
^ permalink raw reply
* Re: [PATCH] Move couple of ifdefs after "include config.mk"
From: Junio C Hamano @ 2005-12-01 1:43 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git
In-Reply-To: <20051201033201.02b47071.tihirvon@gmail.com>
Honestly speaking, I'd personally prefer to just get rid of
"-include config.mak" from Makefile. If somebody wants to keep
her customized set of configuration, she can have her own ./Make
script that would look like:
#!/bin/sh
make WITH_SEND_EMAIL=YesPlesae NO_EXPAT=NoThanks "$@"
^ permalink raw reply
* [PATCH] Move couple of ifdefs after "include config.mk"
From: Timo Hirvonen @ 2005-12-01 1:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0512010144050.11941@wbgn013.biozentrum.uni-wuerzburg.de>
This makes it possible to define WITH_SEND_EMAIL etc. in config.mak.
Also remove GIT_LIST_TWEAK because it isn't used anymore.
---
Makefile | 28 ++++++++++++----------------
1 files changed, 12 insertions(+), 16 deletions(-)
f877acdc3f8c888dd82a1e81ce20c8715e3108e4
diff --git a/Makefile b/Makefile
index 984d167..00521fe 100644
--- a/Makefile
+++ b/Makefile
@@ -138,8 +138,6 @@ ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROG
# Backward compatibility -- to be removed after 1.0
PROGRAMS += git-ssh-pull$X git-ssh-push$X
-GIT_LIST_TWEAK =
-
# Set paths to tools early so that they can be used for version tests.
ifndef SHELL_PATH
SHELL_PATH = /bin/sh
@@ -154,20 +152,6 @@ endif
PYMODULES = \
gitMergeCommon.py
-ifdef WITH_OWN_SUBPROCESS_PY
- PYMODULES += compat/subprocess.py
-else
- ifneq ($(shell $(PYTHON_PATH) -c 'import subprocess;print"OK"' 2>/dev/null),OK)
- PYMODULES += compat/subprocess.py
- endif
-endif
-
-ifdef WITH_SEND_EMAIL
- SCRIPT_PERL += git-send-email.perl
-else
- GIT_LIST_TWEAK += -e '/^send-email$$/d'
-endif
-
LIB_FILE=libgit.a
LIB_H = \
@@ -256,6 +240,18 @@ endif
-include config.mak
+ifdef WITH_OWN_SUBPROCESS_PY
+ PYMODULES += compat/subprocess.py
+else
+ ifneq ($(shell $(PYTHON_PATH) -c 'import subprocess;print"OK"' 2>/dev/null),OK)
+ PYMODULES += compat/subprocess.py
+ endif
+endif
+
+ifdef WITH_SEND_EMAIL
+ SCRIPT_PERL += git-send-email.perl
+endif
+
ifndef NO_CURL
ifdef CURLDIR
# This is still problematic -- gcc does not always want -R.
--
0.99.9.GIT
^ permalink raw reply related
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