GIT 0.99.4 (preview)
I said: My tentative plan is for 0.99.4 to finish send-pack, 0.99.5 to enhance fetch-pack, 0.99.6 to finish the first pass for the documentation updates and stabilizing the binary packaging. Ok, I am almost ready to push 0.99.4 out. Here is what I have in the public repository. - The branches master pu are as usual. Modulo bugs, I consider send-pack enhancement finished. - There is an rc branch whose Makefile already says 0.99.4. I've been working on Debian and RPM packaging issues today, with help from Chris Wright and H Peter Anvin, in this branch. The plan is to stabilize the binary packaging issues in the rc branch, and ordinary feature updates and bugfixes in master or pu branch as usual. When things are ready, rc and master will be merged, 0.99.4 gets created and tagged, and master and pu will continue from there. I would appreciate if folks familiar with binary packaging, especially RPM, give final sanity checks on what is currently in rc branch. - 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
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
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: 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
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: 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: 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: 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: 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: 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: 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
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 remote $ git fetch remote head $ git fetch remote tag tag I am planning to update it to take: $ git fetch remote refspec... but in a backward compatible way. refspec can take the following forms: - A refspec of form src:dst is to fetch the objects needed for the remote ref that matches src, and if dst is not empty, store it to the local that matches dst. The same rule as git push applies for dst. src can be either a ref pattern or the SHA1 object name. If src is not an SHA1 object name, and it does not match exactly one remote ref, it is an error. - tag followed by next is just an old way of saying refs/tags/next:refs/tags/next; 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 refspec without colon is a shorthand for refspec: That is, fetch that ref but do not store anywhere. - when there is no refspec specified - if remote 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 refspec remote-name:refs/heads/remote on the command line, where remote-name is the remote branch name (defaults to HEAD, but can be overridden by .git/branches/remote file having the URL fragment notation). That is, fetch that branch head and store it in refs/heads/remote. - otherwise, it is the same as giving a single refspec 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
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
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
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: 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
