* [PATCH] Fix mkpath abuse in dwim_ref/sha1_name.c
From: Alex Riesen @ 2008-10-14 16:23 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Shawn O. Pearce
[-- Attachment #1: Type: text/plain, Size: 445 bytes --]
Otherwise the function sometimes fail to resolve obviously correct refnames,
because the string data pointed to by "ref" argument were reused.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
sha1_name.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
Frankly, I'm having hard time trying to justify _any_ use of mkpath.
It is a bug waiting to happen every time is any code between the
call site and assignment but strdup.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-mkpath-abuse-in-sha1_name.c.patch --]
[-- Type: text/x-patch; name=0001-Fix-mkpath-abuse-in-sha1_name.c.patch, Size: 1529 bytes --]
From 052e137d4ad8687d78bb2570390ed4f6b19f7cba Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Tue, 14 Oct 2008 18:14:20 +0200
Subject: [PATCH] Fix mkpath abuse in sha1_name.c
Otherwise the function sometimes fail to resolve obviously correct refnames,
because the string data pointed to by "ref" argument were reused.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
sha1_name.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 41b6809..b5b53bf 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -242,6 +242,7 @@ int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref)
{
const char **p, *r;
int refs_found = 0;
+ char fullref[PATH_MAX];
*ref = NULL;
for (p = ref_rev_parse_rules; *p; p++) {
@@ -249,7 +250,8 @@ int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref)
unsigned char *this_result;
this_result = refs_found ? sha1_from_ref : sha1;
- r = resolve_ref(mkpath(*p, len, str), this_result, 1, NULL);
+ snprintf(fullref, sizeof(fullref), *p, len, str);
+ r = resolve_ref(fullref, this_result, 1, NULL);
if (r) {
if (!refs_found++)
*ref = xstrdup(r);
@@ -272,7 +274,7 @@ int dwim_log(const char *str, int len, unsigned char *sha1, char **log)
char path[PATH_MAX];
const char *ref, *it;
- strcpy(path, mkpath(*p, len, str));
+ snprintf(path, sizeof(path), *p, len, str);
ref = resolve_ref(path, hash, 1, NULL);
if (!ref)
continue;
--
1.6.0.2.494.gb25da
^ permalink raw reply related
* Re: How many users of parsecvs are there?
From: Johannes Schindelin @ 2008-10-14 16:21 UTC (permalink / raw)
To: Alex Bennee; +Cc: git, keithp
In-Reply-To: <b2cdc9f30810140310l647eb2fbld3f6a1c608d029a@mail.gmail.com>
Hi,
On Tue, 14 Oct 2008, Alex Bennee wrote:
> I'm wondering how many people are there still using parsecvs to to track
> a live CVS tree?
I used it in conjunction with clonecvs at some stage, but did not need to
use parsecvs in the end, so I stayed with cvsimport.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] Fix fetch/pull when run without --update-head-ok
From: Johannes Schindelin @ 2008-10-14 16:17 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git, spearce
In-Reply-To: <alpine.LNX.1.00.0810141148010.19665@iabervon.org>
Hi,
On Tue, 14 Oct 2008, Daniel Barkalow wrote:
> On Tue, 14 Oct 2008, Johannes Schindelin wrote:
>
> > On Mon, 13 Oct 2008, Daniel Barkalow wrote:
> >
> > > On Mon, 13 Oct 2008, Johannes Schindelin wrote:
> > >
> > > > I actually understand now why the tests started failing: the
> > > > change from resolve_ref() to get_branch() as requested by Daniel
> > > > are at fault: get_branch() does not check if the branch has an
> > > > initial commit.
> > > >
> > > > I am actually regretting making this change. Daniel, do you agree
> > > > that it might be better to change back to resolve_ref(), so that
> > > > the initial complaint (IIRC Han-Wen git pull'ed into a freshly
> > > > initialized repository with that utterly bogus "git pull origin
> > > > master:master" line) is not re-raised?
> > >
> > > Is it, in fact, okay to fetch into the current branch if it's "yet
> > > to be born"? I feel like it shouldn't be, since you'll get exactly
> > > the same problem that you would if the branch already existed: the
> > > index reflects the previous state (in this case, it's empty), so git
> > > will show that you've staged removing all of the files, right? So
> > > this would make the check for --update-head-ok more strict than
> > > before, but I think the behavior change is correct.
> >
> > I think
> > http://thread.gmane.org/gmane.comp.version-control.git/31351/focus=31544
> > is the best link to see what Han-Wen said. Granted, it was a
> > misunderstanding on his part, but there have been quite a few people
> > with the same misunderstanding.
> >
> > So what they did was
> >
> > $ mkdir just-one-branch
> > $ cd just-one-branch
> > $ git init
> > $ git remote add origin <url>
> > $ git pull origin master:master
> >
> > And this _will_ work correctly. Except when using get_branch(NULL)
> > instead of the validating resolve_ref().
>
> "git pull origin master:master" invokes "git fetch" with --update-head-ok,
Does it? You're correct. I do not like it.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] Fix fetch/pull when run without --update-head-ok
From: Johannes Schindelin @ 2008-10-14 16:15 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <20081014150227.GC4856@spearce.org>
Hi,
On Tue, 14 Oct 2008, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Mon, 13 Oct 2008, Daniel Barkalow wrote:
> >
> > > On Mon, 13 Oct 2008, Johannes Schindelin wrote:
> > >
> > > > I actually understand now why the tests started failing: the change from
> > > > resolve_ref() to get_branch() as requested by Daniel are at fault:
> > > > get_branch() does not check if the branch has an initial commit.
> >
> > So, my vote is to revert back to resolve_ref(), even if it needs more
> > lines.
>
> Yes, I agree, resolve_ref() is the best thing to be using here,
> even if it is more code. get_branch() validates the commit and we
> don't want that. We really just want to know if the current branch
> is going to be updated, we don't care to what/why.
Actually, get_branch() does _not_ validate. Which is why it thinks that
the current branch is "master" even if there is no commit yet.
OTOH, resolve_ref() reads the SHA-1 of the ref, which fails in the case
that there has not been any commit yet.
Still, I think that it would be nice to allow "git pull origin
master:master" in a freshly initied non-bare repository, so I like
resolve_ref() better.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] Fix fetch/pull when run without --update-head-ok
From: Daniel Barkalow @ 2008-10-14 16:04 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <20081014150227.GC4856@spearce.org>
On Tue, 14 Oct 2008, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Mon, 13 Oct 2008, Daniel Barkalow wrote:
> >
> > > On Mon, 13 Oct 2008, Johannes Schindelin wrote:
> > >
> > > > I actually understand now why the tests started failing: the change from
> > > > resolve_ref() to get_branch() as requested by Daniel are at fault:
> > > > get_branch() does not check if the branch has an initial commit.
> >
> > So, my vote is to revert back to resolve_ref(), even if it needs more
> > lines.
>
> Yes, I agree, resolve_ref() is the best thing to be using here,
> even if it is more code. get_branch() validates the commit and we
> don't want that. We really just want to know if the current branch
> is going to be updated, we don't care to what/why.
It doesn't validate the commit; it doesn't even validate the symref. The
resolve_ref()-using code validates the symref, and I think that's an
error; we also don't care what state we'd update the current branch from.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH v2] Fix fetch/pull when run without --update-head-ok
From: Daniel Barkalow @ 2008-10-14 15:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, spearce
In-Reply-To: <alpine.DEB.1.00.0810141145491.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Tue, 14 Oct 2008, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 13 Oct 2008, Daniel Barkalow wrote:
>
> > On Mon, 13 Oct 2008, Johannes Schindelin wrote:
> >
> > > I actually understand now why the tests started failing: the change from
> > > resolve_ref() to get_branch() as requested by Daniel are at fault:
> > > get_branch() does not check if the branch has an initial commit.
> > >
> > > I am actually regretting making this change. Daniel, do you agree
> > > that it might be better to change back to resolve_ref(), so that the
> > > initial complaint (IIRC Han-Wen git pull'ed into a freshly initialized
> > > repository with that utterly bogus "git pull origin master:master"
> > > line) is not re-raised?
> >
> > Is it, in fact, okay to fetch into the current branch if it's "yet to be
> > born"? I feel like it shouldn't be, since you'll get exactly the same
> > problem that you would if the branch already existed: the index reflects
> > the previous state (in this case, it's empty), so git will show that
> > you've staged removing all of the files, right? So this would make the
> > check for --update-head-ok more strict than before, but I think the
> > behavior change is correct.
>
> I think
> http://thread.gmane.org/gmane.comp.version-control.git/31351/focus=31544
> is the best link to see what Han-Wen said. Granted, it was a
> misunderstanding on his part, but there have been quite a few people with
> the same misunderstanding.
>
> So what they did was
>
> $ mkdir just-one-branch
> $ cd just-one-branch
> $ git init
> $ git remote add origin <url>
> $ git pull origin master:master
>
> And this _will_ work correctly. Except when using get_branch(NULL)
> instead of the validating resolve_ref().
"git pull origin master:master" invokes "git fetch" with --update-head-ok,
so it doesn't matter for this case what "git fetch" does without
--update-head-ok.
The check would block:
$ git fetch origin master:master
but this also would fail to update the working directory and would leave
the index as if you're removing everything.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: EGIT compare editor
From: Shawn O. Pearce @ 2008-10-14 15:05 UTC (permalink / raw)
To: Chris Dumoulin; +Cc: git
In-Reply-To: <48F4AA33.40605@oanda.com>
Chris Dumoulin <dumoulin@oanda.com> wrote:
> I seem to have successfully installed EGIT in Eclipse 3.4.1, but I can't
> figure out how to bring up the compare editor to view diffs.
>
> I expect that after right-clicking on a changed file, I would have some
> option under "Compare With" or "Team" that would allow me to diff the
> current file against the HEAD or some other revision using the compare
> editor, but I can't seem to find any way to do this. How do I bring up
> the compare editor to view diffs?
Robin knows the Eclipse integration better than I, but we may be
missing the feature to compare the working directory revision to
the last committed revision (or the index revision).
I'm pretty sure the compare editor is available in the History view
(Team -> Show resource in History) by double clicking the file
path when a commit node is selected. But that's obviously only
historical diffs.
--
Shawn.
^ permalink raw reply
* retrieving a diff from git
From: Folkert van Heusden @ 2008-10-14 14:51 UTC (permalink / raw)
To: git
Hi,
How would I retrieve the 'kmemcheck' patches from git for the 2.6.27
kernel? I browsed to the url
http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fx86%2Flinux-2.6-tip.git&a=search&h=HEAD&st=commit&s=kmemcheck
but could not find how to retrieve that diff.
Folkert van Heusden
--
Ever wonder what is out there? Any alien races? Then please support
the seti@home project: setiathome.ssl.berkeley.edu
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
^ permalink raw reply
* Re: [PATCH v2] Fix fetch/pull when run without --update-head-ok
From: Shawn O. Pearce @ 2008-10-14 15:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0810141145491.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Mon, 13 Oct 2008, Daniel Barkalow wrote:
>
> > On Mon, 13 Oct 2008, Johannes Schindelin wrote:
> >
> > > I actually understand now why the tests started failing: the change from
> > > resolve_ref() to get_branch() as requested by Daniel are at fault:
> > > get_branch() does not check if the branch has an initial commit.
>
> So, my vote is to revert back to resolve_ref(), even if it needs more
> lines.
Yes, I agree, resolve_ref() is the best thing to be using here,
even if it is more code. get_branch() validates the commit and we
don't want that. We really just want to know if the current branch
is going to be updated, we don't care to what/why.
--
Shawn.
^ permalink raw reply
* [PATCH] Add Linux PPC support to the pre-auto-gc example hook
From: Miklos Vajna @ 2008-10-14 14:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
contrib/hooks/pre-auto-gc-battery | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/contrib/hooks/pre-auto-gc-battery b/contrib/hooks/pre-auto-gc-battery
index b0a8caa..1f914c9 100644
--- a/contrib/hooks/pre-auto-gc-battery
+++ b/contrib/hooks/pre-auto-gc-battery
@@ -30,6 +30,9 @@ then
elif grep -q '0x01$' /proc/apm 2>/dev/null
then
exit 0
+elif grep -q "AC Power \+: 1" /proc/pmu/info 2>/dev/null
+then
+ exit 0
elif test -x /usr/bin/pmset && /usr/bin/pmset -g batt |
grep -q "Currently drawing from 'AC Power'"
then
--
1.6.0.2
^ permalink raw reply related
* EGIT compare editor
From: Chris Dumoulin @ 2008-10-14 14:18 UTC (permalink / raw)
To: git
I seem to have successfully installed EGIT in Eclipse 3.4.1, but I can't
figure out how to bring up the compare editor to view diffs.
The EGIT plugin seems to be loaded and working for my project; I see
"[Git @ master]" beside the project name, and ">" beside changed files.
Also, the quickdiff seems to be working; I see a different colour in the
left margin beside changes within the file. The "Team" context menu
seems to be populated properly: "Commit", "Update Index (Refresh)",
"Show in Resource History", "Assume unchanged", "Track (Add)", "Untrack
(Remove)", "Apply Patch...", and below the separator "Show Local History".
I expect that after right-clicking on a changed file, I would have some
option under "Compare With" or "Team" that would allow me to diff the
current file against the HEAD or some other revision using the compare
editor, but I can't seem to find any way to do this. How do I bring up
the compare editor to view diffs?
Thanks,
Chris
^ permalink raw reply
* Re: Rerunning merge on a single file
From: Kristian Amlie @ 2008-10-14 12:48 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <adf1fd3d0810140521g7f43ee3bs5d4e60772bcc1d8c@mail.gmail.com>
Santi Béjar wrote:
> On Tue, Oct 14, 2008 at 2:13 PM, Kristian Amlie
> <kristian.amlie@trolltech.com> wrote:
>> Hey, I have question about advanced merging.
>>
>> Suppose I have a huge merge with conflicts all over the place. There is no
>> way to avoid them, so I start working from the top. At some point, however,
>> I make a mistake and lose the merge information for one file (for example by
>> checking out the file from HEAD).
>>
>> In that case I would like to get the conflict markers back, and do that file
>> over again, but I don't want to throw away the rest of the index state.
>> Currently the only way I can see to do this is by checking out several file
>> versions under different names and then using git merge-file on them.
>>
>> Is there a better way to achieve this?
>
> If the different versions are still in the index you could use:
>
> $ git checkout --merge $file
In my case the files were added to the index already, so I guess it
doesn't work then?
Kristian
^ permalink raw reply
* Re: Rerunning merge on a single file
From: Santi Béjar @ 2008-10-14 12:28 UTC (permalink / raw)
To: Kristian Amlie; +Cc: git
In-Reply-To: <adf1fd3d0810140521g7f43ee3bs5d4e60772bcc1d8c@mail.gmail.com>
On Tue, Oct 14, 2008 at 2:21 PM, Santi Béjar <santi@agolina.net> wrote:
> On Tue, Oct 14, 2008 at 2:13 PM, Kristian Amlie
> <kristian.amlie@trolltech.com> wrote:
>> Hey, I have question about advanced merging.
>>
>> Suppose I have a huge merge with conflicts all over the place. There is no
>> way to avoid them, so I start working from the top. At some point, however,
>> I make a mistake and lose the merge information for one file (for example by
>> checking out the file from HEAD).
>>
>> In that case I would like to get the conflict markers back, and do that file
>> over again, but I don't want to throw away the rest of the index state.
>> Currently the only way I can see to do this is by checking out several file
>> versions under different names and then using git merge-file on them.
>>
>> Is there a better way to achieve this?
>
> If the different versions are still in the index you could use:
>
> $ git checkout --merge $file
Note that this is very new, as it was introduced in
v1.6.0.1-26-geac5a40, so you'll need at least 1.6.0.2.
Santi
^ permalink raw reply
* Re: Rerunning merge on a single file
From: Santi Béjar @ 2008-10-14 12:21 UTC (permalink / raw)
To: Kristian Amlie; +Cc: git
In-Reply-To: <48F48CDB.1010309@trolltech.com>
On Tue, Oct 14, 2008 at 2:13 PM, Kristian Amlie
<kristian.amlie@trolltech.com> wrote:
> Hey, I have question about advanced merging.
>
> Suppose I have a huge merge with conflicts all over the place. There is no
> way to avoid them, so I start working from the top. At some point, however,
> I make a mistake and lose the merge information for one file (for example by
> checking out the file from HEAD).
>
> In that case I would like to get the conflict markers back, and do that file
> over again, but I don't want to throw away the rest of the index state.
> Currently the only way I can see to do this is by checking out several file
> versions under different names and then using git merge-file on them.
>
> Is there a better way to achieve this?
If the different versions are still in the index you could use:
$ git checkout --merge $file
Santi
^ permalink raw reply
* Rerunning merge on a single file
From: Kristian Amlie @ 2008-10-14 12:13 UTC (permalink / raw)
To: git
Hey, I have question about advanced merging.
Suppose I have a huge merge with conflicts all over the place. There is
no way to avoid them, so I start working from the top. At some point,
however, I make a mistake and lose the merge information for one file
(for example by checking out the file from HEAD).
In that case I would like to get the conflict markers back, and do that
file over again, but I don't want to throw away the rest of the index
state. Currently the only way I can see to do this is by checking out
several file versions under different names and then using git
merge-file on them.
Is there a better way to achieve this?
Kristian
^ permalink raw reply
* [PATCH] git-gui: Do not munge conflict marker lines in a normal diff
From: Johannes Sixt @ 2008-10-14 11:48 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List
From: Johannes Sixt <johannes.sixt@telecom.at>
Previously, conflict markers were highlighted in two ways: (1) They
received a distinguishing color; and (2) they had the '+' removed at the
beginning of the line. However, by doing (2), a hunk that contained
conflict markers could not be staged or unstaged because the resulting
patch was corrupted. With this change we no longer modify the diff text
of a 2-way diff, so that "Stage Hunk" and friends work.
Note that 3-way diff of a conflicted file is unaffected by this change,
and '++' before conflict markers is still removed. But this has no negative
impact because in this mode staging hunks or lines is disabled anyway.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
lib/diff.tcl | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/lib/diff.tcl b/lib/diff.tcl
index bdcbbf8..94ee38c 100644
--- a/lib/diff.tcl
+++ b/lib/diff.tcl
@@ -377,7 +377,6 @@ proc read_diff {fd cont_info} {
{+} {
if {[regexp {^\+([<>]{7} |={7})} $line _g op]} {
set is_conflict_diff 1
- set line [string replace $line 0 0 { }]
set tags d$op
} else {
set tags d_+
--
1.6.0.2.1493.g2969e
^ permalink raw reply related
* Re: [BUG?] git remote rm repo nukes local refs for mirror repo
From: Michael J Gruber @ 2008-10-14 11:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0810141131130.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin venit, vidit, dixit 14.10.2008 11:32:
> Hi,
>
> On Tue, 14 Oct 2008, Michael J Gruber wrote:
>
>> I just noticed the hard way that "git remote rm repo" nukes all local
>> (mirrored) refs if repo had been setup with "git remote add --mirror
>> repo url".
>>
>> Some may argue that this behaviour fits the description "deletes all
>> remote tracking branches" but I would claim it does not: mirrored
>> branches are not remote tracking branches in the proper sense.
>
> Count me into the former group. If you set up a "--mirror" repository, it
> defeats the purpose to mix that with _true_ local branches.
>
> I'd color this a pilot error,
> Dscho
OK, I'll give some background about the motivation:
I have a "local" repo.
I want to create a "backup repo" which contains the same branches
(including proper remotes, svn remotes).
So, I create an empty bare repo somewhere (say store:backuprepo.git),
and in the local repo I do:
git remote add --mirror backup store:backuprepo.git
git push backup
I need "mirror=true" because otherwise branches are not created
automatically (on push) on the remote side. I need the '+refs/*:refs/*'
refspec because otherwise not all refs are mirrored. But now I can't use
"git remote rm backup" to remove the configuration because that would
take away all my local branches, too.
Instead, I could set up things with
git remote add backup store:backuprepo.git
git config remote.backup.push '+refs/*:refs/*'
Then all branches are mirrored on the remote automatically. But
interesting things happen after fetch and push... Read "recursion". So,
in order to avoid any remote/backup/foo branches on the local side I
would have to use
git remote add backup store:backuprepo.git
git config remote.backup.push '+refs/*:refs/*'
git config --unset remote.backup.fetch
in order to create a "backup remote" configuration. Maybe I'm just being
dense (which is actually OK for a functional analyst); I'd be happy
about any more direct solution. At least I think there should be one, a
backup bare remote mirror is a common use case, and the config massaging
above is not something to recommend to novice users.
Michael
P.S.: Yeah I know, git's no backup tool, there's rsync... ;)
^ permalink raw reply
* Re: concerns about git
From: Ciprian Dorin Craciun @ 2008-10-14 11:25 UTC (permalink / raw)
To: Brandon; +Cc: David Tweed, Shawn O. Pearce, deepwinter, git
In-Reply-To: <82c87da00810131251i52d10170h5c1991e2da0bd208@mail.gmail.com>
On Mon, Oct 13, 2008 at 10:51 PM, Brandon <siamesedream01@gmail.com> wrote:
> You can use "git config core.worktree <location>" to create a ".git"
> folder that manages a working copy in another location.
>
> I know some of the GUI tools don't support this though so I would only
> use it if truly necessary . (For example a using git to manage a
> mapped network drive, it would be faster to keep the ".git" folder on
> the local harddrive)
>
> More documentation here: http://www.kernel.org/pub/software/scm/git/docs/
>
> On Mon, Oct 13, 2008 at 2:40 PM, David Tweed <david.tweed@gmail.com> wrote:
>> On Mon, Oct 13, 2008 at 7:19 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
>>> # then every once in a while, or from a cron job
>>> $ git push --all backup
>>>
>>> Of course since Git is distributed you can you use this same approach
>>> to make backups to other systems. You can even edit the .git/config
>>> to give the [remote "backup"] section more than one url line, so
>>> that "git push --all backup" will send updated copies to multiple
>>> locations at once.
>>
>> Another advantage of 'git push'ing to another repository (possibly via
>> cron) as backup is that (for technical reasons) git push has to
>> 'parse' the new changes to your repository in order to push, so it is
>> likely to spot corruption (eg, dying disk) at that time and when you
>> can decide what to do about it. (I have enough backups all over the
>> place that I don't worry about not having a 'copy' of any stuff I care
>> about, but that there'll be some fatal corruption I don't notice
>> immediately that then gets propagated everywhere rendering them
>> useless.)
>>
>> --
>> cheers, dave tweed__________________________
>> david.tweed@gmail.com
I have the same problem as David, but I manage it by using a
symlink. That is my .git folder is a symlink to the real repository
(possibly on another partition). (So far I had no problems with this
setup.)
Ciprian Dorin Craciun.
^ permalink raw reply
* Re: [BUG?] git remote rm repo nukes local refs for mirror repo
From: Samuel Tardieu @ 2008-10-14 10:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Michael J Gruber, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0810141131130.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Michael> I just noticed the hard way that "git remote rm repo" nukes
Michael> all local (mirrored) refs if repo had been setup with "git
Michael> remote add --mirror repo url". Some may argue that this
Michael> behaviour fits the description "deletes all remote tracking
Michael> branches" but I would claim it does not: mirrored branches
Michael> are not remote tracking branches in the proper sense.
Johannes> Count me into the former group. If you set up a "--mirror"
Johannes> repository, it defeats the purpose to mix that with _true_
Johannes> local branches.
IMO it should exit with an error and force to use "--force" to perform
the operation. The scenario I envision is a mirror becoming the
primary repository because the original source has disappeared. You
would want to remove the now-useless reference to the source, and
silently nuking all branches is wrong.
Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/
^ permalink raw reply
* How many users of parsecvs are there?
From: Alex Bennee @ 2008-10-14 10:10 UTC (permalink / raw)
To: git; +Cc: keithp
I'm wondering how many people are there still using parsecvs to to
track a live CVS tree?
I've been using it for a while at work to track a rather monster CVS
repository. The main reasons are:
1. It's the fastest import I've come across so far. Given the size of
the CVS repo other solutions took far too long to do the conversion
2. It's simple to configure (if you can call "find" configuring),
assuming you have access to the CVS repo proper
3. It reliably regenerates the repository so you can run the entire
conversion from scratch the next day and hapily pull into working
repos (I assume if I got tother working they should exhibit this
property).
However I have come across a few problems. One of which involves files
not getting put into branches which I've managed hack a band-aid
solution for that involves ignoring date discrepancies. However having
mailed keith he made it clear he doesn't use it any more having
converted his stuff so it's currently not being actively maintained.
So the question really is are there people out there still using it?
If not I'll hang up my code exploring boots and have another go at
whatever is considered the best in class iterative CVS to GIT gateway.
If it's still a useful tool for other people as well I'm happy to
delve deeper into the code and seeing if any of the crinkles can be
ironed out.
It's interesting to note from the Git Users Survey 2008 that CVS is
still the second most used legacy version control system. One could
draw the conclusion that having a well supported bullet proof
incremental CVS import mechanism as part of git should still be a
fairly important goal. There are a lot (too many?) out of tree
solutions out there which makes approaching the task somewhat daunting
when first coming to git.
--
Alex, homepage: http://www.bennee.com/~alex/
^ permalink raw reply
* Re: [PATCH v2] Fix fetch/pull when run without --update-head-ok
From: Johannes Schindelin @ 2008-10-14 9:49 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git, spearce
In-Reply-To: <alpine.LNX.1.00.0810131546180.19665@iabervon.org>
Hi,
On Mon, 13 Oct 2008, Daniel Barkalow wrote:
> On Mon, 13 Oct 2008, Johannes Schindelin wrote:
>
> > I actually understand now why the tests started failing: the change from
> > resolve_ref() to get_branch() as requested by Daniel are at fault:
> > get_branch() does not check if the branch has an initial commit.
> >
> > I am actually regretting making this change. Daniel, do you agree
> > that it might be better to change back to resolve_ref(), so that the
> > initial complaint (IIRC Han-Wen git pull'ed into a freshly initialized
> > repository with that utterly bogus "git pull origin master:master"
> > line) is not re-raised?
>
> Is it, in fact, okay to fetch into the current branch if it's "yet to be
> born"? I feel like it shouldn't be, since you'll get exactly the same
> problem that you would if the branch already existed: the index reflects
> the previous state (in this case, it's empty), so git will show that
> you've staged removing all of the files, right? So this would make the
> check for --update-head-ok more strict than before, but I think the
> behavior change is correct.
I think
http://thread.gmane.org/gmane.comp.version-control.git/31351/focus=31544
is the best link to see what Han-Wen said. Granted, it was a
misunderstanding on his part, but there have been quite a few people with
the same misunderstanding.
So what they did was
$ mkdir just-one-branch
$ cd just-one-branch
$ git init
$ git remote add origin <url>
$ git pull origin master:master
And this _will_ work correctly. Except when using get_branch(NULL)
instead of the validating resolve_ref().
When we talk about not breaking existing behavior, we have to talk about
this behavior, too.
So, my vote is to revert back to resolve_ref(), even if it needs more
lines.
Thoughts of others?
Ciao,
Dscho
^ permalink raw reply
* Re: [BUG?] git remote rm repo nukes local refs for mirror repo
From: Johannes Schindelin @ 2008-10-14 9:32 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Git Mailing List
In-Reply-To: <48F460DB.9030209@drmicha.warpmail.net>
Hi,
On Tue, 14 Oct 2008, Michael J Gruber wrote:
> I just noticed the hard way that "git remote rm repo" nukes all local
> (mirrored) refs if repo had been setup with "git remote add --mirror
> repo url".
>
> Some may argue that this behaviour fits the description "deletes all
> remote tracking branches" but I would claim it does not: mirrored
> branches are not remote tracking branches in the proper sense.
Count me into the former group. If you set up a "--mirror" repository, it
defeats the purpose to mix that with _true_ local branches.
I'd color this a pilot error,
Dscho
^ permalink raw reply
* [BUG?] git remote rm repo nukes local refs for mirror repo
From: Michael J Gruber @ 2008-10-14 9:05 UTC (permalink / raw)
To: Git Mailing List
I just noticed the hard way that "git remote rm repo" nukes all local
(mirrored) refs if repo had been setup with "git remote add --mirror
repo url".
Some may argue that this behaviour fits the description "deletes all
remote tracking branches" but I would claim it does not: mirrored
branches are not remote tracking branches in the proper sense.
So:
- Is this behaviour intended?
- If yes, how else would I remove a remote mirror configuration without
destroying a local repo? git config, I know, but that can't be the way.
Michael
Technical:
remote_find_tracking() in remote.c returns "branch" as the remote
tracking branch of "branch" (itself) in a mirror setup. Is this the
right thing to do?
^ permalink raw reply
* Re: View remote logs?
From: Michael J Gruber @ 2008-10-14 8:21 UTC (permalink / raw)
To: git
In-Reply-To: <20081014071907.GP16999@penguin.codegnome.org>
Todd A. Jacobs venit, vidit, dixit 14.10.2008 09:19:
> I've Googled around, and tried some experiments with likely-looking
> tools like git log, git diff, and git ls-remote, but they only seem to
> operate on the local repository. In particular, there doesn't seem to be
> an obvious way to view the commit logs on a remote repository without
> pulling it first.
>
> On an intuitive level, it seems like "git log origin" would allow me to
> see what someone has committed to a remote repository so I can decide
> whether it's something I want to pull. Even something like "git diff
> HEAD origin" would let me know if there were changes I might want to
> pull before doing so.
>
> Am I missing something obvious? Is it possible to use the CLI to view
> remote logs, or is the only choice to pull everything?
You can always fetch (rather than pull) and then decide whether to pull
(i.e. merge or rebase FETCH_HEAD) or not.
The problem with "remote log" is that log can show diffstats, full diffs
etc, so that it would need all new objects anyways.
If you want to avoid fetching new objects the only way is to run git log
etc. on the remote side. You can do this with ssh, but the other
transports (git:, http:) don't support this.
Michael
^ permalink raw reply
* Re: View remote logs?
From: Jeff King @ 2008-10-14 8:10 UTC (permalink / raw)
To: git
In-Reply-To: <20081014071907.GP16999@penguin.codegnome.org>
On Tue, Oct 14, 2008 at 12:19:07AM -0700, Todd A. Jacobs wrote:
> I've Googled around, and tried some experiments with likely-looking
> tools like git log, git diff, and git ls-remote, but they only seem to
> operate on the local repository. In particular, there doesn't seem to be
> an obvious way to view the commit logs on a remote repository without
> pulling it first.
Remember that pull is really "fetch + merge". So you can do just the
fetch part without affecting your local branches.
> On an intuitive level, it seems like "git log origin" would allow me to
> see what someone has committed to a remote repository so I can decide
It does. It just uses the remote tracking branch for "origin" instead of
contacting the remote.
> whether it's something I want to pull. Even something like "git diff
> HEAD origin" would let me know if there were changes I might want to
> pull before doing so.
And that works, too. Once fetched, you can use "origin" as you would any
other ref.
-Peff
^ permalink raw reply
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