* [PATCH] More permissive "git-rm --cached" behavior without -f.
From: Matthieu Moy @ 2007-07-13 17:41 UTC (permalink / raw)
To: git, Johannes Schindelin; +Cc: Matthieu Moy
In-Reply-To: <vpq8x9k9peu.fsf@bauges.imag.fr>
In the previous behavior, "git-rm --cached" (without -f) had the same
restriction as "git-rm". This forced the user to use the -f flag in
situations which weren't actually dangerous, like:
$ git add foo # oops, I didn't want this
$ git rm --cached foo # back to initial situation
Previously, the index had to match the file *and* the HEAD. With
--cached, the index must now match the file *or* the HEAD. The behavior
without --cached is unchanged, but provides better error messages.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Documentation/git-rm.txt | 3 ++-
builtin-rm.c | 32 ++++++++++++++++++++++++++------
t/t3600-rm.sh | 34 ++++++++++++++++++++++++++++++++++
3 files changed, 62 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
index 78f45dc..be61a82 100644
--- a/Documentation/git-rm.txt
+++ b/Documentation/git-rm.txt
@@ -14,7 +14,8 @@ DESCRIPTION
Remove files from the working tree and from the index. The
files have to be identical to the tip of the branch, and no
updates to its contents must have been placed in the staging
-area (aka index).
+area (aka index). When --cached is given, the staged content has to
+match either the tip of the branch *or* the file on disk.
OPTIONS
diff --git a/builtin-rm.c b/builtin-rm.c
index 4a0bd93..9a808c1 100644
--- a/builtin-rm.c
+++ b/builtin-rm.c
@@ -46,7 +46,7 @@ static int remove_file(const char *name)
return ret;
}
-static int check_local_mod(unsigned char *head)
+static int check_local_mod(unsigned char *head, int index_only)
{
/* items in list are already sorted in the cache order,
* so we could do this a lot more efficiently by using
@@ -65,6 +65,8 @@ static int check_local_mod(unsigned char *head)
const char *name = list.name[i];
unsigned char sha1[20];
unsigned mode;
+ int local_changes = 0;
+ int staged_changes = 0;
pos = cache_name_pos(name, strlen(name));
if (pos < 0)
@@ -87,14 +89,32 @@ static int check_local_mod(unsigned char *head)
continue;
}
if (ce_match_stat(ce, &st, 0))
- errs = error("'%s' has local modifications "
- "(hint: try -f)", ce->name);
+ local_changes = 1;
if (no_head
|| get_tree_entry(head, name, sha1, &mode)
|| ce->ce_mode != create_ce_mode(mode)
|| hashcmp(ce->sha1, sha1))
- errs = error("'%s' has changes staged in the index "
- "(hint: try -f)", name);
+ staged_changes = 1;
+
+ if (local_changes && staged_changes)
+ errs = error("'%s' has staged content different "
+ "from both the file and the HEAD\n"
+ "(use -f to force removal)", name);
+ else if (!index_only) {
+ /* It's not dangerous to git-rm --cached a
+ * file if the index matches the file or the
+ * HEAD, since it means the deleted content is
+ * still available somewhere.
+ */
+ if (staged_changes)
+ errs = error("'%s' has changes staged in the index\n"
+ "(use --cached to keep the file, "
+ "or -f to force removal)", name);
+ if (local_changes)
+ errs = error("'%s' has local modifications\n"
+ "(use --cached to keep the file, "
+ "or -f to force removal)", name);
+ }
}
return errs;
}
@@ -192,7 +212,7 @@ int cmd_rm(int argc, const char **argv, const char *prefix)
unsigned char sha1[20];
if (get_sha1("HEAD", sha1))
hashclr(sha1);
- if (check_local_mod(sha1))
+ if (check_local_mod(sha1, index_only))
exit(1);
}
diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh
index 13a461f..5c001aa 100755
--- a/t/t3600-rm.sh
+++ b/t/t3600-rm.sh
@@ -46,6 +46,40 @@ test_expect_success \
'git rm --cached foo'
test_expect_success \
+ 'Test that git rm --cached foo succeeds if the index matches the file' \
+ 'echo content > foo
+ git add foo
+ git rm --cached foo'
+
+test_expect_success \
+ 'Test that git rm --cached foo succeeds if the index matches the file' \
+ 'echo content > foo
+ git add foo
+ git commit -m foo
+ echo "other content" > foo
+ git rm --cached foo'
+
+test_expect_failure \
+ 'Test that git rm --cached foo fails if the index matches neither the file nor HEAD' \
+ 'echo content > foo
+ git add foo
+ git commit -m foo
+ echo "other content" > foo
+ git add foo
+ echo "yet another content" > foo
+ git rm --cached foo'
+
+test_expect_success \
+ 'Test that git rm --cached -f foo works in case where --cached only did not' \
+ 'echo content > foo
+ git add foo
+ git commit -m foo
+ echo "other content" > foo
+ git add foo
+ echo "yet another content" > foo
+ git rm --cached -f foo'
+
+test_expect_success \
'Post-check that foo exists but is not in index after git rm foo' \
'[ -f foo ] && ! git ls-files --error-unmatch foo'
--
1.5.3.rc1.4.gaf83-dirty
^ permalink raw reply related
* Re: Better handling of local changes in 'gitk'?
From: Linus Torvalds @ 2007-07-13 17:36 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List
In-Reply-To: <18071.19489.6733.665052@cargo.ozlabs.ibm.com>
On Fri, 13 Jul 2007, Paul Mackerras wrote:
>
> Try this, let me know what you think. I called the changes in the
> working directory "Local uncommitted changes, not checked in to index"
> and the changes in the index "Local changes checked in to index but
> not committed".
ACK.
This matches exactly what I was thinking of.
The red vs magenta looks a bit too close in color for me (red, green and
blue?), but quite frankly, it's not like I really care.
Those author/date fields look really empty, but that's probably a good way
to emphasize that they aren't real commits, so while it's visually a bit
strange, it probably is the right thing to do.
Linus
^ permalink raw reply
* Re: [RFC][PATCH] Re: git-rm isn't the inverse action of git-add
From: Matthieu Moy @ 2007-07-13 17:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Jan Hudec, Yann Dirson, Christian Jaeger
In-Reply-To: <Pine.LNX.4.64.0707082240510.4248@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > However, if some of the files are of the first kind, and some are of
>> > the second kind, you happily apply with mixed strategies. IMO that is
>> > wrong.
>>
>> I'm not sure whether this is really wrong. The things git should
>> really care about are the index and the repository itself, and the
>> proposed behavior is consistant regarding that (either remove all
>> files from the index, or remove none).
>
> Well, I think it is wrong for the same reason as it is wrong to apply the
> changes to _any_ file when one would fail. And since "git apply" shares
> my understanding, I think "git rm" should, too.
OK, I've been thinking about it for some time (not having time to hack
can be good, it lets time for thinking instead ;-) ).
I'm actually still not convinced that my proposal was wrong, but I
think we disagree because we disagree on what is a "failure". I
consider leaving the file in the working tree to be just a safety
precaution, not a failure, and to me, it's OK to do that only for the
files that need it.
Fixing my patch by just "applying the same strategy to all files"
would be wrong: leaving _all_ the files on disk when just one has
local modifications is very misleading, and if the user notices it
after running the command, he or she does not always have an easy way
to get back to a clean situation (re-running the same command with -f
wouldn't work for example).
So, I went a shorter way from the current semantics:
* Allow --cached in more situations, so that -f is really needed in
very particular situation (as I mentionned above, forcing -f too
often means the -f gets hardcoded in the fingers, and makes it
useless).
* Better error message, which points to --cached in addition to -f.
That's very close to what bzr does, BTW.
Drawback: it still doesn't solve the "rm isn't the inverse of add".
The patch is quite straightforward, and will be in a followup email.
--
Matthieu
^ permalink raw reply
* git-svn: trunk missing, checks out tag instead
From: Bradford Smith @ 2007-07-13 17:24 UTC (permalink / raw)
To: git
I am using git-svn version 1.5.3.rc1.4.gaf83 (svn 1.4.3), and I work
with an SVN repository that is layed out like this:
/trunk/proj1/
...
/trunk/proj2/
...
/trunk/testing/
...
/branches/proj1/
...
/branches/proj2/
...
/branches/testing/
/branches/testing/0000-baseline
/tags/proj1/
...
/tags/proj2/
...
/tags/testing/
/tags/testing/0000-baseline-0
I want to track the testing project, so I tried to use this git-svn
command line:
git-svn clone <base-url> -T/trunk/testing -t/tags/testing
-b/branches/testing testing
This appears to work, though I do get this warning message (edited for privacy):
W: Ignoring error from SVN, path probably does not exist: (175002): RA
layer request failed: REPORT request failed on
'/<server_path>/!svn/bc/101': REPORT of '/<server_path>!svn/bc/101':
Could not read chunk size: Secure connection truncated
(https://<myserver>)
When I run 'git branch -a' in the new testing directory I get this:
* master
0000-baseline
0000-baseline@1546
1.0
1.0@1549
1.0@1656
tags/0000-baseline
tags/0000-baseline-0
tags/0000-baseline@1663
Where is the remote branch for trunk? And, why do I have remote
entries for the defunct 1.0 branch that I deleted from svn earlier
today? What's more, the latest changes from /trunk/testing do not
appear in my working directory, and gitk confirms that master is
pointing at the same commit as tags/0000-baseline-0.
If I just try to track the trunk like this:
git-svn clone <base-url>/trunk/testing
Then I get all of the latest changes and 'git branch -a' shows:
* master
git-svn
So that seems OK at least. It just doesn't work when I try to get
branches and tags. For now, I'll just work this way.
FWIW, I suspect this behavior may be related to recent changes I made
to the Subversion repository. I created
/branches/testing/0000-baseline today by copying an _old_ revision of
/trunk/testing. Then I created /tags/testing/0000-baseline-0 by
copying /branches/testing/0000-baseline. No commits have been done on
/testing/trunk since then. Perhaps the recent (probably latest)
commit that copied an OLD version of trunk is somehow confusing
git-svn? Once I commit a change to the subversion trunk, I'll try to
clone trunk, branches, and tags again and post an update to this
message. Maybe it will work then.
Thanks for your help.
Bradford C. Smith
^ permalink raw reply
* Re: git fetch inside a bare repo does nothing
From: Peter Baumann @ 2007-07-13 17:16 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0707130548s709709a2nf621b19d10e238a0@mail.gmail.com>
On Fri, Jul 13, 2007 at 02:48:19PM +0200, Alex Riesen wrote:
> On 7/13/07, Peter Baumann <waste.manager@gmx.de> wrote:
>> I suggested to use "git fetch --bare" inside the bare repo, but this
>
> "git --bare fetch".
>
> You swapped "fetch" and "--bare".
Sorry, this was only a typo in the mail.
But the problem got fixed, anyway.
-Peter
^ permalink raw reply
* Re: failing to send patches to the list
From: Jeff King @ 2007-07-13 15:55 UTC (permalink / raw)
To: git discussion list
In-Reply-To: <20070713093050.GA18001@lapse.madduck.net>
On Fri, Jul 13, 2007 at 11:30:50AM +0200, martin f krafft wrote:
> git format-patch -s --stdout | sendmail git@vger.kernel.org
>
> Even though my mail server seems to have delivered them correctly:
> [...]
> they never made it onto the list.
vger will reject messages without a message-id. git-format-patch by
default does not generate a message-id, so unless sendmail generates one
on the fly, that is your problem.
In general, git-format-patch output is probably not suitable for direct
sending...have you looked at git-send-email?
-Peff
^ permalink raw reply
* Re: [PATCH 2/4] Move the --decorate option from builtin-log.c to revision.c.
From: Johannes Schindelin @ 2007-07-13 15:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4pk9v4tp.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 12 Jul 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > ---decorate::
> > - Print out the ref names of any commits that are shown.
> > -
> > ...
> > +
> > +--decorate::
> > + When a commit is shown, and it matches a ref, print that ref name
> > + in brackets after the commit name.
>
> The character-pair ( and ) are usually called parentheses, not
> brackets.
Okay. You want me to resend, or will you fix it?
Ciao,
Dscho
^ permalink raw reply
* Re: Draft release notes for v1.5.3, as of -rc1
From: Junio C Hamano @ 2007-07-13 15:31 UTC (permalink / raw)
To: Brian Downing; +Cc: git
In-Reply-To: <20070713135034.GK19073@lavos.net>
bdowning@lavos.net (Brian Downing) writes:
> On Thu, Jul 12, 2007 at 11:40:39PM -0700, Junio C Hamano wrote:
>> GIT v1.5.3 Release Notes (draft)
>> ========================
>>
>> * New commands and options.
>
> - "git repack" learned a "window-memory" limit which dynamically
> reduces the window size to stay within the specified memory usage.
Thanks.
> "git-repack -a -d -f --window=100000 --window-memory=512m" seems to be
> good for those overnight make-it-smaller-damn-the-torpedoes archival
> repackings. (You can't just set --window to BIGNUM as it still
> allocates an array of that size.) Thanks to Nicolas Pitre's depth bias
> patch a high --depth doesn't seem to be quite as critical anymore to
> save space; it still helps, but things much much better at a lower
> depth.
This probably should go to Documentation/git-repack.txt
somewhere.
^ permalink raw reply
* CVS -> SVN -> Git
From: Julian Phillips @ 2007-07-13 14:48 UTC (permalink / raw)
To: git
Has anyone managed to succssfully import a Subversion repository that was
initially imported from CVS using cvs2svn using fast-import?
It looks like cvs2svn has created a rather big mess. It has created
single commits that change files in more than one branch and/or tag.
It also creates tags using more than one commit. Now I come to try and
import the Subversion history into git and I'm having trouble creating a
sensible stream to feed into fast-import.
I'm trying to use fast-import because git-svnimport creates a incorrect
repository that is missing files and even whole directories (I suppose
this could be due to the confusion from cvs2svn), and git-svn is a) _way_
too slow, b) doesn't do merges and c) munges the commit comments.
--
Julian
---
Riffle West Virginia is so small that the Boy Scout had to double as the
town drunk.
^ permalink raw reply
* Re: [PATCH] Documentation for git-log --follow
From: Johannes Schindelin @ 2007-07-13 14:47 UTC (permalink / raw)
To: Steven Walter; +Cc: git
In-Reply-To: <20070712145230.GA21590@dervierte>
Hi,
On Thu, 12 Jul 2007, Steven Walter wrote:
> +--follow::
> + Continue listing the history of a file beyond renames.
> +
Maybe say "Follow the history of a file beyond renames"?
> @@ -91,6 +94,12 @@ git log -r --name-status release..test::
> in the "release" branch, along with the list of paths
> each commit modifies.
>
> +git log --follow builtin-rev-list.c::
> +
> + Shows the commits that changed builtin-rev-list.c, including
> + those commits that occurred before the file was given its
> + present name.
> +
This is not particularly clear IMHO. Probably it would be a good thing to
contrast vs no-follow:
The output of "git log builtin-rev-list.c" stops with commit
"v1.4.0-rc1~126", as if the file was created there.
With "--follow", git will detect that this file was renamed
from "rev-list.c" and minimally modified in that commit. After
this, it will continue with the log, using the file name
"rev-list.c".
Ciao,
Dscho
^ permalink raw reply
* [PATCH] lockfile.c: schedule remove_lock_file only once.
From: Sven Verdoolaege @ 2007-07-13 14:14 UTC (permalink / raw)
To: git, Junio C Hamano
Removing a lockfile once should be enough.
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
---
...unless we're running on VMS.
Anyway, it's not clear to me why we can't remove lk from
lock_file_list (and then free it) after we unlink it
in unlock_ref.
skimo
lockfile.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index 5ad2858..fb8f13b 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -31,16 +31,16 @@ static int lock_file(struct lock_file *lk, const char *path)
sprintf(lk->filename, "%s.lock", path);
fd = open(lk->filename, O_RDWR | O_CREAT | O_EXCL, 0666);
if (0 <= fd) {
+ if (!lock_file_list) {
+ signal(SIGINT, remove_lock_file_on_signal);
+ atexit(remove_lock_file);
+ }
lk->owner = getpid();
if (!lk->on_list) {
lk->next = lock_file_list;
lock_file_list = lk;
lk->on_list = 1;
}
- if (lock_file_list) {
- signal(SIGINT, remove_lock_file_on_signal);
- atexit(remove_lock_file);
- }
if (adjust_shared_perm(lk->filename))
return error("cannot fix permission bits on %s",
lk->filename);
--
1.5.3.rc1.10.gae1ae
^ permalink raw reply related
* Re: Draft release notes for v1.5.3, as of -rc1
From: Brian Downing @ 2007-07-13 13:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkdkq00o.fsf_-_@assigned-by-dhcp.cox.net>
On Thu, Jul 12, 2007 at 11:40:39PM -0700, Junio C Hamano wrote:
> GIT v1.5.3 Release Notes (draft)
> ========================
>
> * New commands and options.
- "git repack" learned a "window-memory" limit which dynamically
reduces the window size to stay within the specified memory usage.
"git-repack -a -d -f --window=100000 --window-memory=512m" seems to be
good for those overnight make-it-smaller-damn-the-torpedoes archival
repackings. (You can't just set --window to BIGNUM as it still
allocates an array of that size.) Thanks to Nicolas Pitre's depth bias
patch a high --depth doesn't seem to be quite as critical anymore to
save space; it still helps, but things much much better at a lower
depth.
As a point of reference, it took around two hours to repack a repository
containing 108,440 objects, around 35,000 files (most with no history),
and my aforementioned troublesome 20MB RTF file (which uses about 60MB
per revision when sitting in the window due to the delta index cache)
with the above command. This is on a 2GHz Core 2 Duo in 64-bit mode.
-bcd
^ permalink raw reply
* Re: Lump commit HOWTO?
From: Josh Boyer @ 2007-07-13 13:43 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <20070713045447.GA2430@steel.home>
On 7/12/07, Alex Riesen <raa.lkml@gmail.com> wrote:
> Josh Boyer, Fri, Jul 13, 2007 03:21:17 +0200:
> > Hi All,
> >
> > I have a specific workflow in mind that I'm not entirely sure how to
> > accomplish with git. What I'd like to do is track a project in a
> > local branch, and do commits of my own there as well. Then when I'm
> > ready to submit the work, I want to take all the incremental commits
> > and lump them into a single new commit and push that out as a patch or
> > into a branch for people to pull from.
>
> See git merge --squash. It is exactly that.
Hm, OK. I'll have to play with that.
> Also git-rebase --interactive and git cherry-pick -n can help you to
> get the same.
Gah... I totally missed git rebase. Looks massively useful. Thanks!
josh
^ permalink raw reply
* Re: [PATCH] Fix git-p4 on Windows to not use the Posix sysconf
From: Simon Hausmann @ 2007-07-13 13:33 UTC (permalink / raw)
To: Alex Riesen; +Cc: Marius Storm-Olsen, git, Junio C Hamano
In-Reply-To: <81b0412b0707130603q69857564i1ba418b74397a33d@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 672 bytes --]
On Friday 13 July 2007 15:03:51 Alex Riesen wrote:
> On 7/13/07, Marius Storm-Olsen <marius@trolltech.com> wrote:
> > argmax = min(4000, os.sysconf('SC_ARG_MAX'))
>
> I wonder why the code in question does not use "-x"?
> I use it git-p4-import and haven't seen the limit yet.
> I.e.:
>
> $ ls |p4 -x - print -q
> $ p4 help usage
> ...
> The -x flag instructs p4 to read arguments, one per line, from the
> named file. If the file is named '-', then standard input is read.
> ...
Good idea!
I still think the patch makes sense as stop-gap for 1.5.3 though, because
without it git-p4 doesn't work at all on Windows.
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix git-p4 on Windows to not use the Posix sysconf
From: Alex Riesen @ 2007-07-13 13:03 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: git, Junio C Hamano, Simon Hausmann
In-Reply-To: <46977660.7070207@trolltech.com>
On 7/13/07, Marius Storm-Olsen <marius@trolltech.com> wrote:
> argmax = min(4000, os.sysconf('SC_ARG_MAX'))
I wonder why the code in question does not use "-x"?
I use it git-p4-import and haven't seen the limit yet.
I.e.:
$ ls |p4 -x - print -q
$ p4 help usage
...
The -x flag instructs p4 to read arguments, one per line, from the
named file. If the file is named '-', then standard input is read.
...
^ permalink raw reply
* Re: failing to send patches to the list
From: Alex Riesen @ 2007-07-13 12:57 UTC (permalink / raw)
To: git discussion list; +Cc: martin f krafft
In-Reply-To: <20070713093050.GA18001@lapse.madduck.net>
On 7/13/07, martin f krafft <madduck@madduck.net> wrote:
> attached you may find two patches, which I've previously sent to the
> list with
>
> git format-patch -s --stdout | sendmail git@vger.kernel.org
>
I suggest you try "git format-patch -s --stdout |less" before sending
format-patch without parameters produces nothing.
Even assuming you run something like "git-format-patch start.."
(note the range specification), its output is NOT what sendmail
can use (unless you have a special sendmail which understands
mboxes).
^ permalink raw reply
* [PATCH] Fix git-p4 on Windows to not use the Posix sysconf
From: Marius Storm-Olsen @ 2007-07-13 12:56 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Simon Hausmann
From 255ec32feb7525db8eef582eeed2b6e60be35ed8 Mon Sep 17 00:00:00 2001
From: Marius Storm-Olsen <marius@trolltech.com>
Date: Fri, 13 Jul 2007 14:39:05 +0200
Subject: [PATCH] Fix git-p4 on Windows to not use the Posix sysconf
function.
Add condition for Windows, since it doesn't support the os.sysconf module.
We hardcode the commandline limit to 2K, as that should work on most
Windows platforms.
Signed-off-by: Marius Storm-Olsen <marius@trolltech.com>
---
contrib/fast-import/git-p4 | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 54a05eb..746e0ca 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -717,7 +717,11 @@ class P4Sync(Command):
# POSIX says it's 4096 bytes, default for Linux seems to be
130 K.
# and all OS from the table below seems to be higher than POSIX.
# See http://www.in-ulm.de/~mascheck/various/argmax/
- argmax = min(4000, os.sysconf('SC_ARG_MAX'))
+ if (self.isWindows):
+ argmax = 2000
+ else:
+ argmax = min(4000, os.sysconf('SC_ARG_MAX'))
+
chunk = ''
filedata = []
for i in xrange(len(files)):
--
1.5.2-GUB
^ permalink raw reply related
* Re: git fetch inside a bare repo does nothing
From: Alex Riesen @ 2007-07-13 12:48 UTC (permalink / raw)
To: git
In-Reply-To: <20070713103303.GD18199@xp.machine.xx>
On 7/13/07, Peter Baumann <waste.manager@gmx.de> wrote:
> I suggested to use "git fetch --bare" inside the bare repo, but this
"git --bare fetch".
You swapped "fetch" and "--bare".
^ permalink raw reply
* Re: Volume of commits
From: Alex Riesen @ 2007-07-13 12:46 UTC (permalink / raw)
To: skimo; +Cc: Johannes Schindelin, VMiklos, Fredrik Tolf, git
In-Reply-To: <20070713103025.GR1528MdfPADPa@greensroom.kotnet.org>
On 7/13/07, Sven Verdoolaege <skimo@kotnet.org> wrote:
> If I squash a whole series of commits, how do I prevent git-rebase -i
> from firing up an editor after every single commit in the series?
It is started only for squashed commits. But you can set VISUAL to true or ":".
> a commit message that contains the commit message of "c" twice and
> after the rebase there are still three commits in the history.
Known, fixed (but not yet approved) in
[PATCH] Fix git-rebase -i to allow squashing of fast-forwardable commits
^ permalink raw reply
* Re: git fetch inside a bare repo does nothing
From: Peter Baumann @ 2007-07-13 11:54 UTC (permalink / raw)
To: CJ van den Berg; +Cc: git
In-Reply-To: <20070713113209.GA9046@prefect.vdbonline.net>
On Fri, Jul 13, 2007 at 01:32:10PM +0200, CJ van den Berg wrote:
> On Fri, Jul 13, 2007 at 12:33:03PM +0200, Peter Baumann wrote:
> > kblin on IRC wanted to know how to update a bare repo with fetching.
> > He wants to have a bare repo of samba as a mirror and clone from this
> > mirror to avoid network traffic and to have several git repos which
> > could all have a different branch checked out. For a better description
> > see [1].
> >
> > I suggested to use "git fetch --bare" inside the bare repo, but this
> > doesn't work. So what I'm asking now if this is intenional behaviour or
> > a bug, so please could someone shed some light on it? Or how is the
> > prefered method to update a bare repo *without* pushing to it?
>
> "git fetch" works fine in a bare repo. The issue you're probably having is
> that "git clone --bare" does not add a [remote "origin"] section to the
> config file like regular "git clone" does, so "git fetch" has nothing to
> do. Just add a remote section (either with "git remote add" or manually) and
> regular "git fetch" will work fine.
>
> Just for reference, this is the remote section that is equivalent to the
> original "git clone --bare your_uri_here":
>
> [remote "origin"]
> url = your_uri_here
> fetch = +refs/heads/*:refs/heads/*
>
>
Thx. This wasn't exactly my problem but it lead me to the real problem:
I used
git fetch /path/to/repo master
and had forgotten that I had to specify the local ref, too.
git fetch /path/to/repo master:master
worked as expected. Sorry for the noise.
-Peter
^ permalink raw reply
* Re: git fetch inside a bare repo does nothing
From: CJ van den Berg @ 2007-07-13 11:32 UTC (permalink / raw)
To: git
In-Reply-To: <20070713103303.GD18199@xp.machine.xx>
[-- Attachment #1: Type: text/plain, Size: 1289 bytes --]
On Fri, Jul 13, 2007 at 12:33:03PM +0200, Peter Baumann wrote:
> kblin on IRC wanted to know how to update a bare repo with fetching.
> He wants to have a bare repo of samba as a mirror and clone from this
> mirror to avoid network traffic and to have several git repos which
> could all have a different branch checked out. For a better description
> see [1].
>
> I suggested to use "git fetch --bare" inside the bare repo, but this
> doesn't work. So what I'm asking now if this is intenional behaviour or
> a bug, so please could someone shed some light on it? Or how is the
> prefered method to update a bare repo *without* pushing to it?
"git fetch" works fine in a bare repo. The issue you're probably having is
that "git clone --bare" does not add a [remote "origin"] section to the
config file like regular "git clone" does, so "git fetch" has nothing to
do. Just add a remote section (either with "git remote add" or manually) and
regular "git fetch" will work fine.
Just for reference, this is the remote section that is equivalent to the
original "git clone --bare your_uri_here":
[remote "origin"]
url = your_uri_here
fetch = +refs/heads/*:refs/heads/*
--
CJ van den Berg
mailto:cj@vdbonline.com
xmpp:cj@vdbonline.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-svn: failure to clone logcheck's repo
From: martin f krafft @ 2007-07-13 10:37 UTC (permalink / raw)
To: git discussion list
In-Reply-To: <20070713094710.GB18199@xp.machine.xx>
[-- Attachment #1: Type: text/plain, Size: 825 bytes --]
also sprach Peter Baumann <waste.manager@gmx.de> [2007.07.13.1147 +0200]:
> This is a known problem. If I remember correctly,it is save to
> just resume the import with git-svn fetch, and nothing bad should
> happen.
Yeah, this seems to work.
> Just found it. Look e.g. here on the comment from Eric Wong:
>
> http://thread.gmane.org/gmane.comp.version-control.git/50962/focus=275913
Shame on me, I really should have done the research myself. I guess
I am still too overwhelmed with git, but that won't last long,
I promise.
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
spamtraps: madduck.bogus@madduck.net
"lessing was a heretics' heretic"
-- walter kaufmann
[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Better handling of local changes in 'gitk'?
From: Johannes Sixt @ 2007-07-13 10:33 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <18071.19489.6733.665052@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Try this, let me know what you think. I called the changes in the
> working directory "Local uncommitted changes, not checked in to index"
> and the changes in the index "Local changes checked in to index but
> not committed". If you prefer some other wording, let me know.
Maybe you go with git-gui's wording:
Index: Staged changes
WD: Unstaged changes
-- Hannes
^ permalink raw reply
* git fetch inside a bare repo does nothing
From: Peter Baumann @ 2007-07-13 10:33 UTC (permalink / raw)
To: git
kblin on IRC wanted to know how to update a bare repo with fetching.
He wants to have a bare repo of samba as a mirror and clone from this
mirror to avoid network traffic and to have several git repos which
could all have a different branch checked out. For a better description
see [1].
I suggested to use "git fetch --bare" inside the bare repo, but this
doesn't work. So what I'm asking now if this is intenional behaviour or
a bug, so please could someone shed some light on it? Or how is the
prefered method to update a bare repo *without* pushing to it?
-Peter
[1]: http://wiki.samba.org/index.php/Using_Git_for_Samba_Development
IRC log (unneccessary comments removed):
11:30 < kblin> how do I update a branch I cloned with --bare?
11:31 < madduck> GIT_DIR=/path/to/dir git pull >
11:31 < madduck> ?
11:31 < madduck> without the >
11:32 < kblin> and for remote repositories, I'd use a URL?
11:37 < madduck> uh, you can't reallly "update" remote repositories in that sense
11:37 < madduck> what are you trying to do?
11:37 < madduck> let's have more info!
11:51 < kblin> madduck: I'm trying to follow http://wiki.samba.org/index.php/Using_Git_for_Samba_Development
11:52 < kblin> madduck: basically, I want to have a --bare repository that mirrors the remote repository
and have a couple of working repositories for the different branches
11:57 < siprbaum> kblin: I think "git --bare fetch" inside your bare repo will solve your problem
[...]
12:01 < kblin> siprbaum: git --bare fetch doesn't seem to fetch anything new either
12:01 < siprbaum> perhaps there isn't anything new to fetch?
12:02 < siprbaum> but i'm just guessing here and reading the manpage (git) suggested that git --bare fetch _could_ work
12:02 < kblin> siprbaum: that'd surpise me. I've got a clone without the --bare, and that has a new commit
[...]
12:14 < siprbaum> kblin: and you are right. i just tried to fetch inside a bare repo and it doesn't work
^ permalink raw reply
* Re: Volume of commits
From: Sven Verdoolaege @ 2007-07-13 10:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: VMiklos, Fredrik Tolf, git
In-Reply-To: <Pine.LNX.4.64.0707121451290.4516@racer.site>
On Thu, Jul 12, 2007 at 02:59:53PM +0100, Johannes Schindelin wrote:
> In this case, "messy history" means that there are tiny patches which are
> often in the wrong order, or should be squashed into one commit. "git
> rebase -i upstream" presents you with the list of A - HEAD, and you can
> reorder the patches. If you want to, you can combine ("squash") some
> into one commit, or you can skip it, by removing the corresponding line.
If I squash a whole series of commits, how do I prevent git-rebase -i
from firing up an editor after every single commit in the series?
Also, if I do the following:
bash-3.00$ git init
Initialized empty Git repository in .git/
bash-3.00$ for i in a b c; do touch $i; git add $i; git commit -m $i -a; done
Created initial commit 19a8485: a
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 a
Created commit 4a00f85: b
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 b
Created commit defe3b5: c
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 c
bash-3.00$ git rebase -i HEAD~2
and then replace the second "pick" by "squash", then I get presented
a commit message that contains the commit message of "c" twice and
after the rebase there are still three commits in the history.
This is with git version 1.5.3.rc1.10.gae1ae
(on top of v1.5.3-rc1-4-gaf83bed).
skimo
^ 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