On Tue, Nov 13, 2012 at 11:40 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
I have to wonder why you care? As far as I'm concerned, the only valid
space is space, TAB and CR/LF.
Anything else is *noise*, not space. What's the reason for even caring?
Btw, expanding the whitespace
On Wed, Oct 24, 2012 at 12:25 AM, Thomas Gleixner t...@linutronix.de wrote:
It is spelled:
git notes add -m comment SHA1
Cool!
Don't use them for anything global.
Use them for local codeflow, but don't expect them to be distributed.
It's a separate flow, and while it *can* be
On Wed, Oct 24, 2012 at 4:56 AM, Al Viro v...@zeniv.linux.org.uk wrote:
How about git commit --allow-empty, with
belated ACK for commit
Don't bother. It's not that important, and it's just distracting.
It's not like this is vital information. If you pushed it out without
the ack, it's out
. With no changes at all,
git diff --stat output was empty. With just a chmod, it said 0
files changed. No way is our legacy behavior sane.
Signed-off-by: Linus Torvalds torva...@linux-foundation.org
---
This was triggered by kernel developers not noticing that they had
added zero-sized files
On Wed, Oct 17, 2012 at 11:28 AM, Junio C Hamano gits...@pobox.com wrote:
I think listing a file whose content remain unchanged with 0 as the
number of lines affected makes sense, and it will mesh well with
Duy's
http://thread.gmane.org/gmane.comp.version-control.git/207749
I first
attachments.
If somebody really cares, and determines that some attachment is binary
data (by looking at the data, not the MIME-type), the whole attachment
should be dismissed, rather than fed in random-sized chunks to
handle_filter().
Signed-off-by: Linus Torvalds torva...@linux-foundation.org
On Thu, Sep 13, 2012 at 7:43 PM, Takashi Iwai ti...@suse.de wrote:
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git for-linus
*PLEASE* don't do this.
You point to a branch, but then the pull request clearly implies there
is a tag with
On Tue, Jul 31, 2012 at 11:37 AM, Junio C Hamano gits...@pobox.com wrote:
* This is not even compile tested, so it needs testing and
benchmarking, as I do not even know how costly the calls to
open/close are when we do not have to call iconv() itself.
Ok, so it's easily compile-tested:
On Tue, Jul 31, 2012 at 1:16 PM, Junio C Hamano gits...@pobox.com wrote:
Eek.
Oh, I agree. Doing a full character set conversion both ways is quite
a bit more work.
Not just write_entry() codepath that creates the final paths on the
filesystem, you would need to touch lstat() calls that
On Sat, Jul 14, 2012 at 12:59 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Unfortunately, on big-endian architectures, if p is a pointer to
unsigned int then current gcc assumes it is properly aligned and
converts this construct to a 32-bit load.
This patch seems to entirely depend on the
On Sat, Jul 14, 2012 at 12:50 PM, Jonathan Nieder jrnie...@gmail.com wrote:
After the patch, what reason does gcc have to expect that 'block' is
32-bit aligned except when it is? The code (including the code I
didn't touch) never casts from char * to int * except in get/put_be32
on arches
Looks good to me. I'd suggest doing the macro argument expansion in
#define SHA_SRC(t) get_be32((unsigned char *) block + t*4)
with parenthesis around 't', but that's a fairly independent thing.
The old code didn't do that either.
Linus
--
To unsubscribe from this list: send the
On Thu, 8 Sep 2005, Junio C Hamano wrote:
Yes, the reading of three trees upfront is probably the culprit
in your case
However, note that _most_ tree reading just reads one.
Merges may take half a second, and yes, when I did it, the fact that we
move things around in the array is by far
On Thu, 8 Sep 2005, Chuck Lever wrote:
in my case the merges were taking significantly longer than a half
second. making this change is certainly not worth it if merges are
running fast...
Note that in cold-cache cases, all the expense of read-tree is in actually
reading the tree
On Thu, 8 Sep 2005, Greg KH wrote:
Or am I missing some option to 'git applymbox' that I can't seem to
find?
No. git-apply wants an exact bit-for-bit match. Partly because fuzz is
hard, but mostly because I don't like it. I apply a _lot_ of patches, and
if a unforgiving git-apply works
On Tue, 6 Sep 2005, Martin Langhoff wrote:
Grep knows how to ignore binary files.
That wasn't the _point_.
The point is, naming things as being scripts is useful. Grep is just an
example. Naming things as being .pl or .sh is _not_ useful.
So with grep you can use -I, but what about doing
On Tue, 6 Sep 2005, Junio C Hamano wrote:
Linus Torvalds [EMAIL PROTECTED] writes:
The point is, naming things as being scripts is useful. Grep is just an
example. Naming things as being .pl or .sh is _not_ useful.
Sorry, but why not?
What's the upside?
I can point to one downside
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,
On Mon, 5 Sep 2005, Wayne Scott wrote:
A recent commit in linux-2.6 looks like this:
It hopefully shouldn't happen any more with the improved and fixed
git-merge-base.
Author: Russell King [EMAIL PROTECTED]
Date: Wed Aug 31 10:12:14 2005 +0100
I suspect rmk is using cogito-0.13, and
On Mon, 5 Sep 2005, David Kågedal wrote:
But to the users (like myself), there's no point in naming it by
whether it's a script or a binary.
So? There's no downside.
To you, as a user, you never see the -script ending anyway. You'd never
type it out, or you're already doing something
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
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
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
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 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 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 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 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
.
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
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
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
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 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 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 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 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 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 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 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 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
, 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 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
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 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 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
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 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
301 - 400 of 577 matches
Mail list logo
