* 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
* Re: [PATCH] git-merge: do up-to-date check also for strategies ours, subtree.
From: Junio C Hamano @ 2007-08-10 8:45 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
In-Reply-To: <7v3aysxvk3.fsf@assigned-by-dhcp.cox.net>
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.
^ permalink raw reply
* Re: git-p4 question
From: Alex Riesen @ 2007-08-10 8:10 UTC (permalink / raw)
To: Govind Salinas; +Cc: git
In-Reply-To: <81b0412b0708100106m3123a504p16309b6e06cd9609@mail.gmail.com>
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
* Re: git-p4 question
From: Alex Riesen @ 2007-08-10 8:06 UTC (permalink / raw)
To: Govind Salinas; +Cc: git
In-Reply-To: <69b0c0350708091953wdc9c22vd2b17b1edd1c5cd2@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 637 bytes --]
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.
The script attached (sorry for .gz, gmail wont let me send a .bat).
[-- Attachment #2: git-p4-import.gz --]
[-- Type: application/x-gzip, Size: 15646 bytes --]
^ permalink raw reply
* [PATCH] Reinstate the old behaviour when GIT_DIR is set and GIT_WORK_TREE is unset
From: Junio C Hamano @ 2007-08-10 7:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Uwe Kleine-König, git
In-Reply-To: <Pine.LNX.4.64.0708100210280.21857@racer.site>
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.
setup.c | 52 +++++++++----------------------------------------
t/t1500-rev-parse.sh | 6 +++-
2 files changed, 14 insertions(+), 44 deletions(-)
diff --git a/setup.c b/setup.c
index b55b82c..06004f1 100644
--- a/setup.c
+++ b/setup.c
@@ -189,53 +189,21 @@ int is_inside_work_tree(void)
}
/*
- * If no worktree was given, and we are outside of a default work tree,
- * now is the time to set it.
- *
- * In other words, if the user calls git with something like
- *
- * git --git-dir=/some/where/else/.git bla
- *
- * default to /some/where/else as working directory; if the specified
- * git-dir does not end in "/.git", the cwd is used as working directory.
+ * set_work_tree() is only ever called if you set GIT_DIR explicitely.
+ * The old behaviour (which we retain here) is to set the work tree root
+ * to the cwd, unless overridden by the config, the command line, or
+ * GIT_WORK_TREE.
*/
-const char *set_work_tree(const char *dir)
+static const char *set_work_tree(const char *dir)
{
- char dir_buffer[PATH_MAX], *rel = NULL;
- static char buffer[PATH_MAX + 1];
- int len, suffix_len = strlen(DEFAULT_GIT_DIR_ENVIRONMENT) + 1;
-
- /* strip the variable 'dir' of the postfix "/.git" if it has it */
- len = strlen(dir);
- if (len > suffix_len &&
- !strcmp(dir + len - suffix_len, "/" DEFAULT_GIT_DIR_ENVIRONMENT)) {
- if ((len - suffix_len) >= sizeof(dir_buffer))
- die("directory name too long");
- memcpy(dir_buffer, dir, len - suffix_len);
- dir_buffer[len - suffix_len] = '\0';
-
- /* are we inside the default work tree? */
- rel = get_relative_cwd(buffer, sizeof(buffer), dir_buffer);
- }
+ char buffer[PATH_MAX + 1];
- /* if rel is set, the cwd is _not_ the current working tree */
- if (rel && *rel) {
- if (!is_absolute_path(dir))
- set_git_dir(make_absolute_path(dir));
- dir = dir_buffer;
- if (chdir(dir))
- die("cannot chdir to %s: %s", dir, strerror(errno));
- else
- strcat(rel, "/");
- inside_git_dir = 0;
- } else {
- rel = NULL;
- dir = getcwd(buffer, sizeof(buffer));
- }
- git_work_tree_cfg = xstrdup(dir);
+ if (!getcwd(buffer, sizeof(buffer)))
+ die ("Could not get the current working directory");
+ git_work_tree_cfg = xstrdup(buffer);
inside_work_tree = 1;
- return rel;
+ return NULL;
}
/*
diff --git a/t/t1500-rev-parse.sh b/t/t1500-rev-parse.sh
index bea40cb..e474b3f 100755
--- a/t/t1500-rev-parse.sh
+++ b/t/t1500-rev-parse.sh
@@ -28,6 +28,8 @@ test_rev_parse() {
[ $# -eq 0 ] && return
}
+# label is-bare is-inside-git is-inside-work prefix
+
test_rev_parse toplevel false false true ''
cd .git || exit 1
@@ -53,13 +55,13 @@ export GIT_DIR=../.git
export GIT_CONFIG="$(pwd)"/../.git/config
git config core.bare false
-test_rev_parse 'GIT_DIR=../.git, core.bare = false' false false true work/
+test_rev_parse 'GIT_DIR=../.git, core.bare = false' false false true ''
git config core.bare true
test_rev_parse 'GIT_DIR=../.git, core.bare = true' true false false ''
git config --unset core.bare
-test_rev_parse 'GIT_DIR=../.git, core.bare undefined' false false true work/
+test_rev_parse 'GIT_DIR=../.git, core.bare undefined' false false true ''
mv ../.git ../repo.git || exit 1
export GIT_DIR=../repo.git
--
1.5.3.rc4.29.g74276
^ permalink raw reply related
* git-log-branches
From: Domenico Andreoli @ 2007-08-10 7:53 UTC (permalink / raw)
To: git
Hi,
in trying to survive in the forest of git repositories I spread all
over my boxes, I came to this script. I use it to see which changes
are in my local branches w.r.t. tracked remotes and vice versa.
It is pretty raw and uses only commands I know. Feel free to point me
to better command using. Or to a better script, which I am sure has
been already written ;)
cheers,
Domenico
#! /bin/sh
if [ -z "$1" ]; then
echo "usage: $0 <remote>"
exit
fi
for b in $(git branch | sed 's/^..//'); do
if ! git branch -r | grep $1/$b >/dev/null; then
continue
fi
if [ -n "$(git log $b..$1/$b)" ]; then
echo "$b..$1/$b:"
git log $b..$1/$b
fi
if [ -n "$(git log $1/$b..$b)" ]; then
echo "$1/$b..$b:"
git log $1/$b..$b
fi
done
-----[ Domenico Andreoli, aka cavok
--[ http://www.dandreoli.com/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
^ permalink raw reply
* [PATCH 2/2] tweak manpage formatting
From: Junio C Hamano @ 2007-08-10 7:49 UTC (permalink / raw)
To: git; +Cc: Carlos Rica
This attempts to force fixed-font in manpages for literal
blocks. I have tested this with docbook 1.71 and it seems to
work as expected.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* The illustration in git-rev-parse.1 is much easier to read
with this...
Documentation/callouts.xsl | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/Documentation/callouts.xsl b/Documentation/callouts.xsl
index 6a361a2..7941af7 100644
--- a/Documentation/callouts.xsl
+++ b/Documentation/callouts.xsl
@@ -27,4 +27,17 @@
</xsl:if>
</xsl:template>
+<xsl:template match="literallayout[@class='monospaced']">
+ <xsl:text>.RS</xsl:text>
+ <xsl:if test="not($man.indent.width = '')">
+ <xsl:text> </xsl:text>
+ <xsl:value-of select="$man.indent.width"/>
+ </xsl:if>
+ <xsl:text> </xsl:text>
+ <xsl:text> .ft C .nf </xsl:text>
+ <xsl:apply-templates/>
+ <xsl:text> .fi .ft </xsl:text>
+ <xsl:text>.RE </xsl:text>
+</xsl:template>
+
</xsl:stylesheet>
^ permalink raw reply related
* [PATCH 1/2] Fix an illustration in git-rev-parse.txt
From: Junio C Hamano @ 2007-08-10 7:49 UTC (permalink / raw)
To: git; +Cc: Carlos Rica
This hides the backslash at the end of line from AsciiDoc
toolchain by introducing a trailing whitespace on one line in an
illustration in git-rev-parse.txt.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* Obviously this needs to be applied without --whitespace=strip
Documentation/git-rev-parse.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index eea9c9c..4b4d229 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -224,7 +224,7 @@ left-to-right.
G H I J
\ / \ /
D E F
- \ | / \
+ \ | / \
\ | / |
\|/ |
B C
^ permalink raw reply related
* Re: msysgit: does git gui work?
From: Marius Storm-Olsen @ 2007-08-10 7:47 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <8FB380EB-CCA4-4BD3-8AD5-93630488D9C9@zib.de>
[-- Attachment #1: Type: text/plain, Size: 1306 bytes --]
Steffen Prohaska said the following on 10.08.2007 09:38:
> On Aug 10, 2007, at 9:03 AM, Steffen Prohaska wrote:
>
>> Marius, Johannes,
>> I really think the right way to fix this would be to include
>> tclsh.exe in mingw. I tried to push a commit to mob but failed
>> to do so (see separate mail on submodule to the list).
>>
>> btw,
>> 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
>
> Ok, I finally defeated git-submodule and pushed two commits to
> the mob branch.
>
> e809cacf22d8dada9801403e19d85e423c51f0d9 profile: removed '.' from PATH
> 6cd2805a3a2ff5e0c941d1882232a22de9d19bf4 mingw: add tclsh.exe (needed
Hi Steffen,
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?
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: msysgit: does git gui work?
From: Steffen Prohaska @ 2007-08-10 7:38 UTC (permalink / raw)
To: Marius Storm-Olsen, Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <B6C82889-ABE0-4B3D-A455-A2EE1CE48297@zib.de>
On Aug 10, 2007, at 9:03 AM, Steffen Prohaska wrote:
> Marius, Johannes,
> I really think the right way to fix this would be to include
> tclsh.exe in mingw. I tried to push a commit to mob but failed
> to do so (see separate mail on submodule to the list).
>
> btw,
> 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
Ok, I finally defeated git-submodule and pushed two commits to
the mob branch.
e809cacf22d8dada9801403e19d85e423c51f0d9 profile: removed '.' from PATH
6cd2805a3a2ff5e0c941d1882232a22de9d19bf4 mingw: add tclsh.exe (needed
by git gui)
Steffen
^ permalink raw reply
* Re: How to work with submodule?
From: Steffen Prohaska @ 2007-08-10 7:29 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <769ABF7E-14C9-43D1-B879-138B6FF96B2E@zib.de>
On Aug 10, 2007, at 9:02 AM, Steffen Prohaska wrote:
> I mean, I should be allowed to work on the submodule and somehow
> work on the superproject at the same time? But none of my
> usual workflow works because I always get trapped by a
> modified submodule.
What I do now is to check with 'git diff' in the supermodule,
which state of the submodule is expected. Then I bring the
submodule in this state (even if this brings me to a detached
head). This keeps the supermodule happy.
But if different branches of the supermodule expect different
states of the submodule you may be forced to switch to another
detached head after every command you run in the supermodule.
There must be a simpler way, which I probably don't know.
Steffen
^ permalink raw reply
* Re: git on Cygwin: Not a valid object name HEAD
From: Steffen Prohaska @ 2007-08-10 7:19 UTC (permalink / raw)
To: Torgil Svensson; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <e7bda7770708092307g49fa9976l5f9972592129fc8e@mail.gmail.com>
On Aug 10, 2007, at 8:07 AM, Torgil Svensson wrote:
> On 8/9/07, Steffen Prohaska <prohaska@zib.de> wrote:
>
>> The next would be a good integration with
>> useful tools on Windows, for example git-mergetool should launch
>> Windows three-way merge tools.
>
> Do you mean tools included in Windows or tools using the Windows API?
I think both. I'm currently conducting a survey what the Windows
users I'm working with are using. Up to now I have no idea what these
tools do. Note, I'm not working on Windows. But I would like to see
git starting the tools that users prefer to use.
Git would just feel more like a useful Windows tool if it interacted
with other useful Windows tools.
Here is what I have on my list (not yet prioritized):
- WinMerge (http://winmerge.org/)
- Visual Comparer (http://www.nikeware.com/vc-features.htm)
- Araxis Merge, http://www.araxis.com/merge/ (expensive!)
- Beyond Compare, http://www.scootersoftware.com/file-comparison.php
(will support 3-way with upcoming version 3; reasonable price)
- KDiff3, http://kdiff3.sourceforge.net/ (comes with Windows-
installer from SF)
- ECMerge, http://www.elliecomputing.com/Products/merge_overview.asp
(OSS developer can get a "Pro" license for free upon request)
A complete list at
http://en.wikipedia.org/wiki/Comparison_of_file_comparison_tools
>
>> My goal would be to type 'make windist' in the official repo and
>> get a very basic installer (maybe just a zip archive) that contains
>> everything needed to run git on Windows. Unpacking this self-
>> contained
>> installer on a freshly installed Windows should get you going. There
>> should be no need to install Cygwin or something else.
>>
>> Is this realistic?
>> What is needed to get there?
>> What would be an estimated timeframe to achieve this goal?
>>
>> 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?
> 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 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.
> You could even start with cloning the TortoiseSVN repo using git. Or
> maybe even better, since KDE4 will compile on Windows [take on wood],
> do it as a kioslave (or whatever mechanism) to have an environment
> that works in both Windows and Linux and most OtherOs:es. Aiming for
> environments that works on several OSes is a good thing for future
> migrations.
I work for years now on cross platform code. I never needed a whole
environment. I need Qt and the native development environment, like
Visual Studio, gcc, Xcode. I don't need KDE on Windows, I don't need
KDE on Mac. Everything's there already.
Steffen
^ permalink raw reply
* Re: msysgit: does git gui work?
From: Steffen Prohaska @ 2007-08-10 7:03 UTC (permalink / raw)
To: Marius Storm-Olsen, Johannes Schindelin; +Cc: Git Mailing List, Shawn O. Pearce
In-Reply-To: <20070810053158.GJ24573@spearce.org>
On Aug 10, 2007, at 7:31 AM, Shawn O. Pearce wrote:
> Steffen Prohaska <prohaska@zib.de> wrote:
>> mingw only contains tclsh84 but not tclsh. This causes
>> the Makefile in git-gui to fail on the creation of
>> lib/tclIndex. Therefore git gui decides to take the slow
>> path of sourcing the files in lib explicitly but this failes
>> because they are sourced before git-version is defined.
>> Therefore blame.tcl reports the error mentioned above.
>>
>> Johannes (or someone else from the msysgit team),
>> We should modify mingw to contain the symlink to tclsh.
>> Or something similar, at least 'tclsh' should be there.
>>
>> Shawn,
>> The fallback mechanism of sourcing files from lib is broken.
>> Either git-version must be defined before sourcing them, or
>> the auto_index must always work.
>
> *ouch*. Yea, that happened when the git-version proc was introduced.
> It doesn't get declared until after we have sourced everything,
> but the things we are sourcing want it to be declared.
>
> The short-term workaround is the obvious thing of just making
> sure the auto_index works in the Makefile. I'll try to reorder
> things in git-gui so that the "source everything fallback" is
> done only after git-version is declared. Though that might be
> difficult as that codepath assumes error_popup has been declared
> and that's in something we are sourcing.
Marius, Johannes,
I really think the right way to fix this would be to include
tclsh.exe in mingw. I tried to push a commit to mob but failed
to do so (see separate mail on submodule to the list).
btw,
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?
Steffen
^ permalink raw reply
* How to work with submodule?
From: Steffen Prohaska @ 2007-08-10 7:02 UTC (permalink / raw)
To: Git Mailing List
I tried to do some work on msysgit, but instead I'm fighting
with submodule for a while now. Maybe I haven't understood
something, but for submodule makes git nearly unusable.
Here is what I did.
msysgit ist organized in the following way.
/.git (clone of repo.or.cz/msysgit.git)
/git/.git (clone of repo.or.cz/git/mingw/4msysgit.git)
That is the root of the project is msysgit and as a submodule
git is included. Working on the submodule is fine.
But it I start to work on msysgit itself I get lost.
I have some changes in the submodule and just want to commit
some changes in the root, rebase to origin/master and push
to mob. To make it a bit harder I have some local changes
in the working tree.
This sounds quite simple, but I'm fighting with submodule
for quite some while now.
I think the root of all trouble is that I changed something
in the submodule git and now would like to change few things
in the root. I have a modified submodule and this messes
up everything.
I can't stash, I can't rebase.
I tried to commit the head of the submodule (btw, how should
I call this? I mean, the sha1 of the head of the submodule),
to get a clean git-status.
Now, I can't even switch branches.
How is this ment to work?
I have no clue how I should work with this mess?
I mean, I should be allowed to work on the submodule and somehow
work on the superproject at the same time? But none of my
usual workflow works because I always get trapped by a
modified submodule.
Steffen
^ permalink raw reply
* git stash doesn't handle submodules with modifications
From: Steffen Prohaska @ 2007-08-10 6:24 UTC (permalink / raw)
To: Git Mailing List
Stash in combination with a submodule does not work as
expected. A submodule with modifications is not handled
correctly if it has modifications.
I started with some changes in the working tree and with
a submodule having changes, too. I do 'git stash', which
stashes away all my changes to the working tree, but it
does not store changes to the submodule. Thus,
'git status' still shows a modified submodule.
'git apply' refuses to work with a modified submodule with:
'Cannot restore on top of a dirty state'.
So, I have stashed my changes, but can't get them back
easily. This happend to me in the msysgit repo, which
includes git as a submodule.
What would be the right way to solve this?
I'd expect that stash somehow would ignore the submodule.
But it may be more correct to include the submodule into
the stash?
Steffen
^ permalink raw reply
* Re: git on Cygwin: Not a valid object name HEAD
From: Torgil Svensson @ 2007-08-10 6:07 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <76795DDC-29A5-4C7E-B56E-A6316A183C75@zib.de>
On 8/9/07, Steffen Prohaska <prohaska@zib.de> wrote:
> The next would be a good integration with
> useful tools on Windows, for example git-mergetool should launch
> Windows three-way merge tools.
Do you mean tools included in Windows or tools using the Windows API?
> My goal would be to type 'make windist' in the official repo and
> get a very basic installer (maybe just a zip archive) that contains
> everything needed to run git on Windows. Unpacking this self-contained
> installer on a freshly installed Windows should get you going. There
> should be no need to install Cygwin or something else.
>
> Is this realistic?
> What is needed to get there?
> What would be an estimated timeframe to achieve this goal?
>
> Will all this run on Windows XP 64 bit and Windows Vista 64 bit?
How fast can you type?
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).
You could even start with cloning the TortoiseSVN repo using git. Or
maybe even better, since KDE4 will compile on Windows [take on wood],
do it as a kioslave (or whatever mechanism) to have an environment
that works in both Windows and Linux and most OtherOs:es. Aiming for
environments that works on several OSes is a good thing for future
migrations.
//Torgil
^ permalink raw reply
* Re: git and larger trees, not so fast?
From: Junio C Hamano @ 2007-08-10 5:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Sean, moe, git
In-Reply-To: <7v643ovyli.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> (I didn't test it, though, maybe I missed something).
>
> I do not think the change affects the normal codepath. The
> one-liner patch to git-commit.sh touches the codepath that
> updates the index used only to write out the partial commit, and
> losing the cached stat info from that index does not matter, as
> that index is removed immediately after writing the tree out and
> is never compared with working tree as far as I can tell.
FWIW, moe's script with and without two patches gives these
numbers for me.
with patches without patches
----------------------------------------------------------------
# git init | # git init
Initialized empty Git repository in | Initialized empty Git repository in
|
real 0m0.029s | real 0m0.004s
user 0m0.000s | user 0m0.000s
sys 0m0.008s | sys 0m0.004s
# git add . | # git add .
|
real 0m2.947s | real 0m3.038s
user 0m0.808s | user 0m0.876s
sys 0m2.120s | sys 0m1.996s
# git commit -a | # git commit -a
|
real 0m4.537s | real 0m4.674s
user 0m1.980s | user 0m1.888s
sys 0m2.356s | sys 0m2.332s
# git status (three times) | # git status (three times)
# On branch master | # On branch master
nothing to commit (working directory| nothing to commit (working directory
|
real 0m0.718s | real 0m17.323s
user 0m0.300s | user 0m16.913s
sys 0m0.416s | sys 0m0.396s
# On branch master | # On branch master
nothing to commit (working directory| nothing to commit (working directory
|
real 0m0.707s | real 0m16.994s
user 0m0.312s | user 0m16.573s
sys 0m0.400s | sys 0m0.416s
# On branch master | # On branch master
nothing to commit (working directory| nothing to commit (working directory
|
real 0m0.720s | real 0m18.042s
user 0m0.344s | user 0m17.633s
sys 0m0.376s | sys 0m0.408s
# git commit (one path) | # git commit (one path)
Created commit 3483df5: expose the t| Created commit ced664f: expose the t
1 files changed, 1 insertions(+), 1| 1 files changed, 1 insertions(+), 1
|
real 0m3.057s | real 0m38.130s
user 0m0.888s | user 0m37.458s
sys 0m0.712s | sys 0m0.616s
----------------------------------------------------------------
^ permalink raw reply
* Re: msysgit: does git gui work?
From: Shawn O. Pearce @ 2007-08-10 5:31 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Johannes Schindelin, Marius Storm-Olsen, Git Mailing List
In-Reply-To: <E886F099-5E9F-4785-A560-F9AAAA4E4C1F@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> mingw only contains tclsh84 but not tclsh. This causes
> the Makefile in git-gui to fail on the creation of
> lib/tclIndex. Therefore git gui decides to take the slow
> path of sourcing the files in lib explicitly but this failes
> because they are sourced before git-version is defined.
> Therefore blame.tcl reports the error mentioned above.
>
> Johannes (or someone else from the msysgit team),
> We should modify mingw to contain the symlink to tclsh.
> Or something similar, at least 'tclsh' should be there.
>
> Shawn,
> The fallback mechanism of sourcing files from lib is broken.
> Either git-version must be defined before sourcing them, or
> the auto_index must always work.
*ouch*. Yea, that happened when the git-version proc was introduced.
It doesn't get declared until after we have sourced everything,
but the things we are sourcing want it to be declared.
The short-term workaround is the obvious thing of just making
sure the auto_index works in the Makefile. I'll try to reorder
things in git-gui so that the "source everything fallback" is
done only after git-version is declared. Though that might be
difficult as that codepath assumes error_popup has been declared
and that's in something we are sourcing.
Ouch.
me: Doctor, it hurts when I declare circular dependencies!
dr: Well, don't do that son!
--
Shawn.
^ permalink raw reply
* Start moving unpack-trees to "struct tree_desc"
From: Linus Torvalds @ 2007-08-10 5:21 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
This doesn't actually change any real code, but it changes the interface
to unpack_trees() to take an array of "struct tree_desc" entries, the same
way the tree-walk.c functions do.
The reason for this is that we would be much better off if we can do the
tree-unpacking using the generic "traverse_trees()" functionality instead
of having to the special "unpack" infrastructure.
This really is a pretty minimal diff, just to change the calling
convention. It passes all the tests, and looks sane. There were only two
users of "unpack_trees()": builtin-read-tree and merge-recursive, and I
tried to keep the changes minimal.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
My plan is that with the more regular interfaces, we can hopefully migrate
the cases that "unpack_trees()" handles one by one to other interfaces -
but in order to do that, it has to use the *common* tree traversal
interface, rather than a special one that requires munging from one
format to another.
Linus
---
builtin-read-tree.c | 26 ++++++++++++++++++--------
merge-recursive.c | 16 +++++++++++-----
unpack-trees.c | 25 +++++++++----------------
unpack-trees.h | 2 +-
4 files changed, 39 insertions(+), 30 deletions(-)
diff --git a/builtin-read-tree.c b/builtin-read-tree.c
index a3b17a3..1967d10 100644
--- a/builtin-read-tree.c
+++ b/builtin-read-tree.c
@@ -13,14 +13,19 @@
#include "dir.h"
#include "builtin.h"
-static struct object_list *trees;
+static int nr_trees;
+static struct tree *trees[4];
static int list_tree(unsigned char *sha1)
{
- struct tree *tree = parse_tree_indirect(sha1);
+ struct tree *tree;
+
+ if (nr_trees >= 4)
+ return -1;
+ tree = parse_tree_indirect(sha1);
if (!tree)
return -1;
- object_list_append(&tree->object, &trees);
+ trees[nr_trees++] = tree;
return 0;
}
@@ -76,11 +81,10 @@ static void prime_cache_tree_rec(struct cache_tree *it, struct tree *tree)
static void prime_cache_tree(void)
{
- struct tree *tree = (struct tree *)trees->item;
- if (!tree)
+ if (!nr_trees)
return;
active_cache_tree = cache_tree();
- prime_cache_tree_rec(active_cache_tree, tree);
+ prime_cache_tree_rec(active_cache_tree, trees[0]);
}
@@ -92,6 +96,7 @@ int cmd_read_tree(int argc, const char **argv, const char *unused_prefix)
{
int i, newfd, stage = 0;
unsigned char sha1[20];
+ struct tree_desc t[3];
struct unpack_trees_options opts;
memset(&opts, 0, sizeof(opts));
@@ -258,7 +263,12 @@ int cmd_read_tree(int argc, const char **argv, const char *unused_prefix)
opts.head_idx = 1;
}
- unpack_trees(trees, &opts);
+ for (i = 0; i < nr_trees; i++) {
+ struct tree *tree = trees[i];
+ parse_tree(tree);
+ init_tree_desc(t+i, tree->buffer, tree->size);
+ }
+ unpack_trees(nr_trees, t, &opts);
/*
* When reading only one tree (either the most basic form,
@@ -266,7 +276,7 @@ int cmd_read_tree(int argc, const char **argv, const char *unused_prefix)
* valid cache-tree because the index must match exactly
* what came from the tree.
*/
- if (trees && trees->item && !opts.prefix && (!opts.merge || (stage == 2))) {
+ if (nr_trees && !opts.prefix && (!opts.merge || (stage == 2))) {
cache_tree_free(&active_cache_tree);
prime_cache_tree();
}
diff --git a/merge-recursive.c b/merge-recursive.c
index c8539ec..f7d1b84 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -216,13 +216,19 @@ static int add_cacheinfo(unsigned int mode, const unsigned char *sha1,
*/
static int index_only = 0;
+static void init_tree_desc_from_tree(struct tree_desc *desc, struct tree *tree)
+{
+ parse_tree(tree);
+ init_tree_desc(desc, tree->buffer, tree->size);
+}
+
static int git_merge_trees(int index_only,
struct tree *common,
struct tree *head,
struct tree *merge)
{
int rc;
- struct object_list *trees = NULL;
+ struct tree_desc t[3];
struct unpack_trees_options opts;
memset(&opts, 0, sizeof(opts));
@@ -234,11 +240,11 @@ static int git_merge_trees(int index_only,
opts.head_idx = 2;
opts.fn = threeway_merge;
- object_list_append(&common->object, &trees);
- object_list_append(&head->object, &trees);
- object_list_append(&merge->object, &trees);
+ init_tree_desc_from_tree(t+0, common);
+ init_tree_desc_from_tree(t+1, head);
+ init_tree_desc_from_tree(t+2, merge);
- rc = unpack_trees(trees, &opts);
+ rc = unpack_trees(3, t, &opts);
cache_tree_free(&active_cache_tree);
return rc;
}
diff --git a/unpack-trees.c b/unpack-trees.c
index dfd985b..5d1ffd1 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -16,19 +16,13 @@ struct tree_entry_list {
const unsigned char *sha1;
};
-static struct tree_entry_list *create_tree_entry_list(struct tree *tree)
+static struct tree_entry_list *create_tree_entry_list(struct tree_desc *desc)
{
- struct tree_desc desc;
struct name_entry one;
struct tree_entry_list *ret = NULL;
struct tree_entry_list **list_p = &ret;
- if (!tree->object.parsed)
- parse_tree(tree);
-
- init_tree_desc(&desc, tree->buffer, tree->size);
-
- while (tree_entry(&desc, &one)) {
+ while (tree_entry(desc, &one)) {
struct tree_entry_list *entry;
entry = xmalloc(sizeof(struct tree_entry_list));
@@ -173,9 +167,11 @@ static int unpack_trees_rec(struct tree_entry_list **posns, int len,
if (S_ISDIR(posns[i]->mode)) {
struct tree *tree = lookup_tree(posns[i]->sha1);
+ struct tree_desc t;
any_dirs = 1;
parse_tree(tree);
- subposns[i] = create_tree_entry_list(tree);
+ init_tree_desc(&t, tree->buffer, tree->size);
+ subposns[i] = create_tree_entry_list(&t);
posns[i] = posns[i]->next;
src[i + o->merge] = o->df_conflict_entry;
continue;
@@ -331,12 +327,10 @@ static void check_updates(struct cache_entry **src, int nr,
stop_progress(&progress);;
}
-int unpack_trees(struct object_list *trees, struct unpack_trees_options *o)
+int unpack_trees(unsigned len, struct tree_desc *t, struct unpack_trees_options *o)
{
- unsigned len = object_list_length(trees);
struct tree_entry_list **posns;
int i;
- struct object_list *posn = trees;
struct tree_entry_list df_conflict_list;
static struct cache_entry *dfc;
@@ -356,10 +350,9 @@ int unpack_trees(struct object_list *trees, struct unpack_trees_options *o)
if (len) {
posns = xmalloc(len * sizeof(struct tree_entry_list *));
- for (i = 0; i < len; i++) {
- posns[i] = create_tree_entry_list((struct tree *) posn->item);
- posn = posn->next;
- }
+ for (i = 0; i < len; i++)
+ posns[i] = create_tree_entry_list(t+i);
+
if (unpack_trees_rec(posns, len, o->prefix ? o->prefix : "",
o, &df_conflict_list))
return -1;
diff --git a/unpack-trees.h b/unpack-trees.h
index fee7da4..9cd39a2 100644
--- a/unpack-trees.h
+++ b/unpack-trees.h
@@ -26,7 +26,7 @@ struct unpack_trees_options {
struct cache_entry *df_conflict_entry;
};
-extern int unpack_trees(struct object_list *trees,
+extern int unpack_trees(unsigned n, struct tree_desc *t,
struct unpack_trees_options *options);
int threeway_merge(struct cache_entry **stages, struct unpack_trees_options *o);
^ permalink raw reply related
* Re: git and larger trees, not so fast?
From: Junio C Hamano @ 2007-08-10 3:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Sean, moe, git
In-Reply-To: <alpine.LFD.0.999.0708091754150.25146@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> (I didn't test it, though, maybe I missed something).
I do not think the change affects the normal codepath. The
one-liner patch to git-commit.sh touches the codepath that
updates the index used only to write out the partial commit, and
losing the cached stat info from that index does not matter, as
that index is removed immediately after writing the tree out and
is never compared with working tree as far as I can tell.
^ permalink raw reply
* [StGIT PATCH 2/2] Don't touch ref files manually
From: Karl Hasselström @ 2007-08-10 3:23 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git, Catalin Marinas, Yann Dirson
In-Reply-To: <20070810031949.19791.54562.stgit@yoghurt>
Messing with files manually doesn't work if the refs are packed. The
officially preferred way is to use git-update-ref, git-show-ref,
et.al. So do that.
As a consequence of this, we have some small behavior changes:
* We used to not leave empty directories behind in the refs tree.
But now that's all in the hands of git-update-ref, which does
leave them behind. Tests that assumed the old behavior have been
fixed.
* We (that is, git-show-ref) no longer distinguish between a ref
that doesn't exist and a ref that contains garbage. So the tests
that assumed we'd fail when encountering a spurious ref with
garbage in it have had to go through attitude readjustment.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
stgit/commands/branch.py | 5 +--
stgit/commands/common.py | 4 +-
stgit/git.py | 79 ++++++++++++++++++++++++++------------------
stgit/stack.py | 70 +++++++++++++++++++++------------------
t/t0001-subdir-branches.sh | 7 ++--
t/t1000-branch-create.sh | 30 +----------------
t/t1001-branch-rename.sh | 2 +
7 files changed, 91 insertions(+), 106 deletions(-)
diff --git a/stgit/commands/branch.py b/stgit/commands/branch.py
index 2fb5f59..75a9046 100644
--- a/stgit/commands/branch.py
+++ b/stgit/commands/branch.py
@@ -208,10 +208,7 @@ def func(parser, options, args):
if len(args) != 0:
parser.error('incorrect number of arguments')
- branches = []
- basepath = os.path.join(basedir.get(), 'refs', 'heads')
- for path, files, dirs in walk_tree(basepath):
- branches += [os.path.join(path, f) for f in files]
+ branches = git.get_heads()
branches.sort()
if branches:
diff --git a/stgit/commands/common.py b/stgit/commands/common.py
index 14dbf67..dddee85 100644
--- a/stgit/commands/common.py
+++ b/stgit/commands/common.py
@@ -42,9 +42,7 @@ def parse_rev(rev):
"""Parse a revision specification into its
patchname@branchname//patch_id parts. If no branch name has a slash
in it, also accept / instead of //."""
- files, dirs = list_files_and_dirs(os.path.join(basedir.get(),
- 'refs', 'heads'))
- if len(dirs) != 0:
+ if '/' in ''.join(git.get_heads()):
# We have branch names with / in them.
branch_chars = r'[^@]'
patch_id_mark = r'//'
diff --git a/stgit/git.py b/stgit/git.py
index 72bf889..832a2dc 100644
--- a/stgit/git.py
+++ b/stgit/git.py
@@ -270,6 +270,13 @@ def local_changes(verbose = True):
"""
return len(tree_status(verbose = verbose)) != 0
+def get_heads():
+ heads = []
+ for line in _output_lines(['git-show-ref', '--heads']):
+ m = re.match('^[0-9a-f]{40} refs/heads/(.+)$', line)
+ heads.append(m.group(1))
+ return heads
+
# HEAD value cached
__head = None
@@ -294,14 +301,16 @@ def set_head_file(ref):
# head cache flushing is needed since we might have a different value
# in the new head
__clear_head_cache()
- if __run('git-symbolic-ref HEAD',
- [os.path.join('refs', 'heads', ref)]) != 0:
+ if __run('git-symbolic-ref HEAD', ['refs/heads/%s' % ref]) != 0:
raise GitException, 'Could not set head to "%s"' % ref
+def set_ref(ref, val):
+ """Point ref at a new commit object."""
+ if __run('git-update-ref', [ref, val]) != 0:
+ raise GitException, 'Could not update %s to "%s".' % (ref, val)
+
def set_branch(branch, val):
- """Point branch at a new commit object."""
- if __run('git-update-ref', [branch, val]) != 0:
- raise GitException, 'Could not update %s to "%s".' % (branch, val)
+ set_ref('refs/heads/%s' % branch, val)
def __set_head(val):
"""Sets the HEAD value
@@ -309,7 +318,7 @@ def __set_head(val):
global __head
if not __head or __head != val:
- set_branch('HEAD', val)
+ set_ref('HEAD', val)
__head = val
# only allow SHA1 hashes
@@ -335,16 +344,15 @@ def rev_parse(git_id):
except GitException:
raise GitException, 'Unknown revision: %s' % git_id
+def ref_exists(ref):
+ try:
+ rev_parse(ref)
+ return True
+ except GitException:
+ return False
+
def branch_exists(branch):
- """Existence check for the named branch
- """
- branch = os.path.join('refs', 'heads', branch)
- for line in _output_lines('git-rev-parse --symbolic --all 2>&1'):
- if line.strip() == branch:
- return True
- if re.compile('[ |/]'+branch+' ').search(line):
- raise GitException, 'Bogus branch: %s' % line
- return False
+ return ref_exists('refs/heads/%s' % branch)
def create_branch(new_branch, tree_id = None):
"""Create a new branch in the git repository
@@ -371,8 +379,7 @@ def switch_branch(new_branch):
if not branch_exists(new_branch):
raise GitException, 'Branch "%s" does not exist' % new_branch
- tree_id = rev_parse(os.path.join('refs', 'heads', new_branch)
- + '^{commit}')
+ tree_id = rev_parse('refs/heads/%s^{commit}' % new_branch)
if tree_id != get_head():
refresh_index()
if __run('git-read-tree -u -m', [get_head(), tree_id]) != 0:
@@ -383,27 +390,33 @@ def switch_branch(new_branch):
if os.path.isfile(os.path.join(basedir.get(), 'MERGE_HEAD')):
os.remove(os.path.join(basedir.get(), 'MERGE_HEAD'))
+def delete_ref(ref):
+ if not ref_exists(ref):
+ raise GitException, '%s does not exist' % ref
+ sha1 = _output_one_line(['git-show-ref', '-s', ref])
+ if __run('git-update-ref -d %s %s' % (ref, sha1)):
+ raise GitException, 'Failed to delete ref %s' % ref
+
def delete_branch(name):
- """Delete a git branch
- """
- if not branch_exists(name):
- raise GitException, 'Branch "%s" does not exist' % name
- remove_file_and_dirs(os.path.join(basedir.get(), 'refs', 'heads'),
- name)
+ delete_ref('refs/heads/%s' % name)
-def rename_branch(from_name, to_name):
- """Rename a git branch
- """
- if not branch_exists(from_name):
- raise GitException, 'Branch "%s" does not exist' % from_name
- if branch_exists(to_name):
- raise GitException, 'Branch "%s" already exists' % to_name
+def rename_ref(from_ref, to_ref):
+ if not ref_exists(from_ref):
+ raise GitException, '"%s" does not exist' % from_ref
+ if ref_exists(to_ref):
+ raise GitException, '"%s" already exists' % to_ref
+ sha1 = _output_one_line(['git-show-ref', '-s', from_ref])
+ if __run('git-update-ref %s %s %s' % (to_ref, sha1, '0'*40)):
+ raise GitException, 'Failed to create new ref %s' % to_ref
+ if __run('git-update-ref -d %s %s' % (from_ref, sha1)):
+ raise GitException, 'Failed to delete ref %s' % from_ref
+
+def rename_branch(from_name, to_name):
+ """Rename a git branch."""
+ rename_ref('refs/heads/%s' % from_name, 'refs/heads/%s' % to_name)
if get_head_file() == from_name:
set_head_file(to_name)
- rename(os.path.join(basedir.get(), 'refs', 'heads'),
- from_name, to_name)
-
reflog_dir = os.path.join(basedir.get(), 'logs', 'refs', 'heads')
if os.path.exists(reflog_dir) \
and os.path.exists(os.path.join(reflog_dir, from_name)):
diff --git a/stgit/stack.py b/stgit/stack.py
index a54a3b2..3880a94 100644
--- a/stgit/stack.py
+++ b/stgit/stack.py
@@ -142,14 +142,16 @@ class StgitObject:
class Patch(StgitObject):
"""Basic patch implementation
"""
- def __init__(self, name, series_dir, refs_dir):
+ def __init_refs(self):
+ self.__top_ref = self.__refs_base + '/' + self.__name
+ self.__log_ref = self.__top_ref + '.log'
+
+ def __init__(self, name, series_dir, refs_base):
self.__series_dir = series_dir
self.__name = name
self._set_dir(os.path.join(self.__series_dir, self.__name))
- self.__refs_dir = refs_dir
- self.__top_ref_file = os.path.join(self.__refs_dir, self.__name)
- self.__log_ref_file = os.path.join(self.__refs_dir,
- self.__name + '.log')
+ self.__refs_base = refs_base
+ self.__init_refs()
def create(self):
os.mkdir(self._dir())
@@ -160,33 +162,31 @@ class Patch(StgitObject):
for f in os.listdir(self._dir()):
os.remove(os.path.join(self._dir(), f))
os.rmdir(self._dir())
- os.remove(self.__top_ref_file)
- if os.path.exists(self.__log_ref_file):
- os.remove(self.__log_ref_file)
+ git.delete_ref(self.__top_ref)
+ if git.ref_exists(self.__log_ref):
+ git.delete_ref(self.__log_ref)
def get_name(self):
return self.__name
def rename(self, newname):
olddir = self._dir()
- old_top_ref_file = self.__top_ref_file
- old_log_ref_file = self.__log_ref_file
+ old_top_ref = self.__top_ref
+ old_log_ref = self.__log_ref
self.__name = newname
self._set_dir(os.path.join(self.__series_dir, self.__name))
- self.__top_ref_file = os.path.join(self.__refs_dir, self.__name)
- self.__log_ref_file = os.path.join(self.__refs_dir,
- self.__name + '.log')
+ self.__init_refs()
+ git.rename_ref(old_top_ref, self.__top_ref)
+ if git.ref_exists(old_log_ref):
+ git.rename_ref(old_log_ref, self.__log_ref)
os.rename(olddir, self._dir())
- os.rename(old_top_ref_file, self.__top_ref_file)
- if os.path.exists(old_log_ref_file):
- os.rename(old_log_ref_file, self.__log_ref_file)
def __update_top_ref(self, ref):
- write_string(self.__top_ref_file, ref)
+ git.set_ref(self.__top_ref, ref)
def __update_log_ref(self, ref):
- write_string(self.__log_ref_file, ref)
+ git.set_ref(self.__log_ref, ref)
def update_top_ref(self):
top = self.get_top()
@@ -358,8 +358,7 @@ class Series(PatchSet):
# initialized, but don't touch it if it isn't.
self.update_to_current_format_version()
- self.__refs_dir = os.path.join(self._basedir(), 'refs', 'patches',
- self.get_name())
+ self.__refs_base = 'refs/patches/%s' % self.get_name()
self.__applied_file = os.path.join(self._dir(), 'applied')
self.__unapplied_file = os.path.join(self._dir(), 'unapplied')
@@ -416,20 +415,22 @@ class Series(PatchSet):
def rm(f):
if os.path.exists(f):
os.remove(f)
+ def rm_ref(ref):
+ if git.ref_exists(ref):
+ git.delete_ref(ref)
# Update 0 -> 1.
if get_format_version() == 0:
mkdir(os.path.join(branch_dir, 'trash'))
patch_dir = os.path.join(branch_dir, 'patches')
mkdir(patch_dir)
- refs_dir = os.path.join(self._basedir(), 'refs', 'patches', self.get_name())
- mkdir(refs_dir)
+ refs_base = 'refs/patches/%s' % self.get_name()
for patch in (file(os.path.join(branch_dir, 'unapplied')).readlines()
+ file(os.path.join(branch_dir, 'applied')).readlines()):
patch = patch.strip()
os.rename(os.path.join(branch_dir, patch),
os.path.join(patch_dir, patch))
- Patch(patch, patch_dir, refs_dir).update_top_ref()
+ Patch(patch, patch_dir, refs_base).update_top_ref()
set_format_version(1)
# Update 1 -> 2.
@@ -441,7 +442,7 @@ class Series(PatchSet):
config.set('branch.%s.description' % self.get_name(), desc)
rm(desc_file)
rm(os.path.join(branch_dir, 'current'))
- rm(os.path.join(self._basedir(), 'refs', 'bases', self.get_name()))
+ rm_ref('refs/bases/%s' % self.get_name())
set_format_version(2)
# Make sure we're at the latest version.
@@ -458,7 +459,7 @@ class Series(PatchSet):
def get_patch(self, name):
"""Return a Patch object for the given name
"""
- return Patch(name, self.__patch_dir, self.__refs_dir)
+ return Patch(name, self.__patch_dir, self.__refs_base)
def get_current_patch(self):
"""Return a Patch object representing the topmost patch, or
@@ -580,7 +581,7 @@ class Series(PatchSet):
"""
if self.is_initialised():
raise StackException, '%s already initialized' % self.get_name()
- for d in [self._dir(), self.__refs_dir]:
+ for d in [self._dir()]:
if os.path.exists(d):
raise StackException, '%s already exists' % d
@@ -593,7 +594,6 @@ class Series(PatchSet):
self.create_empty_field('applied')
self.create_empty_field('unapplied')
- os.makedirs(self.__refs_dir)
self._set_field('orig-base', git.get_head())
config.set(self.format_version_key(), str(FORMAT_VERSION))
@@ -606,14 +606,18 @@ class Series(PatchSet):
if to_stack.is_initialised():
raise StackException, '"%s" already exists' % to_stack.get_name()
+ patches = self.get_applied() + self.get_unapplied()
+
git.rename_branch(self.get_name(), to_name)
+ for patch in patches:
+ git.rename_ref('refs/patches/%s/%s' % (self.get_name(), patch),
+ 'refs/patches/%s/%s' % (to_name, patch))
+ git.rename_ref('refs/patches/%s/%s.log' % (self.get_name(), patch),
+ 'refs/patches/%s/%s.log' % (to_name, patch))
if os.path.isdir(self._dir()):
rename(os.path.join(self._basedir(), 'patches'),
self.get_name(), to_stack.get_name())
- if os.path.exists(self.__refs_dir):
- rename(os.path.join(self._basedir(), 'refs', 'patches'),
- self.get_name(), to_stack.get_name())
# Rename the config section
config.rename_section("branch.%s" % self.get_name(),
@@ -715,9 +719,9 @@ class Series(PatchSet):
% self._dir())
try:
- os.removedirs(self.__refs_dir)
- except OSError:
- out.warn('Refs directory %s is not empty' % self.__refs_dir)
+ git.delete_branch(self.get_name())
+ except GitException:
+ out.warn('Could not delete branch "%s"' % self.get_name())
# Cleanup parent informations
# FIXME: should one day make use of git-config --section-remove,
diff --git a/t/t0001-subdir-branches.sh b/t/t0001-subdir-branches.sh
index fac6339..1685233 100755
--- a/t/t0001-subdir-branches.sh
+++ b/t/t0001-subdir-branches.sh
@@ -50,10 +50,11 @@ test_expect_success 'Create patch in slashy branch' \
test_expect_success 'Rename branches' \
'stg branch --rename master goo/gaa &&
- test ! -e .git/refs/heads/master &&
+ ! git show-ref --verify --quiet refs/heads/master &&
stg branch --rename goo/gaa x1/x2/x3/x4 &&
- test ! -e .git/refs/heads/goo &&
+ ! git show-ref --verify --quiet refs/heads/goo/gaa &&
stg branch --rename x1/x2/x3/x4 servant &&
- test ! -e .git/refs/heads/x1'
+ ! git show-ref --verify --quiet refs/heads/x1/x2/x3/x4
+'
test_done
diff --git a/t/t1000-branch-create.sh b/t/t1000-branch-create.sh
index cca5504..e920e93 100755
--- a/t/t1000-branch-create.sh
+++ b/t/t1000-branch-create.sh
@@ -13,26 +13,9 @@ Exercises the "stg branch" commands.
stg init
test_expect_success \
- 'Create a spurious refs/patches/ entry' '
- find .git -name foo | xargs rm -rf &&
- touch .git/refs/patches/foo
-'
-
-test_expect_failure \
- 'Try to create an stgit branch with a spurious refs/patches/ entry' '
- stg branch -c foo
-'
-
-test_expect_success \
- 'Check that no part of the branch was created' '
- test "`find .git -name foo | tee /dev/stderr`" = ".git/refs/patches/foo" &&
- ( grep foo .git/HEAD; test $? = 1 )
-'
-
-test_expect_success \
'Create a spurious patches/ entry' '
find .git -name foo | xargs rm -rf &&
- touch .git/patches/foo
+ mkdir -p .git/patches && touch .git/patches/foo
'
test_expect_failure \
@@ -69,15 +52,4 @@ test_expect_success \
touch .git/refs/heads/foo
'
-test_expect_failure \
- 'Try to create an stgit branch with an invalid refs/heads/ entry' '
- stg branch -c foo
-'
-
-test_expect_success \
- 'Check that no part of the branch was created' '
- test "`find .git -name foo | tee /dev/stderr`" = ".git/refs/heads/foo" &&
- ( grep foo .git/HEAD; test $? = 1 )
-'
-
test_done
diff --git a/t/t1001-branch-rename.sh b/t/t1001-branch-rename.sh
index 28da15c..4e1ec84 100755
--- a/t/t1001-branch-rename.sh
+++ b/t/t1001-branch-rename.sh
@@ -26,7 +26,7 @@ test_expect_success \
'Rename an stgit branch' \
'stg branch -c buz &&
stg branch -r foo bar &&
- test -z `find .git -name foo | tee /dev/stderr`
+ [ -z $(find .git -type f | grep foo | tee /dev/stderr) ]
'
test_done
^ permalink raw reply related
* [StGIT PATCH 0/2] Teach StGIT to survive git-gc
From: Karl Hasselström @ 2007-08-10 3:23 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git, Catalin Marinas, Yann Dirson
In-Reply-To: <20070809203957.GA14441@diana.vm.bytemark.co.uk>
... and here's the fix, and a test.
Note that while this is fairly intrusive (and took quite some time to
debug), it's also a rather high-priority fix, since git-gc will break
StGIT just fine even without the DAG patches.
You can also get this from git://repo.or.cz/stgit/kha.git.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [StGIT PATCH 1/2] New test: make sure that StGIT can handle packed refs
From: Karl Hasselström @ 2007-08-10 3:23 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git, Catalin Marinas, Yann Dirson
In-Reply-To: <20070810031949.19791.54562.stgit@yoghurt>
It currently can't, which is why this test is needed. The situation
has recently taken a turn for the worse, since git-gc nowadays packs
refs by default.
---
t/t1004-pack-ref.sh | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/t/t1004-pack-ref.sh b/t/t1004-pack-ref.sh
new file mode 100755
index 0000000..a5eb17c
--- /dev/null
+++ b/t/t1004-pack-ref.sh
@@ -0,0 +1,24 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Karl Hasselström
+#
+
+test_description='Test that StGIT can handle packed refs'
+
+. ./test-lib.sh
+stg init
+
+test_expect_success \
+ 'Pack refs and make sure that we can still see them' '
+ stg branch -c foo &&
+ [ $(stg branch -l | tee /dev/stderr | wc -l) -eq 2 ] &&
+ git pack-refs --all &&
+ [ $(stg branch -l | tee /dev/stderr | wc -l) -eq 2 ]
+'
+
+test_expect_success \
+ 'Try to delete a branch whose ref has been packed' '
+ stg branch -d master
+'
+
+test_done
^ permalink raw reply related
* git-p4 question
From: Govind Salinas @ 2007-08-10 2:53 UTC (permalink / raw)
To: git
Hi All,
Me again with more dumb git-perforce questions.
I have been toying with git-p4 and I think it does everything I want
except the crazy client map support. I figure I don't really need
this. My client is something like this:
//depot/sane/... //clientroot/crazy/...
//depot/stuff/... //clientroot/dumb/...
//depot/otherstuff/... //clientroot/dumb/...
//depot/my/product/... //clientroot/src/realworkhere/...
My "working directory" looks something like this:
c:\path\crazy\xyz_from_perforce
c:\path\crazy\abc_from_huge_binary_fileshare_notinp4
c:\path\dumb\...
c:\path\src\realworkhere\...
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.
Is this at all possible to do with git-p4?
If not, what sort of work would be necessary to add that (considering
that I am a git noob).
Thanks for the help.
-Govind
^ permalink raw reply
* Re: git and linux kernel source
From: Joe Perches @ 2007-08-10 1:59 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20070809231718.GH12875@fieldses.org>
On Thu, 2007-08-09 at 19:17 -0400, J. Bruce Fields wrote:
> > Is there a way to separate the resultant single patch into multiple
> > patches by subdirectory? Perhaps some git-rev-parse option?
> Something like
> for each sub/dir:
> git add sub/dir
> git commit -m "use bar not foo in sub/dir"
> should do it. (Of course, in the particular case above the patches you
> ended up with probably wouldn't compile individually.)
Nor would it likely survive a git bisect, but it's a start.
My goal is to eventually commit by maintainer.
Thanks, Joe
^ 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