[PATCH] Teach git push .git/branches shorthand
Although it is uncertain if we would keep .git/branches for long, the shorthand stored there can be used for pushing if it is host:path/to/git format, so let's make use of it. This does not use git-parse-remote because that script will be rewritten quite a bit for updated pulling. Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]> --- I hear a lot of people mention $GIT_DIR/branches/ is confusing. Maybe we should rename it to $GIT_DIR/remote/ directory? git-push-script | 63 ++- 1 files changed, 62 insertions(+), 1 deletions(-) c781a84b5204fb294c9ccc79f8b3baceeb32c061 diff --git a/git-push-script b/git-push-script --- a/git-push-script +++ b/git-push-script @@ -1,3 +1,64 @@ #!/bin/sh . git-sh-setup-script || die "Not a git archive" -git-send-pack "$@" + +# Parse out parameters and then stop at remote, so that we can +# translate it using .git/branches information +has_all= +has_force= +has_exec= +remote= + +while case "$#" in 0) break ;; esac +do + case "$1" in + --all) + has_all=--all ;; + --force) + has_force=--force ;; + --exec=*) + has_exec="$1" ;; + -*) + die "Unknown parameter $1" ;; +*) + remote="$1" + shift + set x "$@" + shift + break ;; + esac + shift +done + +case "$remote" in +*:* | /* | ../* | ./* ) + # An URL, host:/path/to/git, absolute and relative paths. + ;; +* ) + # Shorthand + if expr "$remote" : '..*/..*' >/dev/null + then + # a short-hand followed by a trailing path + shorthand=$(expr "$remote" : '\([^/]*\)') + remainder=$(expr "$remote" : '[^/]*\(/.*\)$') + else + shorthand="$remote" + remainder= + fi + remote=$(sed -e 's/#.*//' "$GIT_DIR/branches/$remote") && + expr "$remote" : '..*:' >/dev/null && + remote="$remote$remainder" || + die "Cannot parse remote $remote" + ;; +esac + +case "$remote" in +http://* | https://* | git://* | rsync://* ) + die "Cannot push to $remote" ;; +esac + +set x "$remote" "$@"; shift +test "$has_all" && set x "$has_all" "$@" && shift +test "$has_force" && set x "$has_force" "$@" && shift +test "$has_exec" && set x "$has_exec" "$@" && shift + +exec git-send-pack "$@" - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Teach format-patch, rebase and cherry a..b format
Although these commands take only begin and end, not necessarily
generic SHA1 expressions rev-parse supports, supporting a..b
notation is good for consistency. This commit adds such without
breaking backward compatibility.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
Unlike the outline I suggested in an earlier message, this adds
support for only a single parameter "a..b" format, while
retaining the original code which takes two parameters. Meant
to be fully backward compatible not to break qgit and friends.
git-cherry | 25 +
git-format-patch-script | 21 +++--
git-rebase-script | 23 +++
3 files changed, 47 insertions(+), 22 deletions(-)
c67e91fad243565423b08a55f63947bd3e36c5a3
diff --git a/git-cherry b/git-cherry
--- a/git-cherry
+++ b/git-cherry
@@ -3,6 +3,8 @@
# Copyright (c) 2005 Junio C Hamano.
#
+. git-sh-setup-script || die "Not a git archive."
+
usage="usage: $0 "' []
__*__*__*__*__>
@@ -18,8 +20,8 @@ upstream, it is shown on the standard ou
The output is intended to be used as:
OLD_HEAD=$(git-rev-parse HEAD)
-git-rev-parse linus >${GIT_DIR-.}/HEAD
-git-cherry linus OLD_HEAD |
+git-rev-parse upstream >${GIT_DIR-.}/HEAD
+git-cherry upstream $OLD_HEAD |
while read commit
do
GIT_EXTERNAL_DIFF=git-apply-patch-script git-diff-tree -p "$commit" &&
@@ -27,20 +29,27 @@ The output is intended to be used as:
done
'
+case "$#,$1" in
+1,*..*)
+upstream=$(expr "$1" : '\(.*\)\.\.') ours=$(expr "$1" : '.*\.\.\(.*\)$')
+set x "$upstream" "$ours"
+shift ;;
+esac
+
case "$#" in
-1) linus=`git-rev-parse --verify "$1"` &&
- junio=`git-rev-parse --verify HEAD` || exit
+1) upstream=`git-rev-parse --verify "$1"` &&
+ ours=`git-rev-parse --verify HEAD` || exit
;;
-2) linus=`git-rev-parse --verify "$1"` &&
- junio=`git-rev-parse --verify "$2"` || exit
+2) upstream=`git-rev-parse --verify "$1"` &&
+ ours=`git-rev-parse --verify "$2"` || exit
;;
*) echo >&2 "$usage"; exit 1 ;;
esac
# Note that these list commits in reverse order;
# not that the order in inup matters...
-inup=`git-rev-list ^$junio $linus` &&
-ours=`git-rev-list $junio ^$linus` || exit
+inup=`git-rev-list ^$ours $upstream` &&
+ours=`git-rev-list $ours ^$upstream` || exit
tmp=.cherry-tmp$$
patch=$tmp-patch
diff --git a/git-format-patch-script b/git-format-patch-script
--- a/git-format-patch-script
+++ b/git-format-patch-script
@@ -3,6 +3,8 @@
# Copyright (c) 2005 Junio C Hamano
#
+. git-sh-setup-script || die "Not a git archive."
+
usage () {
echo >&2 "usage: $0"' [-n] [-o dir] [--mbox] [--check] [-...] upstream [ our-head ]
@@ -60,13 +62,20 @@ do
shift
done
+revpair=
case "$#" in
-2)linus="$1" junio="$2" ;;
-1)linus="$1" junio=HEAD ;;
-*)usage ;;
+2)
+revpair="$1..$2" ;;
+1)
+case "$1" in
+*..*)
+ revpair="$1";;
+*)
+ revpair="$1..HEAD";;
+esac ;;
+*)
+usage ;;
esac
-junio=`git-rev-parse --verify "$junio"`
-linus=`git-rev-parse --verify "$linus"`
me=`git-var GIT_AUTHOR_IDENT | sed -e 's/>.*/>/'`
@@ -108,7 +117,7 @@ _x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0
_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
stripCommitHead='/^'"$_x40"' (from '"$_x40"')$/d'
-git-rev-list --merge-order "$junio" "^$linus" >$series
+git-rev-list --merge-order $(git-rev-parse --revs-only "$revpair") >$series
total=`wc -l <$series | tr -dc "[0-9]"`
i=$total
while read commit
diff --git a/git-rebase-script b/git-rebase-script
--- a/git-rebase-script
+++ b/git-rebase-script
@@ -3,25 +3,32 @@
# Copyright (c) 2005 Junio C Hamano.
#
+. git-sh-setup-script || die "Not a git archive."
+
usage="usage: $0 "' []
Uses output from git-cherry to rebase local commits to the new head of
upstream tree.'
-: ${GIT_DIR=.git}
+case "$#,$1" in
+1,*..*)
+upstream=$(expr "$1" : '\(.*\)\.\.') ours=$(expr "$1" : '.*\.\.\(.*\)$')
+set x "$upstream" "$ours"
+shift ;;
+esac
case "$#" in
-1) linus=`git-rev-parse --verify "$1"` &&
- junio=`git-rev-parse --verify HEAD` || exit
+1) upstream=`git-rev-parse --verify "$1"` &&
+ ours=`git-rev-parse --verify HEAD` || exit
;;
-2) linus=`git-rev-parse --verify "$1"` &&
- junio=`git-rev-parse --verify "$2"` || exit
+2) upstream=`git-rev-parse --verify "$1"` &&
+ ours=`git-rev-parse --verify "$2"` || exit
;;
*) echo >&2 "$usage"; exit 1 ;;
esac
-git-read-tree -m -u $junio $linus &&
-echo "$linus" >"$GIT_DIR/HEAD" || exit
+git-read-tree -m -u $ours $upstream &&
+echo "$upstream" >"$GIT_DIR/HEAD" || exit
tmp=.rebase-tmp$$
fail=$tmp-fail
@@ -29,7 +36,7 @@ trap "rm -rf $tmp-*" 0 1 2 3 15
>$fail
-git-cherry $linus $junio |
+git-cherry $upstream $ours |
while read sign commit
do
case "$sign" in
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
[PATCH] Stash away the original head in ORIG_HEAD when resetting.
When rewinding the head, stash away the value of the original
HEAD in ORIG_HEAD, just like git-resolve-script does.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
Since rewinding the head is a dangerous operation, saving it
somewhere just in case would make life a bit safer. This also
lets you do:
$ git commit
... "oops, I forgot to include that fix."
$ git reset HEAD^1
... edit away and update-cache
$ git commit -m ORIG_HEAD
to reuse the old commit message.
git-reset-script |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
87aced8864d926cf870ddfb2ca7ac5784fccb911
diff --git a/git-reset-script b/git-reset-script
--- a/git-reset-script
+++ b/git-reset-script
@@ -2,6 +2,12 @@
. git-sh-setup-script || die "Not a git archive"
rev=$(git-rev-parse --revs-only --verify --default HEAD "$@") || exit
rev=$(git-rev-parse --revs-only --verify $rev^0) || exit
-git-read-tree --reset "$rev" && echo "$rev" > "$GIT_DIR/HEAD"
+git-read-tree --reset "$rev" && {
+ if orig=$(git-rev-parse --verify HEAD 2>/dev/null)
+ then
+ echo "$orig" >"$GIT_DIR/ORIG_HEAD"
+ fi
+ echo "$rev" > "$GIT_DIR/HEAD"
+}
git-update-cache --refresh
rm -f "$GIT_DIR/MERGE_HEAD"
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GIT 0.99.4 (preview)
My proposed patch, the description as is is misleading.
The rest of the .spec file looks sane (yes, I've built my share of RPMs
over the years).
diff --git a/git-core.spec.in b/git-core.spec.in
--- a/git-core.spec.in
+++ b/git-core.spec.in
@@ -2,7 +2,7 @@
Name: git-core
Version: @@VERSION@@
Release: 1
-Vendor:Linus Torvalds <[EMAIL PROTECTED]>
+Vendor:Junio C Hamano <[EMAIL PROTECTED]>
Summary: Git core and tools
License: GPL
Group: Development/Tools
@@ -13,22 +13,23 @@ BuildRoot: %{_tmppath}/%{name}-%{version
Prereq:sh-utils, diffutils, rsync, rcs, mktemp >= 1.5
%description
-GIT comes in two layers. The bottom layer is merely an extremely fast
-and flexible filesystem-based database designed to store directory trees
-with regard to their history. The top layer is a SCM-like tool which
-enables human beings to work with the database in a manner to a degree
-similar to other SCM tools (like CVS, BitKeeper or Monotone).
+This is a stupid (but extremely fast) directory content manager. It
+doesn't do a whole lot, but what it _does_ do is track directory
+contents efficiently. It is intended to be the base of an efficient,
+distributed source code management system. This package includes
+rudimentary tools that can be used as a SCM, but you should look
+elsewhere for tools for ordinary humans layered on top of this.
%prep
%setup -q
%build
-
make prefix=%{_prefix} all %{!?_without_docs: doc}
%install
rm -rf $RPM_BUILD_ROOT
-make dest=$RPM_BUILD_ROOT prefix=%{_prefix} mandir=%{_mandir} install
install-tools %{!?_without_docs: install-doc}
+make dest=$RPM_BUILD_ROOT prefix=%{_prefix} mandir=%{_mandir} \
+ install install-tools %{!?_without_docs: install-doc}
%clean
rm -rf $RPM_BUILD_ROOT
@@ -43,7 +44,13 @@ rm -rf $RPM_BUILD_ROOT
%{!?_without_docs: %{_mandir}/man7/*.7.gz}
%changelog
+* Sun Aug 07 2005 Horst H. von Brand <[EMAIL PROTECTED]>
+- Redid the description
+- Cut overlong make line, loosened changelog a bit
+- I think Junio (or perhaps OSDL?) should be vendor...
+
* Thu Jul 14 2005 Eric Biederman <[EMAIL PROTECTED]>
- Add the man pages, and the --without docs build option
+
* Wed Jul 7 2005 Chris Wright <[EMAIL PROTECTED]>
- initial git spec file
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, ChileFax: +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gitk "parent information" in commit window
Linus Torvalds wrote: This adds a useful "Parent:" line to the git commit information window. It looks something like this (from the infamous octopus merge): Author: Junio C Hamano <[EMAIL PROTECTED]> 2005-05-05 16:16:54 Committer: Junio C Hamano <[EMAIL PROTECTED]> 2005-05-05 16:16:54 Parent: fc54a9c30ccad3fde5890d2c0ca2e2acc0848fbc (Update git-apply-patch-script ...) Parent: 9e30dd7c0ecc9f10372f31539d0122db97418353 (Make git-prune-script executa ...) Parent: c4b83e618f1df7d8ecc9392fa40e5bebccbe6b5a (Do not write out new index if ...) Parent: 660265909fc178581ef327076716dfd3550e6e7b (diff-cache shows differences ...) Parent: b28858bf65d4fd6d8bb070865518ec43817fe7f3 (Update diff engine for symlin ...) Octopus merge of the following five patches. Update git-apply-patch-script for symbolic links. Make git-prune-script executable again. Do not write out new index if nothing has changed. diff-cache shows differences for unmerged paths without --cache. Update diff engine for symlinks stored in the cache. Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]> where all the parent commit ID's are clickable, because the new lines are added as part of the "comment" string, and thus the regular clickability thing will match them automatically. This new functionality is great except when it truncates the commit description needlessly. When running gitk full-screen on a large display, I have a commit information window that is much wider than needed for the truncated parent information. Leaving me with a lot of whitespace that should be used for the commit descriptions. On a related nit: some of the diffs I'm viewing have lines longer than the width of the commit information window and it's annoying that gitk wraps the line rather than providing horizontal scrolling. How about implementing horizontal scrolling in the commit information window when the commit text or the diffs are wider than the window and not truncating the commit descriptions? - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gitk "parent information" in commit window
Paul Mackerras <[EMAIL PROTECTED]> writes: > Linus Torvalds writes: > >> This adds a useful "Parent:" line to the git commit information window. > > Cool! Applied and pushed out. Thanks. Merged and pushed out. > I have been thinking about adding dialog windows to allow the user to > select which repository and which range of commits they want to look at. > Do you think that would be useful for you? "Which repository to look at" would be like restarting if you need to lose history information, in which case it would not be so useful at least for me (an extra command line option to limit the range with specifying GIT_DIR environment variable would work equally well). If you can do that without losing history when the new repository to look at is the same as the old one, or similar to the old one, then that would be useful. After starting up, without losing history information, if I can tell it to re-read the refs, because I made some changes to the repository while gitk was not looking, that would be very useful. But I hope your "switching repository" logic would do exactly that when I tell it to switch to the same repository. If there was an option, either runtime configurable or command line, to cause gitk slurp not just refs/heads and refs/tags but everything under refs/* recursively, that would help visualizing the bisect status. bisect creates bunch of commit object names in refs/bisect. If you can pop-up a transient window that shows the tag object comments when I hover over a tag icon for 2 seconds, and remove that transient window when stepping outside, that would be a useful addition. I do not currently see any way to inspect the tag itself, not the commit that is pointed at by the tag. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gitk "parent information" in commit window
Paul Mackerras wrote: ... I have been thinking about adding dialog windows to allow the user to select which repository and which range of commits they want to look at. Do you think that would be useful for you? Yes! - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gitk "parent information" in commit window
Linus Torvalds writes: > This adds a useful "Parent:" line to the git commit information window. Cool! Applied and pushed out. I have been thinking about adding dialog windows to allow the user to select which repository and which range of commits they want to look at. Do you think that would be useful for you? Regards, Paul. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
backward compatible changes to format-patch, rebase, cherry and fetch
Marco Costalba <[EMAIL PROTECTED]> writes: > A suggestion I would like to present is if can be useful a > kind of scheduling/list of planned compatibility break features so > that developers can know in advance when and what will break > their stuff and users can know when they will need to upgrade. Yes, that is a valid concern. Fortunately this is the only backward incompatible thing I currently see on the horizon. Here are the list of things I am currently thinking about updating. - The format-patch, rebase and cherry parameters you already know about. I do not think the "ugly" two parameter compromise is too much baggage to keep around, so my original plan was not to break the backward compatibility. - Fetch and pull. Currently git fetch (and git pull) takes the following forms: $ git fetch $ git fetch $ git fetch tag I am planning to update it to take: $ git fetch ... but in a backward compatible way. can take the following forms: - A of form ":" is to fetch the objects needed for the remote ref that matches , and if is not empty, store it to the local that matches . The same rule as "git push" applies for . can be either a ref pattern or the SHA1 object name. If is not an SHA1 object name, and it does not match exactly one remote ref, it is an error. - "tag" followed by is just an old way of saying "refs/tags/:refs/tags/"; this mimics the current behaviour of the third form above and means "fetch that tag and store it under the same name". - A single token without colon is a shorthand for ":" That is, "fetch that ref but do not store anywhere". - when there is no specified - if is the name of a file under $GIT_DIR/branches/ (i.e. a shorthand without trailing path), then it is the same as giving a single ":refs/heads/" on the command line, where is the remote branch name (defaults to HEAD, but can be overridden by .git/branches/ file having the URL fragment notation). That is, "fetch that branch head and store it in refs/heads/". - otherwise, it is the same as giving a single that is "HEAD:". The SHA1 object names of fetched refs are stored in FETCH_HEAD [*1*], one name per line. There will be an empty line for the ref that was not available on the remote end. I have pull enhancements that takes more than one remote refs in mind, but that will not be in the immediate future. What will happen when the above fetch enhancement happens is that pull will accept the same set of parameters as the updated fetch does, runs the fetch, but refuses to run resolve when more than one remote ref is involved. When resolve is updated to do an octopus (or a king ghidorah), this restriction can be lifted without breaking backward compatibility. [Footnote] *1* git-fetch-pack most likely will just output SHA1 to its standard output like Linus suggested earlier. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gitk "parent information" in commit window
Linus Torvalds <[EMAIL PROTECTED]> writes: > [ Btw, the patch was generated against a tree that had Paul's hovering > patches merged. Junio, I don't think you've merged that yet, so this may > apply better to Paul's tree than to standard git. But I _think_ it will > apply cleanly to either one ] Thanks. Since Paul seems to be quite responsive, I'd prefer to keep pulling from his tree. I just pulled the hovering patches from his tree and was about to push things out. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
gitk "parent information" in commit window
This adds a useful "Parent:" line to the git commit information window.
It looks something like this (from the infamous octopus merge):
Author: Junio C Hamano <[EMAIL PROTECTED]> 2005-05-05 16:16:54
Committer: Junio C Hamano <[EMAIL PROTECTED]> 2005-05-05 16:16:54
Parent: fc54a9c30ccad3fde5890d2c0ca2e2acc0848fbc (Update
git-apply-patch-script ...)
Parent: 9e30dd7c0ecc9f10372f31539d0122db97418353 (Make
git-prune-script executa ...)
Parent: c4b83e618f1df7d8ecc9392fa40e5bebccbe6b5a (Do not write out new
index if ...)
Parent: 660265909fc178581ef327076716dfd3550e6e7b (diff-cache shows
differences ...)
Parent: b28858bf65d4fd6d8bb070865518ec43817fe7f3 (Update diff engine
for symlin ...)
Octopus merge of the following five patches.
Update git-apply-patch-script for symbolic links.
Make git-prune-script executable again.
Do not write out new index if nothing has changed.
diff-cache shows differences for unmerged paths without --cache.
Update diff engine for symlinks stored in the cache.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
where all the parent commit ID's are clickable, because the new lines are
added as part of the "comment" string, and thus the regular clickability
thing will match them automatically.
I think this is good. And my random-tcl-monkey-skills are clearly getting
better (although it's perfectly possible that somebody who actually knows
what he is doing would have done things differently).
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
---
[ Btw, the patch was generated against a tree that had Paul's hovering
patches merged. Junio, I don't think you've merged that yet, so this may
apply better to Paul's tree than to standard git. But I _think_ it will
apply cleanly to either one ]
diff --git a/gitk b/gitk
--- a/gitk
+++ b/gitk
@@ -1799,9 +1799,21 @@ proc selectline {l isnew} {
}
$ctext insert end "\n"
}
-$ctext insert end "\n"
+
set commentstart [$ctext index "end - 1c"]
-set comment [lindex $info 5]
+set comment {}
+foreach p $parents($id) {
+ set l "..."
+ if {[info exists commitinfo($p)]} {
+ set l [lindex $commitinfo($p) 0]
+ if {[string length $l] > 32} {
+ set l "[string range $l 0 28] ..."
+ }
+ }
+ append comment "Parent: $p ($l)\n"
+}
+append comment "\n"
+append comment [lindex $info 5]
$ctext insert end $comment
$ctext insert end "\n"
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-format-patch-script bug?
Junio C Hamano wrote: > >I am reluctant to actually do this right away, because this is >an incompatible change from the current format: > >$ git format-patch his mine > Of course this breaks qgit interface to git-format-patch-script but if you think it's better this way >The same goes for rebase (and therefore cherry). I could use an >ugly heuristics for backward compatibility like "if invoked with >exactly two parameters, and there is no prefix ^ nor .. in these >two, then use the old interpretation, otherwise give them to >rev-parse", but I think this is ugly. > >So my question to the list is: do people mind this change? > I think it's ugly too, in this early phase of git development better go with proper solution then compatibility compromises. A suggestion I would like to present is if can be useful a kind of scheduling/list of planned compatibility break features so that developers can know in advance when and what will break their stuff and users can know when they will need to upgrade. Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: use of temporary refs in resolve
On Sun, 7 Aug 2005, Junio C Hamano wrote: > > How about LAST_MERGE? I don't think it matters. I kind of saw it as the "other side" of ORIG_HEAD, but since we now clean it up and since I've never used it, I think it falls under the status of "well-intentioned but useless". Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: use of temporary refs in resolve
Linus Torvalds <[EMAIL PROTECTED]> writes: > In fact, ORIG_HEAD is _the_ most common head I use explicitly. A. You are right. How about LAST_MERGE? - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: use of temporary refs in resolve
On Sun, 7 Aug 2005, Junio C Hamano wrote: > > Also ORIG_HEAD is probably redundant. After a successful > automerge, the same information can be had by HEAD^1 Absolutely not. You forgot about one of the most common merge cases: fast-forward. In fact, ORIG_HEAD is _the_ most common head I use explicitly. Almost all operations take HEAD as default, but doing a gitk ORIG_HEAD.. is extremely useful after a pull. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-format-patch-script bug?
[EMAIL PROTECTED] (Eric W. Biederman) writes: > What format-patch does is currently is fine. If format-patch would > simply notice the case and fail gracefully that would be sufficient to > avoid giving false impressions. Hmph. Since it uses merge-order, We should be able to change it use the tagged output format of rev-list to detect the revision list discontinuity and skip generating diff for such. Or as you suggest just run "diff-tree with the first parent". I've been wanting to update format-patch to take the commit begin-end pair in the rev-parse format, that is: $ git format-patch his..mine I am reluctant to actually do this right away, because this is an incompatible change from the current format: $ git format-patch his mine The same goes for rebase (and therefore cherry). I could use an ugly heuristics for backward compatibility like "if invoked with exactly two parameters, and there is no prefix ^ nor .. in these two, then use the old interpretation, otherwise give them to rev-parse", but I think this is ugly. So my question to the list is: do people mind this change? - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-format-patch-script bug?
Junio C Hamano <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Eric W. Biederman) writes: > >> I was trying to help someone track down a bug that >> occurred between linux-2.6.12 and linux-2.6.13-rc1. >> Since it was very much an unknown where the problem >> was introduced I decided to run git format-patch >> so I could see what all of the differences were. >> Then to be certain the patch series worked I started >> applying them in order. > > Sorry, I offhand do not have a good re-design of what > format-patch should do for this purpose; the current design does > not try to deal with anything but a linear sequence of commits, > primarily because the command was done for preparing individual > developer's patch submission. What format-patch does is currently is fine. If format-patch would simply notice the case and fail gracefully that would be sufficient to avoid giving false impressions. Depending on the quality of the list from git-rev-list --merge-order I should even be able to achieve what I was attempting, by running git-diff-tree with an ordered list of revisions and two parents on the tree. Essentially I was attempting an export to quilt operation, which implies a linearization of the changes. As I recall a linearization of the changes is what BK export to CVS was built on. So that case may be worth returning to as there are a lot of interesting cases out there for it. The other interest tid bit about my experiment was that git-format-patch-script on 2000 diffs was sluggish, certainly slower that the time to perform the write operations. Why it was slow I don't know but it may be worth looking into. > I find your trying to find where the problem was introduced by > reading every single change very laudable. However, for the > purpose of "this one was good but somewhere before this one the > things got broken, where is it?", I suspect that bisect would be > a better fit. If you can teach the user how to use bisect, and git. If we could get gitweb to perform the bisect it would be helpful, or possibly when git settles down and everyone can be counted on to have git on their machine already, bisect would be a help. Had I been thinking a little more clearly I would have suggested walking through the daily git snapshots as those are at least fairly big steps. For the moment I think the unexpected behavior I found in git is more interesting then the problem I was actually trying to solve. Eric - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-format-patch-script bug?
[EMAIL PROTECTED] (Eric W. Biederman) writes: > I was trying to help someone track down a bug that > occurred between linux-2.6.12 and linux-2.6.13-rc1. > Since it was very much an unknown where the problem > was introduced I decided to run git format-patch > so I could see what all of the differences were. > Then to be certain the patch series worked I started > applying them in order. Sorry, I offhand do not have a good re-design of what format-patch should do for this purpose; the current design does not try to deal with anything but a linear sequence of commits, primarily because the command was done for preparing individual developer's patch submission. I find your trying to find where the problem was introduced by reading every single change very laudable. However, for the purpose of "this one was good but somewhere before this one the things got broken, where is it?", I suspect that bisect would be a better fit. The way to use bisect is very simple. First you make sure you do not have unrecorded changes in your working tree, because bisect procedure would check out sequences of commits for you to test there. Then, you give it two "known to be good" and "known to be bad" commits. The order you give them does not matter, but "good" one _must_ be ancestor of "bad" one (the code currently does not check this): $ git bisect start $ git bisect good v2.6.12 $ git bisect bad v2.6.13-rc1 Bisecting: 1035 revisions left to test after this As soon as ou give these two pair, bisect starts thinking, and checks out one revision that is roughly in the halfway between these two good and bad commits. You can, if you feel like, see which one is the first one it wants you to test, like this: $ git log --max-count=1 --pretty=short bisect commit 15d20bfd606c4b4454aeaa05fc86f77994e48c92 Author: Domen Puncer <[EMAIL PROTECTED]> [PATCH] ptrace_h8300: condition bugfix At this point, your working tree has this commit checked out. Compile and test to see if this one is good or bad. If it is good, then you say "good": $ git bisect good Bisecting: 517 revisions left to test after this Bisect eliminated about half commits from the original 1000+ suspects to be innocent, and checked out which one it wants you to check next. Compile and test to see if this one is good or bad. If it turns out to be bad, then you say "bad": $ git bisect bad Bisecting: 266 revisions left to test after this You go on eliminating about half every time you run one test, and eventually it would find one commit that you may want to examine more deeply by code inspection. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bisect gives strange answer
Sanjoy Mahajan <[EMAIL PROTECTED]> writes: > I will redo those tests but rebuilding in place after each bisection > (with -f added to all the git checkout uses in git-bisect-script) and > see whether I get the same results. If I don't, it could be due to > git or git-bisect (but not so likely with the -f switch) or to the > build system. Will keep you and Junio posted. I thought the lack of '-f' was a plausible explanation, but here is what I just did. The same bisect sequence in your example, making sure the state of working tree matches what the commit being tested: $ git bisect start $ git bisect good 17af691cd19765b782d891fc50c1568d0f1276b3 $ git bisect bad c101f3136cc98a003d0d16be6fab7d0d950581a6 Bisecting: 42 revisions left to test after this $ cat .git/HEAD b2f571026594884e7a2a3f8bc6ad5c92e0703330 $ git bisect good; cat .git/HEAD; git-diff-cache -r bisect Bisecting: 30 revisions left to test after this 450008b5a62bb09445ae05c4d01d510386c9435d $ git bisect good; cat .git/HEAD; git-diff-cache -r bisect Bisecting: 15 revisions left to test after this a9df3597fec5472d0840fbfdc2a3fac5268f7d08 $ git bisect bad; cat .git/HEAD; git-diff-cache -r bisect Bisecting: 8 revisions left to test after this 28e8c3ad9464de54a632f00ab3df88fa5f4652d1 $ git bisect bad; cat .git/HEAD; git-diff-cache -r bisect Bisecting: 4 revisions left to test after this c774e93e2152d0be2612739418689e6e6400f4eb $ git bisect bad; cat .git/HEAD; git-diff-cache -r bisect Bisecting: 2 revisions left to test after this b4634484815e1879512a23e4f59eef648135c30a So it does not appear to me that lack of '-f' is a problem. Without the flag, checkout does "read-tree -m -u" which means to update the working tree to match the new tree being read (this includes the removal of files from the working tree that were registered in the original index file that are not in the next tree). - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
qgit-0.82 (was Re: qgit-0.81)
Marco Costalba wrote: >Linus Torvalds wrote: > > >>- Any chance of having a git archive of qgit? I realize that sourceforge >> doesn't have git archives, but (a) maybe you can ask and (b) maybe >> there are alternate places you could put it. It's just sad having to >> download tar-balls. >> > >I will try to proceed from (a) to, eventually, (b). > > Apart from using a public git archive, (I already use my private one ;-)) the other points should be fixed now by a fresh qgit-0.82 Download link (still tarball for now) is: http://prdownloads.sourceforge.net/qgit/qgit-0.82.tar.bz2?download Changelog: - replaced jump-over-bumps with horizontal lines - set graph bullets a bit smaller - no more word wrapping in diff and file viewers - fixed display of e-mail addresses in commit messages Marco __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qgit-0.81
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Linus Torvalds wrote: > Oh, and do people really care _that_ much when the change happened? That's > a lot of screen real estate wasted on the date stamp of "last change". At > least I can drag it to the right and hide it that way.. I fixed that here by manually dragging the "date" column to the left. That had the bonus effect of moving the graph away from the edge of the window, so it was easier to see the left-most line. You can also just resize the column if it bugs you. (Though I think swapping the default order of the two columns is probably worthwhile anyway.) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC9h3rfhVDhkBuUKURAjUHAKDoT4YVE+RDMHJouSjoMUwE67feJQCg03yZ FWWb37PawiNBKkkgb0Ap9no= =qTOy -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gitk "hyperlinks"
Junio C Hamano writes: > I did, and will push it out shortly, but I think you need this > patch. To make later merges from you easier, I will not put > this in my "master" branch. I have committed this plus the hand cursor for the links plus a small change to make gitk display commit messages correctly according to the current locale. Paul. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gitk SHA link hovers
Linus Torvalds writes: > This makes the cursor change when you hover over a SHA1 link with the new > "hypertext" gitk commit ID linking feature. I committed something based on this but with extra stuff to make the cursor changes work with the change from the normal cursor to the watch cursor and back. Paul. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qgit-0.81
Linus Torvalds wrote: >Ok, this is nicer than gitk, with the parents showing up in the commit >message and thus easy to go to. You might add children too: it's not >something git itself knows about intrisically, but since you've already >built the graph, at least you see what children are part of that graph.. > I don't know if this is what you mean, but if you right click on a free lane (i.e. not a bullet but a vertical line) on the graph you should see a pop-up with selectable childs and parent. > - Any chance of having a git archive of qgit? I realize that sourceforge > doesn't have git archives, but (a) maybe you can ask and (b) maybe > there are alternate places you could put it. It's just sad having to > download tar-balls. > I will try to proceed from (a) to, eventually, (b). > - The qgit graph is not as pretty as the gitk one. Any chance of making > the bullets a bit smaller, and having an option to not do the > "jump-over-bumps"? > Ok, I will try to use straight horizontal lines instead of jump-over-bumps. If this seems not enough clear I will add an option to switch visualization. > - the "file annotation" window is nice, but it _really_ shouldn't do line > wrapping. If you make the window narrower, you'll see it wrap and look > horrible.. Are all text windows always wrapped in QT? > No, just a setting. Not a problem to set "No wrap" behaviour. I will set this also in diff viewer window. > - You edit the commit comments heavily, and have no options to unedit. > For example, I need the emails in the sign-offs if I ever cut-and-paste > to an email client when I sent a "hey, this commit broke so-and-so.." > You discover a real bug ;-). I never intended to modify commit comments in any way. > - the "format a patch to be sent as email" thing says "at least two > revisions needed" when you only have one. Why? One of my more common > cases is that I send one commit as a patch, and now I do > > git-diff-tree -p --pretty [commit-id] > ~/diff > > and then just send that. A single commit _does_ describe a valid patch, > after all. > The logic here is to specify a range. As example if you have following commits A B C D E F and you select B and E then 3 patches will be created: patch_1(diff between D-E) patch_2(diff between C-D) patch_3(diff between B-C) So you need at least 2 selected revs. Put in other words, the base is always explicit. Marco __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
git-format-patch-script bug?
I haven't had a chance to investigate this much yet but I have ran into a peculiar problem. I was trying to help someone track down a bug that occurred between linux-2.6.12 and linux-2.6.13-rc1. Since it was very much an unknown where the problem was introduced I decided to run git format-patch so I could see what all of the differences were. Then to be certain the patch series worked I started applying them in order. I didn't get very far when I had a patch conflict. Looking deeper git-diff-tree is always making the diffs against the parent instead of against the next commit in the series. Which is largely sane. However it does not warn or fail when the parents and the next commit are different, which seems nonintuitive. Eric - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
