* Re: [PATCH (GITK) v3 0/4] Enhance encoding support.
From: Paul Mackerras @ 2008-10-15 12:38 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Johannes Sixt
In-Reply-To: <1223885554-27718-1-git-send-email-angavrilov@gmail.com>
Alexander Gavrilov writes:
> Since git apparently cannot work with filenames in non-locale
> encodings anyway, I did not try to do anything about it apart
> from fixing some obvious bugs.
What we did before was read filenames and convert them from the system
encoding (done implicitly by gets) before unquoting filenames that
were quoted. What we do now with your patch 1/2 is that we read the
filenames in binary and unquote any quoted filenames before converting
from the system encoding. So I don't think your patch would have made
as much difference as it might appear. If there is a reason for
unquoting before converting from the system encoding rather than
after, it seems pretty subtle to me and wasn't explained in the patch
description. An explanation, preferably with examples, would be
useful.
Also, you didn't say whether you found the "obvious bugs" by
inspection or by encountering their effects in actual running (and if
so, what those effects were). That information is also good to have
in the patch description.
Paul.
^ permalink raw reply
* Re: [PATCH (GITK) v3 0/4] Enhance encoding support.
From: Paul Mackerras @ 2008-10-15 12:32 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Johannes Sixt
In-Reply-To: <1223885554-27718-1-git-send-email-angavrilov@gmail.com>
Alexander Gavrilov writes:
> Currently GUI tools don't provide enough support for
> viewing files that contain non-ASCII characters. This set of
> patches addresses this issue. The git-gui part of the series
> is based on patches that were in the 'pu' branch of the
> git-gui repository.
Thanks. I applied 1/4 and 2/4 as one commit and 3/4 as another.
However, it seems invoking git check-attr is quite slow, or at least,
there is a large startup cost which is not really amortized by
batching up only 30 paths per call.
As a test I tried displaying the diff in the kernel tree from 2.6.27
to Linus' master as of a day or so ago (3fa8749e) which has 5277 files
different. With the 30-way batching this takes over 6 seconds to get
the file encodings (all of which are "unspecified" since I don't have
any .gitattributes files), which we need before we display the list of
changed files, which before only took 0.12 seconds -- so we're 50x
slower at showing the list of changed files as a result of adding the
per-file encoding support. Also, each call to cache_gitattr was
taking 1.2 seconds, which is too long since file handlers are supposed
to limit themselves to less than 100ms (preferably less than 50ms) of
processing on any one call, and the cache_gitattr call was making
gettreediffline take way too long.
So I have added another commit which makes the per-file encoding
support optional and default to off for now. It also increases the
amount of batching in cache_gitattr (except under windows) and reduces
the number of lines that gettreediffline does when per-file encoding
support is on. Along the way, it also converts the new code to the
gitk coding style, cleans up a few things and adds a simple cache to
tclencoding.
If git check-attr gets the --stdin-paths flag added, that will be
good, except then getblobdiffline will need to do something clever if
it needs the encoding for a file but the result hasn't come back from
git-check-attr yet. That could get quite tricky in fact...
Paul.
^ permalink raw reply
* Re: Git graph on GitHub
From: Petr Baudis @ 2008-10-15 12:20 UTC (permalink / raw)
To: Tom Werner; +Cc: git
In-Reply-To: <530345950810150047v75bfbf9clebbb8a406b172c4c@mail.gmail.com>
Hi,
On Wed, Oct 15, 2008 at 12:47:52AM -0700, Tom Werner wrote:
> We've just pushed out an update to the Network Graph on GitHub this
> evening that finally allows us to draw very large repositories
> (including Git). We're mirroring the Git repo on the site and I
> thought it might be interesting for people to see this visualization.
> Enjoy!
>
> http://github.com/git/git/network
>
> Let me know if you have any ideas for improvements on the graph. I'm
> always looking for ways to enhance it.
it's generally nice, but I think it could be much more useful yet. :-)
Generally, I find its information density very low. I see only tiny
dots connected by lines at the top of the screen (rest grey) and if I
want to know _what_ commits are actually there, I need to carefully
hover over the scattered tiny dots. So my question is, exactly what kind
of information do you seek to present primarily? Based on what I see,
the answer seems to be just "how hairy the project history is", and I'm
wondering if maybe some other class of information would be more
interesting. IOW, what about using that blank grey area to show the
commit subjects? ;-)
Right now, your repository contains only the 'master' branch. I guess
you want to setup a --mirror repository instead of pulling?
Also, it would be pretty nifty if you could tag lines of past topic
branches based on the merge commit message. E.g. mark the blue line
short in the past as pb/gitweb-tagcloud based on the 3e3d4ee merge. On
the other hand, I'm not sure how well would it work visually if the
topic branches are very short and merged right away.
--
Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.
^ permalink raw reply
* [BUG] git status doesn't handle submodules properly on OSX
From: Lars Hoss @ 2008-10-15 12:07 UTC (permalink / raw)
To: git
Greetings all,
two days ago I posted about an issue:
http://thread.gmane.org/gmane.comp.version-control.git/98171
After more testing I can confirm it is indeed a bug.
1.6.0.2 on OSX Leopard doesn't work. After adding a submodule
the folder of the submodule will always get listed under
"Untracked files" when calling git status.
1.5.6, however, works fine. I have not tested trunk yet.
So as a workaround I have to go back to 1.5.6 for now.
Yours,
Lars
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2008, #03; Tue, 14)
From: Nguyen Thai Ngoc Duy @ 2008-10-15 11:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8wsq7rt5.fsf@gitster.siamese.dyndns.org>
On 10/15/08, Junio C Hamano <gitster@pobox.com> wrote:
> [Stuck Topics]
>
> * nd/narrow (Wed Oct 1 11:04:09 2008 +0700) 9 commits
> - grep: skip files outside sparse checkout area
> - checkout_entry(): CE_NO_CHECKOUT on checked out entries.
> - Prevent diff machinery from examining worktree outside sparse
> checkout
> - ls-files: Add tests for --sparse and friends
> - update-index: add --checkout/--no-checkout to update
> CE_NO_CHECKOUT bit
> - update-index: refactor mark_valid() in preparation for new options
> - ls-files: add options to support sparse checkout
> - Introduce CE_NO_CHECKOUT bit
> - Extend index to save more flags
>
> Recently updated with a repost. Shawn says he's been too swamped at
> day-job to actively review the series. There has been some discussion on
> list about it so its not stalled, but it needs more eyeballs.
Just a bit of update. I'm still working on the second half. Code
change is even more than this, so I will wait until the first half
gets reviewed and accepted before sending the rest.
BTW, in the first half, unpack_trees()-related commands may refuse to
work if there is orphaned/stale entries in working directory
(verify_*() functions still look at working directory no matter
whether entries are no-checkout). Those entries are troublesome anyway
so encouraging people to clean them out is, IMHO, a good idea, rather
than fixing unpack_trees() to ignore them.
--
Duy
^ permalink raw reply
* Re: git-scm.com (was Re: Git graph on GitHub)
From: Wincent Colaiuta @ 2008-10-15 10:34 UTC (permalink / raw)
To: PJ Hyett; +Cc: git
In-Reply-To: <bab6a2ab0810150318pb616a6dj867efa36623ac12e@mail.gmail.com>
El 15/10/2008, a las 12:18, PJ Hyett escribió:
>> One nitpick regarding your git.git mirror: I doubt that people here
>> ("the community") consider git-scm.com to be "the git homepage". I
>> don't
>> want to go into the reasons and start a pointless thread, but since
>> git-scm.com is a fork of git.or.cz pointing to the latter (the root)
>> should make everyone happy.
>
> Hi Michael,
> I'll go ahead and start a pointless thread along with the reasons
> provided via answers to the 2008 Git Survey[1]:
Coming up in news at 6...
GitHub announces new maintainer for Git
GitHub is proud to announce the replacement of the old Git maintainer
with the "Git Core Team", comprising PJ Hyett, Scott Chacon, Tom
Preston and some select personalities from the Ruby on Rails world.
You'll be able to track all the latest updates to "Git Edge" over at
GitHub. The former maintainer, Junio C Hamano, is being retired from
service because the Git community (see git-scm.com) decided he wasn't
as good-looking as David Heinemeier Hanson. For more information, see
the official Git book (book.git-scm.com).
^ permalink raw reply
* Re: retrieving a diff from git
From: Christian Jaeger @ 2008-10-15 10:12 UTC (permalink / raw)
To: Folkert van Heusden; +Cc: Alex Riesen, git
In-Reply-To: <20081014172048.GW22427@vanheusden.com>
Folkert van Heusden wrote:
>> Well, you can of course just click on "commitdiff" (and "raw" afterwords)
>> for every commit,
>>
>
> Hmmm the outcome does not apply cleanly to 2.6.27.
>
>
>> but ... Have you considered using Git for that?
>>
>
> and check out the whole tree using Git? I did consider but then I would
> not have all bells and whistles to generate a Debian kernel package.
>
I'm tempted to think that you should move (merge / cherry-pick or
rebase) the relevant changes onto 2.6.27 using Git, and then take the
diff from there (on the theory that Git could reduce the number of
conflicts that you would have to resolve manually, although I'm not sure
how much this is the case); the resulting diff will then apply cleanly
to a 2.6.27 tarball without using Git.
Christian.
^ permalink raw reply
* git-scm.com (was Re: Git graph on GitHub)
From: PJ Hyett @ 2008-10-15 10:18 UTC (permalink / raw)
To: git
In-Reply-To: <bab6a2ab0810150315l273d4ef3k95cda8f43a4745ca@mail.gmail.com>
> One nitpick regarding your git.git mirror: I doubt that people here
> ("the community") consider git-scm.com to be "the git homepage". I don't
> want to go into the reasons and start a pointless thread, but since
> git-scm.com is a fork of git.or.cz pointing to the latter (the root)
> should make everyone happy.
Hi Michael,
I'll go ahead and start a pointless thread along with the reasons
provided via answers to the 2008 Git Survey[1]:
43) What could be improved on the Git homepage(s)?
* Use git-scm.com instead of git.or.cz as the default homepage
* Learn from git-scm.com. Make it more newbie-friendly. More focus on
documentation
* Better graphical design/organization - new(?) git-scm.com looks better
* Look at git-scm.com :)
* Cleaner design, better organization (http://git-scm.com/ is a good start).
* Design - git-scm.com is superior compared to git.or.cz. Also the
first one is more user-friendly having exposed more important things
for users rather for experienced veterans who want to download most
current git release.
* I like what Scott Chacon has done with http://git-scm.com
* I prefer Scot Chacons rewrite, but mostly just it's look and feel.
The original site is perfectly functional; though it could do with
better documentation.
* git-scm.com
* git-scm.com is a great example of some light improvement. I do think
that the online man-page navigation is a little annoying, having to
revert to find in the browser to get to the right spot on the page. An
alternate alphabetical listing might help.
* Don't put everything on the first page, it is a little confusing.
Create categories, like download, documentation, About git and at
least a dedicated page for each of these categories. I think the
"design" could also be improved. I saw a proposition not long ago
aboutr a new git homepage on the mailing list: www.git-scm.com. I
think this site is easier to navigate and thus makes it easier to find
informations.
* I like the new git-scm site (with the blob committed to storing trees)
* Merge with Git-scm page?
* I like <http://www.git-scm.com> very much. I'd vote for it to be the
official Git homepage.
* git.or.cz?? I prefer http://git-scm.com/, it's better for beginners,
and the information is nicely presented (doc, tips, videos..).
* promote git-scm.com instead of git.or.cz
* See http://git-scm.com/
* I think git-scm.com is starting to get things right. Making
documentation readily available especially.
* Complete re-design by somebody actually the least bit proficient in
design? Oh wait, that's already been done at http://git-scm.com/.
* Rather ugly design. git-scm.com looks much better.
* I like Scott Chacon's site a lot and use it often: http://git-scm.com/
* Compare #1 and #2 1) http://git-scm.com 2) http://git.or.cz
* http://git.or.cz and http://git-scm.com should be merged
* http://git-scm.com/ is a worderfull project, making the homepage
look and feel much better and "user friendly". The source code is at
http://github.com/schacon/gitscm. What about using this as the Git
official homepage (not the domain, but the interface and images).
* git-scm.com should be the official page :)
* Organization and flow particularly for new users. I think Scott
Chacon's git-scm.com site does a much better job. Organization and
navigation of the content are the things that make it a winner.
* The www.git-scm.com homepage is great.
* Which one? http://git.or.cz/ or http://git-scm.com/ I tend to use
git-scm.com just because it looks nicer, is written in Rails and has
more user friendly information. Rather than browsing what feels like
"A manual online" that is git.or.cz
* I think the homepage (http://git-scm.com/) however work should be
done to have that come ahead of http://git.or.cz/ which currently tops
all the queries. I would try to strike a deal with that domain to
http-redirect to the new url. I can only imagine that this duplication
leads to confusion and a bad experience.
* It should look more like http://git-scm.com
* http://git-scm.com/ > git.or.cz -scm has all the info I might want
up front in one page, while my eyes gloss over just looking at or.cz.
Cheers,
PJ Hyett
http://github.com/pjhyett
1. http://www.survs.com/app/4/wo/IQ2m9AwQ2qFAVwuZrRLF4w/0.0.9.3.3.0.1.3.42.1.7.1
^ permalink raw reply
* Re: [PATCH] Introduce core.keepHardLinks
From: Johannes Schindelin @ 2008-10-15 9:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v63nw9xor.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 13 Oct 2008, Junio C Hamano wrote:
> You could have said something like "The users may want to have a
> checkout, and keep the same contents always appear elsewhere i.e.
> 'installing by hardlinking'. In such a setup, editing the source with
> an editor configured not to break hardlinks would still work fine, but
> git-checkout will unconditionally break such links, which is
> undesirable. Such a setup would want a configuration variable like
> this."
Sounds very nice. Sorry for being grumpy, and not being able to come up
with such a beautiful description.
> The documentation update needs to warn about the Shawn's scenario. I also
> do not know what this should do when you have two tracked paths with
> identical contents hardlinked to each other.
When the user does that, it's the user's wish. I'd not let Git play cute
games with that.
> It also raises another question. Don't you want this to be an attribute
> for paths, not all-or-nothing configuration per repository?
I'd rather not have it as an attribute, because it is not so much about
file types that should show this behavior. It is more like an option that
I fully expect to be set in $HOME/.gitconfig.
Ciao,
Dscho
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2008, #03; Tue, 14)
From: Johannes Sixt @ 2008-10-15 8:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Petr Baudis
In-Reply-To: <7v8wsq7rt5.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> * pb/rename-rowin32 (Sun Oct 12 21:01:23 2008 -0700) 2 commits
> - (squash): index-pack: do not unconditionally make packfile read-
> only
> - Do not rename read-only files during a push
>
> Supposedly fixes pack file renames on Windows. The (squash) patch is my
> attempt to fix its breakage.
I'm afraid I can't reproduce the problem that the commit message
describes. (But then I don't know whether I understand it correctly
because it talks about "push to local repository", and I'm not sure how to
read this).
Googling around indicates that this is a Samba bug:
http://lists.samba.org/archive/samba/2005-July/108941.html
OTOH, svn has considered a workaround for a similar problem just last week:
http://www.nabble.com/-PATCH--Fix-for-renaming-errors-on-Samba-working-copies.-td19854585.html
I cannot tell what the situation with current Samba versions is. Pasky?
-- Hannes
^ permalink raw reply
* Re: Git graph on GitHub
From: Michael J Gruber @ 2008-10-15 8:24 UTC (permalink / raw)
To: Tom Werner; +Cc: git
In-Reply-To: <530345950810150047v75bfbf9clebbb8a406b172c4c@mail.gmail.com>
Tom Werner venit, vidit, dixit 15.10.2008 09:47:
> We've just pushed out an update to the Network Graph on GitHub this
> evening that finally allows us to draw very large repositories
> (including Git). We're mirroring the Git repo on the site and I
> thought it might be interesting for people to see this visualization.
> Enjoy!
>
> http://github.com/git/git/network
>
> Let me know if you have any ideas for improvements on the graph. I'm
> always looking for ways to enhance it.
Nice graph. The numbers in the grey bar are cut off around the middle,
though (FF 3 on Kubuntu Linux). Is there a way to display branch labels
other than master? Maybe the commit overlays could list all branches a
commit belongs to (like gitk does).
One nitpick regarding your git.git mirror: I doubt that people here
("the community") consider git-scm.com to be "the git homepage". I don't
want to go into the reasons and start a pointless thread, but since
git-scm.com is a fork of git.or.cz pointing to the latter (the root)
should make everyone happy.
Michael
^ permalink raw reply
* Re: [PATCH try 2] t1301-shared-repo.sh: don't let a default ACL interfere with the test
From: Johannes Sixt @ 2008-10-15 8:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matt McCutchen, git
In-Reply-To: <7v7i8a47f6.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>>> - Do you mean, by "educate users", that we teach users not to play fun
>>> games with ACL in a git controled working tree?
>> Correct. In the case of a shared repository we can educate users not to
>> play with ACLs.
>>
>>> - Do you mean, by "fix the code", that we teach adjust_shared_perm() to
>>> deal with ACL?
>> Correct in principle, but we need not go this route in the case of shared
>> repositories because we better educate users.
>
> If that is the case what difference does your suggestion of not putting it
> in test-lib.sh make? We discourage users from playing ACL games, and we
> protect ourselves from such by making sure the trash directory used for
> running tests are not contaminated with ACL. Wouldn't it make more sense
> to do so for all the tests, so that future test writers do not have to
> worry about it?
We have to decide case by case. In the case of shared directories it makes
sense to suggest "do not play ACL games". In other cases, however, this
suggestion could not work out that well, and a workaround in the code is
the better solutions. But we do not know what those other cases are, and
the test suite may be a tool to uncover them.
Perhaps I'm worrying too much because a case that warrants a change in the
code would either have to happen frequently or be backed with very strong
arguments that ACLs are required in that particular way. (And in both
cases there would still have be conflicts in the way how git handles
permissions - we wouldn't care otherwise.) But no such case has turned up
so far.
-- Hannes
^ permalink raw reply
* Re: [PATCH 1/3] Prepare for non-interactive merge-preserving rebase
From: Stephen Haberman @ 2008-10-15 8:07 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Git Mailing List
In-Reply-To: <20080924001027.GA19264@neumann>
> The following DAG is created by the commands below:
>
> -A---B master
> \
> C---M topic
> \ /
> D
>
> git init
> echo 1 >foo
> git add foo
> git commit -m 'first on master' # A
> echo 2 >>foo
> git commit -m 'second on master' foo # B
> git checkout -b topic HEAD^
> echo 1 >bar
> git add bar
> git commit -m 'first on topic' # C
> git checkout -b subtopic
> echo 1 >baz
> git add baz
> git commit -m 'first on subtopic' # D
> git checkout topic
> git merge --no-ff subtopic # M
>
> If I now execute 'git rebase -p master topic', I get the following:
>
> -A---B master
> \ \
> \ C'---M' topic
> \ /
> C----D
Following up on this old thread, I can't get M' to have the old parent
D. I always see D change to D' and then topic is fast fowarded to D'
instead of an M' showing up. (I've tried 1.6.0.2, my rebase-i-p changes,
and sp/maint.)
> But I would rather like to have the following:
>
> -A---B master
> \
> C'---M' topic
> \ /
> D'
>
> Would such a behaviour possible at all?
Yes, I think it just takes the following patch:
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -251,7 +251,7 @@ pick_one_preserving_merges () {
GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
output git merge $STRATEGY -m "$msg" \
- $new_parents
+ --no-ff $new_parents
Applying this to either sp/maint or my rebase-i-p changes gets your
desired output.
With the only caveat being that the subtopic branch stays pointing at
the old D--since you are rebasing topic, it does not change where
subtopic points when rewriting D -> D'.
Musing, I could see moving subtopic being possible, definitely with git
sequencer, but also with a --other-branches-follow-rewrites flag of some
sort that, after rewriting hash1->hash2, just finds any local branches
pointing at hash1 and updates their refs to be hash2. Not that I'm
really suggesting it, but I don't think it would be that hard.
Anyway, subtopic still pointing at D aside, I think your desired output
makes sense, given you've explicitly told rebase to preserve merges. If
you wanted a non-ff M in the first place, I think passing along a
--no-ff to keep M' around is reasonable. And would otherwise be harmless.
I can write a test/patch for this unless you beat me to it or other
think it is unreasonable.
- Stephen
^ permalink raw reply
* Re: [PATCH try 2] t1301-shared-repo.sh: don't let a default ACL interfere with the test
From: Junio C Hamano @ 2008-10-15 7:57 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Matt McCutchen, git
In-Reply-To: <48F59928.5040502@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
>>> But that would also paper over unanticipated bad interactions with strange
>>> ACLs that people might set, wouldn't it? By not placing this into
>>> test-lib.sh there is a higher chance that such an interaction is revealed,
>>> and we can react on it (educate users or fix the code).
>>
>> What do you exactly mean by "educate users or fix the code"? For example,
>> by not putting this setfacl in test-lib.sh, t1301 revealed that with a
>> default ACL higher up, "git init --shared" would not work as expected.
>>
>> Then what?
>>
>> - Do you mean, by "educate users", that we teach users not to play fun
>> games with ACL in a git controled working tree?
>
> Correct. In the case of a shared repository we can educate users not to
> play with ACLs.
>
>> - Do you mean, by "fix the code", that we teach adjust_shared_perm() to
>> deal with ACL?
>
> Correct in principle, but we need not go this route in the case of shared
> repositories because we better educate users.
If that is the case what difference does your suggestion of not putting it
in test-lib.sh make? We discourage users from playing ACL games, and we
protect ourselves from such by making sure the trash directory used for
running tests are not contaminated with ACL. Wouldn't it make more sense
to do so for all the tests, so that future test writers do not have to
worry about it?
^ permalink raw reply
* [Q] "status" of files in (a part of) the working tree
From: Brian Foster @ 2008-10-15 7:53 UTC (permalink / raw)
To: Git Mailing List
Hello,
For every file in a directory of my working tree,
I want to obtain a quick "status" summary (ideally,
recursively, i.e. descending into each sub-directory):
E.g., not-tracked, latest modification is not in
the index, latest modification is in the index,
not-modified, and so on. As a hypothetical example
(`# comments' added to explain what the line means):
$ git some-cmd
? foo # not-tracked
- bar # tracked, not-modified
M xyzzy # tracked, last modification not-in-index
I plover # tracked, last modification in-the-index
...
$
The `git ls-files' command sort-of seems to almost do
what I want, but not exactly. For instance (this is
written by hand but based on actual results):
$ git version
git version 1.6.0.2
$ git ls-files --exclude-standard --others --modified --cached -t
? foo
H bar
H xyzzy
C xyzzy
...
$
However, note that some files are listed twice (which
is confusing for my purposes), and I'm uncertain I've
specified all the magic to see all non-excluded files
regardless of their "status". Obviously, once I know
the appropriate set of magic I should be able to write
a filter to process the output and remove the unwanted
duplicates, but I'm wondering if someone has a better
suggestion? Generalissimo Goggle didn't find any clews.
cheers!
-blf-
--
“How many surrealists does it take to | Brian Foster
change a lightbulb? Three. One calms | somewhere in south of France
the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!
with brightly-coloured machine tools.” | http://www.stopesso.com
^ permalink raw reply
* Git graph on GitHub
From: Tom Werner @ 2008-10-15 7:47 UTC (permalink / raw)
To: git
We've just pushed out an update to the Network Graph on GitHub this
evening that finally allows us to draw very large repositories
(including Git). We're mirroring the Git repo on the site and I
thought it might be interesting for people to see this visualization.
Enjoy!
http://github.com/git/git/network
Let me know if you have any ideas for improvements on the graph. I'm
always looking for ways to enhance it.
Tom Preston-Werner
github.com/mojombo
^ permalink raw reply
* [PATCH] rebase-i-p: do not include non-first-parent commits touching UPSTREAM
From: Stephen Haberman @ 2008-10-15 7:44 UTC (permalink / raw)
To: gitster; +Cc: git, Stephen Haberman
In-Reply-To: <cover.1224055978.git.stephen@exigencecorp.com>
This covers an odd boundary case found by Avi Kivity's script where a branch
coming off of UPSTREAM is merged into HEAD. Initially it show up in
UPSTREAM..HEAD, but technically UPSTREAM is not moving, the rest of head is, so
we should not need to rewrite the merge.
This adds a check saying we can keep `preserve=t` if `p=UPSTREAM`...unless this
is the first first-parent commit in our UPSTREAM..HEAD rev-list, which could
very well point to UPSTREAM, but we still need to consider it as rewritten so we
start pulling in the rest of the UPSTREAM..HEAD commits that point to it.
Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
---
git-rebase--interactive.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 331cb18..3821692 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -583,6 +583,7 @@ first and then run 'git rebase --continue' again."
# parents to rewrite and skipping dropped commits would
# prematurely end our probe
MERGES_OPTION=
+ first_after_upstream="$(git rev-list --reverse --first-parent $UPSTREAM..$HEAD | head -n 1)"
else
MERGES_OPTION="--no-merges --cherry-pick"
fi
@@ -603,7 +604,7 @@ first and then run 'git rebase --continue' again."
preserve=t
for p in $(git rev-list --parents -1 $sha1 | cut -d' ' -f2-)
do
- if test -f "$REWRITTEN"/$p
+ if test -f "$REWRITTEN"/$p -a \( $p != $UPSTREAM -o $sha1 = $first_after_upstream \)
then
preserve=f
fi
--
1.6.0.2
^ permalink raw reply related
* [PATCH] rebase-i-p: if todo was reordered use HEAD as the rewritten parent
From: Stephen Haberman @ 2008-10-15 7:44 UTC (permalink / raw)
To: gitster; +Cc: git, Stephen Haberman
In-Reply-To: <cover.1224055978.git.stephen@exigencecorp.com>
This seems like the best guess we can make until git sequencer marks are
available. That being said, within the context of re-ordering a commit before
its parent in todo, I think applying it on top of the current commit seems like
a reasonable assumption of what the user intended.
Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
---
git-rebase--interactive.sh | 9 +++++++++
t/t3411-rebase-preserve-around-merges.sh | 4 ++--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 3821692..1fc4f44 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -194,6 +194,15 @@ pick_one_preserving_merges () {
if test -f "$REWRITTEN"/$p
then
new_p=$(cat "$REWRITTEN"/$p)
+
+ # If the todo reordered commits, and our parent is marked for
+ # rewriting, but hasn't been gotten to yet, assume the user meant to
+ # drop it on top of the current HEAD
+ if test -z "$new_p"
+ then
+ new_p=$(git rev-parse HEAD)
+ fi
+
test $p != $new_p && fast_forward=f
case "$new_parents" in
*$new_p*)
diff --git a/t/t3411-rebase-preserve-around-merges.sh b/t/t3411-rebase-preserve-around-merges.sh
index b3973c9..dfad5dd 100644
--- a/t/t3411-rebase-preserve-around-merges.sh
+++ b/t/t3411-rebase-preserve-around-merges.sh
@@ -80,7 +80,7 @@ test_expect_success 'setup' '
# \ /
# -- C1 --
#
-test_expect_failure 'squash F1 into D1' '
+test_expect_success 'squash F1 into D1' '
FAKE_LINES="1 squash 3 2" git rebase -i -p B1 &&
test "$(git rev-parse HEAD^2)" = "$(git rev-parse branch)" &&
test "$(git rev-parse HEAD~2)" = "$(git rev-parse B1)" &&
@@ -99,7 +99,7 @@ test_expect_failure 'squash F1 into D1' '
#
# And rebase G1..M1 onto E2
-test_expect_failure 'rebase two levels of merge' '
+test_expect_success 'rebase two levels of merge' '
git checkout -b branch2 A1 &&
touch g &&
git add g &&
--
1.6.0.2
^ permalink raw reply related
* [PATCH] git-mergetool: properly handle "git mergetool -- filename"
From: David Aguilar @ 2008-10-15 7:39 UTC (permalink / raw)
To: gitster; +Cc: git, tytso, David Aguilar
git-mergetool has an entry for "--" in its command-line parsing code
to designate the end of option processing. It was not calling shift,
though, which caused git-mergetool to incorrectly use "--" as the
merge filename.
This patch fixes this bug and updates the usage and documentation
to include [--] in the options spec.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
Documentation/git-mergetool.txt | 2 +-
git-mergetool.sh | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index e0b2703..475db72 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -7,7 +7,7 @@ git-mergetool - Run merge conflict resolution tools to resolve merge conflicts
SYNOPSIS
--------
-'git mergetool' [--tool=<tool>] [<file>]...
+'git mergetool' [--tool=<tool>] [--] [<file>]...
DESCRIPTION
-----------
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 94187c3..1b0dfec 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -8,7 +8,7 @@
# at the discretion of Junio C Hamano.
#
-USAGE='[--tool=tool] [file to merge] ...'
+USAGE='[--tool=tool] [--] [file to merge] ...'
SUBDIRECTORY_OK=Yes
OPTIONS_SPEC=
. git-sh-setup
@@ -296,6 +296,7 @@ do
esac
;;
--)
+ shift
break
;;
-*)
--
1.6.0.2.532.g84ed4c
^ permalink raw reply related
* [PATCH] rebase-i-p: only list commits that require rewriting in todo
From: Stephen Haberman @ 2008-10-15 7:44 UTC (permalink / raw)
To: gitster; +Cc: git, Stephen Haberman
In-Reply-To: <cover.1224055978.git.stephen@exigencecorp.com>
This is heavily based on Stephan Beyer's git sequencer rewrite of rebase-i-p.
Each commit is still found by rev-list UPSTREAM..HEAD, but a commit is only
included in todo if at least one its parents has been marked for rewriting.
Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
---
git-rebase--interactive.sh | 77 +++++++++++++++++++++++++++++--------------
1 files changed, 52 insertions(+), 25 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 274251f..331cb18 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -579,18 +579,67 @@ first and then run 'git rebase --continue' again."
echo $ONTO > "$REWRITTEN"/$c ||
die "Could not init rewritten commits"
done
+ # No cherry-pick because our first pass is to determine
+ # parents to rewrite and skipping dropped commits would
+ # prematurely end our probe
MERGES_OPTION=
else
- MERGES_OPTION=--no-merges
+ MERGES_OPTION="--no-merges --cherry-pick"
fi
SHORTUPSTREAM=$(git rev-parse --short $UPSTREAM)
SHORTHEAD=$(git rev-parse --short $HEAD)
SHORTONTO=$(git rev-parse --short $ONTO)
git rev-list $MERGES_OPTION --pretty=oneline --abbrev-commit \
- --abbrev=7 --reverse --left-right --cherry-pick \
+ --abbrev=7 --reverse --left-right --topo-order \
$UPSTREAM...$HEAD | \
- sed -n "s/^>/pick /p" > "$TODO"
+ sed -n "s/^>//p" | while read shortsha1 rest
+ do
+ if test t != "$PRESERVE_MERGES"
+ then
+ echo "pick $shortsha1 $rest" >> "$TODO"
+ else
+ sha1=$(git rev-parse $shortsha1)
+ preserve=t
+ for p in $(git rev-list --parents -1 $sha1 | cut -d' ' -f2-)
+ do
+ if test -f "$REWRITTEN"/$p
+ then
+ preserve=f
+ fi
+ done
+ if test f = "$preserve"
+ then
+ touch "$REWRITTEN"/$sha1
+ echo "pick $shortsha1 $rest" >> "$TODO"
+ fi
+ fi
+ done
+
+ # Watch for commits that been dropped by --cherry-pick
+ if test t = "$PRESERVE_MERGES"
+ then
+ mkdir "$DROPPED"
+ # Save all non-cherry-picked changes
+ git rev-list $UPSTREAM...$HEAD --left-right --cherry-pick | \
+ sed -n "s/^>//p" > "$DOTEST"/not-cherry-picks
+ # Now all commits and note which ones are missing in
+ # not-cherry-picks and hence being dropped
+ git rev-list $UPSTREAM...$HEAD --left-right | \
+ sed -n "s/^>//p" | while read rev
+ do
+ if test -f "$REWRITTEN"/$rev -a "$(grep "$rev" "$DOTEST"/not-cherry-picks)" = ""
+ then
+ # Use -f2 because if rev-list is telling us this commit is
+ # not worthwhile, we don't want to track its multiple heads,
+ # just the history of its first-parent for others that will
+ # be rebasing on top of it
+ git rev-list --parents -1 $rev | cut -d' ' -f2 > "$DROPPED"/$rev
+ cat "$TODO" | grep -v "${rev:0:7}" > "${TODO}2" ; mv "${TODO}2" "$TODO"
+ rm "$REWRITTEN"/$rev
+ fi
+ done
+ fi
test -s "$TODO" || echo noop >> "$TODO"
cat >> "$TODO" << EOF
@@ -606,28 +655,6 @@ first and then run 'git rebase --continue' again."
#
EOF
- # Watch for commits that been dropped by --cherry-pick
- if test t = "$PRESERVE_MERGES"
- then
- mkdir "$DROPPED"
- # drop the --cherry-pick parameter this time
- git rev-list $MERGES_OPTION --abbrev-commit \
- --abbrev=7 $UPSTREAM...$HEAD --left-right | \
- sed -n "s/^>//p" | while read rev
- do
- grep --quiet "$rev" "$TODO"
- if [ $? -ne 0 ]
- then
- # Use -f2 because if rev-list is telling this commit is not
- # worthwhile, we don't want to track its multiple heads,
- # just the history of its first-parent for others that will
- # be rebasing on top of us
- full=$(git rev-parse $rev)
- git rev-list --parents -1 $rev | cut -d' ' -f2 > "$DROPPED"/$full
- fi
- done
- fi
-
has_action "$TODO" ||
die_abort "Nothing to do"
--
1.6.0.2
^ permalink raw reply related
* [PATCH] rebase-i-p: fix 'no squashing merges' tripping up non-merges
From: Stephen Haberman @ 2008-10-15 7:44 UTC (permalink / raw)
To: gitster; +Cc: git, Stephen Haberman
In-Reply-To: <cover.1224055978.git.stephen@exigencecorp.com>
Also only check out the first parent if this commit if not a squash--if it is a
squash, we want to explicitly ignore the parent and leave the wc as is, as
cherry-pick will apply the squash on top of it.
Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
---
git-rebase--interactive.sh | 14 +++++++++-----
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 23cf7a5..274251f 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -219,15 +219,19 @@ pick_one_preserving_merges () {
die "Cannot fast forward to $sha1"
;;
f)
- test "a$1" = a-n && die "Refusing to squash a merge: $sha1"
-
first_parent=$(expr "$new_parents" : ' \([^ ]*\)')
- # detach HEAD to current parent
- output git checkout $first_parent 2> /dev/null ||
- die "Cannot move HEAD to $first_parent"
+
+ if [ "$1" != "-n" ]
+ then
+ # detach HEAD to current parent
+ output git checkout $first_parent 2> /dev/null ||
+ die "Cannot move HEAD to $first_parent"
+ fi
case "$new_parents" in
' '*' '*)
+ test "a$1" = a-n && die "Refusing to squash a merge: $sha1"
+
# redo merge
author_script=$(get_author_ident_from_commit $sha1)
eval "$author_script"
--
1.6.0.2
^ permalink raw reply related
* [PATCH] rebase-i-p: use HEAD for updating the ref instead of mapping OLDHEAD
From: Stephen Haberman @ 2008-10-15 7:44 UTC (permalink / raw)
To: gitster; +Cc: git, Stephen Haberman
In-Reply-To: <cover.1224055978.git.stephen@exigencecorp.com>
If OLDHEAD was reordered in the todo, and its mapped NEWHEAD was used to set the
ref, commits reordered after OLDHEAD in the todo would should up as un-committed
changes.
Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
---
git-rebase--interactive.sh | 15 +--------------
1 files changed, 1 insertions(+), 14 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 30e4523..c968117 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -376,20 +376,7 @@ do_next () {
HEADNAME=$(cat "$DOTEST"/head-name) &&
OLDHEAD=$(cat "$DOTEST"/head) &&
SHORTONTO=$(git rev-parse --short $(cat "$DOTEST"/onto)) &&
- if test -d "$REWRITTEN"
- then
- test -f "$DOTEST"/current-commit &&
- current_commit=$(cat "$DOTEST"/current-commit) &&
- git rev-parse HEAD > "$REWRITTEN"/$current_commit
- if test -f "$REWRITTEN"/$OLDHEAD
- then
- NEWHEAD=$(cat "$REWRITTEN"/$OLDHEAD)
- else
- NEWHEAD=$OLDHEAD
- fi
- else
- NEWHEAD=$(git rev-parse HEAD)
- fi &&
+ NEWHEAD=$(git rev-parse HEAD) &&
case $HEADNAME in
refs/*)
message="$GIT_REFLOG_ACTION: $HEADNAME onto $SHORTONTO)" &&
--
1.6.0.2
^ permalink raw reply related
* [PATCH] rebase-i-p: delay saving current-commit to REWRITTEN if squashing
From: Stephen Haberman @ 2008-10-15 7:44 UTC (permalink / raw)
To: gitster; +Cc: git, Stephen Haberman
In-Reply-To: <cover.1224055978.git.stephen@exigencecorp.com>
If the current-commit was dumped to REWRITTEN, but then we squash the next
commit in to it, we have invalidated the HEAD was just written to REWRITTEN.
Instead, append the squash hash to current-commit and save both of them the next
time around.
Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
---
git-rebase--interactive.sh | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index c968117..23cf7a5 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -170,13 +170,18 @@ pick_one_preserving_merges () {
if test -f "$DOTEST"/current-commit
then
- current_commit=$(cat "$DOTEST"/current-commit) &&
- git rev-parse HEAD > "$REWRITTEN"/$current_commit &&
- rm "$DOTEST"/current-commit ||
- die "Cannot write current commit's replacement sha1"
+ if [ "$fast_forward" == "t" ]
+ then
+ cat "$DOTEST"/current-commit | while read current_commit
+ do
+ git rev-parse HEAD > "$REWRITTEN"/$current_commit
+ done
+ rm "$DOTEST"/current-commit ||
+ die "Cannot write current commit's replacement sha1"
+ fi
fi
- echo $sha1 > "$DOTEST"/current-commit
+ echo $sha1 >> "$DOTEST"/current-commit
# rewrite parents; if none were rewritten, we can fast-forward.
new_parents=
--
1.6.0.2
^ permalink raw reply related
* [PATCH] rebase-i-p: test to exclude commits from todo based on its parents
From: Stephen Haberman @ 2008-10-15 7:44 UTC (permalink / raw)
To: gitster; +Cc: git, Stephen Haberman
In-Reply-To: <cover.1224055978.git.stephen@exigencecorp.com>
The first case was based off a script from Avi Kivity <avi@redhat.com>.
The second case includes a merge-of-a-merge to ensure both are included in todo.
Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
---
t/t3411-rebase-preserve-around-merges.sh | 136 ++++++++++++++++++++++++++++++
1 files changed, 136 insertions(+), 0 deletions(-)
create mode 100644 t/t3411-rebase-preserve-around-merges.sh
diff --git a/t/t3411-rebase-preserve-around-merges.sh b/t/t3411-rebase-preserve-around-merges.sh
new file mode 100644
index 0000000..b3973c9
--- /dev/null
+++ b/t/t3411-rebase-preserve-around-merges.sh
@@ -0,0 +1,136 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 Stephen Haberman
+#
+
+test_description='git rebase preserve merges
+
+This test runs git rebase with and tries to squash a commit from after a merge
+to before the merge.
+'
+. ./test-lib.sh
+
+# Copy/paste from t3404-rebase-interactive.sh
+echo "#!$SHELL_PATH" >fake-editor.sh
+cat >> fake-editor.sh <<\EOF
+case "$1" in
+*/COMMIT_EDITMSG)
+ test -z "$FAKE_COMMIT_MESSAGE" || echo "$FAKE_COMMIT_MESSAGE" > "$1"
+ test -z "$FAKE_COMMIT_AMEND" || echo "$FAKE_COMMIT_AMEND" >> "$1"
+ exit
+ ;;
+esac
+test -z "$EXPECT_COUNT" ||
+ test "$EXPECT_COUNT" = $(sed -e '/^#/d' -e '/^$/d' < "$1" | wc -l) ||
+ exit
+test -z "$FAKE_LINES" && exit
+grep -v '^#' < "$1" > "$1".tmp
+rm -f "$1"
+cat "$1".tmp
+action=pick
+for line in $FAKE_LINES; do
+ case $line in
+ squash|edit)
+ action="$line";;
+ *)
+ echo sed -n "${line}s/^pick/$action/p"
+ sed -n "${line}p" < "$1".tmp
+ sed -n "${line}s/^pick/$action/p" < "$1".tmp >> "$1"
+ action=pick;;
+ esac
+done
+EOF
+
+test_set_editor "$(pwd)/fake-editor.sh"
+chmod a+x fake-editor.sh
+
+# set up two branches like this:
+#
+# A1 - B1 - D1 - E1 - F1
+# \ /
+# -- C1 --
+
+test_expect_success 'setup' '
+ touch a &&
+ touch b &&
+ git add a &&
+ git commit -m A1 &&
+ git tag A1
+ git add b &&
+ git commit -m B1 &&
+ git tag B1 &&
+ git checkout -b branch &&
+ touch c &&
+ git add c &&
+ git commit -m C1 &&
+ git checkout master &&
+ touch d &&
+ git add d &&
+ git commit -m D1 &&
+ git merge branch &&
+ touch f &&
+ git add f &&
+ git commit -m F1 &&
+ git tag F1
+'
+
+# Should result in:
+#
+# A1 - B1 - D2 - E2
+# \ /
+# -- C1 --
+#
+test_expect_failure 'squash F1 into D1' '
+ FAKE_LINES="1 squash 3 2" git rebase -i -p B1 &&
+ test "$(git rev-parse HEAD^2)" = "$(git rev-parse branch)" &&
+ test "$(git rev-parse HEAD~2)" = "$(git rev-parse B1)" &&
+ git tag E2
+'
+
+# Start with:
+#
+# A1 - B1 - D2 - E2
+# \
+# G1 ---- L1 ---- M1
+# \ /
+# H1 -- J1 -- K1
+# \ /
+# -- I1 --
+#
+# And rebase G1..M1 onto E2
+
+test_expect_failure 'rebase two levels of merge' '
+ git checkout -b branch2 A1 &&
+ touch g &&
+ git add g &&
+ git commit -m G1 &&
+ git checkout -b branch3 &&
+ touch h
+ git add h &&
+ git commit -m H1 &&
+ git checkout -b branch4 &&
+ touch i &&
+ git add i &&
+ git commit -m I1 &&
+ git tag I1 &&
+ git checkout branch3 &&
+ touch j &&
+ git add j &&
+ git commit -m J1 &&
+ git merge I1 --no-commit &&
+ git commit -m K1 &&
+ git tag K1 &&
+ git checkout branch2 &&
+ touch l &&
+ git add l &&
+ git commit -m L1 &&
+ git merge K1 --no-commit &&
+ git commit -m M1 &&
+ GIT_EDITOR=: git rebase -i -p E2 &&
+ test "$(git rev-parse HEAD~3)" = "$(git rev-parse E2)" &&
+ test "$(git rev-parse HEAD~2)" = "$(git rev-parse HEAD^2^2~2)" &&
+ test "$(git rev-parse HEAD^2^1^1)" = "$(git rev-parse HEAD^2^2^1)"
+'
+
+test_done
+
--
1.6.0.2
^ permalink raw reply related
* [PATCH] rebase-i-p: squashing and limiting todo
From: Stephen Haberman @ 2008-10-15 7:44 UTC (permalink / raw)
To: gitster; +Cc: git, Stephen Haberman
This is v3, rebased on top of sp/maint with sp/master and sh/maint-rebase3.
So, it should apply cleanly to that. Junio's feedback aside, the only change
from v2 is that maint-rebase3's dropped commit check needs to be done before
Johannes's recent addition of:
test -s "$TODO" || echo noop >> "$TODO"
Because now the todo may temporarily have picks in it while probing for parents
that could later be removed by the dropped/cherry-picked commit check.
Previously todo never had temporary entries, so it didn't matter when the
dropped commit check was done.
(Apologies for not seeing Junio's what's cooking first and using his
maint/master instead of Shawn's. Let me know if I need to redo this and I will
get even more practice at rebasing.)
(Gah, resending with the list cc'd this time. Dammit, sorry about that.)
Thanks,
Stephen
Stephen Haberman (7):
rebase-i-p: test to exclude commits from todo based on its parents
rebase-i-p: use HEAD for updating the ref instead of mapping OLDHEAD
rebase-i-p: delay saving current-commit to REWRITTEN if squashing
rebase-i-p: fix 'no squashing merges' tripping up non-merges
rebase-i-p: only list commits that require rewriting in todo
rebase-i-p: do not include non-first-parent commits touching UPSTREAM
rebase-i-p: if todo was reordered use HEAD as the rewritten parent
git-rebase--interactive.sh | 131 ++++++++++++++++++-----------
t/t3411-rebase-preserve-around-merges.sh | 136 ++++++++++++++++++++++++++++++
2 files changed, 218 insertions(+), 49 deletions(-)
create mode 100644 t/t3411-rebase-preserve-around-merges.sh
^ 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