* rsync deprecated but promoted?
From: Zack Brown @ 2005-09-25 16:32 UTC (permalink / raw)
To: git
Hi folks,
When I use cogito, it gives a warning saying the rsync method is deprecated and
will be removed in the future. But when I visit kernel.org/git, the page says to
use an rsync URL with cg-clone.
Maybe kernel.org should be updated?
Be well,
Zack
--
Zack Brown
^ permalink raw reply
* Re: Implementing diff, was Re: git 0.99.7b doesn't build on Cygwin
From: Davide Libenzi @ 2005-09-25 16:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.63.0509251745160.17672@wgmdd8.biozentrum.uni-wuerzburg.de>
On Sun, 25 Sep 2005, Johannes Schindelin wrote:
>> Linus Torvalds <torvalds@osdl.org> writes:
>>
>>> The GNU diff sources are hard enough to read that I don't think we want to
>>> try to merge the unified diff generation from there.
>>
>> I was talking with GNU diff maintainer and his impression was
>> that CVS folks may have done enough libification -- I'll find
>> time to look at CVS code and see how much damage we are talking
>> about.
>
> I am not sure if it would be wise to completely do away with the current
> method: Often, I call git-diff with my own wdiff-helper. Also, options
> like "-b" to diff are very useful, and would have to be implemented, too.
What you'd have to do, if you chose to use diffutils stuff, is to
transform the main() of diff in diff_main(), use setjmp/longjmp to capture
its exit()s, and make it use a proper allocator (if you want to avoid
leaks upon aborts). You can see an example inside the diff/libgdiff
directory of this packages:
https://www.cvshome.org
http://www.opencm.org
In that way, instead of executing "diff -u ...", you'd call diff_main()
with the proper args array. The CVS one (the other project seems dead,
and they lifted the thing from CVS anyway) should be readily usable.
- Davide
^ permalink raw reply
* Implementing diff, was Re: git 0.99.7b doesn't build on Cygwin
From: Johannes Schindelin @ 2005-09-25 15:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vzmq1twh5.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 25 Sep 2005, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > The GNU diff sources are hard enough to read that I don't think we want to
> > try to merge the unified diff generation from there.
>
> I was talking with GNU diff maintainer and his impression was
> that CVS folks may have done enough libification -- I'll find
> time to look at CVS code and see how much damage we are talking
> about.
I am not sure if it would be wise to completely do away with the current
method: Often, I call git-diff with my own wdiff-helper. Also, options
like "-b" to diff are very useful, and would have to be implemented, too.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] More descriptive messages for conflict cases in merges
From: Fredrik Kuivinen @ 2005-09-25 14:49 UTC (permalink / raw)
To: junkio; +Cc: git
The merge strategies can give more descriptive error messages for
conflict cases if they are given the actual branch names instead of
the SHA1s.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
git-merge.sh | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
c5a902b12ca631d0ca28f914c1b227481d300295
diff --git a/git-merge.sh b/git-merge.sh
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -71,6 +71,7 @@ test "$#" -le 2 && usage ;# we need at l
merge_msg="$1"
shift
+head_arg="$1"
head=$(git-rev-parse --verify "$1"^0) || usage
shift
@@ -86,7 +87,7 @@ echo "$head" >"$GIT_DIR/ORIG_HEAD"
case "$#,$common" in
*,'')
- die "Unable to find common commit between $head and $*"
+ die "Unable to find common commit between $head_arg and $*"
;;
1,"$1")
# If head can reach all the merge then we are up to date.
@@ -147,7 +148,7 @@ do
}
echo "Trying merge strategy $strategy..."
wt_strategy=$strategy
- git-merge-$strategy $common -- $head "$@" || {
+ git-merge-$strategy $common -- $head_arg "$@" || {
# The backend exits with 1 when conflicts are left to be resolved,
# with 2 when it does not handle the given merge at all.
@@ -202,7 +203,7 @@ case "$best_strategy" in
echo "Rewinding the tree to pristine..."
git reset --hard $head
echo "Using the $best_strategy to prepare resolving by hand."
- git-merge-$best_strategy $common -- $head "$@"
+ git-merge-$best_strategy $common -- $head_arg "$@"
;;
esac
for remote
^ permalink raw reply
* [PATCH] recursive-merge: Don't print a stack trace when read-tree fails.
From: Fredrik Kuivinen @ 2005-09-25 14:48 UTC (permalink / raw)
To: junkio; +Cc: git
If the working tree is dirty read-tree will fail, and we don't want an
ugly stack trace in that case. Also make sure we don't print stack
traces when we use 'die'.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
git-merge-recursive.py | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
5f47cf871d07317d42470f5fa261257e74b57f0e
diff --git a/git-merge-recursive.py b/git-merge-recursive.py
--- a/git-merge-recursive.py
+++ b/git-merge-recursive.py
@@ -149,7 +149,10 @@ def mergeTrees(head, merge, common, bran
else:
updateArg = '-u'
- runProgram(['git-read-tree', updateArg, '-m', common, head, merge])
+ [out, code] = runProgram(['git-read-tree', updateArg, '-m', common, head, merge], returnCode = True)
+ if code != 0:
+ die('git-read-tree:', out)
+
cleanMerge = True
[tree, code] = runProgram('git-write-tree', returnCode=True)
@@ -430,8 +433,11 @@ try:
print ''
except:
- traceback.print_exc(None, sys.stderr)
- sys.exit(2)
+ if isinstance(sys.exc_info()[1], SystemExit):
+ raise
+ else:
+ traceback.print_exc(None, sys.stderr)
+ sys.exit(2)
if clean:
sys.exit(0)
^ permalink raw reply
* Re: GIT 0.99.7d, and end of week status.
From: Alan Chandler @ 2005-09-25 9:32 UTC (permalink / raw)
To: git
In-Reply-To: <7vll1lr1bq.fsf@assigned-by-dhcp.cox.net>
On Sunday 25 Sep 2005 09:36, Junio C Hamano wrote:
> * The fourth minor fix release, GIT 0.99.7d, is available at the
> usual places.
I can't find it. Is this a propogation timing issue?
I tried both ip addresses quoted as being kernel.org
--
Alan Chandler
http://www.chandlerfamily.org.uk
^ permalink raw reply
* GIT 0.99.7d, and end of week status.
From: Junio C Hamano @ 2005-09-25 8:36 UTC (permalink / raw)
To: git
* The fourth minor fix release, GIT 0.99.7d, is available at the
usual places.
RPMs and Debs are found in http://kernel.org/pub/software/scm/
With git:
$ git fetch http://kernel.org/pub/scm/git/git.git tag v0.99.7d
$ git checkout -b <new-branch> v0.99.7d
Fixes since 0.99.7c are:
- Fix show-branch output that named commits incorrectly.
- Fix git-grep -e not passing -e to underlying grep.
* Recent updates to the master branch includes:
- The GIT_VERSION is now 0.99.7.GIT (thanks Pasky for the
idea).
- The symlinks for backward compatible names are not installed
anymore (but existing ones are not automatically removed).
- git-diff-* family acquired a new option, --name-status, to
show the status and name for changed files. Also -l<num>
option disables rename/copy detection when the number of
rename target candidates are more than <num> (idea by Linus
some time ago).
* Proposed updates, not yet graduated to the master branch
includes:
- git-merge fix, not to require a clean tree.
- Likewise for git-revert and git-cherry-pick fix, not to
require a clean tree.
- Use git-merge from git-pull, again.
- A couple of test fixes for further Solaris portability.
- update-index takes -z --stdin to read NUL terminated list of
paths from the standard input instead of from the command
line. This is to help platforms with xargs that cannot grok
-0. git-commit is updated to use this.
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: Junio C Hamano @ 2005-09-25 7:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0509231737140.3308@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> The GNU diff sources are hard enough to read that I don't think we want to
> try to merge the unified diff generation from there.
I was talking with GNU diff maintainer and his impression was
that CVS folks may have done enough libification -- I'll find
time to look at CVS code and see how much damage we are talking
about.
^ permalink raw reply
* Re: [ANNOUNCE qgit-0.95]
From: Marco Costalba @ 2005-09-25 7:07 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
Alan Chandler wrote:
>On Sunday 25 Sep 2005 07:32, Alan Chandler wrote:
>...
>
>>However when I run make I get errors of the form shown below (QSettings
>>errors) and eventually the compile stage fails.
>>
>>/usr/share/qt3/bin/uic -o src/rangeselectbase.h src/rangeselectbase.ui
>>/usr/share/qt3/bin/uic -impl rangeselectbase.h -o
>>src/uic_rangeselectbase.cc src/rangeselectbase.ui
>>/usr/share/qt3/bin/moc -o src/moc_rangeselectbase.cc src/rangeselectbase.h
>>QSettings: error creating /.qt
>>QSettings: error creating /.qt
>>QSettings: error creating /.qt
>>QSettings: error creating /.qt
>>QSettings: error creating /.qt
>>QSettings::sync: filename is null/empty
>>QSettings: error creating /.qt
>>QSettings::sync: filename is null/empty
>>QSettings: error creating /.qt
>>QSettings::sync: filename is null/empty
>>g++ -O2 -DQT_THREAD_SUPPORT -D_REENTRANT -I/usr/include/qt3
>>-I/usr/share/qt3/include -c -o src/git_startup.o src/git_startup.cpp
>>src/git_startup.cpp: In member function `void Git::parseReadFromStdout()':
>>src/git_startup.cpp:473: error: jump to label `resume'
>>src/git_startup.cpp:439: error: from here
>>src/git_startup.cpp:467: error: crosses initialization of `newCommits*nc'
>>scons: *** [src/git_startup.o] Error 1
>>scons: building terminated because of errors.
>>make: *** [all] Error 2
>>alan@kanger qgit-0.95 $
>
>
>Although the QSettings are still there, fixing up git_startup.cpp as per
>Pasky's patch fixed it for me
>
QSettings are there from day one :-<
I am not able to let them disappear.....very bad. In any case should be harmless.
This morining I have updated the downloads with Pasky's patch.
Marco
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [ANNOUNCE qgit-0.95]
From: Alan Chandler @ 2005-09-25 6:47 UTC (permalink / raw)
To: git; +Cc: Marco Costalba
In-Reply-To: <200509250732.06754.alan@chandlerfamily.org.uk>
On Sunday 25 Sep 2005 07:32, Alan Chandler wrote:
...
> However when I run make I get errors of the form shown below (QSettings
> errors) and eventually the compile stage fails.
>
> /usr/share/qt3/bin/uic -o src/rangeselectbase.h src/rangeselectbase.ui
> /usr/share/qt3/bin/uic -impl rangeselectbase.h -o
> src/uic_rangeselectbase.cc src/rangeselectbase.ui
> /usr/share/qt3/bin/moc -o src/moc_rangeselectbase.cc src/rangeselectbase.h
> QSettings: error creating /.qt
> QSettings: error creating /.qt
> QSettings: error creating /.qt
> QSettings: error creating /.qt
> QSettings: error creating /.qt
> QSettings::sync: filename is null/empty
> QSettings: error creating /.qt
> QSettings::sync: filename is null/empty
> QSettings: error creating /.qt
> QSettings::sync: filename is null/empty
> g++ -O2 -DQT_THREAD_SUPPORT -D_REENTRANT -I/usr/include/qt3
> -I/usr/share/qt3/include -c -o src/git_startup.o src/git_startup.cpp
> src/git_startup.cpp: In member function `void Git::parseReadFromStdout()':
> src/git_startup.cpp:473: error: jump to label `resume'
> src/git_startup.cpp:439: error: from here
> src/git_startup.cpp:467: error: crosses initialization of `newCommits*nc'
> scons: *** [src/git_startup.o] Error 1
> scons: building terminated because of errors.
> make: *** [all] Error 2
> alan@kanger qgit-0.95 $
Although the QSettings are still there, fixing up git_startup.cpp as per
Pasky's patch fixed it for me
Sorry for the noise.
--
Alan Chandler
http://www.chandlerfamily.org.uk
^ permalink raw reply
* Re: [ANNOUNCE qgit-0.95]
From: Alan Chandler @ 2005-09-25 6:32 UTC (permalink / raw)
To: git; +Cc: Marco Costalba
In-Reply-To: <20050924160641.60151.qmail@web26307.mail.ukl.yahoo.com>
On Saturday 24 Sep 2005 17:06, Marco Costalba wrote:
...
> INSTALLATION
>
> You need scons and Qt developer libs version 3.3.4 or better already
> installed. You need 'mt' version of Qt libraries.
>
> QGit is NOT compatible with Qt4.
>
> On some platforms (Debian) you should set QTDIR before to compile.
I am running Debian unstable with libqt3-mt-dev installed, and qt3-dev-tools.
I set QTDIR to /usr/share/qt3. (and running with KDE incidentally)
However when I run make I get errors of the form shown below (QSettings
errors) and eventually the compile stage fails.
/usr/share/qt3/bin/uic -o src/rangeselectbase.h src/rangeselectbase.ui
/usr/share/qt3/bin/uic -impl rangeselectbase.h -o src/uic_rangeselectbase.cc
src/rangeselectbase.ui
/usr/share/qt3/bin/moc -o src/moc_rangeselectbase.cc src/rangeselectbase.h
QSettings: error creating /.qt
QSettings: error creating /.qt
QSettings: error creating /.qt
QSettings: error creating /.qt
QSettings: error creating /.qt
QSettings::sync: filename is null/empty
QSettings: error creating /.qt
QSettings::sync: filename is null/empty
QSettings: error creating /.qt
QSettings::sync: filename is null/empty
g++ -O2 -DQT_THREAD_SUPPORT -D_REENTRANT -I/usr/include/qt3
-I/usr/share/qt3/include -c -o src/git_startup.o src/git_startup.cpp
src/git_startup.cpp: In member function `void Git::parseReadFromStdout()':
src/git_startup.cpp:473: error: jump to label `resume'
src/git_startup.cpp:439: error: from here
src/git_startup.cpp:467: error: crosses initialization of `newCommits*nc'
scons: *** [src/git_startup.o] Error 1
scons: building terminated because of errors.
make: *** [all] Error 2
alan@kanger qgit-0.95 $
Is there something else I should have installed.
--
Alan Chandler
http://www.chandlerfamily.org.uk
^ permalink raw reply
* Re: [ANNOUNCE qgit-0.95]
From: Marco Costalba @ 2005-09-25 5:52 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
Petr Baudis wrote:
>
>Yes, it is several times faster than gitk, good work. Had to do this in
>order to be able to compile it with gcc-3.3.6, though (it complained
>about goto'ing after initialization of nc - that's bogus since there's
>the return, but...):
thanks, applied.
>
>Besides that, this is what I don't like about qgit:
>
>* It'd be nice to be able to choose to see all commits in the initial
>dialog by single click (I know about --all). Perhaps a radio buttons
>choosing between all and selected? Also, you might add the "diff against
>working copy" option to that dialog as well.
Yes.
>
>* The graph column is too narrow. It should be auto-sized so that the
>graph fits in, or at least there should be some clear indication that
>the graph does not fit to the column at the given point. This confused
>me a lot at first.
Auto fit the column width to the graph can be not always the best choice, see
0572e3da3ff5c3744b2f606ecf296d5f89a4bbdf (aka Linux v2.6.13-rc7) commit to see what I mean.
But an inidcation that the graph column is resizable is a good thing.
>
>* Could you make the grey background for odd commits span to the whole
>line, including the commit graph?
>
Yes, I am not sure of the results, there are already a lot of colors in the graphs, but I will
check.
>* The commit time is relative to now, which makes no sense to me. Also,
>it is in the second column instead of the last one like in gitk, which
>seems better to me. At least, the column is too narrow and then it
>blends together with the commit title.
>
I took the layout from gitweb where the order is -relative time - author - short log.
But this is the second time someone complains about time column so I will
send to last column: graph - shortlog - author - time
>* In the filter radio buttons groups, only first few letters of the
>labels are visible, and apparently no tooltips.
Yes. I will choose the tooltips way to save space, that line its already too long, this is
the reason I try to avoid adding buttons.
> Same problem in the
>settings dialog, most of the options have the labels cut around 2/3, and
>the window is non-resizable on top of that - why? I hate non-resizable
>windows, especially because they are usually too small. :-)
>
This is strange, I have resizable setting window and no cutted labels.......
This is for sure a bug but I can't reproduce on my box.
>* Single-clicking at a commit produces a significantly slower response
>than in gitk, where I see the difflist and stuff nearly instantly - it
>takes several hundreds of ms in qgit. That's quite annoying.
>
Please, is flag edit->settings->general->'load file names in background' set?
>* Getting to the diff view was non-obvious for me. It'd be nice to have
>some [diff] button as well somewhere. Or you could also show the diff in
>the bottom part of screen in the commit view, I think gitk solved this
>nicely.
I have tought a lot how to pass to the user the information that to see a diff you have to
double click on the commit:
1) Adding a button with a 'double click' tooltip? --> use space forever for a one time
information (once you know you can double click the button is useless, the space not).
2) Adding a menu entry with a tool tip? can be.
3) Add a tool tip directly on the commit line: can became annoying really soon.
4) Show always diff in commit info window? can be time consuming for merges (gitk doesn't shows
merges diff) and the space is limited or you need to resize forth and then back the commit info
window. Perpahs it's only me, but I need the whole screen to go deep in a diff when I really need
to understand the change.
In any case you are right, something has to be made.
>
>* Clicking on the file was supposed to bring some annotated view, but if
>it is so, it should write "Annotate" in the window title, and should
>indicate that it is computing it on the background (and is really slow
>in that, or I don't know, but always only single revision was shown
>there). It is unclear what the "pin file" checkbox is supposed to mean,
>and the whole dialog is just very confusing. :-)
>
Yes annotate can be slow with linux tree with some vip files ;-)
Please try with a small project or with a seldom
touched file: annotation should appear left aligned.
An example can be file daemon.c in git archive, you can reach
from commit f8ff0c0641a14770a2214fffbd4271b1ea3a0d61
When you browse the file history list on top, the corresponding main view
commit changes as does the file revision content: "pin file" checkbox simply avoids
the file viewer content to change, only main view is updated.
This can be useful when you double click on the left align annotation number to jump to commit,
preserving the file view.
>* The lane information might be available as a tooltip in addition to
>right-clicking on it - that wouldn't occur to me.
>
Yes...now I see its also a little bit broken....bad luck ;-)
>* Why is the Edit menu aligned to the right?
>
Is it? really? I cannot reproduce, Its the only menu without shortcuts, but
is correctly aligned here.
>* Well - I don't like the line graphics and prefer gitk's. This is
>perhaps a matter of taste, though. I find the graphics to be too tiny,
>thin and not so clear as gitk's, which makes it harder to see the commit
>flow. I also like diagonal lines more than angles, but that might be
>just because I'm used to them.
>
Diagonal line could be nicer but doesn't leave you play some tricks to greatly speed up
graph drawing. I really like those tricks ;-)
Then when the things get tough, with a lot of lines, the more 'regular' and geometrical
layout of qgit could help...but this is just a matter of taste.
>
>
>Nice work otherwise. :-)
>
Thanks for your very good feedback.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* [PATCH] Finish documenting trivial merge rules
From: Daniel Barkalow @ 2005-09-25 3:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Fix missing symbol explanations, a few incorrect cases, and add
two-way merge rules.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
Documentation/technical/trivial-merge.txt | 49 +++++++++++++++++++++++------
1 files changed, 39 insertions(+), 10 deletions(-)
ad07d5f3075c8749ec16559566fa338c1be1b873
diff --git a/Documentation/technical/trivial-merge.txt b/Documentation/technical/trivial-merge.txt
--- a/Documentation/technical/trivial-merge.txt
+++ b/Documentation/technical/trivial-merge.txt
@@ -10,6 +10,9 @@ This replaces the index with a different
for entries that don't change, and allowing -u to make the minimum
required changes to the working tree to have it match.
+Entries marked '+' have stat information. Spaces marked '*' don't
+affect the result.
+
index tree result
-----------------------
* (empty) (empty)
@@ -20,7 +23,30 @@ required changes to the working tree to
Two-way merge
-------------
+It is permitted for the index to lack an entry; this does not prevent
+any case from applying.
+
+If the index exists, it is an error for it not to match either the old
+or the result.
+
+If multiple cases apply, the one used is listed first.
+
+A result which changes the index is an error if the index is not empty
+and not up-to-date.
+
+Entries marked '+' have stat information. Spaces marked '*' don't
+affect the result.
+ case index old new result
+ -------------------------------------
+ 0/2 (empty) * (empty) (empty)
+ 1/3 (empty) * new new
+ 4/5 index+ (empty) (empty) index+
+ 6/7 index+ (empty) index index+
+ 10 index+ index (empty) (empty)
+ 14/15 index+ old old index+
+ 18/19 index+ old index index+
+ 20 index+ index new new
Three-way merge
---------------
@@ -44,30 +70,28 @@ up-to-date.
*empty* means that the tree must not have a directory-file conflict
with the entry.
-For multiple ancestors or remotes, a '+' means that this case applies
-even if only one ancestor or remote fits; normally, all of the
-ancestors or remotes must be the same.
+For multiple ancestors, a '+' means that this case applies even if
+only one ancestor or remote fits; a '^' means all of the ancestors
+must be the same.
case ancest head remote result
----------------------------------------
1 (empty)+ (empty) (empty) (empty)
2ALT (empty)+ *empty* remote remote
-2ALT (empty)+ *empty* remote remote
2 (empty)^ (empty) remote no merge
3ALT (empty)+ head *empty* head
3 (empty)^ head (empty) no merge
4 (empty)^ head remote no merge
5ALT * head head head
-6 ancest^ (empty) (empty) no merge
-8ALT ancest (empty) ancest (empty)
+6 ancest+ (empty) (empty) no merge
+8 ancest^ (empty) ancest no merge
7 ancest+ (empty) remote no merge
+10 ancest^ ancest (empty) no merge
9 ancest+ head (empty) no merge
-10ALT ancest ancest (empty) (empty)
-11 ancest+ head remote no merge
16 anc1/anc2 anc1 anc2 no merge
13 ancest+ head ancest head
14 ancest+ ancest remote remote
-14ALT ancest+ ancest remote remote
+11 ancest+ head remote no merge
Only #2ALT and #3ALT use *empty*, because these are the only cases
where there can be conflicts that didn't exist before. Note that we
@@ -89,4 +113,9 @@ right. This is a case of a reverted patc
multiple times), and the right answer depends on looking at crossings
of history or common ancestors of the ancestors.
-The status as of Sep 5 is that multiple remotes are not supported
\ No newline at end of file
+Note that, between #6, #7, #9, and #11, all cases not otherwise
+covered are handled in this table.
+
+For #8 and #10, there is alternative behavior, not currently
+implemented, where the result is (empty). As currently implemented,
+the automatic merge will generally give this effect.
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: Daniel Barkalow @ 2005-09-25 3:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Davide Libenzi, git
In-Reply-To: <7vbr2iw6l3.fsf@assigned-by-dhcp.cox.net>
On Sat, 24 Sep 2005, Junio C Hamano wrote:
> Making really really core part usable on Windows would not need
> this, but there is another thing: .git/HEAD symlink.
Cygwin supports symlinks without underlying filesystem support. It does
basically the standard UNIX thing for symlinks, but inefficiently in
userspace.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: Davide Libenzi @ 2005-09-24 22:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0509241524270.3308@g5.osdl.org>
On Sat, 24 Sep 2005, Linus Torvalds wrote:
>
>
> On Sat, 24 Sep 2005, Davide Libenzi wrote:
>>
>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createhardlink.asp
>
> Don't you mean
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createsymboliclink.asp
>
> rather?
>
> It mentions longhorn.
Hah, didn't know this one. Requiring LongHorn is pretty strict though ;)
- Davide
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: Linus Torvalds @ 2005-09-24 22:27 UTC (permalink / raw)
To: Davide Libenzi; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0509241524270.3308@g5.osdl.org>
On Sat, 24 Sep 2005, Linus Torvalds wrote:
>
> It mentions longhorn.
Anyway, regardless, we could certainly make HEAD be a regular file
containing the name of the head instead.
It probably wouldn't even require a whole lot of changes. HEAD already
ends up getting some special attention, since most of the things that look
for refs only look inside the .git/refs directory.
Linus
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: Linus Torvalds @ 2005-09-24 22:26 UTC (permalink / raw)
To: Davide Libenzi; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0509241426240.16554@localhost.localdomain>
On Sat, 24 Sep 2005, Davide Libenzi wrote:
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createhardlink.asp
Don't you mean
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createsymboliclink.asp
rather?
It mentions longhorn.
Linus
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.7b
From: Junio C Hamano @ 2005-09-24 21:59 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050923205436.GF10255@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Fri, Sep 23, 2005 at 10:46:14PM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> told me that...
>> If you pulled from "master" branch, then --version would still
>> say 0.99.7; I agree it is confusing. On the other hand, I do
>> not think we would want to increment the version string with
>> every little changes, so...
>
> In ELinks, we pseudo-bump the version number from v1.2.3 to v1.2.3.CVS
> (now v1.2.3.GIT) right after the release.
That's a nice way of doing it. Maybe I should follow suit.
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: Davide Libenzi @ 2005-09-24 21:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vd5myuoi0.fsf@assigned-by-dhcp.cox.net>
On Sat, 24 Sep 2005, Junio C Hamano wrote:
> Davide Libenzi <davidel@xmailserver.org> writes:
>
>> On Sat, 24 Sep 2005, Junio C Hamano wrote:
>>
>>> Making really really core part usable on Windows would not need
>>> this, but there is another thing: .git/HEAD symlink.
>>
>> Starting from Win2k, they *finally* added:
>>
>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createhardlink.asp
>
> It talks about "a hard link". Can we readlink it?
Nope. It's an hardlink (ala link(2)).
- Davide
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: Junio C Hamano @ 2005-09-24 21:47 UTC (permalink / raw)
To: Davide Libenzi; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.63.0509241426240.16554@localhost.localdomain>
Davide Libenzi <davidel@xmailserver.org> writes:
> On Sat, 24 Sep 2005, Junio C Hamano wrote:
>
>> Making really really core part usable on Windows would not need
>> this, but there is another thing: .git/HEAD symlink.
>
> Starting from Win2k, they *finally* added:
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createhardlink.asp
It talks about "a hard link". Can we readlink it?
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: Junio C Hamano @ 2005-09-24 21:46 UTC (permalink / raw)
To: Davide Libenzi; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.63.0509241426240.16554@localhost.localdomain>
Davide Libenzi <davidel@xmailserver.org> writes:
> On Sat, 24 Sep 2005, Junio C Hamano wrote:
>
>> Making really really core part usable on Windows would not need
>> this, but there is another thing: .git/HEAD symlink.
>
> Starting from Win2k, they *finally* added:
Ah, that's good to know.
^ permalink raw reply
* Re: /bin/sh portability question
From: Junio C Hamano @ 2005-09-24 21:31 UTC (permalink / raw)
To: Peter Eriksen; +Cc: git
In-Reply-To: <20050924195029.GA20514@bohr.gbar.dtu.dk>
"Peter Eriksen" <s022018@student.dtu.dk> writes:
> Here are some small problems to begin with.
Thanks. Next time, please format your patch according to
Documentation/SubmittingPatches. Your MUA ate tabs and leading
whitespaces from the diff, and you lack Signed-off-by line.
I think you need to pass down SHELL_PATH, and prepare for people
running 'make' by hand in t/ directory.
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -252,7 +252,7 @@ SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)
$(patsubst %.py,%,$(SCRIPT_PYTHON)) \
gitk
-export TAR INSTALL DESTDIR
+export TAR INSTALL DESTDIR SHELL_PATH
### Build rules
all: $(PROGRAMS) $(SCRIPTS)
diff --git a/t/Makefile b/t/Makefile
--- a/t/Makefile
+++ b/t/Makefile
@@ -4,8 +4,9 @@
#
#GIT_TEST_OPTS=--verbose --debug
+SHELL_PATH ?= $(SHELL)
BTW, do you have access to a Linux machine to play with? It
would have caught this fairly easily.
Test of 'tar' timestamp would also fail if you do not use
'gtar', but as far as I know that test is the only place we
really rely on 'tar', so it may not be worth fixing.
'xargs -0' and 'find -print0' is really essential in some of the
git barebone scripts. I think the one in git-reset can go, by
unlinking in the Perl script instead of printing the name and
running "xargs -0 rm -f --" on it.
The one in git-commit I am not sure about. We do want to make
it really generic and keep allowing LF in paths. Maybe we would
want 'git-update-index --stdin [-z]' to read list of paths from
the standard input.
The one in git-grep I would not worry too much about; we should
rewrite the whole thing in Perl and the problem will disappear.
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: Davide Libenzi @ 2005-09-24 21:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vbr2iw6l3.fsf@assigned-by-dhcp.cox.net>
On Sat, 24 Sep 2005, Junio C Hamano wrote:
> Making really really core part usable on Windows would not need
> this, but there is another thing: .git/HEAD symlink.
Starting from Win2k, they *finally* added:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createhardlink.asp
- Davide
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: Junio C Hamano @ 2005-09-24 20:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Davide Libenzi, git
In-Reply-To: <Pine.LNX.4.63.0509241129300.31327@localhost.localdomain>
Making really really core part usable on Windows would not need
this, but there is another thing: .git/HEAD symlink.
^ permalink raw reply
* Re: [PATCH] Fix earlier "import quilt patches" patch
From: Catalin Marinas @ 2005-09-24 19:47 UTC (permalink / raw)
To: Paolo 'Blaisorblade' Giarrusso; +Cc: git
In-Reply-To: <20050924104622.17274.18611.stgit@zion.home.lan>
On 24/09/05, Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> wrote:
> I forgot to update all cases - I updated __parse_mail, not __parse_patch, so
> refactor together this duplication and use the fixed version.
Thanks. I'll apply it tomorrow.
> Btw, I don't like those regexps - they'd match in the middle of line too. What
> about adding ^ to their beginning like for the "^Index: " regexp?
Python's re.match() only matches from the beginning of the line, so ^
is not needed.
Catalin
--
Catalin
^ 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