* Re: [RFC] Zit: the git-based single file content tracker
From: Nguyen Thai Ngoc Duy @ 2008-10-23 12:50 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <gdok16$vh2$1@ger.gmane.org>
On 10/23/08, Giuseppe Bilotta <giuseppe.bilotta@gmail.com> wrote:
> The principle is extremely simple: when you choose to start tracking a
> file with Zit,
>
> zit track file
>
> Zit will create a directory .zit.file to hold a git repository
> tracking the single file .zit.file/file, which is just a hard link to
> file.
Why not use one .zit repo and track each file on each own branch?.
--
Duy
^ permalink raw reply
* Re: git performance
From: Matthieu Moy @ 2008-10-23 12:16 UTC (permalink / raw)
To: Edward Ned Harvey; +Cc: git
In-Reply-To: <000901c93490$e0c40ed0$a24c2c70$@com>
"Edward Ned Harvey" <git@nedharvey.com> writes:
>> Yes, it does stat all the files. How many files are you talking about,
>> and what platform? From a warm cache on Linux, the 23,000 files kernel
>> repo takes about a tenth of a second to stat all files for me (and this
>> on a several year-old machine). And of course many operations don't
>> require stat'ing at all (like looking at logs, or diffs that don't
>> involve the working tree).
>
> No worries. No solution can meet everyone's needs.
>
> I'm talking about 40-50,000 files, on multi-user production linux,
> which means the cache is never warm, except when I'm benchmarking.
> Specifically RHEL 4 with the files on NFS mount. Cold cache "svn st"
> takes ~10 mins. Warm cache 20-30 sec.
SVN does not only has to stat the files. It also has to read the
stat-cache information wich is split in one .svn/ per directory in the
working tree. Not sure which operation dominates the performance,
though. Best is just to try.
> Out of curiosity, what are they talking about, when they say "git is
> fast?" Just the fact that it's all local disk, or is there more to
> it than that?
Not just local disk: bzr also works locally, and git is much faster on
most operations (bzr status can now compete with git, but "git log"
and "git commit" can be instantaneous where bzr take 1 minute for
example).
For sure, doing most operations locally is the key to being fast, but
Git has also been written so that the complexity of algorithms be as
low as possible.
> I could see - git would probably outperform perforce for versioning
> of large files (let's say iso files) to benefit from sustained local
> disk IO, while perforce would probably outperform anything I can
> think of, operating on thousands of tiny files, because it will
> never walk the tree.
Mercurial has an extension called "inotify" that avoids walking the
disk too. AFAIK doesn't have an equivalent in Git (mostly because most
people interested find git fast enough).
--
Matthieu
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Felipe Oliveira Carvalho @ 2008-10-23 12:33 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <gdok16$vh2$1@ger.gmane.org>
It sounds interesting. I have some single files that I would like to track
using git, zit seems to be a good solution.
--
Felipe
^ permalink raw reply
* git-cvsimport bug? Newly created branch not seen unless there's at least one commit in it
From: Francis Galiegue @ 2008-10-23 12:00 UTC (permalink / raw)
To: git
Hello,
I've tried to git-cvsimport a module from CVS, where a branch named "foo"
existed. CVSROOT set in the environment, CVS_RSH too, and I imported with:
git-cvsimport -k -a -C themodule themodule
However, it didn't do what I expected: I couldn't see the branch named "foo".
I had to make a commit using CVS on that very same module on that "foo"
branch. After the commit, out of curiosity, I executed the same git command
again in the same directory: this time the branch was seen.
Is this a bug, or is there a git-cvsimport option that I missed? I have looked
at the manpage several times, and couldn't find what option could be of any
use in my case (mind you, I haven't looked at the cvsps manpage either).
Thanks,
--
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 6 83 87 78 75
Tel : +33 (0) 1 78 94 55 52
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris
^ permalink raw reply
* git-cvsimport bug? Newly created branch not seen unless there's at least one commit in it
From: Francis Galiegue @ 2008-10-23 12:01 UTC (permalink / raw)
To: git
Hello,
I've tried to git-cvsimport a module from CVS, where a branch named "foo"
existed. CVSROOT set in the environment, CVS_RSH too, and I imported with:
git-cvsimport -k -a -C themodule themodule
However, it didn't do what I expected: I couldn't see the branch named "foo".
I had to make a commit using CVS on that very same module on that "foo"
branch. After the commit, out of curiosity, I executed the same git command
again in the same directory: this time the branch was seen.
Is this a bug, or is there a git-cvsimport option that I missed? I have looked
at the manpage several times, and couldn't find what option could be of any
use in my case (mind you, I haven't looked at the cvsps manpage either).
Thanks,
--
fge
^ permalink raw reply
* Re: [PATCH 3/7] gitk: Allow starting gui blame for a specific line.
From: Paul Mackerras @ 2008-10-23 11:58 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <1223449540-20457-4-git-send-email-angavrilov@gmail.com>
Alexander Gavrilov writes:
> Adds a context menu item to the diff viewer pane that
> calls blame, focusing it on the clicked line. In case
> of combined diffs, it also automatically deduces which
> parent is to be blamed.
I have some comments on this one, but I haven't finished reviewing it
completely, so I may have more... :)
> +proc find_hunk_blamespec {base line} {
> + global ctext
> +
> + # Find and parse the hunk header
> + set s_lix [$ctext search -backwards -regexp ^@@ "$line.0 lineend" $base.0]
> + if {$s_lix eq {}} return
> +
> + set s_line [$ctext get $s_lix "$s_lix + 1 lines"]
> + if {![regexp {^@@@?(( -\d+(,\d+)?)+) \+(\d+)(,\d+)? @@} $s_line \
In fact there can be many @ characters at the beginning of the line;
the number of parents plus one, in fact. See commit
c465a76af658b443075d6efee1c3131257643020 in the kernel tree for an
example. I suggest starting with ^@@@* rather than ^@@@?.
> + # Now scan the lines to determine offset within the hunk
> + set parent {}
> + set dline 0
> + set s_lno [lindex [split $s_lix "."] 0]
> +
> + for {set i $line} {$i > $s_lno} {incr i -1} {
> + set c_line [$ctext get $i.0 "$i.0 + 1 lines"]
> + if {$parent eq {}} {
> + # find first preceeding line that belongs to some parent
> + for {set j 0} {$j < [llength $old_lines]} {incr j} {
> + set code [string index $c_line $j]
> + if {$code ne {-} && $code ne { }} continue
> + if {$code eq { } && $parent ne {}} continue
> + set parent $j
> + if {$code eq {-}} break
> + }
> + }
This part worries me a bit. If the user clicks on a line where all
the $code values are "+" then I think we should blame the current
commit. Either that, or we disable the context menu item before
posting it if the user clicks on a line that starts with all "+"
characters (as many "+" as there are parents).
BTW, writing "-" rather than {-} in expressions is more idiomatic.
Paul.
^ permalink raw reply
* Re: Tip: avoiding net overhead using git over sshfs
From: Felipe Carvalho Oliveira @ 2008-10-23 11:51 UTC (permalink / raw)
To: Michael J Gruber, Matthieu Moy; +Cc: git
In-Reply-To: <490036A2.20608@drmicha.warpmail.net>
On Thu, Oct 23, 2008 at 6:32 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> I'm sorry but I'm afraid I'm missing the point: If you don't have shell
> access then you can't use ssh(fs), can you?
> Maybe you mean you can't set up git daemon or gitweb.cgi on the server?
Yes, i can't set up any git daemon or any other software.
I have just sftp acess. And sftp is a "dumb protocol" to use git.
On Thu, Oct 23, 2008 at 7:00 AM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> I think you'd better work locally, and push to the sshfs directory
> from time to time. Then, you'd both have working tree and .git locally
> and fast, while keeping the safety of replicating to your ssh server.
I can't use git-push as I explained before.
I use git as a deployment tool in this case.
I work locallly and use git-pull to sync my local repo and the
"production"(server).
Git works better than a manual (S)FTP sync.
I hope I'm more clear now.
--
Felipe
^ permalink raw reply
* Re: git performance
From: Andreas Ericsson @ 2008-10-23 7:11 UTC (permalink / raw)
To: Edward Ned Harvey; +Cc: git
In-Reply-To: <000901c93490$e0c40ed0$a24c2c70$@com>
Edward Ned Harvey wrote:
>> Yes, it does stat all the files. How many files are you talking about,
>> and what platform? From a warm cache on Linux, the 23,000 files kernel
>> repo takes about a tenth of a second to stat all files for me (and this
>> on a several year-old machine). And of course many operations don't
>> require stat'ing at all (like looking at logs, or diffs that don't
>> involve the working tree).
>
> No worries. No solution can meet everyone's needs.
>
> I'm talking about 40-50,000 files, on multi-user production linux, which means the cache is never warm, except when I'm benchmarking. Specifically RHEL 4 with the files on NFS mount. Cold cache "svn st" takes ~10 mins. Warm cache 20-30 sec. Surprisingly to me, performance was approx the same for files on local disk versus NFS. Probably the best solution for us is perforce, we just don't like the pricetag.
>
> Out of curiosity, what are they talking about, when they say "git is fast?" Just the fact that it's all local disk, or is there more to it than that? I could see - git would probably outperform perforce for versioning of large files (let's say iso files) to benefit from sustained local disk IO, while perforce would probably outperform anything I can think of, operating on thousands of tiny files, because it will never walk the tree.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git performance
From: Andreas Ericsson @ 2008-10-23 7:11 UTC (permalink / raw)
To: Edward Ned Harvey; +Cc: git
In-Reply-To: <000901c93490$e0c40ed0$a24c2c70$@com>
Edward Ned Harvey wrote:
>> Yes, it does stat all the files. How many files are you talking about,
>> and what platform? From a warm cache on Linux, the 23,000 files kernel
>> repo takes about a tenth of a second to stat all files for me (and this
>> on a several year-old machine). And of course many operations don't
>> require stat'ing at all (like looking at logs, or diffs that don't
>> involve the working tree).
>
> No worries. No solution can meet everyone's needs.
>
> I'm talking about 40-50,000 files, on multi-user production linux, which means the cache is never warm, except when I'm benchmarking. Specifically RHEL 4 with the files on NFS mount. Cold cache "svn st" takes ~10 mins. Warm cache 20-30 sec. Surprisingly to me, performance was approx the same for files on local disk versus NFS. Probably the best solution for us is perforce, we just don't like the pricetag.
>
> Out of curiosity, what are they talking about, when they say "git is fast?" Just the fact that it's all local disk, or is there more to it than that? I could see - git would probably outperform perforce for versioning of large files (let's say iso files) to benefit from sustained local disk IO, while perforce would probably outperform anything I can think of, operating on thousands of tiny files, because it will never walk the tree.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Tip: avoiding net overhead using git over sshfs
From: Matthieu Moy @ 2008-10-23 9:00 UTC (permalink / raw)
To: Felipe Carvalho Oliveira; +Cc: git
In-Reply-To: <a2075f4c0810221826w511a3b87r6fea4fb0dee24e1f@mail.gmail.com>
"Felipe Carvalho Oliveira" <felipekde@gmail.com> writes:
> Use git over sshfs is not so good, but is an option for people that
> don't have shell acess to the server/hosting like me.
>
> # mounting
> sshfs -o workaround=rename <user>@<host>:/home/<user>/ <mount_point>
> cd <the_directory_of_your_project>
>
> # we will move the .git directory to the local filesystem
> mv .git ~/.my_project_git
> # and create a symlink to the local .git
> ln -s ~/.my_project_git .git
I think you'd better work locally, and push to the sshfs directory
from time to time. Then, you'd both have working tree and .git locally
and fast, while keeping the safety of replicating to your ssh server.
--
Matthieu
^ permalink raw reply
* Re: Tip: avoiding net overhead using git over sshfs
From: Michael J Gruber @ 2008-10-23 8:32 UTC (permalink / raw)
To: Felipe Carvalho Oliveira; +Cc: git
In-Reply-To: <a2075f4c0810221826w511a3b87r6fea4fb0dee24e1f@mail.gmail.com>
Felipe Carvalho Oliveira venit, vidit, dixit 23.10.2008 03:26:
> Use git over sshfs is not so good, but is an option for people that
> don't have shell acess to the server/hosting like me.
I'm sorry but I'm afraid I'm missing the point: If you don't have shell
access then you can't use ssh(fs), can you?
Maybe you mean you can't set up git daemon or gitweb.cgi on the server?
> # mounting
> sshfs -o workaround=rename <user>@<host>:/home/<user>/ <mount_point>
> cd <the_directory_of_your_project>
>
> # we will move the .git directory to the local filesystem
> mv .git ~/.my_project_git
> # and create a symlink to the local .git
> ln -s ~/.my_project_git .git
>
> Done!
>
> Now you can open gitk instantly ;-) and don't need to have the entire
> .git thing on a remote filesystem.
In fact your complete git repository is now on the local filesystem,
with only the worktree checked out on sshfs. Is that what you are trying
to achieve? Or do you want to "synchronize" repos on local and sshfs
filesystems?
Michael
^ permalink raw reply
* Re: Terminology question: "tracking" branches
From: Michael J Gruber @ 2008-10-23 8:07 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Marc Branchaud, Peter Harris, git, Junio C Hamano
In-Reply-To: <20081022161302.GC16946@atjola.homenet>
Björn Steinbrink venit, vidit, dixit 22.10.2008 18:13:
> On 2008.10.22 16:59:58 +0200, Michael J Gruber wrote:
>> - a remote branch (a branch in your local repo which is a copy of a
>> branch in a remote repo; stored under refs/remotes, never to be modified
>> locally)
>> - a (remote) tracking branch (a local branch which is set up to pull
>> from a remote branch by default)
>
> (Remote) tracking branches are actually what you called remote branches,
> at least according to the git glossary. But I wonder, what is the right
> term for a branch that has the --track setup for pull?
Ooops, I'm sorry. I went by the name of the "--track" option and was
sure that that "git help branch" used the name "tracking branch" for the
branches created with "--track", but I was wrong. So:
"(remote) tracking branch" is a local branch stored under refs/remotes/
which is a "copy" of a branch on a remote repository.
That leaves open:
- What does "remote branch" mean, if it means anything at all? It could
be used for a branch in a remote repository, i.e. the other side of
fetch/push refspec (remote branch:tracking branch).
- How to name a local branch created with --track off of a (remote)
tracking branch? Local tracking branch? Downstream/work/modification branch?
I think that linguistically, the confusion comes from using the noun as
well as the adjective "remote". As an adjective: "remote something"
cleary is something residing remotely. As a noun it's the config added
by "git remote add".
Note that the glossary doesn't define remote at all. I'd volunteer
changing that once the discussion reaches a consensus.
My suggestion would be:
remote (noun): A configuration as created by "git remote add" which
points to a remote repository (using a URL) and sets up refspecs for
fetching and/or pulling. Note that the URL may point to a local
filesystem or even ".". See also remote (adjective).
remote (adjective): Anything residing in another repository. See also
remote (noun).
local: Sometimes used to emphasize things residing "locally", i.e. in
the repository at hand, as opposed to "remotely".
tracking branch: A branch tracking a (remote) branch on a remote
repository, i.e. a local branch stored under refs/remotes/ which is a
"copy" of a branch on a remote repository; typically created by "git
clone" or "git remote add/update".
remote tracking branch: Synonymous with tracking branch. [remote is a
noun, an object for track here]
[adjective to be found] branch: A local branch which is set up to pull
or rebase automatically from a tracking branch. Used for local
modifications to remote branches. [I'm tempted to use local tracking
branch here, but that would just add to the confusion.]
Come to think of it: "Off-track" branch would be the ideal name for a
local branch created off of a (remote) tracking branch, using --track to
specify the track where things go off. But I'm not sure everyone would
like the implied pun...
Cheers,
Michael
^ permalink raw reply
* Re: git performance
From: Andreas Ericsson @ 2008-10-23 7:43 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Edward Ned Harvey, git
In-Reply-To: <m3d4hsi708.fsf@localhost.localdomain>
Jakub Narebski wrote:
> "Edward Ned Harvey" <git@nedharvey.com> writes:
>
>> I see things all over the Internet saying git is fast. I'm
>> currently struggling with poor svn performance and poor attitude of
>> svn developers, so I'd like to consider switching to git. A quick
>> question first.
>>
>> The core of the performance problem I'm facing is the need to "walk
>> the tree" for many thousand files. Every time I do "svn update" or
>> "svn status" the svn client must stat every file to check for local
>> modifications (a coffee cup or a beer worth of stats). In essence,
>> this is unavoidable if there is no mechanism to constantly monitor
>> filesystem activity during normal operations. Analogous to
>> filesystem journaling.
>>
>> So - I didn't see anything out there saying "git is fast because it
>> uses inotify" or anything like that. Perhaps git would not help me
>> at all? Because git still needs to stat all the files in the tree?
>
> http://git.or.cz/gitwiki/GitBenchmarks
>
> While it should be possible to use 'assume unchanged' bit together
> with inotify / icron, it is not something tha is done; IIRC Mercurial
> had Linux-only InotifyPlugin...
>
Well, inotify() is Linux specific, so it'd be quite hard to support on
another platform. Emulating it with a billion stat() calls feels rather
like a disk (and I/O performance) killer.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git performance
From: Andreas Ericsson @ 2008-10-23 7:41 UTC (permalink / raw)
To: Edward Ned Harvey; +Cc: git
In-Reply-To: <000901c93490$e0c40ed0$a24c2c70$@com>
Edward Ned Harvey wrote:
>> Yes, it does stat all the files. How many files are you talking
>> about, and what platform? From a warm cache on Linux, the 23,000
>> files kernel repo takes about a tenth of a second to stat all files
>> for me (and this on a several year-old machine). And of course many
>> operations don't require stat'ing at all (like looking at logs, or
>> diffs that don't involve the working tree).
>
> No worries. No solution can meet everyone's needs.
>
> I'm talking about 40-50,000 files, on multi-user production linux,
Umm... using git to track a production server? I think there's something
in your specific use-case that eluded pretty much everyone here the
first time you asked about it.
git was built to maintain the linux kernel with its patch-and-merge based
workflow, 117k commits and 25k files. It's *good* at that sort of thing,
but a lot of features are "source-code management" specific. It sounds to
me you're asking for something that will keep a backup of most of your
entire system (apart from /home), which it's not really suited for. For
instance, it doesn't keep track of mode-bits on files (apart from
"executable or not").
> which means the cache is never warm, except when I'm benchmarking.
> Specifically RHEL 4 with the files on NFS mount. Cold cache "svn st"
> takes ~10 mins. Warm cache 20-30 sec. Surprisingly to me,
> performance was approx the same for files on local disk versus NFS.
> Probably the best solution for us is perforce, we just don't like the
> pricetag.
>
> Out of curiosity, what are they talking about, when they say "git is
> fast?"
Merges, patch application, committing, history walking and data
transfers are all extremely quick operations under git.
Actually, history walking isn't extremely quick, but several neat
tricks are in place that make it *seem* quick. Running
"git log drivers/net/wireless" on the linux kernel with a cold
cache starts spitting out output after about 1 second on my measly
laptop (where the kernel has 117k commits on 25k files).
> Just the fact that it's all local disk, or is there more to
> it than that? I could see - git would probably outperform perforce
> for versioning of large files (let's say iso files) to benefit from
> sustained local disk IO, while perforce would probably outperform
> anything I can think of, operating on thousands of tiny files,
> because it will never walk the tree.
>
Git doesn't *have* to walk the tree either. "git status" obviously
has to do that, since you're asking "what files have changed in this
tree since I last added stuff to the index", but you can use git just
fine without ever issuing "git status" (assuming you're the one
controlling the changes, that is).
"git rm" and "git add" won't walk the tree. They're just interested in
the paths you give them and won't touch anything else.
"git commit path1 path2" won't walk the tree. It has to walk the paths
(which can be entire subdirectories, or all of them), but not more than
that.
"git push" (ie, send your changes upstream) won't walk the tree. It'll
just look at the history and how they differ.
"git merge" (and therefore also "git pull") doesn't walk the tree. It
only makes sure paths that are touched by the merge are up-to-date.
Apart from that, it would be trivial to hack up some inotify config
and scripts that stages changes in a separate index-file and then
add a simple wrapper that operates on the separate index-file rather
than the "regular" one.
Sample "giti" wrapper:
--%<--%<--%<--
#!/bin/sh
# giti - inotify driven git wrapper
GIT_INDEX=.git/inotify-index
export GIT_INDEX
case "$@" in
status)
git diff --name-only --cached
exit $?
;;
esac
git "$@"
--%<--%<--%<--
Sample inotify script:
--%<--%<--%<--
#!/bin/sh
GIT_INDEX=.git/inotify-index git add $1
--%<--%<--%<--
Sample incrontab(5) entry:
--%<--%<--%<--
/watched/path IN_CLOSE_WRITE inotify.git $@/$#
--%<--%<--%<--
Totally untested ofcourse, so it probably needs tweaking. It should
work rather well though, assuming you're somewhat careful what
arguments you send to the "giti" wrapper and make sure to never
use any git-commands that *have* to walk the entire tree (such as
"git commit -a").
Let us know how it pans out.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 2/3] Add -n/--no-prompt option to mergetool
From: Charles Bailey @ 2008-10-23 6:44 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, William Pursell, Andreas Ericsson,
Theodore Ts'o
In-Reply-To: <7vr668tdvy.fsf@gitster.siamese.dyndns.org>
On Wed, Oct 22, 2008 at 04:21:21PM -0700, Junio C Hamano wrote:
> Charles Bailey <charles@hashpling.org> writes:
>
> > I'm pretty keen on this patch, but have no strong opinions on which
> > short option is used, so are there any votes against -y?
>
> Between 'n' and 'y', I am in favour of the latter, but at the same time I
> have to wonder if there are other commands that would want "Assume yes"
> option. It could be that this single command that prompts for "Is this
> Ok" is an oddball and giving it an "interactive" option to trigger the
> current behaviour might make things more consistent. I dunno.
>
I think that git mergetool probably counts as at least 'unusual', and
I think that there is some merit in the current default behaviour. It
gives you a prompt at which you can C-c if it's about to run something
that you don't want it to do the first few times that you try
mergetool.
After more thoughts, I'm somewhat in favour of dropping the short
switch altogether. As it just saves a single keypress per merge I
imagine that most mergetool users, once they discover this new
feature and decide that they want to use it, will prefer to use a user
config option to switch it on. The command line option then becomes
something that you would only need to use to override your normal
default and something on which to hang the option description in the
man page.
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
^ permalink raw reply
* What's in git.git (Oct 2008, #05; Wed, 22)
From: Junio C Hamano @ 2008-10-23 5:41 UTC (permalink / raw)
To: git
The latest maintenance release 1.6.0.3 is out. 'master' has gitk updates
and also quite a lot of topics that have been cooking in 'next'.
* The 'maint' branch has these fixes since the last announcement.
Abhijit Bhopatkar (1):
Documentation: Clarify '--signoff' for git-commit
Junio C Hamano (2):
Fix testcase failure when extended attributes are in use
GIT 1.6.0.3
Nicolas Pitre (1):
rehabilitate 'git index-pack' inside the object store
* The 'master' branch has these since the last announcement
in addition to the above.
Alexander Gavrilov (3):
gitk: Fix a bug in collapsing deeply nested trees
gitk: Enhance file encoding support
gitk: Implement batch lookup and caching of encoding attrs
Andreas Ericsson (1):
rebase: Support preserving merges in non-interactive mode
Brian Gernhardt (1):
format-patch: autonumber by default
Christian Stimming (1):
gitk: Add untranslated error messages to translation
Dmitry Potapov (2):
check-attr: add an internal check_attr() function
check-attr: Add --stdin option
Fredrik Skolmli (1):
Documentation: Spelling fix
Giuseppe Bilotta (1):
gitweb: refactor input parameters parse/validation
Jeff King (8):
refactor handling of "other" files in ls-files and status
t4012: use test_cmp instead of cmp
diff: unify external diff and funcname parsing code
diff: introduce diff.<driver>.binary
diff: add filter for converting binary to text
document "intent to add" option to git-add
rm: loosen safety valve for empty files
submodule: fix some non-portable grep invocations
Johannes Schindelin (1):
Fix fetch/pull when run without --update-head-ok
Johannes Sixt (1):
git-remote: list branches in vertical lists
Jonas Fonseca (1):
git-check-attr(1): use 'verse' for multi-line synopsis sections
Junio C Hamano (6):
pull: allow "git pull origin $something:$current_branch" into an unborn
branch
Fix "checkout --track -b newbranch" on detached HEAD
reset --hard/read-tree --reset -u: remove unmerged new paths
demonstrate breakage of detached checkout with symbolic link HEAD
Enhance hold_lock_file_for_{update,append}() API
Fix mismerge at cdb22c4 in builtin-checkout.c
Lee Marlow (2):
bash completion: Add 'workflows' to 'git help'
workflows documentation: fix link to git-request-pull[1]
Mark Levedahl (1):
compat/cygwin.c - Use cygwin's stat if core.filemode == true
Matt McCutchen (1):
git-merge-recursive: honor merge.conflictstyle once again
Miklos Vajna (2):
builtin-commit: use reduce_heads() only when appropriate
Implement git clone -v
Nanako Shiraishi (2):
rebase --no-verify
rebase: Document --no-verify option to bypass pre-rebase hook
Paul Mackerras (6):
gitk: Use <Button-2> for context menus on OSX
gitk: Clean up file encoding code and add enable/disable option
gitk: Fix binding for <Return> in sha1 entry field
gitk: New way of constructing menus that allows for Alt+letter
accelerators
gitk: Regenerate .po files
gitk: Turn short SHA1 names into links too
Petr Baudis (1):
Do not rename read-only files during a push
René Scharfe (3):
add alloc_ref_with_prefix()
use alloc_ref_from_str() everywhere
make alloc_ref_from_str() the new alloc_ref()
Richard Quirk (1):
gitk: Bind Key-Return to create on new branch dialog
Shawn O. Pearce (1):
describe: Make --tags and --all match lightweight tags more often
Stephen Haberman (1):
rebase--interactive: fix parent rewriting for dropped commits
Thomas Rast (3):
Documentation: new upstream rebase recovery section in git-rebase
Documentation: Refer to git-rebase(1) to warn against rewriting
Documentation: add manpage about workflows
^ permalink raw reply
* What's cooking in git.git (Oct 2008, #05; Wed, 22)
From: Junio C Hamano @ 2008-10-23 5:41 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
----------------------------------------------------------------
[New Topics]
* cj/maint-gitpm-fix-maybe-self (Sat Oct 18 20:25:12 2008 +0200) 1 commit
+ Git.pm: do not break inheritance
Looked Ok; will be in 'master' soon.
* gb/gitweb-pathinfo (Tue Oct 21 21:34:54 2008 +0200) 5 commits
- gitweb: generate parent..current URLs
- gitweb: parse parent..current syntax from PATH_INFO
- gitweb: use_pathinfo filenames start with /
- gitweb: generate project/action/hash URLs
- gitweb: parse project/action/hash_base:filename PATH_INFO
Seventh iteration; hopefully the usual gitweb gangs will give quick
comments and ack to push this out to 'next' soon.
* ag/blame-encoding (Wed Oct 22 00:55:57 2008 +0400) 1 commit
+ builtin-blame: Reencode commit messages according to git-log
rules.
Looked Ok; will be in 'master' soon.
* mv/parseopt-checkout-index (Sat Oct 18 03:17:23 2008 +0200) 1 commit
+ parse-opt: migrate builtin-checkout-index.
Looked Ok; will be in 'master' soon.
----------------------------------------------------------------
[Graduated to "master"]
* rs/alloc-ref (Sat Oct 18 10:44:18 2008 +0200) 3 commits
+ make alloc_ref_from_str() the new alloc_ref()
+ use alloc_ref_from_str() everywhere
+ add alloc_ref_with_prefix()
* jc/maint-reset-remove-unmerged-new (Wed Oct 15 16:00:06 2008 -0700) 1 commit
+ reset --hard/read-tree --reset -u: remove unmerged new paths
Teaches "reset --hard" to remove new paths in conflict.
* jk/fix-ls-files-other (Fri Oct 17 13:03:52 2008 -0700) 2 commits
+ Merge branch 'jk/maint-ls-files-other' into jk/fix-ls-files-other
+ refactor handling of "other" files in ls-files and status
* jc/maint-co-track (Fri Oct 17 15:44:39 2008 -0700) 4 commits
+ Fix checkout not to clobber the branch when using symlinked HEAD
upon detaching
+ Enhance hold_lock_file_for_{update,append}() API
+ demonstrate breakage of detached checkout with symbolic link HEAD
+ Fix "checkout --track -b newbranch" on detached HEAD
* jk/maint-ls-files-other (Thu Oct 16 11:07:26 2008 -0400) 1 commit
+ refactor handling of "other" files in ls-files and status
* pb/commit-where (Fri Oct 3 22:13:49 2008 -0400) 4 commits
+ tutorial: update output of git commit
+ reformat informational commit message
+ git commit: Reformat output somewhat
+ builtin-commit.c: show on which branch a commit was added
* js/maint-fetch-update-head (Tue Oct 14 15:32:20 2008 -0700) 2 commits
+ pull: allow "git pull origin $something:$current_branch" into an
unborn branch
+ Fix fetch/pull when run without --update-head-ok
* ns/rebase-noverify (Tue Oct 14 08:17:16 2008 +0900) 2 commits
+ rebase: Document --no-verify option to bypass pre-rebase hook
+ rebase --no-verify
This adds --no-verify to git rebase, to avoid the pre-rebase hook.
* mv/merge-noff (Fri Oct 3 14:04:47 2008 +0200) 1 commit
+ builtin-commit: use reduce_heads() only when appropriate
Fixes "git merge --no-ff --no-commit".
* ae/preservemerge (Mon Sep 29 22:28:57 2008 +0200) 1 commit
+ rebase: Support preserving merges in non-interactive mode
* pb/rename-rowin32 (Fri Oct 3 12:20:43 2008 +0200) 1 commit
+ Do not rename read-only files during a push
Fixes pack file renames on Windows.
* sp/describe-lwtag (Mon Oct 13 07:39:46 2008 -0700) 1 commit
+ describe: Make --tags and --all match lightweight tags more often
When the user gives --tags, the request is asking to treat lightweight and
annotated tags at equal weight, and if lightweight ones are closer, they
should be used.
* gb/formatpatch-autonbr (Thu Oct 2 16:55:39 2008 -0400) 1 commit
+ format-patch: autonumber by default
* dp/checkattr (Wed Oct 15 09:11:52 2008 +0200) 3 commits
+ git-check-attr(1): use 'verse' for multi-line synopsis sections
+ check-attr: Add --stdin option
+ check-attr: add an internal check_attr() function
Batch attr lookup via --stdin, for gitk and git-gui.
* gb/refactor-pathinfo (Fri Oct 10 20:42:26 2008 +0200) 1 commit
+ gitweb: refactor input parameters parse/validation
A major cleanup on the way gitweb parses its input arguments.
Future gitweb patches to add more arguments into the PATH_INFO
depend upon this initial cleanup work.
* ml/cygwin-filemode (Mon Oct 13 00:33:31 2008 -0400) 1 commit
+ compat/cygwin.c - Use cygwin's stat if core.filemode == true
* mv/clonev (Thu Oct 9 01:40:32 2008 +0200) 1 commit
+ Implement git clone -v
Does what it says it does. This may be ready for master soon,
its a pretty trivial change.
* tr/workflow-doc (Sat Sep 13 18:11:01 2008 +0200) 2 commits
+ Documentation: Refer to git-rebase(1) to warn against rewriting
+ Documentation: new upstream rebase recovery section in git-rebase
Also the workflow document itself is now in 'master'.
* sh/maint-rebase3 (Sun Oct 5 23:26:52 2008 -0500) 1 commit
+ rebase--interactive: fix parent rewriting for dropped commits
* jk/diff-convfilter (Sun Oct 5 17:43:45 2008 -0400) 4 commits
+ diff: add filter for converting binary to text
+ diff: introduce diff.<driver>.binary
+ diff: unify external diff and funcname parsing code
+ t4012: use test_cmp instead of cmp
A general cleanup on how diff drivers are implemented. Its still
missing documentation updates and tests but doesn't break anything
current as far as I can tell.
----------------------------------------------------------------
[Stalled]
* 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
Needs review.
* bd/blame (Thu Aug 21 18:22:01 2008 -0500) 5 commits
- Use xdiff caching to improve git blame performance
- Allow xdiff machinery to cache hash results for a file
- Always initialize xpparam_t to 0
- Bypass textual patch generation and parsing in git blame
- Allow alternate "low-level" emit function from xdl_diff
Réne had good comments on how the callback should be structured.
Waiting for a reroll.
* jn/gitweb-customlinks (Sun Oct 12 00:02:32 2008 +0200) 1 commit
- gitweb: Better processing format string in custom links in navbar
Waiting for some sort of response from Pasky.
* jc/gitweb-fix-cloud-tag (Tue Oct 14 21:27:12 2008 -0700) 1 commit
+ Fix reading of cloud tags
Request-for-review-and-ack sent; waiting for response.
----------------------------------------------------------------
[Actively Cooking]
* np/index-pack (Wed Oct 22 20:59:22 2008 -0400) 4 commits
- improve index-pack tests
+ fix multiple issues in index-pack
+ index-pack: smarter memory usage during delta resolution
+ index-pack: rationalize delta resolution code
The buglets that caused people on 'next' some surprises are quickly
killed. Thanks.
* sh/rebase-i-p (Wed Oct 22 11:59:30 2008 -0700) 9 commits
+ git-rebase--interactive.sh: comparision with == is bashism
+ rebase-i-p: minimum fix to obvious issues
+ rebase-i-p: if todo was reordered use HEAD as the rewritten parent
+ rebase-i-p: do not include non-first-parent commits touching
UPSTREAM
+ rebase-i-p: only list commits that require rewriting in todo
+ rebase-i-p: fix 'no squashing merges' tripping up non-merges
+ rebase-i-p: delay saving current-commit to REWRITTEN if squashing
+ rebase-i-p: use HEAD for updating the ref instead of mapping
OLDHEAD
+ rebase-i-p: test to exclude commits from todo based on its parents
Changes the `rebase -i -p` behavior to behave like git sequencer's
rewrite of `rebase -i` would behave.
----------------------------------------------------------------
[On Hold]
* jc/post-simplify (Fri Aug 15 01:34:51 2008 -0700) 2 commits
- revision --simplify-merges: incremental simplification
- revision --simplify-merges: prepare for incremental simplification
I started making this incremental but the progress is not
so great.
* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
- "git push": tellme-more protocol extension
This seems to have a deadlock during communication between the peers.
Someone needs to pick up this topic and resolve the deadlock before it can
continue.
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
- blame: show "previous" information in --porcelain/--incremental
format
- git-blame: refactor code to emit "porcelain format" output
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
- diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
This would be the right thing to do for command line use,
but gitk will be hit due to tcl/tk's limitation, so I am holding
this back for now.
^ permalink raw reply
* Re: [PATCH] Implement git remote mv
From: Jeff King @ 2008-10-23 3:52 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Brandon Casey, Junio C Hamano, git
In-Reply-To: <1224724704-12700-1-git-send-email-vmiklos@frugalware.org>
On Thu, Oct 23, 2008 at 03:18:24AM +0200, Miklos Vajna wrote:
> The new rename subcommand does the followings:
>
> 1) Renames the remote.foo configuration section to remote.bar
>
> 2) Updates the remote.bar.fetch refspecs
>
> 3) Updates the branch.*.remote settings
>
> 4) Renames the tracking branches.
I can't help but notice that the word "rename" appears all over the
commit description and in the code, but not in the user interface. Maybe
"rename" would be a better name for the command instead of (or in
addition to) "mv"?
-Peff
^ permalink raw reply
* Re: [PATCH] Fixed git archive for bare repos
From: Deskin Miller @ 2008-10-23 1:37 UTC (permalink / raw)
To: Charles Bailey; +Cc: git, kenneth johansson, gitster
In-Reply-To: <1224712023-5280-1-git-send-email-charles@hashpling.org>
On Wed, Oct 22, 2008 at 10:47:03PM +0100, Charles Bailey wrote:
> OK, I've had a chance to have a quick look at this issue and I have an
> altenative patch.
Thanks for making this much simpler than my version was; it passes the testcase
I wrote, as well as the rest of the testsuite, so if you want to include my
testcase (or an equivalent one) and re-send, consider it
Tested-by: Deskin Miller <deskinm@umich.edu>
^ permalink raw reply
* [RFC] Zit: the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-23 1:29 UTC (permalink / raw)
To: git
Hello all,
one of the common remarks done about git is that since it tracks
tree contents, it's not the best-suited tool to track a bunch of
independent files which happen to be in the same directory.
I've found myself in the situation of wanting to track my changes done
to one or more 'single' files in a directory (e.g. $HOME), and
deciding to use antiquate, clumsy, slow and inefficient but file-based
RCS (yes, you read that right) over git.
In other situations (e.g. for my UserJS folder) I ended up using git,
but not liking the idea of having things such as tags referring to all
of my UserJS projects instead of the single file they were inteded
for, or having to put 'filename: ' at the beginning of commit messages
just because the history was shared.
So today I decided to start hacking at a git-based but file-oriented
content tracker, which I decided to name Zit.
The principle is extremely simple: when you choose to start tracking a
file with Zit,
zit track file
Zit will create a directory .zit.file to hold a git repository
tracking the single file .zit.file/file, which is just a hard link to
file.
The reason for using .zit.file as a non-bare repository rather than
just a GIT_DIR is that it allows things such as 'git status' to ignore
everything else. A possible alternative could have been to use
.zit.file as the GIT_DIR and create an all-encopassing
.zit.file/info/exclude, but the general idea of having this kind of
detached GIT_DIR felt less robust (or maybe I just forgot some
export).
I also don't like the idea of the hardlink, first of all because of
portability problems, and secondly because of the way too many
possibility that the hardlink broke somewhere along the way. For
example, I haven't tested any fancy git commands on my sample zit
implementation, and I'm not sure checking out some older version would
actually work.
If anybody is intered in trying out my quick hack for the idea,
there's a git repository for Zit at git://git.oblomov.eu/zit --beware
that nothing past the most elementary uses (i.e. diff, status, log,
commit) has been tested yet. Many commands are bound to fail due to
the braindead way commands are delegated to git.
Suggestions on the best way to approach the many limits of the
implementation are more than welcome.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Tip: avoiding net overhead using git over sshfs
From: Felipe Carvalho Oliveira @ 2008-10-23 1:26 UTC (permalink / raw)
To: git
Use git over sshfs is not so good, but is an option for people that
don't have shell acess to the server/hosting like me.
# mounting
sshfs -o workaround=rename <user>@<host>:/home/<user>/ <mount_point>
cd <the_directory_of_your_project>
# we will move the .git directory to the local filesystem
mv .git ~/.my_project_git
# and create a symlink to the local .git
ln -s ~/.my_project_git .git
Done!
Now you can open gitk instantly ;-) and don't need to have the entire
.git thing on a remote filesystem.
Felipe (from Brazil, my english skills aren't so good :-)
^ permalink raw reply
* [PATCH] Implement git remote mv
From: Miklos Vajna @ 2008-10-23 1:18 UTC (permalink / raw)
To: Brandon Casey; +Cc: Junio C Hamano, git
In-Reply-To: <JQScKsOjmj-C7kmMPApAxZ3UDmaTZ1j0HkObQuCveJ9n4G-4o6Zxbw@cipher.nrlssc.navy.mil>
The new rename subcommand does the followings:
1) Renames the remote.foo configuration section to remote.bar
2) Updates the remote.bar.fetch refspecs
3) Updates the branch.*.remote settings
4) Renames the tracking branches.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Wed, Oct 22, 2008 at 11:52:54AM -0500, Brandon Casey <casey@nrlssc.navy.mil> wrote:
> > + struct rename_info rename = { argv[1], argv[2], &remote_branches
> > };
>
> I think some non-c99 compilers would have issues with this run-time
> initialization from function arguments. Plus, what if argv doesn't
> have
> 3 elements? I see you have a check for that below...
Hm true. Here is a corrected version.
Documentation/git-remote.txt | 6 ++
builtin-remote.c | 106 ++++++++++++++++++++++++++++++++++++++++++
t/t5505-remote.sh | 14 ++++++
3 files changed, 126 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index bb99810..4b5542a 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -11,6 +11,7 @@ SYNOPSIS
[verse]
'git remote' [-v | --verbose]
'git remote add' [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>
+'git remote mv' <old> <new>
'git remote rm' <name>
'git remote show' [-n] <name>
'git remote prune' [-n | --dry-run] <name>
@@ -61,6 +62,11 @@ only makes sense in bare repositories. If a remote uses mirror
mode, furthermore, `git push` will always behave as if `\--mirror`
was passed.
+'mv'::
+
+Rename the remote named <old> to <new>. All remote tracking branches and
+configuration settings for the remote are updated.
+
'rm'::
Remove the remote named <name>. All remote tracking branches and
diff --git a/builtin-remote.c b/builtin-remote.c
index 6b3325d..8a54bca 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -10,6 +10,7 @@
static const char * const builtin_remote_usage[] = {
"git remote",
"git remote add <name> <url>",
+ "git remote mv <old> <new>",
"git remote rm <name>",
"git remote show <name>",
"git remote prune <name>",
@@ -329,6 +330,109 @@ static int add_branch_for_removal(const char *refname,
return 0;
}
+struct rename_info {
+ const char *old;
+ const char *new;
+ struct string_list *remote_branches;
+};
+
+static int read_remote_branches(const char *refname,
+ const unsigned char *sha1, int flags, void *cb_data)
+{
+ struct rename_info *rename = cb_data;
+ struct strbuf buf = STRBUF_INIT;
+
+ strbuf_addf(&buf, "refs/remotes/%s", rename->old);
+ if(!prefixcmp(refname, buf.buf))
+ string_list_append(xstrdup(refname), rename->remote_branches);
+
+ return 0;
+}
+
+static int mv(int argc, const char **argv)
+{
+ struct option options[] = {
+ OPT_END()
+ };
+ struct remote *oldremote, *newremote;
+ struct strbuf buf = STRBUF_INIT, buf2 = STRBUF_INIT;
+ struct string_list remote_branches = { NULL, 0, 0, 0 };
+ struct rename_info rename;
+ int i;
+
+ if (argc != 3)
+ usage_with_options(builtin_remote_usage, options);
+
+ rename.old = argv[1];
+ rename.new = argv[2];
+ rename.remote_branches = &remote_branches;
+
+ oldremote = remote_get(rename.old);
+ if (!oldremote)
+ die("No such remote: %s", rename.old);
+
+ newremote = remote_get(rename.new);
+ if (newremote && (newremote->url_nr > 1 || newremote->fetch_refspec_nr))
+ die("remote %s already exists.", rename.new);
+
+ strbuf_addf(&buf, "refs/heads/test:refs/remotes/%s/test", rename.new);
+ if (!valid_fetch_refspec(buf.buf))
+ die("'%s' is not a valid remote name", rename.new);
+
+ strbuf_reset(&buf);
+ strbuf_addf(&buf, "remote.%s", rename.old);
+ strbuf_addf(&buf2, "remote.%s", rename.new);
+ if (git_config_rename_section(buf.buf, buf2.buf) < 1)
+ return error("Could not rename config section '%s' to '%s'",
+ buf.buf, buf2.buf);
+
+ strbuf_reset(&buf);
+ strbuf_addf(&buf, "remote.%s.fetch", rename.new);
+ if (git_config_set_multivar(buf.buf, NULL, NULL, 1))
+ return error("Could not remove config section '%s'", buf.buf);
+ for (i = 0; i < oldremote->fetch_refspec_nr; i++) {
+ char *ptr;
+
+ strbuf_reset(&buf2);
+ strbuf_addstr(&buf2, oldremote->fetch_refspec[i]);
+ ptr = strstr(buf2.buf, rename.old);
+ if (ptr)
+ strbuf_splice(&buf2, ptr-buf2.buf, strlen(rename.old),
+ rename.new, strlen(rename.new));
+ if (git_config_set_multivar(buf.buf, buf2.buf, "^$", 0))
+ return error("Could not append '%s'", buf.buf);
+ }
+
+ read_branches();
+ for (i = 0; i < branch_list.nr; i++) {
+ struct string_list_item *item = branch_list.items + i;
+ struct branch_info *info = item->util;
+ if (info->remote && !strcmp(info->remote, rename.old)) {
+ strbuf_reset(&buf);
+ strbuf_addf(&buf, "branch.%s.remote", item->string);
+ if (git_config_set(buf.buf, rename.new)) {
+ return error("Could not set '%s'", buf.buf);
+ }
+ }
+ }
+
+ for_each_ref(read_remote_branches, &rename);
+ for (i = 0; i < remote_branches.nr; i++) {
+ struct string_list_item *item = remote_branches.items + i;
+ strbuf_reset(&buf);
+ strbuf_addstr(&buf, item->string);
+ strbuf_splice(&buf, strlen("refs/remotes/"), strlen(rename.old),
+ rename.new, strlen(rename.new));
+ strbuf_reset(&buf2);
+ strbuf_addf(&buf2, "remote: renamed %s to %s",
+ item->string, buf.buf);
+ if (rename_ref(item->string, buf.buf, buf2.buf))
+ die("renaming '%s' failed", item->string);
+ }
+
+ return 0;
+}
+
static int remove_branches(struct string_list *branches)
{
int i, result = 0;
@@ -696,6 +800,8 @@ int cmd_remote(int argc, const char **argv, const char *prefix)
result = show_all();
else if (!strcmp(argv[0], "add"))
result = add(argc, argv);
+ else if (!strcmp(argv[0], "mv"))
+ result = mv(argc, argv);
else if (!strcmp(argv[0], "rm"))
result = rm(argc, argv);
else if (!strcmp(argv[0], "show"))
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index c449663..9b11fd3 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -324,4 +324,18 @@ test_expect_success 'reject adding remote with an invalid name' '
'
+# The first three tests if the config is properly updated, the last one
+# checks if the branches are renamed.
+
+test_expect_success 'rename a remote' '
+
+ git clone one four &&
+ (cd four &&
+ git remote mv origin upstream &&
+ git remote show |grep -q upstream &&
+ git config remote.upstream.fetch |grep -q upstream &&
+ test $(git config branch.master.remote) = "upstream" &&
+ git for-each-ref|grep -q refs/remotes/upstream)
+
+'
test_done
--
1.6.0.2
^ permalink raw reply related
* Re: how to configure Git to treat certain type of ascii files as binary files
From: Weiwei Shu @ 2008-10-23 1:12 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3hc74i73a.fsf@localhost.localdomain>
Thanks Jakub. I'll read its manual and try to play with it. Thank all
for replies!
On Wed, Oct 22, 2008 at 5:40 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> "Weiwei Shu" <shuww1980@gmail.com> writes:
>
>> My first post in this mailing list. Could some one direct me to some
>> document/manual pages to setup Git to treat ascii files as binary
>> files? I'm using Git to do circuit schematics (SPICE files)
>> versioning. I will not do any merging or editing stuff with external
>> editors. The only way to change it is to use schematic capture GUIs
>> (Cadence, ADS, etc). So I'd like to treat them as binary files to
>> reduce the possibilities of messing them up.
>>
>> I know it seems a little bit stupid to use Git to do such an easy job.
>> But hey, it's the most eye-catching SCM software, isn't it?
>
> First, git does not modify files unless you have core.crlf set,
> and even then it warns about irreversible transformations
> (core.safecrlf)
>
> Second, using gitattributes you can set diff driver and merge driver;
> one of possibilities is to treat file as binary (binary diff and no
> using 3-way file merge).
>
> --
> Jakub Narebski
> Poland
> ShadeHawk on #git
>
--
Weiwei
--Hope Springs Eternal.
^ permalink raw reply
* Re: [RFC PATCH 4/5] pack-objects: avoid reading uninitalized data
From: Nicolas Pitre @ 2008-10-23 1:11 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081022203103.GD4547@coredump.intra.peff.net>
On Wed, 22 Oct 2008, Jeff King wrote:
> In the main loop of find_deltas, we do:
>
> struct object_entry *entry = *list++;
> ...
> if (!*list_size)
> ...
> break
>
> Because we look at and increment *list _before_ the check of
> list_size, in the very last iteration of the loop we will
> look at uninitialized data, and increment the pointer beyond
> one past the end of the allocated space. Since we don't
> actually do anything with the data until after the check,
> this is not a problem in practice.
>
> But since it technically violates the C standard, and
> because it provokes a spurious valgrind warning, let's just
> move the initialization of entry to a safe place.
>
> This fixes valgrind errors in t5300, t5301, t5302, t303, and
> t9400.
>
> Signed-off-by: Jeff King <peff@peff.net>
OK. Minor nit...
> ---
> builtin-pack-objects.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
> index 59c30d1..15b80db 100644
> --- a/builtin-pack-objects.c
> +++ b/builtin-pack-objects.c
> @@ -1375,7 +1375,7 @@ static void find_deltas(struct object_entry **list, unsigned *list_size,
> array = xcalloc(window, sizeof(struct unpacked));
>
> for (;;) {
> - struct object_entry *entry = *list++;
> + struct object_entry *entry;
> struct unpacked *n = array + idx;
> int j, max_depth, best_base = -1;
>
> @@ -1384,6 +1384,7 @@ static void find_deltas(struct object_entry **list, unsigned *list_size,
> progress_unlock();
> break;
> }
---> Please preserve the empty line here so the previous code
chunk still appears logically separate.
> + entry = *list++;
> (*list_size)--;
> if (!entry->preferred_base) {
> (*processed)++;
Nicolas
^ permalink raw reply
* [PATCH] improve index-pack tests
From: Nicolas Pitre @ 2008-10-23 0:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Commit 9441b61dc5 introduced serious bugs in index-pack which are
described and fixed by commit ce3f6dc655. However, despite the
boldness of those bugs, the test suite still passed.
This improves t5302-pack-index.sh so to ensure a much better code
path coverage. With commit ce3f6dc655 reverted, 17 of the 26 tests
do fail now.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/t/t5302-pack-index.sh b/t/t5302-pack-index.sh
index 344ab25..b0b0fda 100755
--- a/t/t5302-pack-index.sh
+++ b/t/t5302-pack-index.sh
@@ -11,13 +11,18 @@ test_expect_success \
'rm -rf .git
git init &&
i=1 &&
- while test $i -le 100
+ while test $i -le 100
do
- i=`printf '%03i' $i`
- echo $i >file_$i &&
- test-genrandom "$i" 8192 >>file_$i &&
- git update-index --add file_$i &&
- i=`expr $i + 1` || return 1
+ iii=`printf '%03i' $i`
+ test-genrandom "bar" 200 > wide_delta_$iii &&
+ test-genrandom "baz $iii" 50 >> wide_delta_$iii &&
+ test-genrandom "foo"$i 100 > deep_delta_$iii &&
+ test-genrandom "foo"`expr $i + 1` 100 >> deep_delta_$iii &&
+ test-genrandom "foo"`expr $i + 2` 100 >> deep_delta_$iii &&
+ echo $iii >file_$iii &&
+ test-genrandom "$iii" 8192 >>file_$iii &&
+ git update-index --add file_$iii deep_delta_$iii wide_delta_$iii &&
+ i=`expr $i + 1` || return 1
done &&
{ echo 101 && test-genrandom 100 8192; } >file_101 &&
git update-index --add file_101 &&
@@ -92,6 +97,31 @@ test_expect_success \
'64-bit offsets: index-pack result should match pack-objects one' \
'cmp "test-3-${pack3}.idx" "3.idx"'
+# returns the object number for given object in given pack index
+index_obj_nr()
+{
+ idx_file=$1
+ object_sha1=$2
+ nr=0
+ git show-index < $idx_file |
+ while read offs sha1 extra
+ do
+ nr=$(($nr + 1))
+ test "$sha1" = "$object_sha1" || continue
+ echo "$(($nr - 1))"
+ break
+ done
+}
+
+# returns the pack offset for given object as found in given pack index
+index_obj_offset()
+{
+ idx_file=$1
+ object_sha1=$2
+ git show-index < $idx_file | grep $object_sha1 |
+ ( read offs extra && echo "$offs" )
+}
+
test_expect_success \
'[index v1] 1) stream pack to repository' \
'git index-pack --index-version=1 --stdin < "test-1-${pack1}.pack" &&
@@ -102,19 +132,22 @@ test_expect_success \
test_expect_success \
'[index v1] 2) create a stealth corruption in a delta base reference' \
- '# this test assumes a delta smaller than 16 bytes at the end of the pack
- git show-index <1.idx | sort -n | sed -ne \$p | (
- read delta_offs delta_sha1 &&
- git cat-file blob "$delta_sha1" > blob_1 &&
- chmod +w ".git/objects/pack/pack-${pack1}.pack" &&
- dd of=".git/objects/pack/pack-${pack1}.pack" seek=$(($delta_offs + 1)) \
- if=".git/objects/pack/pack-${pack1}.idx" skip=$((256 * 4 + 4)) \
- bs=1 count=20 conv=notrunc &&
- git cat-file blob "$delta_sha1" > blob_2 )'
+ '# This test assumes file_101 is a delta smaller than 16 bytes.
+ # It should be against file_100 but we substitute its base for file_099
+ sha1_101=`git hash-object file_101` &&
+ sha1_099=`git hash-object file_099` &&
+ offs_101=`index_obj_offset 1.idx $sha1_101` &&
+ nr_099=`index_obj_nr 1.idx $sha1_099` &&
+ chmod +w ".git/objects/pack/pack-${pack1}.pack" &&
+ dd of=".git/objects/pack/pack-${pack1}.pack" seek=$(($offs_101 + 1)) \
+ if=".git/objects/pack/pack-${pack1}.idx" \
+ skip=$((4 + 256 * 4 + $nr_099 * 24)) \
+ bs=1 count=20 conv=notrunc &&
+ git cat-file blob $sha1_101 > file_101_foo1'
test_expect_success \
'[index v1] 3) corrupted delta happily returned wrong data' \
- '! cmp blob_1 blob_2'
+ 'test -f file_101_foo1 && ! cmp file_101 file_101_foo1'
test_expect_success \
'[index v1] 4) confirm that the pack is actually corrupted' \
@@ -140,19 +173,22 @@ test_expect_success \
test_expect_success \
'[index v2] 2) create a stealth corruption in a delta base reference' \
- '# this test assumes a delta smaller than 16 bytes at the end of the pack
- git show-index <1.idx | sort -n | sed -ne \$p | (
- read delta_offs delta_sha1 delta_crc &&
- git cat-file blob "$delta_sha1" > blob_3 &&
- chmod +w ".git/objects/pack/pack-${pack1}.pack" &&
- dd of=".git/objects/pack/pack-${pack1}.pack" seek=$(($delta_offs + 1)) \
- if=".git/objects/pack/pack-${pack1}.idx" skip=$((8 + 256 * 4)) \
- bs=1 count=20 conv=notrunc &&
- git cat-file blob "$delta_sha1" > blob_4 )'
+ '# This test assumes file_101 is a delta smaller than 16 bytes.
+ # It should be against file_100 but we substitute its base for file_099
+ sha1_101=`git hash-object file_101` &&
+ sha1_099=`git hash-object file_099` &&
+ offs_101=`index_obj_offset 1.idx $sha1_101` &&
+ nr_099=`index_obj_nr 1.idx $sha1_099` &&
+ chmod +w ".git/objects/pack/pack-${pack1}.pack" &&
+ dd of=".git/objects/pack/pack-${pack1}.pack" seek=$(($offs_101 + 1)) \
+ if=".git/objects/pack/pack-${pack1}.idx" \
+ skip=$((8 + 256 * 4 + $nr_099 * 20)) \
+ bs=1 count=20 conv=notrunc &&
+ git cat-file blob $sha1_101 > file_101_foo2'
test_expect_success \
'[index v2] 3) corrupted delta happily returned wrong data' \
- '! cmp blob_3 blob_4'
+ 'test -f file_101_foo2 && ! cmp file_101 file_101_foo2'
test_expect_success \
'[index v2] 4) confirm that the pack is actually corrupted' \
@@ -167,9 +203,11 @@ test_expect_success \
'rm -f .git/objects/pack/* &&
git index-pack --index-version=2 --stdin < "test-1-${pack1}.pack" &&
git verify-pack ".git/objects/pack/pack-${pack1}.pack" &&
+ obj=`git hash-object file_001` &&
+ nr=`index_obj_nr ".git/objects/pack/pack-${pack1}.idx" $obj` &&
chmod +w ".git/objects/pack/pack-${pack1}.idx" &&
dd if=/dev/zero of=".git/objects/pack/pack-${pack1}.idx" conv=notrunc \
- bs=1 count=4 seek=$((8 + 256 * 4 + `wc -l <obj-list` * 20 + 0)) &&
+ bs=1 count=4 seek=$((8 + 256 * 4 + `wc -l <obj-list` * 20 + $nr * 4)) &&
( while read obj
do git cat-file -p $obj >/dev/null || exit 1
done <obj-list ) &&
^ permalink raw reply related
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