* [PATCH] nice ftplugin for vim, that shows the commited diff in a split'ed buffer.
From: Pierre Habouzit @ 2006-10-17 0:31 UTC (permalink / raw)
To: git; +Cc: Pierre Habouzit
In-Reply-To: <11610450702261-git-send-email-madcoder@debian.org>
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
contrib/vim/README | 6 ++++
contrib/vim/ftplugin/gitcommit.vim | 61 ++++++++++++++++++++++++++++++++++++
2 files changed, 67 insertions(+), 0 deletions(-)
diff --git a/contrib/vim/README b/contrib/vim/README
index 9e7881f..26c1682 100644
--- a/contrib/vim/README
+++ b/contrib/vim/README
@@ -6,3 +6,9 @@ To syntax highlight git's commit message
$ cat >>$HOME/.vimrc <<'EOF'
autocmd BufNewFile,BufRead COMMIT_EDITMSG set filetype=gitcommit
EOF
+
+To use the fancy split-view with the currently commited diff, you need to:
+ 1. Copy ftplugin/gitcommit.vim to vim's ftplugin directory:
+ $ mkdir -p $HOME/.vim/ftplugin
+ $ cp ftplugin/gitcommit.vim $HOME/.vim/ftplugin
+ 2. Auto-detect the editing of git commit files (see above).
diff --git a/contrib/vim/ftplugin/gitcommit.vim b/contrib/vim/ftplugin/gitcommit.vim
new file mode 100644
index 0000000..f9efd59
--- /dev/null
+++ b/contrib/vim/ftplugin/gitcommit.vim
@@ -0,0 +1,61 @@
+if exists("b:did_ftplugin")
+ finish
+endif
+
+let b:did_ftplugin = 1
+
+setlocal tw=74
+setlocal nowarn nowb
+
+"{{{ function Git_diff_windows
+
+function! Git_diff_windows()
+ let i = 0
+ let list_of_files = ''
+
+ " drop everything until '# (will commit)' and the next empty line
+ while i <= line('$')
+ let line = getline(i)
+ if line =~ '^#\s*(will commit)$'
+ let i = i + 2
+ break
+ endif
+
+ let i = i + 1
+ endwhile
+
+ " read file names until we have EOF or an empty line
+ while i <= line('$')
+ let line = getline(i)
+ if line =~ '^#\s*[a-z ]*:.*->.*$'
+ let file = substitute(line, '\v^#[^:]*:.*->\s*(.*)\s*$', '\1', '')
+ let list_of_files = list_of_files . ' '.file
+ let file = substitute(line, '\v^#[^:]*:\s*(.*)\s*->.*$', '\1', '')
+ let list_of_files = list_of_files . ' '.file
+ elseif line =~ '^#\s*[a-z ]*:'
+ let file = substitute(line, '\v^#[^:]*:\s*(.*)\s*$', '\1', '')
+ let list_of_files = list_of_files . ' '.file
+ elseif line =~ '^#\s*$'
+ break
+ endif
+
+ let i = i + 1
+ endwhile
+
+ if list_of_files == ""
+ return
+ endif
+
+ rightbelow vnew
+ silent! setlocal ft=diff previewwindow bufhidden=delete nobackup noswf nobuflisted nowrap buftype=nofile
+ exe 'normal :r!LANG=C cd ..; git diff HEAD -- ' . list_of_files . "\n1Gdd"
+ exe 'normal :r!LANG=C cd ..; git diff HEAD -- ' . list_of_files . " \| git apply --stat\no\<esc>1GddO\<esc>"
+ setlocal nomodifiable
+ redraw!
+ wincmd p
+ redraw!
+endfunction
+
+"}}}
+
+call Git_diff_windows()
--
1.4.2.3
^ permalink raw reply related
* Re: VCS comparison table
From: Johannes Schindelin @ 2006-10-17 0:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0610161714590.3962@g5.osdl.org>
Hi,
On Mon, 16 Oct 2006, Linus Torvalds wrote:
> On Tue, 17 Oct 2006, Johannes Schindelin wrote:
>
> > (How about making git-cat be a short cuut to "git -p cat-file -p"?)
>
> Well, you can just add
>
> [alias]
> cat=-p cat-file -p
>
> to your ~/.gitconfig file, and you're there.
Ha! I have that for a long time! Although I named it "s", since "git s
todo:TODO" is two letters shorter...
Ciao,
Dscho
P.S.: BTW a certain person complained about ~/.gitconfig not being
documented, but evidently the itch was not big enough for that person to
document it himself...
^ permalink raw reply
* Re: On blame/pickaxe
From: Petr Baudis @ 2006-10-17 0:44 UTC (permalink / raw)
To: Andy Whitcroft
Cc: Josef Weidendorfer, Junio C Hamano, Luben Tuikov, git,
Linus Torvalds
In-Reply-To: <453393E5.3020203@shadowen.org>
Dear diary, on Mon, Oct 16, 2006 at 04:15:01PM CEST, I got a letter
where Andy Whitcroft <apw@shadowen.org> said that...
> Josef Weidendorfer wrote:
> > Hi,
> >
> > this blame-passing thing really looks very promising and powerful.
> >
> > On Monday 16 October 2006 08:43, you wrote:
> >> If the user is not prepared to see code movement, pickaxe can be
> >> run without -M nor -C to get the classic blame output.
Ok, so in this case -M and -C does not mean just looking for
copies/movements in other files but inside the same file as well.
Perhaps we might want to differentiate those two cases since searching
in all files might be significantly slower.
> > Another blame-passing heuristic would be very interesting for code:
> > "Ignore white-space changes".
> > This way, commits which only do some reindentations simply are skipped.
> >
> > It looks like such a thing would just be a matter of passing "-b" to
> > executions of "diff" in the blame-passing algorithm.
>
> I am thinking that that is probabally going to need to be optional, for
> example python the indentation is everything to the meaning of the code.
(OTOH, just today I was retrieving some code from deep inside a script
to a common function, which of course caused massive indentation shift.
So it is very desirable in order to catch these. But more we get
involved in this, the more we will probably want to know about the
syntax of the content we are digging in.)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: Feature: add --force option to cg-push.
From: Petr Baudis @ 2006-10-17 0:55 UTC (permalink / raw)
To: Pierre Marc Dumuid; +Cc: git
In-Reply-To: <452E437D.3070708@adelaide.edu.au>
Dear diary, on Thu, Oct 12, 2006 at 03:30:37PM CEST, I got a letter
where Pierre Marc Dumuid <pierre.dumuid@adelaide.edu.au> said that...
> If I cg-push on a remote branch after changing my mind about how I
> wanted the branch ordered, it will complain and say "maybee you need to
> update"
>
> I didn't know what to do, since I was on the "no" side of maybee.
>
> Here is a patch that adds the --force option for those people.
Thanks, I've committed a similar but different patch (with better
description and handling local pushes as well). Please sign off your
patches in the future.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: VCS comparison table
From: Nguyen Thai Ngoc Duy @ 2006-10-17 1:17 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0610161714590.3962@g5.osdl.org>
On 10/17/06, Linus Torvalds <torvalds@osdl.org> wrote:
> So then you can do just
>
> git cat todo:TODO
>
> and you're done.
>
> [ So for the non-git people, what that will actually _do_ is to show the
> TODO file in the "todo" branch - regardless of whether it is checked out
> or not, and start a pager for you. ]
>
> I actually do this sometimes, but I've never done it for branches (and I
> do it seldom enough that I haven't added the alias). I do it for things
> like
>
> git cat v2.6.16:Makefile
>
> to see what a file looked like in a certain tagged release.
This very useful syntax (<ent>:<path>) didn't get documented
"officially" anywhere. It was actually documented in commit log
v1.4.1^0~255^2. Maybe someone should copy and paste it to git
documentation? Maybe core-tutorial.txt or git-rev-parse.txt, is there
any better place?
--
Duy
^ permalink raw reply
* Re: VCS comparison table
From: Petr Baudis @ 2006-10-17 2:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Aaron Bentley, Jakub Narebski, bazaar-ng, git
In-Reply-To: <Pine.LNX.4.63.0610170128350.14200@wbgn013.biozentrum.uni-wuerzburg.de>
Hi!
Dear diary, on Tue, Oct 17, 2006 at 01:45:34AM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> On Mon, 16 Oct 2006, Aaron Bentley wrote:
> > As the author of two different Arch front-ends, I can say I haven't
> > found that approach satisfactory. Invoking multiple commands tends
> > re-invoke the same validation routines over and over, killing
> > efficiency, and diagnostics tend to be pretty poorly integrated.
>
> Welcome to git! Git's commands are very efficient, and you can even pipe
> them efficiently! And now that we have GIT_TRACE, diagnostics are no
> concern.
I think Aaron rather meant that in case of an error, the error messages
may seem incoherent from the perspective of a porcelain user if it's
been generated by the plumbing. And I had that problem in Cogito as well
few times in the past, but I think most of those are reasonable now (I
can't think of a counter-example off the top of my head).
Calling multiple git commands _is_ a problem, especially in a loop, but
I think it's more the inherent fork()+execve() overhead than whatever
happens over and over when main() takes over. Many git commands got
adjusted so that you can call them just once and then feed from/to them
over longer time period.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: VCS comparison table
From: Sam Vilain @ 2006-10-17 3:52 UTC (permalink / raw)
To: Jon Smirl; +Cc: Petr Baudis, Jakub Narebski, git
In-Reply-To: <9e4733910610152030q45dbeb31l9eb0eb06bd6fd159@mail.gmail.com>
Jon Smirl wrote:
> cvsps works ok on small amounts of data, but it can't handle the full
> Mozilla repo. The current idea is to convert the full repo with
> cvs2git and build the ini file needed by cvsps to support incremental
> imports. After that use cvsps.
>
Looking through the client.mk used to check out the sub-portions of the
CVS repository, I have to ask;
Why are you trying to import this big collection of projects into a
single git repository?
View git's repositories not as a container for an entire community's
code base, but more as object partitions. Currently you are quite happy
to use per-file version control partitions inherent to CVS. Now you are
looking at removing all of the partitions completely and hoping to end
up with something managable. That it has been possible at all to fit it
into the space less than the size of a CD is staggering, but surely a
piecemeal approach would be a pragmatic solution to this problem.
Sam.
^ permalink raw reply
* Re: [PATCH 1/2] Delete ref $frotz by moving ref file to "deleted-$frotz~ref".
From: Christian Couder @ 2006-10-17 4:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6xa91kj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
> > The idea is that moving:
> >
> > $GIT_DIR/refs/<refpath>/frotz
> >
> > to:
> >
> > $GIT_DIR/deleted-refs/<refpath>/frotz~ref
> >
> > maybe cheaper and safer than repacking the refs without the
> > deleted one.
>
> Before actually implementing delete_ref(), we discussed this
> "deleted-refs/" idea. but I do not think it is a direction we
> would want to go.
>
> Ref deletion is an operation that happens far far rarer than
> updates and lookups, and I deliberately chose to optimize for
> the latter.
I think that the ref deletion usage depends on the policy of people using
git, and there may be people that delete a ref very often.
For example, when git becomes a major SCM, there may be people working on
big projects that want to create a new branch for each new bug and then
delete the branch when the code on the bug branch has been integrated into
a new release and the bug is closed.
> There are valid reasons to delete refs, and one most frequent
> one would be to discard throw-away temporary branches you may
> have needed to switch to when your work was interrupted. But
> even counting that kind of deletion, I imagine that you would
> not be creating and removing more than one branch per every 10
> commits you would create, and I also imagine you would be
> invoking not less than 5 operations that inspect project
> history, such as git-log and git-diff, between commits you make.
The operations that inspect project history may use a ref cache or something
so that a lookup on the disk may not be needed. So only the ref creation or
update rate versus delete rate may matter.
> An operation to build a new commit itself needs at least two
> lookups (one to see what's current upfront, and another to see
> nobody touched it upon lockless update). Most history-related
> operations at least need to look at one (typically, HEAD), and
> any refname you use to spell the name of an object or revision
> range (e.g. "v2.6.17..v2.6.18~10" needs to look at tags/v2.6.17
> and tags/v2.6.18). Optimizing for deletion path at the expense
> of giving even a tiny penalty to lookup path is optimizing for a
> wrong case, and that is why I rejected deleted-refs/ idea when I
> originally did the delete_ref() implementation.
The lookup code is already using cached packed refs. It could also use
cached loose and deleted refs, so the lookup penalty would be very very
small. By the way, the OS may already cache loose and deleted ref file stat
information, so that may right now be a very small penalty.
And at least, algorythmically speaking, with my patch the deletion path is
now independent of the number of existing refs, so it's much better (while
the lookup path stay the same).
If there are thousand of refs and a heavy I/O load, rewritting the packed
ref file for each deletion means writing on disk something that may not fit
in the disk cache. It may be very bad.
My patch also has a few added benefits like making it possible to have a
read only packed ref file, while still letting people delete refs. It also
make it possible to resurect a deleted ref, or to control branch deletion
rights on a per ref directory basis (though that may not be very usefull).
And the fact that the packed ref file (which may be read only for added
safety) is not rewritten each time a ref is deleted make things much safer
if there are many users working on the same git repository.
Christian.
^ permalink raw reply
* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-17 4:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jakub Narebski, bazaar-ng, git
In-Reply-To: <Pine.LNX.4.64.0610161625370.3962@g5.osdl.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Linus Torvalds wrote:
>
> On Mon, 16 Oct 2006, Aaron Bentley wrote:
>> Bazaar's namespace is "simple" because all branches can be named by a
>> URL, and all revisions can be named by a URL + a number.
> I pretty much _guarantee_ that a "number" is not a valid way to uniquely
> name a revision in a distributed environment, though. I bet the "number"
> really only names a revision in one _single_ repository, right?
Right. That's why I said all revisions can be named by a URL + a
number, because it's the combination of the URL + a number that is
unique. (In bzr, each branch has a URL.)
> In contrast, in git, a revision is a revision is a revision.
I agree that a revision is a revision, but I don't think that's a
property unique to git. :-)
> If you give
> the SHA1 name, it's well-defined even between different repositories, and
> you can tell somebody that "revision XYZ is when the problem started", and
> they'll know _exactly_ which revision it is, even if they don't have your
> particular repository.
When two people have copies of the same revision, it's usually because
they are each pulling from a common branch, and so the revision in that
branch can be named. Bazaar does use unique ids internally, but it's
extremely rare that the user needs to use them.
> Now _that_ is true simplicity. It does automatically mean that the names
> are a bit longer, but in this case, "longer" really _does_ mean "simpler".
>
> If you want a short, human-readable name, you _tag_ it. It takes all of a
> hundredth of a second to to or so.
But tags have local meaning only, unless someone has access to your
repository, right?
>>> About "checkouts", i.e. working directories with repository elsewhere:
>>> you can use GIT_DIR environmental variable or "git --git-dir" option,
>>> or symlinks, and if Nguyen Thai Ngoc D proposal to have .gitdir/.git
>>> "symref"-like file to point to repository passes, we can use that.
>> It sounds like the .gitdir/.git proposal would give Git "checkouts", by
>> our meaning of the term.
>
> Well, in the git world, it's really just one shared repository that has
> separate branch-namespaces, and separate working trees (aka "checkouts").
> So yes, it probably matches what bazaar would call a checkout.
The key thing about a checkout is that it's stored in a different
location from its repository. This provides a few benefits:
- - you can publish a repository without publishing its working tree,
possibly using standard mirroring tools like rsync.
- - you can have working trees on local systems while having the
repository on a remote system. This makes it easy to work on one
logical branch from multiple locations, without getting out of sync.
- - you can use a checkout to maintain a local mirror of a read-only
branch (I do this with http://bazaar-vcs.com/bzr/bzr.dev).
> Almost nobody seems to actually use it that way in git - it's mostly more
> efficient to just have five different branches in the same working tree,
> and switch between them. When you switch between branches in git, git only
> rewrites the part of your working tree that actually changed, so switching
> is extremely efficient even with a large repo.
You can operate that way in bzr too, but I find it nicer to have one
checkout for each active branch, plus a checkout of bzr.dev. Our switch
command also rewrites only the changed part of the working tree.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFNFrv0F+nu1YWqI0RAgBHAJ9XpmdvuCNDysxFhnyeCmkEG/z0ggCggMsJ
WyW6lqGMokh0k0It1KOdgtk=
=L1SR
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-17 4:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: bazaar-ng, git, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0610161704240.3962@g5.osdl.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Linus Torvalds wrote:
>
> On Tue, 17 Oct 2006, Jakub Narebski wrote:
>> Unless you have branch(es) with totally different contents, like git.git
>> 'todo' branch.
>
> Yes. I have to say, that's likely a fairly odd case, and I wouldn't be
> surprised if other VCS's don't support that mode of operation at _all_.
Bazaar also supports multiple unrelated branches in a repository, as
does CVS, SVN (depending how you squint), Arch, and probably Monotone.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFNFy90F+nu1YWqI0RAgMeAJ99OikxXspSg+efnN6j3ySoPuOovQCfaKA6
yPCRw5Kl/V+ThnU6fsPA8TQ=
=DYAN
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH 1/2] Delete ref $frotz by moving ref file to "deleted-$frotz~ref".
From: Junio C Hamano @ 2006-10-17 4:41 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <200610170626.25654.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> For example, when git becomes a major SCM, there may be people working on
> big projects that want to create a new branch for each new bug and then
> delete the branch when the code on the bug branch has been integrated into
> a new release and the bug is closed.
I would say that is a very valid way to work with git,
regardless of the size of project. Now, how often would you
create such a per-bug branch and delete one, compared to the
number of operations that would require ref lookups? Your
example actually supports what I've said -- optimizing for
deletion at the cost of more expensive lookups is wrong.
> The operations that inspect project history may use a ref cache or something
> so that a lookup on the disk may not be needed. So only the ref creation or
> update rate versus delete rate may matter.
Stop and think about what you are saying. What's a ref cache?
We do not have such a beast today (unless you equate it with
packed-refs file), and you would need to design and implement
it, but think about how you make that operate. You would need
to invalidate it when you delete a ref using the deleted-ref/
approach; that's not much different from repacking packed-refs
file without the ref you just deleted, no?
Of course you can argue that instead of repacking you always
stat deleted-ref/ hierarchy; in other words, you can argue that
you can make deletion path faster by penalizing the lookup path.
So I do not think using "ref cache" (whatever it is, and however
it operates) does not change the situation a bit.
> If there are thousand of refs and a heavy I/O load, rewritting the packed
> ref file for each deletion means writing on disk something that may not fit
> in the disk cache. It may be very bad.
If the goal is to optimize for deletion path, then that is
true. My point is that we do not want to optimize for deletion
path at the expense of more costly lookup path.
^ permalink raw reply
* heads-up: git-index-pack in "next" is broken
From: Junio C Hamano @ 2006-10-17 4:55 UTC (permalink / raw)
To: git; +Cc: Nicolas Pitre
I'm still a bit under the weather and do not have enough
concentration to dig into the problem tonight, but I noticed
that something in "next", most likely the delta-base-offset
patchset, broke git-index-pack:
$ X=ec0c3491753e115e1775256f6b7bd1bce4dea7cd
$ wget http://www.kernel.org/pub/scm/git/git.git/objects/pack/pack-$X.pack
$ ~/git-master/bin/git-index-pack pack-$X.pack
ec0c3491753e115e1775256f6b7bd1bce4dea7cd
$ git-index-pack pack-$X.pack
fatal: packfile 'pack-ec0c3491753e115e1775256f6b7bd1bce4dea7cd.pack' has unresolved deltas
^ permalink raw reply
* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-17 4:56 UTC (permalink / raw)
To: Jakub Narebski; +Cc: bazaar-ng, git
In-Reply-To: <200610170119.09066.jnareb@gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jakub Narebski wrote:
> Well, <ref>~<n> means <n>-th _parent_ of a given ref, which for branches
> (which constantly change) is a moving target.
Ah. Bazaar uses negative numbers to refer to <n>th parents, and
positive numbers to refer to the number of commits that have been made
since the branch was initialized.
> One cannot have universally valid revision numbers (even
> only per branch) in distributed development. Subversion can do that only
> because it is centralized SCM. Global numbering and distributed nature
> doesn't mix... hence contents based sha1 as commit identifiers.
Sure. Our UI approach is that unique identifiers can usefully be
abstracted away with a combination of URL + number, in the vast majority
of cases.
> But this doesn't matter much, because you can have really lightweight
> tags in git (especially now with packed refs support). So you can have
> the namespace you want.
The nice thing about revision numbers is that they're implicit-- no one
needs to take any action to update them, and so you can always use them.
> I wonder if any SCM other than git has easy way to "rebase" a branch,
> i.e. cut branch at branching point, and transplant it to the tip
> of other branch. For example you work on 'xx/topic' topic branch,
> and want to have changes in those branch but applied to current work,
> not to the version some time ago when you have started working on
> said feature.
If I understand correctly, in Bazaar, you'd just merge the current work
into 'xx/topic'.
> What your comparison matrick lacks for example is if given SCM
> saves information about branching point and merges, so you can
> get where two branches diverged, and when one branch was merged into
> another.
I'm not sure what you mean about divergence. For example, Bazaar
records the complete ancestry of each branch, and determining the point
of divergence is as simple as finding the last common ancestor. But are
you considering only the initial divergence? Or if the branches merge
and then diverge again, would you consider that the point of divergence?
merge-point tracking is a prerequisite for Smart Merge, which does
appear on our matrix.
> Plugins = API + detection ifrastructure + loading on demand.
> Git has API, has a kind of detection ifrastructure (for commands and
> merge strategies only), doesn't have loading on demand. You can
> easily provide new commands (thanks to git wrapper) and new merge
> strategies.
I'm not sure what you mean by API, unless you mean the commandline. If
that's what you mean, surely all unix commands are extensible in that
regard.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFNGKQ0F+nu1YWqI0RAsW+AJoDOsNRmBjo3raT43JL6qn7SuJNRwCfe9l5
oAZ9OyrxMQlHnwrruhcjz9Y=
=RNuG
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH 1/2] Delete ref $frotz by moving ref file to "deleted-$frotz~ref".
From: Shawn Pearce @ 2006-10-17 5:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Couder, git
In-Reply-To: <7v4pu3tuye.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
>
> > For example, when git becomes a major SCM, there may be people working on
> > big projects that want to create a new branch for each new bug and then
> > delete the branch when the code on the bug branch has been integrated into
> > a new release and the bug is closed.
>
> I would say that is a very valid way to work with git,
> regardless of the size of project. Now, how often would you
> create such a per-bug branch and delete one, compared to the
> number of operations that would require ref lookups? Your
> example actually supports what I've said -- optimizing for
> deletion at the cost of more expensive lookups is wrong.
I agree completely with Junio. I make a lot of temporary "throw
away" branches in Git; often they live on disk for 5/10 minutes at
most before getting deleted again. I also make a smaller number
(but still significant) of longer lived branches that hang around
for days or weeks before getting deleted.
In the former case (throw away) I wouldn't want those refs added
to the packed refs file. They just don't live around long enough
to make it worth it. And when I delete them I want them gone.
So moving them off to a 'deleted-refs' directory to indicate they
are gone is just delaying the removal. Not something I want.
In the latter case (longer lived) I don't mind if I have to sit
though an extra 500 ms to rewrite the entire packed refs file
during a ref delete operation. I lived with the branch for weeks;
I can probably spare a second to finally get rid of it once its
gone upstream. Heck, the push to move that branch upstream might
actually take longer to unpack the loose objects contained on that
branch than the packed ref delete, even on 1000s of refs.
> If the goal is to optimize for deletion path, then that is
> true. My point is that we do not want to optimize for deletion
> path at the expense of more costly lookup path.
Absolutely. I figure I do ref lookups at least 3x the number of ref
deletes I perform. And that's just thinking about the sequence of
commands I commonly perform against my "throw away" branches which
live for at most 10 minutes, let alone my longer lived branches
that hang around for weeks.
--
Shawn.
^ permalink raw reply
* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-17 5:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, bazaar-ng, git
In-Reply-To: <Pine.LNX.4.63.0610170128350.14200@wbgn013.biozentrum.uni-wuerzburg.de>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Johannes Schindelin wrote:
> On Mon, 16 Oct 2006, Aaron Bentley wrote:
>> Bazaar's namespace is "simple" because all branches can be named by a
>> URL, and all revisions can be named by a URL + a number.
>
> How should this cope with a distributed project? IOW how does it deal with
> "this revision and that revision are exactly the same"?
There are two answers here. One is that the URL + number is UI, not
internals. A unique ID is used internally, so that can be compared.
But to fully ensure that there are no differences, i.e. that no one has
reused an ID, you can generate a revision testament.
> If I understand you correctly, you are claiming that you are not really
> identifying a revision, but a revision _at a certain place with a
> place-dependent number_. This conflicts with my understanding of a
> revision.
No, I am claiming that a revision at a certain place with a
place-dependent number is one name for a revision, but it may have other
names.
>> If that's true of Git, then it certainly has a simple namespace. Using
>> eight-digit hex values doesn't sound simple to me, though.
>
> It depends on your usage. If you want to do anything interesting, like
> assure that you have the correct version, or assure that two different
> person's tags actually tag the same revision, there is no simpler
> representation.
I can use the 'bzr missing' command to check whether my branch is in
sync with a remote branch. Or I can use the 'pull' command to update my
branch to a given revno in a remote branch.
>> That sounds right. So those branches are persistent, and can be worked
>> on independently?
>
> Of course! Persistence (and reliability) are the number one goal of git.
> Performance is the next one.
You'd be surprised. When we last spoke to the Mercurial team, Mercurial
didn't support multiple persistent branches in one repository. Pulling
from a remote repository could join two branches into one. I'm told
they're fixing that now.
>> You'll note we referred to that bevhavior on the page. We don't think
>> what Git does is the same as supporting renames. AIUI, some Git users
>> feel the same way.
>
> Oh, we start another flamewar again?
I'd hope not. It sounds as though you feel that supporting renames in
the data representation is *wrong*, and therefore it should be an insult
to you if we said that Git fully supported renames.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFNGVq0F+nu1YWqI0RAsXiAJ9hjH2sQGG3E9oIYP2SxscXvVQsJACdHtkj
+r37JPSjbQCuchPo08P3px8=
=5MHE
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: VCS comparison table
From: Shawn Pearce @ 2006-10-17 5:20 UTC (permalink / raw)
To: Aaron Bentley; +Cc: Jakub Narebski, bazaar-ng, git
In-Reply-To: <45346290.6050300@utoronto.ca>
Aaron Bentley <aaron.bentley@utoronto.ca> wrote:
> Jakub Narebski wrote:
> > One cannot have universally valid revision numbers (even
> > only per branch) in distributed development. Subversion can do that only
> > because it is centralized SCM. Global numbering and distributed nature
> > doesn't mix... hence contents based sha1 as commit identifiers.
>
> Sure. Our UI approach is that unique identifiers can usefully be
> abstracted away with a combination of URL + number, in the vast majority
> of cases.
But this only works when the URL is public. In Git I can just lookup
the unique SHA1 for a revision in my private repository and toss it
into an email with a quick copy and paste. With Bazaar it sounds
like I'd have to do that relative to some known public repository,
which just sounds like more work to me.
But I don't want to see this otherwise interesting thread devolve into
a "we do X better!" match so I'm not going to say anything further here.
> > I wonder if any SCM other than git has easy way to "rebase" a branch,
> > i.e. cut branch at branching point, and transplant it to the tip
> > of other branch. For example you work on 'xx/topic' topic branch,
> > and want to have changes in those branch but applied to current work,
> > not to the version some time ago when you have started working on
> > said feature.
>
> If I understand correctly, in Bazaar, you'd just merge the current work
> into 'xx/topic'.
Git has two approaches:
- merge: The two independent lines of development are merged
together under a new single graph node. This is a merge commit
and has two parent pointers, one for each independent line of
development which was combined into one. Up to 16 independent
lines can be merged at once, though 12 is the record.
- rebase: The commits from one line of development are replayed
onto a totally different line of development. This is often
used to reapply your changes onto the upstream branch after the
upstream has changed but before you send your changes upstream.
It can often generate more readable commit history.
I believe what you are talking about in Bazaar is the former (merge)
while what Jakub was talking about was the latter (rebase).
> > What your comparison matrick lacks for example is if given SCM
> > saves information about branching point and merges, so you can
> > get where two branches diverged, and when one branch was merged into
> > another.
>
> I'm not sure what you mean about divergence. For example, Bazaar
> records the complete ancestry of each branch, and determining the point
> of divergence is as simple as finding the last common ancestor. But are
> you considering only the initial divergence? Or if the branches merge
> and then diverge again, would you consider that the point of divergence?
I'm believe you nailed what Jakub was talking about on the head.
And yes, I noticed its in your matrix but its not very clear.
I think that some additional explanation there may help other
readers.
--
Shawn.
^ permalink raw reply
* Re: VCS comparison table
From: Carl Worth @ 2006-10-17 5:25 UTC (permalink / raw)
To: Aaron Bentley; +Cc: Johannes Schindelin, Jakub Narebski, bazaar-ng, git
In-Reply-To: <4534656B.7080105@utoronto.ca>
[-- Attachment #1: Type: text/plain, Size: 1373 bytes --]
On Tue, 17 Oct 2006 01:08:59 -0400, Aaron Bentley wrote:
> >> If that's true of Git, then it certainly has a simple namespace. Using
> >> eight-digit hex values doesn't sound simple to me, though.
> >
> > It depends on your usage. If you want to do anything interesting, like
> > assure that you have the correct version, or assure that two different
> > person's tags actually tag the same revision, there is no simpler
> > representation.
>
> I can use the 'bzr missing' command to check whether my branch is in
> sync with a remote branch. Or I can use the 'pull' command to update my
> branch to a given revno in a remote branch.
I think you missed the simplicity of the git naming here. With git, I
can receive a bug report that specifies a bug that appears in a
revision such as:
71037f3612da9d11431567c05c17807499ab1746
And since I have a commit object in my repository with that same name
I have a strong assurance that I am testing the identical software as
the bug reporter without me ever needing any access to pull from the
reporter's repository.
And this works in an entirely distributed fashion. Any two users can
be certain they are working with identical software on both ends by
exchanging and comparing a few bytes, (in email, irc, bugzilla, what
have you), without any need to refer to a common repository which both
users have access to.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: VCS comparison table
From: Shawn Pearce @ 2006-10-17 5:31 UTC (permalink / raw)
To: Aaron Bentley; +Cc: Johannes Schindelin, Jakub Narebski, bazaar-ng, git
In-Reply-To: <4534656B.7080105@utoronto.ca>
Aaron Bentley <aaron.bentley@utoronto.ca> wrote:
> Johannes Schindelin wrote:
> > On Mon, 16 Oct 2006, Aaron Bentley wrote:
> >> You'll note we referred to that bevhavior on the page. We don't think
> >> what Git does is the same as supporting renames. AIUI, some Git users
> >> feel the same way.
> >
> > Oh, we start another flamewar again?
>
> I'd hope not. It sounds as though you feel that supporting renames in
> the data representation is *wrong*, and therefore it should be an insult
> to you if we said that Git fully supported renames.
It would seem that the majority of folks on the Git list feel that
way, myself among them. I don't know that we'd find it an insult
to say Git fully supports renames but I do think we have had better
results from *not* recording them and looking for them after the
fact with smart tools.
Junio's recent work with git-pickaxe (or whatever its name finally
settles out to be) is a perfect example of this. Despite not having
"recorded renames" git-pickaxe is able to fairly accurately detect
blocks of code moving between files, of which renaming files is just
a special case. This provides some fairly accurate blame reporting
pointing to exactly which commit/author/datetime put a given line
of code into the project.
No additional metadata required. All existing repositories can
immediately benefit from the new tool. Rather slick if you ask me.
--
Shawn.
^ permalink raw reply
* [ANNOUNCE] GIT 1.4.2.4
From: Junio C Hamano @ 2006-10-17 5:31 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.4.2.4 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.4.2.4.tar.{gz,bz2} (tarball)
git-htmldocs-1.4.2.4.tar.{gz,bz2} (preformatted docs)
git-manpages-1.4.2.4.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.4.2.4-1.$arch.rpm (RPM)
We are close to 1.4.3, so this update coulc become moot very
soon, but just in case we have to delay it, I am pushing this
out for a rather important performance fix. Without it, "git
diff" on 64-bit machines can run 100x times slower than it
should be on unfortunate input.
Many thanks go to Jim Mayering for giving an easy to reproduce
initial problem report, and Linus and Davide Libenzi to quickly
come up with a fix.
Unfortunately I do not have access to any RPM capable machine
other than an x86-64 right now hence there is no RPM for x86-32
for this release yet (but 32-bit machines do not need this fix
to begin with, so it's Ok).
----------------------------------------------------------------
There is only one change since v1.4.2.3.
Linus Torvalds:
Fix hash function in xdiff library
^ permalink raw reply
* Re: VCS comparison table
From: Junio C Hamano @ 2006-10-17 6:23 UTC (permalink / raw)
To: Aaron Bentley; +Cc: git
In-Reply-To: <4534656B.7080105@utoronto.ca>
Aaron Bentley <aaron.bentley@utoronto.ca> writes:
> Johannes Schindelin wrote:
>
>>> You'll note we referred to that bevhavior on the page. We don't think
>>> what Git does is the same as supporting renames. AIUI, some Git users
>>> feel the same way.
>>
>> Oh, we start another flamewar again?
>
> I'd hope not. It sounds as though you feel that supporting renames in
> the data representation is *wrong*, and therefore it should be an insult
> to you if we said that Git fully supported renames.
Not recording and not supporting are quite different things.
What we don't do is to _record_ renames in the data structure.
I personally would not use a word as strong as _wrong_ (and
Linus may disagree), but (1) we can support renames without
recording them just fine, (2) recording renames would not help
to tell users about line movements across files which we would
want to do, and (3) we are getting closer to come up with a way
to even do (2) without recording renames. Given these, perhaps
I might say recording renames is _pointless_ when I am in good
mood.
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: Use already fetched branch with the --local flag.
From: Junio C Hamano @ 2006-10-17 7:14 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <87ac3w8jl1.fsf@gmail.com>
Santi Béjar <sbejar@gmail.com> writes:
> It allows to separate when you fetch from when you merge. So, a "git pull"
> can be:
>
> $ git fetch
> $ git pull --local
There was something that has been disturbing me in your patches
(this one, and the previous "remote=." one) and I could not tell
what it was. I think I know what it is now.
Let me outline my understanding of the workflow these two
changes would help.
You have an upstream repository that has more than one branches
you are interested in, say "master" and "next". And you work on
top of both of them, so you have two branches of your own that
correspond to them.
So you organize your remote section perhaps like this:
[remote."origin"]
url = git://git.k.o/.../git.git/
fetch = refs/heads/master:refs/remotes/origin/master
fetch = refs/heads/next:refs/remotes/origin/next
fetch = +refs/heads/pu:refs/remotes/origin/pu
[branch."master"]
remote = origin
merge = refs/heads/master
[branch."next"]
remote = origin
merge = refs/heads/next
That is, your refs/heads/master corresponds to upstream's master
branch and your next corresponds to upstream's next branch.
When you are on your "master" you would merge changes made to
upstream's master into it with "git pull".
By the way, could you add descriptions on remote.* to
Documentation/config.txt?
After doing a "git pull" while on your "master" and finishing
working on your "master", you might switch to your "next". At
that point, if you want to merge upstream changes without
re-fetching, you can do either of the following:
git pull . remotes/origin/next
git pull --local
(the former can be "git pull" if "branch.next.remote=.").
I think this is the point of your two patches, and in that
sense, the --local one makes "branch.remote=." patch
unnecessary.
While these save typing on "git pull", two things bother me.
* the tool is not helping you decide if you can get away
without re-fetching. you need to remember that (1) you
fetched from the upstream to update "master" recently _and_
(2) because of your [remote."origin"] configuration your
remotes/origin/next was updated while you pulled into your
"master".
* while the workflow assumes that one local branch is tied
closely to one remote branch (in this example, tracked under
remotes/origin), the rest of the tools do not take advantage
of that assumption to help you decide what to do next.
For example, if each of your local branch is tied closely to one
remote branch, you should be able to "git fetch" to update the
tracking branches and then ask:
- what changes are in remote that I haven't merged?
- what happens when I pull --local right now?
- what changes if any are in mine alone missing from remote?
- can I push to remote right now (i.e. would it fast-forward)?
- how fresh is the tracking branch that corresponds to my
current branch?
Right now, these require you to spell out the name of the
tracking branch. Assuming you are on your "next" branch:
git log ..remotes/origin/next
git log remotes/origin/next..
git log remotes/origin/next...next [*1*]
git show-branch remotes/origin/next next
tail -n 1 .git/logs/remotes/origin/next
would be the ways to ask the above questions (and the last one
is unreadable unless you can do strptime in your head).
Maybe we can introduce a new extended SHA-1 notation to mean
"the tracking branch this branch usually merges from". Then we
can say:
git log ..^
git log ^..
git log ^...
git show-branch ^ next
I am not sure '^' is syntactically viable, but hopefully you get
the idea.
[*1*] While three-dots symmetric difference is a nice addition
made recently, I often find it irritating that the output does
not tell which branch each of the commit is reachable from, and
end up running show-branch, which does. Would anybody have a
clever idea to fix this cleanly?
^ permalink raw reply
* Re: VCS comparison table
From: Christian MICHON @ 2006-10-17 7:26 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0610161714590.3962@g5.osdl.org>
On 10/17/06, Linus Torvalds <torvalds@osdl.org> wrote:
> Well, you can just add
>
> [alias]
> cat=-p cat-file -p
>
> to your ~/.gitconfig file, and you're there.
_WONDERFUL_. Really :)
--
Christian
^ permalink raw reply
* What's in git.git
From: Junio C Hamano @ 2006-10-17 7:44 UTC (permalink / raw)
To: git
* The 'maint' branch has this fix and produced 1.4.2.4 release.
Linus Torvalds (1):
Fix hash function in xdiff library
* The 'master' branch has these since the last announcement.
The fix in 'maint' is also included. Hopefully we can cut the
real 1.4.3 with this sometime this week.
Junio C Hamano (1):
Revert "move pack creation to version 3"
Petr Baudis (1):
svnimport: Fix broken tags being generated
Rene Scharfe (2):
Make write_sha1_file_prepare() void
Replace open-coded version of hash_sha1_file()
* The 'next' branch, in addition, has these.
Alan Chandler (1):
Gitweb - provide site headers and footers
Andy Whitcroft (2):
cvsimport: move over to using git-for-each-ref to read refs.
git-for-each-ref: improve the documentation on scripting modes
Christian Couder (12):
Add [-s|--hash] option to Linus' show-ref.
Use Linus' show ref in "git-branch.sh".
Document git-show-ref [-s|--hash] option.
Fix show-ref usage for --dereference.
Add pack-refs and show-ref test cases.
When creating branch c/d check that branch c does not already exists.
Uncomment test case: git branch c/d should barf if branch c exists.
Fix a remove_empty_dir_recursive problem.
Clean up "git-branch.sh" and add remove recursive dir test cases.
Use git-update-ref to delete a tag instead of rm()ing the ref file.
Check that a tag exists using show-ref instead of looking for the ref file.
Do not create tag leading directories since git update-ref does it.
Dennis Stosberg (2):
lock_ref_sha1_basic does not remove empty directories on BSD
Remove bashism from t3210-pack-refs.sh
Jeff King (3):
wt-status: use simplified resolve_ref to find current branch
gitignore: git-pack-refs is a generated file.
gitignore: git-show-ref is a generated file.
Johannes Schindelin (3):
Fix git-update-index --again
show-branch: mark active branch with a '*' again
Turn on recursive with --summary
Jonas Fonseca (1):
Add man page for git-show-ref
Junio C Hamano (55):
upload-pack: stop the other side when they have more roots than we do.
Add git-for-each-ref: helper for language bindings
Fix t1400-update-ref test minimally
fsck-objects: adjust to resolve_ref() clean-up.
symbolit-ref: fix resolve_ref conversion.
Add callback data to for_each_ref() family.
Tell between packed, unpacked and symbolic refs.
pack-refs: do not pack symbolic refs.
git-pack-refs --prune
pack-refs: fix git_path() usage.
lock_ref_sha1_basic: remove unused parameter "plen".
Clean-up lock-ref implementation
update-ref: -d flag and ref creation safety.
update a few Porcelain-ish for ref lock safety.
Teach receive-pack about ref-log
receive-pack: call setup_ident before git_config
grep --all-match
teach revision walker about --all-match.
git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 1)
ref locking: allow 'foo' when 'foo/bar' used to exist but not anymore.
refs: minor restructuring of cached refs data.
lock_ref_sha1(): do not sometimes error() and sometimes die().
lock_ref_sha1(): check D/F conflict with packed ref when creating.
delete_ref(): delete packed ref
git-branch: remove D/F check done by hand.
show-ref --hash=len, --abbrev=len, and --abbrev
git-fetch: adjust to packed-refs.
Fix refs.c;:repack_without_ref() clean-up path
gitweb: make leftmost column of blame less cluttered.
git-fetch: do not look into $GIT_DIR/refs to see if a tag exists.
pack-refs: use lockfile as everybody else does.
gitweb: prepare for repositories with packed refs.
Revert 954a6183756a073723a7c9fd8d2feb13132876b0
pack-refs: call fflush before fsync.
blame.c: whitespace and formatting clean-up.
git-blame: --show-number (and -n)
git-blame: --show-name (and -f)
blame.c: move code to output metainfo into a separate function.
git-send-email: do not drop custom headers the user prepared
ref-log: allow ref@{count} syntax.
git-send-email: real name with period need to be dq-quoted on From: line
git-blame --porcelain
gitweb: use blame --porcelain
Make git-send-email detect mbox-style patches more readily
core.logallrefupdates create new log file only for branch heads.
git-pack-refs --all
core.logallrefupdates thinko-fix
pack-objects: document --delta-base-offset option
blame: Document and add help text for -f, -n, and -p
gitweb: spell "blame --porcelain" with -p
git-repack: repo.usedeltabaseoffset
diff --numstat
pack-objects: use of version 3 delta is now optional.
gitweb: use for-each-ref to show the latest activity across branches
Revert "pack-objects: use of version 3 delta is now optional."
Linus Torvalds (6):
Add "git show-ref" builtin command
Teach "git checkout" to use git-show-ref
Start handling references internally as a sorted in-memory list
Add support for negative refs
Make ref resolution saner
Enable the packed refs file format
Luben Tuikov (4):
gitweb: blame: print commit-8 on the leading row of a commit-block
gitweb: blame: Mouse-over commit-8 shows author and date
gitweb: blame porcelain: lineno and orig lineno swapped
git-revert with conflicts to behave as git-merge with conflicts
Martin Waitz (2):
gitweb: start to generate PATH_INFO URLs.
gitweb: warn if feature cannot be overridden.
Matthew Wilcox (1):
Add --dry-run option to git-send-email
Nicolas Pitre (8):
introduce delta objects with offset to base
teach git-unpack-objects about deltas with offset to base
teach git-index-pack about deltas with offset to base
make git-pack-objects able to create deltas with offset to base
make pack data reuse compatible with both delta types
let the GIT native protocol use offsets to delta base when possible
zap a debug remnant
allow delta data reuse even if base object is a preferred base
Petr Baudis (5):
Fix broken sha1 locking
Fix buggy ref recording
gitweb: Document features better
gitweb: Fix search form when PATH_INFO is enabled
bisect reset: Leave the tree in usable state if git-checkout failed
Rene Scharfe (2):
git-archive --format=zip: use default version ID
git-archive --format=zip: add symlink support
Robert Shearman (2):
git-rebase: Use --ignore-if-in-upstream option when executing git-format-patch.
git-rebase: Add a -v option to show a diffstat of the changes upstream at the start of a rebase.
Ryan Anderson (1):
Remove git-annotate.perl and create a builtin-alias for git-blame
Santi Béjar (2):
fetch: Misc output cleanup
merge and resolve: Output short hashes and .. in "Updating ..."
Sasha Khapyorsky (1):
git-svnimport.perl: copying directory from original SVN place
* The 'pu' branch, in addition, has these.
Junio C Hamano (17):
git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 2)
para-walk: walk n trees, index and working tree in parallel
para walk wip
merge: loosen overcautious "working file will be lost" check.
git-pickaxe: blame rewritten.
git-pickaxe: minimally use revision machinery.
git-pickaxe: fix output for more than one paths from the same commit.
git-pickaxe: fix "bottom" commit handling.
git-pickaxe: allow using non -u0 diff internally.
git-pickaxe: use linked list of blame entries.
git-pickaxe: collapse trivial blame entry.
git-pickaxe: blame line movements within a file.
git-pickaxe: blame cut-and-pasted lines.
git-pickaxe: -M, -C, and -C -C
git-pickaxe: optimize nth_line()
git-pickaxe: make -C (copy from other file) take immediate blame.
git-pickaxe: document -M, -C, and -C -C
Petr Baudis (1):
gitweb: Show project README if available
^ permalink raw reply
* Re: [PATCH] be more vim-ish, and also syntax hilight Signed-off-by lines.
From: Junio C Hamano @ 2006-10-17 7:46 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, Jeff King
In-Reply-To: <11610450702261-git-send-email-madcoder@debian.org>
I'd prefer patches to contrib/ sections to be CC'ed to the
owners of them (in this case that would be Jeff King) to be
Acked, since I do not actively maintain anything under contrib/
myself.
Jeff, are you Ok with Pierre's two patches?
^ permalink raw reply
* Re: VCS comparison table
From: Andreas Ericsson @ 2006-10-17 7:50 UTC (permalink / raw)
To: Aaron Bentley; +Cc: Linus Torvalds, Jakub Narebski, bazaar-ng, git
In-Reply-To: <45345AEF.6070107@utoronto.ca>
Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Linus Torvalds wrote:
>> On Mon, 16 Oct 2006, Aaron Bentley wrote:
>>> Bazaar's namespace is "simple" because all branches can be named by a
>>> URL, and all revisions can be named by a URL + a number.
>
>> I pretty much _guarantee_ that a "number" is not a valid way to uniquely
>> name a revision in a distributed environment, though. I bet the "number"
>> really only names a revision in one _single_ repository, right?
>
> Right. That's why I said all revisions can be named by a URL + a
> number, because it's the combination of the URL + a number that is
> unique. (In bzr, each branch has a URL.)
>
The revision will change between different repos though, so
random-contributor A that doesn't have his repo publicised needs to send
patches and can't log his exact problem revision somewhere, which makes
it hard for random contributor B that runs into a similar problem but on
a different project sometime later to find the offending code. I prefer
the git way, but I'm a git user and probably biased.
That said, it shouldn't be impossible to add fixed, user-friendly
bazaar-like revision numbers for git. We just have to reverse the
<committish>[^~]<number> syntax to also accept <committish>+<number>.
This would work marvelously with serial development but breaks horribly
with merges unless the first (or last) commit on each new branch gets
given a tag or some such.
Either way, I'm fairly certain both bazaar and git needs to distribute
information to the user in need of finding the revision (which url and
which number vs which sha). I also imagine that the bazaar users, just
like the git users, are sufficiently apt copy-paste people to never
actually read the prerequisite information.
>
>> If you give
>> the SHA1 name, it's well-defined even between different repositories, and
>> you can tell somebody that "revision XYZ is when the problem started", and
>> they'll know _exactly_ which revision it is, even if they don't have your
>> particular repository.
>
> When two people have copies of the same revision, it's usually because
> they are each pulling from a common branch, and so the revision in that
> branch can be named. Bazaar does use unique ids internally, but it's
> extremely rare that the user needs to use them.
>
Well, if two people have the same revision in git, you *know* they have
pulled from each other, because ALL objects are immutable. The point of
"naming" the revision is moot, because it's something all SCM's can do.
>> Now _that_ is true simplicity. It does automatically mean that the names
>> are a bit longer, but in this case, "longer" really _does_ mean "simpler".
>>
>> If you want a short, human-readable name, you _tag_ it. It takes all of a
>> hundredth of a second to to or so.
>
> But tags have local meaning only, unless someone has access to your
> repository, right?
>
I imagine the bazaar-names with url+number only has local meaning unless
someone has access to your repository too. One of the great benefits of
git is that each revision is *always exactly the same* no matter in
which repository it appears. This includes file-content, filesystem
layout and, last but also most important, history.
>>>> About "checkouts", i.e. working directories with repository elsewhere:
>>>> you can use GIT_DIR environmental variable or "git --git-dir" option,
>>>> or symlinks, and if Nguyen Thai Ngoc D proposal to have .gitdir/.git
>>>> "symref"-like file to point to repository passes, we can use that.
>>> It sounds like the .gitdir/.git proposal would give Git "checkouts", by
>>> our meaning of the term.
>> Well, in the git world, it's really just one shared repository that has
>> separate branch-namespaces, and separate working trees (aka "checkouts").
>> So yes, it probably matches what bazaar would call a checkout.
>
> The key thing about a checkout is that it's stored in a different
> location from its repository. This provides a few benefits:
>
> - - you can publish a repository without publishing its working tree,
> possibly using standard mirroring tools like rsync.
>
Can't all scm's do this?
> - - you can have working trees on local systems while having the
> repository on a remote system. This makes it easy to work on one
> logical branch from multiple locations, without getting out of sync.
>
This I'm not so sure about. Anyone wanna fill out how shallow clones and
all that jazz works?
> - - you can use a checkout to maintain a local mirror of a read-only
> branch (I do this with http://bazaar-vcs.com/bzr/bzr.dev).
>
Check. Well, actually, you just clone it as usual but with the --bare
argument and it won't write out the working tree files.
>> Almost nobody seems to actually use it that way in git - it's mostly more
>> efficient to just have five different branches in the same working tree,
>> and switch between them. When you switch between branches in git, git only
>> rewrites the part of your working tree that actually changed, so switching
>> is extremely efficient even with a large repo.
>
> You can operate that way in bzr too, but I find it nicer to have one
> checkout for each active branch, plus a checkout of bzr.dev. Our switch
> command also rewrites only the changed part of the working tree.
>
Works in git as well, but each "checkout" (actually, locally referenced
repository clone) gets a separate branch/tag namespace.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ 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