* Re: Unhappy git in a jailshell?
From: Michael J Gruber @ 2009-11-02 13:51 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Alex MDC, git
In-Reply-To: <20091102124746.GA27126@dpotapov.dyndns.org>
Dmitry Potapov venit, vidit, dixit 02.11.2009 13:47:
> On Mon, Nov 02, 2009 at 11:16:43PM +1100, Alex MDC wrote:
>> Hello,
>>
>> I'm trying to use git on a linux server, but unfortunately I've only
>> been granted jailshelled access. Most of git works, but some commands
>> just fail to run, e.g.
>> git repack
>> git rebase
>> git index-pack
>
> Most Git commands are builtin, so they are executed by git.exe directly,
> but some commands are implemented as separate binaries or shell files.
> These commands require `git --exec-path` in PATH to run. Normally, git
> adds `git --exec-path` in its environment before running them.
>
> Apparently, jailshelled access prevents that somehow. So, I suggest you
> contact your system administrator and tell him that you need to be able
> to run files from `git --exec-path` to being able to use git, as git
> needs them internally for normal work.
>
Can you (Alex) find out whether you are allowed to run those binaries
from that path directly? In that case we could rethink our strategy and
adjust for the case where we can't set the environment.
Michael
^ permalink raw reply
* Re: My custom cccmd
From: Felipe Contreras @ 2009-11-02 14:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr5skim76.fsf@alter.siamese.dyndns.org>
On Fri, Oct 30, 2009 at 11:52 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Tue, Oct 27, 2009 at 11:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> It might make more sense if your tool told you about such a case directly,
>>> rather than helping you find John so that he can tell you ;-).
>>
>> But that's not the purpose of the cccmd tool.
>>
>> I agree that such "patch series simplificator" tool would be very
>> useful, but that's out of scope for this. Isn't it?
>
> Exactly.
>
> So you agree that you _do_ want to "discard the previous commits in the
> patch series", because not doing so would mean the result would be a
> half-cooked "patch series simplificator" that tries to do something that
> is outside the scope of cccmd, right?
>
> The "discarding the previous commits" happens to match what I suggested
> earlier that lead to your "explored this a bit more":
>
> On Thu, Oct 15, 2009 at 11:37 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
>> On Thu, Oct 15, 2009 at 11:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> #2. If you have two patch series that updates one file twice, some
>>> changes in your second patch could even be an update to the changes
>>> you introduced in your first patch. After you fix issue #1, you
>>> would probably want to fix this by excluding the commits you have
>>> already sent the blames for.
>
> so I think we are in agreement.
Cool. Is this script something that would make sense in the contrib section?
--
Felipe Contreras
^ permalink raw reply
* Re: git pull --rebase and losing commits
From: Thomas Rast @ 2009-11-02 15:04 UTC (permalink / raw)
To: Peter Krefting; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.2.00.0911021318400.3919@ds9.cixit.se>
Peter Krefting wrote:
> # Update tree (--strategy=ours avoids merge conflicts)
> git pull --rebase --strategy=ours origin master
[...]
> However, this seems to lose commits. When I ran it today, it commited an
> automatic change, and then pulled a tree that did not contain that change,
> making the changed file just disappear.
Not very surprising if you use the 'ours' strategy, which doesn't
merge at all but instead takes the 'ours' side (IIRC that's the
upstream for a rebase, but I always have these mixed up). It is *not*
the often requested (but ill-defined and hence never implemented)
"resolve all conflict hunks in favour of ours" strategy.
So what happens is that git-rebase rebuilds some commit C from your
side on some base B from the remote, but the 'ours' strategy turns the
*tree* for C' into that of B. Then git-rebase sees that the trees
haven't changed, and concludes that C has already been applied and
drops it.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: git pull --rebase and losing commits
From: Björn Steinbrink @ 2009-11-02 15:10 UTC (permalink / raw)
To: Peter Krefting; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.2.00.0911021318400.3919@ds9.cixit.se>
On 2009.11.02 13:26:37 +0100, Peter Krefting wrote:
> # Update tree (--strategy=ours avoids merge conflicts)
> git pull --rebase --strategy=ours origin master
The "ours" strategy doesn't just avoid merge conflicts, it avoids making
any changes at all. The ours strategy means "just keep our state, just
pretend that we've merged". And rebase will see that there were no
changes and conclude:
Already applied: 0001 test commit
And thus it will drop the commit.
Björn
^ permalink raw reply
* Binary files in a linear repository
From: Markus Hitter @ 2009-11-02 15:08 UTC (permalink / raw)
To: git
In-Reply-To: <S1754797AbZKBONX/20091102141323Z+268@vger.kernel.org>
Hello all,
currently I'm planning a frontend tool which makes use of only a
small subset of git. The repo's contents is all binary (think of
pictures). Accordingly, I can't merge in a meaningful way, making
branches of very limited use.
The situation I'm trying to solve is:
- A revision earlier than the latest one is checked out.
- Files of this earlier commit are modified.
- I want to record this earlier commit along with it's modifications
as a new commit on top of master, ignoring intermediate commits:
com005 <-- master
com004
com003 <-- HEAD, files modified
com002
com001 (initial commit)
One solution to do this is to move all files somewhere else, check
out master, deleting all checked out files, placing the moved away
files back into place and committing the result as com006. Obviously,
this is a pretty complex operation, just waiting to exploit coding
mistakes. Additionally, this will be slow.
Now I'm thinking about a much simpler solution: Simply declare the
current set of files as (a modified) master/com005 and commit them. A
"cp $GIT_DIR/master $GIT_DIR/HEAD" followed by a commit would do it.
Now my question: Is it safe to tweak the files in $GIT_DIR this way
or will this corrupt the repository?
Thanks for any opinions,
Markus
^ permalink raw reply
* Re: [RFC PATCH 06/19] Factor ref updating out of fetch_with_import
From: Sverre Rabbelier @ 2009-11-02 15:12 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Git List, Johannes Schindelin, Johan Herland
In-Reply-To: <alpine.LNX.2.00.0911012038120.14365@iabervon.org>
Heya,
On Mon, Nov 2, 2009 at 04:16, Daniel Barkalow <barkalow@iabervon.org> wrote:
> Why not have the regular list report:
>
> @refs/heads/trunkr HEAD
>
> or whatever it is, again like native git? That is, SVN would have an
> interaction like:
That's fine with me, but earlier you said you didn't like the whole
symlinking idea.
You said in another thread you'll be working on some patches, does
that include this 'refs' command? I want to avoid duplicate work if
possible :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Binary files in a linear repository
From: Björn Steinbrink @ 2009-11-02 15:34 UTC (permalink / raw)
To: Markus Hitter; +Cc: git
In-Reply-To: <8470D32E-2CAA-4E3F-8BA0-B4578372A3C4@jump-ing.de>
On 2009.11.02 16:08:25 +0100, Markus Hitter wrote:
> The situation I'm trying to solve is:
>
> - A revision earlier than the latest one is checked out.
>
> - Files of this earlier commit are modified.
>
> - I want to record this earlier commit along with it's modifications
> as a new commit on top of master, ignoring intermediate commits:
>
> com005 <-- master
> com004
> com003 <-- HEAD, files modified
> com002
> com001 (initial commit)
>
> One solution to do this is to move all files somewhere else, check
> out master, deleting all checked out files, placing the moved away
> files back into place and committing the result as com006.
> Obviously, this is a pretty complex operation, just waiting to
> exploit coding mistakes. Additionally, this will be slow.
Instead of doing "git checkout com003", which detaches HEAD, you could
do:
git read-tree -u --reset com003
Which will update the index and working tree to reflect the contents of
com003. The modify stuff, add, commit, done.
> Now I'm thinking about a much simpler solution: Simply declare the
> current set of files as (a modified) master/com005 and commit them.
> A "cp $GIT_DIR/master $GIT_DIR/HEAD" followed by a commit would do
> it.
>
> Now my question: Is it safe to tweak the files in $GIT_DIR this way
> or will this corrupt the repository?
Ignoring that $GIT_DIR/master is the wrong path, that 'cp' would (at
best) act like detaching HEAD.
Björn
^ permalink raw reply
* Re: [PATCH] Update packfile transfer protocol documentation
From: Shawn O. Pearce @ 2009-11-02 15:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Scott Chacon, git list
In-Reply-To: <7vzl75v737.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Scott Chacon <schacon@gmail.com> writes:
> > +Git Protocol
> > +------------
> > +
> > +The Git protocol starts off by sending "git-receive-pack 'repo.git'"
> > +on the wire using the pkt-line format, followed by a null byte and a
> > +hostname paramater, terminated by a null byte.
> > +
> > + 0032git-upload-pack /project.git\0host=myserver.com\0
>
> - The example and the first line of the description contradict with each
> other.
Yes. The first line description implies the repository path is
wrapped in single quotes, but the example doesn't, because the
protocol doesn't.
> > +Initiating the upload-pack or receive-pack processes over SSH is
...
>
> This depends on the intended audience of this document, but if we are
> writing for people who want to implement their own gitosis and gitolite to
> replace the login shell spawned by ssh daemon,
We are. If we aren't, we should be. This is an area everyone has
struggled with. I had to fight with GitHub to get them to properly
support ssh:// style URLs and not just the scp-style URL.
> you may want to explain the
> "command line" given to it a bit more precisely. Specifically:
>
> - The "command name" is spelled with dash (e.g. git-upload-pack), but
> this can be overridden by the client;
>
> - The repository path is always quoted with sq (i.e. by sq_quote_buf()).
One thing I have been confused on is how ~user is handled here,
because it seems to me we would be allowing ~user outside of the
sq path, so the shell can expand ~user to /home/user or whatever.
But the C code reads to me like we don't do that.
> > +Reference Discovery
> > +-------------------
...
> > + 00441d3fcd5ced445d1abc402225c0b8a1299641f497 refs/heads/integration
> > + 003f7217a7c7e582c46cec22a130adf4b9d7d950fba0 refs/heads/master
> > + 003cb88d2441cac0977faf98efc80305012112238d9d refs/tags/v0.9
> > + 003c525128480b96c89e6418b1e40909bf6c5b2d580f refs/tags/v1.0
> > + 003fe92df48743b7bc7d26bcaabfddde0a1e20cae47c refs/tags/v1.0^{}
> > + 0000
> > +Server SHOULD terminate each non-flush line
> > +using LF ("\n") terminator; client MUST NOT complain if there is no
> > +terminator.
>
> Hmm, LF ("\n") makes me wonder how precise we would want to be. We
> probably should also say we use ASCII (meaning "not EBCDIC") somewhere but
> that level of details can wait until a more later draft..
True. But the common document which also explains our ABNF includes
a definition of LF as the byte %x0D. It might be sufficient to
also say we mean ASCII in that document, though I think these days
that's implied when you start using the IETF ABNF grammar for a
network protocol. Nobody in their right mind assumes EBCDIC.
> > +The returned response is a pkt-line stream describing each ref and
> > +its known value. The stream SHOULD be sorted by name according to
> > +the C locale ordering. The stream SHOULD include the default ref
> > +named 'HEAD' as the first ref. The stream MUST include capability
> > +declarations behind a NUL on the first ref.
>
> I have a vague recollection that in a recent discussion (not discussion on
> this documentation patch, but on a "builtin-fetch.c" patch around mid
> September), we decided that the above two SHOULD should be MUST. Another
> MUST that is missing from here is that a line that describes a peeled tag
> MUST immediately follow the tag itself.
Almost, yes.
The first SHOULD about sorting is a MUST.
Another MUST missing here is that the peeled value of a ref (that is
"ref^{}") MUST be immediately after the ref itself, if presented.
A conforming server MUST peel the ref if its an annotated tag.
The second SHOULD regarding HEAD is more delicate to word. I think
its more like:
If HEAD is a valid ref, HEAD MUST appear as the first advertised
ref. If HEAD is not a valid ref, HEAD MUST NOT appear in the
advertisement list at all, but other refs may still appear.
Consider what happens when HEAD is a symref to refs/heads/foo, but
that branch doesn't exist yet, but refs/heads/master does exist.
The repository is completely valid (it'll pass fsck --full), HEAD
won't advertise, but master will. A clone will fail with no HEAD
reference, but that doesn't mean you can't pull from it with a more
specific refspec.
We shouldn't encourage repository owners to setup their repository
with a dangling HEAD like that, but this is the wrong document to
explain that in.
> > + capability-list = capability *(SP capability)
> > + capability = 1*(ALPHA / DIGIT / "-" / "_")
> > +----
> > +
> > +Server and client SHOULD use lowercase for SHA1, both MUST treat SHA1
> > +as case-insensitive.
>
> Why do we need to retroactively loosen these to allow uppercases? Are
> there implementations that want this loosening?
Are you talking about capabilities? That was a mistake in my draft.
This should instead be:
capability = 1*(LC_ALPHA / DIGIT / "-" / "_")
LC_ALPHA = %x61-7A
If its SHA-1 you are talking about, I wanted this to be a MUST
use lowercase, but people screamed about it (Jakub and Ilari
IIRC). The current C code accepts uppercase due to its use of
get_sha1_hex(), and they wanted to follow the "be liberal in what
you accept" suggestion from other IETF authors.
IIRC, all implementations use lowercase. We should be able to safely
say MUST produce lowercase, and MUST accept lowercase, and SHOULD
NOT accept uppercase, but then the canonical C implementation isn't
exactly conforming anymore due to get_sha1_hex(). Hell, pkt-line.c
also wouldn't conform I guess, it will read uppercase hex.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Update packfile transfer protocol documentation
From: Shawn O. Pearce @ 2009-11-02 15:43 UTC (permalink / raw)
To: Scott Chacon; +Cc: git list, Junio C Hamano
In-Reply-To: <d411cc4a0911011518q15a8267bn642e6937be8c9ab1@mail.gmail.com>
Scott Chacon <schacon@gmail.com> wrote:
> I've incorporated the comments from Shawn (except for the 'annotated
> tag' comment
> in the 'include-tag' section of the capabilities doc, which I didn't
> understand).
...
> +include-tag
> +-----------
> +
> +The 'include-tag' capability is about sending tags if we are sending
> +objects they point to. If we pack an object to the client, and a tag
> +points exactly at that object, we pack the tag too. In general this
> +allows a client to get all new tags when it fetches a branch, in a
> +single network connection.
There are two types of tags, annotated and lightweight, right?
To avoid confusion here we should make it clear we only send
annotated tag objects when this feature is enabled. The protocol
doesn't have provisions to send SHA-1 to ref mapping inside of a
pack stream, so lightweight tags cannot be sent.
--
Shawn.
^ permalink raw reply
* Re: Binary files in a linear repository
From: Dmitry Potapov @ 2009-11-02 15:48 UTC (permalink / raw)
To: Markus Hitter; +Cc: git
In-Reply-To: <8470D32E-2CAA-4E3F-8BA0-B4578372A3C4@jump-ing.de>
On Mon, Nov 02, 2009 at 04:08:25PM +0100, Markus Hitter wrote:
>
> Now I'm thinking about a much simpler solution: Simply declare the
> current set of files as (a modified) master/com005 and commit them. A
> "cp $GIT_DIR/master $GIT_DIR/HEAD" followed by a commit would do it.
>
> Now my question: Is it safe to tweak the files in $GIT_DIR this way or
> will this corrupt the repository?
You probably should use 'git update-ref' if you want to change HEAD
manually. But it seems to me that you do not need even that. All what
you need is:
$ git reset --soft master
and then commit your changes (git reset --soft does not touch the index
file nor the working tree at all).
Dmitry
^ permalink raw reply
* Re: Headless tags don't have a follows or precedes?
From: Michael J Gruber @ 2009-11-02 15:54 UTC (permalink / raw)
To: Tim Mazid; +Cc: git, Paul Mackerras
In-Reply-To: <1257167247221-3931674.post@n2.nabble.com>
Tim Mazid venit, vidit, dixit 02.11.2009 14:07:
>
>
> Michael J Gruber-2 wrote:
>>
>> Tim Mazid venit, vidit, dixit 01.11.2009 10:31:
>>>
>>> Hi all,
>>>
>>> I've noticed that if I create a headless tag (one that doesn't have a
>>> branch, right?), when I click on that commit, it doesn't have precedes or
>>> follows information. Is this by design? Is there a work-around I can use
>>> without creating a branch there?
>>
>> Reposting (without even saying so) doesn't necessarily increase your
>> chance of getting responses.
>>
> I didn't repost. Or at the least, I didn't mean to repost. The mailing list
> kept complaining (spamming me) that my post was pending, and I eventually
> realised that was the old forum. I deleted it from there, and copy-pasted
> here. I didn't even realise it had posted here, and that when I deleted from
> the old forum, it didn't delete here.
>
OK :) (It git through to gmane a while ago.)
> Michael J Gruber-2 wrote:
>>
>> Would would help:
>>
>> - saying you're talking about gitk/git view/whatever it is you're
>> "clicking" on
>>
> My apologies, yes, in gitk.
>
Now we only need the version... but we'll see if current versions
reproduce it.
> Michael J Gruber-2 wrote:
>>
>> - providing a minimal example others can reproduce. That would be one
>> where a tag on a detached head (assuming that's what you mean) has no
>> precedes/follow but a tag "on a branch" does have that info
>>
>
> Example (unless specified, commands as entered into bash)
Great example, thanks!
>
> mkdir temp
> cd temp
> git init
> gitk --all &
> git commit --allow-empty -m '1'
> git tag v1
> git commit --allow-empty -m '1.1'
> git tag v1.1
> git commit --allow-empty -m '1.2'
> git tag v1.2
> (in gitk, press ctrl+f5; all follows and precedes info is there)
> git checkout v1.1
> git commit --allow-empty -m '1.1.1'
> git tag v1.1.1
> (in gitk, press f5; follows and precedes info missing for v1.1 and v1.1.1)
For me, v1.1.1 has no info and v1.1 is missing v1.1.1 in its precedes.
> (close gitk)
> gitk --all &
> (info still missing)
> git commit --allow-empty -m '1.1.2'
> git tag v1.1.2
> (in gitk, press f5, info still missing)
v1.1.1 and v1.1.2 missing all follow/precede info.
> git checkout master
> git commit --allow-empty -m '1.3'
> git tag v1.3
> (in gitk, press f5, info still missing)
Now, even v1.3 is missing its follows and v1.2 its precedes, even though
they've got nothing to do with the "detached branch".
> git commit --allow-empty -m '1.4'
> git tag v1.4
> (in gitk, press f5, info still missing)
> git checkout -b temp v1.2
> git commit --allow-empty -m '1.2.1'
> git tag v1.2.1
> (in gitk, press f5, info still missing)
> git checkout master
> git branch -D temp
> git commit --allow-empty -m '1.5'
> git tag v1.5
> (in gitk, press f5, info still missing)
>
>
> In the end, the only follows/precedes info is:
> v1: precedes v1.1
> v1.1: follows v1, precedes v1.2
> v1.2: follows v1.1
> All the rest is missing.
So basically, all connectivity which has been created after detaching
the head is missing, even that which has been created on a "proper
branch", which means (to me) it has nothing to do with git's revision
parsing (such as missing out on lightweight tags on detached heads).
I looked at the gitk code and got the expected result: no clue (tcl/tk
doesn't tick my fancy). gitk's parsing of ancestry relations seems to be
done completely in tcl (rather then relaying a lot to git-rev-parse,
which may not be efficient here). So I'll take the liberty to cc the
main gitk guy. A few more notes:
After generating v1.1.1 (which misses "follows"), .git/gitk.cache has
this (\n added for clarity):
1 1\n
6bfcf857ceef0507bb50ee17302c1d068b697540
b67f4651e49a33ee8cc77157e4e51d1e635a7c0d
{540abf2b75aec7ccbd8c0413863a018fc1c1eb37
b67f4651e49a33ee8cc77157e4e51d1e635a7c0d}\n
1\n
If I move that out of the way and rerun gitk, everything's in apple pie
order, and the cache file is:
1 3\n
2fd83b12ccea07c88f5998aa6303003ef1e4858b
540abf2b75aec7ccbd8c0413863a018fc1c1eb37
540abf2b75aec7ccbd8c0413863a018fc1c1eb37\n
6bfcf857ceef0507bb50ee17302c1d068b697540
540abf2b75aec7ccbd8c0413863a018fc1c1eb37
540abf2b75aec7ccbd8c0413863a018fc1c1eb37\n
540abf2b75aec7ccbd8c0413863a018fc1c1eb37
b67f4651e49a33ee8cc77157e4e51d1e635a7c0d
b67f4651e49a33ee8cc77157e4e51d1e635a7c0d\n
1\n
Unsurprisingly, v1.1.2 (committed & tagged on a detached head) trips
things up again, moving gitk.cache out of the way helps again.
Surprisingly, v1.3 (committed and tagged on a checked out branch) trips
things up again, moving... helps again.
Paul, I hope you can make sense of this. Something in gitk.cache
prevents gitk from rescanning for new children, an empty cache gets it
right, but only until the next run.
Michael
^ permalink raw reply
* Re: Add gitk-hit/po Hungarian translation
From: Laszlo Papp @ 2009-11-02 15:54 UTC (permalink / raw)
To: git
In-Reply-To: <a362e8010910291540y1f59ce55jd9125599f03acfe9@mail.gmail.com>
On Thu, Oct 29, 2009 at 11:40 PM, Laszlo Papp <djszapi@archlinux.us> wrote:
> Hello,
>
> See the Hungarian translation for gitk-git in the attachment!
>
> Thanks in advance
>
> Best Regards,
> Laszlo Papp
>
up!
^ permalink raw reply
* Re: Binary files in a linear repository
From: Björn Steinbrink @ 2009-11-02 16:09 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Markus Hitter, git
In-Reply-To: <20091102154831.GC27126@dpotapov.dyndns.org>
On 2009.11.02 18:48:31 +0300, Dmitry Potapov wrote:
> On Mon, Nov 02, 2009 at 04:08:25PM +0100, Markus Hitter wrote:
> >
> > Now I'm thinking about a much simpler solution: Simply declare the
> > current set of files as (a modified) master/com005 and commit them. A
> > "cp $GIT_DIR/master $GIT_DIR/HEAD" followed by a commit would do it.
> >
> > Now my question: Is it safe to tweak the files in $GIT_DIR this way or
> > will this corrupt the repository?
>
> You probably should use 'git update-ref' if you want to change HEAD
> manually. But it seems to me that you do not need even that. All what
> you need is:
>
> $ git reset --soft master
>
> and then commit your changes (git reset --soft does not touch the index
> file nor the working tree at all).
But then you still have to do:
git checkout master
git merge HEAD@{1}
To actually update the "master" branch head. The reset doesn't re-attach
HEAD.
Björn
^ permalink raw reply
* BUG: git rebase -i -p silently looses commits
From: Constantine Plotnikov @ 2009-11-02 16:18 UTC (permalink / raw)
To: Git Mailing List
I have encountered what looks like critical bugs in the git rebase -i
-p (it can be reproduced on mingw and cygwin, I have not tried other
platforms).
Let's create a git repository with
git init
# the next line is for mingw
git config core.autocrlf input
echo a >a.txt
echo b >b.txt
git add a.txt b.txt
git commit -m "init commit"
echo aa >a.txt
git add a.txt
git commit -m "aa commit"
echo bb >b.txt
git add b.txt
git commit -m "bb commit"
echo aaa >a.txt
git add a.txt
git commit -m "aaa commit"
Now let's use the following rebase command:
git rebase -i -p HEAD~3
When the editor will appear, just move the commit "bb commit" to the
end of the list. The rebase process will complete successfully, but
commit "aaa commit" will be missing from the history and working tree
will not be affected by that commit.
Other bug is that if we move "bb commit" to the top of the list in the
editor, the rebase process will apply "bb commit", but instead of
applying "aa commit" and than "aaa commit", the rebase process fails
with a merge conflict.
This can be reproduced with git 1.6.5.1 (msys) and 1.6.1.2 (cygwin). I
consider these to be a critical bugs that make "-p" option extremely
dangerous for interactive rebase. It might even make sense to disable
it for interactive rebase until the bug is fixed.
Regards,
Constantine
^ permalink raw reply
* Re: BUG: git rebase -i -p silently looses commits
From: demerphq @ 2009-11-02 16:33 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: Git Mailing List
In-Reply-To: <85647ef50911020818p61d0c975kd5655fa58993e07b@mail.gmail.com>
2009/11/2 Constantine Plotnikov <constantine.plotnikov@gmail.com>:
> I have encountered what looks like critical bugs in the git rebase -i
> -p (it can be reproduced on mingw and cygwin, I have not tried other
> platforms).
>
> Let's create a git repository with
>
> git init
> # the next line is for mingw
> git config core.autocrlf input
> echo a >a.txt
> echo b >b.txt
> git add a.txt b.txt
> git commit -m "init commit"
> echo aa >a.txt
> git add a.txt
> git commit -m "aa commit"
> echo bb >b.txt
> git add b.txt
> git commit -m "bb commit"
> echo aaa >a.txt
> git add a.txt
> git commit -m "aaa commit"
>
> Now let's use the following rebase command:
>
> git rebase -i -p HEAD~3
>
> When the editor will appear, just move the commit "bb commit" to the
> end of the list. The rebase process will complete successfully, but
> commit "aaa commit" will be missing from the history and working tree
> will not be affected by that commit.
>
> Other bug is that if we move "bb commit" to the top of the list in the
> editor, the rebase process will apply "bb commit", but instead of
> applying "aa commit" and than "aaa commit", the rebase process fails
> with a merge conflict.
>
> This can be reproduced with git 1.6.5.1 (msys) and 1.6.1.2 (cygwin). I
> consider these to be a critical bugs that make "-p" option extremely
> dangerous for interactive rebase. It might even make sense to disable
> it for interactive rebase until the bug is fixed.
Doesnt -p ONLY work for interactive rebase?
-p, --preserve-merges
Instead of ignoring merges, try to recreate them. This
option only works in interactive mode.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: [RFC PATCH 06/19] Factor ref updating out of fetch_with_import
From: Daniel Barkalow @ 2009-11-02 16:36 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git List, Johannes Schindelin, Johan Herland
In-Reply-To: <fabb9a1e0911020712q4920e009w5a6d435be205b68e@mail.gmail.com>
On Mon, 2 Nov 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Mon, Nov 2, 2009 at 04:16, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > Why not have the regular list report:
> >
> > @refs/heads/trunkr HEAD
> >
> > or whatever it is, again like native git? That is, SVN would have an
> > interaction like:
>
> That's fine with me, but earlier you said you didn't like the whole
> symlinking idea.
Now that you're not using them for other stuff, they're free to use for
their normal purpose without confusion. The normal layout for a remote git
repository's refs has HEAD as a symlink to something in refs/heads/*, so
it's
> You said in another thread you'll be working on some patches, does
> that include this 'refs' command? I want to avoid duplicate work if
> possible :).
No, I'm just working on getting the handler to work in a context where
there's no local repository, if possible. This will probably generate a
bunch of easy conflicts, but not actually overlap with what you're doing
here.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Binary files in a linear repository
From: Dmitry Potapov @ 2009-11-02 16:52 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Markus Hitter, git
In-Reply-To: <20091102160903.GA6197@atjola.homenet>
On Mon, Nov 02, 2009 at 05:09:03PM +0100, Björn Steinbrink wrote:
> On 2009.11.02 18:48:31 +0300, Dmitry Potapov wrote:
> > On Mon, Nov 02, 2009 at 04:08:25PM +0100, Markus Hitter wrote:
> > >
> > > Now I'm thinking about a much simpler solution: Simply declare the
> > > current set of files as (a modified) master/com005 and commit them. A
> > > "cp $GIT_DIR/master $GIT_DIR/HEAD" followed by a commit would do it.
> > >
> > > Now my question: Is it safe to tweak the files in $GIT_DIR this way or
> > > will this corrupt the repository?
> >
> > You probably should use 'git update-ref' if you want to change HEAD
> > manually. But it seems to me that you do not need even that. All what
> > you need is:
> >
> > $ git reset --soft master
> >
> > and then commit your changes (git reset --soft does not touch the index
> > file nor the working tree at all).
>
> But then you still have to do:
> git checkout master
> git merge HEAD@{1}
>
> To actually update the "master" branch head. The reset doesn't re-attach
> HEAD.
You are right... I forgot about that somehow. So, it should be
$ git reset --soft master
$ git checkout master
and only then
$ git commit
Dmitry
^ permalink raw reply
* Re: BUG: git rebase -i -p silently looses commits
From: Sverre Rabbelier @ 2009-11-02 16:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List, Constantine Plotnikov
In-Reply-To: <85647ef50911020818p61d0c975kd5655fa58993e07b@mail.gmail.com>
Heya,
On Mon, Nov 2, 2009 at 17:18, Constantine Plotnikov
<constantine.plotnikov@gmail.com> wrote:
> I have encountered what looks like critical bugs in the git rebase -i
> -p (it can be reproduced on mingw and cygwin, I have not tried other
> platforms).
Johannes has been working off and on on fixing git rebase -i -p to
DTRT, perhaps this is related?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: BUG: git rebase -i -p silently looses commits
From: Constantine Plotnikov @ 2009-11-02 16:59 UTC (permalink / raw)
To: demerphq; +Cc: Git Mailing List
In-Reply-To: <9b18b3110911020833y56be8fbdoaf10b6e6259f57c8@mail.gmail.com>
On Mon, Nov 2, 2009 at 7:33 PM, demerphq <demerphq@gmail.com> wrote:
> 2009/11/2 Constantine Plotnikov <constantine.plotnikov@gmail.com>:
> Doesnt -p ONLY work for interactive rebase?
>
> -p, --preserve-merges
> Instead of ignoring merges, try to recreate them. This
> option only works in interactive mode.
>
Yep, I forgot about it. But it does not seem to work correctly for
interactive rebase either.
Constantine
^ permalink raw reply
* Re: Binary files in a linear repository
From: Björn Steinbrink @ 2009-11-02 17:01 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Markus Hitter, git
In-Reply-To: <20091102165215.GD27126@dpotapov.dyndns.org>
On 2009.11.02 19:52:15 +0300, Dmitry Potapov wrote:
> On Mon, Nov 02, 2009 at 05:09:03PM +0100, Björn Steinbrink wrote:
> > On 2009.11.02 18:48:31 +0300, Dmitry Potapov wrote:
> > > On Mon, Nov 02, 2009 at 04:08:25PM +0100, Markus Hitter wrote:
> > > You probably should use 'git update-ref' if you want to change HEAD
> > > manually. But it seems to me that you do not need even that. All what
> > > you need is:
> > >
> > > $ git reset --soft master
> > >
> > > and then commit your changes (git reset --soft does not touch the index
> > > file nor the working tree at all).
> >
> > But then you still have to do:
> > git checkout master
> > git merge HEAD@{1}
> >
> > To actually update the "master" branch head. The reset doesn't re-attach
> > HEAD.
>
> You are right... I forgot about that somehow. So, it should be
>
> $ git reset --soft master
> $ git checkout master
>
> and only then
>
> $ git commit
That would do, but:
git checkout <commit>
*make changes*
git reset --soft master
git checkout master
git commit
seems unnecessarily complicated, when you could as well do:
git read-tree -u --reset <commit>
*make changes*
git commit
Björn
^ permalink raw reply
* Re: [PATCH] Update packfile transfer protocol documentation
From: Junio C Hamano @ 2009-11-02 17:31 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Scott Chacon, git list
In-Reply-To: <20091102154104.GR10505@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> If its SHA-1 you are talking about, I wanted this to be a MUST
> use lowercase, but people screamed about it (Jakub and Ilari
> IIRC). The current C code accepts uppercase due to its use of
> get_sha1_hex(), and they wanted to follow the "be liberal in what
> you accept" suggestion from other IETF authors.
>
> IIRC, all implementations use lowercase. We should be able to safely
> say MUST produce lowercase, and MUST accept lowercase, and SHOULD
> NOT accept uppercase,...
I do not see a point in loosening or tightening the definition
document that is written to describe a protocol of a reference
implementation after the fact. It is not like producing lowercase
hexdegits is a lot more work on some weird platforms.
Everybody writes in lowercase, expects to see lowercase, and some may
accept uppercase by accident. I think it is acceptable to describe that
as "MUST produce, MUST accept lc and MAY accept uc", but I do not think it
is even necessary to specifically say "and MAY accept uc".
It is actively wrong to say "SHOULD NOT accept uc"---it won't help
anybody.
^ permalink raw reply
* Re: BUG: git rebase -i -p silently looses commits
From: Johannes Schindelin @ 2009-11-02 17:34 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: Git Mailing List
In-Reply-To: <85647ef50911020818p61d0c975kd5655fa58993e07b@mail.gmail.com>
Hi,
On Mon, 2 Nov 2009, Constantine Plotnikov wrote:
> I have encountered what looks like critical bugs in the git rebase -i
> -p (it can be reproduced on mingw and cygwin, I have not tried other
> platforms).
rebase -i -p was never intended to reorder commits. In fact, the "-i" of
it was only for convenience: I was more familiar with the code base of
rebase -i than that of rebase.
Having said that, I worked for some time on fixing this issue, and I
actually run a version of rebase -i -p here that allows reordering
commits, but it is far from stable (and due to GSoC and day-job
obligations, I had no time to work on it in months).
Ciao,
Dscho
^ permalink raw reply
* Re: Binary files in a linear repository
From: Dmitry Potapov @ 2009-11-02 17:45 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Markus Hitter, git
In-Reply-To: <20091102170106.GA8650@atjola.homenet>
On Mon, Nov 02, 2009 at 06:01:06PM +0100, Björn Steinbrink wrote:
>
> That would do, but:
> git checkout <commit>
> *make changes*
> git reset --soft master
> git checkout master
> git commit
>
> seems unnecessarily complicated, when you could as well do:
> git read-tree -u --reset <commit>
> *make changes*
> git commit
I thought Markus *already* had made changes on that commit, but
maybe I misread what he wrote...
Dmitry
^ permalink raw reply
* Re: Binary files in a linear repository
From: Björn Steinbrink @ 2009-11-02 18:37 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Markus Hitter, git
In-Reply-To: <20091102174546.GE27126@dpotapov.dyndns.org>
On 2009.11.02 20:45:46 +0300, Dmitry Potapov wrote:
> I thought Markus *already* had made changes on that commit, but
> maybe I misread what he wrote...
Hm, I understood that the described scenario is one he wants to
implement in his front-end, and that he was asking for advice how to
do it. I guess only Martin can tell for sure, so let's see :-)
Björn
^ permalink raw reply
* Re: Fw: git-core: SIGSEGV during {peek,ls}-remote on HTTP remotes.
From: Clemens Buchacher @ 2009-11-02 19:21 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Jeff King, Junio C Hamano, Sverre Rabbelier, Samium Gromoff, git,
Tay Ray Chuan, Mike Hommey
In-Reply-To: <alpine.LNX.2.00.0911011829130.14365@iabervon.org>
On Sun, Nov 01, 2009 at 07:59:45PM -0500, Daniel Barkalow wrote:
> I've been looking at it, just now, and I might try to clean stuff up. The
> problem I'm running into is that, in some cases, you have to call
> setup_git_directory_gently(), and it might determine that there is no git
> repo, but then the various environment functions don't distinguish between
> the situation where you haven't called it at all and the situation where
> you called it and determined there to be no answer. Furthermore, a lot of
> functions seem to be getting git_path(something), ignoring the fact that
> there is no repo, and acting like there is a repo that has simply not got
> the file it is looking for.
Indeed. In particular, you can cause most git commands which take a path
argument to segfault in GIT_DIR:
$ git grep -- /
Segmentation fault
$ git ls-files /
Segmentation fault
$ git show HEAD /
Segmentation fault
$ git diff HEAD /
Segmentation fault
You get the idea. It looks like at some point each of these calls
get_git_work_tree(), which returns NULL. I was trying to fix it this weekend
but got confused by the setup api (to be documented in
Documentation/technical/api-setup.txt). I don't think fixing all the callers
of get_git_work_tree() is the right thing to do. Instead, we should die() if
there is no work tree and a different function should be used to check
whether or not a work tree exists.
I will try to understand this convoluted codepath when I have gathered the
patience to do it. But while you're looking at it, maybe you can also take
this issue into consideration.
Thanks,
Clemens
^ 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