* Re: Show remote branches on gitweb
From: Jakub Narebski @ 2006-11-28 15:14 UTC (permalink / raw)
To: git
In-Reply-To: <ek7m6m$qqd$1@sea.gmane.org>
Jakub Narebski wrote:
> Jakub Narebski wrote:
>
>> Pazu wrote:
>>
>>> Is there any way to do it? I'm using git-svn to track a remote subversion
>>> repository, and it would be very nice to browse the history for a remote branch
>>> for which I didn't start a local branch yet.
>>
>> Planned, not implemented yet.
>
> The problem is that to implement it _well_ we have to get remotes, both
> $GIT_DIR/remotes and config remote.xxx, info. And the latter (config
> remotes info) needs config parsing, something we lack.
We could simplify things, and assume that remote name is _never_
hierarchical, so that remote branches names are:
remotes/<remote>/<branch>
where <remote> does not contain '/'.
Additional problem is for "summary" view: should we limit number of heads
per remote, should we sort heads inside remote, or should we also sort
remotes, or should we sort remotes by time without grouping into repos?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Workflow example for remote repository use of GIT
From: Johannes Schindelin @ 2006-11-28 15:15 UTC (permalink / raw)
To: Sean Kelley; +Cc: git
In-Reply-To: <89b129c60611280708x10a9c42fia23e6b7770971838@mail.gmail.com>
Hi,
all in all, a good quick start.
On Tue, 28 Nov 2006, Sean Kelley wrote:
> Getting The Latest Upstream Code into master
>
> git pull origin master
This gives the impression that the 2nd argument of pull specifies which
_local_ branch stuff gets merged to. But it means that you pull into the
_current_ branch from the _remote_ master.
Ciao,
Dscho
^ permalink raw reply
* Re: Some tips for doing a CVS importer
From: Markus Schiltknecht @ 2006-11-28 15:18 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Jon Smirl, Git Mailing List, dev, Shawn Pearce
In-Reply-To: <456B61FE.7060100@alum.mit.edu>
Hi,
Michael Haggerty wrote:
> There's still time to join forces :-) "Far from finished" on a project
> of this messiness can equal quite a bit of time.
Yes. Maybe I'm a little pessimistic ;-)
> But even if you want to pursue your own converter, consider visiting
> #cvs2svn on irc.freenode.net if you want to discuss things.
Thanks, I just happen to not particularly like IRC... I prefer emails
and mailing lists.
>> During parsing of all the *,v files, where I'm collecting events
>> (commits, branching and tagging) into blobs, I do also remember
>> 'possible parent branches' for all the symbols (tag and branch events).
>
> This is the part that can get quite expensive for large repositories, as
> there can be orders of magnitude more symbol creations than revisions.
> According to Daniel Jacobowitz:
>
>> [...] at one point I believe the GCC repository was gaining up
>> to four tags a day (head, two supported release branches, and one
>> vendor branch). I've been using the principal that the number of tags
>> might be unworkable, but the number of branches generally is not.
>
> This means that the number of tag events is O(number-of-days *
> total-number-of-files-in-repo), where the gcc repo has about 50000
> files. By contrast, only a small fraction of files is typically touched
> in any day.
Yeah, 50'000 * 1825 (5 years) * say 100 bytes -> 8GB sounds like a lot.
OTOH, I certainly don't need 100 bytes per tag and one tag per day over
five years is really a lot. Repositories that large are probably not
converted to CVS on an old Pentium III...
I've just tested with the mozilla repository (I don't have the gcc one).
The import has been run only through the first two stpes: collecting the
blobs and symbol resolving. That took almost one and a half hour on my
Core Duo with 2GB of memory:
real 85m20.684s
user 39m59.082s
sys 1m32.874s
And peak memory consumption was:
VmPeak: 1814024 kB
While the mozilla/mozilla cvs repository sums up to 3.1 GB. The monotone
repository (which is still lacking the revisions, but has all files and
file deltas) is 588MB after that step. I'd guess that once it finishes,
it would be less than 1GB.
> I've been trying to find a solution that doesn't require quite so much
> space. I think that if you allow yourself this much space, the problem
> is not very difficult.
Okay. As long as I can import it on my laptop I'm fine ;-)
>> After that and *before* the blob sorting, I check all blobs and try to
>> find one single parent branch for them. In the best case, those symbol
>> blobs do have exactly one possible parent branch, then I just pick that
>> one. If there are multiple possible parents, I try to pick the deepest.
>> As branches are symbols themselves, I have to run that multiple times
>> until all symbols are resolved.
>>
>> An example: having branches ROOT -> A -> B -> C (branched in that order)
>> plus a branch D derived from branch A.
>
> I assume that you are talking about a situation for which CVS is
> ambiguous, like a file with
>
> A = 1.2.2
> B = 1.2.4
> C = 1.2.6
> D = 1.2.2.5.2
Well, almost. I meant a whole repository with these branches. If one
file included all the branches it's getting easy to resolve. But for my
example, I had something like that in mind:
fileA:
A = 1.2.2
(no changes for branch B)
C = 1.2.4 --> makes A a possible parent of branch C
D = 1.2.2.5.2 --> makes A a possible parent of branch D
X = 1.2.4 --> makes C a possible parent of tag X
fileB:
A = 1.2.2
B = 1.2.4 --> makes A a possible parent of branch B
C = 1.2.6 --> makes B a possible parent of branch C
D = 1.2.2.5.2 --> makes A a possible parent of branch D
X = 1.2.2.5.2 --> makes D a possible parent of tag X
fileC:
A = 1.2.2
X = 1.2.2 --> makes A a possible parent of tag X
fileD:
A = 1.2.2
B = 1.2.4
X = 1.2.4 --> makes B a possible parent of tag X
>> The symbol blob for branch A: has only one possible parent: ROOT. Thus I
>> assign A->parent_branch = ROOT.
>>
>> Next comes the blob for branch C: it has two possible parents: branch B
>> and branch A.
>
> Why is ROOT not considered as a possible parent of C?
Those were just examples. In my CVS-repository-in-mind, none of the
files were branching from ROOT directly into C.
>> At that point we know that A is derived from ROOT, but we
>> don't have assigned a parent to B, yet. Thus we can not resolve C this
>> time.
>>
>> Then comes branch B: one parent: A. Mark it.
>>
>> Next round, we process C again: this time, we know B is branched from A.
>> Thus we can remove the possible parent A. Leaving only one possible
>> parent branch: B.
>
> But the fact that B preceded C chronologically does not mean that C is
> derived from B.
No. And I don't assume so in any place. Given the files above, I can
however clearly say that C got branched off from B, no?
> If I branch from ROOT or A after creating branch B, the
> result as stored in CVS looks exactly the same as if I branch from B
> (unless a file was modified between the creation of the parent branch
> and the creation of the child branch).
Sure. That would result in an unresolvable symbol.
>> Now, say we have a tag 'X', which ended up in a blob having A, B, C and
>> D as possible parent branches. I currently remove A and B, as they are
>> parents of C. But C and D still remain and conflict. I'm unable to
>> resolve that symbol. I'm thinking about leaving such conflicts to the
>> user to resolve.
>
> From your description, this sounds like a tag that cannot be created
> from a single parent branch. Therefore it would have to be cobbled
> together from multiple parents.
Right. I somehow have to cope with those cases, as CVS allows them and
monotone does not.
The main point in my symbol resolving code is trying to uniquely assign
a symbol to one branch wherever possible. And handing cases where this
is not possible to the user. AFAICT, it does so quite well.
Regards
Markus
^ permalink raw reply
* Re: Workflow example for remote repository use of GIT
From: Shawn Pearce @ 2006-11-28 15:25 UTC (permalink / raw)
To: Sean Kelley; +Cc: git
In-Reply-To: <89b129c60611280708x10a9c42fia23e6b7770971838@mail.gmail.com>
Sean Kelley <sean.v.kelley@gmail.com> wrote:
> I have been trying to set-up a workflow for developers in my group
> using GIT. I came up with this simplified flow. Do you all see any
> problems with this approach?
...
> Always work out of master
>
> git checkout master
>
> Getting The Latest Upstream Code into master
>
> git pull origin master
>
> Create a topic branch for your development work
>
> git checkout -b <new topic branch name>
That can be streamlined slightly:
git fetch
git checkout -b <new-topic> origin
as fetch would by default download from remote 'origin' and update
the tracking branches. And of course developers may not want to
create their new branch from origin, e.g. if they are doing a bug
fix to an earlier release of the product. I think its a good habit
to be in to always specify the origination point for a branch when
creating it.
> Do your development in the topic branch
>
> edit/debug/test
>
> Committing Changes
>
> git commit -a
Sure, that's CVS-like and rather simple.
> Switch back to master
>
> git checkout master
>
> Update the master branch from origin again
>
> git pull origin master
>
> Now Merge your topic branch
>
> git pull . <topic branch to merge into current branch>
Yes, that works and will get you a merge message like
Merge branch 'my-topic' into master
which is probably what you want if there actually was a merge.
If there wasn't (its just a fast-forward) then you won't get the
merge message. It also has the nice property that the "trunk (if
there is such a thing)" is the first parent in every merge, with
the topic(s) in the other parents.
Though I tend to just pull the origin into the current branch
and push that directly, e.g.:
git pull origin master
git push origin HEAD:master
--
^ permalink raw reply
* Re: [PATCH] Trim hint printed when gecos is empty.
From: Shawn Pearce @ 2006-11-28 15:31 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611281506.53518.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> wrote:
> > So I will never need something like you suggest. Having said that, if you
> > think it is best for you to mark every commit as signed-off-by you, just
> > add an alias:
> >
> > git repo-config --global alias.c "commit -s"
>
> That requires that I introduce a new command; I want the existing command to
> do The Right Thing. Also; I certainly wouldn't want it global, as I said in
> my original message - this is a per-project choice. Some projects don't have
> Signed-Off lines, so there is no point there.
>
> Ideally, I'd be able to do
> git repo-config alias.commit "commit -s"
> Just as I can with shell commands.
Long ago we decided that aliasing over shipped commands was a baaaad
idea, as it might get a shell script into trouble when all of a
sudden the "-s" option is being given to every commit invocation.
But you can install a commit-msg hook (.git/hooks/commit-msg)
in any project you want to ensure a Signed-off-by line is in the
commit message for. Its handed the COMMIT_EDITMSG file, which is
what the message will be generated from. Looking at the code for
git-commit.sh its perfectly OK if the hook edits the file too.
Further the hook could be interactive, prompting the user "are
you sure you don't want to sign this commit?" or can be skipped by
handing --no-verify to commit.
I just learned about commit-msg hook the other day when I was reading
through git-commit.sh and noticed I didn't implement invoking that
particular hook in git-gui...
--
^ permalink raw reply
* Re: [PATCH 1.2/2 (fixed)] git-svn: fix output reporting from the delta fetcher
From: Pazu @ 2006-11-28 15:32 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <9e7ab7380611280445r4ebe344cw69cbc18a74c6122f@mail.gmail.com>
On 11/28/06, Pazu <pazu@pazu.com.br> wrote:
> Error from SVN, (200003): Incomplete data: Delta source ended unexpectedly
> at /opt/local/lib/perl5/vendor_perl/5.8.8/darwin-2level/SVN/Ra.pm line 157
> 512 at /Users/pazu/bin/git-svn line 448
> main::fetch_lib() called at /Users/pazu/bin/git-svn line 319
> main::fetch() called at /Users/pazu/bin/git-svn line 178
I've added some debug statements to git-svn and found more
information. Apparently, this error is happening because
SVN::Git::Fetcher is trying to open a file that hasn't been fetched by
git-svn yet. Now, *why* this is happening, I don't know. Maybe
something happened while fetching the initial revision.
Here's the output from my "debug" run:
Creating fetcher for revision 9785a6fc2d61a6f9b702bb8e2dd81b11415e6e92
Starting update on revision 11159
Opening CamelEar/config/glconfig.xml@11143
Error from SVN, (200003): Incomplete data: Delta source ended unexpectedly
Here, SVN::Git::Fetcher received a request to open
CamelEar/config/glconfig.xml, but:
mini:~/devel/camel-git pazu$ git-ls-tree
9785a6fc2d61a6f9b702bb8e2dd81b11415e6e92
040000 tree 9a02a43ec34e88d4cee64d322354a49c8f6063e2 BungeIntegrationService
040000 tree 6e0bc09356f480f8b6ec782420c4af322ed3bc0a
BungeIntegrationServiceClient
040000 tree 5da3e715525c9b436fdf9a9dfb4de2bffd8e5ff3 CamelService
040000 tree a2d36b9cc469a52aea4f2422ffab30b9a1ee67de CamelServiceClient
040000 tree 3d550fad4dcf09a8d45c5e5808dac4883854872c CamelServiceTests
040000 tree 1fcd2416b4c8494c066abc38051db5244ee801cd CamelWeb
040000 tree d2e30726674b22e06b4ec07aa68b49f925609c85 Reports
040000 tree 007c4ded31cf16418a7fb0b2ffbe2b796e7ce11e Servers
100644 blob da2d34be7d44fff5cf70702edc61fd8b6057a14a _root.iml
100644 blob 6219148365613fd6195b8558376455c3379bbd6e bg-cam.ipr
100644 blob 25d3fbab0971940cf2cdbe399fd2b79cb21de1b5 build.xml
100644 blob abc91fc1b268a3610a927125b88c1ad05c095d95 checkout-svn-build.sh
100644 blob 475a5dc68c8e0eaaac3a182c078c04b947825469 cvs-checkout.xml
Notice that there's no "CamelEar" directory. For some reason, it
wasn't fetched in the initial revision. Now, just to make sure this
isn't svn fault:
mini:~/devel/camel-git pazu$ svn ls -r11143
https://tech.bga.bunge.com/BungeHomeExt/GLS/trunk/java/bg-cam
.cvsignore
BungeIntegrationEar/
BungeIntegrationService/
BungeIntegrationServiceClient/
CamelEar/
CamelService/
CamelServiceClient/
CamelServiceTests/
CamelWeb/
Reports/
Servers/
Servers_W6/
_root.iml
bg-cam.ipr
build.ws.properties.example
build.xml
checkout-build.sh
checkout-svn-build.sh
cvs-checkout.xml
svn-checkout.xml
So yeah, CamelEar was supposed to exist in this revision, but for some
reason, git-svn missed it. I'll keep trying to find why that happened
-- my bets are on a broken network connection during the initial
fetch, with git-svn accepting what it got so far as the initial
revision, instead of reporting the broken connection.
^ permalink raw reply
* Re: [RFC] git-branch: add options and tests for branch renaming
From: Shawn Pearce @ 2006-11-28 15:39 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Lars Hjemli, git, Junio C Hamano
In-Reply-To: <456C4FCE.6090306@shadowen.org>
Andy Whitcroft <apw@shadowen.org> wrote:
> Ok, I have been feeling uneasy about rename and reflogs for a while now.
> About removing reflogs too for that matter.
>
> In my mind the ref log is about tracking what a ref points to. So I
> want to be able to say "what was next, yesterday". Do I care if its not
> there now? Perhaps I want a rename to just put a rename from in the top
> of the new reflog and leave the old there.
>
> Yep, no idea how we would clean them up with this model. But ...
You use a global reflog instead of a ref specific log. There are
of course huge problems with that idea, but it is probably the
simplest way to solve what you want.
Though I'm not sure why you care that much. To me a ref is just
as transient as the name of the working directory the repository is
housed in. I could care less what I called that directory last week,
just that it exists and has the content I expect. On the other
hand, once I'm in that directory I *do* want the history of it.
That's where git comes in. Likewise for a ref once I am speaking
about a given ref, I want the history of it, and that's where git's
reflog comes in.
Although I just realized this paticular case:
git branch -D next
git fetch origin next:next
...
git fetch origin next:next
git branch -M next bob
...
... 2 days go by ...
...
git fetch origin next:next
... arrgh next is no good! ...
git log next@{2.days.ago}
and there's nothing there, as the log for next just started in
the last fetch. Yet you had a next that you renamed to bob, and
that next has the log.
Though this can be easily dealt with by reading the RENAME_LOG.
If you scan both this ref's log and the RENAME_LOG and switch to
scanning another ref's log when you find that this ref was renamed
to another ref, then you get what you expect above. Except if you
deleted the rename destination branch.
I can't say I would use that feature though, despite how handy I
find reflogs to be.
--
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Shawn Pearce @ 2006-11-28 15:44 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611281335.38728.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> wrote:
> I think I've talked myself into the position where it definitely has to be
> HEAD being tracked in the submodules; anything else is a disaster waiting to
> happen because commit doesn't check in your current tree.
Yes, but not only that, HEAD is the only thing that fits with the
rest of the git repository/index/working directory model.
Lets review...
What's HEAD? Its the commit which matches the index state as
closely as possible, with the only differences being the changes in
progress that are being prepared for the next commit (whose parent
will be HEAD). If the index and working directory are both clean
(no changes) then its also the current content of this directory,
right?
What's the index? Its what you are about to commit.
What's the working directory? Its the current content, which may
also be partially checked out or dirty.
So HEAD in a submodule is the current content of that submodule.
Therefore any update-index call on a submodule should load HEAD
(totally ignoring whatever branch it refers to) into the supermodule
index.
--
^ permalink raw reply
* Odd merge message in ad0c31?
From: Shawn Pearce @ 2006-11-28 15:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Is this because of my bash completion breakage?
commit ad0c31801b19d7614fac4c82fba67121b75bdea8
Merge: b3fccc6... 255cae8...
Author: Junio C Hamano <junkio@cox.net>
Date: Mon Nov 27 17:14:31 2006 -0800
Merge branch 'ap/clone-origin' of .git/ into next
^^^^^^^^
^^^^^^^^
or were you just doing something weird at that time?
--
^ permalink raw reply
* Re: [PATCH 1.2/2 (fixed)] git-svn: fix output reporting from the delta fetcher
From: Seth Falcon @ 2006-11-28 16:07 UTC (permalink / raw)
To: Pazu; +Cc: Eric Wong, git
In-Reply-To: <9e7ab7380611280732k4e940380tbf2a96146807d671@mail.gmail.com>
Pazu <pazu@pazu.com.br> writes:
> Notice that there's no "CamelEar" directory. For some reason, it
> wasn't fetched in the initial revision. Now, just to make sure this
> isn't svn fault:
>
> mini:~/devel/camel-git pazu$ svn ls -r11143
> https://tech.bga.bunge.com/BungeHomeExt/GLS/trunk/java/bg-cam
> .cvsignore
> BungeIntegrationEar/
> BungeIntegrationService/
> BungeIntegrationServiceClient/
> CamelEar/
Is CamelEar an empty directory (or was it an empty directory in the
first fetch) by any chance?
I think that presently git-svn does not create empty dirs when pulling
from svn. It would be nice to have such directories created since
some projects will expect the empty dir to be there (no need to track
it in git, IMO).
^ permalink raw reply
* Re: git and bzr
From: Linus Torvalds @ 2006-11-28 16:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, git, bazaar-ng
In-Reply-To: <Pine.LNX.4.63.0611281433270.30004@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, 28 Nov 2006, Johannes Schindelin wrote:
>
> On Tue, 28 Nov 2006, Jakub Narebski wrote:
>
> > [... some reasons why git-annotate is not just your regular annotate ...]
>
> You should also mention that git-annotate can follow code movements
> through file renames.
.. and within the same file, and _copied_ from other files.
A good example of this is still just doing a
git blame -C revision.c
because that "revision.c" file was created by splitting the old
"rev-list.c" into two files (revision.c and rev-list.c). And the fact that
"git blame" catches it and shows it in a very natural format is really
quite nice.
(rev-list.c has since been renamed to "builtin-rev-list.c", so if you want
to see the "other" side of the split, just do
git blame -C builtin-rev-list.c
in order to realize how well git blame follows both renames _and_ pure
data movement).
The reason this is a good example is simply the fact that it should
totally silence anybody who still thinks that tracking file identities is
a good thing. It explains well why tracking file identities is just
_stupid_.
You simply couldn't have done that kind of split sanely with file identity
tracking (well, that one only had a single copy, so you could argue that a
file identity tracker with copies could have done it, but the fact is that
(a) they never do and (b) "git blame" can equally well track stuff that
comes from _multiple_ different "file iddentities").
Such a "multiple sources" case can actually be found by doing
git blame -C tree-walk.c
which (correctly) figures out that the code comes from both merge-tree.c
(the "entry compare/extract" functions)_and_ from sha1_name.c (the
"find_tree_entry()" function).
So yes, "git blame" is a _hell_ of a lot more powerful than anybody elses
"annotate", as far as I know. I literally suspect that nobody else comes
even close.
^ permalink raw reply
* Re: [RFC] git-branch: add options and tests for branch renaming
From: Lars Hjemli @ 2006-11-28 16:10 UTC (permalink / raw)
To: git
In-Reply-To: <456C4FCE.6090306@shadowen.org>
On 11/28/06, Andy Whitcroft <apw@shadowen.org> wrote:
> Perhaps I want a rename to just put a rename from in the top
> of the new reflog and leave the old there.
That is what happens when you do
git branch -l topic master
The first entry in reflog for 'topic' will say:
Branch: created from master
--
^ permalink raw reply
* Re: Workflow example for remote repository use of GIT
From: Jakub Narebski @ 2006-11-28 16:18 UTC (permalink / raw)
To: git
In-Reply-To: <89b129c60611280708x10a9c42fia23e6b7770971838@mail.gmail.com>
Sean Kelley wrote:
> I have been trying to set-up a workflow for developers in my group
> using GIT. I came up with this simplified flow. Do you all see any
> problems with this approach?
>
> Thanks,
>
> Sean
>
>
>
> Always work out of master
>
> git checkout master
This conflicts a bit with later "Create a topic branch" statement.
The statement should be I think twofold: "Never work out of tracking
branches" (if you use separate remotes, git takes care of that for
yourself), and for typical workflow "Always work out of master
or merge changes into master".
This of course deopends on the structure of your repo. For example,
how many development branches are there. Git repository uses four
development branches: 'maint' (maintenance, stable, bugfixes),
'master' (trunk, main development, stable), 'next' (development)
and 'pu' (proposed updates, a kind of topic branch digest).
> Getting The Latest Upstream Code into master
>
> git pull origin master
It always is "merge into current branch".
Please read what this mean in git-pull(1):
? A parameter <ref> without a colon is equivalent to <ref>: when
pulling/fetching, so it merges <ref> into the current branch
without storing the remote branch anywhere locally.
So what "git pull origin master" do is to fetch _single_ remote branch
'master' from remote (repository) 'origin' _without_ storing it anywhere
locally (with separate remotes it would be 'remotes/origin/master',
without separate remotes it would be 'origin'), and merge it into _current_
branch.
What you usually want to do, when you are on branch "master", is
git pull origin
or even
git pull
> Create a topic branch for your development work
>
> git checkout -b <new topic branch name>
One might want to create topic branch off other commit than HEAD,
using
git checkout -b <new topic branch name> <branch point>
> Do your development in the topic branch
>
> edit/debug/test
>
> Committing Changes
>
> git commit -a
Depending on your project policy, it might be "git commit -a -s",
i.e. add signoff line.
> Switch back to master
>
> git checkout master
>
> Update the master branch from origin again
>
> git pull origin master
The same comment as above.
By the way, this is _not_ CVS, you can merge your topic branch first,
_then_ pull from origin.
> Now Merge your topic branch
>
> git pull . <topic branch to merge into current branch>
I'd point out that '.' means current repository here.
> How do I push my changes to the original repository?
>
> git push origin master
Probably (and better) just "git push origin" if everything is set up
correctly.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Andy Parkins @ 2006-11-28 16:29 UTC (permalink / raw)
To: git; +Cc: Shawn Pearce
In-Reply-To: <20061128154434.GD28337@spearce.org>
On Tuesday 2006 November 28 15:44, Shawn Pearce wrote:
> So HEAD in a submodule is the current content of that submodule.
> Therefore any update-index call on a submodule should load HEAD
> (totally ignoring whatever branch it refers to) into the supermodule
> index.
I was with you right up until here.
Why should a submodule do anything to the supermodule? This is like saying,
when I edit a working tree file, it should automatically call update-index.
The supermodule index should only be updated in response to a manual
update-index (or commit -a I suppose).
Worse, if you allow that to happen, the supermodule can commit a state that
cannot be retrieved from the submodule's repository. The ONLY thing a
supermodule can record about a submodule is a commit. Changing the index
doesn't create a commit, so it can't change anything in the supermodule.
If you change the submodule index then that submodule is "dirty", this state
has no parallel with normal git operation. The nearest thing is that you've
changed a file but not saved it. Apart from showing the "dirty" state in the
supermodule's git-status, I don't see that there is anything that the
supermodule can do - it can't go around committing in a repository that it
not itself.
IMO, it should always be possible to take a submodule and work on it in
isolation - in an extreme case, by moving it out of the supermodule tree
entirely.
In summary, from the supermodule's point of view:
* A submodule with changed working directory is "dirty-wd"
* A submodule with changed index is "dirty-idx" from the supermodule's
* A submodule with changed HEAD (since the last supermodule commit)
is "changed but not updated" and can hence be "update-index"ed into the
supermodule
* A submodule with changed HEAD that has been added to the supermodule index
is "updated but not checked in"
* A submodule with changed HEAD (since the last supermodule update-index) is
both "changed but not updated" _and_ "updated but not checked in", just
like any normal file.
What's needed then:
* A way of telling git to treat a particular directory as a submodule instead
of a directory
* git-status gets knowledge of how to check for "dirty" submodules
* git-commit-tree learns about how to store "submodule" object types in
trees. The submodule object type will be nothing more than the hash of the
current HEAD commit. (This might be my ignorance, perhaps it's just
update-index that needs to know this)
I don't know enough about the plumbing to know if my description above is
using the right nomenclature - I'm sure someone will correct me.
In my head, it would look something like this:
$ mkdir supermodule; cd supermodule
$ git init-db
$ git clone proto://host/submodule.git
$ git add --submodule submodule
$ git update-index submodule
$ git commit -m "Added submodule to supermodule"
[ edit submodule ]
$ git status
submodule is dirty, the working directory has changed
[ update-index in submodule ]
$ git status
submodule is dirty, the index has changed
[ commit in submodule ]
$ git status
submodule is changed but not updated
$ git update-index submodule
$ git status
submodule is updated but not checked in
$ git commit -m "Record submodule change in supermodule"
Am I crazy?
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Shawn Pearce @ 2006-11-28 16:36 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611281629.08636.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> wrote:
> On Tuesday 2006 November 28 15:44, Shawn Pearce wrote:
>
> > So HEAD in a submodule is the current content of that submodule.
> > Therefore any update-index call on a submodule should load HEAD
> > (totally ignoring whatever branch it refers to) into the supermodule
> > index.
>
> I was with you right up until here.
>
> Why should a submodule do anything to the supermodule? This is like saying,
> when I edit a working tree file, it should automatically call update-index.
> The supermodule index should only be updated in response to a manual
> update-index (or commit -a I suppose).
You misread my poorly written statement. :-)
What I meant to say was that update-index run in the supermodule
would load the submodule content into the supermodule index; much
as an update-index on a file would load the content of that file
into the index.
> IMO, it should always be possible to take a submodule and work on it in
> isolation - in an extreme case, by moving it out of the supermodule tree
> entirely.
Aside from sharing object directories, yes.
> In summary, from the supermodule's point of view:
> * A submodule with changed working directory is "dirty-wd"
> * A submodule with changed index is "dirty-idx" from the supermodule's
> * A submodule with changed HEAD (since the last supermodule commit)
> is "changed but not updated" and can hence be "update-index"ed into the
> supermodule
> * A submodule with changed HEAD that has been added to the supermodule index
> is "updated but not checked in"
> * A submodule with changed HEAD (since the last supermodule update-index) is
> both "changed but not updated" _and_ "updated but not checked in", just
> like any normal file.
>
> What's needed then:
> * A way of telling git to treat a particular directory as a submodule instead
> of a directory
> * git-status gets knowledge of how to check for "dirty" submodules
> * git-commit-tree learns about how to store "submodule" object types in
> trees. The submodule object type will be nothing more than the hash of the
> current HEAD commit. (This might be my ignorance, perhaps it's just
> update-index that needs to know this)
Err, uhm, more like git-write-tree. git-commit-tree doesn't
care about the tree content. And all of the tree reading code.
And all object traversal code (e.g. rev-list --objects). Martin
Waitz's submodule prototype has been working on those details.
Its non-trivial due to the number of locations affected.
> In my head, it would look something like this:
>
> $ mkdir supermodule; cd supermodule
> $ git init-db
> $ git clone proto://host/submodule.git
> $ git add --submodule submodule
> $ git update-index submodule
> $ git commit -m "Added submodule to supermodule"
> [ edit submodule ]
> $ git status
> submodule is dirty, the working directory has changed
> [ update-index in submodule ]
> $ git status
> submodule is dirty, the index has changed
> [ commit in submodule ]
> $ git status
> submodule is changed but not updated
> $ git update-index submodule
> $ git status
> submodule is updated but not checked in
> $ git commit -m "Record submodule change in supermodule"
Yes, exactly my thoughts on the matter.
> Am I crazy?
Maybe, but I'm not a shrink. Your email looked sane. :-)
--
^ permalink raw reply
* Re: [PATCH 1.2/2 (fixed)] git-svn: fix output reporting from the delta fetcher
From: Pazu @ 2006-11-28 16:56 UTC (permalink / raw)
To: Seth Falcon; +Cc: Eric Wong, git
In-Reply-To: <m2bqmr1rnw.fsf@ziti.fhcrc.org>
On 11/28/06, Seth Falcon <sethfalcon@gmail.com> wrote:
> Is CamelEar an empty directory (or was it an empty directory in the
> first fetch) by any chance?
No, neither. The directory isn't empty on the requested revision, nor
in the initial revision. Anyways…
I've tried to init and fetch the repository again, and guess what, it
worked. So my bet that this was caused by a broken connection during
the initial fetch was probably right -- I'll try to "force" a broken
connection and see what happens…
Hmmm.…
mini:/tmp pazu$ git-svn init
https://tech.bga.bunge.com/BungeHomeExt/GLS/trunk/java/bg-cam
mini:/tmp pazu$ git-svn fetch
A bg-cam.ipr
A CamelWeb/CamelWeb.iml
A CamelWeb/.classpath
A CamelWeb/JavaSource/.emptyDir
A CamelWeb/.serverPreference
A CamelWeb/.website-config
...
<<Here I turned AirPort off>>
Committing initial tree d14cd2aca9a6f15fdc8875212776c6a7cd111341
r8618 = 5a994a730da8dc8141fd116100a773061b7d4212
Creating fetcher for revision 5a994a730da8dc8141fd116100a773061b7d4212
Starting update on revision 9236
Opening CamelService/ejbModule/com/bunge/logistics/elevator/service/util/ElevatorConstants.java@8618
Error from SVN, (200003): Incomplete data: Delta source ended unexpectedly
When I deactivated AirPort, git-svn hang for a long while, but it
finally timed out and just saved what it got so far as the initial
revision. Then when git-svn tried to fetch the next revision, it ended
up trying to open a file that wasn't checked out during the (broken)
initial fetch.
Well, it seems I've found the problem. Unfortunately I have no idea
how to fix that… I'll read some subversion books and source code to
figure that out.
^ permalink raw reply
* Re: git and bzr
From: Aaron Bentley @ 2006-11-28 17:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: bazaar-ng, git, Johannes Schindelin, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0611280754050.30076@woody.osdl.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Linus Torvalds wrote:
> in order to realize how well git blame follows both renames _and_ pure
> data movement).
>
> The reason this is a good example is simply the fact that it should
> totally silence anybody who still thinks that tracking file identities is
> a good thing. It explains well why tracking file identities is just
> _stupid_.
No need to be aggressive about this. Yes, it's true that file identity
doesn't directly solve this problem, but it doesn't prove that an
identity-based approach is wrong.
In the end, everything comes down to identity of some kind. Because if
you're going to apply someone else's changes, you must apply them to the
same thing that they changed.
Git determines identity based on content, while bzr has the user
indicate it. Both approaches work.
Bzr supports merging based on line identity (our weave merge, not our
knit merge). At the moment, our concept of line identity is based on
file identity, but there's no reason it has to stay that way.
> You simply couldn't have done that kind of split sanely with file identity
> tracking (well, that one only had a single copy, so you could argue that a
> file identity tracker with copies could have done it, but the fact is that
> (a) they never do and (b) "git blame" can equally well track stuff that
> comes from _multiple_ different "file iddentities").
I think you're wrong about that. There's nothing stopping bzr from
inferring a file split, or even explicitly recording it. bzr doesn't
record copies, because we think there are no sane merge semantics across
copies.
> So yes, "git blame" is a _hell_ of a lot more powerful than anybody elses
> "annotate", as far as I know. I literally suspect that nobody else comes
> even close.
I notice that blame has an option to limit the annotation to recent
history. I can only assume that is for performance reasons. bzr
annotate doesn't need a feature like that, because annotations are
explicit in bzr's storage format. I expect that even if we were to
extend annotate to track content across files, it would still be so fast
that we wouldn't need it.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFFbGy70F+nu1YWqI0RAt75AKCAy0ALi0IKzqZpgnavJrx97+lhDgCfaMSe
fs4Lt77k1/OXC82aFbh5pKg=
=/OiA
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH 1/2] Teach bash how to complete long options for git-commit.
From: Shawn O. Pearce @ 2006-11-28 17:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
It appears as though this patch was dropped, probably due
to the fact that paint commonly dries faster than tab
completion of --author= on the kernel.git repository runs.
So this is a resubmit without the paint drying features.
contrib/completion/git-completion.bash | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index d8ae4d7..be978cf 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -398,6 +398,20 @@ _git_cherry_pick ()
esac
}
+_git_commit ()
+{
+ local cur="${COMP_WORDS[COMP_CWORD]}"
+ case "$cur" in
+ --*)
+ COMPREPLY=($(compgen -W "
+ --all --author= --signoff --verify --no-verify
+ --edit --amend --include --only
+ " -- "$cur"))
+ return
+ esac
+ COMPREPLY=()
+}
+
_git_diff ()
{
__git_complete_file
@@ -768,6 +782,7 @@ _git ()
cat-file) _git_cat_file ;;
checkout) _git_checkout ;;
cherry-pick) _git_cherry_pick ;;
+ commit) _git_commit ;;
diff) _git_diff ;;
diff-tree) _git_diff_tree ;;
fetch) _git_fetch ;;
@@ -804,6 +819,7 @@ complete -o default -F _git_branch git-branch
complete -o default -o nospace -F _git_cat_file git-cat-file
complete -o default -F _git_checkout git-checkout
complete -o default -F _git_cherry_pick git-cherry-pick
+complete -o default -F _git_commit git-commit
complete -o default -o nospace -F _git_diff git-diff
complete -o default -F _git_diff_tree git-diff-tree
complete -o default -o nospace -F _git_fetch git-fetch
--
1.4.4.1.g289c2
^ permalink raw reply related
* [PATCH 2/2] Fix broken bash completion of local refs.
From: Shawn O. Pearce @ 2006-11-28 17:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <a7f722557e34d86c38da7163392e3be8021692e2.1164733875.git.spearce@spearce.org>
Commit 35e65ecc broke completion of local refs, e.g. "git pull . fo<tab>"
no longer would complete to "foo". Instead it printed out an internal
git error ("fatal: Not a git repository: '.'").
The break occurred when I tried to improve performance by switching from
git-peek-remote to git-for-each-ref. Apparently git-peek-remote will
drop into directory "$1/.git" (where $1 is its first parameter) if it
is given a repository with a working directory. This allowed the bash
completion code to work properly even though it was not handing over
the true repository directory.
So now we do a stat in bash to see if we need to add "/.git" to the
path string before running any command with --git-dir.
I also tried to optimize away two "git rev-parse --git-dir" invocations
in common cases like "git log fo<tab>" as typically the user is in the
top level directory of their project and therefore the .git subdirectory
is in the current working directory. This should make a difference on
systems where fork+exec might take a little while.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
This fixes the breakage noticed by Junio.
contrib/completion/git-completion.bash | 37 ++++++++++++++++---------------
1 files changed, 19 insertions(+), 18 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index be978cf..447ec20 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -34,7 +34,19 @@
__gitdir ()
{
- echo "${__git_dir:-$(git rev-parse --git-dir 2>/dev/null)}"
+ if [ -z "$1" ]; then
+ if [ -n "$__git_dir" ]; then
+ echo "$__git_dir"
+ elif [ -d .git ]; then
+ echo .git
+ else
+ git rev-parse --git-dir 2>/dev/null
+ fi
+ elif [ -d "$1/.git" ]; then
+ echo "$1/.git"
+ else
+ echo "$1"
+ fi
}
__git_ps1 ()
@@ -51,7 +63,7 @@ __git_ps1 ()
__git_heads ()
{
- local cmd i is_hash=y dir="${1:-$(__gitdir)}"
+ local cmd i is_hash=y dir="$(__gitdir "$1")"
if [ -d "$dir" ]; then
for i in $(git --git-dir="$dir" \
for-each-ref --format='%(refname)' \
@@ -60,7 +72,7 @@ __git_heads ()
done
return
fi
- for i in $(git-ls-remote "$dir" 2>/dev/null); do
+ for i in $(git-ls-remote "$1" 2>/dev/null); do
case "$is_hash,$i" in
y,*) is_hash=n ;;
n,*^{}) is_hash=y ;;
@@ -72,7 +84,7 @@ __git_heads ()
__git_refs ()
{
- local cmd i is_hash=y dir="${1:-$(__gitdir)}"
+ local cmd i is_hash=y dir="$(__gitdir "$1")"
if [ -d "$dir" ]; then
if [ -e "$dir/HEAD" ]; then echo HEAD; fi
for i in $(git --git-dir="$dir" \
@@ -101,20 +113,9 @@ __git_refs ()
__git_refs2 ()
{
- local cmd i is_hash=y dir="${1:-$(__gitdir)}"
- if [ -d "$dir" ]; then
- cmd=git-peek-remote
- else
- cmd=git-ls-remote
- fi
- for i in $($cmd "$dir" 2>/dev/null); do
- case "$is_hash,$i" in
- y,*) is_hash=n ;;
- n,*^{}) is_hash=y ;;
- n,refs/tags/*) is_hash=y; echo "${i#refs/tags/}:${i#refs/tags/}" ;;
- n,refs/heads/*) is_hash=y; echo "${i#refs/heads/}:${i#refs/heads/}" ;;
- n,*) is_hash=y; echo "$i:$i" ;;
- esac
+ local i
+ for i in $(__git_refs "$1"); do
+ echo "$i:$i"
done
}
--
^ permalink raw reply related
* Re: git and bzr
From: Jakub Narebski @ 2006-11-28 17:29 UTC (permalink / raw)
To: bazaar-ng; +Cc: git
In-Reply-To: <456C6CBB.70702@utoronto.ca>
Aaron Bentley wrote:
> Linus Torvalds wrote:
>> So yes, "git blame" is a _hell_ of a lot more powerful than anybody elses
>> "annotate", as far as I know. I literally suspect that nobody else comes
>> even close.
Well without the content based detection of contents copying and moving
which git-blame wouldn't work as well as it work now.
> I notice that blame has an option to limit the annotation to recent
> history. I can only assume that is for performance reasons. bzr
> annotate doesn't need a feature like that, because annotations are
> explicit in bzr's storage format.
But you don't have content movement tracking.
>
> I expect that even if we were to
> extend annotate to track content across files, it would still be so fast
> that we wouldn't need it.
I think not.
The first example:
$ time git blame -C revision.c >/dev/null
real 0m7.577s
user 0m7.248s
sys 0m0.020s
while without content copying and moving detection we have
$ time git blame revision.c >/dev/null
real 0m2.108s
user 0m2.044s
sys 0m0.024s
(on 2000 BogoMIPS CPU).
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Daniel Barkalow @ 2006-11-28 17:28 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Linus Torvalds, Yann Dirson, Steven Grimm, git
In-Reply-To: <456C0313.3020308@op5.se>
On Tue, 28 Nov 2006, Andreas Ericsson wrote:
> Daniel Barkalow wrote:
> > On Sat, 25 Nov 2006, Linus Torvalds wrote:
> > > I'd actually suggest that "git commit -a" with non-clean submodules error
> > > out for that reason
> >
> > Just have it run "git commit -a" in each dirty submodule recursively as part
> > of preparing the index, since that's what the user wants to do anyway, and
> > nothing already done would be affected.
> >
>
> Running "commit -a" is definitely the wrong thing to do, as it prevents one
> from using the index at all. Erroring out if the submodules are dirty, or just
> accepting the fact that they are and taking whatever commit HEAD points to is
> *always* preferrable.
I don't think anyone would actually use the index in submodules but not in
the supermodule. If submodules are seen mostly as ordinary directories as
far as the supermodule's working directory is concerned, it wouldn't make
sense to not commit dirty state in a subdirectory with -a just because
it's a submodule.
It would be wrong to do "commit -a" in submodules if the supermodule
weren't being committed with -a, of course.
> > "git commit -a -m <message>" should probably fail, of course.
> >
>
> Why? There's no reason to rob this command of its power just because we're
> using submodules.
It should fail if there are dirty submodules, because the user needs to
provide a commit message for each of them, and only one commit message can
be provided this way, and -m inhibits invoking an editor.
-Daniel
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Jon Loeliger @ 2006-11-28 17:38 UTC (permalink / raw)
To: Andy Parkins; +Cc: Git List, Shawn Pearce
In-Reply-To: <200611281629.08636.andyparkins@gmail.com>
On Tue, 2006-11-28 at 10:29, Andy Parkins wrote:
> IMO, it should always be possible to take a submodule and work on it in
> isolation - in an extreme case, by moving it out of the supermodule tree
> entirely.
This seems to me to be tantamount to saying something like:
We need a "recursively defined git repository" that
is representable as a git repository.
That is, can the tree object be changed from containing
just "blob" and "tree" references to also having a new
"git" reference as well?
jdl
^ permalink raw reply
* Re: git and bzr
From: Nicholas Allen @ 2006-11-28 17:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, bazaar-ng, git, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0611280754050.30076@woody.osdl.org>
>
> The reason this is a good example is simply the fact that it should
> totally silence anybody who still thinks that tracking file identities is
> a good thing. It explains well why tracking file identities is just
> _stupid_.
I'm unfamiliar with git so I could be totally wrong here!
I know that bzr supports file renames/moves very effectively and I
understood that git doesn't support this to the same extent (correct me
if I am wrong as I have not used git at all!).
If that is the case, could that be because bzr gives each file its own
id and can detect this easily but git's content based approach can't? If
so then claiming file identifiers is *stupid* seems a bit extreme. So I
would have thought *both* file identifiers and line/content identifiers
are needed for tracking changes made to the files and to their contents
respectively. When a file is copied then the contents are copied and it
is given a new file identifier. When a file is moved it keeps the same
identifier. So don't you need file identifiers as well as line/content
identifiers?
^ permalink raw reply
* Re: git and bzr
From: Linus Torvalds @ 2006-11-28 18:00 UTC (permalink / raw)
To: Aaron Bentley; +Cc: bazaar-ng, git, Johannes Schindelin, Jakub Narebski
In-Reply-To: <456C6CBB.70702@utoronto.ca>
On Tue, 28 Nov 2006, Aaron Bentley wrote:
>
> I notice that blame has an option to limit the annotation to recent
> history. I can only assume that is for performance reasons.
You'd assume wrong.
Trust me, if you talk about performance, bzr will lose. I can pretty much
guarantee you that you perform worse. The mozilla discussion pointed to a
performance test between hg and bzr, and hg in that test tended to perform
better by a factor of 2-10. And git tends to be another factor faster than
_that_.
Performance is important to git, but it's important not in the sense of
"let's not do it because it performs badly", but in the sense of "things
should be so fast that people don't even realize that they are done". You
guys may count commit times in seconds. I still want to commit multiple
patches _per_second_ to the kernel tree. THAT is performance.
So no, performance wasn't the reason.
The reason is simple: be logical. The original blame/annotate semantics
were
git blame filename
which is what people traditionally use, but then to specify which version
to _start_ with (in case you wanted to go backwards in time), you had an
optional revision argument at the end.
Which is totally against how all the other git programs work, and I
complained, because I had actually wanted to see the blame at a particular
release version, and what my fingers typed didn't work. I want to be able
to do
git blame [revno] [--] filename
the same way I can ask for a git log, git whatchanged, gitk, and any
other such history tool.
And once you do the same command line parsin as the other log-related
commands, you pretty much automatically get the revision limiting. So now
you can do
git blame v2.6.17..v2.6.18 filename
on the kernel archive to see who is to blame for certain lines in a
certain _range_ of commits. It just fell out of using the same syntax
everywhere.
It's also happens to be useful. Quite often, you know something broke
after a particular known-good release, so you're interested in the blame,
but anything older than that known-good release is simply noise, and
actually takes AWAY from the information, by just making things more
cluttered.
Linus
^ permalink raw reply
* Re: git and bzr
From: Jakub Narebski @ 2006-11-28 18:06 UTC (permalink / raw)
To: git; +Cc: bazaar-ng
In-Reply-To: <456C7592.6020700@ableton.com>
Nicholas Allen wrote:
>> The reason this is a good example is simply the fact that it should
>> totally silence anybody who still thinks that tracking file identities is
>> a good thing. It explains well why tracking file identities is just
>> _stupid_.
>
> I'm unfamiliar with git so I could be totally wrong here!
>
> I know that bzr supports file renames/moves very effectively and I
This means: _usually_ works, doesn't it? Emphasisis on "usually"?
> understood that git doesn't support this to the same extent (correct me
> if I am wrong as I have not used git at all!).
Git supports renames/moves in different way. Instead of recording renames
(which has trouble on it's own, for example rename via applying patch)
in the repository it _detect_ renames when needed.
> If that is the case, could that be because bzr gives each file its own
> id and can detect this easily but git's content based approach can't? If
> so then claiming file identifiers is *stupid* seems a bit extreme. So I
> would have thought *both* file identifiers and line/content identifiers
> are needed for tracking changes made to the files and to their contents
> respectively. When a file is copied then the contents are copied and it
> is given a new file identifier. When a file is moved it keeps the same
> identifier. So don't you need file identifiers as well as line/content
> identifiers?
There are trouble with file-ids. Most common example is trouble with file
which was created in two branches (two repositories) independently, then
branches got merged. Most (all?) file-id based rename detection has trouble
with repeated merging of those branches, even if there are no true
conflicts.
Read Linus post about file-id based rename detection:
Message-ID: <Pine.LNX.4.64.0610201049250.3962@g5.osdl.org>
http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/18458
Not that contents based rename detection doesn have it's own pitfals:
Message-ID: <7virha4cnm.fsf@assigned-by-dhcp.cox.net>
http://permalink.gmane.org/gmane.comp.version-control.git/31899
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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