* Re: Overwrite master
From: Nicholas Wieland @ 2008-12-02 20:09 UTC (permalink / raw)
To: Peter Harris; +Cc: git
In-Reply-To: <eaa105840812020832p395ecefdq57e62f95182a3557@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 775 bytes --]
Il giorno 02/dic/08, alle ore 17:32, Peter Harris ha scritto:
> On Tue, Dec 2, 2008 at 11:10 AM, Nicholas Wieland wrote:
>> Hi *,
>> I need to overwrite my master branch with another branch. I've
>> already
>> created a backup branch of my master.
>
> While on master,
> "git reset --hard <newbranch>"
>
> Or while on a different branch,
> git branch -D master
> git branch master <newbranch>
That's what I tried.
Unfortunately I don't know where to go after:
ngw@slicingupeyeballs ~/zooppa$ git commit
# On branch master
# Your branch and 'origin/master' have diverged,
# and have 444 and 25 different commit(s) each, respectively.
#
nothing to commit (working directory clean)
Do I have to push ? If I pull it tries to merge ...
Thanks a lot for your time,
ngw
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2435 bytes --]
^ permalink raw reply
* Re: git-p4, SyntaxError: invalid syntax
From: Jason Foreman @ 2008-12-02 19:45 UTC (permalink / raw)
To: git list
In-Reply-To: <186027.87419.qm@web37901.mail.mud.yahoo.com>
On Tue, Dec 2, 2008 at 1:08 PM, Gary Yang <garyyang6@yahoo.com> wrote:
>
> /home/gyang/bin/git-p4:161: Warning: 'yield' will become a reserved keyword in the future
> File "/user/svdc/pluo/bin/git-p4", line 161
> yield pattern
> ^
> SyntaxError: invalid syntax
>
This seems to indicate that your python doesn't support the "yield"
keyword (used in generators).
Are you using Python 2.2? If so, that is a very old Python and I'd
recommend upgrading. But even with 2.2 you can fix this by adding the
following import line:
from __future__ import generators
I'm not familiar with the git-p4 file specifically but the above
should hopefully fix your problem.
Cheers,
Jason
^ permalink raw reply
* git-p4, SyntaxError: invalid syntax
From: Gary Yang @ 2008-12-02 19:08 UTC (permalink / raw)
To: git list
I got git-p4 from “git clone git://git.kernel.org/pub/scm/git/git.git git”
I copied git-p4 from contrib/fast-import/git-p4 to /home/gyang/bin
I got SyntaxError when I ran,
git-p4 clone //depot/Workshop
/home/gyang/bin/git-p4:161: Warning: 'yield' will become a reserved keyword in the future
File "/user/svdc/pluo/bin/git-p4", line 161
yield pattern
^
SyntaxError: invalid syntax
I opened the file, git-p4. There are three import lines. I am not python programmer. Maybe I missed something in python? I have python installed at /usr/local/bin/python
which python
/usr/local/bin/python
vi git-p4
import optparse, sys, os, marshal, popen2, subprocess, shelve
import tempfile, getopt, sha, os.path, time, platform
import re
Can someone tell me what I missed?
Thanks.
^ permalink raw reply
* Re: Managing websites with git
From: Junio C Hamano @ 2008-12-02 19:07 UTC (permalink / raw)
To: Jeff King; +Cc: Jason Riedy, git
In-Reply-To: <20081202165507.GA15826@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Dec 02, 2008 at 10:55:34AM -0500, Jason Riedy wrote:
>
>> Ah, ok, thanks! Issuing a warning makes sense. I'm not sure if
>> denying such a push by default does...
> ...
> It shouldn't make you change how you work. At most, it will break an
> existing setup until you set receive.denycurrentbranch to false (again,
> if and when the default value changes). You can prepare for any such
> change now by pre-emptively setting the config value.
True.
But "pre-emptively" is a bit misleading. Please realize that the warning
is not about "this is a risky thing to do, you've been warned", but is
about "the behaviour to allow this may change in the future; if you rely
on it please set this config before that happens". We may end up not
flipping the default for a long time, but setting the config also has the
side effect of squelching the warning, so it never hurts to set it now.
^ permalink raw reply
* Re: Grafting mis-aligned trees.
From: Boyd Stephen Smith Jr. @ 2008-12-02 18:28 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <493572A3.4070205@drmicha.warpmail.net>
[-- Attachment #1: Type: text/plain, Size: 2327 bytes --]
On Tuesday 02 December 2008, Michael J Gruber <git@drmicha.warpmail.net>
wrote about 'Re: Grafting mis-aligned trees.':
>Boyd Stephen Smith Jr. venit, vidit, dixit 02.12.2008 18:19:
>> I can't help thinking that rebase -ip might have helped. I wasn't
>> aware of -p when I was initially working on this problem. (It doesn't
>> help that I generally use Debian stable, and git 1.4 did not have -p.)
>
>rebase rebases one branch at a time, but you need to rebase/rewrite
>several, and the merge info between depends on rewritten sha1s.
Yes. I guess that's why I employed filter-branch to begin with.
>> I probably don't need the -f. If there are files that should be
>> ignored (and thus shouldn't be in the repo), I'll filter-branch to cut
>> them out of the history at some point.
>
>'-f' is about not having to clean out refs/original from a previous
>filter-branch run.
Okay, I misread your command line. For some reason I thought "-f" was an
option to add.
>> What *exactly* is the subtree merge. The documentation I've read
>> sounds like this case, sort of, but it's rather unclear to me.
>
>I think 'subtree' does what you want, but 'merge' doesn't!
*giggle* I'm not quite sure what makes this funny to me, but it made me
laugh.
>'subtree'
>saves you the rewriting (putting TI into project/web), but you want a
>one-time conversion anyway. 'subtree' allows you to repeatedly merge
>branches with a different root. What it does is it looks for subdir,
>'rewrites' the incoming tree automatically and merges the result.
>
>But you don't want a merge, do you? Or else your whole TI history would
>be tacked onto FT's head "to the left": a new (subtree) merge commit
>would have FT's and TI's head as parents. This is one way of storing TI
>history in the full repo, but not the one you said you wanted.
You are right; that's not what I want. But, it is a good second-place
result that I'll keep in mind. Sometimes keeping the history at all is
more important that keeping the history orderly.
Again, thanks for the help.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss03@volumehost.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.org/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Branch name with space
From: Shawn O. Pearce @ 2008-12-02 18:03 UTC (permalink / raw)
To: Le; +Cc: git
In-Reply-To: <4935719A.8000705@distributel.ca>
Le <le_wen@distributel.ca> wrote:
> I tried to rename a branch to a new name with space in it. It complained :
> git-branch -M 'test 1' or test\ 1
> fatal: Invalid branch name: refs/heads/test 1
>
> Is there a way the get round this problem?
Don't put spaces in branch names. They aren't permitted. Use
an underscore ('_') or a hypen ('-').
--
Shawn.
^ permalink raw reply
* Re: Bugs in git-gui and git-push when pushing src:dst to mirror?
From: Mark Burton @ 2008-12-02 17:49 UTC (permalink / raw)
To: git
In-Reply-To: <20081202130859.43ba54f6@crow>
On Tue, 2 Dec 2008 13:08:59 +0000
Mark Burton <markb@ordern.com> wrote:
> The other issue is that although git-push did print the usage blurb,
> it didn't actually produce a message saying what it's problem was.
Ah, just twigged, 1.6.0.4 doesn't include b259f09b181c (Make push more
verbose about illegal combination of options) so the lack of error message
from push is understandable.
Cheers,
Mark
^ permalink raw reply
* Branch name with space
From: Le @ 2008-12-02 17:34 UTC (permalink / raw)
To: git
Hi, there,
I tried to rename a branch to a new name with space in it. It complained :
git-branch -M 'test 1' or test\ 1
fatal: Invalid branch name: refs/heads/test 1
Is there a way the get round this problem?
Thanks!
Le
^ permalink raw reply
* Re: Grafting mis-aligned trees.
From: Michael J Gruber @ 2008-12-02 17:38 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git
In-Reply-To: <200812021119.51857.bss03@volumehost.net>
Boyd Stephen Smith Jr. venit, vidit, dixit 02.12.2008 18:19:
...
> It does feel a bit "hacky", I was hoping git would have better support
> this, through the subtree merge or something else. It seems like
> something that might happen to others, perhaps as a side-effect of a
> failed attempt at using submodules.
Well, except for 'tar' my solution uses only git commands ;)
> I can't help thinking that rebase -ip might have helped. I wasn't aware
> of -p when I was initially working on this problem. (It doesn't help that
> I generally use Debian stable, and git 1.4 did not have -p.)
rebase rebases one branch at a time, but you need to rebase/rewrite
several, and the merge info between depends on rewritten sha1s.
...
> I probably don't need the -f. If there are files that should be ignored
> (and thus shouldn't be in the repo), I'll filter-branch to cut them out of
> the history at some point.
'-f' is about not having to clean out refs/original from a previous
filter-branch run.
> What *exactly* is the subtree merge. The documentation I've read sounds
> like this case, sort of, but it's rather unclear to me.
I think 'subtree' does what you want, but 'merge' doesn't! 'subtree'
saves you the rewriting (putting TI into project/web), but you want a
one-time conversion anyway. 'subtree' allows you to repeatedly merge
branches with a different root. What it does is it looks for subdir,
'rewrites' the incoming tree automatically and merges the result.
But you don't want a merge, do you? Or else your whole TI history would
be tacked onto FT's head "to the left": a new (subtree) merge commit
would have FT's and TI's head as parents. This is one way of storing TI
history in the full repo, but not the one you said you wanted.
Michael
^ permalink raw reply
* Re: [PATCH] Modifies the default git help message to be grouped by topic
From: Jeff King @ 2008-12-02 17:28 UTC (permalink / raw)
To: Scott Chacon; +Cc: gitster, git
In-Reply-To: <20081202172025.GB15826@coredump.intra.peff.net>
On Tue, Dec 02, 2008 at 12:20:25PM -0500, Jeff King wrote:
> Sorry to reverse direction after you resubmitted, but my earlier comment
> on "this list shouldn't change frequently" didn't take into account that
> the _synopsis_ might change, which is much more likely. So maybe rather
> than ditching the auto-generation, it makes sense to just hardcode the
> order and categorization, but pull the rest from autogeneration.
Note also that one could of course just use "common:basic" or something
like that in command-list.txt. But to handle arbitrary ordering, we
would have to reorder command-list as appropriate (which currently gets
sorted), or do something awful like common:basic1, common:basic2, etc. I
tried to choose the most straightforward approach that didn't involve
duplication of information.
-Peff
^ permalink raw reply
* Re: [PATCH] Modifies the default git help message to be grouped by topic
From: Jeff King @ 2008-12-02 17:20 UTC (permalink / raw)
To: Scott Chacon; +Cc: gitster, git
In-Reply-To: <20081202060509.GA48796@agadorsparticus>
On Mon, Dec 01, 2008 at 10:05:09PM -0800, Scott Chacon wrote:
> - sed -n '
> - /NAME/,/git-'"$cmd"'/H
> - ${
> - x
> - s/.*git-'"$cmd"' - \(.*\)/ {"'"$cmd"'", "\1"},/
> - p
> - }' "Documentation/git-$cmd.txt"
Sorry to reverse direction after you resubmitted, but my earlier comment
on "this list shouldn't change frequently" didn't take into account that
the _synopsis_ might change, which is much more likely. So maybe rather
than ditching the auto-generation, it makes sense to just hardcode the
order and categorization, but pull the rest from autogeneration.
Something like the patch below (though it makes the 'common' tag in
command-list.txt somewhat redundant, so we should probably just remove
that):
diff --git a/builtin-help.c b/builtin-help.c
index f076efa..b5eafb7 100644
--- a/builtin-help.c
+++ b/builtin-help.c
@@ -275,6 +275,15 @@ static int git_help_config(const char *var, const char *value, void *cb)
static struct cmdnames main_cmds, other_cmds;
+static const char *find_cmdname_help(const char *name)
+{
+ int i;
+ for (i = 0; i < ARRAY_SIZE(common_cmds); i++)
+ if (!strcmp(common_cmds[i].name, name))
+ return common_cmds[i].help;
+ return "";
+}
+
void list_common_cmds_help(void)
{
int i, longest = 0;
@@ -285,11 +294,43 @@ void list_common_cmds_help(void)
}
puts("The most commonly used git commands are:");
- for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
- printf(" %s ", common_cmds[i].name);
- mput_char(' ', longest - strlen(common_cmds[i].name));
- puts(common_cmds[i].help);
- }
+
+#define COMMON(x) \
+do { \
+ printf(" %s ", x); \
+ mput_char(' ', longest - strlen(x)); \
+ puts(find_cmdname_help(x)); \
+} while(0)
+
+ puts("Basic Commands");
+ COMMON("init");
+ COMMON("add");
+ COMMON("status");
+ COMMON("commit");
+ puts("");
+
+ puts("History Commands");
+ COMMON("log");
+ COMMON("diff");
+ COMMON("reset");
+ COMMON("show");
+ puts("");
+
+ puts("Branch Commands");
+ COMMON("checkout");
+ COMMON("branch");
+ COMMON("merge");
+ COMMON("rebase");
+ COMMON("tag");
+ puts("");
+
+ puts("Remote Commands");
+ COMMON("clone");
+ COMMON("fetch");
+ COMMON("pull");
+ COMMON("push");
+
+#undef COMMON
}
static int is_git_command(const char *s)
^ permalink raw reply related
* Re: Grafting mis-aligned trees.
From: Boyd Stephen Smith Jr. @ 2008-12-02 17:19 UTC (permalink / raw)
To: git; +Cc: Michael J Gruber
In-Reply-To: <4935606A.8050906@drmicha.warpmail.net>
[-- Attachment #1: Type: text/plain, Size: 3605 bytes --]
On Tuesday 02 December 2008, Michael J Gruber <git@drmicha.warpmail.net>
wrote about 'Re: Grafting mis-aligned trees.':
>Boyd Stephen Smith Jr. venit, vidit, dixit 29.11.2008 00:01:
>> On Tuesday 2008 November 18 03:24, Michael J Gruber wrote:
>>> Boyd Stephen Smith Jr. venit, vidit, dixit 17.11.2008 23:45:
>>>> Trees look something like this right now.
>>>>
>>>> <some history> -> FT
>>>>
>>>> TI -> <non-linear history> -> A -> <non-linear history> -> C
>>>> \ \ \
>>>> -> PI ------------------------> B ------------------------> D
>>>>
>>>> I'd like to have it look something like:
>>>>
>>>> <some history> -> FT -> <non-linear history> -> A' -> <non-linear
>>>> history> -> C' \ \
>>>> \ -> PI' ----------------------> B' -----------------------> D'
>>>>
>>>> A', B', C', and D' are different commits, but the diff (and history)
>>>> between FT and A' is the same as the diff (and history) between TI
>>>> and A.
>>>
>>> So, your base directory for TI and FT is different, right? I.e.: In
>>> the TI repo, your project sits at the root, whereas in the FT repo it
>>> sits in project/web?
>>
>> Yes.
>>
>>> Has FT advanced since you took the initial subdir
>>> snapshot for TI?
>>
>> No.
>
>OK, here's a possibly primitive solution, but it works with my little
>toy model of your layout:
That sounds like it will work fine. Thank you very much.
It does feel a bit "hacky", I was hoping git would have better support
this, through the subtree merge or something else. It seems like
something that might happen to others, perhaps as a side-effect of a
failed attempt at using submodules.
I can't help thinking that rebase -ip might have helped. I wasn't aware
of -p when I was initially working on this problem. (It doesn't help that
I generally use Debian stable, and git 1.4 did not have -p.)
>- filter-branch your TI branches so that they are in the proper subdir
>(you did that already)
If I need to "undo" this, it's really easy.
>- take a snapshot (say ftstuff.tar) of everything in FT's head (assuming
>this is where TI branched off, or else take that point) *but exclude
>project/web*
>
>- using filter-branch again, rewrite your TI branches to contain those
>missing FT files:
>git filter-branch --tree-filter 'tar -xf /tmp/ftstuff.tar && git add .'
>-f -- ti/master ti/whatever
I probably don't need the -f. If there are files that should be ignored
(and thus shouldn't be in the repo), I'll filter-branch to cut them out of
the history at some point.
Now is as good a time as any.
>Now your TI branches produce the same diffs as before, but are based on
>the full tree. You can happily graft FT's head onto TI's root as a
> parent. In fact those two should produce no diff in between them, so you
> might as well get rid of one of them.
Makes sense.
>[cleaning out refs/original and repack -adf might be in order afterwards]
I generally do these after a successful filter-branch.
>The tree-filter part feels hacky but does the job (probably with -f). I
>don't think a subtree merge can do what you want.
What *exactly* is the subtree merge. The documentation I've read sounds
like this case, sort of, but it's rather unclear to me.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss03@volumehost.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.org/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Managing websites with git
From: Jeff King @ 2008-12-02 16:55 UTC (permalink / raw)
To: Jason Riedy; +Cc: git
In-Reply-To: <87vdu2po5l.fsf@sparse.dyndns.org>
On Tue, Dec 02, 2008 at 10:55:34AM -0500, Jason Riedy wrote:
> Ah, ok, thanks! Issuing a warning makes sense. I'm not sure if
> denying such a push by default does...
I don't know if Junio has made a decision on whether or when the default
should be flipped to 'deny'.
> > Doing git push $remote HEAD:branch-that-is-checked-out
> > has _never_ worked without further action on $remote. Now we're warning
> > about it.
>
> It works just fine. I suspect we have different definitions of
> "works".
Fair enough. To be more precise: such a push has always resulted in a
state on the remote end that the user must be aware of when making
further commits, and the result of _not_ being aware and blindly running
"git commit" is to accidentally revert all of the pushed changes. And
even if one _is_ aware, sorting out any existing changes in the index
from pushed changes can be difficult.
So yes, there are workflows that can legitimately make use of a push to
the current branch. But it is still a dangerous operation for a large
number of users (I would argue the majority, but I don't have actual
numbers) that we have seen numerous complaints about.
> To me, that push updates the branch's reference. The working
> copy and index now may be out of sync, but neither the working
> copy nor the index is the branch's reference. Trying to commit
> from the index correctly refuses. The warning is a nice
How is committing from the index refused? Try this:
mkdir parent &&
(cd parent &&
git init &&
echo content >file &&
git add file &&
git commit -m one) &&
git clone parent child &&
(cd child &&
echo changes >>file &&
git commit -a -m two &&
git push) &&
(cd parent &&
git commit -m oops &&
git show
)
You will find that you have just reverted the changes from 'two' with
'oops'.
Committing straight from the working tree (via "git commit <path>" or
"git commit -a") has the same problem.
> (And in context: I used to update the IEEE754 group's web site by
> a git push to the checked-out master, with a hook to reset
> everything. Worked just fine (and very quickly) until they shut
> off shell access. There was no need for an extra branch on the
> server side.)
Follow the earlier parts of the thread and you will see that is one of
the sane workflows that has been mentioned. You are aware of the lack of
sync (and you have a hook to address it) and you don't plan on having
any local changes (so sorting them out is easy -- you just "git reset
--hard" to take the pushed content).
> I'll try to find time when I encounter another. I'm pretty sure
> that switching to denying pushes to checked-out branches is the
> first one that *really* will make me change how I work.
It shouldn't make you change how you work. At most, it will break an
existing setup until you set receive.denycurrentbranch to false (again,
if and when the default value changes). You can prepare for any such
change now by pre-emptively setting the config value.
-Peff
^ permalink raw reply
* [man bug?] git rebase --preserve-merges
From: Constantine Plotnikov @ 2008-12-02 16:45 UTC (permalink / raw)
To: git
The man page for git rebase mentions "--preserve-merges" command line
option but this option does not seems to be available.
Also if this option is specified, the following usage statement is printed:
Usage: git rebase [--interactive | -i] [-v] [--onto <newbase>]
<upstream> [<branch>]
And this usage statement does not mention -m and -s options that seems
to be available. I assume that the problem is the obsolete
documentation.
Regards,
Constantine
^ permalink raw reply
* Re: [JGIT PATCH v2 0/8] Unit test cleanups
From: Shawn O. Pearce @ 2008-12-02 16:38 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git, fonseca
In-Reply-To: <1228088435-23722-1-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> A completele reworked set of patches, including fixing a couple
> more forgot-to-close bugs and Shawns suggestion that we disable
> memory mapping in junit tests by default.
...
> Robin Rosenberg (8):
> Drop unneeded code in unit tests
> Cleanup malformed test cases
> Turn off memory mapping in JGit unit tests by default
> Add a counter to make sure the test repo name is unique
> Make the cleanup less verbose when it fails to delete temporary
> stuff.
> Cleanup after each test.
> Close files opened by unit testing framework
> Hard failure on unit test cleanups if they fail.
>
> .../tst/org/spearce/jgit/lib/PackWriterTest.java | 3 +
> .../org/spearce/jgit/lib/RepositoryTestCase.java | 152 +++++++++++++++++---
> .../tst/org/spearce/jgit/lib/T0007_Index.java | 10 +-
> 3 files changed, 139 insertions(+), 26 deletions(-)
Merged. The series looked really good to me. Second time is the
charm, eh? :-)
--
Shawn.
^ permalink raw reply
* Re: Managing websites with git
From: Jason Riedy @ 2008-12-02 15:55 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081202011154.GA6390@coredump.intra.peff.net>
And Jeff King writes:
> To clarify: one should not push to the _current branch_ of a
> non-bare repo...
Ah, ok, thanks! Issuing a warning makes sense. I'm not sure if
denying such a push by default does...
> Doing git push $remote HEAD:branch-that-is-checked-out
> has _never_ worked without further action on $remote. Now we're warning
> about it.
It works just fine. I suspect we have different definitions of
"works".
To me, that push updates the branch's reference. The working
copy and index now may be out of sync, but neither the working
copy nor the index is the branch's reference. Trying to commit
from the index correctly refuses. The warning is a nice
reminder, but I don't see why this should be denied by default.
The user (me) hasn't lost anything, and every tool does what it
is supposed to do (from my point of view).
But I'm one of those people who has always liked the three levels
of git. And I use them all.
(And in context: I used to update the IEEE754 group's web site by
a git push to the checked-out master, with a hook to reset
everything. Worked just fine (and very quickly) until they shut
off shell access. There was no need for an extra branch on the
server side.)
> If you have other specific complaints about new git behavior,
> I'm sure the list would be happy to hear about it.
I'll try to find time when I encounter another. I'm pretty sure
that switching to denying pushes to checked-out branches is the
first one that *really* will make me change how I work.
Jason
^ permalink raw reply
* Re: Overwrite master
From: Peter Harris @ 2008-12-02 16:32 UTC (permalink / raw)
To: Nicholas Wieland; +Cc: git
In-Reply-To: <D1AC0A41-E89A-4B53-A449-DA9C4422998E@zooppa.com>
On Tue, Dec 2, 2008 at 11:10 AM, Nicholas Wieland wrote:
> Hi *,
> I need to overwrite my master branch with another branch. I've already
> created a backup branch of my master.
While on master,
"git reset --hard <newbranch>"
Or while on a different branch,
git branch -D master
git branch master <newbranch>
Peter Harris
^ permalink raw reply
* Re: [PATCH] git-gui: Teach start_push_anywhere_action{} to notice when remote is a mirror.
From: Mark Burton @ 2008-12-02 16:31 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081202153007.GJ23984@spearce.org>
Hi Shawn,
> Yea, it is a chunk of work. I thought about trying to do it myself
> right now, but realized I won't be able to do it in 15 minutes and
> gave up. :-)
Well, when you/someone looks at updating the push dialog you could
consider adding another checkbox that disables the refspec so that the
push uses whatever default refspec has been configured. I think that would
be a useful addition.
Cheers,
Mark
^ permalink raw reply
* Re: Grafting mis-aligned trees.
From: Michael J Gruber @ 2008-12-02 16:20 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git
In-Reply-To: <200811281701.46778.bss03@volumehost.net>
Boyd Stephen Smith Jr. venit, vidit, dixit 29.11.2008 00:01:
> On Tuesday 2008 November 18 03:24, Michael J Gruber wrote:
>> Boyd Stephen Smith Jr. venit, vidit, dixit 17.11.2008 23:45:
>>> I haven't gotten a response from my subscription email, so please CC me
>>> on any replies.
>>>
>>> So, I've been managaing the source I had from a client project in git and
>>> have a non-linear history. Currently, two tips (production and testing)
>>> but there are many feature branches that were git-merge'd in, not
>>> rebased.
>>>
>>> Now, I've gotten the full tree. Turns out all the source code I was
>>> working on was in a subdirectory "project/web". I'd like to "graft" the
>>> *changes* I made onto the full tree.
>>>
>>> I figured this might be a job for git-filter-branch. Certainly, that did
>>> the job of moving all my changes into the subdirectory. But, now I want
>>> to do something that's a combination or git-rebase and git-filter-branch.
>>> I want to replay the *patches/deltas* (like rebase) on top of the full
>>> tree I have, but *maintain the non-liear history* (like filter-branch).
>>>
>>> Can anyone think of a recipe for me?
>>>
>>> Trees look something like this right now.
>>>
>>> <some history> -> FT
>>>
>>> TI -> <non-linear history> -> A -> <non-linear history> -> C
>>> \ \ \
>>> -> PI ------------------------> B ------------------------> D
>>>
>>> I'd like to have it look something like:
>>>
>>> <some history> -> FT -> <non-linear history> -> A' -> <non-linear
>>> history> -> C' \ \ \
>>> -> PI' ----------------------> B' -----------------------> D'
>>>
>>> A', B', C', and D' are different commits, but the diff (and history)
>>> between FT and A' is the same as the diff (and history) between TI and A.
>>>
>>> Again, please CC me on any replies.
>> [CCing is customary here anyways.]
>>
>> So, your base directory for TI and FT is different, right? I.e.: In the
>> TI repo, your project sits at the root, whereas in the FT repo it sits
>> in project/web?
>
> Yes.
>
>> Has FT advanced since you took the initial subdir
>> snapshot for TI?
>
> No. Well, maybe. I think the subdir diff is fairly trivial if not empty. TI
> is an import from the code actually present on the testing server. FT was
> the a subversion repository obtained later after some hullabaloo with the
> ex-development house.
>
> Right now this tree is effectively all mine, so I can always graft in commits
> to synchronize the common subtree of FT and TI, if that makes things easier.
OK, here's a possibly primitive solution, but it works with my little
toy model of your layout:
- filter-branch your TI branches so that they are in the proper subdir
(you did that already)
- take a snapshot (say ftstuff.tar) of everything in FT's head (assuming
this is where TI branched off, or else take that point) *but exclude
project/web*
- using filter-branch again, rewrite your TI branches to contain those
missing FT files:
git filter-branch --tree-filter 'tar -xf /tmp/ftstuff.tar && git add .'
-f -- ti/master ti/whatever
Now your TI branches produce the same diffs as before, but are based on
the full tree. You can happily graft FT's head onto TI's root as a parent.
In fact those two should produce no diff in between them, so you might
as well get rid of one of them.
[cleaning out refs/original and repack -adf might be in order afterwards]
The tree-filter part feels hacky but does the job (probably with -f). I
don't think a subtree merge can do what you want.
Cheers,
Michael
^ permalink raw reply
* Overwrite master
From: Nicholas Wieland @ 2008-12-02 16:10 UTC (permalink / raw)
To: git
Hi *,
I need to overwrite my master branch with another branch. I've already
created a backup branch of my master.
I tried a merge but it's just too big to handle, and I don't really
care about what's in my master now.
The reason I want to do something like this is to be able to branch
directly from my master in the future and merge back smaller branches
(basically what I didn't do this time ...) instead of trying to merge
back a huge one. This time I've used git like I've used svn, my bad,
very stupid thing ...
Hope my question is clear.
TIA,
ngw
^ permalink raw reply
* Re: [PATCH 5/5] support writing uncompressed loose object
From: Shawn O. Pearce @ 2008-12-02 16:07 UTC (permalink / raw)
To: Liu Yubao; +Cc: Junio C Hamano, git list
In-Reply-To: <4934975E.2010601@gmail.com>
Liu Yubao <yubao.liu@gmail.com> wrote:
>
> Signed-off-by: Liu Yubao <yubao.liu@gmail.com>
IMHO, this needs more description in the commit message.
> diff --git a/sha1_file.c b/sha1_file.c
> index 05a9fa3..053b564 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -2328,7 +2328,7 @@ static int create_tmpfile(char *buffer, size_t bufsiz, const char *filename)
> }
>
> static int write_loose_object(const unsigned char *sha1, char *hdr, int hdrlen,
> - void *buf, unsigned long len, time_t mtime)
> + void *buf, unsigned long len, time_t mtime, int dont_deflate)
Passing this as an argument is pointless. It should be a repository
wide configuration option in core, so you can declare it a static and
allow git_config to populate it. Defaulting to 1 (no compression)
like you do elsewhere in the patch isn't good.
I'm still against this file format change. The series itself isn't
that bad, and the buffer overflow catch in parse_sha1_header()
may be something worthwhile fixing. But I'm still not sold that
introducing a new loose object format is worth it.
I'd rather use a binary header encoding like the new-style/in-pack
format rather than the older style text headers. Its faster to
parse for one thing.
Your changes in the reading code cause a copy of the buffer we
mmap()'d. That sort of ruins your argument that this change is
worthwhile because concurrent processes on the same host can mmap the
same buffer and save memory. We're still copying the buffer anyway.
I probably should have commented on that in patch 4/5, but I just
realized it, so I'm saying it here.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 4/5] support reading uncompressed loose object
From: Shawn O. Pearce @ 2008-12-02 15:58 UTC (permalink / raw)
To: Liu Yubao; +Cc: Junio C Hamano, git list
In-Reply-To: <493495B4.5070304@gmail.com>
Liu Yubao <yubao.liu@gmail.com> wrote:
>
> Signed-off-by: Liu Yubao <yubao.liu@gmail.com>
I'd like to see a bit more of an explanation of the new loose
object format you are reading in the commit message. We have a
long history of explaining *why* the code behaves the way it does
in our commits, so we can look at it in blame/log and understand
what the heck went on.
> ---
> sha1_file.c | 20 +++++++++++++++++++-
> 1 files changed, 19 insertions(+), 1 deletions(-)
>
> diff --git a/sha1_file.c b/sha1_file.c
> index 79062f0..05a9fa3 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -1985,6 +1985,16 @@ static int sha1_loose_object_info(const unsigned char *sha1, unsigned long *size
> map = map_sha1_file(sha1, &mapsize);
> if (!map)
> return error("unable to find %s", sha1_to_hex(sha1));
> +
> + /*
> + * Is it an uncompressed loose objects?
> + */
> + if ((status = parse_sha1_header(map, mapsize, &size)) >= 0) {
> + if (sizep)
> + *sizep = size;
> + goto L_leave;
> + }
> +
> if (unpack_sha1_header(&stream, map, mapsize, hdr, sizeof(hdr)) < 0)
> status = error("unable to unpack %s header",
> sha1_to_hex(sha1));
> @@ -1993,6 +2003,8 @@ static int sha1_loose_object_info(const unsigned char *sha1, unsigned long *size
> else if (sizep)
> *sizep = size;
> inflateEnd(&stream);
> +
> +L_leave:
> munmap(map, mapsize);
> return status;
> }
> @@ -2124,7 +2136,13 @@ void *read_object(const unsigned char *sha1, enum object_type *type,
> return buf;
> map = map_sha1_file(sha1, &mapsize);
> if (map) {
> - buf = unpack_sha1_file(map, mapsize, type, size, sha1);
> + /*
> + * Is it an uncompressed loose object?
> + */
> + if ((*type = parse_sha1_header(map, mapsize, size)) >= 0)
> + buf = xmemdupz(map + strlen(map) + 1, *size);
> + else
> + buf = unpack_sha1_file(map, mapsize, type, size, sha1);
> munmap(map, mapsize);
> return buf;
> }
--
Shawn.
^ permalink raw reply
* Re: [PATCH 3/5] optimize parse_sha1_header() a little by detecting object type
From: Shawn O. Pearce @ 2008-12-02 15:53 UTC (permalink / raw)
To: Liu Yubao; +Cc: Junio C Hamano, git list
In-Reply-To: <49349579.2030506@gmail.com>
Liu Yubao <yubao.liu@gmail.com> wrote:
> diff --git a/sha1_file.c b/sha1_file.c
> index dccc455..79062f0 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -1099,7 +1099,8 @@ static void *map_sha1_file(const unsigned char *sha1, unsigned long *size)
>
> if (!fstat(fd, &st)) {
> *size = xsize_t(st.st_size);
> - map = xmmap(NULL, *size, PROT_READ, MAP_PRIVATE, fd, 0);
> + if (*size > 0)
> + map = xmmap(NULL, *size, PROT_READ, MAP_PRIVATE, fd, 0);
> }
> close(fd);
> }
This has nothing to do with this change description. Why are we
returning NULL from map_sha1_file when the file length is 0 bytes?
No loose object should ever be an empty file, there must always be
some sort of type header present. So it probably is an error to
have a 0 length file here. But that bug is a different change.
> @@ -1257,6 +1258,8 @@ static int parse_sha1_header(const char *hdr, unsigned long length, unsigned lon
> * terminating '\0' that we add), and is followed by
> * a space, at least one byte for size, and a '\0'.
> */
> + if ('b' != *hdr && 'c' != *hdr && 't' != *hdr) /* blob/commit/tag/tree */
> + return -1;
> i = 0;
> while (hdr < hdr_end - 2) {
> char c = *hdr++;
Oh. I wouldn't do that. Its a cute trick and it works to quickly
determine if the header is an uncompressed header vs. a zlib header
vs. a new-style loose object header (which git cannot write anymore,
but it still can read). But its just asking for trouble when/if a
new object type was ever added to the type table.
Given that we know that no type name can be more than 10 bytes and
if you use my patch from earlier today you can be certain hdr has a
'\0' terminator, so you could write a function to test for the type
against the hdr, stopping on either ' ' or '\0'. Or find the first
' ' in the first 10 bytes (which is what this loop does anyway) and
then test that against the type name table.
--
Shawn.
^ permalink raw reply
* Re: [StGit PATCH] Print conflict details with the new infrastructure (bug #11181)
From: Karl Hasselström @ 2008-12-02 15:43 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20081202144045.24372.69278.stgit@localhost.localdomain>
On 2008-12-02 14:40:45 +0000, Catalin Marinas wrote:
> The patch modifies the IndexAndWorkTree.merge() function to display
> pass the conflict information (files) when raising an exception. The
> logic is similar to the one in the old infrastructure.
Good. But
> if self.__error:
> - out.error(self.__error)
> + error_lines = self.__error.split('\n')
> + out.error(*error_lines)
this feels like something of a hack. Wouldn't it be cleaner to modify
MergeConflictException to hold e.g. the set of conflicting filenames,
and let it have a method that returned a list of lines? No biggie,
though.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 1/5] avoid parse_sha1_header() accessing memory out of bound
From: Shawn O. Pearce @ 2008-12-02 15:42 UTC (permalink / raw)
To: Liu Yubao; +Cc: Junio C Hamano, git list
In-Reply-To: <4934949B.70307@gmail.com>
Liu Yubao <yubao.liu@gmail.com> wrote:
> diff --git a/sha1_file.c b/sha1_file.c
> index 6c0e251..efe6967 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -1254,10 +1255,10 @@ static int parse_sha1_header(const char *hdr, unsigned long *sizep)
> /*
> * The type can be at most ten bytes (including the
> * terminating '\0' that we add), and is followed by
> - * a space.
> + * a space, at least one byte for size, and a '\0'.
> */
> i = 0;
> - for (;;) {
> + while (hdr < hdr_end - 2) {
> char c = *hdr++;
> if (c == ' ')
> break;
> @@ -1265,6 +1266,8 @@ static int parse_sha1_header(const char *hdr, unsigned long *sizep)
> if (i >= sizeof(type))
> return -1;
That first hunk I am citing is unnecessary, because of the lines
right above. All of the callers of this function pass in a buffer
that is at least 32 bytes in size; this loop aborts if it does not
find a ' ' within the first 10 bytes of the buffer. We'll never
access memory outside of the buffer during this loop.
So IMHO your first three hunks here aren't necessary.
> @@ -1275,7 +1278,7 @@ static int parse_sha1_header(const char *hdr, unsigned long *sizep)
> if (size > 9)
> return -1;
> if (size) {
> - for (;;) {
> + while (hdr < hdr_end - 1) {
> unsigned long c = *hdr - '0';
> if (c > 9)
> break;
OK, there's no promise here that we don't roll off the buffer.
This can be fixed in the caller, ensuring we always have the '\0'
at some point in the initial header buffer we were asked to parse:
diff --git a/sha1_file.c b/sha1_file.c
index 6c0e251..26c6ffb 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1162,9 +1162,10 @@ static int unpack_sha1_header(z_stream *stream, unsigned char *map, unsigned lon
stream->next_in = map;
stream->avail_in = mapsize;
stream->next_out = buffer;
- stream->avail_out = bufsiz;
if (legacy_loose_object(map)) {
+ stream->avail_out = bufsiz - 1;
+ buffer[bufsiz - 1] = '\0';
inflateInit(stream);
return inflate(stream, 0);
}
@@ -1186,6 +1187,7 @@ static int unpack_sha1_header(z_stream *stream, unsigned char *map, unsigned lon
/* Set up the stream for the rest.. */
stream->next_in = map;
stream->avail_in = mapsize;
+ stream->avail_out = bufsiz;
inflateInit(stream);
/* And generate the fake traditional header */
--
Shawn.
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox