* Re: [PATCH] Fix the remote note the fetch-tool prints after storing a fetched reference
From: Junio C Hamano @ 2007-06-06 20:07 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <81b0412b0706060852y4ab6b794m5fed0484c63159e4@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
> Otherwise ".git" is removed from every remote path which has it,
> including "/some/path/somename.git".
I was very tempted to apply this patch, but after re-reading it
once more, I decided to drop it.
I do not mind keeping the extra .git/ suffix in the -v output in
your example, as the message is just "verbose information":
$ git fetch -v
* refs/heads/origin: same as branch 'master' of /home/user/linux
commit: 5ecd310
But the same output is used by log messages for the merge
commits; indeed, the primary purpose of this output is to
prepare messages for merge commits. From the beginning we
deliberately omitted .git suffix to keep the resulting log
message short and sweet. Keeping .git suffix goes against it.
A repository "git://$site/repo.git" can be accessed with
"git://$site/repo". Repository owners _can_ confuse their users
by having both repo and repo.git, but I honestly do not see a
reason to encourage that.
Earlier you mentioned you know of a case where "$URL/repo.git"
exists and "$URL/repo" does not, and the current clone fails to
set up the target repository after cloning from "$URL/repo"
correctly? I admit I haven't reproduced nor debugged it, but if
that is the case that needs to be fixed.
^ permalink raw reply
* Re: [RFC PATCH] Add git quick reference
From: Junio C Hamano @ 2007-06-06 20:36 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: J. Bruce Fields, git
In-Reply-To: <20070604184546.GA27088@diku.dk>
Jonas Fonseca <fonseca@diku.dk> writes:
> J. Bruce Fields <bfields@fieldses.org> wrote Sun, Jun 03, 2007:
>> On Sat, Jun 02, 2007 at 08:24:23PM +0200, Jonas Fonseca wrote:
>> > It attempts to list some of the most commonly used commands, which should
>> > give new users an idea of how to get started.
>> >
>> > Available both as a manpage (generated via a script) and HTML page.
>>
>> We have a "git quick start" here:
>>
>> http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#git-quick-start
>>
>> and there's one on the wiki:
>>
>> http://git.or.cz/gitwiki/QuickStart
>>
>> I think the one in the manual tries to follow the organization of the
>> manual more closely.
>
> I like the manual version best. However, it is not as "visually" clean
> and simple as I would like, but perhaps this sort of "use case" approach
> is better.
>
>> I haven't tried to compare those two recently, or to compare yours to
>> either of them. If you could compare and suggest any improvements,
>> that'd be helpful.
>
> I will see what I can do when I get the time and courage. :)
>
>> I like your name better ("quick reference" as opposed to "quick start").
>
> Yes, "quick start" suggest (at least to me) that it is a tutorial and it
> seems far from that.
When I started the "everyday" document, I wanted to make it a
cheat sheet usable by people who are not so familiar with the
workflow. The "quick reference" would be good for people who
want a cheat sheet without need for workflow description.
^ permalink raw reply
* Re: [PATCH] filter-branch: use sh -c instead of eval
From: Junio C Hamano @ 2007-06-06 20:53 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <f44bvq$klu$1@sea.gmane.org>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> Matthias Lederhofer wrote:
>
>> If filters use variables with the same name as variables
>> used in the script the script breaks. Executing the filters
>> in a separate process prevents accidential modification of
>> the variables in the main process.
>> @@ -349,21 +349,21 @@ while read commit; do
>>
>> eval "$(set_ident AUTHOR <../commit)"
>> eval "$(set_ident COMMITTER <../commit)"
>> - eval "$filter_env" < /dev/null
>> + sh -c "$filter_env" < /dev/null
>
> NACK.
>
> The eval is on purpose here. $filter_env must be able export GIT_AUTHOR* and
> GIT_COMMITTER* variables here.
True. The other hunks may be improvements, though.
^ permalink raw reply
* [PATCH 1/2] Fix removal of series with non-existant trash dir.
From: Yann Dirson @ 2007-06-06 21:05 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20070606205852.7657.69286.stgit@gandelf.nowhere.earth>
Otherwise it is not possible to delete a stack that never had a patch
deleted (eg. a newborn stack).
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
stgit/stack.py | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/stgit/stack.py b/stgit/stack.py
index 26b0561..30fcca7 100644
--- a/stgit/stack.py
+++ b/stgit/stack.py
@@ -679,10 +679,11 @@ class Series(StgitObject):
for p in patches:
Patch(p, self.__patch_dir, self.__refs_dir).delete()
- # remove the trash directory
- for fname in os.listdir(self.__trash_dir):
- os.remove(os.path.join(self.__trash_dir, fname))
- os.rmdir(self.__trash_dir)
+ # remove the trash directory if any
+ if os.path.exists(self.__trash_dir):
+ for fname in os.listdir(self.__trash_dir):
+ os.remove(os.path.join(self.__trash_dir, fname))
+ os.rmdir(self.__trash_dir)
# FIXME: find a way to get rid of those manual removals
# (move functionality to StgitObject ?)
^ permalink raw reply related
* [StGIT PATCH 0/2] Fix issues with series deletion
From: Yann Dirson @ 2007-06-06 21:05 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
The following series fixes 2 problems with series deletion.
I am however not happy at all with the way we delete patches and
series, starting with an existence check and then deleting. If any
error occurs midway, then we are left with an inconsistent state that
the user has to cleanup by hand. IMHO, we should have those methods
be as robust as possible, maybe starting by removing the formatversion
item, and printing a "cleaning up zombie stack" if does not find it.
So at least after fixing a "delete" bug, we could rerun the same
command and get to a sane state again.
Does that make sense ?
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* [PATCH 2/2] Fix removal of series to nuke the formatversion config item.
From: Yann Dirson @ 2007-06-06 21:05 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20070606205852.7657.69286.stgit@gandelf.nowhere.earth>
Since this parameter is now used to decide if the branch has already
been initialised, not removing it forbids to create a stack with the
same name as one that was deleted.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
stgit/stack.py | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/stgit/stack.py b/stgit/stack.py
index 30fcca7..e2bf6ac 100644
--- a/stgit/stack.py
+++ b/stgit/stack.py
@@ -718,6 +718,7 @@ class Series(StgitObject):
config.unset('branch.%s.remote' % self.__name)
config.unset('branch.%s.merge' % self.__name)
config.unset('branch.%s.stgit.parentbranch' % self.__name)
+ config.unset('branch.%s.stgitformatversion' % self.__name)
def refresh_patch(self, files = None, message = None, edit = False,
show_patch = False,
^ permalink raw reply related
* Re: [PATCH] Documentation typo.
From: Junio C Hamano @ 2007-06-06 21:16 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, Pierre Habouzit
In-Reply-To: <11810823561507-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> writes:
> From: Pierre Habouzit <pierre.habouzit@m4x.org>
>
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> ---
> Documentation/pull-fetch-param.txt | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt
> index 8d4e950..5bcdbc8 100644
> --- a/Documentation/pull-fetch-param.txt
> +++ b/Documentation/pull-fetch-param.txt
> @@ -4,7 +4,7 @@
>
> <refspec>::
> The canonical format of a <refspec> parameter is
> - `+?<src>:<dst>`; that is, an optional plus `+`, followed
> + `\+?<src>:<dst>`; that is, an optional plus `+`, followed
> by the source ref, followed by a colon `:`, followed by
> the destination ref.
> +
Not really. I suspect you are using AsciiDoc 8?
Your patch does make AsciiDoc 8 keep '+' in the HTML output, but
manual page output gets an extra backslash, so it is not really
an improvement.
Unfortunately our documentation pages were written with AsciiDoc
7, and are not AsciiDoc 8 compatible.
With -aasciidoc7compatible, AsciiDoc 8 is _supposed_ to behave
compatibly, but in reality it does not format our documentation
correctly. It certainly is possible that AsciiDoc 7 "happens to
work" with our documentation pages, and maybe the way we abuse
mark-ups can be argued the bug in _our_ documentation, but
nobody on our end worked on finding a satisfactory solution to
make our documentation format correctly with _both_ versions of
AsciiDoc yet.
I wrote about the differences between AsciiDoc 7, and AsciiDoc 8
with the "compatiblity" I found a few weeks ago on this list;
the most problematic was that 'asciidoc -aasciidoc7compatible'
loses carets in our description where they matter X-<. The list
archive may know more about the details,
^ permalink raw reply
* Re: [PATCH] git-mergetool: Make default smarter by considering user's desktop environment and editor
From: Theodore Tso @ 2007-06-06 21:20 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86lkexjua3.fsf@lola.quinscape.zz>
This is what I've been experimenting in my tree; what do people think?
if test -z "$merge_tool" ; then
if test -n "$DISPLAY"; then
merge_tool_candidates="kdiff3 tkdiff xxdiff meld gvimdiff"
if test "$GNOME_DESKTOP_SESSION_ID"x != ""x; then
merge_tool_candidates="meld $merge_tool_candidates"
fi
if test "$KDE_FULL_SESSION"x = "true"x; then
merge_tool_candidates="kdiff3 $merge_tool_candidates"
fi
fi
if echo "${VISUAL:-$EDITOR}" | grep 'emacs' > /dev/null 2>&1; then
merge_tool_candidates="$merge_tool_candidates emerge"
fi
if echo "${VISUAL:-$EDITOR}" | grep 'vim' > /dev/null 2>&1; then
merge_tool_candidates="$merge_tool_candidates vimdiff"
fi
merge_tool_candidates="$merge_tool_candidates opendiff emerge vimdiff"
echo "merge tool candidates: $merge_tool_candidates"
for i in $merge_tool_candidates; do
if test $i = emerge ; then
cmd=emacs
else
cmd=$i
fi
if type $cmd > /dev/null 2>&1; then
echo merge_tool chosen is $i
merge_tool=$i
break
fi
done
fi
- Ted
^ permalink raw reply
* Re: [PATCH] Add git-index-pack -l to list objects in a pack
From: Sam Vilain @ 2007-06-06 21:23 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.99.0706060952410.12885@xanadu.home>
Nicolas Pitre wrote:
>> I couldn't figure out how to make git-unpack-objects -n work.
>> But it seems to be easy in the loop in index-pack
>
> Why don't you simply use git-show-index?
Because I found the enticing -n switch in the documentation first?
That command certainly would have done the trick for what I needed it
to do. Perhaps change the documentation of the switch?
Subject: [PATCH] fix documentation of unpack-objects -n
unpack-objects -n didn't print the object list as promised on the
manual page, so alter the documentation to reflect the behaviour
---
Documentation/git-unpack-objects.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-unpack-objects.txt b/Documentation/git-unpack-objects.txt
index ff6184b..b1b3ec9 100644
--- a/Documentation/git-unpack-objects.txt
+++ b/Documentation/git-unpack-objects.txt
@@ -27,8 +27,8 @@ new packs and replace existing ones.
OPTIONS
-------
-n::
- Only list the objects that would be unpacked, don't actually unpack
- them.
+ Dry run. Check the pack file without actually unpacking
+ the objects.
-q::
The command usually shows percentage progress. This
--
1.5.2.0.45.gfea6d-dirty
^ permalink raw reply related
* [PATCH] setup_git_directory: fix segfault if repository is found in cwd
From: Matthias Lederhofer @ 2007-06-06 21:29 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <20070603144401.GA9518@moooo.ath.cx>
Additionally there was a similar part calling setenv and getenv
in the same way which missed a check if getenv succeeded.
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
There seems to be no easy way to test this case. We'd have to run the
test in a directory which never has a .git directory in any parent.
---
setup.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/setup.c b/setup.c
index 14a4d95..dba8012 100644
--- a/setup.c
+++ b/setup.c
@@ -251,6 +251,9 @@ const char *setup_git_directory_gently(int *nongit_ok)
die("Not a git repository");
}
setenv(GIT_DIR_ENVIRONMENT, cwd, 1);
+ gitdirenv = getenv(GIT_DIR_ENVIRONMENT);
+ if (!gitdirenv)
+ die("getenv after setenv failed");
}
if (PATH_MAX - 40 < strlen(gitdirenv)) {
@@ -290,6 +293,8 @@ const char *setup_git_directory_gently(int *nongit_ok)
if (gitdirenv[0] != '/') {
setenv(GIT_DIR_ENVIRONMENT, gitdir, 1);
gitdirenv = getenv(GIT_DIR_ENVIRONMENT);
+ if (!gitdirenv)
+ die("getenv after setenv failed");
if (PATH_MAX - 40 < strlen(gitdirenv)) {
if (nongit_ok) {
*nongit_ok = 1;
--
1.5.2.1.887.ge344-dirty
^ permalink raw reply related
* Re: [PATCH] Add git-index-pack -l to list objects in a pack
From: Junio C Hamano @ 2007-06-06 21:35 UTC (permalink / raw)
To: Sam Vilain; +Cc: Nicolas Pitre, git
In-Reply-To: <466725C4.5090707@catalyst.net.nz>
Sam Vilain <sam.vilain@catalyst.net.nz> writes:
> Nicolas Pitre wrote:
>>> I couldn't figure out how to make git-unpack-objects -n work.
>>> But it seems to be easy in the loop in index-pack
>>
>> Why don't you simply use git-show-index?
>
> Because I found the enticing -n switch in the documentation first?
>
> That command certainly would have done the trick for what I needed it
> to do. Perhaps change the documentation of the switch?
I think this is "incorrect expectation". The document says:
> -n::
> - Only list the objects that would be unpacked, don't actually unpack
> - them.
I suspect that you were trying to unpack in a repository that
already had that object? They are not "the objects that would
be unpacked" hence not listed.
^ permalink raw reply
* Re: "stgit rebase" should check for errors before changing tree
From: Yann Dirson @ 2007-06-06 21:47 UTC (permalink / raw)
To: Andrey Borzenkov; +Cc: catalin.marinas, git
In-Reply-To: <200706052059.51173.arvidjaar@mail.ru>
On Tue, Jun 05, 2007 at 08:59:40PM +0400, Andrey Borzenkov wrote:
> {pts/0}% stg rebase 2.6.22-rc4
> Checking for changes in the working directory... done
> Popping all applied patches... done
> Rebasing to "2.6.22-rc4"...
> stg rebase: Unknown revision: 2.6.22-rc4^{commit}
>
> well, now user is forced to reapply (push) all patches by hand, "stg rebase"
> lost history and state. It probably should check before popping patches.
Right, fixed in my tree.
Thanks for your report.
--
Yann
^ permalink raw reply
* [PATCH 1/3] Robustify rebase test: check patches are reapplied.
From: Yann Dirson @ 2007-06-06 22:01 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20070606215922.18635.38379.stgit@gandelf.nowhere.earth>
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
t/t2200-rebase.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/t/t2200-rebase.sh b/t/t2200-rebase.sh
index 52462dd..882572c 100755
--- a/t/t2200-rebase.sh
+++ b/t/t2200-rebase.sh
@@ -27,7 +27,8 @@ test_expect_success \
'Rebase to previous commit' \
'
stg rebase master~1 &&
- test `stg id base@stack` = `git rev-parse master~1`
+ test `stg id base@stack` = `git rev-parse master~1` &&
+ test `stg applied | wc -l` = 1
'
test_done
^ permalink raw reply related
* [SGIT PATCH 0/3] Assorted fixes
From: Yann Dirson @ 2007-06-06 22:01 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
This fixes the issue reported by Andrey Borzenkov, and robustifies
another testcase to catch any similar issue.
Also updates stg-whatchanged, which for some reason had been left
broken.
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* [PATCH 2/3] Catch early trying rebasing to unknown ref, and add testcase.
From: Yann Dirson @ 2007-06-06 22:01 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20070606215922.18635.38379.stgit@gandelf.nowhere.earth>
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
stgit/commands/rebase.py | 4 ++++
t/t2200-rebase.sh | 12 ++++++++++++
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/stgit/commands/rebase.py b/stgit/commands/rebase.py
index d132b60..2f0e660 100644
--- a/stgit/commands/rebase.py
+++ b/stgit/commands/rebase.py
@@ -52,6 +52,10 @@ def func(parser, options, args):
check_conflicts()
check_head_top_equal()
+ # ensure an exception is raised before popping on non-existent target
+ if git_id(args[0]) == None:
+ raise GitException, 'Unknown revision: %s' % git_id
+
applied = prepare_rebase(real_rebase=True, force=options.force)
rebase(args[0])
post_rebase(applied, options.nopush, options.merged)
diff --git a/t/t2200-rebase.sh b/t/t2200-rebase.sh
index 882572c..c142e08 100755
--- a/t/t2200-rebase.sh
+++ b/t/t2200-rebase.sh
@@ -31,4 +31,16 @@ test_expect_success \
test `stg applied | wc -l` = 1
'
+test_expect_failure \
+ 'Attempt rebase to non-existing commit' \
+ '
+ stg rebase not-a-ref
+ '
+
+test_expect_success \
+ 'Check patches were re-applied' \
+ '
+ test $(stg applied | wc -l) = 1
+ '
+
test_done
^ permalink raw reply related
* [PATCH 3/3] Fixed typo in contrib/stg-whatchanged.
From: Yann Dirson @ 2007-06-06 22:01 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20070606215922.18635.38379.stgit@gandelf.nowhere.earth>
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
contrib/stg-whatchanged | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/stg-whatchanged b/contrib/stg-whatchanged
index f80d0a1..d5b6965 100755
--- a/contrib/stg-whatchanged
+++ b/contrib/stg-whatchanged
@@ -23,7 +23,7 @@ fi
# Merges via "push" leave top=bottom so we must look at old patch
# in this case (unlike, eg., "pick --fold")
-patchdir="$(git-rev-parse --git-dir)/patches/$(stg branch)/$(stg top)"
+patchdir="$(git-rev-parse --git-dir)/patches/$(stg branch)/patches/$(stg top)"
if [ $(cat "$patchdir/bottom") = $(cat "$patchdir/top") ];
then
current_cmd="stg show //top.old"
^ permalink raw reply related
* Re: [PATCH] Use git-tag in git-cvsimport
From: Junio C Hamano @ 2007-06-06 20:41 UTC (permalink / raw)
To: Martin Waitz; +Cc: Elvis Pranskevichus, git
In-Reply-To: <20070604071810.GD16637@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
> On Sun, Jun 03, 2007 at 05:01:03PM -0700, Junio C Hamano wrote:
>> Martin Waitz <tali@admingilde.org> writes:
>> > but lightweight tags are not fetched by default.
>>
>> Are you sure about that?
>
> not any more now that you questioned it ;-)
>
> But at least there is a hook script which refuses to receive
> un-annotated tags and I always considered those tags to be temporary
> tags in the local repository.
I'll take the patch to 'next' and see if anybody screams. We
can add the '-m "Label from CVS"' bit easily if annotated tags
turns out to be easier for people before it graduates to
'master', although I suspect we probably do not have to.
^ permalink raw reply
* git does the wrong thing with ambiguous names
From: Brandon Casey @ 2007-06-06 22:13 UTC (permalink / raw)
To: Git Mailing List
When a branch and tag have the same name, a git-checkout using that name
succeeds (exits zero without complaining), switches to the _branch_, but
updates the working directory contents to that specified by the _tag_.
git-status show modified files.
Looks like the ambiguity issue was brought up last year, and git is now
*supposed* to warn when it encounters an ambiguous name. I agree with
Petr, it should fail violently, preferably as Josef Weidendorfer
suggests also printing out the ambiguous matches so the user can cut and
paste.
http://article.gmane.org/gmane.comp.version-control.git/17720
But it doesn't, git-checkout.sh redirects stderr on git-rev-parse
--verify so the message is lost. git-log complains, but most users will
never see it since it is pushed off the screen so quickly.
In another portion of the same thread Junio describes the caveats and
his experience:
http://article.gmane.org/gmane.comp.version-control.git/16996
The tag==branch name case is trivial to reproduce and a test script is
provided below. It should fail, so it's not really a submission as a
test script until this is fixed.
-brandon
ps. I was told a previous patch was ws munged. I'm using thunderbird, if
it happens this time suggestions welcome.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
t/t2006-checkout-name-clash.sh | 39
+++++++++++++++++++++++++++++++++++++++
1 files changed, 39 insertions(+), 0 deletions(-)
create mode 100755 t/t2006-checkout-name-clash.sh
diff --git a/t/t2006-checkout-name-clash.sh b/t/t2006-checkout-name-clash.sh
new file mode 100755
index 0000000..2220578
--- /dev/null
+++ b/t/t2006-checkout-name-clash.sh
@@ -0,0 +1,39 @@
+#!/bin/sh
+
+test_description='git-checkout with tag/branch naming clash
+
+This tests whether git does something sane when a tag
+and a branch have the same name.'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+echo initial >file1 &&
+echo initial >file2 &&
+git-add file1 file2 &&
+git-commit -m initial
+'
+
+test_expect_success 'create modified branch named test' '
+git-branch test &&
+git-checkout test &&
+echo test >file1 &&
+git-commit -a -m test
+'
+
+test_expect_success 'create tag named test on master branch' '
+git-checkout master &&
+git-tag test
+'
+
+test_expect_success 'modify master and commit' '
+echo master >file2 &&
+git-commit -a -m master
+'
+
+test_expect_success 'checkout test and check consistency' '
+git-checkout test &&
+test "`git diff-index --name-only HEAD`" = ""
+'
+
+test_done
--
1.5.2.1.126.g6abd0
^ permalink raw reply related
* Re: [PATCH] Documentation typo.
From: Pierre Habouzit @ 2007-06-06 22:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4plkzsuj.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 2416 bytes --]
On Wed, Jun 06, 2007 at 02:16:36PM -0700, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > From: Pierre Habouzit <pierre.habouzit@m4x.org>
> >
> > Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> > ---
> > Documentation/pull-fetch-param.txt | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt
> > index 8d4e950..5bcdbc8 100644
> > --- a/Documentation/pull-fetch-param.txt
> > +++ b/Documentation/pull-fetch-param.txt
> > @@ -4,7 +4,7 @@
> >
> > <refspec>::
> > The canonical format of a <refspec> parameter is
> > - `+?<src>:<dst>`; that is, an optional plus `+`, followed
> > + `\+?<src>:<dst>`; that is, an optional plus `+`, followed
> > by the source ref, followed by a colon `:`, followed by
> > the destination ref.
> > +
>
> Not really. I suspect you are using AsciiDoc 8?
indeed ...
> Your patch does make AsciiDoc 8 keep '+' in the HTML output, but
> manual page output gets an extra backslash, so it is not really
> an improvement.
Not for me, using asciidoc 8.2.1 on debian. It was because the manpage
was missing a '+' that I actually wrote this patch, as it was really
akward.
> Unfortunately our documentation pages were written with AsciiDoc
> 7, and are not AsciiDoc 8 compatible.
>
> With -aasciidoc7compatible, AsciiDoc 8 is _supposed_ to behave
> compatibly, but in reality it does not format our documentation
> correctly. It certainly is possible that AsciiDoc 7 "happens to
> work" with our documentation pages, and maybe the way we abuse
> mark-ups can be argued the bug in _our_ documentation, but
> nobody on our end worked on finding a satisfactory solution to
> make our documentation format correctly with _both_ versions of
> AsciiDoc yet.
>
> I wrote about the differences between AsciiDoc 7, and AsciiDoc 8
> with the "compatiblity" I found a few weeks ago on this list;
> the most problematic was that 'asciidoc -aasciidoc7compatible'
> loses carets in our description where they matter X-<. The list
> archive may know more about the details,
Okay, I see, sorry for the noise then.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Git Vs. Svn for a project which *must* distribute binaries too.
From: Jakub Narebski @ 2007-06-06 22:34 UTC (permalink / raw)
To: git
In-Reply-To: <f427ur$ohs$1@sea.gmane.org>
Jakub Narebski wrote:
> Bryan Childs wrote:
>
>> 3) With a central repository, for which we have a limited number of
>> individuals having commit access, it's easy for us to automate a build
>> based on each commit the repository receives.
>
> Check out contrib/continuous/ scripts in git repository: you would have
> to enable it only on one machine, of course.
You can also use something similar to dodoc.sh script in 'todo' branch of
git repository, which script makes some build results and saves them in
_separate_ branch of repository.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] [RFC] Generational repacking
From: Junio C Hamano @ 2007-06-06 22:46 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <11811281053874-git-send-email-sam.vilain@catalyst.net.nz>
Sam Vilain <sam.vilain@catalyst.net.nz> writes:
> + c_gen=`eval "echo \\\$c_gen_$i"`
> + packs=`eval "echo \\\$gen_$i"`
I used to write something like these myself when I was young
;-), but it is enough to write:
eval 'c_gen=$c_gen_'$i
eval "packs=\$gen_$i"
^ permalink raw reply
* Re: [PATCH] Fix the remote note the fetch-tool prints after storing a fetched reference
From: Alex Riesen @ 2007-06-06 22:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vfy543kzn.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Wed, Jun 06, 2007 22:07:24 +0200:
> "Alex Riesen" <raa.lkml@gmail.com> writes:
>
> > Otherwise ".git" is removed from every remote path which has it,
> > including "/some/path/somename.git".
>
> I was very tempted to apply this patch, but after re-reading it
> once more, I decided to drop it.
>
> I do not mind keeping the extra .git/ suffix in the -v output in
> your example, as the message is just "verbose information":
>
> $ git fetch -v
> * refs/heads/origin: same as branch 'master' of /home/user/linux
> commit: 5ecd310
>
> But the same output is used by log messages for the merge
> commits; indeed, the primary purpose of this output is to
> prepare messages for merge commits.
BTW, this is hard to believe. Were does git-merge call fetch--tool?
Nor have I found its use for logging purposes. Or, if you refer to the
logs a user can create by redirecting output of git fetch someplace,
than it is highly suspicious for tham to contain something short,
sweet and not existing.
> From the beginning we deliberately omitted .git suffix to keep the
> resulting log message short and sweet. Keeping .git suffix goes
> against it.
But this is how the repo is actually named! If you want to keep the
_message_ short and sweet than cut the suffix in the message
generation code.
> A repository "git://$site/repo.git" can be accessed with
> "git://$site/repo". Repository owners _can_ confuse their users
> by having both repo and repo.git, but I honestly do not see a
> reason to encourage that.
People will never know whether they are encouraged or discouraged.
They just wont notice it is _wrong_ until they copy-paste the path
from git-fetch output and do something nasty to it.
> Earlier you mentioned you know of a case where "$URL/repo.git"
> exists and "$URL/repo" does not, and the current clone fails to
> set up the target repository after cloning from "$URL/repo"
> correctly? I admit I haven't reproduced nor debugged it, but if
> that is the case that needs to be fixed.
mkdir a.git && cd a.git && git init && :>file && \
git add . && git commit -m1 && mv .git/* . && rmdir .git && \
cd .. && git clone -l -s a b && cd b && git fetch
The cloned repo "b" gets "a" verbatim, instead of something more
useful (like "../../a.git" or "/full/path/a.git". It is not even
"/full/path/a").
git clone works correctly (origin's url is an absolute path) if a.git
is given:
mkdir a.git && cd a.git && git init && :>file && \
git add . && git commit -m1 && mv .git/* . && rmdir .git && \
cd .. && git clone -l -s a.git b && cd b && git fetch
Fix, needed because of all this "detachable suffix" confusion:
diff --git a/git-clone.sh b/git-clone.sh
index fdd354f..d45618d 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -20,7 +20,7 @@ usage() {
get_repo_base() {
(
cd "`/bin/pwd`" &&
- cd "$1" &&
+ cd "$1" || cd "$1.git" &&
{
cd .git
pwd
^ permalink raw reply related
* [PATCH] Fix clone to setup the origin if its name ends with .git
From: Alex Riesen @ 2007-06-06 22:49 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
The problem is visible when cloning a local repo. The cloned
repository will have the origin url setup incorrectly: the origin name
will be copied verbatim in origin url of the cloned repository.
Normally, the name is to be expanded into absolute path.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
git-clone.sh | 2 +-
t/t5701-clone-local.sh | 17 +++++++++++++++++
2 files changed, 18 insertions(+), 1 deletions(-)
create mode 100755 t/t5701-clone-local.sh
diff --git a/git-clone.sh b/git-clone.sh
index fdd354f..d45618d 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -20,7 +20,7 @@ usage() {
get_repo_base() {
(
cd "`/bin/pwd`" &&
- cd "$1" &&
+ cd "$1" || cd "$1.git" &&
{
cd .git
pwd
diff --git a/t/t5701-clone-local.sh b/t/t5701-clone-local.sh
new file mode 100755
index 0000000..fb027f3
--- /dev/null
+++ b/t/t5701-clone-local.sh
@@ -0,0 +1,17 @@
+#!/bin/sh
+
+test_description='test local clone'
+. ./test-lib.sh
+
+test_expect_success 'preparing origin repository' \
+':>file && git add . && git commit -m1 && mv .git a.git'
+
+unset GIT_CONFIG
+
+test_expect_success 'local clone without .git suffix' \
+'git clone -l -s a b && cd b && git fetch && cd ..'
+
+test_expect_success 'local clone with .git suffix' \
+'git clone -l -s a.git c && cd c && git fetch && cd ..'
+
+test_done
--
1.5.2.1.141.g3c63
^ permalink raw reply related
* Re: [PATCH] [RFC] Generational repacking
From: Sam Vilain @ 2007-06-06 22:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkewya4s.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Sam Vilain <sam.vilain@catalyst.net.nz> writes:
>
>> + c_gen=`eval "echo \\\$c_gen_$i"`
>> + packs=`eval "echo \\\$gen_$i"`
>>
>
> I used to write something like these myself when I was young
> ;-), but it is enough to write:
>
> eval 'c_gen=$c_gen_'$i
> eval "packs=\$gen_$i"
>
Would've re-written it in Perl ages ago :P
Sam.
^ permalink raw reply
* Re: git does the wrong thing with ambiguous names
From: Alex Riesen @ 2007-06-06 22:58 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git Mailing List
In-Reply-To: <4667319C.9070302@nrlssc.navy.mil>
Brandon Casey, Thu, Jun 07, 2007 00:13:48 +0200:
>
> When a branch and tag have the same name, a git-checkout using that name
> succeeds (exits zero without complaining), switches to the _branch_, but
> updates the working directory contents to that specified by the _tag_.
> git-status show modified files.
Bad. To reproduce:
mkdir a && cd a && git init && :> a && git add . && git commit -m1 &&
:>b && git add . && git commit -m2 && git tag master HEAD^ &&
find .git/refs/ && gco -b new && gco master && git status
> Looks like the ambiguity issue was brought up last year, and git is now
> *supposed* to warn when it encounters an ambiguous name. I agree with
> Petr, it should fail violently, preferably as Josef Weidendorfer
> suggests also printing out the ambiguous matches so the user can cut and
> paste.
>
That'd be failing friendly :) Very good idea
^ 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