tree d84587462e0378c5aa9c5581d6920d76242b8c65
parent 91aa9fb573fcc50bc74d5ee64c7e9b36131f1804
author Al Viro [EMAIL PROTECTED] Fri, 19 Aug 2005 22:42:16 +0100
committer Linus Torvalds [EMAIL PROTECTED] Sat, 20 Aug 2005 07:57:19 -0700
[PATCH] jffs2: fix symlink error handling
The current calling
tree eec3baca8d1c1f026474906a3db3fac311753b4a
parent da6b2d01d6bd2e79fd4f7a08acd37dc4e8fcdce8
author David S. Miller [EMAIL PROTECTED] Sat, 20 Aug 2005 02:57:31 -0700
committer David S. Miller [EMAIL PROTECTED] Sat, 20 Aug 2005 02:57:31 -0700
[TG3]: Update driver version and reldate.
I am drafting an import script to turn a GNU Arch into a GIT archive.
Importing the branches and commits increamentally is reasonably
straightforward -- or so it seems so far. Note: the repository
manipulation is based on cvsimport -- so my knowledge of the git repo
internals is still pertty close
The syntax for .PRECIOUS in a makefile requires
an implicit target to match exactly:
%.txt does not cover all *.txt
Signed-off-by: Kris Shannon [EMAIL PROTECTED]
---
Documentation/Makefile |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/Makefile
Martin Langhoff [EMAIL PROTECTED] writes:
If I remember correctly, Junio added some stuff in the merge rebase
code that will identify if a particular patch has been seen and
applied, and skip it even if it's a bit out of order. But I don't know
I think you are talking about git-patch-id.
Hi,
On Thu, 18 Aug 2005, Junio C Hamano wrote:
Johannes Schindelin [EMAIL PROTECTED] writes:
The patch is for people who thinks the user who uses the --all
flag deserves the danger that comes with the convenience.
Comments?
This is a sane default behaviour. Maybe introduce yet
Martin Langhoff [EMAIL PROTECTED] wrote:
After using arch for a while, I've gotten used to getting .rej and
.orig files instead of big ugly conflict markers inside the file.
Emacs has a nice 'diff' mode that is a boon when dealing with
conflicts this way.
Is there a way to convince
Jason Riedy [EMAIL PROTECTED] writes:
Sun's cc doesn't know __attribute__.
It turns out that your patch breaks GCC build (#ifndef
__attribute__ is true there, and it should be---what it does
cannot be done in preprocessor alone). I am going to work it
around like this. Could you try it with
Hi,
If I understand correctly, the multi-head fetch would not write any ref if
used like this:
git fetch remote:repository/ head tail
but it would try a fast-forward when used like this:
git fetch remote:repository/ head:head tail:tail
Correct? If yes: This is fantastic! It
Quick note: I'm working on importing from SVN.
My current main problem is that SVN's Perl interface leaks server
connections (apparently nobody has used it for any real work yet),
which is of course *bad*, and kindof prevents me from finishing
the job today. :-/
--
Matthias Urlichs | {M:U}
And Junio C Hamano writes:
- It turns out that your patch breaks GCC build
Whoops, sorry. Your fix works with Sun's cc.
BTW, how would people feel about replacing the
setenv() and unsetenv() calls with the older putenv()?
The Solaris version I have to work on doesn't have
the nicer
On Fri, 19 Aug 2005, Martin Langhoff wrote:
I'm keen on keeping my 'merge publish' step in a single repo that
has all the 'team' branches. The person running this repo will
probably actually code in separate repos, and merge in there too.
I would suggest against a person owning a merge
Hi,
I tried to compile run git on cygwin. Two showstoppers:
- cygwin does not support IPv6 (yet). Therefore, it does
not have getaddrinfo() and friends. (minor showstopper)
- fork() and mmap() together have problems. This manifests
itself in git-diff-tree -p
Hey all,
git-commit-script --help says:
git commit [-a] [-m message] [-F logfile] [(-C|-c) commit]
[path...]
That made me assume that if I do:
git-commit-script somedir
it would *only* commit the changes I've made in somedir, but it
appears to commit *all* files that have changed (and
Ah, that explains it. I had already marked all my changes for update,
that's what threw me off here. Thanks!
Linus Torvalds wrote:
On Fri, 19 Aug 2005, Johnny Stenback wrote:
That made me assume that if I do:
git-commit-script somedir
it would *only* commit the changes I've made in
When following tags, check for parse_object() success and error out
properly instead of segfaulting.
Signed-off-by: Sergey Vlasov [EMAIL PROTECTED]
---
rev-list.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
f4ec41063d2f43b06b7c8e511108b4c9bf9e6ebe
diff --git a/rev-list.c
Linus Torvalds [EMAIL PROTECTED] writes:
However, one thing to look out for is that if you've marked any files for
update (with git-update-cache) those will always be committed regardless
of what arguments you give to git commit.
Another thing to look out for is that the files you told it
Jason Riedy [EMAIL PROTECTED] writes:
And Junio C Hamano writes:
- It turns out that your patch breaks GCC build
Whoops, sorry. Your fix works with Sun's cc.
Thanks.
BTW, how would people feel about replacing the
setenv() and unsetenv() calls with the older putenv()?
The Solaris
This teachs git-applypatch, which is used from git-applymbox, three
hooks, similar to what git-commit-script uses.
Signed-off-by: Junio C Hamano [EMAIL PROTECTED]
---
This is still in the proposed updates branch, along with the
hooks for git commit. Are people comfortable with the
Hi,
On Sat, 20 Aug 2005, Paul Mackerras wrote:
Hmmm... now I suppose we want a way to use gitk to drive the git
bisection process... :)
Ssshh! Let sleeping dogs lie! ;-)
Ciao,
Dscho
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
Junio C Hamano [EMAIL PROTECTED] writes:
*1* I should probably write a bit about how I do things in a
separate message as a how-to.
So here it is.
Note that the version of git on my $PATH is usually the one from
the proposed updates branch, so some of the commands I use in
the following text
21 matches
Mail list logo
