* git subtree issues
From: morgflast @ 2009-11-03 3:56 UTC (permalink / raw)
To: git
So, I went ahead and did this
$ git remote add -f vw_extensions git@github.com:sibblingz/vw_extensions.git
(1)
$ git merge -s ours --no-commit vw_extensions/master (2)
$ git read-tree --prefix=some/directory/vw_extensions -u
vw_extensions/master (3)
$ git commit -m "Merge B project as our subdirectory"
And that all seems to work ok.
Then, I went to another directory where i had vw_extensions cloned, and made
a change to the README file, and pushed it.
I went back to my first project, and did this, to try to pull those changes:
git pull -s subtree vw_extensions master remote: Counting objects: 5, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 2), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From git@github.com:sibblingz/vw_extensions
* branch master -> FETCH_HEAD
Already uptodate!
Merge made by subtree.
However, when I looked at the README file in the first project, the changes
weren't there. I was wondering if anyone might have any suggestions about
what to do.
Thanks!
Daniel
--
View this message in context: http://old.nabble.com/git-subtree-issues-tp26159961p26159961.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: using merge subtree and move it..
From: Milos Jakubicek @ 2009-11-03 2:57 UTC (permalink / raw)
To: git
In-Reply-To: <48C64911.4020202@posdata.co.kr>
SungHyun Nam wrote:
>
>
> BTW, I have no idea how I can push 'local changes in subtree' to remote.
> The 'Additional tips' in using-merge-subtree.txt said it is
> possible using subtree. But don't know how? Could someone show me
> a sample command/setup sequence?
>
I found out:
edit your .git/config file and in the [remote "remotename"] section, copy
the "fetch =" line as "push =" line (with same content after "="). Then by
"git push remotename" you'll just push the relevant subtree.
--
View this message in context: http://n2.nabble.com/using-merge-subtree-and-move-it-tp1076542p3936273.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Problem signing a tag
From: Joshua J. Kugler @ 2009-11-03 0:58 UTC (permalink / raw)
To: git
Nobody on the git IRC channel responded to this question, even after
asking it a few times, so I thought I'd try here.
I'm having trouble signing a tag. I'm using this command:
git tag -u EAFD344D14EA086E -F .git/TAG_EDITMSG tag_name
I type in my passphrase, and am then told:
error: gpg failed to sign the tag
error: unable to sign the tag
However, if I use this command:
gpg -s -u EAFD344D14EA086E
and use the same passphrase, it works fine. Is there any way to find out
why a key-signing is failing?
This is git 1.6.5.2 and gpg 1.4.9
Thanks!
j
--
Joshua Kugler
Part-Time System Admin/Programmer
http://www.eeinternet.com
PGP Key: http://pgp.mit.edu/ ID 0x14EA086E
^ permalink raw reply
* Re: [PATCH] Update packfile transfer protocol documentation
From: Shawn O. Pearce @ 2009-11-03 0:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Scott Chacon, git list
In-Reply-To: <7vtyxctpf8.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> > Junio C Hamano <gitster@pobox.com> wrote:
> > ...
> >> Shouldn't we say "the client MUST NOT make reference update request if
> >> everything is up to date" which would imply that in practice there is no
> >> reason to send an empty pack data?
Creating new branch quirk aside, I do agree with this. Clients
shouldn't send no-op updates if it knows in advance the update is
a no-op.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Update packfile transfer protocol documentation
From: Junio C Hamano @ 2009-11-03 0:36 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Scott Chacon, git list
In-Reply-To: <20091102235707.GV10505@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> Shouldn't we say "the client MUST NOT make reference update request if
>> everything is up to date" which would imply that in practice there is no
>> reason to send an empty pack data?
>
> Create a new branch to point at an existing object. Branch creation
> causes a pack to be expected, but if you are creating a new branch
> that points at an existing object there is nothing to pack. E.g.:
>
> git remote add -f A user@host:proj.git
> git push A A/master:refs/heads/new-branch
>
> causes a 0 object pack file to be sent, assuming the remote project's
> master branch has not changed in between the two commands.
Ahh, you are right. Thanks.
^ permalink raw reply
* Re: [PATCH] Update packfile transfer protocol documentation
From: Shawn O. Pearce @ 2009-11-02 23:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Scott Chacon, git list
In-Reply-To: <7vzl74trmc.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Scott Chacon <schacon@gmail.com> writes:
> > +
> > +A pack-file MUST be sent if either create or update command is used.
>
> Easier to read if MUST is followed by "_even_ if", like so:
>
> ... MUST be sent when a create or update command is used, even if the
> server already has all the necessary objects.
>
> Shouldn't we say "the client MUST NOT make reference update request if
> everything is up to date" which would imply that in practice there is no
> reason to send an empty pack data?
Create a new branch to point at an existing object. Branch creation
causes a pack to be expected, but if you are creating a new branch
that points at an existing object there is nothing to pack. E.g.:
git remote add -f A user@host:proj.git
git push A A/master:refs/heads/new-branch
causes a 0 object pack file to be sent, assuming the remote project's
master branch has not changed in between the two commands.
> > + pack-file = "PACK" 24*(OCTET)
>
> Curious---where does this 24 come from?
Hmmph. Its wrong actually. I was trying to write the minimum
number of bytes that make up a pack file, which is actually 28.
(12 in the header minus 4 as "PACK" was already spelled out, plus
20 in the footer for the SHA-1).
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Update packfile transfer protocol documentation
From: Junio C Hamano @ 2009-11-02 23:48 UTC (permalink / raw)
To: Scott Chacon; +Cc: git list, Shawn O. Pearce, Junio C Hamano
In-Reply-To: <d411cc4a0911011518q15a8267bn642e6937be8c9ab1@mail.gmail.com>
Scott Chacon <schacon@gmail.com> writes:
> +Packfile Negotiation
> ...
> +Clients MUST send all the SHAs it wants from the reference
Not "SHAs", but "object names". It also is Ok to say "obj-ids" as you
are using "obj-id" in the syntax description above (and later paragraphs
in this section).
> +discovery phase as 'want' lines. Clients MUST send at least one
> +'want' command in the request body. Clients MUST NOT mention an
> +obj-id in a 'want' command which did not appear in the response
> +obtained through ref discovery.
> +
> +If client is requesting a shallow clone, it will now send a 'deepen'
> +command with the depth it is requesting.
> +
> +Once all the "want"s (and optional 'deepen') are transferred,
> +clients MUST send a flush. If the client has all the references on
> +the server, client simply flushes and disconnects.
The last sentence is a repetition of the first sentence in this section,
isn't it?
> +TODO: shallow/unshallow response and document the deepen command in the ABNF.
> +
> +Now the client will send a list of the obj-ids it has. In multi_ack
Need to say something like 'using "have" lines'.
> +mode, the canonical implementation will send up to 32 of these at a
> +time, then will send a flush-pkt. The canonical implementation will
> +also skip ahead and send the next 32 immediately, so that there is
> +always a block of 32 "in-flight on the wire" at a time.
I'm a bit lost with this "will also". Is it describing what happens
without multi-ack? That is, "with multi-ack, 32 haves are sent ahead, and
this is also done without multi-ack" (which I think is correct, but is a
confusing way to say it)?
> +If the client has no objects (as in the case of a non-referencing
> +clone), it will skip this phase, just send it's 'done' and wait for
> +the packfile.
Hmm, it logically follows that it will say 'done' without any list of
have, if the downloader is in an empty repository. Are these three lines
worth having?
> +A simple clone may look like this (with no 'have' statements):
The document uses three words (statement, command, line) to refer to the
same thing --- I think we should just pick and stick to one. I think
existing documents say "want line", "have line", but I didn't count.
> +----
> + C: 0054want 74730d410fcb6603ace96f1dc55ea6196122532d\0multi_ack \
> + side-band-64k ofs-delta\n
> + C: 0032want 7d1665144a3a975c05f1f43902ddaf084e784dbe\n
> + C: 0032want 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a\n
> + C: 0032want 7e47fe2bd8d01d481f44d7af0531bd93d3b21c01\n
> + C: 0032want 74730d410fcb6603ace96f1dc55ea6196122532d\n
> + C: 0000
> + C: 0009done\n
> +
> + S: 0008NAK\n
> + S: [PACKFILE]
> +----
> +
> +An incremental update (fetch) response might look like this:
> +
> +----
> + C: 0054want 74730d410fcb6603ace96f1dc55ea6196122532d\0multi_ack \
> + side-band-64k ofs-delta\n
> + C: 0032want 7d1665144a3a975c05f1f43902ddaf084e784dbe\n
> + C: 0032want 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a\n
> + C: 0000
> + C: 0032have 7e47fe2bd8d01d481f44d7af0531bd93d3b21c01\n
> + C: [30 more have lines]
> + C: 0032have 74730d410fcb6603ace96f1dc55ea6196122532d\n
> + C: 0000
> +
> + S: 003aACK 7e47fe2bd8d01d481f44d7af0531bd93d3b21c01 continue\n
> + S: 003aACK 74730d410fcb6603ace96f1dc55ea6196122532d continue\n
> + S: 0008NAK\n
> +
> + C: 0009done\n
> +
> + S: 003aACK 74730d410fcb6603ace96f1dc55ea6196122532d\n
> + S: [PACKFILE]
> +----
Nice.
> +Packfile Data
> +-------------
> +
> +Now that the client and server have done some negotiation about what
> +the minimal amount of data that can be sent to the client is, the server
> +will construct and send the required data in packfile format.
> +
> +See pack-format.txt for what the packfile itself actually looks like.
> +
> +If 'side-band' or 'side-band-64k' capabilities have been specified by
> +the client, the server will send the packfile data multiplexed.
> +
> +Each packet starting with the packet-line length of the amount of data
> +that follows, followed by a single byte specifying the sideband the
> +following data is coming in on.
> +
> +In 'side-band' mode, it will send 999 data bytes plus 1 control code,
> +for a total of 1000 bytes in a pkt-line. In 'side-band-64k' mode it
> +will send 65519 data bytes plus 1 control code, for a total of 65520
> +bytes in a pkt-line.
It would need to say "up to 999" (and "up to 65519").
> +The sideband byte will be either a '1' or a '2'. Sideband '1' will contain
> +packfile data, sideband '2' will be used for progress information that the
> +client will generally print to stderr.
Band '3' is used for emergency abort, isn't it?
> +Pushing Data To a Server
> +========================
> +
> +Pushing data to a server will invoke the 'receive-pack' process on the
> +server, which will allow the client to tell it which references it should
> +update and then send all the data the server will need for those new
> +references to be complete. Once all the data is received and validated,
> +the server will then update it's references to what the client specified.
> +
> +Authentication
> +--------------
> +
> +The protocol itself contains no authentication mechanisms. That is to be
> +handled by the transport, such as SSH, before the 'receive-pack' process is
> +invoked. If 'receive-pack' is configured over the Git transport, those
> +repositories will be writable by anyone who can access that port (9418) as
> +that transport is unauthenticated.
> +
> +Reference Discovery
> +-------------------
> +
> +The reference discovery phase is done nearly the same way as it is in the
> +fetching protocol. Each reference obj-id and name on the server is sent
> +in packet-line format to the client, followed by a flush packet. The only
> +real difference is that the capability listing is different - the only
> +possible values are 'report-status', 'delete-refs' and 'ofs-delta'.
We should describe what should happen when there are new capabiliities
advertised by the other side that we do not understand (we ignore, and do
not barf). Even though I forgot to comment on the fetch side, there is
the same issue over there.
If the receiving end does not support delete-refs, the sending end MUST
NOT ask for delete command.
> +Reference Update Request and Packfile Transfer
> +----------------------------------------------
> +
> +Once the client knows what references the server is at, it can send a
> +list of reference update requests. For each reference on the server
> +that it wants to update, it sends a line listing the obj-id currently on
> +the server, the obj-id the client would like to update it to and the name
> +of the reference.
> +
> +This list is followed by a flush packet and then the packfile that should
> +contain all the objects that the server will need to complete the new
> +references.
> +
> +The pack-file MUST NOT be sent if the only command used is 'delete'.
> +
> +A pack-file MUST be sent if either create or update command is used.
> +An empty pack-file MUST be sent if a create or update command is
> +used, and the server already obviously has the object (e.g. the
> +SHA-1 is already pointed to by another ref that was listed in the
> +advertisement).
Easier to read if MUST is followed by "_even_ if", like so:
... MUST be sent when a create or update command is used, even if the
server already has all the necessary objects.
Shouldn't we say "the client MUST NOT make reference update request if
everything is up to date" which would imply that in practice there is no
reason to send an empty pack data?
> +----
> + update-request = command-list [pack-file]
> +
> + command-list = PKT-LINE(command NUL capability-list LF)
> + *PKT-LINE(command LF)
> + flush-pkt
> +
> + command = create / delete / update
> + create = zero-id SP new-id SP name
> + delete = old-id SP zero-id SP name
> + update = old-id SP new-id SP name
> +
> + old-id = obj-id
> + new-id = obj-id
> +
> + pack-file = "PACK" 24*(OCTET)
Curious---where does this 24 come from?
> +----
> +
> +The server will receive the packfile, unpack it, then validate each
> +reference that is being updated that it hasn't changed while the request
> +was being processed (the obj-id is still the same as the old-id), and
> +it will run any update hooks to make sure that the update is acceptable.
> +If all of that is fine, the server will then update the references.
Nice.
> +Report Status
> +-------------
> +
> +If the 'report-status' capability is sent by the client, then the server
> +will send a short report of what happened in that update. It will first
> +list the status of the packfile unpacking as either 'unpack ok' or
> +'unpack [error]'. Then it will list the status for each of the references
> +that it tried to update. Each line be either 'ok [refname]' if the
> +update was successful, or 'ng [refname] [error]' if the update was not.
Unlike previous sections, this section does not begin with "after the
above is done, this happens", so it is not clear where in the protocol
exchange this report is done. Presumably, you meant "After receiving the
pack data from the sender, the receiver sends a report if report-status
was asked previously"?
> +----
> + report-status = unpack-status
> + 1*(command-status)
> + flush-pkt
> +
> + unpack-status = PKT-LINE("unpack" SP unpack-result LF)
> + unpack-result = "ok" / error-msg
> +
> + command-status = command-ok / command-fail
> + command-ok = PKT-LINE("ok" SP refname LF)
> + command-fail = PKT-LINE("ng" SP refname SP error-msg LF)
> +
> + error-msg = 1*(OCTECT) ; where not "ok"
> +----
> +
> +Updates can be unsuccessful for a number of reasons. The reference can have
> +changed since the reference discovery phase was originally sent, meaning
> +someone pushed in the meantime. The reference being pushed could be a
> +non-fast-forward reference and the update hooks or configuration could be
> +set to not allow that, etc. Also, some references can be updated while others
> +can be rejected.
Nice.
> +An example client/server communication might look like this:
> +
> +----
> + S: 007c74730d410fcb6603ace96f1dc55ea6196122532d
> refs/heads/local\0report-status delete-refs ofs-delta\n
> + S: 003e7d1665144a3a975c05f1f43902ddaf084e784dbe refs/heads/debug\n
> + S: 003f74730d410fcb6603ace96f1dc55ea6196122532d refs/heads/master\n
> + S: 003f74730d410fcb6603ace96f1dc55ea6196122532d refs/heads/team\n
> + S: 0000
> +
> + C: 003e7d1665144a3a975c05f1f43902ddaf084e784dbe
> 74730d410fcb6603ace96f1dc55ea6196122532d refs/heads/debug\n
> + C: 003e74730d410fcb6603ace96f1dc55ea6196122532d
> 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a refs/heads/master\n
> + C: 0000
> + C: [PACKDATA]
> +
> + S: 000aunpack ok\n
> + S: 0014ok refs/heads/debug\n
> + S: 0026ng refs/heads/master non-fast-forward\n
Thanks; my review on the remainder will be in a (yet another) separate
message.
^ permalink raw reply
* Re: git pull --rebase and losing commits
From: Nanako Shiraishi @ 2009-11-02 21:34 UTC (permalink / raw)
To: Thomas Rast; +Cc: Peter Krefting, Git Mailing List
In-Reply-To: <200911021604.24066.trast@student.ethz.ch>
Quoting Thomas Rast <trast@student.ethz.ch>
> It is *not*
> the often requested (but ill-defined and hence never implemented)
> "resolve all conflict hunks in favour of ours" strategy.
This was implemented and posted here quite some time ago.
http://thread.gmane.org/gmane.comp.version-control.git/85163/focus=85602
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: Using git with eclipse (jgit/egit?)
From: Sverre Rabbelier @ 2009-11-02 20:33 UTC (permalink / raw)
To: Nico -telmich- Schottelius; +Cc: git, Robin Rosenberg, Shawn O. Pearce
In-Reply-To: <20091102201207.GG4064@inf.ethz.ch>
Heya,
On Mon, Nov 2, 2009 at 21:12, Nico -telmich- Schottelius
<nico-linux-git@schottelius.org> wrote:
> What's currently the best way to use git with eclipse?
> Using jgit or egit? And if so, what's the easiest way to
> install either? Is there any update-site available?
> Is it usable for development at all?
According to [0] there is a download site you can point your eclipse
download manager at [1] and use an unofficial periodic snapshot, but
Robin or Shawn might have more accurate information.
[0] http://www.eclipse.org/egit/install.php
[1] http://www.jgit.org/updates
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Using git with eclipse (jgit/egit?)
From: Nico -telmich- Schottelius @ 2009-11-02 20:12 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 560 bytes --]
Hey!
What's currently the best way to use git with eclipse?
Using jgit or egit? And if so, what's the easiest way to
install either? Is there any update-site available?
Is it usable for development at all?
Sorry for asking so much, there is a lot of information
available, but nothing out there seems to say
"Hey eclipse newbie, click here and you have git support in eclipse."
Sincerely,
Nico
--
Currently moving *.schottelius.org to http://www.nico.schottelius.org/ ...
PGP: BFE4 C736 ABE5 406F 8F42 F7CF B8BE F92A 9885 188C
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ 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
* 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: 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: 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: [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: 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: 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: 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: 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: [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: 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
* 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: 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
* 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: 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
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