On Sat, Oct 26, 2013 at 6:34 PM, Josh Triplett j...@joshtriplett.org wrote:
+ format_commit_message(commit, Fixes: %h ('%s')\n, sb, ctx);
What is the value of double wrapping the commit message inside '...'
and then ('...')?
-Tony
--
To unsubscribe from this list: send the line
* When the branch head pointed by $GIT_DIR/HEAD changes while
the index file and working tree are looking the other way
(e.g. somebody pushed into your repository, or you ran git
fetch to update the ref your working tree is on), git
checkout without -f gets confused. Figure out a good way to
-by: Tony Luck [EMAIL PROTECTED]
---
diff --git a/Documentation/howto/using-topic-branches.txt
b/Documentation/howto/using-topic-branches.txt
--- a/Documentation/howto/using-topic-branches.txt
+++ b/Documentation/howto/using-topic-branches.txt
@@ -5,12 +5,10 @@ Subject: Some tutorial text
* Even if it does always choose the nicer choice of the two,
Tony was lucky (no pun intended). Rather, we were lucky that
Tony was observant. A careless merger may well have easily
missed this mismerge (from the human point of view).
Actually I can't take credit here. This was a
So I have another anomaly in my GIT tree. A patch to
back out a bogus change to arch/ia64/hp/sim/boot/bootloader.c
in my release branch at commit
62d75f3753647656323b0365faa43fc1a8f7be97
appears to have been lost when I merged the release branch to
the test branch at commit
I'm at home, and too lazy to log in to work to look at my tree. But I
have a theory
as to what went wrong for me.
At the start I had a file, same contents in test and release branch.
I applied a patch to release, and pulled to test. So the contents are still
the same, both with the patch
apply.c: In function `show_rename_copy':
apply.c:1147: warning: field precision is not type int (arg 3)
Signed-off-by: Tony Luck [EMAIL PROTECTED]
---
diff --git a/apply.c b/apply.c
--- a/apply.c
+++ b/apply.c
@@ -1143,7 +1143,7 @@ static void show_rename_copy(struct patc
The big problem, however, comes when Jeff (or anyone else) decides to
repack. Then, if you fetch both his repo and Linus', you might end up
with several really big pack files, that mostly overlap. That could
easily mean storing most objects many times, if you don't do some smart
selective
So, what _is_ then the way to pull now, actually? If we use rsync, won't
we end up with having the objects we previous had twice now?
Rsync works fine. You can either unpack the pack you get, or, if you
prefer, just run
git-prune-packed
cg-update from a local repo that contains
cg-update from a local repo that contains packs is broken though :-(
Is this with cg-0.12? The most recent release should be happy with packs.
Yes ... I pulled, built and installed the latest cogito this afternoon
before trying
to touch anything involving packs. cg-version says:
On 7/6/05, Jon Seymour [EMAIL PROTECTED] wrote:
Ok, you asked for it:
...the GIT bucket.
jon.
... ducks for cover ...
Groan ... as well you should.
My tree has re-appeared now. Thanks to whoever fixed it.
-Tony
-
To unsubscribe from this list: send the line unsubscribe git in
the
On Wed, 20 Apr 2005, Brad Roberts wrote:
How about fetching in the inverse order. Ie, deepest parents up towards
current. With that method the repository is always self consistent, even
if not yet current.
Daniel Barkalow replied:
You don't know the deepest parents to fetch until you've
called it git-wget, but it might
also want to be called git-pulltop.
Signed-off-by: Tony Luck [EMAIL PROTECTED]
-- script starts here -
#!/bin/sh
# Copyright (C) 2005 Tony Luck
REMOTE=http://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git/
rm -rf .gittmp
# set up a temp git
13 matches
Mail list logo
