* Re: A tour of git: the basics (and notes on some unfriendly messages)
From: Junio C Hamano @ 2007-09-29 22:25 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List, Carl Worth, Shawn O. Pearce
In-Reply-To: <E5C688F2-4A8D-402A-9757-5007BE4A8B25@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> Quite often git prints a lot of very technical information that
> is not very interesting as long as things succeed without error.
> Some examples are
> - git fetch (see above)
Probably.
> - git rebase: prints a lot of details that I'm not interested in
> unless the rebase fails.
Yes. Most of the clutter is coming from "am" which also should
be squelched.
Saying
Switched to branch <blah>
is good when the branch to rebase is specified.
"HEAD is now at ..."
is not useful -- it is a side effect of rewinding the head to
the --onto commit.
<blank line>
Applying <patch subject>
<blank line>
Wrote tree <tree object>
Committed: <commit object>
are coming from "am" for each patch. We could squelch these
into just one "Applying <patch subject>" and nothing else, which
would also help making "am" quieter.
> - 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.
> - 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.
> 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 and
report of successful remote ref updates are such things, so we
should be careful not to go overboard.
^ permalink raw reply
* Re: BUG: git remote show origin => error code 1
From: Junio C Hamano @ 2007-09-29 22:28 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <ps01nxvd.fsf@blue.sea.net>
Jari Aalto <jari.aalto@cante.net> writes:
> Consider this:
> ...
> Jari
>
> --
> Welcome to FOSS revolution: we fix and modify until it shines
Patches are welcome ;-)
^ permalink raw reply
* Re: Please pull mergetool.git
From: Junio C Hamano @ 2007-09-29 22:43 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: Git Mailing List
In-Reply-To: <E1Ibdbb-0006Ep-NS@candygram.thunk.org>
Thanks.
^ permalink raw reply
* [PATCH] Fix problem with authentification on http repository.
From: jean.guyader @ 2007-09-29 22:26 UTC (permalink / raw)
To: git; +Cc: Jean Guyader
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'
---
git-clone.sh | 3 ++-
git-fetch.sh | 8 ++++----
git-ls-remote.sh | 3 ++-
3 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index 5e582fe..57206ac 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -34,7 +34,8 @@ fi
http_fetch () {
# $1 = Remote, $2 = Local
- curl -nsfL $curl_extra_args "$1" >"$2" ||
+ curl_userpw=`echo "$1" | sed -re 's-http://([^:]*):([^@]+)@.*-\1:\2-g'`
+ curl -u "$curl_userpw" -nsfL $curl_extra_args "$1" >"$2" ||
case $? in
126|127) exit ;;
*) return $? ;;
diff --git a/git-fetch.sh b/git-fetch.sh
index e44af2c..0b7d055 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -268,13 +268,13 @@ fetch_per_ref () {
"`git config --bool http.noEPSV`" = true ]; then
noepsv_opt="--disable-epsv"
fi
-
- # Find $remote_name from ls-remote output.
+ pretty_remote=$(echo "$remote" | sed -re 's-http://([^:]+):([^@]+)@-http://\1:******@-g')
+ # Find $remote_name from ls-remote output.
head=$(echo "$ls_remote_result" | \
git fetch--tool -s pick-rref "$remote_name" "-")
expr "z$head" : "z$_x40\$" >/dev/null ||
- die "No such ref $remote_name at $remote"
- echo >&2 "Fetching $remote_name from $remote using $proto"
+ die "No such ref $remote_name at $pretty_remote"
+ echo >&2 "Fetching $remote_name from $pretty_remote using $proto"
case "$quiet" in '') v=-v ;; *) v= ;; esac
git-http-fetch $v -a "$head" "$remote" || exit
;;
diff --git a/git-ls-remote.sh b/git-ls-remote.sh
index d56cf92..d6e9906 100755
--- a/git-ls-remote.sh
+++ b/git-ls-remote.sh
@@ -61,7 +61,8 @@ http://* | https://* | ftp://* )
"`git config --bool http.noEPSV`" = true ]; then
curl_extra_args="${curl_extra_args} --disable-epsv"
fi
- curl -nsf $curl_extra_args --header "Pragma: no-cache" "$peek_repo/info/refs" ||
+ curl_userpw=`echo "$peek_repo" | sed -re 's-.*http://([^:]*):([^@]+)@.*-\1:\2-g'`
+ curl -u "$curl_userpw" -nsf $curl_extra_args --header "Pragma: no-cache" "$peek_repo/info/refs" ||
echo "failed slurping"
;;
--
1.5.2.4
^ permalink raw reply related
* Re: Stashing untracked files
From: Johannes Schindelin @ 2007-09-29 23:09 UTC (permalink / raw)
To: Tom Prince; +Cc: Benoit SIGOURE, Neil Macneale, git
In-Reply-To: <20070929222320.GB2947@hermes.priv>
Hi,
On Sat, 29 Sep 2007, Tom Prince wrote:
> > > You could stash untracked files that are not ignored (I personally
> > > ignore *.o, *.a and the like).
> >
> > And what if you happen to forget to ignore that? Or if you happen to
> > have an strace log in some file (which you did not ignore either)?
> >
> > Thanks, but I think the semantics of git stash is pretty well defined.
> > And it means that you stash away _tracked_ content that was not yet
> > committed.
> >
> > I mean, you can have your desired behaviour with
> >
> > $ git add .
> > $ git stash
> >
> > but if we were to fulfil your wish and change the default behaviour,
> > there is no way back to the current behaviour (which I happen to find
> > pretty sane).
>
> But
>
> git add .
> git stash
> git stash apply
>
> will not be a no-op any more.
It never was. (Or did you mean "git stash apply --index"?)
> It doesn't need to be a default, but there are certainly times when I
> would find the option to stash untracked files convenient.
But then I'll have to ask you why the untracked files, which are not
touched by git, have to be stashed anyway?
I'm seriously thinking that we are in deep "XY problem" land here.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix problem with authentification on http repository.
From: Johannes Schindelin @ 2007-09-29 23:10 UTC (permalink / raw)
To: jean.guyader; +Cc: git, Jean Guyader
In-Reply-To: <11911047823308-git-send-email-jean.guyader@linkea.org>
Hi,
On Sun, 30 Sep 2007, jean.guyader@linkea.org wrote:
> git-clone.sh | 3 ++-
> git-fetch.sh | 8 ++++----
> git-ls-remote.sh | 3 ++-
git-fetch is already a builtin in "next", and -clone and -ls-remote are
likely to follow suit.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] WinGit: include html pages from official git.git's html branch
From: Johannes Schindelin @ 2007-09-29 23:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steffen Prohaska, git
In-Reply-To: <7vr6khjf22.fsf@gitster.siamese.dyndns.org>
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.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] rebase -i: squash should retain the authorship of the _first_ commit
From: Johannes Schindelin @ 2007-09-29 23:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Avi Kivity, git
In-Reply-To: <7vzlz5jfa1.fsf@gitster.siamese.dyndns.org>
It was determined on the mailing list, that it makes more sense for a
"squash" to keep the author of the first commit as the author for the
result of the squash.
Make it so.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Sat, 29 Sep 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Sat, 29 Sep 2007, Avi Kivity wrote:
> >
> >> > > Can we make "amend" like squash, except that it keeps the
> >> > > first commit's authorship instead of the second? I often
> >> > > merge a commit with some minor fix that comes later, and
> >> > > usually want to keep the original author record.
> >
> > Thinking about this again... Maybe it is a better semantics
> > anyway? What do others think?
>
> I never thought about whose commit the squashed ones become
> before this thread, but making squash quack as if "commit
> --amend" was done after running "cherry-pick -n" the second and
> later ones feels like the most natural semantics to me.
Here you are.
Documentation/git-rebase.txt | 2 +-
git-rebase--interactive.sh | 2 +-
t/t3404-rebase-interactive.sh | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 0858fa8..e8e7579 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -298,7 +298,7 @@ rebasing.
If you want to fold two or more commits into one, replace the command
"pick" with "squash" for the second and subsequent commit. If the
commits had different authors, it will attribute the squashed commit to
-the author of the last commit.
+the author of the first commit.
In both cases, or when a "pick" does not succeed (because of merge
errors), the loop will stop to let you fix things, and you can continue
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 7a5aaa5..050140d 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -276,9 +276,9 @@ do_next () {
esac
failed=f
+ author_script=$(get_author_ident_from_commit HEAD)
output git reset --soft HEAD^
pick_one -n $sha1 || failed=t
- author_script=$(get_author_ident_from_commit $sha1)
echo "$author_script" > "$DOTEST"/author-script
case $failed in
f)
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index f2214dd..1113904 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -180,7 +180,7 @@ test_expect_success 'squash' '
'
test_expect_success 'retain authorship when squashing' '
- git show HEAD | grep "^Author: Nitfol"
+ git show HEAD | grep "^Author: Twerp Snog"
'
test_expect_success 'preserve merges with -p' '
--
1.5.3.2.1102.g9487
^ permalink raw reply related
* 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
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