This doesn't work at least in the form that Junio merged it (and from
what I can tell, he merged your patch as-is):
[EMAIL PROTECTED]:~/src/git make NO_OPENSSL=1
cc -g -O2 -Wall '-DNO_OPENSSL' '-DSHA1_HEADER=mozilla-sha1/sha1.h' -o
git-rev-list rev-list.o libgit.a -lz -lssl
On Fri, 29 Jul 2005, Junio C Hamano wrote:
Would this be OK? I think it is ugly but it gets the job done.
Looks ok. I'd suggest having some option to turn of curl too - I have
one machine that doesn't have curl installed, and I just turn the things
that depend on it off by hand by editing
On Sat, 30 Jul 2005, Peter Osterlund wrote:
I have problems pulling linux kernel changes from
33ac02aa4cef417871e128ab4a6565e751e5f3b2 to
b0825488a642cadcf39709961dde61440cb0731c into my local tree. At first
I thought your patch would fix it, but it doesn't:
No, this is a merge conflict
On Sat, 30 Jul 2005, Alexander Nyberg wrote:
Linus, do you think we could have something like
patch-2.6.13-rc4-incremental-broken-out.tar.bz2 that could like Andrew's
be placed into patches/ in a tree?
Not really. The thing is, since the git patches really _aren't_ serial,
and merging
On Sat, 30 Jul 2005, Peter Osterlund wrote:
Can you send me your HEAD and MERGE_HEAD (don't do the merge).
HEAD : 33ac02aa4cef417871e128ab4a6565e751e5f3b2
MERGE_HEAD: b0825488a642cadcf39709961dde61440cb0731c
Bingo.
Yup, it's git-merge-base, and it is confused by the same thing
On Sat, 30 Jul 2005, Junio C Hamano wrote:
I love it I can just slow down and let others submit obviously
correct patches, which I can just slurp in.
You're obviously doing well as a maintainer. Only stupid people try to do
everything themselves.
Personally, I spend a _lot_ of time
On Sat, 30 Jul 2005, Junio C Hamano wrote:
* Right now, send-pack --all into an empty repository does
not do anything, but send-pack --all master into an empty
repository pushes all local heads. This is because we do not
check send_all when deciding if we want to call try_match
On Sun, 31 Jul 2005, Josef Weidendorfer wrote:
Added hook in git-receive-pack
After successful update of a ref,
$GIT_DIR/hooks/update refname old-sha1 new-sha2
is called if present. This allows e.g sending of a mail
with pushed commits on the remote repository.
Documentation update
On Sun, 31 Jul 2005, Junio C Hamano wrote:
But you are. I can run this just fine:
No I'm not. Try all the machines behind my firewall.
kernel.org is just the place I put things to when I publish them. It
doesn't have any of my working directories on it.
Linus
-
To
On Sun, 31 Jul 2005, Junio C Hamano wrote:
Linus Torvalds [EMAIL PROTECTED] writes:
No I'm not. Try all the machines behind my firewall.
Ah, that's true. Do you push into them?
Yup, I do. I have this thing that I don't do backups, but I end up having
redundancy instead, so I keep
On Mon, 1 Aug 2005, Matthias Urlichs wrote:
Hi, Linus Torvalds wrote:
git checkout -f master
git-rev-parse master .git/refs/heads/merge-branch
#
# Switch to it, always leaving master untouched
#
git checkout -f merge-branch
Isn't that equivalent
A few sparse warnings have crept in again since I checked last time:
undeclared variables with global scope.
Fix them by marking the private variables properly static.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
Btw, sparse also warns about the return 0 in receive-pack.c: unpack
On Tue, 2 Aug 2005, Jeff Garzik wrote:
shrug I don't really care either way.
I suspect it's mostly the users, not the developers, who care. The core
developers already know what went in, and have git to see it, they don't
look at the shortlog output. So I suspect it's more important to see
On Wed, 3 Aug 2005, Junio C Hamano wrote:
Linus Torvalds [EMAIL PROTECTED] writes:
Yeah, probably not. git-rev-list does so much more than git-rev-tree ever
did.
Does rev-list do --edges ;-)?
No, but does anybody use it? It _may_ be interesting as a git-merge-base
thing, but then we
On Wed, 3 Aug 2005, Junio C Hamano wrote:
Linus Torvalds [EMAIL PROTECTED] writes:
Are you sure you have a good git version on master? I've never seen
anything like that, and I push all the time..
I have been esuspecting that it happens only because I rewind
and rebase pu, which you
On Wed, 3 Aug 2005, Johannes Schindelin wrote:
On Wed, 3 Aug 2005, Linus Torvalds wrote:
Are you sure you have a good git version on master? I've never seen
anything like that, and I push all the time..
Call him Zaphod: he has two heads (master and pu). You don't.
Oh, but I most
On Wed, 3 Aug 2005, Josef Weidendorfer wrote:
Yes it is. To reproduce:
Create a repository with 2 branches.
Make 2 clones of the 2 branches via SSH.
Make a commit on one clone and push.
Make another commit on the other clone and push = ERROR
This works perfectly fine, you just have to
On Wed, 3 Aug 2005, Josef Weidendorfer wrote:
But my example shows that the error happens even with 2 branches totally
unrelated to each other: if branch1 got a new commit, you can not push to
branch2 from another clone.
Sure you can.
git-send-pack remote branch2
and you've just
On Wed, 3 Aug 2005, Junio C Hamano wrote:
Wouldn't something like this work equally well?
Nope, for several reasons:
- it's _horribly_ inefficient (ie it traverses directories that it
doesn't need to)
- it shows all the changeset comments, regardless of whether they are
releant or
On Wed, 3 Aug 2005, Junio C Hamano wrote:
While I have not updated the send-pack src:dst syntax, I
added a horrible hack that some people may love to see. This
removes the need to use git-rev-parse from many commands.
Yes, I think this makes sense. We had three different sha1 parsers:
Junio, maybe there should be some test-case for this:
error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a
commit
error: remote ref 'refs/tags/v2.6.11' is not a strict subset of local
ref 'refs/tags/v2.6.11'.
error: Object
On Fri, 29 Jul 2005, Paul Mackerras wrote:
I have reworked the way gitk displays merges.
Ok, goodie. It works fine in my environment, with most merges showing up
as not interesting. But a merge like
3e0777b8fa96f7073ed5d13d3bc1d573b766bef9
shows an example of where there was
in the message. Apparently others do
too, as indicated by a patch I just got from Petr Vandovec. So we've got
for example:
889371f61fd5bb914d0331268f12432590cf7e85:
Author: Linus Torvalds [EMAIL PROTECTED] 2005-07-30 13:41:56
Committer: Linus Torvalds [EMAIL PROTECTED
On Fri, 5 Aug 2005, Johannes Schindelin wrote:
Tutorial says cache aka index. Though technically, a cache
is the index file _plus_ the related objects in the object database.
git-update-cache.txt even makes the difference between the index
and the directory cache.
I think we should
On Fri, 5 Aug 2005, Junio C Hamano wrote:
- Teach fetch-pack reference renaming.
Well, the fetch side at least needs it less.
Right now the renaming means that you can only really fetch _one_ head at
a time, but that's at least a fairly common and important case, and you
can do the rest
On Sat, 6 Aug 2005, Paul Mackerras wrote:
Linus Torvalds writes:
- clickable SHA1's in commit messages would be really really cool if
something like that is even possible with tcl/tk.
Done, and it was even pretty easy. It took only about a dozen lines.
Looks good also. I assume
Duh. A missing meant that half the tests that git-sh-setup-script were
_meant_ to do were actually totally ignored.
In particular, the git sanity checking ended up only testing that the
GIT_OBJECT_DIRECTORY was sane, not that GIT_DIR itself was..
Signed-off-by: Linus Torvalds [EMAIL PROTECTED
it up.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
diff --git a/gitk b/gitk
--- a/gitk
+++ b/gitk
@@ -1802,10 +1802,13 @@ proc selectline {l isnew} {
set linkid [string range $comment $s $e]
if {![info exists idline($linkid)]} continue
incr e
- $ctext tag conf
On Sun, 7 Aug 2005, Sam Ravnborg wrote:
I accidently commited too many files to my tree today, and now I want to
drop the commit so I have logically separate commits.
What is the right way to do this - in cogito hopefully.
Not cogito, and this needs to be scripted, but if what you _want_
On Sat, 6 Aug 2005, Marco Costalba wrote:
Some little new stuff too, complete changelog below:
- added move back/forward in selection history
- added hyperlinks SHA1's in commit messages
Ok, this is nicer than gitk, with the parents showing up in the commit
message and thus easy to go
working directory
to that point too), you'd first use git reset HEAD^ to reset to the
parent, and then do a git checkout -f to reset the working directory
state to that point in time too.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
---
This is potentially a dangerous command, so maybe we should make
On Sun, 7 Aug 2005, Junio C Hamano wrote:
Also ORIG_HEAD is probably redundant. After a successful
automerge, the same information can be had by HEAD^1
Absolutely not.
You forgot about one of the most common merge cases: fast-forward.
In fact, ORIG_HEAD is _the_ most common head I use
On Tue, 9 Aug 2005, Clemens Koller wrote:
Over here - using a non-standard ELDK/LFS mixture, git depends at least on:
...
diffstat (ftp://invisible-island.net/diffstat/diffstat-1.39.tgz)
Hmm.. This should not be true. Any diffstats should be converted to use
git-apply --stat instead.
I
On Tue, 9 Aug 2005, Johannes Schindelin wrote:
You have Firefox, don't you? Next time you surf to gitweb, right click on
the funny yellow symbol in the lower right corner of your Firefox. It
should say something like Subscribe to Do it.
Left-click. And you need to be inside the
On Tue, 9 Aug 2005, John Ellson wrote:
I hacked this:
#!/bin/bash
ID=`git-ls-files -s | grep $1 | cut -d ' ' -f 2`
No. git-ls-files shows the latest _index_ state, not the latest
committed state.
Use git-ls-tree HEAD pathname to get the latest committed state for the
, the rest is uninteresting.
In one - hopefully fairly extreme - case, it made a git-merge-base go from
just under five seconds(!) to a tenth of a second on my machine.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
---
diff --git a/merge-base.c b/merge-base.c
--- a/merge-base.c
+++ b/merge-base.c
On Wed, 10 Aug 2005, Sebastian Kuzminsky wrote:
People still use GNU Interactive Tools. Not just crazy, stupid people,
and I bet not just Debian people.
Why do you say that?
Do you have anybody who actually does, or are you just claiming so?
Some distributions seems to disagree with you.
On Thu, 11 Aug 2005, Sebastian Kuzminsky wrote:
What I have is bug reports against the cogito package, from people who
want to install both. The reports came very soon after I released the
package, so I dont think it's a totally freak occurance.
The point is, people have the thing
On Fri, 12 Aug 2005, Daniel Barkalow wrote:
The git architecture makes the central server less important, and it's
easy to run your own.
On the other hand:
- the git architecture is admirably suited to an _untrusted_ central
server, ie exactly the SourceForge kind of setup. I realize
On Sat, 13 Aug 2005, Martin Langhoff wrote:
Yes, developers can just merge with each other directly
I take it that you mean an exchange of patches that does not depend on
having public repos. What are the mechanisms available on that front,
other than patchbombs?
Just have a shared
On Sat, 13 Aug 2005, Petr Baudis wrote:
Anyway, clone-pack is a clear winner for networks (but someone should
re-check that, especially compared to rsync, wrt. server-side file
caching); really cool fast, but not very practical for anonymous access.
git-daemon is for the anonymous access
On Fri, 12 Aug 2005, H. Peter Anvin wrote:
Running it over ssh would be a good way to do authentication...
Well, if you have ssh as an option, you don't need git-daemon any more,
since the protocol that git-daemon does runs quite well over ssh on its
own...
The only point of git-daemon
On Sat, 13 Aug 2005, Dave Jones wrote:
Git actually has a _lot_ of nifty tools. I didn't realize that people
didn't know about such basic stuff as git-tar-tree and git-ls-files.
Maybe its because things are moving so fast :) Or maybe I just wasn't
paying attention on that day. (I
On Sat, 13 Aug 2005, Carl Baldwin wrote:
The bottom line is that I don't really see many situations where it is
absolutely necessary but it is a convenience. Not supporting it may
seem like an artificial limit that really didn't need to be there.
Well, there is an argument for not
On Sat, 13 Aug 2005, Petr Baudis wrote:
* Does this break atomicity?
I think it does not in real setups, since thanks to O_RDWR the
file should be overwritten only when the write() happens.
Can a 41-byte write() be non-atomic in any real conditions?
That's not the
On Sat, 13 Aug 2005, Steve French wrote:
1) There is no way to send a particular changeset from the middle of a
set from one tree to another, without exporting it as a patch or
rebuilding a new git tree.
Correct.
If I export those two changesets as patches, and send them on.
On Sat, 13 Aug 2005, Linus Torvalds wrote:
That's correct. Same things apply: you can move a patch over, and create a
new one with a modified comment, but basically the _old_ commit will be
immutable.
Let me clarify.
You can entirely _drop_ old branches, so commits may be immutable
On Mon, 15 Aug 2005, Matt Draisey wrote:
The behaviour of the symlinked in ref directories has changed from
earlier versions of git.
Hmm.. There used to be a mix of lstat() (in receive-pack) and stat() (in
fsck-cache.c, and it got standardized in one function which used lstat.
The reason
On Mon, 15 Aug 2005, Wolfgang Denk wrote:
I asked this question before without receiving any reply:
Assume I know exactly where the merge back happenend - is there any
way to tell git about it, so I don't see all these dangling heads any
more?
You'd have to teach cvsimport about it.
On Tue, 16 Aug 2005, Yasushi SHOJI wrote:
Instead of disabling it entirely, how about just having some limit on it?
ah, that's a good idea. here is a quick and dirty patch.
This makes it somewhat more expensive - I was thinking about disabling it
in git-diff-tree, since the rename logic
8326dd8350be64ac7fc805f6563a1d61ad10d32c (from
e886a61f76edf5410573e92e38ce22974f9c40f1)
Author: Linus Torvalds [EMAIL PROTECTED]
Date: Mon Aug 15 17:23:51 2005 -0700
Fix pine whitespace-corruption bug
There's no excuse for unconditionally removing whitespace from
the pico buffers on close
On Sun, 14 Aug 2005, Junio C Hamano wrote:
Linus Torvalds [EMAIL PROTECTED] writes:
I think this is great - especially for places like kernel.org, where a lot
of repos end up being related to each other, yet independent.
Yes. There is one shortcoming in the current git-clone -s
This does only git-diff-cache and git-diff-files, but the concept
should work for any command that uses the working tree.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
---
This is really partly a serious patch, but also just a query whether
people would want git to work in subdirectories
On Tue, 16 Aug 2005, Junio C Hamano wrote:
Comments: Wouldn't that mean git-*-scripts would not benefit from this
because git-sh-setup would set GIT_DIR for you even if
you don't?
As it stands now, yes. But the point being that if people like this, then
I'll just
directory).
Note that ../xyz also works, so you can do
cd linux/drivers/char
git diff ../block
and it will generate a diff of the linux/drivers/block changes.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
---
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
Fix test failure due to overly strict .git directory tests
We may not actually have a valid HEAD at all times, so relax the validity
tests for a .git subdirectory accordingly.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
-
diff --git a/setup.c b/setup.c
--- a/setup.c
+++ b/setup.c
On Wed, 17 Aug 2005, Paul Mackerras wrote:
I would like to get some feedback about what people think of the
visual effect of this new approach, and in particular whether having
the lines jump into hyperspace loses information that people find
useful.
Me likee. Maybe some knob to tune how
On Tue, 16 Aug 2005, Linus Torvalds wrote:
This fixes up usage of .. (without an ending slash) and . (with or
without the ending slash) in the git diff family.
Btw, if it wasn't clear, with this patch you can now do
git diff .
and it will show the diffs for everything under
On Tue, 16 Aug 2005, Junio C Hamano wrote:
This is a companion patch to the previous format-patch fix.
With -k, format-patch can be told not to remove the [PATCH] in
the original commit, nor to add the [PATCH] on its own.
I think this might be the point in time to just make the [PATCH]
Not all programs necessarily have a pathspec array of pathnames, some of
them (like git-update-cache) want to do things one file at a time. So
export the single-path interface too.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
---
cache.h |1 +
setup.c |2 +-
2 files changed, 2
This also makes ./filename acceptable as a side effect, since the
pathname normalization handles that too.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
---
update-cache.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
ece92eeda777c3141f5692132ccc2ba7e4e801a2
diff --git
On Thu, 18 Aug 2005, Paul Mackerras wrote:
I added support for grafts to gitk just yesterday, and it should be on
kernel.org by now. I also committed the changes to send lines into
hyperspace.
Paul, I hate to tell you about yet another flag to git-rev-list, but did
you realize that in
On Thu, 18 Aug 2005, Sam Ravnborg wrote:
I almost always handedit my mails and I find myself forgetting to add
Signed-off-by from time to time.
Is there a simple way to implment a trigger that can check that _I_
signed off the patch before applying it?
Well, Junio has been talking about
On Thu, 18 Aug 2005, Luck, Tony wrote:
The spurious changes reported by git-whatchanged -p are:
Documentation/acpi-hotkey.txt |3
Documentation/kernel-parameters.txt|5
drivers/acpi/osl.c |6
fs/jfs/inode.c
On Fri, 19 Aug 2005, Paul Mackerras wrote:
Umm. git-rev-list really does everything. Rule of thumb: if you _ever_
need to look at any other internal git information, you're probably doing
something wrong, or you've missed yet another flag ;)
I still look in [gitdir]/refs/tags/* and
On Fri, 19 Aug 2005, Martin Langhoff wrote:
In the section 'Emulating CVS behaviour', where the team setup is
described with a team 'merger'. What is not clear is how to deal with
project-wide branches. Should they be created in the master repo, and
everyone clone a new repo from it?
Just
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
On Sat, 20 Aug 2005, Linus Torvalds wrote:
But yes, you _should_ be able to do it with that ultra-simplistic login
shell. Probably just a 5-liner main() function or something.
This is entirely untested, and a lot more than five lines of code. Edit
until it works.
Linus
prefixing means that . and
./ automatically get simplified and work properly.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
diff --git a/ls-files.c b/ls-files.c
--- a/ls-files.c
+++ b/ls-files.c
@@ -21,7 +21,7 @@ static int line_terminator = '\n';
static int prefix_len = 0
.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
---
diff --git a/rev-parse.c b/rev-parse.c
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -107,7 +107,7 @@ static void show_arg(char *arg)
if (do_rev_argument is_rev_argument(arg))
show_rev_arg(arg);
else
in the
top-level directory. This magically also makes git-whatchanged do the
right thing.
Trivial scripting fix to make sure that git log also works.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
---
diff --git a/git-log-script b/git-log-script
--- a/git-log-script
+++ b/git-log-script
@@ -1,5 +1,4
On Tue, 23 Aug 2005, Linus Torvalds wrote:
Try this trivial patch, it should work better.
Actually, don't do the show_default() part of this. We should _not_ show
the default string if we haev --no-revs and the string doesn't match a
rev.
Also, this fixes -- handlign with --flags
The verify_pathspec() function doesn't test for ending NUL character in
the pathspec, causing some really funky and unexpected behaviour. It just
happened to work in the cases I had tested.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
---
diff --git a/ls-files.c b/ls-files.c
--- a/ls
and notice how the not-selected one is:
Author: Antonino A. Daplas [EMAIL PROTECTED] 2005-08-15 06:29:11
Committer: Linus Torvalds [EMAIL PROTECTED] 2005-08-15 09:59:39
Tags: not-selected
while the selected on is:
Author: Luming Yu [EMAIL PROTECTED] 2005-08-11 21:31:00
imply --no-flags.
[ Side note: we might want to get rid of these confusing two-way flags,
where some flags say only print xxx, and others say don't print yyy.
We'd be better off with just three flags that say print zzz, where zzz
is one of flags, revs, norevs ]
Signed-off-by: Linus
On Tue, 23 Aug 2005, Tony Luck wrote:
So GIT decides that the test branch has had a patch, and the release
branch hasn't ... and so it merges by keeping the version in test.
Plausible?
Very. Sounds like what happened.
Linus
-
To unsubscribe from this list: send the line
On Wed, 24 Aug 2005, Junio C Hamano wrote:
Added at the end of git-repack-script (Linus can disable it by
giving an '-n' flag when packing his private repositories).
No, I just haven't updated my git on master.kernel.org in a while. So
nothing to disable.
I ran git-update-server-info
On Wed, 24 Aug 2005, Linus Torvalds wrote:
Basically, he had two branches, A and B, and both contained the same patch
(but _not_ the same commit). One undid it, the other did not. There's no
real way to say which one is correct, and both cases clearly merge
perfectly, so both outcomes
On Wed, 24 Aug 2005, Carl Baldwin wrote:
Oops. I forgot to actually exit from the script if git-diff-files is
non-empty.
Also, looking at it now, I don't think keeping undo information in a
stack is the right thing. But keeping more than just one would be good.
Oh well, my first shot
On Wed, 24 Aug 2005, Junio C Hamano wrote:
that is not a right thing so get rid of that assumption (which
I agree is a good change, and the last sentense says
opposite...
Well, the patch makes it an _explicit_ assumption, instead of a very
subtly hidden one from the code-flow. It was the
On Fri, 26 Aug 2005, Martin Langhoff wrote:
OTOH, storing the metadata in a branch will allow us to run the import
in alternating repositories. But as Junio points out, unless I can
guarantee that the metadata and the tree are in sync, I cannot
trivially resume the import cycle from a new
On Fri, 26 Aug 2005, Fredrik Kuivinen wrote:
In real numbers it is as follows: In Linus' kernel tree there are
5996 commits. 400 of those have more than one parent. Of those 400
merge commits 4 have more than one shared head.
Ok, that's already interesting in itself. I was wanting to re-run
On Sat, 27 Aug 2005, Daniel Barkalow wrote:
What I missed was that the effect of causes_df_conflict is to give no
merge for the entry, rather than giving an error overall. So I do need an
equivalent.
Daniel,
I'm not 100% sure what you're trying to do, but one thing that might work
out
On Sun, 28 Aug 2005, Robert Fitzsimons wrote:
Allow the user to force a patch to be applied even though there might
be whitespace differences. Added a test case for the new option.
If you ignore whitespace, then you should probably accept patches that are
whitespace corrupted in another
On Sun, 28 Aug 2005, Jason Riedy wrote:
I'm fine with requiring a limited C99 compiler. A
pedantic compiler will reject members with a length
of zero. 6.7.5.2 para1 requires a value greater than
zero for a constant array size. So the code now (with
[0] decls) is neither C89 nor C99.
On Sun, 28 Aug 2005, Antti-Juhani Kaijanaho wrote:
This is not true under C99. If an array[] is the last member of a
struct (which is what we are, AFAIK, talking about), then sizeof that
struct is defined and gives the size of that struct as if the array's
size were zero (but the struct
On Mon, 29 Aug 2005, Ben Greear wrote:
I think I'm missing something fundamental though... I wanted to
change to the ben_dev_rfcnt branch to build a kernel without my
additional patch. git branch ben_dev_rfcnt seems to change
it fine, but all of the changes for repository 'foo' are also
On Mon, 29 Aug 2005, Bryan O'Donoghue wrote:
cg-tag-ls lists every version from 2.6.11 to the current 2.6.13
inclusive. cg-tag-ls also lists kernel version 2.6.13-rc6. What I'm
wondering is how exactly I set copy of the tree to that version, so that
I can apply the -mm patchset ?
You need
On Mon, 29 Aug 2005, Paul Mackerras wrote:
Please do a pull from:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/paulus/ppc64-2.6.git
Gaah.
This is not a valid git repository.
Guys, if you do partially populated repositories, _please_ make sure that
you still make it a valid git
On Mon, 29 Aug 2005, Russell King wrote:
Is the expected filesystem layout documented somewhere online (_external_
to the source code) ?
Nope, I don't think so.
Alternatively, when changes occur to the repostory format, please can
they be marked with some obvious subject so that folk
On Mon, 29 Aug 2005, Bryan O'Donoghue wrote:
If I'm understanding, I update to a given git repository, branch locally
based on tags and then I can checkout a branch locally, to make that the
active branch.
Exactly. This is the difference between a tag and a branch: a tag is an
immobile
On Tue, 30 Aug 2005, Paul Mackerras wrote:
What can one put in the alternates file? Just an absolute path, or
does a relative path or a URL work too?
Only an absolute path.
URL's fundamentally do not work, and relative paths end up being parsed as
relative to where-ever the user happens
On Mon, 29 Aug 2005, Robert Fitzsimons wrote:
I should have mentioned before, these changes are being used in a
SourcePuller dump file to git import script I've been working on.
Hmm. Anything that depends on --ignore-applied is fundamentally broken
as an import tool. There's no way something
On Mon, 29 Aug 2005, Junio C Hamano wrote:
But if we allowed duplicate entries per stage, I think we could easily
just fold stage 2/3 into one stage, and just have n entries in stage 2.
That would immediately mean that a three-way merge could be n way.
I suspect you are solving a
On Mon, 29 Aug 2005, Junio C Hamano wrote:
The code is simple enough and I see some beauty in it, but I
honor your veto, at least for now.
Well, I didn't actually veto it when I saw the feature the first time,
because I think it's a valid thing to do when applying patches by hand.
It was
On Mon, 29 Aug 2005, A Large Angry SCM wrote:
Signed-off-by: [EMAIL PROTECTED]
Btw, I enjoy your email address and name, but especially with something
that is supposed to hopefully have some legal value down the line if
somebody starts making SCO noises, it really would be nice to have a
that includes
the known-bad point, we now notice and complain, instead of writing an
empty revision to the new bisection branch.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
---
diff --git a/git-bisect-script b/git-bisect-script
--- a/git-bisect-script
+++ b/git-bisect-script
@@ -105,12 +105,16
Junio, I think this happened when you rewrote the pull/push stuff to do
shorthands..
Lately, git pull generates a lot of extra crud in the single-line commit
message, which is annoying because a lot of tools will thus actually not
show enough of the line to be valid.
For example, it used to get
On Fri, 2 Sep 2005, David Woodhouse wrote:
rm -rf tmp-empty-tree
mkdir -p tmp-empty-tree/.git
cd tmp-empty-tree
Ahh. Please change that to
rm -rf tmp-empty-tree
mkdir tmp-empty-tree
cd tmp-empty-tree
git-init-db
because otherwise you'll
On Mon, 5 Sep 2005, H. Peter Anvin wrote:
It would also hade the somewhat interesting possibility that one could
remove and recreate a file and have it exist as a different entity.
That probably needs to be a user option.
It's a totally broken model. Really.
You think it solves issues,
201 - 300 of 577 matches
Mail list logo
