* stgit truncates binary files to zero length when applying patches
From: Karl Hasselström @ 2005-11-15 14:42 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
When applying patches and not fast-forwarding, stgit truncates the
binary files to zero length:
$ cg-init .
defaulting to local storage area
Committing initial tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
Committed as 73161b6ee428ac8b1c1b16b560c40e13330693d2.
$ stg init
$ stg new foo
Invoking the editor: "emacs .stgit.msg"... done (exit code: 0)
$ cp /bin/bash .
$ stg add bash
$ stg refresh
Refreshing patch "foo"... done
$ ls -l
total 584
-rwxr-xr-x 1 kha vtech 593304 Nov 15 15:34 bash*
$ stg pop
Popping patch "foo"... done
No patches applied
$ stg new bar
Invoking the editor: "emacs .stgit.msg"... done (exit code: 0)
$ echo bar > bar.txt
$ stg add bar.txt
$ stg refresh
Refreshing patch "bar"... done
$ stg push foo
Pushing patch "foo"... done
Now at patch "foo"
$ ls -l
total 4
-rw-r--r-- 1 kha vtech 4 Nov 15 15:34 bar.txt
-rwxr-xr-x 1 kha vtech 0 Nov 15 15:35 bash*
Without the "bar" patch, popping and then pushing "foo" works as
expected.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] git-core-foo -> git-foo, except the core package
From: Josh Boyer @ 2005-11-15 14:41 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <43797C41.2050809@zytor.com>
On 11/15/05, H. Peter Anvin <hpa@zytor.com> wrote:
> This patch renames the tarball "git" rather than "git-core", and changes
> the names of various packages from git-core-foo to git-foo. git-core is
> still the true core package; an empty RPM package named "git" pulls in
> ALL the git packages -- this makes updates work correctly, and allows
> "yum install git" to do the obvious thing.
What about "yum remove git" ? I don't think that will work quite so
well. The "git" package will be removed just fine since nothing
depends on it, but git-<foo> will still remain. Maybe not that big of
a deal, but it might not be obvious to some.
Also, what about http://www.gnu.org/software/git/git.html ? I seem to
recall that was the reason the name git-core was used in the first
place.
josh
^ permalink raw reply
* Re: [PATCH] Disable USE_SYMLINK_HEAD by default
From: Johannes Schindelin @ 2005-11-15 14:24 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, Pavel Roskin, git
In-Reply-To: <20051115121854.GV30496@pasky.or.cz>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1796 bytes --]
Hi,
On Tue, 15 Nov 2005, Petr Baudis wrote:
> Dear diary, on Tue, Nov 15, 2005 at 12:09:42PM CET, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> > I think Junio is right: we should not force everybody not to use
> > symlinks, only because there happens to be VFAT-, SMB- or HTTP-shared
> > repositories. As Junio says, if there are people experiencing problems
> > because they lack symbolic links, they should fix it.
>
> I'm ambivalent here. I would like to have just a single behaviour here,
> since the symbolic ref otherwise really does not get much testing. But I
> can also understand that we are breaking tools here.
>
> Still, for the reason above, I think we should aim at the symbolic refs
> being the canonical format in the next major release after 1.0, giving
> users time to fix their tools. I can see no advantage in symlinks except
> the backwards compatibility - speed argument was presented, but I don't
> buy that until I see hard data supporting that.
<yousortofaskedforit>
Well, I can see no good reason for symrefs, except for backwards
compatibility! Modern systems do support symlinks, you know?
Let´s face it. The main target for git is not Windows users. If we really
want to support all idiocies of all possible ones, how about this one:
If I clone a repository to a USB stick on cygwin, and try to access it
from my iBook, it does not work, because for *backward compatibility*
reasons, files fitting the 8.3 format are stored in UPPER CASE.
So, I would like to have support for UPPER CASE files in .git, please? And
since I cannot do my own testing, please could you force everybody´s git
to write OBJECTS and MASTER in UPPER CASE?
</yousortofaskedforit>
Ciao,
Dscho
^ permalink raw reply
* [RFC] Add support for short help to Cogito commands
From: Jonas Fonseca @ 2005-11-15 12:55 UTC (permalink / raw)
To: git
Hi,
I hope I am not the only one feeling that -h can sometimes be a little
too verbose when you want to have a quick overview of a Cogito command.
I'd like to make -h show only a short summary of the available options
and keep the longer help text for --help. I have attached a patch that
does something like this. Example:
$ cg diff -h
Usage: cg-diff [-c] [-m] [-s] [-p] [-r FROM_ID[..TO_ID]] [FILE]...
Options:
-c Colorize the diff output
-p Use parent commit to specified ID
-s Summarize the diff
-r FROM_ID[..TO_ID] Specify the revisions to diff
-m Base the diff at the merge base of specified revision
-h Print short usage help
--help Print long usage help
If something like this is acceptable, I'd like to know how to proceed
with improving the option captions. I've considered two possibilities:
- Get the caption from the first line of the option description. This
is similar to what the patch does (it also roughly removes everything
after the first punctuation char). But it will require that all
option descriptions are changed to have a one line caption at the
start. Example:
# ...
#
# -r FROM_ID[..TO_ID]::
# Specify revisions to diff. Revisions can be specified
# using either '-r rev1 ...
- Add a special line with the caption. Since we already 'filters' the
help text in the script headers this could go after the '::'.
Example:
# ...
#
# -r FROM_ID[..TO_ID]:: Specify revisions to diff
# Specify the revisions to diff using either '-r rev1
# ...
So that it will be easy to remove from the --help output and from the
generated manpages.
The last option is less intrusive, but does make the syntax of the
script headers less clean. Comments?
diff --git a/cg-Xlib b/cg-Xlib
index fa3a059..a1c89dc 100755
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -347,18 +347,39 @@ deprecated_alias()
print_help()
{
- which "cg-$1" >/dev/null 2>&1 || exit 1
+ which "cg-$2" >/dev/null 2>&1 || exit 1
sed -n '/^USAGE=/,0s/.*"\(.*\)"/Usage: \1/p;
- /^deprecated_alias/,0s/^deprecated_alias \([^ ]*\)/\1 is the new name for/p' < $(which cg-$1)
+ /^deprecated_alias/,0s/^deprecated_alias \([^ ]*\)/\1 is the new name for/p' < $(which cg-$2)
echo
- sed -n '3,/^$/s/^# *//p' < $(which cg-$1)
+ if [ x"$1" = xshort ]; then
+ echo "Options:"
+ _cg_fmt=" %-20s %s\n"
+ sed -n '/# \(-.*::\)/,/^#/s/#//p' < $(which cg-$2) | while read line; do
+ case "$line" in
+ -*::)
+ _cg_option="$(echo -n " $line" | sed 's/ \(-.*\)::/\1/')"
+ ;;
+ *)
+ printf "$_cg_fmt" "$_cg_option" \
+ "$(echo "$line" | sed 's/\([^-][^.,]*\)[.,].*/\1/')"
+ _cg_option=
+ ;;
+ esac
+ done
+ printf "$_cg_fmt" "-h" "Print short usage help"
+ printf "$_cg_fmt" "--help" "Print long usage help"
+ else
+ sed -n '3,/^$/s/^# *//p' < $(which cg-$2)
+ fi
exit
}
for option in "$@"; do
[ x"$option" = x-- ] && break
- if [ x"$option" = x"-h" -o x"$option" = x"--help" ]; then
- print_help ${_cg_cmd##cg-}
+ if [ x"$option" = x"-h" ]; then
+ print_help short ${_cg_cmd##cg-}
+ elif [ x"$option" = x"--help" ]; then
+ print_help long ${_cg_cmd##cg-}
fi
done
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH] Fix git(1) link to git-index-pack
From: Jonas Fonseca @ 2005-11-15 12:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
I noticed this broken link in the git docs @ kernel.org ...
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 7045f3f..bd389bd 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -67,7 +67,7 @@ gitlink:git-commit-tree[1]::
gitlink:git-hash-object[1]::
Computes the object ID from a file.
-gitlink:git-index-pack.html[1]::
+gitlink:git-index-pack[1]::
Build pack index file for an existing packed archive.
gitlink:git-init-db[1]::
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH] Introduce cg-version.in template
From: Jonas Fonseca @ 2005-11-15 12:23 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
diff --git a/Makefile b/Makefile
index 72d7d12..700491f 100644
--- a/Makefile
+++ b/Makefile
@@ -37,24 +37,14 @@ cogito: $(GEN_SCRIPT)
ifneq (,$(wildcard .git))
GIT_HEAD=.git/$(shell git-symbolic-ref HEAD)
-GIT_HEAD_ID=" \($(shell cat $(GIT_HEAD))\)"
+GIT_HEAD_ID=($(shell cat $(GIT_HEAD)))
endif
-cg-version: $(VERSION) $(GIT_HEAD) Makefile
+cg-version: cg-version.in $(VERSION) $(GIT_HEAD)
@echo Generating cg-version...
@rm -f $@
- @echo "#!/bin/sh" > $@
- @echo "#" >> $@
- @echo "# Show the version of the Cogito toolkit." >> $@
- @echo "# Copyright (c) Petr Baudis, 2005" >> $@
- @echo "#" >> $@
- @echo "# Show which version of Cogito is installed." >> $@
- @echo "# Additionally, the 'HEAD' of the installed Cogito" >> $@
- @echo "# is also shown if this information was available" >> $@
- @echo "# at the build time." >> $@
- @echo >> $@
- @echo "USAGE=\"cg-version\"" >> $@
- @echo >> $@
- @echo "echo \"$(shell cat $(VERSION))$(GIT_HEAD_ID)\"" >> $@
+ @sed -e 's/@@VERSION@@/$(shell cat $(VERSION))/' \
+ -e 's/@@GIT_HEAD_ID@@/$(GIT_HEAD_ID)/' \
+ < $< > $@
@chmod +x $@
doc:
diff --git a/cg-version.in b/cg-version.in
new file mode 100644
index 0000000..369818e
--- /dev/null
+++ b/cg-version.in
@@ -0,0 +1,16 @@
+#!/usr/bin/env bash
+#
+# Show the version of the Cogito toolkit.
+# Copyright (c) Petr Baudis, 2005
+#
+# Show which version of Cogito is installed.
+# Additionally, the 'HEAD' of the installed Cogito
+# is also shown if this information was available
+# at the build time.
+
+USAGE="cg-version"
+_git_repo_unneeded=1
+
+. ${COGITO_LIB}cg-Xlib || exit 1
+
+echo "@@VERSION@@ @@GIT_HEAD_ID@@"
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 4fe009a..3aad2fb 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -1,4 +1,4 @@
-CG_IGNORE=$(wildcard ../cg-X* ../cg-*.orig ../cg-*.rej)
+CG_IGNORE=$(wildcard ../cg-X* ../cg-*.orig ../cg-*.rej ../cg-*.in)
CG_SRC=$(filter-out $(CG_IGNORE), $(wildcard ../cg*))
PACKAGE=cogito
--
Jonas Fonseca
^ permalink raw reply related
* Re: [PATCH] Disable USE_SYMLINK_HEAD by default
From: Petr Baudis @ 2005-11-15 12:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Pavel Roskin, git
In-Reply-To: <Pine.LNX.4.63.0511151207070.21671@wbgn013.biozentrum.uni-wuerzburg.de>
Dear diary, on Tue, Nov 15, 2005 at 12:09:42PM CET, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> I think Junio is right: we should not force everybody not to use symlinks,
> only because there happens to be VFAT-, SMB- or HTTP-shared repositories.
> As Junio says, if there are people experiencing problems because they lack
> symbolic links, they should fix it.
I'm ambivalent here. I would like to have just a single behaviour here,
since the symbolic ref otherwise really does not get much testing. But I
can also understand that we are breaking tools here.
Still, for the reason above, I think we should aim at the symbolic refs
being the canonical format in the next major release after 1.0, giving
users time to fix their tools. I can see no advantage in symlinks except
the backwards compatibility - speed argument was presented, but I don't
buy that until I see hard data supporting that.
> On the other hand, I think it would be useful to be able to configure the
> behaviour via .git/config.
Yes, I would very much like to have this. I still want to go
symrefs-only for public repositories created for cg-admin-setuprepo, so
that fetching over HTTP works properly.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* [PATCH] Fix cg-version -h by sourcing cg-Xlib
From: Jonas Fonseca @ 2005-11-15 12:03 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
Also requires cg-version to become a bash script.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
diff --git a/Makefile b/Makefile
index 72d7d12..b18e79f 100644
--- a/Makefile
+++ b/Makefile
@@ -42,7 +42,7 @@ endif
cg-version: $(VERSION) $(GIT_HEAD) Makefile
@echo Generating cg-version...
@rm -f $@
- @echo "#!/bin/sh" > $@
+ @echo "#!/usr/bin/env bash" >> $@
@echo "#" >> $@
@echo "# Show the version of the Cogito toolkit." >> $@
@echo "# Copyright (c) Petr Baudis, 2005" >> $@
@@ -53,6 +53,9 @@ cg-version: $(VERSION) $(GIT_HEAD) Makef
@echo "# at the build time." >> $@
@echo >> $@
@echo "USAGE=\"cg-version\"" >> $@
+ @echo "_git_repo_unneeded=1" >> $@
+ @echo >> $@
+ @echo ". \$${COGITO_LIB}cg-Xlib || exit 1" >> $@
@echo >> $@
@echo "echo \"$(shell cat $(VERSION))$(GIT_HEAD_ID)\"" >> $@
@chmod +x $@
@@ -92,7 +95,7 @@ install-cogito: $(SCRIPT) $(LIB_SCRIPT)
$(INSTALL) -m755 -d $(DESTDIR)$(libdir)
$(INSTALL) $(LIB_SCRIPT) $(DESTDIR)$(libdir)
cd $(DESTDIR)$(bindir); \
- for file in $(SCRIPT); do \
+ for file in $(SCRIPT) $(GEN_SCRIPT); do \
sed -e 's/\$${COGITO_LIB}/"\$${COGITO_LIB:-$(sedlibdir)\/}"/g' $$file > $$file.new; \
cat $$file.new > $$file; rm $$file.new; \
done
--
Jonas Fonseca
^ permalink raw reply related
* Re: pushing patches to an imap folder
From: Johannes Schindelin @ 2005-11-15 11:36 UTC (permalink / raw)
To: Mike McCormack; +Cc: Junio C Hamano, git
In-Reply-To: <4379B9F6.5020402@codeweavers.com>
Hi,
On Tue, 15 Nov 2005, Mike McCormack wrote:
> Junio C Hamano wrote:
>
> > Hmph. How well does the rest of git help your workflow, working with
> > the Wine community? Especially, how are you keeping track of and
> > interoperating with their main CVS repository?
>
> We have a (semi-experimental) wine.git tree, which is updated at the
> same time as the Wine CVS, by the project maintainer:
>
> http://source.winehq.org/git/wine.git
This is cool! I used to track wine with "git-cvsimport -i".
My work flow was like this (not with wine, since I did not have enough
time to hack on it in the last months, but with other CVS managed
projects):
"git-cvsimport -i" every once in a while, followed by "git pull . origin"
(my working branch is always master).
When I have something interesting, I make a topic branch from origin ("git
checkout -b eyes_apple origin"), and pick the interesting commits from
master ("git cherry-pick SHA1").
Sometimes I pick multiple commits with the "-n" flag, so that I can hide
my shortcomings, committing with the message of the first commit ("git
commit -C SHA1").
Then, I use git-format-patch to generate the patches, which I hand-edit to
make sure there is no typo, and no unwanted changes slipped in. Then, I
send the message(s).
> It will probably be maintained in parallel with the Wine CVS for a while,
> unless somebody writes a GIT->CVS gateway.
It would be cool to have something like git-cvs-daemon, which simulates a
CVS server.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Small script to patch .spec for Suse
From: Josef Weidendorfer @ 2005-11-15 11:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Everytime I update and want to generate RPM packages for
my Suse distribution, I have to patch the git-core.spec.in
Here is the current script for patching. It is only about
package names, so a seperate .spec file would
be overkill and a maintenance problem for me.
Usage: Run contrib/patch-spec-for-suse before "make rpm"
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
---
This is handy for Suse users which want to install Git by creating
there own RPM from source. It works for me (on Suse 10.0).
I hope it works for other versions, too.
Perhaps somebody has a better idea how to come up with
corrected .spec files for different distros.
contrib/patch-spec-for-suse | 29 +++++++++++++++++++++++++++++
1 files changed, 29 insertions(+), 0 deletions(-)
create mode 100755 contrib/patch-spec-for-suse
applies-to: 4b6dbe856a3e63699b299c76f4f1fc5cb34cbe26
3e0d98b8065c7a23c6b9a16811bb7b066b13bffc
diff --git a/contrib/patch-spec-for-suse b/contrib/patch-spec-for-suse
new file mode 100755
index 0000000..5b9795c
--- /dev/null
+++ b/contrib/patch-spec-for-suse
@@ -0,0 +1,29 @@
+#!/bin/sh
+#
+# The git-core.spec for RPM creation in the git source works
+# fine for fedora core, but not other distributions.
+# This script patches some distribution dependent package names
+# to make it work for Suse (at least 10.0)
+#
+# Run it from gits main directory like
+# contrib/patch-for-suse
+# Note! This changes git-core.spec.in. So if you do git development
+# yourself, do *not* commit the changed file, or revert before with
+# mv git-core.spec.in.orig git-core.spec.in
+#
+
+[ ! -f git-core.spec.in ] && echo "git-core.spec.in not found!" && exit 1
+cp git-core.spec.in git-core.spec.in.orig
+
+# Updates for Suse:
+# - no seperate "openssh-clients"
+# - "expat" contains devel files
+
+cat git-core.spec.in \
+ | sed -e 's/openssh-clients/openssh/' \
+ | sed -e 's/expat-devel/expat/' \
+ > git-core.spec.temp
+
+mv git-core.spec.temp git-core.spec.in
+echo "git-core.spec.in sucessfully patched."
+
---
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH] Disable USE_SYMLINK_HEAD by default
From: Johannes Schindelin @ 2005-11-15 11:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pavel Roskin, git
In-Reply-To: <7vd5l2mco1.fsf@assigned-by-dhcp.cox.net>
Hi,
I think Junio is right: we should not force everybody not to use symlinks,
only because there happens to be VFAT-, SMB- or HTTP-shared repositories.
As Junio says, if there are people experiencing problems because they lack
symbolic links, they should fix it.
On the other hand, I think it would be useful to be able to configure the
behaviour via .git/config.
Ciao,
Dscho
^ permalink raw reply
* Re: pushing patches to an imap folder
From: Mike McCormack @ 2005-11-15 10:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5l2qnq6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Hmph. How well does the rest of git help your workflow, working
> with the Wine community? Especially, how are you keeping track
> of and interoperating with their main CVS repository?
We have a (semi-experimental) wine.git tree, which is updated at the
same time as the Wine CVS, by the project maintainer:
http://source.winehq.org/git/wine.git
It will probably be maintained in parallel with the Wine CVS for a
while, unless somebody writes a GIT->CVS gateway.
I find git-rebase to be particularly useful. When I used CVS, sending a
series of patches was a pain. I'd contemplated using quilt, but never
got round to trying it.
Pushing patches from git into a drafts folder means I don't have to
manually generate a diff, open a mail, type the mailing list address,
attach the patch and write/copy-paste a ChangeLog entry.
> Do you
> have to do anything special when your patches are accepted by
> the upstream and echoed back to you when you 'cvs update' from
> them next time?
"git pull" is usually sufficient.
Mike
^ permalink raw reply
* Re: [PATCH] Disable USE_SYMLINK_HEAD by default
From: Catalin Marinas @ 2005-11-15 10:31 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Junio C Hamano, git
In-Reply-To: <1132042427.3512.50.camel@dv>
Pavel Roskin <proski@gnu.org> wrote:
> On Mon, 2005-11-14 at 23:03 -0800, Junio C Hamano wrote:
>> The one format is that .git/HEAD can either be a symlink or
>> regular file text symref; both variants are tested -- wouldn't
>> that be good enough?
>
> No. Even if git itself is tested, other tools are not. What's worse,
> the developers of those tools don't even know they are supposed to test
> for two HEAD formats unless they track git changes and mailing lists
> very carefully.
>
> In particular, StGIT still needs fixing.
StGIT has been fixed for this in the latest snapshot (but not in the
latest release). It now uses "git-symbolic-ref HEAD" to get the name
of the current branch.
--
Catalin
^ permalink raw reply
* Re: [PATCH] Disable USE_SYMLINK_HEAD by default
From: Junio C Hamano @ 2005-11-15 10:24 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <7vpsp2qpx4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Pavel Roskin <proski@gnu.org> writes:
>
>> In particular, StGIT still needs fixing.
>>> ...
>> I'm talking from my experience now. If there is an option, there are
>> users that have it enabled and those who have it disabled (by
>> definition). As is often happens, one of the configurations is more
>> popular with developers. The other configuration almost inevitably
>> starts suffering from the "bit rot".
>
> That's a real concern, I should agree.
I think I need to qualify this comment. It is a real concern
because we need to know when it is safe to start using textual
symrefs everywhere, *if* we would want to do that switch.
I wonder how ready StGIT and Cogito are, but also I wonder how
ready other things are. People built homebrew scripts around
git without calling them Porcelains, and git is designed to be
used that way. We do not know how many things we are breaking
if we switch to do textual symrefs by default.
I just checked the latest gitweb, and it does not seem to be
ready. I do not, however, necessarily think it is a high
priority problem. It does not feel to me a realistic issue that
you cannot serve a public repository on a filesystem incapable
of symlinks via getweb. This change is breaking things for
gitweb running on kernel.org machines without real benefit.
Thinking about it a bit more, the current setup to use symlinks
on systems that supports them, and textual symrefs on others, is
looking more and more sensible to me. If supporting
symlink-challenged filesystems become a real issue for a "third
party tool", certainly that will be updated, because people
would want it. Switching to do textual symrefs by default
everywhere is a way to *force* people to scramble and update
their scripts everywhere, but I am not so sure that is worth it;
I cannot justify why I'd be forcing them to do so, especially if
supporting VFAT is a low priority for some of the tools.
"Bit rot" may first seem a concern, but actually it is not. I
suspect that serverish applications such as gitweb view
supporting symlink-challenged filesystems as a lower priority
task, while more client-oriented applications rate it higher.
The core support for textual symrefs cannot afford to rot as
long as some Porcelain needs it, and worrying about it would not
be a good justification to break everybody "just to see what
breaks". On the other hand, if the support for textual symrefs
rot, it probably deserves to --- the only reason that would
happen would be because nobody uses them.
IOW, if we see real breakage in either git itself or Porcelains
that use git, send in fixes to appropriate parties. I think
that's being constructive. Otherwise, let's not break things
just for the sake of consistency. I do not think that is
helping anything.
^ permalink raw reply
* Re: [PATCH] GIT commit statistics.
From: Catalin Marinas @ 2005-11-15 10:04 UTC (permalink / raw)
To: Petr Baudis
Cc: Martin Langhoff, Junio C Hamano, Ryan Anderson, Linus Torvalds,
git
In-Reply-To: <20051112125331.GB30496@pasky.or.cz>
On 12/11/05, Petr Baudis <pasky@suse.cz> wrote:
> On the same note, I would like StGIT to drop functionality not really
> belonging to patch stack manager (stg add, stg rm, stg status, ...) so
> that its commandset gets smaller and more focused
This was the case with the first StGIT implementations but I slowly
began to want to only use StGIT and not switch to something else for
trivial SCM operations. I eventually added 'stg commit' which stores
the patches permanently into the base of the stack to enable some kind
of maintainer mode for StGIT. My main use for this was to import
patches directly into the main branch and not keep a separate one and
pull between them.
> - but before I would
> suggest dropping stg status, cg-status must be able to do conflicts
> tracking, so I will dedicate another mail to this sometime in the
> future, with a more detailed proposal.
The gitmergeonefile.py script in StGIT adds every conflict to the
.git/conflicts file which is read by 'stg status'. My goal is not to
leave any unmerged entried in the index even if there are conflicts.
Maybe this could be changed and .git/conflicts file avoided entirely.
Anyway, while I'll try not to add more SCM functionality to StGIT, I
don't think I should remove the existing add/rm/status functionality.
It's just handy not to use a different command when you want a new
file added to a patch.
--
Catalin
^ permalink raw reply
* Re: [PATCH] Stgit - gitmergeonefile.py: handle removal vs. changes
From: Catalin Marinas @ 2005-11-15 9:54 UTC (permalink / raw)
To: Paolo 'Blaisorblade' Giarrusso; +Cc: git
In-Reply-To: <20051113194225.20447.57910.stgit@zion.home.lan>
On 13/11/05, Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> wrote:
> I just got a "removal vs. changed" conflict, which is unhandled by StGit. That
> is taken from git-merge-one-file resolver, but is bad, as stg resolved does not
> handle unmerged entries (and probably it should be fixed too).
I think it 'stg resolved' should be fixed as well (in case there are
unmerged entries for other reasons). My initial idea was to make
gitmergeonefile not to leave any unmerged entries in the index. As you
could see, there are cases where it failed.
I can see the following scenarios for a file:
1. deleted in the base and modified by the patch. It should leave the
file in the tree together with file.older. Another option would be to
remove the file and leave both file.older and file.remote in the tree
(here .remote means the version in the patch) but I would prefer the
first one.
2. changed in the base but deleted by the patch. It should remove the
file from the tree but leave file.older and file.local. The other
option is to leave the file in the tree but, as above, I prefer the
first one.
Maybe StGIT should try to track the renaming as well but I haven't
played with this feature in GIT at all.
--
Catalin
^ permalink raw reply
* Re: pushing patches to an imap folder
From: Junio C Hamano @ 2005-11-15 9:12 UTC (permalink / raw)
To: Mike McCormack; +Cc: git
In-Reply-To: <43799A67.9030705@codeweavers.com>
Mike McCormack <mike@codeweavers.com> writes:
> I hacked up git-format-patch and isync to create a program to push
> patches from git into an imap folder. This improve my workflow with git
> quite a bit.
Hmph. How well does the rest of git help your workflow, working
with the Wine community? Especially, how are you keeping track
of and interoperating with their main CVS repository? Do you
have to do anything special when your patches are accepted by
the upstream and echoed back to you when you 'cvs update' from
them next time?
^ permalink raw reply
* Re: [Question] info/grafts file.
From: Alan Chandler @ 2005-11-15 8:31 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <20051115000349.GA32136@hpsvcnb.fc.hp.com>
On Tuesday 15 Nov 2005 00:03, Carl Baldwin wrote:
> This is fine, I just needed to know.
>
> How hard is it to, in a generic way, take a grafts file and reconstruct
> commits to include the parents in the graft file in the actual tree? I
> am wondering because I couldn't, after much work, get git-svnimport to
> find my merges correctly. So, I am needing to hand-graft some merges in
> to make things right. Any suggestions? I could try to figure something
> out if I can find some time. I'm good with graph traversals and such.
>
I am interested in that question as well. If you recall I was asking on this
list about a week ago how to lose history (because it was irrelevent).
I at first attemtped to use a graft to bypass all the changes I wanted to
loose, but as many of the tools ignored it I gave up. When I looked at
whether I could change the history by making a commit that looked like the
graft, I came to the conclusion that I would have to do a number of things
a) Recreate the commits all the way to the head - because the commits where
all stored in a content addressable file store, as soon as the parent link
changes it becomes a new commit with a new sha1, so changing a commit in the
middle of a stream of branches effectively required you to walk up to the
head (difficult because the linkages are the other way) re-creating new
commits.
b) Understand the topology of all the interlinking commits, and make sure that
the two commits I were trying to squash together didn't have any intermediate
commits that effectively pointed outside of this space (and when I say
"pointed" I mean either via a parent link, OR via a reverse virtual link when
some other commits parent link pointed at the commit in question).
Because of all of this complexity I gave up and used cg-merge -squash to
create the first stage squashed branch and then manually used git-cherry-pick
to pick one by one the commits from on top of the old branch and move it to
the new one (not so hard there were only about 20 commits in all to move that
way).
So I am interested to see if my logic for why the complexity was high was
correct.
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* Re: [PATCH] Disable USE_SYMLINK_HEAD by default
From: Junio C Hamano @ 2005-11-15 8:24 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1132042427.3512.50.camel@dv>
Pavel Roskin <proski@gnu.org> writes:
> In particular, StGIT still needs fixing.
>
>> The only thing I can think of that might be inconvenient is if
>> you try doing "cp -a" off of a filesystem that supports symlinks
>> to another filesystem that does not -- probably that would fail
>> copying the symlinked .git/HEAD. But if that is the problem,
>> you could always git-clone, which should do the right thing, I
>> think.
>
> I'm talking from my experience now. If there is an option, there are
> users that have it enabled and those who have it disabled (by
> definition). As is often happens, one of the configurations is more
> popular with developers. The other configuration almost inevitably
> starts suffering from the "bit rot".
That's a real concern, I should agree.
^ permalink raw reply
* pushing patches to an imap folder
From: Mike McCormack @ 2005-11-15 8:20 UTC (permalink / raw)
To: git list
Hi,
I hacked up git-format-patch and isync to create a program to push
patches from git into an imap folder. This improve my workflow with git
quite a bit.
It's pretty Wine specific at the moment, but I'd be happy to try and
create a patch for git if I had a little advice on where to store the
configuration... an imap server (host/port/name/pass or ssh command)
with a mail header/template thrown in.
http://mandoo.dyndns.org/mm-send-patch-0.1.tar.gz
Comments and flames welcome :)
Mike
^ permalink raw reply
* Re: [PATCH] Disable USE_SYMLINK_HEAD by default
From: Pavel Roskin @ 2005-11-15 8:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vveyuqto5.fsf@assigned-by-dhcp.cox.net>
On Mon, 2005-11-14 at 23:03 -0800, Junio C Hamano wrote:
> Pavel Roskin <proski@gnu.org> writes:
>
> > Applying this patch before 1.0 may be controversial,...
>
> If I am not mistaken, I thought the last thread on the list
> showed general consensus that symlinks were preferred when
> available. So applying this patch anytime would be
> controversial...
I must have missed that. If you mean "Re: Getting rid of symlinks
in .git?", I don't see any such consensus there. The discussion drifts
to insignificant details, and I see arguments like "I couldn't care
less" and speculations about speed without any hard data at hand.
> > but I think there is a very good reason for that.
>
> Which is...? I do not think this paragraph justifies it:
>
> > There should be exactly one git 1.0 repository format. Now we
> > have two that are present in the sources and that have
> > received testing from the git users.
>
> The one format is that .git/HEAD can either be a symlink or
> regular file text symref; both variants are tested -- wouldn't
> that be good enough?
No. Even if git itself is tested, other tools are not. What's worse,
the developers of those tools don't even know they are supposed to test
for two HEAD formats unless they track git changes and mailing lists
very carefully.
In particular, StGIT still needs fixing.
> The only thing I can think of that might be inconvenient is if
> you try doing "cp -a" off of a filesystem that supports symlinks
> to another filesystem that does not -- probably that would fail
> copying the symlinked .git/HEAD. But if that is the problem,
> you could always git-clone, which should do the right thing, I
> think.
I'm talking from my experience now. If there is an option, there are
users that have it enabled and those who have it disabled (by
definition). As is often happens, one of the configurations is more
popular with developers. The other configuration almost inevitably
starts suffering from the "bit rot".
It could have been prevented if the format choice was encapsulated by
git prior to its introduction. But git-symbolic-ref didn't exist before
symrefs were implemented. Old code outside git accesses .git/HEAD
manually. Fixing git alone is not enough if git files are accessed
without git.
Extra complexity of any format discourages third party applications or
makes them more complex and less safe to use.
I can understand if the complexity has a balance of requirements issue
behind it. For example, coexistence of packed and unpacked files comes
from the conflicting requirements to handle files quickly and not to
consume too much hard disk space and bandwidth.
But there is no strong (compared to portability) reason to have
symlinks, except maybe backward compatibility. It's a weak argument
before 1.0 release. Let's not wait until it becomes stronger.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH 1/2] archimport: allow for old style branch and public tag names
From: Eric Wong @ 2005-11-15 8:07 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git list
In-Reply-To: <20051115080546.GA30506@Muzzle>
Oops, I sent these two patches out of order. They should apply
fine without conflicts either way.
--
Eric Wong
^ permalink raw reply
* [PATCH 2/2] archimport: sync_to_ps() messages for tracking tla methods
From: Eric Wong @ 2005-11-15 8:06 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git list
In-Reply-To: <20051115080546.GA30506@Muzzle>
This patch adds debug messages (enabled with the usual -v switch) for
tracking how often each tla command is called.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-archimport.perl | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
applies-to: 8a7cc429d0fd935805851ac5ac10941d0bd86e94
b4de7920e0116afb35016435131a404658818ced
diff --git a/git-archimport.perl b/git-archimport.perl
index b624ba6..1f721f6 100755
--- a/git-archimport.perl
+++ b/git-archimport.perl
@@ -429,18 +429,23 @@ sub sync_to_ps {
my $ps = shift;
my $tree_dir = $tmptree.'/'.tree_dirname($ps->{id});
+ $opt_v && print "sync_to_ps($ps->{id}) method: ";
+
if (-d $tree_dir) {
if ($ps->{type} eq 't') {
# looks like a tag-only or (worse,) a mixed tags/changeset branch,
# can't rely on replay to work correctly on these
rmtree($tree_dir);
+ $opt_v && print "get (tag)\n";
safe_pipe_capture($TLA,'get','--no-pristine',$ps->{id},$tree_dir);
} else {
my $tree_id = arch_tree_id($tree_dir);
if ($ps->{parent_id} eq $tree_id) {
# the common case (hopefully)
+ $opt_v && print "replay\n";
safe_pipe_capture($TLA,'replay','-d',$tree_dir,$ps->{id});
} else {
+ $opt_v && print "apply-delta\n";
# this can happen if branches cherry-pick
safe_pipe_capture($TLA,'apply-delta','-d',$tree_dir,
$tree_id, $ps->{id});
@@ -448,6 +453,7 @@ sub sync_to_ps {
}
} else {
# new branch work
+ $opt_v && print "get (new tree)\n";
safe_pipe_capture($TLA,'get','--no-pristine',$ps->{id},$tree_dir);
}
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH 1/2] archimport: allow for old style branch and public tag names
From: Eric Wong @ 2005-11-15 8:05 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git list
In-Reply-To: <20051115080352.GG7484@mail.yhbt.net>
This patch adds the -o switch, which lets old trees tracked by
git-archmirror continue working with their old branch and tag names
to make life easier for people tracking your tree.
Private tags that are only used internally by git-archimport continue to be
new-style, and automatically converted upon first run.
Signed-off-by:: Eric Wong <normalperson@yhbt.net>
---
git-archimport.perl | 22 +++++++++++++++++-----
1 files changed, 17 insertions(+), 5 deletions(-)
applies-to: 44d831812786f4dfbf54a67b51e5f48c7d5afd66
4b341dd903883db0a89fe2f04e93dab053beb045
diff --git a/git-archimport.perl b/git-archimport.perl
index 1f721f6..304d462 100755
--- a/git-archimport.perl
+++ b/git-archimport.perl
@@ -67,12 +67,12 @@ my $git_dir = $ENV{"GIT_DIR"} || ".git";
$ENV{"GIT_DIR"} = $git_dir;
my $ptag_dir = "$git_dir/archimport/tags";
-our($opt_h,$opt_v,$opt_T,$opt_t,$opt_D,$opt_a);
+our($opt_h,$opt_v,$opt_T,$opt_t,$opt_D,$opt_a,$opt_o);
sub usage() {
print STDERR <<END;
Usage: ${\basename $0} # fetch/update GIT from Arch
- [ -h ] [ -v ] [ -T ] [ -a ] [ -D depth ] [ -t tempdir ]
+ [ -o ] [ -h ] [ -v ] [ -T ] [ -a ] [ -D depth ] [ -t tempdir ]
repository/arch-branch [ repository/arch-branch] ...
END
exit(1);
@@ -267,7 +267,15 @@ sub tree_dirname {
return $name;
}
-*git_branchname = *tree_dirname;
+# old versions of git-archimport just use the <category--branch> part:
+sub old_style_branchname {
+ my $id = shift;
+ my $ret = safe_pipe_capture($TLA,'parse-package-name','-p',$id);
+ chomp $ret;
+ return $ret;
+}
+
+*git_branchname = $opt_o ? *old_style_branchname : *tree_dirname;
# process patchsets in ancestry order
foreach my $ps (@psets) {
@@ -527,8 +535,12 @@ sub parselog {
sub tag {
my ($tag, $commit) = @_;
- # don't use subdirs for tags yet, it could screw up other porcelains
- $tag =~ s|/|,|;
+ if ($opt_o) {
+ $tag =~ s|/|--|g;
+ } else {
+ # don't use subdirs for tags yet, it could screw up other porcelains
+ $tag =~ s|/|,|g;
+ }
if ($commit) {
open(C,">","$git_dir/refs/tags/$tag")
---
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH] archimport improvements
From: Eric Wong @ 2005-11-15 8:03 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git list
In-Reply-To: <46a038f90511141438q1d85d429vedcf2a3b54d761e1@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> wrote:
> Eric,
>
> thanks for resending those so quickly. I think I'm going to sit on the
> 'overhaul of changeset application' patch a bit -- I'll test & ack
> your other patches for merge soonish but I want to review and test
> this one carefully.
>
> My main concern is that it seems to be calling tla get for each
> revision that it imports. For large trees, this is slow. I would be
> much happier with a fast Perl-based approach. Have you got a public
> repo with directory renames?
Please read my sync_to_ps() function very carefully. Next is a patch
that helps you track which Arch command (get/replay/apply-delta) is used
for each changeset.
tla replay is the most common for any halfway normal (changeset-based)
tree by far.
tla get is not called any more often than before.
apply-delta is hardly, if ever called. It may not even be reachable
unless somebody commits revisions to the same tree with clocks out of
order from patchlevel order. Heck, if it's ever called, it's most
likely faster just to rmtree and tla get again.
Unfortunately, my heavily used and abused trees are private.
> Additional comments follow...
>
> On 11/13/05, Eric Wong <normalperson@yhbt.net> wrote:
> > > > * Identify git branches as an Arch "archive,category<--branch>--version"
> > > > Anything less than that is ambiguous as far as history and patch
> > > > relationships go.
> > >
> > > These bug/sanity fixes are _good_. As you mention, I wasn't aware that
> > > patchnames could show up not having a --branch part. Tricky...
> >
> > Thanks. I got lazy one day and started ignoring --branch on some of my
> > personal projects to save my fingers :)
>
> Yup, makes sense. My concern now is that existing imports will change
> the name of branches and tags going forward. Can I ask you to resend
> that patch with the new branchname mangling as default, and the old
> one as optional?
Ok, good idea. My previous patch already automatically converted the
private tags, which we actually need to parse, and I see no reason to
change that, but branch names and public tags which affect
non-gitarchimport users can be preserved with the -o flag.
> I know it'll force us to go back to using shellquote, but I am not too
> worried by that dependency at the moment.
Actually, usage of shell_quote() in git-archimport was always
unnecessary. Passing arguments to external programs as an array,
using the 3-argument version of open() for files, and using -z in
git-commands with pipes are better ways to go.
> > > > Current weaknesses:
> > > >
> > > > * (Present in the original code as well).
> > > > The code still assumes that dates in commit logs can be trusted, which is
> > > > fine in most cases, but a wayward branch can screw up git-archimport and
> > > > cause parents to be missed.
> > >
> > > Fair enough. You mention an alternative strategy (tla ancestry) --
> > > have you tried it at all?
> >
> > No, not yet.
>
> Also interested in this if you get around to it.
It's not a high priority for me and I probably don't have time to do
this.
--
Eric Wong
^ 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