* 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] 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] 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
* 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: 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
* [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: 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
* 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: 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: Stashing untracked files
From: Tom Prince @ 2007-09-29 22:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Benoit SIGOURE, Neil Macneale, git
In-Reply-To: <Pine.LNX.4.64.0709292248400.28395@racer.site>
> > 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 doesn't need to be a default, but there are certainly times when I would
find the option to stash untracked files convenient.
Tom
^ permalink raw reply
* [ANNOUNCE] tig-0.9.1
From: Jonas Fonseca @ 2007-09-29 22:14 UTC (permalink / raw)
To: git
Hello,
I would like to announce the next installment of tig, which mainly
brings a bunch of fixes. However, there was also room for a few new
features, such as support for cherry-picking to the current branch
(bound to 'C' by default), refreshing of the status view (bound to 'R'),
as well as better handling of unmerged entries in the status view by
suggesting users to launch git-mergetool (by default wired to 'M').
For tig-0.10, I hope to finally get time to finish splitting up the
tig.c file into more manageable pieces. It might also be the release
that will try to get handling of different encodings right by using
wchar_t.
What is tig?
------------
Tig is a ncurses-based text-mode interface for git. It can mainly
function as a git repository browser but can also additionally can act
as a pager for output from various git commands.
Homepage: http://jonas.nitro.dk/tig/
Manual: http://jonas.nitro.dk/tig/manual.html
Tarballs: http://jonas.nitro.dk/tig/releases/
Gitfeed: git://repo.or.cz/tig.git
Gitweb: http://repo.or.cz/w/tig.git
Changes in this release
-----------------------
Below is the diffstat and shortlog for changes made in this release.
.gitignore | 2 +
Makefile | 26 +++++---
SITES | 2 +-
VERSION | 2 +-
acinclude.m4 | 62 ++++++++++++++++++
configure.ac | 41 +------------
manual.txt | 4 +
tig.1.txt | 4 +
tig.c | 198 +++++++++++++++++++++++++++++++++++++++++++++++++---------
tigrc.5.txt | 3 +
10 files changed, 265 insertions(+), 79 deletions(-)
Jonas Fonseca (21):
tig-0.9.1.git
Use the more advanced iconv.m4 script from ELinks
Oops, always ensure that ICONV_CONST is defined
Support cherry-picking commits in main view to current branch
Handle REQ_NONE upfront in view_driver
Fix open_editor to make the file path relative to the project root
Fix out-of-range lineno when reloading the status view
Fix the clean rule to never remove generated doc files
Include autoconf file for 'make dist'
Remove unused 'view' argument from open_editor
Add support for refreshing/reloading the status view
Also ignore generated .md5 files for tarballs
Never put the release number in the tarball name for tagged versions
Ignore REQ_NONE in the help view and improve unbound request handling
Document the refresh request
Detect working trees and disable the status view when it is missing
Refactor code to open_external_viewer
Add support for launching git-mergetool from the status view
Cleanup status_request to make it reload the status view by default
SITES: 'Tarballs' is a bit more telling than 'Releases'
tig-0.9.1
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH] WinGit: include html pages from official git.git's html branch
From: Junio C Hamano @ 2007-09-29 22:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steffen Prohaska, git
In-Reply-To: <Pine.LNX.4.64.0709292149280.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> 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?
^ permalink raw reply
* Re: Fix revision log diff setup, avoid unnecessary diff generation
From: Junio C Hamano @ 2007-09-29 22:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Pierre Habouzit, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0709290932040.3579@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sat, 29 Sep 2007, Pierre Habouzit wrote:
>>
>> - if (strcmp(argv[i], "-z"))
>> - revs->diff = 1;
>> + revs->diff = strcmp(argv[i], "-z")
>> + && strcmp(argv[i], "--color")
>> + && strcmp(argv[i], "--no-color");
>
> The old code was already pretty damn ugly, the new code is worse (never
> mind the bug).
>
> I don't think we should care *at*all* about the actual argument string, we
> should just look at what the diffopts end up being at the end.
Thanks, I think this is the sanest thing to do.
^ permalink raw reply
* Re: [PATCH] rebase -i: support single-letter abbreviations for the actions
From: Junio C Hamano @ 2007-09-29 22:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Avi Kivity, gitster, git
In-Reply-To: <Pine.LNX.4.64.0709292243280.28395@racer.site>
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.
^ permalink raw reply
* Re: Stashing untracked files
From: Johannes Schindelin @ 2007-09-29 22:00 UTC (permalink / raw)
To: Neil Macneale; +Cc: git, Benoit SIGOURE
In-Reply-To: <46FEC799.30803@theory.org>
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
^ permalink raw reply
* Re: Stashing untracked files
From: Johannes Schindelin @ 2007-09-29 21:51 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: Neil Macneale, git
In-Reply-To: <EEE8F630-AE62-4425-96A0-239D54724DF4@lrde.epita.fr>
Hi,
On Sat, 29 Sep 2007, Benoit SIGOURE wrote:
> On Sep 29, 2007, at 11:03 PM, Johannes Schindelin wrote:
>
> > Instead this is what you _should_ do:
> >
> > git add <the files that you care about>
> > git stash
>
> 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).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] rebase -i: support single-letter abbreviations for the actions
From: Johannes Schindelin @ 2007-09-29 21:48 UTC (permalink / raw)
To: Avi Kivity; +Cc: gitster, git
In-Reply-To: <46FEC00B.7050208@qumranet.com>
Hi,
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?
Ciao,
Dscho
^ permalink raw reply
* Re: Stashing untracked files
From: Neil Macneale @ 2007-09-29 21:46 UTC (permalink / raw)
To: git; +Cc: Benoit SIGOURE
In-Reply-To: <EEE8F630-AE62-4425-96A0-239D54724DF4@lrde.epita.fr>
Benoit SIGOURE wrote:
> On Sep 29, 2007, at 11:03 PM, Johannes Schindelin wrote:
>
>> Hi,
>>
>> On Sat, 29 Sep 2007, Neil Macneale wrote:
>>
>>> When using "git stash," in some cases I'd like to stash away files that
>>> are currently untracked. It seems to me like there should be a way to
>>> stash everything in a working directory so that the end result is a
>>> pristine tree. Then applying the stash will reinstate those file as
>>> untracked.
>>
>> Funny how the same ideas always come in packs: I had the same discussions
>> a few nights ago on IRC.
>>
>> Here is why I think it is _wrong_ to stash untracked files: this would
>> include *.o and *.a, as well as all those binary files, too.
>>
>> Instead this is what you _should_ do:
>>
>> git add <the files that you care about>
>> git stash
>
> You could stash untracked files that are not ignored (I personally
> ignore *.o, *.a and the like).
>
Yeah, I wouldn't want the ignored files. I'm interested in the files
listed as untracked when I run git status.
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.
In the case I'm dealing with right now, I working on content files
(html/perl). It's not uncommon for me to have files which are untracked
and will remain that way for an extended period of time (a few commits,
say). When I need to do a stash, I generally don't want those files
around afterward.
( Here is the full story. I'm using git to make my life working with
perforce a little less painful. It's not uncommon for me to jump to my
master branch to do a perforce sync. When I do that, I want all of my
changes in working branches stashed away. I selectively add new files on
each commit so that what is committed to the working branch syncs up
with what I end up submitting to perforce. And to make my life even more
difficult, my co-workers are not using git. So it's not uncommon for
someone to send me a file for my sandbox which I will never submit to
perforce because it's their job to do so. I can't tell you how many
times I've told them "this would be a lot easier if we all just used
git" but I digress... )
Thanks,
Neil
^ permalink raw reply
* Re: A tour of git: the basics (and notes on some unfriendly messages)
From: Steffen Prohaska @ 2007-09-29 21:48 UTC (permalink / raw)
To: Git Mailing List; +Cc: Carl Worth, Shawn O. Pearce
In-Reply-To: <20070929000056.GZ3099@spearce.org>
On Sep 29, 2007, at 2:00 AM, Shawn O. Pearce wrote:
>> * There's a ton of extraneous output from git-fetch. I would
>> love to
>> see it reduced to a single-line progress bar, (even if a
>> multiple-staged progress bar). I'm imagining a final line
>> something like:
>>
>> Computing (100%) Transferring (100%)
>>
>> But you can imagine more accurate words than those, (I'm not even
>> sure what all of the things mean that git-fetch is currently
>> reporting progress on).
>
> Yea. About half of that output is from pack-objects and either
> unpack-objects or index-pack. The other part is from git-fetch
> itself as it updates the local tracking branches (if any are to be
> updated). Now that git-fetch is in C and reasonably stable maybe
> I can look into making this prettier. Few people really grok the
> pack-objects/index-pack output, nor do they care. They just want
> to know two things:
>
> - Is git working or frozen in limbo?
> - Is git frozen because my network sucks, or git sucks?
> - When will this be done? Please $DIETY, I want to go home!
> Make the fetch finish!
>
> The C based git-fetch made the http protocol almost totally silent.
> (No more got/walk messages.) But that's actually also bad as it
> now doesn't even let you know its transferring anything at all.
>
> There are serious issues here about getting the user the progress
> they really want. The last item ("When will this be done?") is
> actually not possible to determine under either the native git
> protocol or HTTP/FTP. We have no idea up front how much data must
> be transferred. In the native git case we do know how many objects,
> but we don't know how many bytes that will be. It could be under
> a kilobyte in one project. That same object count for a different
> set of objects fetch could be 500M. Radically different transfer
> times would be required.
Often you know that you have a good connection and you are not
interested in any progress reporting at all. _No_ output would be
perfect. A return code of 0 would already tell you all you need
to know. If you'd like to know more you could pass something like
'--verbose' or '--progress'.
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)
- git rebase: prints a lot of details that I'm not interested in
unless the rebase fails.
- git push: prints updates of remote heads. A message about
failing to update a remote head may get lost.
- 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.
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. We could
pipe all the technical output to a per-repository logfile, which
can be consulted in case of errors. The log could be cropped
during 'git gc'.
Steffen
^ permalink raw reply
* Re: [PATCH] rebase -i: support single-letter abbreviations for the actions
From: Avi Kivity @ 2007-09-29 21:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, git
In-Reply-To: <Pine.LNX.4.64.0709292156090.28395@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Sat, 29 Sep 2007, Avi Kivity wrote:
>
>
>> Johannes Schindelin wrote:
>>
>>> When you do many rebases, you can get annoyed by having to type out
>>> the actions "edit" or "squash" in total.
>>>
>>> This commit helps that, by allowing you to enter "e" instead of
>>> "edit", or "s" instead of "squash", and it also plays nice with
>>> "merge" or "amend" as synonyms to "squash".
>>>
>> 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.
>>
>
> I do not necessarily think it is not doable, but I have different
> suggestion to you:
>
> If you amend the commit with a minor fix that comes later, why not do
> "rebase -i" _before_ applying the fix, and then using "edit" on the
> respective commit?
>
This is what I do now. Edit the commit, cherry-pick -n, and commit
--amend. But it's less pleasant than using the rebase --interactive
interface.
[This is part of the workflow to prepare a patchset for submitting
upstream; I don't edit commits on my master branch]
> That way you can even test the result easily, which you cannot do with
> "squash".
>
Usually these are trivial fixes, and have already been tested by being
included in my main branch.
--
Any sufficiently difficult bug is indistinguishable from a feature.
^ permalink raw reply
* Re: Stashing untracked files
From: Benoit SIGOURE @ 2007-09-29 21:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Neil Macneale, git
In-Reply-To: <Pine.LNX.4.64.0709292201400.28395@racer.site>
[-- Attachment #1: Type: text/plain, Size: 941 bytes --]
On Sep 29, 2007, at 11:03 PM, Johannes Schindelin wrote:
> Hi,
>
> On Sat, 29 Sep 2007, Neil Macneale wrote:
>
>> When using "git stash," in some cases I'd like to stash away files
>> that
>> are currently untracked. It seems to me like there should be a way to
>> stash everything in a working directory so that the end result is a
>> pristine tree. Then applying the stash will reinstate those file as
>> untracked.
>
> Funny how the same ideas always come in packs: I had the same
> discussions
> a few nights ago on IRC.
>
> Here is why I think it is _wrong_ to stash untracked files: this would
> include *.o and *.a, as well as all those binary files, too.
>
> Instead this is what you _should_ do:
>
> git add <the files that you care about>
> git stash
You could stash untracked files that are not ignored (I personally
ignore *.o, *.a and the like).
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: Stashing untracked files
From: Johannes Schindelin @ 2007-09-29 21:03 UTC (permalink / raw)
To: Neil Macneale; +Cc: git
In-Reply-To: <46FE9924.7080006@theory.org>
Hi,
On Sat, 29 Sep 2007, Neil Macneale wrote:
> When using "git stash," in some cases I'd like to stash away files that
> are currently untracked. It seems to me like there should be a way to
> stash everything in a working directory so that the end result is a
> pristine tree. Then applying the stash will reinstate those file as
> untracked.
Funny how the same ideas always come in packs: I had the same discussions
a few nights ago on IRC.
Here is why I think it is _wrong_ to stash untracked files: this would
include *.o and *.a, as well as all those binary files, too.
Instead this is what you _should_ do:
git add <the files that you care about>
git stash
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] rebase -i: support single-letter abbreviations for the actions
From: Johannes Schindelin @ 2007-09-29 20:58 UTC (permalink / raw)
To: Avi Kivity; +Cc: gitster, git
In-Reply-To: <46FE7D0B.4060806@qumranet.com>
Hi,
On Sat, 29 Sep 2007, Avi Kivity wrote:
> Johannes Schindelin wrote:
> > When you do many rebases, you can get annoyed by having to type out
> > the actions "edit" or "squash" in total.
> >
> > This commit helps that, by allowing you to enter "e" instead of
> > "edit", or "s" instead of "squash", and it also plays nice with
> > "merge" or "amend" as synonyms to "squash".
>
> 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.
I do not necessarily think it is not doable, but I have different
suggestion to you:
If you amend the commit with a minor fix that comes later, why not do
"rebase -i" _before_ applying the fix, and then using "edit" on the
respective commit?
That way you can even test the result easily, which you cannot do with
"squash".
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] WinGit: include html pages from official git.git's html branch
From: Johannes Schindelin @ 2007-09-29 20:50 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11910819542185-git-send-email-prohaska@zib.de>
Hi,
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.
Ciao,
Dscho
^ permalink raw reply
* Submodule idea
From: Daniel Barkalow @ 2007-09-29 19:04 UTC (permalink / raw)
To: git
I *think* that it would be a great benefit if "git submodule update" would
leave you on a branch if (a) you were on that branch before, and (b)
pulling on that branch would update it to the commit that the superproject
specifies for that submodule.
Or maybe there should be a "git submodule fetch" which fetches from the
remote, and replaces FETCH_HEAD with the superproject's index entry, and
"git submodule pull" would merge it? (With the model being that the entry
in the superproject is an additional remote that you both track and
publish to)
-Daniel
*This .sig left intentionally blank*
^ 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