* Re: [PATCH] Fix problem with authentification on http repository.
From: Junio C Hamano @ 2007-09-29 23:38 UTC (permalink / raw)
To: jean.guyader; +Cc: git, Jean Guyader
In-Reply-To: <11911047823308-git-send-email-jean.guyader@linkea.org>
jean.guyader@linkea.org writes:
> From: Jean Guyader <jean.guyader@gmail.com>
>
> Curl uses the option -u user:passwd and not the user:password
> given in the url.
> The solution was to extract user:password from the url and set
> the option.
>
> Here the regex used :
> sed -re 's-.*http://([^:]*):([^@]+)@.*-\1:\2-g'
This is more like "allowing embedded authentication credentials
in URL for http transport".
We never supported URLs with embedded credentials (see
Documentation/urls.txt), partly because nobody asked for it, but
more importantly because giving -n to curl to have it read from
user's .netrc is generally much more preferred approach.
^ permalink raw reply
* [PATCH] Fix adding a submodule with a remote url
From: Daniel Barkalow @ 2007-09-29 23:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Without this, a non-path URL gets lost before the clone.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
I'm not sure if the use of $repo in this function is right, but this is
definitely an improvement.
git-submodule.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 727b1d3..4aaaaab 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -138,8 +138,8 @@ module_add()
# it is local
if base=$(get_repo_base "$repo"); then
repo="$base"
- realrepo=$repo
fi
+ realrepo=$repo
;;
esac
--
1.5.3.2.1107.ge9eab8-dirty
^ permalink raw reply related
* Re: [PATCH] Fix problem with authentification on http repository.
From: Johannes Schindelin @ 2007-09-29 23:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: jean.guyader, git, Jean Guyader
In-Reply-To: <7v8x6pjb4c.fsf@gitster.siamese.dyndns.org>
Hi,
On Sat, 29 Sep 2007, Junio C Hamano wrote:
> jean.guyader@linkea.org writes:
>
> > From: Jean Guyader <jean.guyader@gmail.com>
> >
> > Curl uses the option -u user:passwd and not the user:password
> > given in the url.
> > The solution was to extract user:password from the url and set
> > the option.
> >
> > Here the regex used :
> > sed -re 's-.*http://([^:]*):([^@]+)@.*-\1:\2-g'
>
> This is more like "allowing embedded authentication credentials
> in URL for http transport".
>
> We never supported URLs with embedded credentials (see
> Documentation/urls.txt), partly because nobody asked for it, but
> more importantly because giving -n to curl to have it read from
> user's .netrc is generally much more preferred approach.
To elaborate on that: if you fetch from somewhere, your url, username and
password can be read from the output of "ps ax | grep http" very easily.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix problem with authentification on http repository.
From: Junio C Hamano @ 2007-09-30 0:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: jean.guyader, git, Jean Guyader
In-Reply-To: <Pine.LNX.4.64.0709300039430.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sat, 29 Sep 2007, Junio C Hamano wrote:
>
>> We never supported URLs with embedded credentials (see
>> Documentation/urls.txt), partly because nobody asked for it, but
>> more importantly because giving -n to curl to have it read from
>> user's .netrc is generally much more preferred approach.
>
> To elaborate on that: if you fetch from somewhere, your url, username and
> password can be read from the output of "ps ax | grep http" very easily.
Actually Documentation/howto/setup-git-server-over-http.txt
talks about http://user@server/path/ format. How well does this
work in practice? If it does, we should update Documentation/urls.txt
to allow optional user@ there like...
---
Documentation/urls.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index e67f914..c9aab86 100644
--- a/Documentation/urls.txt
+++ b/Documentation/urls.txt
@@ -6,8 +6,8 @@ to name the remote repository:
===============================================================
- rsync://host.xz/path/to/repo.git/
-- http://host.xz/path/to/repo.git/
-- https://host.xz/path/to/repo.git/
+- http://{startsb}user@{endsb}host.xz/path/to/repo.git/
+- https://{startsb}user@{endsb}host.xz/path/to/repo.git/
- git://host.xz/path/to/repo.git/
- git://host.xz/~user/path/to/repo.git/
- ssh://{startsb}user@{endsb}host.xz{startsb}:port{endsb}/path/to/repo.git/
^ permalink raw reply related
* [PATCH] Improve bash prompt to detect various states like an unfinished merge
From: Robin Rosenberg @ 2007-09-30 0:20 UTC (permalink / raw)
To: gitster; +Cc: git, johannes.sixt, spearce, Robin Rosenberg
In-Reply-To: <20070904071301.GA18160@spearce.org>
This patch makes the git prompt (when enabled) show if a merge or a
rebase is unfinished. It also detects if a bisect is being done as
well as detached checkouts.
An uncompleted git-am cannot be distinguised from a rebase (the
non-interactive version). Instead of having an even longer prompt
we simply ignore that and hope the power users that use git-am knows
the difference.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
contrib/completion/git-completion.bash | 37 ++++++++++++++++++++++++++++---
1 files changed, 33 insertions(+), 4 deletions(-)
This includes Shawns improvements
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index e760930..6854074 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -64,12 +64,41 @@ __gitdir ()
__git_ps1 ()
{
- local b="$(git symbolic-ref HEAD 2>/dev/null)"
- if [ -n "$b" ]; then
+ local g="$(git rev-parse --git-dir 2>/dev/null)"
+ if [ -n "$g" ]; then
+ local r
+ local b
+ if [ -d "$g/../.dotest" ]
+ then
+ r="|AM/REBASE"
+ b="$(git symbolic-ref HEAD 2>/dev/null)"
+ elif [ -f "$g/.dotest-merge/interactive" ]
+ then
+ r="|REBASE-i"
+ b="$(cat $g/.dotest-merge/head-name)"
+ elif [ -d "$g/.dotest-merge" ]
+ then
+ r="|REBASE-m"
+ b="$(cat $g/.dotest-merge/head-name)"
+ elif [ -f "$g/MERGE_HEAD" ]
+ then
+ r="|MERGING"
+ b="$(git symbolic-ref HEAD 2>/dev/null)"
+ else
+ if [ -f $g/BISECT_LOG ]
+ then
+ r="|BISECTING"
+ fi
+ if ! b="$(git symbolic-ref HEAD 2>/dev/null)"
+ then
+ b="$(cut -c1-7 $g/HEAD)..."
+ fi
+ fi
+
if [ -n "$1" ]; then
- printf "$1" "${b##refs/heads/}"
+ printf "$1" "${b##refs/heads/}$r"
else
- printf " (%s)" "${b##refs/heads/}"
+ printf " (%s)" "${b##refs/heads/}$r"
fi
fi
}
--
1.5.3.1.g80926
^ permalink raw reply related
* [ANNOUNCE] GIT 1.5.3.3
From: Junio C Hamano @ 2007-09-30 1:27 UTC (permalink / raw)
To: git; +Cc: linux-kernel
In-Reply-To: <7vir66pjhs.fsf@gitster.siamese.dyndns.org>
The latest maintenance release GIT 1.5.3.3 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.3.3.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.3.3.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.3.3.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.5.3.3-1.$arch.rpm (RPM)
GIT v1.5.3.3 Release Notes
==========================
Fixes since v1.5.3.2
--------------------
* git-quiltimport did not like it when a patch described in the
series file does not exist.
* p4 importer missed executable bit in some cases.
* The default shell on some FreeBSD did not execute the
argument parsing code correctly and made git unusable.
* git-svn incorrectly spawned pager even when the user user
explicitly asked not to.
* sample post-receive hook overquoted the envelope sender
value.
* git-am got confused when the patch contained a change that is
only about type and not contents.
* git-mergetool did not show our and their version of the
conflicted file when started from a subdirectory of the
project.
* git-mergetool did not pass correct options when invoking diff3.
* git-log sometimes invoked underlying "diff" machinery
unnecessarily.
----------------------------------------------------------------
Changes since v1.5.3.2 are as follows:
Carlos Rica (1):
Move make_cache_entry() from merge-recursive.c into read-cache.c
Dan Nicholson (1):
quiltimport: Skip non-existent patches
David Brown (1):
Detect exec bit in more cases.
David Kastrup (1):
Supplant the "while case ... break ;; esac" idiom
Eric Wong (1):
git-svn: don't attempt to spawn pager if we don't want one
Glenn Rempe (1):
Fixed minor typo in t/t9001-send-email.sh test command line.
J. Bruce Fields (1):
user-manual: don't assume refs are stored under .git/refs
Jakub Narebski (2):
gitweb: Remove parse_from_to_diffinfo code from git_patchset_body
gitweb: No difftree output for trivial merge
Jim Meyering (2):
unexpected Make output (e.g. from --debug) causes build failure
Do not over-quote the -f envelopesender value.
Johannes Schindelin (1):
apply: get rid of --index-info in favor of --build-fake-ancestor
Johannes Sixt (2):
gitattributes.txt: Remove a duplicated paragraph about 'ident' and 'crlf' interaction.
gitattributes.txt: Be more to the point in the filter driver description.
Junio C Hamano (3):
Documentation/git-lost-found.txt: drop unnecessarily duplicated name.
Mergetool generating blank files (1.5.3)
GIT 1.5.3.3
Linus Torvalds (1):
Fix revision log diff setup, avoid unnecessary diff generation
Matt Kraai (2):
Move the paragraph specifying where the .idx and .pack files should be
Conjugate "search" correctly in the git-prune-packed man page.
Michael Smith (1):
user-manual: Explain what submodules are good for.
Miklos Vajna (2):
User Manual: add a chapter for submodules
git-bundle: fix commandline examples in the manpage
Randy Dunlap (1):
core-tutorial: correct URL
Shawn Bohrer (1):
Fix spelling of overridden in documentation
Theodore Ts'o (2):
mergetool: fix emerge when running in a subdirectory
mergetool: Fix typo in options passed to kdiff3
^ permalink raw reply
* Re: A tour of git: the basics (and notes on some unfriendly messages)
From: Carl Worth @ 2007-09-30 3:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wcinvth.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2965 bytes --]
On Fri, 28 Sep 2007 17:45:30 -0700, Junio C Hamano wrote:
> Thanks for starting this. It was an interesting read.
You're welcome. I hope it's useful for people.
The original goal was to demonstrate that git is no harder to learn
than mercurial. So that attempt is done, now, (whether successful or
not, I can't really judge).
Now, after getting some initial feedback, it's clear that the document
could further be improved by focusing on the "git way" of doing things
that aren't as natural in hg, (like multiple branches in a single
repository).
Rather than extending the current document, though, I think I'll just
draw up on outline based on what I think would be a good order to
introduce the topics. And then I'll see what text in the current
user's guide could plug into that outline, and what pieces might
be missing or could be improved.
At least, that's my thoughts for now. I don't know if I'll get around
to it though, (we'll have to see if I get annoyed into doing that work
like I got annoyed into this first project).
> "git help init" would give man page. The time when the short
> help is given is when you mistype options, as in:
>
> $ git init --huh?
Oh, and that's *really* short output. Just a summary of the
command-line options and no description. If you look at "hg help" it
has a middle-ground option which is little more than a brief
description and a very small number of options. I think that's a
useful thing to consider for "git help". Or, perhaps just carefully
construct the man page so that this most important information is
first. See "git help clone" for example which does have a better order
than "git help init" in my opinion.
Meanwhile, "git init --huh?" is totally appropriate in just printing
usage information. That's really all you want to see if you
forget the exact name of a particular command-line option.
Trying a couple of random examples though, git could be better in some
cases:
$ git log --pretty=complete
fatal: invalid --pretty format: complete
That's a fairly specific error message, but no information on what I
might have meant to say. A fix should be be quite simple, (presumably
there's a list of --pretty options it just looped through and it might
as well print them out).
$ git log --format=fuller
fatal: unrecognized argument: --format=fuller
There's no usage given in this case at all. It should print some usage
statement, hopefully containing --pretty. Admittedly, this one is
*really* hard to fix entirely since there is a ridiculously large
number of possible options to a command like "git log". But a aummary
of the most common stuff should still help.
Thanks for the various typo fixes. I've implemented those, (and the
things submitted by others). There were some particularly bad markup
problems where "git commit <file>" was being misinterpreted and
presented as "git commit" which was fairly disastrous for my intended
meaning.
Hopefully it's much better now.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: A tour of git: the basics (and notes on some unfriendly messages)
From: Carl Worth @ 2007-09-30 3:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wcinvth.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2965 bytes --]
On Fri, 28 Sep 2007 17:45:30 -0700, Junio C Hamano wrote:
> Thanks for starting this. It was an interesting read.
You're welcome. I hope it's useful for people.
The original goal was to demonstrate that git is no harder to learn
than mercurial. So that attempt is done, now, (whether successful or
not, I can't really judge).
Now, after getting some initial feedback, it's clear that the document
could further be improved by focusing on the "git way" of doing things
that aren't as natural in hg, (like multiple branches in a single
repository).
Rather than extending the current document, though, I think I'll just
draw up on outline based on what I think would be a good order to
introduce the topics. And then I'll see what text in the current
user's guide could plug into that outline, and what pieces might
be missing or could be improved.
At least, that's my thoughts for now. I don't know if I'll get around
to it though, (we'll have to see if I get annoyed into doing that work
like I got annoyed into this first project).
> "git help init" would give man page. The time when the short
> help is given is when you mistype options, as in:
>
> $ git init --huh?
Oh, and that's *really* short output. Just a summary of the
command-line options and no description. If you look at "hg help" it
has a middle-ground option which is little more than a brief
description and a very small number of options. I think that's a
useful thing to consider for "git help". Or, perhaps just carefully
construct the man page so that this most important information is
first. See "git help clone" for example which does have a better order
than "git help init" in my opinion.
Meanwhile, "git init --huh?" is totally appropriate in just printing
usage information. That's really all you want to see if you
forget the exact name of a particular command-line option.
Trying a couple of random examples though, git could be better in some
cases:
$ git log --pretty=complete
fatal: invalid --pretty format: complete
That's a fairly specific error message, but no information on what I
might have meant to say. A fix should be be quite simple, (presumably
there's a list of --pretty options it just looped through and it might
as well print them out).
$ git log --format=fuller
fatal: unrecognized argument: --format=fuller
There's no usage given in this case at all. It should print some usage
statement, hopefully containing --pretty. Admittedly, this one is
*really* hard to fix entirely since there is a ridiculously large
number of possible options to a command like "git log". But a summary
of the most common stuff should still help.
Thanks for the various typo fixes. I've implemented those, (and the
things submitted by others). There were some particularly bad markup
problems where "git commit <file>" was being misinterpreted and
presented as "git commit" which was fairly disastrous for my intended
meaning.
Hopefully it's much better now.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Script to backdate tags
From: Michael Olson @ 2007-09-30 3:16 UTC (permalink / raw)
To: git
[-- Attachment #1.1: Type: text/plain, Size: 533 bytes --]
After importing one of my projects from Arch, I wanted to add tags that
indicated its major releases. Unfortunately, these tags for older
releases would show up before the more recent releases in the gitweb
output. I searched in vain for a way of backdating tags, and finally
decided to make a script to do this for me. Here it is.
This may run into issues if someone uses the "\" character in their tag
names, but I didn't want to bother fixing this until it was affirmed
that this script would be considered generally useful.
[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: git-backdate-tag --]
[-- Type: text/x-sh, Size: 763 bytes --]
#!/bin/sh
#
# git-backdate-tag: Change the date of an existing tag, replacing the
# tag reference with the newly-generated tag object.
#
# Usage: git-backdate-tag TAG DATE
usage () {
echo "Usage: git-backdate-tag TAG DATE"
}
if [ -n "$3" ]; then
usage
exit 1
elif [ -z "$2" ]; then
usage
exit 1
fi
# Set parameters
tag="$1"
date=$(date --date="$2" +%s)
if [ $? -ne 0 ]; then
echo Could not parse date
exit 1
fi
# Replace old date with new date
newtagobj=$(git cat-file tag "$tag" | \
sed -r -e "s/^(tagger .+) ([^ \\n]+) ([^ \\n]+)\$/\1 $date \3/1" | \
git mktag)
if [ $? -ne 0 ]; then
echo Could not create replacement tag object
exit 1
fi
# Set tag to new tag object
git update-ref refs/tags/"$tag" $newtagobj
[-- Attachment #3: Type: text/plain, Size: 255 bytes --]
--
Michael Olson -- FSF Associate Member #652 |
http://mwolson.org/ -- Jabber: mwolson_at_hcoop.net | /` |\ | | |
Sysadmin -- Hobbies: Lisp, GP2X, HCoop | |_] | \| |_|
Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner |
^ permalink raw reply
* Re: Stashing untracked files
From: Neil Macneale @ 2007-09-30 3:59 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0709292259070.28395@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> [please do not cull me from the Cc: list, especially if you quote me.]
>
> On Sat, 29 Sep 2007, Neil Macneale wrote:
>
>> Performing an add would require me to remove those file from the index
>> at a later date in the event that I don't want to commit them on the
>> next commit.
>
> Wrong.
>
> If you "git add <new-file>" and then "git stash", it will no longer have
> the file in the index. Instead, the index will agree with the HEAD (which
> does not have <new-file>).
>
> Ciao,
> Dscho
To be a little more clear, this is why I'd like to stash untracked files.
$ <hack hack> # source tree is a mess
$ git stash -u # stash everything, even untracked files. I never
# suggesting modifying the default behavior.
$ <fix bug>
$ git commit -a
$ git stash apply
$ hack some more
$ git add file1 file2 # I'm ready for some things to be committed,
# but my source tree is still a mess.
$ git commit
To do what you are suggesting would be something like this (correct me
if I'm wrong):
$ <hack hack>
$ git add . # Additional step, not a big deal.
$ git stash
$ <fix bug>
$ git commit -a
$ git stash apply
$ git reset HEAD <all file I don't actually need to add but was forced
to add in step above.>
# What concerns me is that I may not reset some files
# that need to be reset, or reset other ones which
# should not be reset. This is the headache I want to
# avoid.
$ <hack hack>
$ git add file1 file2
$ git commit
git stash is an acknowledgment that not everything needs to be
committed, and sometimes working source trees are messy. Prior to the
stash command, I just accepted that I'd need to commit everything and do
some maintenance to un-commit those changes. stash is awesome for me
and the realities of the way I need to work. IMHO, it would be the best
thing since sliced bread if it handled untracked files.
If this is really just a problem for me, I can write a shell script to
do the dirty work. I just wonder if it is a common enough use case that
it merits support in the tool itself.
Cheers,
Neil
^ permalink raw reply
* Re: Script to backdate tags
From: Michael Olson @ 2007-09-30 4:29 UTC (permalink / raw)
To: git
In-Reply-To: <87bqbklu5r.fsf@hariken.mwolson.org>
[-- Attachment #1: Type: text/plain, Size: 440 bytes --]
Michael Olson <mwolson@gnu.org> writes:
> This may run into issues if someone uses the "\" character in their
> tag names, [snip].
In fact, this isn't the case after all.
--
Michael Olson -- FSF Associate Member #652 |
http://mwolson.org/ -- Jabber: mwolson_at_hcoop.net | /` |\ | | |
Sysadmin -- Hobbies: Lisp, GP2X, HCoop | |_] | \| |_|
Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner |
[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]
^ permalink raw reply
* Re: Script to backdate tags
From: Junio C Hamano @ 2007-09-30 5:16 UTC (permalink / raw)
To: Michael Olson; +Cc: git
In-Reply-To: <871wcglqrg.fsf@hariken.mwolson.org>
Michael Olson <mwolson@gnu.org> writes:
> Michael Olson <mwolson@gnu.org> writes:
>
>> This may run into issues if someone uses the "\" character in their
>> tag names, [snip].
>
> In fact, this isn't the case after all.
Wouldn't it be easier to create the tag with the desired
timestamp from the beginning, by exporting GIT_COMMITTER_DATE?
^ permalink raw reply
* Re: [PATCH v3 2/2] fetch/push: readd rsync support
From: Junio C Hamano @ 2007-09-30 6:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: spearce, Daniel Barkalow, git
In-Reply-To: <Pine.LNX.4.64.0709290134000.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> We lost rsync support when transitioning from shell to C. Support it
> again (even if the transport is technically deprecated, some people just
> do not have any chance to use anything else).
s/chance/choice/?
> +test "$TEST_RSYNC" && {
Somehow this feels dirty ... perhaps leave early like:
if test -z "$TEST_RSYNC"
then
test_expect_success 'skipping rsync transport tests' :
test_done
exit
fi
> diff --git a/transport.c b/transport.c
> index 4f9cddc..a2ee8f3 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -6,6 +6,330 @@
> ...
> +{
> + struct strbuf buf = STRBUF_INIT, temp_dir = STRBUF_INIT;
> + struct ref dummy, *tail = &dummy;
> + struct child_process rsync;
> + const char *args[5];
> + int temp_dir_len;
> +
> + /* copy the refs to the temporary directory */
> +
> + strbuf_addstr(&temp_dir, git_path("rsync-refs-XXXXXX"));
> + if (!mkdtemp(temp_dir.buf))
> + die ("Could not make temporary directory");
I wonder how portable mkdtemp() is (it does not seem to be POSIX);
would we need something in compat/ perhaps based on tempnam()?
> +static int fetch_objs_via_rsync(struct transport *transport,
> + int nr_objs, struct ref **to_fetch)
> +{
> + struct strbuf buf = STRBUF_INIT;
> + struct child_process rsync;
> + const char *args[8];
> + int result;
> +
> + strbuf_addstr(&buf, transport->url);
> + strbuf_addstr(&buf, "/objects/");
> +
> + memset(&rsync, 0, sizeof(rsync));
> + rsync.argv = args;
> + rsync.stdout_to_stderr = 1;
> + args[0] = "rsync";
> + args[1] = transport->verbose ? "-rv" : "-r";
> + args[2] = "--ignore-existing";
> + args[3] = "--exclude";
> + args[4] = "info";
> + args[5] = buf.buf;
> + args[6] = get_object_directory();
> + args[7] = NULL;
Hmm, we used to do "rsync $remote/objects/ $our/.git/objects/",
but this omits the trailing "/" from our side. I suspect the
reason was to deal with the case where our .git/objects was a
symlink to elsewhere (which was how you did alternates before
alternates was invented), which may not matter anymore these
days.
^ permalink raw reply
* [PATCH] prune, rm, show remote: exit with error code 1 on failure
From: Jari Aalto @ 2007-09-30 6:18 UTC (permalink / raw)
To: git
In-Reply-To: <ps01nxvd.fsf@blue.sea.net>
- (rm_remote): Return error code 1 on failure.
- (show_remote): Return error code 1 on failure.
- (prune_remote): Return error code 1 on failure.
- (@ARGV eq show):
exit in case of 'No such remote'.
- (@ARGV eq prune):
- exitin case of 'No such remote'.
- (@ARGV eq rm):
- exit in case of 'No such remote'.
Signed-off-by: Jari Aalto <jari.aalto AT cante.net>
---
git-remote.perl | 19 +++++++++++++------
1 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/git-remote.perl b/git-remote.perl
index b7c1e01..84a9b5c 100755
--- a/git-remote.perl
+++ b/git-remote.perl
@@ -218,7 +218,7 @@ sub prune_remote {
my ($name, $ls_remote) = @_;
if (!exists $remote->{$name}) {
print STDERR "No such remote $name\n";
- return;
+ return 1;
}
my $info = $remote->{$name};
update_ls_remote($ls_remote, $info);
@@ -235,7 +235,7 @@ sub show_remote {
my ($name, $ls_remote) = @_;
if (!exists $remote->{$name}) {
print STDERR "No such remote $name\n";
- return;
+ return 1;
}
my $info = $remote->{$name};
update_ls_remote($ls_remote, $info);
@@ -320,7 +320,7 @@ sub rm_remote {
my ($name) = @_;
if (!exists $remote->{$name}) {
print STDERR "No such remote $name\n";
- return;
+ return 1;
}
$git->command('config', '--remove-section', "remote.$name");
@@ -381,9 +381,12 @@ elsif ($ARGV[0] eq 'show') {
print STDERR "Usage: git remote show <remote>\n";
exit(1);
}
+ my $status = 0;
for (; $i < @ARGV; $i++) {
- show_remote($ARGV[$i], $ls_remote);
+ my $ret = show_remote($ARGV[$i], $ls_remote);
+ $status = $ret if $ret;
}
+ exit($status);
}
elsif ($ARGV[0] eq 'update') {
if (@ARGV <= 1) {
@@ -409,9 +412,12 @@ elsif ($ARGV[0] eq 'prune') {
print STDERR "Usage: git remote prune <remote>\n";
exit(1);
}
+ my $status = 0;
for (; $i < @ARGV; $i++) {
- prune_remote($ARGV[$i], $ls_remote);
+ my $ret = prune_remote($ARGV[$i], $ls_remote);
+ $status = $ret if $ret;
}
+ exit($status);
}
elsif ($ARGV[0] eq 'add') {
my %opts = ();
@@ -455,7 +461,8 @@ elsif ($ARGV[0] eq 'rm') {
print STDERR "Usage: git remote rm <remote>\n";
exit(1);
}
- rm_remote($ARGV[1]);
+ my $status = rm_remote($ARGV[1]);
+ exit($status) if $status;
}
else {
print STDERR "Usage: git remote\n";
--
1.5.3.2.81.g17ed
^ permalink raw reply related
* git-svn and hierarchal branches.
From: David Brown @ 2007-09-30 7:07 UTC (permalink / raw)
To: git
I'm trying to use git-svn to track the 'Tango' SVN repository
<http://www.dsource.org/projects/tango/wiki/Download>
Their layout is mostly standard, except that they have an extra hierarchy
in the branch directory (branch/user1, branch/user2, branch/D1_0 for a
release).
Is this something I can easily track with git-svn, or am I best trying to
do it manually?
Thanks,
David
^ permalink raw reply
* Re: Script to backdate tags
From: Michael Olson @ 2007-09-30 6:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vps00ivgh.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1318 bytes --]
Junio C Hamano <gitster@pobox.com> writes:
> Michael Olson <mwolson@gnu.org> writes:
>
>> After importing one of my projects from Arch, I wanted to add tags
>> that indicated its major releases. Unfortunately, these tags for
>> older releases would show up before the more recent releases in the
>> gitweb output. I searched in vain for a way of backdating tags, and
>> finally decided to make a script to do this for me. Here it is.
>
> Wouldn't it be easier to create the tag with the desired
> timestamp from the beginning, by exporting GIT_COMMITTER_DATE?
Ah, I didn't know about that environment variable.
Would it be possible to mention that option on the git-tag manpage?
Backdating tags is very handy for projects which are converting their
entire history from another VCS to git, and wish to denote releases that
were not previously tagged. (Making a separate Arch branch for every
single release was such a hassle that I didn't bother with it. Git is
much nicer in that area with its concept of tags and tag objects.)
--
Michael Olson -- FSF Associate Member #652 |
http://mwolson.org/ -- Jabber: mwolson_at_hcoop.net | /` |\ | | |
Sysadmin -- Hobbies: Lisp, GP2X, HCoop | |_] | \| |_|
Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner |
[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]
^ permalink raw reply
* [ANNOUNCE] qgit-2.0
From: Marco Costalba @ 2007-09-30 7:13 UTC (permalink / raw)
To: Git, linux-kernel
This is the final qgit-2.0
With qgit you will be able to browse revision histories, view patch content
and changed files, graphically following different development branches.
IMPORTANT NOTE
git 1.5.3 or better is required, Qt 4.3 or better is required.
FEATURES
- View revisions, diffs, files history, files annotation, archive tree.
- Commit changes visually cherry picking modified files.
- Apply or format patch series from selected commits, drag and
drop commits between two instances of qgit.
- Associate commands sequences, scripts and anything else executable
to a custom action. Actions can be run from menu and corresponding
output is grabbed by a terminal window.
- qgit implements a GUI for the most common StGIT commands like push/pop
and apply/format patches. You can also create new patches or refresh
current top one using the same semantics of git commit, i.e. cherry
picking single modified files.
NEW IN THIS RELEASE
This is the final public release of the shining new qgit 2.0 based on
the shining new Qt 4.3 libraries.
All the features of the stable series have been ported. In addition this
new release sports a better GUI both on visually side and on usability side.
Annotation code is much improved in speed and in power, as example
now follows file renames, try it on any git tree file to see a real example.
A new and much improved repository browsing experience is now possible,
in particular you don't need to switch to patch tab to view diff
content anymore. Patch information, together with patch description,
is shown in bottom left pane.
Finally, qgit works natively under Windows due to Qt 4.3 libraries.
The detailed list of changes is very long and interested people can
read from public qgit repository.
Although there are a lot of new features code is considered stable due
to have been very long in 'rc' state.
You can download the tarball from
http://sourceforge.net/projects/qgit
or clone the public git repository at
git://git.kernel.org/pub/scm/qgit/qgit4.git
Please, check the shipped README for detailed build and install information.
Have fun
Marco
^ permalink raw reply
* Re: A tour of git: the basics (and notes on some unfriendly messages)
From: Steffen Prohaska @ 2007-09-30 8:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Carl Worth, Shawn O. Pearce
In-Reply-To: <7vlkapjeir.fsf@gitster.siamese.dyndns.org>
On Sep 30, 2007, at 12:25 AM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> - git push: prints updates of remote heads. A message about
>> failing to update a remote head may get lost.
>
> Please do not remove the report of successful update, as people
> often say "git push" or "git push $there" without explicitly
> saying which refs to push. When pushing out to publish, I say
> "git push ko" (to mean k.org) and I _want_ my positive feedback.
Yes but it's pretty technical.
A much simpler output could be easier to scan by a human
updating 'refs/heads/master' .. fast forward .. ok.
updating 'refs/heads/pu' .. forced non-fast forward .. ok.
updating 'refs/heads/next' ..
ERROR: 'refs/heads/next' not updating to non-fast forward
exit(1) here.
If we exit after the very first problem it can't get lost.
After fixing the issue you can just 'git push' again.
>> - git merge: the fact that a merge is a fast forward merge gets
>> printed at the very top, followed by (often a lot of) diffstat.
>> I know diffstat can help to judge if the merge did what you
>> expected. But even more important is the fact that the merge
>> was just a fast forward, which may get buried under lots of output.
>
> I do not think fast-forwardness is particularly interesting. If
> you find fast-forwardness interesting, I suspect you would even
> want to know what _your_ change that were not in the other side
> of the merge, which is something that we do not even report
> right now.
I use it to advance a branch to a temporary integration branch.
At that point I expect that the merge is a fast forward. Here's
what I do.
git checkout -b for/master master
git merge branch-with-good-topics
git branch -f scratch
git push compileservers # pushes scratch for automatic builds
Now I wait for compiles to finish. Typically I continue not before
the next morning. If everything's ok I do.
git checkout master
git merge for/master
git push
The last merge must be a fast forward. This is the only fact I'm
interested in. I could do 'git reset' or 'git branch -f' but then
I'd loose the check if it's a fast forward.
I don't merge directly to master to avoid any accidentally push.
I can also easily revert by just deleting 'for/master'.
Maybe there's a better workflow?
>> Maybe git should become more quiet, as other unix tools are, and
>> per default only report problems. Technical details and progress
>> could be requested explicitly by '--verbose' or similar.
>
> I'd agree with this sentiment in principle, and many of the
> things you propose to remove above fall into the "unnecessary
> clutter" category. But some of the existing output fall into
> the "necessary info" category --- diffstart after merge
I agree. Could we print the note about fast forward _after_ the
diffstat? Maybe there are more useful oneline information that
could be output there.
> and report of successful remote ref updates are such things, so we
> should be careful not to go overboard.
But the output could be less technical and more human readable.
Also diffstat's output and "git push" are different. diffstats
change with the content of your repo. "git push" just succeeds
or fails. If is succeeds it updates remote refs according to your
configuration. There is no new information in the output beyond
success or failure [which is not quite true if you depend on
git push finding matching refs automatically -- I don't]. I don't
think the sha1's printed are needed by anyone. And if someone
needs them, he could call push with '--verbose'.
I asked about a '--dry-run' switch to "git push" some time ago,
which would only report what "git push" would do without actually
changing anything on the remote side. I'd use this to check what
I expect to do. Just in case I messed up my configuration. At the
time "git push" is actually pushing it's too late to fix a broken
configuration. I know '--dry-run' it's not trivial to implement
and I'll likely have no time to look into it.
Steffen
^ permalink raw reply
* Re: [PATCH] WinGit: include html pages from official git.git's html branch
From: Steffen Prohaska @ 2007-09-30 8:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0709300022080.28395@racer.site>
On Sep 30, 2007, at 1:23 AM, Johannes Schindelin wrote:
> Hi,
>
> On Sat, 29 Sep 2007, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>>> On Sat, 29 Sep 2007, Steffen Prohaska wrote:
>>>
>>>> It is assumed that a matching version of the html documentation is
>>>> available as the HEAD of /doc/git/html/.git. If not an error
>>>> will be
>>>> reported.
>>>>
>>>> This patch doesn't include a mechanism to fetch the html pages to
>>>> /doc/git/html/.git. You should manually clone them. Maybe this
>>>> could
>>>> handled as a submodule of msysgit?
>>>
>>> I'd rather handle it as in git.git, as another branch, and not check
>>> it out in /git/html/, but rather use "git read-tree
>>> --prefix=/tmp/WinGit/share/git/html origin/html", or some such.
>>
>> This is starting to smell like an opportunity to use the gitlink
>> stuff,
>> isn't it?
>
> I'd agree that we could have a submodule in /doc/git/html/. This way,
> even users of msysGit and GitMe would benefit.
And we could completely tag a WinGit release. The version of the
html docs included would be defined by the submodule's head in
/doc/git/html. This is what I had in mind when submitting the
patch. Maybe I didn't express this clearly.
I do not yet understand submodules sufficiently. Therefore I didn't
add a patch that actually sets up the submodule in /doc/git/html.
Maybe I'll do so later today.
Steffen
^ permalink raw reply
* Re: Stashing untracked files
From: Steffen Prohaska @ 2007-09-30 8:41 UTC (permalink / raw)
To: Neil Macneale; +Cc: git, Johannes Schindelin
In-Reply-To: <46FF1F1E.2050000@theory.org>
On Sep 30, 2007, at 5:59 AM, Neil Macneale wrote:
> git stash is an acknowledgment that not everything needs to be
> committed, and sometimes working source trees are messy. Prior to
> the stash command, I just accepted that I'd need to commit
> everything and do some maintenance to un-commit those changes.
> stash is awesome for me and the realities of the way I need to
> work. IMHO, it would be the best thing since sliced bread if it
> handled untracked files.
I agree, it could be a great tool. Even only to make me feel better
before running 'git clean' on a larger source tree when I was to
lazy to scan 'git clean -n' in detail.
BTW, I don't have results of the builds in my work tree but keep
them in a separate directory. Nearly everything in the work tree
is 'real' source code, maybe cluttered with some backups or tmp files.
> If this is really just a problem for me, I can write a shell script
> to do the dirty work. I just wonder if it is a common enough use
> case that it merits support in the tool itself.
I think it would be useful. Here is a problem I ran into last week:
A merge failed because it wanted to add a file not tracked by
the current branch. At first I didn't fully appreciate this fact
and thought that 'git stash' could help. But to do so, it would
need to store the _untracked_ file and remove it from the work tree.
This would allow the merge to succeed. Current stash didn't really
help.
Steffen
^ permalink raw reply
* Re: [PATCH] prune, rm, show remote: exit with error code 1 on failure
From: Junio C Hamano @ 2007-09-30 9:54 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <641soeuv.fsf@blue.sea.net>
Thanks.
Because this is a bugfix patch, we would want the fix applied to
'maint' to become part of 1.5.3.4, but your patch contained the
fix for "remote rm" that is not (and will not be) part of 'maint'.
I split the patch into two, applied the bits without "rm" part
to 'maint', merged the result into 'master' and applied the fix
for "rm" on 'master'.
^ permalink raw reply
* Re: A tour of git: the basics (and notes on some unfriendly messages)
From: Junio C Hamano @ 2007-09-30 10:17 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List, Carl Worth, Shawn O. Pearce
In-Reply-To: <E8851B12-AAA5-4B4D-9F28-C5AB5AEF0E57@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> ... If everything's ok I do.
>
> git checkout master
> git merge for/master
> git push
>
> The last merge must be a fast forward.
Last week I saw somebody (I think it was Shawn) mentioned a
trick:
git push . thisbranch:thatbranch
will moves thatbranch to thisbranch iff thisbranch is a
descendant of thatbranch. So doing
git push . for-master:master
instead of that checkout + merge command sequence would
obviously be a good solution for your particular use case.
Having said that it may make sense to swap the order so that the
diffstat is shown first and then a single line "Merge made by
recursive" or "Updatting A..B, Fast Forward" concludes the
report. At least, I do not think such a swapping would hurt the
usability, although people used to the UI may first feel uneasy.
I would not object to such a patch in principle.
^ permalink raw reply
* git-svn merge helper
From: Björn Steinbrink @ 2007-09-30 11:05 UTC (permalink / raw)
To: git
Hi,
I recently discovered git-svn and absolutey love it. One thing that I'm
missing though, is an equivalent of "svn merge" for merging between svn
remotes, to support the SVN way of using "squashed" merges, where you
just note the merge meta-data in the commit message. "git merge" didn't
work for me (and probably isn't expected to work) to merge between two
svn branches, so I've resorted to cherry-picking the required commits
one by one into a temporary branch and then squashing them together by
doing a --squash merge with a second temporary branch (as in [1]).
Of course that becomes extremely annoying if there are like 200
commits to merge, so I came up with the following script to help me.
It does just what I described above, but automated. Usage is like this:
git-svn-merge trunk 123 543
Which does the same as "svn merge -r123:543 trunk-url", except for being
incremental (ie. no huge one-time patch, eventually causing a massive
set of conflicts) and often faster.
In case of conflicts, it bails out and let's you fix them. Then you can
just re-run it with the same parameters again, as it automatically
determines where to start cherry-picking if you're currently on the
merge branch.
It's neither complete nor nice to look at, but it more or less gets the
job done, so I thought I'll just post it here, maybe someone picks it up
and brings it into shape.
Thanks,
Björn
[1] http://cheat.errtheblog.com/s/gitsvn/
#!/bin/sh
BRANCH=$(git branch | grep \* | cut -d ' ' -f2)
START=$(git svn find-rev r$2 $1)
END=$(git svn find-rev r$3 $1)
if echo $BRANCH | grep -q svnmerge/
then
START=$(git svn find-rev r$(git svn find-rev HEAD) $1)
else
git checkout -b svnmerge/$BRANCH
fi
for HASH in $(git log --pretty=format:%H --reverse $START..$END)
do
git cherry-pick $HASH || exit
done
git checkout $BRANCH
git checkout -b svnmerge/$BRANCH-squashed
git merge --squash svnmerge/$BRANCH
git commit -m "Merged changes from revisions $2-$3 from $1 into $BRANCH."
^ permalink raw reply
* Obliterating a commit
From: Wincent Colaiuta @ 2007-09-30 11:32 UTC (permalink / raw)
To: Git Mailing List
A couple of days ago I mistakenly checked in a file that had some
confidential information in it. I immediately realized and amended my
commit, and this is a local repository whose contents won't be
visible until I push them out.
So how do I *really* get rid of the that commit before publishing? I
couldn't find any porcelain or plumbing to do this. Do I have to
manually destroy it? ie. wind back the HEAD, manually remove the
commit object, the corresponding tree object, the corresponding file
blobs, and probably manually remove the entry from the reflog as well?
Is there a "shortcut" wherein I can somehow mark this commit and its
related tree and file blobs as unreachable, and then use git-prune to
erradicate them?
Cheers,
Wincent
^ permalink raw reply
* Re: Obliterating a commit
From: Matthias Kestenholz @ 2007-09-30 12:15 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Git Mailing List
In-Reply-To: <D2BD14BD-44F2-4D01-AAEE-6CBC2A2DE85B@wincent.com>
Hello,
2007/9/30, Wincent Colaiuta <win@wincent.com>:
> A couple of days ago I mistakenly checked in a file that had some
> confidential information in it. I immediately realized and amended my
> commit, and this is a local repository whose contents won't be
> visible until I push them out.
>
> So how do I *really* get rid of the that commit before publishing? I
> couldn't find any porcelain or plumbing to do this. Do I have to
> manually destroy it? ie. wind back the HEAD, manually remove the
> commit object, the corresponding tree object, the corresponding file
> blobs, and probably manually remove the entry from the reflog as well?
>
If you use ssh to push your changes (that is, you are not copying
or rsyncing packfiles), only commits, trees and blobs, which are reachable
through the DAG will be published. Commits and Blobs which are only
reachable through your reflog are not published, since the reflog only applies
to your local repository.
The simplest thing you could do is remove the reflog for HEAD and
refs/heads/master respectively your current branch and run 'git prune'
afterwards (if you have not repacked
already, otherwise you'd need to run 'git repack -a -d' or 'git gc' to get
rid of blobs inside your packfile.
> Is there a "shortcut" wherein I can somehow mark this commit and its
> related tree and file blobs as unreachable, and then use git-prune to
> erradicate them?
>
You don't need to mark anything -- it's sufficient that the blob with the
confidential information is only reachable through the reflog (which you
need to remove, obviously, if you want to get rid of the blob locally too)
Cheers,
Matthias
^ 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