* Re: git-name-rev off-by-one bug
From: Daniel Barkalow @ 2005-11-30 18:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux, junkio, git, pasky
In-Reply-To: <Pine.LNX.4.64.0511291742000.3135@g5.osdl.org>
On Tue, 29 Nov 2005, Linus Torvalds wrote:
> If we left things in the index in an unmerged state, we'd be guaranteed to
> either _fail_ that git commit unless somebody has done the
> git-update-index (or names the files specifically on the commit command
> line, which will do it for you).
At this point, we could have a "git-merged-by-hand" script that would take
filenames, check that they're unmerged now, and, if so, call
git-update-index for them. And it could have a -a to do all of the
unmerged entries (i.e., "I'm done merging by hand"), and maybe also have a
flag to git-commit that does this, so you can say, "Commit the merge I did
by hand, whatever filenames it used, but not any other changes I may have
had beforehand."
The "merged-by-hand" script would probably be a sensible place to complain
about leftover conflict markers (unless you force it).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git-name-rev off-by-one bug
From: Daniel Barkalow @ 2005-11-30 17:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: linux, git
In-Reply-To: <7vhd9wngn6.fsf@assigned-by-dhcp.cox.net>
On Mon, 28 Nov 2005, Junio C Hamano wrote:
> *1* It is a shame that the most comprehensive definition of
> 3-way read-tree semantics is in t/t1000-read-tree-m-3way.sh test
> script.
Isn't Documentation/technical/trivial-merge.txt more comprehensive?
Probably the tables in various other places should be replaced with
references to this document.
-Daniel
^ permalink raw reply
* Re: Question about handling of heterogeneous repositories
From: Josef Weidendorfer @ 2005-11-30 16:49 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Johannes Schindelin
In-Reply-To: <81b0412b0511300701w71da125am2dcc896b4693f37f@mail.gmail.com>
On Wednesday 30 November 2005 16:01, Alex Riesen wrote:
> On 11/30/05, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> > git-mv could support this. Additional to deleting from
> > one repository and adding to the new, it could generate a remark for
> > the commit message, like:
> >
> > Added file xxx is from remote repo '/path/myrepo' with name 'yyy'
> > (file SHA1: 123445... from remote commit SHA1: 345667...)
>
> That's sounds very tempting to special-case for nested repos :)
If the repo path is an URL, this works quite general. I tried
to avoid adding local head names to this remark...
> Maybe use .git/objects/info/alternates in top-level repo?
Or better the .git/remotes namespace...
Still, this is misusing repo-local config for multiple repos.
Seems quite confusing for me.
> It may
> have side-effects of the new objects ending up in top-level repo
> if commited from top-level directory. Even then, the tools can
> be tought to stop looking for GIT_DIR in the directory closest
> to the file being commited:
> $ pwd
> .../top
> $ git-commit sub1/dir/file
> ... uses repo in .../top/sub1 instead of $(pwd)/../top/.git
>
> Looks very messy, with a potential for lots of corner cases and
> not that tempting anymore :(
git-mv would have to do exactly something like this to detect
inter-repo renames at all ;-)
But in general, this is really messy.
See my suggestion in a previous thread with similar topic
http://www.gelato.unsw.edu.au/archives/git/0511/12028.html
Josef
^ permalink raw reply
* Re: git-name-rev off-by-one bug
From: Linus Torvalds @ 2005-11-30 16:12 UTC (permalink / raw)
To: linux; +Cc: junkio, git, pasky
In-Reply-To: <20051130060906.13277.qmail@science.horizon.com>
On Tue, 30 Nov 2005, linux@horizon.com wrote:
>
> > +-0 -1 -2::
> > + When an unmerged entry is seen, diff against the base version,
> > + the "first branch" or the "second branch" respectively.
> > +
> > + The default is to diff against the first branch.
>
> Er... why are these flags zero-based?
Because it makes more sense from a "git diff" standpoint to do that.
The fact that _internally_, git puts the first branch into "stage 2", and
the second one into "stage 3", that's very much a internal git
implementation issue that makes no sense to expose to a regular user.
> git-ls-files -s displays them as "1", "2" and "3". All the docs talk
> about "stage1", "stage2" and "stage3".
Yes, but those are _technical_ docs, not docs aimed toward a user. Nobody
sane uses "git-ls-files --stage" outside of a script, or unless they
really know git and are trying to debug something.
>From a user standpoint, it makes a lot more sense to say "primary branch"
and "other branch" , and then "-1" and "-2" make sense (and then the "base
of the merge" makes sense as "-0").
Linus
^ permalink raw reply
* Re: git-name-rev off-by-one bug
From: Linus Torvalds @ 2005-11-30 16:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vek4y1x79.fsf@assigned-by-dhcp.cox.net>
On Tue, 29 Nov 2005, Junio C Hamano wrote:
>
> Actually there is one. If we are asked to do diff -1 and an
> unmerged path does not have stage #2 but stage #1 entry exists,
> we would end up showing that stage #1, without telling the user
> that we are showing something different from what was asked.
> How about doing something like this, on top of yours?
Yes.
Linus
^ permalink raw reply
* Re: git-name-rev off-by-one bug
From: Linus Torvalds @ 2005-11-30 16:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslte1y5z.fsf@assigned-by-dhcp.cox.net>
On Tue, 29 Nov 2005, Junio C Hamano wrote:
>
> About #3, I am not quite sure. I often use --name-status and I
> do _not_ want -p to kick in when I do so. How about something
> like this?
Yes. I was thinking about something like that, but I decided it was too
much work ;)
Linus
^ permalink raw reply
* [PATCH] Do not attempt to access literal dirname "GIT_OBJECT_DIRECTORY".
From: Tommi Virtanen @ 2005-11-30 15:37 UTC (permalink / raw)
To: git; +Cc: Tommi Virtanen
Dereference the environment variable before using it.
Signed-off-by: Tommi Virtanen <tv@inoi.fi>
---
setup.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
applies-to: fa10b18d1546129bf73713b64fbc4a8feae3487f
a4a0e60f920f906284f4f6a4d3b4ffb043834bc7
diff --git a/setup.c b/setup.c
index cc44a72..3286a56 100644
--- a/setup.c
+++ b/setup.c
@@ -116,7 +116,7 @@ static const char *setup_git_directory_1
if (validate_symref(path))
goto bad_dir_environ;
if (getenv(DB_ENVIRONMENT)) {
- if (access(DB_ENVIRONMENT, X_OK))
+ if (access(getenv(DB_ENVIRONMENT), X_OK))
goto bad_dir_environ;
}
else {
---
0.99.9.GIT
^ permalink raw reply related
* Re: Question about handling of heterogeneous repositories
From: Alex Riesen @ 2005-11-30 15:01 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git, Johannes Schindelin
In-Reply-To: <200511301540.34776.Josef.Weidendorfer@gmx.de>
On 11/30/05, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> git-mv could support this. Additional to deleting from
> one repository and adding to the new, it could generate a remark for
> the commit message, like:
>
> Added file xxx is from remote repo '/path/myrepo' with name 'yyy'
> (file SHA1: 123445... from remote commit SHA1: 345667...)
That's sounds very tempting to special-case for nested repos :)
Maybe use .git/objects/info/alternates in top-level repo? It may
have side-effects of the new objects ending up in top-level repo
if commited from top-level directory. Even then, the tools can
be tought to stop looking for GIT_DIR in the directory closest
to the file being commited:
$ pwd
.../top
$ git-commit sub1/dir/file
... uses repo in .../top/sub1 instead of $(pwd)/../top/.git
Looks very messy, with a potential for lots of corner cases and
not that tempting anymore :(
> This info could be interesting both for humans and a history browsing tool.
> The tool still would have to know where to look for repo '/path/myrepo'.
> It could also work for moving subdirectories (ie. trees instead of files).
Well, these are just lots of files. I can't really think of case were
I'd need to know about moving a directory without knowing what
happened to the files.
>
> Josef
>
^ permalink raw reply
* Re: [PATCH] Make git-mv work in subdirectories, too
From: Josef Weidendorfer @ 2005-11-30 14:50 UTC (permalink / raw)
To: git, Alex Riesen; +Cc: Junio C Hamano, Johannes Schindelin
In-Reply-To: <20051129221024.GB3033@steel.home>
On Tuesday 29 November 2005 23:10, Alex Riesen wrote:
> It actually works in subdirs.
>
> --- t/t4007-mv.sh
> test_expect_success \
> 'moving the file' \
> 'cd path0 && git-mv COPYING ../path1/COPYING'
Thanks for the test.
After moving to path1, you should check the other way, too:
cd path0 && git-mv ../path1/COPYING COPYING
And this currenly does *not* work because git-mv is only aware
of the git-controlled files in the subdirectory.
We probably also should check that source and target are in the
same git repo.
Josef
^ permalink raw reply
* Re: Question about handling of heterogeneous repositories
From: Josef Weidendorfer @ 2005-11-30 14:40 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Alex Riesen
In-Reply-To: <Pine.LNX.4.63.0511301457040.2284@wbgn013.biozentrum.uni-wuerzburg.de>
On Wednesday 30 November 2005 14:58, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 30 Nov 2005, Alex Riesen wrote:
>
> > On 11/30/05, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> > >
> > > To detect inter-repository renaming, one has to see both repositories.
> > > Currently, git/cogito etc. commands only work with one repository
> > > only.
> >
> > This case is somewhat special: one is _guaranteed_ to see both
> > repositories.
>
> It is even more so: it is guaranteed that git cannot reconstruct this
> as a move operation.
Say it in another way: because currently, git commands only work in the
scope of one repository, there is no need to want to detect an
inter-repository rename.
Git has no explicit support for renaming, but can do it. Why should it
be a problem to write a tool which is able to detect inter-repository
renames? Still, such a search probably would be very expensive.
git-mv could support this. Additional to deleting from
one repository and adding to the new, it could generate a remark for
the commit message, like:
Added file xxx is from remote repo '/path/myrepo' with name 'yyy'
(file SHA1: 123445... from remote commit SHA1: 345667...)
This info could be interesting both for humans and a history browsing tool.
The tool still would have to know where to look for repo '/path/myrepo'.
It could also work for moving subdirectories (ie. trees instead of files).
Josef
^ permalink raw reply
* GIT_OBJECT_DIRECTORY handling broken on master.kernel.org?
From: David Woodhouse @ 2005-11-30 13:59 UTC (permalink / raw)
To: git
Daily kernel snapshots broke again. Trying to access, literally, "GIT_OBJECT_DIRECTORY".
hera /home/dwmw2 $ export GIT_DIR=/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
hera /home/dwmw2 $ git-rev-parse --revs-only 00d7a7358e3f9f2575501674e604fe4c6700b365
00d7a7358e3f9f2575501674e604fe4c6700b365
hera /home/dwmw2 $ export GIT_OBJECT_DIRECTORY=/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects
hera /home/dwmw2 $ git-rev-parse --revs-only 00d7a7358e3f9f2575501674e604fe4c6700b365
fatal: Not a git repository: '/pub/scm/linux/kernel/git/torvalds/linux-2.6.git'
hera /home/dwmw2 $ strace git-rev-parse --revs-only 00d7a7358e3f9f2575501674e604fe4c6700b365 2>&1 | tail
access("/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs", X_OK) = 0
lstat64("/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/HEAD", {st_mode=S_IFLNK|0777, st_size=17, ...}) = 0
readlink("/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/HEAD", "refs/heads/master", 255) = 17
access("GIT_OBJECT_DIRECTORY", X_OK) = -1 ENOENT (No such file or directory)
write(2, "fatal: ", 7fatal: ) = 7
write(2, "Not a git repository: \'/pub/scm/"..., 72Not a git repository: '/pub/scm/linux/kernel/git/torvalds/linux-2.6.git') = 72
write(2, "\n", 1
) = 1
exit_group(128) = ?
Process 30646 detached
--
dwmw2
^ permalink raw reply
* Re: Question about handling of heterogeneous repositories
From: Johannes Schindelin @ 2005-11-30 13:58 UTC (permalink / raw)
To: Alex Riesen; +Cc: Josef Weidendorfer, git
In-Reply-To: <81b0412b0511300515u5d2840ccv92be6e374dd795be@mail.gmail.com>
Hi,
On Wed, 30 Nov 2005, Alex Riesen wrote:
> On 11/30/05, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> >
> > To detect inter-repository renaming, one has to see both repositories.
> > Currently, git/cogito etc. commands only work with one repository
> > only.
>
> This case is somewhat special: one is _guaranteed_ to see both
> repositories.
It is even more so: it is guaranteed that git cannot reconstruct this
as a move operation.
Hth,
Dscho
^ permalink raw reply
* Re: Question about handling of heterogeneous repositories
From: Alex Riesen @ 2005-11-30 13:15 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200511301405.19541.Josef.Weidendorfer@gmx.de>
On 11/30/05, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> > BTW, how does git-mv behave for out-of-tree renaming? How about
> > inter-repo renaming (remove+add)?
>
> git-mv will fail. The source has to appear in git-ls-files, and the
> target simply is given to "git-update-index -add", which will return an
> 'outside repository' error. Hmmm... git-mv should check this itself.
>
> To detect inter-repository renaming, one has to see both repositories.
> Currently, git/cogito etc. commands only work with one repository only.
This case is somewhat special: one is _guaranteed_ to see both repositories.
PS: Im'restoring git@vger.kernel.org in cc-list, the discussion could be useful
^ permalink raw reply
* More merge questions
From: linux @ 2005-11-30 13:10 UTC (permalink / raw)
To: git; +Cc: junkio, linux
In-Reply-To: <7vwtiqzljr.fsf@assigned-by-dhcp.cox.net>
I'm working my way through a thorough understanding of merging.
First I got git-read-tree's 3-way merge down to 6 conditionals, where
a missing entry is considered equal to a missing entry, and a missing
index entry is considered clean.
a) If stage2 == stage3, use stage2
b) If stage1 == stage3, use stage2
c) If the index entry exists and is dirty (working dir changes), FAIL
d) If stage1 == stage2, use stage3
e) If trivial-only, FAIL
f) Return unmerged result for 3-way resolution by git-merge-index.
Case c is needed so you don't change the world out from under
your working directory changes. You could move it earlier and
make things strictire, but that's the minimal restriction.
Then I started thinking about 2-way merge, and how that differed
from a 3-way merge where stage2 was the previous index contents.
If you apply the same rules (with trivial-only true), the only differences
to the big 22-case table in the git-read-tree docs are:
3) This says that if stage1 and state3 exist, use stage3.
3-way says if they're equal, delete the file, while if they're
unequal, it's fail.
If 3-way git-merge-index were allowed, then the conditions that would
change to do it are cases 8 and 12.
The full list of cases and the conditional that applies, is:
0) a
1) d
2) a
3) see above. It's b or e by my logic, but d by the table.
4) b
5) b
6) a
7) a
8) e
9) c
10) d
11) c
12) e
13) c
14) a or b
15) a or b
16) e
17) c
18) a
19) a
20) d
21) c
Given that it all matches up so nicely, I'd like to honestly ask if
case 3 of the conditions is correct. I'd think that if I deleted
a file form te index, and the file wasn't changed on the head I'm
tracking, the right resolution is to keep it deleted. Why override
my deletion?
Sorry if this is a dumb question, but it's not obvious to me.
^ permalink raw reply
* Re: git-name-rev off-by-one bug
From: Junio C Hamano @ 2005-11-30 9:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vfypey573.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> What does "git-diff-files" do? Just output a lot of nasty "unmerged"
>> messages?
>
> That was not what was unpleasant. What was unpleasant was those
> "unmerged" messages were buried under heap of normal diffs,
> showing the successfully merged entries as the result of merge.
Correction. The above is a faulty memory, and does not happen,
with or without your "stage0 or stage2" patch. Cleanly merged
paths are written out to working tree and collapsed to stage0 in
the index, so diff-files wouldn't have shown them at all.
Sorry about the confused statement. What I saw was my local
modifications on the paths unrelated to the merge.
^ permalink raw reply
* Re: git-name-rev off-by-one bug
From: Junio C Hamano @ 2005-11-30 9:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vfypey573.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> On Tue, 29 Nov 2005, Junio C Hamano wrote:
>>>
>>> I have actually resolved one conflicting merge with this and it
>>> was OK, except that it was a bit unpleasant when I first did
>>> "git-diff-index HEAD" without giving any path ;-),
>>
>> What does "git-diff-files" do? Just output a lot of nasty "unmerged"
>> messages?
>
> That was not what was unpleasant. What was unpleasant was those
> "unmerged" messages were buried under heap of normal diffs,
> showing the successfully merged entries as the result of merge.
>
> I am inclined to munge your patch to do this:
This I have done, and pushed out to "pu" for tonight. After
doing some more test I'll have this graduate to "master"
sometime tomorrow along with other accumulated changes.
^ permalink raw reply
* Re: git-name-rev off-by-one bug
From: Junio C Hamano @ 2005-11-30 8:37 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <7voe43iyyu.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> On a related topic of removing unwanted paths, earlier I said
> 2-way is used to make sure "git checkout" takes your changes
> with you when you switch branches. As a natural consequence of
> this, if you do not have any local changes, "git checkout"
> without "-f" does the right thing -- it removes unwanted paths
> that existed in the original branch but not in the branch you
> are switching to.
Here is an unsolicited advice ("tip of the day").
I was on a branch which had some local "throwaway" changes, and
I wanted to switch back to the master branch. To be honest, I
even forgot I had local changes there. So I ran "git checkout",
and here is what happened.
junio@siamese:~/git$ git checkout master
fatal: Entry 'Documentat...' not uptodate. Cannot merge.
The easiest is "git checkout -f master" at this point, but I
usually do not do that. If that entry "git checkout" complains
about is something that is not in the master branch and I have
throwaway changes, "git checkout -f master" would leave that
file with throwaway changes behind. So I did this first:
junio@siamese:~/git$ git reset --hard
This would sync my working tree to the current branch. Then
junio@siamese:~/git$ git checkout master
would switch branches properly, removing that new file that
should not exist in the working tree.
^ permalink raw reply
* Re: [PATCH] SVN import: Use one log call
From: Matthias Urlichs @ 2005-11-30 8:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtiqwoy7.fsf@assigned-by-dhcp.cox.net>
Hi,
Junio C Hamano:
> $ git svnimport -T main/sources \
> http://127.0.0.1/svn/private/main/sources/photocat
>
> seems to be doing something. But I do not understand why. How
> did you decide "-T main/sources" is good for my case while "-T
> main/brltty" is good for Nicolas? I would have guessed you may
> say "-T main" for Nicolas, dropping the last path component.
>
What git-svnimport does right now is rather simple. It pulls the log
from the SVN URL, drops everything that does not have a prefix of either
of the -t tags -T trunk -b branches options. The prefix is then thrown
away. If it's a trunk, import the rest to the "origin" branch; otherwise
remove the next path component and use that as either the branch name
or the tag name.
The point is that the picture in the SVN manual is incomplete.
There's not just a branches/ subdirectory alongside the trunk/ one;
trunk/ directly contains the project's files, while branches/ contains
subdirectories which are named for the branch, and *they* contain the
files.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
If you're looking ahead long-term, and what you see looks like
science fiction, it might be wrong. But if it doesn't look like
science fiction, it's definitely wrong...
-- Christine Peterson,
^ permalink raw reply
* Re: [PATCH] SVN import: Use one log call
From: Junio C Hamano @ 2005-11-30 7:54 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <20051130065241.GY20418@kiste.smurf.noris.de>
Matthias Urlichs <smurf@smurf.noris.de> writes:
> Nicolas Pitre:
>> Same here, with the following public repo: svn://mielke.cc/main/brltty
>>
> Same thing -- should work with a "-T main/brltty" option.
So would the full command line be like this?
$ rm -rf try1; mkdir try1; cd try1
$ git-svnimport -T main/brltty svn://mielke.cc/main/brltty
I realize my first attempt was incorrectly using "-t" (tags)
instead of "-T" (trunk), which was obviously incorrect, but
replacing that lowercase -t with -T did not work well. However,
as you told me:
$ git svnimport -T main/sources \
http://127.0.0.1/svn/private/main/sources/photocat
seems to be doing something. But I do not understand why. How
did you decide "-T main/sources" is good for my case while "-T
main/brltty" is good for Nicolas? I would have guessed you may
say "-T main" for Nicolas, dropping the last path component.
^ permalink raw reply
* Re: git-name-rev off-by-one bug
From: Junio C Hamano @ 2005-11-30 7:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511291852530.3099@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Tue, 29 Nov 2005, Junio C Hamano wrote:
>>
>> I have actually resolved one conflicting merge with this and it
>> was OK, except that it was a bit unpleasant when I first did
>> "git-diff-index HEAD" without giving any path ;-),
>
> What does "git-diff-files" do? Just output a lot of nasty "unmerged"
> messages?
That was not what was unpleasant. What was unpleasant was those
"unmerged" messages were buried under heap of normal diffs,
showing the successfully merged entries as the result of merge.
I am inclined to munge your patch to do this:
* Change -0/-1/-2 to -1/-2/-3 to be consistent with stage
numbers, for technically minded.
* Give --base, --ours, and --theirs as synonyms for -1/-2/-3,
for end users.
* Change it not to pick other unmerged stage (I sent a separate
message about this already).
* Change the diff_unmerged_stage default to 0. While you are
inspecting a conflicted merge, you need to give --ours (or
-2) explicitly. Alternatively we could first check if the
whole index is unmerged and make it default to 2 without
flags, but that would mean inspecting 19K entries first
before starting the main loop for the kernel for normal case.
With hot cache it is fine, so I'll try it first.
This "with unmerged defaults to 2 otherwise defaults to 0"
behaviour needs to be made overridable with an option, say -0
(or --merged, but that is overkill); otherwise you cannot get
diffs for merged paths until the index file is unmerged.
* When diff_unmerged_stage is zero, keep the current behaviour.
Show diff for only specified stage when diff_unmerged_stage
is not zero.
^ permalink raw reply
* Re: [PATCH] SVN import: Use one log call
From: Matthias Urlichs @ 2005-11-30 6:52 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0511292247591.3122@localhost.localdomain>
Hi,
Nicolas Pitre:
> Same here, with the following public repo: svn://mielke.cc/main/brltty
>
Same thing -- should work with a "-T main/brltty" option.
> Thing is the above repository is not _that_ weird. And with the real
> svn it produces a proper source tree of course, without any special
> options. So I would think git-svnimport should be able to do the same.
> No?
Sure. The problem is that svn doesn't have tags, branches, or different
projects; it's all just subdirectories with linked files.
So you need a good mapping from one to the other. In principle that's
simple, it's just that nobody has written the code for a more flexible
mapping from svn paths to tags / branch+subpath yet.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
"Adam may not have been so perfect after the 'fall," but he was
not so big a fool."
[Lemuel K. Washburn, _Is The Bible Worth Reading
And Other Essays_]
^ permalink raw reply
* Re: git-name-rev off-by-one bug
From: Junio C Hamano @ 2005-11-30 6:39 UTC (permalink / raw)
To: linux; +Cc: junkio, torvalds, git, pasky
In-Reply-To: <20051130060906.13277.qmail@science.horizon.com>
linux@horizon.com writes:
>> +-0 -1 -2::
>> + When an unmerged entry is seen, diff against the base version,
>> + the "first branch" or the "second branch" respectively.
>> +
>> + The default is to diff against the first branch.
>> +
>
> Er... why are these flags zero-based?
Because -1 means "first branch" (usually "ours", aka HEAD), and
-2 means "second branch" ("theirs", aka MERGE_HEAD), and -0 is
for the base (aka merge base)?
But I think you are right. The numeric parameters should match
stage number for consistency.
How about if I redo the patch to make diff-files accept -1/-2/-3
instead, and in addition accept "--base", "--ours", and
"--theirs" as synonyms?
Side note. diff3 says MINE OLDER YOURS and the way to remember
the order is they are alphabetical. We can say the same for
base, ours and theirs.
^ permalink raw reply
* Re: git-name-rev off-by-one bug
From: Junio C Hamano @ 2005-11-30 6:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vslte1y5z.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> Whaddaya think? I really like it.
>
> Yes. Maybe split this into 3 pieces. I do not want to waste
> your time with that, so will take the liberty to do so myself,
> with appropriate commit log messages, if you do not mind.
>
> 1. give diff-files -[012] flags.
> 2. merge-one-file leaves unmerged index entries.
> 3. always use -M -p in git-diff.
>
> I do not have any issue against #1.
Actually there is one. If we are asked to do diff -1 and an
unmerged path does not have stage #2 but stage #1 entry exists,
we would end up showing that stage #1, without telling the user
that we are showing something different from what was asked.
How about doing something like this, on top of yours?
--- diff-files.c
+++ diff-files.c
@@ -117,8 +117,11 @@
*/
i--;
/*
- * Show the diff for the 'ce' we chose
+ * Show the diff for the 'ce' if we found the one
+ * from the desired stage.
*/
+ if (ce_stage(ce) != diff_unmerged_stage)
+ continue;
}
if (lstat(ce->name, &st) < 0) {
^ permalink raw reply
* Re: git-name-rev off-by-one bug
From: linux @ 2005-11-30 6:09 UTC (permalink / raw)
To: junkio, torvalds; +Cc: git, linux, pasky
In-Reply-To: <Pine.LNX.4.64.0511292031280.3099@g5.osdl.org>
> +-0 -1 -2::
> + When an unmerged entry is seen, diff against the base version,
> + the "first branch" or the "second branch" respectively.
> +
> + The default is to diff against the first branch.
> +
Er... why are these flags zero-based?
git-ls-files -s displays them as "1", "2" and "3". All the docs talk
about "stage1", "stage2" and "stage3".
Change the nomenclature if you want, but this mixed messages business is
kind of weird...
(Heartened by the response to my previous question of "why do you do
this thing that makes no sense to me", I'm going to be bold and not ask
why this is a good idea.)
^ permalink raw reply
* Re: git-name-rev off-by-one bug
From: Junio C Hamano @ 2005-11-30 5:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511292031280.3099@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Whaddaya think? I really like it.
Yes. Maybe split this into 3 pieces. I do not want to waste
your time with that, so will take the liberty to do so myself,
with appropriate commit log messages, if you do not mind.
1. give diff-files -[012] flags.
2. merge-one-file leaves unmerged index entries.
3. always use -M -p in git-diff.
I do not have any issue against #1.
Regarding #2, in an earlier message you said something about
"patch to do that was just broken" which I did not understand; I
think your patch I am replying to is doing the right thing. That
case arm is dealing with a path that exists in "our" branch and
the working tree blob should be the same as recorded in the
HEAD, so I did not have to do the unpack-cat-chmod like I did in
mine. Am I simply confused?
About #3, I am not quite sure. I often use --name-status and I
do _not_ want -p to kick in when I do so. How about something
like this?
---
diff --git a/git-diff.sh b/git-diff.sh
index b3ec84b..8e0fe34 100755
--- a/git-diff.sh
+++ b/git-diff.sh
@@ -7,8 +7,6 @@ rev=$(git-rev-parse --revs-only --no-fla
flags=$(git-rev-parse --no-revs --flags --sq "$@")
files=$(git-rev-parse --no-revs --no-flags --sq "$@")
-: ${flags:="'-M' '-p'"}
-
# I often say 'git diff --cached -p' and get scolded by git-diff-files, but
# obviously I mean 'git diff --cached -p HEAD' in that case.
case "$rev" in
@@ -20,6 +18,21 @@ case "$rev" in
esac
esac
+# If we do not have --name-status, --name-only nor -r, default to -p.
+# If we do not have -B nor -C, default to -M.
+case " $flags " in
+*" '--name-status' "* | *" '--name-only' "* | *" '-r' "* )
+ ;;
+*)
+ flags="$flags '-p'" ;;
+esac
+case " $flags " in
+*" '-"[BCM]* | *" '--find-copies-harder' "*)
+ ;; # something like -M50.
+*)
+ flags="$flags '-M'" ;;
+esac
+
case "$rev" in
?*' '?*' '?*)
echo >&2 "I don't understand"
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox