* Re: How do I show only log messages for commits on a specific branch?
From: Elijah Newren @ 2009-12-17 0:04 UTC (permalink / raw)
To: Santi Béjar; +Cc: Miklos Vajna, bd, git
In-Reply-To: <adf1fd3d0912161558u36d9674eid36e3042d181ed8f@mail.gmail.com>
On Wed, Dec 16, 2009 at 4:58 PM, Santi Béjar <santi@agolina.net> wrote:
> git log new --not $(git for-each-ref --format='%(refname)'
> 'refs/heads/*' | grep -v refs/heads/new)
How did I miss '--not' as a git log option? Thanks for pointing it out!
^ permalink raw reply
* Re: How do I show only log messages for commits on a specific branch?
From: Elijah Newren @ 2009-12-16 23:59 UTC (permalink / raw)
To: Miklos Vajna; +Cc: bd, git
In-Reply-To: <20091216232641.GK25474@genesis.frugalware.org>
On Wed, Dec 16, 2009 at 4:26 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Wed, Dec 16, 2009 at 11:05:52AM -0700, Elijah Newren <newren@gmail.com> wrote:
>> git log new@{30.years.ago}..new
>> (You'll get a warning that 'new' hasn't existed for 30 years but it
>> doesn't hurt anything)
>
> That's the same as "git log new", if I'm not mistaken.
Did you try it with a 'new' branch in your repository that started at
the beginning of history rather than at some commit? "git log new"
and "git log new@{30.years.ago}..new" are not the same for me with
git-1.6.5.5:
$ git init repo
$ cd repo
$ echo content> foo && git add foo && git commit -mone foo
$ echo more content >> foo && git commit -mtwo foo
$ git checkout -b new master~1
$ echo stuff >> foo && git commit -mthree foo
$ git log new@{30.years.ago}..new
warning: Log for 'new' only goes back to Wed, 16 Dec 2009 16:48:02 -0700.
commit 7df8bad7cc146875c59ab030da0d25555976e79c
Author: Elijah Newren <newren@gmail.com>
Date: Wed Dec 16 16:48:07 2009 -0700
three
$ git log new
commit 7df8bad7cc146875c59ab030da0d25555976e79c
Author: Elijah Newren <newren@gmail.com>
Date: Wed Dec 16 16:48:07 2009 -0700
three
commit b86eadcdb152877ade44bebf4b8742884949f29f
Author: Elijah Newren <newren@gmail.com>
Date: Wed Dec 16 16:47:31 2009 -0700
one
> What Stefan wants to do is to let git log show the commits which are
> only in the "new" branch, but I don't think there is an out-of-the-box
> solution for that.
Are you sure? I'm more inclined to believe he'd like to see all the
commits that have been added to the "new" branch since he created it
(which may be the same as what you say, but not necessarily). Of
course, neither my assumption or yours match what he actually asked
for (though I think what he asked for isn't possible and is merely an
means to the end he really wants).
Also, I think this does what you asked for (the commits in the "new"
branch but no other branch):
$ git log new $(git for-each-ref --format='%(refname)' 'refs/heads/*'
| grep -v '^refs/heads/new$' | sed -e s/^/^/)
^ permalink raw reply
* Re: How do I show only log messages for commits on a specific branch?
From: Santi Béjar @ 2009-12-16 23:58 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Elijah Newren, bd, git
In-Reply-To: <20091216232641.GK25474@genesis.frugalware.org>
On Thu, Dec 17, 2009 at 12:26 AM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Wed, Dec 16, 2009 at 11:05:52AM -0700, Elijah Newren <newren@gmail.com> wrote:
>> git log new@{30.years.ago}..new
>> (You'll get a warning that 'new' hasn't existed for 30 years but it
>> doesn't hurt anything)
>
> That's the same as "git log new", if I'm not mistaken.
>
> What Stefan wants to do is to let git log show the commits which are
> only in the "new" branch, but I don't think there is an out-of-the-box
> solution for that.
Not out-of-the-box but this does exactly what you said, print all
commits only reachable from the "new" branch:
git log new --not $(git for-each-ref --format='%(refname)'
'refs/heads/*' | grep -v refs/heads/new)
For the original question, I think what makes most sense in this case
is asking for the commits since the upstream branch. Some time ago
there was a discussion about a syntax for the tracking branch and
there was even a patch:
Subject: [PATCH v2] Introduce <branch>@{upstream} as shortcut to the
tracked branch
Date: 2009-09-10 15:25:57 GMT
http://news.gmane.org/find-root.php?message_id=%3calpine.DEB.1.00.0909101724520.8306%40pacific.mpi%2dcbg.de%3e
but it's not in git.git.
HTH,
Santi
^ permalink raw reply
* Re: How do I show only log messages for commits on a specific branch?
From: Miklos Vajna @ 2009-12-16 23:26 UTC (permalink / raw)
To: Elijah Newren; +Cc: bd, git
In-Reply-To: <51419b2c0912161005n1596d4a1n92ed555c98aee4c6@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 784 bytes --]
On Wed, Dec 16, 2009 at 11:05:52AM -0700, Elijah Newren <newren@gmail.com> wrote:
> git log new@{30.years.ago}..new
> (You'll get a warning that 'new' hasn't existed for 30 years but it
> doesn't hurt anything)
That's the same as "git log new", if I'm not mistaken.
What Stefan wants to do is to let git log show the commits which are
only in the "new" branch, but I don't think there is an out-of-the-box
solution for that.
One solution I can think of is to iterate over each ref using "git
for-each-ref --format='%(refname)' 'refs/heads/*'", then run "git
merge-base $i new", run git rev-list $mb..new|wc -l and then you could
decide what is the first commit that does not belong to any other
branch. But that's just an idea, I don't have the motivation to script
it properly.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Git on QNX
From: Sean Boudreau @ 2009-12-16 22:38 UTC (permalink / raw)
To: git
In-Reply-To: <905315640912151413g10ee5befh58fbd171237e7659@mail.gmail.com>
Tarmigan <tarmigan+git <at> gmail.com> writes:
> >
> > Other hunks are QNX specific enough but this hunk is worrisome; you cannot
> > tell how you are hurting other platforms with this change. Can you tell
> > declarations of which functions are missing on QNX without this change?
>
> strcasecmp()
> http://www.opengroup.org/onlinepubs/000095399/functions/strcasecmp.html
>
> I agree that this change could affect other platforms and they've
> gotten along fine without it so far. I'm surprised no others have
> needed it. Would it be better wrapped in a #ifdef?
>
> Thanks,
> Tarmigan
>
What version of qnx is this on. <strings.h> is
now brought in by <string.h> and the lock() /
unlock() prototypes have been removed from <unistd.h>
AS OF 6.4.1 (the current release).
There's a package for git-4.3.20 here that also has a work around
for the SA_RESTART issue.
ftp://ftp.netbsd.org/pub/pkgsrc/packages/QNX/i386/6.4.1_head_20090724/All
-seanb
^ permalink raw reply
* Re: git-reflog 70 minutes at 100% cpu and counting
From: Eric Paris @ 2009-12-16 22:37 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jeff King, git
In-Reply-To: <alpine.LFD.2.00.0912161526080.23173@xanadu.home>
On Wed, 2009-12-16 at 16:06 -0500, Nicolas Pitre wrote:
> On Wed, 16 Dec 2009, Eric Paris wrote:
>
> > On Tue, 2009-12-15 at 22:03 -0500, Nicolas Pitre wrote:
> > > On Mon, 14 Dec 2009, Eric Paris wrote:
> > >
> > > > The alternative repo is slowing pushing up to that same location. That
> > > > tar is 855838982, so just a tad bit smaller.
> > >
> > > It doesn't appear to be complete yet, and not progressing either.
> >
> > The alternative repo is now available (but the original is down)
> >
> > I tried to run git gc --aggressive last night while I slept and got this
> > as output, maybe it helps point to a solution/problem? The git reflog
> > portion ran for 5 hours and 36 minutes and appears to have finished.
>
> Yes. I was able to reproduce your issue. And because of the *horrible*
> repository packing, the reflog expiration process is taking ages when
> determining object reachability at a rate of one reflog entry every 2
> seconds or so. With 4214 entries for the fsnotify-syscall branch, and
> 1352 entries for the fsnotify branch, this already takes up asignificant
> portion of the actual run time. I'm sure if your repository was
> properly packed this would take less than a minute.
I'm guessing this is a result of stgit.? These branches really should
be just a branch from a tag (which exists in kernel-1) and about 30-50
patches linearly applied on top. I don't know how I get that many
objects. I'm guessing many/most of them are crap that should be able to
be cleaned/deleted entirely as the rebasing/pushing/poping/updating that
stgit does under the covers should have rendered them pointless. Not
really sure when/how that should/could have happened.
Should I be running git-gc every night?
> Now, repacking doesn't work because...
>
> > $ git gc --aggressive
> > error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
> > error: Could not read 29b6c2fb1390b4fd350a5ecc78f1156fc5d91e9f
/me is pretty git dumb, but is there some way to figure out the parents
or children of these? I just trolled through all of my directories
doing git show and didn't get any hits. I guess I'll just clean up and
start over....
> Those objects are indeed missing from the repository. Without them your
> repository is "broken". Either you can find them somewhere else and
> copy them over, or salvage as much as you can by fetching the
> interesting branches into another freshly made repository. This is
> unfortunate because I would have liked to see by how much this
> repository would have shrunk after a successful repack.
>
> Of course, usage of alternates is recommended _only_ with repositories
> that are stable, i.e. don't ever add repositories to
> .git/objects/info/alternates if those repositories are rewinded/rebased
> and/or branches in them are deleted/replaced. That could be a reason
> why some objects are now missing from the repository using alternates.
So I'm not sure how I did things wrong. my kernel-1 has those bunch of
remotes. The linux-next remote, like I said, basically rebases to
linus' tree, then merges 150 random branches. It tags that tree every
day and I pull those tags. So I would never expect any objects from
those remote trees to ever disappear.
Now I created branches in kernel-1 and I certainly have done lots of
things like so
git checkout -b testing remotes/linux-next/master
[edit]
git commit -a
git checkout -b testing1 remotes/linux-next/master
git branch -D testing
My assumption though was that this wouldn't ever affect my other
repositories. My other repository branches always started by checking
out a branch with remotes/*/* as the base.
My understanding was that I would only run into problems if I used
something on a branch I created myself in the alternatives repo in other
repos (and I didn't remove remotes)
I guess it's not impossible to believe that at some point in time i
would have exported patches to and mbox from kernel-1 and applied them
to kernel-2 or vice versa. I guess this would end up with the same
objects, right? Then if I deleted the branch in kernel-1 I would have
problems in kernel-2?
I guess I'll rebuild my setup
new kernel-alt has just the remotes, and my kernel-1,2,3 all alt to it
I'll never have local branches in my kernel-alt
I'll run git-gc every night
I'll hope to never have problem again.
Sound good?
^ permalink raw reply
* Re: git-reflog 70 minutes at 100% cpu and counting
From: Nicolas Pitre @ 2009-12-16 21:06 UTC (permalink / raw)
To: Eric Paris; +Cc: Jeff King, git
In-Reply-To: <1260970885.2788.87.camel@localhost>
On Wed, 16 Dec 2009, Eric Paris wrote:
> On Tue, 2009-12-15 at 22:03 -0500, Nicolas Pitre wrote:
> > On Mon, 14 Dec 2009, Eric Paris wrote:
> >
> > > The alternative repo is slowing pushing up to that same location. That
> > > tar is 855838982, so just a tad bit smaller.
> >
> > It doesn't appear to be complete yet, and not progressing either.
>
> The alternative repo is now available (but the original is down)
>
> I tried to run git gc --aggressive last night while I slept and got this
> as output, maybe it helps point to a solution/problem? The git reflog
> portion ran for 5 hours and 36 minutes and appears to have finished.
Yes. I was able to reproduce your issue. And because of the *horrible*
repository packing, the reflog expiration process is taking ages when
determining object reachability at a rate of one reflog entry every 2
seconds or so. With 4214 entries for the fsnotify-syscall branch, and
1352 entries for the fsnotify branch, this already takes up asignificant
portion of the actual run time. I'm sure if your repository was
properly packed this would take less than a minute.
Now, repacking doesn't work because...
> $ git gc --aggressive
> error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
> error: Could not read 29b6c2fb1390b4fd350a5ecc78f1156fc5d91e9f
Those objects are indeed missing from the repository. Without them your
repository is "broken". Either you can find them somewhere else and
copy them over, or salvage as much as you can by fetching the
interesting branches into another freshly made repository. This is
unfortunate because I would have liked to see by how much this
repository would have shrunk after a successful repack.
Of course, usage of alternates is recommended _only_ with repositories
that are stable, i.e. don't ever add repositories to
.git/objects/info/alternates if those repositories are rewinded/rebased
and/or branches in them are deleted/replaced. That could be a reason
why some objects are now missing from the repository using alternates.
Nicolas
^ permalink raw reply
* Re: git svn clone just stops
From: Mark Jerkovic @ 2009-12-16 20:47 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20091216081514.GB26038@dcvr.yhbt.net>
On Wed, 2009-12-16 at 00:15 -0800, Eric Wong wrote:
> Mark Jerkovic <mjerkovic@aconex.com> wrote:
> > Hi all,
> >
> > I am new to Git and I am attempting to clone a SVN repository
> > (containing approximately 60,000 commits) to Git.
> >
> > Using Git v1.6.0.4 with the following command:
> >
> > git svn clone https://path/to/svn/repo/trunk project.git
> > --authors-file=svnauthors.txt --no-metadata
> >
> > the process just ends without any messages and the Git repository is
> > empty. I have attempted this four times already, and each time it has
> > stopped after a different revision, so I can't pin it down to a
> > particular commit.
>
> Hi Mark,
>
> Any chance you're OOM-ing (extremely large file) or running
> out of space somewhere? What exit code do you get when it exits?
>
> > Has anyone experienced this before? Is there a log anywhere that
> > records what is happening during this process?
>
> Not without error messages of some sort. git svn was designed with poor
> network conditions in mind and clone is resumable, so you can just
> resume like this:
>
> cd project.git && git svn fetch
>
That is an excellent tip. Thanks a lot!
> I wouldn't use --no-metadata at this point, though, as it makes it much
> harder to debug/fix things or recover from errors.
>
> Once you're comfortable with it, you should be able to write
> "git filter-branch" invocation to remove the metadata lines.
I have done some more investigating and it appears that at some point a
branch was moved to replace our trunk. When the migration process hits
this I it goes back to the beginning and starts migrating the branch
history too. I think when it gets to the end of it is not able to
resume from the "move" point.
I will try your resume tip to see if I can get it started again.
Many thanks,
Mark.
>
^ permalink raw reply
* Re: [PATCH 6/6] GITWEB - Separate defaults from main file
From: J.H. @ 2009-12-16 20:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <200912162052.09470.jnareb@gmail.com>
Jakub Narebski wrote:
> On Tue, 15 Dec 2009, 18:00 -0800, J.H. wrote:
>> Junio C Hamano wrote:
>
>>> Any progress on this front?
>> Sadly, no. Busy weekend and a need to get some of the kernel.org
>> servers upgraded has taken some precedence. I should be circling back
>> around on this tomorrow I think.
>
> So should I wait for reroll with proposals for improvements (modified
> patches)?
I'd probably wait, though it's starting to look like if I get to gitweb
today it will be this evening as I ventured off into getting the last 6
of the kernel.org servers upgraded. Either way I will have a new patch
series and some changes in my own git tree shortly.
- John 'Warthog9' Hawley
^ permalink raw reply
* Re: [PATCH 6/6] GITWEB - Separate defaults from main file
From: Jakub Narebski @ 2009-12-16 19:52 UTC (permalink / raw)
To: J.H.; +Cc: Junio C Hamano, git, John 'Warthog9' Hawley
In-Reply-To: <4B283F3D.3020209@kernel.org>
On Tue, 15 Dec 2009, 18:00 -0800, J.H. wrote:
> Junio C Hamano wrote:
> > Any progress on this front?
>
> Sadly, no. Busy weekend and a need to get some of the kernel.org
> servers upgraded has taken some precedence. I should be circling back
> around on this tomorrow I think.
So should I wait for reroll with proposals for improvements (modified
patches)?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: How do I show only log messages for commits on a specific branch?
From: Elijah Newren @ 2009-12-16 18:05 UTC (permalink / raw)
To: bd; +Cc: git
In-Reply-To: <20091216101647.GB27373@bc-bd.org>
On Wed, Dec 16, 2009 at 3:16 AM, <bd@bc-bd.org> wrote:
> imagine this:
>
> --A--*--B (new)
> /
> *--X--*--Y (master)
>
> Now I'd like to list only log messages for A..B (X..B would be okay too).
>
> I know of
>
> git log master..new
>
> however then I need to remember that I branched new of master, and to be honest,
> sometimes I forget.
>
> So how do I:
>
> git please-tell-me-the-branch-I-started-this-branch-from new
In the above example, you technically did not create 'new' off of
'master', you created new starting at X. You may think of it in terms
of branching off of 'master', but
git branch new master
resolves 'master' to the commit it points at and creates 'new'
pointing at that commit. That's all that is recorded. But I believe
the info you are really interested in is where new started, rather
than the fact that it branched off master. Is that correct? If so,
just use new@{30.years.ago} (or any other sufficiently long period of
time):
git log new@{30.years.ago}..new
(You'll get a warning that 'new' hasn't existed for 30 years but it
doesn't hurt anything)
Hope that helps,
Elijah
^ permalink raw reply
* Re: subtree merge tries to merge into wrong directory
From: naderman @ 2009-12-16 18:05 UTC (permalink / raw)
To: Avery Pennarun; +Cc: git
In-Reply-To: <32541b130912100638v1f701183w909367cd97c8325@mail.gmail.com>
Avery Pennarun wrote:
> On Wed, Dec 9, 2009 at 10:41 PM, Nils Adermann <naderman@naderman.de>
wrote:
>> Following
>> http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html
>> I have subtree merged a 3rd party library (ezc-reflection) into my
>> repository (pflow). The prefix I used was lib/ezc/trunk/Reflection. Now
>> there have been changes to ezc-reflection but merging them into my
>> repository fails. The merge is attempted in example/ rather than
>> lib/ezc/trunk/Reflection.
>
> The auto-guessing feature of "merge -s subtree" doesn't always work.
> The 'pu' branch of git has some patches which allow you to use a
> command line like
>
> git merge -Xsubtree=lib/ezc/trunk/Reflection
>
> If you're nervous about using all of 'pu', try building git's 'master'
> after merging from commit 0354b06927a1220b696a5ee1004a8f061ba9b153.
So I finally got around to trying this. This was my first result:
$ git merge -Xsubtree=lib/ezc/trunk/Reflection/ FETCH_HEAD
fatal: entry not found in tree 60270661e0d2a5ee03b24609fac5c6d00d048988
Interestingly the following works, as in merges correctly into
lib/ezc/trunk/Reflection/. The "arbitrary" part can be set to anything it
just needs to be set. No directory with that name is created.
$ git merge --strategy-option=subtree=arbitrary FETCH_HEAD
Merge made by recursive.
.../trunk/Reflection/src/doc_comment_parser.php | 38
++++++++++---------
1 files changed, 20 insertions(+), 18 deletions(-)
While the following results in the same issue I originally had with -s
strategy
$ git merge --strategy-option=subtree FETCH_HEAD
CONFLICT (delete/modify): example/src/doc_comment_parser.php deleted in
HEAD and modified in FETCH_HEAD. Version FETCH_HEAD of
example/src/doc_comment_parser.php left in tree.
Automatic merge failed; fix conflicts and then commit the result.
I'm not sure why this is happening, but the
--strategy-option=subtree=arbitrary solves my issue for now.
Cheers
Nils
^ permalink raw reply
* Re: [PATCH] Let format-patch and rebase ignore trivial merges.
From: Johannes Sixt @ 2009-12-16 16:53 UTC (permalink / raw)
To: Bernhard R. Link; +Cc: git
In-Reply-To: <20091216164553.GA22471@pcpool00.mathematik.uni-freiburg.de>
Please do not set Mail-Followup-To (and use reply-to-all to keep the Cc list).
Bernhard R. Link schrieb:
> --prune-tree makes rev-list without paths equivalent to
> "git rev-list $options -- ." (or .. or ../.. and so on,
> if you are in some subdirectory).
> This is the new default for format-patch and rebase
Why do you need a new option when you can just add "-- ." to the rev-list
invocation?
-- Hannes
^ permalink raw reply
* [PATCH] Let format-patch and rebase ignore trivial merges.
From: Bernhard R. Link @ 2009-12-16 16:45 UTC (permalink / raw)
To: git
As git rebase and git format-patch linearize commits,
having the same change in different branches causes in the
best case duplicate patches in the produced series and in the
worst case conflicts. If there are trivial merges involved
(i.e. merges that do not change the tree), then this patch
will cause git to only look at one branch, thereby avoiding
duplicates and reducing the chance of conflicts.
There are two new options --prune-tree and --no-prune-tree
added.
--prune-tree makes rev-list without paths equivalent to
"git rev-list $options -- ." (or .. or ../.. and so on,
if you are in some subdirectory).
This is the new default for format-patch and rebase
--no-prune-tree deactivates --prune-tree.
Signed-off-by: Bernhard R. Link <brlink@debian.org>
---
Documentation/rev-list-options.txt | 11 +++++++++++
builtin-log.c | 1 +
git-rebase--interactive.sh | 1 +
git-rebase.sh | 2 +-
revision.c | 11 ++++++++++-
revision.h | 1 +
6 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index 1f57aed..6c5e90c 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -328,6 +328,17 @@ The following options select the commits to be shown:
Commits modifying the given <paths> are selected.
+--prune-tree::
+
+ No paths is equivalent to the whole tree as path.
+ That means merges with the same tree follow only one parent.
+ (Default for format-patch and rebase).
+
+--no-prune-tree::
+
+ No paths means not doing history simplification based on paths.
+ (Default for everything but format-patch and rebase).
+
--simplify-by-decoration::
Commits that are referred by some branch or tag are selected.
diff --git a/builtin-log.c b/builtin-log.c
index 1766349..efc2f40 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -960,6 +960,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
rev.diff = 1;
rev.combine_merges = 0;
rev.ignore_merges = 1;
+ rev.prune_tree = 1;
DIFF_OPT_SET(&rev.diffopt, RECURSIVE);
rev.subject_prefix = fmt_patch_subject_prefix;
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 0bd3bf7..ea23d9b 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -703,6 +703,7 @@ first and then run 'git rebase --continue' again."
fi
git rev-list $MERGES_OPTION --pretty=oneline --abbrev-commit \
--abbrev=7 --reverse --left-right --topo-order \
+ --prune-tree \
$REVISIONS | \
sed -n "s/^>//p" | while read shortsha1 rest
do
diff --git a/git-rebase.sh b/git-rebase.sh
index b121f45..2186619 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -539,7 +539,7 @@ echo "$head_name" > "$dotest/head-name"
echo "$GIT_QUIET" > "$dotest/quiet"
msgnum=0
-for cmt in `git rev-list --reverse --no-merges "$revisions"`
+for cmt in `git rev-list --reverse --no-merges --prune-tree "$revisions"`
do
msgnum=$(($msgnum + 1))
echo "$cmt" > "$dotest/cmt.$msgnum"
diff --git a/revision.c b/revision.c
index a8a3c3a..3350af6 100644
--- a/revision.c
+++ b/revision.c
@@ -1112,6 +1112,10 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
revs->dense = 1;
} else if (!strcmp(arg, "--sparse")) {
revs->dense = 0;
+ } else if (!strcmp(arg, "--prune-tree")) {
+ revs->prune_tree = 1;
+ } else if (!strcmp(arg, "--no-prune-tree")) {
+ revs->prune_tree = 0;
} else if (!strcmp(arg, "--show-all")) {
revs->show_all = 1;
} else if (!strcmp(arg, "--remove-empty")) {
@@ -1408,8 +1412,13 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
}
}
- if (prune_data)
+ if (prune_data) {
revs->prune_data = get_pathspec(revs->prefix, prune_data);
+ } else if (revs->prune_tree) {
+ /* limit whole tree (limits trivial merges to one side) */
+ static const char *whole_tree[2] = { "", NULL };
+ revs->prune_data = whole_tree;
+ }
if (revs->def == NULL)
revs->def = def;
diff --git a/revision.h b/revision.h
index d368003..d007aaa 100644
--- a/revision.h
+++ b/revision.h
@@ -38,6 +38,7 @@ struct rev_info {
/* Traversal flags */
unsigned int dense:1,
prune:1,
+ prune_tree:1,
no_merges:1,
merges_only:1,
no_walk:1,
^ permalink raw reply related
* RE: Huge pack file from small unpacked objects
From: Nick Triantos @ 2009-12-16 16:34 UTC (permalink / raw)
To: 'git@vger.kernel.org'
In-Reply-To: <404585ED79625A40AB5A9884ECA9A63B3E02083F@VMBX125.ihostexchange.net>
Hi,
I recently created a repo from SVN via git-svn. The bare repo was about ~600MB. I cloned it, and on the clone, I added 2 small files (.gitignore and .gitattributes) to a branch, merged them to master, and pushed that back to the origin. The cloned repo remains at about 600MB, while my origin repo (the one from svn) is now about 2.4GB. I found that it created a file in objects/pack which accounts for this huge size.
I've tried running 'git repack -a -d' but that didn't shrink the size of this pack file.
Any ideas why the pack file is so huge? Anything I can do to shrink it? My coworkers are understandably unhappy that the repo is so huge now (makes for very slow pulls)
thanks,
-Nick
^ permalink raw reply
* Re: New Proposal (simple) for Metadata in Git Commits: git-meta
From: Shawn O. Pearce @ 2009-12-16 16:30 UTC (permalink / raw)
To: Sam Elliott; +Cc: git
In-Reply-To: <7349A827-41D5-434F-85FE-D49980A7D501@lenary.co.uk>
Sam Elliott <sam@lenary.co.uk> wrote:
> On 15 Dec 2009, at 23:05, Shawn O. Pearce wrote:
>> If you dropped the --git-meta-- tags above, JGit would happily
>> recognize the awesome: and Github: tags, but it might need a bit
>> more work to recognize the nested user: tag. Also, you'd be able
>> to use git-meta on the git and Linux kernel repositories to pull
>> out and work with Signed-off-by, Acked-by, etc.
>
> I'm not entirely sure about this approach. The current implementation
> also works with PGP-signed tags, where the information is not
> necessarily going to be at the bottom of the message when i use `git-
> cat-file -p`. I think it shouldn't be too hard to also have git-meta
> read any YAML-like data just before the signing message.
Ah, good point. But as you point out, it should be simple enough
to detect a PGP signature on the bottom and just clip that off the
end, and then perform the YAML-like data parsing on the footer.
--
Shawn.
^ permalink raw reply
* Re: error: git-svn died of signal 13
From: Jason Felice @ 2009-12-16 14:56 UTC (permalink / raw)
To: git
In-Reply-To: <20091209075319.GA4201@progeny.tock>
Jonathan Nieder <jrnieder <at> gmail.com> writes:
>
> CCing those who reported the problem. There is some debugging advice below,
> for anyone who wants to take a further stab at tracking this down.
>
> Eric Wong wrote:
> > Can somebody get an strace or core dump for the "git update-index"
> > call? Or even an strace -f of the entire git svn invocation as well...
>
I am having the same issue, pulling a HTTPS repo being served with Subversion
1.4.5. Other info: The repo has many, many tags (~300?), and ~5000 revisions,
and I've been pulling it since Saturday! Each iteration of git svn fetch takes
longer and longer before producing output. It "feels" like It The tags seem to
be what's slowing it down.) I can't make this repo or shell access available
(sorry).
I got an strace:
jfelice@lx-cclamp:~/xpay-core$ strace -f -o /tmp/strace git svn fetch
r3176 = 816a8e7ffd28a2224a75037cf6a983883532c76e (refs/remotes/tags/v01_01_87)
error: git-svn died of signal 13
The strace output is at:
http://eraserhead.net/files/strace.bz2
I originally suspected that our crufty HTTPS server was closing the connection
on us due to some kind of timeout.
^ permalink raw reply
* Re: Git on QNX
From: Alex Riesen @ 2009-12-16 14:20 UTC (permalink / raw)
To: Tarmigan; +Cc: Junio C Hamano, Git Mailing List, mkraai
In-Reply-To: <905315640912151413g10ee5befh58fbd171237e7659@mail.gmail.com>
On Tue, Dec 15, 2009 at 23:13, Tarmigan <tarmigan+git@gmail.com> wrote:
> On Tue, Dec 15, 2009 at 1:42 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Tarmigan <tarmigan+git@gmail.com> writes:
>>> diff --git a/git-compat-util.h b/git-compat-util.h
>>> index 5c59687..857e938 100644
>>> --- a/git-compat-util.h
>>> +++ b/git-compat-util.h
>>> @@ -79,6 +84,7 @@
>>> #include <stdlib.h>
>>> #include <stdarg.h>
>>> #include <string.h>
>>> +#include <strings.h>
>>> #include <errno.h>
>>> #include <limits.h>
>>> #include <sys/param.h>
>>
>> Other hunks are QNX specific enough but this hunk is worrisome; you cannot
>> tell how you are hurting other platforms with this change. Can you tell
>> declarations of which functions are missing on QNX without this change?
>
> strcasecmp()
> http://www.opengroup.org/onlinepubs/000095399/functions/strcasecmp.html
Just for completeness:
http://www.qnx.com/developers/docs/6.4.1/neutrino/lib_ref/s/strcasecmp.html
http://www.qnx.com/developers/docs/6.4.1/neutrino/lib_ref/s/strcmpi.html
> I agree that this change could affect other platforms and they've
> gotten along fine without it so far. I'm surprised no others have
> needed it. Would it be better wrapped in a #ifdef?
If you put the ifdef in git-compat-util.h
^ permalink raw reply
* Re: git-reflog 70 minutes at 100% cpu and counting
From: Eric Paris @ 2009-12-16 13:41 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jeff King, git
In-Reply-To: <alpine.LFD.2.00.0912152201300.23173@xanadu.home>
On Tue, 2009-12-15 at 22:03 -0500, Nicolas Pitre wrote:
> On Mon, 14 Dec 2009, Eric Paris wrote:
>
> > The alternative repo is slowing pushing up to that same location. That
> > tar is 855838982, so just a tad bit smaller.
>
> It doesn't appear to be complete yet, and not progressing either.
The alternative repo is now available (but the original is down)
I tried to run git gc --aggressive last night while I slept and got this
as output, maybe it helps point to a solution/problem? The git reflog
portion ran for 5 hours and 36 minutes and appears to have finished.
$ git gc --aggressive
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
warning: reflog of 'refs/remotes/audit/master' references pruned commits
warning: reflog of 'refs/remotes/btrfs/enospc' references pruned commits
warning: reflog of 'refs/remotes/btrfs/merge' references pruned commits
warning: reflog of 'refs/remotes/btrfs/for-linus' references pruned commits
warning: reflog of 'refs/remotes/security-testing/for-linus' references pruned commits
error: Could not read 29b6c2fb1390b4fd350a5ecc78f1156fc5d91e9f
fatal: bad tree object 29b6c2fb1390b4fd350a5ecc78f1156fc5d91e9f
error: failed to run repack
^ permalink raw reply
* How do I show only log messages for commits on a specific branch?
From: bd @ 2009-12-16 10:16 UTC (permalink / raw)
To: git
Hello list,
[ git v1.6.3.3 ]
imagine this:
--A--*--B (new)
/
*--X--*--Y (master)
Now I'd like to list only log messages for A..B (X..B would be okay too).
I know of
git log master..new
however then I need to remember that I branched new of master, and to be honest,
sometimes I forget.
So how do I:
git please-tell-me-the-branch-I-started-this-branch-from new
Thanks in advance,
Stefan
--
BOFH excuse #181:
Atilla the Hub
^ permalink raw reply
* elegant(?) debian topgit workflow?
From: Thomas Koch @ 2009-12-16 10:13 UTC (permalink / raw)
To: vcs-pkg-discuss; +Cc: git, debian-devel
CC (FYI) to git and debian-devel. see http://vcs-pkg.org
Hi,
would you be so kind to review my workflow proposal?
branches
--------
upstream
debian/*, fixes/*, features/* - topgit branches based on upstream
patches - the hero
master - contains the debian/ dir and is the branch we build from
All topgit branches are integrated in the patches branch, which is afterwards
merged into master. The magic is, that the integration is not a regular merge,
but a handcrafted merge and commit with quilt and git plumbing.
workflow
--------
Every merge starts with reseting "patches" to the state of upstream:
#> git checkout upstream
(for the first time: git checkout -b patches, otherwise:)
#> git symbolic-ref HEAD refs/heads/patches
Now we're on branch patches with the working tree and index in the pristine
state of upstream. We can now integrate the topgit branches:
#> tg export --quilt debian/patches \
-b debian/use-debian-java-libraries,debian/disable-tests-that-break-on-buildd
#> quilt push -a
#> git add debian/
#> rm -rf .pc
#> git add -u
Now let's create the commit and specify, which topgit branches were manually
merged:
#> TREE=$(git write-tree)
#> COMMIT=$(git commit-tree $TREE \
-p debian/use-debian-java-libraries \
-p debian/disable-tests-that-break-on-buildd)
#> git update-ref refs/heads/patches $COMMIT
Now I can happily merge patches into master.
advantages
----------
- The commits of all ever merged topgit branches are preserved, even after tg
delete
- easy to understand, non cluttered history
- Easy to retire topgit branches
- Easy to work on old package versions(?): just make a branch from master at
desired version, eventually also branch patches branch to work on old patches
- The quilt patches are used and therefore tested in the same way, as dpkg-
source uses them in version 3
- Integrates with git-buildpackage
- Doesn't need anything, that topgit hasn't ATM
Todo
----
discuss, test, script
Best regards,
Thomas Koch, http://www.koch.ro
^ permalink raw reply
* [RFC/PATCH] branch: new option --will-track
From: Dave Olszewski @ 2009-12-16 9:39 UTC (permalink / raw)
To: git; +Cc: Dave Olszewski
A common question from users creating branches in an environment where
they intend to push the branch to a shared bare repository, and then
later pull commits from upstream into the branch that they initially
created, is how do they create the branch with this tracking info
already set up.
This feature allows them to pre-specify the tracking info in their
config, so that after the branch has been pushed, no futher action is
needed to pull future commits.
Signed-off-by: Dave Olszewski <cxreg@pobox.com>
---
Documentation/git-branch.txt | 7 +++++++
Documentation/git-checkout.txt | 4 ++++
branch.c | 7 +++++--
branch.h | 2 +-
builtin-branch.c | 18 +++++++++++++++++-
builtin-checkout.c | 19 +++++++++++++++++--
cache.h | 1 +
t/t3200-branch.sh | 8 ++++++++
t/t7201-co.sh | 10 ++++++++++
9 files changed, 70 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 0e83680..ca7b120 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -129,6 +129,13 @@ start-point is either a local or remote branch.
Do not set up "upstream" configuration, even if the
branch.autosetupmerge configuration variable is true.
+--will-track <remote ref>::
+ Instead of tracking the starting point, a user might wish to set
+ up tracking info for a future location of the branch once it's
+ been pushed to a remote. Specifying this allows you to
+ configure the branch in such a way before the branch actually
+ exists on the remote.
+
--contains <commit>::
Only list branches which contain the specified commit.
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 37c1810..c18852a 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -86,6 +86,10 @@ explicitly give a name with '-b' in such a case.
Do not set up "upstream" configuration, even if the
branch.autosetupmerge configuration variable is true.
+--will-track <remote ref>::
+ Configure "upstream" as a yet-nonexistent remote branch. See
+ "--will-track" in linkgit:git-branch[1] for details.
+
-l::
Create the new branch's reflog; see linkgit:git-branch[1] for
details.
diff --git a/branch.c b/branch.c
index 05ef3f5..c3f6bbe 100644
--- a/branch.c
+++ b/branch.c
@@ -126,7 +126,8 @@ static int setup_tracking(const char *new_ref, const char *orig_ref,
void create_branch(const char *head,
const char *name, const char *start_name,
- int force, int reflog, enum branch_track track)
+ int force, int reflog, enum branch_track track,
+ const char *will_track)
{
struct ref_lock *lock;
struct commit *commit;
@@ -184,7 +185,9 @@ void create_branch(const char *head,
snprintf(msg, sizeof msg, "branch: Created from %s",
start_name);
- if (real_ref && track)
+ if (will_track)
+ setup_tracking(name, will_track, track);
+ else if (real_ref && track)
setup_tracking(name, real_ref, track);
if (write_ref_sha1(lock, sha1, msg) < 0)
diff --git a/branch.h b/branch.h
index eed817a..30fd5c7 100644
--- a/branch.h
+++ b/branch.h
@@ -13,7 +13,7 @@
* branch for (if any).
*/
void create_branch(const char *head, const char *name, const char *start_name,
- int force, int reflog, enum branch_track track);
+ int force, int reflog, enum branch_track track, const char *will_track);
/*
* Remove information about the state of working on the current
diff --git a/builtin-branch.c b/builtin-branch.c
index 05e876e..b29e6cf 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -556,12 +556,15 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
enum branch_track track;
int kinds = REF_LOCAL_BRANCH;
struct commit_list *with_commit = NULL;
+ char *will_track = NULL;
struct option options[] = {
OPT_GROUP("Generic options"),
OPT__VERBOSE(&verbose),
OPT_SET_INT('t', "track", &track, "set up tracking mode (see git-pull(1))",
BRANCH_TRACK_EXPLICIT),
+ OPT_STRING(0, "will-track", &will_track, "future remote branch",
+ "set up branch to track future remote branch"),
OPT_BOOLEAN( 0 , "color", &branch_use_color, "use colored output"),
OPT_SET_INT('r', NULL, &kinds, "act on remote-tracking branches",
REF_REMOTE_BRANCH),
@@ -628,6 +631,16 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
if (!!delete + !!rename + !!force_create > 1)
usage_with_options(builtin_branch_usage, options);
+ if (will_track) {
+ will_track = xstrdup(will_track);
+ if (strncmp(will_track, "refs/remotes/", 13)) {
+ will_track = xrealloc(will_track, sizeof(char) * (strlen(will_track) + 14));
+ memmove(will_track + 13, will_track, strlen(will_track) + 1);
+ memcpy(will_track, "refs/remotes/", 13);
+ }
+ track = BRANCH_TRACK_FUTURE;
+ }
+
if (delete)
return delete_branches(argc, argv, delete > 1, kinds);
else if (argc == 0)
@@ -638,9 +651,12 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
rename_branch(argv[0], argv[1], rename > 1);
else if (argc <= 2)
create_branch(head, argv[0], (argc == 2) ? argv[1] : head,
- force_create, reflog, track);
+ force_create, reflog, track, will_track);
else
usage_with_options(builtin_branch_usage, options);
+ if (will_track)
+ free(will_track);
+
return 0;
}
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 64f3a11..f69be79 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -34,6 +34,7 @@ struct checkout_opts {
const char *new_branch;
int new_branch_log;
enum branch_track track;
+ char *will_track;
};
static int post_checkout_hook(struct commit *old, struct commit *new,
@@ -484,7 +485,7 @@ static void update_refs_for_switch(struct checkout_opts *opts,
const char *old_desc;
if (opts->new_branch) {
create_branch(old->name, opts->new_branch, new->name, 0,
- opts->new_branch_log, opts->track);
+ opts->new_branch_log, opts->track, opts->will_track);
new->name = opts->new_branch;
setup_branch_path(new);
}
@@ -621,6 +622,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
struct option options[] = {
OPT__QUIET(&opts.quiet),
OPT_STRING('b', NULL, &opts.new_branch, "new branch", "branch"),
+ OPT_STRING(0, "will-track", &opts.will_track, "future remote branch", "nonexistent branch on remote that will be tracked"),
OPT_BOOLEAN('l', NULL, &opts.new_branch_log, "log for new branch"),
OPT_SET_INT('t', "track", &opts.track, "track",
BRANCH_TRACK_EXPLICIT),
@@ -650,7 +652,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, prefix, options, checkout_usage,
PARSE_OPT_KEEP_DASHDASH);
- if (patch_mode && (opts.track > 0 || opts.new_branch
+ if (patch_mode && (opts.track > 0 || opts.new_branch || opts.will_track
|| opts.new_branch_log || opts.merge || opts.force))
die ("--patch is incompatible with all other options");
@@ -810,6 +812,19 @@ no_reference:
if (!get_sha1(buf.buf, rev))
die("git checkout: branch %s already exists", opts.new_branch);
strbuf_release(&buf);
+
+ if (opts.will_track) {
+ opts.will_track = xstrdup(opts.will_track);
+ if (strncmp(opts.will_track, "refs/remotes/", 13)) {
+ opts.will_track = xrealloc(opts.will_track,
+ sizeof(char) * (strlen(opts.will_track) + 14));
+ memmove(opts.will_track + 13, opts.will_track,
+ strlen(opts.will_track) + 1);
+ memcpy(opts.will_track, "refs/remotes/", 13);
+ }
+
+ opts.track = BRANCH_TRACK_FUTURE;
+ }
}
if (new.name && !new.commit) {
diff --git a/cache.h b/cache.h
index bf468e5..1dd7762 100644
--- a/cache.h
+++ b/cache.h
@@ -544,6 +544,7 @@ enum branch_track {
BRANCH_TRACK_REMOTE,
BRANCH_TRACK_ALWAYS,
BRANCH_TRACK_EXPLICIT,
+ BRANCH_TRACK_FUTURE,
};
enum rebase_setup_type {
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index d59a9b4..67e769a 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -137,6 +137,14 @@ test_expect_success 'test tracking setup via --track' \
test $(git config branch.my1.remote) = local &&
test $(git config branch.my1.merge) = refs/heads/master'
+test_expect_success 'test tracking setup via --will-track' \
+ 'git config remote.local.url . &&
+ git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
+ (git show-ref -q refs/remotes/local/master || git fetch local) &&
+ git branch --will-track local/my11 my11 local/master &&
+ test $(git config branch.my11.remote) = local &&
+ test $(git config branch.my11.merge) = refs/heads/my11'
+
test_expect_success 'test tracking setup (non-wildcard, matching)' \
'git config remote.local.url . &&
git config remote.local.fetch refs/heads/master:refs/remotes/local/master &&
diff --git a/t/t7201-co.sh b/t/t7201-co.sh
index ebfd34d..803bcad 100755
--- a/t/t7201-co.sh
+++ b/t/t7201-co.sh
@@ -330,6 +330,16 @@ test_expect_success \
test "$(git config branch.track2.merge)"
git config branch.autosetupmerge false'
+test_expect_success \
+ 'checkout w/--will-track sets up tracking' '
+ git config branch.autosetupmerge false &&
+ git config remote.local.url . &&
+ git config remote.local.fetch refs/heads/*:refs/remotes/local/* &&
+ git checkout master &&
+ git checkout --will-track local/track3 -b track3 &&
+ test "$(git config branch.track3.remote)" &&
+ test "$(git config branch.track3.merge)"'
+
test_expect_success 'checkout w/--track from non-branch HEAD fails' '
git checkout master^0 &&
test_must_fail git symbolic-ref HEAD &&
--
1.6.6.rc2.8.g5599df
^ permalink raw reply related
* Re: git svn clone just stops
From: Eric Wong @ 2009-12-16 8:15 UTC (permalink / raw)
To: Mark Jerkovic; +Cc: git
In-Reply-To: <1260915555.6475.8.camel@mark.engr.acx>
Mark Jerkovic <mjerkovic@aconex.com> wrote:
> Hi all,
>
> I am new to Git and I am attempting to clone a SVN repository
> (containing approximately 60,000 commits) to Git.
>
> Using Git v1.6.0.4 with the following command:
>
> git svn clone https://path/to/svn/repo/trunk project.git
> --authors-file=svnauthors.txt --no-metadata
>
> the process just ends without any messages and the Git repository is
> empty. I have attempted this four times already, and each time it has
> stopped after a different revision, so I can't pin it down to a
> particular commit.
Hi Mark,
Any chance you're OOM-ing (extremely large file) or running
out of space somewhere? What exit code do you get when it exits?
> Has anyone experienced this before? Is there a log anywhere that
> records what is happening during this process?
Not without error messages of some sort. git svn was designed with poor
network conditions in mind and clone is resumable, so you can just
resume like this:
cd project.git && git svn fetch
I wouldn't use --no-metadata at this point, though, as it makes it much
harder to debug/fix things or recover from errors.
Once you're comfortable with it, you should be able to write
"git filter-branch" invocation to remove the metadata lines.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH v5 1/7] reset: do not accept a mixed reset in a .git dir
From: Christian Couder @ 2009-12-16 6:36 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt,
Stephen Boyd
In-Reply-To: <7vskbcyot5.fsf@alter.siamese.dyndns.org>
On mardi 15 décembre 2009, Junio C Hamano wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
> > While at it, instead of disallowing "git reset --option" outside
> > a work tree only when option is "hard" or "merge", we now disallow
> > it except when option is "soft" or "mixed", as it is safer if we
> > ever add options to "git reset".
>
> I fail to see any sane logic behind this reasoning; you cannot decide if
> you need to allow or disallow the new --option with unspecified semantics
> until you have that --option, and you are saying
>
> Hmm, "reset --option" that does not work when it should work is a bug,
> just like "reset --option" that does not refuse to work when it should
> refuse is, and you cannot decide if you should allow a new --option until
> you have it. Your "disallowing everything the code does not know about
> by default" doesn't particularly sound safer to me. I'd suggest dropping
> it from this patch.
Ok, I will drop it.
> It is perfectly fine to have a change like that, if it makes the logic
> easier to follow with the updated repertoire when a new --option is
> added, but not before.
Ok.
[...]
> By "after the next patch, it will not fail in a bare repository",
> did you mean "if the next patch blindly replaced an external call to
> read-tree with an internal call to unpack_trees(), it will change the
> behaviour, and we will end up allowing '--mixed in bare'. To prevent it
> from happening, cmd_reset() should check that condition upfront"?
Yes, that's what I meant.
> Then you were not trying to hide regressions (which makes me happier).
> But then doesn't the change belong to the next patch, not this one?
I can put it in the patch that calls unpack_trees() directly, but on the
other hand it can also be seen as an improvement that could be applied
to "maint" as it improves the error message.
Best regards,
Christian.
^ permalink raw reply
* Re: TortoiseGIT
From: Frank Li @ 2009-12-16 6:26 UTC (permalink / raw)
To: Laszlo Papp; +Cc: git
In-Reply-To: <a362e8010912150741x2c39c01bh1f64e669726dafab@mail.gmail.com>
You keep cr+lf on/off on whole develop cycle. Avoid change it during
developing.
After change cr+lf setting, I perfer you remove all work copy and
recheckout all.
best regards
Frank Li
2009/12/15 Laszlo Papp <djszapi@archlinux.us>:
> Hello,
>
> I had got a problem in the past with cr + lf between windows and linux
> client(maybe now too).
> I heard that from more experienced users I need to set autocrlf +
> safecrlf on windows, and core.autocrlf false on linux (which is the
> default), but If I set core.autocrlf true on linux too, it worked
> normally, after a git pull on windows I don't see any modified file
> that should be committed, not the case in core.autocrlf false.
>
> Could someone explain this habbit of git, please ?
>
> Everybody said I need to set autocrlf for false, but it doesn't work
> so, just with true on linux client, what do I do wrong ?
> It's okay now for me, because it works without any problem, I just
> don't understand the behaviour of it, and I don't know whether it will
> cause further problems.
>
> Thanks in advance!
>
> Best Regards,
> Laszlo Papp
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ 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