* Re: [HELP] A local branch has disappeared
From: Neil Macneale @ 2009-01-19 5:37 UTC (permalink / raw)
To: Johnny Lee; +Cc: git
In-Reply-To: <488807870901181954p558756f5v94c8a6681125e8bb@mail.gmail.com>
On Jan 18, 2009, at 7:54 PM, Johnny Lee wrote:
> Hi all,
>
> Today I found my current branch (named cupcake) has disappeared.
> git@tomato:~/golf$ git branch -a
> htc_cupcake
> tmo_cupcake
> origin/HEAD
> origin/cupcake
> origin/device
>
> As you can see, there is no "*" to mark the current branch.
>
> But when I check the HEAD, it still pointed to the cupcake branch
> git@tomato:~/golf$ cat .git/HEAD
> ref: refs/heads/cupcake
>
> But when I check the ref/heads, the cupcake is missing
> git@tomato:~/golf$ ls .git/refs/heads/
> htc_cupcake tmo_cupcake
>
> And the cupcake in still in the config:
> git@tomato:~/golf$ cat .git/config
> [core]
> repositoryformatversion = 0
> filemode = true
> bare = false
> logallrefupdates = true
> sharedRepository = 1
> [remote "origin"]
> url = /home/rick/golfresort/device/.git
> fetch = +refs/heads/*:refs/remotes/origin/*
> [branch "cupcake"]
> remote = origin
> merge = refs/heads/cupcake
>
> I'm confused:
> 1. I didn't do any aggressive operations. Why the branch has
> disappeared? Normally I have done these operation for this repo:
> i. pull from parent repo
> ii. cloned by children repo
> iii. pulled by children repo
> iv. pushed from children repo
> 2. Is there any way to resume the cupcake branch? Can I manually add
> the cupcake to ref/heads?
I don't know why the cupcake branch would be gone, but you can
probably get something from the logs:
$ cat .git/logs/refs/heads/cupcake
The last line should tell you what commit you were at before it was
destroyed. Then you can create the branch again.
$ git checkout -b cupcake <hash in the log>
Hope that helps,
Neil
^ permalink raw reply
* Re: git-svn updates
From: Junio C Hamano @ 2009-01-19 6:29 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20090119040615.GA11306@dcvr.yhbt.net>
Thanks, pulled.
^ permalink raw reply
* Re: [PATCH (resend) 2/2] difftool: put the cursor on the editable file for Vim
From: Junio C Hamano @ 2009-01-19 6:43 UTC (permalink / raw)
To: David Aguilar; +Cc: git
In-Reply-To: <1232343269-27665-1-git-send-email-davvid@gmail.com>
Ok, I see you updated from r to l.
Please do not mark such "an earlier one had a thinko, and here is a
corrected patch" as "resend". It is confusing, because "resend" usually
means "I sent this earlier but somehow it did not reach the list, so here
is another copy verbatim."
Instead, please add a sentence or two after "---" lines to explain the
situation, like...
You only need to edit worktree files when comparing against
the worktree. Put the cursor automatically into its window for
vimdiff and gvimdiff to avoid doing <C-w>r every time.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
Markus pointed out that 'l' is not left (it is right as in vi key
bindings).
contrib/difftool/git-difftool-helper | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
and say "[PATCH 2/2 (corrected)]" so that I can easily tell which one was
a dud and which one I should take.
This time it wasn't confusing because the exchange between Markus and you
were the only unread messages before your three patches in my mailbox, but
you are not always that lucky.
Will take your original 1/2 and this one.
Thanks.
^ permalink raw reply
* Re: [HELP] A local branch has disappeared
From: Johnny Lee @ 2009-01-19 7:16 UTC (permalink / raw)
To: Neil Macneale; +Cc: git
In-Reply-To: <488807870901182219j763995c6y1796cf3c0a98a958@mail.gmail.com>
Sorry, I forgot to reply to all in the last mail, again..
Hi Neil,
I used "git lost-found" to find out the latest commits, and use git
checkout -b cupcake commit_hash to get my lost branch back.
Thanks!
Though, I'm still confused about what had happened. :(
Regards,
Johnny
On Mon, Jan 19, 2009 at 2:19 PM, Johnny Lee <johnnylee194@gmail.com> wrote:
> The log about cupcake is also gone..
>
> git@tomato:~/golf$ cat .git/logs/refs/heads/
> htc_cupcake tmo_cupcake
>
> And I can't get the latest hash by git log:
> git@tomato:~/golf$ git log
> fatal: bad default revision 'HEAD'
>
> Regards,
> Johnny
>
> On Mon, Jan 19, 2009 at 1:37 PM, Neil Macneale <mac4@theory.org> wrote:
>>
>> On Jan 18, 2009, at 7:54 PM, Johnny Lee wrote:
>>
>>> Hi all,
>>>
>>> Today I found my current branch (named cupcake) has disappeared.
>>> git@tomato:~/golf$ git branch -a
>>> htc_cupcake
>>> tmo_cupcake
>>> origin/HEAD
>>> origin/cupcake
>>> origin/device
>>>
>>> As you can see, there is no "*" to mark the current branch.
>>>
>>> But when I check the HEAD, it still pointed to the cupcake branch
>>> git@tomato:~/golf$ cat .git/HEAD
>>> ref: refs/heads/cupcake
>>>
>>> But when I check the ref/heads, the cupcake is missing
>>> git@tomato:~/golf$ ls .git/refs/heads/
>>> htc_cupcake tmo_cupcake
>>>
>>> And the cupcake in still in the config:
>>> git@tomato:~/golf$ cat .git/config
>>> [core]
>>> repositoryformatversion = 0
>>> filemode = true
>>> bare = false
>>> logallrefupdates = true
>>> sharedRepository = 1
>>> [remote "origin"]
>>> url = /home/rick/golfresort/device/.git
>>> fetch = +refs/heads/*:refs/remotes/origin/*
>>> [branch "cupcake"]
>>> remote = origin
>>> merge = refs/heads/cupcake
>>>
>>> I'm confused:
>>> 1. I didn't do any aggressive operations. Why the branch has
>>> disappeared? Normally I have done these operation for this repo:
>>> i. pull from parent repo
>>> ii. cloned by children repo
>>> iii. pulled by children repo
>>> iv. pushed from children repo
>>> 2. Is there any way to resume the cupcake branch? Can I manually add
>>> the cupcake to ref/heads?
>>
>> I don't know why the cupcake branch would be gone, but you can probably get
>> something from the logs:
>>
>> $ cat .git/logs/refs/heads/cupcake
>>
>> The last line should tell you what commit you were at before it was
>> destroyed. Then you can create the branch again.
>>
>> $ git checkout -b cupcake <hash in the log>
>>
>> Hope that helps,
>> Neil
>>
>
>
>
> --
> we all have our crosses to bear
>
--
we all have our crosses to bear
^ permalink raw reply
* Re: [RFC PATCH] Fix gitdir detection when in subdir of gitdir
From: Johannes Sixt @ 2009-01-19 7:17 UTC (permalink / raw)
To: SZEDER Gábor
Cc: Junio C Hamano, Johannes Schindelin, SZEDER Gábor, git
In-Reply-To: <20090119020311.GA8753@neumann>
SZEDER Gábor schrieb:
> if (is_git_directory(".")) {
> + char gd_rel_path[PATH_MAX];
> inside_git_dir = 1;
> if (!work_tree_env)
> inside_work_tree = 0;
> - setenv(GIT_DIR_ENVIRONMENT, ".", 1);
> + if (cdup_count) {
> + char *p = gd_rel_path;
> + while (cdup_count-- > 1) {
> + *p++ = '.'; *p++ = '.'; *p++ = '/';
> + }
> + *p++ = '.'; *p++ = '.';
> + *p = '\0';
> + } else {
> + gd_rel_path[0] = '.';
> + gd_rel_path[1] = '\0';
> + }
> + setenv(GIT_DIR_ENVIRONMENT, gd_rel_path, 1);
> check_repository_format_gently(nongit_ok);
> return NULL;
> }
This does not make sense because you don't chdir back to where you
started, so the relative path would be incorrect.
I have the feeling that it is not worth to support this particular
use-case with so many lines of code.
-- Hannes
^ permalink raw reply
* Re: how to track multiple upstreams in one repository
From: Ciprian Dorin, Craciun @ 2009-01-19 7:52 UTC (permalink / raw)
To: david; +Cc: Bryan Donlan, git
In-Reply-To: <alpine.DEB.1.10.0901181957070.20741@asgard.lang.hm>
[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]
On Mon, Jan 19, 2009 at 5:58 AM, <david@lang.hm> wrote:
> On Sun, 18 Jan 2009, Bryan Donlan wrote:
>
>> On Sun, Jan 18, 2009 at 06:58:06PM -0800, david@lang.hm wrote:
>>>
>>> for linux I want to track both the linus tree and the -stable tree.
>>> Ideally I want to be able to do a checkout of tags from either tree from
>>> the same directory (along with diffs between items in both trees, etc)
>>>
>>> I have found documentation on how to clone from each of them, but I
>>> haven't found any simple documentation on how to work with both of them.
>>
>> After cloning from one:
>> git remote add remotename git://...
>> git fetch remotename
>>
>> You will now have the other repository fetched into your local
>> repository; tags from both will be replicated to your local tags.
>
> thanks, given the nature of git I figured it was something really simple,
> but I just wasn't able to find it.
>
> I've forwarded this to the kernel.org webmaster to update the 'how to follow
> linux development' page
>
> David Lang
I use something even simpler, please see the attached .git/config
file that I use. It also uses remote branches, and rewrites the refs
to something like: stable/v2.6.25/master or torvalds/v2.6/master. Also
in order to fetch them I use git fetch stable/v2.6.25
Ciprian Craciun.
[-- Attachment #2: config --]
[-- Type: application/octet-stream, Size: 1772 bytes --]
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[user]
name = Ciprian Dorin Craciun
email = ciprian.craciun@gmail.com
[url "git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/"]
insteadOf = torvalds:
[url "git://git.kernel.org/pub/scm/linux/kernel/git/stable/"]
insteadOf = stable:
[remote "torvalds/v2.6"]
url = torvalds:linux-2.6.git
fetch = refs/heads/master:refs/heads/torvalds/v2.6/master
[remote "stable/v2.6.17"]
url = stable:linux-2.6.17.y.git
fetch = refs/heads/master:refs/heads/stable/v2.6.17/master
[remote "stable/v2.6.18"]
url = stable:linux-2.6.18.y.git
fetch = refs/heads/master:refs/heads/stable/v2.6.18/master
[remote "stable/v2.6.19"]
url = stable:linux-2.6.19.y.git
fetch = refs/heads/master:refs/heads/stable/v2.6.19/master
[remote "stable/v2.6.20"]
url = stable:linux-2.6.20.y.git
fetch = refs/heads/master:refs/heads/stable/v2.6.20/master
[remote "stable/v2.6.21"]
url = stable:linux-2.6.21.y.git
fetch = refs/heads/master:refs/heads/stable/v2.6.21/master
[remote "stable/v2.6.22"]
url = stable:linux-2.6.22.y.git
fetch = refs/heads/master:refs/heads/stable/v2.6.22/master
[remote "stable/v2.6.23"]
url = stable:linux-2.6.23.y.git
fetch = refs/heads/master:refs/heads/stable/v2.6.23/master
[remote "stable/v2.6.24"]
url = stable:linux-2.6.24.y.git
fetch = refs/heads/master:refs/heads/stable/v2.6.24/master
[remote "stable/v2.6.25"]
url = stable:linux-2.6.25.y.git
fetch = refs/heads/master:refs/heads/stable/v2.6.25/master
[remote "stable/v2.6.26"]
url = stable:linux-2.6.26.y.git
fetch = refs/heads/master:refs/heads/stable/v2.6.26/master
[remote "stable/v2.6.27"]
url = stable:linux-2.6.27.y.git
fetch = refs/heads/master:refs/heads/stable/v2.6.27/master
^ permalink raw reply
* Re: [PATCH] interpret_nth_last_branch(): avoid traversing the reflogs twice
From: Junio C Hamano @ 2009-01-19 8:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Rast, git, Johannes Sixt, Johan Herland
In-Reply-To: <alpine.DEB.1.00.0901182152010.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sat, 17 Jan 2009, Junio C Hamano wrote:
> ...
>> My HEAD reflog is 7MB long with 39000 entries, and among them, 13100
>> entries have "checkout: moving ".
>>
>> I know I will never want to switch back to the 10000th from the last
>> branch. I am quite sure that I would forget which branch I was on after
>> switching branches three or four times (hence my original hardcoded
>> limitation of 10 which "should be plenty"). When I know I only have to
>> keep track of 10 entries, having to keep track of 13100 entries, even if
>> it is 36kB (it would actually be 260kB in my case) feels there is
>> something wrong in the design.
>
> Hrm. So let's leave it as a two-pass thing?
Well, I would rather be in favor of something like this.
-- >8 --
Subject: interpret_nth_last_branch(): avoid traversing the reflog twice
You can have quite a many reflog entries, but you typically won't recall
which branch you were on after switching branches for more than several
times.
Instead of reading the reflog twice, this reads the branch switching event
and keeps the latest 16 (which is an arbitrary limitation that should be
plenty) such entry, to switch back to the branch we were recently on.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
sha1_name.c | 48 +++++++++++++++++++++------------------------
t/t2012-checkout-last.sh | 44 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 66 insertions(+), 26 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 9e1538e..d6622f2 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -684,10 +684,11 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
return retval;
}
+#define MAX_PREVIOUS_BRANCH 16
+
struct grab_nth_branch_switch_cbdata {
- int counting;
- int nth;
- struct strbuf *buf;
+ long cnt;
+ struct strbuf buf[MAX_PREVIOUS_BRANCH];
};
static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
@@ -697,6 +698,7 @@ static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
struct grab_nth_branch_switch_cbdata *cb = cb_data;
const char *match = NULL, *target = NULL;
size_t len;
+ int nth;
if (!prefixcmp(message, "checkout: moving from ")) {
match = message + strlen("checkout: moving from ");
@@ -711,16 +713,9 @@ static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
if (target[len] == '\n' && !strncmp(match, target, len))
return 0;
- if (cb->counting) {
- cb->nth++;
- return 0;
- }
-
- if (cb->nth-- <= 0) {
- strbuf_reset(cb->buf);
- strbuf_add(cb->buf, match, len);
- return 1;
- }
+ nth = cb->cnt++ % MAX_PREVIOUS_BRANCH;
+ strbuf_reset(&cb->buf[nth]);
+ strbuf_add(&cb->buf[nth], match, len);
return 0;
}
@@ -737,7 +732,8 @@ static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
*/
int interpret_nth_last_branch(const char *name, struct strbuf *buf)
{
- int nth;
+ long nth;
+ int i;
struct grab_nth_branch_switch_cbdata cb;
const char *brace;
char *num_end;
@@ -750,19 +746,19 @@ int interpret_nth_last_branch(const char *name, struct strbuf *buf)
nth = strtol(name+3, &num_end, 10);
if (num_end != brace)
return -1;
-
- cb.counting = 1;
- cb.nth = 0;
- cb.buf = buf;
- for_each_reflog_ent("HEAD", grab_nth_branch_switch, &cb);
-
- if (cb.nth < nth)
- return 0;
-
- cb.counting = 0;
- cb.nth -= nth;
- cb.buf = buf;
+ if (nth <= 0 || MAX_PREVIOUS_BRANCH < nth)
+ return -1;
+ for (i = 0; i < MAX_PREVIOUS_BRANCH; i++)
+ strbuf_init(&cb.buf[i], 20);
+ cb.cnt = 0;
for_each_reflog_ent("HEAD", grab_nth_branch_switch, &cb);
+ if (cb.cnt < nth)
+ return -1;
+ i = (cb.cnt + MAX_PREVIOUS_BRANCH - nth) % MAX_PREVIOUS_BRANCH;
+ strbuf_reset(buf);
+ strbuf_add(buf, cb.buf[i].buf, cb.buf[i].len);
+ for (i = 0; i < MAX_PREVIOUS_BRANCH; i++)
+ strbuf_release(&cb.buf[i]);
return brace-name+1;
}
diff --git a/t/t2012-checkout-last.sh b/t/t2012-checkout-last.sh
index 320f6eb..87b30a2 100755
--- a/t/t2012-checkout-last.sh
+++ b/t/t2012-checkout-last.sh
@@ -47,4 +47,48 @@ test_expect_success '"checkout -" detaches again' '
test_must_fail git symbolic-ref HEAD
'
+test_expect_success 'more switches' '
+ for i in 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
+ do
+ git checkout -b branch$i
+ done
+'
+
+more_switches () {
+ for i in 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
+ do
+ git checkout branch$i
+ done
+}
+
+test_expect_success 'switch to the last' '
+ more_switches &&
+ git checkout @{-1} &&
+ test "z$(git symbolic-ref HEAD)" = "zrefs/heads/branch2"
+'
+
+test_expect_success 'switch to second from the last' '
+ more_switches &&
+ git checkout @{-2} &&
+ test "z$(git symbolic-ref HEAD)" = "zrefs/heads/branch3"
+'
+
+test_expect_success 'switch to third from the last' '
+ more_switches &&
+ git checkout @{-3} &&
+ test "z$(git symbolic-ref HEAD)" = "zrefs/heads/branch4"
+'
+
+test_expect_success 'switch to fourth from the last' '
+ more_switches &&
+ git checkout @{-4} &&
+ test "z$(git symbolic-ref HEAD)" = "zrefs/heads/branch5"
+'
+
+test_expect_success 'switch to twelfth from the last' '
+ more_switches &&
+ git checkout @{-12} &&
+ test "z$(git symbolic-ref HEAD)" = "zrefs/heads/branch13"
+'
+
test_done
--
1.6.1.245.gdd9f9
^ permalink raw reply related
* Re: [PATCH] interpret_nth_last_branch(): avoid traversing the reflogs twice
From: Junio C Hamano @ 2009-01-19 8:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Rast, git, Johannes Sixt, Johan Herland
In-Reply-To: <7vprijra52.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Well, I would rather be in favor of something like this.
>
> -- >8 --
> Subject: interpret_nth_last_branch(): avoid traversing the reflog twice
>
> You can have quite a many reflog entries, but you typically won't recall
> which branch you were on after switching branches for more than several
> times.
>
> Instead of reading the reflog twice, this reads the branch switching event
> and keeps the latest 16 (which is an arbitrary limitation that should be
> plenty) such entry, to switch back to the branch we were recently on.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> sha1_name.c | 48 +++++++++++++++++++++------------------------
> t/t2012-checkout-last.sh | 44 ++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 66 insertions(+), 26 deletions(-)
>
> diff --git a/sha1_name.c b/sha1_name.c
> index 9e1538e..d6622f2 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -750,19 +746,19 @@ int interpret_nth_last_branch(const char *name, struct strbuf *buf)
> nth = strtol(name+3, &num_end, 10);
> if (num_end != brace)
> return -1;
> ...
> - if (cb.nth < nth)
> - return 0;
> ...
> + if (cb.cnt < nth)
> + return -1;
This should (obviously) be "return 0".
^ permalink raw reply
* Re: parent-filter loses my merged branch -- what am I doing wrong?
From: Johannes Sixt @ 2009-01-19 8:41 UTC (permalink / raw)
To: Ask Bjørn Hansen; +Cc: git
In-Reply-To: <7578B9A6-BF81-4096-B0FD-F433AD62A41E@develooper.com>
Ask Bjørn Hansen schrieb:
> On Sam Villain's recommendation I'm spending a bit of time cleaning up
> the branches and merges with git filter-branch, but I don't think I'm
> quite understanding how it's supposed to work.
Don't use --parent-filter for this; use grafts. You can see the history in
gitk right away. Later run filter-branch without a filter (except perhaps
the tag-name-filter).
-- Hannes
^ permalink raw reply
* What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Junio C Hamano @ 2009-01-19 9:13 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the branches, but I am still
holding onto them.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
----------------------------------------------------------------
[New Topics]
* jk/color-parse (Sat Jan 17 10:38:46 2009 -0500) 2 commits
+ expand --pretty=format color options
+ color: make it easier for non-config to parse color specs
* sb/hook-cleanup (Sat Jan 17 04:02:55 2009 +0100) 5 commits
+ run_hook(): allow more than 9 hook arguments
+ run_hook(): check the executability of the hook before filling
argv
+ api-run-command.txt: talk about run_hook()
+ Move run_hook() from builtin-commit.c into run-command.c (libgit)
+ checkout: don't crash on file checkout before running post-
checkout hook
* js/maint-all-implies-HEAD (Sat Jan 17 22:27:08 2009 -0800) 2 commits
- bundle: allow the same ref to be given more than once
- revision walker: include a detached HEAD in --all
* tr/previous-branch (Sat Jan 17 19:08:12 2009 +0100) 6 commits
- Fix parsing of @{-1}@{1}
- interpret_nth_last_branch(): avoid traversing the reflog twice
- checkout: implement "-" abbreviation, add docs and tests
- sha1_name: support @{-N} syntax in get_sha1()
- sha1_name: tweak @{-N} lookup
- checkout: implement "@{-N}" shortcut name for N-th last branch
* rs/ctype (Sat Jan 17 16:50:37 2009 +0100) 4 commits
+ Add is_regex_special()
+ Change NUL char handling of isspecial()
+ Reformat ctype.c
+ Add ctype test
* mh/unify-color (Sun Jan 18 21:39:12 2009 +0100) 2 commits
- move the color variables to color.c
- handle color.ui at a central place
* jf/am-failure-report (Sun Jan 18 19:34:31 2009 -0800) 2 commits
+ git-am: re-fix the diag message printing
+ git-am: Make it easier to see which patch failed
* cb/add-pathspec (Wed Jan 14 15:54:35 2009 +0100) 2 commits
- remove pathspec_match, use match_pathspec instead
- clean up pathspec matching
* sg/maint-gitdir-in-subdir (Fri Jan 16 16:37:33 2009 +0100) 1 commit
+ Fix gitdir detection when in subdir of gitdir
This has my "don't do the fullpath if you are directly inside .git"
squashed in, so it should be much safer.
* am/maint-push-doc (Sun Jan 18 15:36:58 2009 +0100) 4 commits
+ Documentation: avoid using undefined parameters
+ Documentation: mention branches rather than heads
+ Documentation: remove a redundant elaboration
+ Documentation: git push repository can also be a remote
* sp/runtime-prefix (Sun Jan 18 13:00:15 2009 +0100) 5 commits
- Windows: Revert to default paths and convert them by
RUNTIME_PREFIX
- Modify setup_path() to only add git_exec_path() to PATH
- Add calls to git_extract_argv0_path() in programs that call
git_config_*
- git_extract_argv0_path(): Move check for valid argv0 from caller
to callee
- Move computation of absolute paths from Makefile to runtime (in
preparation for RUNTIME_PREFIX)
----------------------------------------------------------------
[Stalled and may need help and prodding to go forward]
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
+ blame: show "previous" information in --porcelain/--incremental
format
+ git-blame: refactor code to emit "porcelain format" output
This gives Porcelains (like gitweb) the information on the commit _before_
the one that the final blame is laid on, which should save them one
rev-parse to dig further. The line number in the "previous" information
may need refining, and sanity checking code for reference counting may
need to be resurrected before this can move forward.
* db/foreign-scm (Sun Jan 11 15:12:10 2009 -0500) 3 commits
- Support fetching from foreign VCSes
- Add specification of git-vcs helpers
- Add "vcs" config option in remotes
The "spec" did not seem quite well cooked yet, but in the longer term I
think something like this to allow interoperating with other SCMs as if
the other end is a native git repository is a very worthy goal.
----------------------------------------------------------------
[Actively cooking]
* kb/lstat-cache (Sun Jan 18 16:14:54 2009 +0100) 5 commits
+ lstat_cache(): introduce clear_lstat_cache() function
+ lstat_cache(): introduce invalidate_lstat_cache() function
+ lstat_cache(): introduce has_dirs_only_path() function
+ lstat_cache(): introduce has_symlink_or_noent_leading_path()
function
+ lstat_cache(): more cache effective symlink/directory detection
This is the tenth round, now in 'next'.
* lh/submodule-tree-traversal (Mon Jan 12 00:45:55 2009 +0100) 3 commits
- builtin-ls-tree: enable traversal of submodules
- archive.c: enable traversal of submodules
- tree.c: add support for traversal of submodules
Still getting active reviews.
* lt/maint-wrap-zlib (Wed Jan 7 19:54:47 2009 -0800) 1 commit
+ Wrap inflate and other zlib routines for better error reporting
Needs the "free our memory upon seeing Z_MEM_ERROR and try again" bits
extracted from Shawn's patch on top of this one.
* jk/signal-cleanup (Sun Jan 11 06:36:49 2009 -0500) 3 commits
- pager: do wait_for_pager on signal death
- refactor signal handling for cleanup functions
- chain kill signals for cleanup functions
Sorry, I lost track. What is the status of this one?
* js/diff-color-words (Sat Jan 17 17:29:48 2009 +0100) 7 commits
- color-words: make regex configurable via attributes
- color-words: expand docs with precise semantics
- color-words: enable REG_NEWLINE to help user
- color-words: take an optional regular expression describing words
- color-words: change algorithm to allow for 0-character word
boundaries
- color-words: refactor word splitting and use ALLOC_GROW()
- Add color_fwrite_lines(), a function coloring each line
individually
Dscho's series that was done in response to Thomas's original; two agreed
to work together on this codebase.
* ks/maint-mailinfo-folded (Tue Jan 13 01:21:04 2009 +0300) 5 commits
- mailinfo: tests for RFC2047 examples
- mailinfo: add explicit test for mails like '<a.u.thor@example.com>
(A U Thor)'
- mailinfo: more smarter removal of rfc822 comments from 'From'
+ mailinfo: 'From:' header should be unfold as well
+ mailinfo: correctly handle multiline 'Subject:' header
I think "more smarter" one is too aggressive for our purpose. Perhaps not
removing comments at all would be what we want.
* js/patience-diff (Thu Jan 1 17:39:37 2009 +0100) 3 commits
+ bash completions: Add the --patience option
+ Introduce the diff option '--patience'
+ Implement the patience diff algorithm
* js/notes (Tue Jan 13 20:57:16 2009 +0100) 6 commits
+ git-notes: fix printing of multi-line notes
+ notes: fix core.notesRef documentation
+ Add an expensive test for git-notes
+ Speed up git notes lookup
+ Add a script to edit/inspect notes
+ Introduce commit notes
* sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
- gitweb: Optional grouping of projects by category
- gitweb: Split git_project_list_body in two functions
- gitweb: Modularized git_get_project_description to be more generic
----------------------------------------------------------------
[Graduated to "master"]
* ds/uintmax-config (Mon Nov 3 09:14:28 2008 -0900) 1 commit
+ autoconf: Enable threaded delta search when pthreads are supported
See if anybody screams.
* gb/gitweb-opml (Fri Jan 2 13:49:30 2009 +0100) 2 commits
+ gitweb: suggest name for OPML view
+ gitweb: don't use pathinfo for global actions
* mv/apply-parse-opt (Fri Jan 9 22:21:36 2009 -0800) 2 commits
+ Resurrect "git apply --flags -" to read from the standard input
+ parse-opt: migrate builtin-apply.
* tr/rebase-root (Fri Jan 2 23:28:29 2009 +0100) 4 commits
+ rebase: update documentation for --root
+ rebase -i: learn to rebase root commit
+ rebase: learn to rebase root commit
+ rebase -i: execute hook only after argument checking
Looked reasonable.
* mh/maint-commit-color-status (Thu Jan 8 19:53:05 2009 +0100) 2 commits
+ git-status -v: color diff output when color.ui is set
+ git-commit: color status output when color.ui is set
* rs/maint-shortlog-foldline (Tue Jan 6 21:41:06 2009 +0100) 1 commit
+ shortlog: handle multi-line subjects like log --pretty=oneline et.
al. do
* rs/fgrep (Sat Jan 10 00:18:34 2009 +0100) 2 commits
+ grep: don't call regexec() for fixed strings
+ grep -w: forward to next possible position after rejected match
* as/autocorrect-alias (Sun Jan 4 18:16:01 2009 +0100) 1 commit
+ git.c: make autocorrected aliases work
* tr/maint-no-index-fixes (Wed Jan 7 12:15:30 2009 +0100) 3 commits
+ diff --no-index -q: fix endless loop
+ diff --no-index: test for pager after option parsing
+ diff: accept -- when using --no-index
* jc/maint-format-patch (Sat Jan 10 12:41:33 2009 -0800) 1 commit
+ format-patch: show patch text for the root commit
* ap/clone-into-empty (Sun Jan 11 15:19:12 2009 +0300) 2 commits
+ Allow cloning to an existing empty directory
+ add is_dot_or_dotdot inline function
* gb/gitweb-patch (Thu Dec 18 08:13:19 2008 +0100) 4 commits
+ gitweb: link to patch(es) view in commit(diff) and (short)log view
+ gitweb: add patches view
+ gitweb: change call pattern for git_commitdiff
+ gitweb: add patch view
----------------------------------------------------------------
[Will merge to "master" soon]
* kb/am-directory (Wed Jan 14 16:29:59 2009 -0800) 2 commits
+ git-am: fix shell quoting
+ git-am: add --directory=<dir> option
This is "third-time-lucky, perhaps?" resurrection. I do not think I'd be
using this very often, but it originated from a real user request.
* jc/maint-format-patch-o-relative (Mon Jan 12 15:18:02 2009 -0800) 1 commit
+ Teach format-patch to handle output directory relative to cwd
----------------------------------------------------------------
[On Hold]
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
. diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
. git-am --forge: add Signed-off-by: line for the author
. git-am: clean-up Signed-off-by: lines
. stripspace: add --log-clean option to clean up signed-off-by:
lines
. stripspace: use parse_options()
. Add "git am -s" test
. git-am: refactor code to add signed-off-by line for the committer
* jc/post-simplify (Fri Aug 15 01:34:51 2008 -0700) 2 commits
. revision --simplify-merges: incremental simplification
. revision --simplify-merges: prepare for incremental simplification
* jk/valgrind (Thu Oct 23 04:30:45 2008 +0000) 2 commits
. valgrind: ignore ldso errors
. add valgrind support in test scripts
* wp/add-patch-find (Thu Nov 27 04:08:03 2008 +0000) 3 commits
. In add --patch, Handle K,k,J,j slightly more gracefully.
. Add / command in add --patch
. git-add -i/-p: Change prompt separater from slash to comma
* jc/grafts (Wed Jul 2 17:14:12 2008 -0700) 1 commit
. [BROKEN wrt shallow clones] Ignore graft during object transfer
* jc/replace (Fri Oct 31 09:21:39 2008 -0700) 1 commit
. WIP
^ permalink raw reply
* What's in git.git (Jan 2009, #02; Mon, 19)
From: Junio C Hamano @ 2009-01-19 9:13 UTC (permalink / raw)
To: git
Tonight's pushout has some git-svn updates included, in addition to a
handful of new features.
Perhaps 1.6.1.1 mid next week.
* The 'maint' branch has these fixes since the last announcement.
Christian Couder (1):
builtin-fsck: fix off by one head count
Johannes Schindelin (3):
http-push: fix off-by-path_len
http-push: when making directories, have a trailing slash in the path
name
t5540: clarify that http-push does not handle packed-refs on the remote
Junio C Hamano (2):
Update draft release notes to 1.6.1.1
Update draft release notes for 1.6.1.1
Markus Heidelberg (1):
Documentation: let asciidoc align related options
Michael J Gruber (2):
add test cases for "git mv -k"
fix handling of multiple untracked files for git mv -k
Miklos Vajna (1):
Make t3411 executable
Stephan Beyer (5):
t3501: check that commits are actually done
t3404: Add test case for aborted --continue after "edit"
t3404: Add test case for auto-amending only edited commits after "edit"
builtin-commit.c: do not remove COMMIT_EDITMSG
githooks.txt: add missing word
* The 'master' branch has these since the last announcement
in addition to the above.
Adeodato Simó (1):
git.c: make autocorrected aliases work
Alexander Potashev (2):
add is_dot_or_dotdot inline function
Allow cloning to an existing empty directory
Brandon Casey (1):
t7700: demonstrate misbehavior of 'repack -a' when local packs exist
David Aguilar (3):
contrib: add 'git difftool' for launching common merge tools
difftool: fix documentation problems
difftool: put the cursor on the editable file for Vim
David M. Syzdek (1):
autoconf: Enable threaded delta search when pthreads are supported
Eric Wong (4):
git-svn: handle empty files marked as symlinks in SVN
git-svn: better attempt to handle broken symlink updates
git-svn: fix SVN 1.1.x compatibility
git-svn: avoid importing nested git repos
Giuseppe Bilotta (6):
gitweb: add patch view
gitweb: change call pattern for git_commitdiff
gitweb: add patches view
gitweb: link to patch(es) view in commit(diff) and (short)log view
gitweb: don't use pathinfo for global actions
gitweb: suggest name for OPML view
Junio C Hamano (2):
Resurrect "git apply --flags -" to read from the standard input
format-patch: show patch text for the root commit
Keith Cascio (1):
test more combinations of ignore-whitespace options to diff
Marcel Koeppen (1):
git-svn: Show UUID in svn info for added directories with svn 1.5.5
Markus Heidelberg (4):
git-commit: color status output when color.ui is set
git-status -v: color diff output when color.ui is set
Documentation: let asciidoc align related options
mergetool: put the cursor on the editable file for Vim
Miklos Vajna (1):
parse-opt: migrate builtin-apply.
Pete Harlan (1):
git-svn: Add --localtime option to "fetch"
René Scharfe (3):
shortlog: handle multi-line subjects like log --pretty=oneline et. al. do
grep -w: forward to next possible position after rejected match
grep: don't call regexec() for fixed strings
SZEDER Gábor (3):
bash: remove unnecessary checks for long options with argument
bash: add missing format-patch command line options
bash: refactor 'git log --pretty=<format>' options
Ted Pavlic (3):
bash-completion: Support running when set -u is enabled
bash-completion: Try bash completions before simple filetype
bash-completion: Add comments to remind about required arguments
Thomas Rast (7):
rebase -i: execute hook only after argument checking
diff: accept -- when using --no-index
diff --no-index: test for pager after option parsing
diff --no-index -q: fix endless loop
rebase: learn to rebase root commit
rebase -i: learn to rebase root commit
rebase: update documentation for --root
^ permalink raw reply
* how to omit rename file when commit
From: Frank Li @ 2009-01-19 9:13 UTC (permalink / raw)
To: git
For example there are a file a.c at git repository.
use
git mv a.c b.c
git status:
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# renamed: a.c -> b.c
If we don't want to stage this change at this commit, what can I do?
^ permalink raw reply
* Re: how to omit rename file when commit
From: Junio C Hamano @ 2009-01-19 9:16 UTC (permalink / raw)
To: Frank Li; +Cc: git
In-Reply-To: <1976ea660901190113l5407f108lff8f37d9a8331f58@mail.gmail.com>
"Frank Li" <lznuaa@gmail.com> writes:
> For example there are a file a.c at git repository.
> use
> git mv a.c b.c
>
> git status:
> # On branch master
> # Changes to be committed:
> # (use "git reset HEAD <file>..." to unstage)
> #
> # renamed: a.c -> b.c
>
> If we don't want to stage this change at this commit, what can I do?
I may be misunderstanding what you want to do, but wouldn't "git mv b.c
a.c" undo whatever you did?
^ permalink raw reply
* Re: [PATCH] git-svn: fix SVN 1.1.x compatibility
From: Tom G. Christensen @ 2009-01-19 9:17 UTC (permalink / raw)
To: Eric Wong; +Cc: git@vger.kernel.org
In-Reply-To: <20090119004556.GA25038@dcvr.yhbt.net>
Eric Wong wrote:
> The get_log() function in the Perl SVN API introduced the limit
> parameter in 1.2.0. However, this got discarded in our SVN::Ra
> compatibility layer when used with SVN 1.1.x. We now emulate
> the limit functionality in older SVN versions by preventing the
> original callback from being called if the given limit has been
> reached. This emulation is less bandwidth efficient, but SVN
> 1.1.x is becoming rarer now.
>
> Additionally, the --limit parameter in svn(1) uses the
> aforementioned get_log() functionality change in SVN 1.2.x.
> t9129 no longer depends on --limit to work and instead uses
> Perl to parse out the commit message.
>
> Thanks to Tom G. Christensen for the bug report.
>
> Signed-off-by: Eric Wong <normalperson@yhbt.net>
I applied this to 1.6.1 and the testsuite now passes using SVN 1.1.4 on
RHEL 4/i386 (t9106 still fails on RHEL 4/x86_64).
-tgc
^ permalink raw reply
* Re: how to omit rename file when commit
From: Frank Li @ 2009-01-19 9:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v63kbr6zc.fsf@gitster.siamese.dyndns.org>
For example:
there are 2 file. a.c and e.c
I modify e.c.
and git mv a.c b.c
git update-index e.c
I just want to commit e.c and don't commit rename(a.c -> b.c)
I am debuging a tortoisegit. at commit dialog, there will be show all
changed as
[x] rename (a.c => b.c)
[x] modify (e.c)
button [OK]
assume user uncheck rename
[]rename (a.c=>b.c)
[x]modify (e.c)
then click okay.
I don't know use which git command to handle this case.
if git mv b.c a.c, local working copy will be changed.
2009/1/19 Junio C Hamano <gitster@pobox.com>:
> "Frank Li" <lznuaa@gmail.com> writes:
>
>> For example there are a file a.c at git repository.
>> use
>> git mv a.c b.c
>>
>> git status:
>> # On branch master
>> # Changes to be committed:
>> # (use "git reset HEAD <file>..." to unstage)
>> #
>> # renamed: a.c -> b.c
>>
>> If we don't want to stage this change at this commit, what can I do?
>
> I may be misunderstanding what you want to do, but wouldn't "git mv b.c
> a.c" undo whatever you did?
>
>
^ permalink raw reply
* Syncing with CVS
From: Christian von Kietzell @ 2009-01-19 9:39 UTC (permalink / raw)
To: git
Hi,
I have a project I started in git. After a while I exported that to
CVS via git cvsexportcommit which worked quite nicely. Now, a
colleague made changes to the project - in CVS. What's the best way to
get those back into my git repository so that I'll be able to sync
back and forth between git and CVS? I had a quick look at the wiki but
couldn't find anything appropriate.
I know of git cvsimport, of course, but that doesn't work on my
original repository. Or does it? I didn't find anything on how to
limit what to import. After all, some of the commits are already in my
repository (the ones I exported).
Hope any of you can help. Thanks in advance.
Chris
^ permalink raw reply
* Re: Syncing with CVS
From: Johan Herland @ 2009-01-19 10:28 UTC (permalink / raw)
To: Christian von Kietzell; +Cc: git
In-Reply-To: <f31e50960901190139w65b69fd1k752973a23c40f384@mail.gmail.com>
On Monday 19 January 2009, Christian von Kietzell wrote:
> Hi,
>
> I have a project I started in git. After a while I exported that to
> CVS via git cvsexportcommit which worked quite nicely. Now, a
> colleague made changes to the project - in CVS. What's the best way
> to get those back into my git repository so that I'll be able to sync
> back and forth between git and CVS? I had a quick look at the wiki
> but couldn't find anything appropriate.
>
> I know of git cvsimport, of course, but that doesn't work on my
> original repository. Or does it? I didn't find anything on how to
> limit what to import. After all, some of the commits are already in
> my repository (the ones I exported).
>
> Hope any of you can help. Thanks in advance.
Unfortunately bidirectional syncing between CVS and Git is pretty much
impossible in the general case, because CVS's structure is so different
from Git's. For one, it is very easy to (re)move tags and branches in
CVS, with no record of where it was moved from. (Also, as anybody
involved in proper CVS-to-Git converters ("git cvsimport" does _not_
fall into this category) will tell you, recreating history from CVS is
a highly non-trivial task in itself.) This means that even if you have
imported some CVS state into Git, you cannot guarantee that the CVS
state has not changed the next time you try to import. Therefore, it is
very hard to determine whether you're importing a whole new branch from
CVS, or whether you are just incrementally importing patches on top of
a previously imported branch.
I have a similar situation at $dayjob, where we have a central CVS
server with the official version, and I use Git for working locally. In
this case, I use "git cvsexportcommit" to propagate my local changes to
the CVS server. I only use this approach on branches where nobody else
is allowed to commit (of course CVS does not enforce this rule, so I
have to manually make sure that does not happen). If someone else were
to commit to my branch in CVS, I would have to redo a full CVS-to-Git
conversion, in order to get a new Git repo that is in sync with CVS. I
can then resume "git cvsexportcommit" to propagate my changes from Git
to CVS.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Syncing with CVS
From: Boaz Harrosh @ 2009-01-19 10:58 UTC (permalink / raw)
To: Christian von Kietzell; +Cc: git
In-Reply-To: <f31e50960901190139w65b69fd1k752973a23c40f384@mail.gmail.com>
Christian von Kietzell wrote:
> Hi,
>
> I have a project I started in git. After a while I exported that to
> CVS via git cvsexportcommit which worked quite nicely. Now, a
> colleague made changes to the project - in CVS. What's the best way to
> get those back into my git repository so that I'll be able to sync
> back and forth between git and CVS? I had a quick look at the wiki but
> couldn't find anything appropriate.
>
> I know of git cvsimport, of course, but that doesn't work on my
> original repository. Or does it? I didn't find anything on how to
> limit what to import. After all, some of the commits are already in my
> repository (the ones I exported).
>
> Hope any of you can help. Thanks in advance.
>
> Chris
I would "git cvsimport" into temporary new git.
Then "git remote add cvs_import that_temp_git" into the main git
Then find the point of the common base, do
"git tag CVS_GIT_BASE that_base_commit_uid"
"git checkout -b cvs_import cvs_import/master"
"git rebase --onto master CVS_GIT_BASE"
So in fact I'm just cherry-picking the additions from CVS
and reapplying on to original git tree. If you want it more
automatic you'll need to do the above in a script with some
kind of naming conventions for your git tags and CVS's tags
at points of sync.
Boaz
^ permalink raw reply
* Re: how to omit rename file when commit
From: Jakub Narebski @ 2009-01-19 11:01 UTC (permalink / raw)
To: Frank Li; +Cc: Junio C Hamano, git
In-Reply-To: <1976ea660901190135k71087673p85e995878e539a8f@mail.gmail.com>
"Frank Li" <lznuaa@gmail.com> writes:
> For example:
> there are 2 file. a.c and e.c
> I modify e.c.
> and git mv a.c b.c
>
> git update-index e.c
>
> I just want to commit e.c and don't commit rename(a.c -> b.c)
The simplest way (but I'm not sure if it is what you want) would be
$ git commit e.c
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: meaning of --8<--
From: Samuel Tardieu @ 2009-01-19 11:36 UTC (permalink / raw)
To: Peter Harris; +Cc: markus.heidelberg, git
In-Reply-To: <eaa105840901180804k64a745f9q1a092fe3915db868@mail.gmail.com>
>>>>> "Peter" == Peter Harris <git@peter.is-a-geek.org> writes:
Peter> Scissors 8<
One can also use the Unicode character 0x2702: ✂
Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/
^ permalink raw reply
* gitk doesn't work w/o sudo.
From: Dilip M @ 2009-01-19 10:16 UTC (permalink / raw)
To: git list
Hi,
..I recently install GIT on Ubuntu (hardy) box....I am able to use
'gitk' only If I do 'sudo'. Without 'sudo' it complains 'repository
not found'
-- DM
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Kjetil Barvik @ 2009-01-19 11:54 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vbpu3r745.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
<snipp>
> ----------------------------------------------------------------
> [Actively cooking]
>
> * kb/lstat-cache (Sun Jan 18 16:14:54 2009 +0100) 5 commits
> + lstat_cache(): introduce clear_lstat_cache() function
> + lstat_cache(): introduce invalidate_lstat_cache() function
> + lstat_cache(): introduce has_dirs_only_path() function
> + lstat_cache(): introduce has_symlink_or_noent_leading_path()
> function
> + lstat_cache(): more cache effective symlink/directory detection
>
> This is the tenth round, now in 'next'.
Thanks!! Nice to see that the patch is going forward. And I have to
admit that it was very fun to make that patch.
How long is the 'merge window' in Linux Kernel terms for this round
(to the next release of GIT)?
I have a second idea to an improvement, which also looks quite good
for the moment, and I am sort of wondering how fast I must work. :-)
-- kjetil
^ permalink raw reply
* Re: gitk doesn't work w/o sudo.
From: Reece Dunn @ 2009-01-19 11:59 UTC (permalink / raw)
To: Dilip M; +Cc: git list
In-Reply-To: <c94f8e120901190216x246589ebwc4a44dd85bb655d2@mail.gmail.com>
2009/1/19 Dilip M <dilipm79@gmail.com>:
> Hi,
>
> ..I recently install GIT on Ubuntu (hardy) box....I am able to use
> 'gitk' only If I do 'sudo'. Without 'sudo' it complains 'repository
> not found'
Who is the owner of the repository directory (and the .git directory)
and what are the permissions on the directory? You can run (on the
command line from the Terminal program):
ls -lh directory
to find this out (where directory is the directory you are interested
in) and run:
sudo chown user -R directory
to change ownership of that directory (and all of its content) to the
specified user (i.e. the one you are currently logged in as). This
will make it so that you own that directory and can make changes to
it. This should allow you to run gitk without using sudo.
HTH,
- Reece
^ permalink raw reply
* Re: [PATCH] contrib/workdir: create logs/refs and rr-cache in the origin repository
From: Adeodato Simó @ 2009-01-19 12:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vskngwfko.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano [Sun, 18 Jan 2009 11:59:35 -0800]:
> Adeodato Simó <dato@net.com.org.es> writes:
> > However, I've as of late directly created bare repositories knowing that
> > I wanted to work just with workdirs against it. In this case, the logs
> > for each checkout'ed branch will be stored in the workdirs and not the
> > repo, so deleting the workdir will make you lose those logs. Which is
> > bad, since workdirs should always be safe to delete.
> I had to think about the above for a while, but after realizing that you
> have a strict distinction between a "workdir" and a normal "repository
> with a work tree" in mind, I can see where you are coming from. A workdir
> is transient in nature and you should be able to dismiss it safely as long
> as the repository it borrows from is intact.
The thing, for me, is that a workdir should result in effects as close
as possible as doing the work in the repository with the workdir itself.
I normally use workdirs when it's not feasible to do the work in the
repo itself (eg., there's work in progress I'd rather have around,
rather than committing it to a temporary branch, to leave the repo
"clean" for further work).
> A workdir is a new work area that is not a normal "work tree with a
> full repository", but borrows from an existing repository. Any side
> effect from the work you do in a workdir will be saved in the original
> repository, and removing one would lose only the three kind of
> information listed above. Creating a new workdir has the side effect
> of enabling reflogs and rerere in the original repository.
> But the last sentence somehow feels dirty.
I really don't understand that last sentence. Does "mkdir logs/refs rr-cache"
*enable* reflogs and rerere at all? Or, rather, it just gives an empty
space for the workdirs "connecting" to it to save their reflogs and
rerere stuff iff they are configured to do so?
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Love in your heart wasn't put there to stay.
Love isn't love 'til you give it away.
-- Oscar Hammerstein II
^ permalink raw reply
* [PATCH] parsecvs: produce tagger fields acceptable to newer git versions
From: Lennert Buytenhek @ 2009-01-19 12:02 UTC (permalink / raw)
To: keithp; +Cc: git, jay, jim, kedars
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
diff --git a/git.c b/git.c
index da320d1..8f94d1b 100644
--- a/git.c
+++ b/git.c
@@ -371,11 +371,13 @@ git_mktag (rev_commit *commit, char *name)
"object %s\n"
"type commit\n"
"tag %s\n"
- "tagger %s\n"
+ "tagger %s <%s> %lu +0000\n"
"\n",
commit->sha1,
name,
- author ? author->full : commit->author);
+ author ? author->full : commit->author,
+ author ? author->email : commit->author,
+ commit->date);
if (rv < 1) {
fprintf (stderr, "%s: %s\n", filename, strerror (errno));
fclose (f);
^ permalink raw reply related
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